System controls are deeply bound to Dynamic Type
Aliases: Dynamic Type · content size category · text styles · preferred font
What it is
Apple exposes type size as a user-level content size category, and interface copy as named text styles (body, headline, footnote, caption). System controls—labels, buttons, cells, navigation titles—subscribe to those styles by default. When the user enlarges text in Settings, subscribed controls grow with it and the layout reflows from their intrinsic content size. That coupling is Dynamic Type binding: the control is not “using a point size,” it is attached to a live channel driven by the user’s preference.
The question it answers is why system controls can grow with accessibility text settings, not whether system controls should be used so the app “looks native.” A custom draw that hard-codes 17 pt, text baked into a bitmap, or a cell with a fixed height has unplugged itself from the channel.
Why it happens
The binding works because size is not a pixel stored on the control; it is looked up as style role × current category. The same Body style yields different point sizes at the default category and at accessibility sizes; line height and tracking follow the style table as well. A system control reports the height it needs through intrinsic content size, and Auto Layout or a stack shifts its neighbors—when type grows, what changes is the demand the control itself reports, not a height the designer pre-drew.
A custom typeface rejoins the channel only if it opts into category scaling and requests layout again when the category changes. The moment height becomes a constant, the moment copy is rasterized into an icon, the moment truncation is used to “keep the card one line tall,” the channel is cut: the slider in Settings still moves, this surface can no longer hear it. Titles inside system containers (navigation bars, tab bars, section headers) also ride text styles; replacing them with a fixed-size custom view opens a deaf enclave inside the system chrome.
Where it stops holding
Illustration, wordmarks, and marketing covers that must keep a fixed visual cadence should not subscribe to Body; the mark would distort as accessibility text grows. Game HUDs and camera overlays that pin controls to a composition will have aiming broken by large type and need a separate legibility strategy. Watch and some spatial surfaces map the same style names onto different absolute sizes; values must not be copied across devices. An interface checked only at the default category cannot reveal whether the binding is live—failures live in the tail of the category range, not on the size used in mockups.
Applying it
- Use system text styles instead of hard-coded point sizes. If a custom typeface is required, scale it with the content size category and invalidate constraints when the category changes.
- Let labels, buttons, and cells grow and wrap from intrinsic content size. Treat “must stay one line” as a rare exception and inspect it at the largest accessibility category to see whether truncation eats meaning.
- Do not paint captions into bitmaps or freeze them in a fixed-height decorative bar. Keep navigation and list titles in system containers rather than swapping in views that do not subscribe.
- Verify by dragging Settings from the default category to the largest accessibility size and walking lists, forms, navigation titles, and buttons. Any clipping, overlap, verb lost to a single line, or body text that grew while buttons stayed put means that control is off the channel. Then restore the default category and confirm the layout collapses, rather than leaving holes from the enlarged pass.