GPS-трекінг дитини: реалізація мобільного застосунку

GPS-трекінг дитини — завдання, яке виглядає простим лише до першого продакшн-запуску. «Фонова геолокація» працює принципово по-різному на iOS та Android, і більшість проблем проявляються не в дев-оточенні, а в реального користувача через два тижні після релізу. Особливо гостро це відчувається в застосунках батьківського контролю, де потрібна історія маршрутів і точне місцезнаходження в реальному часі. Ми вирішуємо це завдання комплексно: від вибору оптимального API до публікації в сторах. Наш підхід — нативна реалізація модулів під кожну платформу, що дає стабільність і довгу роботу від батареї.

На Android 10+ фоновий доступ до геолокації вимагає ACCESS_BACKGROUND_LOCATION — окремого runtime-дозволу, який користувач має надати через системні налаштування, а не через стандартний діалог. Google Play вимагає обґрунтування для цього дозволу при рев'ю. На iOS ситуація інша: Always authorization можна отримати лише після того, як користувач спочатку надав WhenInUse, потім окремо погодився на постійний доступ — системний промпт з'являється в потрібний момент лише при правильно вибудуваному флоу запиту.

Чому фоновий трекінг часто дає збої?

Батарея проти частоти оновлень

CLLocationManager з desiredAccuracy: kCLLocationAccuracyBest і distanceFilter: kCLDistanceFilterNone — вірний спосіб розрядити iPhone дитини за 4 години. Для дитячого трекера достатньо kCLLocationAccuracyHundredMeters і distanceFilter: 50 метрів. При русі пішки це дає оновлення кожні 30-60 секунд майже без впливу на батарею.

Для Android — FusedLocationProviderClient з Google Play Services з LocationRequest.Builder і пріоритетом PRIORITY_BALANCED_POWER_ACCURACY. У поєднанні з SmallestDisplacement в 30-50 метрів це знижує енергоспоживання в 3-4 рази порівняно з PRIORITY_HIGH_ACCURACY.

Як балансувати між батареєю та частотою оновлень?

iOS: застосунок вбиває система

Background App Refresh — перше, що iOS вимикає при низькому заряді або в режимі Low Power Mode. CLLocationManager з allowsBackgroundLocationUpdates = true та pausesLocationUpdatesAutomatically = false тримає застосунок живим довше, але не вічно. Для гарантованої роботи в фоні потрібен significant location change як fallback: startMonitoringSignificantLocationChanges() прокидається при зміні вишки стільникового зв'язку — це 300-500 метрів точність, але працює навіть при suspended-стані застосунку.

На Android вбивця процесів — Doze mode та виробничі оболонки (MIUI, EMUI, OneUI) з агресивним battery management. Рішення: ForegroundService з постійним повідомленням в статусбарі — саме так працюють Яндекс.Навігатор і Google Maps. Без foreground service в MIUI 14 трекінг засинає через 5-7 хвилин після вимкнення екрана.

Крос-платформна розробка: який підхід надійніший?

Якщо застосунок крос-платформний, react-native-background-geolocation (Transistor Software) — найзріліша бібліотека, має власний headless mode для Android і коректно обробляє iOS background modes. Альтернатива в Flutter — background_locator_2, хоча її підтримка нестабільна: перевіряй дату останнього коміту перед інтеграцією. Ми частіше пишемо нативні модулі під iOS та Android окремо і прокидуюємо події через EventEmitter / EventChannel — це надійніше для критичного трекінгу.

Як ми реалізуємо трекінг — покроково

1. Аналіз вимог (точність, частота оновлень, платформи)
2. Проектування схеми збору та передачі (локальна буферизація, батчинг)
3. Розробка native location module під iOS (Swift + CoreLocation)
4. Розробка native location module під Android (Kotlin + FusedLocationProvider)
5. Інтеграція з backend (REST/WebSocket)
6. Тестування на реальних пристроях (Xiaomi, Huawei, Samsung, iPhone)
7. Підготовка до рев'ю (Privacy Policy, дозволи, App Store connect)
8. Публікація та моніторинг

Як правильно організувати передачу координат?

Координати не варто відправляти кожне оновлення безпосередньо на backend. Правильна схема:

1. Нагромаджувати точки локально в SQLite / Room (Android) або Core Data (iOS)
2. Відправляти батчами кожні 30-60 секунд або по накопиченню N точок
3. На сервері зберігати last_known_location окремо від треку — для швидкої відповіді на запит «де зараз»

WebSocket підходить для real-time відображення на карті батька, але тримати постійне з'єднання в фоні на iOS неможливо без VoIP push trick (сіра зона App Store політики). Практичніше: застосунок дитини пушить через APNs / FCM фонові data-push, застосунок батька отримує їх і оновлює UI.

Які дозволи потрібні і як пройти рев'ю?

На iOS потрібні ключі в Info.plist: NSLocationAlwaysAndWhenInUseUsageDescription, NSLocationWhenInUseUsageDescription. Без зрозумілого тексту (не «для роботи застосунку») рев'юери Apple відхиляють за guideline 5.1.1. Опис має явно пояснювати, навіщо саме потрібне відстеження в фоні. Згідно з App Store Review Guidelines Section 5.1.1, застосунок має явно пояснювати мету збору даних.

Google Play вимагає Privacy Policy з явною згадкою збору геолокації та форми Declaration для ACCESS_BACKGROUND_LOCATION. Застосунки для контролю дітей додатково перевіряються на відповідність Family Policy — потрібна age gate або явне зазначення, що застосунок для батьків, а не дітей.

Що входить в роботу

• Вихідний код модулів трекінгу (iOS/Android) з коментарями
• API для передачі координат з документацією
• Інтеграція з вашим backend
• Інструкція зі збірки та деплою
• Консультація з проходження рев'ю сторів
• Підтримка 2 тижні після релізу
• Опціонально: налаштування push-повідомлень та real-time карти

Терміни та вартість

Термін: від 3 до 8 тижнів залежно від набору платформ і вимог до точності. Вартість розраховується індивідуально після аналізу вимог.

Ми — команда мобільних розробників з 8-річним досвідом. За цей час ми реалізували понад 15 проєктів з фоновим трекінгом, включаючи дитячі трекери та логістичні рішення. Якщо потрібен надійний трекінг — зв'яжіться, оцінимо проєкт безкоштовно і запропонуємо оптимальне рішення під ваші завдання. Замовте консультацію, щоб обговорити деталі.