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.


  • 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?

1 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.
  • So in short, are you recommending making two disparate versions compatible with each other? Feb 25, 2019 at 11:00
  • I mean as long as they're the same major version. Is that the point of semantic versioning? Feb 25, 2019 at 11:01
  • The main purpose of semantic versioning is to be aware of the possible effects that a version number change can have. The point isn't to maintain disparate compatible versions but to switch to a new version for example on the backend without having to fear incompatibility with older clients (as long as they work with a major version supported by the backend) Feb 25, 2019 at 11:43
  • Sorry but that's a bit vague. That's not really the problem that I'm tasked with dealing with. In this case a client will always be on the latest version, but the back end could be on any version. For example, the back end could be on 1.3.0. The client might be on 6.5.7. They have to work together. I don't understand how semantic versioning solves this problem. Feb 25, 2019 at 20:01
  • A classic case would be SQL Server manager. You can run SQL server manager 2016 against a 2005 database server. The client is backwards compatible with ant server. The only way I can think of that that would work is if every client version is deployed in the installer. Feb 25, 2019 at 20:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.