A referral reward you give away is not a purchase, so no billing rule starts.
You can add a referral program to an app on both stores, and the reward does not have to be bought through in-app purchase. Apple guideline 3.1.1 tells you what to use when you want to unlock features or functionality within your app, and the whole of section 3.1 is titled Payments. Google Play's Payments policy is triggered by an app requiring or accepting payment. Hand something over for nothing and there is no payment for either rule to govern. Google writes that out for reward points in so many words. What changes the answer is what the reward is, which is why this page is organised around that and not around the word referral. If you are still deciding what you are building, start from make an app.
Every clause on this page is quoted from Apple's App Store Review Guidelines, last updated 16 October 2026, or from Google Play's own policy pages. Both were read on 23 October 2026. The clauses that actually sink referral screens turn out to have nothing to do with money.
Start hereThe short version
Three reward shapes, three different rulebooks.
A reward that is a digital item inside your app sits near the in-app purchase rules without being caught by them. You may grant it. What you may not do is let anyone buy the same item through your own payment sheet, because that is a sale and a sale is what the store billing rules are about.
A reward that is a real world good or service goes the other way. Apple guideline 3.1.3(e) tells you that you must use something other than in-app purchase to collect payment for physical goods and services consumed outside the app, so in-app purchase is not an option you have. Google Play says its billing system must not be used for those either. Your own checkout holds the discount.
A reward that is cash or a gift card never touches a store billing system at all. The clause to read for that one is a privacy rule, guideline 5.1.2(i), which forbids making someone switch on push, location or tracking before they can collect compensation, including gift cards and codes. That is the pattern a reviewer actually sees on your screen.
Does a referral reward have to be an in-app purchase?
No. Read guideline 3.1.1 carefully and the trigger is a sale. It says that 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, and that 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. It sits under a heading called Payments, and the section after it opens with the words Other Purchase Methods. Every clause in the neighbourhood is about how money reaches you.
The verbs give it away once you look for them. Guideline 3.1.1 says any credits or in-game currencies purchased via in-app purchase may not expire. It says digital gift cards, certificates, vouchers and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase. Purchased. Sold. Apple has written a rule for what happens when a customer pays, and has written no rule at all for what happens when you give a customer something. The absence is the answer. An absence is weaker than a written permission, so say plainly in your App Review notes that nobody pays for the reward.
There is one reward shape where in-app purchase is closed to you altogether. Guideline 3.1.3(e) says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. It is written as an obligation. A referral credit that takes ten off a delivery or a haircut lives in your own billing, next to the rest of the order. The same logic shapes how you add shopping cart behaviour to an app that sells real things.
Pick your reward
What the reward is decides which rule you read
Choose the thing a referrer actually receives. Every clause quoted below comes from Apple's App Store Review Guidelines, last updated 16 October 2026, or from Google Play's own policy pages, both read on 23 October 2026.
Nothing picked yet. If you do not know what the reward is, you cannot know which rule applies, and that is the whole reason this question gets answered wrongly on forums.
What does Apple say about rewarding referrals?
Very little, and the little it says is easy to misread. Search the whole document for the word referral and you get one hit, in guideline 5.6.3 Discovery Fraud: 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. People find that sentence, see the word referrals and conclude that referral programs are banned. It is about manipulating the App Store, in a section titled Developer Code of Conduct, alongside clauses on fake reviews and developer identity. Rewarding your own customers for telling a friend is not what it describes.
The clause that genuinely covers incentives is guideline 3.2.2(x), which first forbids the gating version and then permits the rest: 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, and apps may otherwise incentivize users to take specific actions within apps, such as by completing a level or watching an ad. That second half is as close as Apple comes to writing down that incentive mechanics are allowed.
Two privacy clauses do more damage to real referral screens than any payment rule. Guideline 5.1.2(i) says your app may not require users to enable system functionalities, such as push notifications, location services or tracking, in order to access functionality, content, use the app, or receive monetary or other compensation, including but not limited to gift cards and codes. Guideline 5.1.2(v) says 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, and you must give the user a clear description of how the message will appear to the recipient before it is sent. An invite screen with a tick-everyone button fails that on sight.
Two more apply depending on your design. If the reward is a chance rather than a certainty, guideline 5.3.1 requires the developer of the app to sponsor the sweepstake or contest, and 5.3.2 requires the official rules to be presented in the app and to make clear that Apple is not a sponsor or involved in any manner. And if any of your referrers pay you a subscription, guideline 3.1.2(a) says they should be able to get what they have paid for without performing additional tasks, such as posting on social media or uploading contacts. Reward a referral on top of the subscription, never behind it.
Apple, App Store Review Guidelines, guidelines 3.2.2(x), 5.1.2, 5.3 and 5.6.3, read 23 October 2026
What does Google Play document for the same thing?
Google answers the payment question directly, which Apple never does. Its Payments policy explainer carries the question as a heading: can I issue loyalty or reward points in my app without using Google Play's billing system. The answer is yes, earned or awarded points can be issued in-app without it, and users can also exchange those earned or rewarded points in-app for digital goods and services without it. Then comes the boundary: if these points, or other types of virtual currency, are sold in-app, Google Play's billing system must be used. That is the clearest first-party statement either store has published on this, and it matches the reading of Apple's verbs above.
The underlying rule sets the same trigger. Google Play's Payments policy says Play-distributed apps requiring or accepting payment for access to in-app features or services must use Google Play's billing system for those transactions, and lists virtual currencies, extra lives, subscription services and ad-free versions as examples. Requiring or accepting payment is the condition. It also carries the mirror of Apple guideline 3.1.3(e): its billing system must not be used where payment is primarily for the purchase or rental of physical goods, or for the purchase of physical services, with transportation, cleaning, airfare, gym memberships, food delivery and tickets for live events given as examples. Peer-to-peer payments are on the same exclusion list, which is where a cash referral bonus sits.
One genuine divergence is worth planning around. Google's explainer says its billing system is not required for the sale of in-app gift cards, whether the card is an eGift or physically mailed. Apple guideline 3.1.1 says digital gift cards, certificates, vouchers and coupons redeemable for digital goods or services can only be sold in your app using in-app purchase. If your referral reward is a card you also sell, the two platforms need two different paths, and that decision belongs in the build rather than in a patch after the first rejection.
Google's hard no lives somewhere else. The User Ratings, Reviews, and Installs policy says developers must not attempt to manipulate the placement of any apps on Google Play, including inflating product ratings, reviews or install counts by illegitimate means, such as fraudulent or incentivized reviews and ratings, or incentivizing users to install other apps as the app's main functionality. Its key considerations repeat it as an instruction: do not offer rewards or incentives for ratings or reviews. The worked example Google prints is a notification offering a discount in exchange for a high rating.
Google, Understanding Google Play's Payments policy, read 23 October 2026
Six moves that cost a referral screen its review
Only one of these is a payment problem. The rest are copy and permissions decisions that someone makes on a Friday afternoon without opening the guidelines. Check your invite screen against the middle column before you upload a build.
| The move | What the rule says | Who rejects it |
|---|---|---|
| Reward is paid for a five star rating | Apple 3.2.2(x) forbids forcing store actions as a gate. Google Play's ratings policy forbids incentivized reviews and ratings outright. | Both stores. Google names this one as a common violation. |
| Invite screen has a Select All for contacts | Apple 5.1.2(v) says do not include a Select All option or default the selection of all contacts, and messages may only go out at the explicit initiative of that user on an individualized basis. | Apple. The screen is visible in review, so this is caught early. |
| Reward is held back until push is switched on | Apple 5.1.2(i) says an app may not require users to enable system functionalities in order to receive monetary or other compensation, including but not limited to gift cards and codes. | Apple. The clause names gift cards and codes in that sentence. |
| Paying subscribers have to refer to keep a feature | Apple 3.1.2(a) says apps offering subscriptions should allow a user to get what they have paid for without performing additional tasks, such as posting on social media or uploading contacts. | Apple. It reads as a scam pattern to a reviewer. |
| A prize draw with no published rules | Apple 5.3.1 and 5.3.2 require the developer to sponsor the contest and the official rules to be in the app, saying clearly that Apple is not involved. | Apple. Writing the rules is the whole fix. |
| Referral points also sold through your own card form | Google Play's Payments policy requires its billing system where an app accepts payment for in-app features, and its explainer repeats that points sold in-app must use it. Apple 3.1.1 requires in-app purchase to unlock features or functionality. | Both stores, and this is the only payment failure on the list. |
How do you build the invite, the code and the payout?
Four pieces, and only one of them is a screen. A code per account, generated on your server and never on the device. A link that opens your app with that code attached, which is a deep link on both platforms. A record of which new account arrived with which code, written server side at sign-up so the device cannot lie about it. And a rule for when the reward is earned, which is the piece people get wrong by paying out on install instead of on the first real action.
Pay on a qualifying event, not on arrival. An install costs a referrer nothing to fake and costs you whatever the reward is worth. A first completed order, a first week of use or a first payment is cheap to verify and expensive to fake. If the qualifying event is a delivery, the same plumbing you need to add order tracking already tells you when to release it.
For the invite itself, prefer the system share sheet to the contacts permission. The share sheet needs no permission prompt, it puts the choice of recipient and app in the person's hands, and it steps around every requirement in guideline 5.1.2(v) by design, because the user picks the recipient and sees the message. Apple's own data minimization clause, 5.1.1(iii), recommends the share sheet or an out-of-process picker over full access to Contacts. Reaching for the address book buys you a permission dialog, a rejection risk and a worse conversion rate.
Newly builds this kind of screen from a description. You say what the reward is and when it unlocks, and it writes a real React Native and Expo project you own, with two-way GitHub sync so the referral logic is code you can read and change. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It costs $25 a month and there is no free tier. It will not press submit on the App Store for you, because Apple guideline 4.2.6 says apps created from a commercialized template or app generation service are rejected unless submitted directly by the provider of the app's content. That step stays yours, and the mechanics of it are in publish to app store.
One last thing to write down before you build. Section 3 of Apple's guidelines opens by telling you to explain a business model that is not obvious in your metadata and App Review notes, and warns that a reviewer who cannot understand how your app works will delay the review. A referral reward that quietly unlocks premium content is exactly the kind of thing a reviewer meets with no context. Two sentences in the review notes, saying what the reward is and that nobody pays for it, costs you nothing and answers the question before it is asked.
Google, Understanding Google Play's Payments policy, loyalty and reward points, read 23 October 2026
Questions people ask about referral programs in apps
No, because nobody is buying it. Apple guideline 3.1.1 is written about what you must use when you want to unlock features or functionality within your app, and the whole of guideline 3.1 is titled Payments. Google Play's Payments policy is triggered by apps requiring or accepting payment for access to in-app features or services. A reward you hand over for free collects no payment, so neither rule starts. Google says this explicitly for reward points: earned or awarded points can be issued in-app without Google Play's billing system, and can be exchanged in-app for digital goods and services without it, but points sold in-app must use it. Read on 23 October 2026.
Decide what the reward is. The rest follows.
Write one line: what a referrer gets, and what has to happen before they get it. That line picks your rulebook, your payout trigger and your screen, in that order, and it is the whole brief for the feature.
Start building