All existing apps will be rendered into the current 320x568 frame buffer and scaled up. It's really no different to an iPhone app running on an iPad in that respect.
I'd imagine the scaled up apps will also look slightly blurry, but how much is to be seen once we get the devices.
A developer has to build the app under iOS 8 SDK with new launch images for the iPhone 6 and 6+ to use the native resolutions of those devices.
The frames will then be 375x667 and 414x736 for the iPhone 6 and iPhone 6+ respectively.
So the auto scaling is a stop gap, you really need to have the app running at the native resolutions to look as best they can.
Is it definitely upscaling a 320x568 buffer, or is it fractionally scaling the UIView hierarchy to render at 375x667 or 414x736? My impression from the article was that it is doing the latter.
In the keynote they seemed to imply that existing apps would appear sharp on the new displays, and this sort of rendering trick would achieve that.
Thanks — I was kind of excited to think that they had found a reliable way to upscale an arbitrary view hierarchy. I guess upscaling the compositor output is more reliable.
> All existing apps will be rendered into the current 320x568 frame buffer and scaled up. It's really no different to an iPhone app running on an iPad in that respect.
I don't think it quite works that way. In the past, your iPhone app was designed to run on iPhone only and it upscaled if you attempt to run it on iPad and the OS knew it had to do this due to a checkbox setting in xCode.
Nowadays, most apps are universal and runs on any device by adjust the output according to device resolution and given scale factor. Basically the scaling is handle internally by the program and not by the OS as described above. In theory, your app should be future proof if you did this correctly.
That said, you need HD Retina graphics so that your code avoids upscaling images. Beyond that, everything else such as fonts are not upscaled but drawn to scale.
This is really interesting, it means that non-iPhone 6 apps are tricked into thinking they are rendering into a 320x568 logical buffer; but really a fractional scaling is applied to the UI views so that things like text labels and buttons render crisply into the larger resolution of the device without the app needing to be updated at all.
It bothers me that we are still referencing iPhone 3 resolutions on 4 and above. Eventually @2x will be the default and we need to stop bundling apps with four versions of an image. Apple needs multi-targeted .ipa files. Why does my iPhone need to download iPad assets?
Because you might sync that app to iTunes over USB and from there to your iPad.
In particular, if your iTunes machine does not have a internet connection, the user messaging/experience could get hairy. Do you copy the non-iPad version to the iPad, yes or no? Do you tell the user, yes or no? Would the typical non-technical user understand what happened? My guess: probably not.
Also, restoring a backup made from an old device to a new device with higher resolution could get complicated, either technically or for the end user.
Other questions:
- what would iTunes show is on your Mac? "You have twitter, but only the 2x resources"?
- testing effort would explode, as one would have to test apps with partial resources.
I think we will at some time get such partial downloads, but for now, copying the whole app keeps things simple.
We're looking at moving to PDF when we adapt to fit the iPhone 6 Plus and I'd be interested to hear if you guys ran into any snags along the way or if it was all smooth sailing?
It's been very smooth for us. We use UIImage+PDF to load and cache assets. The only issue is that you can't use PDFs directly in Xibs or Storyboards — you'll have to load them in code.
I'd recommend creating all your assets on non-retina sized artboards in Illustrator. We wrote a simple script to export all artboards to separate PDFs, using the name of the artboard as the file name.
None that we have encountered. And we've done quite a few apps like this.
I'd highly recommend ShrinkIt for shrinking the Illustrator exported PDFs, as it can reduce the size by as much as a factor of 10.
Also PDFs really lend themselves to being dynamically tinted. You can use the new render mode in iOS 7+ or something like UIImage+Tint to make sure your key colours are all well defined in your code. (It's really nice when a client suddenly decides they want their app to be orange instead of blue, and it's a one-line change without touching a single asset.)
Yup - but there's no reason (other than app developers making a mess) not to remove images which aren't needed.
So on install - from the app store or itunes, remove ipad assets if there's correct asset for iPhone (same with retina and non-retina).
It has to be done at some point because it's already getting ridiculous
I made some updates to the article taking into account some of the feedback mentioned here as well as quick way to "turn off" the scaling by adding launch images.
I'd imagine the scaled up apps will also look slightly blurry, but how much is to be seen once we get the devices.
A developer has to build the app under iOS 8 SDK with new launch images for the iPhone 6 and 6+ to use the native resolutions of those devices.
The frames will then be 375x667 and 414x736 for the iPhone 6 and iPhone 6+ respectively.
So the auto scaling is a stop gap, you really need to have the app running at the native resolutions to look as best they can.