Hello folks,
this is not necessarily an ionic specific question, but I hope, someone also had to deal with this issue or has some good best practice for solving it.
I have built a mobile app for Android and iOS (ionic 1.3 app). Now I’m asking myself what’s a good practice for managing version conflicts between client (app) and server.
If I change certain api methods on the server side, of course I have to change the client accordingly. But since users of mobile os aren’t necessarily forced to update to the latest version, they likely use outdated versions of the app (at least temporarily).
I can think of 2 options to solve that problem:
Force app users to update if a new version of the app and the backend is available. This is very low effort for me as developer and a little disadvantage for the user in my opinion.
Do a versioning for the server backend (the api) so that every version of the app can access the appropriate version of the api. This is high effort for me.
How do you handle this issue? Am I getting something wrong? Is there a bad practice?
Thanks in advance.
Bye
You can certainly try, but be sure that some users will find a way around that. So you really have to disable the app for them, otherwise they just keep using it.
Please also note that you will need way to check if a new version is available and execute this at every app start and probably also from time to time while the app is running - an app can run for a very long time. You could/should probably abuse the normale API calls for that, adding an header like X-Required-Version: 1.2.3 that is added to every response and then compared to the app version.
If you want the app to be working for users all the time, this is the only way. Some users can’t update the app for whatever reason (they are abroud with a 50$/100mb data plan…) and so will be barred from using your app.
Then the “easiest” solution would be to differentiate in every function that is changed after go live (which is breaking the reverse compatibility) which version is used and then deliver the appropriate code.
Ahh, website development had been way easier…
1 Like
To put this all into context: Breaking changes in APIs are usually not that common. But it totally makes sense to have a mechanism in place to handle them if the appear.
It’s not really an API, it’s rather a general backend holding the user info and offering methods for the business logic. If a new feature is done, I need to change the backend. Same if a method changes it’s behavior.
But I think I can do a compromise between usability and effort if I try to keep changes at a minimum. New features shouldn’t be a problem anyway.
1 Like