Racetrack scatterplot lap times
The same car, the same track, read as a season instead of a drive.
A dashboard you read at 70 mph
TrackDash is a track-day telemetry dashboard for iPhone and CarPlay. The interesting constraint was not the data. It was that the glance is one second long, and Apple decides what a car screen is allowed to draw.
One second is the whole budget
Everything on this screen is sized for a driver who can look away from the road for about a second. That single constraint decides the hierarchy: current speed is set large enough to read peripherally, the trace behind it answers "what was I just doing," and everything else is a tile you can ignore until you are parked.
Colour does one job. The interface is black, and a single highlighter yellow marks the live value. Nothing else on the screen competes for that hue, so the eye lands in the right place without being aimed.
The screen, driving
Everything works with no hardware attached
The speed trace runs 0 to 160 mph from GPS. A friction circle derives lateral and longitudinal g from the gyro and GPS together, so it needs no mount calibration and does not care how the phone is angled. Zero-to-sixty, sixty-to-zero and peak g are detected automatically, with the crossings interpolated inside the GPS fix rather than rounded to it. A drive timer and a GPS odometer reset themselves per drive.
An OBD2 adapter is optional. Connect one and engine channels stream in alongside the GPS data; without one, every screen above still works. That was a deliberate product decision: the app had to be worth opening before anyone bought a dongle for it.
Recording starts on its own above roughly ten miles an hour and saves two minutes after you park, so a session is never lost to forgetting to press a button. Drives export as CSV.
Two dashboards, because Apple has two answers
CarPlay does not let an app draw whatever it likes. Access is granted per app, by category, and the category determines what you are permitted to render. TrackDash sits in an awkward gap between two of them, so it implements both.
Under the navigation entitlement, an app receives a window to draw into, which is how map apps render maps. The full dash lives there: temperature cards, both scrolling traces, and a track-position tile drawing the driven line and the car on it. It is the version I would want in a car. It is also the version Apple is unlikely to approve, because that entitlement exists for navigation products and the review looks at what the map layer actually shows.
The sanctioned category for this app is driving-task, and it allows template text rows refreshed about once a second. No custom drawing, no gauges, no map. The same telemetry, rendered as a list.
Designing both taught me more than either would have alone. The rich version is a design problem. The text-row version is an editing problem: with five rows and one refresh a second, you are choosing which five numbers a driver gets, and every decision about hierarchy has to survive being expressed as plain words in a fixed order.
What the constraints were worth
The app is road-tested and in testing for CarPlay approval. The part I would defend is what it refuses to do. The posted speed limit appears only when the map data actually has one tagged for the road you are on, because iOS exposes no posted-limit API and a guessed limit on a driving screen is worse than no limit at all.
That is the same rule as the reconstruction note under my lap-time chart and the source line under every chart on this site. An instrument that shows a number it cannot support is not a convenience. It is a thing that will eventually be believed.