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.


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 Small Small Medium Large Extra Large Extra Extra Large Extra Extra Extra Large
Title 1 25 26 27 28 30 32 34
Title 2 19 20 21 22 24 26 28
Title 3 17 18 19 20 22 24 26
Headline 14 15 16 17 19 21 23
Body 14 15 16 17 19 21 23
Callout 13 14 15 16 18 20 22
Footnote 12 12 12 13 15 17 19
Caption 1 11 11 11 12 14 16 18
Caption 2 11 11 11 11 13 15 17

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.


For more from Jesse on CI/CD and Fastlane


About The Author

Jesse Black has eight years programming experience that he brings to stable|kernel as a software engineer. His passion for programming stemmed from a love of logic and some tedious paperwork responsibilities working with his family. Inevitably, he decided to write custom software for his family's business Salon Harmony, located in Park Slope, Brooklyn. He has a B.A. in Mathematics from New York University. When he's not working on client solutions for native Android and iOS apps, he enjoys longboarding, television, playing guitar and listening to Phish.