FIELD ANALYSIS · CANVAS APPS & SOURCE CONTROL

Why modern Power Apps controls can make your Canvas App surprisingly large

26 MB screen. 17 MB Git limit. Not a single large image in sight.

I dug into a Canvas App's internal files and found that dozens of modern controls had a surprisingly large effect on the source-control footprint.
Controls/2176.json26.4 MB
17 MB · Git limit
optimise
< 17 MB · targetControls/2176.json
01 · THE ERROR

First, the error itself.

git — powershell
$ git push origin main
remote: pushing to Azure DevOps …
error: Controls/2176.json of CanvasApp(...) is too big to fit in source control.

Azure DevOps itself handles larger files just fine. But the native Power Platform Git integration works with generated per-screen files — and has a much lower practical limit there: around 17 MB.

Our generated screen file Controls/2176.json was 26.4 MB. No commit gets through that.

02 · THE INVESTIGATION

My first suspect: assets.

Large files in a Canvas App? You immediately think of media. So I unpacked the .msapp and walked through the usual suspects.

SVGs?
Images?
One enormous Power Fx formula?
Generated control metadata?

The problem wasn't in what the app shows — but in what Power Apps writes away per control.

03 · MODERN VERSUS CLASSIC

Modern controls look better. They're also bigger.

Two controls, the same job. This is the difference in this app's generated screen files:

Modern TextText@0.0.51
in this app±74 KB
Classic LabelLabel@2.5.1
in this app±7 KB
ControlModern variantClassic / lighter
Text / LabelText@0.0.51±74 KBLabel@2.5.1±7 KB
RadioRadio@0.0.25±62 KBClassic/Radio@2.3.0±8 KB
Text inputTextInput@0.0.54±83 KBClassic/TextInput@2.3.2±9 KB
Date picker±85 KB±9 KB
Empirical measurement from this app — not a Microsoft benchmark.

One container, almost 2 MB

A concrete example from the screen:

14 × modern Text9 × modern Radio2 × modern TextInput1 × modern DatePicker

≈ 2 MB of generated screen file — for one screen section.

04 · WHY DOES THIS HAPPEN?

5 lines of YAML become much more under the hood.

The readable YAML you see in source control is only half the story. Power Apps also writes generated control definitions: metadata, bindings and properties, per control. And modern controls take up considerably more room there than classic controls.

What you see in source control
Control: Text
Text: ="Welkom"
X: =Parent.Width / 2
Y: =Parent.Height / 2
Width: =Parent.Width * 0.5
What Power Apps stores on top
[generated control definition]
[metadata]
[bindings]
[properties]
Controls/2176.json
much larger than the YAML
05 · THE FIX

Different control, same screen.

The same functionality, built lighter — in this app these replacements were enough:

BEFORE
Control: Text@0.0.51
AFTER
Control: Label@2.5.1
BEFORE
Control: Radio@0.0.25
AFTER
Control: Classic/Radio@2.3.0
BEFORE
Control: TextInput@0.0.54
AFTER
Control: Classic/TextInput@2.3.2

The user sees virtually the same thing. The underlying app can be built much lighter.

06 · A PATTERN I KEPT SEEING

Buttons that weren't really buttons.

Another pattern: five modern Buttons in a gallery, doing nothing but displaying data.

Gallery · Template
Control: Button@0.0.45
Appearance: Transparent
OnSelect: (empty)
Text: =ThisItem.Name
ButtonButtonButtonButtonButton
AFTER
LabelLabelLabelLabelLabelone real clickable overlay

These 'buttons' weren't buttons: no OnSelect, no click behaviour. Just text. A classic Label does that job for a fraction of the metadata — and if you do need clickable behaviour somewhere, one real button as an overlay is enough.

07 · PRACTICAL CHECKLIST

When Controls/*.json gets too big, check:

modern Text controls that only display text
modern Buttons without real OnSelect functionality
hidden legacy controls
duplicate component instances
large popups permanently parked on the same screen
repeated UI that could be built with a Gallery
screens that could technically be split up
08 · NUANCE

Modern controls are not 'bad'.

They have their advantages and they're Microsoft's current design direction. The lesson of this analysis isn't 'replace every modern control', but: in large enterprise Canvas Apps, consciously choose which control the functionality really needs.

Use complex controls where their functionality adds value. Use the lightest possible control for simple presentation.

A Canvas App that's slow, too large or inexplicably complex?

Problems like this often sit a layer deeper than the visible Power Fx. I help organisations analyse and restructure existing Canvas Apps.