Case study
Poole: A Shared Van Booking App with Real-Time Tracking (UAE)
Shared Van Booking with Real-Time Tracking (UAE)
Role
iOS / mobile engineer — Passenger & Driver apps
Timeline
Built from scratch through production support and hotfixes
Platform
iOS & Android · Passenger App + Driver App
Framework
SwiftUI (iOS) + Firebase
Category
iOS
Passenger app — live Google Maps tracking, stop timeline, driver/vehicle card, and QR verification.
Overview
Poole is a shared van booking platform built for the UAE market, where a single van with multiple seats runs along a fixed route, and passengers book individual seats rather than an entire vehicle — closer to a shared shuttle than a private ride-hailing trip.
The system is built as two connected apps: a Passenger App for booking seats and tracking the van in real time, and a Driver App for managing the route, passengers, and live location broadcasting, with Firebase powering the real-time layer that ties them together.
The problem
Traditional ride-hailing apps match one rider to one driver, which gets expensive for commuters on predictable, high-traffic UAE corridors. Poole targets shared vans with seat-level booking, multi-stop routes, and live visibility for everyone on the trip.
- Commuters on fixed routes needed a cheaper, shared alternative to solo ride-hailing
- Van operators needed a way to fill multiple seats per trip rather than running near-empty vehicles
- Both riders and drivers needed live visibility into where the van was and how many seats were left
- The system needed to handle multiple passengers with different pickup/drop-off points on the same route
Why a two-app architecture
Different core workflows
Passengers need to browse routes, book seats, and track a van. Drivers need to manage a live queue of pickups/drop-offs and broadcast location — fundamentally different UI and interaction patterns.
Simpler, focused UX
Each app stays lean and purpose-built instead of hiding driver-only or passenger-only features behind role toggles.
Cleaner permission model
Driver apps need continuous background location access; passenger apps don’t. Splitting the apps keeps permissions and battery usage appropriate to each role.
Independent release cycles
Driver-side fixes (e.g. route logic) could ship without forcing an update on every passenger’s device, and vice versa.
Architecture & tech stack
The driver app writes the van’s GPS coordinates to a Firebase Realtime Database node on a short interval. Passenger apps subscribed to that trip listen for location and seat/status changes and update the map marker live, with client-side interpolation so the van moves smoothly between updates instead of jumping.
| Category | Tools / tech |
|---|---|
| Passenger App (iOS) | SwiftUI / Swift |
| Driver App (iOS) | SwiftUI / Swift |
| Android apps | Passenger + Driver apps on the same Firebase real-time contracts as iOS |
| Real-time layer | Firebase Realtime Database — live van location, seat availability, trip status |
| Authentication | Firebase Auth with phone OTP (UAE ride-style signup) |
| Maps & routing | Google Maps SDK — route rendering, live van position, ETA |
| Push notifications | Firebase Cloud Messaging — booking, approaching, and trip updates |
| Backend / API | Firebase-centered backend with Cloud Functions where server rules are needed |
| Payments | Trip booking flows with ops-configurable payment handling for UAE routes |
| CI/CD / release | Production store releases with ongoing hotfix support |
Key features
Route-based seat booking (Passenger App)
Passengers select a route and pick their nearest pickup and drop-off points along that route, then book one or more seats — not a full private vehicle.
Live van tracking
Once a trip starts, passengers see the van’s live position on the map, along with an estimated arrival time at their pickup point, powered by Firebase’s real-time sync.
Seat availability in real time
As other passengers book or cancel seats on the same route/trip, availability updates instantly across all connected passenger devices — no manual refresh needed.
Driver route & passenger management (Driver App)
Drivers see an ordered list of upcoming pickups and drop-offs along their route, can mark passengers as picked up or dropped off, and the app updates trip status for all affected passengers automatically.
Trip notifications
Automated push notifications for booking confirmation, approaching-van alerts, pickup reminders, and trip completion.
Engineering challenges & solutions
Challenge
Keeping live location updates smooth and battery-efficient
Solution
Driver location writes were throttled to a few seconds instead of continuous streaming. Passenger maps interpolate between snapshots so the van still looks fluid while Firebase write volume — and battery cost — stay under control for full shifts.
Challenge
Multiple passengers, one van, different stops
Solution
A trip model carries an ordered list of passenger stops (pickup/drop-off) rather than a single point-to-point ride. Driver completion actions update the shared trip node so every affected passenger sees the right next status.
Challenge
Keeping seat availability consistent under concurrent bookings
Solution
Seat changes go through transactional Firebase updates (and server-side checks where needed) so two devices cannot claim the last seat at once. Clients then refresh from the authoritative seat count.
Results
- Passenger and Driver apps shipped as a dual-app system on a live product site: mypoole.com
- Firebase Realtime Database powers live van location, seat availability, and trip status across apps
- Production support continued after launch with issue resolution and hotfix releases
- Documented as a UAE mobility case study with a companion SwiftUI-focused blog summary
What I’d do differently
- Realtime Database was the right fit for live location fan-out; for heavier historical analytics I would add Firestore (or a warehouse) rather than overloading the live trip nodes.
- I would formalize the seat-transaction rules even earlier — overbooking is the one bug class that destroys trust in a shared-seat product.
- I would keep Passenger and Driver as separate apps at this stage; a unified shell only makes sense later if ops tools and rider tools truly converge.
Building a real-time marketplace, delivery, or booking app?
Message on WhatsApp +974 55179747 or book a free consultation — bring your platforms, roles, and must-have launch features.
Prefer a quick jump? Start on the ads landing page or return to portfolio.