Dynamic Type on a workout screen: what breaks at 200 percent

A workout screen is the densest surface your app renders. A running clock, a rep count, a load, a set number and a rest countdown, nearly all of it numeric, nearly all of it sitting on a grid you tuned by eye at the default text size. Underneath, a tab bar with six icons and six labels. There is no slack anywhere in that layout, which is why it is the first screen to fall apart when somebody turns text size up.

The legal layer sits in compliance; this page is engineering.

The number Apple asks for#

Apple's Human Interface Guidelines put a figure on it: "Ideally, give people the option to enlarge text by at least 200 percent (or 140 percent in watchOS apps)." Apple gives two routes to that figure — "Your interface can support font size enlargement either through custom UI, or by adopting Dynamic Type" — and describes the setting as "a systemwide setting that lets people adjust the size of text for comfort and legibility."

Read 200 percent as a layout target, not a typography one. Doubling text in a paragraph of prose is cheap: the paragraph gets taller and the page scrolls. Doubling text in a row that holds a timer, a rep count and a weight side by side is not a typography change at all. It is a different layout, and somebody has to design it.

What breaks, in the order it breaks#

None of these are exotic. Each is a decision that makes a dense screen look good at the default size, and each is a bet that the text stays the size you drew it.

A fixed-height row is usually there to make a list look even. It costs nothing until the text inside it grows, at which point the row is a window onto text that is bigger than the window. The user does not see a typography problem, they see a rep count with its top cut off.

Set a minimum height if you want the rhythm and let the maximum follow the content. The list stops being perfectly even at large sizes. That is the correct trade.

Stack the row, and never truncate the value#

Horizontal groups of numerics are the real work. Timer, reps and weight in one row is three competing demands on the same width; at large sizes the width does not stretch, so something has to give.

The fix is to stack. Above some size threshold the row becomes a column: the timer on its own line, then reps, then load, each with its label above or beside it. Our judgement, not Apple's statement: pick the threshold by opening the screen at every size the platform offers and finding the first one where two values touch, then stack one step earlier. Do not pick it by reading a number off a spec.

Two things to watch. Scroll position matters more, because the screen that used to fit now does not, and the value needed mid-set must not sit below the fold. A stacked layout also moves the buttons, and a control that shifts under the thumb between sets is one somebody mis-taps.

Truncation, meanwhile, is silent data corruption. A label that reads Aver… is untidy. A weight that reads 1,2… is wrong, and wrong invisibly, because a truncated number still looks like a number.

The rule needs no platform fact behind it: the value never truncates. If something on that line has to give, it is the label. Shorten it, move it, or drop it, in that order. If both the value and its label genuinely cannot fit even after stacking, the row is carrying too much and the screen needs a design decision rather than a text-layout trick.

Thin weights fail first#

Fitness apps love an ultralight numeral for the hero timer. It photographs well and it is the single most fragile choice on the screen.

Apple is direct about it: "Thicker weights are easier to read for smaller font sizes. Consider increasing the font size when using a thin weight." Note what that costs you. If you keep the thin weight, Apple's own advice is to spend more size on it, and size is exactly the budget you were trying to protect. The compact ultralight number that fits three metrics in a row is not compact once you have followed the guidance for it.

Thin weights are also the pairing that dies in daylight, because a hairline stroke has less area to carry whatever contrast you have. If your hero numerals are ultralight and your background is a photograph, you have two problems and they multiply.

The watch has its own number#

Apple's figure for watchOS is 140 percent rather than 200 percent, in the same sentence. Lower ceiling, much smaller canvas, and a glance rather than a read. The practical effect is that a watch screen can afford roughly one primary value and one secondary one, and the stacking decision you deferred on the phone is made for you here. The anatomy of a watchOS workout app covers what else the wrist changes, and the watch cluster covers construction.

Android: sp, and where our evidence stops#

Google's accessibility guidance states its contrast thresholds in sp: "If the text is smaller than 18sp, or if the text is bold and smaller than 14sp, use foreground and background colors that result in a color contrast ratio of at least 4.5:1. For all other text, set the color contrast ratio to at least 3:1."

That is the whole of what the Google pages we fetched this session say about sp. We did not verify Android's maximum text scale, the name or location of the user-facing setting, or any API for reacting to a change in it, so this page does not describe them. Check Google's current documentation before you write that branch.

What does carry across without any platform claim is the structure. A layout that survives Apple's 200 percent is one whose rows grow, whose values never truncate and whose horizontal groups can become vertical. Build it that way once and the Android target inherits it. The mechanics of building the same screen twice are in the Android tracking guide.

Monday morning#

Set text size to the largest your device offers, open the live workout screen, and photograph it. Do the same at the largest size on the watch. Then work the list: every fixed height, every truncation applied to a value rather than a label, every horizontal group of two or more numerics, every ultralight numeral.

Apple's Accessibility Inspector is the tool for the audit pass — Apple describes it as a way to "display, query, and test accessibility information for the elements in your app's view hierarchy" and adds: "Audit your app to confirm that it addresses accessibility issues such as clipped text and unlabeled elements, and uses appropriate text size and color contrast levels." Clipped text is precisely the failure this page is about. Put that pass in the rotation described in device lab and CI: the row that fits today is the row somebody adds a third metric to next sprint.