Posts tagged: apple iphone programming lunacy

Dark ages with rounded edges

By , October 5, 2009

Yes, the day I’ve been avoiding for so long has come and I’ve decided to look at Apple development environment in details. And what I found was not pretty – Xcode IDE and Objective-C. After years of basking in ignorance, assuming general forward movement of humanity, I stumbled across this artifact from the past that seems to be taking over the mobile world.

Objective-C is an interesting language and seemed like an interesting step from C towards more dynamic languages. However, the toolset (IDE, Frameworks, APIs) that surrounds it for the sake of Mac and iPhone development makes it look just as ugly as Visual C++ looked 10 years ago. Coming from Java, .NET and Ruby development environments, iPhone application development looks like a relic from the museum of natural history – curiosity that deserves to be on the shelf collecting dust.

The amount of tedium one has to go through to build a simple business application is just mind boggling. It feels like the people who develop and market this have been locked up in the reality distortion field for the last 10-15 years and have missed the advances happening everywhere. Every iPhone developer session I went to lead to conversations about inevitable memory leaks and corruption. Everything takes 3 times as long to develop as for any other platform. Don’t forget to restart XCode 20 times per day whenever you are not sure whether this is XCode bug or yours. I have seen this in the past – that’s what C++ projects were 10-15 years ago: lengthy, hard to write, very prone to crashes, horrors of shrink-wrap distribution model.

With this in mind a lot of things make sense: the draconian control policies of Apple store approval process, the obnoxiously lacking ability to multitask applications and the overall secrecy. What else can Apple do to separate perception of their reliability and simplicity from reality of the platform? Try having memory leaks in the background applications with only 128-256MB RAM total and essential phone operations under threat. Or explain why the long running program can’t be written by typical developers because they will have an obscure crash condition somewhere that cannot be dealt with. Their way was to try to take full control.

There are some positives that come out from this attitude. Forcing multi-week approval cycle for even the simplest application changes enforces a higher general quality of apps in the store. Developers hate it, but users might be better off in most cases. However, mistakes happen and inability to correct them quickly irritates both developers and users. Also the performance of the applications is generally better than those of their peers on competitor phones. The phones today are in many ways comparable to desktop computers 10 years ago – no one was running Java for intensive applications back then. The low level C-style code tends to be written with performance in mind more often than not. While Java can be as efficient in many cases, the typical developers are already not thinking about squeezing every possible efficiency and that is unforgiving on phone-like devices.

Apple performed remarkably well on a dated platform due to focus on mindshare of high paying customers. This is a testament to the power of their marketing machine and ability to execute. Reduce the choices to one thing that works for most. Pay attention to the polish, implement only few features but do them really well since most users aren’t too bright to use the extra stuff anyway. Their solution to the horrors inside was to paint bouncy icons with rounded edges on outside and control the gateway. Appearance is everything, welcome to the Dark Ages 2.0 …

For all you disbelievers – Apple stuff is incredibly easy: Think same!

Panorama Theme by Themocracy