Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

power-apps/06-code-and-extensibility/feature-code-apps.md
feature-code-apps.mdv1 · history
CurrentApplies to BothUpdated last monthSource Microsoft Learn ↗

What it does

Code apps let a developer build a web app in their own IDE with their own framework — React, Vue, whatever — and host and run it on Power Platform as a governed app. You keep full control of the UI and logic, and you get Entra authentication, the connector catalogue callable from JavaScript, and the platform's admin controls around it. They went generally available in February 2026.

Key facts

  • Enabled per environment by an admin: Settings > Product > Features > Power Apps code apps > Enable code apps. Environment groups and rules can set it across many environments at once.
  • End users running a code app need a Power Apps Premium licence, per the Learn page. Anything more specific belongs in the licensing guide, not here.
  • Prerequisites are developer-machine tooling: an IDE, Node.js LTS, and the Power Apps CLI. The client library from v1.0.4 onward ships its own npm-based CLI, which Microsoft says will replace the pac code commands in a future release.
  • They inherit real managed-platform behaviour: connector consent dialogs, canvas app sharing limits, app quarantine, DLP enforcement at launch, Conditional Access on the individual app, tenant isolation, Azure B2B guest access, and health metrics in both the admin centre and the maker portal.
  • Documented limitations as of the April 2026 refresh: no Power Platform Git integration, no support in the Power Apps mobile app or Power Apps for Windows, no PowerBIIntegration function yet, no SharePoint forms integration, and no Storage SAS IP restriction support.
  • Service principals can't create or own a code app.
  • They can still be embedded in a Power BI report through the Power Apps visual.

When to use / skip

This is the answer when you have a real development team, a genuine web app requirement, and an IT function that wants the app inside the platform's governance rather than sitting in an App Service nobody has looked at since 2022. It's a poor answer when the requirement is a form over data, when nobody on the account writes TypeScript, or when the client's support model is "a maker in finance owns it". Code apps solve a political problem as much as a technical one — they give developers their tooling and give IT the DLP, sharing and Conditional Access story — and that framing is usually the reason to choose them.

Configuration decisions

  • Which environments have code apps enabled, and whether that's set individually or through environment groups.
  • Which CLI the team standardises on now, given the npm-based one is replacing pac code.
  • How source control and deployment work, since Power Platform Git integration doesn't cover code apps — that pipeline is yours to build.
  • Whether the app needs to run in the Power Apps mobile app, because that rules code apps out today.
  • Who owns the app record in the platform, given service principals can't be owners.

Gotchas

  • No Git integration means the platform's own ALM story doesn't apply. Teams assume it does because everything else in the solution does.
  • Mobile is the one that catches people. "It's a web app, it works on a phone browser" is true, and it still isn't available in the Power Apps mobile app.
  • The service principal restriction breaks the automated-ownership pattern most mature customers use for canvas apps.
  • End-user licensing is premium regardless of what the app connects to. That's a different economic profile from a standard-connector canvas app.
  • The tooling prerequisites are real. Code apps aren't something a maker experiments with on a locked-down laptop.

Consultant notes

  • Sell it to IT as governance, not to the business as flexibility. The pitch that lands is "your developers keep their stack and you keep DLP, sharing limits and Conditional Access".
  • Check the limitations list at the start of every engagement. It has moved several times since preview and it's the fastest way to disqualify the option honestly.
  • Be clear that this doesn't remove the need for developers. It moves where they work, not whether you need them.
  • If the client is choosing between a code app and an Azure-hosted web app, the deciding factors are usually connector access, the admin controls, and who ends up on the hook for hosting — not the code itself.

Worth rechecking the limitations list each wave; Git integration and mobile support are the two that would change the recommendation.

Was this accurate?
Related
Power Apps vs custom development11-decision-guidesManaged environments for Power Apps09-governance-and-securityPower Apps licensing decision guide11-decision-guidesPower Apps licensing10-licensing-and-performanceNative Mobile Apps07-mobile-and-offlineCoE Starter Kit for apps09-governance-and-security