Does my size report get uploaded?

The raw file never leaves the browser. It is parsed client-side, and only a compact summary — the total, per-category byte counts, up to 120 of the largest items and the mechanical flags — is sent with a run. The page tells you exactly how many nodes were profiled locally and how many items were sent.

Which report formats does Size Lens read?

Three: the *-code-size-analysis_*.json treemap that flutter build --analyze-size writes into build/ (the main one), the App Thinning Size Report.txt that Xcode produces when exporting an IPA with all compatible device variants, and plain text lines of the form path, whitespace, size.

Why does it insist on a release build?

Debug builds include the VM and JIT support and skip AOT compilation and tree-shaking, so their size is meaningless as a shipping estimate. Size Lens flags debug indicators (kernel_blob.bin, JIT artifacts) mechanically and the plan will tell you to re-measure from --release before acting on any number.

What happens when the app genuinely cannot get under the store cap?

The posture says so. When the measured content minus every realistic saving still exceeds the limit, the verdict is oversized and the plan pivots to structural options — deferred components, on-demand model download at first run, App Thinning variants — rather than pretending WebP conversion will save 100 MB. Estimated savings are sanity-checked in the browser against the measured bytes.

What does a run cost, and can I try it without signing in?

The parse and breakdown are free and always run client-side. The audit run is metered: a worst-case amount is reserved before the run and only what the run actually uses is charged, both shown on the meter. Three bundled examples — a bloated consumer app, a lean app, and a fat ML app over the store cap — replay their saved results in full for free without signing in.

Size Lens — paste the Flutter size report, get the shrink plan

The size report

Or pick the file: it is read locally, and the raw report never uploads.

Measured breakdown — free, computed in your browser

#	Item	Size	% of total	Category

What the app is — optional, sharpens the trade-offs

The goal — optional

The audit

Executive summary

Assumptions & open questions

Findings

The plan

Picked	#	Action	Command	Impact	Effort	Risk

Browser cross-check

Summary

Result

How it works

Nothing to hand? Load the — a 57 MB travel app carrying 2 MB onboarding PNGs and a full icon font — the , where the honest answer is that nothing needs fixing, or the , a 239 MB multi-ABI ML app where only structural changes can clear Google Play's limit.

Paste the report — the breakdown is free

Run flutter build apk --analyze-size (or appbundle / ios / macos / windows / linux) and paste the *-code-size-analysis_*.json it writes into build/, or drop the file on the box. Your browser parses it locally — total, category bars, the largest items, and mechanical flags: fat multi-ABI packaging, an un-shaken MaterialIcons font, raster assets over 250 KB, native libraries over 3 MB, heavy Dart packages, store-cap risk, debug-build indicators. The raw file never uploads; App Thinning Size Reports and plain path size lines parse too.

The AI audits — this is the metered part

The model receives the compact measured facts — never the raw file, and the page says exactly how many nodes were profiled locally and how many items were sent — plus your context and goal. It returns severity-ranked findings each citing the measured evidence, a sequenced plan with real commands (--split-debug-info, --tree-shake-icons, --split-per-abi, deferred components, WebP conversion, App Thinning), per-step impact, and a posture: healthy, trim-recommended or oversized. Pricing is honest: a worst-case amount is reserved before the run and only what the run uses is charged — the meter shows both. The browser then cross-checks the plan: claimed savings are compared against the measured bytes and the largest measured items must be addressed or explicitly set aside.

Apply, rebuild, re-audit

Tick the steps you will actually do and the projected total recomputes as you go — if your goal names a number (“under 30 MB”), the page says whether the ticked set reaches it, which steps close the gap, or that the target is out of reach for this plan entirely. Copy the commands one by one or all at once, download the plan as a shell script with every step in order (edits included as commented TODOs), or export it as Markdown, JSON or CSV. Then rebuild with --analyze-size and paste the new report: your audits are saved to your SkillSafe account, so Size Lens shows the delta against your previous run — on your laptop or any other device. That diff loop is what the whole exercise exists for.

A derived work of @flutter/flutter-reducing-app-size, the Flutter team's open-source app-size skill (BSD-3-Clause).