What iPhone 6 screen size means for developers
cleancrispcode.wordpress.com
cleancrispcode.wordpress.com
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.
http://oleb.net/blog/2014/08/replacing-launch-images-with-st...
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.
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 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.
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.
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.
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 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.)
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.
Simple.