Updated 13 August 2026

What Garly does, and what it does not

A safety app is asked to watch you. That is not a side effect of the business model — it is the function. This page states plainly what Garly watches, what it keeps, what it sends elsewhere, and which things people assume it does but it does not. The reasoning is underneath, for anyone who wants it.

The short version. Motion is read on your phone and, in ordinary use, never leaves it. Locations are shared only when you start something that shares them, and only ever the latest one — never a route history. There is no continuous audio recording, on either platform. Deleting your account deletes your rows.

Point by point

What is not solved. Garly collects ten categories of data, including precise location and trusted-contact details, and the store label says so. Conversations are processed by a third-party model provider. Product analytics are recorded against the account. None of that is invisible or inevitable — it is a set of choices, and a different product could make some of them differently.

The watcher's paradox

On personal safety, privacy, and the one category of software where the two are genuinely opposed.

Most privacy debates in software are about greed. An app asks for your contacts because contacts are worth money; it tracks your location because location is worth money. The fix is well understood even when it is not applied: stop collecting what you do not need.

Personal safety apps are the exception, and they are interesting precisely because the usual fix does not work. A safety app needs the data. Not for advertising, not for a growth model — for the function itself. It cannot notice that you have fallen without watching how you move. It cannot tell anyone where you are without knowing where you are. It cannot recognise that something is wrong tonight without some idea of what your ordinary night looks like.

The only way to be protected by software is to be observed by it. Everything interesting about this category happens in how that tension is handled, and most of the failures come from pretending it does not exist.

I. Five problems, none of them solved by “collect less”

1. Protection requires a baseline

A fall detector that fires on any sharp movement is useless, because a phone being set down on a table produces the same spike as a phone hitting the pavement. The difference between the two is context: what came before, what came after, whether the person moved again, whether this pattern is normal for them.

Every meaningful safety signal is a deviation from a baseline, and a baseline is a record of your ordinary life. There is no version of this feature that works while knowing nothing about you. An app that promises “we know nothing about you and we will detect your fall” is promising one of the two things it cannot deliver alongside the other.

2. The permission cliff

Mobile platforms are built on the assumption that an app not on screen should not be running. This is a good assumption, and it is exactly wrong for this category — a safety app is most needed when the screen is off and the phone is in a pocket.

The platforms offer narrow exceptions, and the shape of those exceptions dictates the shape of the app. On iOS, the only sanctioned way to keep motion sensors sampling in the background is to hold a background location session. The consequence is worth stating plainly: an iOS safety app must ask for “Always” location, not because it wants your movements, but because that permission is the ticket to staying awake. The user sees the scariest possible prompt for a reason that has nothing to do with what the app does with location.

3. The honesty gap

This is the failure least discussed and most serious.

A safety app has a switch, and the switch says “Protected”. Behind that switch is a chain of things that can quietly stop: the operating system suspends the process, a sensor session dies, a permission is downgraded, a battery optimiser kills a background service. When any of those happen, the screen usually keeps saying “Protected”.

The person then walks home believing they have a safety net that no longer exists. A protection app that lies about its own state is more dangerous than no protection app, because it has replaced a person's own caution with a false-confidence signal. Somebody who knows they are unprotected takes the lit street. Somebody who wrongly believes they are protected takes the short cut.

4. The data that outlives the moment

An emergency justifies a great deal. It justifies knowing where you are, opening a microphone, telling a stranger your location. What it does not justify is keeping any of that afterwards.

Yet the natural engineering choice at every step is to retain. Route histories are easier than latest-position-only. Permanent share links are easier than expiring ones. Storing the audio is easier than deleting it. Nothing forces the retention; it accumulates because deletion is work that nobody asks for. The result, across the category, is that a product designed for ten frightening minutes ends up holding a continuous record of an ordinary life.

5. The third-party chain

The privacy label describes what the developer collects. It says much less about who else touches the data on the way: a geocoder converting your home address into coordinates, a messaging platform delivering the alert, a telephony gateway carrying the fallback, a language model processing the conversation. Each of those is a company, in a jurisdiction, with a retention policy of its own. An honest account of a safety app's privacy is not “we do not sell your data”. It is a list of every party that sees any of it, and why.

II. What a good answer looks like

On-device by default. The distinction that matters is not “collected or not” but “left the phone or not”. Sensor data processed on the device and never transmitted is a different category of risk from the same data on a server. It is the largest lever available, and it is underused because on-device processing is harder to build and impossible to monetise.

Latest state, not history. Almost every safety feature needs to answer “where is this person now”, and almost none need “where has this person been”. Those are the same feature to a lazy implementation and completely different products to the person being watched.

Expiry by design. Anything created during an emergency should have a death date written into it at birth: the share link, the recording, the elevated permission. Retention should require an action; deletion should be the default.

Honest state. The interface must distinguish “armed” from “working”. A safety app that cannot display the sentence “this is not currently protecting you” has no way to be truthful on the day it matters.

Deletion that means deletion. Account deletion is a compliance checkbox in most products and a single timestamp in most databases. For this category it should mean the rows are gone — all of them, everywhere, in one transaction that either completes or does not.

III. Where Garly stands, including where it does not

Described honestly rather than favourably, because a safety product that oversells itself has already committed the sin in section 3.

On the baseline problem. Garly does build a picture of you: your routine, the places you go, the people you trust. It is used for detection and personalisation, and it is stored on the server because it has to survive a lost phone. What it does not do is infer.

On the permission cliff. Garly asks for Always location on iPhone for exactly the reason described above, and rather than dress this up, the app says so — and the same explanation goes to Apple's reviewers.

On the honesty gap. This is the one to point at. The protection screen distinguishes armed from working: when the sensors stop delivering samples, the line changes from “Protection active” to “Active, but the sensors have stopped”. That sentence exists because the failure was found on a real phone, where the app had been claiming protection it was not providing. A watchdog re-checks every two seconds, and the sensor session is restarted rather than trusted.

On data outliving the moment. The live journey link shares only the latest position, never a route history, and expires by itself — including automatically when the person reaches home.

On event recording. There is none, and the policy says so: no recording has ever been produced or saved. The app briefly said otherwise — a line claimed a short recording was kept after a confirmed event, which the code never did. It was written by mistake and corrected. There is a recorder in the codebase, but it belongs to an internal microphone test that starts only when a person opens it and accepts a notice, and its clips are encrypted with a hardware key, never uploaded, and deleted within 24 hours.

On the third-party chain. Garly's alerts travel over a messaging platform, its SMS fallback over a telephony provider, its address lookups through an open mapping service, and its conversations through a model provider. That is four companies that see some fragment. There is probably no version of this product with none; the obligation is to name them.

On deletion. Deleting a Garly account removes the person's rows from every table that holds them, in a single transaction, from inside the app.

IV. The honest conclusion

There is no privacy-preserving way to be caught when you fall. Someone or something has to be watching, and the watching has to be continuous, because danger does not schedule itself.

What can be chosen is everything else: whether the watching stays on the device, whether it remembers or merely knows, whether what it creates expires, whether the product tells the truth about its own state, and whether the person can end it completely.

An emergency justifies a great deal for a few minutes, and almost nothing afterwards. Design for the few minutes. Make everything else evaporate.

That is a harder product to build. It is also the only version of this product that deserves to be trusted with the thing it is asking for.

The claims on this page are meant to be checkable. The Android and iPhone clients are published at github.com/GarlyTeam/garly, and the automated checks that run before every release are listed on what we check.