Розробка мобільного додатку для батьківського контролю під ключ

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

Моніторинг геолокації: як знизити витрату батареї?

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 для батьківського контролю

Android кращий за iOS у 2–3 рази за глибиною контролю, але вимагає більше зусиль на онбординг та дотримання правил Play Store.

Що входить в роботу

• Аналітика: вибір API-стратегії з урахуванням майбутніх змін
• Проектування архітектури клієнт-дитина, клієнт-батько, бекенд
• Реалізація обмежувальних механізмів (екранний час, фільтрація, блокування)
• Моніторинг активності та геолокація з push-повідомленнями
• Дашборд для батька (статистика, історія, налаштування)
• Інтеграція з бекендом (TLS, REST/GraphQL)
• Тестування на пристроях останніх версій ОС
• Проходження рев'ю App Store та Google Play
• Документація, доступи, код, навчання команди замовника
• Підтримка після релізу (налаштування push, оновлення при зміні API)

Етапи проекту

1. Аналітика та вибір платформи
2. Проектування архітектури
3. Розробка обмежувальних механізмів
4. Моніторинг активності та геолокація
5. Дашборд батька та бекенд
6. Тестування та баг-фікс
7. Рев'ю в сторах та публікація
8. Підтримка

Терміни та вартість

MVP з базовими обмеженнями додатків та моніторингом для однієї платформи — від 8 тижнів. Повноцінний продукт з двома платформами, геолокацією, DNS-фільтрацією та дашбордом — 4–6 місяців. Вартість розраховується індивідуально залежно від складності та вимог. Зв'яжіться з нами для оцінки вашого проекту — ми проаналізуємо задачу і запропонуємо оптимальне рішення. Замовте розробку додатку батьківського контролю під ключ. Отримайте консультацію — ми розповімо, як реалізувати моніторинг без ризику блокування в сторах.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.