This time last year I was winding down my work on several Grails plugins and contracting for customers to help them with their Grails application development.

At that time I had decided to start spending all my spare moments making an iPhone app of my own to sell in the app store. Those of you with young families will appreciate how scarce this category of time is. However I felt and still do feel incredibly drawn to the kind of application design that can only be realised on this platform. It feels more like forging actual gadgets people will use than web development which feels like jumping through endless hoops to achieve relatively mundane forms-based applications, or massively compromised and awkward UIs on mobile devices.

I had been reasonably deep in Cocoa Touch, iOS APIs and Objective-C] since the first iPhone SDK was released as I greatly admire the platform and the design ethos as well as the possibilities afforded by modern mobile devices. I had so far failed to find a way to translate this into income.

I had done a couple of years as a mobile Java developer previously, back when the entire game literally had to fit into a 64KB JAR file (sometimes less) and you had 128KB of RAM maximum if you were very lucky. That was fun, but the limitations of the devices and platform were so extreme that made it rather dull. On some phones you were lucky to get a few sprites moving at more than 5 frames per second.

However, I have been able to monetise my iOS skills over the last few months as I have been working on a prototype iPad app for the BBC, which I am sadly contractually prevented from talking about at this time. It has been a pretty cool project to be involved with, and it has been a great learning experience on many fronts.

The migration to Cocoa development has been somewhat of a renaissance of my distant “C” past – as while coding for iOS you inevitably end up dipping into C.

I have actually really enjoyed going back to such low-level coding again. I’ve even re-awoken my assembly language brain, not used since my teenage years, in order to help debug thorny crashes in static libraries for which we have no source code.

There’s a debate being led by the likes of John Siracusa that Apple cannot stick with Objective-C for much longer and that we need to be working in much higher level languages, but I am not so sure. Having been at the higher level with Groovy, Java, Javascript for years I still can’t see a time for several years when it will be satisfactory to write mobile apps like this if you care about quality.

Caring about quality in mobile means performance; both responsiveness to user interactions and battery life. This is why Apple has all those amazingly designed C APIs like Grand Central Dispatch. This is why Objective-C is a good enough mix of dynamic vs. static language. Being able to trivially drop in C where needed is unbelievably powerful. C++ is a total horror that I plan never to revisit, but that can also be used very easily and this coupled with C is no doubt a huge part of the success of iOS for gaming.

Of course it isn’t all rosy. There are downsides like the hornets’ nest of compiler and linker options, but it is getting more and more tolerable (for me at least) as Apple make refinements and enhancements to the Objective-C language, Xcode and the build tools. If you didn’t know, Apple basically own Objective-C and this happened by osmosis when they acquired Next. This gives them total control which is the Apple way after all.

People complain about the verbosity of Objective-C and all the square brackets but really… you end up with very little code in your apps, it is astonishing. The code you do have is pretty easy to understand because if you follow the idioms. The long names help you read the code: Objective-C might be considered an adult font of verbiage vs. the almost monosyllabic teenager of a modern dynamic language such as Ruby or Groovy.

Ultimately however, the language is less important than the idioms and the APIs. The design of Apple’s APIs is often very impressive and deceptively simple. The patterns used are few but powerful. Once you absorb these mentally, you can get things done incredibly quickly. It has taken me years to feel at home here.

If you are starting an iOS project, what you should find is that the major time suck is actually the UX design process and the touch interactions and animations. Getting these designed and implemented right is by far the hardest part of a high quality app. Finding designers able to think about natural animations and effects is hard enough. Finding coders that understand why 60FPS UI is important and how to achieve that is even harder.

We should be thankful for the way this pans out however, as it shows that the language and frameworks are doing the heavy lifting. The design – how it works – is exactly what we should be spending most of our time on. And it is really hard.

Anyway I’ll be back working on my own iPhone app in a week or so as the BBC project is nearly done. If your team needs some help on an iOS project let me know.