51 — Apple Invites — UI/UX reference study
Reference / analysis doc. Governed by
00-ROADMAP.md— defer to it on any conflict. Created 2026-07-03 (owner-captured: 38 screenshots of Apple's Invites app inreference_assets/, walked end-to-end by the owner as UI/UX reference for the two Release headline features). Feeds52-DISCOVERY-EVENTS.mdand53-CONTACTID-RELEASE.md— those docs cite the stable pattern IDs (INV-xx) defined in §3, so do not renumber patterns; append only.Asset note — RESOLVED by owner (2026-07-04, via doc-54):
reference_assets/is committed and pushed as-is (plain git, no LFS). §5 Q1 closed; the §2 links hold for all clones.
1. Why Invites
Apple Invites (iOS, 2025) is Apple's consumer event app: create an event, customize its invitation, publish it, invite guests by contact or link, collect RSVPs, and live with the event across its lifetime (upcoming → live → past). It is worth studying for Sonnance because it is a first-party, iOS-26-era reference for exactly the two problems our Release headline features must solve:
- Discovery / Events (doc-52): an event is a timespan-bound object with momentum — it is created, shared, RSVP'd, anticipated, experienced, and archived. Invites shows how Apple surfaces each stage with a request-for-action at its center (the RSVP), and how hosting vs attending are two lenses over the same object.
- Contact ID (doc-53): Invites handles the identity-meets-privacy edges we care about — a host identity card on every invitation, a contacts picker that respects limited contact access, the guest-via-link escape hatch for people outside your graph, and a Tiles link-hub (links · shared album · Apple Music playlist) that is structurally a Linktree.
It is also a clean specimen of the iOS 26 Liquid Glass design language our iOS app already follows (22-IOS-DESIGN-SYSTEM.md): sheet-first editing, preview-before-publish, hero-image cards, progressive disclosure — the same grammar as our Portal system (49-PORTAL-SYSTEM.md).
How to read this doc: §2 is the full index of the 38 screenshots (grouped by flow stage). §3 extracts the reusable patterns with stable IDs and an Adopt / Adapt / Skip verdict each. §4 lists what we deliberately do not take. §5 holds open questions for the owner.
2. Screenshot index
One master table, capture order (≈ the owner's walkthrough order). Feeds = which doc consumes it: doc-52 (Discovery/Events) · doc-53 (Contact ID).
| Image | Screen | Flow stage | Notable patterns | Feeds |
|---|---|---|---|---|
| IMG_2147 | Invitation preview (top) | Preview | Full-bleed hero bg · title · date/time · 3-line venue · RSVP bar: Going / Not Going / Maybe · host mini-card (avatar + "Hosted by …" + subtitle) · footer: "This is what guests will see. You'll publish and invite guests in the next step." | both |
| IMG_2148 | Invitation preview (scrolled) | Preview | Auto-enriched context cards: Weather (date-aware temp range, attributed) · Directions (address + embedded Maps snippet) — all derived from one venue+date input | 52 |
| IMG_2149 | Event editor (top) | Customize | "Edit Background" affordance over hero · field rows with icons (calendar → date, pin → full address) · Preview button top-right (editor ↔ preview toggle) | 52 |
| IMG_2150 | Event editor (scrolled) | Customize | Weather/Directions cards removable via (×) — auto-content is opt-out, not locked · Shared Album pitch card ("guests can see event photos and add their own") | 52 |
| IMG_2151 | Event editor — Tiles rail | Customize | Tiles system: Shared Album · Link ("gift registry, travel itinerary, packing list, shared document, and more") · Shared Playlist (Apple Music, guests can add songs) · "Add up to 5 links, a shared photo album, or an Apple Music playlist" | both |
| IMG_2152 | Event editor — Tiles rail (alt scroll) | Customize | Same Tiles rail, full view: every tile = icon + name + one-line value pitch + single CTA | both |
| IMG_2153 | Shared Album creation sheet | Customize | Inline album creation: "Add 2 Photos" + thumbnail stack + name field — no context switch to Photos app | 52 |
| IMG_2154 | Editor — tiles filling up | Customize | Shared Album tile in filled state (thumbnails + "Add Photos") next to still-empty Link/Playlist pitches — empty vs filled tile states | both |
| IMG_2155 | Editor — rich link tile | Customize | Filled Link tile = fetched logo + custom Title ("Creative Studio | Vision · Technology · Design") + Description ("LandingPage") + Edit Link — links are first-class objects, not bare URLs | both |
| IMG_2156 | Add Playlist sheet + permission fork | Customize | Search own Apple Music playlists; on attach, explicit dialog: "Collaborate on this playlist? Anyone with the link will be able to edit…" → Add and Collaborate / Add Playlist Only — write-permission decided at attach time, in context | both |
| IMG_2157 | Edit Link sheet | Customize | Structured link editing: URL · Title · Description (char limit 250, live counter) — curator controls how the link presents | 53 |
| IMG_2158 | Editor + Tiles catalog | Customize | Filled Link + Playlist tiles; Tiles catalog sheet at bottom (tile type + pitch + "+") to add more of a type | both |
| IMG_2159 | Editor — multiple link tiles | Customize | Two Link tiles (landing page, Amazon "Gifts love") + Playlist coexisting — the tile rail is a mini link-hub / Linktree | 53 |
| IMG_2160 | Editor — link + playlist tiles | Customize | Amazon Link tile + Apple Music Playlist tile + "Add Tile"; every tile removable (×) — composable, capped (5), reversible | both |
| IMG_2161 | Invitation preview — tiles, guest view | Preview | Guest-facing tiles show an outbound-domain chip ("ff8.dev ↗", "amazon.co.uk ↗") — destination transparency before tapping | 53 |
| IMG_2162 | Apple Music — collaborative playlist | Sharing (Music detour) | Playlist page: owner + "Updated 2m ago" · per-track contributor avatar badges on artwork — attribution at item level | 52 |
| IMG_2163 | Apple Music — collaboration sheet | Sharing (Music detour) | The whole sharing-privacy kit on one sheet: Share Invite Link · QR Code · "Link expires in 7 days… generate a new link" · Collaboration Stop · member list w/ role + handle ("Facu Ferreyra (Owner) @FacuSape") · "Approve Collaborators" toggle ("when off, anyone with the link can join") | both |
| IMG_2164 | Apple Music — playlist context menu | Sharing (Music detour) | Long-press menu: Download · Favorite · Share · Pin · Edit · Manage Collaboration · Sort · Move to Folder · Play Next · Delete — collaboration management as a first-class menu verb | 52 |
| IMG_2165 | iOS share sheet (playlist) | Sharing (Music detour) | System share sheet: SharePlay · recent-contact shortcuts (app-badged) · app row · Copy/actions — the OS-level share surface Sonnance links ride on | both |
| IMG_2166 | Apple Music — collab playlist body | Sharing (Music detour) | Contributor badges per track · "Add Music" row · "15 songs, 1 hour" summary · Suggested Songs: preview + one-tap add — assisted contribution inside a shared object | 52 |
| IMG_2167 | Apple Music — playlist people surfaces | Sharing (Music detour) | Collaborators avatar row + auto-derived Featured Artists row — people/identity surfaces generated from the content graph | 53 |
| IMG_2168 | Publish & invite screen (top) | Publish / share | Dual-mode inviting on one screen: "Invite with Link" (Messages · Mail · Share Link · Copy Link) + "Approve Guests" toggle ("anyone with the link can reply and join your guest list") vs "Invite Individuals" ("send a one-time link to a single guest") · mini card preview up top | both |
| IMG_2169 | Publish & invite screen (scrolled) | Publish / share | Guest List policy line: "Guests can't bring additional guests. Change" — delegation policy stated in prose with inline edit · Host row: "Facundo Octavio Ferreyra (Me)" | 52 |
| IMG_2170 | System contacts picker (limited access) | Guests / privacy | OS picker: checkmark multi-select · "Show Selected (1)" · "Select Contacts Later" escape — user curates which contacts the app may see | 53 |
| IMG_2171 | iOS limited-contacts permission dialog | Guests / privacy | "Allow access to 1 contact? 'Invites' will only have access to contact information for the contacts you selected…" → Allow Selected Contact / Not Now — granular, informed, minimal-by-default consent | 53 |
| IMG_2172 | Choose a Guest sheet | Guests / privacy | Two lanes: "Not in Contacts → New Guest" ("send a link to someone who is not in your contacts") vs Contacts list · in-place notice that access is limited + Settings deep-link | both |
| IMG_2173 | Send Link sheet (per-guest) | Guests / privacy | Per-guest one-time link: Guest Name (editable) + delivery Options: Share Link · phone (Messages) · email (Mail) — the link is personal, the channel is the guest's | both |
| IMG_2174 | Per-guest link → system share sheet | Publish / share | The one-time link rides the OS share sheet (AirDrop · Messages · WhatsApp · Copy…) with a branded "HPrty" share card — app link + system distribution | 52 |
| IMG_2175 | iMessage compose with invite | Publish / share | The invite link unfurls into a rich card in Messages (hero image + "Reply to 'HPrty'" + domain) — the invitation sells itself inside the chat | 52 |
| IMG_2176 | Choose a Guest — Invited state | Guests / privacy | Picker now shows an "Invited" section above Contacts — guest lifecycle state visible where you'd re-invite | 52 |
| IMG_2177 | Publish screen — Invited list | Guests / privacy | Invited (Total: 1): "People who have received an invitation, but haven't replied yet. Only hosts can view who's invited. Change" — asymmetric visibility (host sees, guests don't) stated in prose, configurable inline | both |
| IMG_2178 | Event Settings sheet | Guests / privacy | Per-event config panel: Additional Guests stepper (None) · Specify Number of Kids · Approve Guests · Show Who's Invited ("names match your Contacts unless you edit them") · Privacy: Remove Background Preview ("only show the background… after they've opened the invitation with a verified email address or from a private link") · Accessibility: Background Image Description | both |
| IMG_2179 | Published event (host) + calendar sync | Live event | Host actions: Send a Note · Invite Guests · "Sync Event to Calendar" sheet (per-event calendar pick; "to automatically sync all events, go to Settings") — the event escapes into the user's own time system | 52 |
| IMG_2180 | Notifications pre-permission pitch | System / onboarding | Value pitch before the OS dialog: "Get notified about events you are attending and hosting…" + Continue / Not Now — the app earns the permission first | both |
| IMG_2181 | OS notification permission dialog | System / onboarding | The real dialog only after the pitch: Allow / Allow in Scheduled Summary / Don't Allow | both |
| IMG_2182 | Events home (Upcoming) | Browse / filter | Filter-as-title ("Upcoming ⌄") · "+" create · profile corner · full-bleed event card with "Hosting" crown badge — role state worn by the card itself | 52 |
| IMG_2183 | App Settings | System / identity | Apple-Account identity block ("you can change your name and profile picture when replying to an invitation" — per-reply identity!) · Notifications / Calendar Sync / Email Updates rows · Privacy & Information: "See how your data is managed…" | 53 |
| IMG_2184 | Events list filter menu | Browse / filter | Dropdown lenses: Upcoming (1) · All Events (1) · Past Events ÷ Drafts · Hosting (1) · Attending — one list, timespan lenses + role lenses, with live counts | 52 |
3. Pattern extraction (INV-xx)
Stable IDs — doc-52 and doc-53 cite these; append, never renumber. Verdicts: Adopt (take the pattern), Adapt (take the idea, re-express in Sonnance grammar), Skip (note why in §4).
A. The event object (→ doc-52)
- INV-01 — Invitation-card anatomy. (IMG_2147, 2149, 2182) Full-bleed hero · title · when · where (3-line venue) · host mini-card. One glanceable object that is the event everywhere it appears (editor, preview, list, share unfurl). Adapt → the Sonnance Event card; anatomically it is a doc-49 Portal Identity zone worn as a card.
- INV-02 — RSVP = a pinned tri-state request-for-action. (IMG_2147, 2168) Going / Not Going / Maybe lives on the card, above the fold — the object leads with the action it wants from you. Adopt → this is exactly the owner's "request-for-action" and rhymes with our approve / request-changes grammar (doc-32); Discovery events lead with attend / decline / interested.
- INV-03 — Preview-before-publish. (IMG_2147 footer, 2149 Preview toggle) "This is what guests will see" — the guest view is one tap away while editing; publishing is a separate, explicit step (drafts exist, IMG_2184). Adopt — matches doc-47 §7 calm/progressive-disclosure and doc-46's draft states.
- INV-04 — Auto-enriched context, opt-out. (IMG_2148, 2150) One venue + date input auto-generates Weather and Directions/map cards, each removable (×). Adapt — for sessions/gigs: venue map, "time until", studio address; generate value from data we already hold, never locked-in.
- INV-05 — Timespan lenses + role lenses over one list. (IMG_2184, 2182) Upcoming / All / Past ÷ Drafts / Hosting / Attending, with counts, and filter-as-title ("Upcoming ⌄"). Adopt → the owner's "timespan" idea verbatim; extends the doc-40 lens grammar.
- INV-06 — The card wears your role. (IMG_2182) "Hosting" crown badge on the event card — hosting vs attending is object state, not app mode (one surface, role-driven — doc-47 §7 principle 5). Adopt.
- INV-07 — Host verbs live on the live object. (IMG_2179) Published event = Send a Note (broadcast to guests) + Invite Guests + per-event calendar sync (escape into the user's own time system). Adapt → momentum actions per lifecycle stage (doc-52 §5).
- INV-08 — The invitation sells itself in the chat. (IMG_2175, 2174) The link unfurls into a rich hero card in Messages/share sheet — the share is the first impression. Adopt → Open Graph / link presentation is part of the feature, not an afterthought (ties to doc-26 share links).
B. Sharing & links (→ both)
- INV-09 — Dual-mode inviting on one screen. (IMG_2168, 2172, 2173) Broadcast link (Messages · Mail · Share · Copy, gated by an "Approve Guests" toggle: "anyone with the link can reply and join") vs one-time per-guest links ("send a one-time link to a single guest", guest name editable, delivered via the guest's channel). Adopt → maps directly onto doc-26 share links + doc-44 Link/guest principals; the per-guest one-time link is the piece our link model doesn't have yet.
- INV-10 — Link hygiene as UI. (IMG_2163) "Link expires in 7 days… generate a new link" + a hard Stop on collaboration. Expiry, rotation, and kill-switch are user-visible controls, not admin arcana. Adopt — our
linkmodule already has TTL; surface it this plainly. - INV-11 — QR is a peer of the share link. (IMG_2163) "Share Invite Link" and "QR Code" sit side by side, equal rank. Adopt → doc-53's QR-forward Contact ID and event QR posters.
- INV-16 — Tiles: a capped, composable link-hub. (IMG_2151–2160, 2161) Up to 5 tiles — rich links (title + description + fetched logo), a shared album, a collaborative playlist — each with one CTA, each removable; guests see them on the invitation. Adopt → structurally a Linktree: the same grammar serves the Contact ID card (doc-53) and event resources (doc-52: lineup links, presave, tickets, merch, stems…).
- INV-17 — Outbound-domain transparency. (IMG_2161) Guest-facing link tiles show a "domain ↗" chip — you know where you're going before you tap. Adopt (cheap trust win).
C. Privacy & identity (→ doc-53 first)
- INV-12 — Asymmetric, configurable visibility. (IMG_2177, 2178) "Only hosts can view who's invited" by default; a Show Who's Invited toggle flips it, and "names match your Contacts unless you edit them." Who-sees-whom is (a) stated in prose where it applies, (b) owner-configurable, (c) private by default. Adopt → this is the Contact ID privacy philosophy in miniature (doc-53 §3).
- INV-13 — Per-object privacy config panel. (IMG_2178) Event Settings: additional-guests stepper · approve-gate · show-who's-invited · Remove Background Preview (content hidden until "verified email address or… a private link") · accessibility description. Config is a place on the object (doc-47 §7 principle 4; doc-48 apply-at-node). Adopt.
- INV-14 — Minimal-by-default contact consent. (IMG_2170, 2171, 2172, 2176) iOS limited-contacts: the app sees only the contacts you selected ("Allow access to 1 contact?"), with "Select Contacts Later" and a "New Guest via link" lane for people outside your graph entirely. Adopt → Contact ID's contacts graph must work graph-minimal: never demand the whole address book; always keep the out-of-graph lane (doc-53 §4).
- INV-15 — Identity is contextual and per-reply. (IMG_2183, 2173) "You can change your name and profile picture when replying to an invitation"; hosts can edit a guest's display name. Identity presented ≠ identity stored — the person controls the lens per context. Adapt → doc-53's "outsider view is a configured lens".
- INV-18 — People surfaces derived from the content graph. (IMG_2162, 2166, 2167) Collaborator avatars per contributed item, a Collaborators row, an auto-generated Featured Artists row. Belonging is shown, computed from real contributions — never a vanity follower count. Adapt → Contact ID stats + "the club" (doc-53 §4), roster surfaces (doc-40).
- INV-20 — Data transparency in plain reach. (IMG_2183) Settings carries "See how your data is managed…" one tap deep. Adopt for doc-53's philosophy section (and doc-09 posture).
D. Platform craft (→ any iOS surface)
- INV-19 — Earn the permission before asking. (IMG_2180, 2181) A value-pitch screen ("get notified about events you are attending and hosting") precedes the OS notification dialog, which itself offers "Allow in Scheduled Summary". Adopt for every iOS permission we request (notifications, contacts) — belongs in the doc-24 craft bar.
4. What we deliberately skip
- Consumer-party aesthetics (balloons icon, playful backgrounds-first creation): Sonnance is calm and professional (doc-47 §7). We keep hero-image cards, not the party dress.
- iCloud+ gating / Apple's business model (hosting requires iCloud+): irrelevant to us; our gating is roles + plans (doc-44,
subscription). - Apple-proprietary integrations as-is (Apple Weather, Apple Music playlists, iCloud Shared Albums): we take the shape (INV-04, INV-16) — auto-context cards, collaborative media tiles — not the vendors. Our media collaboration already exists natively (Tracks/Files/doc-28 variants).
- Kids / household semantics (Specify Number of Kids): consumer-event detail with no studio analog.
- "Product updates and special offers" in the notification pitch (IMG_2180): we earn permissions for workflow signal only (doc-38 calm posture) — never marketing.
5. Open questions for the owner
- Asset handling —
reference_assets/is ~77 MB untracked: Git LFS, plain commit, or keep local-only? (Links in §2 assume the folder ships with the repo clone.)Resolved (owner, 2026-07-04): plain commit — committed and pushed as-is.
- Does Event become a full node (own Portal, doc-49 anatomy) or a lighter timespan object attached to Workspace/Artist? (doc-52 §7 sketches the fork.)
- One-time per-guest links (INV-09) — extend the
linkmodule's model (doc-26) with per-principal links now, or Release-phase-2? - QR surfaces (INV-11) — Contact ID first (doc-53, Wallet pass) and events later, or both in the Release cut?
- Auto-enrichment depth (INV-04) — which context cards are worth it for sessions/gigs v1: map + "time until" only, or also weather?