A location app that keeps working when your network doesn't
In the previous post we explained the blind server: your data is sealed and computed on your own device, not in our database. That choice has a useful side effect that has nothing to do with privacy, it just falls out of the design. Fenzly keeps working when your network doesn’t.
Most location apps are the opposite. They’re really just a window onto the company’s servers: lose the signal and the map goes grey, your places disappear, the screen spins. The app is only as alive as your connection.
The tunnel test
Picture the metro, a mountain trail, a parking garage, a flight, a dead zone in the countryside. Your phone has no signal. With a typical app, that’s the end of the session.
With Fenzly, almost everything keeps responding, because almost everything already lives on your phone. The data isn’t somewhere far away that you have to fetch, it’s right there, in a small database that belongs only to you.
What still works with no signal
Quite a lot. You can open the app and read your past messages and location history. You can browse your saved places and pan around the map (tiles you’ve already loaded are cached). You can start recording a trip and watch your speed, distance and heading update live, because that’s just your phone’s GPS talking to your phone.
And here’s the one that surprises people: geofencing still works offline. When you walk into or out of a place, home, the office, school, the detection happens entirely on the device. Your phone notices the crossing with no help from any server. The event is recorded immediately; it simply waits to be shared.
Deferred, not lost
So what happens to the things that do need to reach another person, a message, a trail of your route? They’re not thrown away. They go into an outbox: a queue on your phone that holds them safely until the connection comes back, then sends them in order, automatically.
You barely notice. A message you send offline appears in the conversation right away with a small clock icon, meaning “waiting to go out.” The moment you’re back online, the queue drains and the clock turns into a sent mark. The same goes for the breadcrumb points of a route you’re sharing as a trail, each one is kept and delivered when the network returns.
What genuinely can’t work offline
Honesty, as always. One thing truly can’t happen without a connection: showing your live position to someone far away, in real time. That’s not a design limitation we could engineer around, it’s physics. A friend across town can’t receive your location through a network that isn’t there.
There’s a deliberate detail here. When you share your live position and the network drops, Fenzly doesn’t queue those updates. A location from thirty seconds ago has no value, by the time it could be sent, a fresher one already exists. So live updates are dropped rather than piled up, while a route you’re recording as history keeps every point, because there a gap in the trail would actually be missing.
Why it works this way
It comes back to the same decision behind the blind server. Because your data has to live on your device anyway, so that we can’t read it, the app is built to run from the device first and treat the network as a bonus, not a lifeline. The architecture that protects your privacy is the same one that frees you from the signal bars.
A location app you can’t use in a tunnel isn’t much of a safety tool. We’d rather build one that’s still there when you need it most.
Next we’ll tackle a question we get a lot: just how hard is the Signal encryption to break? The honest answer involves some very large numbers.