If you've ever stared at your Play Console's download size and wondered where all those megabytes are actually going, you're not alone. App size directly impacts user acquisition — every megabyte you add is a friction point. So when I stumbled across Grab's App Sizer, a tool that promises to break down exactly what's inflating your APK, I was curious. Two years after its creation and still in alpha, here's my honest assessment of whether this repo deserves a spot in your build pipeline.
What It Actually Does
App Sizer isn't just a dumb file size counter. It parses your APK down to the file and class level, then maps those components back to their source AARs and JARs. The result is a breakdown of size contribution by module, library, team, and individual large files. Think of it as a dependency graph for your app's binary weight, not just its dependency tree.
It ships in two forms: a Gradle plugin that integrates directly into your Android build, and a CLI tool for non-Gradle setups. Both feed into the same analysis engine. The recent release (0.2.0-alpha03) added a self-contained HTML dashboard — a single index.html file per device that lets you explore size data interactively without spinning up any server. That's a genuinely useful addition.
Why It Matters
The Android ecosystem has tools for profiling runtime performance, memory usage, and battery drain. But dedicated, structured analysis of download size — the actual bytes a user transfers from the Play Store — is surprisingly underserved. Google Play does provide some size insights, but they're coarse. App Sizer fills a gap by giving you granular, composable data about where your app's weight comes from.
The Grafana and InfluxDB integration is another reason this matters. For teams running CI pipelines, being able to track size regressions over time and visualize them in a dashboard is a game-changer. Size creep is insidious — it happens one library at a time, and without tracking, you won't notice until your users do.
What I Found Compelling
-
The HTML dashboard is a real win. Every analysis now produces a self-contained
index.htmlfile. No server, no setup, just open it in a browser and drill down by component, module, or library. For quick local analysis, this is exactly what I want. -
The Grafana/InfluxDB setup is production-ready. The Docker setup they provide means you can plug this into your CI and start tracking size trends immediately. For teams serious about size budgeting, this is the killer feature.
-
The configuration cache support is a quiet signal of maturity. Recent commits show they replaced execution-based dependency resolution with ArtifactView-based resolution to support Gradle's configuration cache. That's not a flashy feature, but it tells me the maintainer actually uses this in a real build environment and cares about build performance.
-
Dagger removal shows engineering discipline. Dropping kapt and Dagger from their own build infrastructure is a sign that the maintainer isn't just building a tool — they're maintaining a project. Clean builds matter.
-
MIT license with Grab backing. Grab (the ride-hailing company) open-sourced this. That's not the same as a random solo dev — there's institutional support behind it, even if the actual commit history tells a different story.
Who Should Use This
If you're an Android team at any scale that cares about download size — and you should — this tool is worth evaluating. It's particularly useful if you:
- Have a large monolithic app with dozens of modules and need to attribute size to teams
- Track size regressions in CI and want a Grafana dashboard
- Need to identify which libraries are bloating your APK
- Want a local HTML view of your size composition without complex setup
Who Should Skip It
If you're building a small app with a handful of dependencies, the overhead of integrating a Gradle plugin and running analyses might not justify the output. Also, if you need exact byte-level attribution of every class in your Dex files, you'll be disappointed. The README is upfront about this: Dex structure complexity means class-level sizes are approximations. Use it for trends and relative comparisons, not precise measurements.
The Honest Concerns
Let me be direct about the red flags.
First, this is still in alpha. Version 0.2.0-alpha03, two years after creation. That's not necessarily a bad thing — Android tooling moves slowly, and getting the analysis right is hard — but it means the API isn't stable. Don't build critical tooling around this until they hit 1.0.
Second, the community engagement is thin. 210 stars, 12 forks, zero stars gained in the last week. There's one primary maintainer (MinhNguyen-nvm with 43 commits) and two minor contributors. This is essentially a one-person project. If Minh moves on, this repo could stall. That's a real risk when you're depending on open-source infrastructure.
Third, the open issues count is low (5), which could mean the tool is stable enough that people aren't hitting problems — or it could mean nobody's using it enough to generate issues. Given the star count, I'd lean toward the latter.
The Verdict
App Sizer is a solid tool solving a real problem, and the recent HTML dashboard and Grafana integration show the maintainer is still actively improving it. The MIT license and Grab backing give it credibility. But the alpha status, single-maintainer risk, and modest community traction mean I'd recommend it with caveats.
If your team is already struggling with app size and needs granular breakdowns, integrate it into a side project first. Run it on a staging build, look at the reports, see if the data is useful enough to justify the pipeline overhead. If it is, great — you've found a tool that fills a genuine gap. But don't bet your release process on it until it graduates from alpha.
The tool is clearly built by someone who understands the problem space. The question is whether the community will grow enough to keep it alive and evolving. Right now, it's a promising solo project with institutional backing — not quite an ecosystem staple yet.
Repository: github.com/grab/app-sizer