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>
The earlier entry said only "suspect what the test does not control".
Having now found it, the specifics are worth more than the warning.
State leaks between UI tests because @AppStorage is UserDefaults and the
simulator keeps them for days; the fix is a debug hook writing to the
normal domain, because launch arguments land in NSArgumentDomain and
outrank the app, making settings unchangeable rather than merely
predictable. Elements below the fold of a lazy container genuinely do not
exist, which reads exactly like a bug. Both cost a full evening.
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>
Apple work is what exists today, but the methodology skills sitting
unversioned in ~/.claude/skills are the same problem and will want the
same home. A marketplace name is the key users register it under, so
renaming later would mean everyone removing and re-adding it. Cheaper to
be right now.
Marketplace is `pdat`, repository is claude-plugins, and the install
lines carry the real Gitea URL.
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>
Skills have been living inside one app's repository, which means the next
Xcode project starts without them and a copy is the only way to share.
A marketplace makes them installable once at user scope.
Two kinds of knowledge, handled differently. What Apple ships with Xcode
stays Apple's: this repository carries a script that exports it from the
locally installed Xcode rather than a copy, so nobody redistributes
pre-release material and everyone's guidance matches their own SDK.
What we learned by shipping goes in the skill, and only if it burned us —
the file writes hidden in view bodies, the blobs that froze the main
thread, the watch target that quietly stopped compiling, the test summary
that reads as zero tests when eighty-four passed. Each of those cost real
time twice before being written down.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
TomUviandClaude Opus 5