Referral Programs and the App Store Rules: What Apple Allows

You want your users to invite their friends, and you want to thank them for it. Then you read a forum thread where someone got rejected for exactly that, and you start wondering whether a referral program is allowed in an iOS app at all.

It is — but Apple draws a few lines that are easy to cross by accident. This guide goes through the guidelines that actually apply (with section numbers and the exact wording), shows what App Review has rejected in practice, and ends with a checklist you can run before you submit.

Note: this is a practical summary for developers, not legal advice. Quotes are from Apple's App Review Guidelines as last updated on June 8, 2026. Apple can change them at any time — check the current text before you ship.

The short answer

Referral mechanic	Status	Why
Rewarding the person who sends the invite (points, a free month, a commission)	Allowed	App Review has said so explicitly (see below)
Rewarding the person who receives the invite just for installing or signing up	Risky — has been rejected	Treated as incentivizing downloads
Unlocking premium features with your own referral code instead of in-app purchase	Rejected	Guideline 3.1.1
Giving the invitee a discount through Apple offer codes	Allowed	Apple's own mechanism for discounted subscriptions
Requiring a rating, review or another app's download to get a reward	Rejected	Guideline 3.2.2(x)
Uploading the whole address book and messaging everyone	Rejected	Guideline 5.1.2(v)
Fake accounts, self-referrals, bought "referrals"	Rejected, can end your developer account	Guideline 5.6.3

The guidelines that apply

3.1.1 — rewards that unlock digital content must go through in-app purchase

The most common way to get a referral program rejected is to let a code unlock something the user would otherwise pay for. Guideline 3.1.1 is explicit:

"If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc."

A homemade referral code that switches on "Pro for 30 days" is exactly such a mechanism. If you want the reward to be premium access, deliver it through Apple's own tools — a subscription offer code or a promotional offer — not through your own unlock logic.

3.2.2(x) — don't make store actions the price of the reward

Section 3.2.2 lists unacceptable business models. Item (x) is the one referral programs run into:

"Apps must not force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality, content, or use of the app. Apps may otherwise incentivize users to take specific actions within apps (e.g. completing a level, watching an ad)."

The second sentence matters: rewarding an action inside your app is fine. Inviting a friend from an in-app screen is an in-app action. Asking for a 5-star rating in exchange for a reward is not.

5.6.3 — Discovery Fraud mentions referrals by name

The Developer Code of Conduct is short and blunt:

"Manipulating any element of the App Store customer experience such as charts, search, reviews, or referrals to your app erodes customer trust and is not permitted."

This is about manipulation: fake accounts, users referring themselves, paying a "referral farm" for installs. A real program where real users invite real friends is not discovery fraud — but your program needs basic fraud controls so that it can't turn into it. At minimum, block self-referrals and don't pay out before a refund window has passed.

5.1.2(v) — contacts are for individual, user-initiated invites

If your invite screen reads the address book, this rule applies:

"Do not contact people using information collected via a user's Contacts or Photos, except at the explicit initiative of that user on an individualized basis; do not include a Select All option or default the selection of all contacts."

The safe pattern is the iOS share sheet: the user picks one person and one channel, and the message is theirs. No contact upload, no "invite all".

The rewarded-invitee problem

Here is where most confusion comes from. The guidelines never literally say "you can't reward the invitee". But in February 2021, App Review rejected an app under 3.2.2 with this message, quoted in an Apple Developer Forums thread:

"While rewarding the invitation sender with points or other digital content is acceptable, the person receiving the invitation should not receive any rewards for downloading or registering an account to use your app. Incentivizing downloads has a direct influence on the App Store user reviews or chart ranking."

Two things follow from this:

1. Rewarding the sender is explicitly acceptable. That's the core of every referral program.
2. Rewarding the receiver for downloading or registering is the risk. Developers in the same thread point out that big apps run "give $10, get $10" programs anyway. Some of those reward a later action (a first purchase, a first deposit) rather than the install, and some are simply treated differently. You don't want to be the test case.

If you want a double-sided program anyway, tie the invitee's benefit to something other than the download — for example a discounted first period through an Apple offer code, applied when they subscribe.

Rewarding the referrer: three ways that work

1. In-app rewards delivered through Apple's mechanisms. A free month or extra credits for the referrer, granted as a promotional offer or offer code, stays inside Apple's in-app purchase rules.

2. A cash commission paid outside the app. This is how affiliate and creator programs work: the referrer earns a share of what the people they brought in pay, and you pay that out yourself — by PayPal, Wise or bank transfer. Nothing is unlocked inside the app, so 3.1.1 doesn't come into play, and the reward goes to the sender, which App Review has called acceptable.

3. Status or recognition. Badges, leaderboards and early access are harmless as long as they don't unlock paid functionality.

Whatever you choose, describe the program in the Notes for Review field in App Store Connect. Guideline 2.3.1(a) requires new features to be "described with specificity", and a reviewer who understands the program is less likely to guess wrong.

Rewarding the invitee: Apple offer codes

If the invitee should get something, Apple's offer codes are the mechanism built for it. A few facts from App Store Connect Help:

• They exist for auto-renewable subscriptions and also for consumables, non-consumables and non-renewing subscriptions.
• Each app can have up to 10 active offers with a limit of 1 million codes per app, per quarter.
• One-time-use codes expire after at most six months; each customer can redeem one code per offer.

Offer codes are a discount mechanism, not an attribution mechanism: they tell you that someone redeemed a discount, not who invited them. To know who gets the commission, you still need your own referral code.

How Google Play compares

Google Play's User Ratings, Reviews, and Installs policy prohibits inflating ratings, reviews or install counts "by illegitimate means, such as fraudulent or incentivized reviews and ratings", and prohibits "incentivizing users to install other apps as the app's main functionality". It doesn't single out referral programs. The same design that passes App Review — reward the sender, no rewards for ratings, no fake installs — works on Google Play.

A design that stays on the safe side

Putting it together, a referral program that matches both the guideline text and App Review's practice looks like this:

1. Each user gets their own code and shares it through the system share sheet.
2. The new user enters the code — in onboarding or from a link if the app is already installed.
3. Only the referrer is rewarded, and only when the new user actually pays.
4. The reward is a commission paid outside the app (or an Apple offer, if you want an in-app reward).
5. Self-referrals are blocked, and commissions wait out the refund window before they become payable.
6. Refunds cancel the commission.

That is the model AppThunder Referrals is built on: generated codes, commissions for the referrer only, a 30-day hold, refunds voiding commissions, self-referral blocking, and exports you pay out yourself. Attribution is deterministic: a referral counts only when a code actually arrives, with no device fingerprinting or probabilistic matching.

Checklist before you submit

• No premium feature is unlocked by your own code — rewards inside the app use in-app purchase, promotional offers or offer codes (3.1.1)
• Nobody is asked to rate, review or download another app to get a reward (3.2.2(x))
• The invitee isn't rewarded just for installing or registering
• Invites go out one by one, at the user's initiative; no contact upload, no "select all" (5.1.2(v))
• Self-referrals are blocked and payouts wait for the refund window (5.6.3)
• The program is described in the Notes for Review (2.3.1(a))
• The program's terms (who gets what, when) are visible in the app

FAQ

Can I give both the referrer and the friend a reward? The referrer, yes. For the friend, avoid a reward for downloading or registering; a discount applied when they subscribe, via an Apple offer code, is the cleaner route.

Can a referral code unlock a free month of my subscription? Not with your own unlock logic — that's what 3.1.1 rules out. Use a subscription offer code or promotional offer instead.

Is paying referrers in cash allowed? App Review has stated that rewarding the invitation sender is acceptable. A commission paid outside the app doesn't unlock anything inside it. Make sure your terms are clear and that you handle the tax side for payouts in your country.

Do I need to mention the referral program to App Review? Yes. Describe it in the Notes for Review; generic descriptions of new features can be rejected under 2.3.1(a).