What iPhone 6 screen size means for developers(cleancrispcode.wordpress.com)
cleancrispcode.wordpress.com
What iPhone 6 screen size means for developers
http://cleancrispcode.wordpress.com/2014/09/09/what-iphone-6-screen-size-means-for-developers/
24 comments
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.
does this mean iOS is a fragmented mess?
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.
This is not just a trick, it's a actually feature that the user can turn on throughout the system, look for "Zoom View":
http://www.apple.com/iphone-6/display/
This is going to be great for older users :) But it begs the question if there shouldn't be a similar feature on the iPad mini.
http://www.apple.com/iphone-6/display/
This is going to be great for older users :) But it begs the question if there shouldn't be a similar feature on the iPad mini.
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.
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.
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.
As far as I can see in the simulator it's definitely upscaling the 320x568 buffer.
I think the apps will look sharp because of a good scaler, not because it's messing with the UI View hierarchy.
I get the sense the author of the article isn't aware you need new launch images to make the app iPhone 6/6+ 'native' ?
I think the apps will look sharp because of a good scaler, not because it's messing with the UI View hierarchy.
I get the sense the author of the article isn't aware you need new launch images to make the app iPhone 6/6+ 'native' ?
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.
[deleted]
> 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.
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.
Apparently launch images in different sizes will go away and will be replaced by storyboards with auto layout
http://oleb.net/blog/2014/08/replacing-launch-images-with-st...
http://oleb.net/blog/2014/08/replacing-launch-images-with-st...
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.
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.
"Please wait while a version suitable for your device is downloaded from the app store".
Simple.
Simple.
We have moved to PDF assets for all of our apps. It's wonderful.
Generally we have a single illustrator file, some export scripts, and push the resulting PDFs through ShrinkIt to minimise file size.
The result is tiny apps that handle all scale factors, can easily be tinted programmatically, and generally match the aesthetic of iOS 7 and 8.
Generally we have a single illustrator file, some export scripts, and push the resulting PDFs through ShrinkIt to minimise file size.
The result is tiny apps that handle all scale factors, can easily be tinted programmatically, and generally match the aesthetic of iOS 7 and 8.
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.
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.
Wow I had not stumbled across this idea yet... Are there any caveats or downsides to PDF over PNG? (other than xib/storyboard issues you mention)
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.)
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.)
Because for historical reasons those apps are backed up to itunes where they may eventually be transferred to an iPad.
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
Good, related Stack Overflow discussion: http://stackoverflow.com/questions/25755443/iphone-6-plus-re...