How to Add Subscriptions to a V1 App (and What to Skip)

The short version

For each area, here is what to build for launch and what to leave for later. The first half of each line decides whether people can pay and keep access fairly. The second half only helps once you have paying users to learn from.

• Plans. Build for launch: one subscription group, a monthly and a yearly plan. Leave for later: extra plan types and regional pricing experiments.
• Sharing. Build for launch: a sharing decision for each product. Leave for later: group seats sold to teams or households.
• Paywall. Build for launch: a line saying what each plan includes, and whether it can be shared. Leave for later: promo codes, win back offers and cancellation offers.
• Access. Build for launch: access that ends on expiry, refund or revocation. Leave for later: bundles across several apps.
• Restore. Build for launch: restore purchases on a new device. Leave for later: custom analytics dashboards for churn.
• Testing. Build for launch: real tests on every purchase path. Leave for later: A/B tests on paywall design.

1. One subscription group with two plans

On iOS, subscriptions belong to a subscription group, and a user can only hold one active plan in a group at a time. For a v1, one group with a monthly and a yearly plan covers most cases. Every extra plan means another price to defend, another product to test and another line on your paywall for users to compare. If you can't decide between two prices, launch with one and change it later. Changing a price costs less than removing a plan people already pay for.

2. Decide on Family Sharing product by product

Apple lets auto-renewable subscriptions and non-consumable purchases be shared with up to five other family members. It is off by default, and you turn it on one product at a time in App Store Connect. Once it is on for a product, you can't turn it off. Adapty's Family Sharing docs and RevenueCat's Apple Family Sharing guide both cover this. For a v1, the safe default is simple: leave sharing off unless sharing is part of your offer. A meal planner for households might want it. A personal fitness coach probably doesn't. You can add a separate shareable plan later, but you can't take sharing back from a plan that already has it.

3. Say on the paywall what each plan includes

Users decide in a few seconds. Each plan on your paywall needs one line that says what it unlocks. If a plan can be shared with family, say so. On iOS, your app can read this from the product itself (isFamilyShareable in StoreKit), so the label stays right even if you change settings later. A good v1 paywall fits on one screen: the plans, what each one includes, the price as the store shows it, a subscribe button and a restore link.

4. End access when it should end

Founders skip this part more than any other, and it costs money. Your app needs to listen for these changes. If you have a server that unlocks content or features, it has to process the same events from the App Store, including the revocation notice Apple sends when shared access ends. A subscription tool like RevenueCat can handle much of this for you, but someone still has to check that your app actually locks the feature. Access should stop when:

• The subscription expires and isn't renewed.
• The buyer gets a refund.
• A family member loses shared access because the buyer stopped sharing or left the family group.

5. Restore purchases

A user who changes phones should get their plan back with one tap. App Review expects a restore option for purchases that can be restored. Put it on the paywall and in settings. Halfway through and unsure which of these your app needs? Book a free 30-minute call and bring your questions.

What to leave out of v1

Stores offer extra subscription options, such as offer codes and cancellation offers. Each one suits a specific app at a specific stage. None is needed to take your first payment. A useful rule: add a subscription feature when a real user problem points to it. Until then, every extra option is more code to maintain and a decision made without data. To estimate what the stores take from each sale before you set prices, use our App Store fee calculator. If you're still choosing between subscriptions, one-time purchases or ads, try the app monetization quiz. Some examples:

• Users ask to share with a partner or team. Now consider a shareable plan or seats.
• Many users cancel in the first month. Now consider offers, after you've looked at why they leave.
• Users in one country find the price too high. Now consider regional pricing.

Test every path before you submit

A quick tap test won't catch the ways subscriptions break. Before you send your build to review, run each path on test accounts. If any plan is shareable, use a sandbox family group too:

• A new user subscribes and the paid feature unlocks straight away.
• The subscription expires and the feature locks again.
• A refund removes access.
• If a plan is shareable: a family member gets access, then loses it when the buyer stops sharing.
• Restore purchases works on a second device.
• Each plan shows the right price and the right label.
• The app works offline after purchase and doesn't lock out a paying user.

One App Store rule to plan around

The first subscription in your app has to be submitted for review together with a new app version, as App Store Connect Help explains. After that first approval, you can add more subscriptions without a new version. So set up your plans before your launch build, not after it.

Web and Android: keep one source of truth

If your app runs on iOS, Android and the web, a user who pays on one should get the same features on the others. The simplest v1 setup gives each platform its own checkout (App Store, Google Play, Stripe on the web) and one place that decides who has access. Tie access to the user's account, not to the device. Don't build three paywalls with three different plan lists. Keep the same plans, the same names and the same features everywhere, even if prices differ by store.

Where this fits in your build

Subscriptions are one part of a v1, not a project of their own. In our MVP Development package, auth, onboarding, payments and design are part of the build, and it is Fixed at $3,460. Mobile builds include push and RevenueCat or Stripe when you sell, TestFlight + Play submission support, and 100% GitHub ownership + 2-week fixes. If you're still working out the whole product, start with our guide on how to build an MVP. If your app is already live and you need subscriptions added, Continuous Growth Support is the better fit. For more on StoreKit, TestFlight and App Store launches, see our iOS and Apple guides.

How many subscription plans should a v1 app have?

Usually two: monthly and yearly, in one subscription group. Add more only when users ask for something those two plans don't cover.

Should I turn on Family Sharing at launch?

Only if sharing is part of what you sell. You choose it product by product, and once it is on for a product you can't turn it off. Leaving it off at launch keeps your options open.

Can I add subscriptions after my app is already live?

Yes. On iOS, though, your first subscription has to be submitted with a new app version, so plan it into a release instead of adding it on its own.

Do I need a server to handle subscriptions?

Not always. A subscription tool can track who has access. If your server unlocks content or features, it also has to know when access ends, including after refunds and lost family access. Want subscriptions built into your v1, with a fixed price agreed before any code? Book a call.