WebSockets in a mobile app are already installed. What costs you is what the phone does to the connection.

Do you already have WebSockets, or do you have to add something?

You already have them. React Native's networking page, last updated on 14 October 2026, says it also supports WebSockets, a protocol which provides full-duplex communication channels over a single TCP connection. Its sample is four handlers on a bare constructor: open, message, error, close. No import, no plugin, no entry in your app config. Read the whole page and that section is that one sentence plus the code block, which is genuinely all of React Native's WebSocket documentation.

The API reference is thinner still, and honest about it. The entry for the global WebSocket class, last updated 12 August 2026, opens with a warning that the page is work in progress, so please refer to the MDN documentation for more information. The body underneath it is a single sentence. That is not a complaint. It is the fastest way to know where to look, and it is why the rest of this page quotes MDN rather than guessing at React Native internals.

Expo adds nothing here either. Checking Expo's documentation index on 17 October 2026, across roughly 1,680 pages, there is no WebSocket page and no socket module in the SDK list. That absence is the right outcome rather than a hole: the class is already in the runtime, so there is nothing for Expo to ship. Practically, this means a socket leaves no trace in your dependency list. If you grep package.json for a socket library and find nothing, that tells you nothing. Grep the source for the word WebSocket instead.

If you do find a library in package.json, it was added for behaviour, not for the connection. Reconnection with a backoff, rooms, acknowledgements and fallbacks are the parts the built in class does not have. Knowing which one you are looking at matters before you change anything, because a library usually has its own idea about retries, and ripping it out means writing that idea yourself.

React Native, Networking, last updated 14 October 2026, read 17 October 2026

What breaks when the phone leaves your hand?

Start with what the standard promises, because it is less than people assume. MDN describes the WebSocket API as making it possible to open a two way interactive communication session between the user's browser and a server, so that you can send messages and receive responses without having to poll. The interfaces are WebSocket, CloseEvent and MessageEvent. There is a fourth, WebSocketStream, which MDN marks as non-standard and supported in only one rendering engine, so ignore it in an app.

The connection has four states and the numbers are worth memorising because you will read them in a log: CONNECTING is 0, OPEN is 1, CLOSING is 2, CLOSED is 3. Calling send before the open event throws an InvalidStateError, because the socket is still CONNECTING. Every attempt ends in one of two events, open or close, so there is no third outcome to handle. And send is asynchronous. It does not wait for transmission, it adds the data to an internal buffer and starts sending. On a bad connection that means send keeps returning quietly while the queue grows behind it. The one number that tells you is bufferedAmount, the bytes not yet transmitted, counted on the UTF-8 encoding of any buffered text.

Now the part that is nobody's documentation. The standard exposes no heartbeat to JavaScript. MDN's own guide to writing client applications has no protocol level ping or pong in it; the ping in its example is the literal text ping, sent on a timer by the application. So every keepalive in every app is application code that somebody wrote or forgot to write. A socket that has silently died looks identical to a socket where nobody is talking, and only your own timer can tell the difference.

Backgrounding is the same story with higher stakes. React Native's AppState page, last updated 27 September 2026, defines active, background, and an iOS only inactive state for transitions and interruptions such as an incoming call. It says nothing at all about networking, and neither does the networking page. There is no first-party sentence in React Native's documentation about what happens to an open socket when the app goes to the background, so do not plan from one. Plan from the consequence instead: your JavaScript is not running, so assume the connection is gone, treat reconnection as the normal path, and refetch state on reconnect rather than assuming you missed nothing.

One performance note, because it surprises people who came from a web app. Every frame that arrives is handed to your JavaScript, and a parse of each one runs on the same thread that is deciding what the screen looks like. A chatty socket on a list that is scrolling competes directly with the scroll. That thread, and what the runtime does with the work on it, is the ground that Hermes and the new architecture change, and it is worth knowing which one your project is on before you blame the socket.

MDN, The WebSocket API, last modified 12 September 2026, read 17 October 2026

When is a socket the wrong tool for a phone?

A socket earns its place when the server has to speak first, often, at times you cannot predict, while a person is watching. A chat thread that is open. A score during a match. A driver moving on a map. Two people in the same document. In all four, the useful life of a message is a couple of seconds, and there is no request to hang the answer off.

It is the wrong tool in three situations, and the first one is absolute. If the update has to arrive while the app is closed, no socket can deliver it, because a socket needs your JavaScript running and your JavaScript is not running. That is a push notification, which is a separate system with separate credentials and a separate delivery story. Second, if the data changes a few times an hour, a refetch when the screen comes into focus is less code, fails more loudly and costs nothing to keep alive. Third, if the user is already telling you when to ask, by pulling a list down to refresh, a socket adds a second path into the same state that can disagree with the first.

The cost nobody prices up front is on the server, not the phone. A request is stateless: it arrives, it is served, it is gone, and ten thousand of them a day fit on anything. A socket is a connection your server holds open per user for as long as they have the app open. That changes how you host, how you deploy, how you scale and what a restart does to people mid-sentence. The close code list below has an entry for exactly that, 1012 Service Restart, which exists because it happens. This is the kind of commitment that shows up later in what an app costs to maintain, long after the feature that justified it shipped.

The alternative is already in your project too, which is the part people forget while they are being told that polling is primitive. React Native's networking page documents fetch as the default for networking and notes that XMLHttpRequest is built in as well, so libraries that depend on it work. A refetch on focus is three lines. If a feature can be built either way, build the cheap one first and add the socket when you can point at the moment the cheap one visibly failed a user.

React Native, Networking, fetch and XMLHttpRequest, read 17 October 2026

Why does a socket that works on your laptop fail in a release build?

Usually the scheme. MDN's constructor reference allows ws, wss, http and https, forbids a fragment in the URL, and resolves a relative URL against the base URL of the calling script, which is a sensible rule in a browser and a trap in an app. Write the address absolute and write it as wss. MDN is blunt on the security side: WebSockets should not be used in a mixed content environment, most browsers now only allow secure WebSocket connections, and in a real application the connection should use wss. React Native's own sample uses a ws address, which is shorthand for a documentation page rather than advice for something you ship.

Android presses from its own direction. Android's network security configuration documentation, read on 17 October 2026, says cleartext support is enabled by default up to Android 8.1, API level 27, and disabled by default starting with Android 9, API level 28, with apps that need it opting in. A ws address is cleartext. So if a release Android build cannot open a connection that opens happily from your machine, that default is the first thing to check, before you touch any application code. The second thing to check is duller: a hostname or a localhost address that only resolves on your own network has never been heard of by a phone on mobile data.

Then authentication, which is where native apps differ from the web in a way that catches people. React Native's networking page carries a caution that the security model for XMLHttpRequest is different from the web because there is no concept of CORS in native apps. No browser is refusing anything on your behalf, and the same applies to a socket: your server authenticates the connection or nobody does. The standard constructor takes a url and optional protocols and nothing else, and MDN says the handshake headers are added automatically, so there is no header argument to put a token in. The three real options are a query string, which every proxy and access log in the path will keep; the sub-protocol value, set through the protocols argument, where MDN notes only one sub-protocol is selected per connection; or the first message after open, which means your server holds an unauthenticated connection briefly and has to time it out.

Last, closing properly, because this is small and strictly defined. MDN says close takes an optional code and reason, the code must be either 1000 or a custom value in the range 3000 to 4999, and the reason must be no longer than 123 bytes encoded in UTF-8. Break either and you get an exception rather than a disconnection: an InvalidAccessError for a code outside those ranges, a SyntaxError for a reason that is too long. Your own codes belong in 4000 to 4999, which MDN describes as private use, by prior agreement between the two ends. Agree them with whoever owns the server and write them down somewhere you will find again.

MDN, The WebSocket API, constructor, close and security notes, read 17 October 2026