If you’ve planned, polished, tested and pushed and now you’re ready to launch, then the good news is you are almost there. There is however one last bridge to cross: submitting to Apple.
If you’re ready, don’t wait
It can take Apple a week or more (though sometimes less) to approve your app, so once it’s ready and you’re confident there are no bugs or other things that might make Apple reject it then it’s time to submit. In fact, if that’s the case, I advise you to submit it now even if you may not be planning to ‘officially’ launch the app for a few weeks.
Why?
Firstly, should the worst happen and you are rejected for any reason then you’ve got some time to come back, correct things and submit a new build. If you’re worried about submitting early and the app going live (and people downloading it) before its official launch date that doesn’t have to be a concern either. You can either set a launch date for the app when you submit it (before which it won’t appear) or at any time after its approved you can simply login to the iTunes Connect website and ‘hide’ it from the App Store until its ready to go (instructions for this follow under ‘Housekeeping’ in this chapter).
Secondly, if you a relying on Apple only taking a week to approve be aware it could take longer. If there is a rush of submissions for a new device (iPad) or large event (eg. the soccer World Cup), that one week could quickly become two or more. Oh and the App review team don’t work weekends either, so don’t count on that! So, if it’s ready, submit it now and, as mentioned, you can always hide it from the App Store if you’re worried about it appearing early.
If you want to carry on working the app after submitting your first version, you can still do that too! The nice thing is you can have your first build waiting in the queue with Apple and start to work on your first ‘update’ straight away. Let me give you a more specific example.
Working the submission process into your project
Imagine a scenario where there is a less essential feature that you’re still keen to include in your app, but your planned release date is now only two weeks away. Although you really want to include this feature, you don’t want to risk delaying your launch because of it. However, it seems silly to sit around and do nothing for two weeks while waiting for your app to be approved, so what can you do?
Let’s say you have a version of the app (which we’ll call Build A) without this feature but tested, signed-off and ready to go. You decide to submit this ‘launch’ version of the app to Apple now (specifying the date it should not go live before, if you wish) giving them a full two weeks to approve it.
In the meantime you start working on the first update to the app which will include the feature that you want, (which we’ll call Build B). After four days you manage to finish Build B and get it tested and signed-off, but Apple still hasn’t reviewed Build A. What to do?
At this point you could, if you wanted to, immediately submit Build B to Apple. This would replace (effectively ‘overwrite’) Build A that is waiting to be reviewed, but it would also push you to back of the queue again (meaning another week or more wait is possible).
The better choice then is to wait for Apple to finish approving Build A (which should now be very close) so you decide to wait and, two days later Apple does exactly that, approving Build A (which you can immediately hide from the App Store if you didn’t set an advance launch date). You can now submit Build B of the app to Apple (updates are generally reviewed faster than new apps so you shouldn’t have to wait so long this time).
Now, if Build B then gets approved before your official launch date you will just launch with Build B anyway (no-one will ever have had the chance to download Build A as you chose to hide it). If some reason Build B gets rejected though, you still have the original, approved Build A ‘in the bank’ with Apple ensuring that whatever happens you have a good version of your app for your official launch.
This might seem like a lot of extra work (and of course you should always build in as much time as you feel you can for the approval process anyway), so why approach the submission in this way?
If your app has an unmovable, publicised launch date which you cannot miss but you’re also under pressure to make the first version as good as possible and use all the time you have, then you may want to use such an approach. By doing so you should be able to ‘guarantee’ a decent version in the App Store (which can remain hidden) in advance of your official launch date. While at the same time giving yourself the possibility of developing new features and making updates to the app right up until the moment of your project.
Are you registered?
Firstly make sure you are registered as an Apple Developer (you did that in Part One right?). Now, assuming you are registered, the very last thing you should do before you submit your app to Apple is pull together all the things you will need for your App Store listing. As discussed in Part Four, this is one of the most important ways you will market your app so it’s worth putting some thought into. If you have other stakeholders involved in the project you might want to get their input too. Let’s take a look.
