One of the things I am asked most about by non-iPhone developers is the Apple review process. While I am pretty happy about it, it has gotten a few undeserved hits by other developers. It has also gotten a few deserved ones. I thought I would share some of my experiences.

About 7 days
When I submitted the first app, iPushFit, to Apple I was worried about being rejected. Would they not approve of the user-interface? Did something not work as intended? They accepted it around the 1st of October after approximately 7 days review-time. It was smooth as butter!

The second app I submitted was the Halloween Pumpkinizer. A small simple app that took only a few days of work. That application was accepted within 24 hours (if I remember correctly). I guess that it was because it was just a few days before Halloween and Apple gave it some special attention. So again, smooth as butter and even dead fast.

After that the review periods increased. The next app was iPushFit Lite. A lite version of my jigsaw-like puzzle game. It took about 7 days again, but for the first time I experienced a rejection; According to Apple it crashed on the very first screen. I had used a preprocesser macro LITEVERSION and I had a lot of code of the form #ifdef LITEVERSION ... #endif. In the release and debug builds of iPushFit Lite I had included that preprocessor macro and so all my tests work flawlessly. However, I had forgotten to add it in the distribution build, so the version Apple received was a mix of full-version code and lite-version resources. Of course it crashed. It took me about an hour to understand what was going on though, but I am happy that Apple tested the application, because otherwise I would have had a lot of angry customers. It would have been cool though, if I could have tested the distribution build before submitting the app, but it is code signed differently.

A revision of iPushFit Lite was submitted and again rejected after about 3 days. In iPushFit I included a TableViewController with a list of all the jigsaw puzzles you can play. In the lite version I had included the same list, but those puzzles that were only available in the full version would lead to a "Buy the full version"-screen. This is not allowed because according to apple it can confuse the user, despite the fact that "only available in full version" was written below each entry. It was a bit annoying, but not a big thing. I would have preferred that I could somehow advertise for all those extra jigsaws that you get in the full version more clearly, but Apple is looking after its customers. I fixed this, and after a few more days of review the app was finally accepted.

As I remember the subsequent apps, Turkeynizer, XmasizeMe, and NotifyMe all went through smoothly. I think there was a crash in one of the updates and Apple's test team caught it.

Before Christmas I started getting a bit overconfident about the whole review process. After all, it seemed like Apple just made a few tests here and there.

Private APIs

Before Christmass I read a blog post by Erica Sadun via Darring Fireball. Back then there was a lot of discussion about using undocumented APIs.

Erica makes a distinction between private and public undocumented APIs, and calls the private APIs "Sauron of App Store". It is not really clear to me why linking to a private framework is worse than using undocumented APIs in public ones. After all, both can break at updates. The only reason I can think of is that you are not violating the contract you have with Apple.

NotifyMe (Soon to be called Voice Alarm) is my own little speaking clock/alarm/timer. When the idea for NotifyMe was first pitched to me, one of the important elements was that the iPod music playback should be paused during speech. I searched and searched and searched and couldn't find any public API to start/stop the iPod.

Eventually, NotifyMe was submitted without the feature. I had to gain all the sound, so that you could hear it while your iPod music was playing. That greatly degraded audio quality and I got some angry reviews because of it.

When it was time to make an update I decided to dig into the undocumented APIs again. It is relatively simple to find the different API calls of the different frameworks, but I am not going to disclose the procedure here out of fear of what Apple might do. After all, I am generally quite satisfied with the agreements I have with Apple, and I don't want to step on their toes.

I discovered that among the private frameworks there is in fact a set of procedures that can be used to pause, start, and stop the iPod playback. A bit of hacking and testing and I had everything up and running nicely after a couple of hours.

Now, I no longer had to gain the audio, and the whole feeling of the app was much better. I actually only started this as an experiment to see if it was possible. I was thinking that it would either work, in which case I would have more happy customers, or Apple would discover that NotifyMe was using private APIs and reject it. Either way, I didn't really have much to lose. Well, Apple went ahead and accepted the application, and in a way that was the worst thing that could happen.

After a couple of weeks I discovered a few bugs and one of my friends suggested a whole list of changes. So I started brewing an update. Now, the application with its usage of undocumented APIs had already slipped through Apple's review process, so I guessed that it would do it again. It didn't. The second time they rejected it for its usage of undocumented private APIs and they were very specific about the framework I had used, so I am guessing that Apple is actually screening the apps more thoroughly now.

I haven't used undocumented APIs in any of the other applications, and I regret having done it in NotifyMe now, because in a way this put me in a gigantic dilemma. I wanted to submit the update, but I couldn't do it without reverting to the old horrible sound system. However, the APIs I am looking for are coming in 3.0.

So what should I do, submit an update with horrible sound now, or wait 3 months and submit the intended update for version 3.0 of the iPhone software? After more than 1 month of consideration and working on other projects, I decided to revert the sound system and resubmit. The reason was that when people start updating to 3.0 everything should still work. I know that this will disappoint a lot of customers, but hopefully it will make me sleep better at night.

So let this be a warning to anyone else who thinks that they can slip under Apple's private frameworks radar. You might actually put yourself in an ugly dilemma, so don't do it!

Network connection

Recently I have had trouble again with rejections. Lifecards got rejected because a feature on the feature-list wasn't obvious to get to, so I added a help message. Eyestorm Lite got rejected the first time because I had copy-pasted the feature list from the full version which included "Local and global highscores". I had decided to remove "global highscores" since it didn't make much sense in the lite version, but Apple read the description and rejected the app because the feature was missing. It was OK to reject the submission, but a little annoying that we had to wait another 7 days just because I had overlooked something in the description. In Apple's defense; there was no way of knowing whether the description was wrong or the feature was missing from the app.

Yesterday we got two applications rejected because they didn't " adhere to the iPhone Human Interface Guidelines". This is what Apple writes when they find something they don't like. Both applications can access the Internet, but neither actually tested to see if the internet connection was available before doing it. We knew about this, but had decided that it probably didn't really pose a big problem to users, as it should be a little bit obvious that you need an Internet connection when you wish to export to Facebook or you want to synchronize high-scores.

In both cases Apple was right. There should really be a message.

The app store police?
Generally, I have been happy with Apple's rejection system. Almost all the rejections we've had were because we could have improved one thing or another, or because something went plain wrong. I really think that the that it is a wonderful thing that they check apps before they start to sell them. It improves the quality of the applications and the whole user experience on the platform. Sometimes it can be annoying as a developer because each reject costs another 7 days of wait, but on the other hand 7 days is really not a long wait.

I know that some developers get their apps rejected because they fall right in the middle of interests; Like that famous wifi-tethering app. It is a problem for the platform, and it would be great if Apple stated clearly what can be rejected. Unfortunately, it can be hard for them to predict all the possible uses of their phone.

It feels like Apple is also becoming increasingly pedantic about features and an annoying new thing for us developers is that all applications are now being tested against iPhone firmware 3.0 beta 5 before being accepted. I guess I finally have to download that SDK and start testing with it.

Considering that Apple receives around 200 app-submissions per days, I am amazed how well they are doing. The longest wait I've had was around 10 days!