The install-conversion tax hiding in your SDK stack

Nobody decides to lose installs on purpose. But every time your team adds an analytics SDK, a new ad network mediation layer, or a crash-reporting tool, your app gets a little bigger — and app size has a measured, direct relationship with how many people who reach your install button actually tap it.

The number Google already measured

Google's own engineering data on this is specific: a 6MB increase in served APK size costs roughly a 1% decrease in install rate. That sounds small until you count how many separate SDKs a typical mobile game runs — attribution, analytics, ads, crash reporting, A/B testing, push notifications, sometimes two or three of these stacked because a past integration was never cleaned up. Each one adds real weight on its own, and none of them show up as a line item anyone reviews together.

iOS has a harder cliff. Apps that cross Apple's 200MB over-the-air cellular download threshold saw install rates drop 66% — not a gradual slope, a real wall. A player on cellular data who hits that threshold is prompted to wait for Wi-Fi, and most of them don't come back to finish the install. If your build is creeping toward that line, the next SDK you add isn't a 1% tax, it's the one that pushes you over a cliff you didn't know was there.

Why nobody's tracking the total

This isn't a case of studios ignoring a known cost. It's that the cost is genuinely invisible under normal review. A pull request that adds an SDK gets reviewed for what it does — does the crash reporting work, does the new ad network integrate cleanly — not for what it costs in install conversion three steps removed from the change. Size isn't a bug. It doesn't throw an error. It just quietly erodes a number that lives on a different dashboard, owned by a different team, checked on a different cadence.

The result is a stack that accumulates weight the way a garage accumulates boxes: each addition seemed reasonable at the time, and the total is only visible once you finally measure it. A studio that's been shipping for two or three years, adding a mediation network here and an experimentation SDK there, is very often surprised by how much size has crept in without a single decision that, on its own, looked wrong.

Where the weight actually comes from

Ad, analytics, and multiplayer SDKs are the usual heavy contributors, and it's rarely the SDK's core logic that's the problem — it's the dependencies each one drags in. A mediation SDK that bundles support for a dozen ad networks you're not even using still ships the code for all of them unless you're explicitly trimming unused adapters. Analytics SDKs that ship their own networking stack instead of using the platform's native one duplicate functionality your app already has elsewhere. None of this is a single studio's mistake — it's the default behavior of most third-party SDKs, which are built to work everywhere out of the box rather than to be lean for your specific integration.

Making the running total visible

The fix that emerged in 2026 tooling isn't a one-time cleanup, it's ongoing visibility. Size-monitoring products like Sentry's Size Analysis and Emerge Tools — already in use at companies like Tinder, Spotify, and Square — exist specifically to catch size regressions the same way an automated build check catches a failing test: automatically, on every build, before the change ships rather than after a quarterly audit finds it.

That's the actual fix worth adopting even if you don't buy a specific tool: treat app size as a metric with an owner and a budget, checked on every release, not as something someone eyeballs once a year when a store listing complaint prompts a look. A size budget doesn't mean freezing the app at its current weight forever — it means every SDK addition gets weighed against what it costs, the same way you'd weigh a new feature against its engineering time.

What to actually do about it

Start with an audit of what's currently in the build and why. It's common to find SDKs from an integration nobody remembers approving, or two tools doing overlapping jobs because a migration was never finished. Removing dead weight is the cheapest win available and it costs nothing but the review time.

For SDKs you're keeping, check whether you're pulling in the full package or a subset. Most major ad mediation and analytics providers ship a lean-integration path specifically because size complaints from studios pushed them to build one — it's worth asking your SDK provider directly whether a smaller footprint exists before assuming the full install is mandatory.

And before your next SDK integration, put the size cost in the same conversation as the feature benefit. "This adds 4MB and gets us better crash reporting" is a decision someone can actually make with the tradeoff in front of them. A silent 4MB addition that nobody weighed against anything is how a two-year-old app ends up at the 200MB cliff without a single person having decided to put it there. If you're already instrumenting install and conversion funnels through your analytics dashboard, app size is worth adding as a tracked input next to the numbers you're already watching — it's one of the few conversion levers that's entirely inside your own team's control.