⬡ Dev Tools/2026-06-30Advanced

Take One Contact, Not the Whole Book — iOS 18's ContactAccessButton

iOS 18 adds a limited tier to contacts access. With ContactAccessButton you can receive just the one contact a user picks, without ever asking for the whole address book. Assuming the native Swift Rork Max generates, here is the design and implementation.

Contacts iOS 18⁵ ContactAccessButton Rork Max¹⁹⁵ Privacy⁸

✦ Premium Article

The moment someone taps "invite a friend," up comes "App Name would like to access all your contacts" — and plenty of people freeze right there. As an indie developer who has shipped apps for years, I see that for someone who only wants to share one person, demanding the entire address book is an obviously lopsided trade.

iOS 18 adds a "limited" tier to contacts access. And by placing a ContactAccessButton, you can hand your app only the contact the user picks on the spot — without even showing a permission dialog. No full access required. Assuming the native Swift Rork Max generates, we will walk the design and the implementation.

The problem when it was "all or nothing"

Contacts used to be effectively binary: show everything, or show nothing. Even a user who wants to invite one person was asked for full disclosure, and a denial killed the whole feature. At indie scale, that single denial often becomes a drop-off.

iOS 18's limited access breaks the binary. The user shares "just this person and that person," and the app reads only that range. ContactAccessButton folds that selection into a single button.

Place the ContactAccessButton

ContactAccessButton is a SwiftUI view. Give it a query string and it finds matching contacts internally, handing the app only the one the user taps. The key point: the button itself shows no permission dialog.

import SwiftUI
import ContactsUI
import Contacts
 
struct InviteField: View {
    @State private var query: String = ""
    @State private var picked: [String] = []   // identifiers received
 
    var body: some View {
        VStack {
            TextField("Search by name", text: $query)
                .textFieldStyle(.roundedBorder)
 
            ContactAccessButton(queryString: query) { identifiers in
                // Only the contact the user tapped arrives here
                picked.append(contentsOf: identifiers)
                fetchPickedDetails(identifiers)
            }
            .frame(height: 44)
        }
    }
}

Candidates matching the typed name appear inside the button, and only the tapped one returns as identifiers. You receive the one contact you need without ever requesting read access to all of them.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Receive only the contact a user picks — no full-access prompt — with ContactAccessButton (working SwiftUI included)

✦Use the limited authorization and ContactAccessPicker to let users widen or narrow what they share later

✦A migration path from full-access code and the pitfalls of keeping features alive when access is denied

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Read the contact you received

ContactAccessButton returns identifiers. You fetch the actual name and phone number from CNContactStore, but you can only read the range shared via limited access. The full book stays invisible.

func fetchPickedDetails(_ ids: [String]) {
    let store = CNContactStore()
    let keys = [CNContactGivenNameKey, CNContactPhoneNumbersKey] as [CNKeyDescriptor]
    let request = CNContactFetchRequest(keysToFetch: keys)
    request.predicate = CNContact.predicateForContacts(withIdentifiers: ids)
    try? store.enumerateContacts(with: request) { contact, _ in
        // Only shared contacts pass through here
        print(contact.givenName)
    }
}

This is the crux of the privacy design. Because the picked range equals the readable range, accidentally sweeping the whole book becomes impossible by construction.

Treat authorization as three worlds

With limited access, authorization is no longer a two-value "allow / deny." In design terms, handle three worlds separately.

authorized (full)

The user explicitly granted all contacts. Run your existing full-fetch code only in this case.

limited

The new iOS 18 state. You read only what was shared, and additions come from ContactAccessButton or the picker below. Treat this the same as authorized and you will query for contacts you cannot see and fail silently.

notDetermined / denied

Not yet decided, or denied. ContactAccessButton still works here, so rather than disabling the whole invite feature "if denied," I strongly recommend keeping the single-contact share through the button alive.

Let users widen or narrow the share later

After sharing under limited access once, a user may later want to add more. Presenting ContactAccessPicker opens a system screen to add or remove shared contacts.

.contactAccessPicker(isPresented: $showPicker) { identifiers in
    // The shared set was updated
}

Instead of sending users to the Settings app, this in-app picker keeps it self-contained, which reduces drop-off. Being able to "reduce" the share in the same place as "expand" it speaks directly to a user's sense of safety.

Migration and where people trip up

When migrating old code, first add .limited to your CNContactStore.authorizationStatus(for: .contacts) branch. Funnel it into the same branch as .authorized and a full-book query runs for a limited user, returns empty, and looks like a "cannot read contacts" bug. Running it once on a real device under limited access is essential before production.

Another is NSContactsUsageDescription in Info.plist. Limited access still needs a reason string, and an empty one gets rejected in review. Write it from the user's perspective — why the contact is needed.

Finally, do not leave the ContactAccessButton query string empty. An empty query surfaces broad candidates and dilutes the button's whole point of "the one you aimed at." Wire queryString to update with the input.

Pick one screen where a single contact is enough — invite, share — and swap it for ContactAccessButton. Just removing the full-access dialog visibly changes how many people get through that screen.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.