You built an app you believe people will pay for. Once you charge for digital content, Apple requires in-app purchase, and the documentation is sprawling. Product setup also has to match your code exactly. For a solo developer with no server backend, this can look like a wall.
A shippable solo iOS purchase flow needs StoreKit 2, matching App Store Connect products, review-safe purchase rules, staged testing, and pricing based on proceeds instead of gross sales.
Small developers make up more than 90% of App Store developers and grew their earnings at 4.5 times the rate of large developers between 2020 and 2022. Modern StoreKit lets a solo developer ship a working paid app without a server, faster than most expect.
Why StoreKit 2 changes the math for solo builders
Most solo developers should start with StoreKit 2 because it removes server validation work and reduces the first paid-flow build to product lookup, purchase, and entitlement checks. You get a working iOS-only paid app without a backend project attached to it.
StoreKit 2 is the modern Swift-based In-App Purchase API, and it is the one you should use for any app targeting iOS 15 or later. Apple deprecated the original StoreKit 1 API. The new framework uses Swift concurrency with async/await throughout, which simplifies receipt-handling code.
StoreKit 2 supports on-device purchase validation and is simpler than the earlier framework, so you do not have to depend entirely on a server-side backend. For a solo operation, that removes the biggest infrastructure burden.
The API organizes around five areas:
- Products
- Purchases
- Transaction info
- Transaction history
- Subscription status
Focus on the functional pieces you need first.
- Products retrieve available items and their details from the App Store.
- Purchases initiate the purchase flow and return a result your app reads.
- Transaction info verifies and delivers the content the customer paid for.
Fetch what you sell, ask Apple to process payment, then grant access to the right entitlement.
Verification happens automatically
The App Store signs all StoreKit 2 transactions using JWS, so you do not need to manually verify a transaction; the framework handles that for you. New transactions also synchronize automatically across a customer's devices, so a purchase made on an iPhone shows up on the same person's iPad without extra work.
A minimal SwiftUI paywall
If you build with SwiftUI, the SubscriptionStoreView(groupID:) view does most of the work for you. It handles the full paywall, and Restore Purchases works automatically. For a solo developer trying to ship, this is the shortest viable path to a working paywall.
- It fetches products and renders the picker.
- It handles introductory offer eligibility.
- It shows renewal terms and presents the system payment sheet.
You get a system paywall before you design custom purchase screens.
One recent change to note: in iOS 18.4, Apple deprecated Transaction.currentEntitlement(for:) and replaced it with Transaction.currentEntitlements(for:), which returns an asynchronous sequence. A customer can now hold more than one entitling transaction, such as a personal subscription plus Family Sharing access.
What Apple actually takes from each sale
Price the product against proceeds instead of gross sales. Your product price is not your take-home amount. Apple's commission changes the math before taxes, refunds, or your own costs enter the picture.
Apple has announced a 25% standard rate for in-app purchase and paid app transactions. The Small Business Program rate will be a 12% reduced rate. The same 12% rate applies to subscription auto-renewals after the first year.
Be careful here. Some official documentation still lists 30% and 15%, so check the current active rate before you build any revenue projection.
The Small Business Program is built for you
If you are just starting, you almost certainly qualify for the reduced rate. The Small Business Program applies to developers who made up to $1,000,000 in proceeds across all apps in the prior calendar year. New App Store developers can qualify. Eligibility uses proceeds: sales net of Apple's commission and certain taxes.
A few terms matter as you grow:
- If you pass the proceeds threshold in the current year, the standard rate applies to future sales.
- If your proceeds drop back below the threshold, you can re-qualify the year after.
- Apple determines eligibility within 15 days of the end of each fiscal calendar month.
Track proceeds while you set prices.
To enroll, you must be the Account Holder. You also need to accept the latest Paid Apps agreement, Schedule 2, in App Store Connect. Then list any associated developer accounts.
Choosing the right product type
Choose the product type that matches what you sell. The product model controls how Apple treats access, renewal, and restoration. A permanent access purchase, a consumable credit pack, and a subscription all behave differently in review and in your app.
There are four product types, and picking the wrong one is a common source of confusion and rejection.
Customers use consumables once, then the app depletes them, like a pack of in-game currency. Customers buy non-consumables once, and access does not expire, like a permanent feature access purchase. Auto-renewable subscriptions give ongoing access that renews until canceled. Non-renewing subscriptions grant access for a fixed period with no automatic renewal.
For a solo developer, use consumables for repeat-use goods, non-consumables for permanent access, auto-renewable subscriptions for ongoing access, and non-renewing subscriptions for fixed-duration access.
Subscriptions get the most platform support
Auto-renewable subscriptions receive the most built-in support, so you get features without building them yourself.
- Billing Grace Period keeps subscribers in your paid content while Apple resolves a billing issue.
- Family Sharing lets a buyer share access with family members.
- Subscription Levels set upgrade and downgrade paths so you can offer basic and premium tiers.
- App Store Server Notifications send near-real-time updates for refunds and subscription state.
If your app sells ongoing access, subscriptions give you the most Apple-managed purchase behavior.
Configuring App Store Connect before you write code
Set up App Store Connect before you debug code. Administrative setup breaks many first IAP tests before StoreKit runs. Put these pieces in order first so account state does not look like an engineering bug.
- Active agreements
- Banking details
- Tax information
- Matching product IDs
- Clear product metadata
Before anything works in the sandbox, your agreements, banking, and tax information must be in order.
To offer in-app purchases, the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect and provide banking and tax details. The agreement must be Active before you can test IAP in the sandbox environment.
Follow this order before testing purchases.
- Accept the Paid Apps Agreement in the Business section.
- Design your IAP against the Human Interface Guidelines and App Review Guidelines.
- Configure products in App Store Connect.
- Set a reference name, product ID, price, availability, localized descriptions, and tax category.
- Build StoreKit purchase code, signing the app with a provisioning profile that includes the bundle ID and IAP capability.
- Test your purchases.
Creating a product
To create a product, open your app in App Store Connect, click In-App Purchases under Monetization, click the add button, select the type, then add a reference name and product ID and click Create. Subscriptions go a step further: you assign each one to a subscription group before adding name, price, and description.
Many builders trip over exact ID matching: the bundle identifier and product identifiers in Xcode must match App Store Connect exactly. You can create 10,000 IAP products per app, and changes to metadata may take up to an hour to appear in the sandbox.
Avoiding the rejections that delay launch
App Review needs to understand what the customer buys, how access works, and how your purchase model fits the rules. Make those details obvious before you submit.
One indie developer building an AI finance app went through two Apple rejections before going live. Check the purchase rules before your first submission.
Guideline 3.1.1 is the core rule. If you give access to features, content, or a full version inside your app, you must use IAP. You may not use your own mechanisms such as license keys, QR codes, or cryptocurrency wallets to give access to content. Related requirements matter just as much. Apple does not let purchased credits or in-game currencies expire, and you must provide a restore mechanism for restorable purchases.
Before launch, focus on these review traps.
- Unclear business models trigger delays. If Apple cannot understand how your app works, explain it in the metadata and App Review notes.
- Receipt code adds risk. For StoreKit 2 apps, use signed transaction data instead of adding receipt code by default.
Use clear review notes to help reviewers understand a valid purchase model.
Restore behaves differently than you expect
The app receipt is absent in Sandbox and TestFlight until the customer completed or restored a purchase. If your app finds no receipt, treat it as a new customer with no purchases. With StoreKit 2, you can often avoid a custom restore button. Calling Transaction.currentEntitlements at app launch retrieves the latest transactions, so no user-triggered restore action is required in many StoreKit 2 flows.
Pricing and paywall decisions that move revenue
Test whether users understand the value before they see the payment sheet. Pricing and paywall placement shape that moment.
Show value first, then ask for payment, because the user already understands why they need the app.
One indie developer behind the VibeLing app changed the paywall by replacing an explicit "Continue for free" button with a small, non-obvious X in the corner. Trial starts doubled from 2.5% to 5%, and the developer reported a sharp revenue increase after the change. Free tier framing follows the same logic: a free output that feels complete builds trust, while one that withholds the answer makes users bounce.
Trials, tiers, and localization
Test trial length. Curtis Herbert of the Slopes app uses a 7-day trial, with a conversion rate near 80% in early season, dropping to roughly 60% later, and refund requests consistently under 1%.
Price localization deserves a separate check. Median monthly subscription prices vary 2 to 3 times between countries, so prices often need local adjustment.
Testing your purchases before you ship
Move testing outward in stages so you can isolate StoreKit bugs before account state and App Store behavior enter the picture. Start locally, then use sandbox, then use TestFlight.
You can test the entire purchase flow before involving the App Store at all. There are three testing stages that build on each other, so start locally.
StoreKit Testing in Xcode is a local environment that needs no App Store Connect setup and no network connection. You create a StoreKit configuration file, select the StoreKit configuration in your scheme settings, and run in Simulator or on a real device. From there you can test receipt validation, promotional and introductory offers, interrupted purchases, renewals, and restoration.
Use this progression.
- Xcode testing validates your purchase logic locally with no account or network.
- Sandbox requires App Store Connect and adds server-side receipt validation and App Store Server Notifications, which are exclusive to this stage.
- TestFlight uses the sandbox environment to give external beta testers end-to-end coverage with no real charges.
Local purchase failures usually point to code. Sandbox-only failures usually point to account setup and product availability.
For sandbox testing, create a tester account under Users and Access, then Sandbox Testers in App Store Connect. If products fail to appear, review sandbox availability issues.
When native StoreKit is enough versus reaching for more
Native StoreKit 2 is usually enough when your app only sells on Apple platforms, checks entitlements on-device, and does not need purchase state coordinated with a separate backend. Add more infrastructure only when purchase state has to follow the user outside the Apple-only app.
Third-party purchase infrastructure becomes more relevant when you must sync purchase status across more systems, such as a web app and an iOS app sharing one subscription. For a solo project shipping an iOS-only app, the native path keeps your maintenance surface small and your dependencies few.
Administrative setup causes much of the friction in shipping a paid iOS app: active agreements, banking and tax details, matched product IDs, and clear review notes. Get those in order first, test locally in Xcode before touching the sandbox, and pick the simplest product type that fits what you sell.
If you want a faster first build, try Anything, our AI app builder. Describe your idea, refine it through prompts, and ship a working app with iOS deployment via Expo and cloud-signed App Store submission. If that fits your project, try Anything free and spend more time on the product decisions only you can make.
