Hire React Native Developers

React Native earns its place when the same product has to reach both platforms and stay in step with a web application built by the same team. Sazinga Field is offline-first for sales representatives who lose signal for hours, AdBoard puts operations in the hands of crews at the site, Factory runs on the shop floor and Engage delivers training on personal devices — four different reasons for the same technology choice.

The hard part of a field application is never the screens. It is the queue. Everything that makes these apps difficult — retries, duplicates, partial success, a photo that exists on a phone and nowhere else — lives in the few hundred lines between “the user pressed save” and “the server has it”.

What an upload queue actually has to guarantee

Four properties, and each one is a bug we have had to fix rather than a principle we read.

State is written to disk the instant the server confirms a step, not when the whole flow finishes. A photo carries its own flags for uploaded, file identifier and attached, so a retry re-uses the bytes already in object storage and can never attach the same file twice. Completion is asserted against what is on disk, not against the fact that a function returned.

Anything created offline gets its server identifier promoted onto the stored draft the moment it exists. Without that step, a retry after a partial failure creates a second record — and a duplicate inspection report is far more expensive to unpick than a failed one.

Draining is single-flight. A second call while a drain is running does not start another worker and does not silently do nothing; it requests one more pass and returns the promise already in flight. Uploads inside the drain are sequential, because a thin field connection is not helped by three parallel PUTs fighting over it.

Retries are bounded. After a handful of automatic attempts an item stops retrying and appears on a screen where a person can see it and act — an infinite retry loop on a broken item is how a queue stops delivering everything behind it.

The bugs that only exist on a real device

On Android, uploading a file through an HTTP client that routes through the browser-style Blob path can stall indefinitely — the request never completes and never errors. The symptom is an upload button that spins forever while the server has already recorded the file as created. Sending the same body through the platform fetch with a file reference rather than a blob is what fixed it.

Presigned uploads have their own rule: extra headers invalidate the signature, and the content type has to match the value that was signed byte for byte or the store answers 403. So the upload path deliberately bypasses the app’s own HTTP interceptors, which is the opposite of what a tidy architecture would do and is correct here.

And on the device-hardware side, image handling is where the surprises are. A resize routine that looked correct delivered photographs cropped to the top-left corner, because the library’s batch operation was a crop-and-resize and the size the app read back was the platform’s already-downsampled decode size rather than the true bitmap. It got worse the better the camera was.

Version upgrades are the tax nobody budgets for

React Native moves quickly and breaks native modules on the way. When a release removed a property that community modules relied on, the fix in one of our apps was a patch applied automatically after install, written to be idempotent and to skip cleanly if the file is not there — so a fresh checkout cannot regress and nobody has to remember.

Treat every third-party native module as code you have adopted, because at some upgrade you will be maintaining it. An engineer who has never patched one has not been through an upgrade that mattered.

Where React Native is the wrong choice

Where the app is a thin wrapper around content, a progressive web app or a plain mobile site is cheaper and updates instantly. Where the product depends on the newest platform features the week they ship, native will always get there first. Where sustained high-frame-rate custom rendering is the product — heavy animation, games, real-time video effects — the bridge is a cost you do not need to pay.

And where a team has no appetite for native work at all. You will still open Xcode and Android Studio; a cross-platform framework reduces native work, it does not remove it.

What we interview for

Ask about offline behaviour and about the native side. What happens to a form submitted with no connection and edited again by someone else before it syncs. When did they last write Swift or Kotlin, and why. Engineers who have shipped a real fleet app talk about device fragmentation, battery and store review; engineers who have not talk about component libraries.

Then the test that settles it: describe what happens when the app is killed mid-upload. Anyone who has run one of these in the field answers with what is on disk. Anyone else answers with what is in memory.