Design a Mobile Travel Itinerary App

Updated July 26, 2026 · techinterview.org

Travel itinerary apps (TripIt, Hopper, Google Trips legacy) auto-organize a trip from confirmation emails into a unified itinerary. The interview tests whether you understand email parsing, time-zone-aware data modeling, real-time flight tracking, and the operational realities of a stressed traveler at an airport.

Functional requirements

• Forward email confirmations; app extracts trip details
• Unified timeline of flights, hotels, rentals, restaurants
• Time-zone aware: shows arrival in destination time
• Real-time flight status (delays, gate changes)
• Offline maps and notes for destinations
• Sharing with travel companions

Email parsing

Source of trip data: confirmation emails forwarded by the user.

Parsing strategies:

• Pattern matching for known senders (United, Delta, Hilton): regex or template extractors keyed to each sender’s HTML layout. Fast and accurate for the handful of airlines and chains that cover most volume, but they break the moment a sender tweaks their template, so budget for ongoing maintenance.
• Generic ML model for unknown formats: a trained extractor pulls dates, times, confirmation numbers, and locations from senders you have no template for. Precision is lower than a hand-built template, so route low-confidence extractions to review instead of silently creating a wrong event.
• Schema.org structured data when available: many confirmation emails embed machine-readable markup (schema.org/FlightReservation, LodgingReservation) as JSON-LD. When it’s present it’s the cleanest source — parse it first and fall back to text extraction only when it’s missing.

Modern apps increasingly use LLMs for robust parsing across diverse email formats.

Time-zone modeling

The most-broken aspect of travel apps. Each event has:

• Local start/end time: store the wall-clock time the traveler actually experiences, not just a UTC instant. A 9:00am departure should read 9:00am regardless of where the device or server sits.
• Time zone (IANA identifier): keep the IANA zone (America/New_York, Asia/Tokyo) with each event, never a fixed offset — offsets shift with daylight saving, so a stored offset goes stale across a DST boundary. Zone plus local time lets you compute UTC on demand for sorting and countdowns.
• Logical “trip day” for organizing: group events into “Day 1, Day 2” by the destination’s local calendar so an overnight red-eye lands on the right day. A classic interview probe is the flight that departs late one night and arrives the next morning across zones.

Critical: a 1pm Tokyo arrival is at midnight in NYC. The display must show local-to-the-event time, not user’s home time.

Real-time flight tracking

Sources:

• FlightAware, FlightStats, OAG (commercial APIs): these feeds carry schedules, live status, gate, and delay data. Pricing is usually per-query or tiered, so cache aggressively and only poll flights inside an active window — roughly the day of travel — rather than every flight in every stored itinerary.
• Airline-specific APIs (limited public access): a few carriers expose direct APIs, often gated behind a partnership. Coverage is uneven, so treat these as a supplement to a commercial aggregator instead of the primary source.

Push notifications for:

• Schedule change: the highest-value alert — a departure moved by hours. Fire it the moment the feed reports the new time so the traveler still has room to rebook.
• Gate change: common and easy to miss on airport boards. Include both the old and new gate so the message is actionable at a glance.
• Boarding: time-sensitive; deliver as boarding starts. Some travelers lean on this instead of listening for gate announcements.
• Departure / arrival: confirms the leg happened and lets whoever is meeting the traveler track progress. The arrival push is also a good trigger to flip the display to destination-local time.

Critical that these are reliable — travelers count on the app.

Offline maps and notes

For destinations without reliable cellular:

• Pre-download maps (OpenStreetMap or Google offline maps): bundle a map region for each destination while the user still has wifi. OpenStreetMap tiles can be self-hosted; Google’s offline maps carry licensing limits worth checking before you commit.
• Cache key destinations: hotel address, restaurant reservations: store the geocoded hotel and reservation locations so the traveler can pull up an address and navigate with no signal.
• Cache trip docs (boarding pass PDFs, hotel confirmations): keep these on-device — the moment you most need a boarding pass is often the moment you have zero bars.

Wallet integration

Boarding passes go in the user’s mobile wallet:

• Apple Wallet: PKPass format: boarding passes ship as signed .pkpass bundles, so your server needs the pass type ID and signing certificate to generate or update them. The payoff is lock-screen and geofenced surfacing right at the airport.
• Google Wallet: Wallet API: passes are created server-side and added through a save link or JWT. Both platforms support push updates, so a gate change can update the pass in the wallet itself, not only inside your app.

App can generate or import these from email attachments.

Sharing

Travel companions need access:

• Read-only sharing via link or in-app invite: the common case — a companion sees the itinerary but can’t change it. A shareable link is easiest; an in-app invite ties access to an account so you can revoke it later.
• Full collaboration: anyone can edit, which raises concurrent-edit and conflict questions — the same territory as collaborative editing, so be ready to talk about last-write-wins versus merging.
• Per-event sharing (only the joint dinner, not the whole trip): share a single reservation without exposing the full itinerary. Model access at the event level, not just the trip level, or this case gets awkward.

Calendar integration

Sync trip events to user’s calendar:

• iOS: EventKit: write events straight into the user’s calendar after requesting calendar permission. Keep a stable external identifier per event so a re-sync updates the existing entry instead of duplicating it.
• Android: Calendar Provider: the Calendar Provider content API fills the same role on Android — you insert events against a chosen calendar account.
• Cross-platform: ICS export: an .ics file works everywhere with no per-platform integration, which makes it a solid fallback and easy to share. The catch is it’s a one-way snapshot, so later changes won’t propagate.

Battery and data

Light. Travel apps are reference apps, not always-on. The exception: real-time flight tracking pushes are infrequent but high-value.

Frequently Asked Questions

What if the user forwards an email in a non-supported language?

Modern LLM-based parsers handle most languages. Older pattern-matching parsers fail; surface the email to manual review.

How does the app handle a multi-leg flight?

Each leg as separate event. Display as a connected itinerary. Track delays per leg.

What about loyalty programs?

Connect to airline/hotel accounts; track points and tier progress. OAuth is the norm.