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 the size is mostly about cutting what you don’t ship and building correctly for release.
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.
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.
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.
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.