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

391–400 of 455 posts

Re: App sizes are out of control

#391

Post by allover »

deft wrote: post #284
allover wrote: post #68

Earlier quoted context omitted.

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.

Well it wasn't that you weren't being specific, more that you were casually maligning the JS community unfairly, when the article isn't even about web/JS :)

(I also don't agree with 'don't need to'. The main takeaway from the leftpad debarcle was the fixes to the npm module deletion policy, and hopefully people learning they shouldn't rely on an 'npm install' for production deployments! Whether people should use small modules is still up for debate, there are trade-offs [1] [2]).

[1] https://github.com/sindresorhus/ama/issues/10#issuecomment-1... [2] https://medium.com/@Rich_Harris/small-modules-it-s-not-quite...

Re: App sizes are out of control

#392

Post by stickfigure »

toast0 wrote: post #377
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…

If Apple (or Google) wanted to make this work, it wouldn't be that hard. An app could list the dependencies, with a name perhaps, but definitely a hash. The developer would have to upload the dependencies, too. If the hash matched, the server would also do a byte by byte comparison, and if that matched, mark the dependencies as sharable. When downloading an app with a sharable dependency, the phone would check if it…

Sounds like you just invented https://nixos.org/nix/

Re: App sizes are out of control

#393

Post by real-hacker »

A major culprit of the bloat is the monolithic 3rd-party libraries/frameworks. You have to import the whole thing, even if what you need is just one simple function. Of course, you have the option of carefully studying the code, and hand-pick the part of code you need, but most developers will not do this, due to poor ROI.

One way to solve this problem, is to promote modular library structures, and package management tools (pod, npm) should support importing fine-grained submodules, even single features of a library/framework, whenever possible.

Re: App sizes are out of control

#394

Post by flukus »

rimliu wrote: post #386
flukus wrote: post #329

Earlier quoted context omitted.

To paraphrase Bill Gates, that's like measuring an aircraft designers skill based on the final weight of the aircraft. Any idiot can create something bloated and complex, creating something small and simple requires much more effort.

But when you think about it, final weight of the aircraft does say something? I guess an amateur could design something like Cesna and have it flying, but designing An-225 is a different matter.

This is more like people building a Vesna but having it turn out the weight of a 747.

Re: App sizes are out of control

#395

Post by xg15 »

toast0 wrote: post #375
kijin wrote: post #371

Earlier quoted context omitted.

Every popular mobile OS has standard libraries for making HTTP requests and doing crypto. I can forgive games for sacrificing size in favor of high-res animations and a blazing fast graphics stack, but I don't think LinkedIn, for example, is in need of particularly fast graphics.

If you've had to look at a pcap from what the android standard libraries do for https chunked upload, you would cry. One tls packet for the per chunk header, one for the chunk of data, and one for the carriage return newline. I've thankfully forgotten if these managed to also be separate tcp packets. Given that, I don't think it's unreasonable to consider using a library to do it better, although you have to weigh th…

Except the standard library will be updated if this actually became a problem, whereas you might choose that the cost/benefet ratio to updating your library is not worth it.

Re: App sizes are out of control

#396

Post by xg15 »

babesh wrote: post #194
mtl_usr wrote: post #177

Earlier quoted context omitted.

I'm as far to mobile development as I can be but is there no shared libraries on those platforms ? Other than the environment provided ones, isn't it possible to bundle some dynamically loaded libraries that can be shared by multiple apps ? Makes absolutely no sense for each application to implement it's own web browser/runtime. Can't believe we are constantly reinventing the wheel again.

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…

> Shared libraries beyond that would bring the hell of version incompatibility

This is more a general question but I've never understand why so many shared library systems have the restriction of "only one version of a library". What stops you from storing different versions of the same library for different apps?

(I understand the problem with transitive dependencies - e.g. if the same app transitively depends on two different versions of a library, that might spell trouble. Even for this there are solutions - e.g. different classloaders for the jvm - but even without, you could disallow this special case witout sacrifying much)

Re: App sizes are out of control

#397

Post by on_and_off »

mfabbri77 wrote: post #180
vladdanilov wrote: post #159

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…

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.

Android starts to use it more and more. At least where it makes sense : icons and simple illustrations.

From discussions with iOS colleagues it seems that Android has seen a way stronger push for vector assets. Probably because from day one the OS and SDK has been designed for unknown displays at compile time.

Re: App sizes are out of control

#398

Post by on_and_off »

toast0 wrote: post #377
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…

If Apple (or Google) wanted to make this work, it wouldn't be that hard. An app could list the dependencies, with a name perhaps, but definitely a hash. The developer would have to upload the dependencies, too. If the hash matched, the server would also do a byte by byte comparison, and if that matched, mark the dependencies as sharable. When downloading an app with a sharable dependency, the phone would check if it…

Google is actually working on this for the support libraries. All the Android apps use them, so it is a good target (and of course it might be possible to extend it to other libs). I guess it makes the most sense in the markets where data is very costly. By itself the support lib is not really big but if each KB counts, let's not download it several times.

Re: App sizes are out of control

#399

Post by real-hacker »

noahmbarr wrote: post #7

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!

+1 for this. I think 16G iPhone6 exists to promote sales of models with larger memory. Now I have to uninstall an app to install a new one on my iPhone(16G), EVERY TIME, it's painful. Next time, I will definitely go for 64G.

Re: App sizes are out of control

#400

Post by real-hacker »

Another question has to be asked: do they have the motivation to reduce the size of apps?

Earlier this year, Wechat released a revolutionary (kinda) feature called 'Miniapp', it supports releasing apps within Wechat itself (a bunch of xml/js files). All major Internet companies published their own miniapp in Wechat, which include s the most-used feature of their full app, and only takes less than 1MB of space. Guess what? the miniapps are not adopted by most users, it became just a fad.

This means most users are not sensitive to the disk space used by an app. Apps know this, and thus don't have motivation to reduce the size.

Post reply on HN