TomUviandClaude Opus 5
3ad73df76a
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>
42 lines
2.1 KiB
Markdown
42 lines
2.1 KiB
Markdown
---
|
|
name: apple-findings
|
|
description: A curated file of Apple platform APIs worth adopting, each with where we found it and what it would replace in our code — iOS 26 UI affordances (close button role, concentric corners), modern scrolling APIs, and things noted for a later deployment target. Use when reviewing SwiftUI code for outdated patterns, when a hand-built control might have a system equivalent, or when deciding whether a newly published API is worth adopting.
|
|
---
|
|
|
|
# Findings
|
|
|
|
Things worth adopting that we found elsewhere — release notes, other
|
|
people's writing, conference talks — written up in our own words with the
|
|
source named, and with the part nobody else can write for us: what it
|
|
would replace in our code and whether it is actually a step forward.
|
|
|
|
Read `references/` for the individual entries.
|
|
|
|
| File | Covers |
|
|
|---|---|
|
|
| `references/ios26-ui.md` | `Button(role: .close)`, concentric corners |
|
|
| `references/scrolling.md` | `ScrollPosition` and friends |
|
|
| `references/localization.md` | Plurals, and why `inflect:` does not cover Czech |
|
|
| `references/waiting-on-target.md` | Known, not yet usable at our deployment target |
|
|
| `references/checked-and-skipped.md` | Swept and deliberately not adopted, with reasons |
|
|
|
|
## How to add an entry
|
|
|
|
**Write it yourself.** Do not paste someone else's prose or their longer
|
|
code examples. An API signature is a fact and facts are free; a paragraph
|
|
explaining it is their work. Name the source and link it — that is
|
|
courtesy and it lets the next person check whether the entry has aged.
|
|
|
|
Every entry answers four things:
|
|
|
|
1. **What it is** — the API, in one or two sentences.
|
|
2. **What it replaces** — the hand-built thing in our code, with the file
|
|
if we know it. An entry without this is a bookmark, not a finding.
|
|
3. **Whether it is a step forward** — sometimes the honest answer is "no,
|
|
ours is fine", and that is worth recording so nobody re-litigates it.
|
|
4. **Source** — author, title, link, date read.
|
|
|
|
If an entry turns out to be wrong or the API changes, fix it in place and
|
|
say so. A stale finding is worse than no finding, because it is quoted
|
|
with confidence.
|