Розробка мобільного додатка для батьківського контролю
Батьківський контроль — це не просто «заблокувати TikTok». За цією формулюванням скриваються три технічно несумісні завдання: перехват трафіку, обмеження системних функцій та моніторинг активності—все це на платформах, які цілеспрямовано утруднюють такі речі. Apple та Google регулярно закривають API, якими користувалися попередні версії таких додатків. Проектування системи потребує розуміння, що протягом року половина механізмів може змінитися.
iOS: Screen Time API як єдиний легальний шлях
До iOS 16 розробники використовували 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— фонові розширення, які отримують eventiintervalDidStart/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-проксі, але це більш складно і потребує установки кореневого сертифіката.
Моніторинг геолокації
CLLocationManager на iOS та FusedLocationProviderClient на Android—стандарт для фонової геолокації. Але у фоновій геолокації є нюанси: iOS з iOS 13 показує користувачу сповіщення «Додаток X використовує вашу геолокацію»—дитина його бачить. На Android з версії 10 потрібно ACCESS_BACKGROUND_LOCATION + пояснення у Google Play Console.
Для економії батареї використовуємо геозони (CLCircularRegion / GeofencingClient) замість безперервного трекінгу. Подія входу/виходу з зони генерує push-сповіщення батькам. Безперервний трекінг—лише за явним запитом.
Синхронізація та батьківська панель
Дані з дитячого пристрою → зашифрований канал → бекенд → батьківський додаток. Шифрування E2E не обов'язково для цієї задачі—TLS із mutual auth достатньо. Але зберігання статистики активності додатків, історії браузера та геолокації—це чутливі дані, які потребують відповідності GDPR/COPPA (якщо користувачі молодше 13 років).
COPPA у контексті мобільного додатка означає: згода батьків перед збиранням будь-яких даних про дитину, мінімізацію зібраних даних, можливість видалення за запитом. Apple та Google вимагають явного зазначення у App Store Connect / Play Console про збирання даних неповнолітніх.
Етапи проекту
Вибір платформи та API-стратегії → проектування архітектури (клієнт-дитина, клієнт-батько, бекенд) → розробка обмежувальних механізмів → моніторинг активності → геолокація → панель батька → тестування на пристроях різних версій OS → ревью App Store / Google Play → підтримка.
Терміни: MVP з базовими обмеженнями додатків та моніторингом—від 8 тижнів на одну платформу. Повноцінний продукт з двома платформами, геолокацією, DNS-фільтрацією та панеллю—4–6 місяців. Вартість розраховується індивідуально.