What is In-App Purchases?
In-app purchases are transactions made inside a mobile application for digital content, features or subscriptions, processed through the platform's own payment system. They cover consumables, non-consumables and auto-renewing subscriptions, and the detail that decides a business model is the store commission, the reduced rate on long-lived subscribers, and where a purchase may legally be made outside the app. In 2016, the year after launch, Sweat with Kayla, built by PixelForce, generated more revenue than any other fitness app.
As of August 2026, United States apps may link out to an external checkout for digital purchases without paying Apple a commission, following the April 2025 court ruling in Epic Games v Apple, while in the European Union the same steering is permitted under the Digital Markets Act through Apple's external purchase link entitlement and its associated fee terms.
How do in-app purchases work?
In-app purchases (IAP) allow users to buy digital goods, features or subscriptions from within an application after they have installed it. On iOS and Android, these transactions are processed through the platform's own billing system - the App Store or Google Play - which handles payment, receipts and, for subscriptions, renewals. The app requests a product, the store presents the purchase flow, and the platform confirms the transaction back to the app so the content can be unlocked.
Because the platforms manage billing, they also take a commission and enforce rules about what may and may not be sold through IAP. Digital content typically must use the store's billing, while physical goods and services are usually handled by external payment providers instead.
Why in-app purchases matter
In-app purchases let an app stay free to download while still earning revenue, which lowers the barrier to acquiring new users in the first place. Done well, they align income with value: users pay at the moment they reach a feature worth paying for, rather than being asked to commit before they understand the product. This model underpins much of the modern app economy, from recurring subscriptions to consumable currencies, and is often far more sustainable than relying on a single upfront purchase price.
What are the types of in-app purchases?
The platforms define several distinct product types:
- Consumables - used up and bought again, such as in-game coins or credits.
- Non-consumables - bought once and kept permanently, such as unlocking a premium feature.
- Auto-renewable subscriptions - recurring access that renews automatically, such as a monthly plan.
- Non-renewing subscriptions - access for a fixed period that does not renew on its own.
Best practices for in-app purchases
Make the value obvious before asking for payment, and avoid aggressive prompts that erode trust. Follow each platform's billing rules precisely, since violations risk rejection or removal. Handle edge cases properly - restoring purchases, failed payments and subscription lapses - because broken purchase flows cost both revenue and reputation. Test thoroughly with sandbox accounts before release, and treat receipt validation as a security requirement, not an afterthought.
What do the app stores charge on in-app purchases?
The commission is the single figure that decides whether an in-app purchase business model works, and it is not one number. These are the rates that apply in Australia and most markets as at August 2026:
| Situation | App Store | Google Play |
|---|---|---|
| Standard rate on digital purchases | 30 percent | 30 percent on annual earnings above USD 1 million |
| Smaller and new developers | 15 percent under the App Store Small Business Program, for developers with up to USD 1 million in proceeds in the prior calendar year | 15 percent on the first USD 1 million of annual earnings |
| Auto-renewing subscriptions | The developer receives 70 percent of the price during a subscriber's first year, rising to 85 percent after one year of paid service | 15 percent on auto-renewing subscription products |
Two consequences follow from that table and both change product decisions. First, the subscription rate improves with subscriber tenure on the App Store, so churn costs more than the lost subscription alone - it resets a subscriber who was about to become 15 percent cheaper to serve. Second, free trials do not count towards that year of paid service, so a long trial delays the better rate as well as the revenue.
Rates and eligibility change, and they now differ by region: Google Play moved the European Economic Area, the United Kingdom and the United States onto a separate fee structure on 30 June 2026, and Apple operates alternative terms in the European Union. Confirm the current terms for your markets during planning rather than modelling from a rate you read once.
Which in-app purchase model fits your app?
The product types are fixed by the platforms, but choosing between them is a business decision about how value arrives over time.
| Model | Suits | Revenue shape | Where it goes wrong |
|---|---|---|---|
| Consumables | Games, credits, boosts, one-off unlocks of a quantity | Spiky, tied directly to usage | Pricing and balance need constant tuning, and a user can spend to zero and stop |
| Non-consumables | Unlocking a premium feature, removing advertising | One payment per user, ever | No recurring revenue to fund maintenance, and restore-purchase must work on every device the user owns |
| Auto-renewable subscriptions | Content that keeps arriving - workouts, courses, media, tools used weekly | Predictable and compounding | Churn, trial abuse, and the higher first-year commission |
| Non-renewing subscriptions | Seasonal access, a fixed-length programme or course | One payment for a defined period | You own the renewal reminder - the store will not send it, so lapse is silent |
In practice most products combine a free tier with one of the above, and the decision that moves revenue most is not the model but where the paywall sits relative to the moment the user first gets something out of the app. A paywall before that moment converts the small group who already trusted you; a paywall just after it converts the group who have seen the value.
What breaks in-app purchases in production?
Purchase flows fail in a small number of predictable ways, and each of them costs real revenue because it fails at the exact moment a user was trying to pay.
- Entitlement stored only on the device. If "has paid" lives in local storage, it is lost on reinstall, absent on the user's second device, and editable. Entitlement belongs on your server, derived from the store's own record.
- Receipt validation done client-side or not at all. Validate with the store's server, and treat the store as the source of truth for whether a subscription is currently active.
- No restore path. Both platforms require a way for a user to restore previous purchases, and a missing or broken restore is both a support burden and a common review rejection.
- Renewal states ignored. Billing retry, grace periods, price-increase consent and cancellation-but-still-active all exist, and an app that treats a subscription as simply on or off will lock out paying users during a retry window.
- Sandbox behaviour mistaken for production. Test subscriptions renew in minutes rather than months and use separate receipts, which makes lifecycle bugs easy to miss. Test every state deliberately: purchase, restore, decline, expiry, refund.
- Prices set once in one currency. Store pricing is per-territory, tax is handled by the platform, and a product configured only for a home market is invisible or mispriced everywhere else.
How PixelForce approaches in-app purchases
At PixelForce, monetisation is shaped during Phase 1 Scoping and Design, so the purchase model fits the product and the audience rather than being bolted on at the end. Our in-house Adelaide team has built revenue-generating apps at scale, including SWEAT, which grew from MVP to a $400M exit with tens of millions of users. We implement IAP against current platform rules, validate receipts securely, and design flows that respect the user. Choosing a monetisation strategy is rarely a single answer, which is why related concepts are covered in app monetisation, and broader product strategy sits within our MVP app development work.
Where this applies
The PixelForce services where In-App Purchases matters most - explore how we put it to work in client products.
Frequently asked questions
Subscriptions are one type of in-app purchase. The broader category also includes consumables, which are used up and rebought, and non-consumables, which are bought once and kept forever. Subscriptions specifically grant recurring access that renews on a schedule, such as monthly or yearly. So every subscription is an in-app purchase, but not every in-app purchase is a subscription.
Yes. Both the App Store and Google Play charge a commission on digital purchases processed through their billing systems, with reduced rates available to smaller developers and for subscriptions held over time. Physical goods and certain services are generally exempt because they must use external payment providers. Because rates and rules change, it is worth confirming the current terms during planning.
It depends on what you are selling. Digital content consumed within the app generally must use the platform's billing system. Physical goods, real-world services and some other categories are usually required to use external payment providers instead. The rules are platform-specific and evolve over time, so the correct approach for your product should be confirmed before build to avoid rejection.
Both platforms provide sandbox environments and test accounts that simulate purchases without real charges. You configure your products in the store console, then verify each flow - buying, restoring, failed payments and subscription renewals - using these test accounts. Thorough sandbox testing is essential, because purchase bugs discovered in production cost revenue and frustrate paying users who expect transactions to work reliably.
A subscription only works if something keeps arriving - new workouts, new content, new features, or a service that runs continuously. If the app is finished at launch and does not change, a subscription is a promise you have to keep funding, and users notice within two billing cycles. A one-off non-consumable suits a tool whose value is the tool itself, at the cost of having no recurring revenue to pay for maintenance and platform upgrades. Most products land on a free tier plus a subscription because that funds the ongoing work the app stores require anyway.
Assume 70 percent as the planning figure, and improve on it deliberately. The standard store commission on digital purchases is 30 percent. The App Store Small Business Program reduces that to 15 percent for developers with up to USD 1 million in proceeds in the prior calendar year, and Google Play charges 15 percent on the first USD 1 million of annual earnings. On the App Store, subscription revenue rises from 70 to 85 percent of the price once a subscriber has accumulated one year of paid service. Payment processing, tax and refunds come out before you see it, so model net revenue rather than gross from the first spreadsheet.
Yes, and it is one of the more common monetisation strategies - the app stays free, and the subscription is sold on the web at a price that does not carry a store commission. What has changed recently is whether the app may point users there. Following the April 2025 ruling in Epic Games v Apple, United States apps may link out to an external checkout for digital purchases without paying Apple a commission, and in the European Union similar steering is permitted under the Digital Markets Act through Apple's external purchase link entitlement and its fee terms. Elsewhere the rules are stricter. Confirm the position for each market you sell in before designing the flow, because this is the area of store policy changing fastest.
After the user has experienced something worth paying for, and before the effort they have invested is wasted. That usually means letting them complete one real action - finish a workout, generate one result, save one item - then asking. Placing the paywall on the first screen converts only the users who already decided before installing, and it makes every acquisition dollar work harder than it needs to. The specific placement is worth testing rather than reasoning about, which is what A/B testing is for.
Within a platform it carries over, because the subscription belongs to the store account rather than the device - as long as your app has a working restore-purchases path and reads entitlement from your server rather than local storage. Across platforms it does not: an App Store subscription is invisible to Google Play and the reverse. Supporting a user who buys on iOS and later switches to Android requires your own account system, with the store purchase linked to that account, so entitlement is something you own rather than something the platform tells you. Decide this before launch, because retro-fitting accounts onto an anonymous user base is a migration rather than a feature.
Last reviewed:
Have an idea worth building?
Whether you are validating a concept or scaling a product, our Adelaide team can scope it properly. Book a free consultation and we will map the fastest path from idea to launch.
- Top Clutch App Development Company · Australia
- 100% in-house · Adelaide HQ
- 100+ products shipped
- 99.99% crash-free