Consulting Briefing

03.05.2026 — boddenberg.de

Code Apps in Power Apps werden generally available

Executive Summary

Microsoft hat am 5. Februar 2026 die Code Apps in Power Apps offiziell auf general availability gehoben. Damit wird aus dem netten Preview-Spielzeug fuer Pro-Devs ein Produkt, das du mit gutem Gewissen in Produktion stellen darfst — vorausgesetzt, du hast deine Hausaufgaben in Sachen Lizenzierung, Governance und ALM gemacht. Der Witz an der Sache: Code Apps sind keine Canvas-Apps mit Code-Nase, sondern echte React- oder Vue-Web-Apps, die im Power Platform Managed Host laufen, dabei aber Entra-Auth, DLP-Policies und Conditional Access mitbekommen — ohne dass dein Dev-Team eine einzige Zeile Auth-Code schreiben muss.

Was du als Berater oder IT-Verantwortlicher mitnehmen solltest: Die Grenze zwischen Low-Code und klassischer Web-Entwicklung loest sich auf. Deine Maker-Community wird in den naechsten Monaten Pro-Devs in den Tenant einladen, die ploetzlich npm-Builds in eure Environments deployen. Wenn du jetzt nicht ALM, GitHub-Integration und Lizenzbedarf klaerst, hast du in sechs Monaten ein Schatten-IT-Problem — diesmal aber mit Premium-Lizenz und voller Connector-Power.

Worum geht es im Detail? Auch Hintergruende erlaeutern

Power Apps war jahrelang der Inbegriff von „mein Buchhalter baut sich seine eigene App". Drag-and-Drop, Power Fx, ein bisschen Magie — und auf der anderen Seite Pro-Devs, die bei jedem Canvas-App-Code-Editor aussehen, als haetten sie in eine Zitrone gebissen. Genau diese Frontlinie hat Microsoft mit Code Apps eingerissen. Eine Code App ist eine vollstaendige Web-App, die du in Visual Studio Code mit React, Vue oder einem anderen modernen Framework baust — und dann im Power Platform Managed Host laufen laesst, statt auf einem App Service in Azure.

Der entscheidende Unterschied zu „ich baue mir eine eigene Web-App und schiebe sie irgendwo hin" liegt in dem, was du beim Hosten gratis dazubekommst. Microsoft Entra ID uebernimmt die Authentifizierung, ohne dass du eine MSAL-Library importieren musst. Conditional-Access-Policies greifen, weil deine App genauso behandelt wird wie eine Canvas-App. Data-Loss-Prevention-Policies wirken zur Laufzeit auf jeden Connector-Aufruf — wenn euer Tenant SAP fuer „Business"-Connector und Twitter fuer „Non-Business" klassifiziert hat, kann euer Dev keine Bruecke zwischen beiden bauen, auch wenn er es wuerde versuchen. Tenant-Isolation, App-Quarantine, Sharing-Limits: alles erbst du, ohne ein einziges Ticket bei der Security aufzumachen.

Technisch funktioniert das so: Du installierst Node.js LTS, das npm-CLI @microsoft/power-apps (ab v1.0.4 ist das die offizielle CLI, das alte pac code wird deprecated) und bekommst ein Projekt-Skelett. Lokal entwickelst du wie gewohnt — Vite-style Hot Module Replacement inklusive — und faengst per JavaScript-Aufruf die ueber 1.500 Power-Platform-Connectors ab. SQL, SharePoint, Dataverse, SAP, ServiceNow, eigene Custom-Connectors auf REST-Basis: alles als typed-Methoden, ohne dass du dich um Token-Refresh, OAuth-Dance oder Proxy-Konfiguration kuemmern musst. Beim Publish baut die CLI deinen Bundle, lädt ihn in das Environment hoch und registriert die App so, dass sie im Maker-Portal auftaucht.

Damit das ganze nicht zur Wildwest-Veranstaltung wird, hat Microsoft den Schalter bewusst beim Admin gelassen. Code Apps sind pro Environment deaktiviert, bis ein Power-Platform-Admin oder Environment-Admin im Power Platform Admin Center unter Settings > Product > Features den Toggle „Enable code apps" aktiviert. Fuer Tenants mit vielen Environments gibt es Environment-Groups und -Rules, mit denen du die Aktivierung centrally steuern kannst. Wer also ohne Vorwarnung morgen frueh feststellt, dass das Marketing eine React-App in Produktion geschoben hat, hat sich diese Ueberraschung selbst eingebaut.

Lizenz-Update, das gerne unter den Tisch faellt: Die alte „Per-App-Lizenz" fuer fuenf Dollar pro Nutzer und App ist am 1. Februar 2026 in Rente gegangen. Wer heute Code Apps oder Canvas-Apps in Produktion fahren will, braucht fuer jeden Endanwender eine Power Apps Premium-Lizenz — egal ob das eine 200-Mann-Vertriebsabteilung ist oder die drei Kollegen in der Logistik. Microsoft 365 alleine reicht weiter nur fuer Sub-Set-Szenarien (z. B. Apps gegen SharePoint-Listen). Pack das in deine TCO-Rechnung, bevor das Sales-Team euch eine Code App fuer den ganzen Aussendienst empfiehlt.

Abb. 1: Drei Welten — Developer, Managed Host, Daten. Code Apps verbinden sie unter einer einzigen Governance-Decke.

Chancen und Risiken

Chancen: Du holst deine Pro-Dev-Kollegen aus dem Power-Apps-Frust raus und bekommst trotzdem die Governance-Vorteile der Plattform. Konkret heisst das: Deine Devs koennen mit ihrer gewohnten Toolchain arbeiten — VS Code, Git, Jest, Storybook, GitHub Copilot, GitHub Actions — und mussten trotzdem keine eigene Auth-Schicht zimmern. Was frueher ein dreimonatiges Azure-AD-App-Registrations-Drama war, ist jetzt eine Zeile in der CLI. Die 1.500+ Connectors machen aus eurem Tenant einen Integration-Hub: SAP-Daten gegen Dataverse joinen und in einer pixelgenauen React-UI darstellen, ohne einen einzigen API-Gateway zu deployen — das war frueher ein Architektur-Workshop, heute ist es ein Sprint.

Praxisbeispiel aus dem letzten Quartal: Ein mittelstaendischer Maschinenbauer hatte eine Canvas-App fuer die Aussendienst-Auftragserfassung. Performant — solange der Aussendienstler nicht mehr als drei Positionen anlegt. Ab Position vier laggte die Galerie, der Vertrieb tobte, der Maker zuckte mit den Schultern. Mit Code Apps haben die Devs in vier Wochen eine React-Variante gebaut, die dieselben Connectors nutzt, aber Virtualisierung der Liste und Optimistic-UI mitbringt. Rollout in der Produktion ohne neue Lizenz-Diskussion, weil das Premium-Subscription eh schon vorhanden war. Time-to-Production: ein Drittel im Vergleich zu einem App-Service-Eigenbau, weil Auth, Hosting und DLP geschenkt waren.

Risiken: Die Schattenseite ist, dass deine Maker-Community ploetzlich denkt, sie sei ein Software-Engineering-Team. Ein Maker, der vorher Power Fx geschrieben hat und jetzt via GitHub-Copilot eine React-App produziert, hat noch lange keine Tests, kein Code-Review-Setup und kein Verstaendnis dafuer, was passiert, wenn die Storage-Quote des Connectors gerissen wird. Die Code-App laeuft, die App fuehlt sich gut an — und dann reisst die SQL-Connector-Throttling-Grenze und ihr habt einen Vorfall, weil niemand Retry-Logik vorgesehen hat.

Zweite Falle: Die Limitations-Liste. Code Apps unterstuetzen heute kein Power Platform Git Integration (das nette Feature, mit dem Solutions als Branches in Azure DevOps oder GitHub liegen), keine Power-BI-Integration via PowerBIIntegration-Function, keine SharePoint-Forms-Integration, kein SAS-IP-Restriction, und sie laufen nicht in der Power-Apps-Mobile-App. Wer also eine schnelle Mobile-Lieferung braucht oder Power-BI-Embedded zwingend benoetigt, sollte bei Canvas-Apps bleiben. Die Mobile-Luecke ist besonders fies, weil viele Auftraggeber „Power Apps" automatisch mit „laeuft auf dem Handy in der App" gleichsetzen — was bei Code Apps schlicht nicht stimmt. Die Browser-Variante geht, klar, aber dann stellt sich die Frage, warum man ueberhaupt im Power-Platform-Universum bleibt.

Drittes Risiko: ALM-Reife. Microsoft sagt „Code Apps sind ja Code, also funktioniert ALM mit GitHub einfach". Stimmt halb. Du brauchst eine Pipeline, die auf Pull-Requests baut, einen Test-Tenant fuer Pre-Prod-Deployments und eine Strategie fuer Connector-Connections in unterschiedlichen Environments. Ohne diese Hausaufgaben deployst du Dev-Builds in Prod und stellst Montagmorgens fest, dass dein Connector immer noch auf den Test-Tenant zeigt. Praxisanekdote: Ein Kunde hat in der Preview-Phase genau das gemacht — Test-Connector, Prod-Build, Prod-Deployment. Der Endkunde sah Test-Daten, der Datenschutz war begeistert.

Abb. 2: Entscheidungsmatrix Canvas vs. Code App vs. Azure-Eigenbau. Code Apps sind selten der einzige Weg — aber haeufig der schnellste mit Governance.

Was muessen wir jetzt schon vorbereiten?

Erstens: Lizenz-Inventur. Geh durch deine Tenants und schau dir an, wer heute Power-Apps-Lizenzen welcher Form besitzt. Die Per-App-Lizenz ist tot, aber sie taucht in Subscription-Berichten weiterhin auf, bis Renewals durchlaufen. Modelliere fuer die naechsten zwoelf Monate, was es kostet, alle relevanten Anwender auf Power Apps Premium zu heben. Wenn die Zahl schmerzhaft hoch wird, ist das ein guter Moment, um zu fragen, ob der App-Use-Case nicht in Microsoft 365 mit Sub-Set-Connectors abbildbar ist.

Zweitens: Environment-Strategie. Lege fest, in welchen Environments Code Apps ueberhaupt aktiviert werden duerfen. Default sollte sein: aus. Aktiviere die Funktion explizit in einem Dev-Environment, einem Pre-Prod-Environment und einem oder mehreren Prod-Environments — und nutze Environment Groups + Rules, damit nicht jeder zweite Maker auf eigene Faust den Toggle sucht. Schreib das ins Environment-Lifecycle-Dokument, sonst hast du in einem Vierteljahr 47 Code-App-faehige Environments und keiner weiss, warum.

Drittens: ALM und GitHub-Setup. Stelle eine Reference-Pipeline bereit, mit der ein Dev-Team einen GitHub-Repository forkt und in einer Stunde aus dem nichts deployt. Pipeline-Bausteine: Linter, Unit-Tests, Build, Power-Apps-CLI-Publish in eine Test-Environment, Smoke-Test, optionaler Approval-Step, Publish in Prod. GitHub Actions hat dafuer fertige Power-Platform-Actions, die du aus dem Marketplace ziehen kannst. Ohne diese Pipeline machst du Continuous Chaos statt Continuous Deployment.

Viertens: Connector-Governance. Klaere mit deinem Security-Team, welche Connectors in welcher DLP-Policy stecken, und kommuniziere das deinen Pro-Devs vor dem ersten Sprint. Spar dir die Diskussion „Aber meine App braucht Twitter UND SAP" auf einer PowerPoint-Folie, nicht zwei Tage vor dem Go-Live. Custom Connectors brauchen ein eigenes Review — die App-Fassade kann noch so huebsch sein, wenn der Custom Connector ein API-Key-Lecken-Geschenkpaket ist.

Fuenftens: Skill-Inventur in deinem Maker- und Dev-Team. Nicht jeder Canvas-Maker wird zum React-Profi, und nicht jeder Dev ist plattform-affin. Mach ein internes Enablement (zwei Tage Hands-On reichen) und definiere klar, wer welchen Typ App bauen darf. Eine saubere Trennung „Maker bauen Canvas, Pro-Devs bauen Code Apps, beide nutzen dieselben Connectors" reduziert Reibung erheblich.