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.
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.
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.
Great subject for discussion: "Why?". Too bad that everything following your subject was a useless rant.
All the better to spy on you with...
-
There are effectively 3 asset sizes on iOS and one of them is more or less depricated at that point unless you want to support really old phones for some reason. Screens and layouts are done by compositing those assets and using constraints to figure out where things go so you don't need more of those... and even if you did there are only a handful of actual screen sizes in the iOS ecosystem. The SE, the 6/7 and 6/7 plus, iPad, iPad pro 10" and ipad pro 12".
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Our "hello world" programs were a couple of megabytes. Geeze!
1995 called and wants it's anti-C++ rant back.
The problem isn't the programming language. The problem is that everybody forgot how to write a string to the console with a single OS function call instead of installing a 500Mb "framework" just to call that same function for them.
No sig today...
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.
Nice irony
I've experienced the same thing where the instructor wanted everything to be an object
Making everything an object is good - when you're writing a program with 1,000,000 lines of code.
YOUR failure is in confusing "Hello, world" with real programming.
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?"
I'd like to see you write a maintainable 1,000,000 lines of code in assembly language.
C++ is currently the best balance of most programming worlds and isn't as 'bloated' as 1990s C programmers love to claim. One of the mantras of C++ design was "you don't pay for what you don't use!"
Mr. Assembly Language needs to sit down and disassemble some C++ code, methinks. He might learn something.
No sig today...
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.
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.
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.
Someone want to comment on code analysis here?
It's not code, it's data.
To satisfy all the different screen resolutions of iPhones you're app is likely to run on you need to include all your graphic assets in about 5 different resolutions. Keep going it you want to handle iPads as well. Most developers bundle all of those assets in the .ipa they upload to iTunes, so users will get far more than they need for their particular device. Nowadays iTunes is able to break the .ipa files up to device-specific code bundles but they don't (AFAIK) do the same for graphic assets. I wish they did.
The last iOS app I was involved in had just a core set of graphic assets bundled in the .ipa and then the app would download device-specific levels and graphic assets to the user's Documents folder when it was first run. It meant they'd have to wait for a few seconds to a minute on first run, or after an update, but on the up side they wouldn't have to download GBs worth of things they didn't need.