Submitting An App To The Apple App Store

Why does it take so much time and effort to get a mobile App submitted to the Apple App Store?

Apple has a submit and review process that rivals getting accepted to do quantum mechanics at university. They force developers to produce good Apps whether they like it or not. If it isn’t good enough then it will get rejected. This might be good news for users but it isn’t so good for developers.

Submitting an Android App is child’s play in comparison

I developed a mobile app and submitted it to the Android Play site about three months ago. It’s an Adobe AIR based app written entirely in ActionScript 3 which makes it a cross platform app that can easily be ported to the Apple iOS system for use on iPhones and iPads. I thought that this would enable me to submit the same app to the Apple App Store very soon after it was established in the Android Market but I was completely unprepared for the additional work I would have to do before I could submit to Apple.

Three months after submitting to the Android Play site I am only now at the point where I feel confident in submitting to the App Store. So why has it taken so long to get the Apple version ready? Well that’s the purpose of this post. Read on to find out where all my time has gone.

First steps in preparing an App for the App Store

The first thing to do was to get a test version of my app running on an iPhone. Packaging the Air app for iOS is fairly straightforward using the Adobe Air sdk tools but I did have a problem trying to use the latest versions. I could not get it to build successfully and I finally reverted to version 1.6 because it works and I didn’t have the time to work out why later versions do not. I shall revisit this problem once the App is in the App Store.

Now you might think that once you have built and packaged your app for iPhone you should be able to transfer it to your iPhone and start testing it. This is indeed exactly what you would do with an Android App but not when it’s an Apple device I am afraid to say.

99 dollars just to run your own App on the iPhone that you own 

Before you can run your App on the iPhone that you paid good money for you have to get yourself an account at the Apple Development Portal which will cost you $99 for a one year subscription. Why do you need this? Well there are a few requirements that your App has to fulfill before it will run un an iPhone and you can only fulfill these requirements through the development Portal.

The first thing you need to get from the developer portal is a Developer certificate. This can only be obtained through the portal and you use it to build your App binary package. The purpose of the certificate is to authenticate your App and without it it will not work when you put it on your device.

The next thing you need from the portal is a provisioning file which is tied to the device that you run it on. Yes this means that you have to build as many binary packages as there are devices you want to test it on. This can be a real problem if you have many testers because every time you make an update you have to build a new binary package for each tester one at a time. The appropriate provisioning file also needs to be loaded onto the test device before the App can be loaded and run.

Yippee it runs on my iPhone! A long way from submitting to the App Store

So you have your developer certificate and a mobile provisioning file for your App. You have loaded your provisioning file onto your test device and built a binary package that you have loaded and installed onto your iPhone or iPad via iTunes. You start the App on the device and it works. Great you want to upload it to the App Store immediately so that everyone can use it. Well no, not yet. You still have a lot to do before you can do that.

When I got to this point I set about testing it to make sure it worked the same as the Android version. It’s an Air App so it should work exactly the same right. Well it should and it mostly does but there are some differences that need to be identified and corrected for all platforms you are targeting. I found that some events do not behave in exactly the same way, especially around start up. There are also some important differences with events from Web View windows so it’s important to check it out thoroughly.

I was testing the App on an iPhone 3gs because it’s the only Apple device that I personally own. This is ok but you really do need to test it on more than one device and with more than one tester. I have a developer friend with an iPhone4 so I asked him to do some testing for me. His name is Huw Nichols

Always get someone else to test your software

Huw found some bugs for me very quickly. It’s funny how you can test your own code until you are blue in the face and still miss bugs. Luckily I am used to this and make a point of writing maintainable code that is easy to fix. This enables me to correct bugs quickly so the only real problem is discovering them in the first place. I’m always happy when someone finds a bug for me because I know that once I’ve fixed it then it’s one less bug in the App.

Conforming to Apple guidlines

Then a more pressing set of issues started to emerge. I had begun to study the Apple developers guidelines and I realized that my App didn’t conform to several of the requirements. While it was perfectly acceptable in the Android world there were some points that I felt might get it rejected by the Apple review team. There is no review process for Android Apps so there is no risk of it being rejected for non conformance to any guidelines.

Now it can take several weeks to get an App reviewed by Apple so I didn’t want it to get rejected if I can help it. It took me a lot more time to mould my App into Apple form than it ever did to fix the bugs we found. If you are developing an App for iOS then I would strongly suggest that you read the guidelines before you start to avoid lengthy delays at the end.

Well I am nearly ready to submit to the App Store. I have collected together most of the things that I will need. Icons, keywords and descriptions are just a few of the things required. I am now writing a set of review notes for the review team. They need enough description to enable them to test everything including any test accounts and other things that they will need.

Don’t leave unfinished features in your App

It was during writing the review notes that I discovered another issue that could get the App rejected. I had built in a messaging system which I had planned to activate from the server post launch. I realized that Apple might see this as an unfinished feature which is something that they will reject Apps for. After much soul searching I decided to implement the bare minimum which was to send the App a welcome message on installation. This took a couple of days to put in but I think it was worth it.

I’m hoping to submit the App to the App Store very soon so watch out for my next update.