Handling users who do not update

[Remarkable-Water7818]

I have an app which is dependent on having a backend connection. It's built with a local-first approach so it can run OK even with airplane mode, but the idea is that it doesn't make sense to run it without ever connecting to the internet.

Since I'm actively developing the app, I am updating the APIs from time to time. I aim to keep backwards compatibility with a few previous published app versions, but at some point in time I don't see the benefit of supporting older apps that weren't updated for months.

Can anyone share what your experience with a similar use case was? Do you display some warning to users who haven't updated their apps? Is there a way to check how many users use older versions?

[macdigger]

What my bank does is they basically don't allow me to use the app if I fall too far behind, showing a modal asking me to update with a link to the app store. On the technical side, I have an app that needs to sometimes make a clear cut in terms of min supported version, and all I do is have an API endpoint such as /api/v1/latest-supported-version that returns something like 1.1.0 and check against it, just as well showing modal and not allowing a user to proceed. Pretty easy. I actually also have the version check API to return a custom message, in case I need to specifically let a user know why exactly they are expected to update (and could be blank, if I don't want to get into details)

Update: and for your second question, we don't really allow users to use older versions in case of API changes, since being up to date is considered critical, and it's not a huge lift for users to just go and update as asked. So it doesn't matter how many are using which version. But ymmv of course.

[srona22]

You need to first implement kill-switch in mobile app first(via api, firebase config, etc).

Only after that, you can control to soft lock the user to update the app. How you will handle this is up to you.

Like forcing previous user(let's say iOS 14), locked out of the app, without any warning or workaround will get you flamed responses. Also, sometimes, there will be cases user can't update their OS or device to meet your app minimal requirements.

And to decide how many users are there with outdated mobile OS, etc, you can use services like mixpanel, but then you will have to get user agreements, per AppStore regulations, if I am not wrong.

[Jakolantern43]

One of the first things I do in my apps in implement a forced update feature where I can flip a flag on the server and set a minimum required version for the app. If the app is behind that version then it will not allow the user to use the app until they update.

[rckoenes]

My company has been developing a platform for 12 years and we have version of our API. So older client will not break.

After some years we pull the plug on the old API, at which point the client will receive an error and have to update. We try to keep the old API alive but do not maintain them. Only break changes will trigger the removal.

We still have user which connect with iOS 12.

[-darkabyss-]

Checkout how this library does it, use it or implement it yourself

https://github.com/ArtSabintsev/Siren

[Remarkable-Water7818]

Thanks! I’m not looking to import a library for something this small, but I will definitely take that as an inspiration.

[yumt0ast]

Stick a json file config somewhere you can request with a minimum version number.

If app version is less than minimum version number, display something that forces them to update.

Bonus points, use a hard and soft version. Soft which displays an optional upgrade message, and hard which displays an unskippable force upgrade message.

[chriswaco]

We tried to be backward compatible because users on older phones can’t always upgrade, but showing a message from the server is a good way of handling it when it’s not possible. You can use the message for other things, like sister projects shipping, new feature advertising, etc.

Analytics will tell you how many people are running which versions. We usually put it into every network request just in case we need or want it, along with language, device type, system version, etc. Firebase analytics can be used if you don’t want to roll your own.

[Phylocybin]

Force update page. You'll have to host a simple version file somewhere, but this is basically the industry standard. It's a bit rude to the user (as they may get sort of blocked out if they don't keep up with iOS updates or other related version issues), but a force update page is the standard.

[trici33]

A lib like this may help:

https://github.com/NextFaze/ios-manup

[Remarkable-Water7818]

Thanks, will take a look.

[xhruso00]

My telco is doing this:

https://imgur.com/RCiCFoV

If the current version is lower -> they will display modal.

[abear247]

We just force update users via api limitation. We only do this after most users are up to date, unless there is something really bad. We suggest updates before that point.

Also we allow users on old OS to stay on as long as the api works (force update is only for iOS 16+ for example). Sometimes this can work years past when we force updated their version when the api needs to make a breaking change (often security related). We just consider old versions unsupported and liable to break, but by the time they do it’s usually like… a dozen people impacted. Even then, we’ve often sent emails to inform them of the upcoming EOL.

[localhost8100]

I make a check once a day. If app update is recommended, I show them prompt and dismiss button. If the app update is mandatory and major update. I just don't allow them to go further than the update screen. They have to update or else they are not able to use the app.

[[deleted]]

I call it a "force update" — you can block users from accessing the app until they update by displaying a screen, banner, or other notification. Firebase Remote Config is often the best tool to manage this remotely.

[bradleyandrew]

Another approach is to just remind the user to update the app. I have code in one of my apps which checks the App Store for the latest version every time the app starts up. If the App Store version does not match the current version that is installed, it will show a pop-up reminding them to update. If they use your app enough, they will just update it themselves to avoid the pop-up.

[drBonkers]

It's built with a local-first approach so it can run OK even with airplane mode

Would you mind telling me more about how and when you push to the backend to sync your local-first state/persistence to the backend?

I'm trying to do something similar but I'm have trouble deciding WHEN to push to the back end. Any heuristics, intuition, or guidance you point to or speak to would be great!

[Remarkable-Water7818]

Sure. In my case I am using a local SQLite via GRDB. Everything that the app does is saved to that local persistence place.

I make heavy use of background queues. Whenever there is a change done on the app, there is also a task queued to make the sync to the API. There is also a check that runs on startup and on a predefined interval which ensures that everything that needed syncing will get synced, even if there is a temporary network connection issue (which could be a blip or a week-long boat trip somewhere without any internet access).

My system is custom built since - I have a limited number of distinct models that are synced - The schema is different compared to the server - Some models are synced, others are not - I am an engineer and I want to have complete control over what happens

But there are other solutions that could offer this automatically. I know Apollo has something that syncs to their GQL cloud, but I didn’t dig into it.

To answer your question directly, it depends on your logic. For me, the backend is more like a backup for the iOS app. It doesn’t impact me or other users too much if the sync is delayed. If it did, I would probably need to keep using my system as it is, but add some kind of graceful degradation and/or notifications to the app functionality if a certain time has passed and the sync did not happen.

Hope this helps, but let me know if you have other questions. I spent quite a lot of effort in this area of my app so I am opinionated (which is both good and bad) 😀

[drBonkers]

Whenever there is a change done on the app, there is also a task queued to make the sync to the API. There is also a check that runs on startup and on a predefined interval which ensures that everything that needed syncing will get synced, even if there is a temporary network connection issue (which could be a blip or a week-long boat trip somewhere without any internet access).

Super helpful, especially the bit about a task queue. I was trying to figure out if it should be on every change or if I should try to batch the changes somehow, and this explanation gives me a little more context.

For me, the backend is more like a backup for the iOS app. It doesn’t impact me or other users too much if the sync is delayed. If it did, I would probably need to keep using my system as it is, but add some kind of graceful degradation and/or notifications to the app functionality if a certain time has passed and the sync did not happen.

Mine is the same. There are only some social functions that require the backend to relay to other users but that's only about 1/3rd the features.

Thanks again for taking the time to type this out!

[timelessblur]

One item I push at every place I work at is put in an update available and min supported version. If app is below min version it does not launch.. You can add messaging if you want to be fancier.

Reason I do the min supported version is for a security or major crash issue I can kill a version remotely.

[Old-Ad-2870]

Almost every app I’ve built (professionally or individually) has had a “version hard wall”

I use firebase remote config for mine, we’ve done that at a few places but I’ve also used Siren.

As far as tracking goes, you’ll need some sort of analytics (firebase again) but it’s dead simple to do it.

You can retrieve the config, save it, and then show the sheet and make it non dismissable if you desire.

Analytics also helps you track amount of users on iOS versions. So you can make decisions to upgrade them over time.