In-App Purchases and Subscriptions: The Complete Publishing Guide

In-App Purchases and Subscriptions: The Complete Publishing Guide

Monetizing through in-app purchases or subscriptions is one of the most common reasons apps get rejected on first submission.

Not because the monetization model is wrong. Both Apple and Google actively support and benefit from subscription revenue. The rejections come from how the payment flows are implemented, how the terms are presented, and how the store products are configured — all of which have specific, non-negotiable requirements that most developers encounter for the first time during review.

This guide covers everything you need to get a monetized app through review cleanly.

The Non-Negotiable Rule

The single non-negotiable rule across both platforms: digital content and features delivered within the app must be purchased through the platform's own payment system. Apple's StoreKit / In-App Purchase framework. Google Play Billing Library.

There are no exceptions for "we'll add it later" or "we use Stripe for everything else." If your app offers a subscription that unlocks in-app features and you route the payment through an external system, it's a rejection. Every time.

Setting Up Products in App Store Connect

Creating In-App Purchase Products

Before you submit an app with IAP, every purchasable product must be created in App Store Connect under your app's "In-App Purchases" section. You need to create each product, give it a reference name, a product ID, a pricing tier, and a display name and description that will appear to users at purchase time.

The product description is reviewed. Vague descriptions like "Premium Access" get more scrutiny than specific ones like "Monthly subscription — unlimited access to all workout plans." Be accurate and specific about what the user is buying.

Subscription Configuration

Auto-renewable subscriptions require additional configuration: a subscription group (which organizes your subscription tiers), a promotional offer setup if you're using free trials, and a renewal date display configuration.

Free trials must be configured as introductory offers in App Store Connect — not as a separate product. The trial duration, post-trial price, and billing period are all configured here and must match what you display in-app before the user confirms.

Setting Up Products in Google Play Console

Google Play uses a similar but differently named system. In-app products are configured under the app's "Monetize" section in Play Console. You create Products for one-time purchases and Subscriptions for recurring billing.

Google Play's subscription system supports base plans (the core billing schedule) and offers (free trials, discounts, introductory pricing). These are configured as separate components linked to the subscription product — a more flexible but more complex system than Apple's.

What the Review Team Tests in Payment Flows

Reviewers complete test purchases as part of the review process. The sandbox environment for both platforms lets reviewers test payment flows without real charges. Here's exactly what they verify:

  • Price and billing period are clearly displayed before the user confirms the purchase
  • The payment is processed through the platform's own framework — not redirected externally
  • A subscription management option is accessible from within the app
  • A working Restore Purchases mechanism exists and functions correctly (iOS requirement)
  • Free trial terms — trial duration, post-trial price, cancellation method — are clearly communicated before the user opts in
  • No dark patterns hide the recurring nature of a subscription

The Restore Purchases Requirement (iOS)

This is the single most commonly missed requirement for subscription apps on iOS.

Apple requires that any app with in-app purchases or subscriptions provide a mechanism for users to restore their purchases if they reinstall the app, switch devices, or log in on a new phone. This is typically a "Restore Purchases" button somewhere in settings.

The implementation is straightforward — a single call to StoreKit's restore API. But it's easy to forget if you're building quickly, and its absence is an automatic rejection.

Handling the 30% Platform Fee in Your Pricing

Both platforms take a 30% commission on in-app purchase and subscription revenue. This reduces to 15% for apps in Apple's Small Business Program (under $1M annual revenue) and for Google Play's equivalent program, and reduces to 15% after the first year of a subscriber relationship on both platforms.

The practical implication for pricing: if your target revenue is $10 per user per month, your in-app subscription price needs to be $14.29 to net $10 after Apple or Google's share. Build this into your pricing model before you set prices — changing subscription prices after launch is possible but requires careful communication with existing subscribers.

Pre-Submission Checklist for Monetized Apps

Before submitting any app with in-app purchases or subscriptions:

  • All products configured in App Store Connect or Play Console with accurate descriptions
  • Payment uses Apple IAP / Google Play Billing — no external payment links for digital content
  • Price, billing period, and terms visible before purchase confirmation
  • Free trial duration and post-trial price clearly displayed
  • Restore Purchases button present and functional (iOS)
  • Manage Subscription accessible from within the app
  • At least one meaningful free feature available before hitting a paywall

How Froxi AI Handles Subscription Apps

When you indicate during Froxi AI's intake that your app has a subscription or in-app purchases, the guide generates the complete payment compliance checklist — including the product setup steps, the required terms disclosure configuration, and the platform-specific items like Restore Purchases that are easy to miss.

The guide also covers what to test in the payment flow before submission and what reviewers will specifically check. For subscription apps that have been rejected, the Rejection Resolver identifies which payment-related guideline was violated and the exact configuration change required.

Our Latest Blog