0 Replies
      Latest reply on May 20, 2020 10:13 PM by impnp
      impnp Level 1 Level 1 (0 points)

        Hello! We are stuck on an apparent Apple HIG and iOS technical contradiction. We could use some official guidance on what to do and to avoid having our app rejected.

         

        We are developing an augmented reality app that naturally requires Camera permissions to function. The Apple Human Interface Guidlines on Requesting Permission states "Use the system-provided alert. You can customize text in the standard permission alert, but avoid adding custom prompts that replicate the standard alert’s behavior or appearance." This customized text is called the "purpose message."

         

        When requesting Camera permissions, iOS opens a native alert modal with a system-generated title, the custom purpose message, a "Don't Allow" button, and an "Allow" button. The user cannot exit to the home screen or go to the app switcher; they are stuck in the app until they tap on either option. They can use the device lock button, but resuming the device returns to the app with this blocking, permissions alert.

         

        This AR application is worthless without Camera permissions, so we need to confirm Camera permissions are enabled and prompt the user to grant permission if not enabled. There is no user experience without it.

         

        We see three ways of accomplishing this task:

        1. Repeatedly initiate the system-provided alert, preventing the user from doing anything else on their device until they tap "Allow". This doesn't seem like the right thing to do, and we're guessing you agree.

        2. If they tap "Don't Allow" or launch the app without Camera permissions granted, open our own iOS alert, which resembles the system-provided alert with a single OK button. This regular alert doesn't entangle the device and the app can be exited. When OK is tapped, (a) open the system-provided alert so they can tap "Allow" or (b) redirect the user to iOS Settings > our app's permissions settings to let the user manually enable the Camera permission and let them find their own way back to the app. 2a seems like it could confuse or trap the user every time they're on the system-provided alert like option 1 does. 2b seems like the most appropriate and user-friendly solution, but doesn't use the system-provided alert like the guidelines suggest we should.

        3. Plop the user onto a static screen that tells the user they need to enable the camera settings to use the app with an OK button. This OK button can then do the same as 2a or 2b above (so think 3a and 3b here). This may follow the HIG guideline by the letter of the law, but this option results in an odd user experience, is near identical to using our own alert or the system-provided one, seems to also break the spirit of guidelines, and results in excessive functionality and code in our app.

         

        Recommendations here?

         

        Thanks in advance!