8

We are building a suite of native mobile applications to supplement our existing application that currently only supports a web interface to the server. The application can be installed and hosted by clients on their own infrastructure or hosted by ourselves for clients who want to make use of it. Big enterprise customers typically chose to self-host whilst smaller customers choose our hosting option.

We need to support multiple versions of the application. Not all customers want to upgrade at the same time. With the web interface, supporting multiple versions are not difficult as the web interface automatically uses the server version associated with its server installation. With mobile applications where you typically only have a single app available in the App Stores, the support for different levels of the Server API and functionality in the mobile app becomes a challenge. I'm interested to know how other people are solving the issue. To my mind you have options like:

  1. Support multiple versions of the app in the app store.
  2. Build support into the mobile applications to automatically determine the API version of the server it is talking to and route calls to the relevant server API endpoints. Also introduce use some kind of feature toggle mechanism to enable/disable functionality in the mobile application based on what's available in the different server versions.
  3. Do not use the app store for deploying your app. Points users to a version specific URL they can use to download and install the app.

Option 1 - IMO will create confusion for the users of the app. There also isn't a nice migration path from one version of the app to the next as it really is two separate applications.

Option 2 - on the other hand can quickly become very complex if you take into account that your UI visuals now basically need to adapt to whatever functionality is available in the version of the server API it is talking to. It also needs to support the different versions of the server API calls it need to make.

Option 3 - is possible in the Android world when doing side-loading of your app, but as far as I know not supported in iOS and I'm not sure what the picture will be for Windows 10 mobile apps going forward.

What other approaches are there to tackling the issue? Please don't debate the fact that we are writing native apps. That's not what I'm asking. I'm looking for guidance on how other people are tackling the issue of supporting multiple versions of the same native mobile app talking to different versions of a server API.

  • 1
    Option 3 is doable in the Windows Phone world too, so long as they're connected to the corporate infrastructure you can specify which apps they use. – James Snell Aug 28 '15 at 21:03
2

Look at what will happen...

Option 1 will generate support calls when users install the wrong version. There will always be one user who either can't read or pick the latest version thinking they know better... and you'll have a large number of versions to potentially backport fixes to should you need to.

Option 2 adds some complexity to the UI code, how much depends on how well the UI is written to be adaptive. But it has the best user experience.

Option 3 can't happen on iOS (Android and Windows will allow it in certain configurations) which means different behaviours for different platforms. That makes things inconsistent which is a recipe for trouble.

So out of those, making a responsive UI and targeting the right endpoint is by far the best way to go for your users.

1

I've dealt with this in a slightly different context, but what we came up with was that if you used our public server we required you to upgrade. If you self hosted, we allowed you to stay on whatever version you liked.

I know that isn't the most customer friendly answer, and it might not be an option depending on your situation, but it was the stance we ended up taking.

One thing to note: we ended up having to do a lot of one-offs based on old baselines that were being self-hosted when we found security issues or significant bugs. If you support multiple versions, whether the way we did or if you end up supporting multiple APIs fully, you need to make sure that you have rock solid configuration management and source control. As you find bugs, make sure to take the time to source them back to were they originated because you might have to fix it on a old branch.

  • 1
    What do you do about staggering a release? If you only want to deploy the back end to a couple of customers first to try it out, how do you do this without telling all your customers to delay client upgrade? – Melbourne Developer Mar 6 at 21:56
0

API versioning is fine but this would require more some work at the UI Layer a) The UI needs to know which version of the API to invoke depending upon the configuration ( use a properties file or a resource file on the client device)

b) Also the server needs to have support for multiple versions of the API's.

Does the server API only cater to Mobile clients or does it have other clients as well . If it caters to other clients then for the Mobile only you might want to get a wrapper API that basically calls server API at one end with versioning support.

Basically versioning is tough at the server API if there are the other clients like public API's that are served by the server API otherwise it is simple .

My 2 cents .

  • The server API caters for multiple clients, not only mobile clients. With wrapper API, are you referring to something like the API Gateway Pattern – Carel Aug 24 '15 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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