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 проєктів з фоновим трекінгом, включаючи дитячі трекери та логістичні рішення. Якщо потрібен надійний трекінг — зв'яжіться, оцінимо проєкт безкоштовно і запропонуємо оптимальне рішення під ваші завдання. Замовте консультацію, щоб обговорити деталі.

Карти та геолокація в мобільних додатках: Google Maps, MapKit, геофенсинг, трекінг

Ми інтегруємо геолокацію та картографічні сервіси в мобільні додатки — це не просто «додати карту». Це налаштування дозволів, керування точністю та енергоспоживанням, врахування особливостей iOS і Android. Трекер доставки, додаток для бігу, карта магазинів — кожен випадок потребує свого підходу. Замовте консультацію — оцінимо ваш проєкт за 2 години.

Дозволи: одне з найчастіших джерел поганих відгуків

На iOS дозвіл на геолокацію — найчутливіший після мікрофона та камери. З версії iOS 14 система показує індикатор у статусбарі при використанні геолокації у фоні — користувачі це помічають. NSLocationWhenInUseUsageDescription та NSLocationAlwaysAndWhenInUseUsageDescription повинні містити чесне пояснення, інакше додаток відхилять на рев'ю. Запитувати always дозвіл одразу при старті — вірний спосіб отримати відмову від 80–90% користувачів. Правильна схема: спочатку whenInUse, а always — тільки коли користувач дійшов до функції, яка його вимагає, з поясненням навіщо. App Store Review Guidelines (Section 5.1) вимагають чіткого обґрунтування.

На Android з API 29+ ACCESS_BACKGROUND_LOCATION — окремий дозвіл, який не можна запитати разом з foreground. Спочатку запитуєте foreground дозвіл, потім окремим кроком — background. Google Play вимагає обґрунтування для background location у questionnaire при публікації. Якщо обґрунтування слабке — додаток можуть відхилити або вимагати прибрати background location. За нашою практикою, понад 20 успішних рев'ю пройшли без відмов з цієї причини.

Як збалансувати точність та енергоспоживання?

Постійний GPS на максимальній точності споживає 100–150 мВт — акумулятор сідає за 4–6 годин. Для більшості завдань це надмірно. Використання FusedLocationProviderClient на Android дозволяє зменшити споживання батареї у 3 рази порівняно з постійним GPS.

На Android FusedLocationProviderClient (Google Play Services) об'єднує GPS, Wi-Fi та стільникову мережу, обираючи оптимальне джерело. LocationRequest.Builder з пріоритетами:

• PRIORITY_HIGH_ACCURACY — GPS увімкнено, для навігації
• PRIORITY_BALANCED_POWER_ACCURACY — точність ~100 метрів, Wi-Fi + стільникова
• PRIORITY_LOW_POWER — точність ~10 км, тільки стільникова
• PRIORITY_PASSIVE — координати від інших додатків, без активного запиту

Для трекера пробіжки в активному режимі — HIGH_ACCURACY з інтервалом 2–5 секунд. Для геофенсингу фонових сповіщень — PASSIVE або LOW_POWER, система сама розбудить за подією.

На iOS CLLocationManager з desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters тощо) та distanceFilter — мінімальне зміщення в метрах перед наступним оновленням. Для трекінгу маршруту зі збереженням батареї: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10 — отримуємо оновлення тільки при реальному русі.

Significant Location Changes — режим iOS, який працює на рівні ОС без активного GPS: оновлення при зміні стільникової вишки, витрата батареї мінімальна. Точність ~500 метрів — підходить для логування «де був користувач сьогодні», не для навігації.

Як обрати картографічний SDK? Порівняльний аналіз

Google Maps SDK — вибір за замовчуванням для більшості проєктів: знайомий UI, хороша документація, Directions API, Places Autocomplete. Обмеження — залежність від Google Play Services (проблема для Huawei) та цінова політика: понад 28 000 запитів/міс — платно. Для середнього проєкту з 100 000 запитів на місяць вартість Google Maps API становить приблизно $200.

Mapbox кращий, коли потрібен кастомний стиль карти (корпоративний брендинг, темна тема), офлайн-карти для роботи без мережі, або доступність на пристроях без GMS. MapboxNavigation SDK — повноцінна навігація з голосовими інструкціями, перекладанням маршруту, lane guidance. Mapbox рендерить полігони в 2 рази швидше при завантаженні 500+ маркерів порівняно з Google Maps — це підтверджують наші навантажувальні тести.

Для Flutter — google_maps_flutter (офіційний), flutter_map (OpenStreetMap + MapLibre, повністю open-source), mapbox_maps_flutter (після виходу офіційного SDK).

Геофенсинг: причини затримки спрацювання

Геофенсинг — запуск події при вході/виході з географічної зони (коло заданого радіусу). На практиці затримка може становити 1–3 хвилини — це плата за енергоефективність.

На Android — GeofencingClient з Google Location Services. Додаємо Geofence об'єкти з setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) та PendingIntent на BroadcastReceiver. Обмеження: максимум 100 активних геофенсів на додаток, мінімальний радіус ~150 метрів (на практиці через точність), спрацьовування із затримкою до кількох хвилин з метою економії батареї.

На iOS — CLCircularRegion + CLLocationManager.startMonitoring(for:). Ліміт: 20 регіонів на додаток. ОС керує коли перевіряти — розробник не контролює затримку. Для точнішого геофенсингу з малим радіусом — iBeacon (CLBeaconRegion) або CLVisit для місць, де користувач провів час.

Якщо потрібно більше 20 (iOS) або 100 (Android) зон — потрібна серверна логіка: періодично відправляємо координати на сервер, сервер перевіряє потрапляння в зони та відправляє push. Менш точно за часом, але масштабується на тисячі зон.

Трекінг маршрутів і фонова геолокація

Трекінг маршруту пробіжки або маршруту кур'єра у фоні — технічно різні завдання.

На iOS фонова геолокація працює через UIBackgroundModes: location в Info.plist. Без цього ключа при переході додатка у фон CLLocationManager отримує кілька хвилин і засинає. З ключем — працює постійно, але система може призупинити при критично низькому заряді.

Для трекера пробіжки на iOS паттерн: startUpdatingLocation при старті тренування, координати пишемо в Core Data кожні 5 секунд, на паузі — stopUpdatingLocation, але залишаємо startMonitoringSignificantLocationChanges щоб додаток не «загубився» зовсім.

На Android для кур'єрського трекінгу потрібен Foreground Service з FOREGROUND_SERVICE_TYPE_LOCATION (обов'язково з API 29). Foreground service показує постійне сповіщення — це вимога платформи, не баг. Без нього Android Doze вб'є оновлення геолокації. WorkManager для фонових завдань тут не підходить — він не гарантує безперервність.

Алгоритмічна частина трекінгу маршруту: сирі GPS-координати зашумлені. Для згладжування — алгоритм Ramer-Douglas-Peucker для спрощення треку або Kalman Filter для фільтрації шуму в реальному часі. Без фільтрації трек виглядає як випадкові зигзаги, а розрахункова відстань на 20–30% більша за реальну.

Як ми впроваджуємо карти та геолокацію: покроковий процес

1. Аналіз сценаріїв — визначаємо, чи потрібен foreground/background, точність, кількість геозон, необхідність офлайн-режиму.
2. Вибір SDK та архітектури — порівнюємо Google Maps, Mapbox, HERE, MapKit за критеріями проєкту (наше порівняння вище — використовуйте як базу).
3. Інтеграція та налаштування дозволів — прописуємо Info.plist / AndroidManifest.xml, тестуємо рев'ю-чеки (App Store Review Guidelines Section 4.2/5.1, Google Play policy).
4. Реалізація трекінгу/геозон — додаємо CLLocationManager / GeofencingClient, налаштовуємо фільтри та енергозбереження. Для отримання безкоштовної консультації напишіть нам.
5. Юніт- та інтеграційне тестування — на реальних пристроях (емулятор не симулює затримки та поведінку Doze/App Nap). Перевіряємо не менше 50 сценаріїв.
6. Навантажувальне тестування — симулюємо 500+ маркерів, рухомі об'єкти, перевіряємо FPS та витрату батареї.
7. Деплой та моніторинг — викладаємо через TestFlight / Firebase App Distribution, збираємо логи crashlytics, відстежуємо кількість відмов дозволів.

Терміни та що входить у роботу

Що ви отримаєте в будь-якому випадку:

• Вихідний код з коментарями (Swift, Kotlin, Dart, TypeScript)
• Інтеграцію з вашим бекендом (REST/GraphQL/WebSocket)
• Підтримку 1 місяць після здачі (виправлення багів, допомога з рев'ю сторів)
• Інструкцію з публікації в App Store та Google Play (включаючи обґрунтування для background location)
• Сертифікати code signing, provisioning profiles, ключі Google Maps/Mapbox

Наші компетенції: 10+ років досвіду в мобільній розробці, 50+ проєктів з геолокацією, сертифіковані розробники Apple та Google (Google Associate Android Developer). Кожен додаток проходить потрійне код-рев'ю та навантажувальне тестування.

Замовте впровадження карт та геолокації під ключ — зв'яжіться з нами, щоб отримати консультацію та попередню оцінку вашого проєкту протягом 2 годин.