Power Apps mobile

What it does

The native player that runs canvas and model-driven apps on iOS, Android and Windows. Users sign in with their Entra ID credentials and see every app they've been given access to in one list, rather than following a URL per app.

Key facts

Available on iOS, Android and Windows. The Windows client is a separate product, Power Apps for Windows, and it's the only one where canvas apps must still use the legacy Dataverse connector.
Version support tracks the OS vendors: latest iOS recommended with the previous version as the minimum, and the previous three Android versions as the minimum. When a new major OS version ships you get 60 days to move off the oldest supported version.
Model-driven apps only appear in the list if the user holds a predefined security role in that environment. If the role comes via a Dataverse owner team the app stays invisible — it has to be a Microsoft Entra ID group team.
Only production model-driven apps show by default. Non-production apps need the Show non-production apps toggle in Settings.
Device permissions and data-source consent are prompted on first run of each app, not at install.
Available in the Azure global cloud plus GCC, GCC High, DoD and the China sovereign cloud, with a region picker on the sign-in screen.
Apps can be pinned to the device home screen. On iOS 14 and later this goes through Siri Shortcuts rather than a Safari web clip.

When to use / skip

This is the default answer for anyone running a Power Apps app on a phone. Use it unless you have a specific reason not to — the main reasons being that you need store presence, custom branding, or sign-in for people outside the tenant, all of which push you towards wrap. Running a model-driven app in a phone browser isn't supported, so for model-driven work on a phone there is no alternative. Canvas apps will technically run in a mobile browser, but you lose offline entirely and most device capabilities with it, so don't design for that unless you've decided it's a browser app.

Configuration decisions

Whether users get the stock Power Apps mobile app or a wrapped branded build, which changes the whole distribution and support conversation.
How security roles are assigned for model-driven apps — Entra group teams rather than owner teams, because that decides whether the app appears at all.
Whether non-production apps should be visible to a pilot group, and who tells them to flip that toggle.
Whether app discovery is left to search or actively managed with favourites, home-screen shortcuts and a short app list.
Which physical devices form the supported estate, given the rolling 60-day OS floor.

Gotchas

The security-role-via-owner-team trap catches almost everyone once. The app is deployed, the role is assigned, the user sees nothing, and there's no error to explain why.
Search only looks at the apps on the screen you're currently on, not across the whole tenant. Users conclude the app hasn't been shared with them.
A shared app doesn't appear on Home until the user has opened it once. First-time users have to find it through search, which is a poor first impression on rollout day.
If the device is behind a VPN, localhost has to be excluded from tunnelling or the player won't start reliably.

Consultant notes

Rolling OS floors mean the supported device list is a moving target. Put it in the support model rather than a one-off statement in the design document, or you'll own the problem when a fleet of old Androids drops off.
Budget for a device-permissions conversation with the client's security function early. The first-run consent prompt for camera and location is the thing that generates the helpdesk tickets on day one.
Rehearse app discovery in UAT with a user who isn't the maker. The gap between "the app is shared" and "the user can find it" is where mobile rollouts lose their first week.

Worth a look after each major iOS or Android release, since the minimum supported versions shift with them.