App Store Promo Codes vs Offer Codes: How to Give People Free Access to Your Expo App

App Store promo codes are single-use codes, generated in App Store Connect, that give a person a free copy of your app on iOS, macOS or tvOS. Apple's App Store Connect Help states the rules plainly: you can request up to 100 promo codes per version of each platform your app supports, each code stays valid for four weeks from its generation date, it can be redeemed on any storefront where the app is available, and the app then behaves as if it were purchased, including future updates. Two details decide whether they are the right tool for you. First, a customer who downloads through a promo code cannot rate or review the app. Second, promo codes can redeem an unreleased version that is Ready for Distribution or Pending Developer Release, which makes them a way to let a journalist or a partner run the real build before launch day.

What they are not, as of this year, is a way to give away an in-app purchase. Apple announced that offer codes now cover every in-app purchase type, and that starting March 26, 2026 you can no longer create promo codes for in-app purchases in App Store Connect. Existing ones can be redeemed until they expire, and promo codes continue to work for a free download of the app itself. That change matters for the way most apps in this community are built: a free download with a subscription behind a paywall. For that app, a promo code does nothing, because the download was already free. The thing you want to give away is the subscription, and that is an offer code.

Inside App Store Launch Club I describe free access as three doors, because members keep reaching for the wrong one. Each door is built for a different person at a different moment, and Apple publishes a hard limit on every one of them.

The pattern that works: TestFlight for the people helping you find bugs, because that is what [TestFlight beta testing](/blog/testflight-beta-testing-guide-for-expo-apps) is for and a 90-day expiring build keeps testers on the current version. Promo codes only when the app itself costs money. Offer codes for everything involving the paywall. If you are still deciding on your pricing model, the [guide to pricing your app subscription](/guides/how-to-price-your-app-subscription) is the place to settle that first, because the door you use follows from it.

The first instinct for a builder who wants to give a friend free access is to add a text field to the paywall, check the string against a list in Supabase, and flip a flag. Apple forbids it. App Review Guideline 3.1.1 says that if you want to unlock features or functionality within your app, including subscriptions, premium content or 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. A home-made coupon field is a license key with a friendlier name. [The Guideline 3.1.1 rejection post](/blog/app-store-rejection-guideline-3-1-1) walks through what that rejection looks like when it lands.

There is a second rule sitting next to it. The Business section of the guidelines warns that attempts to manipulate reviews or inflate chart rankings with paid, incentivized, filtered or fake feedback can get you expelled from the Apple Developer Program. So a promo code handed over with the message please leave a five-star review is a problem twice over: the recipient cannot review anyway, and asking is the thing Apple punishes. If reviews are the goal, [the first app reviews post](/blog/how-to-get-your-first-app-reviews) covers the sanctioned route, which is the in-app rating prompt at the right moment.

You need the Account Holder, Admin, App Manager or Marketing role. In App Store Connect, open the app, click Promo Codes in the sidebar, enter the number of version promo codes you want under App Promo Codes, click Generate Code, read and agree to the contract terms for Apple to distribute free versions of your app, then click Generate Code again. The codes appear on the History tab, where you can copy them or download a text file. The History table shows the date each batch was generated, and Apple tells you to use that date to work out the expiry, since the four weeks run from generation, not from when you hand the code out.

Offer codes attach to a specific subscription, so the subscription and its group must already exist. If they do not, [setting up in-app subscriptions with RevenueCat](/blog/how-to-set-up-in-app-subscriptions) comes first. Then, in App Store Connect: open the app, click Subscriptions in the sidebar, choose the subscription group, select the subscription, click the add button in the Subscription Prices section, and choose Create Offer Codes. Enter a reference name, which is how the offer will show up in Sales and Trends and in StoreKit transactions. Choose whether the subscription should auto-renew to the standard price when the offer ends; if you tick the box to prevent auto-renewal, Apple restricts you to Free offers only. Pick eligibility from new subscribers, existing subscribers and expired subscribers. If the subscription has an introductory offer, decide whether code redeemers also get it. Select countries, choose Pay as you go, Pay up front or Free, set the duration and any discounted price, then confirm. Apple's help page is explicit that once an offer is created you cannot edit it; changing eligibility means creating a new offer.

The offer is the pricing container. The codes come next, and there are two kinds. One-time-use codes are unique 18-digit codes, each redeemable once, which Apple describes as suited to small-scale or restricted distribution. They must carry an expiry date and can live at most six months. Custom codes are a word you choose, such as a community name, up to 64 characters with no special characters, redeemable by many people up to a redemption limit you set. You can set that limit up to 25,000 at a time and reuse the same custom code on the same offer if you need more, and an expiry date is optional for custom codes. Both kinds count against the same pool of 1 million codes per app per quarter, and both take up to an hour before they become redeemable. Your app has to be live on the App Store for anyone to redeem either kind.

Distribution is on you. Apple gives you two mechanisms: hand out the code itself, which a person types into the Redeem Gift Card or Code page in their App Store account settings or into your app, or build a redemption URL that opens a redemption page and prompts the person to install your app first if they do not have it. For a community launch, one custom code in the welcome post is the simplest thing that works, and Apple's own distribution examples include email campaigns, event flyers, partner promotions, a member referral program and a save offer to a subscriber who has turned off auto-renew.

The 2026 expansion is what makes this post relevant to a paid-unlock app, not just a subscription app. Apple's help page for in-app purchase offer codes says they now cover consumables, non-consumables and non-renewing subscriptions, and StoreKit documentation gives the platform floor: offer codes for auto-renewable subscriptions work from iOS 14.2, while offer codes for the other purchase types need iOS 16.3, macOS 15 or visionOS 1.0 or later for in-app redemption. Eligibility on these offers is based on purchase history inside your app: never purchased, purchased in the last 30 days, or purchased more than 30 days ago, and selecting all three opens the offer to everyone. To generate one-time-use or custom codes the app must be Ready for Distribution and the in-app purchase must be Approved. One-time-use batches run from a minimum of 500 to a maximum of 25,000 codes, so the smallest batch you can create is 500 even if you need five.

Apple also added sandbox codes, which exist purely for testing. Each app can create up to 10,000 sandbox codes per quarter, in batches of 10 to 10,000, and you redeem them from the Sandbox Account Settings page on a device running iOS 16.3 or later by tapping Initiate Transaction and choosing Offer Codes. That slots straight into the routine from [testing in-app purchases in sandbox mode](/blog/how-to-test-in-app-purchases-in-sandbox-mode). Test the redemption before you distribute a single real code, because deactivating an offer expires every unredeemed code immediately and Apple says those codes are not credited back to your quarterly limit.

Nothing in the Expo SDK presents Apple's redemption sheet, so this runs through RevenueCat's Purchases SDK, which is what most members already use for the paywall. RevenueCat's iOS offers documentation says that from Purchases SDK 3.8.0 you call the presentCodeRedemptionSheet method to show Apple's sheet, and that Apple gives no callback to tell you whether the redemption succeeded. The SDK picks up the new transaction from the underlying queue and refreshes CustomerInfo, so your paywall should react to the customer info listener, not to the sheet closing. The same page is candid that the in-app sheet has been unstable since launch, with cases where it does not connect, does not dismiss, or rejects valid codes, and it offers a workaround: link out to the App Store with a redemption URL of the form apps.apple.com/redeem?ctx=offercodes&id=YOUR_APP_ID&code=YOUR_CODE, then call syncPurchases when the person returns to the app so the entitlement shows up without a manual restore.

Apple's StoreKit guidance explains why the listener matters. When a customer redeems a code in the App Store rather than in your app, the transaction arrives through the Transaction updates stream while the app runs, and on launch the app must check current entitlements and unfinished transactions to catch anything that happened while it was closed. A brand new customer who redeemed a code on the redemption page already owns the subscription the first time they open your app, so the paywall should never appear for them. RevenueCat handles that check for you, but only if the SDK is configured before the first screen decides whether to show the paywall. One more configuration detail from RevenueCat's docs: upload an In-App Purchase Key to RevenueCat, or offer code revenue will not be tracked accurately in its charts.

The redemption sheet is a small feature that touches the same paywall you have already tuned. Keep the button quiet, below the plans, so it does not distract from [the paywall screen that converts](/blog/paywall-screen-that-converts). The people who have a code will find it.

My own order of operations is boring and it holds up. TestFlight for the first two dozen people, because I want their crash reports and the build expiring after 90 days keeps them current. One custom offer code for the community I launch into, with a redemption limit that matches the size of the group and a six-month expiry so it does not outlive the launch. A small batch of one-time-use codes kept in reserve for a subscriber who hits a bug, since Apple lists customer service compensation as an intended use and a free month is cheaper than a refund conversation. Promo codes I only touch on the rare paid-up-front app, and then I tell the recipient in the same message that they cannot leave a review, so the code is a courtesy and not a transaction.

What I do not do is hand out codes as a substitute for a free trial. Apple's introductory offer already covers that for the general public, and the [free trial primer](/free-resources/how-to-use-a-free-trial) explains when it earns its keep. Codes are for people you can name. If you cannot name who is getting the code and why, it belongs in the introductory offer, not in a spreadsheet of 500 one-time-use strings. And once the codes are out, the follow-up is the same as any other acquisition channel, which is the work in [getting your first 100 app users](/blog/how-to-get-your-first-100-app-users).

App Store promo codes give a free download of a paid app: 100 per version per platform, single use, four weeks from generation, no rating or review from the recipient. Offer codes give free or discounted in-app purchases and subscriptions, and since March 26, 2026 they are the only code Apple lets you create for anything behind a paywall, with 10 active offers per app, 1 million codes per quarter, one redemption per customer per offer, one-time-use codes that expire within six months and custom codes that can run indefinitely. You cannot build your own coupon box because Guideline 3.1.1 forbids unlocking functionality through your own mechanisms. In an Expo app the redemption runs through RevenueCat's presentCodeRedemptionSheet with the App Store redirect URL as the fallback, and your paywall must trust the entitlement listener rather than the sheet.

The Three Doors came out of watching members give a promo code to someone who wanted the subscription, then wonder why nothing unlocked. Inside App Store Launch Club you can post which door you are about to use and what you are trying to achieve, and get it checked by people who have run the redemption flow on a live app. Join at applaunchclub.co for $9 a month and bring your paywall.