UX/UI reference
A field guide to mobile-first writing apps — the ones that combine quick capture with careful editing, live inline feedback, and sometimes audio. Several of the platform's own defaults quietly fight against exactly this kind of interaction.
Published August 28, 2026
A horizontal swipe on a line or row used to be a safe, common pattern for a quick action — archive, stash, mark as done. That safety has been eroding on both major platforms. iOS 26 introduced a system gesture recognizer that claims a swipe starting anywhere in a screen's content area, not just the edge, for back navigation. Android's predictive back gesture, on by default since Android 14, claims an inward swipe from either edge for the same purpose.
A row-level swipe action now has real odds of fighting the system's own back gesture rather than triggering the intended action. The safer pattern is to make a full-bleed horizontal swipe an optional accelerator at most, and give the action a real primary affordance instead — a long-press context menu, or a dedicated button/handle on the row. If a swipe accelerator is kept, constrain it to start on an interior element rather than the full row width, and avoid the outer edge insets entirely.
“Recording continues in the background” is two different claims that get conflated easily. Non-blocking capture while someone keeps typing in the foreground is normal and solved. Capture that survives the screen locking or the app moving to the background is a different promise entirely — and on iOS, installed home-screen web apps routinely lose or mute microphone access once they leave the foreground, a behavior documented across WebKit's own bug tracker and Apple's developer forums.
The honest design response is to scope the feature explicitly to foreground capture, show a clear “still recording” state while the app is active, and treat anything that requires audio to survive a locked screen as out of reach for a web-based app on this platform today — not a bug to chase later, but a real, current constraint of building on the web rather than shipping natively.
Any value computed live off what someone is typing — a count, a score, a status — will occasionally be wrong, especially on unusual or invented words the underlying logic wasn't built to handle. Treating that number as always-correct sets up a small but recurring trust problem: the one time it's visibly wrong, people start to doubt every other instance of it too.
The more durable approach doesn't chase a perfect algorithm — it designs for the imperfect one. Show the value with a visibly lower-confidence state when it's a guess rather than a lookup. Let someone correct it inline and remember the correction. And where useful, present it as a relative signal — this is drifting from its neighbors — rather than an absolute, authoritative number.
Long-form writing apps — iA Writer, Scrivener, Ulysses among them — lock the active line at a fixed point in the viewport, usually around its vertical center, rather than letting normal scroll behavior push it wherever it lands. On a phone, that's the difference between the line someone is typing staying visible above the software keyboard, and it disappearing underneath it the moment the keyboard opens.
Long-press-to-drag is a common instinct, but on a touch surface it collides with two things at once: normal scrolling, and tap-to-edit on the same element. An explicit grab handle — a small, dedicated drag affordance on each row — removes that ambiguity entirely; the gesture only ever means one thing, and it stays reachable by keyboard for anyone not using touch or a mouse at all.
The compact waveform chip — tap to play, drag to scrub, position remembered between plays — is a well-worn pattern from voice messaging that transfers cleanly to any app pairing short audio clips with text. The part worth getting right is the scrub gesture itself: a real, generously sized hit target, a small drag threshold before scrubbing engages so a tap isn't misread as a drag, and continuous tracking even if the drag briefly leaves the bounds of the waveform. A waveform that looks scrubbable but isn't is a worse experience than a plain, honest progress bar.
Gestures that respect the platform's own reserved space. Audio features scoped honestly to what the browser can actually promise. Live feedback that shows its own uncertainty instead of asserting false confidence. None of these are exotic on their own — the pattern worth noticing is how often a writing tool that feels effortless turns out to be one where all of this was decided deliberately, rather than discovered the hard way after shipping.
Apple Developer Forums, iOS 26: how to disable swipe to navigate back — confirms the content-area pop gesture recognizer introduced in iOS 26.
WebKit Bug Tracker, User media tracks muted after route change in standalone PWA, and Apple Developer Forums, iOS Audio Lockscreen Problem in PWA — document microphone/audio suspension in installed web apps on iOS.