So we have this app going on zappmeet.com and it’s my first on iOS. Coming more from web/backend development world I’m used to continuous delivery, where I push my code through continuous integration and once it’s passes all the tests it can get easily and automatically delivered to production in a nice server-by-server manner. Usually no downtime involved, all done in minutes if not seconds. This gets me nice stream of new features, experiments and fixes flowing to end users.
Now, how do I do the same for apps that sit on our users’ phone. What if I want to do an API breaking change – how do I ensure my users always get the compatible version. How do I time my backend/android/ios releases?
Before we get to see if there is a resolution, let’s talk rules of the game
1. AppStore releases are all tied to a manual review from Apple employee. Apple will usually take 1-4 days to review and approve your new version.
2. What is more, Apple will actually want to use the app – log in to it and see how it works. They even want a demo account details from you (registration process doesn’t require the review?)
3. Google Play is much more lenient on the approach and once you submit the app it will go through the automatic review process. A bot will launch your app on variety of phones and click through random things looking for crashes and slow downs. This is usually quick and painless, you even get the performance report back.
4. Unfortunately once the Play publishes the app it takes up to 24 hours for the update to be available to every user, even if they explicitly go to Play app and try to update manually.
5. We have an AWS deployed cluster of Node.js services and we’re fine to deploy it with a few seconds downtime. We obviously could get better and devise a rolling update, but that wasn’t necessary at least for now.
6. Updates happen automatically on both systems and full adoption of a new version usually takes 3-4 days for Android. We’re yet to asses this for iOS.
7. Of course there are people who don’t like updates and have them turned off or on-demand.
Now if you look at this holistically you’re kind of screwed when it comes to deeper refactoring in API. You need to be prepared to face people who have never updated from 3-months old version as well as be prepared that even active users will take 3 days to update.
What you can do is to devise an in-app screen that will pop-up once your back-end decided the app is too old to work with. I think a nice place is to keep it either on your backend or other remote-config location (like firebase remote config). This helps, but just a tiny bit.
You can deal with the laggers and force them to update once the new version is out, but you can’t just roll out a breaking change and count on users to go and fetch updates instantly the same day. They might not have that for next 24 hours (play), or longer (appstore). And if apple testers go in and test your new app with old backend and it breaks they will not approve it.
Huh, so a backward compatibility, at least one version? Seems like it. Till now we’re keeping old and new APIs living in parallel for some time, before we end up cutting them and increasing the minimum required version property. Since you don’t really have a choice, best to build this into your delivery process and be prepared for multi version usage. The good thing is that you can usually stick to your good old continuous delivery in the backend of your application and keep the updates rolling frequently, just make sure your tests reflect the non-deprecated versions of your app as well.