Права приступа и приватност у мобилном развоју: шта је то, који механизми и како подесити

Модели дозвола на 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 Manifests-а са стварним понашањем апликације током рецензије. Приватност у мобилној апликацији мора бити документована.

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. Захтева: изричиту сагласност за прикупљање личних података, право на управљање правима приступа, право на брисање података (право на заборава), обавештења о цурењу података и именовање DPO (службеника за заштиту података) за велике компаније. Уредба такође дефинише транспарентан модел права приступа у мобилним апликацијама.

За мобилне апликације, GDPR значи: приказ банера сагласности при првом покретању (са јасним описом који подаци се прикупљају и у које сврхе), могућност одбијања необавезних дозвола и дугме «Избриши налог» у подешавањима. Популарни GDPR алати: OneTrust, платформа за управљање сагласношћу (CMP) Google-а, Usercentrics. Обезбеђивање приватности у мобилној апликацији захтева интеграцију CMP.

У IT Sectr имплементирамо GDPR сагласност у фази онбординга: корисник види јасан опис, бира које податке дозвољава прикупљање и може променити избор у подешавањима. Ово није само законски захтев већ и фактор поверења: транспарентне апликације имају 20% вишу стопу задржавања (подаци IT Sectr, 2024). Приватност мобилне апликације и управљање правима приступа су кључни фактори задржавања корисника.

GDPR и сагласност корисника

Сагласност мора бити: добровољна (не значи не), конкретна (не може се прикупити сагласност «за све»), информисана (корисник зна на шта пристаје) и недвосмислена (потребна је активна радња — потврдни квадратић, дугме). Унапред означени квадратићи су забрањени GDPR-ом. Казне за кршење — до 4% глобалног промета или 20 милиона евра. Правилно подешавање права приступа у мобилној апликацији помаже у избегавању казни.

Практични савети

На основу искуства IT Sectr — неколико практичних препорука за рад са дозволама и приватношћу. Захтевајте дозволе у контексту: прикажите екран који објашњава зашто је дозвола потребна пре системског дијалога. На пример, пре захтева за камеру прикажите: «Потребан нам је приступ камери за скенирање QR кодова» — ово повећава вероватноћу сагласности за 40%. Права приступа у мобилним апликацијама треба захтевати у контексту коришћења.

Не захтевајте све дозволе при првом покретању. Контекстуални захтев за дозволу (захтев у тренутку коришћења) даје 60% вишу конверзију од захтева током онбординга. Одбијање обрадите са тактом: ако корисник одбије, не блокирајте функционалност, већ понудите алтернативу (нпр. ручни унос адресе уместо геолокације). Приватност у мобилној апликацији има користи од овог приступа.

За iOS обавезно додајте Privacy Manifest (од 2025. обавезан за све апликације). За Android наведите Data Safety Section у Google Play конзоли. Чувајте статус свих дозвола локално и синхронизујте са системским подешавањима. Редовно проверавајте усклађеност — законодавство се брзо мења. Модел права приступа и приватност мобилне апликације захтевају сталну ревизију.