Are apps getting more bloated?

[figmentPez]

I've got an older Android phone (Moto G 1st-ish generation, a later model from that gen with LTE), and I'm having to delete apps in order to have enough free space to update my existing apps. Are the core Android apps getting more and more bloated, or is there something wrong with my phone?

If I dip much below 700MB free, my phone refuses to update apps. I frequently have to clear my cache in order to get that much free space.

Every app that can be moved to the SD card has been moved. All the pictures and audio that can be moved onto the SD card have been moved there. Every app that can be told to store it's data on the SD card has had that done... and I still had to delete my grocery store coupon apps in order to have enough free space to update my apps last night.

There are bigger apps I could have deleted, but I really don't want to rid myself of Amazon Prime Video or Snapchat (neither of which is significantly larger than it used to be, despite being fairly large apps).

Am I going to have to start thinking about a new phone if I want to keep using all the apps I'm used to? This one is slow, but it still gets great battery life, and that's still not a common feature for the cheap phones I'll have to choose from.

 

[jwhouk]

Noticed the same thing with my Nextbook. I play NHL Supercard, and with each new year the game is taking up more resources and crashing more.

 

[strawman]

Yes, apps are getting bigger. The process android uses to update requires a lot of free space. It needs enough to download it, uncompressed it, and install it before it deletes the old one. Further it doesn’t want to go below a certain amount of free space for a variety of other reasons.

So you could easily need 700mb free to update a 150mb app. And there are a lot of 150mb apps these days, app designers like to assume most people have 16, 32, or 64 GB devices minimum.

The older versions of android were worse about app updates and location too, so you might be hobbled by that as well.

I believe you can get around some of these limitations using sideloading.

But unless there are necessary features in new app updates there’s no reason to update. You might consider just living with the older versions of the apps until it bothers you too much, then free up the space, do all the updates, then waiting a long time before updating again.

Wait another few months and used Samsung S5 phones should be low cost.

 

[PatrThom]

Also an app that is written to work across several generations of OSes and/or devices will probably be larger just because it has so much alternative code to allow that very flexibility.

--Patrick

 

[Eriol]

Also an app that is written to work across several generations of OSes and/or devices will probably be larger just because it has so much alternative code to allow that very flexibility.

--Patrick

I disagree. Code is TINY. It's resources (images, sound, 3D-objects) which are big. Even with workarounds, you wouldn't even notice the difference for code size. Only resources that take up significant space.

 

[PatrThom]

I disagree. Code is TINY. It's resources (images, sound, 3D-objects) which are big. Even with workarounds, you wouldn't even notice the difference for code size. Only resources that take up significant space.

I disagree with your disagreement. All it takes is "we have to make this app both 32 and 64 bit compatible" and you've almost doubled your code size right there. As far as resources go, having to carry asset bundles to support multiple screen sizes, while technically not code still fits my original assertion. I think you may be fixating on my use of the word "code" to mean "only the executable portion" when in fact I was referring to any asset that is part of the app, not merely the executables.

Because if you want to get technical, even though I know a lot of stuff, I'm still just a layman, and will therefore describe things as such.

--Patrick

 

[Eriol]

I disagree. Code is TINY. It's resources (images, sound, 3D-objects) which are big. Even with workarounds, you wouldn't even notice the difference for code size. Only resources that take up significant space.

Dude, my current company's codebase is between 300k and 400k lines (I just did a count), and compiled takes up ~12MB. The SOURCE FILE size uncompressed is less than 15MB.

The apps are bloated because of resources, not because of alternate code paths.[DOUBLEPOST=1510600994,1510600460][/DOUBLEPOST]

"we have to make this app both 32 and 64 bit compatible" and you've almost doubled your code size right there."

Umm, no you don't. You set a define in one spot, and a few alternates here and there as needed (the fewer places the better). If you have to maintain two entire codebases for that, you are completely screwed.

As far as resources go, having to carry asset bundles to support multiple screen sizes, while technically not code still fits my original assertion.

That wouldn't change between many versions of android, just the number of aspect ratios and other things to change per-device. But even then, you shouldn't have an insane number of them to make things work. But I'd target that as the source of the problems most of the time.

I think you may be fixating on my use of the word "code" to mean "only the executable portion" when in fact I was referring to any asset that is part of the app, not merely the executables.

Then use "assets" or "resources." "Code" is something executed and/or compiled. Hell, I don't consider blocks of text to be code either. That's also resources.

Because if you want to get technical, even though I know a lot of stuff, I'm still just a layman, and will therefore describe things as such.

Take my word on it as a Professional working with code all the time: bloat isn't from code, it's assets/resources being duplicated and organized in a crappy way, not 32/64 bit, or alternative code paths for different Android versions. That's a trivial amount of difference. The only applications where code size matters is in embedded stuff where you have 4k of ROM and that's ALL, but that really doesn't happen anymore with how cheap memory/storage is these days. That's more "history of computing" stuff for 99.99% of software.


Sorry for "bringing the hammer" down on this one so hard Patrick, but it's a mistaken impression that "gets" to me every once in a while. You just happened to put that assertion out here.

 

[PatrThom]

Sorry for "bringing the hammer" down on this one so hard Patrick, but it's a mistaken impression that "gets" to me every once in a while. You just happened to put that assertion out here.

It's one thing to "bring the hammer," and quite another to educate. If it's indeed as you say, then it should be easy to explain with, "That's a common misconception, and here's why" rather than just saying, "WRONG!" especially for a subject where you're so steeped in it that it might be obvious for you, but not so much for anyone else. And I freely admit this is something I'm not perfect about, either.

--Patrick

 

[strawman]

I suspect the discussion is getting a wee bit technical. The primary issue is the final app size, the apk for Android, the ipa for iOS. This includes resources and assets, and while some code bases are straightforward enough that supporting a variety of devices doesn't incur a penalty, there are far too many apps where it does.

 

[Eriol]

I suspect the discussion is getting a wee bit technical. The primary issue is the final app size, the apk for Android, the ipa for iOS. This includes resources and assets, and while some code bases are straightforward enough that supporting a variety of devices doesn't incur a penalty, there are far too many apps where it does.

One cause of this is "resource rot" over time. The best way I have to illustrate that is the "Hot Coffee" mod for GTA that had all the controversy. People wondered why it was still "in the game files" even if it was disabled? The short answer is this: it's safer. It's often difficult to analyze your product to tell what resources CAN be removed, and/or aren't needed. Thus if you have a lot (thousands, or more) of resources, disabling access to them is better than removing them, as it's always possible "somewhere" in the codebase that they're still used by another section. More advanced analysis (and testing) tools can help with this, but there's always the "feeling" that something is going to break because you pulled something out. Safer to just leave everything in, then you can't get a "missing asset" problem anywhere.

I think this type of practice is at least part of the problem with modern app bloat.

 

[SpecialKO]

Lay-person here, but a developer I spoke to blamed it on ad-platform SDKs as well. Since every ad platform uses their own, and a lot of developers work with a bunch of ad platforms to avoid having undelivered impressions, an app can come with a whole mess of advertising SDKs loaded up front, including bundles that include plug-ins for other operating systems and assets (for branded ad layouts).

 

[Tinwhistler]

Take my word on it as a Professional working with code all the time: bloat isn't from code, it's assets/resources being duplicated and organized in a crappy way, not 32/64 bit, or alternative code paths for different Android versions.

I'll agree with this. We have a phone app that we wrote in Cordova and use PhoneGap Build to make executables for (since one codebase will translate to both android and ios in a single build pass). Old version of PGB let us get away with making one icon and one splash screen, and the code would resize as needed. After an upgrade in the Phonegap CLI to be more in line with apple specs, we were forced to provide a different icon file for every possible IOS device. Our compiled code went from 700k to 2 megs. Just from icons and splash screens.

 

[jwhouk]

A question - how the heck do you load an app onto a SD card instead of the main memory?

 

[Tinwhistler]

A question - how the heck do you load an app onto a SD card instead of the main memory?

https://www.howtogeek.com/114667/ho...y-default-move-almost-any-app-to-the-sd-card/

 

[figmentPez]

A question - how the heck do you load an app onto a SD card instead of the main memory?

Depends on the version of Android. I think they stopped this on recent versions, and instead you can add an SD card to main storage somehow. I'm not really sure since I haven't done it myself, and they may have stopped allowing even that (since most SD cards are a lot slower than the flash memory used in phones).

I'm on Android 5.1 (Lollipop) and in this version you can find this tab in Settings -> Apps -> On SD Card:

You'll note that Amazon Music has moved itself off of the SD card. For some reason on my phone it likes to move apps to main memory when they're updated, and I have to tell it to put them back on the SD card. I don't know if this is something I messed up when trying to get apps to install directly to the SD card, or if that's just how things work.

Anyway, tap on an entry for more info:

And there's a "Move to SD card" button.

But that button only does so much:

Only certain apps can be moved to the SD card (and no Google apps) and then only so much. Apparently Snapchat doesn't allow any of it's data to be moved to the SD card, and when it's app is entirely in main memory it's ~160MB, I think, so it gains about 20MB in the process of spreading itself across two volumes.

Different programs have different levels of efficiency at this. I've had some games transfer nearly everything to the SD card, and other programs that barely move anything over.

 

[jwhouk]

I don't have that option on my version of Lollipop :-(