Case study
A regional transit agency had iOS and Android apps built by different vendors two years apart, and they had drifted. We put one API in front of scheduling, fares and alerts, then rebuilt both clients against it.
Named only with client approval Figures marked are illustrative Reply within one business day
Good morning
Your account at a glance
Balance
12,480
OlDevs rebuilt the iOS and Android apps for a regional transit agency serving a metropolitan area of about one million residents in western Canada, and put a single TypeScript API on Node in front of the scheduling, fare and service alert systems.Both clients were written from one shared specification, iOS in Swift and SwiftUI and Android in Kotlin and Jetpack Compose, each meeting WCAG 2.2 AA for text scaling and screen reader use. A feature now ships to both platforms in the same release instead of arriving late on one of them, and the agency's own developers own and maintain the whole stack. The seven month engagement consolidated 3 to 1 Back-end APIs, and the agency reported 99.5% Crash-free sessions and a 47% reduction in App support tickets.
Key facts
The challenge
The iOS and Android apps had been built by different vendors two years apart and had drifted badly: trip planning behaved one way on one platform and another way on the other, and fare purchases differed again. Each app talked directly to its own mix of back-end services, so a schedule or fare change meant several separate updates and one of them was always late. Riders reviewed the apps accordingly, and agency staff fielded the complaints.
The same journey, entered the same way, produced different results depending on which phone a rider was holding. Staff could not reproduce a complaint without first asking which app it came from, and riders had no reason to trust either answer.
Fare purchase had been implemented separately on each platform, so the steps, the wording and the edge cases did not match. A rider who switched phones had to relearn the part of the app where getting it wrong costs money.
Each app spoke directly to its own mix of back-end services, so a schedule or fare change meant several separate updates coordinated across systems and release cycles. One of them was always late, and the late one was what riders noticed.
App store reviews reflected the inconsistency, and the questions that followed came to agency staff who had no way to fix the underlying difference. Support time went into explaining behaviour rather than into service.
What we built
We put a single API in front of the scheduling, fare and service alert systems, written in TypeScript on Node with a published contract that both clients build against. iOS was rebuilt in Swift and SwiftUI and Android in Kotlin and Jetpack Compose from one shared specification, both meeting WCAG 2.2 AA for text scaling and screen reader use. A feature now ships to both platforms in the same release, and the agency's own developers own and maintain the whole stack rather than depending on whichever vendor built that half.
A TypeScript service on Node sits in front of scheduling, fares and service alerts and presents them as one interface. Back-end APIs went from 3 to 1 as far as the apps are concerned, so a change is made once and both clients see it.
The API contract is documented, versioned and testable, so neither app is guessing at behaviour. Trip planning and fare purchase are specified once and implemented against the same definition rather than interpreted twice.
Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android, both written from the same functional specification so a rider gets the same trip and the same fare regardless of which phone they carry.
Both apps support large text sizes without breaking layout and are navigable with VoiceOver and TalkBack, with service alerts and fare state conveyed in text rather than by colour alone. Accessibility was part of the weekly demo, not an audit at the end.
Process
Audit of both apps and every back end
We documented what each app actually did, where the two disagreed and which back-end service each screen was calling, so the differences were a written list rather than an argument.
One specification for both platforms
Trip planning, fares and alerts were specified once, with the agency choosing the correct behaviour wherever the old apps disagreed. That specification became the shared source for both client teams.
API first, with the contract published
The TypeScript API went in front of scheduling, fares and alerts before client work started, so both apps were built against a stable, documented and versioned contract instead of a moving target.
Parallel client builds with weekly demos
iOS and Android were built alongside each other with a working demo every week, shown on both platforms in the same session so any drift was visible immediately and fixed while it was small.
Paired release and handover
Both clients shipped in the same release, then the API, both apps, the pipelines and the documentation went to the agency's own developers, who own and maintain the stack.
Stack
API and services
iOS client
Android client
Delivery
Accessibility and quality
3→1
Back-end APIs consolidated
99.5%
Crash-free sessions
−47%
App support tickets
Outcomes
Trip planning and fare purchase now come from one specification over one API, so a rider gets the same answer and the same steps whether they are on iOS or Android, and staff can reproduce a complaint without asking which app it came from.
Back-end APIs went from 3 to 1 behind the apps, so a schedule or fare change is made in one place and ships to both platforms in the same release rather than arriving late on one of them.
With behaviour consistent and alerts reliable, the agency reported a 47% reduction in App support tickets, and 99.5% Crash-free sessions on the rebuilt clients.
The API, both apps, the pipelines and the documentation sit with the agency's own developers, who now ship changes themselves instead of coordinating two vendors on two schedules.
In their words
Riders get the same trip and the same fare on either phone now, and we make a change once instead of three times.
Digital services manager, regional transit agency
Public transit
FAQ
The duplication that hurt this agency was in the back end and the specification, not in having two clients. Consolidating three APIs into one and writing a single specification removed it, while native clients kept the platform accessibility support that riders using large text or a screen reader depend on daily.
Three things hold them together: one published API contract with contract tests running in CI, one functional specification that both clients implement, and a release process that ships a feature to both platforms together. Drift becomes visible in the same week rather than two years later.
In practice it means the app still works at large text sizes without cutting off a departure time, that VoiceOver and TalkBack can read a trip plan and a fare screen in a sensible order, and that a service alert is conveyed in text rather than by colour alone. We test that through the build rather than auditing at the end.
That was the point of the engagement. Clients own all code, designs, accounts and IP, and here the agency's developers took over the API, both apps and the deployment pipelines with a documented contract and a period working alongside our team before we stepped back.
We left them in place. The new API sits in front of scheduling, fares and service alerts and presents one interface to the apps, which meant no risky replacement of systems that were already working and let the agency retire or change those services later without touching either client.
Let’s connect
Tell us what is not working. We’ll reply within one business day with how we would approach it and a tailored quote.