Dynamic Type

iOS has a lot of tools that help us make our apps easy to use and approachable, but did you know how easy it is to make your apps accessible to more people? In this post we’ll examine one of the accessibility features of iOS: Dynamic Type. We’ll see how supporting it is actually quite easy – and probably benefits more people than you think.

Our mobile devices are deeply personal. This applies to the way we use them as well. How you use your device is quite likely very different to the way anyone else does. It’s important to remember not everyone chooses, or is able, to use a device the same way you do. Some people will prefer a bigger or smaller font than you, and some will not be able to read the text on the screen at all unless it is made much larger. Supporting dynamic type will make a huge difference in your app’s usability for these people. In some cases, you will enable people to use your app who may never have been able to use it at all. The great news is supporting this is easy, especially if you start early on in your project.

Dynamic Type

Dynamic type allows people to adjust the system-wide font size. Find it in Settings → Display & Brightness → Text Size. There is also an option to further increase the sizes for accessibility users in the Accessibility settings.

Three examples of dynamic type sizes. Your app will need to cope with them all. The setting is available in Settings → General → Accessibility → Larger Text

Three examples of dynamic type sizes. Your app will need to cope with them all. The setting is available in Settings → General → Accessibility → Larger Text

Dynamic type is important to keep in mind when designing your app so that your interface stays usable throughout all the sizes. For a breakdown of the different sizes, see the typography section in the iOS Human Interface Guidelines. It’s not uncommon to design and implement a beautiful, functional app but at the last minute realise it’s broken with an increased font size. When the app is released and runs on a device with a large font size the interface may not even work! Imagine downloading an app and finding it won’t work simply because you changed the font size! Here’s a little example showing what can go wrong if you fail to take into account the need for dynamic type:

Failing to support dynamic type can result in a completely unusable app. As the font size increases, the text boxes are merging with each other rendering both illegible and useless.


The simplest way to start with dynamic type is to use the built in styles that come with iOS. In Interface Builder, just select a text style from the drop down. You may already be doing this!

Choose a built in text style from the drop down to get dynamic type support right away.

Choose a built in text style from the drop down to get dynamic type support right away.

Or in code:

let headingFont = UIFont.preferredFont(forTextStyle: .headline)
let bodyFont = UIFont.preferredFont(forTextStyle: .body)

If you check the Automatically Adjusts Fonts option, your label will automatically adjust its font size as the user changes the size in Settings. If you don’t check this, your app will need to restart to update its appearance for the new size. In code this is adjustsFontForCategorySizeCategory = true. This property comes from the UIContentSizeCategoryAdjusting protocol adopted by UILabel, UITextField and UITextView.

iOS will post a notification when the preferred content size setting changes. You can use this to refresh the other parts of your user interface which don’t update automatically.

UILabels will adjust their intrinsic sizes as they need to make room. Make sure you have your constraints configured to allow for changes in the labels’ sizes. Adjusting the numberOfLines property will allow a label to expand to more lines (or just set it to 0 to allow it to take up all the lines it needs).

You can allow your label to shrink its font size to keep things fitting: set adjustsFontSizeToFitWidth to true and adjust the minimumScaleFactor. Don’t do this unless you really need to! Remember: there is a reason for the system font size. It’s not there as an aesthetic preference, but because that is what makes using the device possible.

Custom typefaces

We can’t always use the built-in styles. Many of us will want to use custom typefaces in our apps. We can still do this without throwing away the important benefits dynamic type brings! If you’re targeting iOS 11 or above, use UIFontMetrics to help. Here’s how you might use it for Gill Sans:

if let gillSans = UIFont(name: "GillSans", size: 17) {
    myLabel.font = UIFontMetrics(forTextStyle: .body).scaledFont(for: gillSans)

Unlike the system fonts, this must be done in code. To keep things organised, you should extract your typography code. You may even want to use a library like BonMot, or Swash, which have support for dynamic type built in.

Testing your Dynamic Type

Accessibility Inspector

The Accessibility Inspector is a fabulous help! It’s built into Xcode. To open it, go to the Xcode Menu → Open Developer Tool → Accessibility Inspector.

From there, you can connect it to your app running in the simulator. You can use it to change font sizes and see how your app responds. It’s also a good opportunity to test how your design will look for users who have turned on reduced transparency, motion and inverted colours. These accessibility features are just as important!

When dynamic type is supported correctly, the interface stays usable throughout all font sizes


Reveal is especially useful while testing your app as well. You can use it to inspect and edit constraints while the app is running. This will allow you to find and fix any layout issues that arise as you scale your fonts.

Colour blindness

In your design, how much emphasis are you putting on colour? While we’re on the topic of designing for dynamic type, we should touch on colour blindness. Colour blindness, or colour vision deficiency, is a common condition found in 8% of males and 0.4% of females. People who are colourblind can’t see some colours or see them differently to other people. Colours that are easily differentiable to you may not be to everyone. Put simply: never rely on colour to make your app usable.

iOS provides colour filter to help you test your app for this. On a device, go to Settings → General → Accessibility → Display Accommodations. From there, you can add colour filters that apply to your entire device. Perfect for simulating how people who are colourblind will see your app. (Interestingly, screenshots do not have the filters applied — keep that in mind if sending a bug report.)

On a device, go to Settings → General → Accessibility → Display Accommodations and add a filter. This will help you see how your app looks to people who are colourblind

On a device, go to Settings → General → Accessibility → Display Accommodations and add a filter. This will help you see how your app looks to people who are colourblind

For designers, there are a number of tools and plugins to help you design for colour blindness. Stark is a plugin for Sketch which helps not just with colour blindness, but also contrast. Skala Preview from Bjango will help you to test your designs on device, and has built-in support for colour blindness testing.


Finally, I want to encourage you to think about the accessibility of your product from the very start. It’s not something you can add at the end just before you ship ‘if you get the time’. We all know better: you will not get the time.

Accessibility must be considered as part of every stage of the project. We already work testability into everything we do, why can’t we do this accessibility as well? Make a point of it when planning, and when estimating. Consider how it will be tested. Keep it in your mind and work it into each task you do.

Don’t do it as a separate job at the end of the sprint. Good design cannot be sprinkled over the top of a project once it’s over, and neither can accessibility. Good design must include all people. For the small amount of work it is, you will make a big difference to many people’s lives. And as I hope I’ve shown you, it’s not difficult!

In future blog posts, we shall explore more of the accessibility features in iOS. In particular: VoiceOver, the iOS screen-reader. VoiceOver takes visual accessibility further and focuses on people who may not be able to see or touch the screen. While a little more involved, we’ll see once you get started it’s very straightforward.

Further Reading

Written by
Huw Rowlands — Huw is a iOS Developer at Itty Bitty Apps. You can follow him on Twitter @huwr.