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?
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.
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?)
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.
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.
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.
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?
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.
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.
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.
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.
It would be interesting to see the chart of size of the org working on the app next to the size of the app itself. I suspect they are highly correlated.
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'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.
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.
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.
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%”.
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.
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.
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?)
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.
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.)
> 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.
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.
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.
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.
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.
It may be a clue that netflix "only" ramped up by 5x while the others are in the 10x-20x range. I'm guessing (as I don't use FB) that netflix's app requires much less user interface design.
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.
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.
Around the same time was the 64-bit requirement for app updates. This resulted in a dual-slice fat binary. Began being enforced in June 2015 I think, so about 2 years ago.
> Why? There are two big factors at play, and both are tied to moves by Apple itself. First, the iPhone maker has been raising the cap on the size of apps, most recently lifting the maximum to 4GB in early 2015. Secondly, the phones themselves are also coming with more memory, increasing consumer's willingness to put up with bigger apps.
Saying "there's more space and apps can be bigger" is not an explanation for _why_ the apps are bigger.
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.
>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.
> 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.
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
118 comments
[ 3.6 ms ] story [ 181 ms ] threadNo, the fault here is purely with the developers.
http://blog.timac.org/?p=1707
HN discussion: https://news.ycombinator.com/item?id=14082491
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.
Also feels a lot like adware bloat...
https://arstechnica.com/apple/2015/06/app-thinning-will-be-a...
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.
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.
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.
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.
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 doubt the total installed size of the FB app is very high on their list of concerns.
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%”.
(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?)
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 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.)
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.
Saying "there's more space and apps can be bigger" is not an explanation for _why_ the apps are bigger.
Double memory in your new computer? Great! Let's use it all up!
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.
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.
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.
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.
https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
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.
It used to be small and lean, and suddenly -bam- 10x bigger over night.
Anyone have any insights?
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.
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.
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.
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.
https://news.ycombinator.com/item?id=14207752
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.
Is compression not the first step of basically every encryption algorithm ever?
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 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.