App Store Guideline 5.1.1 Rejection: How to Fix Data Collection and Purpose Strings

Don't panic. This kind of rejection rarely means rebuilding your app. In most cases the fix is a few strings, one sign-up screen, or an SDK setting. Still, a calm order of work beats rushing out a new build. Follow these steps:

1. Read the full rejection message in App Store Connect and note the sub-clause it cites.
2. Reproduce the screen, permission, or data field it mentions on your own device.
3. Decide whether the problem sits in text, in a user flow, or in a third-party SDK.
4. Make the fix and test the new build on a real device with a clean install.
5. Reply to the message with a short, itemized summary, then submit the new build.

This guide covers Guideline 5.1.1 only. For the wider map of rejection causes, see our article on the most common app rejection reasons.

How should you read the 5.1.1 reference in the rejection message?

Apple names the rule behind every rejection by its number. Section 5.1 covers privacy, and 5.1.1 covers data collection and storage. However, 5.1.1 is not one rule. It is a heading with ten detailed sub-clauses, so if you start fixing before you read the rest of the message, you may change the wrong screen.

The message usually gives you three clues. First, it describes the screen or feature in question. Second, it states the behavior Apple expects. Third, it sometimes includes a screenshot. For example, the reviewer may attach a screenshot of your camera permission prompt and note that the text does not explain the purpose. In that case the problem almost always lives in the purpose string inside Info.plist.

On the other hand, if the message says you ask for personal information the app does not need, the problem sits in a form field or a sign-up flow. The exact wording of these messages can change over time. So focus on the screen it points to rather than the phrasing. Also, save the screenshot, because you will need that evidence when you write your reply.

Which sub-clauses make up Guideline 5.1.1?

In Apple's official App Review Guidelines, 5.1.1 contains ten sub-clauses, numbered (i) through (x). Most rejections we see trace back to four or five of them. The table below sums up the most frequent ones and the typical fix:

In short, once you match the message to one of these rows, the direction of the fix becomes clear.

When might you be unable to fix this rejection alone?

For most teams, fixing a purpose string takes a few hours. Some cases go deeper, though. You may need to redesign the whole sign-up flow, add a guest mode to the data layer, or work out which SDK touches which protected resource. That work needs both product decisions and code changes.

If another team built the app and you have no control over the source code or the build pipeline, the rejection loop can drag on. In that situation, an experienced mobile app development team can review the flow and help you avoid a second rejection under the same clause. That said, we suggest you try the checks in the sections below first, because many of these problems live at the text level.

Apple also states in its guidelines that review takes longer for apps that keep getting rejected for the same violation. Therefore, a complete first fix is the cheapest path in terms of time.

What is a permission purpose string?

A purpose string, also called a usage description, is the text the system shows in the permission alert when your app asks for a protected resource such as the camera, location, microphone, or photos. You define it in Info.plist as the value of the matching key. For example, the camera uses the NSCameraUsageDescription key.

Apple's guide to purpose strings explains that the operating system blocks access to these resources until the user grants permission. It also explains that the purpose string lets people make an informed decision. In other words, this text is more than a technical requirement. It is the first sentence of trust between your app and the user.

Sub-clause 5.1.1(ii) puts it plainly: your purpose strings must clearly and completely describe your use of the data. Reviewers open each permission alert one by one and check whether the text says what the app wants and why. That is why a line such as "We need your location" can be enough for a rejection, since it only repeats the resource name.

Why do purpose strings trigger an App Store data collection rejection?

Apple's guide lists three common traits of weak purpose strings. The first is repeating the resource name without explaining its use. The second is vague benefits or passive phrasing that hides who can access the data. Finally, Apple warns against marketing copy or a long feature list.

• Resource name only: "To use the camera."
• Vague benefit: "Your data helps us give you a better experience."
• Marketing copy: "Enjoy our amazing features!"
• A purpose the app never uses: the text mentions scanning receipts, but the camera opens somewhere else.

The last point matters most, because reviewers compare the text with the real behavior. For example, if your text says "to take a profile photo" but the camera prompt appears on first launch, the text and the context do not match. Also, copying the same string across several resources causes trouble. Apple asks for a separate purpose string for every protected resource.

How do you write a purpose string that passes review?

According to Apple's guide, a good purpose string is one brief, complete sentence. Apple asks for active voice and sentence case, with a period at the end. It should also name the feature or outcome the data makes possible and give a concrete example. Put simply, a reader should finish the sentence knowing what happens if they tap Allow.

A simple formula helps: who uses which data for which feature? The examples below follow it:

• Location: "The app uses your location to show the nearest branch on the map and give you directions."
• Camera: "The app uses the camera to scan the QR code on your bill and fill in the payment screen."
• Microphone: "The app uses the microphone to record voice notes and attach them to your entries."
• Contacts: "The app accesses your contacts so you can pick the person you want to invite."

These follow the same logic as Apple's own example about choosing a route and giving turn-by-turn directions. After you write each string, ask yourself one question. Can a reader tell whether the data leaves the app? If you share it for ads or analytics, say so openly.

How do you localize purpose strings in a multilingual app?

If your app supports several languages, Apple's guide says you must provide localized purpose strings. In practice, leaving a single English value in Info.plist and showing an English permission alert inside a German or Turkish interface creates a poor experience and a real rejection risk.

In practice, you keep a separate InfoPlist.strings file, or whatever localization file your project uses, for each language. Then you define the translation for every key there. Next, switch the device language one at a time and open every permission alert to confirm the right text appears. Apple also recommends that you set the app to each localization and test the permission request in each one.

When you translate, keep the same level of detail instead of translating word for word. For instance, if the English string mentions "the nearest branch," the German and Turkish versions should name the same feature. Likewise, broken machine translations may not meet the "clearly and completely" standard in the eyes of a reviewer.

How do third-party SDKs cause Guideline 5.1.1 rejections?

Many teams feel surprised when they receive a rejection for a permission their own code never uses. Apple's guide leaves no doubt here: you are responsible for everything in your app, including SDKs, libraries, and other third-party code. An analytics, ad, or maps SDK can reference a protected API without you realizing it.

Apple describes two paths. If your app has a valid reason to access the resource, you define a purpose string in Info.plist that describes your specific use case. If it does not, you remove references to those APIs from your binary. As a result, "the SDK asks for it, but we don't use it" is not an answer reviewers accept.

1. List every dependency in the project.
2. Check each one's documentation for the protected resources it can access.
3. Disable or remove the modules you don't use.
4. Write a purpose string that describes your own feature for any access that remains.

You also need to show the data your SDKs collect accurately in your App Store privacy details. We cover that in our guide on how to prepare App Store privacy labels.

Why is asking for unnecessary personal data a rejection reason?

Sub-clause 5.1.1(v) says apps may not require users to enter personal information to function, unless it relates directly to the core functionality or the law requires it. For example, a calculator app that asks for a birth date and phone number on its first screen runs straight into this rule.

Sub-clause (x), on the other hand, allows apps to request basic contact information such as a name and email address. It comes with three conditions. The request must stay optional for the user. Features must not depend on providing the information. The app must also follow every other provision, including the limits on collecting data from kids. So you can add an email field for a newsletter, but you cannot say "enter your email to continue."

When you audit your forms, ask one question for each field. Does the feature still work without it? If the answer is yes, make the field optional or remove it. For instance, a delivery app needs an address, but the same app should not require a job title or gender. Users in the EU also have rights under data protection law; our guide to GDPR compliance covers the basics. This article is not legal advice.

How do you remove a forced login from features that need no account?

The first sentence of 5.1.1(v) reads like this in practice: if your app doesn't include significant account-based features, let people use it without a login. This rejection shows up often in catalog, menu, content, and information apps.

Take a restaurant app as an example scenario. Viewing the menu, checking branch hours, and looking at prices need no account. Placing an order, viewing order history, or collecting points may need one. So the right flow lets people in as guests and asks for a login only when they reach a step that truly needs an account.

1. Sort every screen into two groups: works without an account, or needs an account.
2. Remove the mandatory login at launch, or make it easy to skip.
3. Show the login or sign-up sheet at the moment a user starts an account-based action.
4. Store guest data locally and move it over once the user signs up.

Also, if your app supports account creation, the same clause requires in-app account deletion. We explain that separate but closely related requirement in our article on Apple's mandatory account deletion rule.

What does Guideline 5.1.1 say about social network login?

Sub-clause 5.1.1(v) includes a separate rule for social networks. If your core app functionality does not relate to a specific social network, you must provide access without a login or through another mechanism. Apple does not count pulling basic profile information, sharing to the network, or inviting friends as core functionality.

The clause also sets two technical conditions. First, the app needs a way to revoke social network credentials and disable data access between the app and the network from inside the app. Second, the app may not store social network credentials or tokens off the device. It may only use them to connect directly to the network while the app is in use.

Therefore, an app that offers only a social login carries a risk if its core feature has nothing to do with that network. The usual fix adds an alternative path, such as a guest mode or email login, plus a disconnect option in settings. That way you meet the rule and keep users who don't have a social account.

Should you use the system picker instead of full access?

Sub-clause 5.1.1(iii), on data minimization, asks apps to request access only to data relevant to their core functionality and to collect only what a task requires. It also recommends that, where possible, you use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.

In practice, if a user wants to upload a profile photo, you don't need access to the whole photo library. The system photo picker hands your app only the image the user selects, and your app never sees the rest. As a result, you skip a permission alert entirely and remove the reviewer's question of why the app needs the full library.

The same logic applies to contacts. Instead of reading the whole address book to send one invite, the system interface that lets a user pick a single contact is usually enough. In short, cutting the number of permissions is the strongest fix under 5.1.1, because a permission you never request needs no purpose string at all.

What alternative should you offer users who decline a permission?

Sub-clause 5.1.1(iv) asks apps to respect the user's permission settings and not to manipulate, trick, or force people into unnecessary data access. Apple gives two examples. An app that posts photos to a social network must not require microphone access before a user can upload photos. And if a user declines to share location, the app should offer manual address entry.

This clause targets flows that say "no permission, no app." For example, showing an empty screen and a "turn this on in Settings" notice when someone declines location is risky. Instead, add alternatives such as a city or postcode search, or let people drop a pin on the map by hand.

• Location declined: manual address or city entry.
• Camera declined: pick from the photo library or type the code by hand.
• Notifications declined: an in-app inbox.
• Contacts declined: manual phone number entry.

Also, any explainer screen you show before the system alert should not pressure people into tapping Allow. Ad tracking permission follows a separate framework, which we cover in our article on App Tracking Transparency (ATT).

What must your privacy policy link cover?

Under 5.1.1(i), every app must include a link to its privacy policy in the App Store Connect metadata field and inside the app in an easily accessible place. The policy itself must clearly and explicitly cover three areas.

• What data the app collects, how it collects that data, and every use of it.
• Confirmation that third parties such as analytics tools, ad networks, and SDKs will provide the same or equal protection.
• Data retention and deletion policies, plus how a user can revoke consent or request deletion.

A mistake we often see is linking a generic policy that someone wrote for the website. Such a text may never mention why the app uses the camera or location. So update the policy to match the app's real data flow, and leave no conflict between your purpose strings, your privacy labels, and your policy. When the three documents back each other up, the reviewer's job gets easier too.

What do the consent withdrawal and paid feature rules say?

Sub-clause 5.1.1(ii) says apps that collect user or usage data must secure consent, even if the data counts as anonymous at the time of collection. The clause adds two more conditions. Paid functionality must not depend on granting access to this data. And the app must give people an easily accessible and understandable way to withdraw consent.

For instance, an app that opens its premium tier only to users who share location or contacts breaks this clause directly. Similarly, if a user must email support to withdraw consent for analytics, that causes trouble. A clear toggle in the settings screen is the simplest way to meet the requirement.

The clause also says apps that collect data for a legitimate interest without consent, relying on the EU General Data Protection Regulation (GDPR) or a similar law, must comply with all terms of that law. At this point you need a legal assessment. This article is not legal advice, and we recommend you talk to a qualified lawyer.

How do you write a Resolution Center reply?

What many developers still call the Resolution Center is now the App Review messaging area inside App Store Connect. According to Apple's help page on replying to App Review messages, you select your app, click the link at the top of the page that flags unresolved issues, click Resolve next to the submission, and then click Reply to App Review. You can attach screenshots and supporting documents.

Apple's own guidance also says how to phrase the reply. Be specific about what you're asking, such as the exact feature, guideline, or step. If you believe App Review misunderstood the app, add information about its concept and intended functionality. So a strong 5.1.1 reply is not a long defense. It is a short change report.

1. Name the cited sub-clause.
2. State in one sentence what you changed for each issue.
3. Quote the new purpose strings or describe the form change word for word.
4. Attach a screenshot that shows the change.
5. Update demo account details in App Review Information if the reviewer needs them.

Note that Apple asks you not to use this reply field to appeal a rejection. Appeals have their own form.

Should you reply, resubmit, or appeal?

You have three paths after a 5.1.1 rejection, and the right one depends on whether the issue truly exists. If it does, for example a vague purpose string or a forced login, the fastest path is to fix it, submit a new build, and send a short reply that explains the change.

On the other hand, if the reviewer misread a feature, for instance by missing that location data never leaves the device, you first explain it through App Store Connect. Apple's guide to appeals to the App Review Board also asks you to reply to the rejection message and clarify the issue before you file an appeal. If that clarification does not resolve it, you move on to the appeal form.

In an appeal, Apple expects you to cite the specific guideline and explain point by point how your app meets it. You also submit only one appeal per rejected app. If the rejection cites several guidelines, you address all of them in that single appeal. And if you already fixed the issue and resubmitted, you don't appeal at all. The guide states clearly that a complete appeal does not guarantee a reversal. We make no promise of approval either; choosing the right path only shortens the process.

Which mistakes bring the App Store data collection rejection back?

A second App Store data collection rejection under the same clause usually comes from a half-finished fix. These are the mistakes we see most often:

• Fixing only the permission the message named and leaving other vague purpose strings untouched.
• Fixing the strings in the base language and forgetting the other localization files.
• Adding a Skip button to the launch login, then asking for a login again on the very next screen.
• Leaving an unused SDK module in the code.
• Updating the privacy policy but never adding the in-app link.

So don't limit the fix to the screen in the message. Instead, sweep the whole app with the same eye. If the reviewer finds the same issue on another screen during the next submission, you get a fresh 5.1.1 rejection. Also, delete the app and test with a clean install before you submit, because permissions you granted earlier hide the alerts from you.

Rejections for missing or half-working features rest on a different rule. We cover them in our article on the Guideline 2.1 app completeness rejection.

What does a similar data issue mean on Google Play?

If you publish on both stores, it makes sense to carry your 5.1.1 fix over to the Android version too. Google Play has its own policy framework and processes, so Apple's clause numbers don't apply there. Still, unnecessary permissions and opaque data collection can cause problems on that side as well.

We explain the steps for a Play app taken down over a policy violation in our article on Google Play app removal appeals. For the closed testing requirement on new developer accounts, see our guide to the Google Play closed testing requirement. If you face an account-level termination, our article on a terminated Google Play developer account fits better.

One important warning: on either store, uploading the same app under a new account or through related accounts to get around a rejection or a ban does not solve anything. In fact, that route can make the policy violation worse and lead to account-level action. The right path is always to fix the issue and resubmit through the official channel.

When should you get help with a Guideline 5.1.1 fix?

Purpose string and form field fixes are usually work your own team can handle. However, outside eyes save time if the rejection repeats two or three times, if the message targets your entire sign-up flow, or if you can't tell which SDK triggers which permission. The same applies if you have no access to the source code or lost contact with the previous developer.

At Talha Aslan and team, we start this kind of work by mapping the rejection message and the app's permission footprint. Then we plan the code and text changes in one pass. That said, no team can guarantee Apple's approval, and we want to say that plainly; App Review always makes the final call. If you want to build your app's data flow right from the start, or rework an existing app, take a look at how our custom mobile app development process works.

The most lasting fix for an App Store data collection rejection is to make permission and data decisions at the design stage. That way, every new feature starts with the same question: do we really need this data?

Which final checks should you run before you resubmit?

Before you submit the new build, tick off the list below one item at a time. We built it to cover every Guideline 5.1.1 sub-clause:

• Every protected resource has its own specific, one-sentence purpose string.
• Purpose strings exist in every supported language, and you tested them on a device.
• You removed unused SDK modules and API references.
• Content that needs no account opens in guest mode.
• Fields such as name and email stay optional, and no feature depends on them.
• Users who decline a permission see an alternative.
• The privacy policy is current and reachable from inside the app.
• A clear option to withdraw consent sits in the settings screen.

Once the list is complete, delete and reinstall the app, then open every permission alert in turn. After that, write your short reply to the rejection message and submit the new build. Following this order noticeably lowers the chance of a second rejection under the same clause.