Live data from Hacker News

App sizes are out of control

trevore.com

61–70 of 455 posts

Re: App sizes are out of control

#61

Pretty soon these will start to hit Apple's limit on downloads over cellular (something I still can't believe exists in 2017).

You're typing from a first world country where there are not huge cellular costs or speed limitations. If you go to other countries, even say, Botswana, the option to download over a gig in apps every (other) week isn't cheap. Bandwidth costs.

As a Canadian, to get 2.5 GB of data from a larger cell phone company costs me over $100 / month (there are smaller companies that will reduce that, but still, it's little data for quite a bit of money). I'm very happy I can force things to download only over WiFi.

Re: App sizes are out of control

#62
Most of the time it's the same reason why web pages are MBs in size today: lazy developers that uses a new library for every feature they need, without a deeper analysis of costs and benefits.

Re: App sizes are out of control

#63
post #26

I never understand where this increasing size comes from. For videos or hi-res photographs, I understand. There is however no reason that code, either compiled to a binary format or in a textual format, uses so much data. Heck, the memoirs of Casanova spans 3000 pages, and is 6,5 MB. People don't understand how incredibly large a megabyte is for simple code. Surely the 275 MB isn't all useful data (I wonder what comp…

Could it be that whenever coders today need some fairly trivial functionality, they tend to go out and find a library that contains it. So you end up with lots and lots of libraries where only a tiny bits of them are used. Just a hypothesis though.

This would be true if the entirety of the library was used by the application. Wouldn't the linker throw out anything unused?

Re: App sizes are out of control

#65

Earlier quoted context omitted.

You're right - there should be minimal (if any) size bloat because of the use of browsers on iOS. You're not allowed to include your own browser, and can only use the platform's web view, which is not duplicated on a per-app basis. There are many culprits for app bloat, but using a browser is most certainly not one of them.

I'm sincerely curious what would be the worst offenders for app bloat.

It varies, but for most apps I'd wager it's library bloat, but in my experience doing iOS dev here are the common culprits:

- For games assets are a big issue. Some do not compress their assets, and unfortunately most image-authoring tools make it easy to output PNGs that are much larger than they can be. I think a lot of people by default assume bloat comes from images/icons/etc, but IMO this is a red herring for most non-game apps.

- Library bloat. Even simple apps pull in a large number of external dependencies, which contribute dramatically to app bloat. There's also a lot of code pulled in that replicate platform-provided functionality (see: the bajillions of layout libraries out there), which may be simpler to use than the stock Apple components, but add to your bundle size.

One of the common problems is that iOS open source dependencies are typically all-or-nothing - you end up pulling in a very large library even if you're only using a small slice of its functionality.

I think most disassemblies of iOS app bundles show that library bloat is typically a far larger problem than asset bloat.

In any case, I think the future will be something like Android Instant Apps - where apps are sliced up such that necessary bits can be downloaded on-demand. This gets users into apps faster, and saves space.

Re: App sizes are out of control

#67
The Phillips Sonicare Kids app, which is nothing more than a simple game for kids to track brushing their teeth, is 245MB.

I guess the good thing is that it gave me an opportunity to teach my kid about tradeoffs. "Ok, so if you really want this app, we're gonna have to delete 4 of your other games on the iPad." Even a 5 year old could reason his way out of that one.

Re: App sizes are out of control

#68
post #29
post #26

Earlier quoted context omitted.

Could it be that whenever coders today need some fairly trivial functionality, they tend to go out and find a library that contains it. So you end up with lots and lots of libraries where only a tiny bits of them are used. Just a hypothesis though.

I'm pretty sure this is part of it. Remember leftpad? For electron based apps they're just bundling all of chrome which explains the size too.

Leftpad is not an example of the issue mentioned. Leftpad is an example of a small module that was being used by a lot of projects. GPP is talking about pulling in larger libraries which contain code not actually used by the app.

(Also Electron bundles 'just the rendering library from Chromium' [1], not 'all of Chrome').

[1] https://electron.atom.io/docs/tutorial/about/#core-philosoph...

Re: App sizes are out of control

#69

Short a major customer outcry, Apple is largely incentivized to not fix this— (1) They substantial profits from memory upsells on their product lines (2) Larger apps take more horsepower to run— so older models become less effective sooner!

But if Android apps are smaller and faster, people will switch over to Android.

Re: App sizes are out of control

#70
post #52

Earlier quoted context omitted.

I think this is likely the biggest culprit. Another user pointed out an analysis of the Facebook app: http://blog.timac.org/?p=1707 Most of it is actual code - not assets. For some types of apps (see: games) assets do take up a significant portion of total size, but for most everyday apps bloat by code over-inclusion is likely a bigger problem than asset-bloat. I wonder if it's possible to get major open-source libs…

> I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality. Fwiw, this is already a trend in JavaScript land. Libraries are moving towards many small packages so you can import only the parts you need either manually or using a tool…

I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy).

What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link time not build time -- otherwise you still have the same problem).

Post reply on HN