Handling Network Errors in React Native

WHY IT EXISTS: Mobile networks are not broadband. A React Native app moves through dead zones, low battery modes, and handoffs between WiFi and cellular towers. If you treat a failed fetch as an unhandled exception, your UI crashes or leaves the user staring at an infinite spinner. The goal is to keep the app usable when the network is not.

THE MENTAL MODEL: Treat every network call as a message sent across an unreliable bridge. The request, the response, and the error are all possible states of the same operation, not separate concerns. Your component should own a state machine that moves from idle to loading to either success or error. Error is a normal state, not a catastrophe.

HOW IT WORKS: Wrap your API layer in a hook or library that tracks status explicitly. Distinguish error families: a 4xx status means the client sent bad data and retrying is useless; a 5xx status means the server is struggling and a limited retry with exponential backoff is reasonable; a timeout or unreachable host means the device has no route and you should wait for connectivity. Use NetInfo to listen for online status. For mutations, use an optimistic update pattern: show the change immediately, queue the server call, and roll back only if the server explicitly rejects it. Never throw a raw exception into the render path; map errors to user-facing messages and recovery actions.

WHEN TO USE IT: Use explicit error handling for every remote read that blocks content, every write that changes server state, and any background sync that must survive app suspension. It is essential when you build offline-first features or when your users are primarily on cellular connections.

WHEN NOT TO USE IT: Do not wrap non-critical analytics pings in blocking error UI. Do not retry 4xx errors blindly. Do not use infinite retry loops without backoff, because a fleet of devices retrying simultaneously can overwhelm a recovering server. Avoid synchronous network checks on the JavaScript thread.

ONE CANONICAL EXAMPLE: Imagine a user submits a comment on a photo. The app immediately renders the comment in the list with a pending indicator. The app calls fetch. If the device enters a tunnel and the request times out, the app keeps the comment visible and shows a small retry button. When NetInfo reports the device is back online, the app automatically resends the request. If the server returns a 500, the app retries twice with a one-second and then a two-second delay. If the server returns a 403, the app removes the optimistic comment and navigates to a login screen. The user never loses their typed text.