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