Real-Time on Mobile — Real-Time APIs

Mobile OSes suspend background apps, so persistent sockets only work in the foreground. Combine: WebSocket/SSE while the app is open; push notifications (APNs/FCM) for important events when backgrounded — sometimes silent/data pushes to trigger a sync; and sync on resume using cursors. Minimize battery and data use: avoid frequent polling, batch updates, and reconnect with backoff when networks change.

Mobile real-time strategy

App state	Mechanism	Notes
Foreground	WebSocket / SSE	Live updates; reconnect on network change
Background	Push (APNs/FCM)	User-visible or silent data messages (rate-limited by OS)
Resume	Delta sync with cursor	Fetch everything missed
Killed / offline	Push + sync on next launch	Durable server-side state

On app foreground:  GET /sync?cursor=abc123 → apply changes → open WebSocket (resume from latest seq)
On background:      close socket after short grace period; rely on push
Push payload:       {"type": "message.new", "conversation_id": "c_9", "seq": 1834}  → app syncs on open

Common pitfalls

Keeping sockets open in the background (killed by OS, battery drain).
Putting sensitive content in push payloads.
Silent pushes as a reliable delivery mechanism (OS throttles them).

Key points

Sockets in foreground, push in background
Sync on resume with cursors
Battery- and data-aware

Further reading: Firebase Cloud Messaging: Message types

Practice questions

Why can't mobile apps rely on WebSockets for background notifications?

Answer

The OS suspends background apps and their network connections to save battery; only platform push services can wake or notify them.

Why shouldn't silent push notifications be treated as guaranteed delivery?

Answer

iOS and Android throttle or drop background/data pushes (low power mode, app usage patterns), so apps must still sync on launch.