[stephengillie]

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...)

[tolmasky]

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.

[masklinn]

> 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.

[tolmasky]

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.

[olalonde]

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.

[keeperofdakeys]

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...

[olalonde]

I thought all Android apps ran in a Dalvik VM. What do you mean by "could be used for different ARM architectures"? Isn't Java bytecode independent of the underlying architecture?

[vidarh]

There's an increasing number of MIPS based Android devices out these days, so hopefully they can handle that too...

[fpgeek]

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

[illumen]

Yeah, but Ubuntu is professional, well designed, and well made - by people who truly care about their users. You can't hold Apple up to the same high standards... they're just not in the same league.

[phil]

This would definitely require more work on the developer's part!

Right now the situation is: toss whatever you want into the bundle and it's there everywhere. For what you're proposing to have any benefit it would have to be: add files, annotating them with whether they are needed for iphone/ipad, keeping those annotations updated as you work.

[tolmasky]

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 different on iPad vs iPhone. These labels are how it knows what interface to load on each device -- yet the code and resources to load either exist regardless of what device you are on.

[phil]

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.

[tolmasky]

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.

[phil]

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

[smashing]

I suspect that the real problem is that some people download every app that interests them with the words FREE and LITE in the title.

[pmjordan]

No, we have less than 4 pagefuls of apps on our (admittedly 16GB) 1st-gen iPad, and space is pretty tight. No music and we only keep around about 1-3 hours of video at a time.

Games are by far the worst of course, but I'm sure part of that is down to the higher-res textures for iPad2/3 which are useless on the first iPad's much weaker GPU. (the difference is likely even worse between iPhone4S and iPhone 3GS or older) Adding a higher-res mip level for each texture in a game will increase the size of all textures by about 155%[1]. So in principle a 16GB/32GB non-retina iPad could store at least as many apps as a 32GB/64GB retina one, respectively. (not counting savings from losing all the iPhone/iPod touch assets, which will be big for non-OpenGL apps)

The iOS app update mechanism is also pretty broken when you're low on disk space: to update large apps, you have to delete the old version (deleting any of your data in said app) and reinstall with the new one, if both of them don't fit side-by-side on your device.

And as an app developer I'm already so used to jumping through ridiculous hoops to get apps onto the app store, so tagging files for different device types seems straightforward enough (and would help a LOT for reducing the size of one of the apps in the store that I developed - in fact, pushing it below the 3G threshold vs the current wifi-only size).

[1] http://wolfr.am/HUOxZ1

[smashing]

Whenever someone comes at me with this topic, I can't help but think of the greatest George Carlin quote of all time, "Simplify."

[pmjordan]

Specifically?

[statictype]

Apple has historically not given the slightest fuck about what is an inconvenience for developers. Even more so when what's good for users is the opposite of what's convenient for developers. And in this case (if they ever do decide to enforce multiple binaries) that would be a good thing.