App sizes are out of control • Hacker News Board

Re: App sizes are out of control

#241

Post by justinclift » Tue, Aug 01, 2017, 8:15 PM UTC

LocalH wrote: post #210

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.

Because the experience is subpar when that is done. It is impossible to create a vector image that will result in clean, unblurred strokes at arbitrary small pixel sizes. Don't even suggest using TrueType-style hinting, I don't think any designer would want to touch that with a 10 foot pole.

Wouldn't it make sense for the file format to just allow svg in addition to others?

eg png is fine, but if a developer wants to include svg then let them.

For developers who do care about the clean, unblurred stroked at arbitrary pixel sizes this wouldn't impact them at all.

For the developers who care more about the space taken up, this would give them a potential useful option.

Re: App sizes are out of control

#242

Post by babesh » Tue, Aug 01, 2017, 8:16 PM UTC

mtl_usr wrote: post #206

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…

I guess they went as far as they could without a proper package manager. > 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? Since the source code is shared with Apple once it reaches the marketplace, wouldn't it be simpler for Apple to compile a specific version for whatever version of the Swift…

Your source code isn’t shared with Apple. You ship Apple a binary or intermediate code.

Edit: Also doesn’t help if you have C or C++ code mixed in there.

Re: App sizes are out of control

#243

Post by DamnInteresting » Tue, Aug 01, 2017, 8:16 PM UTC

saagarjha wrote: post #204

DamnInteresting wrote: post #92

One of my first jobs was as a technician at a tech support call center. For a while around 1997-1998, a good 1/3 of our calls were customers who ordered a new system with a hard drive over 2.1GB, but Windows/DOS could only make partitions as large as 2.1GB. Customers wondered why they got a smaller hard disk than they ordered, not realizing the extra space was that Drive D under My Computer. Fast forward to today, wh…

> my MacBook keeps nagging me that my "hard disk" (actually an SSD) is "full" because I only have 3GB of free space That's because it will use that space for caches and swap, and you're preventing it from doing so and making the system slower.

Yes, I know. My point was that today's "practically none" was 20 years ago's "more than the OS can handle."

Re: App sizes are out of control

#244

Post by IncRnd » Tue, Aug 01, 2017, 8:17 PM UTC

nathancahill wrote: post #189

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.

Because different graphics are shown are different resolutions, rather than purely scaling a highly detailed 1024x1024 SVG down to 128x128.

SVG = scalable vector graphics

SVG files are vector based.

Re: App sizes are out of control

#245

Post by justinclift » Tue, Aug 01, 2017, 8:19 PM UTC

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.

Not sure if "Linux distros" is the completely right term there. The various *BSD based "ports" systems do similar too.

Re: App sizes are out of control

#246

Post by jmduke » Tue, Aug 01, 2017, 8:20 PM UTC

Worth pointing out: The author of this article works at Kayak, which has an iOS app of 176MB.

https://itunes.apple.com/us/app/kayak-flights-hotels-cars/id...

(As far as I can tell, the answer to "why is LinkedIn.app so large?" is not "because LinkedIn's iOS team sucks", but "because LinkedIn's iOS team works under a number of constraints, including app size, and app size is not a particularly powerful constraint to optimize for.")

Re: App sizes are out of control

#247

Post by chatmasta » Tue, Aug 01, 2017, 8:23 PM UTC

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…

A simple solution to this would be for Apple (or the developer, via Apple) to distribute different builds based on the device installing the app.

That is, developers could compile a different copy of the IPA for all target devices. Using variables like CPU architecture, screen size, and other feature flags, a smart compiler could cut a lot of code and assets that never run or display on certain devices.

(Granted, this would be much simpler on iOS, which has a limited set of targeted devices compared to Android.)

In fact, it seems Apple has already taken steps in this direction with its cloud compilation (I'm not an iOS developer, so not sure of the specifics). What would worry me is if they started requiring all source code be uploaded to their servers for compilation. Going down that road is fraught with ideological pitfalls.

Re: App sizes are out of control

#248

Post by marcosdumay » Tue, Aug 01, 2017, 8:28 PM UTC

whowouldathunk wrote: post #131

lcnmrn wrote: post #119

Earlier quoted context omitted.

Why vectors can't be pre-rendered and cached?

That's what a bitmap asset is.

Except that a cache is disposable, and disposed often in practice.

Re: App sizes are out of control

#249

Post by skywhopper » Tue, Aug 01, 2017, 8:29 PM UTC

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…

Wild guess, but presumably file size was not Apple's only or primary consideration on image format. Rendering performance, app load times, and power conservation all likely rank higher in Apple's priority list that raw disk space used.

Re: App sizes are out of control

#250

Post by acdha » Tue, Aug 01, 2017, 8:31 PM UTC

hengheng wrote: post #157

jamieomatthews wrote: post #134

Earlier quoted context omitted.

I work on Amazon Prime Photos iOS app. It's currently 60mb in size, and a good chunk of that is the Swift runtime. Even the main Amazon shopping app is less than 100mb.

I'll bite. In what ways can you use up 100MByte with a fancy reimplementation of an online shop ? That should be enough for a text to speech engine, or a 3d engine with quite a few assets. I am being deliberately ignorant, having no idea what functionality one might add, but I'm actually genuinely curious. All that I see is a small databse and a lot of assets that are being downloaded on the fly.

I don't know the division of work between the app and server but don't forget that the app includes some level of voice recognition, and has not just a bar-code scanner but enough of a computer vision system that I can pretty reliably look up products simply by taking a picture of them.