Airport Rentals — featured image

Online Republic · Webjet Group

Airport Rentals

Airport RentalsCase study · 2026

The rental app, rebuilt mid-flight.

A React Native rebuild of the Airport Rentals app — Wild embedded as dev partners in GCD's team for Online Republic, a Webjet Group company — shipping release after release to both stores while travellers kept booking underneath.

ClientAirport Rentals · Webjet Group
SectorTravel · Car rental
EngagementEmbedded dev partners · GCD
BuildReact Native · Expo — live in stores
React Native RebuildApp Store & Play ReleasesBooking-Flow IntegrationAuth EngineeringCrash MonitoringRelease Automation
Airport Rentals — App Store · Google Play
[ APP — SEARCH, COMPARE & BOOK RENTAL CARS ]
The app in numbers01 / At a glance
3.9.25

Current version, live in the App Store and Google Play.

2

Platforms shipped from a single codebase — iOS and Android.

15+

Production builds shipped this cycle — iOS 246 through 261.

100%

Vehicle benefits fully API-driven — nothing hardcoded in the app.

140→28

Megabytes per build upload, after untracking stale artifacts.

1

Shared booking platform behind app and web — same API, same source of truth.

Phase 01 — The challenge

Rebuilt in production — with travellers booking underneath.

Airport Rentals helps travellers search, compare and book rental cars — and its ageing app needed a modern foundation without ever going dark.

The rebuild had to land on the same shared booking platform as the website, keep real bookings flowing through every release, and pass the client’s own QA — all from a single codebase serving both app stores.

LegacyThe original app, due for a modern rebuild
1Codebase for both platforms — Expo + TypeScript
LiveUsers in-store throughout — no downtime rebuild
3.9.xContinuous releases while rebuilding underneath
Phase 02 — Engineering

A modern stack that ships like clockwork.

Everything in the build exists to make the next release safer and faster than the last.

→Expo SDK 53 + React 19 + TypeScript strict, with typed expo-router navigation
→Two-token auth — identifier token exchanged for an auto-refreshing JWT
→Zustand + AsyncStorage for state that survives restarts
→Formik + Yup booking forms against the shared booking-flow API
→Sentry crash reporting and on-device Storybook 9 for component QA
→EAS builds with auto-incrementing versions — releases as routine
Phase 03 — Quality in production

Shipped, tested, and tested again

Real fixes from real client QA, release after release
/01Reinstall device-record bug found by client QA — fixed and verified
/02Push-notification delivery hardened across reinstalls
/03Benefits list moved fully API-side — updates without releases
/04Build payload cut 140MB → 28MB
/05Booking details & splash polish shipped
/06Unlimited-mileage gating shipped in 3.9.19
Key screens02 / Showcase
[ SEARCH & BOOK — APP ]
Search and book — the core rental flow.
[ BOOKING DETAILS ]
Booking details — everything a traveller needs at the desk.
[ VEHICLE BENEFITS — API-DRIVEN ]
Vehicle benefits, driven entirely by the API.
Outcomes
/01

Live in both stores

A React Native rebuild shipping continuously to the App Store and Google Play — version 3.9.25 and counting, with users on it the whole way through.

/02

One codebase, two platforms

Expo + TypeScript strict replaces platform-specific maintenance — one team, one codebase, both stores.

/03

Release as routine

EAS automation with auto-incrementing builds and Sentry monitoring — fifteen-plus production builds shipped this cycle without drama.

/04

Content without releases

Vehicle benefits and rental content fully API-driven, so the client updates the app experience without waiting on a store review.

The Wild perspective

A rebuild only counts when it ships — release after release, in both stores.