Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

App sizes are out of control

trevore.com

Post reply on HN
Print view View original

431–440 of 455 posts

Re: App sizes are out of control

#431

Post by OldSchoolJohnny »

mncolinlee wrote: post #428
mfabbri77 wrote: post #180

Earlier quoted context omitted.

I was wondering why not use SVG (or any other vector file format) files and render all the graphic on the device, instead of including tons of PNG at various resolutions.

I'm not sure about iOS, but on Android the reason is the cost penalty of rasterizing larger icons and images on the fly. There's also some fragmentation with differing levels of SVG support on different OS levels. As a result, SVG is limited.

"some fragmentation..." That's like calling the ocean a bit wet! The experience of learning to code on Android revolves a great deal around dealing with that fragmentation.

Re: App sizes are out of control

#432

Post by CodeWriter23 »

jordansmithnz wrote: post #207
saagarjha wrote: post #193

Earlier quoted context omitted.

iOS vector asset catalogs (which use PDFs) actually don't support true vector rendering; any vector images are converted to PNGs at compile time.

As of iOS 11/Xcode 9 vector images are supported which is quite nice. It may still convert to PNG for backwards compatibility though, I’m not sure if App thinning discards the PNG for iOS 11 devices.

Pretty sure every trade off made at Apple is weighted heavily toward extending battery life.

Re: App sizes are out of control

#433

Post by kllrnohj »

vbezhenar wrote: post #379
kllrnohj wrote: post #289

Earlier quoted context omitted.

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

May be SVG is not the best vector format after all. May be we need something simpler, where every item directly maps to GPU graphics calls, also binary would help.

If you want something simpler that works with GPUs it needs to be exclusively built out of triangles and/or code that can operate on a single pixel independently of its neighbors.

Resolution independent formats are inherently anti-triangle and by the time you've hit triangles you already have a target resolution in mind.

Or put another way, GPUs really don't like vector graphics in general. That's not what they're built for or good at.

Re: App sizes are out of control

#434

Post by scott_karana »

kronos29296 wrote: post #411
habosa wrote: post #359

I am surprised at all of the app developer shaming in this thread. Is it really likely that every developer working on a popular BigCorp app is an idiot who imports 10MB libraries every time he/she faces the slightest challenge? It's much more likely that app developers are optimizing for many things, including app size, but reducing app size has a bad cost/benefit ratio. Here are some decisions that may bloat your a…

Yet the installed size of my facebook app on android is 350MB and since the total phone memory is 2 GB I have a storage problem (less than ideal free space). While facebook lite is not a smooth experience compared to the full app.

"Installed size" as reported by iOS can be deceptive, since it includes a cache.

Unlike Android, end users can't clear it, though backing up and restoring your phone does that...

Re: App sizes are out of control

#435

Post by custos »

pandalicious wrote: post #213
babesh wrote: post #194

Earlier quoted context omitted.

For iOS, there are the shared libraries provided by the OS. UIKit, PhotoKit, etc... Shared libraries beyond that would bring the hell of version incompatibility. One need only look at Apple’s evolution of Swift where there still isn’t binary compatibility? Most people don’t want to crack open their phone and set paths so that their app has a version of Python that works with it. Also shared libraries can be giant sec…

It's pretty telling that Linux distros are pretty much the only end-user platforms where binary distribution and packaging is built around shared libraries. Pretty much everyone else (Windows/OS X/iOS/Android/etc) generally expect binaries to include their own bundled versions of 3rd party libraries. Lots of people have looked at this problem and most have opted against the shared library approach.

The Global Assembly Cache for .NET was supposed to be a shared library storage with support for multiple versions of the same library + signed assembly/hash matching.

It just never really took off for some reason. It's where all the BCL assemblies existed.

Instead we have NuGet and the libraries exist wherever the application is installed. GAC be damned :(

Re: App sizes are out of control

#436

Post by vanderZwan »

crazygringo wrote: post #270
vanderZwan wrote: post #50

Earlier quoted context omitted.

The worst part is that they probably use huge PNGs to make sure the flat graphics are clean. You know, the kind that are perfectly suitable for vector graphics .

Flat graphics are actually extremely compressible with PNG's. That's actually one of the positives from moving away from gradients and shadows everywhere, funnily enough.

They are, but as soon as ther is anything that is not a rectangular gradient with a continuous delta, they're probably still bigger than SVGs

Re: App sizes are out of control

#437

Post by maxxxxx »

verytrivial wrote: post #406
maxxxxx wrote: post #176

Earlier quoted context omitted.

It's pretty ironic that dynamic linking's main motivation was to eliminate duplicate code and reduce code size. Deploy a DLL once, every software uses it and doesn't have to include it. Now it has turned out exactly the opposite way. If we went back to linking object code together we would get smaller sizes. Instead we have to include huge DLLs.

> dynamic linking's main motivation was to eliminate duplicate code and reduce code size I'm pretty sure the main motivation is/was to allow patching of dependencies independently from applications. Very popular shared libraries might save space overall, but that is a secondary effect.

When I started out the main motivation was to get install sizes down. At least on Windows patching never really worked and ended in "DLL hell".

Re: App sizes are out of control

#438

Post by maccard »

AstralStorm wrote: post #384
maccard wrote: post #141

Earlier quoted context omitted.

Not exactly large organisation, but the slack app is 80MB. For reference, discord is 17.

Please also count in server side data downloaded for identical functionality. It does not help if 80% of the app is downloaded after installation.

I'm on iOS, so checking the sizes in Storage. Slack is 74MB with 14MB extra downloaded. Discord is 18MB with 6MB extra downloaded.

Re: App sizes are out of control

#439

Post by jamescostian »

cyphar wrote: post #367
jamescostian wrote: post #127

Earlier quoted context omitted.

JavaScript people do not create libleftpad.so, they create libleftpad.o (metaphorically speaking), which will not clutter up your distribution, it will just clutter up some apps. I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries. But I agree with what you're saying in the second paragraph, which actually sounds just like what my GP meant by using "Webpack to throw away what isn't used". Havin…

> which will not clutter up your distribution, it will just clutter up some apps. Not necessarily. Distributions have to build everything, and in openSUSE we have an integrated build system[1] which has a lot of very useful features (rebuild when dependencies are updated, and automated QA runs before releases). Those features require you to have all of the dependencies of a project in an RPM package. Even if you don'…

I had no idea about this - thank you for bringing it up! But we seem to be discussing different ideas. I was trying to argue about apps, specifically iOS apps, like the original article was about. iOS apps aren't distributed on openSUSE, so if some devs make some kind of libleftpad.o for Objective C developers making iOS apps, I'm saying that's fine, and I doubt it would clutter up your distro because Objective C isn't exactly known for it's cross-platform adoption :)

If we're going to talk about linux packages, aren't they often written in languages with amazing optimization skills? If I write some C99 code that uses a gigantic library but I only use like 2% of it, my compiler will cut out the 98% my code doesn't use, so libleftpad sounds like an awful idea. That's one reason why packages on linux distros aren't too big.

But I'm talking about iOS apps where, as others have pointed out, the available optimizations suck[0], and as such, I think that having libleftpad.o included in everyone's iOS apps isn't a big deal (note that iOS doesn't really have a nice way to create libleftpad.so anyway AFAICT because all code for your app is supposed to be sandboxed so no one else can mess with or use it). I agree that it would be really cool to just cut out the 98% of $GIGANTIC_LIBRARY that isn't used at compile time, but since Objective C doesn't seem to have that now, I think small things would be a really nice way to give users more space on their phones without removing features.

[0] https://news.ycombinator.com/item?id=14902174

Re: App sizes are out of control

#440

Post by nerdponx »

wooter wrote: post #137
nerdponx wrote: post #86

Earlier quoted context omitted.

This is usually my thought when I see issues like this. If Apple wanted to fix the problem, they would fix the problem.

this incentive analysis is so shallow it doesn't pass first muster. does fitting/selling more apps make Apple more money? are storage and bandwidth expenses? do users value performance? most people here seem to agree more bloat = less users.

most people here seem to agree more bloat = less users

I haven't seen any data in this thread to back that up. It certainly doesn't apprar true in my experience.

Post reply on HN