I was cleaning up the UI on a side-project iOS app and did one thing: set Dynamic Type to XXXL and screenshot every screen.
Reading the code had turned up nothing.
The screenshots showed problems immediately.
Eleven of them, in the end.
All the same cause.
Here's the conclusion first. "A parent that pins things side by side" × "text that grows" is not a bug, it's a pattern.
And in Japanese it breaks reliably worse than in English.
English truncates.
Japanese stacks vertically.
Same layout, different failure depending on language.
English wraps at word boundaries and, failing that, ends in .
You can't read it, but you can tell something was cut.
Japanese doesn't do that.
It can break between almost any two characters, so once a column is squeezed to one character wide, you get one character per line, stacked downward.
Actual output: Rendered Intended Paired Macs (broken mid-word) Claude Code One character per line "実行中のセッション" (Running sessions) Three step labels stacked vertically A three-step horizontal stepper , turning the capsule into a circle A "Demo" badge is English breaking mid-word.
Once the column has only a few characters left, even English gets there.
Japanese gets there much earlier.
The cause had the same shape every time Nearly all eleven were this: The 44pt icon and the trailing value claim their width first, leaving the label column a few characters.
The fix: rows that carry a value drop the value to the line below — but affordances like chevrons and toggles stay on the right.
That row component was shared across the whole settings tree, so fixing one place fixed the entire settings screen.
Which also means one decision inside a shared component was breaking eleven screens. is not a general answer I used to switch to a stacked layout.
It broke the standard size. decides using each child's ideal width.
A title that wraps reports its unwrapped full length as its ideal width.
So the side-by-side candidate was judged "doesn't fit" and the badge dropped below the title at the standard size.
I could not have reasoned my way to this.
I found it by screenshotting the standard size.
Where each one belongs: — when every child is short and has an intrinsic width (badges, two-word metrics) An explicit branch — when one of the children is a sentence that wraps Only pin things to the right if you operate them in place I reversed one of my own calls partway through.
I'd classified a Picker with Toggle, as something that belongs pinned right.
A screenshot of the audit-log screen disproved that — the filter label came out as .
The rule I ended up with: Pin right — controls whose state changes in place (Toggle) Allowed to take the full-width row — things that merely open something ( Picker, chevron) The modals had never been tested at all I had a env var for UI tests.
It applies to the root view.
That does not propagate into a 's environment.
So the paywall and the setup guide had never once been rendered at the largest text size.
What was passing was "the tests are green," not "the modals were checked." Now it's applied from the system side: I declared convergence twice After fixing six, I wrote that the pattern had converged.
It hadn't.
There were simply screens I hadn't looked at.
When I did, four more appeared — numbers seven through ten.
Then I went through the QR scanner, host-add and pairing flows in Japanese at XXXL, confirmed zero new findings, and only then called it converged at eleven.
The lesson is: don't declare convergence until you've actually looked at the screens.
Judge by how many screens you looked at, not by how many you fixed.
And, incidentally, zero pluralization While reading the audit log, caught my eye.
I swept the strings: of 38 English strings with a quantity placeholder, zero had plural variants. (on the paywall) — in a share-sheet body, i.e. it leaves the device Thirteen keys got variants.
Japanese has no plural agreement, so nothing changed there.
Strings like , where the number doesn't agree with