--- title: "How DriveStream's drive recording got built" description: "Drive recording started as item five in a list. Here's how it became an automatic, crash-safe feature with animated replay." date: "2026-11-04" app: drivestream kind: build readingTime: "6 min read" image: "/img/build/drivestream/drive-replay.jpg" imageAlt: "DriveStream's animated drive replay with a scrubber and speed control" --- Every drive you take in DriveStream is recorded automatically: the route at 1 Hz, the distance, your moving time and your top speed. The replay runs back on the map at up to 300x. That feature didn't start as a recording app. It started as item five in a list. ## The requirement A few days into the first build sessions, the convoy map was working, the walkie-talkie was connected, and a first real drive had raised a cluster of practical problems. One session captured them all in a single prompt: > 1. In Solo trips and group trips after i reached destination add an end trip button or auto end trip after 1 minute of reaching the destination > 2. Even solo trips , group trips i want to store everything in the cloud > 3. its not showing the route I'm going just drawing one point to another , it should track which route i took what speeds i went etc > 4. Add live activity to show how far everyone is in group trips and some other ideas for solo trip > 5. Our app should be able to run in background even when locked and track the route speed distance etc correctly > 6. I want to be able to create trip with multiple points in our app and once people join the group trip they should have an open in google maps link and it should automatically add all the stops , routes etc in google maps Six things in one message. Items two and three are what turned DriveStream into a recording app: store everything in the cloud, and track the actual route taken rather than just the straight line between start and destination. Item five — running in the background while the screen is locked — was the technical precondition everything else depended on. A phone in a car mount with the screen off is running in the background from iOS's perspective, even if navigation is on. That is exactly the state most drives are in. If the app couldn't track in the background, the route would be gaps and straight lines between position pings. That session produced cloud backup for every drive, crash-safe checkpoints written as you go, and the route log. The Live Activity for the Dynamic Island came from item four of the same list. ## The trigger The original flow required opening the app and creating a trip before recording started. On real drives that step was easy to skip, particularly when the phone was mounted and already doing navigation. The fix was to let the app start automatically when a reliable hardware signal appeared: > Can we use the mapbox default template ? with 3d buildings if possible ? > also can we automatically detect a trip by seeing when the device connects to the car's bluetooth / carplay ? so even without destination set we log the trips and once its disconnect we end the trip ? > Keep some minimum defaults like atleast 1km travelled to use it as a trip so that just connecting to car doesnt endup creating ghost trips etc > also when a trip is ended ensure i dont get back in and resume , i feel someting is broken in this aspect not sure what exactly . keep getting resume option often , not sure if its fixed now though . This prompt did four things at once. Mapbox Standard with 3D buildings was one. The automatic CarPlay and Bluetooth trigger was another: when the phone connects to the car, recording starts; when it disconnects, recording ends. A minimum of 1 km filtered out driveway movements and accidental connections. The third part was the ghost-trip guard. The fourth was a note about a resume bug that had been showing up intermittently. The CarPlay trigger is the right one for a car app. The connection happens before the drive starts. It uses a hardware signal — the CarPlay handshake — rather than trying to infer from speed or location that a drive has begun, which is both slower and more error-prone. You don't have to remember to tap anything. The drive is there when you check. ![DriveStream's convoy map in the low-poly style, with speed readouts above each car](/img/build/drivestream/convoy-map.jpg) *The convoy map. Each car's position is updated from the same 1 Hz location feed that powers recording.* ## The replay Once recording was working, the history became its own feature. Each drive showed the route on a map, but as a static trace. The natural next question was whether that trace could be played back: > Can you make it so that I can replay the routes animated ? The session that handled this built an animated replay: the car moves along the recorded route with a scrubber that lets you jump to any point. The replay updates position, speed and distance as it runs. A single prompt. What came back is the replay the app ships with today. The speed control runs from 1x to 300x. At 1x the drive takes as long as it did. At 300x you get the shape of the route in seconds: where you slowed down, the junction you turned at, the stretch of road where you held a consistent speed. ## The floating car After the replay was working, one visual problem was immediate enough to send as a screenshot: > [Image #25] its floating on the map , can u see how uber/ola etc do this correctly and implement it The replay car was appearing above the road rather than on it. On the low-poly map, where roads and terrain are rendered with height, a marker that doesn't sit on the surface looks wrong. It was visible in the first build — the car clearly hovering above its own path rather than driving along it. The fix was in how the marker's position was derived from the route geometry: aligning the anchor point to the road surface and matching the heading to the bearing of the route segment at each replay frame. The reference in the prompt — how Uber and Ola handle this — was useful framing. Those apps solve the same problem across varied device conditions, and the pattern they follow in MapKit is well-documented. ![DriveStream's drive summary with route map, distance, moving time and top speed](/img/build/drivestream/drive-summary.jpg) *A drive summary: the route map, total distance, moving time separated from time stopped, and top speed.* ## What the recording does now The finished drive recording runs automatically when CarPlay connects and stops when it disconnects, with the 1 km guard against ghost trips. The route is logged at 1 Hz and checkpointed as you go, so a dead battery or crash doesn't lose the drive. Each recorded drive shows the route on the map, the total distance, the moving time separated from time stopped, and the top speed. The history backs up to your account and survives a phone change. The replay runs from 1x to 300x speed with a scrubber. It's the same for solo drives and group convoys: the app records whether you're the only car or one of several. The rank system — Rookie, Commuter, Cruiser, Tourer, Road Warrior, Trailblazer and Legend, with Legend sitting at 40,075 km (the Earth's circumference) — is built from that accumulated distance. Every recorded drive adds to the total. The drive history is both the archive and the scoreboard. The session that introduced recording was not about recording. It was about six things, one of which was running reliably in the background. That one line — item five — is what made everything else work. [DriveStream](https://drivestream.app) is on the App Store for iPhone on iOS 26.