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

The Apps are Too Damn Big

tobykeller.tumblr.com

Post reply on HN
Print view View original

111–120 of 129 posts

Re: The Apps are Too Damn Big

#111

Post by jongraehl »

dasil003 wrote: post #80
robomartin wrote: post #22

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…

> 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. Why would they run into these realities now? Apple's been around just as long as Microsoft, and they have been pissing off their customer base with poor backwards compatibility the whole time. The scale is much larger now, I'll give you that, but the relentless forward-thinking is what has…

"But to solve it is non-trivial"

No, it's trivial. Device-dependent DRM-signed packages. Either the common part is duplicated in each device's version, or app store downloads can consist of two packages.

Re: The Apps are Too Damn Big

#112

Post by martingordon »

thasmin wrote: post #24

The comments I see are about technical solutions. I think Apple's happy that there's finally a reason for people without humongous music collections to pay $200 for 64MB of flash memory.

If Apple really cared about pushing people to the 32/64 GB devices, why would they offer iTunes Match?

Re: The Apps are Too Damn Big

#113

Post by robomartin »

DHowett wrote: post #110
robomartin wrote: post #106

Thinking some more about the problem I concluded that I don't personally have a problem with the creation of multiple versions of the artwork. Most of it can be done through batch processing and some hand tweaking. No big deal. The issue is with app bundle bloat and the download of a huge number of files into a device that will not use them. Here's an off-the-top-of-my-head potential solution: Update Xcode to sensibl…

I feel like this is an overengineered solution by somebody who is not quite familiar with what the platform has to offer. 1) UIImage already handles choice based on asset name. Apple could use the same asset choice logic server-side for each device, without the developer having to corral his assets into directories. It just needs to be expanded to handle ~ipad and ~iphone (which UIImage does not natively, but if they…

> an overengineered solution by somebody who is not quite familiar with what the platform has to offer.

Geez, thanks.

UIImage's handling of assets based on file name is a horrible band-aid.

Also, one has to think workflow. And, to make things more interesting, exaggerate. Let's make it 5,000 files in one directory. That's a mess. With device-specific directories an artist could create a workflow leading to easy maintenance and creation of files. No need to engage in funky naming conventions. The per-device files are simply located where they need to be and a mechanism is provided to identify which path serves a particular device type.

Another problem with UIImage is that there is no way to communicate to Apple which files are to be delivered to, say, an iPod touch. So, an external mechanism is required in order to encode that information. Hence the proposal for an external JSON (or whatever) file.

Why JSON. I like it. Supported by iOS 5.0 as well. Easy to maintain and exist externally to Xcode. This also means that I can write scripts or automation tools on a PC or Mac to automate the creation of assets and their placement within the proper structure. The file used within the app to communicate the per-device directory structure would also could also serve external purposes that cannot be covered with plists. In our case, as an example, all of our assets are being produced on PC's, not Macs.

> Apple is not in the business of giving developers (or users) choices.

That's another matter. Although my proposal wasn't about providing choices as much as it is about a mechanism to only deliver the necessary files to a device. Only the developer can make decisions about which files are appropriate, not Apple.

Ultimately, I don't care what technology might be used in order to enable something like this so long as it works and is reasonably open. Right now I'd love to be able to deliver only 1X files to iPods and ~ipad@2X files to the new iPad rather than forcing a huge download of 1,600 files to every device or the current project on our table. That's just silly.

Re: The Apps are Too Damn Big

#114

Post by robomartin »

robomartin wrote: post #106

Thinking some more about the problem I concluded that I don't personally have a problem with the creation of multiple versions of the artwork. Most of it can be done through batch processing and some hand tweaking. No big deal. The issue is with app bundle bloat and the download of a huge number of files into a device that will not use them. Here's an off-the-top-of-my-head potential solution: Update Xcode to sensibl…

I have a question about localization: Does Apple deliver all language files to a device or only those based on the localization settings? That could be another area of app bloat.

Also, keep in mind that localization can also exist in graphical assets. You could have images with built-in text that need to be switched in based on localization. So, an English version of the app uses this set and an Italian version another set of assets. This might include sound files.

Depending on how this is handled it can start to explode the app bundle in impressive ways. Start with 100 images. Now you need 400 to cover all device display configurations. Then you need to replicate this on a per-language basis. If you cover, say, five languages, you are up to 2,000 files potentially delivered to every single device regardless of applicability. I realize that this is a corner case where all images need to be localized. No need to point that out.

I have not done any internationalization yet, so I don't know how this part works. For some cases it might not be practical to release a separate app in different languages. For example, a kids app that is able to operate in English and Spanish and sold through the US app store.

Re: The Apps are Too Damn Big

#115

Post by tolmasky »

phil wrote: post #109
tolmasky wrote: post #100

Earlier quoted context omitted.

These annotations already exist and developers already use them. As stated in the article you have to use the @2x naming convention to label double resolution images. Similarly you have to use the ~iPhone and ~iPad naming conventions for xibs and any other resource that's different on iPhone and iPad. When making a universal app you are already forced to do this. Take a look at the Twitter app: it is completely diffe…

There's a png in the project. Is it an icon that's used by both iPhone and iPad? A background image used by only one? A texture they share? The nib and @2x annotations don't handle that stuff.

Yes they do: If its an image that gets used in both situations then you don't annotate it. In fact thats the common case. You only annotate the few resources and classes that are different on each platform. It's not complex, and it's also not a system I've invented, it's the system developers are already forced to use by Apple: http://developer.apple.com/library/ios/ipad/#documentation/2... (scroll to "updating your image resource files", you'll see it handles all the cases you mentioned, and the same applies to xibs)

And it works fine except for the fact that it chooses the resource at runtime. When you ask for resource "x" it looks for all the resources that start with "x" but may end with @2x or ~iPhone or whatever. It then decides which to return based on what device you have. There is no reason it cant make this determination at compile-time and just not include the resources it knows it won't be using in four separate builds. There is literally no difference with this system except when it chooses to ignore resources.

Re: The Apps are Too Damn Big

#116

Post by prof_hobart »

jfoster wrote: post #79
prof_hobart wrote: post #63

Earlier quoted context omitted.

It's far from ideal, but it's a long way from the Android fragmentation (can't comment on Windows Phone, never been involved in dev for that). With Android, there could be any one of dozens of resolutions (iOS has two basic resolutions, with a relatively simple 2x multiplier version of each of those), you could have a keyboard or not, you could be a device with a resistive screen with no multi-touch (or even no touch…

You're right that there is a big difference between them for now. We're currently seeing around one new iPhone and one new iPad coming out of Apple each year, though. Don't forget iPod Touch, by the way. Sometimes they come with new features not available to older devices. They get released with three different storage capacities, and only some of your users will have 3G/4G on their iPads. The point is that in a year…

I agree it will get worse, but I don't yet see anything that suggests iOS is going to get close to the fragmentation that Android already suffers with.

Things like storage capacity and network availability are challenges, it's true. But they are things that can affect any device (you can fill up a 64GB device, and you can be in an area with no network), so they aren't really fragmentation issues unless your app requires huge storage or depends on a specific network type being available. Android by its very nature is always going to have a far wider variation than iOS. This is not necessarily a bad thing (there's more choice and more cutting edge options in Android), but it does create a fragmentation challenge of a totally different scale to iOS.

Re: The Apps are Too Damn Big

#117

Post by phil »

tolmasky wrote: post #115
phil wrote: post #109

Earlier quoted context omitted.

There's a png in the project. Is it an icon that's used by both iPhone and iPad? A background image used by only one? A texture they share? The nib and @2x annotations don't handle that stuff.

Yes they do: If its an image that gets used in both situations then you don't annotate it. In fact thats the common case. You only annotate the few resources and classes that are different on each platform. It's not complex, and it's also not a system I've invented, it's the system developers are already forced to use by Apple: http://developer.apple.com/library/ios/ipad/#documentation/2... (scroll to "updating your…

Oh. I didn't realize you could apply a device modifier to an image. Thanks.

Re: The Apps are Too Damn Big

#118

Post by huhtenberg »

ajslater wrote: post #104
huhtenberg wrote: post #43

Earlier quoted context omitted.

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.

Automatic scaling doesn't work very well. You can find numerous design blogs showing you in great detail why it looks slightly shoddy if you scale from 512x512 down to 128x128 or 64x64, and how below 64x64 you just get into illegibility. For your app to look great you need hand tweaked assets for most resolutions. http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes http://bjango.com/articles/designingforretina2…

No, you don't understand. Of course, automatic scaling doesn't work.

Prepare two images - 512x512 and 32x32. Scale first one down to 32x32, subtract it from the second one and this will yield a arithmetic, per-pixel difference. Compress it. Now store 512x512 image and the compressed diff with an app. With these two, you will then be able to recreate original 32x32 (by scaling down 512x512 and applying the diff). And I am making an (educated) guess here that the compressed diff will take less space than the actual 32x32 image.

Re: The Apps are Too Damn Big

#119

Post by huhtenberg »

pornel wrote: post #76
huhtenberg wrote: post #43

Earlier quoted context omitted.

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.

iOS already supports PNG8+a, which is much smaller than regular PNGs and a"CgBi" PNG variant that Xcode uses.

PNG8 is 256 colors, that's pretty limiting in very many cases. CgBI - I just looked it up - appears to be a speed optimization rather than a space one.

Re: The Apps are Too Damn Big

#120

Post by fpgeek »

keeperofdakeys wrote: post #58
olalonde wrote: post #55

Earlier quoted context omitted.

I never owned an iDevice so I'm not sure the analogy stands but I believe the Ubuntu Software Center does something similar to what you're describing. You get the same 'app store' whatever version of Ubuntu you are running but when you install an 'app' it silently downloads the package targeted at your Ubuntu version.

Google Play supports this, which is mainly used for tablet vs phone, but could be used for different ARM architectures.. http://developer.android.com/guide/market/publishing/multipl...

Good point, though I'd say different architectures rather than different ARM architectures, now that we have Android/x86 in the wild, too.
Post reply on HN