Apps are getting bigger — developers are loading them up with images, fonts, video, SDKs and more. But you don’t often hear about the impact of app size on installs and usage.
Apps are getting bigger. In the intense competition for consumer attention, developers have loaded their apps up with images, fonts, video, SDKs, and more. The benefits of all of these are well-documented, but you don’t often hear about the impact of app size on installs and usage. Larger apps tend to be slower to load, more likely to crash and, overall, create a worse experience for the user. This can be the difference between customers actually using an app, burying it deep on their phones, or worse, deleting it.
The trend towards bulkier apps started in 2013, when Apple increased its over-air download limit to 100MB — any apps bigger than that can only be downloaded when the device connected to Wi-Fi. Since then, apps have only gotten bigger. In 2012, the average iOS app used to be 23MB for non-gaming apps and 60MB for games, while today the average size of the Top 500 apps in Apple’s App Store is 73MB.
The dreaded 100MB effect
At Segment, we help thousands of businesses connect, translate, and activate their customer data, building products that make developers and marketers lives’ easier. We work with more than 3,000 mobile apps, which have been downloaded more than 500 million times, and have our own set of mobile SDKs that offer developers a simple way to collect their analytics data. In short, I spend a lot of time thinking about, analyzing, and testing mobile app performance.
I’ve heard from customers and other mobile developers that install rates fall significantly when your app size reaches 100MB. In fact, a general manager at a large mobile company told me recently that he’s dedicating the next six months to reducing bloat in his apps to stay below the 100 MB threshold while they develop new features.
It certainly makes sense that crossing 100MB creates more friction, but our engineering and product teams wanted to understand the impact of incremental increases in app size on installs and usage. Does app size alone reduce installs? And if so, how big is the effect? We spent the past couple of months conducting an experiment into these issues. Here are the results.
We bought an app … and bloated it
First, we needed a test subject. We planned to buy a small app with no active marketing activities, but significant and steady download numbers. Then we’d increase the app’s size, leaving everything else constant, and observe the impact on the app’s install rate. This would simulate the impact of app bloat on downloads.
So we bought the Mortgage Calculator Free iOS app. It was a minuscule 3MB, with a steady pattern of organic installs (about 50 installs per day for several years) and no active marketing activities. It was the perfect test case.
Over the course of the experiment, we increased the app size from 3MB to 99MB, 123MB and 150MB. We kept everything else constant to observe the isolated impact on install rate with each change in app size.
App sizes can increase substantially with the addition of seemingly simple things, like an explainer video, a bunch of fonts, an SDK or a background picture for your loading screen. For the purposes of our experiment, we bloated our app with a ton of hidden Taylor Swift album art.
To measure the impact of each successive bloating, we looked at data provided directly by Apple in iTunes Analytics. We specifically tracked conversion from “Product Page Views” to “App Units,” better known as “installs” to ”install rate.”
… then lost 66 percent of our installs
We saw substantial losses in product-page-to-app-install rate with the larger app sizes. In particular, there was a substantial drop around the cellular download limit (~100MB). If the app is above this size, the user needs to be connected to Wi-Fi to install the app, which is just enough friction to have a big effect.
Here are the results we saw for our app at 3MB, 99MB, 123MB and 150MB. Note that the conversion rate can be greater than 100 percent due to installs direct from search results that skip the product page view.
From these results, we estimate a linear change in install conversion rate below the 100MB cutoff of -0.45 percent install rate per MB. Above the 100MB cutoff, we estimate a linear change in install rate of -0.32 percent per MB. To our best estimate, the gap between the two lines is covered by a 10 percent instantaneous install rate drop across the cellular download limit.
Although Apple says the cellular download limit is 100MB, we found in practice that a 101MB IPA did not trigger the cellular download block. The actual limit was somewhere between 101MB and 123MB, and varied depending on the exact build.
Increasing the size of our app from 3MB to 99MB reduced installs by 43 percent, and the increase to 150MB reduced installs by 66 percent in total.
How to destroy an app
We then tried to replicate the experiment by returning the app to its original 3MB size (plus other intermediate sizes) and re-measuring the install rate. Unfortunately, as a result of our earlier bloating, the app attracted several critical ratings and reviews, which stick around forever:
In our measurements, the app’s growth appears to be semi-permanently damaged. We saw a minor rebound, from 44 percent to 59 percent install conversion rate, for the 16 days the 3MB version was available. (Note that these customers cite 140MB and 181MB as the download sizes — the true download size varies depending on the customer’s device and OS version.)
What makes an app big?
The experiment proved to us that app bloat is a problem with potentially grave consequences. So, what can developers do to make sure their apps are as slim as possible while still being performant?
We looked at what adds bulk to apps. We randomly chose to inspect the NBC Sports app that was featured on the App Store during the Olympic games. The app is 90.5MB. Images are by far the biggest contributor — they are 51 percent of the entire app’s size, with code (23 percent), fonts (16 percent) and video (9 percent) accounting for most of the rest.
Images were both in the raw app package and in the asset catalog (hidden away inside assets.car). There are huge numbers of local station and team logos, startup screens and soccer field layouts.
We found there’s quite a bit of low-hanging fruit in optimizing an app’s size. There are about a dozen SDKs within the “code” category, which is a single encrypted file. We could detect and estimate the size of a handful of these. We found that SDKs contributed roughly 3.5MB to the total app size, with an estimated impact of -1.54 percent install rate.
Today’s mobile market conditions require that developers add images, features, experiences and analytics to apps, but it also requires a ruthless focus on efficiency and user experience. To help developers out, we built an App Size Calculator that shows how large your app is, how it compares to other popular apps, and how to slim it down. Even minor issues with app performance can cost you users, and you might never get them back. When trying to design amazing app experiences, ask yourself if every addition is critical.
Peter Reinhardt is the co-founder and CEO of Segment, a customer data platform that developers and analysts love because of its elegant APIs and extensive partner ecosystem. Reinhardt studied aerospace engineering at MIT, and started Segment in 2011 with three college friends to help businesses connect, translate and activate their customer data. Backed by Y Combinator, Accel, and Thrive Capital, Segment has more than 8,000 customers and 200 partners. Prior to starting Segment, Reinhardt was a research assistant at the Naval Postgraduate School, where he wrote and designed flight software for the NPS-SCAT Cubesat, a platform which tests solar cells while they’re in orbit. He blogs at rein.pk; reach him @reinpk.