Files
claude-plugins/pdat-swift-practice/skills/apple-findings/references/waiting-on-target.md
T
TomUviandClaude Opus 5 f84852d49c Collect findings from other people's writing, with sources
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>
2026-08-16 23:14:51 +02:00

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.