CocoaPods > Git Submodules

I must take a moment to recant some comments I made over a year ago about CocoaPods in a post about OCMock.  The first time I came across CocoaPods I thought it was pretty awesome, but then reality set in.  I had problems getting my project configured.  It would sometimes crash with cryptic errors (and still does if you have syntax issues).  I had trouble getting it to work with our continuous integration system.  Then a developer I have much respect for told me to just use Git submodules–it does what CocoaPods tries to do the “right way” I was informed.

Fast forward a year and I have changed my tune.  Git submodules is a reasonable solution to the problem of integrating other projects–but that’s not the primary problem that CocoaPods solves.  The real power of CocoaPods is having a searchable repository of open source frameworks at your fingertips.  In addition, with Git submodules there is usually a messy bit of configuration to do in order to get the framework integrated–and if you decide you don’t want to use it, additionally messy work to remove it.

CocoaPods makes it simple to find and include thousands of open source frameworks into your project.  It does the heavy lifting of dealing with dependencies and integrating into your project.  It works with Xcode’s Bots and Jenkins.  You can even configure it to use a private repository which contains your own frameworks that are not to be distributed to the public.

What’s even cooler? It makes it drop-dead simple to create and distribute a framework for iOS or Mac.

The only thing you need to do is evaluate the quality of the code you’re using.  There’s a lot of stuff out there and not all of it is great.  Buyer beware (the linked article is about Ruby Gems, but applies to all open source code).

 

Testing Your Software: Or How To Make Changes With Confidence

Writing unit tests is important.  Without unit tests, how do you know that your software still works when someone makes a change?  Sure, you can deploy a small army of manual testers to double-check that it still “works.”  But maybe the change you made has subtle effects in disparate parts of your code–are your testers going to cover everything?

The best way to have confidence that your code is functioning properly is to build and maintain a suite of unit tests.  There are entire books written about this topic (for iOS developers I like Test-Drive iOS Development by Graham Lee), but the most recent issue of objc.io covers just this very topic and is a great place to start if you’ve never written tests in Objective C.

 

Top 10 CoreData Tools

Matthew Morey on the Ray Wenderlich website has written a great post on his top 10 CoreData tools to help make one’s life easier. I’ve written a bunch of code to manage CoreData stacks, make fetch requests, ingest JSON in to CoreData and serialize back into JSON… some of these tools are a big time saver.

One thing I would note though: the author’s own framework (MDMCoreData) looks helpful–but I wouldn’t initialize it on the main thread, as it could take a long time if there is a migration required. You wouldn’t want your app to become unresponsive and get killed with everyone’s favorite 0x8badf00d

Apple Gives Some Love to Older Devices

As an iOS developer dealing with old devices is a thorny problem. Progress in iOS marches ever onward and eventually a new version comes out which drops support for older devices. You are then faced with a choice: keep supporting that older OS and your established customers who are unable to upgrade, or abandon them.

Apple has come up with a new feature for users on older versions of iOS which allows them to download the last compatible version of your app.  This is good news for users and potentially a headache for developers.

I always try to support the older OS as long as possible. If there’s a new OS feature I’d like to take advantage of it’s usually possible to do so–and make it so that feature is simply unavailable for users on an older OS version. But at some point there is a fundamental new feature you want to support that requires an architecture change to your code and means dropping that old OS.

When it does finally come time to abandon support for an OS version I always try to make sure there is one final version of my app that has a number of bug fixes and improvements that will leave these people happy until such time as they get a new device that can support the latest OS.  This version of the app goes up in the app store and in the “What’s New” metadata I’ll highlight that the update is the last version to support whichever OS version is being dropped.  I’ll leave this version in place for several weeks to a month–which should be ample time for my users to update.

Still, some stragglers who are lazy about updating their device might not get around to it, or some new customer with an older device might hear about my app and want to try it.  Apple’s new system is going to help them out by letting them download and use my app.  Hooray!  This is good news for them and for me.

The one main gotcha is if that last version is a doozy–perhaps because of some nasty bugs I never got around to fixing.  Undoubtedly there will be developers in this camp and some people who are unhappy with Apple’s latest move.  I think this just highlights the importance of doing that final maintenance release before you drop support for an OS.

Update 9/20/13

Kyle Richter (co-founder of Empirical Development) points out some additional considerations with Apple’s new service.  I agree there are some pitfalls, but on balance I still think this is a win for users–as long as developers are careful to put out a high-quality final version before dropping support for an older OS version.

Thread This!

Today I wrote a utility to ease the use of dispatch queues and GCD (Grand Central Dispatch) in Objective-C.  GCD is very powerful, but it’s written in C and I often find there’s a lot of boilerplate code required in order to use it.  So I wrote a light wrapper called NHThreadThis which makes it a bit easier.  Of course the provided source code has unit tests and a sample app.

@todo: dispatch I/O and sources API support!

Concurrency in iOS

There are many and more articles on concurrency in iOS and Objective-C, but I think this is a great one.  However, I recommend skipping over the talk about threads and go straight to GCD and NSOperationQueue.  There’s really no reason to manage your own threads any more (unless you’re porting over some code to iOS)–unless of course you like debugging hard-to-find threading issues in your app!

One further caveat: the section which discusses managing shared resources could use a little improvement.  It is correct that traditionally one uses a lock to manage access to a shared resource.  However, there is a much better way to do this in iOS, and that is with GCD and a serial queue.  Consider the following code example:

@implementation MyController ()
@property (nonatomic, assign) dispatch_queue_t sharedResourceQueue;
@property (nonatomic, assign) NSUInteger sharedCounter;
@end

@implementation MyController

- (id)init {
    if ((self = [super init])) {
        _sharedResourceQueue = dispatch_queue_create("com.myidentifier.MyCoolApp.sharedResourceQueue", DISPATCH_QUEUE_SERIAL);
    }
    return self;
}

- (void)dealloc {
    dispatch_release(self.sharedResourceQueue);
}

- (void)accessSharedResourceSynchronously {
    dispatch_sync(self.sharedResourceQueue, ^{
        // safely access my shared resource and block the calling thread
        self.sharedCounter++;
    });
}

- (void)accessSharedResourceAsynchronously {
    dispatch_async(self.sharedResourceQueue, ^{
        // safely access my shared resource but don't block the calling thread
        self.sharedCounter++;
    });
}

In the above example I’m creating a serial dispatch queue and managing access to the shared resource by using dispatch_sync() and dispatch_async(). Because the serial dispatch queue guarantees that any blocks executed on it will happen in order, I can ensure that the shared resource is not accessed simultaneously (as long as I don’t abuse this elsewhere in my class).

Why is this better than using @synchronized or NSLock? Because both of those require a kernel interrupt, which is going to cause a context switch and reduce your app performance. Dispatch queues are handled entirely in-process and don’t have the overhead of a kernel interrupt. You get the behavior of a lock without a performance hit.

Of course, you still need to watch out for deadlocks, but that’s a pitfall with managing access to any shared resource with concurrency.

There is even more great advice on using dispatch queues in this follow-up article, including a great pattern for multiple readers and a single writer.  My example is a trivial one, but using dispatch_barrier_async() will greatly improve performance by waiting to write until all the reads are finished.