Hacker News Reader

Comment by tolmasky | Hacker News Reader

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 one on the app store. Then the app store correctly downloads the correct one depending on your device (iTunes can keep all three if it wants or whatever), and then there is no need for the app store to muck around in your app internals or anything.

View on HN

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.

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

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

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

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?

The Android Native Development Kit allows you to write normal C code and compile it for ARM devices.

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

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.

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.

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

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

Specifically?

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.

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.

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.

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

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.

I see your point, but users don't need to be moving apps from one device to the other. They just need to DL it on one and have it delivered to others, which is standard icloud procedure now. It's the same for backups, especially for apps that you want a copy nevermind what happens down the way (the app is deleted, the news version is crap, you can't connect to the store etc).

As a matter of price, for the reasons above I am OK to pay more for an universal app than have two different ones I'll have to manage separately.

You totally missed his point. He's not saying the experience should present to the user as anything but what it does now - but behind the scenes there isn't any reason for the universal binary to exist. The phone or tablet should just download the binary it needs.

I talked about backup and multi distribution of the same app to different devices in one batch. Isn't that enough "behind the scenes" related? I understand he wants the better of both worlds, a light download for each device and still full compatibility with each. But just thinking about it 30 sec and there are plenty of cases where the magic breaks and you find yourself in a corner with only one version when you need the other. You can say "throw the edge cases away", but it' unrealistic to think that you can keep the same usability in everycases while heavily cutting on the data you transmit to your users. Let's be honest about the compromises.

> But just thinking about it 30 sec and there are plenty of cases where the magic breaks and you find yourself in a corner with only one version when you need the other.

Name a single one an end-user would encounter. They wouldn't.

Reply on news.ycombinator.com