Apple contact usage policy

I am building a native social app in Android and iOS I am using contacts from users phonebook to determine if his target friends are on our app or not and send the events accordingly I recently came across this news that Apple is banning apps to send contacts to the server, which is the backbone of my app in order to function

How should I approach this problem? How do apps like WhatsApp which sync contacts (whole phonebook) to their server manage through this? Do I need apple review of the app to access phonebook permission?

From This article I quote

But the phone maker didn’t publicly mention updated App Store Review Guidelines that now bar developers from making databases of address book information they gather from iPhone users. Sharing and selling that database with third parties is also now forbidden. And an app can’t get a user’s contact list, say it’s being used for one thing, and then use it for something else -- unless the developer gets consent again. Anyone caught breaking the rules may be banned.

Since the question is quite general let's dive into it a bit.

Looking into the App Store Review Guidelines there are three places mentioning that users' contacts should not be collected.

First and second, users should not be forced to provide their address book in exchange for app functionality (paying with contacts; highlights were added, a similar phrase is used for app subscriptions):

Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, […]

Third, uploading and/or storing contacts to/on a server has an impact on users' privacy and is prohibited for the following use-cases:

Do not use information from Contacts, Photos, or other APIs that access user data to build a contact database for your own use or for sale/distribution to third parties, and don’t collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing.

This does not exclude using contacts for creating a social graph for the benefit of your users. However, collecting all contacts might violate the principle of data minimization. So Instead of just uploading all contacts, Apple recommends to use a contact picker (see ContactsUI), where the app only gets access to the contacts the user selected:

Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.

The Art. 32 of the GDPR requires you to take the

[…] the state of the art, the costs of implementation and the nature, scope, context and purposes of processing […]

into account.

I think that the process has to be made transparent (as in comprehensibly explained to the user):

• The user should have control over which contacts are used for discovery. All would be a valid choice – selected contacts (through the contact picker) or manually entering contact information (phone number, email – whatever is used for your contact discovery process) would be valid choices as well.
• The app should function even if the user denies access to the contacts. In that case you can still offer a contact picker, or manual entering.
• You must describe the process, including what information is used and for what purpose, in your privacy policy.
• You should at least hash the processed values, as you do not need the actual phone numbers or email addresses for contact discovery and hashing comes without much effort and cost. However, be aware that hashing of personally identifiable information is not sufficient for "anonymising" these values – which is a common misconception.

For more advanced protection, you can take a look at the blog post by the authors of the Signal app, where they describe technical details on how they protect their contact discovery process.