News
When connectivity is unreliable and drivers are under time pressure, your mobile app cannot afford to wait for a server response. Here is how we built Transporter — a rugged C# field operations app for Zebra devices that keeps working no matter what.
When TST Terschelling approached us to replace their paper-based driver workflow, the brief was straightforward: make it faster, make it digital, make it reliable. What followed was one of the most technically demanding projects we have shipped.
The Wadden Islands have patchy mobile coverage. Ferries cross twice a day. A driver loading goods at the dock at 6 AM does not have the luxury of waiting for a server round-trip every time they scan a barcode. The app had to work fully offline — not as a fallback, but as the primary operating mode.
That single constraint changed every architectural decision we made.
Transporter is the operational spine of a driver's day. It handles:
Every action is local-first. The device stores state, queues events, and syncs opportunistically when connectivity is available. Nothing blocks on a network call in the critical path.
We built Transporter as a native C# application targeting Zebra Android devices. Zebra handhelds are the industry standard for warehouse and logistics scanning — they survive drops, dust, temperature swings, and shift after shift of continuous use. Their integrated barcode scanners are an order of magnitude faster than camera-based scanning on consumer phones.
The backend is a PHP REST API backed by MySQL. State reconciliation happens through an event-sourced sync model: the device accumulates a log of operations, the server applies them in order, and conflicts are resolved deterministically. The driver never sees a loading spinner at the critical moment.
Offline-first sounds simple until you have to handle it properly. Every edge case that is trivial in an always-connected app becomes a design problem: what happens if a driver scans the same item twice on different devices? What if the route data has changed on the server since the app last synced? What if the device clock is wrong?
We spent considerable time on the sync protocol and on the UI feedback model — making sure the driver always knows the authoritative state of their route, even when that state was last updated three hours ago on a ferry crossing.
The result is an app that has been running daily routes since launch without a single data integrity issue.
TST Terschelling replaced a clipboard-and-paper process that had been in place for years. Loading time per truck dropped significantly. Proof-of-delivery disputes disappeared because every delivery now has a timestamped, signed digital record. And the operations team can see live route progress from the office rather than waiting for drivers to call in.
It is the kind of project that reminds us why software exists: to remove friction from work that actually matters.
More
Kiewiet Rijwielverhuur on Terschelling runs a bike rental, a luggage transport service, and a ferry booking desk from a single integrated 4D application. Here is how we built it — and why 4D was the right choice.
Read more
