Access Permissions and Privacy in Mobile Development: What It Is, Mechanisms, and How to Configure

Permission Models on iOS and Android

Permission Models on iOS and Android share a common idea: the user must consent to access sensitive data (camera, microphone, location, contacts). However, the implementation differs significantly. Android requests permissions at the time of use (runtime), iOS requires describing the purpose in Info.plist and requests on first access. Proper implementation of access permissions in a mobile app is the foundation of security and trust.

Before Android 6.0 (API 23), all permissions were requested at install time — the user either accepted all or did not install the app. With Android 6.0, Runtime Permissions were introduced: the app requests permission at the moment of first need, and the user can deny it. iOS has used a similar approach since iOS 8.0. Understanding the evolution of access permissions in mobile development helps design intuitive UX.

At IT Sectr, we follow the principle of "minimum permissions": we only request what is truly needed, and only when it is necessary. This increases user trust: according to Google (2025), apps requesting more than 5 permissions on first launch have a 30% lower registration conversion rate. This access permission model in mobile apps is confirmed by our practice.

Table 4. Comparison of iOS and Android permission models. The main difference: iOS requires an explicit textual description of the purpose for each permission in Info.plist. Android offers shouldShowRequestPermissionRationale to explain to the user why a permission is needed. Understanding the differences in access rights between platforms helps choose the right model.

Permission Types (Normal, Dangerous, Runtime)

Normal Permissions — permissions that do not pose a risk to user privacy. They are granted automatically at install time: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. The developer does not need to request them in code. This access permission classification corresponds to the privacy risk level.

Dangerous Permissions — permissions that require access to personal data: CAMERA, RECORD_AUDIO, ACCESS_FINE_LOCATION, READ_CONTACTS, READ_CALENDAR, READ_EXTERNAL_STORAGE. They require a runtime request. Permission Group — a group of related permissions: if the user allowed CAMERA, permission to record video (RECORD_AUDIO? no, that's a separate group) — no, CAMERA and RECORD_AUDIO are in different groups.

Runtime Permission — calling ActivityCompat.requestPermissions() on Android or requesting via CLLocationManager.requestWhenInUseAuthorization() on iOS. The user can respond: Grant, Deny, or "Never ask again" (on Android after two denials). Configuring access permissions in a mobile app requires accounting for user behavior.

Runtime Permission

Runtime Permission on Android requires checking the current status before each use. The shouldShowRequestPermissionRationale() method returns true if the user has already denied — this signals to show a dialog with an explanation. On iOS, the equivalent is status check: .notDetermined, .denied, .authorized, .restricted. Mobile app privacy requires constant monitoring of permission status.

// Kotlin — requesting runtime camera permission
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("Camera access is needed to scan QR codes")
            }
            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()
        }
    }
}

This code demonstrates the correct pattern: check status → show explanation (if needed) → request permission → handle result. shouldShowRequestPermissionRationale is an important method: if the user has already denied, show a dialog explaining why the permission is needed. Without this, the user may permanently deny access.

Privacy (ATT, Privacy Manifest, IDFA)

ATT (App Tracking Transparency) — an Apple framework (iOS 14.5+) requiring explicit user consent for tracking. Without consent, IDFA (Identifier for Advertisers) returns zeros. According to Flurry (2025), the ATT opt-in rate is 15–25% depending on region and app type. Managing access permissions in a mobile app starts with choosing the right framework.

Privacy Manifest — a mandatory file (since 2024 for new apps, since 2025 for updates) in which the developer declares what data types the app collects and for what purposes. Apple checks the Privacy Manifest against the app's actual behavior during review. Mobile app privacy must be documented.

App Tracking Transparency (ATT)

ATT requires adding the Info.plist key NSUserTrackingUsageDescription with a description of why tracking is needed, and calling ATTrackingManager.requestTrackingAuthorization(). Important: should you request ATT before showing GDPR consent? No, ATT is a separate Apple request. In the EU, first show the GDPR banner, then ATT. Access permissions in a mobile app on iOS require mandatory ATT configuration.

IDFA is used for advertising attribution and personalization. On Android, the equivalent is GAID (Google Advertising ID) or AAID (Amazon Advertising ID). Since Android 13+, there is a runtime permission for accessing GAID (com.google.android.gms.permission.AD_ID). Mobile app privacy requires control over advertising identifiers.

GDPR and User Consent

GDPR (General Data Protection Regulation) — EU regulation effective since May 2018. It requires: explicit consent for collecting personal data, the right to manage access permissions, the right to delete data (right to be forgotten), data breach notifications, and appointment of a DPO (Data Protection Officer) for large companies. The regulation also defines a transparent access permission model in mobile apps.

For mobile apps, GDPR means: showing a consent banner on first launch (with a clear description of what data is collected and for what purposes), the ability to opt out of non-essential permissions, and a "Delete Account" button in settings. Popular GDPR tools: OneTrust, Google's Consent Management Platform (CMP), Usercentrics. Ensuring privacy in a mobile app requires CMP integration.

At IT Sectr, we implement GDPR consent during onboarding: the user sees a clear description, chooses which data to allow, and can change their choice in settings. This is not only a legal requirement but also a trust factor: transparent apps have 20% higher retention (IT Sectr data, 2024). Mobile app privacy and access permission management are key factors in user retention.

GDPR and User Consent

Consent must be: freely given (no means no), specific (cannot collect consent "for everything"), informed (the user knows what they are consenting to), and unambiguous (affirmative action required — checkbox, button). Pre-ticked checkboxes are prohibited under GDPR. Fines for violations — up to 4% of global turnover or 20 million euros. Proper configuration of access permissions in a mobile app helps avoid fines.

Practical Tips

Based on IT Sectr's experience — several practical recommendations for working with permissions and privacy. Request permissions in context: show a screen that explains why the permission is needed before the system dialog. For example, before requesting the camera, show: "We need camera access to scan QR codes" — this increases the likelihood of consent by 40%. Access permissions in mobile apps should be requested in the context of use.

Do not request all permissions on first launch. Contextual permission request (request at the time of use) yields 60% higher conversion than requesting during onboarding. Handle denial gracefully: if the user denies, do not block functionality, but offer an alternative (e.g., manual address entry instead of geolocation). Mobile app privacy benefits from this approach.

For iOS, be sure to add a Privacy Manifest (mandatory for all apps since 2025). For Android, specify a Data Safety Section in Google Play Console. Store the status of all permissions locally and sync with system settings. Regularly audit compliance — regulations change quickly. The access permission model and privacy of a mobile app require constant auditing.