OWTO: Android, iOS, and the Backend Between Them

I could follow one booking through the whole system

At OWTO I led delivery across the native Android and iOS apps and backend work. I was also hands-on. The clients used Kotlin and Swift, the backend used Node.js with Postgres, Firebase supported operational pieces, and the mobile architecture drew from Uber RIBs.

A booking didn't belong to one screen or even one repository. The rider's location changed, the network dropped in and out, payment had its own result, and the server remained the shared source for both apps. When those states disagreed, the symptom often appeared on mobile even when the cause sat elsewhere.

I worked on booking-path changes, GPS behavior, payment handling, and API contracts. Because my scope crossed the clients and backend, I could trace a problem past the first failing UI. If the contract was missing a state the apps needed, I could work on the contract instead of teaching Android and iOS to guess in different ways.

The lead role also meant sequencing changes across people. A client release couldn't safely depend on an API behavior that wasn't deployed, and a backend change wasn't complete if neither native app could represent its new state. I planned those as one piece of delivery rather than separate tickets that happened to share a feature name.

That cross-platform scope meant I could take a booking issue from its first mobile symptom through client state, API contract, and backend behavior, then plan the release across all three.