Canvas app fundamentals

What it does

A canvas app is a screen-by-screen application you lay out yourself on a blank design surface, wiring controls to data through Power Fx formulas. You pick the pixels, the navigation and the data sources; the platform gives you the runtime, the connectors and the mobile players.

Key facts

The unit of structure is the screen. Controls sit on screens, screens sit in the app, and every control property is either a constant or a Power Fx formula that recalculates when its inputs change.
You choose phone or tablet format at creation time. That choice sets the design canvas dimensions and can't be swapped later without rebuilding the layout.
Data comes in through connectors — Dataverse, SharePoint, SQL Server, Excel in cloud storage, and several hundred others. Premium connectors need a premium licence; check the Power Platform licensing guide rather than guessing.
Apps run in a browser, in Power Apps mobile on iOS and Android, on Windows, and embedded in SharePoint, Teams and Power BI.
Sharing is per-app: you name users or groups and choose whether they can run it, or also edit and reshare.
An app created outside a solution lives loose in the environment. An app created inside a solution is a solution component and moves between environments with the rest of the solution.

When to use / skip

Reach for canvas when the interface is the point — a task-focused mobile app, a kiosk, a guided form over data that isn't in Dataverse, or something that has to look like the client's brand rather than like Dynamics. Skip it when the requirement is really "let people work with a lot of records across several related tables", because you'll spend weeks rebuilding grids, filters, search and security that a model-driven app gives you free. The honest test: if you're about to build a list view with column sorting and a filter pane, you're building a model-driven app the hard way.

Configuration decisions

Phone or tablet format at creation, and whether the app is meant to be responsive at all — this is effectively irreversible.
Which data sources the app owns directly versus which it reaches through Dataverse, because every extra connector is another connection, another DLP consideration and another licence question.
Whether the app lives in a solution from day one. Retrofitting solution awareness onto a loose canvas app is possible but nobody enjoys it.
Whether logic lives in the app or behind it — Power Fx in the app, business rules or plug-ins in Dataverse, or a flow.
Naming conventions for controls and screens, set before the app has forty controls called Label12_3.

Gotchas

Create the app in a solution. Apps built outside one and imported later work, but you lose the clean ALM story and end up hand-managing connection references.
Connections are owned by whoever created them. Share an app built on a personal SQL connection and you've quietly shared that identity's access.
The design canvas is not the runtime. An app that looks right in Studio can look wrong on a 13-inch laptop, and Studio won't warn you.
Formulas recalculate automatically, which is the whole point — but it means a badly placed Filter() on a control property can fire hundreds of data calls without you noticing.

Consultant notes

Have the canvas-versus-model-driven conversation before anyone opens Studio. Changing your mind three sprints in is a rewrite, not a refactor.
Canvas apps are easy to start and hard to hand over. Budget for naming standards, comments and a written data model, or the client's internal team will not touch it after you leave.
Warn the client that "anyone can build these" is true and is also how you end up with four apps doing the same thing. Governance is a delivery item, not an afterthought.
Premium connector licensing is the single most common nasty surprise. Confirm the licence position in writing before you design around SQL or a custom connector.

Worth a fresh look whenever Microsoft changes the default app format or the maker portal reorganises again.