The top iPhone apps are taking up a lot more space(axios.com)
axios.com
The top iPhone apps are taking up a lot more space
https://www.axios.com/ios-app-size-increase-apple-apps-iphone-2445288877.html?utm_source=newsletter&utm_medium=email&utm_campaign=newsletter_axioslogin&stream=top-stories
118 comments
>Saying "there's more space and apps can be bigger" is not an explanation for _why_ the apps are bigger.
Sounds like a great explanation. Apps tend to fill up to take all available disk space, and we've known that since 1981 or so. Every time computers got more disk/memory, apps grew in size. Back in the day you could fit most apps in a single 360K floppy disk or two.
Sounds like a great explanation. Apps tend to fill up to take all available disk space, and we've known that since 1981 or so. Every time computers got more disk/memory, apps grew in size. Back in the day you could fit most apps in a single 360K floppy disk or two.
> Apps tend to fill up to take all available disk space
Basically this. It's not just software, either. "Stuff takes up the available time / space available" is about as broadly applicable of an axiom as any I can think of.
Basically this. It's not just software, either. "Stuff takes up the available time / space available" is about as broadly applicable of an axiom as any I can think of.
How is it not? It doesn't seem reasonable to you to model the expected size of an app as a function with the size of the phone on which the app will be installed as one of the inputs and the function's first derivative w.r.t. the phone size being always positive?
It's not like it's the only factor but of course it would play some role. If you accept a higher size then all sorts of benefits follow. You can make the assets higher res, hold more of their data locally, just take less development time optimizing the app.
It's not like it's the only factor but of course it would play some role. If you accept a higher size then all sorts of benefits follow. You can make the assets higher res, hold more of their data locally, just take less development time optimizing the app.
> Saying "there's more space and apps can be bigger" is not an explanation for _why_ the apps are bigger.
In large multi-app companies it leads to product decisions on bundling vs. shipping separate apps. For example, Uber vs. UberEATS.
The latter would probably benefit from being bundled in the former and having immediate access to a wider audience, but it's asset-rich as it's much more visual.
In large multi-app companies it leads to product decisions on bundling vs. shipping separate apps. For example, Uber vs. UberEATS.
The latter would probably benefit from being bundled in the former and having immediate access to a wider audience, but it's asset-rich as it's much more visual.
Devs spend less time on making them smaller?
That was the logic for desktop apps in the 90s.
Double memory in your new computer? Great! Let's use it all up!
Double memory in your new computer? Great! Let's use it all up!
Memory or storage? I hate when these terms get used interchangeably.
Somebody posted a breakdown of Facebook.app earlier this year. Looks like a lot of duplicated assets in there (too many developers / teams working on different parts of the app?)
http://blog.timac.org/?p=1707
HN discussion: https://news.ycombinator.com/item?id=14082491
http://blog.timac.org/?p=1707
HN discussion: https://news.ycombinator.com/item?id=14082491
From what I understand the FB app is bloated because it's shipped with all experimental features that are toggled on/off with flags by all the teams that are working on the app. So yeah, that adds up.
And because nobody will uninstall the Facebook app because of that.
I did. Too much space consumption plus notification spam got me to delete it from my device. I'd get rid of Messenger, too, if it weren't so central to my social life.
I did
Facebook used to throttle devices once a week to make devs dogfood bandwidth in developing nations--I think it's much more top of mind there than we give them credit for.
I don't think Facebook forces them to download new versions that day. Because responsiveness is clearly more top of mind with them than download time/cost.
As a developer, I only use my app on 64kbps speeds.
At those speeds, the only webpages still working are a few blogs and HN, and the only apps still working are whatsapp, some special irc apps optimized for that such as quasseldroid or irccloud, some reddit readers, and, if you have a lot of time, imgur.
Most of these also have app sizes in the kilobytes to single digit megabytes, making downloading possible within of a few minutes on 64kbps (essentially dialup).
Those speeds are basically guaranteed anywhere in the solar system, and if your app works with that, it basically works everywhere.
At those speeds, the only webpages still working are a few blogs and HN, and the only apps still working are whatsapp, some special irc apps optimized for that such as quasseldroid or irccloud, some reddit readers, and, if you have a lot of time, imgur.
Most of these also have app sizes in the kilobytes to single digit megabytes, making downloading possible within of a few minutes on 64kbps (essentially dialup).
Those speeds are basically guaranteed anywhere in the solar system, and if your app works with that, it basically works everywhere.
The dark side of version pinning - many slightly different copies of the same thing.
Swift is a big part of the app binary size bloat. It creates about 3-4x the amount of binary for about the same lines of code count as objective-c. Generic specialization happens everywhere in swift and using optionals takes a lot more ASM instructions than you would think it does. Swift also adds about 5-20MB of standard libraries for each app that uses it. Extensions like maps or watch apps also take a few MB each.
Also apple makes decisions like encrypting binaries and then compressing, removing a lot of over the air space savings. They don't give free apps the option to just sign their apps and not encrypt them for smaller IPA sizes.
I wouldn't be surprised if a similar decision was made in the xcode toolchain that caused a similar issue.
Also apple makes decisions like encrypting binaries and then compressing, removing a lot of over the air space savings. They don't give free apps the option to just sign their apps and not encrypt them for smaller IPA sizes.
I wouldn't be surprised if a similar decision was made in the xcode toolchain that caused a similar issue.
It's not Swift. App sizes are mostly increased by graphic assets, and libraries. Here is a 15,000 line swift app that compiles to 11 megs.
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
I'm skeptical Swift creates significantly larger binaries, let alone 3x-4x, but I'd still use it if so. Using optionals and stronger typing is makes it easier to write correct code, and anyway we can save users from wild pointer crashes is super valuable. Far more valuable than the cost of a couple megabytes of code in an ocean of PNGs and Cocoapods.
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
I'm skeptical Swift creates significantly larger binaries, let alone 3x-4x, but I'd still use it if so. Using optionals and stronger typing is makes it easier to write correct code, and anyway we can save users from wild pointer crashes is super valuable. Far more valuable than the cost of a couple megabytes of code in an ocean of PNGs and Cocoapods.
Yeah, Swift should only contribute a small, constant amount to account for the runtime and standard library. 3-4x doesn't make sense.
Go decompile using an optional or an array, or interfacing with an Obj-C lib, you'll be surprised how much ASM is generated.
You'll also be surprised how much stuff is reduced in swift 4. Swift is still in beta, lots of low hanging fruit to improve still.
You'll also be surprised how much stuff is reduced in swift 4. Swift is still in beta, lots of low hanging fruit to improve still.
[deleted]
Actually, use of large value types in Swift can cause significant binary bloat.
https://news.ycombinator.com/item?id=14207752
https://news.ycombinator.com/item?id=14207752
That same app written in 17kloc of objective c code would be significantly smaller. The reason why it's small is because it just doesn't have a lot of code. Most these fat apps have already done all the other easy crap specified in the article. The author knows that all the other apps are at least 500kloc of code minimum, he worked at twitter.
All other things being equal, a swift app is much larger. The article also is just talking about binary sizes, not about all the other graphical assets.
All other things being equal, a swift app is much larger. The article also is just talking about binary sizes, not about all the other graphical assets.
I recall reading at one point that apps written in Swift statically bundle the entire set of libraries, whereas Objective C apps use shared libraries from the operating system. Something about Swift not having yet reached the level of maturity to warrant the use of stable shared libs. If and when Swift switches to supporting shared libs, app sizes should shrink.
> Also apple makes decisions like encrypting binaries and then compressing, removing a lot of over the air space savings.
Is compression not the first step of basically every encryption algorithm ever?
Is compression not the first step of basically every encryption algorithm ever?
Not for apple fairplay DRM. :/ It's pretty obvious, you'll see how much the binary compresses to when you build on your machine vs what you download from the store and compare the sizes.
Oh, well that sucks. :/ I haven't done any iOS dev yet, I guess Android doesn't have the monopoly on stupid though.
2GB is 1.5% of the storage for a mid-range (128GB) late-2016 iPhone; or 6% of the storage for the lowest-end (32GB) iPhone SE.
Any decent product team – which I assume these apps have – is tracking this, and is continuously setting direction for the tradeoffs among space optimization, speed optimization, bandwidth optimization, battery life, usability, stability, server costs, feature velocity, and probably a half dozen other factors.
The implication of some of the comments here is that they've been making these tradeoffs incorrectly. I'd be interested to hear more about the reasoning behind this conclusion.
Any decent product team – which I assume these apps have – is tracking this, and is continuously setting direction for the tradeoffs among space optimization, speed optimization, bandwidth optimization, battery life, usability, stability, server costs, feature velocity, and probably a half dozen other factors.
The implication of some of the comments here is that they've been making these tradeoffs incorrectly. I'd be interested to hear more about the reasoning behind this conclusion.
Individual rank-and-file employees don't get promoted for not building features. So there's an inherent incentive for the app size to grow, whether or not that code is useful to 99% of its install base.
Between writing a single line that includes a 100 MB library and writing a hundred lines that include just the code needed; many people will pick the former. Just look at usage of GPUImage or other libraries.
Between writing a single line that includes a 100 MB library and writing a hundred lines that include just the code needed; many people will pick the former. Just look at usage of GPUImage or other libraries.
I'd be shocked if they were making those tradeoffs correctly. The people making the decisions are not paying all of the costs, and they'll naturally favor saving only the costs they pay directly.
Not exactly. If e.g. an app using more space antagonizes users to the point of not using it, any competent PM would mitigate that.
Latency definitely antagonizes users to the point of reducing use, and from what I can tell very few tech company PMs are “competent” at keeping latency of their apps/websites down, when faced with competing pressures like shipping new features, rearranging everything in the UI, switching front-end rendering strategy, gathering increasing amounts of invasive analytic data, or cramming more ads in.
Certainly not the ones at Facebook, Google, etc. Nobody gets promoted for “we shipped less new features but our latency remained constant”, or “we shipped less new features but reduced device battery use by 10%”.
Certainly not the ones at Facebook, Google, etc. Nobody gets promoted for “we shipped less new features but our latency remained constant”, or “we shipped less new features but reduced device battery use by 10%”.
This is probably true for your "average" app, but how many people are gonna uninstall Facebook (the #1 app, according to TFA) just because it's taking up a little more space?
I doubt the total installed size of the FB app is very high on their list of concerns.
I doubt the total installed size of the FB app is very high on their list of concerns.
Especially since space is fungible, so deleting 300MB of other apps will have the same effect. Facebook's wastefulness here could be causing users to abandon other apps.
Sure, but there's no particular reason that cost would line up with the cost of additional storage they're imposing on their users.
> Any decent product team – which I assume these apps have – is tracking this, and is continuously setting direction for the tradeoffs
Key word right there. One criterion you didn't explicitly list: development time.
Pruning and deduplicating dependencies takes time and effort that could be spent elsewhere - e.g. all the criteria you listed - and so the question becomes, what benefit is there to improving that? There's an argument to be made for onboarding, of course, but between the prevalence of WiFi and the proportion of users with the app installed to those installing it, I suspect it's tough to make.
Key word right there. One criterion you didn't explicitly list: development time.
Pruning and deduplicating dependencies takes time and effort that could be spent elsewhere - e.g. all the criteria you listed - and so the question becomes, what benefit is there to improving that? There's an argument to be made for onboarding, of course, but between the prevalence of WiFi and the proportion of users with the app installed to those installing it, I suspect it's tough to make.
Actually, he explicitly called out "feature velocity" as a factor.
I'm not sure if Facebook is making the tradeoffs correctly. But both my wife and I removed it from our phones and just use the browser and are very happy with the decision.
Eight gb phones were the doorbuster deals in 2016, they're not that old, or rare.
from when a 128GB iphone is mid-range? i paid around 700 euro for iPhone 6 16GB and is still damn good. what is not good is a stupid app taking 2GB.
I guess you don't get many pictures or constantly offloads them. sure 16gb model is fine for standard usage plus maybe a handful apps, but hd videos eat lot of space.
Why would anyone not offload pictures and videos taken off their phone?
To be able to see and show them everywhere without having to download them.
OK, sure. I'd count that as local caching---ie still offload as soon as possible, but keep the local copy for as long as you have space. Though aren't connections in the developed world fast enough that you can just download/stream them on-demand?
(For lots of pictures and videos, you can keep a lower quality version on the device as a compromise---but not sure whether Google Photos or Apple does that by default?)
(For lots of pictures and videos, you can keep a lower quality version on the device as a compromise---but not sure whether Google Photos or Apple does that by default?)
Though aren't connections in the developed world fast enough that you can just download/stream them on-demand?
The problem isn't so much the speed but the caps, if you're not on Wifi. I don't know anyone who has more than 5GB/month, and HD video will eat that in less than an hour.
The problem isn't so much the speed but the caps, if you're not on Wifi. I don't know anyone who has more than 5GB/month, and HD video will eat that in less than an hour.
I'm on a nominally unlimited pay-as-you-go plan in the UK for about 25 GBP a month. I regularly do 20+ GB over 4g a month.
The UK isn't ahead of the rest of the world here, is it? (Google paid for my mobile data in the last few years before that, so I am out on the loop on general prices.)
The UK isn't ahead of the rest of the world here, is it? (Google paid for my mobile data in the last few years before that, so I am out on the loop on general prices.)
yes and I used to do that when pictures didn't count towards your icloud storage cap, but then got fucked by Apple change of policy
On the other hand, the iPhone5s is still current and will be getting iOS11 later this year, and the base model has ~12GB usable storage out of the box, and 2GB is a sizable chunk of those 12GB.
Cellular data plans have caps. Usually relatively small ones. Download 10 100MB apps—the maximum size for an app downloaded over a cell connection—and you've blown a 1GB data plan.
I'm not sure if a 5c user would get that 2gb app or an optimized version. But if the question is tradeoffs, and that 2gb number holds that is 1/8 and 1/4 of the 8gb and 16gb phone. Also, iirc I only had ~5gb after the OS and apple preinstalled software. >40% is not a possible or sustainable portion of storage. Worst case they get dropped, best case intermittently installed and deleted.
The thing is having your app be 200 MB is not actually a big issue in the real world. So why do space optimization? Time is limited and there's always other things to be worked on.
It is if it can only be downloaded on WiFi -- I see that as a big motivating factor to keep your app below 50 or 100mb (whatever the Cellular data limit is).
My team was discussing the embarrassment of customers not being able to download our app in our own stores. Plus there is actual real world data showing smaller apps are downloaded more.
Just ordered an iPhone 7 with 32GB, to go to 128GB is another £100.
As an outsider looking in - it appears app developers have decided that operating system integration is not desirable. I have heard various reasons for this ranging from; "We can do it better" to "Allowing users to escape your app significantly reduces interaction time".
As a consequence, major app developers seem to be shipping a lot of things which used to be integration points. Half of Android apps seem to ship their own browsers now.
These are the functionalities which used to be operating system integration points which I have seen largely replaced by applications (even if they are designed to look identical):
- Web browsing
- Camera interfacing / image processing
- Type/Swipe/text input
- Dictionaries / spellcheck
On top of that, most large app developers seem to be shipping their own run-time environments that appear to be designed to bridge cross-compatibility gaps across operating systems and operating system versions. Until some of those targets are truly end-of-life'd the number of graceful feature fall-backs and work-arounds will likely keep growing.
As a consequence, major app developers seem to be shipping a lot of things which used to be integration points. Half of Android apps seem to ship their own browsers now.
These are the functionalities which used to be operating system integration points which I have seen largely replaced by applications (even if they are designed to look identical):
- Web browsing
- Camera interfacing / image processing
- Type/Swipe/text input
- Dictionaries / spellcheck
On top of that, most large app developers seem to be shipping their own run-time environments that appear to be designed to bridge cross-compatibility gaps across operating systems and operating system versions. Until some of those targets are truly end-of-life'd the number of graceful feature fall-backs and work-arounds will likely keep growing.
I don't see this on iOS, for example web browsing is required to be done with a UIWebview from iOS.
Or better, SFSarfariViewController, which ensures user privacy by being sandboxed off from the app, supports content blockers, and provides all the standard system sharing options instead of trying to pigeonhole users into a subset of highly tracked "desirable" sharing options.
I personally make a point to avoid apps that opt to use a UIWebView over an SFSafariViewController. The reasons for doing so are rarely in my best interest as a user.
I personally make a point to avoid apps that opt to use a UIWebView over an SFSafariViewController. The reasons for doing so are rarely in my best interest as a user.
Right. My point was you have to use a iOS class for web browsing to pass store review.
I think that's exactly what he is describing. Line and Messenger now open all links in a crappy in app web view instead of opening the browser app like they used to.
It looks like all of these apps had a notable bump in size at about the same time. I'm wondering what happened at that point to cause this.
One effect two years ago was 3x retina images for first iPhone 6 Plus, roughly doubled size of all asset catalogs. With app slicing the 3x aren't usually downloaded to most devices, but that's not clear to customers.
Probably due to the release of Xcode 8.3, which creates binaries 3x the size of those created by Xcode 8.2.1. https://news.ycombinator.com/item?id=13991851
That bug was fixed one week later in Xcode 8.3.1 and the app store rejects apps built with 8.3.0.
Sounds like a 80/20 rule. They initially got 80% of the features with 20% of the code/digital assets.
Also feels a lot like adware bloat...
Also feels a lot like adware bloat...
I can only imagine that developers are adding assets for all the variations of Apple devices now, with retina everything. But that still shouldn't add up to hundreds of megabytes, should it?
iOS 9 was supposed to fix this asset bloat, with "app thinning".
https://arstechnica.com/apple/2015/06/app-thinning-will-be-a...
https://arstechnica.com/apple/2015/06/app-thinning-will-be-a...
Yep, makes a big impact:
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
The problem in my book is being caused by AB tests and low incentives for pruning dead code aggressively.
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
The problem in my book is being caused by AB tests and low incentives for pruning dead code aggressively.
App thinning works and works well if you use it.
Is there any way to tell if these apps are using it? On the one hand, big tech companies should definitely be taking advantage of this capability.
On the other hand, it's possible that their procedures for releasing new versions — which they do very frequently - don't work as well with whatever the app thinning procedures are.
Also, if their apps are super popular, these companies have somewhat less incentive to keep their apps small. If you need the uber app, you'll delete something else to make room.
On the other hand, it's possible that their procedures for releasing new versions — which they do very frequently - don't work as well with whatever the app thinning procedures are.
Also, if their apps are super popular, these companies have somewhat less incentive to keep their apps small. If you need the uber app, you'll delete something else to make room.
The problem is the download size doesn't match the store size, but customers can't see that. They also have differential updates, but again customer can't see that.
Huh, interesting. I got a banner message in the uber app yesterday saying I'll need to update soon. I declined to do so over cellular because of the apparent size of the app. Glad to know that's just the worst-case scenario, not the likely download size.
I wonder how Apple could efficiently display the relevant download size to users based on device type and previously-downloaded version. I would imagine this would not be easy to do quickly and accurately, but most users would probably be happy just have a rough estimate of what the actual download size would be.
I wonder how Apple could efficiently display the relevant download size to users based on device type and previously-downloaded version. I would imagine this would not be easy to do quickly and accurately, but most users would probably be happy just have a rough estimate of what the actual download size would be.
I’m pretty confident that a lot of this is basically because of AB tests.
Even in a top app like Facebook it can take many months to hit statistical significance on a new feature test. If the numbers on that test are down (I.e it’s not moving in the right direction) they don’t just give up on it, they iterate and try again.
Add to this NUXs, not being diligent about deleting unused code and you have a receipe for a phat app.
Even in a top app like Facebook it can take many months to hit statistical significance on a new feature test. If the numbers on that test are down (I.e it’s not moving in the right direction) they don’t just give up on it, they iterate and try again.
Add to this NUXs, not being diligent about deleting unused code and you have a receipe for a phat app.
I broke my 64GB iPhone 6 that and recently switched to a friend's old 16GB 6 Plus and it has been super eye-opening to do the "what do I really need on here?" dance.
I've switched to a web apps for what I can, which has helped, but it's a little bonkers for some apps. Pages, Numbers, and Keynote need 1.3GB - almost 12% of the 10.93GB of available free space on the phone.
I've switched to a web apps for what I can, which has helped, but it's a little bonkers for some apps. Pages, Numbers, and Keynote need 1.3GB - almost 12% of the 10.93GB of available free space on the phone.
I don't know much about Apple stuff, but do they allow you to upload different versions for each type of device DPI etc?
You can't upload different application bundles for different devices, but you can put your assets into an asset catalogue with different versions for each screen density / device type. Then when it's deployed to the end-user, Apple only includes the assets for that specific device.
App thinning allows you to target different devices with sets of assets.
Article doesn't mention the bitcode bloat caused by Xcode 8.3. https://news.ycombinator.com/item?id=13991851
Because that was fixed in 8.3.1
Can anyone provide some insight as to what happened to gmail? It seemed to be around the 15MB range then had a huge spike.
It was probably all "pure" Objective-C development then someone decided to cut dev costs by bringing in some huge monolithic library that does everything from which they use 5% of the APIs.
Based on things that I've heard at work from our mobile engineers, iOS apps written in Swift compile to larger binary sizes than what they saw with Obj-C. Anyone have any numbers they can share for comparison?
Swift adds a few megs but you can minimize that impact by doing things like this guy did:
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
Swift size difference is almost unnoticeable. What is noticeable is writing more correct code to produce higher quality apps.
I'd wager a guess that the weight is coming from machine learning models.
Do any major vendors run ML models on mobile devices vs just shipping the datasets to their GPU-stuffed data centers?
That would seem consistent with Netflix being on the lowest tier.
That's why I've stopped updating my apps. I just wait for the next major release. It's utterly pointless to me right now.
[deleted]
More bandwidth too. Bandwidth was why I removed FB and that's not update bandwidth which I do over WIFI.
The resolution of the devices have been going up. 2D assets get bigger in memory.
I miss phones that had micro SD card slots. Space doesn't matter so much when you can just plug more in.
Planned obsolescence?
That doesn't make sense. Apple is telling app developers to make their apps bigger? Even after introducing things like app thinning and differential downloads to great fanfare?
No, the fault here is purely with the developers.
No, the fault here is purely with the developers.
I agree; seems to me that Apple would want developers to keep apps smaller so that users can install more of them in the same amount of space / on the same (e.g. 64 GB) device.
Saying "there's more space and apps can be bigger" is not an explanation for _why_ the apps are bigger.