Live data from Hacker News

App sizes are out of control

trevore.com

281–290 of 455 posts

Re: App sizes are out of control

#281
post #273

Earlier quoted context omitted.

When it only has the functionality of a 20Mb app... it's a problem. When EVERY app does the same thing? It's a problem.

From that perspective, you have a very valid point.

It's really crazy. Overcast (my favorite podcast app) is under 10 MB because Marco cares about things like that.

Here's some of what's listed in the update list on my iPhone:

Chipotle is 92. The kindle app is 171 (perhaps the fonts?). The Amazon app (which is mostly a web view anyway) is 127.

Robocall blocker? 22. Verizon app? 160. An app for tracking streaks of achieving task? 65.

Slack is 123.

Clips? The Apple app for making little movies that includes a fair bit of art? Only 55. That makes sense.

Authy? To show 2-factor codes? 65!

Outside of games (which have a lot of assets) app sizes seem to have absolutely no correlation to what they actually do.

Re: App sizes are out of control

#282
post #279
post #269

Earlier quoted context omitted.

I'm 100% willing to believe this is a universal problem and is just as bad as Android. I'd be FLOORED if Android apps were significantly smaller.

I checked now. LinkedIn: 20.36MB Facebook: 76.59MB Twitter: 25.71MB That's about 1/8th the size of those apps on iOS. Those are just the first three apps in use article, I'm sure the rest are about the same.

Wow.

I wonder why it's so different.

Hopefully someone can chime in with the reason.

Re: App sizes are out of control

#283
post #282
post #279

Earlier quoted context omitted.

I checked now. LinkedIn: 20.36MB Facebook: 76.59MB Twitter: 25.71MB That's about 1/8th the size of those apps on iOS. Those are just the first three apps in use article, I'm sure the rest are about the same.

Wow. I wonder why it's so different. Hopefully someone can chime in with the reason.

Java byte code is generally much smaller than equivalent machine code. If you use something like Multi-OS engine which statically compiles Java bytecode to native code for iOS it's fairly typical to see an order of magnitude difference in binary size.

This actually affects Android 5+ too (Multi-OS engine uses Android's AOT compiler) but since it happens on the device it doesn't affect download sizes.

Re: App sizes are out of control

#284
post #68
post #29

Earlier quoted context omitted.

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...

Sorry for not being specific. As for leftpad I just meant the concept of using libraries when you really don't need to. Not the size.

Re: App sizes are out of control

#285
post #218
post #191

Earlier quoted context omitted.

I'm guessing but it seems logical that phones are not the place you want to do extra graphics rendering if you don't have to.

Modern smartphones have quite competent GPUs. They can run 3D games at 1080p/60fps. They could raymarch circles around an svg icon. And if it wasn't enough, the renderings could be cached for later use.

TBH not many people consider SVG format worth the effort unless the graphic is made from scratch. 1) an organization rarely rationalizes having a UI dev spend 6 something hours either transforming an existing PNG to an SVG, or spending 12 hours compleitly replicate an existing design in photoshop only for it to be exportable as an SVG. I could be far fe5ching things but sometimes business or upper management get short sighted on the small things. Probably there is no rationalizarion in spending extra effort in having these graphics all svg format, thus improving your application's load and bandwidth utilization, vs pumping more funds towards other easier quicker solutions.

Re: App sizes are out of control

#286

It's pretty rich how these companies are well known for the rigor they apply to interviewing candidates on technical subjects, yet actually drop the ball in production with poor engineering like this. Where does that rigor go after the interviews are done? Are there any examples of well-known apps from large organizations that aren't excessively large in size?

> Are there any examples of well-known apps from large organizations that aren't excessively large in size? This is nothing new. Look how much memory your typical Java desktop app, or worse, your average Java server app, uses. As soon as you have enterprises involved where it's regular occurrence for devs to be outfitted with the shiniest and beefiest (as perks or per standard company policy) developers won't care ab…

I do not think you worked in Enterprise. Getting new tech approved is difficult, provisioning a VM takes weeks. Most enterprise lag at least 2 years behind everyone else.

Enterprise apps are slow because developers lack shiny new tech. You are forced to build yet another Spring App that takes minutes to start and gigabytes of memory. You also need to use MQ to interface with other systems and log/audit almost everything.

Re: App sizes are out of control

#287
post #5

This is definitely getting to be a major problem. I've removed several apps for this reason as well. Code bloat = lost users

I think the way it works in the real world unfortunately is: code bloat => "your phone is full" => "oh, my phone is too old" => new iphone => free space => code bloat That said, I also delete bulky apps before I start deleting media.

Yup, and also bulky apps that insist on a two week rolling release schedule...

Re: App sizes are out of control

#288
post #282

Earlier quoted context omitted.

Wow. I wonder why it's so different. Hopefully someone can chime in with the reason.

Java byte code is generally much smaller than equivalent machine code. If you use something like Multi-OS engine which statically compiles Java bytecode to native code for iOS it's fairly typical to see an order of magnitude difference in binary size. This actually affects Android 5+ too (Multi-OS engine uses Android's AOT compiler) but since it happens on the device it doesn't affect download sizes.

Really? I've never heard that before. I'd guess it would be bigger if anything.

Any idea why that is?

Re: App sizes are out of control

#289
post #218
post #191

Earlier quoted context omitted.

I'm guessing but it seems logical that phones are not the place you want to do extra graphics rendering if you don't have to.

Modern smartphones have quite competent GPUs. They can run 3D games at 1080p/60fps. They could raymarch circles around an svg icon. And if it wasn't enough, the renderings could be cached for later use.

GPUs do not like SVGs. They don't handle them well at all. Most SVGs are CPU-rasterized as a result.

Re: App sizes are out of control

#290

The situation is messy. Take Facebook.app. The reported size on the App Store is 377MB, the distributed .ipa is 241MB. But it is a universal app which includes fat binaries arm_v7 and arm64 and all the graphics 1x, 2x and 3x. App Thinning halves that size for end users. Yet the App Store reports the full size. There's more. App Store also provides some sort of delta updates [1], which save a lot bandwidth, but failin…

This may be unrelated, but why do they push out updates every other day or so? No other app is like that. And sizes aren’t getting any smaller. They’re at version 137 right now...
Post reply on HN