The car-park test

Cross-platform wrappers keep getting better, and the honest position is that most internal tools should use one. One codebase, half the cost, and the compromises are invisible to somebody checking a rota on office wifi.

The question I ask before agreeing to that is not about the technology. It is: who opens this, and what is happening to them when they do?

For the hospital's public app, the answer is a person in a car park. They are stressed, possibly lost, possibly about to visit somebody who is very unwell, on whatever signal the building allows. They have one question, they want it answered now, and their patience is already spent before the app opens.

That is the worst possible context for a web view. Not because a web view cannot render the screen, but because every small hesitation compounds against a person who has none left. A splash that waits on the network, a scroll that does not quite have native momentum, a tap target that responds fifty milliseconds late. Any one of those is unnoticeable in a usability test on a desk. Together, in a car park, they are the difference between an app that gets used and one that gets closed.

So: native on both platforms over a shared service layer. More expensive, two codebases, and correct for that user.

The same test says the opposite elsewhere. Internal dashboards used at a desk on a hospital network fail the car-park test, and should not be native. The point is not that native wins; it is that the answer comes from the worst moment the software will be used in, not from the average one.

One more thing that decision bought, which I did not anticipate at the time. Building it natively meant building it properly enough to hand over, and the codebase became the thing a mobile team formed around. The handover turned out to be as much the deliverable as the app.