How does the client learn about new data: polling, long polling, WebSocket, server-sent events or push? How do you choose?

Reported at Meta (anonymous, unverified) for a feed with pushed posts. Short polling (ask every N seconds) is the simplest and works everywhere, but it spends battery and data on empty answers and has latency up to N. Long polling holds the request open until the server has something, so latency is low, but it still means a reconnect after each message. A WebSocket (URLSessionWebSocketTask) is a persistent two-way channel: lowest latency and good for chat or live collaboration, but the app must reconnect, resend, handle background suspension (iOS suspends it soon after backgrounding) and keep it alive through proxies. Server-sent events are one-way server-to-client over HTTP: simpler than a WebSocket when you only need updates. Remote push (APNs) is the only path that works while the app is not running: use it to tell the user or wake the app, not to carry the data.

A sound answer picks by need: live and foreground (a chat open, a running game, an auction) means WebSocket or SSE with a polling or catch-up fallback; “something new exists” while closed means APNs, then fetch on open; low-frequency background freshness means a cheap poll with an ETag or a cursor, so empty answers cost almost nothing. Whatever the transport, design for missed messages: every update carries a sequence number or cursor so the client can ask “what did I miss since X?” after a reconnect, and the notification triggers a sync instead of containing the only copy of the data (Q491). Say what you would measure: battery, data use and time-to-fresh.