At some point you will likely want to update your app and release a brand new version. If you are happy with your current supplier/developer and have a good relationship with them then the best thing may be to continue using them for any updates too (presumably they are keen on keeping you as a customer as well!).
Even if updates are covered as part of your original agreement with them though, you may wish to put a new agreement in place for each new version so the requirements and expectations on each side are clear. To do this you can simply use the same Supplier Agreement template mentioned in Part Two of this guide but update the Project Description to reflect the new update requirements.
What to update?
There is no point updating your app for the sake of it or worse still pushing out an update that upsets your users by altering a core piece of functionality (and making it worse) or introducing a bug through lack of proper testing (I have seen many high-profile apps do this so don’t think you are immune!).
So how do you decide what to update and – if you’ve got a long list of potential improvements – how do you decide what to update first?
You may already have a list of extra features that you never got round to adding before launch but before you starting working through them you should do a little research first.
Firstly, if any stats/analytics tracking software was included in your app then your first stop should be here. Look through the stats and see if any trends stand out. Are people visiting one part of the app much more than you expected? Are many not getting past the homescreen or another particular point (suggesting a problem there)? Take some time to have a good look into this. Don’t only look for what’s not working though, look at what is working too. After all you don’t want to ‘break’ your app’s most popular feature with an update.
Next take a look at the user reviews your app has in the App Store (if you don’t already check regularly!). Remember if your app is released worldwide don’t just check your ‘home’ App Store, check the feedback from everywhere (you can use www.appergy.com to get user reviews from all App Stores in one place). What do people praise? What do they hate? Is there a way for you to fix some of the things they don’t like without it impacting on what’s good about your app?
If you have the chance to connect with some of your audience more directly then do that too. If you’ve got a blog with people regularly commenting on it, poll them for their thoughts. If you have a website ask people to email in their suggestions. If you have customers you see regularly ask them if they use your app (if not why not?) and what they do and don’t like about it.
Based on all these findings you can then prioritise the features you’d like to improve first. You will also be clear about the ‘killer’ features of your app you either won’t want to change or only change with care because of their popularity with your current audience.
Ultimately it’s down to you what the next priorities should be but they are much more likely to be better received by your users if you’ve done your research first.
How often to update?
…most likely depends on the type of update you are doing. If you have accidentally introduced a bug in a previous update, then you should aim correct the bug through an update as soon as possible (particularly if it is something major or something attracting a lot of comments in your user reviews!). If your aim is to introduce a few new features however then try to avoid hitting your users with too many changes all at once (particularly if you have a large, loyal audience using your app already).
How to update?
Again, the easiest way to handle this, is to let your supplier/developer manage this for you as they are building all the code (‘binaries’) for you. Remember though, when submitting a new build you also have the chance to update your:
- Keywords
- Category (Primary & Secondary)
if you want to. If that’s the case then let your developer know you want this to be part of your update too. Once approved you will also get 50 new promotional codes which you can use to share the app with colleagues, journalists or others you may be promoting the app to.
Even though you are doing an update rather than a whole new app, you should still follow the same testing procedure outlined in the Project chapter of this guide to avoid introducing any bugs (Apple will check too, but it is possibly they may miss something). Nothing looks worse on the App Store than seeing a popular app creator upset their loyal community of users with an ill thought-out or poorly tested app update (count the angry user
reviews!).
After your supplier submits the update, you will still receive the standard ‘In Review’ emails. However, this time you will also receive an extra one when the app is approved: Pending Developer Release.
All this means is that you can now replace the current ‘live’ version of the app on the App Store with your new version, if you wish. This ‘delay’ is a useful feature to have. For example, you may decide to hold off releasing the new version of the app to coincide with some marketing activities or – if you have a paid app – timing it with a new price promotion.
When you are ready to release it though, you can either ask your developer to push it live for you or if you’d like to do it yourself simply:
- Login to the iTunes Connect website with your Apple ID and password;
- Click ‘Manage Your Applications’;
- Click the appropriate app;
- And click the appropriate button and confirm.
The App Store prompting a user to update an app
The current version of your app on the App Store will then be replaced with the update within a few hours and anyone downloading it for the first time will only receive the updated version. Any current users of your app on the other hand will be prompted to update the app next time they access their in-device App Store.
Remember to renew your developer account!
Just one last but important thing to end this section on. I have seen one high profile (and profitable) app developer suffer this fate (and you definitely don’t want to repeat the same). A simple case of the app owner forgetting to renew the $99 a year Apple Developer fee (a year to the day after their initial registration) resulted in all their apps being removed from the App Store for several days, a lot of lost profit and many dissatisfied customers. Put a reminder in your calendar now, it’s better than the reminder you’ll get when all your apps come down!
