# Native In-App Purchases in SwiftUI Without RevenueCat

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-02. 4 min read.
> Source: https://vp0.com/blogs/native-iap-swiftui-without-revenuecat

StoreKit 2 lets you ship in-app purchases with no third-party SDK. The catch: you own entitlement logic and server verification.

**TL;DR.** You can build in-app purchases in SwiftUI with StoreKit 2 directly and skip RevenueCat, which removes a dependency and a fee but means you own product loading, purchase, entitlement checks, restore, and server-side verification. Apple requires in-app purchase for digital goods, so route digital sales through StoreKit, verify transactions, and never charge cards yourself. Start the paywall UI from a free VP0 design.

You do not need RevenueCat to ship in-app purchases. StoreKit 2 gives SwiftUI a clean API to load products, run a purchase, and check entitlements, and for many apps that is enough. What you take on by going direct is the receipt and entitlement logic a service would otherwise own. VP0 is the free, AI-readable iOS design library builders start from for the paywall and purchase screens, so the storefront looks right while you wire StoreKit.

## Who this is for

You are building a paid feature or subscription in SwiftUI, maybe with Cursor or Claude Code, and you want native in-app purchases without a third-party SDK. This is the honest tradeoff and the compliance rules.

## Apple in-app purchase is required for digital goods

Start with the rule that governs everything: Apple requires in-app purchase for digital goods and services used in the app, as the [App Store Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) spell out. Unlocking features, subscriptions, and digital content must go through StoreKit, and charging an outside card for that content risks rejection. In 2023 Apple [rejected more than 248,000 app submissions](https://www.apple.com/newsroom/2024/05/app-store-stopped-over-7-billion-usd-in-potentially-fraudulent-transactions/) for various violations, so getting payments right is not optional. You never handle card numbers for digital goods; Apple does.

## What StoreKit 2 gives you, and what you own

Use [StoreKit](https://developer.apple.com/documentation/storekit) to load products, start a purchase, and read current entitlements, and Apple's [in-app purchase documentation](https://developer.apple.com/documentation/storekit/in-app-purchase) to verify transactions. The table shows the split when you skip a service.

| Responsibility | RevenueCat | Raw StoreKit 2 |
| --- | --- | --- |
| Load products and purchase | Handled | You call StoreKit |
| Receipt and transaction verification | Handled | You verify, ideally server-side |
| Entitlement state and restore | Handled | You persist and re-check |
| Subscription analytics | Built in | You build or add it |

For a small catalog, raw StoreKit 2 is lean and free of a dependency. For a complex subscription business, a service like a [RevenueCat paywall](/blogs/revenuecat-paywall-template-swiftui/) earns its keep, and a hosted checkout such as a [Paddle mobile checkout](/blogs/paddle-mobile-checkout-ui-kit-swiftui/) suits non-app sales.

## Verify on the server

StoreKit 2 hands you signed transactions you can check on device, but for anything valuable, verify on your server too, so a tampered client cannot unlock content for free. Grant entitlements from the verified result, persist them, and re-check on launch and restore. The server is the source of truth, and restore must always work, or App Review will fail you.

## A worked example: a monthly subscription

Take a monthly Pro subscription. On the paywall, you load the product from StoreKit so the price shows in the user's own currency and format automatically, with no hardcoded numbers. They tap subscribe, StoreKit runs the purchase and Face ID confirms it, and you receive a signed transaction back.

You verify that transaction, ideally on your own server using Apple's API, then grant the Pro entitlement and persist it. On the next launch you re-check current entitlements so Pro stays unlocked, and a Restore Purchases button re-grants it on a new device or after a reinstall. No card number ever touches your code, Apple handles the billing and the renewals, and your server stays the source of truth for who actually has Pro. That is a complete, compliant subscription built on StoreKit 2 with no third-party SDK, and the only parts you maintained were the verification and entitlement logic. For a single product that is a small, clear amount of code; for a dozen tiers across platforms, that is when a paywall service starts to pay for itself. Either way the user experience is identical, a price in their currency, a one-tap purchase, and a Pro badge that survives a reinstall, which is all most people ever notice about your billing; the plumbing is your choice, the polish is what they will actually judge you on.

## Common mistakes and fixes

- Charging an outside card for digital goods. Use StoreKit, as Apple requires.
- Trusting the client. Verify transactions server-side for valuable content.
- Forgetting restore. A working restore is mandatory for review.
- Hardcoding prices. Load localized prices from StoreKit products.
- Skipping entitlement re-checks. Confirm current entitlements on each launch.

When the purchase succeeds, a little celebration helps, like a [wheel of fortune spinner](/blogs/wheel-of-fortune-spinner-ui-template-ios/) reward done tastefully.

## Key takeaways

- StoreKit 2 ships in-app purchases in SwiftUI with no third-party SDK.
- Apple requires in-app purchase for digital goods; never charge cards yourself.
- Verify transactions server-side and make restore always work.
- Choose raw StoreKit or a service by subscription complexity, from a free VP0 design.

## Frequently asked questions

The FAQ above answers building IAP without RevenueCat, whether Apple IAP is required, how to verify a purchase safely, and what RevenueCat saves you.

## Frequently asked questions

### Can I do in-app purchases in SwiftUI without RevenueCat?

Yes. StoreKit 2 gives you everything you need: load products, start a purchase, check current entitlements, restore, and verify transactions. Skipping RevenueCat removes a dependency and its fee, but you take on the entitlement logic and server-side verification it would have handled. For a small catalog this is very doable; for a complex subscription business, a service can save time. Start the paywall from a free VP0 design.

### Do I have to use Apple in-app purchase for digital goods?

Yes. Apple requires in-app purchase for digital goods and services consumed in the app, and charging users with an outside payment method for that content risks rejection. Physical goods and real-world services use other payment methods, but unlocking app features, subscriptions, and digital content must go through StoreKit. Read the App Store Review Guidelines before you build the paywall.

### How do I verify a StoreKit 2 purchase safely?

StoreKit 2 delivers signed transactions you can check on device, but for anything valuable you should also verify on your server using Apple's APIs, so a tampered client cannot unlock content for free. Grant entitlements based on the verified result, persist them, and re-check current entitlements on launch and restore. Treat the server as the source of truth.

### What does RevenueCat actually save me?

RevenueCat handles receipt validation, entitlement state across platforms, restore logic, and subscription analytics, so you write less server code. The tradeoff is a dependency and a fee. Raw StoreKit 2 is leaner and free of both, but you write and maintain that logic yourself. Choose by how complex your subscriptions are and how much you want to own.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*