Child Location Tracking via Mobile App
Background geolocation tracking — looks simple until first production launch. "Background location" works fundamentally different on iOS and Android, and most problems surface not in dev environment, but with real user two weeks after release.
On Android 10+ background geolocation access requires ACCESS_BACKGROUND_LOCATION — separate runtime permission user must grant in system settings, not standard dialog. Google Play since late 2020 requires justification for this permission on review. iOS situation is different: Always authorization only after user first grants WhenInUse, then separately consents to permanent access — system prompt appears at right moment only with properly built request flow.
Where background tracking breaks
Battery vs update frequency
CLLocationManager with desiredAccuracy: kCLLocationAccuracyBest and distanceFilter: kCLDistanceFilterNone — sure way to drain iPhone battery in 4 hours. For child tracker sufficient kCLLocationAccuracyHundredMeters and distanceFilter: 50 (meters). With pedestrian movement this gives update every 30-60 seconds without battery impact.
For Android — FusedLocationProviderClient from Google Play Services with LocationRequest.Builder and PRIORITY_BALANCED_POWER_ACCURACY priority. With SmallestDisplacement 30-50 meters this reduces energy consumption 3-4x vs PRIORITY_HIGH_ACCURACY.
iOS: system kills app
Background App Refresh — first thing iOS disables on low battery or Low Power Mode. CLLocationManager with allowsBackgroundLocationUpdates = true and pausesLocationUpdatesAutomatically = false keeps app alive longer, but not forever. For guaranteed background work need significant location change as fallback: startMonitoringSignificantLocationChanges() wakes on cell tower switch — 300-500 meter accuracy, but works even with suspended app.
On Android killers — Doze mode and manufacturer overlays (MIUI, EMUI, OneUI) with aggressive battery management. Solution: ForegroundService with persistent notification in status bar — how Yandex.Navigator and Google Maps work. Without foreground service in MIUI 14 tracking sleeps 5-7 minutes after screen off.
React Native and Flutter: additional complications
For cross-platform, react-native-background-geolocation (Transistor Software) — most mature, has own headless mode for Android and correctly handles iOS background modes. Alternative in Flutter — background_locator_2, though support unstable: check last commit date before integrating. We more often write native modules for iOS and Android separately and expose events via EventEmitter / EventChannel — more reliable for critical tracking.
Coordinate transmission architecture
Don't send coordinates on every update directly to backend. Proper scheme:
- Accumulate points locally in SQLite / Room (Android) or Core Data (iOS)
- Send in batches every 30-60 seconds or by N points accumulated
- On server keep last_known_location separate from track — for fast "where now" response
WebSocket suits real-time map display for parent, but maintaining permanent connection in iOS background impossible without VoIP push trick (gray area of App Store policy). Practical: child app pushes via APNs / FCM background data-push, parent app receives and updates UI.
Permissions and App Store / Google Play
On iOS need Info.plist keys: NSLocationAlwaysAndWhenInUseUsageDescription, NSLocationWhenInUseUsageDescription. Without clear text (not "for app to work") Apple reviewers reject under guideline 5.1.1. Description must explicitly explain why background tracking needed.
Google Play requires Privacy Policy with explicit geolocation collection mention and Declaration form for ACCESS_BACKGROUND_LOCATION. Child control apps additionally checked for Family Policy compliance — need age gate or explicit statement that app for parents, not kids.
Stack and stages
For native iOS — Swift, CoreLocation, MapKit or Google Maps SDK. For Android — Kotlin, FusedLocationProviderClient, WorkManager for periodic track sync. Server part: store coordinates in PostGIS or TimescaleDB, REST or GraphQL API.
Stages: analyze requirements by platform → design storage and transmission schema → implement native location modules → integrate with backend → test on real devices (especially Xiaomi/Huawei/Samsung) → configure push notifications → review and publish.
Timeline: 3 to 8 weeks depending on platform set and accuracy requirements. Cost calculated individually after requirements analysis.