How a location app can run all day without draining your battery
Welcome to the engineering chapter of this series. The foundations posts covered why Fenzly is built the way it is; from here on we open the hood on how. And there’s no better place to start than the objection everyone raises first: “a location app running all day? My battery won’t survive lunch.”
It would be true, if the app worked the way people imagine, with the GPS switched on from morning to night. It doesn’t. The real design goal is almost the opposite: keep the GPS off as much as possible, and be clever about the few moments it’s worth waking.
The GPS is a headlight, not a heartbeat
The GPS receiver is one of the hungriest components in your phone. Left running continuously, it can burn through a large share of your battery in a day. So the naive design, ask the satellite chip “where are we?” every few seconds, forever, is dead on arrival.
But here’s the thing the naive picture misses: most of the time, the answer doesn’t change. You spend hours at home, at your desk, at school. Polling the GPS all evening to learn, again and again, that you’re still in your living room is pure waste. The GPS is like a car’s headlights: essential when you’re going somewhere, pointless while you’re parked.
So the whole problem reduces to one question: how do you know when to switch them on, without using the GPS to find out?
The phone already knows you’re moving, for free
Your phone contains sensors that cost almost nothing to run. The accelerometer and the motion coprocessor, a small dedicated chip, run continuously anyway, whatever apps you use; that’s how your phone counts steps. Both Android and iOS expose what they deduce: still, walking, in a vehicle.
Fenzly is built on top of exactly that. At rest, the app is in a stationary state: GPS off, no position sampling, essentially asleep. What remains awake are the nearly-free layers, the motion chip listening for sustained movement, and a small “you’ve left the area” tripwire the operating system watches around your last known position.
When those layers agree that you’re really going somewhere, the app switches to its moving state: the GPS wakes, records the trip, feeds the sealed envelopes you chose to share. When you arrive and settle, motion goes quiet, and the engine drops back to sleep. Watch your day through this lens and the pattern is stark: for most people the GPS is actually on for a handful of short windows a day, the commutes, the errands, and off for the twenty-plus hours in between.
Moving: measure by metres, not by seconds
Even while the GPS is awake, there’s a second layer of thrift. Fenzly doesn’t sample on a timer; it samples on distance. A new point is recorded when you’ve moved a meaningful number of metres, not every N seconds. Sitting at a red light produces nothing; a steady cruise produces a clean, evenly spaced trail.
The spacing also stretches with speed. At walking pace, points come close together, because street-level detail matters. On the motorway, they spread out: a straight line at 120 km/h doesn’t need a point every twenty metres to be faithful. You get a trail that fits the shape of the journey, at a fraction of the fixes.
And because phones are personal, so is the dial: a setting lets you choose between three recording levels, battery saver, balanced, or detailed, trading trail finesse against consumption. The default sits in the middle and suits almost everyone.
Places don’t need the GPS at all
What about “tell me when he arrives at school”? Surely that needs constant watching?
No, and this is the part that surprises people: geofencing is delegated to the operating system itself. Android and iOS both run a chip-level service that watches registered circles on the map using whatever radio signals are around, cell towers, Wi-Fi, and only occasionally the GPS. Fenzly hands your locally-stored places to that service and goes to sleep. When you cross a boundary, the OS wakes the app for a moment; the app seals the event for your circle and goes quiet again.
That’s also why place detection works offline: it never depended on our server in the first place.
The honest trade-offs
This design buys all-day battery life, and it pays for it in three places you deserve to know about.
The first is reaction time. Because the engine sleeps between trips, it needs you to travel a short distance, on the order of a couple hundred metres, before it’s confident you’ve really left and starts the trail. A recorded trip may therefore begin slightly after your front door, not at it. That’s the price of not running the GPS while you sleep, and we think it’s the right one.
The second is that cheap signals are noisy signals. Indoors, position estimates based on Wi-Fi and cell towers can jump around by tens of metres, enough, in a naive implementation, to make the system believe you briefly “left” home while you were on the sofa. Fenzly layers guards against this: a crossing only counts when the fix is confidently outside the place, with a margin, so wobble gets ignored and real departures still fire. Building those guards, frankly, took field testing and several rounds of humility.
The third is outside our hands: the operating system itself. Everything above assumes the OS lets the app wake when the sensors call. Aggressive battery managers on some Android brands break exactly that assumption, and that story, which every location app quietly struggles with, deserves its own post.
Next in the engineering chapter: when iOS and Android decide your app should sleep forever, Doze mode, background killing, and what it takes to stay reliable on phones that are actively working against you.