One app for both app stores
We built it in React Native, which lets one codebase run on iPhone and Android. The app is published on the App Store and Google Play, with booking and itineraries in one place.
Travel app development case study
A travel app that keeps working — when the signal doesn't.
A travel operator wanted booking and itineraries in one app, for travelers who are often offline mid-journey. So the app had to work without a connection from the first screen. We built it in React Native for both app stores.
- 50,000+ monthly active users
- Itineraries, maps and documents work without signal
- One app on the App Store and Google Play
- React Native
- Offline-first data layer
In brief
- The client
- A travel operator in the travel and aviation sector. The work: a cross-platform app build, including offline storage and sync.
- The problem
- Travelers lose signal in transit, underground, and abroad without a roaming plan. That is exactly when they reach for their bookings, and an app that needs a connection fails them.
- The result
- One React Native app for booking and itineraries that works from data on the phone. More than 50,000 people use it every month.
The challenge
Two copies of the data that can disagree.
Keeping data on the phone solves the signal problem and creates a sync problem.
Once data lives on the phone, there are two copies of it: one on the phone and one on the server. The app has to settle any difference between them.
What the brief needed
- One app. Booking and itinerary management in a single place.
- Travelers on the move. They are often offline mid-journey, which is when they open their itinerary.
- No signal at all. Itineraries, maps and documents had to work with no connection.
- Changes made offline. Anything changed while the phone had no signal had to be reconciled (matched up with the server's copy) when it reconnected.
What we built
An app that works from the phone first.
The app treats the data on the device as its working copy and syncs whenever it can.
Data kept on the phone
An offline-first data layer (the part of the app that stores and fetches data) means screens work from data on the phone, with or without signal. Itineraries, maps and documents are stored for offline use.
Catches up when signal returns
When the connection comes back, the app reconciles the phone's copy with the server's, including any changes made while the phone was offline.
The impact
More than 50,000 monthly active users.
Travelers use it every month, signal or no signal. Figures are the client's own, as reported to us.
- 50,000+
- monthly active users
- Offline
- first architecture
What made it work
Offline-first is decided on day one.
Offline support can't be sprinkled onto an app later. In an offline-first app, every screen reads from data held on the phone, and the server catches up in the background. That changes how each screen is built, so the decision had to come before the first one. For this operator, it did.
- Decide at the start, or not at all. Bolting offline support on afterwards means rewriting every screen that touches data, because each one was built assuming the network would answer.
- Raise it early. We would rather have that conversation at kickoff than quote for the rewrite later.
Related services
Facing something similar? Start here.
- Our customers need an app that keeps working when the signal drops.Mobile app development
- We need the same app on iPhone and Android without building it twice.React Native development
- Should our app be cross-platform or native in the first place?Cross-platform app development
More case studies: the AI recruitment platform, the AI teaching platform for schools, the bank security assessment and the hotel management platform, which also has a React Native app. Or see every case study.
Let's talk
Building an app people use on the move?
Decide on offline support before design starts. We can help you work out whether you need it. We reply within one working day.