Xcode 6 Size Classes

Question

I would like to ask a question about the highly confusing (at least to me) topic - Size Classes in Xcode 6. I have been trying to get a full understanding of how all this works, but it is still not clear to me.

Before Xcode 6 and the new iPhones, everything was very straightforward. To, Non-Retina and Retina, displays that enabled us to work with always same resolution 320x480 (or 568 for taller devices). Standard and @2x assets made perfect sense. Now however, we have the big ass screens with the same ratio (almost the same), but working area is not the same any more.

Size Classes are supposed to make things possible to fit all of it in one storyboard. But wait.. iPhone 6 uses @2x assets, which, in my understanding, means that the graphics will look smaller on that device than on iPhone 5/5S. And iPhone 6 Plus uses @3x assets, which again aren't gonna look the same. Seems like it is not possible to make, for example, a certain button always be of the same size in relation to, say, full width of the screen. Unless we code that of course, but that would make Size Classes useless.

Am I understanding things correctly or am I missing something? It would be great to hear how you all see it. Maybe you know some good tutorials? I haven't found anything that would explain my doubts.

Thanks in advance!

Answer 1

You can do much of what you're talking about here using a combination of different approaches:

1. Size classes for different types of devices to cover most large-scale changes in UI configuration (for example, differences between iPad and iPhone). You might use this to change whether a sidebar appears or not, for example.

2. Autolayout rules that are specific to individual size classes. You might add different autolayout rules for different size classes in order to tweak the layout (for example, you might switch between a horizontal row of buttons and a stacked column of buttons this way, since you can now have different Autolayout rules for different size classes). This technique is extremely powerful once you realize that you don't need to use the same autolayout rules for all size classes anymore.

3. Asset catalogs to switch out pre-rendered graphics for the different supported resolutions, etc, automatically. Note also that because many older devices don't actually support iOS 8, you don't need to include the really low-res versions anymore unless you need extensive backwards compatibility (and if you do, not all of the size class features are available anyway). I just made a new version of the app that only supports iOS 8, since users on older versions will just get the previous version of the app.

4. Resizable images: you can now specify resizable areas within images in order to control how they get stretched when applied to things like UIButtons, etc, that may change size according to Autolayout rules. (This is a feature Android has had for quite a while, so it's welcome on iOS.) This means that you can make things look good on a wider variety of screen sizes without having as many separate images or as much precise control over the size of the UI elements.

5. Programmatic code in the view controllers to tweak anything that you can't achieve any other way.

While it's true that you don't have quite as fined grained control over which devices show what exact layout with size classes, I found that this wasn't really as big a problem as you might think, as the size classes let your view controllers adapt to different devices very seamlessly. The combination of autolayout and size classes is particularly powerful. And it's actually potentially a good thing, because it means less new manual configuration whenever Apple comes out with a different screen size. It's a bit of a pain right now to convert, but probably worth it in the long run. You just have to think about how you set things up a little bit differently. It is a little bit more like Android, where they have long had to contend with lots of different device screen sizes and resolutions, but it's also the sort of natural evolution of the platform where you can't really precisely design for every single physical device as a practical matter (you should still test on them in the simulator, though).