Your 25 MB Power Apps Screen Contains 430 Lines of Real Work

What actually takes up space inside a canvas app, measured byte by byte.

---

Everyone who has worked on a large canvas app knows the feeling. The editor gets sluggish. Publishing takes a minute. Opening the app in Studio means staring at a spinner long enough to check your email. The usual advice is “you have too many controls” — which is true but useless, because nobody tells you why controls are expensive.

So we took a real production app apart and measured it.

The app is a training-and-requests portal: 7 screens, 994 controls, built by a customer, exported in February 2026. Nothing synthetic, nothing pathological. A normal business app that a normal team would call “getting a bit big.”

Here is what is inside it.

The headline numbers

Measure	Value
Packed .msapp on disk	3.15 MB
Controls/ folder, uncompressed	48.8 MB
Controls	994
Persisted property formulas	29,196
Formulas a human actually wrote	838 (2.9%)
Bytes spent on control template metadata	33.4 MB (68.5%)

Read that fourth row again. Of 29,196 property formulas stored in this app, 838 were authored by a person. The other 28,358 are defaults that the serializer wrote down anyway.

And it gets more extreme per screen.

Screen by screen

File	Screen	Size	Controls	Formulas	Human-authored	Template metadata
1.json	App	0.02 MB	2	14	2	3.3%
4.json	Welcome	0.47 MB	21	562	29	48.4%
25.json	CreateNewRequest	1.56 MB	38	915	44	74.0%
63.json	MyRequests	3.54 MB	76	2,046	57	74.6%
139.json	CreateNewRequestItemSummit	24.91 MB	495	15,199	430	67.4%
634.json	CreateNewRequestLogBook	5.55 MB	111	3,156	87	68.9%
745.json	CreateNewRequestTruVault	12.39 MB	244	7,187	185	68.3%
989.json	Screen1	0.33 MB	7	117	4	90.4%

One screen is 24.91 MB. It holds 495 controls nested up to 9 levels deep. It stores 15,199 property formulas. 430 of them are real.

That is the title of this post, and it is not a rhetorical flourish. It is a RuleProviderType field:

{
  "Property": "Height",
  "Category": "Design",
  "InvariantScript": "40",
  "RuleProviderType": "Unknown"
}

Every persisted property carries this marker. "User" means a human typed it. "Unknown" means the platform filled it in. On the big screen: 430 User, 14,769 Unknown.

Where the 25 MB actually goes

If you break a screen file down by field, one field dominates:

Field	Size	Share
Template	16.80 MB	86.5%
Rules (the formulas)	1.69 MB	8.7%
DynamicProperties	0.55 MB	2.8%
ControlPropertyState	0.32 MB	1.6%
everything else combined	~0.05 MB	0.3%

Template is the control’s own definition — its property list, defaults, metadata, manifest. And it is stored on every single control instance.

Not by reference. By value. In full.

Deduplicate those template blobs and 16.80 MB collapses to 552 KB of unique content. A 31× redundancy factor inside a single file.

The part that surprised us: modern controls are the problem

Here is the same screen, grouped by which template each control inlines:

Template	Instances	Bytes each	Total
PowerApps_CoreControls_TextCanvas	120	71,393	8.17 MB
PowerApps_CoreControls_TextInputCanvas	56	79,670	4.25 MB
PowerApps_CoreControls_ComboboxCanvas	24	84,056	1.92 MB
PowerApps_CoreControls_ButtonCanvas	13	81,699	1.01 MB
PowerApps_CoreControls_DatePickerCanvas	10	81,780	0.78 MB
PowerApps_CoreControls_DropdownCanvas	8	62,363	0.48 MB
PowerApps_CoreControls_TabList	1	53,283	0.05 MB
PowerApps_CoreControls_CheckboxCanvas	1	47,921	0.05 MB
groupContainer	212	318	0.06 MB
attachments	12	312	0.00 MB
htmlViewer	8	310	0.00 MB
icon	4	298	0.00 MB
label	1	300	0.00 MB

Look at the two ends of that table.

Classic controls store a 300-byte stub. 212 group containers cost 60 KB in total, because each one just records a template name and version and resolves the real definition from References/Templates.json — one shared copy per app.

Modern controls inline the entire manifest, per instance. One TextCanvas costs 71 KB. A hundred and twenty of them cost 8.17 MB. The definition is byte-identical every time.

So the practical rule is inverted from what you would guess: 212 classic containers are cheaper than 2 modern text labels. The modern control set is a real usability improvement, and it is also a 200×-per-instance storage regression against the classic controls it replaces.

Microsoft already built the fix, and you may already be running it

After measuring the app above we took apart a second, larger one — 6 screens, 1,609 controls, saved August 2026 — and found something that changes the conclusion.

It contains two generations of modern controls, side by side:

Generation	Naming	How the template is stored	Cost per instance
gen 2	PowerApps_CoreControls_TextCanvas	inlined into every instance	71,393 bytes
gen 3	modernText	shared once in References/Templates.json	~300 bytes

Gen 3 is a return to the shared-template model the classic controls always used. Same control, ~240× cheaper to store.

Across that app:

	Instances	Template bytes
gen 2 (PowerApps_CoreControls_*)	524	34.33 MB
gen 3 (modern*)	59	0.02 MB

266 TextCanvas controls cost 18.11 MB. The modernText template that replaces them is 8,300 bytes, stored once. Migrating the four control types that currently have a gen-3 equivalent would remove roughly 29 MB of that app’s 34 MB of template metadata.

The app already contains both — 266 TextCanvas next to 15 modernText, 112 TextInputCanvas next to 6 modernTextInput. It is mid-migration, and nothing in the product says so.

So far only four controls have a gen-3 version: modernText, modernTextInput, modernCombobox, modernDatePicker. Three are feature-gated (enabledForFeatureGate="Controls.ModernTextInputControl" and friends). There is no gen-3 button, checkbox, toggle, dropdown, or tab list yet.

Two practical consequences. Where a control offers a modern* equivalent, using it is worth two orders of magnitude in stored bytes. And if your app is large and slow, check whether it is carrying gen-2 controls that now have a gen-3 replacement — that is a mechanical win nobody is advertising.

One caution: the migration is not free. Property names change (FontColor → Color, FontSize → Size), TabIndex and Tooltip disappear, and on the text input the read/write Value splits into Default and Text. In that app, 94 formulas set .Value and another 187 read it from other controls — 281 edits for one control type.

The second app, by the numbers

Measure	First app (Feb 2026)	Second app (Aug 2026)
Screens	7	6
Controls	994	1,609
Controls/ uncompressed	48.8 MB	64.6 MB
Largest single screen	24.91 MB	35.07 MB (895 controls)
Persisted formulas	29,196	54,463
Human-authored	838 (2.9%)	1,364 (2.5%)
DeserializationLoadTime	2.27 s	3.15 s
AnalysisLoadTime	5.54 s	12.31 s

15.5 seconds of parse-plus-analyse before the editor draws anything, and 97.5% of what it is analysing is boilerplate the platform wrote itself. One screen holds 895 controls and 31,551 stored formulas, of which 705 are real.

The trend is the point: both apps land near 97% machine-authored, and the cost scales with the total, not with the part anyone wrote.

The app knows it is slow

Canvas apps record their own performance in Properties.json. This app’s last save:

"DeserializationLoadTime": 2.2710907,
"AnalysisLoadTime":        5.5444732,
"ParserErrorCount":        1,
"BindingErrorCount":       97

7.8 seconds before the editor can show you anything: 2.3 s to parse the JSON, 5.5 s to analyse the formula graph. Plus 97 binding errors the team has been living with.

That AnalysisLoadTime is the one that scales badly. Analysis walks the dependency graph across all 29,196 formulas — and the platform has no way to know that only 838 of them matter, because it wrote the other 28,358 into the file itself.

The most-stored properties

On the big screen, the top of the leaderboard is exactly what you would expect from unconditional serialization:

Property	Instances stored
Height	495
Width	495
X	494
Y	494
ZIndex	494
DisplayMode	470
BorderColor	460
Fill	445
BorderStyle	437
Visible	428
ContentLanguage	414

495 controls, 495 stored Height values. Every control on the screen has an explicit height persisted, whether or not anyone chose it.

What to do about it

You cannot change the serializer. You can change what you feed it.

1. Split the monster screen. 495 controls on one screen is a 25 MB file and 7.8 s of load work every time it opens. Two screens of 250 halve the parse cost of whichever one you are editing.

2. Count modern controls, not controls. A screen budget of “under 300 controls” is meaningless if 150 of them are TextCanvas. Budget by inlined bytes: ~70–85 KB per modern control, ~300 B per classic one.

3. Reuse containers, not copies. Galleries replicate their template once (replicationLimit=1); 40 hand-copied cards inline 40 full manifests.

4. Fix your binding errors. 97 of them is 97 nodes the analyser cannot resolve cleanly on every load.

5. Stop trusting .msapp size. This app is 3.15 MB packed and 48.8 MB expanded — a 15× ratio, which is precisely what you get when a file is mostly the same bytes repeated. Compression hides the problem from you right up until the editor has to expand it.

6. Prefer modern* controls where they exist. modernText over PowerApps_CoreControls_TextCanvas is a ~240× reduction in stored bytes per instance. Only four have gen-3 versions so far, but those four are the most-used controls in most apps.

The uncomfortable summary: in this app, 97.1% of what the platform persists is boilerplate, and 86.5% of the biggest file is one control definition photocopied 120 times. The 430 formulas that represent actual engineering are buried in it.

The hopeful footnote: Microsoft has already shipped the architectural fix. It is called modernText, it is 300 bytes per instance instead of 71,393, and it is quietly rolling out behind feature gates while most apps keep paying the old price.

---

Methodology

Every figure above comes from a single production .msapp exported 2026-02-16 (DocVersion 1.348, MSAppStructureVersion 2.4.0, DocumentAppType: DesktopOrTablet, 1366×768). An .msapp is a ZIP; unpack it and the numbers are directly countable.

unzip -q app.msapp -d app/
python3 - <<'EOF'
import json, os
for f in sorted(os.listdir('app/Controls'), key=lambda x: int(x.split('.')[0])):
    d = json.load(open(f'app/Controls/{f}')); nodes = []
    def walk(n):
        nodes.append(n)
        for c in n.get('Children', []) or []: walk(c)
    walk(d['TopParent'])
    rules = sum(len(n.get('Rules', []) or []) for n in nodes)
    user  = sum(1 for n in nodes for r in (n.get('Rules', []) or [])
                if r.get('RuleProviderType') == 'User')
    print(f, len(nodes), rules, user,
          f"{os.path.getsize(f'app/Controls/{f}')/1048576:.2f} MB")
EOF

Single-app sample, so treat the ratios as indicative rather than universal — but the mechanisms (per-instance template inlining, unconditional default serialization) are structural, not app-specific.