If You Can't Fix Your Commute, You Might as Well Graph It

3 weeks ago 2

Motivation comes in many forms.

Some things are worth doing for a result, like painting a room so the room will be painted.

Some things are worth doing for the joy of doing them, like going for a hike or chasing your kids on the playground.

Some things are worth doing because the very act of trying creates the illusion of control over something you can’t truly change.

I built myself an over-the-top commute-tracking app for all three reasons: to look for patterns or optimizations, to challenge myself with a fun project, and to satisfy a deep-seated need for control even if it doesn’t really change a thing.

Too Many Variables

After working remotely for almost six years, I recently started a new job that requires commuting to Midtown Manhattan four times a week. My last commute was fairly average by NYC standards: walk to the subway station, ride a single subway train, then walk to the office in about 45 minutes. It’s not so simple anymore. Commuting is a puzzle now that I’ve relocated from Queens to a suburban commuter town in New Jersey, with every choice of timing and route involving tradeoffs and unpredictability.

A map of the various routes between home and work.

I live close to two train stations. Weather permitting, I can walk to one of them or take a repurposed school bus (quaintly called a jitney) to the other. Some trains stop at one station, some stop at the other, and some stop at both. Does it really need to be this complicated? Trips range from 29 to 47 minutes depending on the time of day, number of stops, and required transfers. Of course, this doesn’t account for the time spent trapped in the Meadowlands while Amtrak gets priority over every other train. Once in Manhattan, I can choose between three subway lines. Each has its quirks in walking distance, train frequency, and overall reliability. I’m not choosing one commute so much as eliminating all the others.

After a few weeks of commuting, I thought I knew what worked. But I wasn’t sure I trusted my own judgment. Some commutes felt quick until I checked the time and saw nearly two hours had passed. Maybe it’s because no single leg of the trip is very long, and with so many short segments, my brain rarely had time to feel impatient. I also used my commute time to catch up on movies, so it was easy to get distracted and lose track of time.

What I needed was real data. Not just start and end times, but each step of the trip to understand where my time actually went.

Attempt #1: iOS Shortcuts

To understand every version of my commute, I identified ten key points along the route and decided to track when I entered and exited each one. My first stop: Apple’s Shortcuts app. I’d dabbled with automations in the past without finding much value, but I discovered a geofencing trigger that looked promising. The intended use case is home automation (like turning on the air conditioner when you arrive home), but one of the available actions turned out to be a generic HTTP request. I could spin up a webserver to listen for POST requests and log each event to a database for later exploration.

I began wiring everything together and immediately hit all sorts of walls. One of the biggest frustrations was that the entire automation has to be configured on mobile, rather than being built and shared from a laptop. That means tedious, error-prone setup tasks like defining JSON schemas or selecting variables must be done on the worst possible form factor for work like this. The thought of defining twenty automations this way (ten entry events and ten exit events), plus the need to copy-paste API keys correctly, made me want to quit the whole project.

An animated gif of the iOS Shortcut UI configuring a request body.

Geofencing turned out to be just as frustrating. You can pick an address, but pinching and dragging the map to fine-tune it is awkward and imprecise. Also, the Shortcuts app only supports circular geofences, which makes it hard to define long or narrow locations like a train station. Capturing the full area would mean expanding the radius so much that it triggered well before I arrived.

An enormous geofence in the iOS Shortcuts app.

Finally, logging and troubleshooting were incredibly bare-bones. I set a test automation to trigger when I left my house, but it never seemed to fire reliably. I’ve never felt crazier than pacing the sidewalk in front of my house, waiting for it to trigger. In the end, I couldn’t ever get it to fire unless the app was in the foreground, and online documentation was inconsistent on whether automations that hit external URLs can run in the background at all.

Attempt #2: Radar.com

While taking a break to look into alternatives to circular geofences, I came across an article criticizing iOS location tracking. It spoke to so many of the frustrations I was feeling that I started exploring their alternative instead. Luckily, if you only build apps for a single user, it’s quite easy to stay under most services’ free-tier limits. After creating my new polygonal geofences (on a laptop!), I configured the Radar app to fire a webhook on any entrance or exit event.

The last step was wiring the Radar SDK into an iOS app to send updates. Even though I don’t have much experience with Swift or Xcode, I eventually requested location access on my phone and started communicating with Radar’s servers. After one more trip down the block, I saw my first webhook fire and land in my webserver’s database. Once it was running, I set up the iOS app to print event logs so I could monitor how everything was working in the real world. I was riding high at this point, but it took another two weeks of troubleshooting and obsessively watching my phone during my commute before the app worked the way I wanted.

The main issue I ran into was that Radar didn’t check in often enough. Events fired, but delays frequently skewed my data. In some cases, the events were so far apart that I missed entire nodes on my commute, like the stop at Newark where the train picks up new passengers before continuing on. I pivoted to a timer-based approach, forcing Radar to check my location every 15 seconds. This worked great while the app was open, but I was seeing inconsistent results when it was in the background. Every night when I tweaked my code, the timer in the background worked beautifully. But each morning on my commute, I was bewildered to find the timer paused whenever the app was pushed to the background. After a lot of debugging, I realized that running the app while connected to Xcode (which I did every night to push new versions) actually changes background behavior. Because streaming logs back to Xcode prevents apps from being suspended, the background timer kept counting down.

Convinced the background timer wasn’t viable, I dove deep into the Radar documentation and found a handful of aggressive (and not generally-recommended) settings for maximum-accuracy tracking. With these settings enabled, iOS triggers the Radar SDK to check in for even the tiniest location changes. This approach would never work for a real consumer app because of the heavy battery drain, but it’s an acceptable hit for me right now; I can always charge my phone again when I get to work.

A gif of my app logging events in real time.

How it’s going today

After nearly three months of regular use, I’m very happy with the end result! These days, I fire up the app when I leave and generally trust it will work for the whole commute. That said, there are a few limitations and known issues:

1. Due to the aggressive nature of my tracking, I sometimes see duplicate events that make it look like I’ve arrived, departed, and arrived at the same location in quick succession. I’d rather have too many events than miss something real, so I added a simple admin interface to my webserver and clean up stray events every few days.

2. My commute involves lots of tunnels, so geofence events can be delayed due to shoddy reception. In the map below, you can see the coordinates my phone reported when I entered or exited a given geofence. A stray Penn Station event showing up in Weehawken means my phone couldn’t connect to Radar’s servers until we left the tunnel, which can skew the recorded time between nodes.

3. I’ve noticed that staying connected to my home and work Wi-Fi networks can make it harder for Radar to pinpoint my location accurately. If I forget to disconnect, the app sometimes logs me as being in the office when I’m already a few blocks away. So I take the travel times with a grain of salt and leave a little buffer when using this data to plan trips.

The Data (Last Updated October 14th, 2025)

Below is a snapshot of my commute data collected since July 31st, 2025.