Developing a app store app
Be careful with v1 so it will work with v2

Whitepaper: Developing a app store app

Most users can ignore this document. It provides information that will be of interest to some.

Be careful with v1 so it will work with v2

To deliver the app you need to go through Apple and Google's review process. For apps that work on local data, this is usually not a big deal. But for apps that rely on data stored on a server, for APIs on a server, this can be a nightmare to work, and doing it wrong can cause your users to be broken for months.

So this discussion is for an enterprise application, it does not apply nearly as much to the 99% of apps on the app stores.

You have to submit your upgrades to both providers. Each of them is different, and they look for different things, and what they are looking for can vary from release to release, so 'past success is not a guarantee of future performance.'

You have to update of your server to offer the new features, so it has to be live on a system you are hosting before either of them review.

They may each, for different reasons, fail you so only one gets upgraded.

  • This means Apple may put your upgrade on live months before Google or
  • Google may put your upgrade on live months before Apple.
  • Months can become a year if it takes you that long to meet their 'new' requirements.

Once approved it takes typically several days (regions can be different) to be downloadable.

  • Once ONE of them releases, if you didn't design it correct, you MUST upgrade your servers.
  • But what happens to the one that you didn't upgrade? Simple: You need both the client app AND the server app to be backwards compatible with the other.
  • But not just one … Apple and Google both do rolling upgrades, so they may be released in one part of the world today, and it make take days before everywhere in the world is upgraded, so you cannot rely on "Apple should use this server, Android should use this other one until everything is upgraded".

So again the answer is "simple" you HAVE to make sure both your server and your client are backwards compatible. Your server code has to work with the old client apps as well as new, and your clients have to work with old server APIs as well as new.

And this same answer will continue to apply to the following issues. So at least there are no additional problems, just additional cases that you need to realize will exacerbate the problem frequently for months or even longer.

Once it is on the app store, it can take a week or two for a device that HAS the auto-upgrade set to grab it and upgrade it. You can verify this by being aware of upgrades of your favorite, going to the app store and 'forcing' it to upgrade, whereupon you can see that, even though you had auto-upgrade on – unlike MCe, it did NOT auto-upgrade for days or up to a couple weeks.

Corporate enterprise polities are often NOT auto-upgrade. We have some customers (JPL) that require devices to be physically shipped in for every upgrade and their IT often refuses.

If you don't think and design backwards compatibility into both your client and your server, you can cause MONTHS of data corruption and grief for your users. You may have several 'old' versions running. This requires a LOT of thought that most companies don't do. We spend probably 15% of our dev time EVERY upgrade dealing with this – we have for 18 years had to deal with customers running client software that is YEARS old against a new sever version. You won't know about this until they do it wrong.

If you wait until version 2 to think about this – you've got ANOTHER problem… you will potentially FOREVER have some version 1.00 users, and you will FOREVER have to design and test. So instead, you should, from version 1.00 be thinking about this and designing it in so that you can make an end of life call that tells version 1.00 (and any other older version) to in a non-data corrupting way – stop working after it has saved all it's changes.

If you have MULTIPLE servers, your client software has to be aware that on every call, you may be changing which version of the server you are talking to. In the same way that the server needs to be aware that different users may be different versions and may be dealing with data in 2+ versions.

If you have a bug ever … you need to understand that conceptually, there is only ONE app store (well, regions may be 'out of date' but you can't pick your region), so a client could have an upgrade of client, but accessing the old sever APIs until all the servers are updated. If you get it wrong for one version – you can't roll back the client device. You can roll back the server, if it won't cause data corruption from what has been received by a client (and you probably didn't test for this case), but the app stores will not permit users to install any version other than the one that they, in that region, have marked as the shipping version.

This is simply something very few companies have experience dealing with. So to avoid causing huge problems for your users, you must think and design and code for this starting with version 1.00 of your product.

We have the 'advantage' that we've had to deal with this with our software AND we have Accruent making changes so that we have to work with a wide range of MC's. We understand how hard this is – and actively have been dealing with it for nearly 2 decades. We spend about 15% of our dev effort on this – all the time. It is part of our life and has been since the early 2000's.

If you are PURCHASING software that is important to you from a company – make sure THEY understand this thoroughly and you are comfortable that they have done this.