Can You Put an Offerwall in an iOS App? Apple's Rules

Can you put an offerwall in an iOS app?

Yes, in most cases, if you build it within Apple’s rules. The App Review Guidelines never mention offerwalls by name, but guideline 3.2.2(x) lets apps “incentivize users to take specific actions” while forbidding apps from forcing users to download other apps or take other store actions to use the app. In practice: an optional wall that pays your own in-app currency, no rewards for ratings or reviews, an App Tracking Transparency (ATT) prompt if anything tracks users across apps, and an honest privacy label.

This guide quotes the guidelines as last updated by Apple on October 16, 2026, and Apple’s privacy pages, all checked on October 20, 2026. It is general information, not legal advice. Apple decides each case at review, and the business model section says its own lists “are not exhaustive”, so read the live text before every submission.

Apple’s rules that apply to an offerwall

Several guidelines touch a rewarded offer wall. Here is what each one means in practice.

Guideline 3.2.2: rewards are fine, forced store actions are not

The key sentence for any rewarded feature sits in the list of unacceptable business practices:

The first half is about force. If level 12 only unlocks after the user installs a partner game, you are forcing a download. If the user can reach level 12 by playing, and the wall is a faster optional way to earn coins, nothing is forced.

The second half allows incentives, and an offerwall is a menu of optional, rewarded actions. Ratings and reviews are different: never reward them, in your app or in any offer. The introduction to section 3 warns that if you try to “inflate your chart rankings with paid, incentivized, filtered, or fake feedback”, Apple may expel you from the developer program. Can you pay for app reviews? covers that rule in detail.

The gray area: when the wall becomes the app

Guideline 3.2.2(i) forbids “creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection.” Guideline 3.2.2(iii) forbids “apps that are designed predominantly for the display of ads.” And 4.2.2 says apps “shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.”

A game with an Earn tab is far from these lines. An app whose only screen is a list of “install this app for points” offers is close to all three. A rewards app needs real features of its own, such as games, streaks, or content.

In-app purchase and your virtual currency

Guideline 3.1.1 says: “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.” It is about how users pay you. A user who earns 500 gems by finishing an offer has paid you nothing, so the wall does not bypass in-app purchase. What the rules do mean:

• Sell currency only through in-app purchase. If your app also sells gems, those sales go through Apple, and links to other ways to pay are allowed only where 3.1.1(a) permits them (the US storefront is exempt from the ban).
• Keep earned and bought currency consistent. Apple says “any credits or in-game currencies purchased via in-app purchase may not expire.” If earned and bought gems share one balance, let none expire.
• No crypto for tasks. Guideline 3.1.5(v): “Cryptocurrency apps may not offer currency for completing tasks, such as downloading other apps, encouraging other users to download, posting to social networks, etc.”
• Pay your own currency. A currency that lives inside your app is the cleanest model. Cash or gift card payouts bring extra questions about fraud, taxes, and local law.

How to set your virtual currency exchange rate explains how to price offers against your in-app purchase packs, and the virtual currency calculator does the math.

Privacy, ATT and privacy labels

App Tracking Transparency

Guideline 5.1.2(i) says: “You must receive explicit permission from users via the App Tracking Transparency APIs to track their activity.” Apple’s User Privacy and Data Use page defines tracking as linking data from your app with other companies’ data for targeted advertising or advertising measurement, or sharing it with data brokers. Without permission, the advertising identifier (IDFA) is all zeros.

Three points matter for an offerwall:

• The prompt depends on what the wall does, not on what it is called. If the wall or its SDK links your user’s data with other companies’ data for ads or ad measurement, you need ATT. Using a user ID only to credit rewards in your own app does not, by itself, match that definition. Ask your provider, because “developers are responsible for all code included in their apps.”
• Web views count. Apple’s FAQ says that if tracking happens in a web view used for app functionality, “it should be treated the same way as native functionality in your app, unless you are enabling the user to navigate the open web.”
• No fingerprinting. Apps whose SDKs derive data to uniquely identify a device may be rejected.

For how ATT and Apple’s install measurement fit together, see SKAdNetwork and ATT explained and what GAID and IDFA are.

Privacy policy and privacy label

Guideline 5.1.1(i) requires a privacy policy that says what data you collect and confirms that third parties, “such as analytics tools, advertising networks and third-party SDKs”, protect it equally. Apple’s app privacy details page adds that your privacy label must include data collected by “third-party partners whose code you integrate into your app”. For a typical wall, expect entries such as a user ID, a device ID for fraud prevention, coarse location, and product interaction. An SDK’s privacy manifest helps you fill this in. If you have users in Europe, read offerwalls and GDPR too.

Also note 5.1.2(iv): don’t “collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing.” Install offers are confirmed by the advertiser’s tracking, not by scanning the device.

Kids, age ratings and offer content

Guideline 1.3 says Kids Category apps “should not include third-party analytics or third-party advertising” and must keep links out of the app behind a parental gate. Guideline 5.1.4 extends this: “Apps intended primarily for kids should not include third-party analytics or third-party advertising.” An offerwall does not belong in either. Offerwall COPPA rules for kids’ apps covers the US law on top of the store rules.

For general audience apps:

• Age rating. Guideline 2.3.6 asks you to answer the age rating questions honestly. Apple’s age ratings reference lists Advertising (“paid promotion of products or services within the app”) among the capabilities the questionnaire asks about. Declare it.
• Offer content. Guideline 2.5.18 says ads “must be appropriate for the app’s age rating” and that apps with ads must let users “report any inappropriate or age-inappropriate ads.” Treat each offer as an ad: filter categories that do not fit your rating, and give users a visible way to report an offer.

WebView or native SDK: does it change the rules?

No. The guidelines apply to what the user sees and what data leaves the device, however the wall loads. The differences are practical.

Whichever you choose, credit rewards from your server, never from events in the app. What an SDK is explains the trade-offs of third-party code, and how to monetize a mobile game with an offerwall walks through the link, postback, and currency setup.

Gray areas and how to lower review risk

You cannot get a ruling in advance, but you can make the reviewer’s job easy. The introduction to section 3 says: “If your business model isn’t obvious, make sure to explain in its metadata and App Review notes.” Guideline 2.3.1(a) adds that new features must be described “with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected)”.

• Label it clearly. Call the entry point what it is, such as “Earn gems: optional offers from partners”, not “Free gems” with no context.
• Keep the entry point optional. A tab, a button in the store, or a “need more gems?” link. No pop-ups on launch that block play. Offerwall placement lists placements that work and ones to avoid.
• Be honest in metadata. Show the rewards feature as it is, and never promise amounts users cannot earn.
• Give the reviewer access. Guideline 2.1(a) asks for demo account details and a working back end. Offers depend on country, so say so in your notes and attach a screenshot of the wall.

How Apple compares with Google Play

The two stores land in a similar place. Google’s User Ratings, Reviews, and Installs policy opens with “Developers must not attempt to manipulate the placement of any apps on Google Play”.

On both stores, design for the stricter rule. Incentivized installs and Google Play policy covers the Android side in full.

Frequently asked questions