You can add contacts access to an app without ever asking permission.
There are two ways to add contacts access to an app, and the good one is the one most teams skip. The system contact picker shows people their own address book, returns the single person they tapped, and never shows a permission prompt. The contacts permission returns the whole address book at once, and with it a set of store rules you now have to live inside. Start at the picker. Move only when a feature genuinely cannot work without the full list.
One limit is worth knowing before any code gets written. Sending a user's entire address book to your server is the fastest way to fail App Store review. It is also personal data about people who never installed your app. This page covers the picker, the permission, what the stores forbid once you hold contacts, and how to build invites without hoarding anything. It sits on top of app security basics, which is worth settling first.
See which route your feature needsThe short version
Ask for one contact, not for the address book.
Almost every contacts feature people describe is one of two things. Someone is filling in a field and would rather tap a name than type it. Or the app wants to know which of their friends already use it. The first needs no permission at all. The second needs a permission, a matching design, and a straight answer about what leaves the phone.
Reaching for full access because it is the obvious API is how an app ends up storing other people's phone numbers with no plan for them. The prompt takes ten minutes to add and months to justify.
The picker route, which asks for nothing
Both platforms ship a contact picker that runs outside your app. The user sees their own contacts, taps one, and your app receives that selection and nothing else. Apple's documentation for the contact picker view controller is blunt about it. The app does not need access to the user's contacts. The user is not prompted to grant permission, and the app has access only to the final selection.
Android reaches the same place through a pick intent. Fire the pick action with a specific data type, a phone number or an email address, and the result is a URI for the chosen item. Android's documentation states that the response grants your app temporary permission to read that contact data even if your app does not include the read contacts permission. Pick a whole contact instead and you get basic details such as the display name, but reading that contact's phone number or email still needs the permission. So ask for the exact field, not the person.
In a React Native and Expo project this is the expo-contacts module, which exposes the native picker alongside the permission calls. The picker path needs no runtime request, so there is no denial screen to design and nothing to explain at review. If the feature is "let me choose a person", you are finished here, and everything below is a problem you do not have.
Android developers, common intents for selecting a contact
Try it
Which contacts route your feature needs
Tick what is true of the thing you are building. Most features stop at the first line.
System contact picker, no permission at all
The picker runs outside your app, returns only the tapped selection and shows no prompt. Nothing to justify at review.
1 of 4 ticked.
What the stores will not let you do with an address book
Apple's App Store Review Guidelines are specific about contacts, and the rules bite after you hold the data rather than before. Guideline 5.1.2 says not to use information from Contacts to build a contact database for your own use or for sale or distribution to third parties. Guideline 5.1.1 adds that apps which compile personal information from any source that is not directly from the user, or without the user's explicit consent, are not permitted on the App Store.
The invite rules are tighter than most teams expect. You may not contact people using information collected from a user's Contacts except at that user's explicit initiative, one recipient at a time. There must be no Select All option and no defaulting to the selection of all contacts. And you have to show the user how the message will appear to the recipient, including who it looks like it came from, before it is sent. A bulk invite screen with everything pre-ticked is a rejection, not a growth feature.
Two more catch people out. Purpose strings must describe your use of the data clearly and completely, so "to improve your experience" is not a purpose string. And paid functionality must not depend on or require someone to grant access to this data, which rules out putting a paid tier behind the contacts prompt. Work out what the stores allow before you design the screen, not after a reviewer sends it back.
One honest gap. We read Apple's guidelines directly for this page. We did not verify Google Play's current policy wording for contacts data, so read Play's own user data policy before shipping anything that moves contacts off the device. Do not take our word, or an AI's, for what a store allows.
Apple, App Store Review Guidelines, sections 5.1.1 and 5.1.2
When full access is genuinely the right call
There is one honest reason to read phone contacts in bulk. You need to match the user's address book against your own users, and nobody can do that by tapping one name at a time. Friend finding, deduplicating against a customer list, an app whose entire job is contacts. If your feature is not on that list, the picker still wins.
On Android this is the READ_CONTACTS permission, declared in the manifest and requested at runtime, with the usual result that a large share of people decline. Design the screen that appears when they do. On iOS, since iOS 18, someone can grant limited access instead of full access, so your app sees only the contacts they chose. Expo's permission response reports this as all, limited or none, and your code has to treat limited as a normal state rather than a failure. Apple also provides a contact access button so people can add more contacts from inside your app instead of going back to Settings.
Matching is where the real decision sits, because it usually means sending something to a server. Hashing phone numbers before they leave the device is the common compromise. It is a compromise, not anonymity. Phone numbers come from a small enough space that anyone willing to compute the whole list can reverse a hash. Say what you do in the purpose string and then do exactly that. If the point of the feature is growth, an app referral program built on a shareable link reaches the same outcome without touching anyone's contacts.
Letting people invite friends from contacts, safely
Most plans to invite friends from contacts exist to produce one thing: a link, in a message, from someone the recipient already knows. You do not need the address book to produce that. The system share sheet hands the user their own messaging apps and their own recent conversations, they choose the recipient there, and your app never learns who it was.
The trade is that you cannot count who was invited until they arrive. In exchange you drop the permission prompt, the store rules, the storage question and the awkward conversation about whose data this is. For most apps that is a good trade, and the link itself can still carry attribution. The mechanics are in add share sheet.
If you do build the contacts version, the shape that passes review is narrow. The user opens a search field, finds one person, sees exactly what the message says and who it appears to come from, and sends it. No preselected list, no Select All, no silent send. Sketch that screen first and the permission question mostly answers itself.
What each route actually gives you
| Route | Permission prompt | Your server sees contacts | Store review risk | Good for |
|---|---|---|---|---|
| System contact picker | No | No | low | Filling one field with one person |
| Share sheet invite link | No | No | low | Invites and referrals |
| Contacts permission, kept on device | Yes | No | low | Search, dedupe, an app about contacts |
| Contacts permission, hashed match on a server | Yes | hashes only | worth review | Friend finding with no other route |
| Whole address book uploaded | Yes | Yes | high | Nothing worth the trouble |
Building the contacts screen into your own app
The code is small and the decisions are not. A picker is an afternoon. A friend finder is a permission prompt, a denial path, a matching service, a retention rule and a paragraph in your privacy policy that has to be true. Scope it before you build it, and be honest about which of the two your feature really is.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own. It runs on a cloud iPhone or Android simulator while it builds, then ships to TestFlight and to Google Play internal testing. Plans are $25 a month and there is no free plan. Ask for the picker flow by name, because "add contacts" as a phrase tends to produce the wrong one.
Whatever you build, write the permission prompt yourself. It is the only place anyone is told what you plan to do with their friends' phone numbers, and it is the first sentence a reviewer reads.
Questions people ask about contacts access
Two routes. Present the system contact picker, which runs outside your app, returns only the person the user tapped and shows no permission prompt. Or request the contacts permission, which gives you the whole address book and brings the store rules with it. Start with the picker and move only if the feature cannot work without the full list.
Describe the contacts screen you actually need
Write down the one thing the user is trying to do, a name in a field or a friend to invite, then build that and nothing more.
Start building