Many canvas apps pin every control to absolute X/Y coordinates at one design size, and look wrong at any other: a label overlapping a button on a laptop, dead space on a tablet, horizontal scrolling on a phone.
Power Apps has had proper responsive layout tools — horizontal and vertical layout containers — for several years. Here's how to build screens that adapt, and the limits worth knowing before you commit to a layout.
Why fixed positioning breaks
A control with X: 850, Y: 120, Width: 300 is correct for exactly one screen size. With Scale to fit on, Power Apps' answer to other sizes is to render your app at its design resolution and scale the whole thing like an image: text gets smaller, touch targets shrink, and a phone shows a miniature desktop app.
The alternative is real responsiveness: the app uses the actual window size, and your layout reflows. That takes two changes:
-
Settings > Display: turn off "Scale to fit". (Older Studio versions and some Microsoft pages call this area File > Settings > Screen size + orientation.) Turning it off also switches off and disables Lock aspect ratio. Lock orientation is a separate setting — turn it off too if the app should follow device rotation. With Scale to fit off,
App.WidthandApp.Heightchange as the window is resized. - Stop positioning controls with absolute numbers, and let containers do it.
You could make every control's X/Y/Width a formula referencing Parent.Width — Microsoft documents that technique, including a centering pattern of the form (Parent.Width - C.Width) / 2, where C is the control being centered (the Self operator can stand in for its own name) — but a screen full of that math is miserable to maintain. Containers exist so you don't have to.
One testing caveat from Microsoft's documentation: the authoring canvas in Studio doesn't respond to these sizing formulas. Test in a published app, or in Preview — and if you resize the browser window while Preview is open, close and reopen Preview, because it may not update correctly.
Containers in 90 seconds
The controls that matter:
-
Horizontal container — lays out children left to right and manages their
Xfor you. -
Vertical container — lays out children top to bottom and manages their
Y. -
Container — a container in manual layout. Its children keep their own
X/Y/Width/Height, so it groups and nests controls under a common parent but doesn't position them for you; responsiveness inside it still relies on formulas based onParent.WidthandParent.Height. - Grid container — a newer control that places children by rows and columns. Microsoft's controls index has labelled it as preview, so check its status in your version of Studio before relying on it in production.
Inside a layout container, the children's position properties are taken over by the container. You stop thinking in coordinates and start thinking in structure. (Microsoft notes that drag and drop on the canvas is disabled inside layout containers: you reorder children in the Tree view or with the arrow keys, and controls moved into a container are inserted in their Tree-view order.)
Screen
└─ Vertical container (X 0, Y 0, Width Parent.Width, Height Parent.Height, Align (horizontal): Stretch)
├─ Horizontal container ← header, fixed height 64
├─ Horizontal container ← content, flexible height (Fill portions 1), Align (vertical): Stretch
│ ├─ Vertical container ← sidebar, fixed width 280
│ └─ Vertical container ← main area, flexible width (Fill portions 1)
└─ Horizontal container ← footer, fixed height 48
That's a classic app shell — header, sidebar, content, footer. The top-level container is sized to its parent (Microsoft's documented setup); everything inside it is laid out by the containers rather than by position formulas. Resize the window and the main area absorbs the change, while the header and footer keep their fixed height and the sidebar keeps its fixed width.
Fixed sizes vs Fill portions
Each child of a layout container sizes along the container's main axis in one of two ways:
- Fixed size — "this button is 120 wide, always."
- Flexible width / Flexible height with Fill portions — "give this child a share of whatever space is left."
Fill portions are relative weights over the container's extra space — the space left once the fixed children are placed. Two flexible children with portions 1 and 2 get one third and two thirds of it:
Horizontal container (width: Parent.Width)
├─ Gallery flexible width, Fill portions: 2
└─ Detail panel flexible width, Fill portions: 1
The pattern that makes real layouts work is mixing the two in one container: fixed sizes for chrome (icons, buttons, sidebars), flexible sizes for content. A search bar that fills the space between a fixed logo and a fixed avatar button:
Horizontal container
├─ Logo fixed 140
├─ Search input flexible width, Fill portions: 1
└─ Avatar button fixed 48
On the cross axis, set the container's Align property to Stretch (Microsoft's walkthroughs label it Align (vertical) on a horizontal container and Align (horizontal) on a vertical one, but Studio labels vary between pages and versions — rely on the formula-bar name LayoutAlignItems, with values Start, Center, End and Stretch). A stretched vertical container inside a horizontal one is how you get equal-height columns without ever setting a Height.
Minimum sizes
Flexible children can get very narrow on a small screen, and fixed children can overflow it. The platform gives you two floors to set deliberately:
-
Per child: layout-container children have a Minimum width / Minimum height (
LayoutMinWidth/LayoutMinHeightin the formula bar) — the minimum size of the child in the direction of the Fill portions. -
Per app: the app has
MinScreenWidthandMinScreenHeight. In Microsoft's responsive-layout page the default screen width isMax(App.Width, App.MinScreenWidth), so below that floor the screen stops shrinking and the user scrolls; another Microsoft page describes the formula asMax(App.Width, App.DesignWidth)once Scale to fit is off, so check theWidthformula on your own screens.
Still plan the "too narrow" case explicitly with a breakpoint (next section): switch a container to vertical, or hide the element.
Breakpoints
There's no CSS media query in Power Apps, but there is built-in breakpoint support. Every screen has a Size property (ScreenSize.Small, Medium, Large, ExtraLarge) computed from App.SizeBreakpoints, which you can customize. Microsoft documents the defaults for tablet and web apps as [600, 900, 1200], and its own example uses it directly:
// A control's Visible property: show only from "Medium" up
Parent.Size >= ScreenSize.Medium
Inside a container, Parent is the container, not the screen — so reference the screen by name instead (for example HomeScreen.Size).
If you want your own thresholds, define them as named formulas in the App object's Formulas property (named formulas belong there, not in OnStart):
// App.Formulas
nfBreakpoint = If(App.Width < 640, "sm", App.Width < 1024, "md", "lg");
nfIsMobile = App.Width < 640;
A named formula is declarative: it updates when the values it depends on change, and App.Width changes as the window is resized. A Set() in OnStart runs once at startup and doesn't follow a resize. Resize a published app once to confirm it behaves that way in yours. (The 640 and 1024 above are illustrative, and they assume a tablet/web-format app — apps created in phone format use different default breakpoints, so check your own app's format.)
Then drive layout properties from the formula:
// A container's Direction (LayoutDirection in the formula bar): a two-column section
// that stacks on phones. Pick the values from the formula bar's suggestions if your
// Studio version names them differently.
If(nfIsMobile, LayoutDirection.Vertical, LayoutDirection.Horizontal)
// Sidebar container's Visible property: hidden on phones, shown from "md" up
nfBreakpoint <> "sm"
// Container padding: tighter on phones, wider elsewhere
// (set PaddingLeft and PaddingRight, or whichever sides you use)
If(nfIsMobile, 16, 40)
A context variable set once in Screen.OnVisible is the wrong tool here: it doesn't recalculate, so it won't follow a later window resize or a rotation.
Wrap
Horizontal and vertical containers both have a Wrap property. With wrap on, children that don't fit flow onto the next row (or column), which turns a container of fixed-width cards into a responsive card grid without positioning formulas:
Horizontal container (Wrap: on, Gap: 16, flexible height, vertical overflow: scroll)
├─ Card 1 (fixed 320)
├─ Card 2 (fixed 320)
├─ Card 3 (fixed 320)
└─ ...
Give the wrapping container flexible height and vertical scrolling — Microsoft's own wrapping recipe does the same — otherwise the wrapped rows can be clipped when the window is narrow. With 320-wide cards and a 16 gap, a row holds four cards once the container's inner width (its width minus padding) reaches 1,328 px (4 × 320 + 3 × 16), three from 992 px and two from 656 px; below that, expect one card per row. Those thresholds are derived from the sizes above, not figures from Microsoft's documentation. One documented limitation: when Wrap is on, the Align setting of the child controls is ignored.
Limits worth knowing
Spacing lives on the container. Use the container's Gap for spacing between children and its padding (PaddingTop, PaddingRight, PaddingBottom, PaddingLeft) for inset. Invisible spacer rectangles make layouts fragile.
Not every control works inside layout containers. Microsoft's known-issues list for auto-layout containers says that, at the time of writing, Data table, Charts and Add picture aren't supported inside them. Separately, the reference page for the Container control lists its own limitations: containers don't work within forms, and Data table, PDF viewer and Web barcode scanner aren't supported inside it. Check both pages before you design a screen around one of those controls.
Alignment edge cases. Besides Wrap ignoring the children's Align, Microsoft notes that Center or End justification combined with scrolling can leave children unreachable.
Galleries are sized like any other child of a layout container. To let a gallery take the remaining space, give it flexible height with Fill portions rather than a fixed height, and let the container own the size. Don't confuse this with the Flexible height gallery type, which is about items of variable height, and check the exact property names in your version of Studio.
Nest only as deep as the layout needs. Containers can be nested; each extra level is one more container to reason about when something doesn't resize as you expect.
A shorter checklist version of this — the settings, the container setup and the breakpoint pattern — is in the responsive containers guide.
Start from a working skeleton
Starting a responsive screen from a blank canvas is slow, and a reusable starting point removes much of that cost. Since Power Apps supports YAML copy-paste, a screen layout is a text snippet you can keep in a repo and paste into the tree view.
PowerBlocks has three free layout skeletons — a dashboard, a list/browse screen and a master-detail screen. To be precise about what they are: they're manual-layout containers whose X, Y, Width and Height are formulas based on the parent's size (mostly Parent.Width, some Parent.Height), mixed with a few fixed values — you paste them and fill each region with your own controls. They are not built on auto-layout containers or Fill portions, so the Direction, Gap and Wrap properties described above don't apply to them, and they don't ship with breakpoint formulas. To add one, drive each region's X, Y, Width, Height (and Visible) from a named formula such as nfIsMobile; the comments inside the YAML suggest setting a context variable in Screen.OnVisible, but as explained above a named formula is the better tool. Or rebuild the skeleton with auto-layout containers and use the pattern in this article — build it once, save the YAML, and never start a responsive screen from zero again.
Wrap-up
- Turn off Scale to fit (Lock aspect ratio switches off with it; Lock orientation is separate) and reference
App.Width, not pixels. - Structure screens as nested horizontal/vertical containers.
- Fixed sizes for chrome, flexible sizes with Fill portions for content, Stretch on the cross axis.
- Set minimum sizes deliberately: per-child
LayoutMinWidth/LayoutMinHeight, per-appMinScreenWidth/MinScreenHeight. - Use
Screen.Size/App.SizeBreakpoints, or named formulas inApp.Formulas, for breakpoints — not a one-time variable. - Wrap gives you card grids without positioning formulas.
- Check Microsoft's known-issues and limitations pages for unsupported controls before committing to a layout.
Are you building canvas apps with containers, or still on fixed X/Y? If something specific keeps you away from containers, tell me in the comments.
