Reach for a code app once a canvas app's formula language can't build the interface the job needs, or once you want real code review on the front end. Code apps went generally available in February 2026, after roughly a year in preview. Underneath, it's still a Power App: Dataverse, connectors, managed auth and Power Platform ALM all stay exactly where they were. What changes is who builds it and what they need installed to do it.
What a code app is
A code app is a proper single-page application: TypeScript, bundled by Vite, built in Visual Studio Code the way any other front end project gets built. Microsoft's official starter template is React and needs zero extra setup. Vue drops in with one plugin line. Svelte, Solid and Preact are tested and work. If the brief calls for Angular, budget an extra day, its build tooling doesn't slot in as cleanly as the others.
What makes it a Power Platform product rather than "a React app someone hosted somewhere" is where it runs and what it's allowed to touch. Microsoft hosts the app inside the Power Apps runtime, so there's no separate hosting bill or deployment pipeline to invent from scratch. The Power Apps SDK gives your code typed access to Dataverse and Power Platform connectors, without you writing a line of authentication code yourself.
The three things a canvas app can't do that eventually push a team off platform
Most teams don't leave canvas apps because they got tired of them. They leave because they hit one of three walls, usually in this order.
Custom interaction design is the first. Canvas apps run on a formula language and a fixed set of controls, and that's genuinely fast for forms, lists and simple approval screens. It falls over the moment someone wants a drag-and-drop scheduler, a multi-step wizard with real transition states, or a data grid that behaves the way a proper front end library behaves. You can force a canvas app to do it. I've watched people force it. The formula bar was never built for that job, and it shows in every workaround.
Then engineering practice. A canvas app's source is a `.msapp` file, effectively a binary. You can put it in source control, but you can't meaningfully diff it, review it in a pull request, or run an automated test against it the way a developer expects to. Teams that care about code review, CI and test coverage hit this wall fast, and it's a legitimate reason to leave.
The npm world is the third. Charting libraries, mapping, complex client-side state, component libraries built and maintained by someone else, none of that exists inside the canvas control palette. You can wire in a custom connector or a component framework control for some of it, but past a certain point you're rebuilding a library that already exists on npm, badly, in a formula language that was never designed for it.
Hit all three and you get the "let's build a custom front end" conversation, which until this year meant leaving Power Platform behind entirely: your own hosting, your own auth, your own connection back to whatever system of record you were using. Code apps close that specific gap. You get the real front end and keep the plumbing underneath it.
What you keep
This is the part worth being precise about, because it's where the value of the product sits.
Dataverse access stays as direct as it was in a canvas app. The SDK gives you typed service methods for reading and writing Dataverse tables, so you're writing ordinary front end code against ordinary data, with no formula to fight. If the open question is the backend itself rather than the front end, that's a separate call: Dataverse or Azure SQL.
Managed connectors carry across too. SharePoint, Outlook, Dataverse and the rest are available through the same connector model the rest of Power Platform already uses, and custom connectors work as well, once you've attached a managed identity for the connector to your client's Entra app registration.
The host handles auth. It manages the Entra ID tokens, the OAuth flows and the consent dialogs, and your code never touches a token directly. That's a genuine saving, because getting authentication wrong is one of the more expensive ways to lose a week on a custom front end build.
ALM is the same ALM as the rest of Power Platform. Code apps go into solutions like any other component, move through dev, test and production environments, and deploy through Power Platform Pipelines the same way a canvas app or a Copilot Studio agent would. Managed Environments have been auto-enabled on pipeline targets since February 2026, so the same governance guardrails, sharing limits, solution checking on import, deployment insights, apply here too.
One thing to check before you commit to a licensing model: if you were planning to licence a single code app per user through the older Power Apps per app plan, confirm it's still open to you. Microsoft has been winding that plan down for new non-CSP purchases through 2026. Premium, at roughly USD 20 per user per month as at July 2026, is the safer number to budget against for anything touching Dataverse or a premium connector. Check the current rate before you quote it to anyone; Microsoft moves this pricing more often than most people expect.
What you take on
All of that costs you a real front end project, with real front end overhead.
There's a build step. Vite bundles the app, so there's an npm install, a local dev server, a build command, and a deploy step, historically `pac code push` through the Power Platform CLI, or a newer npm-based CLI shipped inside the code apps client library that's gradually replacing it and needs fewer prerequisites to get running.
The repo is yours to manage. Code apps don't have native Power Platform Git integration the way some other components do, so your source lives in whatever Git provider your team already uses, and branching, review and history are your job, done the ordinary way rather than the Power Platform maker way.
One admin step catches most teams the first time: code apps have to be switched on per environment before anyone can push one into it, under environment settings, product, features. Small thing, but it stops a first attempt cold until someone knows to flip it.
Someone also has to be able to do front end work. TypeScript, component structure, dependency management, reading a build error and knowing what it means. That's a developer's job, working with the SDK instead of standing up hosting and auth from a blank page, and it's a long way from the citizen maker Power Platform built its reputation on. If that person doesn't already exist inside the business, this is a build to commission rather than a maker afternoon to squeeze in.
When I'd still reach for canvas instead
Three situations, in practice.
A field team that needs the app on their phone, including somewhere without signal. Code apps have no mobile app support today, not on Power Apps for iOS, not on Android, not on Windows, so there's no offline story at all. A canvas app running in the Power Apps mobile player still owns that job, and will for a while yet.
A simple internal tool that one person in the business will build and maintain without a developer sitting behind it. If the whole job is a form, a list and an approval step, the formula language gets you there in an afternoon and leaves nobody owning a repo they didn't ask for.
Anything that needs to sit inside another canvas or model-driven app. Code apps are standalone, they don't embed. If the requirement is "add this screen to the app we already have", that's a canvas or component framework conversation.
| Canvas app | Code app |
|---|---|
| Built with formulas and a fixed control set | Built with TypeScript and a real framework, in a normal repo |
| Auth, Dataverse and connectors built in | Auth, Dataverse and connectors built in, same connector model |
| Runs on the Power Apps mobile player, including offline | No mobile app support, no offline story |
| Can embed inside other apps as a component | Standalone only, does not embed |
| A maker comfortable with formulas can build and maintain it | Needs a developer who can maintain a front end |
| Source is a binary `.msapp`, hard to diff or review | Source is text in Git, diffable, reviewable, testable |
If you're not sure whether a problem in front of you needs a code app, a canvas app, or a model-driven app, that's a normal place to be stuck, the three options look similar from a distance and cost very different amounts of time to build and maintain. I go through the trade-offs between all three in canvas apps versus model-driven apps versus code apps. If you want to see what a build like this looks like end to end, the case studies show a few, and I cover where code apps sit in the wider Power Platform and Copilot picture on the Power Platform page.
Common questions
Are Power Apps code apps generally available?
Yes. Code apps went generally available in February 2026 after roughly a year in preview. Before that, treating them as production-ready for a client build would have been premature. As at July 2026 they're a supported, GA capability of Power Apps.
Do I need a special licence for a Power Apps code app?
No special code app licence exists. The same rule that applies to any Power App applies here: the moment it touches Dataverse or a premium connector, the users need a premium tier, typically Power Apps Premium, priced per user per month. Check current pricing before budgeting, Microsoft revises it regularly.
Can a Power Apps code app run offline on a phone?
No. Code apps have no mobile app support today, not on Power Apps for iOS, Android or Windows, so there is no offline story at all. A canvas app running in the Power Apps mobile player is still the right tool for field staff who need the app without signal.
Weighing a code app against something simpler?
Free 30-minute call. I'll tell you which of the three Power Apps types fits, including when the answer is none of them.