●BUILD — Rork Max runs real Macs in the cloud loaded with Xcode and the iOS SDK, writing SwiftUI, compiling, reading the errors and building again. That loop, not the code generation, is what lifts the output●NATIVE — What comes out is pure Swift and SwiftUI, not React Native. Reaching AR, Metal graphics and widgets that React Native cannot touch is the real gap between this and other builders●PLATFORMS — Coverage spans iPhone, iPad, Apple Watch, Apple TV and Vision Pro, plus iMessage. Worth a look if you want to start from a watch app or an extension rather than a phone screen●COMPANION — The Rork Companion app lets you check a generated build on a real iPhone without a paid Apple Developer account, lowering the bar for trying a first project end to end●PRICING — Free to start, paid plans from $25 a month, and Rork Max on the $200 Max plan. Worth working out up front how many projects it takes to earn that back●DEADLINE — From August 31, 2026, Google Play requires target API level 36 or higher for new apps and updates alike. Ten days out, and the targetSdkVersion of what you generate is yours to verify●BUILD — Rork Max runs real Macs in the cloud loaded with Xcode and the iOS SDK, writing SwiftUI, compiling, reading the errors and building again. That loop, not the code generation, is what lifts the output●NATIVE — What comes out is pure Swift and SwiftUI, not React Native. Reaching AR, Metal graphics and widgets that React Native cannot touch is the real gap between this and other builders●PLATFORMS — Coverage spans iPhone, iPad, Apple Watch, Apple TV and Vision Pro, plus iMessage. Worth a look if you want to start from a watch app or an extension rather than a phone screen●COMPANION — The Rork Companion app lets you check a generated build on a real iPhone without a paid Apple Developer account, lowering the bar for trying a first project end to end●PRICING — Free to start, paid plans from $25 a month, and Rork Max on the $200 Max plan. Worth working out up front how many projects it takes to earn that back●DEADLINE — From August 31, 2026, Google Play requires target API level 36 or higher for new apps and updates alike. Ten days out, and the targetSdkVersion of what you generate is yours to verify
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.
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 SwiftUIimport ContactsUIimport Contactsstruct 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.
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.
Share
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.