Matt Birchler:
Auto updates only happen when you are connected to Wifi, but iOS won’t stop you from updating on cellular if you tap the update button. The fact that someone could blow through 10% of their monthly data plan (2GB) just by updating Snapchat and Messenger once. This could be tough if you do it once, but Facebook updates Messenger all the time. They’ve updated the app 5 times in the past month, which could work out to upwards of 400-500 MB over just a month.
And:
“App thinning” is not a magic bullet that erases this problem though, as Facebook Messenger, which shows as being 154 MB, still downloaded 99MB of data for its update.
And:
So are giant app sizes a problem? Yes. Do delta updates allow these updates to use less data? Yes. Do delta updates make these large apps a non-issue? Hell no!
And from this Washington Post article, titled It’s not just you: Your iPhone storage isn’t going as far as it used to:
Apple has announced some features that may be able to help with this problem down the line. In iOS 11, due out in the fall, there is a feature that lets you “offload” apps you use less often — deleting the apps themselves from your phone, but retaining enough data so that you don’t have to set them up again.
Screens are getting larger, pixels denser, which means the resources used to support those bigger/denser screens are growing larger. Add to that the steadily increasing complexity of Apple’s SDKs, and it is clear that device storage availability continues to be a tricky balancing act.
But this is “same as it ever was”. Ever since the dawn of the modern computing era, memory and drive size was always a constrained resource and memory and drive sizes grew and software techniques were developed to meet demand with every new generation.
Back in the day, I had a word processing program that ran on my Apple ][+ in 48k of memory and did what 90% of the people using word processors for today. Compare that to the current size of MS Word or Pages and the question becomes, are they large because of the increase in size of SDKs? Or are they larger because programmers are lazy? I suspect, Woz would say the later.
I think it’s a little bit of both but more so lazy developers not taking the time to optimize their apps. Gruber has been digging into this a lot and linked to a few articles, one of which showed how terrible the facebook app was including the same file numerous times in different directories, duplicated image assets etc. that ended up being not insignificant in terms of impact on file size.
Seriously. I remember working at my first design job running Pagemaker on a Mac SE with 4MB of RAM and a 40MB hard drive. With the exception of colors and fonts, those designs are just like what I’m producing today.
Laziness is not quite fair. It’s more a matter of priorities.
In the old days, programmers had to spend a lot of time optimizing for space because they had no choice. When that’s no longer the first priority, binary sizes are going to increase. When you have goals to build out features at the cost of other things, things like binary size are going to suffer.
So that leads to the question of features. The tricky part of the “90%” problem is that different people use different 90%s.
As a concrete example: look at the really angry customers that bitterly complained when Apple rebooted the iWork apps a few years ago with reduced functionality. It’s easy for us to say “too complex!” but the devil’s in the details.
What happens here is that there’s not a single set of folks working on the app, but rather many teams working on different parts of the app, which are often in separate source code subtrees, which in turn all get linked together in a regular release process. Facebook effectively becomes a platform, not just an app.
In such an environment, it takes a ton of work to optimize, and that conflicts with product priorities. Moreover, I’d bet FB spends more cycles doing that on Android, where they have a much wider range of devices, than iOS, where the customer base tends to upgrade more and the devices are higher-end and can handle a bit of bloat.
(I’m not saying it’s good, just trying to give a bit of color as to how these things happen.)
Facebook, etc, have decided that their users’ bandwidth charges are not on their priority list.
Considering the cost most IOS device owners pay for bandwidth, this strikes me as a foolish decision.
Presumably, Facebook has metrics defining whether or not a decision is “foolish.” Chances are, when you download a FB app update, you download not only the app you see but a bunch of code that may or may not be turned on for experiments to further get an idea of what users like and don’t.
Also note that the Facebook app sits just shy of 100MB to get around the iOS download-over-the-air limitation. So that is a forcing function to improve their efficiency as the app does more.
Don’t get me wrong—the app scores <3 on the App Store and is almost definitely bloated—but I’d imagine that score and user convenience is not #1 on the priority list because most people download and install FB because they feel they have to/want to. The only way to get them to think otherwise is to not use the FB app (i.e., affect engagement). That’s what I do, I don’t have Facebook installed on my phone anymore.
This post and most of the comments so far miss the point. It’s less about storage than it is about the impact of updates on download caps. As Birchler notes in the quoted post:
“The [is] fact that someone could blow through 10% of their monthly data plan (2GB) just by updating Snapchat and Messenger once. This could be tough if you do it once, but Facebook updates Messenger all the time. They’ve updated the app 5 times in the past month, which could work out to upwards of 400-500 MB over just a month.”
This is NOT ‘same as it ever was’ when software was updated manually on physical media. It’s a new impact.
That’s a poor excuse though – there are build tools out there to manage this stuff. Scripts can be written. And not every feature developer needs to manage this, just the build engineers.
Sure, it’s a poor excuse. And yet it happens. Again, priorities are often elsewhere.
… I will say that, as someone who’s in such a universe, the build and tooling work to fix dependency spaghettis on large teams is far from trivial, though. We have people working multiple quarters on related problems; the problem is there are also feature teams adding complexity faster than we can clean it up.
i can’t help wondering if having fonts internal to apps and other similar bits is hurting storage. perhaps its time to move that stuff to the iOS level along with language support etc. let us download what we need when we need it. same with things like pages templates etc. opening it up would also mean being able to add things like other templates, fonts etc. I know in iMovie for iOS the templates are way restricted and frankly not that great.