A developer's perspective on iPhone applications

I'm proud to announce that Cogi has joined the rest of the world and now has an iPhone application! We believe that we are uniquely suited to provide the best available recording application, for a variety of reasons. For more information on the app itself, check out its FAQ page. But convincing you of the merits of that app (of which I believe there are many), isn't the reason for this post. What I want to discuss in this post is the iPhone application development process.

To set the stage, let me note that I've worked on several applications, across many programming languages, with quite a few different development environments. However, after several weeks of development, I have come to the conclusion that iPhone development is quite possibly the worst environment for development of an application I have come across yet.

Okay, you're hooked now, right? What am I going to say that's bad about XCode, Interface Builder and Objective C? Well, let's set that aside for the moment and discuss what's good about the environment first:

1. XCode's refactoring tool may be the best I have ever seen -- just right click on a symbol, provide a name, click preview and apply. It even integrates with Subversion nicely, so I don't have to worry about renaming the files in Subversion first. The only thing that I haven't been able to get XCode to refactor properly was a category I applied to a built in class, which is understandable.
2. The provided iPhone simulator is great! It's a great way to build and test without an actual iPhone connected to your computer.
3. There is an amazing amount of detailed documentation. (If you can find it, more on that below.)
   

Unfortunately, that's about all I see in this environment that stands out from the crowd -- anything else is either merely par for the course, or much worse than everything else.

So, what's so bad about it? Here are the highlights:

1. Objective C. In order to build an application of any complexity, Apple has forced developers into learning and developing with Objective C. Now, I know there's a good deal of history there, but this is a language that has roots in the 60's, and it shows. There is so much cruft just to get a simple class in place that I cringe, and often want to avoid proper OO design, and avoid good testing practices, just because of the nasty overhead involved. The square bracket message passing syntax is a nightmare to type out and read, and difficult-at-best to indent properly for multi-line messages. Finally the ridiculously long names and function calls with arguments leave you with no choice but to have either strange linebreaks in your code or to have lines that are 200+ characters long.
2. XCode. I see things online all the time about how good XCode is, so maybe there's something wrong that we're doing here at Cogi, but we all hate XCode. In particular, it doesn't help you with navigating around many open files, and wants to impose it's idea of "groups" on top of your particular file system layout. You actually have to jump through hoops to create a hierarchy of folders that makes sense.
3. Interface Builder & UIFramework. Why can't you set anything on an object in Interface Builder that you can do programatically? Why aren't UITextField and UITextArea related objects?¹ This area in particular is particularly difficult to get to work at all until you've read all of the hundreds of pages of documentation that Apple has made available.²
4. No way to simulate phone calls. As far as we've been able to find, when running your code in the iPhone simulator, there is no way to simulate either incoming or outgoing phone calls. In the real world, applications have to deal with this -- with no way to test this in a simulator, this requires a full build, deploy, test, and place a phone call cycle, just to discover that your change may or may not work as you expected.

And this is all assuming you've already jumped through all the hoops Apple requires you to go through just to start developing on a phone. And that you have a pretty good understanding of the hundreds of pages of documentation required to "get" how Apple wants you to develop applications for the iPhone. And we're assuming you already have a Mac available to do the development (really, there's no good reason to force development in XCode on a Mac -- just put out an SDK that can be used from Windows already!).

So, all that said, where do we go from here? Well, at Cogi, we are continuing to develop an outstanding iPhone application that our customers will love -- us developers will just have to continue to suffer through some amount of pain and frustration along the way.



1. This issue is particularly frustrating. So much so, that I will likely be writing more about it in the coming weeks.
2. Apple could learn a lot from the Pythonism: "Simple is better than complex." (from the Zen of Python).