You built your first app. People are downloading it. Now you need a way to charge for it, and every mobile platform has specific rules about how money changes hands inside an app. Get this wrong and your app may get rejected from the store before a single user pays you.
In-app purchases (IAPs) decide how you charge, what fees you pay, and which review rules apply before launch. You need the right product type, a pricing model that fits your stage, and a setup that passes review. First-time builders who understand IAP types, fees, and compliance rules before launch can avoid common rejection issues and start earning faster.
What an in-app purchase actually is
An in-app purchase is any transaction where a user buys digital content, features, or services inside your app after downloading it. Both platforms control how digital payments happen inside the app, which decides when platform billing applies and what flow your code needs to handle.
Instead of charging upfront, you let people download for free. Then you offer paid upgrades, subscriptions, or virtual items within the experience.
On iOS, payments run through StoreKit. On Android, Play billing handles the same function. You configure products and prices in the store dashboard. The platform processes the transaction, takes a commission, and deposits the rest in your developer account.
Both platforms require you to use their billing systems for digital goods. You can not send users to Stripe, PayPal, or your website to pay for digital content sold inside the app. Physical goods and services like food delivery or merchandise are generally not subject to these in-app purchase requirements.
4 types of in-app purchases on Apple, 2 on Google
The product type you choose affects restore behavior, renewal logic, and how users experience your paywall. Apple gives you 4 IAP types, while Google uses 2 broader categories. That difference changes how much logic your app needs to handle, so map your offer to the right product type before you build the paywall.
Apple's 4 IAP types
Consumables get used up and need to be purchased again. Game coins, AI message credits, and extra lives all fit here. Users can buy the same item multiple times, and the item disappears after use. Your app tracks usage.
Non-consumables are one-time purchases that last indefinitely. A "remove ads" upgrade, a premium template pack, or a full app upgrade are typical examples. These are restorable across a user's Apple devices. You can also offer discount codes for non-consumables.
Auto-renewable subscriptions charge users on a recurring schedule until they cancel. Monthly fitness app access, annual productivity tools, and weekly AI content plans fall into this category. Apple manages billing recovery if a payment fails.
Non-renewing subscriptions provide time-limited access that expires without auto-renewal. A seasonal sports stats pass or a 3-month course bundle would use this type. Users must manually repurchase to continue.
Google's simpler structure
Google Play offers in-app products and subscriptions. Within in-app products, it distinguishes between consumables and non-consumables. Google does not split one-time products into consumable and non-consumable at the configuration level. Whether an item depletes after use or lasts indefinitely depends on your app logic, not the store setup.
For subscriptions, Google Play works similarly to Apple's auto-renewable model. There is no formal non-renewing subscription type on Google Play.
Here is how the main types compare across platforms:
- Consumable (Apple): does not renew, does not last forever, does not auto-restore on a new device.
- Non-consumable (Apple): does not renew, lasts forever, auto-restores on a new device.
- Auto-renewable subscription (both platforms): renews automatically, lasts per billing period, auto-restores on a new device.
- Non-renewing subscription (Apple only): does not renew, lasts a fixed duration, does not auto-restore.
What Apple and Google charge you per sale
Platform fees shape your pricing before you earn your first dollar. Smaller developers may qualify for lower rates, but those lower rates often require enrollment or accepted terms. Review the fee programs before you publish paid products so you do not learn too late that you missed a program or terms acceptance step.
Apple's fee structure
Apple's default commission is 30% of every purchase.
The Small Business Program drops that to 15% if your total App Store earnings were $1 million or less in the previous calendar year. You must actively enroll. It is not applied by default.
For subscriptions, 15% applies at every billing cycle for enrolled Small Business Program developers. Standard developers pay 30% during a subscriber's first year, then 15% from year 2 onward.
Google's fee structure
Google Play's fee guidance outlines how fees vary by eligibility and revenue tier. The relevant points for smaller developers are these:
- Developers earning under $1 million per year pay 15% on the first $1 million of annual revenue.
- Subscriptions for developers are typically 15%.
- Google Play service fees for standard in-app purchases vary by app eligibility and revenue tier.
The practical takeaway is simple: review your eligibility and accept any required terms before you publish paid products. Apply for Apple's Small Business Program before you launch. That can reduce your commission immediately if you qualify.
How to pick the right monetization model for your first app
Your revenue model decides how easy it is to explain your offer, convert early users, and support the product over time. For most first launches, a simple model is easier to price and test than a layered setup, which is why many builders start small and add complexity later.
With fee structures understood, the next decision is which model fits your app and your stage as a builder. A pricing breakdown from the indie builder community suggests starting simple and layering complexity over time.
One-time purchases for validation
Start here if you have not proven people will pay for your app. A single non-consumable purchase, like a "Pro Upgrade," tests willingness to pay with minimal friction. One builder shared an example of validating a macOS developer tool with a $9 lifetime purchase before expanding further.
The downside is that sustained revenue from one-time purchases alone may be harder unless you rank in the top 5 for high-traffic search terms in the App Store.
Subscriptions for recurring revenue
Subscriptions can offer predictable cash flow, which is one reason solo operators often prefer them. Revenue compounds as you retain subscribers. Lower subscription fees may also make this model more attractive on some platforms.
The tradeoff is higher conversion friction. Users must justify an ongoing payment. You must continuously deliver value to prevent cancellations.
Freemium with feature unbundling
Selling individual features reduces the barrier to entry. One builder shared this pricing example:
- Free: writing, saving, spell-check
- $2: grammar check
- $1: PDF export
- $20: all features included
This structure lets users pay incrementally for what they value, which can reduce purchase friction early.
When to use ads
Only 24% of US apps include advertising. For many first-time builders, ads work better as a secondary model. Sell a "remove ads" non-consumable as an upsell rather than relying on ad revenue alone.
Pricing tactics that do not require code
You can improve conversion before you redesign your paywall or change app logic. Pricing changes in the store dashboards are often the fastest tests to run, so start with the adjustments that change perception without changing the product itself.
Smart pricing decisions can increase conversions without touching technical configuration. These tactics apply inside App Store Connect and in Google Play Console.
Anchor with a higher tier first. Show your most expensive option before the monthly plan. When users see annual pricing before monthly pricing, the monthly price often feels more reasonable by comparison.
Frame subscriptions by their smallest unit. A daily framing can feel lighter than a monthly framing, even when the total price is identical.
Set custom prices per country. Both Apple and Google let you set different prices for different regions. Default pricing and currency presentation can affect how customers perceive the cost of your app in different markets. Adjusting local prices is one of the highest-impact changes you can make with minimal effort.
Show value before the paywall. Payment requests should align with demonstrated value, not trigger arbitrarily. Trigger your upgrade prompt after your user's "aha moment," not before it.
Compliance rules that block app store approval
A strong pricing strategy does not matter if review blocks your release. Most rejection risk comes from configuration mistakes, missing disclosures, or purchase flows that do not match store rules. Fix those details before submission, not after review.
Rejection reasons often include configuration issues such as:
- Missing purchase information in the app metadata
- Incorrect App Store Connect setup
- Not attaching the IAP to the build
- Not using the proper in-app purchase flow
Subscription screen requirements
Subscription screens need clear pricing and purchase details before checkout. Making a per-day price prominent while minimizing the actual total charge can create review risk. You also need links to your Terms of Service and Privacy Policy in the app, and a way to restore previous purchases.
Free trial disclosure
When you offer a free trial, both the trial duration and price must appear on the same screen. Users can not be required to find another screen to learn what they will be charged.
Common rejection triggers and fixes
- IAP products not created before app submission. Create all products in App Store Connect and set them to "Ready to Submit" before submitting your app build.
- Reviewer can not reach the purchase screen. Include demo account credentials in your App Review notes.
- Price mismatch on Google Play. Prices shown in your app UI must exactly match Google Play Console configuration.
- Missing cancellation option on Android. Subscription users need a clear way to cancel from account settings, not just a support email. Review the cancellation requirements before launch.
These checks are easy to miss when you are focused on code. They are also easier to fix before review than during a rejected submission. If you may switch monetization models later, plan that transition before launch. That reduces the chance of confusing existing customers or creating entitlement problems inside your app.
How AI app builders handle in-app purchases
Billing code takes time, and first-time builders usually lose time in setup before they lose it in strategy. Tools that reduce that setup work can shorten the path to a working purchase flow. You still need to follow store billing rules, but you may need to wire up less infrastructure yourself.
Coding IAP from scratch typically requires working with StoreKit and the Play Billing Library directly. AI app builders can reduce some of that work by handling more of the app setup around billing flows.
Anything uses a two-track approach. For web apps, Stripe payments let you start charging without wiring up billing from scratch. For mobile, iOS deployment works via Expo with cloud-signed App Store submission, while Android is still in development.
Anything also includes built-in infrastructure such as:
- Payments
- Hosting
- Authentication
- Database management
That removes setup work that often slows first-time builders down, which means you can spend more time on pricing, entitlement logic, and review readiness.
The order is simple. Choose the right IAP type first. Then confirm your fees. Match the monetization model to your stage. Fix compliance details before submission.
If this approach fits your project, start building with Anything.
