Power Apps Code Apps - Simply Explained

You've heard of Power Apps, but now there's something called code apps. Is that a whole new platform? Do you need to learn a completely different tool? I'm Mirko Peters from M365, FM, and today we're clearing this up in plain English. By the end of this episode, you'll understand exactly what code apps are, why Microsoft built them and whether they matter to you. If you've ever felt limited by the drag and drop canvas, or wonder if Power Apps is only for non-coders, this changes everything. We'll break down the problem, the solution, and how it all connects to the Power Platform you already know. Grab your coffee and let's dive in. The big confusion. What exactly is a code app? So let's start with the basic question everyone's asking. What is a code app? Here's the simplest definition. A code app is a power app that you write in code instead of dragging and dropping. Canvas apps are built in a visual designer using PowerFX formulas. You know the drill, you pick a button, drop it on the screen, type a formula like patch or filter, and the app works. It's visual, it's fast, and it's accessible to anyone who can think logically about a spreadsheet. Code apps are different. You build them in Visual Studio Code using JavaScript, TypeScript, and React. There's no drag and drop screen. No property panel on the right. You're writing code in a text editor, just like a web developer building a modern website. But here's the key. Once you deploy it, it runs inside Power Apps just like any other app. It's still hosted, authenticated, and managed by the platform. You don't need to set up your own server. You don't need to build a login screen. You don't need to worry about where the app lives or how users get to it. That's all handled for you. Think of it like this. Canvas apps are pre-furnished rooms. You walk in the furniture is already there. You just rearrange things to your liking. Code apps are empty rooms where you bring your own furniture. But the building security, electricity, and plumbing are already installed. You don't have to build the building. You just decorate the room, however you want. Now, the honest question, does that mean you need to be a developer? The honest answer is yes. Code apps are aimed at pro coders, people who already know JavaScript, who are comfortable with a terminal, who understand how React components work. But that doesn't mean you can't benefit from them. If you're a maker who's hit a wall with Canvas apps, you can partner with a developer on your team. You design the logic, they write the code. It's a fusion model. So what can code apps do that Canvas apps can't? Let's look at the real limits of Canvas apps and where code apps pick up the slack. Body 2, where Canvas apps stop and code steps. In Canvas apps are powerful. Let's be clear about that. You can build real business applications with them. Thousands of companies do it every day, but they have restrictions. You can't use custom CSS. The styling options are what they are. You can change colors, fonts and sizes, but you're limited to what the platform gives you. You can't embed complex JavaScript libraries. If there's a charting library you love or a date picker that's more sophisticated than the default one, you're out of luck. Animation and pixel-perfect control are tough. You can make things fade in and slide out, but you can't build the kind of smooth, polished animations users expect from modern web apps. Code apps change all of that. You get full control over HTML, CSS and JavaScript. You can use any React framework you want. Any NPM package, that's the note. JS package manager with hundreds of thousands of libraries is available to you. You can build anything a modern web app can do. Let me give you concrete examples. Fancy animations, easy. You can use libraries like frame-emotion to add smooth transitions, drag gestures and spring animations. Custom charting libraries, no problem. You can drop in D3, JAS or chart JAS and build visualizations that look like they belong in a data dashboard from a major tech company. Drag and drop within an app. You can build that yourself using libraries like React, beautiful D&D. The sky's the limit, but here's the trade-off. You lose the simplicity of the visual editor. You're writing code now. That means you need to understand how React works, how state management works, how to debug JavaScript errors in the browser console. It's a trade. You gain flexibility, but you lose speed and accessibility. Microsoft is working on tools to bridge this gap. There's a new experience called vibe, powerapps.com that aims to make code apps more accessible. But right now, code apps are for people comfortable with a terminal. If the command line makes you nervous, this might not be for you yet. So what does the actual development workflow look like? Let's open the hood and see the developer experience. The developer's toolbox, VS Code, CLI, React. So what do you actually need to get started? The prerequisites are straightforward. You need visual studio code. That's Microsoft's free code editor. You need Node.JS, which is a runtime that lets JavaScript run outside a browser. And you need a power platform environment with code apps enabled. That's a toggle your admin flips in the settings. Once that's set up, here's the workflow. First, you scaffold a project. That means you run a single command that downloads a starter template, a basic app structure with all the files you need. Think of it like getting a blank canvas with the easel already assembled. You run NPM install to pull in the dependencies, which are pre-built code packages that your app needs to work. Then you initialize the app with NPMX power apps in it. That command connects your local project to your power platform environment. It asks for your environment ID, authenticates you and creates a configuration file that ties everything together. Now here's where it gets interesting. You run NPM, run dev, and your app appears in a browser window, running locally on your machine, but already connected to your power platform environment. You can test with real data. You can see your changes live as you edit the code. It's hot reloading, which means you save a file and the browser updates instantly. No waiting for builds, no manual refresh. When you're ready to share your app, you run NPM, run build. That packages everything into a distribution folder, optimized, minified, ready for production. Then NPMX power apps push deploys it to power apps as a new code app. It appears in your app list, just like a canvas app, you can share it, add it to solutions and manage it through the normal power platform life cycle. Here's an analogy. It's like filming a movie in your own studio, then uploading it to Netflix. The platform handles distribution. You just focus on the content. You don't need to build the streaming infrastructure. You don't need to negotiate with cable providers. You make the movie uploaded and Netflix handles the rest. Even though it sounds technical, the workflow is three commands in it. Dev push, that's it. Everything else, the authentication, the hosting, the security is handled behind the scenes by power platform. But how does your code actually talk to power platform? How does a react component read data from data verse or trigger a power automate flow? That's where the SDK comes in. What the power apps SDK actually does, the power apps SDK is a node, JS package. It acts as a translator between your custom code and power platform services. Without it, you'd have to manually write API calls, handle authentication tokens and pass responses. The SDK does all of that for you. Here's how it works in practice. When you add a data source, say a data verse table or a share point list, you run NPX power apps at data source. The SDK reaches out to power platform, pulls the schema of that table and generates two things. First, a model file. That's a typed interface that shows every column in your table, the column names, data types and relationships. Second, a service file. That's a set of functions you can call to read and write data. Let me give you a concrete example. You run NPX power apps at data source with your data verse table name, say catalog items. The SDK creates a model file that shows all the columns name, price, category, availability. It also creates a service file with functions like create record, get records, update record and delete record. Each function is fully typed, which means your code editor knows exactly what parameters to expect. No guessing, no digging through documentation contrast is with canvas apps. In a canvas app, you use power effects formulas like patch and filter. You type the formula, the platform figures out the rest in code apps. You import the service and call run with parameters, same result, different language. One is visual and formula based. The other is code and function based. Here's an analogy. Think of the SDK as a pre-written instruction book. You don't need to know how to build the car. You just use the steering wheel. The SDK handles the complexity of authentication, data serialization and error handling. You focus on what you want to do. Read a record, create a record, update a record, one more thing worth mentioning. The SDK is open source on GitHub, Microsoft maintains it and the community can contribute. That means you can see exactly how it works, report bugs and even submit improvements. It's the same technology that powers the new vibe, power apps.com experience, which is Microsoft's attempt to make code apps more accessible through AI assisted development. And behind the SDK, the same connectors you already know data and connectors, same platform, different controls. So what data sources actually work with code apps, the short answer is the same ones you already use in canvas apps. SharePoint, Dataverse SQL Server Office 365, they're all available. You're not losing access to anything, but there is some nuance. Right now SharePoint document libraries aren't fully supported for file uploads. You can read from them, but sending files back has limitations. Microsoft is actively fixing this. And if you're watching this a few months from now, it's probably already sorted for now just be aware of it. So how do you actually add a connector? You use the CLI. The command is NPX Power Apps add data source and then you pass the connector ID for SharePoint. That's shared SharePoint online. For Dataverse, it's even simpler. You just type Dataverse, the CLI handles the rest. It reaches out to your environment, authenticates and pulls the schema. And here's something really powerful. You can also add instant cloud flows as data sources. That means your code app can trigger a power automate flow and get a response back. The CLI generates a service file with a run method that accepts the flows input parameters and returns the output. Imagine a help desk app. A user submits a ticket. Your code app calls a flow via the SDK. The flow runs in approval process sends an email, updates a data All within the same app, the user never leaves the interface. And because these use the same connectors, all your data loss prevention policies apply. You don't lose any security. Therefore connector is blocked in your environment. It's blocked in code apps to there's no back door. But if code apps are so powerful, do they replace canvas apps entirely? Let's talk about the elephant in the room. Governance licensing and where code apps fit in your strategy. Governance and licensing. Yes, it's still power apps. Let's be clear about one thing. Code apps are subject to the same governance as canvas apps. They appear in solutions. They can be deployed through pipelines. They inherit environment policies. Your IT team doesn't lose control licensing is straightforward. Users need a power apps premium license to run code apps. There's no extra code app. SQ if you already have premium your covered same license, same cost, same rights. But admins do need to enable code apps per environment. It's a toggle in the power platform admin center environment settings. Then product, then features flip it on and your developers can start deploying code apps to that environment. It's off by default, which makes sense. You don't want random apps appearing without your knowledge. Now, let's address a common myth. Some people think code apps can't be governed because they're built in external tools like VS code. The opposite is true. They're fully managed by power platform. You can apply DLP policies, conditional access policies and audit logging. Every action is tracked. Every deployment is recorded. If someone tries to use a blocked connector, the platform stops them. Compare that to building a separate React app on Azure. You'd need to handle authentication yourself. You'd need to set up hosting, configure security, manage compliance. You'd need to build your own login page, your own session management, your own audit trail with code apps. All of that is provided. You write the front end code. The platform handles everything else. Here's an analogy. It's like renting a fully serviced office versus building your own building. Both let you work both give you space. But one removes all the overhead. The utilities, the maintenance, the security, you just show up into your work. Now let's step back and see how all these pieces connect. How all parts fit together. So how does everything actually work when someone uses your code app? You have three layers, the app itself. That's your React code, the user interface you built, the SDK. That's the translator connecting your code to the platform. And power platform services hosting authentication connectors, data verse, three layers, one system. Here's how they interact. Your app calls a function from the SDK is generated service. The SDK handles authentication reaches through a connector proxy and fetches data from whatever source you connected. Dataverse, SharePoint, SQL Server. The platform returns the results, your app renders them. The user sees the data on screen. Let me walk through a real example. A user clicks a button in your code app. Your React code calls a service function, say, create record from your generated service file. That service sends an authenticated request to data verse. The record is added to the table. The service returns a success response. Your app shows a confirmation message on screen. All of that happens in seconds. The user never sees the complexity underneath. The real magic isn't the code itself. You could write that same React app and host it anywhere. The magic is that every part identity data automation security is already connected. You're writing the front end, but the platform handles everything else. The authentication is built in. The data connections are pre-configured. The security policies from your environment apply automatically. You don't wire any of that up yourself. Once you see that, the aha moment hits code apps aren't a separate platform. They're not a new tool you have to learn from scratch. There are new way to build on the same foundation you already have. Same power platform, same governance, same data sources, different front and approach. So if you're intrigued, what should you do next? Start here. Your next steps. Let me give you five concrete actions you can take today. First, enable code apps in your development environment. Go to environment settings, then product, then features. Find the toggle for power apps code apps and turn it on. That's a five second step, but without it, nothing else works. Second, follow the official Microsoft documentation to scaffold your first code app. The docs walk you through the whole process. You run a single command and within minutes you have a working hello world app running in your browser. It's not exciting, but it proves the pipeline works. Third, try adding a data source, connect to a dataverse table or a share point list, run the npx power apps at data source command and watch what happens. The SDK generates model and service files automatically. You'll see typed interfaces for your columns and ready to use functions for reading and writing data. That's when it clicks fourth use an AI coding assistant GitHub co pilot or Claude code can help you write the react code. Many tutorials show this path. You describe what you want in plain language. Build a table view of the catalog items with a search bar and the AI writes the react components. You review, tweak and deploy. It's not magic, but it's close. Fifth, join the community. The code apps GitHub repo is active. Developers are asking questions, reporting issues and sharing real examples. You'll learn more from reading their discussions than from any tutorial. And here's the reassuring part you don't have to be a senior developer. If you're comfortable with basic JavaScript and can copy paste commands from documentation, you can get started. The AI tools handle the heavy lifting your job is to understand what you want to build and verify the code works. If you want to build custom web apps without the headache of managing infrastructure, code apps are your ticket. You get full control over the user interface. You get all the enterprise benefits of power platform and you get to use modern development tools. You already know power apps code apps give professional developers the freedom to build fully custom front ends while keeping all the enterprise benefits of power platform. If you're a maker who's hit a wall with canvas apps, this is your next step. Start with the first action, enable code apps and see what you can create. Subscribe to m365.fm for more plain English breakdowns of Microsoft's newest tools. Drop a comment below. Are you planning to try code apps?