Developing a Mobile App for Travel (TravelTech)
Booking flight through mobile browser—12 screens user must complete in 3 minutes before boarding in passport control queue. If any screen times out, app cold starts after backgrounding, or map freezes from unloaded tiles—user switches to competitor. TravelTech apps don't forgive instability.
What Distinguishes Travel Apps from Other Verticals
Main pain—heterogeneous external APIs with unpredictable SLA. Amadeus GDS returns response in 800 ms best case, peak season 4–6 seconds. Show skeleton and block screen, user taps "back" in 2 seconds. Right solution—progressive loading: first return cached results from Room/CoreData (past searches), simultaneously start fresh request, update list via DiffUtil/diffableDataSource without full screen redraw.
Second bottleneck—offline mode. Tourist in expensive roaming abroad can't load route map. Use MapLibre GL Native and preload tile packages (.mbtiles) by region before trip—user selects country, downloads ~40–120 MB, navigation works without internet. iOS pairs well with URLSession background transfer for background download during charging.
System Calendar API integration (EventKit iOS, CalendarContract Android) adds flights, hotel bookings, tours straight to system calendar with deep links back to app. Users don't notice how convenient until it breaks.
Booking and Real-Time
Working with booking engines (Amadeus, Sabre, Travelport) or aggregators (TravelFusion, Duffel API) built on polling or webhook pattern. Duffel provides REST with good docs, Amadeus requires OAuth 2.0 and understanding their NDC protocol. Both require storing search result locally (encrypted SQLCipher or iOS Data Protection)—user returns in 20 minutes expecting same variant.
For flight status change push use Firebase Cloud Messaging (Android) and APNs (iOS) with content-available: 1 for silent push—app updates data in background via BGAppRefreshTask without waking user.
Maps and Routes
| Scenario | Technology | Note |
|---|---|---|
| Online map with POI | Google Maps SDK / MapKit | Ready styles, fast integration |
| Offline navigation | MapLibre GL Native | Open source, own tiles |
| Walking routes | OpenRouteService API | Pedestrian, cycling profiles |
| AR guidebook | ARKit / ARCore | Overlay POI on camera |
AR guidebooks—separate story. Android ARCore requires Depth API support for stable object placement. Old Pixel 3 without LiDAR—objects "float" on movement. Honestly tell client on design stage.
Stack and Architecture
For cross-platform TravelTech projects typically choose Flutter with BLoC or Riverpod. Pragmatic reason: Dart Isolates let you parse large JSON responses (500+ flight records) outside main isolate without UI janks. Native Android—Kotlin Coroutines + Flow, iOS—Swift Concurrency with async/await. Architecture—Clean Architecture with data/domain/presentation layers; not religion, necessity with 4 different data sources per screen.
Localization—separate module. Work with ICU message format via intl (Flutter) or Lokalise SDK. Dates, currencies, phone formats don't hardcode—NumberFormat.currency(locale: userLocale) instead of manual symbols.
From Practice
Project: tour aggregator for CIS market. Flutter, 3 platforms (iOS / Android / Web via Flutter Web). Main post-launch issue—OOM crash on Android scrolling 300+ tours with images. Cause: Image.network without cacheWidth/cacheHeight loaded 4K originals to memory. Solution—CachedNetworkImage with explicit memCacheWidth and lazy loading via flutter_staggered_grid_view with strict addRepaintBoundaries: true. Memory use dropped from 380 MB peak to 140 MB on Redmi Note 10.
Work Stages
- Audit requirements—understand client's existing external APIs (GDS contracts, partner agreements), what integrate fresh
- Architecture design—data schema, offline-first or online-first, caching strategy
- UI/UX—Figma prototype, booking flow sign-off
- Development—iterate by vertical slices (search first, then booking, then profile)
- Testing—Appium for E2E, XCTest/Espresso for unit/integration, load testing on API integrations
- Publishing—App Store Connect + Google Play Console, Fastlane for automation
- Support—monitoring via Firebase Crashlytics + Sentry, A/B tests via Firebase Remote Config
Timeline depends on scope: MVP with flight search and hotel booking—3 months from start. Full travel superapp with routes, AR features, offline maps—6–12 months. Cost estimated after detailed requirement analysis and existing API audit.