What a Flutter app actually weighs

There is no shortage of writing about Flutter app size and very little of it has numbers in it. We ship six Flutter apps, all built by the same people against the same pinned SDK version, so we can do the thing the articles skip: put them side by side and see what actually moves the figure. It is not the framework.

The six, as the App Store reports them

Every number below is what Apple prints in the Information section of the product page, read on 6 September 2026. That is deliberately not our build output: it is the figure a person sees before deciding to install, it is what Apple decided to publish after thinning, and it is the only one a reader can check without our source code. All six are listed together on our developer page.

The gap, and what is in it

Derived: the largest is 4.3 times the smallest, a difference of 65.3 MB. Even the smallest of the five is 45.7 MB heavier than Community Stress First Aid. The five average 78.4 MB, which is 58.5 MB above the odd one out.

None of that is Flutter. Community Stress First Aid is a Flutter app, on the same pinned 3.44.0, with a hundred Dart files behind it and the same iOS runner as the rest. What it does not have is a block of dependencies that every other app on the list carries:

• firebase_core, firebase_analytics, firebase_auth and firebase_crashlytics
• cloud_firestore
• google_mobile_ads
• hive_ce, for the local coin and score storage

The five that carry it are 65.6 MB to 85.2 MB. The one that does not is 19.9 MB. It shares the rest of its dependency list with the others — dio, in_app_review, path_provider, share_plus, url_launcher — so the shared part is not what separates them.

What we are not claiming. We have not isolated those packages one at a time, so we cannot tell you what Crashlytics costs on its own or how much of the block is AdMob. That would need seven builds per app and we have not done them. The honest statement is narrower and still useful: across six apps built the same way, that block and the download size move together, and nothing else in the dependency lists does.

Why the five are not identical either

There is a 19.6 MB spread inside the group that carries the block, and it lines up loosely with what each app adds on top. Step and Earn, the largest, is the only one with health for HealthKit. Play and Earn and Taco Rain both pull in the flame game engine, and Taco Rain adds flame_audio on top of it — yet Taco Rain is the smallest of the five, which is the one result on this page we cannot explain from the dependency lists alone. We are publishing it unexplained rather than inventing a reason, the same way the rest of this site handles a figure that does not resolve.

The same game, in a browser

While building the playable web version of Taco Rain we measured the same source compiled for a third target, which makes a useful comparison because only the platform changed.

• 65.6 MB as an App Store download.
• About 5 MB over the wire in a browser, compressed — the Dart bundle is 4.37 MB raw and 1.00 MB brotli, the rendering engine is 1.35 MB to 1.88 MB brotli depending on which variant the browser takes, and the game’s own art and audio are 2.1 MB.

That is a thirteenfold difference and it is almost entirely composition rather than efficiency. The browser build has no Firebase and no ad SDK, because neither has a working web implementation, and it ships no engine binary of its own because the browser is the engine. It is the same source producing a much smaller artifact by leaving out most of what made the phone build large — which is the same finding as the table above, arriving from a different direction.

The SDK pin, and what it cost us

Seventeen of our twenty-seven pubspec files pin the framework exactly, flutter: 3.44.0, rather than declaring a range. The case for it is reproducibility: a build today and a build in six months resolve the same way, and an upgrade is something somebody decides rather than something that happens.

The cost showed up immediately when we tried to measure. The machine had 3.44.9 installed — a patch release ahead — and every pinned project refused to resolve, with version solving failed and nothing else. That is the pin working exactly as designed, and it is still a real piece of friction: any contributor, any CI runner and any future you needs the exact version present before anything builds. We worked around it by spawning the pinned SDK explicitly rather than by loosening the pin, because loosening it to take one measurement would have defeated the point of having it.

How to repeat this on your own apps

Nothing here needed a profiler. Open your own App Store listings and read the Size row on each, then diff the dependency lists of your largest and smallest app. If one of them lacks an analytics or advertising SDK, you already have the comparison, and it will be more honest than any benchmark, because it is your code and your users’ download.

The reason to bother is that app size is one of the few engineering numbers with a direct commercial consequence, and it is usually discussed without evidence. On our apps the framework was not the problem, and neither was the game engine. It was the four Firebase packages and the ad SDK — every one of which we chose, and most of which we would choose again. Knowing what they cost is not an argument against them. It is just the number.