I spent this year’s Christmas holiday trying to learn how to write iPhone applications. I have to say, I now know why developers rave so much about Apple’s software platform despite the fact that its development tools are severely limited compared to, say, Microsoft’s.
First of all, Objective-C is, realistically, an easy language to grasp and learn, if you discount the lack of closures (without which, in my opinion, event-driven development is about as much fun as drinking turpentine) and the mind-boggling, reference-based memory management scheme. Perhaps it’s the stupidity that comes with programming in C for so long, but I spent about 25% of my time chasing down memory leaks caused by forgetting to release a reference, or autorelease a pool, or pool an autoreference, or something like that.
Nonetheless, at the end of it all, Obj-C is just a language, and the language a platform does not make. The fun of developing for the iPhone OS is in learning how Cocoa works, then rejoicing at the fact that so many complex tasks are already taken care of (and in an efficient way), then getting mad because there is almost always one thing that you want to do and can’t be done because the functionality you need, although present, belongs to a private API whose usage will cause immediate rejection from the App Store.
Maybe it was the fact that I actually had some spare time for a chance, but I actually managed to go from no knowledge of either Objective-C or Cocoa to a completed and submitted application in about four days and around 22 hours of work—all of it on evenings and weekends. The application does nothing special, but it still handles a database, graphical transitions, HTML rendering and REST service consumption, which means that writing applications of a certain complexity is relatively simple.
I don’t mind telling you that my application was rejected twice—both times because of bugs. I don’t mind telling you—why should I? Four days before I submitted the application, I had only installed XCode so that I could compile PHP—because it means two things: first, the app vetting process is more than just a way for Apple to keep competition out of the hands of iPhone users. Personally, I feel that they’ve been rather clear on what they allow and don’t, and it’s not that difficult to figure out ahead of time whether your application will sail through (assuming, of course, that you’re not stupid enough to leave bugs in it) or be blocked because it skirts dangerously close to or outright violates the ToS.
The other reason why I don’t mind telling you that I was rejected is that I was rejected professionally. Both rejection notices came with clear explanations on what I had done wrong, a description of the steps required to reproduce the bug and either a core dump or screenshots of the errors. Moreover, the vetting team promptly replied to all the inquiries I sent, once again displaying a reasonable amount of professionalism.
And so, while I await for my two apps (I managed to squeeze another in before the end of the holidays) to be rejected a third time finally approved, it’s time to move my concerns from how to write the software to how to make money from it. It doesn’t seem to be impossible, but it’s certainly unrealistic to expect that Apple will do the marketing work for me.