Back in February of this year I developed a small Twitter app for iPhone called Chirpie. Frankly, being a n00b in this area it was a little taxing, and that’s just the development I’m talking about. What I was even less prepared for was the App Store approval process, so I thought I’d give some tips to developers hoping for a successful submission.
Device Support
My first failure at App Store approval was because of device support. I had built in functionality that enabled the user to take a photo with the camera, or select a photo from their library and attach to a tweet. It gave users the option to choose the source from a menu. Great times.
What I hadn’t thought about, and should have realised throughout, was that an iPod Touch doesn’t have a camera, yet they’re given the same software and same camera option in my app. This is made clear in the iPhone Human Interface Guidelines – Go over it with a fine tooth comb!
Write code that validates the device/availability of hardware to support your software!
Don’t Assume Reviewer knowledge of 3rd party products
So this was an interesting one. Like I said before, I was giving the option to attach photos, the device grabs an image, compresses it and then uploads it to a third party service like Twitpic.
As a regular Twitter iPhone app user I realised that I had to wait x amount of time for that to take place before I submitted the tweet, in order to let the upload finish and to get back a Twitpic URL. That assumption was clearly wrong. My app was again rejected because the reviewer didn’t wait, and classed that as a critical bug and against the sales description as the image wasn’t attached, assuming it was attached instantly.
Another rejection also came during a 1.x release, so after the app was in the store. The reviewer didn’t have Facebook or Twitter credentials to use the application with, therefore the app update was rejected.
So, do make sure any 3rd party integration credentials are supplied, and try not to assume any kind of user behaviour! (This should be a given, but as a regular iPhone user, you may become dull to certain aspects).
Email Apple to complain your app is taking too long
This was an interesting one. I could see my app was taking longer than other people’s new submissions, and it bugged me that Chirpie was going nowhere. So I emailed Apple to find out why. They replied within an hour, and the app went into review within a couple more.
The app was rejected ultimately for one of the issues above, but it worked!
Don’t email Apple to complain your app is taking too long
The flipside to emailing Apple is that it usually does nothing for your cause. During my prolonged initial 1.0 submission (and after my initial chaser email that seemed to speed up Apple), I again email them as my app appeared to be stuck in limbo land again. This time Apple were less helpful and told me to wait like the rest, and that some apps take longer to go through than others.
Point taken, I never emailed them again.
New apps take longer than Existing App updates to approve
Something you will quickly learn is that .x releases of your application will take a very short time, usually 24 hours turn around. For new apps it’s longer, how long is down to the size and complexity of your application.
What would infuriate me is that I knew for certain that a developer had submitted his twitter app the exact same time as me (Feathers), had very similar functionality, and was approved within 2-3 days, vs mine which was stuck in limbo for 5 days until I got a response from Apple.
Which leads me to my next point…
Existing “Trusted” Developers appear to be fast-tracked
Feathers developer @Aral had previously developed applications that were live in the store. I can only summise that this fact gave him a kind of “trusted developer” status, which meant that his application could go through first submission a little easier than my noobie one.
I have no idea if this is true, but it’s the only way I can understand why Feathers was approved really quickly for a 1.0 release, and mine was stuck.
Memory Leaks don’t matter
This was an unknown to me, I had assumed that my submissions should be 100% memory leak free. In actual fact, this isn’t true. Whilst it should be best practice for any developer to ensure they have no memory leaks in their code, you can happily submit your app (and get it approved) with memory leaks.
Conclusion
I hope this brief summary helps some developers with their submissions. Some of the mistakes above are easy to make – and shouldn’t happen for seasoned pros, but sometimes you have to make them to realise.
Feel free to add any of your own learnings to the App Store submission process in the comments section. I don’t think this is against my NDA… we’ll soon see!
