How does URLSessionWebSocketTask work, and what do you have to handle yourself?

A WebSocket is a long-lived, bidirectional connection that starts as an HTTP request (an upgrade) and then carries framed text or binary messages both ways without per-message HTTP overhead; use it for chat, live prices, presence and collaborative state. URLSession.webSocketTask(with:) returns a URLSessionWebSocketTask in the suspended state, and nothing connects until you call resume(). You send with send(.string(...)) or send(.data(...)) and receive with receive(), which returns one message per call: you must call it again in a loop (while true { let m = try await task.receive() … }) or you stop hearing messages. Wrap that loop in an AsyncThrowingStream (or a task) so consumers can for try await it, and cancel the task when the stream ends. Use sendPing to check the connection is alive, and close with cancel(with: .normalClosure, reason:) (close code 1000; 1001 is “going away”).

What the API does not do for you: reconnect, heartbeats beyond a manual ping, message framing of your protocol, ordering and delivery guarantees across reconnects, or backpressure. A production client adds: reconnection with exponential backoff and jitter, resubscription of what the server needs to know after a reconnect, a sequence number or “last event id” to resume without gaps or duplicates, a decision about what to do with messages sent while offline (queue, drop or fail), authentication on the handshake (headers on the request) and token refresh, and an app-lifecycle policy: iOS suspends the app soon after it goes to the background, which closes the socket, so use push notifications for background delivery, not a socket. Remember that proxies and load balancers close idle connections, so a periodic ping keeps one open. For simple server-to-client updates, Server-Sent Events over a streaming URLSession request may be simpler than a WebSocket, and for high-level needs consider a library that handles reconnects.