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>
1.5 KiB
Known, not yet usable
Things worth having, blocked on a deployment target. Kept so nobody rediscovers them from scratch, and so the workarounds they replace can be deleted the day the target moves.
Adaptive toolbars (iOS 27)
What it is. Explicit control over how a toolbar collapses when it runs
out of room: visibilityPriority on a ToolbarItem (.low, .automatic,
.high, or custom levels declared relative to those), an explicit
ToolbarOverflowMenu for what should go into the overflow, and
ToolbarItem(placement: .topBarPinnedTrailing) for what must never move.
Related modifiers control minimisation on scroll.
What it replaces. A workaround we already carry: .secondaryAction
put our view-options menu into the system's own overflow, where it needed
two taps to open, so it was rebuilt as an ordinary primary-action button
with a hand-placed ToolbarSpacer. visibilityPriority plus
ToolbarOverflowMenu is the supported way to say what we meant.
Step forward? Yes, and it removes a comment explaining a hack.
Blocked on. Deployment target iOS 26. Either raise it or gate with
#available, which for a toolbar layout is more trouble than waiting.
Source. Natalia Panferova, "Adaptive SwiftUI toolbars in iOS 27",
nilcoalescing.com, 9 Aug 2026. Read 16 Aug 2026. Apple's
swiftui-whats-new-27 skill covers the same APIs in more depth — prefer
it once the target moves; this entry exists for the "what of ours does it
replace" note.