Slashdot Mirror
The Size of iPhone's Top Apps Has Increased by 1,000% in Four Years (sensortower.com)
Research firm Sensor Tower shares an analysis: As the minimum storage capacity of iPhone continues to increase -- it sits at 32 GB today on the iPhone 7, double the the iPhone 5S's 16 GB circa 2013 -- it's not surprising that the size of apps themselves is getting larger. In fact, Apple raised the app size cap from 2 GB to 4 GB in early 2015. What's surprising is how much faster they're increasing in size compared to device storage itself. According to Sensor Tower's analysis of App Intelligence, the total space required by the top 10 most installed U.S. iPhone apps has grown from 164 MB in May 2013 to about 1.8 GB last month, an 11x or approximately 1,000 percent increase in just four years. [...] Of the top 10 most popular U.S. iPhone apps, the minimum growth we saw in app size since May 2013 was 6x for both Spotify and Facebook's Messenger. As the chart above shows, other apps, especially Snapchat, have grown considerably more. In fact, Snapchat is more than 50 times larger than it was four years ago, clocking in at 203 MB versus just 4 MB at the start of the period we looked at. It's not the largest app among the top 10, however. That distinction goes to Facebook, which, at 388 MB, is 12 times larger than it was in May 2013 when it occupied 32 MB. It grew by about 100 MB in one update during September of last year.
perfecting art of bloatware and spyware.
Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
That could explain why my iPad 2 is getting sluggish over time.
We will always use all the space and time we have.
“He’s not deformed, he’s just drunk!”
I recently found myself in my new phone without a ride hailing app. Turns out Uber was too big to download OTA, but Lyft was not.
Someone want to comment on code analysis here?
Curious to see just how lazy, sloppy, or 'liberal', memory use, and data is being used in code.
Is it because folks are switching to Swift? I'm assuming that the frameworks and libraries it uses as well as XCode are part of the problem.
And many developers have this fetish for going apeshit with the OOP paradigm - much of that is to be blamed on academia. When I was forced to take a C++ class for a pre-req (the department didn't care that I had years of on the job experience), I was aghast at what the prof of was teaching. He didn't want to hear different - "In my class we do it my way!" Whatever. Our "hello world" programs were a couple of megabytes. Geeze!
Those who know do; those who don't know teach.
I feel like the OS manufacturers (Apple and Google) are doing this on purpose to make people's phones obsolete - especially the lower end models.
Google force feeds you updates of their core apps (Maps, Gmail, Youtube, Play Store, Play Services) which originally were in the ROM (and therefore did not impact you storage) but then eat up your internal storage (these apps, of course, can't be moved to the SD card). Often, if you reject these updates, these apps will just stop working (esp. if you don't update Play Services).
It's like the manufacturers are saying - if you purchased a phone for less than US$200-250 (I'm talking about full price here, unlocked, no contract) then we're just not going to LET YOU to use it more than 2 years...we will bloat the software as to make your phone unusable. The increase on the app limit does the same thing.
If you buy the $600-900 phones, then you might be good for 4 years, 5 if you're lucky.
I used to have more apps on my iPhone 5 SE 64GB.
I just delete them and let them live in the cloud now.
FB - gone.
Look, I don't pay for apps. I already paid for the phone. I don't care why you want me to have an app. I'm not installing it.
Bloat that!
-- Tigger warning: This post may contain tiggers! --
How much did the binaries grow? Because if you added a gigabyte of video to your 300MB app, I just don't care.
Let's see the same comparison with Android phones.
I suspect the issue isn't that iPhone apps are growing at a faster rate than the iPhone's storage options. These top apps are going to be cross-platform ones, not iOS-exclusives. What's more likely happening is app file sizes are trending in line with smartphone storage as a whole. The iPhone is the one not keeping up with everyone else in storage sizes, which is a problem when there's no way for the consumer to upgrade the storage themselves.
Just looking the size of the application is very crude because for all we know they could just be packing in a lot of additional uncompressed data. What really needs to be looked at is how much of it is executable code and how much is wasted on repetitious framework libraries.
Anons need not reply. Questions end with a question mark.
One of the hottest trends in app building these days is to use Javscript frameworks such as React Native (invented by Facebook) or NativeScript. Everyone seems to be jumping on that bandwagon (it isn't necessarily without merit, as it allows developers to create a native UI experience with cross-platform tools, and share code with the web as well).
One of the side-effects of this is a huge javascript dependency graph, with (often) thousands of packages. A simple hello world app written in React Native is probably somewhere near 100MB.
The App Store requires you to support 1,024 different screen sizes, each requiring their own graphic assets. Every time they add 10 more pixels to the device, the size of the app increases by 110% of the original app size.
Yes, yes, I know, "Apple's Walled Garden, blah, blah, blah..." Haters will hate.
But what about Android? As far as this particular metric, I'm gussing it's not exclusive to iDevices...
If you want news from today, you have to come back tomorrow.
Appy app apps are appier than LUDDITE programs, so of course they use more apps! Only LUDDITES wouldn't understand this!
Apps!
What on Earth are they stuffing into their apps to make them balloon in size so quickly?
I remember when my ca. 2013 phone started to run out of space because the fifteen or twenty apps I had installed (including Facebook and Gmail) were taking up much of the half-gig of available storage space. Now I wouldn't be able to fit much more than Facebook in that space.
I certainly don't see 10x the features in Facebook.
'nuff said.
All the better to spy on you with...
-
All those bits are adding up, I can barely carry my phone around any more.
"Sloppy" is imprecise, so you need better metrics. For example, how much use you get out of a given app, divide by its on-disk, in-memory, and bandwidth usage. Even that is subjective. Having a ton of features that you never use is arguably worse than not having the features, though again there are exceptions. Having a "911/112" feature on the old phone is one that you hope to never use but is mighty handy when you suddenly do need it, then the need'll be likely quite urgent indeed. But that doesn't go for all possible features.
So any analysis is going to be hand-wavy, but an app of size N that lets you achieve the exact same thing as an app of size N*10 is arguably objectively better. Less complexity, more use, less room for hidden surprises, and so on. On that note, don't forget the libraries and other dependencies the app sucks in.
But yes, some sort of measuring would be useful here. You'd probably have to define several profiles with different usage patterns and such, but with a suitable set one could do quite a bit of testing and measuring.
So I used to be quite proud of the around 1.5MB size of many of my apps, but with the need to embed the Swift libraries with the app (as opposed to being bundled with the OS) I'm now got 10MB minimum sized apps. I guess when the ABI settles down we won't have to embed anymore.
The problem isn't the programming language.
No one said it was the language's fault. The GP said it was the teacher's fault.
I've experienced the same thing where the instructor wanted everything to be an object and if you didn't use every OOP paradigm in your code, you got points marked off - size and performance be damned!
I have seen C++ programmers make their code so sleek and fast that I questioned their choice of language (those embedded guys! I tell ya!)
And when folks want to get into a pissing contest about their language of choice, I say "let's go down to the assembly and see, shall we?"
What the hell are they packing into these apps that takes up so much space? This is why we need chat apps without all the garbage stickers and fancy emoticon graphics and video filters and all that other garbage. Just give us something that works, is interoperable with everyone, and is rock-solid.
While i don't think the situation is quite as bad on Android, it's still ridiculous. Thankfully I don't install any of those top 10 apps. Unfortunately with more people using web app frameworks like Cordova and such that embed the entire framework within each app, they are continuing to grow in size, unnecessarily.
We desperately ned to get back to web-based applications. The latest web technology covers pretty much every need for a native app that I can think of. Even WebAsembly to run your silly 3D games at native speeds. There is simply no need for native apps anymore. They are boated and need to die.
That post made me very sad.
Instead of "increased by 1000%"
or whatever the correct multiplier is... I'm always off figuring those out.
Like anyone can even know that
The size efficiency of a hello world program as simple as the one you're trying to exhibit depends heavily on which frameworks you use.
Let's take MinGW for example. MinGW is a port of GCC to Windows. The last time I was using it often, its linker used a system DLL implementing the C standard library, but its C++ standard library (iostream and STL) was statically linked. Using any part of iostream caused a couple hundred kilobytes of code to get linked into your executable, even with the -s option to not write debugging symbols.
Similar sizes were found for devkitARM with libgba, a homebrew toolchain targeting the Game Boy Advance. GBA executables can be either "cartridge", which run from ROM, or "multiboot", which run from RAM. Only multiboot executables can run on the GBA Movie Player flash card or on players 2 through 4 of a single-cartridge multiplayer game. And multiboot executables must fit into the 256 KiB of RAM.
We desperately ned to get back to web-based applications. The latest web technology covers pretty much every need for a native app that I can think of.
Others who have posted comments to the article "Chrome To Deprecate PNaCl, Embrace New WebAssembly Standard" disagree with you. The consensus there is that HTML documents ought to be static and applications ought to be native. Web applications should work with script turned off, with interactivity through form submission interacting with server-side logic. Applications too rich for that paradigm should be written with Qt, wxWidgets, or a similar cross-platform framework, and distributed as source code under a free software license, with hobbyists taking care of ports to other platforms.
Wouldn't the median of the top 10 apps' size be more statistically significant?
Unless you're claiming that (almost) everyone installs (almost) all of the top 10 apps, though I didn't see evidence for this.
However, even as an Android user, I've long been aware that the fastest way to save some space is to temporarily (or permanently) uninstall Facebook.
Another good reason to just use the browser and go to the respective websites that way. You also avoid every app knowing all your contacts, birthdays and whatnots that way.
-- Cheers!
And all of these bloated apps need to be updated, which'll go against either your cellular data cap, or your wifi data cap. It's a racket, for sure.