Offline-first isn't a feature in a cabin. It's the floor.

“Offline-first” usually describes a nicety: the app degrades gracefully on a bad train connection and reconciles when signal comes back. The network is the normal case and offline is the exception you handle politely.

In an aircraft cabin the polarity flips. There is no cloud to lean on at 43,000 feet. A passenger's phone talks to the cabin management system over the aircraft's own onboard network, and that is the entire world the application lives in. Offline is not the degraded mode. It is the only mode.

Optimistic UI is a lie you can no longer afford

The dominant pattern in consumer apps is to assume success: update the interface immediately, fire the request, quietly reconcile if the server disagrees. It feels fast, and when it is wrong the cost is a toast notification.

Now put that pattern in a cabin. A passenger raises the lights. The interface shows them raised. The cabin stays dark. What has actually been built is a control surface that lies about the state of the aircraft, and the passenger's next move is to call a crew member.

So the rule becomes blunt: the UI never claims something happened unless the cabin confirmed it. Every command carries an explicit acknowledgement and an explicit failure state. Pending is a real, visible state rather than a gap between optimism and reality.

On the ground, an unresponsive app is an annoyance. In a cabin, it's a support call to the flight deck. We built for the second standard.

Several devices, one aircraft, one truth

The harder problem is not one device talking to the cabin. It is six. Every passenger may have their own phone or tablet connected, and each is a peer with equal authority over shared state. When one of them dims the lights, every other screen has to agree, immediately, without anyone pulling to refresh.

That pushes you toward a specific shape:

• The aircraft is the source of truth, not the app. Devices render cabin state; they do not own it. Any device may propose a change, but the cabin decides and broadcasts.
• Commands are idempotent. A media command that fires twice because a connection blipped mid-send is not an acceptable failure mode. Retries must be safe by construction.
• Joining is a first-class event. A device that connects mid-flight has to arrive at correct state immediately, not incrementally. There is no warm-up period in a cabin.

The network you have is not the network you tested on

An onboard network is small, closed, and much less forgiving than it looks on a bench. Devices join and leave constantly as passengers pick up and put down their phones. Connections drop mid-command. Signal varies with where someone is sitting and what is between them and the access point.

None of that is exotic, but all of it is routine rather than exceptional, which changes how much engineering it deserves. Recovery cannot require user intervention, because the user is a passenger who did not sign up to debug anything. The application has to notice it has drifted, resynchronise, and carry on without saying so.

One codebase, because the cabin does not care what you boarded with

A passenger boards with whatever device they own. That makes platform parity a hard requirement rather than a roadmap item: a single React Native codebase delivering iOS and Android, so the experience is identical regardless of what walks onto the aircraft.

The interesting constraint is not writing once. It is that any behavioural difference between platforms becomes a difference in how the aircraft appears to respond, which is precisely the thing you cannot have.

What generalises

You probably are not building for a cabin. But the questions transfer cleanly to anything where being wrong is expensive: What does the interface claim, and on what evidence? What happens when the same command arrives twice? How does a client that just arrived get to the truth? What does recovery look like when nobody is available to help?

Most systems can answer those questions eventually. Systems that answer them at design time tend to be the ones still working at three in the morning.