Designs by Duhart All work
Rank
18 of 28
Tier
Tier B 62 of 120

16 — Dating: Swipe Deck & Discovery UI

UI project 3 of 5 · IOS/TheOne/Dating, app/web-platform/app/dating Stack: SwiftUI + gesture-driven card stack, Next.js/React web tier, MatchService backend Scope: iOS 147 files · 90,161 lines — the largest single mode in the app

Where this sits. The swipe deck is the most recognizable interaction pattern in consumer software, and it is a harder engineering problem than it looks: gesture physics, prefetch, optimistic state, and an undo that has to survive a network failure. It also carries the portfolio's most useful negative finding.

The swipe deck, and why it is harder than it looksinteractive
Tomás, 27Braga · chef · 3 photos
Ines, 31Porto · cellist · 6 photos
Renata, 29Lisbon · climbs · 4 photos

Drag a card, or use the buttons.

  • no writes yet

Gesture physics, prefetch, optimistic state, and an undo that has to reverse a network call already in flight. Drag a card, or use the buttons. The deck above runs the same state machine the iOS module does.

Open the running deck The product's own Discover deck, running in the same pod as the players, on invented profiles with drawn portraits so no real person is on the other end of a swipe.

The surface

Containers/MatchSwipeStack.swift      the card stack and its gesture layer
MatchService/MatchDeck.swift          deck state, prefetch, exhaustion
MatchService/DatingMatchCard.swift    card model
Components/components/MatchSwipeCard.swift   the rendered card
Types/SwipeAction.swift               like / pass / super, as a type
Beacon/  Inbox/  Profile/  Engines/  ViewModels/  Views/

Plus discovery, profile, prompts, favorites, an inbox, and a web counterpart in app/web-platform/app/dating.

What is actually hard here

The deck is a distributed-systems problem wearing a UI costume

A swipe deck is a client-side cache of a server-ranked candidate stream. It has to prefetch ahead of the user, survive exhaustion mid-gesture, exclude already-seen profiles, and stay consistent with a ranking pipeline that is concurrently rewriting scores. That pipeline is Match Service — and the phantom-partition bug documented there surfaced here, as nameless cards in a real user's deck.

That is the connection worth drawing in an interview: the UI is where the distributed-systems defect became visible, and the fix was three inference steps upstream in a Cassandra partition key.

Optimistic swipe, and what happens when the write fails

A swipe must feel instantaneous, so the card leaves the stack before the server has agreed. If the write then fails, the options are all bad: silently drop the action, resurrect the card mid-session, or reconcile later. SwipeAction being a type rather than a boolean is what makes that reconciliation expressible.

Gesture physics

Rotation proportional to horizontal displacement, a velocity-aware release threshold, and a stack that renders the next two cards with scale/offset so the deck reads as physical. Getting the threshold wrong makes an app feel either sticky or trigger-happy.

The honest finding

The Dating mode audit is blunt about this mode, and the write-up is worth more than a clean claim would be:

DATING_REMEDIATION.md records 49 findings (F-01…F-49) with file:line, severity, and evidence, plus five ready-to-run fix plans. Every architectural claim cites a real path and line; anything unconfirmable is marked UNVERIFIED.

Bringing a document that says "the flagship interaction in my largest module was not wired, here is the line, here is the fix plan" is a stronger signal than a portfolio with no defects in it. Nobody believes the second one.

Interview surface this opens