Force mandatory update to latest version

[vancewong]

Hey all, tried finding the forums for a similar question or answer but can’t find any.

I’m thinking how to force a mandatory update on users before they can continue.

ie. When I push a new build and it’s available to update on the respective app stores, users must update their apps before they can continue using the app.

There’s a similar topic here but it’s only workable if I’ve already implemented this on the current build that users are already using

Other than notifying them via email or a push notification, which they can ignore… Are there any other workarounds?

Thank you in advance

[vancewong]

Bumping this up

[Victor]

Hi @vancewong,

As I know, it’s not possible to force users to update the app (at least in the Apple App Store). So if update check is not built-in in your app… then there is not much things left to do in your case

Best regards, Victor.

[vancewong]

Hey Victor, thanks for your help. I’ll just have to implement it right now before pushing the next update for future purposes.

Is there a way for the Google Play Store?

Thanks!

[Victor]

Hi @vancewong,

I’m not very familiar with Play Store, but some search shows that the policy is pretty much the same. User has full control over his/her apps, so developer can’t really force the update.

You’ve raised a good question though. It’s not very obvious at the beginning that app developer needs to plan the update policy in advance, from the very first steps.
The logic as I see it could be the following: on Welcome and Home screens, the first action is to check the app version & requirement for update, and if update is required, then redirect user to the “Update the app” page.
The open question for me would be where to store the actual & desired version. Actual version could be stored in hardcoded format, for example, somewhere in the hidden input as a default value (developer will need to maintain this manually).
But where the actual version should be stored (if there is no external resource, like some website)?..

Best regards, Victor.

[vancewong]

Thanks for your help!

For the logic, I’m thinking there’ll be two versions of the home screen (probably don’t need welcome since new users would most likely download the latest version anyway).

There will be a database with two records and a custom boolean field “latest version?”. The first record will be set to “true” and tagged to the first version, while the second record will be set to “false” and tagged to the second version.

The first version would have a condition that checks if the boolean is false, redirect the user to the update page with a link made by https://www.onelink.to/, so it handles the checking of the user’s phone OS.

The second version would be the back-up screen for when a new update is pushed. This will be a duplicate of the first version, except it wouldn’t be labelled “home screen” until the new update is ready to be pushed.

I imagine the workflow would then be:

• Work on the updates of the app without touching the database (it’s ok to make changes to screens and hardcoded stuff since it won’t reflect on the live app
• Once the latest version is ready, change the home screen to be the second version
• Change the first version with that boolean to be a normal screen
• Make sure all connections to the home screen is now to the second version (SUPER important)
• Do checks on the PWA version of the app
• Switch the boolean of the first record to “false” so it sends users to the update page
• Switch the boolean of the second record to “true” so when users update, they won’t be redirected to the update page again for nothing

I think to keep track of the versioning and making sure that no one runs on older versions, we might have to keep old home screens and create new records in the version database.

Would be good to have an official documentation of how to handle app versioning (not on the backend, but for users).

P.S. If anyone has a better way to do this, please share. I typed it all out in a way that makes logical sense to me, but I might be jumping one too many hoops to achieve something simple.

Thanks in advance!

[Victor]

Hi @vancewong,

As for me, your approach should work; but for it you need your users to be logged in.
What I was wondering about: how do you determine which app version is it for non-logged-in users?..

Best,
Victor

[montetennis]

Hello, do you suggest a final approach for checking if an update is available when the user is logged-in?

[c.hris]

Here’s another solution I have that also relates to what @vancewong mentioned.

I solved this issue by adding a new collection to my Adalo app named, “Latest App Version.” Every time I submit a new version either to the App Store and/or Google Play Store, I input one similar build version in a number field in the collection.

Here’s a more detailed example:

Here’s the collection with a single number property named Latest App Version. It’s up to you, the developer, to add your app’s latest build version. Even if your TestFlight and Android build has different versions, find a similarity, as it is not currently possible for your app/Adalo to differentiate different OS and check for two different versions.

When a user logs in, you can have the default screen that a user sees when they log in/open the app have an action to update the user’s current version. Essentially, make sure you have a new number property in you user collection called “Current App Version.” You’ll need to manually change this version number before publishing a new build for your app. Don’t forget!

Now that you have the structure. Let’s move forward with how you can have a prompt pop up whenever a user’s current version does not match the latest version you have set. On my main home screen for my app, users can receive either a non-intrusive or intrusive banner that lets them know they need to update their app. It’s set to only appear if a user’s current app version is LESS THAN the MAXIMUM latest app version. So that way, you don’t have to delete the last build version you put in the Latest App Version collection before putting a new version. Just make sure you don’t put new build version that is less than the last one you entered.

Alright, let’s recap.

You’ve created the following from the start:

1. A new Latest App Version collection, where you’ll input one single new version for both TestFlight and Android builds.
2. A new number property for your Users collection named “Current App Version.”
3. Your default home screen has an action that will update a logged in user’s Current App Version number property with something that you’ve manually inputted (usually the same latest app version # that you’ve put in the Latest App Version collection.
4. A new screen, modal pop-up, or banner that appears when a user’s current app version is less than the maximum latest app version.

5. You make sure to change the maximum latest app version when your TestFlight build is Ready For Sale on the App Store and/or your Android build has reached public production, so that users will know that it is time to update. Doing this beforehand will prompt users to update and they wouldn’t be able to do so if your new app version isn’t available to publicly download, obviously.

Practice makes perfect with this as sometimes you might forget to change your home screen’s current app version update action before publishing a new build. If you are need in more assistance with this, let me know. I’m happy to help! This might seem like a lot, but I promise it’s not that bad at all.

[montetennis]

It’s funny how 2 different coders in different part of the world, came up with the same solution.

I had this trick for a while, even if I don’t like it very much in the long term.

But sure, that works!