There is a specific kind of feature request that shows up late in almost every connected-product project: "can the app call for help?" Someone on the team has realized that the device already knows where the user is, already has an accelerometer, and already has a phone attached to it. Adding an SOS button looks like a weekend of work. It is not. The moment your product implies that it will summon help, you have changed what you are selling, who regulates you, and what happens in court when it does not work. This article is about building those features honestly — what is genuinely achievable in a consumer app, what is not, and where the line sits.
Three tiers of safety feature, and why the difference matters
Before writing any code, sort the request into one of three buckets. They carry completely different obligations.
- Informational. The app notices something and tells the user. "Your gas sensor reading is high." "You have not moved in four hours." No promise of response. Lowest risk, and often the most useful thing you can ship.
- Notification to a person. The app alerts a caregiver, spouse, or coworker the user chose in advance. You are now a messaging system with an implied reliability requirement, and every failure mode of push notifications from a connected device becomes a safety issue rather than an inconvenience.
- Emergency dispatch. The app tries to reach 911, a monitoring center, or an emergency service. This is a regulated, staffed, contractual business. You almost certainly should not build it yourself.
Most products that need "an emergency feature" actually need tier one or tier two done extremely well. Tier three sounds impressive in marketing copy until someone prices the operations behind it.
The FDA wellness line
The FDA distinguishes between general wellness products and medical devices. A general wellness product makes claims about maintaining or encouraging a healthy lifestyle and does not reference a specific disease or condition. "Track your daily activity" is wellness. "Detects atrial fibrillation" or "alerts you to a dangerous fall" is a claim about a medical condition, and it can pull your product into device territory, with everything that follows — classification, submission, quality system. The test is not what the hardware does; it is what you say it does. Two identical accelerometers ship under completely different regulatory burdens depending on the sentence on the box.
If you are anywhere near this line, run the analysis early rather than after the app store listing is written. Our guide to the FDA definition test walks through the questions, and if the answer comes back yes, software as a medical device explains what the pathway looks like. Marketing teams change wording constantly; put a review gate on any claim language that touches health, injury, or emergencies.
What your app cannot do about 911
Founders are consistently surprised here. A consumer app cannot reliably deliver a caller's location to a public safety answering point the way a mobile carrier does. Enhanced 911 location works through the carrier and the handset operating system, not through your code. Placing a call from your app is possible on both platforms, but you do not control which dispatch center receives it, you cannot transmit device telemetry to that center, and you cannot guarantee the call connects at all in a dead zone.
The realistic options are: hand off to the phone's native emergency dialer and let the operating system do what it is good at; integrate with a commercial emergency response service under contract, which is a real vendor relationship with per-user monthly costs; or stay in tier two and notify people the user nominated. Whichever you choose, the app must state it plainly on screen — not buried in terms of service.
Designing detection that does not cry wolf
Fall detection and crash detection are classification problems with brutally asymmetric costs. A missed event is the failure everyone fears, but a false alarm is the failure that actually kills the feature, because users switch it off after the third time their phone panics at a dropped backpack.
The pattern that works
- Detect a candidate event on the device from accelerometer and gyroscope data — a free-fall signature followed by an impact spike followed by a period of stillness, for example. Choosing the right sensor matters more than the algorithm; see how to choose an IMU for a wearable.
- Ask the user first. A loud, escalating countdown — typically 30 to 60 seconds — with an obvious cancel. Most detected events are not emergencies, and the user cancels.
- Escalate only on silence. No response means notify contacts, with location and a timestamp.
- Log everything so you can tune thresholds against real field data rather than lab drops.
Tune with data from the population you actually serve. Gait, wheelchair use, tremor, and occupation all shift the signal enormously. A threshold that works for office workers generates constant false positives on a construction site.
Permissions, battery, and the offline case
A safety feature that requires the app to be in the foreground is not a safety feature. Both platforms restrict background execution aggressively, and both require explicit user consent for the always-on location and Bluetooth access these features depend on. Expect a meaningful share of users to decline, and design a graceful degraded state rather than a broken one. Our article on what iOS and Android ask users for Bluetooth and location covers the prompts and the wording that gets accepted.
Battery is the other silent killer. Continuous high-rate sampling on the phone drains it in hours; run detection on the device's own microcontroller and wake the phone only on a candidate event.
Then ask what happens with no connectivity. The device should buffer, retry, and tell the user honestly that the alert has not been delivered yet — a silent failure is far worse than a visible one. Offline behavior in a companion app is worth designing deliberately for exactly this reason.
Liability is the part nobody budgets for
If people rely on your product in an emergency and it does not perform, you will be asked to explain why in a setting you will not enjoy. Disclaimers help but do not make the exposure disappear, especially when marketing has promised more than engineering delivered. Practical steps: keep claims narrow and literal, document your verification testing, keep the event logs that show what the system did and when, carry appropriate product liability coverage, and treat safety-path code as a separate risk tier in companion app QA and testing — with regression tests that run on every release, not just the big ones.
Write the honest sentence early: "This product may help someone notice a problem sooner. It is not a substitute for calling emergency services." If that sentence makes the feature sound less exciting, that is useful information about whether the feature should ship at all.
A reasonable scope for version one
For most connected products, a defensible first release looks like this: reliable local detection with conservative thresholds, a clear on-screen countdown with cancel, notification to user-nominated contacts with location and context, a visible delivery status, an obvious link to the phone's own emergency dialer, and no claim anywhere that you dispatch help. Add tier three later, with a contracted monitoring partner and a legal review, if the market genuinely demands it.
Projects House develops connected products where the firmware, the device, and the app are designed together — including the uncomfortable conversations about claims, failure modes, and what a safety feature can honestly promise. If you are weighing one of these features for your product, tell us what you have in mind through the contact form and we will tell you what it really takes.