Permesso di accesso ai contatti nello sviluppo mobile — cosa è, come funziona e richiesta di accesso

Cos'è il permesso di accesso ai contatti?

Il permesso di accesso ai contatti è un meccanismo del sistema operativo che protegge la rubrica dell'utente dalla lettura non autorizzata da parte di app di terze parti. Nei sistemi operativi mobili, i contatti sono considerati dati sensibili perché contengono nomi, numeri di telefono, indirizzi email e foto delle persone nella cerchia dell'utente.

Su iOS, l'autorizzazione è regolata dal framework Contacts e dalla classe CNContactStore. L'utente vede un dialogo di sistema alla prima richiesta di accesso, dove può scegliere di concedere o negare l'accesso. Su Android, la protezione si basa sul sistema di autorizzazioni runtime: l'app dichiara READ_CONTACTS nel manifest e lo richiede in fase di esecuzione tramite ActivityResultLauncher o un fragment che gestisce il risultato.

Secondo Statista (2025), oltre il 68% degli utenti iOS e il 54% degli utenti Android nega l'accesso ai contatti alla prima richiesta. Ciò significa che lo sviluppatore non solo deve implementare correttamente la richiesta, ma anche spiegare all'utente perché l'accesso è necessario.

Standard di settore — richiedere l'accesso solo quando la funzionalità è effettivamente necessaria, non al primo avvio. Questo approccio riduce il tasso di rifiuto e migliora l'esperienza utente.

Come funziona la richiesta di accesso ai contatti su iOS

Nell'ecosistema Apple, l'accesso ai contatti è regolato dal framework Contacts, introdotto in iOS 9. La classe CNContactStore fornisce metodi per richiedere l'autorizzazione ed eseguire operazioni di lettura e scrittura. Alla prima chiamata di requestAccess(for:), il sistema mostra un dialogo nativo che spiega il motivo dell'accesso.

CNContactStore e accesso a un singolo contatto

A partire da iOS 17, Apple ha introdotto la modalità di accesso a un singolo contatto. L'utente può selezionare un contatto dalla rubrica e condividerlo con l'app senza rivelare l'intero database. Questa modalità è implementata tramite CNContactPickerViewController e non richiede la chiamata a requestAccess(for:).

È importante che lo sviluppatore capisca: se un'app richiede l'accesso completo ma funzionalmente necessita solo di un contatto, i moderatori dell'App Store potrebbero rifiutare la build. Secondo le Apple App Review Guidelines (2025), la sezione 5.1.1 richiede esplicitamente la quantità minima necessaria di dati.

Privacy Manifest in iOS 18

Con il rilascio di iOS 18, Apple ha inasprito i requisiti per il Privacy Manifest — il file privacy.xcprivacy in cui lo sviluppatore dichiara il motivo dell'accesso ai dati protetti. Per i contatti, viene utilizzata la chiave NSContactsUsageDescription con testo localizzato visualizzato nel dialogo di sistema.

Senza un privacy manifest corretto, l'app non supera la moderazione di App Store Connect. Il testo della descrizione deve essere specifico: non “Per migliorare le prestazioni”, ma “Per trovare amici tramite numero di telefono”.

Come funziona la richiesta di accesso ai contatti su Android

Su Android, l'accesso ai contatti è protetto dall'autorizzazione READ_CONTACTS, che appartiene alla categoria pericolosa — deve essere richiesta in fase di esecuzione, non solo durante l'installazione. Il meccanismo delle autorizzazioni runtime è stato introdotto in Android 6.0 (API 23) e rimane il metodo principale per proteggere i dati sensibili.

READ_CONTACTS e autorizzazione runtime

L'autorizzazione READ_CONTACTS viene dichiarata nel manifest tramite il tag uses-permission e richiesta nel codice tramite ActivityResultLauncher o un fragment con onRequestPermissionsResult. L'utente può negare la richiesta o selezionare “Non chiedere più”, dopodiché l'app deve gestire correttamente il rifiuto.

A partire da Android 14 (API 34), il comportamento delle autorizzazioni runtime è cambiato: dopo due rifiuti consecutivi, il sistema operativo imposta automaticamente il flag neverAskAgain. Secondo Google Developer Documentation (2024), lo sviluppatore dovrebbe verificare lo stato tramite shouldShowRequestPermissionRationale prima di richiedere nuovamente.

ContactsContract e ContentProvider

Per leggere i contatti, Android utilizza un ContentProvider chiamato ContactsContract. Si tratta di un database strutturato accessibile tramite ContentResolver. I dati sono organizzati in diverse tabelle: Contacts (contatti), RawContacts (record grezzi da diversi account), Data (informazioni dettagliate: telefoni, email, indirizzi).

La query a ContactsContract viene eseguita tramite l'URI ContactsContract.Contacts.CONTENT_URI. Lo sviluppatore dovrebbe richiedere il numero minimo di colonne e utilizzare la proiezione per filtrare i campi — questo accelera l'esecuzione della query e riduce il consumo di memoria.

Esempi di codice per richiedere i contatti

L'implementazione pratica della richiesta di accesso ai contatti differisce tra iOS e Android. Di seguito sono riportati esempi concreti in Swift e Kotlin con la gestione di tutti i possibili stati dell'autorizzazione.

Richiedere l'accesso in Swift

Su iOS, la richiesta viene effettuata tramite il metodo requestAccess della classe CNContactStore. Il risultato viene restituito in una closure con un valore booleano e un errore opzionale. L'esempio seguente mostra il ciclo completo di richiesta con la gestione dello stato.

import Contacts

let store = CNContactStore()

store.requestAccess(for: .contacts) { granted, error in
    if granted {
        print("Accesso ai contatti concesso")
        // Esecuzione di operazioni sui contatti
        let keys = [CNContactGivenNameKey, CNContactFamilyNameKey, CNContactPhoneNumbersKey]
        let request = CNContactFetchRequest(keysToFetch: keys as [CNKeyDescriptor])
        try? store.enumerateContacts(with: request) { contact, stop in
            print("\(contact.givenName) \(contact.familyName)")
        }
    } else {
        print("Accesso negato: \(error?.localizedDescription ?? "errore sconosciuto")")
    }
}

Richiedere l'accesso in Kotlin

Su Android, la richiesta viene effettuata tramite ActivityResultLauncher con il contratto RequestPermission. L'esempio seguente mostra il lavoro con ContactsContract.ContentProvider dopo aver ottenuto l'autorizzazione.

val requestPermissionLauncher =
    registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
        if (isGranted) {
            val uri = ContactsContract.Contacts.CONTENT_URI
            val cursor = contentResolver.query(uri, null, null, null, null)
            cursor?.use {
                val nameIndex = it.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME)
                while (it.moveToNext()) {
                    val name = it.getString(nameIndex)
                    Log.d("Contacts", "Contatto: $name")
                }
            }
        } else {
            // Spiegare all'utente il motivo della necessità di accesso
            showRationaleDialog()
        }
    }

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    requestPermissionLauncher.launch(android.Manifest.permission.READ_CONTACTS)
}

Migliori pratiche per lavorare con i contatti

Gli sviluppatori di app mobili esperti seguono una serie di pratiche comprovate quando lavorano con il permesso di accesso ai contatti. Queste regole aiutano a superare la moderazione degli app store e a mantenere la fiducia degli utenti. Seguire le migliori pratiche semplifica notevolmente il processo di pubblicazione e manutenzione.

Minimizzare le autorizzazioni richieste

Non richiedere mai l'accesso ai contatti al primo avvio dell'app. La prima richiesta dovrebbe avvenire nel contesto di una funzionalità specifica: cercare amici, invitare partecipanti, importare contatti. Un utente che comprende il motivo della richiesta accetta 2–3 volte più spesso, secondo le ricerche di Apptentive (2024).

Se la funzionalità necessita solo dell'accesso a un singolo contatto, utilizza CNContactPickerViewController su iOS o un intent implicito ACTION_PICK su Android. Questi metodi non richiedono autorizzazione preventiva e consentono all'utente di selezionare autonomamente un record senza rivelare l'intera rubrica all'app.

Gestione del rifiuto di accesso

L'app deve gestire correttamente le situazioni in cui l'utente nega l'accesso. Su iOS, verifica lo stato tramite CNContactStore.authorizationStatus(for:) e indirizza l'utente alle Impostazioni se necessario. Su Android, utilizza shouldShowRequestPermissionRationale per mostrare una spiegazione aggiuntiva prima di richiedere nuovamente.

Non mostrare mai un secondo dialogo immediatamente dopo un rifiuto — viene percepito come aggressivo e abbassa la valutazione dell'app. Migliore pratica: dopo un po' di tempo, mostra una schermata con una spiegazione e un pulsante “Vai alle Impostazioni” che apre la schermata delle autorizzazioni di sistema tramite un Intent. Testa lo scenario di rifiuto su dispositivi reali — i simulatori non sempre riproducono correttamente il comportamento dei dialoghi di autorizzazione di sistema.