[Question] In-app updates

[Dmytro Kulakov]

Hello, everyone! You are doing an impressive and unique open-source project! Much appreciated.

I couldn't find any channel to communicate on so I have a question about in-app updates.
Do you have any thoughts on synchronizing the app version with the iOS App Store and Google Play Store?
I'm aware that Google Play Store provides in-app updates, so we don't have to worry about it. However, for iOS (in you app for Android too, as I couldn't find this feature in your Android files), how do you manage killed \ outdated versions? How can we determine when a new version has been released by the app stores and users can download them? I know there is a link to fetch the current available version in iOS directly from the appstore, but is it reliable(in google play store there is an option to fetch html so it's not so effective)?
Essentially, I just want to understand the moment when to set killed \ outdated versions if it's done by the own backend and force users to update and if it's an effective way to handle app updates or better to handle fetching information directly from the store?
Is it good to force users update without being able to dismiss the screen on minor/patch updates?

I also don't get the difference between killedVersions and minimumRequiredVersion. Both of these returns a message with force update. What is the purpose of killedVersions if they have the same behaviour?

[Brian Beckerle]

Hey @kulak91 these are all good questions!

I'll try to address some of them, although some will be just my opinions:
Is it good to force users update without being able to dismiss the screen on minor/patch updates?

In my opinion no, this is not a great user experience will cause users to leave your application if you do it too aggressively, for me being able to run old versions of the application without being forced to update is a feature of App Stores even if it makes devs lives a little harder. For this reason we only force update users when we have to or the effort to support old versions becomes too great for the number of users we are supporting. So we would not fetch directly from store in our case to force users to always have the latest.

So here is an example of how we might do it:

1. Say we have a legacy api call that we want to remove from our backend, the last mobile version to use it was 6.5.4, after that we released an update with a newer api call, however removing this api call from the backend will crash the application for any users on 6.5.4 or below
2. We check our user analytics to see how many users still are using those versions of the app, if it is above a certain amount we may decide to wait a while until more users migrate, if it is below go to next step
3. We update the minimumRequiredVersion string to the one after 6.5.4, let's say 6.5.5. This will be read by the app from a server, you can use anything for this really, we have our own setup here: https://github.com/artsy/echo, FirebaseConfig I believe supports similar but you really just need to read a json file reliably from somewhere at app launch time.
4. When that is deployed the next time a user on 6.5.4 or lower opens the application the latest json file will be checked and compared against the running app version, since it is lower the whole application will be inaccessible with just a message and a button to update that will take you to the App Store.
5. Now that users can no longer run versions below 6.5.5 we can safely remove the api from the backend.

killedVersions and minimumRequiredVersion are very similar but killedVersions is a little more targeted. Setting a minimumRequiredVersion basically says that we will only support versions less than or equal to this minimum version so in our example 6.5.1, 5.3.18, 4.1.1 etc, would all no longer be supported. killedVersions allows us to target a specific version to force upgrade. So say we added 6.5.4 as a killedVersion instead of as a minimum version, this means if a user is running 6.5.4 they would receive a force update message, all other versions would not, including 6.5.1, 5.3.18, 4.1.1. They would all happily keep running. This can be useful if you accidentally release a very bad bug that only affects a specific version of the app.

Hope that helps, let me know if you have any more questions!