5.6Apple App Store

Guideline 5.6: Developer Code of Conduct

A Guideline 5.6 citation is different from the rest of the rejection list. Other guidelines are about a build. This one is about you, and the stated consequence is removal from the Apple Developer Program rather than a resubmission.

Read the message before replying. A 5.6 on a single build is usually fixable in one submission. A 5.6 about your account is a different conversation, in a different place.

How it is usually worded

The header arrives as Guideline 5.6 - Legal - Developer Code of Conduct, sometimes with a subsection, and the body tends to be one of:

  • "Your app includes a custom prompt asking users to rate or review the app."
  • "We noticed activity associated with your account that appears intended to manipulate ratings, reviews or App Store chart position."
  • "Your app or developer account has been associated with repeated violations of the App Store Review Guidelines."

Account-level notices sometimes arrive by email rather than through Resolution Center, naming an appeal route. If yours did, use that route, not the build thread.

What it actually means

The guideline says developers are held to a high standard, asks you to treat customers with respect, and states that attempting to cheat the system, including by manipulating reviews, chart rankings or App Store discovery, can end in removal from the Apple Developer Program.

There are subsections, and knowing which one you are in tells you what to fix:

  • Ratings and Reviews. How you solicit ratings, and any attempt to inflate or suppress them.
  • Developer Identity. Whether the entity on the account really operates the app.
  • Discovery Fraud. Manipulating search results, keyword abuse, install farms, chart gaming.

Why it triggers

  • A custom review prompt. Your own dialog asking "Enjoying the app?" and pushing happy users to the store while routing unhappy ones to support. That funnel is exactly what the rule targets, and reviewers meet it in normal use.
  • Incentivised or gated reviews. Coins, credits, an unlock, a giveaway entry or a discount in return for rating, including "rate us to remove ads", and anything that will not work until you review it.
  • Bought reviews or installs. Review farms and install services. Assume Apple sees patterns you cannot.
  • Keyword abuse in metadata. Competitor names, unrelated high-volume terms, a keyword-stuffed subtitle. That is discovery manipulation, not clever ASO.
  • Multiple accounts to work around a removal. Resubmitting a rejected app under a second entity is treated as the same actor, and converts a build problem into an account problem.

How to fix it, in order

  1. Work out whether the notice is about the build or the account. Different remedy, different channel. Do not answer an account notice with a code change and hope.
  2. Remove every custom review prompt. Delete the dialog, the funnel, and any "rate us" button that constructs an App Store URL. Use AppStore.requestReview in SwiftUI, or SKStoreReviewController.requestReview on older APIs, and nothing else.
  3. Ask rarely, and at a good moment. The system permits a limited number of prompts per year, on the order of three in a 365-day period, and silently ignores the rest. Trigger it after a success, never on launch.
  4. Strip every incentive. No reward, unlock, entry or discount tied to a rating. Search your code for itms-apps, write-review and action=write-review, which is where manual store links hide.
  5. End any paid review or install arrangement immediately, including anything an agency runs for you. You are answerable for your contractors.
  6. Clean the metadata. Remove competitor names and unrelated keywords from the title, subtitle and keyword field, in every localisation.
  7. Consolidate accounts, and answer your support queue. Publish a working contact address and clear the backlog: supporting what you sell is genuinely part of the rule.
  8. Fix the pattern, not the build, on a repeat-violation notice. The reviewer is describing a history, so the reply has to describe a change of process.

What to send back

Where the citation is about a build, name the mechanism you removed:

Thank you for the review. We have removed the custom rating prompt entirely. The screen that asked "Enjoying the app?" and directed users to the App Store no longer exists, and the manual write-review URL has been deleted from the codebase. Ratings are now requested only through SKStoreReviewController, at most once after a completed export, and nothing is rewarded, unlocked or gated in exchange for a rating.

Where it is about metadata, the same shape works: name the localisations you cleaned, and state plainly that you have no arrangement with any service supplying ratings, reviews or installs.

Where it is account level, the reply is facts plus a remedy, filed through the route Apple named:

Thank you for the notice. We take it seriously and want to resolve it. We have ended our engagement with the marketing agency that ran our user acquisition, as we cannot verify the source of the installs it delivered; we have removed the custom rating prompt from all three of our apps; and we have consolidated our submissions under one developer account. We would welcome any detail you can share about the activity identified, so we can confirm it has stopped rather than guess.

Be honest there: if something happened, saying so and describing what changed is the stronger position.

And we will not pretend to know the outcome. Apple does reinstate developers who fix the underlying behaviour, it also declines to, and nobody outside Apple can tell you which you will get.

When it is really a different guideline

  • Hidden features found once, without a pattern, is 2.3.1.
  • An app copying another developer's is 4.1; spammy duplicates from one account is 4.3.

The protection is a habit rather than a tool: no rating prompt you wrote yourself, no keyword you cannot defend as describing your own app, one account, and a support address someone reads. AppSubmit keeps your metadata history, so you can see which keywords were live for which release when a question like this arrives.

Source: Apple, App Store Review Guidelines, 5.6 (https://developer.apple.com/app-store/review/guidelines/#developer-code-of-conduct)

Related: apple-guideline-4-1-copycats, apple-guideline-4-3-a-design-spam, apple-guideline-2-3-1-hidden-features

Read next

Last reviewed 2026-08-17. Apple and Google change their rules without notice, so check anything decision-critical against their live documentation.