Power Apps mobile stuck on an old version? How to force an update

You publish a fix on Tuesday. On Thursday a supervisor sends you a photo of their tablet. It still shows the old inspection form, the one with the bug.

A maker I came across this week was living this every day. They support about 200 users, each with at least one phone or tablet. They had done the sensible thing. They built a force-update screen: a version number in App.Formulas, compared against a required version kept in a Dataverse table. If the device was behind, the app showed an update screen with a restart button.

Staff tapped the button. Some devices still came back on the old version.

The same app opened in a browser loaded the latest version every time. So the publish was fine. The problem was the phone. In the end, only two things worked for them. One was uninstalling and reinstalling Power Apps. The other was relaunching the app at the exact moment a new version was published. Some staff gave up and walked to a computer.

The update screen can’t update anything

A force-update screen runs inside the copy of the app the device already has. It can see that it is old. It cannot replace itself.

I think of it as a smoke detector. It tells you there is a fire, and something else has to put it out.

Microsoft’s own wording on publishing is short. Users see the new version the “next time they open or refresh the app.” On a phone, “open” is fuzzy. My guess, and Microsoft doesn’t confirm it, is that switching back to an app often resumes it rather than starting it fresh.

There is also a banner for this in browsers. When you publish, people with the app open see “You’re using an old version of this app. Refresh to use the latest version.” Microsoft lists where that banner appears: the web, an iframe, SharePoint forms, Teams, Power BI and the Power Apps web part. Power Apps mobile is not on that list. I couldn’t test a phone for this post, but I wouldn’t count on staff being told that a new version exists.

Microsoft doesn’t document how the mobile player decides when to fetch a new copy. I can’t tell you the rule, and I’d be wary of anyone who claims to. What I can tell you is how to catch a stale device, and what to do once you have.

Build the version check anyway

The check is still worth having. It turns “some people are on the old version” into a screen that shows the exact build each person is running. Here is the version I built in a test tenant.

1. Keep the required build in a table

Make a table called App Version with two columns: App Name (text) and Required Build (whole number). Add one row per app.

Click to zoomTap to zoom

Use a whole number for the build. As text, “1.10” sorts before “1.9”, and your check quietly breaks on the tenth release. A plain counter (7, 8, 9) can’t go wrong that way.

2. Put the build number in App.Formulas

Select App in the tree view. Pick Formulas from the property list and add three named formulas:

AppBuild = 8;
RequiredBuild = LookUp(
    'App Versions',
    'App Name' = "Field Inspections"
).'Required Build';
IsOutdated = AppBuild < RequiredBuild;

Click to zoomTap to zoom

AppBuild is the number baked into this copy of the app. You change it by hand every time you publish. RequiredBuild comes from the table. IsOutdated compares the two.

You need your own number because the Versions tab counts versions in a place your formulas can’t read. The App object does have a StudioVersion property. It reports the version of Power Apps Studio used to publish, which tells you nothing about which publish this is. My two test publishes, less than a minute apart, both showed the same Studio release.

3. Send stale devices to an update screen

Set App.StartScreen to:

If(IsOutdated, UpdateScreen, HomeScreen)

Microsoft says StartScreen is evaluated once when the app loads. It can read from a data source with LookUp, which is what makes this work. Microsoft’s docs say you can test it in Studio with Navigate to StartScreen, from the … menu next to App in the tree view.

On the update screen, tell people exactly what to do and show both numbers. When someone calls you, they can read the numbers out.

Click to zoomTap to zoom

The Close app button runs Exit(), which closes the app. Nothing in that formula clears the old copy or downloads a new one. If the player opens the same old copy next time, the user lands right back on this screen.

That matches what the maker saw. Their restart button worked as built, and closing the app was all it could ever do.

4. Release in the right order

1. Raise AppBuild by one.
2. Save and publish.
3. Only then raise Required Build in the table to match.

Do it the other way round and every device fails the check, including the ones that are up to date, because no copy with the new number exists yet.

You don’t have to raise Required Build on every release. Raise it only when the old build has to stop, like a bug that writes bad data.

Click to zoomTap to zoom

What actually gets a device onto the new version

Once the screen has caught a stale device, here is the order I would try things in. Start with the cheapest step.

1. Close Power Apps completely. Swipe it away in the phone’s app switcher, then open it again. Going back to the home screen leaves it running. It costs ten seconds, so try it first. Don’t expect much, though. For the maker, ordinary relaunches did not reliably bring the new version.
2. Use the browser while you wait. The maker’s browser test held up every time. The Web link on the app’s Details page opens the same app in a browser. Put it in your support notes. Staff can keep working while you sort out the phone.
3. Uninstall and reinstall Power Apps. For the maker, this was the fix that worked every time. It’s blunt, and it costs the user a sign-in. But it is the only step that guarantees no old copy is left on the device. That is why it keeps winning.

I’d skip the trick of relaunching at the moment you publish. It worked for the maker, but you can’t schedule 200 people to open an app in the same minute.

A checklist to confirm a device is current

Use this when someone reports old screens:

1. Ask them to read the build number on the home screen. (Show AppBuild there in small text. It costs one label.)
2. Compare it with Required Build in your table.
3. Check the Live version on the app’s Versions tab, so you know the publish went through.
4. If the device is behind, have them close Power Apps fully and reopen it. Ask for the number again.
5. Still behind? Send the browser link today, and book the reinstall.

What this does not fix

It doesn’t make the phone download anything. The check spots a stale copy. Getting the new one is still up to the player and the user.

It fails open when the lookup fails. Microsoft says that if StartScreen returns an error, the first screen in the tree view shows instead. In my build that is HomeScreen. So a phone with no signal skips the check and runs whatever it has. I think that is the right default: a field worker with no signal still needs to work. If you want the opposite, put the update screen first in the tree view and accept that offline users get blocked.

It only protects builds that include it. A device running a copy from before you added the check has no check to run. Your first release with the check is the floor.

It can change your licensing. When I checked the test app’s Details page, it said License designation: Premium. The Dataverse table did that. If your app was on standard connectors before, every user may now need a premium licence. Keep the version row in whatever data source the app already uses, such as a SharePoint list, and the check works the same.

The bottom line

Add a build number to App.Formulas, a required build to a table, and an update screen behind App.StartScreen. Treat that screen as a smoke detector. When it goes off, have staff close Power Apps fully, give them the browser link, and reinstall only if the number still won’t move.