As you may know, there are more and more devices working under the iOS system. Differences in their sizes may cause problems connected with adjusting the elements’ size while creating an application. To make it all easier, Apple introduced so-called Size Classes which allow distinguishing the device’s size we’re dealing with.
1. What are Size Classes?
Both iPad and iPhone enable changing the orientation from vertical to horizontal which comes with simultaneous alteration of width and height. It means that the value which was a width before changes into height and vice versa. Size Classes help recognize what kind of case we’re dealing with. There are some features that allow us to establish if the current size is regular or compact. The regular value defines a vast space, and compact a limited one. The size can consist of one of the combinations:
- Width regular, height regular
- Width regular, height compact
- Width compact, height regular
- Width compact, height regular
This approach allows reducing all the brainstorming connected with placing the interface’s elements to four cases only — we aren’t bothered with factors such as: resolution, kind of device, or orientation. A well prepared Size Classes solution results in the app’s predictability and compatibility with previous establishments on every iOS system device.
2. Size Classes’ behaviour on iPads and iPhones
Defaultly, in case of iPhones, the device’s height is defined as regular and its width as compact. For iPads both values are regular. It gets a little bit complicated when the device’s orientation changes into vertical. It’s well described in Pic. 1. Smaller devices both values are compact, whereas bigger iPhones have regular width and compact height. iPads’ are still both regular. It allows planning the interface’s combination easily depending on the current Size Classes.
Additionally, iPads allow launching several applications in a divided view with dedicated 3 liminal values that can change the Size Classes: ⅓, ½ and ⅔ of the screen’s width occupied by an app. The apps can be smoothly narrowed down and broadened, adjusted perfectly to our needs. Depending on the device and a part of the screen’s occupancy, an operating system decides if the width is regular or compact. As a result, the app is displayed in the same manner as on iPhones’ portrait orientation — compact width, regular height.
3. Using Size Classes in the Interface Builder
When it comes to interface configuration according to particular Size Classes, the Interface Builder gives us two possibilities. We can, for example, configure varied behaviours for an applied font, its color, the color of the background, or, what’s the most important, the constraints. Clicking the “+” icon next to chosen features allows adjusting them in a random width and height combination. Thus, the view looks good on both iPhone and iPad with elements’ configuration and font size adjusted to the interface depending on the Gamut value — color space available for the device. It allows setting the colors that combine with broader color palette and are reflected better on the screen which supports such possibilities.
Using Interface Builder, we can check the behaviour of different interface elements on varied devices and orientations and implement the changes according to previous establishments in case of problems at any time.
In the simplest case — to achieve the same application’s look on iPad and iPhone in vertical orientation and a different one on iPhone in horizontal orientation, we can focus on the fact that it’s the only situation with the compact value of height. Similarly, if other interface elements’ setting is only for iPhone in vertical orientation, it’s valid that the width is compact and the height is regular at the same time.
4. Using Size Classes in code
If we want to use Size Classes in the code, we should implement the traitCollection value available in every UIView and UIViewController object. It consists of information about current vertical and horizontal Size Class value. Responding to changes occurring in current values implies overstraining the traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) method which is called out every time when traitCollection changes. At this moment, it’s worth updating the constraints so they adjust to the new sizes and arrange the interface elements properly.
Unfortunately, creating views from code is not as smooth as in Interface Builder. This time, if we want to obtain various effects for various Size Classes, we need to create separate constraints for particular cases and change their isActive attribute according to previous establishments. This way, only those adequate for current width and height values are active.
5. Why should we know all that?
Most of all, the information above allows creating applications that behave predictably on all devices they were prepared for. Thanks to the Size Classes, we don’t have to worry about varied devices’ sizes. We should only consider four cases for which the height and width can be either regular or compact. It’s also an easy way to configure the app’s look without the need of implementing many valid changes, and the effects are visible on different devices at any time.
