Yandex Go style taxi booking UI in SwiftUI: the full flow

A Yandex Go style taxi booking UI in SwiftUI is a map-first flow: a MapKit map with pickup and dropoff pins, address entry, tariff cards showing price and arrival time, and a booking state machine that moves from request to matched to en route to arrived. The part that carries real risk is payment, and the rule there is absolute: card data and payment keys never live in the app, only a certified processor like Apple Pay touches them. The fastest way to get the screens right is to start from a free VP0 design and let Claude Code or Cursor read its source page, then wire the map, the booking states, and the payment provider on top.

A ride-hailing flow is mostly states: the user is choosing, waiting, matched, or moving, and each needs its own clear screen. Getting those transitions to feel calm and certain is the whole job. The sections below cover the map, the booking flow, secure payment, and the mistakes that make a booking app feel anxious or unsafe.

How do you build a taxi booking UI in SwiftUI?

You build a full-screen map with the booking controls layered over it as a bottom sheet. The map handles pickup and dropoff pins and the route between them, the bottom sheet handles address entry and tariff selection, and a state machine drives the flow from booking to ride. MapKit gives you the map, annotations, and the route polyline natively, so you do not need a third-party map for a standard build.

The booking flow is a sequence of states the UI moves through: entering addresses, choosing a tariff, searching for a driver, driver matched with car and plate details, en route, and arrived. Each state is a distinct screen or sheet, and the transitions between them are where the app feels responsive or broken. Keeping the map visible throughout, with the bottom sheet changing per state, is the pattern that reads as a modern ride app. The live-map foundation carries over from the parking spot finder live map.

The map, pins, and route

The map is the backbone, so get its pins and route right first. A pickup pin and a dropoff pin anchor the trip, and a route polyline between them shows the path, with the map framing both points so the user sees the whole trip at a glance. As the driver is matched and moves, a car marker animates along the route toward the pickup.

Map(position: $camera) {
    Marker("Pickup", coordinate: pickup).tint(.green)
    Marker("Dropoff", coordinate: dropoff).tint(.red)
    MapPolyline(route).stroke(.blue, lineWidth: 5)
}

Apple’s maps guidance covers annotation and overlay conventions, but the booking-specific detail is framing: when both pins are set, fit the camera to show pickup, dropoff, and the route together, so the user immediately understands the trip. Animate the driver’s marker smoothly toward the pickup rather than jumping it, since a teleporting car reads as a glitch. Custom map markers, when you need them, follow the same idea as the Kakao Map custom marker UI.

Ride options and the booking flow

The tariff cards are where the user decides, so each should show the class, the price, and the arrival time clearly. A row of cards, economy, comfort, business, lets the user compare at a glance, with the selected one highlighted and a single confirm action below. Keep the price and ETA prominent, since those are the two numbers the decision turns on.

After the user confirms, the flow enters its waiting states, and these are the ones most clones skip. Searching for a driver needs a clear, calm indicator rather than a frozen screen. Driver matched should show the car, plate, color, and the driver’s ETA, the details a rider checks before getting in. En route shows the trip progressing, and arrived signals completion. A cancel option must stay available through the early states, with clear wording about any fee. The booking-card patterns from the flight booking app UI kit translate directly to ride tariffs.

Payments without holding card data

This is the part that must be built correctly, because it touches money and regulated payment infrastructure. The rule is simple and non-negotiable: your app never stores or transmits raw card numbers, and your payment keys never ship inside the app. Instead, you use a certified payment provider, Apple Pay through PassKit being the cleanest on iOS, or a PCI-compliant processor, which tokenizes the card so your app only ever handles a token, never the real number.

The flow is that the app requests payment through Apple Pay or the processor’s SDK, the provider handles the card securely, and your server confirms the charge using a secret key that lives only on the server. Anything that looks like storing a card number in the app, or embedding a processor’s secret key in the binary, is both a security hole and a compliance failure, since a key in a mobile app can be extracted. Build the payment path through a certified provider from the start, because retrofitting compliance after a prototype that hardcoded a key is how secrets end up in a repo.

Making it native with AI and a real design

AI builders produce the map and tariff cards quickly and get the states and payment wrong. Claude Code and Cursor will lay out the booking sheet, then skip the searching, matched, and cancel states so the flow feels incomplete, and worse, they will sometimes scaffold a payment form that takes a raw card number directly, which is exactly the compliance mistake to avoid. The screens look done and the riskiest parts are wrong.

A real design plus explicit rules fixes most of it. When the booking states and the payment approach are already decided, the model builds the full flow and routes payment through a certified provider, and you tell it to use Apple Pay or a tokenizing processor rather than a raw card form. Starting from a free VP0 design gives that structure, since each design has a machine-readable source page Claude Code, Cursor, or Rork read from a pasted link. Always review the payment path yourself, because taking a raw card is a default mistake AI makes.

Common taxi booking UI mistakes

A few mistakes recur, and some are serious. Taking or storing raw card data in the app is the worst, and the fix is a certified provider that tokenizes. Skipping the waiting states, searching, matched, cancel, is the second, which makes the flow feel frozen and uncertain exactly when the rider is most anxious.

Teleporting the driver marker instead of animating it is the third, which reads as a glitch. Poor address entry, with no autocomplete or no clear pickup confirmation, is the fourth, since getting the pickup wrong is a real-world failure, not just a UI one. The fifth is hiding the cancel option or its fee, which erodes trust at the moment it matters. A certified payment path, complete waiting states, smooth marker animation, solid address entry, and an honest cancel flow are what make a ride app feel safe to use.

Keeping the driver location live

Once a driver is matched, the rider watches the car approach, so how that location updates decides whether the app feels live or laggy. The driver’s position comes from the server, pushed over a websocket or polled every few seconds, and the app animates the marker between updates so it glides rather than jumping. Interpolating the car’s movement over the update interval, the same technique any live-tracking map uses, hides the gap between sparse server updates and produces smooth motion even when a new position arrives only every few seconds.

Two details make it trustworthy. Show an honest ETA that updates as the driver moves, rather than a fixed countdown that drifts out of sync with reality, and handle the case where updates stop: if the driver’s location goes stale, show that the connection is reconnecting rather than leaving a frozen car on the map. A rider staring at a car that has not moved for thirty seconds will assume the app is broken, so admitting a lost connection is better than faking continuity. Throttle the updates to what the server actually sends, since polling faster than the data changes only drains battery.

When a simpler booking flow works

A full ride-hailing flow is not always needed. For a single-operator service, a scheduled pickup, or a B2B booking where the rider and route are known, a simpler form-based booking without live driver matching may serve better and be far less to build. The full map-and-matching flow earns its place when there is a real fleet, live availability, and on-demand matching to show.

For a fixed-route or pre-booked service, the live map and tariff comparison are overhead the product does not need. Matching the flow to whether the service is on-demand or scheduled keeps you from building a dispatch system for a single car. Decide by how dynamic the actual service is.

Key takeaways: a taxi booking UI that feels safe

Build a map-first flow with MapKit pins and a route, tariff cards showing price and ETA, and a booking state machine through searching, matched, en route, and arrived, with the map visible throughout. Route every payment through a certified provider like Apple Pay so the app never holds a raw card or a payment key. Animate the driver marker smoothly, give address entry real autocomplete, and keep an honest cancel option. Let an AI builder build the screens from a real design, then review the payment path yourself. A commissioned ride-booking feature can cost $5,000 or more, while starting from a free VP0 design gives you the layout for nothing.

You can browse VP0 designs to start your booking flow from a real layout rather than a blank map.

Frequently asked questions

How do you build a taxi booking UI in SwiftUI?

Build a full-screen MapKit map with pickup and dropoff pins and a route, layer a bottom sheet for address entry and tariff selection, and drive the flow with a state machine through entering addresses, choosing a tariff, searching for a driver, matched, en route, and arrived. Keep the map visible while the sheet changes per state. Route payment through a certified provider so the app never holds card data. Starting from a free VP0 design gets the screens and states right so you focus on the map and booking logic.

How should a ride app handle payments securely?

The app must never store or transmit raw card numbers, and your payment keys must never ship inside the binary. Use a certified provider, Apple Pay through PassKit on iOS or a PCI-compliant processor, which tokenizes the card so your app only handles a token. The actual charge is confirmed on your server with a secret key that lives only there. Building this path from the start avoids the compliance failure of a hardcoded key or a raw card form, which AI builders sometimes scaffold by default.

What booking states does a taxi UI need?

At minimum: entering addresses, choosing a tariff, searching for a driver, driver matched with car and plate details, en route, and arrived, plus a cancel option through the early states. The waiting states, searching and matched, are the ones most clones skip, and they are exactly when the rider is most anxious, so they need calm, clear indicators rather than a frozen screen. Showing the car, plate, color, and ETA at the matched state is what lets a rider safely identify their ride.

Can VP0 provide a free SwiftUI template for a taxi booking app?

Yes. VP0 is a free iOS app design library where every design has a machine-readable source page an AI builder reads from a pasted link, with SwiftUI and React Native variants. You start from the booking design, with its map, tariff cards, and states already decided, hand its source to Claude Code, Cursor, or Rork, and wire MapKit, the booking flow, and a certified payment provider on top, rather than building the flow and its states from scratch.

What common errors happen when building a taxi booking UI?

The frequent ones are taking or storing raw card data instead of using a tokenizing provider, skipping the searching, matched, and cancel states so the flow feels frozen, teleporting the driver marker instead of animating it, weak address entry without autocomplete or pickup confirmation, and hiding the cancel option or its fee. The fixes are a certified payment path, complete waiting states, smooth marker animation, solid address entry, and an honest cancel flow.