Offline-First iOS App
Development: The Transdata Kollect Case Study

Picture an enumerator riding a minibus through Maputo, counting passengers as they board and alight, noting the fare, the operator, the vehicle type, the exact spot on the route. Now take away the mobile signal, because on that bus, on that route, there often isn’t one. If the app in her hand needs the internet to save what she just recorded, that data is gone the moment she taps. Multiply that across a full day, a full team, a full survey, and you understand why field data collection is one of the least forgiving problems in mobile software.

Transdata Kollect was built for exactly that world. It’s a public-transport survey system for Transdata Consult, pairing a native, offline-first iOS app for field enumerators with a React and Node.js dashboard for supervisors, engineered so that not a single trip is ever lost to a missing signal. This is how it was designed to be dependable where it matters most: out in the field, offline.

In one line: capture every trip and stop offline, auto-sync when a connection returns, watch it live on the dashboard, and export to CSV and KML.

The Problem: Field Data Collection Is Uniquely Unforgiving

Collecting transport survey data isn’t like filling in a form at a desk. The work happens on the move, often with no signal, and the output has to be both tabular and geospatial at once. Several hard constraints stack on top of each other.

There’s usually no connectivity in the field, so the app can’t depend on being online to capture or save anything. A trip is a sequence of stops, a GPS track punctuated by stops, each needing several values captured quickly and correctly: boarding and alighting counts, fare, operator, and vehicle type. Data must not be lost, because field data that fails to save or sync is gone for good, so capture has to be reliable offline and reconcile cleanly later. The output has to be tabular and geospatial together, meaning CSV for spreadsheets and KML for mapping from the same records. Supervisors need live visibility, seeing incoming data and which devices have synced without waiting for a manual handover. And it all has to fit the existing tooling, flowing into KoboToolbox, the client’s survey platform, through its API.

Miss any one of these and the survey has holes in it. The system had to answer all of them.

The Solution: Offline-First on iOS, Live on the Dashboard

Transdata Kollect pairs an offline-first iOS app for enumerators with a React and Node.js dashboard for admins. An enumerator logs in with their Enumerator ID, selects a project, and starts a trip. The app tracks GPS continuously and lets them tag stops as Start, Intermediate, or End. At each stop, a validated form captures passengers boarding and alighting, fare collected, operator, vehicle type, a timestamp, and optional comments. Every entry is written to on-device SQLite immediately, so nothing depends on a signal, and the app auto-syncs to the backend whenever a connection is available.

On the admin side, supervisors manage enumerators and projects, watch trip data arrive in real time, filter by date, route, and vehicle type, monitor which devices have synced, and export to CSV and KML. The same data flows into KoboToolbox through its API, and the dual export serves both spreadsheet analysis and mapping in a GIS or Google Earth.

The Design Decisions That Make It Work

Four decisions shape the build, starting with the one everything in the field depends on.

Offline-first, not offline-tolerant. Every capture is written to on-device SQLite first and synced later, so the app behaves exactly the same with or without a signal. No field data is ever left at the mercy of connectivity, which is the whole difference between a survey tool that works on a bus route and one that doesn’t.

A trip is a GPS track plus tagged stops. Modeling a trip as continuous GPS with Start, Intermediate, and End stops, each carrying its own counts and fare, matches how surveys actually run and produces clean geospatial output that maps directly to KML.

Dual export from one dataset. CSV and KML are generated from the same trip and stop records, so the tabular and geospatial views never diverge and analysts use whichever tool fits, a spreadsheet or a GIS, from a single source.

One dataset, several destinations. The same captured data reaches the dashboard, the CSV and KML exports, and KoboToolbox, so there’s a single source of field truth feeding every downstream use, rather than parallel copies that drift apart.

The Technical Architecture

The hard part is capturing reliable, geotagged survey data where there’s no signal, then getting it cleanly to a dashboard, to exports, and to KoboToolbox. The iOS app is offline-first over SQLite with continuous Core Location tracking; the Node.js backend receives synced data, serves the React dashboard, and produces CSV and KML; and the KoboToolbox integration ties it into the client’s survey tooling. Building a native offline-first app that stays correct through days of intermittent connectivity, then reconciles cleanly on the server, is demanding iOS engineering, and it’s the kind of work an iOS native app development agency is built to get right.

A few subsystems carry the product. Offline capture and storage writes trips and stops to SQLite the moment they’re entered, with form validation, so an enumerator can work an entire route with no connection and lose nothing. Continuous GPS and stop logging uses Core Location to track the trip while the enumerator tags Start, Intermediate, and End stops, each geotagged and timestamped. Auto-sync and status pushes queued trips to the Node.js backend when a connection returns and shows supervisors which devices and trips have synced. Dashboard, filtering, and exports show incoming trips live and generate CSV and KML from the same records. And KoboToolbox integration submits the captured data into the client’s existing survey workflow through its API.

Each stop, incidentally, carries eight-plus fields, stop type, boarding and alighting counts, fare, operator, vehicle type, an automatic timestamp, GPS location, and optional comments, all captured through a validated form that’s fast to fill and hard to get wrong on a moving bus.

Outcomes and Value Delivered

Because capture is offline-first and one dataset feeds every destination, the system is dependable in the field and useful the moment data arrives. There’s no lost field data, since enumerators work anywhere with nothing depending on a signal. The output is clean in both forms, the same trips exporting to KML for mapping and CSV for analysis. Supervisors get live oversight, seeing data arrive and monitoring sync status in real time. Capture is fast and consistent thanks to validated forms. It fits the existing workflow through KoboToolbox. And it’s ready to run and hand over, with the delivery including the app, dashboard, full source, documentation, sample exports, and 45 days of post-completion support.

The performance figures for a system like this are best described as illustrative rather than audited: full offline capture on SQLite, auto-sync on reconnect, eight-plus fields per stop, CSV and KML exports, KoboToolbox integration, two roles, a real-time filtered dashboard, and 45 days of included support. The defining goal is simple to state and hard to earn, capture every trip and stop reliably offline, then get it to the dashboard, the exports, and KoboToolbox with nothing lost.

This was a very different iOS brief from the other work in this series, from building an offline iOS museum audio guide around accessibility, to clearing an App Store 4.3(a) rejection through a full revamp, but all three share the same instinct: solve the constraint that actually matters, whether that’s a missing signal, a blind visitor, or a strict reviewer.

The Challenges We Solved

Capturing reliably with no signal came down to on-device SQLite storing every trip and stop as it’s entered, so the app behaves identically online or off. Syncing without losing or duplicating data meant queued trips reconcile server-side on reconnect, with sync status visible on the dashboard, so nothing silently disappears between field and server. Producing tabular and geospatial output together meant generating CSV and KML from the same records so the two views never drift. Capturing stop data quickly and correctly meant a validated, form-based flow for boarding, alighting, fare, operator, and vehicle type. Fitting into KoboToolbox meant integrating through its API so Kollect adds field collection without replacing the surrounding tooling. And giving supervisors live oversight meant a real-time dashboard with filters and sync monitoring, so admins manage field data as it arrives rather than after the fact.

The Result

Transdata Kollect is a dependable, offline-first field survey system: a native Swift iOS app that captures GPS trips and tagged stops with no signal, a Node.js backend that reconciles the synced data, a React dashboard that shows it live and filters it by date, route, and vehicle type, and CSV, KML, and KoboToolbox outputs from a single source of truth. Enumerators work anywhere and lose nothing; supervisors see everything as it lands; analysts get both spreadsheets and maps. It ships ready to run, with source, docs, sample exports, and 45 days of support, and it turns the messy reality of on-the-move data collection into something reliable end to end.

Building an Offline-First or Field App on iOS?

If your product has to work where the signal doesn’t, capturing data reliably offline, syncing cleanly when it can, and feeding dashboards, exports, and third-party platforms from one dataset, that’s a specific and demanding kind of iOS engineering. It’s exactly what we do. As an iOS app development company, we build native offline-first apps, the backends and dashboards behind them, and the integrations that fit them into your existing tooling, delivered ready to run and hand over.

Frequently Asked Questions

Can you build an iOS app that works fully offline in the field?

Yes. Transdata Kollect captures every trip and stop to on-device SQLite immediately, so enumerators work with no signal and nothing is lost, then it auto-syncs to the backend when a connection returns.

How do you make sure no data is lost or duplicated when syncing?

Captured trips are queued on the device and reconciled server-side when they sync, and the dashboard shows which devices and trips have synced, so supervisors can see the state of the field data rather than guessing.

Can you export survey data for both spreadsheets and mapping?

Yes. CSV and KML are generated from the same trip and stop records, so the same data opens in a spreadsheet for analysis or in a GIS or Google Earth for mapping, without the two views drifting apart.

Can you integrate an iOS app with KoboToolbox or other survey platforms?

Yes. Kollect submits and syncs its captured data into KoboToolbox through its API using the client’s credentials, so it slots into an existing survey workflow rather than replacing it.

Do you build the dashboard and backend too, not just the iOS app?

Yes. This delivery included the native iOS app, a React dashboard, a Node.js and PostgreSQL backend, CSV and KML exports, KoboToolbox integration, full source, documentation, and 45 days of post-completion support.