Fixing the Czech plurals turned up a trap worth recording: String(localized:
locale:) reads the language from the bundle, while locale: only drives
number and date formatting. A test that passes a Czech locale and nothing
else quietly compares English strings — ours failed with "1 coupon" ==
"1 kupón", which reads as broken plurals when the plurals were fine and
the test was looking in the wrong place.
Also that a plural variation must reference the number, so a key
extracted as "%@" cannot carry one and the build says so outright.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
153 posts under the SwiftUI tag, plus wwdc25 and wwdc26. Filtering them
against what our code actually contains turned up one real defect and a
short list worth keeping.
The defect is plurals. A checkout screen renders "\(count) coupons",
whose Czech translation is the single form "%lld kupónů" — so it says
"1 kupónů" and "3 kupónů", wrong for every count below five. The article
that surfaced it recommends inflect:, which covers English, Spanish and
six others but not Czech, the language that needs three forms rather than
two. Plural variations in the String Catalog are the fix for us; the
entry says so rather than repeating the article's advice.
Two entries are filed against a future rather than now: swipe action
buttons draw their titles from iOS 26, which will surprise us the day we
add a custom one, and a Form inside a sheet covers the glass behind it,
which starts to matter if the payment sheet ever gets a medium detent.
The rest is recorded as swept and skipped, with reasons — including that
Core Spotlight and the search tab are things we already do correctly, and
that three posts are covered better by the skills shipping inside Xcode.
A sweep that leaves no trace of what it rejected gets repeated.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A UI test went red in the same run that adopted three new APIs. The one
touching that screen was reverted; the test still failed. A modifier
order was corrected; still failed. Simulator data was wiped; still
failed. Running it against a clean checkout — which should have been the
first move, not the fourth — it failed there too, with none of the work
present.
The scrolling entry had already been rewritten to explain the fault in
confident detail. That write-up was fiction, so it now says what actually
happened: the API was convicted on circumstance and remains unproven
here, and the one claim that survives is about its two-way binding
costing invalidations.
xcode-practice gets the general lesson, since it will outlive this
particular test: stash and rerun before reasoning about which edit did
it, and a note recording a false cause is worse than no note, because
the next person believes it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The skill so far only held what we broke ourselves. Most of what is worth
knowing about a new SDK is found rather than suffered — release notes,
other people's articles — and that deserves a place too, on terms that
stay fair to whoever wrote it.
So: entries in our own words, source named and linked, and the one thing
no external article can supply — what it would replace in our code and
whether it is genuinely a step forward. Attribution answers plagiarism,
not copyright, so nothing is pasted; an API signature is a fact, the
paragraph explaining it is not ours to take.
First four entries come from Natalia Panferova's writing at nilcoalescing
.com: the close button role and concentric corners, both of which replace
things we hand-built; ScrollPosition, which replaces one wrapper view;
and the iOS 27 toolbar APIs, which we cannot use at our deployment target
but which would delete a workaround the day we can.
A LICENSE was overdue and now says plainly what is ours, what is Apple's
and stays out of the repository, and what belongs to the authors we cite.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
TomUviandClaude Opus 5