iosdesign-guidelines

Is it OK to request Calendar and push notifications access at app start-up in iOS?


I my app I need both Calendar and notifications access. I know this is not the best approach to ask user to accept a bunch of requests on the app's first start, but currently it is not possible to rethink app design. So my question on this stage is - will App Store approve my app if I do these two request one by one on app start? Or will I break some critical Apple guidelines?

Update

Found https://developer.apple.com/ios/human-interface-guidelines/app-architecture/requesting-permission/

It is not clear if my app can be rejected if I make 2 requests at launch though.


Solution

  • SO isn't a great forum for this, as you won't get an authoritative answer from Apple's app review team on what will/won't get you rejected — just speculation and anecdotal experiences from other developers. That said...

    The Human Interface Guidelines you linked are how to make a "good" app that gets you good reviews, design awards, the adulation of your peers, etc. App Review Guidelines are how to not make a "bad" app that gets rejected from the store. Failing the former doesn't necessarily fail the latter.

    There are basically three ways to handle privacy/notification permissions in an app:

    1. Call the system APIs that lead to permissions prompts opportunistically during app startup. (Either conditionally on your first startup, or universally, relying on the OS to make sure that it only asks once.)

      This can be jarring to users — it might not be clear why an app is requesting permission for this or that, and they might get several permission prompts in a row (if the app needs camera and notifications and contacts and whatever else.)

    2. Call permission-related APIs only as needed; e.g. if you have a social media app where users post text and sometimes use the camera to post pictures/video, don't prompt for camera permission until the user tries the camera for the first time. (Most permission-requiring APIs give you two ways to handle this: either you can explicitly check for / request permission, or you can just start using the API and the system will show the permissions alert automatically.)

      This makes it clearer to the user exactly what the permission is needed for, but still interrupts their workflow. And it's not always feasible for cases where the permission is for something the app does without user action (like notifications).

    3. If you have some sort of on-boarding intro/tour when your app first launches, ask for permission then, one step at a time. For example, a learning app's first-launch experience might have the user swipe through several screens explaining features, one of which is "do you want notifications reminding you to study?", and another is "do you want to use the camera for creating your own flashcards?".

      This helps avoid the "pile of unexpected prompts" problem from #1, but it also keeps the user from getting into your app right away.

    There are trade-offs to all of these (and to other variations you might sometimes see), so think about the user's perspective and pick what seems best for your app.