The Apps are Too Damn Big

Typically, when the App Store complains about lack of space to update all, you can still update them all one at a time, or do the big ones first, then, update all. That's because when you update apps, you've got two copies of an app on your device until the old version gets deleted, and when you click 'update all', it checks if you have enough space for all the apps in question to be duplicated.

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/

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 sensibly handle file structures within a project. You know, the blue folders. We currently use blue folders for all app assets because, well, can you imagine maintaining 1600 files all in on directory?

The problem with blue folders today is that they needle you with pain. You have to remember to do clean builds (scripts during the build don't seem to work reliably) and, in general, be very aware of them. Once they are part of your process its not a big deal, but I think it's high time that Xcode come to this century and do something that most other development systems have been doing for, I don't know, decades?

Anyhow, once that is in place, you could have a directory structure such as this one at the app root:

  App Resources
  App Resources @2X
  App Resources ~ipad
  App Resources ~ipad @2X

I then want to include a JSON file at the app root level that points out the root directories for each device category. Maybe something like this:

  {
    "ipod 1":    "App Resources",
    "ipod 2":    "App Resources",
    "ipod 3":    "App Resources",
    "ipod 4":    "App Resources @2X",
    "iphone 1":  "App Resources",
    "iphone 2":  "App Resources",
    "iphone 3":  "App Resources",
    "iphone 4":  "App Resources @2X",
    "iphone 4S": "App Resources @2X",
    "ipad 1":    "App Resources ~ipad",
    "ipad 2":    "App Resources ~ipad",
    "ipad 3":    "App Resources ~ipad @2X"
  }

Now provide for a way to load this JSON data into the app and have relevant methods, such as "imageNamed" use a device specific path. My guess is that you'd want this to be by extension rather than modification so:

  + (UIImage *) imageNamedAndKeyForPath:(NSString *)name  key_for_path:(NSString *)key

Obviously the key would be used to retrieve the value from the JSON file or, preferably, a value already stored in memory when the JSON file was parsed at app start time.

Apple then, would have a mechanism to only deliver the appropriate resource files during an in-device installation. iTunes could download the whole set and also be intelligent during to-device installation. They'd use the JSON file to have the developer tell them which files to deliver.

Any files left outside the designated directories would be treated as they are today: Everything goes to every device.

Also, other methods that take a path, such as "imageWithContentsOfFile" ought to have a version that uses the aforementioned mechanism while --and this is important-- letting me specify relative paths from the device-specific folder. If I have something like this:

  
    + character
      + arms
      + legs
      + head
    + background
      + trees
      + rocks
      + clouds

I ought to be able to access the path structure relative to the chosen device-specific directory of assets.

On first inspection this sounds like a good solution. I haven't thought it through entirely. I'd be interested to hear of what holes the idea might have.

Something like this could have a striking effect on app bundle size, particularly on older devices. I don't think that it places an undue burden on developers either, if anything it makes things easier. Heck I'm sure Apple could even find a way to make it a marketing point: "Four times as many apps in the same space".

> ... will not take kindly to their 16 GB iPhone becoming obsolete simply because Apple released an iPad with more resolution.

The vast majority of normals will never even realize this is the case. Plus, even if they do, people are well conditioned to the obsolescence of technology. I mean more people buy a new PC before they re-install Windows when things get unbearably slow, and if we had a graph of how often people upgrade their phones, I don't think we'd see much to support your point.

Now if the media decides to latch onto this (which I wouldn't doubt given the fervor for a juice Apple scandal), then it might piss off a few people, but do you really think that people will be convinced to trade in their iPads for pitchforks over this? What percentage of people are really not going to be able to update their apps anyway? If this really became a media problem then Apple might move to address it, but I stand by my written and attributed assertion that this is a non-issue for Apple and will not affect their bottom line or move them to any action other than to perhaps go 32/64/128 for the next iPad.

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 make this a standard, they could.) The fallbacks would, of course, be most-specific to least-specific: scale and device before common. One downside here is that direct path access to an image will not be fixed, but they already do static analysis for message names, you can find calls to bundle methods and keep those assets lying around.

2) JSON?! We have property lists, they're way more Appley and have framework support through-and-through.

3) While this might provide the ability for a developer to choose which resources are used where, Apple is not in the business of giving developers (or users) choices.

In other words, I don't think the onus should be on developers. They should be free to do what they do best: innovate about the real problems, not the platform's solvable deficiencies.

The above listed can also be applied to all existing app bundles, were Apple feeling adventurous. Parent's method can not.