I plan to write some coding guidelines for iOS extending what’s here (not much, I know), but one thing I need to warn right now, just in case:
If you add any external libraries, don’t modify them.
That said, if you need to change them to fit our app:
- Make it generic enough to be accepted by the original developer, if it fixes a general problem
- Try creating a subclass, or find other workaround, if it’s too specific to our app
- If you absolutely must modify the library, at least commit a clean copy of it to svn, then apply your changes and commit. This way we can have a diff of what we’ve modified and update the library easily in the future
This came from trying to update the XMLRPC library. Our version was really old, the first version committed to our svn already had modifications, in all this time they moved from svn to git losing the history. There was no sane way to figure out what our changes were compared to the original version to port them over the latest version, so I had to take a guess (only picked the changes after it was added to svn)
Dan are discussing. 
Jorge Bernal 8:39 pm on December 16, 2011 Permalink |
I also plan next week to move all the libraries to a Vendor directory, so it’s easier to differentiate our code from third party. Since we can’t have git externals/submodules in svn, I was planning to just store a list of libraries in a text file. Something like this:
I’ve been looking at dependency management for Objective-C like CocoaPods and VendorKit, but I’m not sold on any of those yet.
Dan 8:59 am on December 28, 2011 Permalink |
Speaking of external libraries, AFNetworking has a bunch of example code in it. We should remove that at some point.
Jorge Bernal 10:53 am on December 28, 2011 Permalink |
Not 100% happy about it, but it goes to the “don’t modify”. Since we can’t have them as externals/submodules, I tried to keep the files the same as upstream, and add only what we need in the Xcode project.