A Flutter app bundle grew past 60 MB right after adding a charts package; how do you find exactly what grew and decide what to cut?

## The situation A release app bundle was comfortably small; after one pull request that added a charting package, it is past 60 MB. Two questions follow: **where** exactly did the bytes go, and **is it real** for users or an artifact of how the bundle is packaged? ## Step 1: build a fair pair of size files A diff only means something if both builds differ in nothing but the change. 1. Check out the commit **before** the charts package. 2. Build: `flutter build appbundle --analyze-size --target-platform android-arm64`. Note the file it reports, for example `~/.flutter-devtools/aab-code-size-analysis_01.json`. 3. Check out the commit **after** the change and run the exact same command. The next file gets the next number. 4. Keep both files; they are cheap and make later questions answerable. ## Step 2: diff them Open DevTools, choose the **app size tool**, go to the **Diff** tab, drop the first file into "old" and the second into "new" and click **Analyze Diff**. The treemap and table now show **only data that differs** between the two builds, so a large new rectangle is your answer. | Where the growth shows | Typical cause | Typical fix | |---|---|---| | Dart code under the package's name and its dependencies | a large Dart library pulled in whole | use less of it, or swap for a lighter package | | Assets | bundled fonts, images or data files | remove or compress what you do not use; check if a lighter asset set exists | | Native libraries | a plugin with a native SDK | check whether the native part is needed at all | ## Step 3: find out why the code is kept Load the **new** file in the **Analysis** tab and open the **dominator tree**. Find the package's node and look at what dominates it: often one screen's import. That tells you whether a single feature pulls in everything, and it is also the seam where a deferred component could be cut. ## Step 4: decide what to cut - **Trim**: many chart packages are modular; importing only the chart types you use can shrink the Dart code. - **Replace**: for two simple line charts, a lighter package or a small custom painter may cost far less than a general-purpose library. - **Defer (Android)**: if charts live behind one analytics screen, move that screen's library into a **deferred component** so the base install excludes it. - **Accept**: if the per-device download grew only a little, the right answer may be to keep it and record the cost. ## Step 5: check what users actually download An upload app bundle contains code for every ABI plus content the store strips before delivery. Before treating "60 MB" as the user-facing number, check the per-device download size in the store's size report. The Diff result tells you the relative growth; the store tells you the absolute cost. ## Keep it from happening again Save a size file as a build artifact on every release branch. Then the next "why did we grow?" is a two-minute diff instead of an archaeology project.