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.
| Платформа | API | Рекомендуемая точность | Фильтр дистанции | Энергопотребление (в час) |
|---|---|---|---|---|
| iOS | CLLocationManager | kCLLocationAccuracyHundredMeters | 50 м | ~10-15% заряда |
| Android | FusedLocationProvider | PRIORITY_BALANCED_POWER_ACCURACY | 30 м | ~8-12% заряда |
Как балансировать между батареей и частотой обновлений?
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 — это надёжнее для критичного трекинга.
| Библиотека | Платформы | Стабильность | Поддержка фона |
|---|---|---|---|
| react-native-background-geolocation | iOS, Android | Высокая | Полная (headless) |
| background_locator_2 | iOS, Android | Средняя | Ограниченная |
| Нативные модули (кастом) | iOS, Android | Максимальная | Полная |
Как мы реализуем трекинг — пошагово
- Анализ требований (точность, частота обновлений, платформы)
- Проектирование схемы сбора и передачи (локальная буферизация, батчинг)
- Разработка native location module под iOS (Swift + CoreLocation)
- Разработка native location module под Android (Kotlin + FusedLocationProvider)
- Интеграция с backend (REST/WebSocket)
- Тестирование на реальных устройствах (Xiaomi, Huawei, Samsung, iPhone)
- Подготовка к ревью (Privacy Policy, разрешения, App Store connect)
- Публикация и мониторинг
Типичные ошибки при реализации
- Неправильный порядок запроса разрешений на iOS - Отсутствие ForegroundService на Android - Слишком частая отправка координат на backend (без буферизации) - Игнорирование battery management на MIUI/EMUI - Недостаточное описание цели в Privacy PolicyКак правильно организовать передачу координат?
Координаты не стоит отправлять каждое обновление напрямую на backend. Правильная схема:
- Накапливать точки локально в SQLite / Room (Android) или Core Data (iOS)
- Отправлять батчами каждые 30-60 секунд или по накоплению N точек
- На сервере хранить 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 недель в зависимости от набора платформ и требований к точности. Стоимость интеграции с серверной частью — от $500 до $1,500, основной проект — от $1,500 до $5,000. Стоимость рассчитывается индивидуально после анализа требований.
Мы — команда мобильных разработчиков с 8-летним опытом. За это время мы реализовали более 15 проектов с фоновым трекингом, включая детские трекеры и логистические решения. Если нужен надёжный трекинг — свяжитесь, оценим проект бесплатно и предложим оптимальное решение под ваши задачи. Закажите консультацию, чтобы обсудить детали.