Design Uber on iOS: a system design interview answer from the hiring side

The trap in this prompt is the backend. Matching drivers to riders is a famous problem, and candidates spend twenty minutes on it. Nobody asked. The client has more than enough decisions for 45 minutes.

Say the plan in the first minute. The interviewer will pull you off it. The plan is how you get back.

Questions first. Are we designing the rider app, the driver app, or both? How many cities, and do drivers use older phones? What must keep working in a tunnel or a parking garage? Does the rider need to see the trip from the lock screen?

• Functional, rider: request a ride, see the assigned driver approach, follow the trip, see the fare.
• Functional, driver: go online, accept a request, navigate, mark arrived, start and end the trip.
• Non-functional: the rider never sees a confident ETA built on stale data; the driver's phone lasts a shift in a windshield mount; a lost connection never loses a trip.
• Out of scope: matching and pricing on the server, payments processing, the map renderer itself. I will state the API contract I need.

Saying "matching is out of scope" out loud is a senior move. It protects the 40 minutes that are actually yours.

Start with the trip as a state machine: requested, accepted, arriving, arrived, in progress, completed, cancelled. The decision interviewers listen for is not the list. It is who may move it.

The rule: the device proposes, the server ratifies, and money-moving transitions are never client-authoritative. The driver's own screen honours its tap immediately, so the app feels fast, and the rider sees what the server has confirmed. A GPS fix is evidence the server can weigh, never a confirmation on its own, because a fix can be spoofed.

This is where the round is decided. A position is not true or false. It is old or new, and the screen has to change what it says as it ages. Give it numbers:

The exact numbers are a product decision. Having numbers is the engineering one. Measure the age against the server's clock, from when it received the fix, not against the device clock.

struct DriverFix {
    let coordinate: CLLocationCoordinate2D
    let receivedAt: Date   // server time when the fix arrived
}

enum PinState {
    case live(CLLocationCoordinate2D)       // under 6 s: animate, show the ETA
    case updating(CLLocationCoordinate2D)   // 6 to 20 s: keep the pin, stop animating
    case locating                           // over 20 s: no minute count
}

func pinState(for fix: DriverFix?, serverNow: Date) -> PinState {
    guard let fix else { return .locating }
    let age = serverNow.timeIntervalSince(fix.receivedAt)
    switch age {
    case ..<6: return .live(fix.coordinate)
    case ..<20: return .updating(fix.coordinate)
    default: return .locating
    }
}

serverNow is the device clock corrected by the offset measured when the connection opened. Say that sentence, because the follow-up "what if the phone's clock is wrong?" is coming.

Polling every few seconds works in a demo and costs battery and server capacity at rush hour. The answer is a WebSocket, URLSessionWebSocketTask on iOS, carrying position updates whose rate adapts: fast near pickup and during the trip, slow while the rider is waiting for a match, slower still when the network is congested.

The stream is not enough on its own. Tunnels, parking garages and a suspended app all drop it, and an old app version may not speak it at all. So every frame carries a sequence number, and a reconnect asks for everything after the last one the app has applied. The detail that separates levels is when the app records that number:

actor TripStream {
    private let store: PositionStore
    private(set) var cursor = 0   // last sequence the app has stored

    init(store: PositionStore) { self.store = store }

    func consume(_ frames: AsyncThrowingStream<PositionFrame, Error>) async throws {
        for try await frame in frames where frame.sequence > cursor {
            try await store.save(frame)   // durable first
            cursor = frame.sequence       // then the cursor moves
        }
    }
}

Move the cursor when a frame arrives instead of after it is stored, and an app killed between the two believes it is current while it missed thirty seconds of movement. That is exactly how a pin freezes while the car keeps driving.

Here candidates describe iOS as if it were a server. The accurate version, for the two apps:

• Driver app. It needs continuous location during a shift. That means the location background mode, allowsBackgroundLocationUpdates, the system's blue location indicator, and an honest permission request. On iOS 17 and later, CLLocationUpdate.liveUpdates() with a CLBackgroundActivitySession is the modern way to keep updates flowing.
• Rider app. It does not need the rider's location in the background at all. Once the rider leaves the app, it is suspended and its socket closes. The trip stays visible on the lock screen through a Live Activity, updated by push from the server, and the app resyncs from its cursor when it returns.
• Significant-change monitoring is the low-power fallback: coarse, but it can relaunch an app the system terminated.

Then the budget. Continuous high-accuracy GPS, a bright screen and a hot windshield mount are how a phone starts throttling and stops reporting. A senior answer makes accuracy a dial with a rule:

struct LocationPolicy {
    let accuracy: CLLocationAccuracy
    let distanceFilter: CLLocationDistance   // metres between updates
    let degraded: Bool                       // reported to the server
}

func locationPolicy(thermal: ProcessInfo.ThermalState, lowPower: Bool) -> LocationPolicy {
    switch thermal {
    case .nominal where !lowPower:
        return LocationPolicy(accuracy: kCLLocationAccuracyBest, distanceFilter: 5, degraded: false)
    case .nominal, .fair:
        return LocationPolicy(accuracy: kCLLocationAccuracyNearestTenMeters, distanceFilter: 20, degraded: true)
    default:
        return LocationPolicy(accuracy: kCLLocationAccuracyHundredMeters, distanceFilter: 50, degraded: true)
    }
}

The app watches ProcessInfo.thermalStateDidChangeNotification and Low Power Mode, applies the policy, and tells the server it has degraded. Degrading is a state dispatch can see, not a silent decision that leaves it guessing.

A third-party map and routing SDK draws the map, computes routes and estimates arrival times. It is also the largest dependency in the app, updated on the vendor's schedule. The design question is the boundary.

Put it behind your own RouteProvider interface, so no screen and no trip logic imports the vendor's types. Its outputs, a route and an ETA, are advice the trip logic may accept or reject. It can never write trip state. Then give it an exit: a remote flag that switches the provider per cohort, to the last good version or to a coarse ETA computed on the server, with no app release.

Why this earns points: when a vendor release starts burning CPU on one device family, the phones heat up, positions arrive late and pins freeze. With the boundary and the flag, the fix is a configuration change for the affected cohort in minutes. Without them, it is an App Store release and a message asking drivers to update, which helps neither drivers who are offline nor those who will not update today.

Name the numbers. Position age at p99, which is the freshness budget as a metric. Time in degraded mode per trip. Battery drain per active hour, by device model. Reconnects and resync size. Disagreements between what a device proposed and what the server confirmed. Crash-free sessions. All of them segmented by region, device model and app version, because a failure that disappears in the global average is often obvious in one city on one phone.

Rollout: the streaming client ships behind a remote flag, off by default, with polling kept as the fallback. Internal drivers first, then a small share of one city, watching position age and battery. App Store phased release controls how fast the binary spreads; the flag controls how fast the behaviour does and can be turned off without a release. Expect several app versions in the field at once, and write down when the old polling path will be removed.

The trip model, the freshness budget, server authority and the SDK boundary carry over unchanged. Two platform answers change. The driver app keeps location flowing with a foreground service and its persistent notification, which is the Android contract for work the user should know about. And the process can be killed mid-trip and restored, so the trip screen rebuilds from the stored trip and cursor, never from a view model's memory. The Android worked answer walks that platform in depth with a different prompt.

The staff column is not more components. It is the same design with owners, budgets and a way to know when it is wrong.

• "The last position is 21 seconds old. What does the rider see?" Tests the freshness budget.
• "The phone's clock is two minutes off." Tests whether age is measured against server time.
• "The driver drives through a tunnel and the app is killed." Tests the cursor and the resync.
• "The driver taps completed with no signal." Tests what may be shown early and what may not.
• "The phone is overheating in the windshield mount." Tests the accuracy policy and the reported degrade.
• "The map vendor's new release drains batteries on one phone model." Tests the SDK boundary and the per-cohort switch.

Prepare one sentence for each. If a follow-up makes you draw a new box, your design was missing a decision. If it makes you point at a box that already handles it, you are having the conversation the round is for.

How do you design Uber in a mobile system design interview?

Design the client, not the dispatch backend. Name who owns trip state, set a freshness budget for the driver's position and say what the screen shows when it is exceeded, stream positions with a resync path, keep location flowing in the background without draining the phone, and isolate the map SDK so a vendor bug cannot break a trip.

What do interviewers look for in a ride-hailing design?

Three things most candidates skip: a number for how stale a position may be before the UI changes what it claims, a clear line between transitions the device may show early and the ones only the server may confirm, and a battery budget with a rule for degrading accuracy.

How is the Android answer different?

The trip model, the freshness budget and the server authority stay the same. On Android, the driver app keeps location flowing with a foreground service and a visible notification, and process death mid-trip is a normal event. The offline field app version of the Android round is worked through separately.

How should I practise this round?

Answer it out loud against a 45-minute timer, then change one fact: the phone is overheating, the driver loses signal in a tunnel, or the map vendor ships a bad release. Answer again. The second pass shows which parts of your design were decisions and which were boxes.