While looking through some old code, I found my first iOS projects that I did while I was a graduate student at the University of Hawaii at Manoa. The earliest of which goes back to November of 2008, which was 4 months or so after the App Store opened its doors (according to Wikipedia). Since then I had developed 3 apps (two ended up in the App Store), the last of which I worked on in 2010.
Whenever I spoke to others about my experience developing iOS apps, I would often complain about how difficult it was. The challenges of learning Objective C, managing memory, little to no support for unit testing, and dealing with threads in order to perform network requests were things early iOS developers needed to overcome. It was even more challenging if you were relatively new to programming (like I was) or hadn’t done much lower level programming. Not to say it was all bad. Knowing how it works under the hood is still valuable even today. That experience has even helped me out in interviews when asked about how I might do things at a lower level.
I knew I wasn’t alone, even as Objective C rose steadily in the TIOBE language ranks starting in mid-2009. John Siracusa of Ars Technica was skeptical in 2005 about Objective C’s future, and wrote a followup in 2010 calling for Apple to create a successor to Objective C that supports automatic memory management. ARC, fully released in 2011, made memory management in Objective C a lot easier, although it did little to appease Siracusa. Siracusa was but one voice among many developers clamoring for better tools and improvements to the runtime.
TIOBE Index from 2002 to 2013, courtesy Wikipedia and TIOBE.
Fast forward to today, where I just started developing iOS applications in earnest again. Apple has made several improvements, like the aforementioned ARC, object literals (no more having to type “[array objectAtIndex:0]”!), and better support for testing from XCode. It’s also easier to get your application on your device (the process on the old developer portal was pretty painful). We may never know if these changes were in response to developers clamoring for them, but they do make developing Cocoa applications easier. Yeah, there’s still the whole verbosity thing, but we can’t have everything, right?
But, the thing that dramatically changed in the past 4 years is the development of 3rd party tools that make development so much easier. The advent of frameworks like Xamarin and PhoneGap make app development easier by letting you develop for multiple platforms using programming languages you’re familiar with. However, the tool that dramatically changed how I approach iOS development now is CocoaPods, a dependency manager for Cocoa projects. If you’re familiar with Ruby on Rails, then you’ll notice that CocoaPods looks a lot like Bundler.
What CocoaPods brought to Cocoa development is that it makes installing third party packages so much easier. Previously, you’d have to download the package, add it to your project, and then muck with some settings to make sure it’s on your build path. CocoaPods streamlines this process dramatically. Installing a library like AFNetworking (the current go-to library for performing network requests) is as simple as adding it to your Podfile and doing a “pod install”. Having not followed Cocoa development closely these past 4 years, I imagine that CocoaPods was integral in creating the ecosystem we have today.
We know how open source projects live and die by community involvement. Projects like Node.js and Ruby on Rails thrive on the thousands and thousands of developers that contribute code, develop packages, and test out their ideas. It’s relatively rare to see a community develop around a walled garden like Apple and still innovate and contribute. Of course, Apple is still closed and that’s unlikely to change, but the community found a way to get in and make development for fellow developers much easier.