How to Create a Subscription In-App Purchase for iOS Without Breaking Review

Before you touch subscriptions, your Apple back office has to be clean. Apple will happily let you design paywalls and flows while quietly blocking payouts or in‑app purchase setup because something in the background is red.

At minimum, make sure:

• Your Apple Developer Program membership is active and you are on the correct team.
• The Paid Apps / Paid Applications agreement is accepted and in Active status.
• Tax forms (W‑8BEN or W‑9) and banking info are fully completed, verified, and not stuck in “Processing.”
• Your app’s bundle ID is created under Certificates, Identifiers & Profiles and matches exactly what you use in Xcode and App Store Connect.
• The person doing the setup has a role with the right permissions (Admin, App Manager, or a custom role that can manage in‑app purchases).

If any of this is missing, you can still click around, but things will fail silently later: products that never become “Ready to Submit,” payouts that never arrive, or subscriptions that cannot be attached. For auto‑renewable subscriptions, Apple keeps 30% of the first year of each subscription and usually drops to 15% afterward for eligible long‑running subs, so your pricing and margin math should assume that cut from day one.

At AppMakers USA, we treat this as infrastructure work. The unglamorous checklists here are what keep you from debugging money flows at midnight the day before launch.

Once the account and agreements are in a good place, you can actually reach the subscription configuration screens. The path moves a bit as Apple tweaks UI, but the logic stays the same.

1. Sign into App Store Connect.
2. Go to My Apps and select the app you want to monetize.
3. In the left sidebar, open Subscriptions (or In‑App Purchases → Auto‑Renewable Subscriptions, depending on Apple’s current layout) under the Features or Monetization area.
4. Confirm your role has permission to Create and Edit in‑app purchases. If you only see greyed‑out buttons, it is likely a role/permission issue, not a bug.

This is the control center you will use for:

• Creating and naming subscription groups.
• Adding individual subscription products and durations.
• Setting pricing, trials, and introductory offers.
• Checking product status (e.g., “Ready to Submit,” “Waiting for Review,” “Approved”).

A quick sanity check: if you do not see “Auto‑Renewable Subscription” as an option when adding a product, you either picked the wrong app type, or your agreements/region do not allow it yet.

Subscription groups are where your business model and Apple’s rules meet. A subscription group is a set of related subscriptions (for example, Basic / Pro / Team) where each user can only have one active subscription at a time. Upgrades, downgrades, and crossgrades all happen inside that group.

A simple rule: if you are shipping one product with different levels of access, you almost always want one subscription group. Multiple groups only make sense if you have truly separate products that should not share trials or upgrade paths—for example, a meditation app and a separate kids’ content app that just happen to live in the same binary.

Inside a group you:

• Define the tiers (for example, “Starter,” “Pro,” “Business”).
• Rank them so Apple knows what counts as an upgrade versus a downgrade.
• Set how upgrades, downgrades, and crossgrades behave (immediate vs at renewal, whether users get prorated credit).
• Decide how free trials and introductory offers should apply at the group level.

The group‑level trial rule is the one that surprises teams: a user who has already used a free trial in a group is not treated as “new” just because you move them to a different SKU in that same group. They only get one “first‑time” trial per group.

Some practical patterns we use with clients at AppMakers USA:

• Start with one group and two tiers (Monthly and Yearly, or Standard and Pro) unless you have strong evidence you need more complexity.
• Use tier names based on value, not price (for example, “Pro Access,” not “$9.99 Plan”).
• Keep upgrade logic simple: upgrades apply immediately with prorated credit; downgrades take effect on the next renewal.
• Treat offer logic like security rules: make it hard to bounce between SKUs purely to farm trials.

Once the group is structured well, everything downstream—pricing, offers, analytics—becomes easier to reason about.

Now that your groups are structured, you can stop arguing about tiers and define the actual products. With groups in place, you can add the actual subscription products users will buy.

In App Store Connect → My Apps → [Your App] → Subscriptions:

1. Open your subscription group and click Add.
2. Set a Reference Name that your team can understand later (for example, “Premium Monthly – Global”).
3. Define a Product ID that you will reference in code (for example, com.yourcompany.yourapp.premium.monthly). This ID is permanent once you ship; do not reuse IDs or change naming patterns halfway through a project.
4. Choose a duration (1 month, 3 months, 6 months, 1 year, etc.) and attach the product to the right group.

Now handle the metadata that actually gets you through review:

• Add at least one localization with a clear display name and description. The text should match your in‑app paywall language closely enough that a reviewer is not confused.
• Set a group display name that will make sense if Apple shows it to users (for example, “YourApp Premium Access”).
• Upload required assets: a 1024×1024 subscription icon and any subscription screenshots the current guidelines require.
• Check for consistency: prices, benefits, and terms should not contradict what is shown inside your app.

Most of the painful rejections we see are not about StoreKit. They are about missing localization, vague descriptions, or metadata that does not line up with what the product actually does. When we are working with teams using GoodBarber, we also keep the subscription names, pricing, and terms in the GoodBarber back office in lockstep with App Store Connect so review is not looking at two different stories for the same paywall.

Now that your metadata is ready, you can move from “what exists” to “what it costs.” This is where you set concrete subscription price tiers and decide how trials and introductory offers work so users know exactly what they are paying for and when.

Remember that you cannot sell subscriptions at all until the Paid Apps agreement is active and your tax and banking setup in App Store Connect is complete. From our side at AppMakers USA, the apps that perform best treat this as a pricing strategy exercise, not just another form to fill out. To keep it manageable, think about it in two passes: first, how you configure subscription price tiers, and second, how you design trials and offers so they support that structure instead of fighting it.

Configuring Subscription Price Tiers

Apple uses a price tier system rather than arbitrary prices. You pick a base tier in your primary currency, then either accept Apple’s regional conversions or override specific countries where you want custom pricing. Avoid regional overrides unless you have clear requirements, like local regulations, competitive pressure, or a specific positioning goal in that market. You do not need to out‑optimize the entire planet. You need pricing that supports your unit economics and makes sense to your audience.

Within each subscription group, price and value should line up cleanly. The top tier in the group should be the richest plan, with lower tiers stepping down in benefits in a way that still feels fair. In App Store Connect you can:

• Pick price points per country or region from Apple’s standard ladder of 800+ price options, with up to 100 premium tiers available if you qualify.
• Define one active subscription per group per user so upgrades and downgrades replace each other instead of stacking.
• Schedule price changes and decide whether to preserve legacy pricing for existing subscribers.

Remember: Apple takes around 30% of the first year and 15% after that for eligible subscribers. That means your ARPU math should assume you are keeping roughly 70–85% of the list price after Apple’s cut. Before you commit to big price jumps, keep in mind that certain increases are effectively one‑way; once you move a live plan to a higher price, you cannot simply roll it back without careful handling of existing subscribers.

A simple, durable structure we come back to often:

• A monthly subscription as the default entry point.
• A yearly subscription with a clear, honest discount.
• Optional quarterly plan if your usage pattern has a natural three‑month cycle.

Designing Trials and Offers

Trials and introductory offers sit on top of core pricing; they do not rescue a weak value proposition. Average iOS prices have crept up year over year, but about 82.3% of App Store transactions still happen without any offer attached, which tells you most of the work is done by the base price and perceived value. Trials should confirm that your price makes sense, not hide it.

A simple way to think about them:

• Day 0 conversion is where a lot of the action is. It is common to see 80%+ of trial starts driven by the very first paywall experience a user sees.
• Match trial length and offer depth to how long it takes a reasonable user to feel the product’s value.
• Pair trial types with tiers, so different segments have a sensible entry point.

Rough patterns we have seen work across projects:

Avoid weekly plans; long‑term retention often hovers around 3–6%, and they tend to attract churn‑heavy users who create more support load than they are worth. When we do run experiments at AppMakers USA, we A/B test structures in soft‑launch markets first, then localize offers by region and acquisition cost before rolling anything out broadly.

Whatever you choose, keep an eye on the right numbers: customer acquisition cost, lifetime value, trial start rate, trial‑to‑paid conversion, and post‑trial churn. Those tell you whether the pricing and offers you picked are actually working or just looking good in a spreadsheet. Treat this entire section as a business decision, not a UI detail. You are deciding who you want to attract, how you want them to pay, and what behavior you are rewarding. Once those basics are solid, you can layer in AI‑driven matchmaking to suggest the right tier or feature bundle for different user segments instead of blasting everyone with the same generic upgrade.

Once the business rules are in place, StoreKit is the bridge between App Store Connect and your app.

With StoreKit 2, the flow looks roughly like this:

1. Use Product.products(for:) with your product IDs to fetch available subscriptions.
2. Render a paywall that uses the real product data (names, prices, durations) instead of hard‑coding values.
3. When a user taps a plan, call product.purchase() and handle the result (success, cancellation, or error).
4. Listen to Transaction.updates so you can respond to renewals, upgrades, downgrades, refunds, and revokes while the app is running.
5. When a transaction is verified, unlock entitlements in your app and finish the transaction so StoreKit knows you have handled it.

For more serious products, you do not want all of this logic living only on device. A server‑side component that can:

• Validate receipts,
• Maintain its own view of who is entitled to what,
• And expose that to your apps via a simple API,

makes it much easier to support multiple platforms, multiple devices per user, and cleaner account recovery. In practice, we often lean on Firebase or similar backend tooling to centralize receipt validation and entitlement checks instead of reinventing yet another backend from scratch.

If you are early, you can start with on‑device verification and a thin abstraction layer around entitlements. Just design that layer so you can move the logic off‑device later without rewriting your whole app. 

Developers often choose engines like Godot or Unity based on project size and cost, and the same thinking applies here: pick tools you can afford now, but plan for where they need to be when usage ramps. Our team also recommends planning for cloud scalability early so your subscription infrastructure can grow with your user base instead of becoming the bottleneck.

Subscriptions that look fine in a demo can still fall apart once renewals, upgrades, and cancels start happening. That is what sandbox is for.

A clean test setup looks like this:

1. In App Store Connect → Users and Access → Sandbox, create Sandbox Testers with emails that are not tied to real Apple IDs.
2. On a test device, enable Developer Mode. Sign out of your personal Apple ID under Settings → App Store so you do not accidentally buy anything for real.
3. Trigger a purchase in your app, then sign in with the sandbox account when prompted. Verify that the correct product, price, and trial/offer details appear.
4. Use Apple’s accelerated renewal schedule (for example, a “month” renewing every few minutes) to watch renewals, expirations, and grace periods play out quickly.

Then run the scenarios you will actually see in production:

• A new user starting a free trial, then converting, then canceling.
• A user upgrading from a lower tier to a higher one and getting prorated correctly.
• A user downgrading and seeing the change apply at the next renewal instead of instantly losing features.
• Subscriptions expiring and your app gracefully locking premium features without breaking the core experience.
• Failed payments or interrupted purchases and what your UI does when things do not complete cleanly.

Most of the broken subscription flows we inherit come from teams that only ran the first purchase once and never looked at what happens three or four renewals later.