Train delay live tracking timeline UI in React Native

A live train tracking timeline in React Native is a vertical list of stops with a live status on each one and a marker that moves as the journey progresses, optionally next to a map. The build is a custom timeline component for the stops, Reanimated for the moving progress, and react-native-maps when you add the map. The hard part is not the animation, it is making delays, cancellations, and stale data read clearly, which is mostly a design problem. Starting from a free VP0 design and letting Claude Code or Cursor read its source page gets the layout right so you can focus on the live data.

If your timeline already looks fine with fake data but falls apart the moment a train is twelve minutes late or a stop is skipped, the sections below are the parts that make a live tracker trustworthy.

How do you build a live train tracking timeline in React Native?

A train timeline is a vertical line with a node for each station, a status on each node, and a position indicator that sits between the last departed stop and the next one. You render the stops as a list, draw the connecting line behind them, and animate the progress indicator with Reanimated as new position data arrives. react-native-maps, with more than 15,000 stars, adds the optional map view with a marker that moves along the route.

The data model carries most of the weight. Each stop needs a scheduled time, a live or estimated time, and a status such as departed, approaching, delayed, or skipped. The UI reads those fields and shows the difference, so a stop is not just “10:42” but “10:42, now 10:54, delayed 12 min.” Getting that shape right first makes the rest of the screen straightforward.

For the travel-history variant of this pattern, the NS Flex travel history timeline shows the same vertical-timeline structure applied to past journeys.

The timeline: stops, status, and the moving indicator

The visual core is a vertical line with station nodes and a progress indicator that fills as the train moves. Render the line as a thin view behind the list, give each stop a node, and color the segment between completed stops differently from the segment still ahead.

function Stop({ stop, isPast }) {
  return (
    <View style={styles.row}>
      <View style={[styles.node, isPast && styles.nodeDone]} />
      <View style={styles.info}>
        <Text style={styles.station}>{stop.name}</Text>
        <Text style={stop.delayMin ? styles.delayed : styles.onTime}>
          {stop.delayMin ? `${stop.scheduled}, now ${stop.live} (+${stop.delayMin})` : stop.scheduled}
        </Text>
      </View>
    </View>
  );
}

The progress indicator between the last departed stop and the next is where Reanimated earns its place. Animating its position with withTiming when new data arrives makes the train appear to glide forward rather than jump, which reads as live rather than polled. Keep the animation short, around 500 milliseconds, so it settles before the next update. The same animated-marker idea is covered for maps in the live tracking map marker animation guide.

Handling live data, delays, and cancellations

Live status is what separates a real tracker from a static schedule, and it is where most timelines break. Train data arrives by polling an API every few seconds or over a websocket, and your UI has to handle three awkward cases gracefully: a delay that grows over time, a stop that gets skipped, and data that goes stale when the connection drops.

Show delays as a clear difference, not a silent overwrite, so a rider sees both the original and the new time. Mark skipped stops visibly rather than removing them, because a vanished stop is more confusing than a struck-through one. And when an update has not arrived in a while, show a quiet “updated 2 min ago” rather than pretending the data is current; a stale tracker that looks live erodes trust fast. Transit APIs vary widely in what they expose, so design the UI to degrade gracefully when a field is missing rather than assuming every feed is complete.

Relative times help here too. “Departs in 3 min” is easier to act on than an absolute clock time, though showing both covers riders who are planning ahead.

Adding the map view

A map alongside the timeline answers a different question: where is the train right now, in space rather than in the list. With react-native-maps you place a marker on the train’s current coordinates and animate it toward each new position so it glides along the route instead of teleporting. Interpolating between the last and next coordinate over the update interval produces smooth movement even when data arrives only every few seconds.

The route line itself is a Polyline drawn from the sequence of station coordinates, with the completed portion styled differently from the portion ahead, mirroring the timeline. For heavier map work like turn-by-turn overlays, Mapbox navigation in React Native and a flight-radar style live map overlay cover the moving-vehicle pattern at more depth. Keep the map and timeline reading the same data source so they never disagree about where the train is.

Making it smooth with AI and a real design

AI builders produce a timeline layout quickly and then stumble on the live behavior. Claude Code and Cursor will lay out the stops and even animate the progress, but they tend to re-render the entire list on every data tick, hardcode the timezone, or overwrite a delayed time without showing the original. The screen looks right with sample data and misbehaves the moment real, messy data flows in.

A real design plus tight rules fixes most of it. When the stop layout, status states, and delay styling are already decided, the model implements a tracker that handles the awkward cases instead of guessing at them. 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. For the location plumbing underneath, the React Native background location tracking UI covers keeping position current when the app is not in the foreground, using Expo Location where a managed setup fits.

Common live-timeline mistakes

A handful of issues account for most broken trackers. Re-rendering the whole list on every update is the first; a FlatList with stable keys and memoized rows updates only the stops that changed, which keeps a long route smooth. Hardcoding the timezone is the second, and it produces times that are right for the developer and wrong for the rider; format against the journey’s timezone, not the device’s, when they differ.

Silently overwriting a delayed time is the third, because it hides the very information a rider opened the app for. Show the change. The fourth is treating a dropped connection as “no delays,” which is worse than showing staleness honestly; surface the last-updated time instead. None of these show up with tidy test data, which is exactly why they survive into production.

Keeping the timeline accessible

A transit timeline is exactly the kind of screen where accessibility is not optional, because riders often check it one-handed, in motion, or with a screen reader. Two things matter most. First, announce live changes: when a delay grows or a stop is skipped, a sighted rider sees the update, but a VoiceOver user will not unless you tell them. On iOS through React Native you can post an announcement with AccessibilityInfo.announceForAccessibility, so a change like “Utrecht Centraal now delayed 12 minutes” is spoken when it happens rather than discovered only on the next swipe.

Second, give each stop a single, complete accessibility label rather than letting the screen reader read the station name and times as disconnected fragments. A label like “Utrecht Centraal, scheduled 10:42, now 10:54, delayed 12 minutes, next stop” conveys the whole row in one focus. Mark decorative parts of the line and nodes as hidden from accessibility so the reader does not stop on them. These are small additions that make the difference between a tracker a screen-reader user can rely on and one they cannot.

When a map is more than you need

A map is not always worth the weight. For many riders, a clear timeline answers the real question, which is whether their train is on time and which stop is next, and a map adds load, battery use, and another thing to keep in sync for little gain. When the journey is a known line with fixed stops, the timeline alone is often the clearer and lighter choice.

The map earns its place when the geography matters: an unfamiliar route, a multi-leg trip, or a service where seeing the vehicle’s real position reassures the rider. Adding it by default, rather than because it answers a question the timeline cannot, is the common overreach. Decide based on what the rider actually needs to see.

Key takeaways: a train timeline riders can trust

Model each stop with a scheduled time, a live time, and a status, and let the UI show the difference rather than overwriting it. Animate the progress indicator with Reanimated so the train glides, render stops in a memoized list so updates stay cheap, and mark delays and skipped stops visibly. Show staleness honestly when data stops arriving. Add a map only when the geography genuinely helps. Let an AI builder implement the layout from a real design, then harden the data handling yourself. A commissioned tracking screen can cost $5,000 or more, while starting from a free VP0 design costs only the time you spend on the live data.

You can browse VP0 designs to start your timeline from a real screen rather than a blank list.

Frequently asked questions

How do you build a live train delay timeline in React Native?

Render the stops as a memoized vertical list with a connecting line, give each stop a scheduled time, a live time, and a status, and animate the progress indicator with Reanimated so it glides forward as new data arrives. Poll an API or use a websocket for updates, and show delays as a visible difference rather than overwriting the original time. Starting from a free VP0 design gets the layout and status states right so you can focus on the live data handling.

How should a tracker show train delays and skipped stops?

Show a delay as both times, such as “10:42, now 10:54, delayed 12 min,” so the rider sees what changed rather than a silently updated clock. Mark a skipped stop visibly, usually struck through, instead of removing it, because a vanished stop is more confusing than a crossed-out one. When updates stop arriving, show a quiet “updated 2 min ago” so a stale screen does not pretend to be live.

Do I need a map for a train tracking UI?

Not always. A clear timeline answers the main question, whether the train is on time and which stop is next, with less load and battery use than a map. Add a map when the geography genuinely helps, such as an unfamiliar route or a multi-leg trip where seeing the vehicle’s real position reassures the rider. Adding a map by default, rather than because it answers something the timeline cannot, is usually overreach.

Can VP0 provide a free React Native template for a tracking timeline?

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 React Native and SwiftUI variants. You start from the timeline design, hand its source to Claude Code, Cursor, or Rork, and wire up the live data on top, rather than designing the screen and coding it from a blank prompt.

What common errors happen when vibe coding a live tracking timeline?

The frequent ones are re-rendering the whole stop list on every data tick instead of memoizing rows, hardcoding the timezone so times are wrong for the rider, overwriting a delayed time so the change is hidden, and treating a dropped connection as “no delays” instead of showing staleness. All four pass with clean test data, so they tend to ship unless you test with realistic, messy delay scenarios.