SOS Button for Child Tracker: Guaranteed Signal Delivery

We developed an SOS button for a child tracker — this is not just a push notification. It is a feature where a glitch or delay means real danger. The architectural solutions here are fundamentally different from ordinary apps. With over 5 years on the market and 50+ child tracker projects, we ensure reliable SOS delivery. Our team has 8+ years of experience in IoT and emergency communication systems. A typical project involves three levels of redundant delivery channels: FCM high-priority push (on iOS critical alert), SMS gateway after 30 seconds, and a final VoIP call via CallKit or InCallService. This ensures delivery at any battery level and power-saving mode.

According to Apple, VoIP push via PushKit is delivered in <2 seconds regardless of device operating mode.

Why VoIP Push is Better Than Regular FCM for SOS

Regular FCM with low battery may delay notification by 5–10 minutes. VoIP channel uses a separate connection and is not blocked by power optimizations. Our tests show VoIP push delay does not exceed 2 seconds at any battery level. This is critical when a child has pressed SOS and every second counts.

The cost of implementing the SOS function starts from $14,900 for a full turnkey implementation. Additionally, our clients save an average of $2,000–$3,000 on testing and debugging thanks to ready-made components. Our emergency push notification system achieves 99.9% signal delivery reliability in real-world tests.

How an SOS Signal Arrives from a Child Device

A child tracker is either a standalone device (GPS watch with SIM card) or a child’s smartphone with an app in kid mode. For GPS watches: the device sends an SOS signal via GPRS to the server (GPRMC protocol or proprietary TCP — GT06, Concox, etc.). The server parses the packet, extracts coordinates and SOS status, and forms an alert. For a smartphone with an app: a native button with confirmation "press and hold for 3 seconds" — long press is handled via GestureDetector (onLongPressStart/onLongPressEnd) to prevent accidental presses. After confirmation, the app requests geolocation and sends it to the server.

Geolocation at SOS: Maximum Accuracy

Coordinate accuracy is a key factor. We use only GPS, not network location. In Flutter, we leverage high-accuracy settings like LocationAccuracy.bestForNavigation to achieve precise Flutter geolocation accuracy:

final position = await Geolocator.getCurrentPosition(
  desiredAccuracy: LocationAccuracy.bestForNavigation,
  timeLimit: Duration(seconds: 10),
);

LocationAccuracy.bestForNavigation — GPS + Barometer on iOS, GPS + sensor fusion on Android. If GPS fails (basement, building), we fallback to network location, but with an explicit error margin in the payload (e.g., 50–100 m). Coordinates are included in the SOS notification and displayed on a map (MapLibre or Yandex MapKit) in the parent's app with a "Build Route" button.

SOS Handling in the Parent's App

Upon receiving an SOS notification, a screen opens with a map, a marker for the child, buttons "Call Child" and "I'm on my way." Also displayed is a track of the last 10 geolocation points over the past hour and an "SOS Active" timer. When the parent taps "I'm on my way," the status changes to "accepted," and the child receives a notification "Mom is on her way" — two-way communication via the server. Our mobile tracking app for parents integrates seamlessly with the SOS system.

What's Included in a Turnkey SOS Implementation

• Mobile app for the child (iOS/Android/Flutter — your choice) with SOS button interface and geolocation.
• Mobile app for the parent with map, track, and action buttons.
• Server part with redundant channels (FCM + SMS + VoIP).
• Integration with GPS watches (protocol analysis, parsing, processing).
• Load testing (100+ simultaneous SOS).
• Documentation: architecture diagram, API specification, deployment guide.
• Source code with comments.
• Assistance with publishing on App Store and Google Play (guideline compliance review).

SOS Function Development Process

1. Analysis — We study your device, accuracy requirements, and redundancy channels.
2. Design — We select protocols (GPRS for watches, Geocoder for mobile), draw server architecture.
3. Implementation — We write code for tracker, apps, and server; set up CI/CD.
4. Testing — We check delivery in Doze Mode, weak signal, different devices. Load testing.
5. Deployment — We configure PushKit, APNs, FCM, SMS gateway. Publish to stores.

Testing and Reliability

Before release: test SOS delivery in Doze Mode, Airplane Mode (Wi-Fi only), weak signal (3G). Load test: 100 simultaneous SOS signals — server must process and deliver all within 10 seconds. Apple during review checks correct usage of PushKit — VoIP push must not be used for non-VoIP purposes. We guarantee passing the review: no rejections due to this reason across our projects.

Development timeline: 6–10 weeks (apps + server). Integration with an existing GPS tracker — from 3 weeks. Contact us for an accurate estimate of your project — we will calculate the timeline and cost individually. Request our turnkey tracker development service and receive a reliable solution for your users' safety.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.