Swipe to Approve AI Actions in SwiftUI: The Approval UI

Why agent actions need a human gate

An AI agent proposes; the app decides what executes. In every serious agent integration, including the tool use model Anthropic documents, the model returns a structured request, send this email, delete these files, place this order, and the client application chooses whether to run it. That choice is where your UI lives. For consequential actions, the right interface is an explicit approval: the user sees what the agent wants to do, in full, and commits with a gesture that cannot happen by accident.

Swipe-to-approve is that commitment gesture. The proposed action renders as a card or row, amount, recipient, consequence, and the user drags to confirm, with anything short of the threshold springing back to neutral. It keeps the human in the loop without burying them in dialogs, which is the actual design problem: an agent that asks badly gets either rubber-stamped or abandoned, and both defeat the point of asking.

Why a swipe instead of a tap?

A swipe is deliberate in a way a tap cannot be. Taps happen by accident, while scrolling, while pocketing the phone, while reaching for a different control, and a tap’s cost is so low that users fire them without reading. A drag across a threshold takes continuous intent: direction, distance, and commitment, with a cancel built into the physics, since releasing early returns the card to neutral. That is why the gesture has carried meaning on iOS since the original slide to unlock, a pattern Apple valued enough to litigate, with a jury awarding $119.6 million in a case that included the slide-to-unlock patent.

The friction is the feature, and it must be priced honestly. A swipe that approves a $400 purchase is well spent; a swipe demanded for every trivial suggestion teaches users to swipe without reading, which quietly destroys the gate. Match the gesture’s weight to the action’s consequence, and let small things be taps.

The approval surfaces compared

One agent product usually needs more than one approval surface, graded by consequence.

Surface	Fits when	The cost
Swipe-to-approve row or slider	Consequential, single actions: payments, sends, deletions	Real friction; must be reserved or it dulls
Plain tap with detail visible	Low-stakes, reversible suggestions	Easy to fire without reading
Confirmation dialog	Rare, destructive, irreversible actions	Interrupts; numbing if frequent
Notification action	Approvals arriving while the app is closed	Tiny canvas; show consequence in the text

The grading matters more than any single surface. A well-built agent app lets trivial actions through with light confirmation, reserves the swipe for actions with real consequence, and keeps a hard dialog for the rare irreversible step. The card the user swipes is ordinary SwiftUI, and a free VP0 design is the strong starting point for it: a real action-card layout with a machine-readable source page that an agent like Claude Code or Cursor reads from a pasted link and extends, while you wire the approval pipeline behind it. The surrounding conversation surface, where proposals appear among streamed replies, is its own craft, covered in the AI chat streaming UI guide.

How do you build swipe-to-approve in SwiftUI?

For actions living in a list, start with the system’s own affordance: the swipeActions modifier attaches approve and reject actions to a row, with full-swipe commitment and platform-correct behavior for free. It is the right tool when proposals queue up like inbox items and each row’s consequence is visible in the row itself.

For the single high-stakes action, build the slider: a track, a draggable thumb, and a threshold. A DragGesture moves the thumb, progress is clamped to the track, releasing below the threshold animates the thumb home, and crossing it fires once, with a haptic at the moment of commitment so the body registers what the screen did. Two details separate a solid implementation from a demo: the threshold sits high, around four fifths of the track, so a casual flick cannot cross it, and the fired state immediately replaces the slider with progress, because the gesture’s job ended and the pipeline’s job began. Firing once means exactly once, so disable the control the moment it commits and make the approval idempotent on the back end, with a token per proposal, since a stressed user will retry anything that looks stuck and a payment must not double on a retry. Apple’s gesture guidance is worth a read before inventing variants; the standard gestures carry meanings users already know, and an approval slider should feel like one of them, not a novelty.

States, undo, and the audit trail

Approval is a pipeline, not a boolean, and the UI owes the user every state of it: proposed, approved, executing, done, failed. The dangerous shortcut is optimism, showing success the instant the swipe lands; if the action then fails, the user’s mental ledger and reality have diverged on exactly the kind of action important enough to gate. Render approved-but-executing honestly, and let done mean done.

Expiry belongs in the model as well. A proposal is a snapshot of the world when the agent made it, and a price, a balance, or a calendar can change before the human gets around to swiping, so consequential proposals should carry a validity window and re-verify on approval rather than executing stale intent.

Build the ledger view early: a list of what the agent proposed, what was approved, what executed, and what failed. It is the screen that makes an agent trustworthy over weeks rather than impressive for a demo, and it is also where undo lives, since reversible actions can offer a short window after approval. While an approved action grinds through a longer execution, status belongs on system surfaces too, the pattern covered in the Live Activities agent status guide, and the waiting moments inside the app are exactly where a considered thinking animation earns its keep.

Accessibility: the gesture needs a twin

Every swipe needs a non-gesture twin. VoiceOver users, Switch Control users, and anyone with limited dexterity must be able to approve through an accessibility action, a custom action on the card that commits the same approval through the same pipeline. The slider can remain the visual centerpiece, but it cannot be the only door, and the twin must carry the same weight: a clear label stating the consequence, not a bare “confirm”.

This is also where generated code fails silently, because the demo works and the gap only appears with assistive tech on. Make the twin part of the definition of done for the component, test the flow once with VoiceOver, and keep the action’s description honest, “Approve sending $250 to Dana”, so a screen reader user hears exactly what a sighted user reads. The swipe mechanics themselves are well-trodden ground, the same physics as any swipe-driven card UI, and none of that craft is lost by adding the second path.

Key takeaways: swipe-to-approve for AI actions

• The agent proposes, the UI gates. Tool calls execute only after the human commits.
• Swipe friction is the feature. Continuous intent with cancel in the physics; reserve it for consequence.
• Grade the surfaces. Taps for trivial, swipe for consequential, dialog for irreversible.
• States stay honest. Proposed, approved, executing, done, failed, plus a ledger and undo where possible.
• Start the card from a free VP0 design. The agent extends it from the source page; you wire the pipeline.

The practical build order

Build the approval card and pipeline before polishing the gesture. Render the proposed action with its full consequence, wire approve and reject through one pipeline with honest states, and use the system’s swipe actions for queued proposals. Then add the slider for the genuinely high-stakes action, threshold high, haptic on commitment, accessibility twin from day one. Start the card itself from a free VP0 design and let your agent extend it from the source page while you build the part no template can know: which of your actions deserve friction. If your agent only ever suggests reversible, low-stakes changes, skip the swipe entirely, a clear tap with visible detail serves better, and save the ceremony for the day the agent can spend money.

Frequently asked questions

How do I build a swipe-to-approve UI for AI actions in SwiftUI? Render each proposed action as a card showing its full consequence, then gate execution behind a deliberate gesture. For queued proposals in a list, attach approve and reject through the swipeActions modifier; for single high-stakes actions, build a slider with a DragGesture, a threshold around four fifths of the track, a haptic on commitment, and a spring back to neutral on early release. Drive everything through one pipeline with honest states, and start the card from a free VP0 design an agent extends from its source page.

Why use a swipe instead of a tap to approve agent actions? Because a swipe cannot happen by accident and a tap can. A drag across a threshold requires continuous, directed intent, and cancellation is built into the physics, since releasing early returns the control to neutral. That makes the gesture a true signature for consequential actions, in the lineage of slide to unlock. The trade is real friction, so it should be reserved for actions with weight; demanding it for every suggestion teaches users to swipe without reading.

Should every AI agent action require approval? No, and over-asking is its own failure. Grade actions by consequence and reversibility: let trivial, reversible suggestions through with a visible tap, gate consequential single actions behind the swipe, and reserve a hard confirmation dialog for rare irreversible steps. The goal is that when the approval gesture appears, it always means something, which keeps users actually reading proposals instead of rubber-stamping them. An agent that asks rarely and clearly earns more trust than one that asks constantly.

Is there a free template for an AI action approval UI? The reusable part is the action card and its states, and VP0 provides that free: real iOS designs with a machine-readable source page that Claude Code, Cursor, or another agent reads from a pasted link and extends into your approval surface. You then wire the part specific to your product, the action pipeline, the consequence copy, and the grading of which actions deserve friction. That split holds because card layouts transfer between products and risk policies never do.

How does swipe-to-approve work with VoiceOver? Through a twin, not the gesture. Expose a custom accessibility action on the card that commits the same approval through the same pipeline, with a label that states the full consequence, such as “Approve sending $250 to Dana”. The slider stays as the visual control, but assistive technology users get a first-class path, and the approval’s meaning is identical on both. Test the flow once with VoiceOver enabled; it is a five-minute check that catches the gap generated code reliably leaves.