Repeated Apple Guideline 3.1.1 findings are the point where an In-App Purchase problem moves off a single app and onto the developer account. A first finding means App Review rejects or removes one app because it sells digital content, features, subscriptions or currencies outside In-App Purchase, or because it steers users to outside purchasing on a storefront where that is not permitted. A second and third finding change how Apple reads you. The App Review Guidelines say an app repeatedly rejected for the same guideline violation will take longer to review, and the Developer Code of Conduct in Guideline 5.6 says a Developer Program account will be terminated for conduct outside that code. Since May 1, 2025, the same purchase button can be allowed on the United States storefront and rejected on every other storefront, which is why repeat cases now start with a storefront map.

We map which storefronts an app ships to before we read the rejection. If you are still on a first finding, our guide to fixing a single Guideline 3.1.1 rejection covers the one-app fix. Everything below is written for developers who have seen the same finding twice, or who have received a notice that mentions the Apple Developer Program.

How Apple Escalates Repeated Guideline 3.1.1 In-App Purchase Findings

The first finding under Guideline 3.1.1 is an app-level event. App Review rejects the build or removes the live app, names the guideline, and waits for a corrected submission. What changes with repetition is the reading Apple gives to the history. One purchase flow outside In-App Purchase can be an oversight. The same flow returning after a fix, or appearing in a second app from the same team, reads as a decision to route around the rule.

The escalation path

1. App-level rejection. A new build is rejected under 3.1.1. Any version already live stays up while you correct the build.
2. App-level removal. A live app is pulled because its purchase flow does not comply on one or more storefronts.
3. Repeat findings and slower review. The same pattern returns in the same app or in a sibling app. Apple states that apps repeatedly rejected for the same guideline take longer to review.
4. Account-level action. A notice refers to the Apple Developer Program License Agreement or to the Developer Code of Conduct, and the account faces termination.

Apple publishes no fixed count of findings that triggers account action. Do not plan around a number of chances. Treat the second finding as the warning, because the guidelines tie termination to conduct, and a repeated pattern is conduct.

What a repeat finding costs before any termination

Slower review is the first price, and most teams underestimate it. Apple’s App Review page says the team typically reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. An account flagged for repeated rejections under one guideline should not plan a launch, a seasonal sale or a security patch around those figures. Approved builds can also take up to 24 hours to appear on every selected storefront. Build both delays into the release calendar after a second finding.

Why repetition reads as intent

A reviewer looking at one rejection sees a flow. A reviewer looking at a history sees a developer who keeps shipping flows that avoid In-App Purchase. When fixes go out one rejection at a time, the same idea tends to come back in a new form. A link moves from the paywall to a settings screen. A web checkout becomes a manage account page. An external store button becomes a promo code field that redeems a key bought on the web. Guideline 3.1.1 names license keys, QR codes and augmented reality markers as mechanisms apps may not use to grant paid functionality, so the promo code version is the same violation with a new label.

The business models where this happens

• SaaS and subscription businesses with web checkout. These companies already run a billing stack on the web and want mobile users on it. Each new attempt to steer users there outside the US storefront counts as another finding.
• Content and course platforms. Granting access in the app to content bought elsewhere is not the problem on its own. The finding comes when the app also promotes or links to that outside purchase on a storefront where steering is barred.
• Games selling currencies. Coins, gems and battle passes bought in an outside store bypass In-App Purchase. Credits bought through In-App Purchase may not expire under 3.1.1, so a currency model that expires balances is a second problem on top of the first.

The same escalation logic shows up in repeated Guideline 4.3 spam findings and in repeat hidden features violations, where Apple also reads a history rather than a single build.

What Apple Guideline 3.1.1, 3.1.1(a) and 3.1.3 Say About Repeat Violations

Three provisions decide most of these cases. Guideline 3.1.1 is the core In-App Purchase rule. Guideline 3.1.1(a) covers links to other purchase methods and the entitlements that permit them. Guideline 3.1.3 lists the apps that may use a purchase method other than In-App Purchase. Read all three on Apple’s App Review Guidelines page before each submission, because Apple revised them on May 1, 2025 and again on October 16, 2026.

The core rule in 3.1.1

If an app grants features or functionality for payment, it must use In-App Purchase. Apple lists subscriptions, in-game currencies, game levels, premium content and a full version upgrade as examples. Several other lines in 3.1.1 catch repeat offenders.

• Apps may not use their own mechanisms to grant paid content, such as license keys, QR codes or cryptocurrency wallets.
• Credits and in-game currencies bought through In-App Purchase may not expire.
• Apps should offer a restore mechanism for restorable In-App Purchase items.
• Digital gift cards, vouchers and coupons redeemable for digital goods may be sold in the app only through In-App Purchase. Physical gift cards mailed to customers may use other payment methods.
• Loot boxes and other randomized paid items must disclose the odds of each item type before purchase.

Guideline 3.1.1 itself does not say how many findings lead to account action. The account consequences sit elsewhere in the same document, which is why a repeat case has to be read across the whole guideline set.

Where the account consequences are written

The introduction to the guidelines says developers who try to trick the review process will have their apps removed and will be expelled from the Apple Developer Program. Guideline 3.1.1(a) adds that an app engaging in misleading marketing, scams or fraud in relation to a link entitlement will be removed from the App Store, and the developer may be removed from the program. Guideline 5.6 states that a Developer Program account will be terminated for conduct outside the Developer Code of Conduct, and that repeated manipulative or misleading behavior leads to removal from the program. A purchase flow that looks one way during review and another way to users falls under all three.

Where purchases may sit outside In-App Purchase

Guideline 3.1.3 names seven categories that may use another purchase method. They are reader apps in 3.1.3(a), multiplatform services in 3.1.3(b), enterprise services in 3.1.3(c), person-to-person services in 3.1.3(d), goods and services outside of the app in 3.1.3(e), free stand-alone apps in 3.1.3(f) and advertising management apps in 3.1.3(g). Apps in these categories still may not encourage users inside the app to buy elsewhere, except on the US storefront and as 3.1.1(a) and 3.1.3(a) allow. Developers may still email their own user base about other purchase methods outside the app. Every exception has conditions, and a flow that relies on one has to meet all of them.

The storefront split since May 1, 2025

On May 1, 2025, Apple updated Guidelines 3.1.1, 3.1.1(a), 3.1.3 and 3.1.3(a) to comply with a United States court decision on buttons, external links and other calls to action. On the US storefront, apps may now include those buttons and links without an entitlement. On every other storefront, apps and their metadata may not include buttons, external links or calls to action that send customers to a purchase method other than In-App Purchase, unless the developer holds a StoreKit External Purchase Link Entitlement valid for that storefront. The October 16, 2026 revision folded the Music Streaming Services Entitlement into the StoreKit External Purchase Link Entitlement bullet and clarified that links may go only to a permitted destination.

This split causes more repeat findings than any other single change. A team adds an external purchase link for US users, as now allowed, and the link ships to every storefront because the feature flag is global. The US build is compliant. Every other storefront build is a 3.1.1 finding. Our guides to US storefront external purchase links and alternative payments on EU storefronts cover each regime in detail.

When an account notice is already open, have our Apple App Store reinstatement team read the storefront map before you reply.

What the EU terms require in numbers

Apple’s page on the DMA and apps in the EU sets out the current figures. Developers who choose alternative payment options must keep that choice for 12 months. Alternative payment transactions must be reported to Apple monthly, within 15 days after the end of each calendar month. The store services commission on out-of-app offers applies to sales made within 7 days of the link tap, at 15% for standard offers and 10% for program participants and subscriptions after their first year. Apple lists a 20% commission for alternative payment processing inside the app and 26% for standard In-App Purchase sales on EU storefronts. A team that misses the 15-day reporting window or switches options inside the 12-month period is creating a new compliance issue while trying to close an old one.

Notices That Signal Account Level Action

Rejection and removal messages arrive in App Store Connect and cite a guideline number. The notices that matter here move the conversation from a build to the account.

Signs the case has moved to the account

• The message cites the Apple Developer Program License Agreement or Guideline 5.6, in addition to 3.1.1.
• It names more than one app, or refers to conduct across your submissions.
• It describes behavior, such as misleading users or manipulating review, rather than one purchase screen.
• It says the account is pending termination and invites a response.
• It confirms that the account has been terminated and the apps removed.

Any one of these means a resubmission will not close the case. A reply that fixes one purchase screen does not answer a question about the account.

What a pending termination response needs

Guideline 5.6 gives the restoration route in plain terms. You may provide a written statement detailing the improvements you plan to make, and if Apple approves the plan and confirms the changes have been made, the account may be restored. That is an improvement plan, not an argument. It answers every point in the notice with a root cause, a change already shipped and proof Apple can confirm in the current builds. It names a payments owner and an audit schedule. Our guide to answering a pending termination notice covers the format line by line.

Options Left After the Apple Developer Program Decision

Once Apple acts on the account, the options narrow, and the right channel depends on the exact status in the notice.

If an app was rejected or removed and you believe it complies

Apple’s help page on appealing to the App Review Board sets the order. First reply to the rejection or removal message in App Store Connect and clarify the issue. File an appeal only if that reply does not resolve it. Submit one appeal per rejected or removed app, and address every cited guideline in that single appeal. One form can cover up to five rejected or removed apps. Apple also says not to appeal after you have already fixed the issue and resubmitted. An appeal on a repeat 3.1.1 case works only when the flow met a written rule, such as a 3.1.3 category or the US storefront allowance, and the reviewer missed it.

If the account is pending termination

A pending termination is the best position left. The same help page says an appeal is appropriate when the account faces termination and you believe it complies with the guidelines and the License Agreement. Cite the specific terms the account was found to violate and explain how the account meets them. If the notice is right, do not argue. Fix every app in the portfolio first, then send the written improvement plan Guideline 5.6 describes, so Apple can confirm the changes against live builds.

If the account is already terminated

Apple’s help page says not to file an App Review Board appeal to reinstate an already terminated account. Use the Contact Us route Apple provides for that request instead, and build the submission around the Guideline 5.6 statement of improvements. It should be one complete package that lists each 3.1.1 finding, the root cause behind the pattern, the corrections in every app and the control now in place. Our guide to a terminated Apple developer account walks through that request.

If a first appeal has been denied

A denied appeal leaves little room, and a second appeal that repeats the first one changes nothing. Our guides to a denied Guideline 3.1.1 appeal and to an App Review Board decision that went against you cover what a final, consolidated response should contain.

How we structure the response

1. Position. Each app uses the required billing method for each storefront it ships to, or has been corrected, with the build numbers.
2. Root cause. The specific flow behind each finding, whether digital goods sold outside In-App Purchase, an external link on a storefront without the allowance, or a reader or multiplatform claim that failed a 3.1.3 condition. Then the pattern behind them, such as a global flag for a US-only allowance or a growth team adding offers without payments review.
3. Corrective action. Purchases routed correctly, links limited to each storefront’s allowance, restore flows and disclosures fixed, across every app in the account.
4. Preventive control. An item-to-billing map checked before every submission, signed by a named owner.
5. Law, kept factual. One or two sentences that explain why a storefront’s rules differ, never a legal brief.
6. Evidence. The rejection history, per-storefront screenshots, the item-to-billing map, the flag configuration and the disclosures.

A worked example

Take a hypothetical language learning company with three apps, the scenario shown in the diagram above. One app is rejected under 3.1.1 for a get the full course on our website button on its lesson screen. The team removes the button and resubmits. Two months later a second app is removed for the same kind of button inside a settings page. After the May 1, 2025 update, the team adds an external purchase link to all three apps through one shared configuration. A third finding follows, and then a pending termination notice that cites conduct across the account.

The diagnosis has three layers. The flows are a website button on a lesson screen, the same button in settings, and an external link shown on every storefront. The pattern is that purchase and promotion screens come from a shared component library owned by the growth team, with no payments review, so each removed button reappears somewhere else. The configuration is a US-only allowance switched on globally.

The response maps every app and every storefront. Course subscriptions go through In-App Purchase on every storefront where it is required. The external link is limited to the US storefront and removed from the shared library for all others. Restore purchases is tested in every app. A payments owner is named, and every change to purchase or promotion screens now needs that owner’s sign-off against the item-to-billing map. The response lists each finding with its root cause and the build containing the fix, and offers the map, the per-storefront screenshots and the flag configuration as evidence. The law appears in one sentence explaining why the US storefront differs.

What the law does and does not do here

In the United States, the Ninth Circuit decided Epic Games, Inc. v. Apple, Inc., Nos. 21-16506 and 21-16695, on April 24, 2023, and affirmed the district court’s ruling that Apple’s anti-steering provisions were unfair under California’s Unfair Competition Law, along with the injunction barring their enforcement. Apple’s May 1, 2025 guideline change cites compliance with a US court decision on buttons, links and calls to action.

In the European Union, the Digital Markets Act, Regulation (EU) 2022/1925, entered into force on November 1, 2022 and sets obligations for designated gatekeepers. On March 4, 2024, the European Commission fined Apple over EUR 1.8 billion in Case AT.40437 for anti-steering rules that stopped music streaming apps from telling iOS users about cheaper options outside the app, and ordered Apple to remove those provisions. On April 23, 2025, the Commission fined Apple EUR 500 million for breaching the DMA anti-steering obligation and gave it 60 days to comply.

These decisions explain why the rules differ by storefront. They do not make an out-of-policy flow compliant on a storefront where the standard rule applies. In a response to Apple, cite them only to show that a flow matched the allowance for its storefront.

Auditing Every Live Item Before the Next Review

Run a portfolio audit after the first 3.1.1 finding so no other live app repeats the pattern. If you are past the first finding already, run it now and hold every pending submission until it is done.

Build the item-to-billing map

For every app, list every purchasable item. That means subscriptions, consumables, non-consumables, currencies, content packs, course access, premium features, gift cards, physical goods and services. For each item, record these fields.

• Whether it is a digital good used in the app, or a physical good or service used outside it.
• The billing method on each storefront the app ships to.
• The written rule that permits that billing method on that storefront, by guideline number.
• Every screen, push message, email and web view where the item is offered, promoted or linked.
• Whether restore purchases works for it, and whether purchased credits can expire.

Any digital item billed outside In-App Purchase needs a named rule that permits it on that storefront. If you cannot write the guideline number next to it, the item is a finding waiting for its review.

Running each business model compliantly

• SaaS and subscription businesses. Route digital subscriptions sold in the app through In-App Purchase on storefronts where it is required. On the US storefront, external links are allowed, so limit them to that storefront through a per-storefront flag. Keep the web account system, but do not promote the web price inside the app on storefronts where steering is barred. If subscription disclosures were part of a past rejection, see our guide to Guideline 3.1.2 subscription denials.
• Content and course platforms. Separate access from purchase. Check whether the app meets every condition of 3.1.3(a) for reader apps or 3.1.3(b) for multiplatform services. Remove calls to action that point to outside purchasing on storefronts where they are not allowed.
• Games selling currencies. Sell currencies and items through In-App Purchase wherever it is required, and never expire purchased balances. Run promotions as In-App Purchase products. If you use an outside store on the US storefront, confirm the link appears only there.

Check the whole app, including what is not a paywall

Steering often hides outside the paywall. We check onboarding screens, help pages, account settings, emails triggered from the app, push notifications and web views that load marketing pages. A web view that loads your pricing page with a subscribe button is a purchase flow, whatever the team calls it. Guideline 3.1.1(a) applies the same storefront rule to metadata, so the App Store description and screenshots are in scope too. Our guide to accurate metadata under Guideline 2.3 covers the listing side.

Test like a reviewer, per storefront

Test each app with an account set to each storefront it ships to, and record what a user there sees. A link meant only for the US storefront must be absent everywhere else, including on first launch before remote configuration loads. Reviewers also need to reach every purchase flow during review. Our article on Guideline 2.1 app completeness covers demo accounts and review notes. Apple also offers 30-minute App Review consultations over Webex, which are worth booking before a high-stakes resubmission.

What Never to Do, Including New Accounts

At the repeat and termination stage, a few moves turn a recoverable case into a closed one.

New developer accounts

Do not open a second developer account to republish apps from a terminated or pending account. Guideline 5.6 describes restoration through a written plan for the existing account, and the introduction to the guidelines treats attempts to trick the review process as grounds for expulsion. A fresh account that ships the same apps from the same team undercuts the plan before Apple reads it. If a second account already exists for a legitimate reason, such as a separate legal entity, read our guide to related account terminations before you do anything with it.

Other actions to avoid

• Moving the link. Taking an external link off the paywall and putting it in settings, a help page or a web view. It is the same steering on a different screen.
• Renaming the offer. Calling an outside purchase a membership, an account upgrade or a donation. Apple judges what the flow does, not its label.
• Swapping the link for a code. Selling a license key on the web and redeeming it in the app. Guideline 3.1.1 names license keys and QR codes as barred mechanisms.
• Hiding the flow during review. A purchase path that appears only after approval or only for some users. The October 16, 2026 revision moved hidden, dormant and undocumented features into a new Guideline 2.5.19, and Guideline 5.6 treats misleading behavior as a code of conduct issue.
• Turning a US-only allowance on globally. One flag, every storefront, one more finding.
• Arguing the case law. A long legal brief in a reply to App Review does not change the rule on a storefront. Keep the law to a sentence.
• Fixing only the cited app. At the repeat stage, Apple is looking at the portfolio.
• Blaming a contractor. The account holder owns what ships under the account, and the root cause has to say so.

Frequently Asked Questions

What happens if I get repeated Guideline 3.1.1 findings on Apple?

Each finding is still a rejection or removal, but the history now affects the account. Apple says apps repeatedly rejected for the same guideline take longer to review, and Guideline 5.6 allows termination of the Developer Program account for conduct outside the code of conduct. Answer the next finding with fixes across every app.

Will a second Apple Developer account get my apps back after a 3.1.1 termination?

No, not as a way back onto the App Store. Apple’s restoration route in Guideline 5.6 runs through a written improvement plan for the existing account. A new account that republishes the same apps reads as an attempt to get around the decision.

How do I check if my other apps carry the same Guideline 3.1.1 risk?

Build an item-to-billing map for every app and test each one on every storefront it ships to. Match every digital item sold outside In-App Purchase to a written rule in 3.1.1(a) or 3.1.3 for that storefront, and fix any item without one before the next submission.

Can I appeal an Apple Guideline 3.1.1 termination?

You can appeal to the App Review Board while the account is pending termination. Apple says not to use the appeal form for an account that is already terminated, and to use the matching Contact Us form instead, with a written statement of improvements under Guideline 5.6.

What triggers an Apple Guideline 3.1.1 finding?

Selling digital content, features, subscriptions or currencies through anything other than In-App Purchase triggers it. Steering users to outside purchasing on a storefront where that is not allowed triggers it too. Since May 1, 2025, the US storefront allows buttons and links, so the answer depends on which storefront the reviewer is checking.

How many apps can one App Review Board appeal cover?

One appeal form can cover up to five rejected or removed apps. Apple asks for only one appeal per rejected or removed app, with every cited guideline addressed in that single appeal.

Get Help With Repeated Guideline 3.1.1 In-App Purchase on Apple

A single 3.1.1 fix is usually manageable in-house. Bring it to us when the findings have repeated, when a pending termination notice has arrived, or when the business needs different payment flows by storefront and wants a structure that holds up under review. We map storefronts first, build the item-to-billing map across the portfolio, and prepare one response that covers every app.

Start with our Apple App Store reinstatement service, or book a consultation for an assessment of your payment flows by storefront. Developers with cases on other stores can browse our app store and developer reinstatement services.

Sources

1. Apple Developer, App Review Guidelines 3.1.1, 3.1.1(a), 3.1.3 and 5.6
2. Apple Developer News, Updated guidelines now available, May 1, 2025
3. Apple Developer News, Updated App Review Guidelines are now available, October 16, 2026
4. Apple Developer Help, Appeal to the App Review Board
5. Apple Developer, App Review
6. Apple Developer, Update on apps distributed in the European Union
7. U.S. Court of Appeals for the Ninth Circuit, Epic Games, Inc. v. Apple, Inc., Nos. 21-16506 and 21-16695 (April 24, 2023)
8. EUR-Lex, Regulation (EU) 2022/1925 (Digital Markets Act)
9. European Commission, Case AT.40437 decision, March 4, 2024
10. European Commission, DMA anti-steering decision against Apple, April 23, 2025