# Power Apps mobile stuck on an old version: force an update

> Some phones keep running last week's Power Apps build after you publish a fix. A version check in App.Formulas spots them. The fixes, in order to try.

[Home](https://tenantcraft.ca/)  [Insights](https://tenantcraft.ca/insights)  Power Platform

Validate Oct 6, 2026  8 min read

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

You publish a fix, and some phones keep running last week's app. A version check in App.Formulas can catch a stale device, but it can't pull the new version down. Here is what does, and the order to try it in.

![Geri Crroj](https://tenantcraft.ca/images/byline-portrait.webp)

[Geri Crroj](https://tenantcraft.ca/about)

Microsoft 365 consultant, Niagara, Ontario

Tested in a live tenant, October 6, 2026

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 5-minute version

1.  **An update screen can’t update the app.** It runs inside the old copy, so it can spot that copy but not replace it.
2.  **Don’t count on the “new version” banner on phones.** Microsoft’s list of places that show it leaves out the Power Apps mobile app.
3.  **Still build the check.** Put a build number in **App.Formulas**, a required build in a table, and route stale copies to an update screen with **App.StartScreen**.
4.  **Publish first, then raise the required build.** Do it the other way and every device gets locked out.
5.  **To fix a stale phone:** close Power Apps fully and reopen it, use the browser link in the meantime, and reinstall only if the build number still won’t move.

## 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](https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/save-publish-app) 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.

![A Dataverse table called App Version in Power Apps, with one row: App Name is Field Inspections and Required Build is 8, with the Required Build value ringed in red.](https://tenantcraft.ca/images/pam-02-dataverse-required-build.png)

Tables > App Version

One row per app. Raise Required Build only after the new build is published.

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;
```

![Power Apps Studio with the App object selected and the property list set to Formulas, ringed in red. The formula bar shows AppBuild = 8, RequiredBuild as a LookUp on the App Versions table, and IsOutdated = AppBuild < RequiredBuild.](https://tenantcraft.ca/images/pam-01-app-formulas.png)

App > Formulas

Three named formulas. AppBuild is the only line you edit on each release.

`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](https://learn.microsoft.com/en-us/power-platform/power-fx/reference/object-app). 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.

![Power Apps Studio showing a screen named UpdateScreen. The phone canvas reads Update required, then a line telling the user to close Power Apps completely and open the app again, then the line You have build 8. The lowest build allowed is 9, ringed in red, and a Close app button.](https://tenantcraft.ca/images/pam-03-update-screen.png)

UpdateScreen

I raised Required Build to 9 to test the gate on a build 8 copy.

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.

![The Versions tab for the Field Inspections Demo app in Power Apps, listing Version 2 and Version 1 with their modified dates and Power Apps release 3.26093.10. Version 2 is marked Live, and the Live badge is ringed in red.](https://tenantcraft.ca/images/pam-04-versions-live.png)

Apps > Details > Versions

Live is what a fresh launch should load. Check it here before you raise Required Build.

## 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.

What I could and could not test

I couldn’t test the native mobile player for this post. The steps above come from Microsoft’s documentation, the maker’s results, and a test app I built and published. I’ve only written down what I could check.

## 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.

Rebuilding InfoPath forms as Power Apps for staff on phones? Add the build check to the first release, and the decision tree routes the rest of your forms.

InfoPath Forms Decision Tree

PDF · 7 pages

[Email me the PDF](https://tenantcraft.ca/resources/guides/infopath-forms-decision-tree)

## Tell me what is stuck. I will tell you what it takes.

Same consultant from the first email to the last cutover.

[Book a 20-min call](https://tenantcraft.ca/contact) [See published rates](https://tenantcraft.ca/pricing)

---

_Canonical HTML: https://tenantcraft.ca/insights/power-apps-mobile-old-version-force-update · Agent guide: https://tenantcraft.ca/llms.txt · Site map: https://tenantcraft.ca/sitemap-index.xml_