Wrap and app distribution

What it does

Wrap packages one or more canvas apps into a native iOS or Android app shell with your own icon, splash screen and colours. You get an IPA, APK or AAB out of the wizard, sign it, and distribute it through Apple Business Manager, Google Play or Intune like any other line-of-business mobile app.

Key facts

Canvas apps only. Model-driven apps can't be wrapped, and every app in a wrap project must come from the same environment.
The apps must be in a solution before they can be wrapped.
Minimum platforms are iOS 14.0 and Android 8.0 (API level 26). Device floor is iPhone 6S / iPad 5th generation on the Apple side.
One app is the primary — the entry point — and the rest are secondary. Navigation between them uses Launch(), and you can only land on another app's home screen, not a specific screen.
Published changes to the underlying canvas apps flow through to already-installed wrapped builds automatically. You don't rebuild the package for a content change.
The build needs a Microsoft Entra app registration, an Azure subscription for Key Vault and Blob Storage, and either automatic code signing through Key Vault or manual signing with Xcode / Android Studio.
APKs distributed through Google Play are capped at 100 MB. Building an AAB instead raises that to 150 MB.
Users still need a Power Apps licence to run a wrapped app.
Wrapped apps support offline. Push notifications aren't supported, and neither are sovereign cloud environments.
There's no visible sign-out button — users press and hold the app entry to sign out, which you have to tell them.

When to use / skip

Wrap earns its keep in exactly two situations: you need the app to appear in a store under the client's brand, and you need frontline or guest users who won't happily install a Microsoft-branded container. It also helps adoption in a real, measurable way — people find "Contoso Field" in the store, they don't find "Power Apps". Everywhere else, use the standard Power Apps mobile app and save yourself an Azure subscription, a code-signing certificate and a store review cycle. If the client is on a sovereign cloud, the decision is made for you.

Configuration decisions

Which canvas app is primary, since that's the landing experience and can't be swapped without a rebuild.
Bundle ID, which has to be unique across the organisation and is baked into the Key Vault tags — get it wrong and you're recreating the vault.
Automatic code signing through Azure Key Vault versus manual signing on a Mac or a Windows box with Android Studio. Automatic is less painful but means handing certificates to Key Vault.
APK versus AAB for Android, which is really a decision about whether your app will exceed 100 MB now or later.
Distribution channel: Apple Business Manager and Google Play for store presence, or Intune for a managed estate. These carry different enrolment expectations for the user.
Who owns certificate renewal, because expired signing certificates break new installs and nobody notices until they do.

Gotchas

The wrap wizard doesn't work over a VPN. That's a documented limitation and it wastes an afternoon the first time it happens.
All branding images have to be PNG. Anything else fails the build with an unhelpful message.
The Android hardware back button doesn't reliably match the app's own back navigation. Users end up somewhere unexpected.
Offline-enabled wrapped apps only show image thumbnails, never the full image view. If your workflow is photo capture and review, test that before you commit.
Bundle ID conflicts and Key Vault permission problems are the two most common build failures, and both surface late in the wizard.

Consultant notes

Wrap is a mobile release process, not a Power Apps feature. Price it with store review time, certificate procurement and an MDM conversation, and put it on the critical path early — Apple's review queue doesn't care about your go-live date.
The guest-access angle is the strongest business case. If the client has contractors or frontline staff outside the tenant, the wrapped APK is the route that lets them sign in, and that's worth leading with.
Tell the client up front that there's no sign-out button. It reads as a defect in UAT every single time, and a line in the user guide costs nothing.
Content updates flowing through automatically is a genuine selling point. Sell it as "we ship the app once and update the content weekly", because that's the bit that differentiates it from custom native development.

Worth revisiting if push notification support arrives, or if the sovereign cloud restriction lifts.