Права доступу та приватність у мобільній розробці: що це, які механізми та як налаштувати

Моделі дозволів на iOS та Android

Моделі дозволів на iOS та Android мають спільну ідею: користувач повинен дати згоду на доступ до чутливих даних (камера, мікрофон, геолокація, контакти). Однак реалізація суттєво відрізняється. Android запитує дозволи в момент використання (runtime), iOS вимагає опису мети в Info.plist і запитує при першому зверненні. Правильна реалізація прав доступу в мобільному застосунку — основа безпеки та довіри.

До Android 6.0 (API 23) всі дозволи запитувалися при встановленні — користувач або приймав усі, або не встановлював застосунок. З Android 6.0 з'явилися Runtime Permissions: застосунок запитує дозвіл у момент першої необхідності, а користувач може відмовити. iOS використовує аналогічний підхід з iOS 8.0. Знання еволюції прав доступу в мобільній розробці допомагає проектувати зрозумілий UX.

В IT Sectr ми дотримуємося принципу «мінімальних дозволів»: запитуємо лише те, що дійсно потрібно, і лише в момент, коли це необхідно. Це підвищує довіру користувачів: за даними Google (2025), застосунки, що запитують більше 5 дозволів при першому запуску, мають на 30% нижчу конверсію в реєстрацію. Ця модель прав доступу в мобільних застосунках підтверджується нашою практикою.

Таблиця 4. Порівняння моделей дозволів iOS та Android. Головна відмінність: iOS вимагає явного текстового опису мети використання кожного дозволу в Info.plist. Android пропонує shouldShowRequestPermissionRationale для пояснення користувачеві, навіщо потрібен дозвіл. Розуміння відмінностей у правах доступу між платформами допомагає вибрати правильну модель.

Типи дозволів (Normal, Dangerous, Runtime)

Normal Permissions — дозволи, які не становлять загрози для приватності користувача. Вони надаються автоматично при встановленні: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. Розробнику не потрібно запитувати їх у коді. Ця класифікація прав доступу відповідає рівню ризику для приватності.

Dangerous Permissions — дозволи, що вимагають доступу до особистих даних: CAMERA, RECORD_AUDIO, ACCESS_FINE_LOCATION, READ_CONTACTS, READ_CALENDAR, READ_EXTERNAL_STORAGE. Вони вимагають runtime-запиту. Permission Group — група пов'язаних дозволів: якщо користувач дозволив CAMERA, дозвіл на запис відео (RECORD_AUDIO? ні, це окрема група) — ні, CAMERA та RECORD_AUDIO в різних групах.

Runtime Permission — це виклик ActivityCompat.requestPermissions() на Android або запит через CLLocationManager.requestWhenInUseAuthorization() на iOS. Користувач може відповісти: Grant (дозволити), Deny (заборонити) або «Більше не питати» (на Android після двох відмов). Налаштування прав доступу в мобільному застосунку вимагає врахування поведінки користувача.

Runtime Permission

Runtime Permission на Android вимагає перевірки поточного статусу перед кожним використанням. Метод shouldShowRequestPermissionRationale() повертає true, якщо користувач уже відмовив — це сигнал показати діалог з поясненням. На iOS аналог — перевірка статусу: .notDetermined, .denied, .authorized, .restricted. Приватність мобільного застосунку вимагає постійного моніторингу статусу дозволів.

// Kotlin — запит runtime-дозволу на камеру
class CameraActivity : AppCompatActivity() {

    companion object {
        private const val CAMERA_PERMISSION_CODE = 100
    }

    private fun requestCameraPermission() {
        when {
            ContextCompat.checkSelfPermission(
                this, Manifest.permission.CAMERA
            ) == PackageManager.PERMISSION_GRANTED -> {
                openCamera()
            }
            shouldShowRequestPermissionRationale(Manifest.permission.CAMERA) -> {
                showRationaleDialog("Для сканування QR-кодів потрібен доступ до камери")
            }
            else -> {
                requestPermissions(
                    arrayOf(Manifest.permission.CAMERA),
                    CAMERA_PERMISSION_CODE
                )
            }
        }
    }

    override fun onRequestPermissionsResult(
        requestCode: Int,
        permissions: Array<String>,
        grantResults: IntArray
    ) {
        if (requestCode == CAMERA_PERMISSION_CODE &&
            grantResults.firstOrNull() == PackageManager.PERMISSION_GRANTED
        ) {
            openCamera()
        }
    }
}

Цей код показує правильний патерн: перевірка статусу → показ пояснення (якщо потрібно) → запит дозволу → обробка результату. shouldShowRequestPermissionRationale — важливий метод: якщо користувач уже відмовив, покажіть діалог з поясненням, навіщо потрібен дозвіл. Без цього користувач може назавжди заборонити доступ.

Приватність (ATT, Privacy Manifest, IDFA)

ATT (App Tracking Transparency) — фреймворк Apple (iOS 14.5+), що вимагає явної згоди користувача на відстеження. Без згоди IDFA (Identifier for Advertisers) повертає нулі. За даними Flurry (2025), рівень згоди на ATT становить 15–25% залежно від регіону та типу застосунку. Управління правами доступу в мобільному застосунку починається з вибору правильного фреймворку.

Privacy Manifest — обов'язковий файл (з 2024 року для нових застосунків, з 2025 — для оновлень), в якому розробник декларує, які типи даних збирає застосунок та для яких цілей. Apple перевіряє відповідність Privacy Manifest реальній поведінці застосунку на рев'ю. Приватність у мобільному застосунку має бути задокументована.

App Tracking Transparency (ATT)

ATT вимагає додати Info.plist ключ NSUserTrackingUsageDescription з описом, навіщо потрібне відстеження, і викликати ATTrackingManager.requestTrackingAuthorization(). Важливо: чи варто запитувати ATT до показу GDPR-згоди? Ні, ATT — це окремий запит від Apple. В ЄС спочатку покажіть GDPR-банер, потім ATT. Права доступу в мобільному застосунку на iOS вимагають обов'язкового налаштування ATT.

IDFA використовується для рекламної атрибуції та персоналізації. На Android аналог — GAID (Google Advertising ID) або AAID (Amazon Advertising ID). З Android 13+ з'явилося runtime-дозвіл для доступу до GAID (com.google.android.gms.permission.AD_ID). Приватність мобільного застосунку вимагає контролю над рекламними ідентифікаторами.

GDPR та згода користувача

GDPR (Загальний регламент захисту даних) — регламент ЄС, що діє з травня 2018 року. Він вимагає: явної згоди на збір персональних даних, права на управління правами доступу, видалення даних (right to be forgotten), повідомлення про витоки даних та призначення DPO (Data Protection Officer) для великих компаній. Регламент також визначає прозору модель прав доступу в мобільних застосунках.

Для мобільних застосунків GDPR означає: показ банера згоди при першому запуску (з чітким описом, які дані збираються та для яких цілей), можливість відмовитися від необов'язкових дозволів, кнопка «Видалити обліковий запис» у налаштуваннях. Популярні інструменти для GDPR: OneTrust, Consent Management Platform (CMP) від Google, Usercentrics. Забезпечення приватності в мобільному застосунку вимагає інтеграції CMP.

В IT Sectr ми впроваджуємо GDPR-згоду на етапі онбордингу: користувач бачить зрозумілий опис, вибирає, які дані дозволяє збирати, і може змінити вибір у налаштуваннях. Це не лише юридична вимога, але й фактор довіри: прозорі застосунки мають на 20% вищий retention (дані IT Sectr, 2024). Приватність мобільного застосунку та управління правами доступу — ключові фактори утримання користувачів.

GDPR та згода користувача

Згода повинна бути: добровільною (ні — означає ні), конкретною (не можна зібрати згоду «на все»), інформованою (користувач знає, на що погоджується) та однозначною (потрібна активна дія — галочка, кнопка). Попередньо встановлені галочки (pre-ticked consent) заборонені GDPR. Штрафи за порушення — до 4% глобального обороту або 20 млн євро. Правильне налаштування прав доступу в мобільному застосунку допомагає уникнути штрафів.

Практичні поради

На основі досвіду IT Sectr — кілька практичних рекомендацій щодо роботи з дозволами та приватністю. Запитуйте дозволи в контексті: покажіть екран, який пояснює, навіщо потрібен дозвіл, перед системним діалогом. Наприклад, перед запитом камери покажіть: «Для сканування QR-коду нам потрібен доступ до камери» — це підвищує ймовірність згоди на 40%. Права доступу в мобільних застосунках мають запитуватися в контексті використання.

Не запитуйте всі дозволи при першому запуску. Contextual permission request (запит у момент використання) дає на 60% вищу конверсію, ніж запит при онбордингу. Обробляйте відмову gracefully: якщо користувач відмовив, не блокуйте функціональність, а запропонуйте альтернативу (наприклад, ручне введення адреси замість геолокації). Приватність у мобільному застосунку виграє від такого підходу.

Для iOS обов'язково додайте Privacy Manifest (з 2025 — обов'язково для всіх застосунків). Для Android вкажіть Data Safety Section у Google Play Console. Зберігайте статус усіх дозволів локально та синхронізуйте з налаштуваннями системи. Регулярно перевіряйте відповідність вимогам — законодавство змінюється швидко. Модель прав доступу та приватність мобільного застосунку вимагають постійного аудиту.