Unlock content for disabled persons only

>we want to unlock it to disabled persons only. All other functionalities, such as live location tracking or departure times per stop are available to every user.

That would violate the first bullet of 3.1.1 in the Guidelines. This guideline is mostly aimed at attempts to get around using IAP to avoid Apple's 30% fee. If you are not doing that....so read the 'good news' below. But if you are charging someone, see the 'Good News' below.

> Is there any implementation design, that matches the apple coding guidelines to pass the review 100%?

The 'bad news' is that there is nothing that can guarantee passing the review, let alone 100%.

The 'good news' is that although you are violating that guideline you are doing it for a reason for which the guideline is not intended so the guideline might be used by App Review as a guide rather than a barrier. I'd recommend including a note to App Review that indicates you will be requiring authentication of disabilities through an approved agency and are implementing that authentication through an email link that unlocks limited features in the app for diasbled users. Also indicate that you will not be charging the user or the authorizating agency.

More Good News - although not 100%, you could sell memberships to use these features. For example, you could sell to the authorizing agency (e.g. the bus service) a package of 100 memberships and allow that authorizing agency to distribute that membership through an email link or otherwise. (See 'gifting' under 3.1.1 bullet 5) In fact, if you were planning on charging anyone, this may be your only solution.

>E.g.: Can we offer a regular e-mail sign up form where the user can optionally provide her/his Disablility ID, which the Public Transport Association can approve?

Sounds like that process would go like this:

User opens the PTA's app, fills out a form, then sends that form via email from the app direct to the PTA. The PTA receives that email, and approves the disabled user's request to send and receive PTA notifications, presumably also via email, w/the assumption that the feature if disallowed is simply blocked on the backend, and by 'content' you meant location-aware notifications.

Asking permission for notifications is common enough - see

UserNotifications

&

https://developer.apple.com/documentation/usernotifications/asking_permission_to_use_notifications

As is asking permission to use location services, w/the dev deciding if that means always, or sometimes/session=based - see:

Choosing the Authorization Level for Location Services

> pass the review 100%?

About that...there are no pre-reviews, App Review isn't here and no one can promise what they will/won't approve reject. Be sure to reference ASRGs Section 5 Legal/Privacy.

Good luck.

My comment above refers to your feature 'unlocking code within the app'. On rereading your post it is unclear you want to do that. You wrote:

>The corresponding driver is getting notified to stop at this stop and help the person to enter the bus.

That 'notification' could be sent outside of your app or triggered by an entity within your app based on their information of the status of the person - e.g. the Public Transportation Authority has entered the person's CloudKit.userRecord.recordName into the app and so the app itself triggers a notification. In that case you are not 'unlocking code within the app' and therefore not violating 3.1.1.

Thanks @PBK and @KMT for your answers. I will try to include a not for the App Review and will report what the outcomes are.