Status: Public Preview — behaviour may change.

What it does

Generates standalone iOS and Android apps — real React Native/Expo/TypeScript projects, not something running inside the Power Apps player. You install a mobile-app plugin into an AI coding agent, describe the app in plain English, approve a generated plan, and the plugin scaffolds the project, provisions the Dataverse tables and wires up the connectors. The output is a codebase you own and ship through the App Store, Google Play or MDM.

Key facts

• Three supported hosts for the plugin: GitHub Copilot CLI, VS Code with Copilot Chat, and Claude Code. The plugin comes from the microsoft/power-platform-skills marketplace.
• Stack is fixed: React Native, Expo, TypeScript. Identity is a Microsoft Entra app registration; data is Dataverse tables plus Power Platform connectors.
• Workstation prerequisites are real developer tooling — Node.js 24 LTS, npm 10+, Git 2.30+.
• The plugin pauses at four planning gates (data model, native capabilities, connectors, screens) and writes the approved plan to native-app-plan.md. That file is reused by later /edit-app runs, so the plan is the durable artefact, not a one-off prompt.
• Testing on device uses the separate Power Apps Developer app plus a dev-server QR code, with hot reload against the app/ directory.
• App registration is created through the Wrap surface in the maker portal (.../wraps#create-app-registration), or you reuse an existing Wrap client ID.
• /deploy publishes to whichever environment is recorded in power.config.json.
• Not supported in preview: push notifications, Power Automate flow integration, converting an existing canvas app to a native app, Apple CarPlay, and agent-created AI-first controls.

When to use / skip

Use it when the app genuinely needs to be native — deep hardware access (advanced camera control, Bluetooth/NFC, sensors), background tasks, widgets, near-real-time responsiveness, or a branded experience that has to match platform conventions exactly. Skip it for anything an ordinary canvas app can carry: you're trading a maker-owned artefact for a codebase with npm dependencies, store submissions and a release cycle. Microsoft is explicit that this isn't for MVP-scoped work, and they're right — it's a long-term investment in a platform, so if you're testing an idea, build a canvas app first.

Configuration decisions

• Which coding host the team standardises on, and whether your organisation's policies permit agent plugins at all — several of the documented failure modes are a blocked plugin.
• Whether the app reuses an existing Wrap app registration or gets its own, which drives who owns consent and conditional-access scoping.
• Which native capabilities go into the plan up front. They generate typed wrappers under src/native/; adding them later means another /add-native pass and a rebuild.
• Whether Dataverse tables are new or existing. The plugin will create them, which means someone with System Customizer is effectively letting an agent do schema work — decide if that's acceptable in your environment before you start.
• Distribution route: App Store/Play versus MDM sideloading. That decision sets your release cadence and who holds the developer accounts.

Gotchas

• Offline is the usual source of pain and the checklist is long: IsAvailableOffline and ChangeTrackingEnabled set, profile published, user assigned, table in scope, column in selectedColumns, relationship traversed, initial sync finished. Any one of those missing looks identical from the device — empty data.
• Device and workstation have to be on the same reachable network for the QR-code dev loop. On a corporate WLAN with client isolation that quietly doesn't work, and the symptom is an "invalid server URL", not a network error.
• Power Apps CLI and Azure CLI keep separate auth caches. Signing into one doesn't sign you into the other, which produces a very confusing wrong-tenant deploy.
• Some hosts namespace the slash commands, so /create-mobile-app becomes /mobile-app:create-mobile-app. Run /help before assuming the plugin is broken.
• Scaffolding time scales with Dataverse provisioning, and Dataverse metadata operations queue behind other platform activity. A build that took ten minutes in a quiet dev environment can take considerably longer mid-morning in a busy one.
• There's no migration path from canvas. If a client asks you to "convert" their existing app, that's a rewrite.

Consultant notes

• The scoping trap is treating this as another Power Apps flavour. It isn't — it produces a source repository that needs a git workflow, dependency upgrades, store accounts, signing certificates and someone who can read TypeScript. Price the app support model, not just the build, and confirm the client actually has or will hire that capability. Plenty won't, and a native app with nobody to maintain it is worse than a canvas app that's slightly clunky.
• Ask early whether agent plugins are permitted on developer workstations. In regulated clients this goes to a security review, and it can hold the project up before a line of code exists. The GitHub marketplace dependency is the part that tends to get pushed back on.
• The planning gates are where you earn your fee. The generated native-app-plan.md locks in the data model and screen set, and everything downstream is regenerated from it — so a sloppy approval at gate one costs far more later than the review time saved. Treat the gates as a design workshop, not a wizard to click through.
• Watch the preview limitations against the client's actual requirements before committing. No push notifications and no Power Automate integration rules out a large slice of typical field-service scenarios, and both are the sort of thing a client assumes is present because the rest of the platform has them.

---

Preview feature with a fast-moving plugin — recheck the limitations list and host support before each engagement, and confirm GA status before anything goes near production.