How to build an app referral program,
without breaking either store's rules.
A good app referral program turns existing users into an acquisition channel, sitting alongside your other app monetization strategies rather than replacing them. It only works, though, if the reward structure survives what Apple and Google actually allow, and if the referral link survives the trip through an app store install. Here is how a referral program for mobile apps is actually built, what a mobile app referral program is allowed to reward, and what it costs.
The short version
Reward a real action, not a download.
A referral program app feature needs three things: a unique code or link per user, a way for that link to survive the trip through the App Store or Play Store install, and a reward tied to a real signup or in-app action rather than the download itself. Reward the download alone, or dangle the reward in exchange for a rating, and you are in the exact territory both Apple and Google police. Reward a genuine signup with a small, honest incentive, and referral programs are entirely normal. The mechanics and the policy detail are both below.
The mechanics
How a referral actually gets tracked.
The hard part of a referral program for mobile apps was never the invite screen. It is that a link has to survive an app store install and come out the other side still knowing who sent it.
- 1
A user gets a unique code or link
The app generates a referral code (or a link carrying that code) tied to one account, usually surfaced in a Refer a Friend or Invite screen.
- 2
They share it outside the app
Text, email, social, or just reading the code aloud. This part needs no special engineering, it is a native share sheet.
- 3
The link has to survive an install
If the recipient does not already have the app, the link opens the store listing instead. A deferred deep link (or the person typing the code in by hand after installing) is what reattaches the new account to the original referrer once the app opens for the first time.
- 4
The backend records the pairing and waits
Nothing rewards anyone yet. The backend stores which account referred which, then watches for the qualifying event you actually chose to reward.
- 5
The reward fires on the qualifying event
Signup completed, onboarding finished, first booking made, first payment taken, whatever you defined. This is also where basic fraud checks belong: same device, same payment method, or a burst of accounts from one IP are the usual signs of someone gaming the reward.
Three ways to build the tracking
Step three and four above are not free. Here is what each way of building them actually trades off.
| Approach | Setup | Fraud protection | Cost | Data ownership |
|---|---|---|---|---|
| Build it yourself | Custom backend: link generation, deferred deep links, a referral-pairs table, reward triggers | You write your own checks (device, IP, payment method matching) | No per-user fee, just engineering time | Full, the data lives in your own database |
| Attribution SDK | Drop in a mobile attribution SDK, configure link domains and events | Built-in fraud filters, tuned across many apps | Usage-based, typically priced per attributed install | Partial, attribution events live on the vendor's platform |
| Full-service referral platform | Hosted widgets and reward rules, minimal code required | Handled by the platform, limited customization | Monthly platform fee, sometimes plus a per-referral cut | Least, referral relationships live outside your stack |
Where this stops being a design decision
Once referrals are flowing, the pairing data from step four is also the raw material for measuring whether the channel is any good, cost per referred user, conversion rate, retention against your other channels. That reporting layer is its own subject; see mobile app analytics for how to actually build the dashboards on top of it, since getting that right is a bigger topic than a referral program's plumbing on its own.
Reward structures
Four ways to structure the reward.
There is no single right answer here, the right structure depends on what a converted user is actually worth to you, and whether the reward is cash-equivalent or just app credit. If the reward is a subscription discount or extra credits rather than cash, you are issuing it through whatever billing layer already handles your subscriptions, worth weighing against a provider's own revenuecat pricing before you commit to a structure.
| Model | Referrer gets | Referee gets | Best for | Watch out for |
|---|---|---|---|---|
| Double-sided (give-give) | Reward on signup or first action | Same reward, or a smaller welcome reward | Apps where the new user needs their own reason to act, not just to help a friend | Doubles your payout per successful referral, so the reward has to stay small |
| Single-sided (referrer only) | Reward once the referral converts | Nothing beyond the app itself | Apps with strong organic pull, or a cash-equivalent reward too big to pay twice | Lower conversion, since the new user has no personal incentive to finish signing up |
| Milestone / tiered | Bigger rewards at 3, 10, 25 successful referrals | Standard welcome reward | Apps trying to surface a small number of power referrers, not casual one-off shares | Needs a visible progress tracker or most users never notice the tiers exist |
| Delayed / conversion-gated | Reward only after the referee subscribes or pays | Discount on their first paid period | Subscription apps that cannot afford to reward a signup that never converts | The gap between invite and reward can be weeks, which weakens the incentive |
Find your reward structure
What is the reward worth?
When should it fire?
Referrer gets: Reward on signup or first action
Referee gets: Same reward, or a smaller welcome reward
Apps where the new user needs their own reason to act, not just to help a friend.
Try it yourself
What would your program actually cost?
Plug in a reward amount and a rough volume to see whether the math holds up before you build anything.
What this program would do
9.0x return on reward spend. That is a healthy multiple for a referral program to run on.
A rough model, not a forecast — it ignores fixed engineering cost and any drop-off between invite and signup.
The rules
What Apple and Google actually allow.
Neither store has a page titled "referral program rules." What they have are broader anti-manipulation policies that a referral program has to stay clear of.
Apple: Guideline 3.2.2(x)
Apple's App Store Review Guidelines state, verbatim: 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," while apps "may otherwise incentivize users to take specific actions within apps." A referral reward is fine; a reward conditioned on a store action, or functionality locked behind referring someone, is not.
Read the App Review GuidelinesGoogle Play: Ratings, Reviews & Installs
Google Play's policy prohibits "inflating product ratings, reviews, or install counts by illegitimate means, such as fraudulent or incentivized reviews and ratings," and separately calls out offering an incentive in exchange for a rating, or using automated services to inflate installs or ratings. A referral that rewards a genuine signup is not what this policy targets; a referral that rewards a bare install with no signup behind it, or asks for a rating in return, is much closer to it.
Read the Play Console policySelf-audit checklist
0/4 confirmedRed flags to avoid
If the reward comes from a third party: FTC disclosure
Store policy is not the only rule that applies. If you ever pay outside parties, not your own users, a commission for driving signups, that shifts the relationship from a referral program into affiliate territory, and the FTC's Endorsement Guides require any material connection (a commission, a free product, a discount) to be disclosed clearly wherever the endorsement appears.
Read the FTC's guidanceGrowth channels
Where a referral program actually fits.
A referral program for mobile apps is not, on its own, a full growth strategy. It is one lever, best pulled alongside the others. For the rest of the channels worth running, see how to get more app downloads.
| Channel | Primary cost driver | Trust signal | Scales with | Store policy risk |
|---|---|---|---|---|
| Referral program | Reward payouts to existing users | High, the recommendation comes from someone the new user knows | The size and engagement of your current user base | Real, but narrow: only if a reward is tied to a raw download, a rating, or a review |
| Paid user acquisition | Ad spend, priced per install or per action | Low to medium, a stranger's ad rather than a friend's word | Your budget, up to what the channel can absorb | Low, store policy is mostly untouched by how you buy traffic |
| App Store Optimization | Time spent on keywords, screenshots, and listing tests | Medium, organic ranking reads as earned rather than bought | Search visibility for the terms people already type | Low, unless you buy fake reviews or ratings to boost ranking |
Building it
This is backend work, not a screen.
The invite screen is the easy part. The actual referral program app logic, deferred deep links that survive an install, a table pairing referrers to referrals, fraud checks before a payout fires, lives in your backend, not your UI. That is exactly the kind of app-specific logic that does not fit neatly into a fixed template, which is why teams whose referral rules do not match an off-the-shelf plugin end up building it themselves. In Newly, that logic sits in the same backend that already handles your accounts and your database, instead of a bolted-on third-party service you have to keep in sync.
FAQ
App referral programs, answered.
An app referral program is a built-in feature that gives an existing user a unique code or link to share, then rewards someone (the referrer, the new user, or both) when the person they invited signs up or takes a defined action, like completing onboarding or subscribing. It is a growth channel that runs inside the app itself rather than through paid ads, and it depends on attribution: the app has to know which new install or signup came from which shared link.
Building the app first? Start with Newly.
Describe the app, including the referral flow, and Newly builds it with a real backend underneath, ready for the reward logic and fraud checks a referral program actually needs.