Deploying Multiple Versions in One App Package

Question

This is a question about Android, and iOS apps. The technology is Xamarin (C#) but this is not really important. The app will be deployed to the stores. The client app must be compatible with the back end up. As we know, a user can reject an upgrade at any time, so the client must try to work with the current version of the back end if possible. However, in my situation, the client could also be upgraded before the back end (long story and completely out of my control). So, the client version could be behind, or in front of the back end.

The only solution I can think of is to compile multiple versions of these things in every release:

• Database structure
• Business logic (rules)
• UI

This would mean that the client / back end would find the best fit version and work together as best they can. If no compatible versions are found, then the client would just throw up an error and ask the user to upgrade the app in the hope that this would fix the problem.

Constraints:

• A customer (an organisation) can delay a back-end upgrade for as long as they want
• A user cannot delay a front end upgrade (a deployment in to the app store)
• A user (a person with a phone who works for the organisation) can choose to not upgrade to the latest client version because App Store.

For example, customer x could be on version 1.3 of the back-end, but customer y may be on version 6.8, and the version of the app in the store may be on 7.5. However, user z may delay the upgrade and stay on version 4.7 for example.

The implication is that merely trying to keep versions somewhat compatible isn't going to solve the problem.

My question is: what is best practice for this scenario? What are some techniques that can be used to mitigate the bifurcation in the code? What successful strategies have worked in the past? Is this doomed for failure?

Answer 1

First, the option mentioned in the title is probably the worst. Don't do that :-)

Instead, concentrate on the reasons for changes in frontend, API and backend. Take a look at semantic versioning (https://semver.org).

Here's a list of some things to consider:

• for any change, start looking at the API to see whether you need a major or minor version step. Patch versions in the API should only be done to correct typos or clarify documentation, not to change functional aspects of the interface.
• patch and minor version increments in the backend can be done at any time, as they don't change the way the backend responds to existing API requests (except for fixing bugs.)
• patches in the frontend can be done at any time, they should only correct content representation issues and erroneous API usage.
• minor version increments in the frontend that might be ahead of the backend should include code in the client to cope with the older API offered by the backend. To support this, the backend must have an API call to find the supported versions. But in the general case you should avoid this situation.
• major version increments should be really rare, and need to be carefully planned.
• the backend should support the previous API version for a reasonable time (until you can expect all frontends to be updated.) In the extreme case, this can mean "forever."
• frontend software with the new API version should only be pushed to users when the backend servers are updated and tested.