iOS 10 is the third version to allow users to specify a size preference under Accessibility: Larger Text. Apple usually gives a runway of 6 months up to a year before they start forcing developers into supporting a new feature. At this point, it seems like it will always be optional for developers to respect this setting. When iOS 7 was released, the overhead of supporting the Larger Text settings could be a little overwhelming, especially if you had not yet made the leap to Auto Layout. That was 3 years ago, so let’s address some of the initial concerns with supporting this setting:

  • Effort: It is a lot more work than supporting the Font Size preference in Android.
  • Design: I don’t want to design my UI for the 7 main sizes, let alone the 5 additional sizes when Larger Accessibility Sizes is toggled on.
  • Testability: It is difficult to test. I have to switch to settings, and then the phone restarts before I can get back into my app.
  • Customization: My app uses custom fonts, so it will take extra effort to support Larger Text.


override func viewDidLoad() {


override func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?) {

private func configureFonts() {
    myTitleLabel.font = UIFont.preferredFont(forTextStyle: .title1)
    myHeadlineLabel.font = UIFont.preferredFont(forTextStyle: .headline)
    myBodyLabel.font = UIFont.preferredFont(forTextStyle: .body)

There is no denying it; this is quite a bit more work than simply using sp instead of dp in the layout xml for Android. The additional effort isn’t enough to justify skipping the support. That is the case with other concepts that are easier in Android: styles, themes and localization. We tend to do our styling and localization in code, taking on the extra up front effort for the ease of change down the road.


New call-to-action



It is a valid concern to worry about how this will affect the app design. We know how much effort designers put into choosing font families, font weights and point sizes. A quick look at the point size variations for a text style across content size categories should help dismiss that concern:

Extra SmallSmallMediumLargeExtra LargeExtra Extra LargeExtra Extra Extra Large
Title 125262728303234
Title 219202122242628
Title 317181920222426
Caption 111111112141618
Caption 211111111131517

Related: Illustrator UX Workflow Tips for Wireframing and Design

A few things to note here:

  • The largest gap between the Extra Small and Extra Extra Extra Large category is 9 points.
  • The largest scale multiplier from Extra Small to XXX Large is x1.69.
  • Some of the Text Styles don’t even change sizes at the lower and higher ends of the settings.

These changes are a lot less drastic than I would have guessed. If you take on the perspective of the Large setting being the default, the degrees of change are even less drastic when comparing the smallest to Large and the largest to Large.

Things get a little more intense when you start to bring in the accessibility sizes:

  • Accessibility Medium
  • Accessibility Large
  • Accessibility Extra Large
  • Accessibility Extra Extra Large
  • Accessibility Extra Extra Extra Large

The names alone are atrocious. Luckily, the Body is the only text style that changes from XXX Large to Accessibility XXX Large. It grows an additional 20 points. I posit that it is okay to have your UI fall to pieces when supporting the additional Accessibility size categories, as long as the UX remains clear. It is unfeasible to have a UI that looks great when the Body text can range anywhere from 14 to 53 points.

Perfect your designs for the Large category, and then test and tweak for the Extra Small and Extra Extra Extra Large categories.


The size variations laid out in the previous section could still seem alarming. Sometimes, it takes seeing it in action to quell the fear. The Accessibility Inspector, included in Xcode under Developer Tools, makes seeing the changes a breeze. You can run your app on various simulators and devices and change the underlying preferred content size by using the Accessibility Inspector.


Look at that body go!



If you are in the habit of styling your views in code, supporting Larger Text using a custom font doesn’t add too much complexity. You will need to do two things: update your styling code to respect UIApplication.shared.preferredContentSizeCategory or traitCollection.preferredContentSizeCategory and override traitCollectionDidChange(_:). Work with a designer to choose appropriate UIFontDescriptor values for each style and category size combo. The built-in system fonts serve as a great guide; Apple provides weight, leading, tracking and point size details in the iOS H.I.G. Here is an example lookup table for one custom font from a WWDC 2016 video, Typography and Fonts:

let customDynamicType: [UIContentSizeCategory: (pointSize: CGFloat, styleName: String,
    leading: CGFloat,  tracking: CGFloat)] = [
        .extraSmall:                        (10.0, "Heavy",  3.0, 0.6),
        .small:                             (12.0, "Heavy",  2.0, 0.4),
        .medium:                            (14.0, "Roman",  1.0, 0.2),
        .large:                             (14.0, "Roman",  0.0, 0.0),
        .unspecified:                       (16.0, "Roman",  0.0, 0.0),
        .extraLarge:                        (17.0, "Roman",  0.0, 0.0),
        .extraExtraLarge:                   (18.0, "Light",  -1.0, 0.0),
        .extraExtraExtraLarge:              (19.0, "Light",  -2.0, -0.1),
        .accessibilityMedium:               (20.0, "Light",  -3.0, -0.2),
        .accessibilityLarge:                (21.0, "Light",  -4.0, -0.2),
        .accessibilityExtraLarge:           (22.0, "Light",  -4.0, -0.2),
        .accessibilityExtraExtraLarge:      (23.0, "Light",  -4.0, -0.2),
        .accessibilityExtraExtraExtraLarge: (24.0, "Light",  -4.0, -0.2)

For the most part, supporting Larger Text is a straightforward programming task. Auto Layout softens the difficulties in making sure your layout doesn’t break. It may seem daunting to create lookup tables for custom text styles, but you can study the patterns Apple uses or partner up with a designer and create some great typography.

Jesse Black

Software Architect at Stable Kernel

Leave a Reply

Your email address will not be published. Required fields are marked *