TomUviandClaude Opus 5
f84852d49c
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>
32 lines
1.5 KiB
Markdown
32 lines
1.5 KiB
Markdown
# 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.
|