This is not a tutorial. This is me talking to myself. Much of what I say about iPhone development will be wrong.
It has become a truism that the platform library, not the programming language, has become the large barrier to learning. As a guy with a background in “everything but the Mac” (well, I learned Smalltalk on a Mac FX – does that count? And I had a NeXT pizzabox, but I never did any serious development on it), the barrier to iPhone development involves:
- Objective C
- XCode
- Cocoa
- iPhone Licensing / Provisioning Hurdles
My initial expectation was that Objective C was going to be the big problem. Objective C was a fascinating hybrid language back in the late 80s which combines approaches from C and Smalltalk – every C program is a valid Objective C program. (I really doubt that every valid Smalltalk program is also valid, but given Smalltalk’s famously compact grammar, who knows?)
Objective C was a success both in its time as an important part of the dialog about shifting towards object-orientation and, to this day, as the main programming language for the second-most-popular OS. But, let’s face it, it’s kind of an odd bird in today’s ecosystem. The combination of pointers and explicit memory management with Smalltalk-style messages and syntax is guaranteed to cause some mental context thrashing (I was looking at a simple piece of code yesterday and caught myself in a loop: “Right-associative? Left-associative? Right-associative? Left-Associative?…”). Heck, Brad Cox doesn’t much code in Objective C anymore!
But after a short time with my books (Cocoa(R) Programming for Mac(R) OS X (3rd Edition) by Hillegass, The iPhone Developer's Cookbook: Building Applications with the iPhone SDK (Developer's Library) by Sadun, and Step into Xcode: Mac OS X Development by Anderson), it became clear that not only did I have to add a new challenge to my list:
- Interface Builder
But that the real challenge would be understanding Cocoa and its design idioms.
APIs, Frameworks, and Opinions
At the lower-levels of an Operating System API, you can typically solve a problem in any number of ways: you have a potful of function calls and a whole bunch of resources that can be combined in whatever way you desire. You want to use a technique for inter-process communication that was obsolete a decade ago and is kept for legacy purposes? Go for it! You want to store the results of a calculation by encoding them in filenames? Awesome!
At the other extreme, frameworks such as Ruby on Rails boast of being “opinionated.” How do you structure your source code? Like this. Do you use unit-testing? Damn right: that goes over here. Storage structure, naming conventions, etc. – there’s a good argument to be made that “convention over configuration” saves a lot of time.
One of the big advantages of a baked-in “opinion” is that one can write tools based on the opinion. While it’s possible to write, say, a screen painter that works with any kind of layout management, generally speaking, tools can generate better code when there are fewer options.
Cocoa is less opinionated than Ruby on Rails but more than, say, .NET. More accurately, it appears to me that XCode and Interface Builder are quite opinionated, and if you forego the convention, you’re likely to lose out on some very powerful tooling (particularly in Interface Builder).