Delivered remotely for a business based in Paris, France. Names withheld by agreement.
Project Overview
Industry: Consumer personal safety and emergency alerting.
Type of solution: Two fully native mobile applications over a shared REST API, integrating hosted live video, mapping and location services, and in-app subscription billing.
Business context: Personal-safety products are judged on a single question: does it work in the ten seconds when it matters? That constraint invalidates most conventional mobile design. The user cannot be asked to navigate menus, compose a message, choose recipients or make decisions. Everything that can be prepared in advance must be prepared in advance, and everything that happens at the moment of need must happen in as close to one action as possible.
General users: Individuals who want a way to summon attention and preserve a record if they feel unsafe, and the trusted contacts they nominate to be alerted.
General purpose: To make it possible, in a few seconds and under stress, to alert the right people, share location and start capturing evidence that will survive whatever happens to the phone.
The Business Challenge
The user is not calm. Every assumption behind ordinary interface design — that the user is reading, deciding, typing accurately, and looking at the screen — fails in the situation this product exists for.
Time-to-activation is the whole product. A safety app that takes four taps to start is a safety app that does not get used. Reducing the moment of need to as close to a single action as possible is the primary design constraint.
Evidence stored on the phone is not evidence. A recording held locally can be deleted, and a phone can be taken or broken. Anything that only exists on the device can be removed by exactly the person the recording would implicate.
Live video is the hardest thing a phone can do. Streaming is demanding on battery, processor and network — and the circumstances the product is designed for are not ones with strong signal or a full battery.
The message cannot be written in the moment. Composing an explanation while frightened is not realistic. It has to exist beforehand and be editable at leisure.
Two native codebases, safety-critical behaviour. iOS and Android had to behave identically in a context where a difference is not a cosmetic inconsistency.
The product has to fund itself. Subscription billing through two different store systems, each with its own lifecycle, entitlement model and edge cases.
Permissions are requested in advance or not at all. Camera, microphone and location access cannot be negotiated during an emergency, so the permission strategy has to be resolved during onboarding.
Our Approach
Move everything possible out of the emergency. The trusted contacts, the emergency message, the permissions and the account setup are all handled during calm onboarding. What remains at the moment of need is activation, and only activation. This is the organising principle of the entire product.
Make the message a pre-written, editable asset. The alert text is composed ahead of time and can be revised whenever the user wants. It is a stored, owned piece of the user's configuration rather than something produced under pressure.
Get footage off the device immediately. Live streaming was chosen over local-only recording precisely because the device cannot be trusted to survive. Footage leaves as it is captured, so the record exists somewhere the situation cannot reach.
Delegate video transport. Real-time video delivery over unreliable mobile networks is a specialist problem with a mature solution, so streaming runs over a hosted communications platform rather than a bespoke media pipeline. That decision put the team's effort into the safety experience instead of into rebuilding video infrastructure.
Retain the record. Past streams and recordings are kept and remain accessible afterwards, because the value of evidence is realised later — when it is being reviewed, reported or acted upon.
Build both platforms natively. Camera, microphone, location and background behaviour are the areas where platform differences matter most, and this is a product where those behaviours have to be exactly right.
Compose screens from a consistent component set on iOS. Safety-critical screens are assembled from reusable cell types rather than bespoke per-screen layouts, so behaviour stays consistent across the product and changes propagate everywhere.
Isolate store billing. Subscription handling lives behind a dedicated manager, keeping two different store lifecycle models out of the rest of the application.
The Solution
Guided onboarding. A tutorial and setup flow establishes the account, permissions, trusted contacts and emergency message before the product is ever needed — the work that makes activation fast later.
Trusted contact management. Users nominate and maintain the people to be alerted, editing the list at any time.
Pre-written, editable emergency messaging. The alert text is composed in advance and revised whenever the user chooses, with support for custom messages, so nothing has to be written during an incident.
Rapid activation. Help request and live activation flows are built to reach streaming and alerting in minimal actions.
Live video streaming. Video is streamed as it is captured, so the record leaves the device during the incident rather than depending on the phone surviving it.
Video recording and media handling. Capture and container handling on both platforms, with controlled playback of retained material.
Retained session library. Past streams and recordings remain available, so evidence can be reviewed, shared or acted on afterwards.
Location and map context. Location accompanies alerts, with map views providing geographic context for a request — so contacts know not only that something is wrong but where.
Region awareness. The application understands coverage regions, aligning the consumer experience with the response infrastructure available in a given area.
Subscription billing. In-app purchase and subscription management through each platform's own store infrastructure, handled behind a dedicated purchase manager.
Account and settings management. Registration, sign-in, password recovery, account settings and hosted content through an in-app web view.
Key Features
Pre-written editable emergency message The alert text is composed and revised during calm periods, so at the moment of need nothing has to be written — the single most consequential usability decision in a panic-activated product.
Live streaming as evidence preservation Footage leaves the device while the incident is happening, so the record survives the phone being taken, broken or lost.
Minimal-action activation Help request and go-live flows designed to reach streaming and alerting in as few actions as possible, for a user who is not in a position to navigate.
Trusted contact alerting with location Nominated contacts receive the user's pre-written message together with location context, so they know both that something is wrong and where.
Retained stream and recording library Past sessions remain accessible after the event, when evidence is actually reviewed and acted upon.
Map-based incident context Map views provide geographic context for a request, making location immediately intelligible rather than a set of coordinates.
Advance permission handling Camera, microphone and location permissions are resolved during onboarding, because they cannot be negotiated during an emergency.
Native implementation on both platforms Camera, microphone, location and background behaviour implemented natively on iOS and Android, where platform-specific correctness matters most.
Delegated video transport Live video runs over a hosted communications platform, so streaming reliability over poor mobile networks is handled by purpose-built infrastructure.
Subscription billing behind a dedicated manager Store purchase and subscription lifecycles isolated from the rest of the application, keeping two different billing models contained.
Technical Architecture
iOS client. A native Swift application composing screens from a consistent set of reusable cell types — map, label, button, contact, confirmation and stream cells — assembled by dedicated view controllers per flow, with a central application configuration object and a discrete in-app purchase manager. Networking runs through a single HTTP client library; live video is handled by a hosted communications SDK.
Android client. A native Java application using a single-activity, fragment-per-screen structure, with a dedicated REST client package, typed model objects, adapters and utility widgets. Media capture uses a camera recording library with container-level media handling, and playback runs through a bundled player module included in the repository. Subscription handling uses the platform billing library.
Networking layer. Both clients target the same REST API with token-based authorisation, each using its platform's standard HTTP client with typed serialisation.
Media and streaming layer. Live video is delegated to a hosted communications platform; recording uses platform capture with container handling rather than bespoke encoding, and retained material is played back through controlled in-app playback.
Location layer. Platform location and mapping services provide position for alerts and geographic context for requests.
Billing layer. Each platform's own in-app purchase and subscription infrastructure, isolated behind a dedicated manager on iOS and the platform billing client on Android.
Flow: Activation → Live video stream to hosted platform + location and pre-written message to trusted contacts → Session retained → Reviewable afterwards from the in-app library
Technology Stack
| Category | Technology |
|---|---|
| iOS language | Swift |
| iOS networking | Alamofire |
| iOS live video | Hosted video communications SDK |
| iOS UI | Reusable cell-composed screens, slide-menu navigation, keyboard management |
| iOS billing | Platform in-app purchase via a dedicated purchase manager |
| Android language | Java |
| Android networking | Retrofit with Gson and Scalars converters |
| Android media | Camera recording library, MP4 container handling, bundled player module |
| Android UI | AndroidX AppCompat, Material Components, ConstraintLayout, fragment-per-screen |
| Android media loading | Glide with circular image component |
| Android billing | Google Play Billing Library |
| Location & mapping | Google Play Services Location and Maps (Android); platform location services (iOS) |
| API | Shared REST API with token-based authorisation |
Technical Challenges & Solutions
| Challenge | Our Approach |
|---|---|
| A user who is frightened, hurried and possibly not looking at the screen | Everything that can be prepared in advance is prepared in advance — contacts, message, permissions, account — so the only thing remaining at the moment of need is activation itself. |
| Composing an emergency message under stress | The alert text is a pre-written, editable asset maintained during calm periods, with custom message support, so nothing has to be written during an incident. |
| Evidence stored locally being destroyable by the person it implicates | Live streaming rather than local-only recording, so footage leaves the device as it is captured and the record exists somewhere the situation cannot reach. |
| Real-time video over unreliable mobile networks | Streaming delegated to a hosted communications platform rather than a bespoke media pipeline, putting engineering effort into the safety experience instead of rebuilding video infrastructure. |
| Permissions that cannot be requested during an emergency | Camera, microphone and location permissions resolved during onboarding, with the setup flow designed to secure them before the product is ever needed. |
| Evidence being useful only after the event | A retained library of past streams and recordings with controlled in-app playback, so material remains accessible when it is actually reviewed or acted upon. |
| Two native codebases delivering safety-critical behaviour | Both platforms implemented natively, precisely because camera, microphone, location and background behaviour are where platform differences matter most and where correctness cannot be approximated. |
| Two different store subscription models | Billing isolated behind a dedicated purchase manager on iOS and the platform billing client on Android, keeping two different lifecycle models contained rather than distributed through the application. |
| Screen-by-screen inconsistency in a safety product | On iOS, screens composed from a shared set of reusable cell types rather than bespoke layouts, so behaviour stays consistent and changes propagate across the product. |
Security & Reliability
Authenticated API access. All API requests carry token-based authorisation, with registration, sign-in and password recovery handled through the platform.
Off-device evidence. Streaming footage away from the handset during an incident is itself the product's central reliability property — the record does not depend on the device surviving.
Permission model. Camera, microphone and location access are requested through each platform's permission system, resolved during onboarding so access is already granted when needed.
Delegated streaming infrastructure. Live video runs on a purpose-built communications platform with its own reliability and delivery characteristics rather than a bespoke pipeline.
Store-managed entitlement. Subscription status is governed by each platform's own billing infrastructure rather than by client-held state.
Thin clients. The applications are presentation and capture clients over a hosted API rather than local systems of record, limiting what sensitive material accumulates on the handset.
Controlled playback. Retained recordings are played back through in-app playback rather than being exported to general device storage by default.
Scalability & Performance
Delegated streaming capacity. Live video scales with the hosted communications platform rather than with infrastructure the business operates itself.
Container-level media handling. Recording uses capture and container handling rather than unnecessary re-encoding on the device, reducing processing cost and battery drain at the moment it matters most.
Cached image loading. Media and imagery load through caching loaders, keeping repeated browsing of retained sessions responsive.
Lightweight navigation. A single-activity fragment structure on Android and cell-composed screens on iOS keep the applications light, so activation is not delayed by heavy screen construction.
Thin client architecture. With retention and delivery handled server-side, the applications remain small and their behaviour scales with backend capacity rather than device capability.
Business Outcomes
- Activation takes seconds, because everything that could be prepared in advance was moved out of the emergency and into onboarding.
- Users never have to write anything under stress, since the emergency message is pre-composed and editable at leisure.
- Evidence survives the device, because footage streams away from the handset while the incident is happening.
- Trusted contacts know where, not just what, with location and map context accompanying every alert.
- The record is useful afterwards, through a retained library available when material is reviewed or acted upon.
- The product funds itself, with subscription billing integrated through both platform stores.
- Both platforms behave identically in a context where an inconsistency is not cosmetic.
- Streaming reliability is not the business's problem to solve, having been delegated to purpose-built infrastructure.
Why it worked
Most consumer apps are designed for an attentive user with time to spare. A personal-safety app is designed for the opposite, and almost every conventional design instinct has to be inverted. The question is not what the interface can offer — it is what can be removed from the moment of need entirely.
Our team builds from that constraint. We moved contacts, messaging, permissions and configuration into calm onboarding so that activation is a single decision. We chose streaming over local recording because the device is not a safe place to keep evidence about a situation that is currently happening to the device's owner. And we delegated video transport to purpose-built infrastructure, because a product team's effort belongs in the safety experience rather than in rebuilding real-time media delivery over bad networks.
Our teams work natively across Swift and Java as well as cross-platform, with practical experience in the areas this product depends on — camera and microphone capture, background behaviour, location services, permission strategy, hosted real-time video, and store subscription billing on both platforms. In a product where correctness is measured in seconds under stress, those platform details are the product.
Final Summary
A personal-safety application is defined by a scenario in which almost nothing about ordinary app design applies. The user is frightened, may be moving, may be observed, and has seconds. They cannot navigate, cannot compose a message, and cannot make choices. And the device in their hand — the thing holding any evidence being captured — is exactly the thing most likely to be taken or destroyed.
Our team built native iOS and Android applications designed around those constraints. Trusted contacts, the emergency message, permissions and account setup are all completed during calm onboarding, so the moment of need requires activation and nothing else. The message is pre-written and editable whenever the user chooses. When activated, video streams away from the device as it is captured — so the record exists somewhere beyond the reach of the situation — with location and the user's own message reaching their nominated contacts, and map context making that location immediately intelligible.
Past sessions are retained and reviewable afterwards, when evidence is actually used. Live video runs over a hosted communications platform rather than a bespoke pipeline, so streaming reliability over poor mobile networks is handled by infrastructure built for it. Subscription billing is integrated through both platform stores behind an isolated purchase layer. Both applications are fully native, because camera, microphone, location and background behaviour are where platform differences are largest — and this is a product where those details are not implementation choices but the difference between working and not.