Ми розробляємо додатки батьківського контролю, які вирішують три технічно несумісні задачі: перехоплення трафіку, обмеження системних функцій та моніторинг активності — на платформах, що цілеспрямовано ускладнюють подібні рішення. Apple та Google регулярно закривають API, якими жили попередні версії таких додатків. Проєктувати систему треба з запасом на майбутні зміни. Наш досвід — понад 7 років у мобільній розробці, 50+ успішних проєктів для iOS та Android. Гарантуємо якість та проходження рев'ю в сторах.
iOS: як обійти обмеження App Store?
До появи Family Controls розробники використовували VPN-профілі для перехоплення DNS та MDM-конфігурації для обмежень. Все це досі працює, але в App Store такі додатки не пройдуть рев'ю — Apple 4.2 (minimum functionality) або пряма відмова за використання приватних API.
Єдиний легальний та стабільний шлях на iOS сьогодні — Family Controls з ManagedSettings та FamilyActivityPicker (iOS 16+, Swift). Батько авторизує дитину через AuthorizationCenter.shared.requestAuthorization(for: .individual), і додаток отримує доступ до:
-
ManagedSettingsStore— блокування конкретних додатків, обмеження веб-сайтів через WebContentFilter, вимкнення App Store, обмеження екранного часу. -
DeviceActivityMonitor— фонові розширення, які отримують подіїintervalDidStart/EndтаeventDidReachThresholdбез постійно працюючого основного додатку. -
ShieldConfiguration— кастомний екран-заглушка при спробі відкрити заблокований додаток.
Обмеження Family Controls: працює лише для «дочірнього» Apple ID в сімейному доступі. Якщо дитина під окремим дорослим Apple ID — API недоступний. Це організаційна проблема, не технічна, але про неї потрібно попереджати замовника на старті.
Типова грабля при розробці: DeviceActivityMonitor — це App Extension, він запускається в окремому процесі з обмеженими ресурсами. Спроба звернутися до CoreData в основному контейнері з розширення призводить до крэшу з NSPersistentStoreCoordinator: Multiple NSEntityDescriptions. Рішення — App Group зі спільним SQLite-файлом через NSPersistentContainer з явним appGroupContainerIdentifier.
Чому Android складніший, але гнучкіший?
Android дає більше інструментів, але їх поєднання потребує точності. Робочий стек:
-
UsageStatsManager— статистика використання додатків з точністю до пакета. ВимагаєPACKAGE_USAGE_STATS— користувач повинен явно надати дозвіл в налаштуваннях (не можна запросити черезrequestPermissions). Класичний кейс: додаток запитує дозвіл, користувач натискає «Назад», статистика не працює. Потрібен onboarding з прямим Intent вSettings.ACTION_USAGE_ACCESS_SETTINGS. -
DevicePolicyManager+ Device Owner / Profile Owner. Device Owner дає повний контроль: блокування додатків, камери, мережевих налаштувань. Встановлення Device Owner вимагає ADB-команди при первинному налаштуванні (adb shell dpm set-device-owner), що непрактично для масового продукту. Profile Owner працює в рамках Work Profile — трохи менш потужний, але простіший у розгортанні. -
AccessibilityService— історично популярний спосіб моніторингу активного додатку (TYPE_WINDOW_STATE_CHANGED). Google послідовно посилює правила Play Store: додатки зAccessibilityServiceбез очевидної accessibility-причини викидаються. Використовувати лише якщо немає альтернативи і є переконливе обґрунтування для рев'ю. - VPN API (
VpnService) — локальний VPN для DNS-фільтрації. Трафік не покидає пристрій, все фільтрується на loopback через DNS-резолвер. Працює без root. Застосовуємо в зв'язці з заблокованими базами доменів (StevenBlack, Pi-hole lists). Проблема: деякі додатки використовують DoH (DNS-over-HTTPS) і обходять DNS-фільтр. Рішення — deep packet inspection по SNI через TLS-проксі, але це вже складніше і вимагає встановлення кореневого сертифікату.
| API | Призначення | Складність | Легальність у сторах |
|---|---|---|---|
| UsageStatsManager | Статистика додатків | Низька | Висока |
| DevicePolicyManager | Блокування пристроїв | Середня | Середня |
| AccessibilityService | Моніторинг активного вікна | Середня | Низька |
| VpnService | DNS-фільтрація | Висока | Висока |
Моніторинг геолокації: як знизити витрату батареї?
CLLocationManager на iOS та FusedLocationProviderClient на Android — стандарт для фонової геолокації. Але у фонової геолокації є нюанси: iOS показує користувачу сповіщення «Додаток X використовує вашу геолокацію» — дитина це бачить. На Android з версії 10 потрібен ACCESS_BACKGROUND_LOCATION + пояснення в Google Play Console.
Для економії батареї використовуємо геозони (CLCircularRegion / GeofencingClient) замість безперервного трекінгу. Подія входу/виходу з зони генерує push-повідомлення батьку. Безперервний трекінг — тільки за явним запитом. В середньому витрата батареї знижується на 40–60% порівняно з безперервним моніторингом.
Синхронізація та батьківський дашборд
Дані з дитячого пристрою → зашифрований канал → бекенд → батьківський додаток. Шифрування E2E не обов'язкове для цієї задачі — TLS з mutual auth достатньо. Але зберігати статистику активності додатків, історію браузера та геолокацію — це чутливі дані, які вимагають відповідності GDPR та COPPA (якщо користувачі молодші 13 років).
COPPA в контексті мобільного додатку означає: згода батька перед збором будь-яких даних про дитину, мінімізацію зібраних даних, можливість видалення на запит. Apple та Google вимагають явної вказівки в App Store Connect / Play Console про збір даних неповнолітніх.
Порівняння платформ: iOS vs Android для батьківського контролю
| Характеристика | iOS (Family Controls) | Android (UsageStats + VPN + DPC) |
|---|---|---|
| Легальність у сторах | ✅ Повністю | ⚠️ Частково (Accessibility під загрозою) |
| Глибина блокування | Середня (тільки додатки) | Висока (всі системні функції) |
| Фонова робота батареї | ~5–10% на добу | ~10–15% (VPN) + геозони |
| Складність реалізації | Низька (готові API) | Висока (комбінація різних API) |
| Вимоги до пристрою | Apple ID сімейний | Android 10+ |
Android кращий за iOS у 2–3 рази за глибиною контролю, але вимагає більше зусиль на онбординг та дотримання правил Play Store.
Що входить в роботу
- Аналітика: вибір API-стратегії з урахуванням майбутніх змін
- Проектування архітектури клієнт-дитина, клієнт-батько, бекенд
- Реалізація обмежувальних механізмів (екранний час, фільтрація, блокування)
- Моніторинг активності та геолокація з push-повідомленнями
- Дашборд для батька (статистика, історія, налаштування)
- Інтеграція з бекендом (TLS, REST/GraphQL)
- Тестування на пристроях останніх версій ОС
- Проходження рев'ю App Store та Google Play
- Документація, доступи, код, навчання команди замовника
- Підтримка після релізу (налаштування push, оновлення при зміні API)
Етапи проекту
- Аналітика та вибір платформи
- Проектування архітектури
- Розробка обмежувальних механізмів
- Моніторинг активності та геолокація
- Дашборд батька та бекенд
- Тестування та баг-фікс
- Рев'ю в сторах та публікація
- Підтримка
Терміни та вартість
MVP з базовими обмеженнями додатків та моніторингом для однієї платформи — від 8 тижнів. Повноцінний продукт з двома платформами, геолокацією, DNS-фільтрацією та дашбордом — 4–6 місяців. Вартість розраховується індивідуально залежно від складності та вимог. Зв'яжіться з нами для оцінки вашого проекту — ми проаналізуємо задачу і запропонуємо оптимальне рішення. Замовте розробку додатку батьківського контролю під ключ. Отримайте консультацію — ми розповімо, як реалізувати моніторинг без ризику блокування в сторах.