The Current State of Size Classes

Apple introduced size classes in iOS 8, which provide a broad description of horizontal and vertical screen space. These broad descriptions currently only include "Regular" or "Compact" options. The great thing about size classes is that they allow developers to create different versions of layouts which will be used depending on available screen real estate. This means that layouts can be different not only between iPhone and iPad, but also when an app is moved into a split view during iPad multitasking, and the system will automatically apply the correct layout if the available space changes. 

That's a pretty huge benefit, and a great alternative to the manual approaches for doing this in the past. However, the actual breakdown of what size class description is used where is frighteningly arbitrary and makes it hard to really tailor layouts optimally for different devices or contexts.

For example:


• The iPad has the exact same size classes (Regular width, Regular height) when it is in portrait or landscape. So there is no way to use size classes to create different layouts for the iPad depending on orientation. I've worked on multiple apps that needed to change their layout when in landscape vs. portrait on iPad, and today the only way to accomplish that is through manual code workarounds.

• The iPad Pro in landscape 1366 points wide, and has a "Regular" horizontal size class. The iPhone 6s Plus is 736 points wide in landscape and also has a "Regular" horizontal size class. So you cannot use size classes to create a layout that is different on an iPad Pro in landscape and an iPhone 6s Plus in landscape, even though the iPad Pro has about 4 times more screen real estate for displaying information than an iPhone 6s Plus


The ultimate upshot is that, depending on the information a developer wants to display for a certain view, the difference between an iPhone SE and iPhone 6 screen size, or the difference between an iPad and an iPhone 6 Plus sizes may be important enough to warrant different layouts. But size classes, as implemented, do not allow us to consider those differences as significant, and we cannot tailor layouts more specifically than what mostly boils down to "iPhone in portrait", "iPhone in landscape", or "iPad in any orientation."

And as Apple continues to release more devices with more variations in screen sizes, the "Regular" and "Compact" size classes will become even more arbitrary and limiting. 


A Better Future

So what is my wish exactly? I’d settle for simply more size classes and more specific size classes, but what I’d really like as a developer is the ability to specify my own size classes for any given scene in a storyboard. For example, I might like to define one layout for screen space with width between 500 and 700 points, another layout if the width is less than 500 points, and a layout for widths larger than 700 points. Any time the screen dimensions changed (for example, when adjusting the split view ratio on an iPad), UIKit could find the custom size class I defined which intersects with the current dimensions and then apply that set of constraints, fonts, etc. to the current scene.

What I’d really like as a developer is the ability to specify my own size classes for any given scene in a storyboard

This would not only allow developers and designers to create layouts as perfectly tailored for any number of screen sizes as they would like, but it would also be completely future-proof in terms of supporting new device screen sizes and aspect ratios. Current layouts associated with “Regular” and “Compact” size classes will be ignored in the future if there are new size classes such a “Large” or “Mini”, and so any existing apps which use these size classes would see their UI break on new devices with new size classes. But allowing developers to specify layouts for different ranges of screen dimensions would mean that some layout would exist for any new size that is introduced, and while the developer could add in a new custom size class to better tailor to any new devices, at least their existing layouts would be correctly applied in the meantime.

So here's hoping that size classes go from being great in many cases but unusable in others, to being a tool flexible enough to use everywhere.