Dynamic Typography & Adaptive Layouts

Written by: on August 7, 2017

Apple has set an example that accessibility should be a natural, integrated part of iOS. They turned accessibility into a competitive advantage. If doing the right thing isn’t motivation enough, following Apple’s lead and building inclusively means your app can be enjoyed by more users. Head over to apple.com/accessibility and watch some of the great videos there to get a sense of how important being inclusive is to Apple.

According to the World Health Organization, about 4% of the population have low vision, and 0.6% are blind. Around age 40, many people develop a form of age-related farsightedness called presbyopia. Statistically, the fastest growing part of your user base is people 60 years of age and older, and about 50% of those people have some sort of visual impairment. Low vision isn’t binary, there is a continuum of impairments between 20/20 vision and blindness. When we design for inclusivity, we’re designing for everyone, not just people with difficult visual impairments.

Accessibility is a broad topic, and Apple categorizes accessibility features into Vision, Hearing, Physical and Motor Skills, and Learning and Literacy. We will be taking a look at Font Adjustments in the Vision category, which includes technologies like VoiceOver, Siri, Dictation, and Magnifier.

Font Adjustments describes a user-facing feature. In Settings, users can increase the system text size, and “Apps that support Dynamic Type will adjust to your preferred reading size below.”

iOS is a little late to offer the necessary tools to enable developers to build apps that respond to text size changes. Despite the platform having won awards for features like VoiceOver, the state of text sizing is poor. This year in iOS 11, Apple is rolling out better text sizing in all of the default applications like Calendar and Music, and they plan to continue on that path with all of their apps. While Apple is modernizing their apps, many third-party apps like Wimbledon do not respond to Dynamic Type yet.

Before we dig into the technical aspects of wrangling type on iOS, let’s recap how we got here with a brief history of digital typography on the Mac and iPhone, and make some connections between typography and inclusivity.

Typography

Digital typography has a rich history on Apple computers. Apple liberated typography from the confines of type design studios and print shops with the introduction of the Mac in 1984, which is the first personal computer to offer font choices in programs like MacWrite.

Apple developed the TrueType font standard which shipped with Mac System 7 in 1991. TrueType was a revolutionary advancement in digital typography that enabled scaling—in TrueType, glyphs are constructed from a geometric blueprint rather than bitmapped pixels. Steve Jobs played an integral part in advancing digital typography in his time at NeXT, which Apple acquired when Jobs rejoined Apple.

Fast-forward to 2007, and TrueType is built into the first iPhone, and Helvetica is selected as the system typeface. Helvetica has a simplicity and classic neutrality that paired well with the iPhone design aesthetic. Custom font support was introduced with iOS 3.2 in 2010, enabling designers to inject style and branding queues into their app designs. Through iOS 6, iOS layouts are generally static, which worked for the skeuomorphic designs that were popular at the time, and text sizing had not been introduced yet.

Meanwhile on the web, a CSS renaissance happened in the mid 2000’s which leads to Ethan Marcotte coining the phrase Responsive Web Design in 2010. Web designers learned how to build layouts that could adapt to changing viewport and text sizes.

Despite Apple’s history of innovations in typography, they had work to do in iOS layout and type sizing capabilities to catch up with web. Beginning with Auto Layout in iOS 6, Apple introduced a series of supporting features that culminated in Dynamic Type and Adaptive Layouts.

Dynamic Type

Dynamic Type describes a framework that supports system-wide text size changes that third-party app developers can integrate into their apps. This feature is available in Settings, and in iOS 11 you can add a Control Center control that makes testing apps easier.

Another great way to test Dynamic Type is with the Accessibility Inspector tool that can be found in Xcode > Open Developer Tool > Accessibility Inspector. It works with both the simulator and devices. Be sure to select the device you want to inspect in the dropdown.

Using Dynamic Type means setting up fonts with Text Styles. Text Styles are a set of semantic names that describe how the font will be used. Here are the Text Styles available today, along with the size at the default Large user setting, and when used with the San Francisco font, the leading and tracking values.

When the user changes the system text size, a new UIContentSizeCategory is indicated in code, and the set of sizes for each Text Style is larger or smaller depending on their selection.

This is the code you write to specify a font with the Title 1 Text Style.

let font = UIFont.preferredFont(forTextStyle: .title1)

And in iOS 11 if you set that font on a UILabel, and set adjustsFontForContentSizeCategory to true the text in the label will respond to changes in UIContentSizeCategory automatically. Previously you had to listen to an NSNotification and then update controls manually.

These new APIs play very nicely with the new default UITableView setting for self-sizing cells. With very little code, as long as your cells fully define a height with Auto Layout, you can have a table view set up with Dynamic Type that automatically reflows text after system text size change events.

Each of the Text Styles increase in size at a different rate. Titles increase slower than body text does to prevent them from becoming overwhelming at very large sizes. At the largest accessibility settings, title text doesn’t appear very much larger than body text.

With iOS 11, new APIs are available to tie custom fonts into Dynamic Type. UIFontMetrics can return a new instance of a custom dynamic font which also works with the adjustsFontForContentSizeCategory setting on UIKit controls.

It’s important to base the custom font size on what it should look like at the Large default content size setting, because from there it will scale up or down proportionate to the behavior of its Text Style. Here’s an example of custom font scaling in action from the demo app on GitHub. Note how the body font scales more quickly than the title.

UIFontMetrics can also provide us with scaled values that we can use in updating layout constraints.

This is a good time to point out a new Auto Layout constraint available in iOS 11 that’s helpful in laying out text with Dynamic Type. We activate this constraint in the demo project defining the relationship between title label and body label. When we use constraintEqualToSystemSpacingBelow(_:multiplier:), the system automatically spaces the title label and body label so that at larger text sizes, the labels do not grow into each other.

Both the automatic font adjustment control setting and the system spacing constant constraint are available in Interface Builder via “Automatically Adjusts Font” and “Use Standard Value” respectively.

When you select San Francisco as your typeface for Dynamic Type with preferredFont(forTextStyle:), you get Apple’s finely-tuned leading and tracking values applied to your fonts. San Francisco is a mobile-first family of fonts that’s been actively designed for legibility on Apple’s devices. Included are Text and Display optical variants. The Text variant is optimized for legibility at smaller sizes with larger margins and apertures. At 20 points and above, iOS automatically selects the Display variant, which is tuned for larger, shorter elements like titles.

Did you know that all iOS developers are typographers? Typography is the practice of picking fonts, choosing styles, selecting typographical features, and applying those in layouts. Typography is a very developer-friendly aspect of interface design that’s a natural place where designers and developers can meet in the middle so to speak.

One of the less technical aspects of typography is type pairing. The practice is a lot like wine pairing, in that there are some basic guidelines you can follow to do a pretty good job, and San Francisco is neutral enough that pairing it with fonts that have more character for elements such as titles goes a long way. Just like wine paring, it can get esoteric in certain circles, but that doesn’t mean we can’t all participate!

Adaptive Layouts

Design is about elegantly solving for a set of problems—it’s about searching for the truest solution that improves how we experience the world around us. Steve Jobs said, “Design is not just what it looks like and feels like. Design is how it works.” Before we embark on a design, it’s important to thoroughly understand the problem space it should solve for.

When we design interfaces for iOS, we have to answer several questions.

  • What happens when the viewport size changes?
  • What happens when content exceeds its container?
  • What happens when text size increases via Dynamic Type?
  • What text should grow?
  • Does the layout need to change to accommodate text or viewport size changes?

Another Steve, Steve Ballmer, famously said, “Accessible design is good design.” And he’s right! An iOS design that doesn’t adequately address accessibility hasn’t solved for the complete problem that the platform presents.

Let’s talk about some techniques we can use to design and build layouts around dynamic type. It’s a design exercise to determine how text should behave when it outgrows its bounding box. Recall the tennis scorecard from earlier? How might we get started correcting the issues in that design? We can begin by deciding what content should adapt to type size changes, and how it should adapt. Consider this simplified layout from the demo app.

When text size increases, the player names are going to push into the scores. And the match status line at the bottom is likely to exceed the width of the view. One of the best ways to accommodate content size increases is to reflow horizontal content vertically.

Just as a calendar has a canonical layout, the tennis score line needs to be horizontally oriented to match fans’ expectations, so we can’t lay the scores out vertically. What we can do is put the names above the scores when the text size passes a predefined threshold.

Now we are accommodating the accessibility-sized player names, and we maintain the scoreline as it’s expected to be formatted.

We decided that the match status line was less important than the other content, and sometimes it’s appropriate for secondary content not to participate in Dynamic Type. Be careful about making that judgment, though. Most of the time, you want to offer the same content to all of your users, and this example is contrived to demonstrate that you have a choice to make. Another choice we made is that if the player name exceeds the horizontal space available after we reflowed the layout vertically, that we would then truncate the player names.

Alternatively, we could have set a Minimum Font Scale, which is a threshold that defines how much we will downscale the font size before truncation begins. This results in the first line having a larger text size than the second line to avoid truncation.

When scaling text sizes, remember that the user has expressed that they are comfortable at a particular size, and you are rendering text contrary to that choice. When deciding how text and layouts should behave, we have to carefully consider what tools to employ. Here’s the complete view demonstrating text size changes.

Now let’s see how a visually impaired user might experience our layout at default text size vs. the largest accessibility size. The top cell is rendered at the default text size and it’s totally illegible, while we can read the bottom scores.

This is fairly complex behavior considering how easy it is to build. UIStackView is a great tool for reflowing layouts from horizontal to vertical. By simply adjusting the axis property, we can rearrange content in response to UIContentSizeCategory trait collection changes. The player names and score grid are in a horizontal stack view to begin with. Then we change the axis to vertical when the preferred content size category is greater than xxxLarge.

If our layout didn’t use stack views, we could activate and deactivate constraints and achieve the same level of control.

Apart from making layout adjustments, we used the Dynamic Type tools discussed earlier to either set standard system fonts or dynamic fonts according to the behavior we want. We also set properties on our labels to determine the line break mode, minimum scale factor, and number of lines.

The phrase “Adaptive Layouts” was coined at WWDC 2014 with iOS 8. Usually it takes a couple years before a new iOS technology has all the kinks worked out, and the feasibility of building Adaptive Layouts with all the supporting technology really comes together two years later with iOS 10, which includes UI elements that automatically react to text size changes, and the adding of preferredContentSizeCategory to UITraitCollection.

I recall when I worked in front-end web development, even without inspecting a web page’s source code, that I could instinctively tell whether it was going to respond to my text size and viewport changes gracefully. If you use and build with Dynamic Type, you’ll develop a similar instinct for native apps.

The view layer of iOS is getting more complex each year, and the difficulty of keeping up with the entire platform is starting to show. Not unlike what has happened on web, we’ll likely see an increasing need for specialists—people who are very skilled at a subset of iOS development, such as Adaptive Layouts and other accessibility concerns.

Build Inclusively!

If you set larger font sizes in Settings today, you’ll experience a hodgepodge of support across third-party apps. Dynamic Type is profoundly important to your users, and we have a responsibility to advocate for, design, and build inclusive apps.

For more resources on the topics we have covered, check out these WWDC sessions.

Sean Coleman

Sean Coleman

Sean Coleman is a Technology Lead at POSSIBLE Mobile where he leads multi-platform projects with large teams for well-known brands. Outside of writing native apps for Apple platforms you’ll find Sean playing with his two kids or hitting balls on the tennis court.

Article


Add your voice to the discussion: