cd /news/developer-tools/i-set-the-font-to-the-largest-size-a… · home topics developer-tools article
[ARTICLE · art-98356] src=dev.to ↗ pub= topic=developer-tools verified=true sentiment=· neutral

I set the font to the largest size and found the same bug eleven times

A developer found the same layout bug eleven times in an iOS app by setting Dynamic Type to XXXL and screenshotting every screen. The root cause was a shared row component that pinned a value to the right, leaving too little space for labels, which broke worse in Japanese due to character wrapping. The fix involved moving values to a second line while keeping affordances on the right, and the developer emphasized verifying convergence by actually viewing screens rather than relying on tests.

read4 min views1 publishedAug 16, 2026

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.

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
Paire / d / Macs
Paired Macs (broken mid-word)
Claud / e / Code
Claude Code
One character per line "実行中のセッション" (Running sessions)
Three step labels stacked vertically A three-step horizontal stepper
De / mo , turning the capsule into a circle
A "Demo" badge

Paire / d / Macs

is English breaking mid-word. Once the column has only a few characters left, even English gets there. Japanese gets there much earlier.

Nearly all eleven were this:

HStack {
  Image(systemName: icon).frame(width: 44)   // fixed
  Text(label)
  Spacer()
  Text(value)                                 // pinned right
}

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.

ViewThatFits

is not a general answer I used ViewThatFits

to switch to a stacked layout. It broke the standard size.

ViewThatFits

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:

ViewThatFits

isAccessibilitySize

branchI reversed one of my own calls partway through.

I'd classified a .menu

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:

.menu

Picker, chevron)I had a UITEST_FORCE_ACCESSIBILITY_XXXL

env var for UI tests. It applies .dynamicTypeSize

to the root view.

That does not propagate into a .sheet'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:

xcrun simctl ui <udid> content_size accessibility-extra-extra-extra-large

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.

While reading the audit log, 1 items need attention

caught my eye. I swept the strings: of 38 English strings with a quantity placeholder, zero had plural variants.

1 items need attention

1 saved Macs

1 days free

(on the paywall)1 sessions, 1 active…

— Thirteen keys got variants. Japanese has no plural agreement, so nothing changed there. Strings like %d of %d Macs

, where the number doesn't agree with the noun, were deliberately left alone.

The verification order mattered. Add one key, build, confirm 1 item needs attention

on a real screen, then roll out the rest. Finally, read en.lproj/Localizable.stringsdict out of the build product and confirm

NSStringPluralRuleType

was generated correctly.Recorded honestly, on the principle of not manufacturing work:

ScrollView

behaviour).large

navigation title layout — the same as Apple's own appsViewThatFits

judges on ideal width.Reading the code found zero of the eleven.

Separately from this, I build a desktop AI agent called Wisp.

It stands on your desktop, answers when you talk to it, and runs commands when you ask — always showing you what it's about to do first.

── more in #developer-tools 4 stories · sorted by recency
── more on @ios 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/i-set-the-font-to-th…] indexed:0 read:4min 2026-08-16 ·