Flutter apps are convenient but not small, and a bloated download hurts twice: users on slow connections skip it, and you can bump into store size limits. Trimming Flutter app size is mostly about cutting what you don’t ship and building correctly for release.
Why Flutter app size matters
Every Flutter app carries the engine and framework with it, so even a simple app starts heavier than a minimal native one. That baseline is fine. The problem is everything that piles on top during development: oversized images, spare fonts, debug settings and packages added for one small feature.
Size shows up in places you may not watch. People on limited data plans or nearly full phones hesitate before a large download, and they delete large apps first when space runs out. Stores show the download size on the listing, so a heavy app also looks heavy before anyone installs it.
Build for release, split by architecture
A debug build is far larger than release. For Android, building an App Bundle lets the store deliver only the code for each device’s architecture instead of bundling all of them, which alone can roughly halve the download.
In practice that means a few habits:
- Never judge size from a debug build. Measure the release output only.
- Publish to Google Play with
flutter build appbundle, so Play generates optimised downloads per device. Android’s guide to Android App Bundles explains how that delivery works. - If you distribute APK files directly, use
flutter build apk --split-per-abiso each file contains one architecture rather than all of them. - On iOS the App Store also thins the app for each device, so the size a user downloads is smaller than the archive you upload.
Audit assets and dependencies
Bundled images, fonts, and files are often the biggest contributors. Compress images, ship only the font weights you actually use, and remove placeholder assets that crept in during development: a single uncompressed background image can cost more than all your code.
A few specific checks catch most asset bloat:
- Image format and resolution. Export photos as WebP or well-compressed JPEG at the size they are displayed, not straight from the camera or design tool.
- Resolution variants. Every 2.0x and 3.0x variant you add is shipped in the app. Keep them for images that need them, not for everything by default.
- Large or rarely used media. Onboarding videos and big illustrations can often be loaded from the network when needed instead of bundled.
- Fonts. A full font family with every weight and italic is heavy. Bundle the two or three weights the design actually uses.
- The assets folder itself. Declaring a whole folder in
pubspec.yamlships everything in it, including files nobody uses anymore.
Every package adds weight, and it’s easy to pull in a heavy library for one small feature. Review your dependencies and drop the ones you barely use. Then enable code shrinking and obfuscation for release so the build strips unused code from libraries you only partly use.
For the Dart side, building with --obfuscate --split-debug-info=<directory> moves debug symbols out of the app. Keep that directory safe, because you need it to read crash reports later. Release builds also strip unused Material icons from the icon font, as long as icons are referenced as constants.
Measure where the bytes go
Finally, check what’s actually in the build: Flutter’s size analysis tools show where the bytes go, so you can target the real offenders instead of guessing. Release builds, per-architecture delivery, compressed assets, and lean dependencies usually get an app comfortably under the limit.
To run the analysis, build with the --analyze-size flag, for example flutter build apk --analyze-size --target-platform android-arm64. The build prints a summary and writes a file you can open in DevTools to see how much each package and asset contributes. Flutter’s guide to measuring your app’s size covers the iOS side as well.
Run the analysis before and after each change. It keeps you honest about which fixes actually mattered, and it catches the next oversized asset before it ships.
Common mistakes when shrinking a Flutter app
- Comparing a debug build with a release build and assuming something broke.
- Uploading a universal APK when an App Bundle would let the store trim it.
- Deleting a package while another package still depends on it, so nothing gets smaller.
- Losing the split debug info, which makes production crash reports unreadable.
Size is part of the first impression
A lean download is where the user’s experience starts, not where it ends. Budget phones are also the ones that struggle to render smoothly, so check why your Flutter app janks on older Android phones while you have one on your desk.
If the app sits in front of a subscription product, the first session after install decides most of what happens next. Why your SaaS trial-to-paid conversion is stuck covers that stage. Before launch, it is also worth reviewing the authentication mistakes found in small SaaS apps, since mobile apps usually share the same backend.
Size, speed and security are all things I check before a release goes out, and they are part of every mobile app build I take on.
