Trace

• 

  Some initial draft designs

• 

  Screen implementantions

Inspiration

I travel quite a lot and usually without planning far ahead.

Apps like Flighty can create a great recap of recent flights, but they do not show the whole journey, and they cannot reconstruct travel from before I started using them. At the moment I have years of geotagged photos sitting in Immich, so at some point I tried manually recreating my history using something off the shelf selfhosted but it didn't quit fit what I was going for, and thus Trace started with a "Can i build something that could use the information I already have with my stored old photos to rebuild the travel history I never tracked?"

What Trace does

At the moment it connects to Immich with read only access and imports capture dates and location metadata, it doesn't download the photos. It then groups those records into possible visits and journeys, filters out routine locations such as home and work, and produces a map and yearly recap.

Travel data is often incomplete, so Trace keeps uncertain places in a review queue. I (or an user) can decide whether a location was a visit, part of a route, incorrect, or irrelevant.

GPT-5.6 (or any model on codex) can optionally review those places using structured context such as nearby observations, distance from home, journey boundaries, and timing but the suggestions are not applied automatically.

How it's built

Trace is a phone first React Native application built with Expo. It uses Mapbox for travel maps, Apple MapKit for selecting routine locations, secure on-device storage for credentials, and a local ledger for confirmed travel decisions. Deterministic code handles distances, dates, location grouping, journey boundaries, and recap statistics. GPT-5.6 handles the ambiguous cases where the available evidence does not give an obvious answer.

Codex helped throughout the project, from refining the original idea and creating Penpot designs (connected via an mcp) to implementing the application, running it on iPhone simulators and on my physical device, reviewing changes, and debugging reconstruction decisions against the Immich metadata, worth mentioning prior to this I had no experience building IOS apps.

Challenges and lessons

Photo metadata is not a continuous location history. I might photograph an airport from a plane, spend a day somewhere without taking a photo when I return home, or take pictures near work that should not become a trip thus the early reconstruction attempts produced journeys that didn't much up

Another challenge, I tried splitting work into parallel implementantions while still remaining in the same thread (so the primary build thread), this however didn't work out, I eventually used narrower task boundaries and returned to one implementer and one reviewer on the shared checkout. (app does support worktrees but i think i could have done better if i did the cordination however this would have resulted in a separate thread, something to polish more in my workflows probably)

Overall though the model is decent at design, and i got to learn a bunch of things about IOS dev, plus got to see how it looks iterating consistently with the model on something from scratch (i use coding agents almost everyday but not like this thus I got a workflow out of this build for the future)

What's next for Trace

The next step is to...

• Test Trace against my full photo archive, including trips from nearly ten years ago (that's around 39000 photos)
• Turn the corrections into tests for better journey reconstruction.
• Improve domestic days out, airport transit, time zones, sparse photo periods, and changing home locations.
• Add GPX imports for cycling, driving, and road trips.
• Use calendar events as optional supporting evidence.
• Support local photo folders.
• Explore self hosted maps and local models through something like llama.cpp for review too

Built With

• codex
• expo.io
• gp5.6
• mapbox
• react-native