On iPhone Development
I work on a team at my company that, among many varying responsibilities, develops mobile applications that interface with our core on-demand web app. The idea being that a cellphone web browser is a less than optimal interface to our services and that a slimmed down, streamlined UI is a better approach. And what with the iPhone being the next big thing, it’s obviously next on our list of mobile platforms to develop for.
So. This is something of a departure for me, coming from a mostly C++/Java on Windows background, but this is also an opportunity to develop new skills and learn a platform that will be invaluable in the coming years. Here are my initial observations:
Xcode is just plain awful when you compare it with Visual Studio. It’s clearly a far more immature product and it shows, from the brain-dead window management philosophy to the debugging tools to the keyboard shortcuts. Don’t get me wrong; I’m not whining because it’s different. I use vi for half my day when I’m coding on my Linux VM and get by with minimal fuss. I’m whining because there are clearly established UI standards for IDEs and for editors that have been proven over the years and Xcode just ignores them, doesn’t implement them or takes a completely different and wrong direction.
Interface Builder is…OK. It’s a different UI design and layout mechanism than I’m used to, but once you grasp how the controls you’re laying out in a NIB/XIB interact with and are represented by the objects in your code, it’s pretty painless. I don’t like having to drop into another app every time I want to tweak my UI however.
The supporting platform libraries and API are likewise just OK. Cocoa Touch brings over almost everything you would want from regular Cocoa, with the notable exception of a few selectors (why doesn’t [NSDateFormatter initWithDateFormat] work?). However, I really, really wish they’d ported Core Data or a subset thereof. My data-driven app would be about half the size and would have been done weeks ago. I think I understand why Apple chose to exclude CD from the iPhone API—it’s a behemoth and performance might have been unacceptable. But I spend way too much time writing sqlite database glue and plumbing code and it’s a bit frustrating.
Objective-C is fun. I enjoy the dynamic nature of the language. I suspect I’ve made the inexperienced ObjC developer mistake of abusing categories, but I’ve put a few on NSString and NSDate and they’re just so useful I don’t see how you can’t get by without them. The release/retain memory management approach also takes a bit of adjustment but it’s not without it’s merits. I’m not sure if I wouldn’t rather trade a few CPU cycles for a garbage collector however—maybe I’m just lazy.
Given these criticisms, you might gather that I’m somewhat down on the platform, but my overall experience has been quite to the contrary. It’s been a pleasure, and part of the reason why is that it’s so easy to create a polished, professional UI that just looks like it belongs on my iPhone. This is due to the tools Apple gives you—the default controls, views and behavior you get out of the box put you on a straight path to a nice UI. You don’t get it for free; you have to constantly tweak and work at it, but compared to Windows Forms or MFC, it’s like night and day.
Let me say this more clearly: It doesn’t matter how pristine, well-architected and beautiful the code supporting an app is—if the UI isn’t intuitive for your users or is so obviously different from the rest of the platform and it’s standards that using your app becomes a jarring experience, you’ve failed. This is where the iPhone SDK shines and why I’ll be actively developing for it in the future.
