TLDR: Wire your iOS save to focus-loss — onChange(of: focusedField) — not onSubmit. Mobile users tap away. They don't press Return.

The App

A health startup I work with needed a native iOS CRM to manage KOL (Key Opinion Leader — the doctors, researchers, and advocates they partner for outreach) relationships on the go.

We built an iOS KOL CRM in SwiftUI.

Contact detail views. Inline editing for phones, emails, social handles. Relationship warmth tracking.

Shipping inline editing felt like a REAL win.

The Wall

I opened the app on my actual phone, tapped a contact's phone number, edited it, then tapped to the next field.

The edit was gone.

No error. No toast. Just silently reverted to the old value like I'd never touched it.

I did what I always do when something disappears — went hunting for a state management bug. Stale @State, a binding mismatch, something structural.

Nothing.

The save logic was fine. Data was landing in Supabase (my backend/database) perfectly every time someone pressed Return.

That was the problem. The save was only wired to the Return key.

Desktop Brain

Here's the assumption I baked in without thinking about it:

When you finish editing a field, you press Done or Return.

That's true on a laptop. On a phone? You finish editing a field and you tap somewhere else. That's it. That IS the done gesture on mobile.

So every normal user — using the app the way humans actually use phones — was losing their edit silently, every single time.

BRUTAL to discover. Even more brutal that it was my assumption to fix, not a framework bug.

The Fix That Worked

Wire the save to focus loss.

When the focused field changes — when the user taps away — that's the save moment. In SwiftUI, that means watching @FocusState and firing the save on the transition out, not inside onSubmit.

One commit. Edits started persisting.

Except — now both focus-loss AND Return were both triggering a save on the same edit. Double-save, plus a race condition on the save toast. Two more commits to deduplicate it down to one save per edit.

Annoying. Still worth it.

Why It Matters Beyond SwiftUI

The lesson isn't really about SwiftUI.

Whatever gesture ends a user's interaction on your platform — that's where the save belongs.

On mobile: tap-away.

In a web form: probably onBlur.

On desktop: maybe Return, maybe Tab, maybe neither.

Don't assume. Observe.

I've since hit the same category of bug on the web side of this same project — two editor surfaces, same data type, different save patterns. The user's muscle memory transfers from the first surface to the second… and breaks on arrival.

Different platform. Identical root cause.

If an edit silently disappears, the app failed — even if your database is perfectly healthy.