Live data from Hacker News

The Apps are Too Damn Big

tobykeller.tumblr.com

41–50 of 129 posts

Re: The Apps are Too Damn Big

#41

I don't understand why "universal binaries" exist at all on iOS. On desktops where the app space is more "free" it has a purpose, but it's not like users are regularly moving apps from one iDevice to another -- so what on earth is the point of having three different things altogether? The much more intelligent solution would have been to simply allow developers to upload 3 different binaries, but only present it as o…

How many developers are willing to create and upload 3 different versions of their app? I seem to remember reading a thread here on HN complaining about that... Would Apple allow an app maker to release their app for only newer iPads and iPhones, and not for the older devices? (I have no idea...)

It would require no extra work on the developer's part. The 4 binaries could just be bundled in a "super" bundle and still even look like one thing and keep the ".app" extension. So we could actually keep everything as it is (code and resource wise), then when you hit compile, it simply makes 4 copies: 1 for iPhone (non-retina) which includes the .xibs for iPhone and non-HD images, one for iPhone HD (same but with HD images), one for iPad (blah blah) and one for iPad HD. It then shoves those into MyApp.app. That gets uploaded to iTunes as normal, but then only MyApp.app/Real-iPhone-HD.app gets actually downloaded to your phone for when you buy it.

What I'm asking for isn't crazy: You can kind of do this today by shipping a separate iPad and iPhone app (you can't separate non-HD and HD). The main thing I'm asking for is for the App Store to recognize that they are the same thing without forcing me physically combine them.

Re: The Apps are Too Damn Big

#43

I have a feeling that Apple might just start to run into the kinds of realities MS and others have been living with for years. Either they choose to piss off millions of users of older devices or figure out how to allow for evolution without causing problems for the installed base. Or, maybe they don't. As an iDevice user I am glad that I chose to buy all my devices with the absolute max storage available. Everything…

Can't you do some sort of custom image compression? Bundle app with the highest resolution images, then scale them down, arithmetically subtract from the respective image and pack and ship the difference. Just gzip or paq it, and see what the savings are like. If it works (and my gut feeling is that it would), then reconstruct lo-res images on the fly when they are needed.

Re: The Apps are Too Damn Big

#45

I have a feeling that Apple might just start to run into the kinds of realities MS and others have been living with for years. Either they choose to piss off millions of users of older devices or figure out how to allow for evolution without causing problems for the installed base. Or, maybe they don't. As an iDevice user I am glad that I chose to buy all my devices with the absolute max storage available. Everything…

If you did dynamic downloads you cold then run out of storage while doing this,mwhich would be a terrible experience.

Vector graphics help in some cases.

Re: The Apps are Too Damn Big

#46

I like this author's thoughts, and there are some creative solutions offered by him and the commenters there on how to thin the assets. However, I would be interested to see how the assets' size stacks up against the actual binary. Some of the biggest apps on my iPhone are iBooks (57.9MB) and Nook (51.3MB). I doubt their pretty little icons take up the lion's share of that size. I mean, Kindle does it in a measly 23.…

You'd be surprised: the assets take up about 50% of the total. It's simple enough to examine the contents of an IPA file:

iBooks used to be under 20MB. Over time it's expanded to its current size of 50.8MB when it's uncompressed (the extra space it's taking up on your device is probably the books themselves).

The vast majority of that is images. Apple have at least been somewhat smart about it, choosing in certain cases to use lossy JPGs rather than PNGs where the user won't notice (the startup image, for example).

The app also ships with some custom fonts, which take up a few of those MB. The languages, which you suspect take up a lot of the space, actually don't represent that much: each language is about 45KB.

The executable itself is 25MB: so basically, 50% of the app size consists of assets. The percentage is probably higher on most other apps, because the iBooks executable is rather large (unusually so).

Re: The Apps are Too Damn Big

#47
This doesn’t address the root problem, but liberal use of Imageoptim and ImageAlpha can drop file sizes for images by 50-60% in extreme cases. As a web guy when bandwidth matters I’m very familiar with these techniques, but maybe they haven’t got traction in the app world?

Re: The Apps are Too Damn Big

#48

This doesn’t address the root problem, but liberal use of Imageoptim and ImageAlpha can drop file sizes for images by 50-60% in extreme cases. As a web guy when bandwidth matters I’m very familiar with these techniques, but maybe they haven’t got traction in the app world?

When creating iOS apps part of the process of transferring the app resources into the app itself involves compressing the images even further. There are ways to improve this, but at the base line you have it done for you.

Re: The Apps are Too Damn Big

#49

Earlier quoted context omitted.

How many developers are willing to create and upload 3 different versions of their app? I seem to remember reading a thread here on HN complaining about that... Would Apple allow an app maker to release their app for only newer iPads and iPhones, and not for the older devices? (I have no idea...)

It would require no extra work on the developer's part. The 4 binaries could just be bundled in a "super" bundle and still even look like one thing and keep the ".app" extension. So we could actually keep everything as it is (code and resource wise), then when you hit compile, it simply makes 4 copies: 1 for iPhone (non-retina) which includes the .xibs for iPhone and non-HD images, one for iPhone HD (same but with HD…

> You can kind of do this today by shipping a separate iPad and iPhone app (you can't separate non-HD and HD)

And it's bloody inconvenient for the user who has to buy and keep half a dozen identical applications.

Re: The Apps are Too Damn Big

#50

Earlier quoted context omitted.

It would require no extra work on the developer's part. The 4 binaries could just be bundled in a "super" bundle and still even look like one thing and keep the ".app" extension. So we could actually keep everything as it is (code and resource wise), then when you hit compile, it simply makes 4 copies: 1 for iPhone (non-retina) which includes the .xibs for iPhone and non-HD images, one for iPhone HD (same but with HD…

> You can kind of do this today by shipping a separate iPad and iPhone app (you can't separate non-HD and HD) And it's bloody inconvenient for the user who has to buy and keep half a dozen identical applications.

Right that's the whole point of my post. I'm saying its technically possible to separate them - Apple should then do the presentation work of showing them as the same on the store and pretending they're one app.
Post reply on HN