A branded travel companion that brings agency itineraries, trip documents, updates and traveller communication into native iOS and Android apps with offline access.
Visit the product websiteTravel information originates in several systems and continues to change after a booking is made. Travellers need flights, hotels, transfers, documents and agency messages to remain understandable and available on a phone—even when source data is irregular, a trip is updated or connectivity disappears.
Within the Corporate Interactive team, I worked across the itinerary service and both native platforms, connecting Sabre and QuoteCloud data to traveller-facing experiences. My role combined maintaining the established delivery pipeline with modernising the iOS and Android clients, especially around persistence, synchronisation, background behaviour and native platform features.
TravelDocs is a mobile travel companion delivered by Corporate Interactive for travel agencies and their customers. It takes itinerary data and documents supplied through QuoteCloud and connected travel systems such as Sabre, then presents them as a trip the traveller can actually use. Flights, accommodation, transfers and other segments sit alongside tickets and supporting documents, agency messages, weather, trip costs, check-in links and real-time notifications. Agencies can provide a branded experience while travellers keep important information available offline.
The product spans more than a mobile interface. A server-side itinerary pipeline receives and interprets travel data, generates or attaches documents and publishes changes to the native applications. The iOS and Android clients then have to preserve a useful local view of that trip through background updates, intermittent networks, time-zone changes and the normal lifecycle constraints of a phone.
I worked on TravelDocs as part of the Corporate Interactive engineering team across several generations of the product. The work involved coordinating changes between the itinerary service, shared product expectations and two native clients rather than optimising one repository in isolation. Existing travel-agency workflows had to keep operating while the apps became more capable, so delivery depended on small compatible steps, careful review and feedback from the people supporting real travellers.
As Principal Engineer, I helped trace issues across those boundaries and turn them into changes the team could maintain. That included reading imperfect source data, agreeing how a state should be represented on each client, and making sure a change that looked correct online still behaved sensibly after an app restart or without a connection.
On the service side, my work included Sabre queue and agency configuration, itinerary parsing, flight and hotel segments, document generation, account and session flows, travel-safety information and operational monitoring. On the native side, I have worked deeply in the Swift application and contributed to Android, with recent iOS work covering persistence and synchronisation, document grouping, time-zone tools, deep links, app locking, attachments, weather fallbacks and handling trips that have been removed on the server.
I also developed native extensions that put timely travel information where it is most useful: widgets, Live Activities and Apple Watch experiences. Those features were not separate demos; they had to read the same trip state and degrade safely when the app or network could not refresh it.
TravelDocs made offline-first behaviour concrete for me. Caching a successful response is the easy part; the real work is reconciliation—knowing what changed, what was deleted, which copy is authoritative and what the traveller should see while that answer is unavailable. It also taught me to treat inconsistent dates, segments and identifiers as normal integration conditions rather than exceptional data. In travel software, time zones, background execution, notifications and deep links are core domain concerns, and reliable teams design them into the workflow from the beginning.
Against the busiest platform on record (882 sessions)
Hours are wall clock with an agent in the loop — specifying, reviewing and correcting, not just generating.