How to Add In-App Subscriptions to an iOS App the Simple Way

Start with the simplest viable App Store Connect setup

The minimum path is boring in the best possible way, which is ideal. In App Store Connect, create a subscription group first, then add your subscription product inside that group. Apple’s subscription-group guidance says subscription groups organize products, and the official setup flow starts there. The fetched guidance also notes that if you already have a subscription group, you can skip that step when creating another plan in it.

If you want the official paper trail, start with Apple’s subscription-group guidance and setup steps, which are summarized in the fetched source here: Apple subscription group guidance.

Decide your subscription structure before you click anything

This is the part people like to wing, and then future-you gets to clean up the mess. Decide whether you need a single tier or multiple tiers, because that decision affects how users move between plans and how your subscription group should be structured.

The official guidance in the fetched source warns that subscription groups matter for upgrade, downgrade, and crossgrade policies, and that if the initial setup is not done properly, it cannot be changed later. That is the annoying-but-important part. If you accidentally group plans the wrong way, you can create avoidable limits later, or make it easier for users to end up with the wrong access path.

A simple rule works well for many indie apps: if you only have one premium offering, keep one group and one subscription product. If you expect multiple levels, decide ahead of time how users should move between them, then build the group structure to match that plan instead of improvising after launch.

Create the subscription group and product in App Store Connect

At a high level, the flow is straightforward:

1. Open your app in App Store Connect.
2. Go to Monetization, then Subscriptions.
3. Create a subscription group.
4. Create the subscription plan inside that group.

The fetched source describes the same path, including selecting the app, going to Subscriptions under Monetization, and clicking the plus button to create a subscription group. It also notes that the Reference Name is not user-facing, so you can use an internal label that helps you keep your own sanity intact.

Once the group exists, add the subscription product within it. That is the product you will actually sell in the app.

Add the required metadata reviewers and users will see

Before review, App Store Connect needs the user-facing subscription details filled out. The fetched guidance says you must add at least one localization to the subscription group before you can submit the in-app purchase for review. It also says the App Store localization is the name and description the user will see.

In practice, make sure you complete the fields reviewers expect to see, including:

• Localized subscription name
• Localized subscription description
• Pricing
• Duration
• Any other required App Store Connect fields for the subscription product and its localization

The key here is consistency. The in-app paywall, the App Store Connect metadata, and the screenshot copy should not feel like three different apps accidentally got merged in a hallway.

If you are still tightening your listing assets, the related guide on how to legally choose an app name helps with naming consistency, and how to write App Store screenshot captions that read fast helps make the subscription pitch easy to scan.

Implement the paywall and entitlement check in the app

On the app side, keep the flow simple:

• Show the subscription offer in a paywall or settings screen.
• Send the purchase through StoreKit.
• After purchase, verify the user’s active entitlement.
• Unlock premium content only when that entitlement is active.

That last step matters. Do not unlock based only on a button tap or a successful purchase screen. The app should check the current entitlement state so access follows the actual subscription status, not whatever the UI was feeling that afternoon.

If your app has a server, you can still use the same basic rule: the app should not treat premium access as permanent just because a purchase once succeeded.

Handle restore, renewal, cancellation, and expired access

A predictable subscription app needs predictable state handling.

At minimum, plan for:

• Restore purchases, so users can recover access on a new device or after reinstalling the app
• Renewal, so active users keep premium access when the subscription continues
• Cancellation, so the app reflects that the user may keep access until the current period ends
• Expired access, so premium features lock again when the entitlement is no longer active

The big thing is to keep the app honest. If access is gone, say so. If access is still valid until the period ends, do not pretend the subscription vanished the instant someone hit cancel. That kind of mismatch is exactly the sort of thing that turns a routine review into a tiny bureaucratic sitcom.

Submit the subscription with a clean first-review checklist

Before you send it in, run a short checklist:

• The paywall opens and works
• There is a clear way to reach the subscription from inside the app
• The App Store Connect metadata matches the in-app experience
• Reviewers can test the purchase path without hunting through hidden menus like it is a treasure map
• Restore purchases works
• The app only unlocks premium content after entitlement is verified

The goal is to make the first review boring. Boring is good. Boring means the reviewer can understand the product, test the subscription, and move on without filing a mystery report.

Worked example: a one-tier indie app subscription setup

Say you have a note-taking app with one premium tier.

In App Store Connect, you would:

1. Launch the app within App Store Connect.
2. Navigate to Monetization, then Subscriptions.
3. Set up a single subscription group for the premium tier.
4. Add one subscription product inside that group.
5. Enter the localized name and description, along with pricing and duration.

In the app, you would:

1. Show a single paywall with one option, for example “Premium Monthly.”
2. Start the StoreKit purchase flow when the user taps subscribe.
3. Check the active entitlement after purchase.
4. Unlock premium note templates, sync, or whatever the paid feature is.
5. On app launch, check again so access stays correct if the subscription renews, lapses, or gets restored.

That is the whole trick. One group, one product, one clear entitlement check. Fancy enough to ship, boring enough to maintain.

Use this related setup guide if your app is still being prepared for review

If your app is still in pre-review limbo, two setup details tend to cause extra friction: naming consistency and screenshot clarity. The naming guide, How to legally choose an app name, helps keep your product name aligned across the listing and the subscription pitch. The screenshot caption guide, How to write App Store screenshot captions that read fast, helps your subscription offer make sense at a glance.

FAQ

Do I need a subscription group for the first product?

Yes. The fetched Apple guidance says that to create an in-app subscription for the first time, you need to create a subscription group first.

Can I change the structure later?

Not safely if it was set up wrong at the start. The fetched guidance says the upgrade, downgrade, and crossgrade structure matters, and that it cannot be changed if the initial setup is not done properly.

What do reviewers need to test?

They need to be able to reach the paywall, understand the subscription offer, and complete or simulate the purchase path. They also need the metadata and in-app experience to match, so the subscription is reviewable without guesswork.