This was posted here a few weeks ago:

http://bjango.com/articles/appdesignworkflow/

OK, I should blog about this. But instead here's a lengthy post...

tl;dr Think about proportions instead of pixels. Don't worry about the autoscaling trickery.

Before getting into resolution, you should think about adaptivity. And specifically autolayout constraints, size classes, trait collections and points.

You should consider the different screen sizes in points (basically 1x), and think about the screen proportions and sizing element similar to the way you would think about responsive web design (with trait collections being breakpoints). So the best way to design is to consider a element's size as a relationship between absolute values (points) and proportional values (percentages). Example

• A header might contain two icons that are 15pt from the left edge of the screen, with 10pt of margin in between them,
• with a title sitting in a proportional area that stretches in the center of the screen,
• and an image on the right that is a fixed size and positioned 15pt from the right edge of the screen

Size classes are a way of thinking about how a device should be considered depending on its proportional dimensions and orientation. Right now, the spec provides classes for vertical and horizontal proportional sizes called “Regular” and “Compact”. Regular being the larger size and Compact being the smaller.

So when you design your app, it might be best to start with something that is fairly generic (to hammer this home, the default storyboard size in Xcode is a square) – that can then be adapted to each of the classes via proportional resizing.

Much like responsive design, you can also create exceptions for each combination of size classes. Each of these orientations (horizontal and vertical) are consider traits. And the display scale is consider a trait collection. So within a trait collection you can do very powerful things:

• determine where elements are placed using auto layout constraints
• modify visual aesthetics like margins and padding
• use different assets/sizes etc.

So instead of designing for specific point dimensions, I'd approach the problem by designing for a specific set of trait collections:

• iPhone in portrait
• iPhone in landscape
• Large iPhone in landscape (the 6+ has its own trait collection)
• iPad in portrait
• iPad in landscape

Assets still need to be exported at different sizes, although you can get around that by using vectors in PDF and letting Xcode render the resulting images (this is the workflow we are moving towards).

It behooves you to watch all of the WWDC material around adaptivity. You get a lot for free in iOS 8 for universal support of the four collections.

https://developer.apple.com/design/adaptivity/

Smashing Magazine posted a great article on this http://www.smashingmagazine.com/2014/10/15/create-assets-for-multiple-scale-factors/

Also, PaintCode put together the ultimate guide to iphone resolutions. http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions

How you work is really personal preference, but it's now more important than ever to work with vector/svg graphics as much as possible to make your life easier when scaling up/down.

I haven't heard too much yet on how display zoom is handled. We have a few here int he office, but haven't had an opportunity to put it through the ringer.

I'd like to thank you all for your time. This really helped. Marc Edwards + Aaron Sagray Thank you for your explanations on how to design for the iPhone 6/6+.

Nabeel

Hey, this question has been bugging me a lot as well. Am I literally making double/triple the number of comps as I did before? What about the 6/+'s landscape orientation (which behaves as an iPad)? Plus the 6+'s wonky downsampling.

Need to rethink our whole workflow really, or triple the size of our design team?

I design at @3x for the iPhone 6+ (1242x2208) and @2x for the iPhone 6 (750x1334)/iPhone 5 (640x1136).

Basically the display zoom feature takes an iPhone 5 resolution and blows it up for the iPhone 6 screen. Not really much to worry about there, but it looks pretty awful.

I've always worked from lowest resolution and scaled up. Scaling down seems to always be difficult unless you're designing with specific integers in mind that you know will look good when scaled down (like 0, 2, 4, etc). As well as when designing at the highest resolution it could make complicated / busy icons look bad when scaled down. A higher resolution icon can show more detail than a lower resolution one can. If you design for the lowest resolution first then scaling up you've already solved for the lowest common denominator. The chances of getting half pixel on an element are a lot less. I know some people that start at 2x because for iOS 1x is almost irrelevant anymore. So maybe starting at 2x and going up should be fine; something that you have to play with. For android start at mDPI (whatever that is for your user base) and scale up or down as needed.