The engineering behind a safety app you hope you never need

Most apps are judged on a good day: a full battery, decent signal, a free minute. A safety app is judged on the worst one. The phone is at 4%, there's one bar of signal in a parkade, your hands are shaking too hard to read the screen, and the person who most needs to know doesn't have the app.

Close Circle, our own iOS safety app, is built around that moment. Its happy path is a trip where nothing happens: you set off, you arrive, and the people you trust see both. The harder engineering sits underneath, in what the system does when the phone, the network or the person stops cooperating. Here are four of those moments, and the principle behind them all.

When the phone goes dark

A phone that dies can't tell anyone it died. So in Close Circle, the phone doesn't own the deadline.

When someone sets a check-in, the app sends our servers only an interval. The database stamps the due time with its own clock, and a job checks every minute for anyone overdue. If the battery dies or the app is killed, the server still alerts the people watching that trip, and a wrong clock on the phone can't move the deadline. The timer on the phone only reminds the traveller, every five minutes. The watchers get one push per missed deadline, not a stream of them.

Even snooze respects this. It quiets the phone for five minutes but deliberately doesn't tell the server you answered, so a snoozed prompt that's never answered still escalates.

The server also listens for silence, like a dead man's switch. If a live trip goes 10 minutes without reporting its location, the people watching get a "Lost contact" push within the next few minutes. During an active emergency, the silence window drops to 90 seconds: the people watching are alerted and the emergency contacts are texted again, with the last known location when there is one. Switching the phone off raises the alarm instead of silencing it.

When the phone goes quiet, the server speaks up.

When the signal drops

During a trip, Close Circle doesn't write location points straight to the network. Points go into a queue that's saved to disk and sent in batches. A failed batch goes back to the front of the line so the order holds, and the queue drains when the network returns. The server only ever moves a trip's last-seen time forward, so a late or out-of-order batch can't wind it back.

Alerts are queued too, but on the server. They fan out from the database, not from the sender's phone, so an alert still goes out if the app dies mid-action. Each one lands in a durable outbox with its own row for every contact on every channel, so one bad number can't take the others down with it. A trigger wakes the sender as soon as a row arrives, because a panic alert shouldn't wait for a scheduled job, and a once-a-minute sweep catches anything missed. Temporary failures retry at 30, 60, 120 and 240 seconds.

One delivery decision looks like a step backwards. Panic pushes are sent at Apple's top priority for immediate delivery, but not as critical alerts, the kind that sound through silent mode. Critical alerts need an entitlement Apple grants case by case, and Close Circle doesn't hold one, so the app doesn't depend on it. A louder alert you can't actually send isn't a safety feature.

When your hands are shaking

When someone triggers SOS, the app sends the alarm to our servers straight away, and the server pushes the people watching over them and texts every emergency contact. The 30-second countdown that follows isn't a delay before anyone is told. It's the run-up to the emergency call. When it ends, the app opens the iOS call prompt for a local emergency number. The app looks the number up from where the phone actually is, so a Canadian on a trip in London is offered 999. That lookup needs a location fix and a data connection, so without them the app falls back to its last successful lookup, then the home country the person picked, then the phone's region setting, and finally 112. "Call now" skips the wait. Either way, iOS asks for confirmation and the person places the call.

The countdown breathes gently instead of flashing, because a strobing number is hard to read when you're scared, and the haptics build as time runs down.

The screen won't claim more than it knows. It tracks two separate facts: whether the server accepted the alarm, and what happened to each contact's text. "Text sent" means the SMS provider accepted the message, nothing more. If a text fails while the SOS screen is open, that contact jumps to the top of the status list as a solid button telling the person to call them instead. Carrier error codes never reach the person in trouble.

That honesty runs both ways. If an "I'm safe" tap can't reach the server, the app says so plainly: You're marked safe on this phone, but we couldn't reach the server. Your circle may still be told you went quiet. In a safety app, false reassurance is the bug you can't ship.

When the person who needs to know doesn't have the app

Emergency contacts don't need Close Circle installed. Our servers send them a plain text with the person's name, a static Apple Maps pin of the phone's last known position when the alarm fired, and the phone's battery level when it's reported. If there's no location fix yet, the alert goes anyway without the pin, on a simple rule: an alert with no coordinate beats no alert.

We kept SMS because it reaches a phone on 2G with no app installed. Numbers have to be saved in full international format, and the sender won't guess a country for one that isn't, because an emergency text that reaches the wrong person is its own kind of failure. Each contact is texted on every alarm, stand-down and follow-up, so the app keeps the list to five.

The list is frozen when the alarm fires. If it was a false alarm, a stand-down that reaches our servers sends a "they're OK" follow-up to exactly the people the alarm went to. Editing contacts mid-emergency can't leave someone frightened without the all-clear, or send an all-clear to someone who never heard the alarm.

Design the failure first

None of this shows up in a screenshot, so it's easy to cut when a deadline tightens. If people will rely on your product, list the ways it can fail before you draw anything: what breaks, who needs to know, and what the app is allowed to claim.

Sometimes that means leaving a switch out. None of Close Circle's per-person visibility settings can turn off someone's SOS alerts, because a circle that silently can't help you is the one failure the app exists to prevent.

And sometimes the danger is another person in the room. The app's delete-trip action refuses any trip where the panic button was pressed, because "delete the trip where I pressed the panic button" is exactly what someone standing over them would demand. The lock keys off the time of the press, not the trip's current status, so cancelling the alarm doesn't release it. The record isn't permanent: it still ages out under the app's normal retention rules.

The best outcome for a safety app is that most people never see any of this. But someone, someday, will reach for it with a dying battery and one bar of signal, and that's who it has to be built for.

If you're building something people will lean on at their worst moment, we'd love to talk: appe-latte.ca/contact.