Skip to content
Ritesh FirodiyaGet in touch

Work / AskCal / Wiki / Surfaces

alerts

Surfacecanonicalverified 2026-09-28

SURFACE.MOBILE.PATTERNS.ALERTS

Summary

The nine native dialogs the app raises, with the copy it actually ships.

Raw wireframe

  • .context/designs/mobile/patterns/alerts.html

Why it is drawn this way

Because they were the only user-visible copy in the app that no wireframe held. Nine Alert.alert calls across the paywall, settings and the photo screen — four of them on the money path and one on an irreversible delete — and a review of the set would never have shown any of them. A dialog being drawn by the OS rather than by us does not make its words less ours.

A pattern page, not nine screens. A native alert has no route, no navigation and no layout of ours to get wrong; what needs reviewing is the wording. So the page is the wording, at the size it is read, grouped by where it is raised. This is the one screen in the set whose route is null.

The exact strings, not paraphrases. A wireframe that approximates the copy is worse than none here: it reads as approved while differing from what ships. Where a call has two branches — Restored versus Nothing to restore — both are named.

"No charge was made" appears in two of the four money alerts, and that is deliberate. A failed purchase and an unreachable store are different events with the same first question.

Cancelling raises nothing. The purchase catch checks userCancelled and stays silent; a dialog confirming that you meant to tap Cancel is noise, and the absence is drawn as a note rather than left to be discovered in the code.

Related

Sources

  • .context/designs/mobile/patterns/alerts.html
  • apps/mobile/src/app/(onboarding)/paywall.tsx

Every project of mine is written down like this.

Read the résumé