diff --git a/apps/docs/src/config/llmsCustomSets.ts b/apps/docs/src/config/llmsCustomSets.ts index 26fa871dc..eca506c9d 100644 --- a/apps/docs/src/config/llmsCustomSets.ts +++ b/apps/docs/src/config/llmsCustomSets.ts @@ -64,7 +64,7 @@ Plugin Native Audio|native audio playback plugin|docs/plugins/native-audio/** Plugin Native Biometric|biometric authentication plugin for fingerprint and face ID|docs/plugins/native-biometric/** Plugin Native Geocoder|native geocoding plugin for address lookup|docs/plugins/nativegeocoder/** Plugin Native Market|app store deep linking plugin|docs/plugins/native-market/** -Plugin Native Purchases|in-app purchases and subscriptions plugin|docs/plugins/native-purchases/** +Plugin Native Purchases|in-app purchases, subscriptions, paywalls, revenue playbook, and monetization plugin|docs/plugins/native-purchases/** Plugin Navigation Bar|Android navigation bar customization plugin|docs/plugins/navigation-bar/** Plugin NFC|NFC reading and writing plugin|docs/plugins/nfc/** Plugin Pay|Apple Pay and Google Pay integration plugin|docs/plugins/pay/** diff --git a/apps/docs/src/config/sidebar.mjs b/apps/docs/src/config/sidebar.mjs index 0493b6465..51071a04c 100644 --- a/apps/docs/src/config/sidebar.mjs +++ b/apps/docs/src/config/sidebar.mjs @@ -127,6 +127,7 @@ const pluginEntries = [ [ linkItem('Overview', '/docs/plugins/native-purchases/'), linkItem('Getting started', '/docs/plugins/native-purchases/getting-started'), + linkItem('Revenue Playbook', '/docs/plugins/native-purchases/revenue-playbook'), section('Android Setup', [ linkItem('Sandbox Testing', '/docs/plugins/native-purchases/android-sandbox-testing'), linkItem('Create Subscription', '/docs/plugins/native-purchases/android-create-subscription'), diff --git a/apps/docs/src/content/docs/docs/plugins/native-purchases/getting-started.mdx b/apps/docs/src/content/docs/docs/plugins/native-purchases/getting-started.mdx index 055d0c13d..72f1bb36d 100644 --- a/apps/docs/src/content/docs/docs/plugins/native-purchases/getting-started.mdx +++ b/apps/docs/src/content/docs/docs/plugins/native-purchases/getting-started.mdx @@ -236,6 +236,10 @@ purchases.forEach((purchase) => { 5. **Test thoroughly** – follow the [iOS sandbox guide](/docs/plugins/native-purchases/ios-sandbox-testing/) and [Android sandbox guide](/docs/plugins/native-purchases/android-sandbox-testing/). 6. **Offer restore & management** – add UI buttons wired to `restorePurchases()` and `manageSubscriptions()`. +## Revenue next steps + +After the purchase flow works, use the [Revenue Playbook](/docs/plugins/native-purchases/revenue-playbook/) to plan your first paid funnel: product scope, ASO, pricing, paywall placement, analytics, and churn feedback. + ## Troubleshooting **Products not loading** diff --git a/apps/docs/src/content/docs/docs/plugins/native-purchases/revenue-playbook.mdx b/apps/docs/src/content/docs/docs/plugins/native-purchases/revenue-playbook.mdx new file mode 100644 index 000000000..6cfbc2cb6 --- /dev/null +++ b/apps/docs/src/content/docs/docs/plugins/native-purchases/revenue-playbook.mdx @@ -0,0 +1,200 @@ +--- +title: Revenue Playbook +description: Learn how to turn a Capacitor app into revenue with a focused MVP, store discovery, paywall placement, pricing, analytics, and @capgo/native-purchases. +sidebar: + order: 3 +--- + +import { Steps } from '@astrojs/starlight/components'; + +![Revenue playbook for in-app purchases](/native-purchases/revenue-playbook.png) + +The purchase SDK is only one part of making money from an app. Revenue comes from a clear problem, a small product that users can try, reliable store billing, and a paywall that teaches you what people are willing to buy. + +Use this playbook when you are adding subscriptions or premium unlocks with `@capgo/native-purchases`. + +## Start with a simple revenue target + +Make the first target concrete. For example: + +| Monthly price | Active subscribers needed for about $1K MRR | +| --- | --- | +| $4.99 | 201 | +| $7.99 | 126 | +| $9.99 | 101 | +| $29.99 yearly | About 400 annual subscribers, depending on timing | + +These numbers are before store fees, taxes, refunds, and currency differences. They are still useful because they keep the launch plan practical: you need a few hundred motivated users, not a huge audience. + +## Build the smallest paid product + + +1. **Pick one painful use case** + + Build around one outcome users already search for. Examples: a workout plan for new parents, a budget tracker for couples, a receipt scanner for freelancers, or a language drill app for one exam. + +2. **Check demand in the stores** + + Search App Store and Google Play for the core keyword. Read low and mid-score reviews of competing apps to find missing features, confusing onboarding, pricing complaints, and UI friction. + +3. **Ship a narrow MVP** + + The first version should include onboarding, one useful core action, basic error handling, and enough analytics to see whether users reach the value moment. + +4. **Add purchases early** + + Do not wait until the app feels complete. A basic paywall helps you learn whether users understand the value and whether your pricing is plausible. + + +## Instrument the funnel before optimizing + +Track these events before you start changing prices or screens: + +| Event | Why it matters | +| --- | --- | +| `install` or first open | Baseline traffic | +| `onboarding_completed` | Whether users understand the setup | +| `core_action_completed` | Whether the product delivers value | +| `paywall_viewed` | Whether users reach monetization | +| `trial_started` | Whether the offer is compelling | +| `purchase_completed` | Paid conversion | +| `restore_started` and `restore_completed` | Purchase recovery and review compliance | +| `subscription_status_checked` | Entitlement reliability | +| `cancel_feedback_submitted` | Churn reason | + +If many users do not see the paywall, fix onboarding before changing the paywall. If users see the paywall but do not start a trial, improve the offer, proof, or price presentation. + +## Choose one monetization model + +Start with one model so the data is readable. + +| Model | Good fit | First version | +| --- | --- | --- | +| Freemium | Daily utilities, trackers, tools with repeat use | Free core action, paid limits or premium features | +| Paywall plus free trial | Apps that deliver quick value after onboarding | Paywall after onboarding with 3- to 14-day trial | +| One-time unlock | Small tools with limited recurring value | Lifetime product plus optional future subscription later | + +Avoid shipping three tiers, many bundles, and complex upgrade paths on day one. Use one monthly plan and one annual plan when you need subscriptions. Add localized pricing after you see meaningful traffic from a country. + +## Configure products for revenue learning + +Keep product identifiers stable and readable: + +```text +com.example.app.premium.monthly +com.example.app.premium.yearly +com.example.app.premium.lifetime +``` + +Use store product names that reinforce the value users are searching for, such as "Meal Planner Pro Monthly" instead of only "Monthly". Store metadata and in-app purchase names can help discovery and clarity. + +Load product data from the stores so pricing, currency, and introductory offers are always accurate: + +```typescript +import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases'; + +const { products } = await NativePurchases.getProducts({ + productIdentifiers: [ + 'com.example.app.premium.monthly', + 'com.example.app.premium.yearly', + ], + productType: PURCHASE_TYPE.SUBS, +}); + +const monthly = products.find((product) => product.identifier.endsWith('.monthly')); +const yearly = products.find((product) => product.identifier.endsWith('.yearly')); +``` + +Never hardcode store pricing in the UI. Render `product.priceString`, localized product title, billing period, and trial terms from store data whenever possible. + +## Build a first paywall + +A first paywall should be clear, not clever: + +- Headline: the paid outcome, such as "Unlock unlimited workout plans". +- Benefits: 3 to 5 concrete improvements, not a long feature list. +- Plans: monthly and annual, with real annual savings if offered. +- Trial: exact trial length and what happens after it ends. +- CTA: "Start free trial" or "Upgrade now". +- Links: terms, privacy policy, restore purchases, and manage subscriptions. + +Place the first paywall after onboarding, once the user understands what the app does. Later, test additional triggers such as usage limits, premium feature taps, or completed core actions. + +## Purchase and restore flow + +```typescript +import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases'; + +export async function buyYearly(appAccountToken: string) { + const transaction = await NativePurchases.purchaseProduct({ + productIdentifier: 'com.example.app.premium.yearly', + planIdentifier: 'yearly-plan', + productType: PURCHASE_TYPE.SUBS, + appAccountToken, + }); + + await fetch('/api/purchases/validate', { + method: 'POST', + headers: { 'content-type': 'application/json' }, + body: JSON.stringify({ + transactionId: transaction.transactionId, + receipt: transaction.receipt, + purchaseToken: transaction.purchaseToken, + productIdentifier: transaction.productIdentifier, + }), + }); + + return transaction; +} + +export async function restorePurchases() { + await NativePurchases.restorePurchases(); + + return NativePurchases.getPurchases({ + productType: PURCHASE_TYPE.SUBS, + }); +} +``` + +Always validate purchases on your backend before granting durable entitlements. Keep a local entitlement cache for fast UI, but treat the store and your backend as the source of truth. + +## Bring in the first users + +Revenue needs traffic. Start with channels that can work before you have a brand: + +- ASO: title, subtitle, keywords, screenshots, app description, icon, ratings, and in-app purchase names. +- Short-form video: post quick demos, problem/solution clips, and before/after examples for the target country. +- Reddit and communities: join the conversation first, then share what you built as a useful story instead of an ad. +- Beta groups: TestFlight, Google Play internal testing, Discord, and niche forums. + +Each channel should send users into the same measured funnel so you can compare retention, paywall views, trials, and purchases. + +## Read churn correctly + +Some churn means users tried the app and decided it was not for them. That is normal. What matters is the pattern: + +- Cancels during trial: unclear value, poor onboarding, or wrong traffic. +- Cancels after one cycle: not enough repeat value or weak habit loop. +- Refunds: pricing mismatch, accidental purchase risk, or unclear terms. +- No restores: broken entitlement handling or missing restore UI. + +Add a one-question cancellation survey when possible. Use the answers to improve onboarding, feature scope, store screenshots, and paywall copy. + +## Launch checklist + +- Product solves one clear paid problem. +- Store products are active and tested on iOS and Android. +- Paywall displays store-loaded prices and terms. +- Purchase, restore, manage subscription, and backend validation are implemented. +- Funnel events are tracked from first open to purchase. +- App store metadata explains the value in the first screenshots. +- At least one acquisition channel is active before launch. +- Churn feedback is collected from the first subscribers. + +## Related guides + +- [Getting started](/docs/plugins/native-purchases/getting-started/) +- [Create iOS subscriptions](/docs/plugins/native-purchases/ios-create-subscription/) +- [Create Android subscriptions](/docs/plugins/native-purchases/android-create-subscription/) +- [iOS sandbox testing](/docs/plugins/native-purchases/ios-sandbox-testing/) +- [Android sandbox testing](/docs/plugins/native-purchases/android-sandbox-testing/) diff --git a/apps/web/public/native-purchases/revenue-playbook.png b/apps/web/public/native-purchases/revenue-playbook.png new file mode 100644 index 000000000..47554659c Binary files /dev/null and b/apps/web/public/native-purchases/revenue-playbook.png differ diff --git a/apps/web/public/native-purchases/revenue-playbook.svg b/apps/web/public/native-purchases/revenue-playbook.svg new file mode 100644 index 000000000..6f48add5d --- /dev/null +++ b/apps/web/public/native-purchases/revenue-playbook.svg @@ -0,0 +1,32 @@ + + + + + + + + + + + + + + + + + Start free trial + + + + + + + + + + App revenue playbook + Validate demand, ship one paywall, + and learn from purchase data. + + $1K MRR path + diff --git a/apps/web/src/content/blog/en/how-to-make-revenue-with-capacitor-iap.md b/apps/web/src/content/blog/en/how-to-make-revenue-with-capacitor-iap.md new file mode 100644 index 000000000..dceff46f2 --- /dev/null +++ b/apps/web/src/content/blog/en/how-to-make-revenue-with-capacitor-iap.md @@ -0,0 +1,211 @@ +--- +slug: how-to-make-revenue-with-capacitor-iap +title: How to Make Revenue With a Capacitor App +description: A practical guide to turning a Capacitor app into revenue with in-app purchases, subscriptions, ASO, paywall placement, pricing, analytics, and @capgo/native-purchases. +author: Martin Donadieu +author_image_url: https://avatars.githubusercontent.com/u/4084527?v=4 +author_url: https://github.com/riderx +created_at: 2026-05-01T00:00:00.000Z +updated_at: 2026-05-01T00:00:00.000Z +head_image: /native-purchases/revenue-playbook.png +head_image_alt: Revenue playbook for Capacitor in-app purchases +keywords: Capacitor revenue, in-app purchases, subscriptions, mobile app monetization, paywall, ASO, app revenue, native purchases +tag: Mobile, IAP, Monetization +published: true +locale: en +next_blog: '' +--- + +Revenue does not start with a perfect app. It starts with a useful app, a small group of users, and a purchase flow that helps you learn what people will pay for. + +For Capacitor apps, the technical part is straightforward with [`@capgo/native-purchases`](/docs/plugins/native-purchases/). The harder part is deciding what to sell, where to show the paywall, how to price it, and how to get the first users into the funnel. + +This guide gives you a practical path from zero revenue to the first meaningful subscription revenue without overbuilding. + +## Start With One Paid Problem + +The easiest products to monetize are not always new categories. They are often focused versions of things users already search for: workout plans, budget tracking, language drills, photo tools, scanners, journaling, learning aids, and niche productivity workflows. + +Before building more features, check whether there is existing demand: + +- Search App Store and Google Play for the problem users would type. +- Open 5 to 10 competing apps and study their screenshots, onboarding, pricing, and reviews. +- Read 2-star and 3-star reviews to find what users almost like but still complain about. +- Look for a sharper niche: one country, one audience, one workflow, or one simpler user experience. + +Competition is not automatically bad. If users are already downloading and paying for similar apps, the market is proving there is demand. Your job is to make the experience clearer, faster, more focused, or better priced for a specific audience. + +## Build the Smallest App That Can Teach You + +Your first version should not try to be the final product. It should answer three questions: + +1. Do users understand what the app does? +2. Do users reach the core action? +3. Do users care enough to pay, start a trial, or come back? + +That means your MVP needs onboarding, one useful core flow, analytics, and a basic paywall. It does not need every setting, every integration, or a complicated account system. + +Track these events from the beginning: + +- First open +- Onboarding completed +- Core action completed +- Paywall viewed +- Trial started +- Purchase completed +- Restore completed +- Subscription status checked +- Cancellation feedback submitted + +If users do not reach the main feature, fix onboarding. If they reach the feature but never see the paywall, fix the flow. If they see the paywall but do not convert, work on the offer, price, proof, and message. + +## Use Store Discovery as a Revenue Channel + +ASO matters because it affects both discovery and conversion. A user who finds you in search still needs to understand the value in a few seconds. + +Focus on the basics first: + +- Put the strongest keyword in the title without making it unreadable. +- Use the subtitle or short description for the main benefit. +- Fill the iOS keyword field without repeating title terms. +- Make the first three screenshots explain the outcome, not every feature. +- Use a simple icon that is readable at small sizes. +- Add meaningful in-app purchase names, because plan names can support clarity and search. +- Localize one market at a time when you see traffic from a country. + +Treat the store page like the first paywall. Users need to know what the app does, who it is for, and why it is worth trying. + +## Get the First Users Before Scaling Anything + +You do not need a large paid acquisition budget to learn. You need enough traffic to see patterns. + +Short-form video can work well for visual or outcome-driven apps. Show the problem, the result, and the app in use. Test many small clips instead of waiting for one perfect launch video. If you target a specific country, keep the account setup, language, and posting context aligned with that region. + +Reddit and niche communities work differently. Do not show up with a generic ad. Read first, understand the tone, and share a useful story: what you built, what problem it solves, what surprised you, and what kind of feedback you want. + +Beta distribution is also useful. Use TestFlight, Google Play internal testing, Discord, existing users, or small communities. The goal is not vanity installs. The goal is to watch real users move through the onboarding, value moment, and paywall. + +## Pick One Monetization Model + +Early revenue tests fail when the offer is too complicated. Start simple. + +Freemium works well when users can get ongoing value for free but hit meaningful premium limits. Examples: more scans, unlimited plans, cloud sync, export, advanced insights, or premium content. + +A paywall with a free trial works well when the app delivers value quickly and the user understands the outcome after onboarding. A 3- to 14-day trial is common, but the right length depends on how fast users can experience value. + +A one-time unlock can work for small utilities where recurring value is weak. You can add a subscription later if the product evolves into a service. + +For subscriptions, start with monthly and annual. Make annual savings clear, but do not hide the monthly option. A first price such as $4.99/month, $7.99/month, or $29.99/year is often easier to test than a complex pricing table. Adjust later based on traffic quality, country, conversion, retention, and refund behavior. + +## Implement Purchases With Native Store Data + +Use `@capgo/native-purchases` to load product data, start purchases, restore purchases, and check entitlement state across iOS and Android. + +```bash +bun add @capgo/native-purchases +bunx cap sync +``` + +Load prices from the stores instead of hardcoding them: + +```typescript +import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases'; + +const { products } = await NativePurchases.getProducts({ + productIdentifiers: [ + 'com.example.app.premium.monthly', + 'com.example.app.premium.yearly', + ], + productType: PURCHASE_TYPE.SUBS, +}); + +for (const product of products) { + console.log(product.title, product.priceString); +} +``` + +Start the subscription flow: + +```typescript +const transaction = await NativePurchases.purchaseProduct({ + productIdentifier: 'com.example.app.premium.monthly', + planIdentifier: 'monthly-plan', + productType: PURCHASE_TYPE.SUBS, + appAccountToken: userPurchaseToken, +}); + +await fetch('/api/purchases/validate', { + method: 'POST', + headers: { 'content-type': 'application/json' }, + body: JSON.stringify({ + transactionId: transaction.transactionId, + receipt: transaction.receipt, + purchaseToken: transaction.purchaseToken, + }), +}); +``` + +Always provide restore and manage subscription actions: + +```typescript +await NativePurchases.restorePurchases(); +await NativePurchases.manageSubscriptions(); +``` + +The local app can unlock quickly for good UX, but durable access should be verified by your backend using the receipt or purchase token. This protects revenue and avoids broken entitlements when users switch devices, cancel, refund, or renew. + +## Put the First Paywall After Onboarding + +The first paywall should appear after users understand the app, not before they know what they are buying. For many apps, that means immediately after onboarding or after the first meaningful action. + +A useful first paywall includes: + +- A headline that describes the paid outcome +- 3 to 5 concrete benefits +- Store-loaded monthly and annual prices +- Trial length and renewal terms +- Restore purchases +- Terms and privacy links +- A clear CTA such as "Start free trial" or "Upgrade now" + +Do not hide the price. Do not invent fake urgency. Do not make cancellation terms hard to find. Clear terms convert better over time because they reduce refunds, review risk, and support issues. + +## Learn From Churn Instead of Panicking + +Some users will cancel. Early churn is information, not just failure. + +Look at the pattern: + +- Trial cancels usually mean the user did not see value fast enough. +- First-month cancels often mean the app solved a one-time problem or lacked a habit loop. +- Refunds can mean the paywall was unclear or the user expected something different. +- Support requests about lost access usually mean restore or entitlement handling needs work. + +Ask one short cancellation question when you can. Use the answers to improve onboarding, screenshots, pricing, feature scope, and paywall copy. + +## Keep the Loop Small + +The first revenue loop should be boring and measurable: + +1. Improve the store page. +2. Bring in a small batch of users. +3. Watch onboarding and core action completion. +4. Show one clear paywall. +5. Measure trials, purchases, restores, refunds, and cancels. +6. Change one thing. +7. Repeat. + +That loop is how you move from guessing to revenue. Once it works, you can add more channels, more plans, better localization, and deeper lifecycle messaging. + +## Implementation Checklist + +- Build one core feature around one paid problem. +- Add analytics before optimizing the paywall. +- Create active iOS and Android products in the stores. +- Load product names and prices with `getProducts()`. +- Implement purchase, restore, manage subscription, and backend validation. +- Show the first paywall after onboarding or the first value moment. +- Use ASO, short-form video, Reddit, or beta groups for early traffic. +- Collect churn feedback from the first subscribers. + +For the technical setup, use the [Native Purchases getting started guide](/docs/plugins/native-purchases/getting-started/). For the product and revenue workflow, keep the [Native Purchases revenue playbook](/docs/plugins/native-purchases/revenue-playbook/) next to your launch checklist.