Observation: iOS Programming Is Hard

I’ve been up to my ears in iPhone and iPad programming lately. It’s been a few years since I’ve jumped to a new platform, a new language, and a new framework all at once. Of course, scads of developers and coders and students have been doing the same thing in the last two years.

• Cocoa Touch, the framework, is remarkably nice and surprisingly easy to learn.
• There are lots of books to help you get started. Most aspire to be more accessible to beginners than the Apple documentation.
• Apple’s documentation remains the best resource for people who know what they’re doing – people with an adequate computer science background. If you’re old enough to remember Petzold, this will come as a surprise.
• Apple’s documentation is too elementary. It tends to avoid useful terms that everyone learns in elementary CS courses. Not everyone, admittedly – I never managed to take any courses. But there aren’t that many old autodidacts like me around the business anymore, and even I can manage to read “call by reference” without bursting into tears.
• iOS does a remarkable job of hiding its constraints. It’s not easy to know, for example, how much memory you have, or how much you can ask for. You’re encouraged to allocate objects with abandon. It feels like it’s running on a big machine, and the processor does not feel slow.
• I expected to want FORTH (or something like it), the language best suited to doing difficult tasks in constrained environments. I don’t.
• Between the pattern-aware framework and tricky memory management, iOS programming has got to be really hard for untrained programmers. I suspect a lot of programs out there simply leak memory left and right and hope for the best. I have no idea how non-technical folk go about hiring iOS programmers; it must be ugly.
• Many aspects of Objective-C seem awkward, and they are rendered more unpleasant for want of a defense. Why is there no overloading of methods? Why don’t braces create a new variable scope? Are @private methods useful now that we have @interface foo(), or are they just a leftover? It would be nice to read a rationale, and to know what the authors were (and are) thinking.
• I'm often tempted to bridge to something from STL or BOOST . Are the Core Foundation containers adequate substitutes? When is the unsighliness of the bridge class worth undertaking?
• What, really, are the drawbacks of Objective C++, anyway?

The iTunes App Store makes lots of money and it's a big success. But an awful lot of those apps we see are tiny fripperies with fancy graphics glued on. Long term, that’s a danger to the platform.