Is a custom pre-permission screen allowed at all?

Yes. Apple's Human Interface Guidelines say you can show a custom screen before the system alert if you need to give additional details. The conditions are that it has a single button, labelled with a term like Continue or Next, that the button opens the system alert, and that nothing on the screen imitates the alert or draws attention to its Allow button.

Our button said Enable, not Allow. Does the same rule apply?

In practice, yes. Apple's guidance says not to use Allow or similar terms, because people do not allow anything on a pre-alert screen. Enable, Grant, Turn on and Give access all describe granting the permission, so they carry the same risk. Use Continue or Next.

How long did it take to get approved after the fix?

For Cuefold, we replied to App Review and resubmitted at 00:14 UTC on 16 October 2026 and the app was approved around 03:00 UTC the same morning, about three hours later. Resubmissions after a reply tend to be quick in our experience, but Apple does not promise a time.

Should we appeal a 5.1.1(iv) rejection?

Only if your screen already follows the guidance: one Continue or Next button, no way to skip the alert, nothing that looks like the alert. If it does not, appealing will cost you days and you will still have to change it. Fix the screen in every language, reply to App Review explaining the change and resubmit.

Can we avoid the problem by not showing a custom screen?

Yes, and for a camera app it is often the simplest answer. If the button that starts the feature leads straight to the system alert, there is no pre-permission screen for 5.1.1(iv) to apply to. Put your explanation in the purpose string instead, which is the text the system alert shows.

Rejected under Guideline 5.1.1(iv)? What Apple means and how we fixed it

The guideline, the Human Interface Guidelines detail behind it, the one-word mistake that got our own app rejected, and the steps to resubmit.

By our team. Published 27 October 2026. 4 sources.

A rejection under guideline 5.1.1(iv) usually arrives with a short message: your app "attempts to manipulate, trick, or force people to consent" to data access. It sounds like an accusation, and most teams who receive it were not trying to trick anyone. We know, because it happened to us. In October 2026 Apple rejected our own iOS app, Cuefold, under exactly this clause, and the cause was one word on one button.

This guide explains what the guideline actually covers, why the wording of a permission screen matters so much to App Review, what we changed to get approved the next morning, and the steps to take if the same message has just landed in your inbox.

What guideline 5.1.1(iv) says

The guideline itself is short. Apps "must respect the user's permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access". Apple gives an example: an app that posts photos to a social network must not also demand microphone access before letting someone upload a photo. It adds that where possible you should "provide alternative solutions for users who don't grant consent", such as letting someone type an address if they decline to share their location ^[1].

Read literally, that covers three different mistakes:

Forcing. Blocking a feature until someone grants a permission that the feature does not need.
Tricking. Presenting a screen that looks like, or stands in for, the system's own permission alert.
Unnecessary access. Asking for data the app has no clear use for.

Most 5.1.1(iv) rejections we hear about fall into the second category, and the detail of what counts as tricking lives not in the App Review Guidelines but in Apple's Human Interface Guidelines on privacy.

The detail is in the Human Interface Guidelines

iOS shows a standard alert when an app first asks for the camera, microphone, location, photos or other protected data. That alert displays your purpose string, the one or two sentences you write in the app's Info.plist, between the app name and the Allow and Don't Allow buttons ^[2].

Apple lets you show your own screen before that alert if it is "essential to provide additional details" ^[2]. Many apps do this. It is a chance to explain, in your own words and design, why you need the camera before the system asks. But Apple's guidance on how that screen may look is precise:

People "can feel manipulated when a custom screen or window also includes a button that doesn't open the alert", because it diverts them from making their choice ^[2].
"Another type of manipulation is using a term like 'Allow' to title the custom screen's button" ^[2].
"Use a term like 'Continue' or 'Next' to title the single button in your custom screen or window, clarifying that its action is to open the system alert" ^[2].
"Don't include additional actions in your custom screen or window, unless needed to obtain a legal consent" ^[2].
"Don't create a button title that uses 'Allow' or similar terms, because people don't allow anything in a pre-alert screen" ^[2].
"Don't add a visual cue that draws people's attention to the system alert's Allow buttons" ^[2].

The logic is simple once you see it. Only the system alert grants permission. If your button says "Allow", a person may feel they have already agreed before the real question appears, and then tap the system's Allow button without reading it. Apple treats that as manipulation whether or not you intended it.

What happened to us

We build and publish our own apps, so we go through App Review like any client. Cuefold is a teleprompter camera for iPhone and iPad, built in native Swift 6 and SwiftUI, with on-device speech recognition and StoreKit 2 subscriptions. The first time you open the record screen, it needs the camera and the microphone.

We followed good practice. Before iOS showed its two system alerts, Cuefold showed a short screen saying that it needs the camera and microphone to record you, and that nothing leaves the device. One button at the bottom of that screen read "Allow camera and microphone".

The timeline, from our App Store Connect record:

8 October 2026, 02:03 UTC. We submitted version 1.0 for review.
8 October. Apple replied with an "Information Needed" message under guideline 2.1, App Completeness, as it often does with a new developer account and a hardware-dependent app. We recorded the app running on a device, attached the recording to the submission and explained how to reach every feature, including the paywall.
11 October, 00:18 UTC. We resubmitted with the recording attached.
15 October. Rejected under guideline 5.1.1(iv). The reviewer's screenshot showed our pre-permission screen and its "Allow camera and microphone" button.
15 October, 23:29 UTC. We committed the fix: the button now reads "Continue".
16 October, 00:14 UTC. We replied to App Review explaining the change and resubmitted build 19.
16 October, about 03:00 UTC. Version 1.0 approved and released.

The whole second round, from reading the rejection to approval, took under a day, and the review itself took about three hours. Our first, honest reaction to the rejection was that the reviewer had misread a reasonable screen. Then we read the HIG page quoted above and saw that it describes our button almost word for word. The reviewer was right.

The fix, and the two things we nearly got wrong

The change itself was one string. Two details mattered more than the string.

Every language, not just English. Cuefold's 1.0 build was English only, but we were already preparing 1.0.1 with eight more languages, and the "Allow" wording had been translated into every one of them. We changed all of them the same night, on both release branches. Had we fixed English alone, the next update would have been rejected again for the same reason in Spanish, French, German, Japanese, Korean, Portuguese or Chinese.

Check the whole app for the same pattern. We looked for every other pre-permission screen. Cuefold asks for Photos access when you save a video and for speech recognition when you turn on script following; neither had a custom screen in front of the system alert, so there was nothing else to change. In a later app we skipped the custom screen entirely for the camera. A button that starts a feature ("Start camera") leads straight to the system alert, so 5.1.1(iv) has nothing to attach to.

Since then we have a rule for every app we build or take over: a pre-permission screen has one button, it says "Continue" or "Next", and it opens the system alert and nothing else.

How to fix your own 5.1.1(iv) rejection

Read the message and the screenshot. App Review nearly always attaches a screenshot of the screen it objected to. Identify which permission and which screen it shows.
Match the screen against the HIG checklist above. Look for the word "Allow", "Enable", "Grant" or "Turn on" on your button; a second button that skips the alert; an arrow, animation or highlight pointing at where the system's Allow button will appear; or a screen that imitates the system alert.
Fix the pattern everywhere, in every language. Search your string files for every permission pre-prompt. The reviewer only has to find one instance to reject you again.
Check that the permission is necessary at that moment. If a feature works without the data, do not block it. Apple's own example is an app that demands the microphone before letting someone upload a photo ^[1]. Ask only when the feature that needs the data is about to run.
Offer a path for people who say no. If someone declines the camera in a camera app there is little to offer, but for location, contacts or notifications there usually is: manual entry, a reduced mode, or simply carrying on without.
Rewrite the purpose strings while you are there. They are the only words that appear in the system alert, and Apple expects them to describe clearly and completely how the data will be used ^[3]. Cuefold's microphone string, for example, says that it records audio with your video and listens on the device to follow your script.
Reply to App Review, then resubmit. In App Store Connect, open the rejection message, describe what you changed in two or three sentences, and resubmit the new build. In our case the reply and the resubmission went in at 00:14 UTC and the approval came around 03:00.
Appeal only if the screen genuinely complies. If your button already says "Continue" and there is no second action, you can appeal to the App Review Board. Apple asks you to give specific reasons why the app complies, to file one appeal per rejected submission, and to answer any outstanding information requests first ^[3].

Mistakes we see in other apps

Beyond the "Allow" button, these patterns tend to draw the same rejection:

A "Not now" button that quietly sets a flag so the alert is never shown. The person never gets the real choice. Apple calls out buttons that do not open the alert ^[2].
Asking for everything on first launch. A wall of camera, microphone, photos, notifications and location requests before the person has done anything. Each one should come in context, when the feature needs it.
Explaining the data in marketing language. "Unlock the full experience" tells nobody what will be collected. Say what the app does with the data.
Requiring notifications or tracking before sign-up. Tracking has its own clause, 5.1.2, and its own system prompt, and the same no-custom-Allow rule applies to any screen you show before it ^[2].

Why this matters beyond the rejection

Apple reviewed about 9.1 million submissions in 2025 and rejected around 2.1 million of them; privacy sits inside the Legal section, which accounted for 495,673 of those rejections ^[4]. A permission screen is one of the first things a reviewer sees in a camera, health or social app, so it is checked on every submission, not only the first.

A clean pre-permission flow also converts better. People who understand why an app wants the camera are more likely to tap Allow on the real alert, and a person who declines once has to go to Settings to change their mind.

If your developer is no longer around to make the change, we can take over the app, fix the permission flow and resubmit it, then keep it passing review on our App care plan.

A checklist before you resubmit

Every pre-permission screen has one button, labelled "Continue" or "Next".
No button on that screen skips or suppresses the system alert.
No arrows, highlights or animations point at where the system's Allow button will appear.
The screen does not look like the system alert.
The wording is fixed in every language the app ships in.
Each permission is requested when the feature that needs it is about to run, not on first launch.
Every purpose string says plainly what the app does with the data.
Features that can work without the data still work when it is declined.
Your reply to App Review says what changed and where.

Questions we get asked

Is a custom pre-permission screen allowed at all?: Yes. Apple's Human Interface Guidelines say you can show a custom screen before the system alert if you need to give additional details. The conditions are that it has a single button, labelled with a term like Continue or Next, that the button opens the system alert, and that nothing on the screen imitates the alert or draws attention to its Allow button.
Our button said Enable, not Allow. Does the same rule apply?: In practice, yes. Apple's guidance says not to use Allow or similar terms, because people do not allow anything on a pre-alert screen. Enable, Grant, Turn on and Give access all describe granting the permission, so they carry the same risk. Use Continue or Next.
How long did it take to get approved after the fix?: For Cuefold, we replied to App Review and resubmitted at 00:14 UTC on 16 October 2026 and the app was approved around 03:00 UTC the same morning, about three hours later. Resubmissions after a reply tend to be quick in our experience, but Apple does not promise a time.
Should we appeal a 5.1.1(iv) rejection?: Only if your screen already follows the guidance: one Continue or Next button, no way to skip the alert, nothing that looks like the alert. If it does not, appealing will cost you days and you will still have to change it. Fix the screen in every language, reply to App Review explaining the change and resubmit.
Can we avoid the problem by not showing a custom screen?: Yes, and for a camera app it is often the simplest answer. If the button that starts the feature leads straight to the system alert, there is no pre-permission screen for 5.1.1(iv) to apply to. Put your explanation in the purpose string instead, which is the text the system alert shows.

Sources

Checked on 27 October 2026.

1.Apple Developer, "App Review Guidelines", 5.1.1(iv): https://developer.apple.com/app-store/review/guidelines/
2.Apple Developer, "Human Interface Guidelines: Privacy" (requesting permission, pre-alert screens): https://developer.apple.com/design/human-interface-guidelines/privacy
3.Apple Developer, "App Review" (purpose strings, appeals, expedited review): https://developer.apple.com/distribute/app-review/
4.Apple, "2025 App Store Transparency Report": https://www.apple.com/legal/app-store/transparency/2025/