A Preliminary Look at iOS 8 Size Classes

iOS8's new feature, Size Classes, is a new abstraction of the old UI idea: abstracting the screens of various devices (iphone4, 5, 6, ipad, iwatch?) and their screen rotation states into changes in screen size, and grouping these sizes into several classes.

Width (normal, arbitrary, compact), Height (normal, arbitrary, compact)

There are 9 sizes in 3x3. Each size can be set with a specific set of layouts. If not specified, the default is set in (arbitrary width, arbitrary height) mode, and the other 8 layouts inherit it.

I have heard people say that we don’t need to learn AutoLayout and can just learn Size Class directly. This is wrong because after Size Class classifies the screen, it is still AutoLayout that performs the layout.

Size Classes and Interface Builder

Of course, as expected, Interface Builder in Xcode6 has strong support for Size Class:

After enabling Size Class, a menu for switching Size Class will appear in IB

We can switch to wAny, hAny mode to edit common controls and layouts, or switch to a specific Class to preview the changes immediately, so here is a question:

If the layouts of iPad and iPhone are different, the old way of writing is to write them separately in ipad.storyboard and iphone.storyboard. This is a bug in itself, because most of the controls are actually the same. Does the new Size Class solve this problem?

The answer is yes. The Size Class solution is much better than the old one:

In IB, the appearance of a certain View, the appearance of a constraint, and the value of the constraint can all be set individually according to the Size Class, which means that now a storyboard is 9 in 1.

For example, there is a Label below, and I only want it to appear when the screen is compacted (think iwatch), so just check this box (the appearance or non-appearance is named "Installed", and this option can be selected from 9 Size Classes)

Size Classes XML file changes

When it comes to 9-in-1, there will definitely be questions: Will the storyboard file be very large? Will the source file be very messy, causing frequent conflicts when multiple people are developing?

The answer is no, because Apple's description of the Size Class in XML is for variable configuration. What does this mean? You can see it by comparing the storyboard's XML source file:

The page with only one Label in wAny and hAny modes:

If the label is not displayed in wC or hC compression mode, the following configuration appears at the parent view level of the label:

Therefore, IB uses an additional description field to indicate which elements are included or excluded by which Size Class. It is precisely because of this description method that the new XML format can be compatible with lower versions (lower versions do not parse this field, but other fields are parsed normally)

Size Classes and xcassets

Since storyboard has become 9-in-1, the corresponding xcassets must also be represented. After Xcode6, when adding pictures to xcassets, a menu for selecting corresponding Size Classes is added. After expanding, it will be like this:

It is indeed good to express it through symbols - corresponds to tightening, * corresponds to Any, and + corresponds to loose

(@3x is iPhone 6 plus)

Summarize

In general, iOS's changes to the UI are epoch-making. The emergence of Autolayout reduces the complexity of layout to the relationship between Views, and then the root View (that is, the screen) specifies the frame. Then all sub-Views are relatively laid out, normalizing the concept of frame to the frame of the root View. But with Size Class, the concept of the root view's frame is also removed. Now the entire app's UI is no longer related to the word frame, which is exactly what Apple wants to achieve.

Farewell, frame, and those iOS coders who are still struggling with handwritten UI…