RevenueCat Blog

Launch Party June ’26: The New Features You Should Know

Fri, 12 Jun 2026 00:46:12 GMT

On June 5, 2026 we hosted special edition of our bi-weekly office hours featuring live demos and Q&A around our recent features launches. It was hosted by the Product Managers who built and shipped the features, giving you the chance to discuss your questions with the team live.

If you couldn’t join live, here’s a summary of what we covered and clips of the demos.

Paywalls

AI Editor

The AI Editor is a conversational AI agent built directly into the RevenueCat Paywall Editor that lets you create, edit, and refine paywalls using natural language prompts.

This feature is ideal for rapidly generating a production-ready paywall from scratch, adjusting visual design like colors and typography, or updating existing templates without manual tweaking. You chat with the AI (for example, “Make a paywall for a book tracking app targeting the BookTok community”) and it automatically adjusts the copy, layout, and imagery. It can also accept a design.md file to match your brand guidelines or a screenshot for inspiration.

To set it up, go to Paywalls in the RevenueCat dashboard, click Create paywall, and select Generate with AI, or open an existing paywall and use the AI Editor tab in the left sidebar. Check out the docs here.

Paywall Rules

Paywall Rules allow you to customize the visibility of paywall components based on both preset and Custom Variable based rules, enabling you to customize a single paywall to support multiple scenarios.

One example is using Paywall Rules to show a trial timeline only when a trial is available, or to display a different package (like family sharing vs. individual) based on a custom variable.

Rules are evaluated at runtime. You define conditions such as offer.intro, package.identifier, or custom variables, and set components to be visible or hidden when those conditions are met.

To set this up, open the Paywall logic tab in the Paywall Editor, create a new rule based on your desired condition, and then set the visibility of your paywall components for that rule. Check out this blog post for more info.

Funnels

Funnels Builder

Funnels allow you to build customizable, hosted web onboarding experiences that can be designed remotely from the RevenueCat dashboard and shipped by anyone on your team.

Use cases for funnels include web-to-app acquisition funnels for ad campaigns or influencers, surveying users before checkout, and capturing web conversions with lower friction. You build multi-step web flows using the Funnels editor, which is similar to the Paywalls editor. You can add screens, branching logic, survey questions, and a checkout step. It currently supports Stripe and Paddle for payments.

To set it up, configure a payment provider in RevenueCat, create a Funnel in the dashboard, design your steps and branching logic, and deploy the generated URL. Check out the docs here.

A/B Testing

Testing within Funnels enables you to run experiments directly within your web Funnels to optimize conversion.

This feature is used for testing different price points, paywall designs, or onboarding survey flows to see which yields the highest conversion rate on the web. In the Funnel Editor, you can add an “Experiment” branch that splits traffic between different paths (e.g., a high-price paywall vs. a low-price paywall) and track the results in the funnel analytics.

To set it up, add an Experiment node in your funnel flow and connect it to your variant screens or paywalls. Check out the docs here.

Web

One-Tap Purchases via Express Checkout

One-Tap Purchases via Express Checkout adds Apple Pay and Google Pay buttons directly to your web paywalls and funnels for frictionless purchasing.

This maximizes web conversion rates by allowing users to skip the traditional credit card form and check out with a single tap. The Express Checkout component surfaces Apple Pay or Google Pay (if supported by the user’s device and browser) and processes the payment through Stripe.

To set it up, add the “Express checkout buttons” component to your paywall in the Paywall Editor or Funnel Editor. See the docs here.

Stripe Billing & Stripe Managed Payments

RevenueCat supports both Stripe Billing and Stripe Managed Payments, a Merchant of Record solution where Stripe handles tax compliance, collection, and remittance.

A merchant of record solution is ideal for selling subscriptions on the web while offloading the complexity of global sales tax, VAT, and GST to Stripe. RevenueCat creates a Stripe Checkout session, and for eligible products, Stripe acts as the Merchant of Record, processes the payment, handles taxes, while RevenueCat tracks the transaction and unlocks entitlements.

To set it up, connect your Stripe account via the RevenueCat Stripe App, create a Stripe Web Config in RevenueCat, and toggle on “Use Managed Payments when available”. See the docs.

Discounts and Discount Codes

This is a flexible system to apply percentage-based discounts to products in RevenueCat Web Billing using shareable, customer-facing discount codes.

Use cases include running promotional campaigns like Black Friday, attributing sales to influencers via unique codes, or offering win-back discounts. You create a discount (e.g., 50% off for 3 months) and generate codes (e.g., BLACKFRIDAY50). Customers enter the code at checkout, or it can be auto-applied via a URL parameter on a Web Purchase Link.

To set it up, navigate to Product catalog > Web discounts in the dashboard, create a discount, define its rules and codes, and enable discount codes on your Web Purchase Links. Check out the docs here.

Experiments

pLTV Winner, Credible Intervals, Astra Analysis, Winner Rollout

This suite of features enhances Experiments with advanced statistical tools: predicted LTV (pLTV) winner predictions, credible intervals for metrics, AI-driven analysis via Rico (Astra), and one-click winner rollouts.

These tools help you make confident decisions on A/B tests by understanding not just initial conversion, but long-term value, and quickly deploying the winning variant. RevenueCat calculates the Chance to Win and 95% credible intervals for conversion metrics. Once sufficient data is gathered, it predicts the pLTV winner. You can ask Rico to analyze the nuances of the test, and use the “Rollout” option to set the winner as the default offering or create a targeting rule.

These features automatically populate in the Results tab of your running Experiments.

AI Tools

Rico

Rico is RevenueCat’s AI-powered app growth advisor built into the dashboard and available in Slack.

It is designed for diagnosing revenue drops, analyzing experiment results, benchmarking against industry data, or answering SDK integration questions using plain language. Rico has access to your app’s data, charts, experiments, RevenueCat documentation, and industry benchmarks. You ask it a question, and it reasons through the data to provide an answer.

To set it up, use the chat interface in the dashboard overview. To use it in Slack, go to Account Settings, select the Rico tab, and connect it to your workspace.

AI Toolkit

RevenueCat offers a comprehensive AI toolkit to help AI agents set up RevenueCat, integrate it into apps, and access your revenue data — all directly from your AI coding assistant.

Explore the docs.

Charts & Dashboard

Benchmarks

Benchmarks allow you to compare your app’s key metrics like conversion, churn, and realized LTV against other apps in the same store and category.

This helps identify growth opportunities, set meaningful goals, and see how your app stacks up against peers in metrics like trial conversion or refund rates. RevenueCat calculates benchmark percentiles using anonymized data from apps in the same category over the last 12 months. Your app’s performance is shown as a percentile (e.g., 90th percentile).

Benchmarks are automatically available in the dashboard under the Benchmarks tab for eligible apps.

See the docs.

In-App Ad Revenue in Charts

In-App Ad Revenue in Charts tracks ad impressions, clicks, and revenue alongside your subscription data for a unified view of your app’s hybrid monetization.

This is essential for calculating accurate Realized LTV that includes both ads and subscriptions, and understanding how ad revenue varies by segment. By hooking into your ad mediation platform’s (like AdMob or AppLovin) impression-level revenue data (ILRD) callbacks, RevenueCat tracks ad events and displays them in dedicated Ad Charts and the main Revenue mix chart.

To set it up, opt-in to the beta in the Ads page of the dashboard, and integrate the AdMob Adapter SDK or manually call the AdTracker methods from your ad SDK callbacks. See the docs.

Store Updates

Apple 12-Month Commitments

This feature supports Apple’s new subscription option that bills customers monthly but requires a 12-month commitment.

It is highly effective for lowering the upfront price barrier for annual subscriptions in price-sensitive regions while maintaining long-term retention. Apple models this as a billing plan under an annual product. RevenueCat exposes the monthly commitment plan as a separate product ID with a :monthly suffix (e.g., com.myapp.product:monthly).

To set it up, configure the billing plan in App Store Connect. In RevenueCat, create a second product and check the “12 months commitment” option. Ensure you are using StoreKit 2 and iOS 26.4+.

Join our next office hours

Wish you were there? Don’t worry, you can find our team live every other Friday for Office Hours.

We gather members of the RevenueCat team, our community, and anyone curious about RC or consumer-software monetisation as a whole for a fast-moving, fully interactive Q&A and platform demo session.

We plan to take over one of these session with a launch party at least once a quarter, so stay tuned for the next one

Introducing the RevenueCat Codegen Gradle Plugin: type safe entitlements and offerings on Android

Thu, 11 Jun 2026 23:59:43 GMT

Every RevenueCat integration shares the same quiet liability: the string keys. Your entitlements, offerings, and packages live in the RevenueCat dashboard, and your Kotlin code reaches for them with raw strings like entitlements["premium_access"]. The compiler cannot verify those strings, the IDE cannot autocomplete them, and a single typo ships as a runtime bug instead of failing the build. The new RevenueCat Codegen Gradle Plugin closes this gap by talking to the RevenueCat API at build time and generating type-safe Kotlin accessors for everything you’ve configured in the dashboard.

In this article, you’ll explore what the plugin generates and why, how its two Gradle tasks fetch and cache your project schema, how to set it up with a version catalog, how naming styles turn dashboard lookup keys into Kotlin identifiers, how caching and offline mode keep builds working without a network, and the trade-offs to weigh before adopting it.

The fundamental problem: Dashboard keys as raw strings

Consider the typical code for gating a premium feature and resolving a package to purchase:

This code compiles whether or not "premium_access" exists in your project. If someone renames the entitlement in the dashboard, or a teammate types "premium_acess" in a new screen, nothing fails until a user hits that code path: the entitlement lookup silently returns null, and getPackage throws at runtime. The usual mitigation is a hand maintained constants file, but that file drifts out of sync with the dashboard the moment anyone forgets to update it.

With the codegen plugin applied, the same logic becomes:

The difference is more than aesthetics:

IDE autocomplete: every entitlement, offering, and package from your dashboard surfaces as a typed property, so you discover them by typing a dot instead of switching to a browser tab.
Compile time safety: a typo or a removed entitlement becomes a build error, not a runtime null.
No drift: the plugin fetches your latest dashboard state at build time, so there is no constants file to maintain by hand.

Setting up the plugin

The plugin is published to Maven Central as part of the RevenueCat Purchases SDK. The plugin ID is com.revenuecat.purchases.codegen, and its version always matches the Purchases SDK version, so you reuse the version string you already have.

Step 1: Apply the plugin

Add it to your version catalog in gradle/libs.versions.toml:

Declare it in your root build.gradle.kts so Gradle resolves it for all subprojects:

Then apply it in your app module’s build.gradle.kts:

Step 2: Configure the extension

Only three properties are required: apiKey, projectId, and packageName. Everything else has a default.

apiKey must be a v2 secret key (it starts with sk_) with read permissions, created in the RevenueCat dashboard under Project Settings > API Keys. This key is used only at build time and is never compiled into your app binary. You’ll see how to keep it out of version control in a later section.

projectId is your project’s identifier, also found in Project Settings.

packageName is the package the generated code lands in, and it must be a package you own, such as com.myapp.rc. Avoid anything under com.revenuecat.*. The Purchases SDK ships a consumer ProGuard rule, -keep class com.revenuecat.** { *; }, which prevents classes in that namespace from being shrunk or obfuscated. If your generated code lands there, R8 retains all of it in release builds even when unused, which bloats your APK for no benefit.

The full set of optional properties looks like this:

The four generate* flags each control one category of output. If you iterate offering.availablePackages dynamically rather than accessing packages by name, for example, set generatePackages.set(false) to keep the generated surface small. The caching and offline options are covered in their own section below.

Step 3: Build

Run any standard build task:

./gradlew assembleDebug

Generation runs automatically before compilation. After the first successful build, do File > Sync Project with Gradle Files in Android Studio so the IDE picks up the new source directory and autocomplete starts working.

If you ever want to fetch or regenerate without a full build, both tasks are invokable directly:

./gradlew :app:rcFetchSchema ./gradlew :app:rcGenerateCode

What gets generated

Suppose your project has a premium_access entitlement and a perplexity offering containing the standard $rc_monthly and $rc_annual packages. The plugin generates four categories of output.

Entitlement ID constants

A single RCEntitlementId object holds one constant per entitlement:

These constants are useful at the boundaries where you still need the raw key, such as logging or analytics events, while keeping the compiler in the loop.

Type safe `EntitlementInfos` extensions

For each entitlement, two extension properties land on EntitlementInfos: an accessor that returns the EntitlementInfo or null, and a boolean shortcut for the common isActive check.

Convenience `CustomerInfo` extensions

The same active check is also generated directly on CustomerInfo, so gating a feature behind a single entitlement skips the entitlements lookup entirely:

Offering and package accessors

Each offering gets a constant in RCOfferingId and a typed accessor on Offerings that wraps getOffering():

Packages need one extra design decision. Multiple offerings commonly share the same package lookup key, since $rc_monthly exists in nearly every offering. Generating a bare monthly extension on Offering would collide the moment a second offering defines the same package. The plugin resolves this by prefixing each package property with its offering name and scoping the ID constants into a per offering object:

The ${'$'} sequence might catch your eye. Because $ begins a string template in Kotlin, KotlinPoet escapes the literal dollar sign in $rc_monthly this way so the generated file always compiles. At runtime the string is exactly $rc_monthly.

Every generated property also carries a KDoc comment with the display name from your dashboard and a reminder that the code reflects the dashboard at build time, so the documentation popup in the IDE tells you what each key actually is.

Naming styles: From lookup keys to Kotlin identifiers

Dashboard lookup keys are arbitrary strings, so the plugin runs each one through a pipeline before it becomes an identifier: strip the $rc_ prefix, apply the configured naming style, replace characters that are invalid in identifiers, prefix an underscore when the key starts with a digit, and escape Kotlin reserved words with backticks. The result always compiles, even if someone names an entitlement when or 2024_promo in the dashboard.

The namingStyle option controls the middle step:

Lookup key	`CAMEL_CASE` (default)	`SNAKE_CASE`	`AS_IS`
`premium_access`	`premiumAccess`	`premium_access`	`premium_access`
`ProPhoto`	`prophoto`	`pro_photo`	`ProPhoto`
`$rc_monthly`	`monthly`	`monthly`	`monthly`

CAMEL_CASE fits most Kotlin codebases because it follows the standard property naming convention. AS_IS preserves the key exactly after prefix stripping, which is useful when your lookup keys are already well formed identifiers and you want a one to one mapping. The constants inside ID objects like RCEntitlementId are always UPPER_SNAKE_CASE regardless of the style, because constants follow their own convention in Kotlin.

Caching and offline mode: Builds that don’t depend on the network

A Gradle plugin that hits the network on every build would be a hard sell, so the fetch step is built around a local cache. rcFetchSchema writes the fetched schema and a timestamp to build/revenuecat/cache/revenuecat-schema.json. On the next build, it checks the file’s age against cacheTtlMinutes (default 30) and skips the network call entirely if the cache is still fresh. Setting the TTL to 0 forces a fetch on every build.

When a fetch does run and your project has many offerings, the client paces itself: it follows the API’s pagination, waits 500 milliseconds between requests, and retries up to five times with exponential backoff when it hits a rate limit response. This makes the first build slower on large projects, but every subsequent build reads from the cache.

The interesting question is what happens when the fetch fails: no network on a flight, a connection timeout, or a key that was revoked. The offlineMode option offers two behaviors:

USE_CACHE_OR_SKIP (default): if a stale cache exists, it is used and a warning logs the cache age. If no cache exists at all, generation is skipped with a log message and the build continues without generated sources. Local builds keep working with no intervention.
FAIL: the build fails immediately with a GradleException describing the error. This is the right choice for a release pipeline where you need a hard guarantee that the generated code reflects the latest dashboard state.

A practical pattern applies each mode based on the environment:

With this setup, a local build falls back to the cache when the network is unavailable, while CI refuses to ship a build whose generated code might be stale.

Note that the fallback applies to fetch failures, not to missing configuration. An empty apiKey fails the build immediately with “revenuecat.apiKey must be configured in your build script.” regardless of the offline mode, so every developer needs the key configured even when a cache is present.

One more consequence of USE_CACHE_OR_SKIP is worth calling out: if your very first fetch fails, generation is skipped and references to the generated code fail to compile with unresolved symbols. If you hit “No RevenueCat schema cache found. Skipping code generation.” in the build log, temporarily set offlineMode.set(OfflineMode.FAIL) to surface the underlying error, which is usually a wrong apiKey or projectId.

Refreshing after dashboard changes

The generated code reflects your dashboard at the time of the last fetch. After you add or rename an entitlement, a normal build picks the change up once the TTL expires. To pick it up immediately, wipe the cache and rerun the tasks:

Then sync the project in Android Studio so the IDE reindexes the regenerated sources.

How it works: Two Gradle tasks and a schema cache

The plugin registers a revenuecat { } extension and two Gradle tasks under the revenuecat group:

rcFetchSchema calls the RevenueCat API v2 (/projects/{projectId}/entitlements, /projects/{projectId}/offerings, and /projects/{projectId}/offerings/{offeringId}/packages), follows pagination, and writes the result to a JSON cache at build/revenuecat/cache/revenuecat-schema.json along with a timestamp.
rcGenerateCode reads that cache and generates Kotlin source files into build/generated/revenuecat/kotlin/ using KSP.

You never invoke either task by hand during normal development. The plugin wires rcGenerateCode into your compile tasks, so any standard build runs generation first.

Keeping the secret key out of version control

The apiKey is a v2 secret key, so even though it never reaches your app binary, it should not be committed in build.gradle.kts. The generated files contain only plain lookup key strings like "premium_access", never the key itself, but the build script is checked in. For local development, read the key from local.properties, which stays out of version control:

Then add the values to local.properties:

REVENUECAT_API_KEY=sk_your_v2_secret_key
REVENUECAT_PROJECT_ID=proj_your_project_id

For CI, inject both values as environment variables, as shown in the offline mode example above.

Trade offs: When generated accessors fit and when they don’t

The plugin fits best with stable identifiers. Entitlement IDs rarely change once set, and turning every entitlement check into a compile time verified property removes a whole class of bugs. Offerings and packages benefit the same way when their IDs are stable, especially in a large codebase where autocomplete and rename refactoring matter.

For highly dynamic offerings, keep one trade off in mind. The generated code is a snapshot of your dashboard at build time. Adding a new package or renaming an offering in the dashboard requires a new build and a new app release before the generated accessors reflect it. If you iterate offering.availablePackages at runtime instead, an already shipped app picks up new packages without a release, because the package list comes from the RevenueCat backend at runtime.

In practice this matters less than it sounds. Adding a new package that you intend to reference by name in code requires writing new code anyway, which means a new release regardless. But if you drive your paywall presentation entirely from the dashboard without touching code, the runtime API keeps that flexibility, and you can disable generatePackages while keeping the entitlement and offering accessors. The two approaches compose: use the generated properties where identifiers are stable, and the dynamic API where the dashboard is the source of truth.

Conclusion

In this article, you’ve explored the RevenueCat Codegen Gradle Plugin: the raw string problem it removes, the rcFetchSchema and rcGenerateCode tasks that fetch your dashboard schema and generate typed Kotlin accessors, the setup from version catalog to first build, the naming pipeline that turns lookup keys into identifiers that always compile, and the caching and offline modes that keep builds fast and network independent. If your entitlement checks are still string lookups, applying the plugin turns the next typo into a build error instead of a support ticket.

As always, happy coding!

— Jaewoong (skydoves)

How to build a reactivation strategy that actually works

Thu, 11 Jun 2026 14:01:51 GMT

A lot of subscription apps either make the mistake of treating churn as the end point and never bother to follow up with these users or they spam them with discounts, believing this is the only strategy that works to bring them back.

Churned users are actually one of the most valuable segments you have. They’ve already crossed the hardest threshold: they trusted you enough to pay. And yet, most apps either ignore them completely or hit them with a random, out-of-context, discount three months later. Reactivation is a whole strategy in itself, not just a campaign. If you build it properly, it becomes one of the highest ROI levers in your entire growth model.

According to RevenueCat’s State of Subscription Apps 2026 Report:

Monthly subscribers come back at ~18–24% within a year
Even weekly plans see ~7–10% reactivation
Only annual plans behave like “true churn” (~4–6%)

So let’s look at some of the ways you can build a strategy around reactivation.

1. Start at the moment of churn: Your cancellation flow is step zero

Many teams treat cancellation as the last touchpoint with a user (e.g. using “Sorry to see you go”-style messaging). However, cancellation is a great opportunity for data collection segmentation and follow-up. This is where your reactivation strategy actually begins.

What to implement

A simple questionnaire that triggers on user cancellation and asks them why they no longer wish to use or pay for the app or product.

What to ask

Keep it straightforward – One clear question should suffice.

Not only are you looking to collect valuable insights here, you’re also tagging intent so you can follow up with users later with messaging that’s appropriate for them specifically.

Focus on actionable reasons like:

“I don’t need it right now”
“Too expensive”
“Missing features I need”
“Technical issues”
“I didn’t get value”

Each of these should map directly to a future reactivation path.

Note that in every app I’ve worked with, there will be a portion of users who think the product is too expensive or simply don’t want to pay. Unless your conversion is below benchmarks, I’d take these responses with a grain of salt.

Make sure to also leave an “other” option open-ended so you’re collecting insights from users who may have discovered a bug or problem with the app you’re not aware of.

Once you’ve got a breakdown of the most popular answers, you can define your list of actionable reasons further.

What to offer

This is where most apps throw discounts immediately. That trains users to churn to get a better deal, and it also cheapens the value perception of your product (e.g. why did I pay $39.99 when I could have got this for $20?)

Instead, take each individual cancellation reason from your survey and map out a personalized reactivation plan.

Some examples:

“Not needed right now” → Offer pause instead of cancel
“Too expensive” → Offer lower tier or annual reframing
“Didn’t get value” → Offer guided setup or feature education
“Technical issues” → Offer support escalation

Not every churn needs to be saved. Some should be cleanly segmented for later.

What data to capture

For each churned user, you want to capture the following data points:

Churn reason
Plan type (monthly vs annual)
How long they were a user
Usage intensity before churn
Last meaningful action

If you’re not capturing these data points, your reactivation strategy will be generic and impersonal. For example, you won’t know if this was a power user who just dropped out of the habit or a low frequency user who may need time before the use case is relevant again.

On iOS, there’s also a platform-level lever here that’s still relatively new and underused: Apple Retention Messaging API.

This allows developers to present a targeted message or offer directly within the App Store cancellation flow, before the subscription is fully canceled. In other words, you get one last, native touchpoint at peak intent.

Access and adoption are still evolving, so not every team is using it yet. But it’s worth keeping on your radar, because it fundamentally changes what’s possible at the moment of churn.

Used well, this can reinforce the same logic as your in-app cancellation flow:

Surface a pause or downgrade option instead of pushing discounts
Address common churn reasons with a clear value reminder

Used badly, it becomes another place to throw generic discounts and train users to game your system.

2. The post-churn relationship: how to stay present without being annoying

You want to stay relevant enough that returning feels natural, not forced. Instead of generic “come back” emails, try to focus on value reminders. Remember your product is still there to solve a user’s problem – so messaging should be centred around that, and this is where your data collection from Step 1 comes in handy.

“Here’s what’s new since you left” – could target the “didn’t get value” or “technical issues” segments.
“People like you are using X feature to achieve Y” – could target the “didn’t get value” segment.
“Quick win you can get in 2 minutes” – could target the “didn’t get value” or “not needed right now” segments.

Think of it less like win-back and more like lightweight re-education. You’re rebuilding perceived value over time and just like all lifecycle messaging, the strategy needs to align exactly with the user’s goals.

Channel strategy

Email alone likely won’t carry your reactivation strategy. The strongest setups layer channels so the message shows up in the right place at the right time. Email should still do most of the heavy lifting, but it works best when reinforced with push for users who are still opted in, and paid retargeting for higher LTV churned users where the economics justify it.

The trap is thinking more channels means more pressure. It doesn’t. Frequency and coordination matter far more than channel count. If a user gets the same “come back” message three times in two days across different touchpoints, it feels like you’re chasing them.

A better approach would be along the lines of one well-timed email a few days after churn, a contextual push a week later, and a lightweight retargeting touchpoint only if the user is high value. Different messages, spaced out, and each with a clear purpose.

3. Timing matters more than what you say

Timing is where most reactivation strategies fall apart. Sending the same message to everyone 30 days after churn is easy to set up, but it ignores the fact that not all churn behaves the same. The biggest difference comes down to plan type.

Monthly and annual subscribers churn for very different reasons, and more importantly, they forget you at different speeds.

For monthly users, the relationship is short and transactional. Habits break quickly, and if you wait too long, you’re no longer reactivating, you’re reacquiring. That’s why it’s worth testing earlier touchpoints:

Around 7 days: while the habit is still fresh
Around 21 days: before they fully disengage
Around 45 days: a final attempt before they go cold

For annual users, the dynamic is different. They’ve made a bigger commitment and usually had stronger initial intent. Churn is often driven by timing or changing needs, not lack of belief in the product. That gives you a longer window to re-engage:

Around 30 days: once they’ve had some distance
Around 90 days: when the original use case might return
Around 6 months: aligned with seasonal or cyclical needs

The key idea is that reactivation works best when it matches the user’s natural usage habit, not your CRM calendar.

Plan type is only one part of the picture. To make timing actually work, you also need to layer in why the user churned and how they behaved before leaving.

Start with their churn reason. Different reasons create very different reactivation windows:

“Not needed right now”
This isn’t a rejection, it’s a timing issue. Reaching out too early feels pushy because the need genuinely isn’t there. You’re better off waiting until the use case naturally returns, whether that’s tied to travel, routines, or specific moments.
“Too expensive”
Price sensitivity doesn’t disappear overnight. Instead of immediately offering discounts, time your outreach around moments where value feels higher, like seasonal spikes, new feature releases, or more relevant use cases.
“Didn’t get value”
This is the one case where speed matters. The longer you wait, the more the product is mentally written off. Re-engage quickly with education, guided use cases, or a clearer path to first value.
“Technical issues”
Timing here is simple: don’t reach out until the problem is fixed. Coming back too early just reminds the user why they left.

Then you can layer in behavior. Not all churned users are equal:

Highly engaged users who churned
Their habit just broke. Your window is short, because they’re more likely to replace you quickly. Early, relevant touchpoints matter here.
Low-engagement users who churned
They never really built a habit in the first place. At this point, you’re not reactivating, you’re essentially reacquiring. That means slower timing and more emphasis on value explanation.

In summary, message timing shouldn’t just reflect when someone left, but why they left and how close they were to forming a habit in the first place.

4. Offer strategy: what works vs what feels desperate

Let’s be blunt. If your only reactivation lever is “20% off”, your product isn’t doing enough heavy lifting. Discounts only work if they feel timely and relevant to the user.

The better approach is to make your offer feel relevant, not reactive. That starts with contextual offers.

1. Instead of a generic incentive, tie the message directly to why the user left:
“You canceled because X. Here’s a solution for that.”
This immediately makes the outreach feel personal.

2. Then look at usage-based incentives.
Credits, limited access, or feature unlocks reduce the barrier to re-entry without forcing a full commitment. They let users ease back into the product instead of making an all-or-nothing decision.

3. Time-based framing is another underrated lever.
For users who churned due to timing, messages like “Try again for your next trip” or “Restart when you need it” align with real-world behavior. You’re not pushing them to come back now, you’re giving them a reason to come back when it actually makes sense.

4. Lean on product-led hooks.
New features, meaningful improvements, or integrations can be powerful reactivation drivers, especially for users who left due to missing value. This is where your product does the convincing for you.

Remember, the goal isn’t to win everyone back. It’s to win back the right users (high value, high intent), for the right reasons, in a way that actually sticks.

5. Make it frictionless to return

Even if your messaging is perfect, unnecessary friction can kill your reactivation efforts.

A lot of teams get the user to click and then lose them the moment they land back in the app because the experience feels like starting from scratch. If a returning user is treated like a brand new one, forced through generic onboarding, or dropped into an impersonal state, you’ve just undone all the work it took to bring them back. Instead, make the return feel like a continuation, not a reset.

Start by removing unnecessary friction. If you can avoid re-onboarding, do it. Let users pick up where they left off, with their preferences, history, and progress intact. The more familiar the experience feels, the faster they’ll get back to value.

Then reduce decision fatigue. Don’t make users rethink everything from scratch. Default to their previous plan, clearly highlight what’s changed since they left, and guide them toward an immediate “quick win” so they can feel progress right away.

Finally, consider more flexible ways to re-enter. Options like pausing instead of canceling, easy plan switching, or grace periods all lower the psychological barrier to coming back. You’re not asking for a big commitment, you’re offering a low-risk way to try again.

6. Ultimately, the quality of your product determines reactivation success

Whether your reactivation strategy works is directly tied to everything that happens before a user churns, especially your onboarding quality, activation success, value delivery, and pricing and packaging.

In other words, if users churn because they didn’t understand the product, didn’t experience value, or barely used it, no amount of win-back messaging will fix that.

I go deeper into lifecycle architecture in my course on StartApp School. Reactivation only works when the system before it is solid.

Final thought

It’s easy to assume churned users are no longer interested in your product and might be a waste of time to pursue. However, the data shows that this is where some of the highest-leverage growth sits.

You already paid to acquire these users and convinced them to pay. Are you building a system where you’re top of mind when they’re ready to come back? And does that return experience help them pick up where they left off?

WWDC26: What’s new for subscription apps

Tue, 09 Jun 2026 18:01:53 GMT

WWDC26 has wrapped up and there’s a lot to dig into for subscription app businesses. We’ve been going through the session videos and release notes to figure out what Apple has changed this year that actually matters for developers building with RevenueCat.

Most of the keynote was focused on Siri AI and iOS 27’s design updates, but the StoreKit and App Store sessions had some of the most significant subscription business changes in years. Here’s everything worth knowing.

Annual subscriptions can now bill monthly

(By the way, this is only available outside of the United States and Singapore for now, and requires iOS/iPadOS/macOS/tvOS/visionOS 26.5 or later.)

Apple has introduced a new pricing option that lets customers pay for an annual subscription in monthly installments. The customer still commits to a full year, but the cost is spread across twelve monthly payments instead of charged upfront.

This is a meaningful new tool for paywalls. Annual plans convert well because of the price-per-month math, but the upfront cost is a real barrier for a lot of users. Monthly-billed annual plans give you the retention benefits of an annual commitment without asking users to hand over a year’s worth of money at once.

You can add this billing option to new or existing one-year auto-renewable subscriptions in App Store Connect.

What changes in your code

The entry point on the client side is a new pricingTerms property on a product’s subscription info. It returns an array of every billing plan available for that product. Every annual subscription has at least one entry with a billingPlanType of .upFront. If you’ve configured a commitment plan, a second entry shows up with a billingPlanType of .monthly.

There’s a new preferredSubscriptionPricingTerms view modifier for SubscriptionStoreView if you’re using StoreKit’s built-in UI. For custom paywall UI, read pricingTerms directly to get both the monthly price and the total 12-month commitment price so you can display both clearly to users.

To trigger the purchase, pass the billing plan as a purchase option:

let result = try? await product?.purchase(options: [.billingPlanType(.monthly)])

What changes on your server

The JWS transaction payload has new fields to be aware of: billingPlanType, renewalBillingPlanType, and commitmentInfo. The commitmentInfo block tells you which billing period a customer is in, the total number of billing periods, the committed price, and the commitment expiration date.

This is important: a single annual product ID can now represent two completely different billing arrangements. Make sure your backend is reading and storing these new fields, or you’ll end up with incorrect entitlement data.

What this means for RevenueCat customers

Your paywalls will need to show both the monthly price and the total 12-month commitment. “Pay $4.99/month, billed over 12 months” is not the same thing as “$59.99/year” and your users will expect to see both.

In analytics, committed monthly billing is not the same as a regular monthly subscription. If you don’t segment them, your LTV models will be wrong.

One testing caveat: there’s a known Xcode bug where pricingTerms.commitmentInfo.price returns an incorrect price for commitment plans in StoreKit Testing. Keep that in mind as you build and test.

RevenueCat supports committed monthly billing out of the box. We parse and store the new billingPlanType, renewalBillingPlanType, and commitmentInfo fields automatically, so you don’t need to build custom backend logic to handle them. See the docs for implementation details.

Retention Messaging lets you save subscribers at the moment they cancel

Retention Messaging is one of the most interesting business tools Apple has shipped in a while. When a subscriber goes to cancel, the App Store can now show them a message or offer that you’ve configured. This is access to a moment in the subscription lifecycle that developers previously had no visibility into.

There are two ways to use it.

The App Store Connect path requires no custom server infrastructure — you configure messages and offers directly in App Store Connect and Apple handles the rest. The real-time path is more powerful but optional.

App Store Connect configuration is the simpler path. You set up messages in App Store Connect, optionally attach a retention offer and creative assets from the new Asset Library, and Apple displays them during the cancellation flow. No additional server infrastructure required.

Real-time Retention Messaging is more powerful. When a user tries to cancel, the App Store makes a server-to-server request to an endpoint you configure, passing fields like originalTransactionId, productId, and userLocale. Your server responds with what to show: a message, an alternate product, or a promotional offer.

This opens up subscriber-aware save flows that weren’t possible before. You can offer a discounted annual plan to a loyal monthly subscriber, suggest a lower tier to someone on a premium plan, skip the offer entirely for someone who already redeemed one recently, or show different messaging by market.

Apple shared early data in the WWDC session (session 309): subscriptions using Retention Messaging saw an average save-rate lift of 1.4 percentage points, equivalent to an 82% increase. Promotional offer messages had the strongest lift at 5.5 percentage points. Apple noted that results vary by developer.

One important technical requirement: real-time Retention Messaging requires a fast server response. Apple runs a sandbox performance test and your endpoint has to pass before you can use real-time messaging in production. If your server doesn’t respond in time, the App Store falls back to your App Store Connect configuration. Plan for that fallback path.

Real-time retention also works with the new commitment billing plans. You can respond to a cancellation request by offering a switch to the monthly-billed annual plan, which is a useful save option for users who are cancelling because of the upfront cost.

What this means for RevenueCat customers

Retention offer transactions have their own identifiers in the JWS payload: offerType: 5, offerIdentifier, and offerDiscountType. Make sure your analytics pipeline tracks these separately from other promotional offers so you can measure actual save rates, post-save retention, and which offer types are performing.

RevenueCat handles the real-time Retention Messaging server side for you. The dashboard lets you configure all four message types — text, text + image, switch plan, and promotional offer — and manages the response window requirement automatically. You’ll still need to complete Apple’s approval form to register the endpoint, but the infrastructure is taken care of. Full setup steps are in the docs.

Subscriptions can now be sold to groups and organizations

Apple has introduced two new ways to sell subscriptions beyond the individual consumer model.

Group purchases let a single subscriber buy multiple seats and invite others to join from inside your app. Apple handles the invitation flow; each person joins using their own Apple Account. This is available for in-app purchases you build yourself with the StoreKit 2 purchase flow.

Volume purchasing puts your subscription in front of enterprise and education buyers through Apple Business Manager and Apple School Manager. Seat assignments are handled through existing device management workflows, which means IT can deploy your app to a fleet of devices without users needing to do anything themselves.

Volume purchasing is available this fall. Group purchases arrive this winter. Both are configured in App Store Connect and are on by default for most auto-renewable subscriptions (Family Sharing subscriptions are opted out).

Volume pricing bands are configurable: you can set up to five price tiers with reduced per-seat pricing for larger purchases.

On the StoreKit side, Apple added Transaction.OwnershipType.assigned and Transaction.RevocationType.assignmentRevoked enum values to support volume purchases. Transaction query methods also now return transactions assigned to a Managed Apple Account.

Entitlement design is the hard part

If your app has any team, education, or organization use case, think through these before you enable group subscriptions:

The buyer is often not the end user
One transaction can produce multiple entitled seats
Seats can be assigned, revoked, or reassigned
Volume purchases may arrive through device management rather than the app itself
Volume pricing changes your per-seat revenue metrics

This is genuinely new territory for most subscription apps. The purchasing layer is simpler now, but the entitlement logic is more complex.

One implementation detail worth flagging now: both group purchases and volume purchasing require StoreKit 2. If your app hasn’t migrated yet, it’s worth prioritizing that before these features become available later this year to avoid delays.

We’ll have updates later this year on how to implement this in RevenueCat.

Cross-developer Bundles and Suites

This is the App Store change getting the most attention in the broader developer community, and it’s worth understanding what it actually is.

App Store Bundles let developers from different companies package their subscriptions together and offer them at a combined discount. Users can still buy each subscription individually; the bundle is an additional offering alongside the standalone products.

App Store Suites are different: a collection of subscriptions that only exist as a package and can’t be purchased separately. They’re designed for tightly related apps from different developers that make more sense together than apart.

Both formats address something developers have been asking for for years: cross-developer bundling without requiring the same parent company.

The StoreKit API for Bundles and Suites is available to prototype in Xcode 27 today. New Product.ProductType values represent Bundles and Suites, and Product.SubscriptionInfo.BundledSubscription lets you fetch merchandising data about subscriptions in a bundle. Transaction and RenewalInfo also have new fields for Bundle and Suite status.

That said, Apple has said full program details are coming later in 2026. Prototype against the API now, but don’t plan a ship date yet.

What this means for your RevenueCat Dashboard

Bundle and Suite subscribers will look different in your analytics from direct subscribers. Revenue attribution, churn analysis, and per-app subscriber counts will all need to account for the bundle layer. We’ll have more to share on RevenueCat support as the program details become clearer.

App Store Merchandising: new placements for Creative Assets

Apple is adding new creative placements on the App Store this year. Developers can now supply rich images and videos that appear in product page headers and search results, and these assets also work with custom product pages and product page optimization tests. They’re managed through a new Asset Library in App Store Connect.

A few things worth noting about how this works:

Assets can be submitted for App Review independently from an app update, so you can refresh seasonal creative or coordinate with an Apple Ads campaign without shipping a new build
The Asset Library centralizes all your creative across custom product pages, In-App Events, and now these new placements, so you’re not uploading the same assets in multiple places
A new product page preview lets you see exactly how your page looks across languages, Dark Mode, and device orientations before you publish

The same Asset Library also feeds Retention Messaging. That means your creative team can manage App Store acquisition assets and cancellation-save assets from the same place. That’s a meaningful workflow improvement for teams that have historically treated those as completely separate functions.

Personalized Collections and App Notes

Apple is rolling out two new discovery surfaces on the App Store. Personalized Collections are curated lists that appear on the Apps, Games, and Search tabs, surfacing apps based on each user’s interests and behavior. App Notes are short explanations that appear alongside a recommendation, telling users why a specific app is being suggested to them.

Both are already rolling out in English (US), with more languages and regions coming later this year.

There’s no developer action required to participate. That said, apps with complete, accurate metadata — clear descriptions, relevant keywords, up-to-date screenshots — will be better positioned to surface in relevant collections. It’s a good time to audit your App Store listing if you haven’t recently.

Offer Code Redemption gets a proper result

A smaller but welcome StoreKit update: the offer code redemption sheet now returns a VerificationResult when redemption completes, rather than firing and forgetting.

On success, you get a VerificationResult containing a Transaction to verify and finish. On failure, you get a descriptive error. The API also now takes a set of RedeemOption values to configure the flow.

This brings offer code redemption in line with how the rest of StoreKit 2 works. If you have a custom “redeem code” button in your app, it’s worth updating the transaction handling path to use the new result.

Unified App Review submissions

A useful operational change: you can now group In-App Purchase products into a single App Review submission alongside other item types like in-app events, custom product pages, and product page optimizations.

Previously you had to submit each product individually and track them separately. Now you select everything together, submit once, and track review status from one view. The App Store Connect API’s reviewSubmissions collection now supports IAP, subscription, and subscription group resources. Apple is deprecating the older per-resource submission endpoints in favor of this unified path.

If you have tooling or automation built around the old individual submission flow, start migrating now rather than waiting.

App Review Guidelines: saturated categories now face removal, not just rejection

Alongside the new monetization features, Apple updated its App Review Guidelines in a way that’s worth knowing about.

Previously, guideline 4.3(b) warned developers not to submit new apps in categories that were already crowded with low-effort entries. Apple would reject new submissions in categories like flashlight apps, fortune telling apps, and dating apps unless they offered something meaningfully different.

The updated guidelines go further. Apple now says it may remove existing apps in well-established saturated categories if they are not “updated, improved, or attracting customers.” The list of targeted categories has also been expanded to include wallpaper apps, simple timers, and sound effects. Apple also added language calling repeated submissions of low-effort apps “mediocre” and “low-quality,” with a warning that developers who keep submitting them may lose Apple Developer Program access entirely.

This is a meaningful shift from “we won’t accept new ones” to “we may remove the ones already there.”

It connects directly to Apple’s new Personalized Collections discovery feature. Apple is building better ways for users to find quality apps, and low-quality clutter degrades those surfaces. The two moves go together.

For existing developers building legitimate subscription businesses, this is more tailwind than headwind. A cleaner App Store, optimized for apps that are actively maintained, is a welcome addition!

Summary

WWDC26 brought more than just the usual updates—it was a really exciting year for subscription apps! Apple has introduced some fantastic new ways to help your business grow and connect with users. Here’s a quick look at the highlights:

Committed annual billing gives you a new middle-ground pricing option that could convert users who balk at the annual upfront cost
Retention Messaging gives you a save opportunity at the moment of cancellation that didn’t exist before
Group purchases and volume purchasing open up B2B and team sales paths without building your own billing infrastructure
Cross-developer Bundles and Suites are coming later this year, with an API available now to prototype
Creative Assets expand your merchandising surface on the App Store
Updated App Review Guidelines raise the quality floor across the store

We know there’s a lot to dig into here, especially regarding analytics and how you design your entitlements. We’re already hard at work figuring out the best ways for RevenueCat to support you through these changes, and we’ll be sharing more updates as we learn more. We’re excited to see what you build!

Don’t trust your Flutter app: verifying RevenueCat entitlements with the Firebase Extension

Tue, 09 Jun 2026 09:58:34 GMT

You spent months working on your shiny new app (or hours vibecoding it), and you’re almost ready to earn millions of dollars with it. Just one last step: add purchases, and you’re ready to go. But… not so fast. While on the surface it may seem obvious: you just check isPremium and unlock the premium content, in reality, there are many more caveats. Can malicious actors bypass this check? How easy is it? And how can you prevent unsanctioned access to premium content and protect your resources? In this article, we will discuss these questions and propose efficient solutions, without compromising security. This matters even more if you’re an indie dev like me and don’t have unlimited resources.

Now let’s build an app!

What are we building?

To explore the concepts, we will start by building a simple sample app called “Catflix”. As you probably guessed from the name, it is a video streaming service (for cats, about cats…). The use case is simple: all users can see the available shows in the catalog, but only premium users can watch unlimited episodes and premium shows. Premium is unlocked via a renewable subscription.

Note: the sample app and code in this article will be a Flutter app, but the logic applies to other mobile clients, since most of the work involves Firebase. The app uses RevenueCat for purchases. More on how to integrate RevenueCat into your Flutter app: https://www.revenuecat.com/docs/getting-started/installation/flutter

Here’s how it looks:

You can follow along with the code in this GitHub repository. To get a complete understanding of why we’re making these technical decisions, we will build our architecture from the ground up.

Level 1: Client-only check

Imagine that your movie streaming data is stored in a remote database. The database itself is unrestricted (already a red flag 🚩), but you need a way to gate premium access. The most straightforward approach is to use the RevenueCat SDK to check if a user has a specific entitlement and grant access accordingly.

Throughout the article, the 🔑 marks where the entitlement check actually lives.
Watch where it moves as we go.

Note: this step assumes you have integrated the RevenueCat SDK into your app and set up purchases in the App Store and Google Play. For this example, we will omit the actual store setup and rely on RevenueCat test purchases, but here’s the full documentation on how to integrate everything in your real app: https://www.revenuecat.com/docs/projects/overview.

In code, it looks something like this:

The appeal of this approach is obvious: it requires only a couple of lines of code, with no extra boilerplate or complicated verifications. However, that very appeal is also the obvious problem: since the check runs purely on the client side, a malicious user can decompile it, patch isPremium to always return true, and abuse your premium resources.

Conclusion: this approach should never be used in production!

Now, let’s look at the first step we can take to make our app’s premium content more secure.

Level 2: Client-only check + Firebase App Check

The code on the client side is unsafe by definition — it lives on the user device, and honestly, not a lot of things are stopping a potentially malicious user from tampering with the source code and doing all sorts of nasty things. For example, they can easily change your isPremium check to a hard-coded true, granting access to premium content without a subscription. But we’re in luck, because mechanisms exist that allow us to secure our apps from this vector of attack. One of those mechanisms is Firebase App Check.

Note: We won’t discuss the pros and cons of spinning up your own backend versus using a Backend-as-a-Service (BaaS), or the different types of BaaS available. Let’s just assume you have done your research and reached the same conclusion as I did: Firebase is the solution.

Firebase App Check uses underlying platform attestation mechanisms (Play Integrity by Google and App Attest/Device Check by Apple). It sends a special token with each request to Firebase services; this token is invalid if it was generated from a tampered device or app version (e.g., an Android version that wasn’t signed with your Play Store certificate). If a malicious user repackaged your app and flipped isPremium to true, App Check would refuse the new binary’s tokens, and Firestore would reject every request, keeping your premium content safe. App Check doesn’t catch every form of tampering, but we’ll come back to that in a moment. Therefore, App Check is a must-enable feature if you’re using Firebase services and ESPECIALLY if you’re using the Firebase AI Logic client SDK.

In a nutshell, here is how Firebase App Check works:

Setting up App Check is straightforward. It is highly recommended to enable it from the start, before you even launch your app. But even if you haven’t done so before, it is possible and essentially required to set it up for an existing app; you’ll just need to monitor and wait for some time for your existing users to update their app before enforcing it.

So with this approach, our architecture would look like this:

Notice that the 🔑 has not moved. We have added an extra layer of security, but the entitlement decision still lives in the client code. The crucial thing to understand is what App Check actually attests: it confirms a request came from a genuine, untampered instance of your app on a genuine device. It does not confirm that this genuine app instance is telling the truth about the user. That gap is the problem. App Check is great at stopping the basic attacks: someone hitting your Firestore straight from the command line, or repackaging your app into a tampered build. What it can’t do is vouch for the decision your app makes once it’s legitimately running, because that decision happens on a device the user fully controls. And you don’t even need to tamper with anything to see why that matters. Picture our Level 2 setup the moment a paying user’s app fetches the real video URL. That user can read the URL straight out of the network traffic and share it around, and it keeps working for anyone who has it. App Check faithfully protected the lookup, but it can’t protect an asset once a trusted client has been handed it. As long as the client is making the final call, your premium content is vulnerable. To truly secure it, we need to stop trusting the client altogether and move the decision-making process somewhere safe.

Thankfully, with Firebase, we have a couple of options to achieve this without spinning up a whole backend infrastructure. Let’s see what they are.

Level 3: Server-verified entitlements

Firebase offers a solution called Cloud Functions, which allows you to write and deploy custom backend logic without the overhead of managing a full server infrastructure. We will explore these in more detail shortly, but first, we need to address a prerequisite: user authentication.

Identifying Firebase users in RevenueCat

To verify entitlements on the server, we must link our Firebase users to their RevenueCat identities. For this sample app (and many real-world use cases), Firebase Anonymous Authentication is sufficient, though you can later upgrade to email or SSO providers. From Firebase Cloud Functions‘ point of view, an anonymous user is just as authenticated as an email/SSO user: the function receives a real UID it can trust, signed by Firebase. That’s all the server needs to look the user up in RevenueCat.

Linking users is very simple, but extremely important for the next steps:

This will allow us to identify our user purchases in our database going forward. Now, back to our Cloud Functions.

Understanding Firebase Cloud Functions

If you are already familiar with Firebase Cloud Functions, you can skip this part. Otherwise, here’s a quick intro:

Firebase Cloud Functions vs. Google Cloud Functions:
While both allow you to execute code in isolation, Google Cloud Functions is the underlying technology, supporting many languages (Go, Java, Python, etc.). Firebase Cloud Functions is built on top of Google Cloud Functions and is specifically tailored for the Firebase ecosystem. It provides libraries that make working with Firebase much easier, offering features like user authentication and App Check out of the box. Due to this specialized support, Firebase Cloud Functions currently supports Node.js (JavaScript and TypeScript), Python, and Dart (experimental).
Types of Firebase Functions:
Firebase Functions generally fall into three categories: HTTP functions, Callable functions, and Background Triggers.
1. HTTP functions are for when you need functions openly available on the web (e.g., for a web app or a third-party API). This option requires you to manually handle security concerns, including user authentication validation, caller verification (App Check), and managing CORS.
2. Callable functions are designed to be triggered directly from your client app using Firebase SDKs. Firebase handles the heavy lifting for you: CORS is automatically managed, and Firebase Auth and App Check tokens are automatically verified and injected directly into the function’s context. Because of this seamless, built-in security, callable functions are the perfect choice for safely verifying a user’s RevenueCat entitlements from your mobile app.
3. Background Triggers (or event-driven functions) run automatically in the background in response to events within your Firebase project, such as a new user sign-up or a document update in Firestore. In a RevenueCat architecture, these are incredibly useful. For instance, you might use an HTTP function to receive a RevenueCat webhook, write the user’s new subscription status to Firestore, and then let a Background Trigger automatically provision their premium access the moment that database document changes.

We will use Dart, which has just recently become available in experimental mode, to write our Cloud Functions. That’s a great addition (and something the community has been waiting for years!), because using Dart keeps us in one language end-to-end, lets us share models between client and server, and avoids context-switching mid-feature.

Note: The Dart SDK is currently in experimental support (announced April 2026), so APIs may change. Always consult the latest documentation. For more information on how to set up and deploy Dart Cloud Functions, check the documentation. We will use the Dart SDK for this example, but the approach itself is fully applicable to Firebase Cloud Functions in general, with any supported SDK. Another thing to know is that using Firebase Cloud Functions requires you to be on the pay-as-you-go Firebase plan, Blaze.

Implementing Cloud Function for movie-playing functionality

In our Catflix app, we want to make sure that only premium users can stream premium movies. To do that, we will implement a callable function to verify the RevenueCat entitlement. If the user has a premium subscription, it returns a streaming URL; otherwise, it throws a “subscription required” error. So the code will look something like this:

We’re doing several things here:

We register a callable function called play
We check if the user is authenticated with Firebase, and if not, throw an UnauthenticatedError
We check if the authenticated user has premium entitlement to access this content, and if not, we throw a PermissionDeniedError

And then on the client side, to call this function:

Now, to the fun part: how do we actually check user premium eligibility? For this, we have two options: direct calls to the RevenueCat API and custom webhook functions.

Option 1: Direct calls to RevenueCat API

RevenueCat provides an API we can use to request a user’s entitlement status. The base flow is pretty simple: whenever we need to check a user’s premium status, we make a request to the RevenueCat API and receive back the user entitlements. This flow is simple to wrap your head around and implement. It also doesn’t require you to do any bookkeeping yourself, as RevenueCat provides you with up-to-date info on demand.

With this approach, our architecture would look like this:

And in pseudocode, the entitlement check would look something like this:

A note on the API key. This is a project-scoped secret key (created in the RevenueCat dashboard under API Keys -> New secret API key), and it’s different from the public SDK key the client uses. It should never be shipped in client code or sit in your repo. In Cloud Functions, inject it as a runtime secret and read it from the function’s environment. Scope the key to the minimum permissions you need (read on customers is enough for this) and rotate it independently of everything else.

How to access sensitive parameters in Firebase Cloud Functions

Firebase Cloud Functions have their own way of defining configuration parameters, and it separates plain config from secrets. Secrets are backed by Google Cloud Secret Manager: stored encrypted, and injected only into the functions you explicitly bind them to. Use a secret for anything sensitive, like your RevenueCat API key, and plain parameters for everything else, like your RevenueCat project ID. The experimental Dart SDK supports both, with defineSecret(‘RC_API_KEY’) for the key and defineString(‘RC_PROJECT_ID’) for the rest. Here are the docs.

Now, even if a malicious user manages to change the value of isPremium to true on the client side, they still won’t be able to access the premium features because our Cloud Function simply won’t return the premium content.

Unfortunately, this approach isn’t the most efficient one, especially if you plan to scale, for a few reasons:

Overhead on every check. Each premium check now costs an extra HTTP round-trip to RevenueCat, which adds latency to every gated request, and your function is billed for the time it spends waiting on that call.
Service unavailability and rate limits. If the RevenueCat API is unavailable for any reason, your check will fail. Additionally, RevenueCat enforces rate limits that you could hit under burst traffic. This could temporarily deny a paying user access to a paid feature, and we don’t want that.

You might be thinking: can’t I just cache the result? You can, but then it’s your responsibility to keep the cache fresh, which is exactly the bookkeeping RevenueCat was doing for you, and entitlement state can flip the moment a subscription renews, lapses, or gets refunded.
Direct calls are only viable if you need to perform checks very rarely and are okay with the possibility of the request failing (for example, if you can simply reschedule the task for later). For a general modern app, this isn’t the most efficient solution, and we need to go a different route. The fix is to invert the flow: instead of asking RevenueCat every time for user entitlement status, let RevenueCat tell us once, the moment something changes.

Option 2: Custom Webhook Function

Instead of making the request from your end each time you need to check the status, you can use webhooks to reverse this pattern. You can define a function that RevenueCat will call each time there is a status change. This requires quite a bit of upkeep on your end, such as:

Validating that the request really came from RevenueCat. RevenueCat sends a static authorization header value you configure in the dashboard. You need to verify it on every request, or anyone who finds your endpoint URL can call it and grant themselves premium access.
Handling retries and idempotency. RevenueCat retries failed deliveries and, in a rare case, may send duplicate events. Your code needs to process duplicate events idempotently, e.g., by keeping track of the id of the event.
Storing and updating user status. Each event you receive describes a change to a specific RevenueCat customer’s entitlements. Your code needs to find the matching user in your own database and apply the right update (grant, revoke, change expiry), so the rest of your app has an up-to-date source of truth to read from.

In this case, the architecture would look like this:

But the benefits are worth it:

Requests between you and RevenueCat happen only when something actually changes with a user’s entitlement, not on every premium check in your app.
Your database holds the current premium status for all users, so checking it is a quick local read, instead of sending an expensive request to the RevenueCat API that could also fail or hit a rate limit.

Note: You can read more about working with RevenueCat webhooks in the documentation: https://www.revenuecat.com/docs/integrations/webhooks

While the maintenance of the webhook option is a bit of overhead, if you use Firebase, you are in luck – RevenueCat actually provides a Firebase extension that handles all the boring plumbing and removes all the headache.

Option 3: RevenueCat Firebase Extension

First, what exactly is a Firebase Extension? Simply put, it’s a pre-packaged, configurable backend solution that automates specific tasks so you don’t have to write and maintain the server code yourself. In our case, it provides deployable, pre-written Cloud Functions that handle all the boring boilerplate.

The RevenueCat extension specifically provides an endpoint for RevenueCat webhooks to call whenever a user’s status changes. These functions handle request validation, data parsing, and syncing that state directly into a Firestore document assigned to the specific user. Once you’ve configured the extension, your own Cloud Functions can simply read the latest entitlement status directly from your Firestore database.

You configure the Extension once, and then everything in the purple rectangle is done automatically for you:

This way, the data is always up to date in your own database, you don’t make unnecessary API calls, and you don’t need to do any manual plumbing or maintenance. All of the benefits of custom webhooks and none of the headache.

Let’s walk through the setup of the RevenueCat Firebase Extension.

Note: this guide contains all the steps to enable the Extension. It also walks you through connecting to Google Analytics, but the analytics portion is outside the scope of this article.

Start the integration in your RevenueCat console and generate a shared secret. You will need it in the next step.
Install the extension from the Firebase Extension Hub: https://extensions.dev/extensions/revenuecat/firestore-revenuecat-purchases
Fill in the information. There are two optional fields: the location of the customer collection and the RevenueCat Webhook Events Firestore collection. For our use case, they are both required. These are the paths in Cloud Firestore where the RevenueCat data for your app and for your users will be stored. Also, set ENABLED for custom claims; we will discuss them soon.

After you have installed the extension (it will take around five minutes to install itself), you will see a webhook URL and Firebase security rules:

It is very important to copy these rules and add them to your Cloud Firestore Security rules. They control access to purchase information. Learn more about Firebase Security Rules here.

Also, from the previous screen, copy the webhook URL and add it to your RevenueCat console:

You’re done with installation! Now, when your users make a purchase, this information will be synced to your Firestore database, as well as set in your user’s auth custom claims (we will return to them in a moment). To finalize our task of making our play function gate premium access, let’s see how to do it with our current setup. Again, we have two options: reading from the database or reading from the user’s custom claims.

Reading entitlement data from Firestore

There isn’t much to explain here, because the code is as simple as it gets: it’s literally just a read from your own Firestore database:

And you can verify in your Firestore database that this information exists:

Reading entitlement data from Auth Custom Claims

Before we get to the code, we need to understand a couple of concepts.

What are custom claims, in a nutshell?

A Firebase Auth user has the standard fields you’d expect from an authenticated user, depending on the authentication type: a UID, maybe an email, sign-in providers, etc. Custom claims let you add a small list of arbitrary key-value pairs on top of that, included directly into every ID token Firebase issues for the user. You can think of them as a tiny piece of trusted metadata that Firebase signs and ships with every request. Anything in the claims your backend can read and trust because Firebase has already verified the token’s signature.

This is exactly what the RevenueCat Extension handles for us. Because earlier, during installation, we enabled custom claims, the extension now writes a claim called revenueCatEntitlements onto each user: a simple list of the entitlement IDs that the user currently has active. So, for a Catflix subscriber, their ID token carries revenueCatEntitlements: [‘catflix Premium’]from now until something changes (a cancellation, a refund, the subscription period ending). The Extension keeps that claim in sync, the same way it keeps the Firestore document in sync.

Note: The entire custom-claims payload for a user is capped at 1KB. That’s enough for an entitlements list, but worth knowing if you’re ever tempted to start stuffing user preferences in there: don’t.

Where does the auth data come from in our function?

Remember from earlier in the article that callable functions take care of a lot of heavy lifting for us: CORS, App Check verification, ID-token verification? One of the things they hand us “for free” is the verified auth payload in the request body via request.auth. By the time your handler runs, you already know who the caller is and, thanks to custom claims, what they’re allowed to do. No HTTP round-trip to RevenueCat, no Firestore read, nothing. The answer is right there in the request.

So our entire premium check collapses to: pull the revenueCatEntitlements claim out of the token and ask whether catflix Premium is in it.

That’s the whole thing. Notice this function isn’t async and doesn’t return a Future. There’s literally zero I/O. Compare that to the Firestore version, which still costs us a document read per call. With many requests, this difference can quickly add up.

The catch: claim refresh latency

There’s one tradeoff worth knowing about, otherwise you’ll hit it in production and have a confusing afternoon.

When the extension updates a custom claim on the server (e.g., the user just bought premium, cancelled, or their card got declined), the change is applied to the user’s auth record immediately. The catch is that custom claims live inside the user’s ID token, and the Firebase SDK on the client caches that token and reuses it for up to an hour before refreshing it. So even though the server has the new claim, the client keeps sending the old token to your function, and your function reads whatever claims were baked into that old token.

The result: the user just paid for premium, but for up to an hour, the next call to your function still sees them as a free user. Which is fine for “the user cancelled, and we’re holding on to their access for a bit,” but very much not fine for “the user just paid and is staring at a still-locked play button.”

The fix is one line on the client. Whenever RevenueCat tells us that the user’s subscription has changed, we force an ID-token refresh:

Now the very next call to our function carries the freshly-updated claim, and a just-purchased premium movie unlocks immediately.

Note: At the time of writing, the experimental Dart Cloud Functions SDK (firebase_functions: ^0.6.0) doesn’t expose custom claims on auth.token because they get stripped when the token is decoded. The pseudocode above is what your code will look like once that’s fixed; today, you have to grab the raw JWT off auth.rawToken and decode the payload yourself. Safe to do (the framework has already verified the token’s signature before your handler runs), but it’s a few lines of plumbing that have nothing to do with entitlements. TypeScript and Python SDKs surface claims correctly out of the box; this is a Dart-specific issue that should disappear in a future release.

So which one should you pick?

Both options end up at the same place: our function knows whether the user is premium without ever talking to RevenueCat at request time. The choice is mostly about latency vs freshness.

Default to custom claims when the check runs on most requests. Zero I/O, zero marginal cost per call, scales for free as your user base grows.
Default to Firestore when you need entitlement updates to propagate within seconds (no token-refresh dance), or when your function already reads other Firestore data and one more read is essentially free.

Use both if you want. The Extension keeps them in sync, so there’s no source-of-truth conflict: you can use claims on hot paths and Firestore on admin/analytics paths in the same project.

Summary

Before we wrap this up, let’s reiterate a few important caveats and considerations.

App Check is a must for production apps; this is the lowest-hanging fruit when it comes to Firebase security. Server-side entitlement checks tell your function whether to grant access; App Check tells it whether to even talk to the caller. Both layers do different jobs, so don’t drop App Check just because the entitlement check moved to the backend.
For Cloud Functions and RevenueCat Extension, you need to enable the Firebase pay-as-you-go Blaze plan. This means you will be billed, and make sure you secure your billing account and Firebase access.
Make sure your private and secret keys stay that way: don’t commit them to your repository, never expose them to your client, store securely, and rotate regularly.
If you’re using only Firebase Anonymous Authentication, remember that on re-install, you should restore your users’ purchases, because the UID is device-local.
If you rely on custom claims, remember to refresh the token on the client side when changes happen in the RevenueCat SDK.
Dart SDK for Firebase Cloud Functions is freshly launched and is currently behind the “experimental” flag: use with caution, read up on current limitations.

We have gone through the best practices for building a simple, efficient, and secure tech stack to handle premium content access in your mobile apps. The main takeaway is timeless: never trust the client. Thankfully, if you’re using Firebase, the RevenueCat Firebase extension and Firebase Cloud Functions make this quite easy. Moreover, the newly launched Dart SDK for Firebase Cloud Functions makes the process even more streamlined (although in the era of Gen AI, the comfort of a familiar language becomes less important, and there are obvious benefits to more mature SDKs… yet I still love and prefer Dart).

Happy building, stay safe, and may the delighted users and pretty dollars be constant companions in your indie journey!

How to build a “name your price” paywall

Mon, 08 Jun 2026 11:56:14 GMT

Paywalls don’t always have to follow the same model, in which customers choose between 2-3 subscription options (e.g., annual or yearly). Sometimes you might want something different. One option could be, for example, “name your price paywall”, where users can choose between differently priced packages, that all unlock the same entitlement:

This is a custom paywall that I built for my app Trippity, which I will be launching (hopefully soon). The reason I built it this way was to offer a single lifetime unlock for features while allowing customers to choose how much they want to support the app. The levels also appear in the app, so later on you can purchase a higher level if you feel like it.

This quick tutorial will look at how to organize your subscriptions to support a “name your price paywall” with five different subscription levels. Code examples are in React Native, but you could easily implement this in any development stack. The main setup takes place in the RevenueCat dashboard or, if you are using our MCP, in your coding agent.

Use the RevenueCat AI Toolkit to shorten development time

If you’re using an AI coding assistant, you can skip most of the manual setup. The new RevenueCat AI Toolkit lets agents like Claude Code, Codex, Gemini CLI, and VS Code create products, entitlements, offerings, and SDK integrations directly from prompts.

Install it with:

Or, for Codex:

After authenticating with RevenueCat, you can simply ask your agent to create the products, entitlements, and offering needed for this tutorial. We’ll show both the AI-assisted and manual approaches below.

How “name your price” slider paywall works

The paywall slider lets users choose how much they feel the premium features are worth while still guiding them toward reasonable price anchors (e.g., $3.99 → $9.99). Because all price points unlock the same entitlement, the technical setup stays simple.

There are three parts to the system:

Multiple IAP products in App Store Connect / Google Play Console
Example: support_399, support_599, support_999
A slider UI
Each slider position corresponds to a specific product ID
A single entitlement in RevenueCat

No matter which price the user selects, they unlock the same features

This model works with both non-consumable in-app purchases as well as subscriptions (“Pay what feels right” kind of a thing). You could even combine these by making the lowest price a subscription. Just remember to keep it obvious what the total price and monthly price are so your app doesn’t get rejected by Apple or Google for deliberately confusing customers.

Step 1: Create your price-tiered products and entitlement

Our first step is to create the products we will be showing in our custom paywall. In this example, there are five products, with prices ranging from $1.99 to $19.99. I’ll show two ways of doing this: first, through RevenueCat MCP, and then through App Store Connect and importing those products to RevenueCat. The same approach works with the Google Play Store Console.

Create products using RevenueCat MCP

Creating 5 different products using RevenueCat MCP is simple. First, see our setup guide for RevenueCat MCP here, and once that is done, run the following prompt in your MCP-connected agent of choice:

Once you run this prompt, you will be potentially asked for access to the MCP. As long as you’ve correctly set up the App Store Connect connection in RevenueCat, products should get created in both places. Alternatively, you can create these products in the RevenueCat Test store if you have not connected App Store Connect to RevenueCat.

Create products using RevenueCat dashboard

If you’d rather set everything up manually, start by creating your products in App Store Connect (or Google Play Console). Create one product for each price point and give them clear identifiers, such as:

pro_bronze_lifetime — $1.99
pro_silver_lifetime — $4.99
pro_gold_lifetime — $9.99
pro_platinum_lifetime — $14.99
pro_diamond_lifetime — $19.99

Since every purchase unlocks the same features, keep the product names and descriptions consistent. The only thing changing is the price. Once the products have been created in your store, import them into RevenueCat from Product Catalog → Products. RevenueCat can automatically import products from App Store Connect and Google Play after you’ve connected your stores.

Next, create a single entitlement that represents the premium access users receive. Navigate to Product Catalog → Entitlements, click New Entitlement, and create an entitlement called pro (or any identifier you prefer).

After creating the entitlement, open it and click Attach in the Products section. Select all five lifetime products and save. This tells RevenueCat that purchasing any price tier should unlock the same premium access.

Finally, create an Offering (for example, default) and add all five products to it. Your React Native app can then fetch the offering and display the products in the slider UI we’ll build next.

Step 2: Connect RevenueCat to React Native

Next, we need to add RevenueCat to our app. Once again, I’m going to give you both an agentic way to do this and instructions on how to do it by hand.

Setup RevenueCat using an agent

If you installed the RevenueCat AI Toolkit earlier, open your React Native project in your coding agent and ask it to wire up the SDK:

The agent should install the SDK, add the initialization code, and make sure the native project is configured correctly. You may be asked to authenticate with RevenueCat through OAuth before the agent can access your project.

Set up RevenueCat manually

Install the React Native SDK:

Then configure RevenueCat when your app starts:

You can find your public SDK keys in the RevenueCat dashboard under Project Settings → API Keys.

To check whether the user has unlocked your pro entitlement, fetch their CustomerInfo and use it in a custom hook:

You can use this anywhere in your app to determine whether premium features should be unlocked. Since all five of our “name your price” products are attached to the same pro entitlement, it doesn’t matter which price tier the user purchased—RevenueCat will grant access in exactly the same way.

With RevenueCat connected and the entitlement configured, we’re ready to fetch our products and build the slider UI.

Step 3: Fetch the available price tiers

Now that RevenueCat is connected, we can fetch the products that will power the slider. Once again, you can either ask your coding agent to build this for you or implement it manually.

Build the slider using an agent

If you’re using the RevenueCat AI Toolkit, you can ask your agent:

That you should get to the stage where you have a slider. Prompt it to your liking to get the UI you want.

Code for name your price paywall

Here’s a pretty lengthy code sample that aims to replicate the slider flow you saw in the beginning:

This fetches your current RevenueCat Offering, sorts the available packages by price, and maps each package to a slider step. When the user taps Unlock Pro, the app purchases the currently selected package and then checks whether the pro entitlement is active.

Because every price tier unlocks the same entitlement, the app does not need separate access logic for Bronze, Silver, Gold, Platinum, or Diamond. The selected product only controls how much the user pays.

Wrapping up

A “name your price” paywall is surprisingly simple to implement. Under the hood, it’s just multiple products linked to the same entitlement, with a slider that lets users choose the level of support that feels right to them. The approach works especially well for indie apps, creator tools, open-source projects, and products where users genuinely want to support ongoing development. Instead of forcing customers into a single price point, you give them flexibility while keeping your purchase logic and entitlement management simple.

Because everything is powered by RevenueCat Offerings, you can also experiment over time. Add or remove price tiers, change your default recommendation, or test entirely different pricing strategies without rebuilding the underlying purchase flow.

If you build one, I’d love to see it. Tag me on Twitter at @plahteenlahti and let me know what pricing tiers you decided to offer.

Sources

Migrating native BillingClient and StoreKit code to shared Kotlin Multiplatform in-app purchases

Mon, 08 Jun 2026 03:06:25 GMT

Most teams that adopt Kotlin Multiplatform share their networking, models, and business logic first, and leave in-app purchases for last. Billing is the one layer where Android and iOS share almost nothing: a BillingClient connection and a PurchasesUpdatedListener on one side, a StoreKit transaction listener and manual receipt verification on the other, with two server-side validation paths behind them that have to agree on what “subscribed” means.

Migrating that to a shared layer is less about rewriting Kotlin and more about replacing two purchase state machines with one. This article walks through collapsing both native billing stacks into a single commonMain integration backed by RevenueCat’s Kotlin Multiplatform SDK, without losing the customers who already paid through your existing code.

In this article, you’ll add the RevenueCat SDK to an existing project, replace two platform initializers with one commonMain configuration, migrate product loading, the purchase flow, and entitlement checks, bring existing purchasers across with syncPurchases, keep user identity stable through logIn, and verify parity before you delete the old BillingClient and StoreKit code.

The reason billing resists code sharing is that the two platforms model a purchase differently at every step, and the types never line up.

On Android, you own a connection. You build a BillingClient, register a PurchasesUpdatedListener, start the connection, and handle reconnection when the service drops. The result of a purchase arrives asynchronously on the listener, not as a return value:

After the buyer confirms, you are not done. You verify the purchase token on your server against the Google Play Developer API, grant the entitlement, and then acknowledge the purchase. If you fail to acknowledge within three days, Google Play automatically refunds the user and revokes the purchase:

On iOS, the shape is different. There is no long-lived connection, but there is a verification step you cannot skip, and you finish each transaction by hand:

Reading the current entitlement state is two unrelated APIs. Android queries owned purchases and you map purchase tokens back to entitlements yourself. iOS iterates Transaction.currentEntitlements and you verify each one. The objects are different, the verification model is different, and the field that tells you “this user has premium” does not exist in either SDK. You compute it.

Underneath both clients, you typically run two receipt validation paths, because a Google purchase token and an App Store signed transaction are validated against different servers and stored in different shapes. Every concept in your subscription logic exists twice, and the two copies drift.

The shared model that replaces both

RevenueCat’s KMP SDK does not expose BillingClient or StoreKit through a thin shim. It replaces both with four store-agnostic concepts that live in commonMain:

Offerings are the set of products you currently sell, configured in the dashboard rather than hardcoded in the app.
Packages are the buyable units inside an offering, such as monthly, annual, or lifetime.
Entitlements are the access levels your app checks, such as premium, independent of which store the user paid through.
CustomerInfo is one object that aggregates every active entitlement for the current user across platforms.

Once your code asks customerInfo.entitlements["premium"]?.isActive instead of “did this user buy token X on Google or sign transaction Y on Apple,” the platform split disappears from your app. The migration is mostly a matter of deleting the per platform machinery and routing each old call to its shared equivalent:

Native Android / iOS	Shared `commonMain` call
`BillingClient.startConnection` / StoreKit listener setup	`Purchases.configure(apiKey) { }`
`queryProductDetailsAsync` / `Product.products(for:)`	`awaitOfferings()` or `awaitGetProducts(ids)`
`launchBillingFlow` + `onPurchasesUpdated` / `product.purchase()`	`awaitPurchase(package)`
acknowledge / `transaction.finish()`	handled by the SDK
server side receipt validation	handled by RevenueCat’s backend
`queryPurchasesAsync` / `Transaction.currentEntitlements`	`awaitCustomerInfo()`
restore button / `AppStore.sync()`	`awaitRestore()`
importing existing purchasers	`awaitSyncPurchases()`

The rest of this article walks through each row from top to bottom.

What the SDK does at the platform boundary

Before changing your code, it helps to see that the shared API is not magic. The translation from native types to KMP types is an explicit boundary that you can read in the SDK’s mappings module, and seeing it removes the worry that something is hidden.

StoreProduct is a good example, because Google’s ProductDetails and StoreKit’s product type have nothing in common. On Android, the mapping wraps the native object and reads its Kotlin properties directly (simplified here to the fields that matter for the contrast):

The iOS mapping, also simplified, implements the same StoreProduct interface, but the native value is reached through Objective C bridged method calls rather than properties, and the platform specific fields flip:

Notice the two design decisions that make one interface work on both stores. First, access is wrapped.id on Android but wrapped.productIdentifier() on iOS, because the Android side wraps the native RevenueCat Android model while the iOS side wraps a StoreKit backed value reached through Kotlin/Native interop. Second, fields that only exist on one platform are filled with safe defaults on the other: subscriptionOptions is a Play Store concept, so it is null on iOS, and discounts is an App Store concept, so it is emptyList() on Android. Your common code reads a single StoreProduct and never branches on the platform.

This is the boundary you are migrating onto. Everything below replaces a native call with a call into this shared model.

Step 1: Add the SDK and drop the native billing dependencies

Add the SDK to your shared module’s commonMain source set. The core artifact carries the platform bindings inside it, so there is no separate androidMain dependency on Play Billing and no iOS pod:

If you are coming from the 2.x line, the iOS side changed in a way that matters here. In 2.x you pinned a PurchasesHybridCommon pod and kept its version in sync with the SDK. As of 3.0.0 the iOS native dependency is pulled through Gradle as a Swift Package Manager build of purchases-ios, so a consumer app has no Podfile, no PurchasesHybridCommon, and nothing to pin. The Kotlin framework your shared module produces already contains the RevenueCat symbols. The same release raises the Android floor to API 23 (Android 6.0) because it ships on Play Billing Library 8.3.0, so set minSdk = 23 if you are lower.

You do not delete your BillingClient and StoreKit code yet. You will route around it step by step, verify parity, and remove it at the end.

Step 2: Replace two initializers with one

Native initialization is two separate jobs. On Android, you build and connect a BillingClient and hold its connection state. On iOS, you register a StoreKit transaction observer early in the app lifecycle so you do not miss updates. Neither has a shared form, so they live in androidMain and Swift respectively.

With the SDK, configuration is one call in commonMain that runs once at startup:

The configure(apiKey) { } form is a small builder. Inside the trailing lambda you can set appUserId, purchasesAreCompletedBy, and the other options on PurchasesConfiguration.Builder. The API key is the one value that differs per platform, so inject it with expect/actual or a tool like BuildKonfig, using your Android key on the Android target and your iOS key on the iOS targets.

Two things you used to manage are now gone. There is no connection to open and reconnect: the SDK owns the BillingClient lifecycle on Android and the StoreKit transaction listener on iOS. And there is no Context to thread through on Android, because the SDK captures the Application through an androidx.startup initializer. On iOS, nothing in your Swift code imports RevenueCat at all. The same configure call covers both platforms.

Step 3: Replace product loading

Loading products natively means describing each product to the store SDK and parsing back a platform-specific response. On Android, you build a QueryProductDetailsParams, set a product type, and parse the QueryProductDetailsResult that the Play Billing 8 callback returns, reading subscriptionOfferDetails and pricing phases off each ProductDetails. On iOS, you call Product.products(for:) with a set of identifiers. The two responses share no type.

The shared replacement reads the offering you configured in the dashboard:

Offerings.current is the offering marked as current in the dashboard. Offering exposes named accessors for common cadences such as monthly, annual, and lifetime, plus availablePackages if you build a custom plan picker. Because the product list comes from the dashboard, you can change which products an app version sells without shipping a build, and the prices arrive already localized for the user’s storefront.

If you are not using offerings yet and want a direct lookup that mirrors your old queryProductDetailsAsync call, awaitGetProducts(productIds) takes a list of identifiers and returns List<StoreProduct>. Both methods are suspend functions, so they replace the listener and async callback with a straight line call.

Step 4: Replace the purchase flow

This is the step that removes the most code. Natively, a purchase is a multi stage process you orchestrate by hand. On Android, you build BillingFlowParams, call launchBillingFlow, wait for the result on onPurchasesUpdated, check PurchaseState, verify the token on your server, grant the entitlement, and acknowledge within three days. On iOS you call product.purchase(), switch on the result, verify the signed transaction, grant the entitlement, and call transaction.finish().

The shared replacement is one suspend call:

awaitPurchase opens the native purchase dialog, validates the receipt on RevenueCat’s backend, finishes the transaction on the store, and returns a SuccessfulPurchase. Read the result through its properties, purchase.storeTransaction and purchase.customerInfo, since it is a plain class rather than a destructurable data class. By the time the call resumes, the receipt is validated and the user’s CustomerInfo already reflects the new entitlement, so anything bound to your customer info state updates on its own.

Two behaviors from the native flow are now handled for you. Acknowledgement and finishing happen inside the SDK, which means the three day Google Play refund trap is closed by default. Cancellation is surfaced as a PurchasesTransactionException whose userCancelled flag is true, so you can distinguish a buyer backing out from a genuine error in one catch.

There is one nuance worth keeping if you sell consumables. Play Billing Library 8 removed the ability to query already consumed one time products, the APIs the SDK previously relied on to restore them, so a consumable that was consumed cannot be reconstructed on the client. Grant those entitlements server side, through your backend or RevenueCat’s grant API, rather than relying on a client restore. Subscriptions and non consumable products are not affected.

Step 5: Replace entitlement checks

Natively, “is this user subscribed” is a computation. On Android you call queryPurchasesAsync, walk the returned purchases, and map each token to one of your entitlements. On iOS you iterate Transaction.currentEntitlements, verify each transaction, and map product identifiers to entitlements. Both produce your own boolean.

The shared form is a property read:

CustomerInfo.entitlements is an EntitlementInfos wrapper, and its indexing operator returns a nullable EntitlementInfo, which is why the null safe ?.isActive == true is the correct check. The "premium" key is the entitlement identifier you set up in the dashboard, not a product id. When you need more than a boolean, EntitlementInfo carries the fields you previously reconstructed yourself:

isActive is the only field most access decisions need.
willRenew tells you whether the subscription is set to renew, which you cannot reliably derive from a purchase token.
store reports where the entitlement was unlocked, such as PLAY_STORE or APP_STORE.
periodType distinguishes a TRIAL or INTRO period from a NORMAL one.
expirationDate is the entitlement’s expiry, or null for lifetime access.

The value is active whether the user subscribed through Google Play, the App Store, or a promotional grant from your support team, which is the property that lets you delete the per store mapping code on both platforms.

Step 6: Bring your existing purchasers with you

A migration is not a fresh install. Your existing customers already paid through your old native code, and RevenueCat does not know about those purchases yet. Skipping this step is how a migration silently locks out paying users, so treat it as part of the cutover rather than a follow-up.

For users whose purchases live on the store account, call syncPurchases once after configuring. Its KDoc states the intent directly:

This posts the store receipts already on the device to RevenueCat, which reconstructs the customer’s entitlement state from them. It is a migration and observer mode tool, not something you call on every launch.

If you want to de risk the cutover, run the SDK in observer mode first by setting purchasesAreCompletedBy to MyApp. In this mode your existing billing code keeps completing purchases while RevenueCat observes and builds its view of your customers, so you can compare its entitlement data against your current source of truth before you flip the switch:

Note the trade-off the SDK calls out in the same configuration: when purchasesAreCompletedBy is MyApp on Android, you are still responsible for acknowledging purchases yourself, and failing to acknowledge within three days lets Google Play refund the user and revoke the purchase. Observer mode is a staging step on the way to letting RevenueCat complete purchases, not a permanent home.

Step 7: Keep user identity stable

The last piece is identity, because losing it is the other way a migration drops entitlements. If you left appUserId null, the SDK uses an anonymous identity it generates and persists. The moment you can tie purchases to your own account system, identify the user so their entitlements follow them across devices and reinstalls:

awaitLogIn returns a SuccessfulLogin with the merged customerInfo and a created flag.

RevenueCat maintains the alias graph between the anonymous identity and the identified one on its backend, so purchases made before login transfer to the account. On logout, awaitLogOut clears the saved id and returns to a fresh anonymous user.

This also clarifies when to use restore versus login. awaitRestore posts the purchases on the current store account to the current user, which is what Apple’s required restore button should call. Apple mandates a visible restore control regardless of whether you have your own account system, so that button stays even when logIn already covers continuity for you.

The SDK’s own guidance is that if you have your own account system, you do not need restore for continuity, because “restoration” is simply your app passing the same appUserID the customer used when they first purchased. In practice, rely on logIn for account based continuity and keep the restore entry point for store account based recovery.

Verify parity before you delete anything

The native code stays until you have proven the shared path matches it. Run this checklist on a sandbox account on both platforms before removing BillingClient and StoreKit code:

Products load correctly from awaitOfferings on both platforms with correct localized prices.
A purchase completes end to end through awaitPurchase, and the entitlement flips to active without your old acknowledgement or finish code running.
An upgrade or downgrade between plans works on Android with the right oldProductId and replacement mode, since that path is the most likely to regress when you remove the native BillingFlowParams code.
A pending purchase, such as a deferred cash payment, resolves to an active entitlement, matching the enablePendingPurchases behavior your native code used to handle.
Cancellation surfaces as PurchasesTransactionException with userCancelled true, not as an error.
Trial and introductory state renders correctly through periodType, remembering that eligibility itself is iOS only.
Existing purchasers see their entitlements after syncPurchases or restore, including a reinstall test.
Identity merges correctly: a purchase made anonymously appears under the account after logIn.

Once those hold, delete the BillingClient setup, the PurchasesUpdatedListener, the acknowledgement code, the StoreKit purchase and verification code, and the com.android.billingclient:billing dependency. If you ran observer mode, you can also retire the parts of your receipt validation server that the RevenueCat backend now covers, or keep them running in parallel until you are confident.

What still needs platform awareness

The shared model covers the common path, but a few capabilities remain tied to one store, and it is better to know which than to assume the abstraction hides everything:

Introductory and trial eligibility are iOS-specific. awaitTrialOrIntroPriceEligibility returns a real status on iOS and UNKNOWN on Android, where Google computes eligibility itself.
Win back offers require iOS 18 and StoreKit 2, and the related calls throw on other configurations.
Personalized price and replacement mode for upgrades are Play Store only parameters on awaitPurchase, ignored on iOS.
Amazon Appstore support is opt-in through a separate purchases-store-amazon dependency on the Android source set.

These stay as small, well-marked branches in otherwise shared code, rather than the two full billing implementations you started with.

Conclusion

Migrating to a shared in-app purchases layer is mostly subtraction. You replace two initializers with one configure, two product queries with awaitOfferings, two purchase pipelines with awaitPurchase, and two entitlement computations with one entitlements["premium"].isActive check, then bring your existing customers across with syncPurchases and logIn before deleting the native code. What remains is one purchase flow to reason about instead of two.

Why are React Native apps making more money?

Wed, 03 Jun 2026 15:02:21 GMT

Earlier this year, we released the newest version of our annual State of Subscription apps report (SOSA), which contains a huge amount of interesting insights for app builders. One of these insights was how well apps with different development stacks (also referred to as frameworks in the report) are performing when it comes to monetization.

This one insight turned out to be rather controversial, despite the previous year’s data showing similar results: React native apps are monetizing better than Flutter and native apps. Specifically, they are excelling in:

Higher conversion from download to paid
Higher revenue per install
Higher lifetime value

When I tweeted about it, some developers were quick to question the results, the dataset, correlation vs causation, and essentially everything that goes against the “intuition” that technology is the key to building great apps that customers want to pay for. This article is about looking at the data and figuring out the why.

How is this data collected?

The data for the State of Subscription Apps report is collected from 115,000 apps, making a combined $16 billion in revenue. RevenueCat tracks more than the mentioned amount of apps, but only apps that have active subscription revenue, meet a minimum threshold of installs and revenue (to ensure statistically meaningful findings) are included in the report. Apps come from indie teams to mid-size organizations and large publishers.

The time frame for the data is 2025. This means that the data set includes apps built with agents and vibe coding tools. All data is anonymized and aggregated, ensuring that no single app’s performance metrics are individually identifiable. The findings are presented as aggregated performance benchmarks across segments, categories, and platforms.

Understanding the visualizations

Before diving into what the numbers tell us about React Native, Flutter, and native apps, it’s important to understand the structure of the SOSA dataset and how its visualizations work, since I’ll be showing them in this article.

The report uses box-and-whisker (candlestick) charts to visualize the data:

Lower ‘whisker’: marks P10 (10th percentile), the bottom 10% of app performance.
Bottom of the ‘box’: marks P25 (25th percentile) and represents Q1 (bottom quartile) — apps below this make up the lowest 25% of performers.
Marker inside the ‘box’: marks P50 (50th percentile) and represents Q2 (median) — this is the midpoint of app performance.
Top of the ‘box’: marks P75 (75th percentile) and represents Q3 (upper quartile) — apps above this fall into the top 25% of performers.
Upper ‘whisker’: marks P90 (90th percentile) — apps here or above are the highest performers.

This structure gives a more realistic picture of how apps perform in the real world. The “box” shows where most apps cluster, while the whiskers show the spread between weaker and exceptional performers. When we talk about React Native outperforming other stacks, we’re referring to these distribution points — not isolated outliers.

React Native leads in download to paid conversion

The first chart to look at is the Download-to-paid conversion rate (D35): the share of installs that result in at least one paid subscription within 35 days of the install date. This metric captures how effectively an app converts new users into paying customers in the first ~5 weeks.

The first thing you should notice from this chart is that React Native apps have the highest median conversion rate at 2.5%. That might not sound like much, but it is still 25% higher than native and Flutter. However, the absolute spread between stacks is modest compared to within-stack variation.

After that, pay attention to the top whisker of React Native. Being higher than others means that top React Native apps are outperforming other stacks; at the same time, the results are very widespread. Some React Native apps do great, others don’t.

First key learning: execution matters far more than stack choice

If you look at the spread inside each stack, you start to get a picture of the real insight in this data: the variance within a stack absolutely dwarfs the variance between stacks.

Put another way, the top performers convert to paying customers 10+ times better than the bottom performers in their own stack. Execution matters more than the stack itself.

What’s actually pulling the top React Native apps ahead? Probably not the stack itself. More likely, it’s the teams building them. These teams have to focus on two things to win: building a great app and monetizing it effectively. Stack choice can enable you to do that, but it is not a magic spell that doubles your conversion.

React Native apps generate more revenue per install

The second chart to look at is the revenue per install (RPI) chart. This chart tells us how much revenue an app makes 14 days after a user installs it. From the chart, we can see that React native leads with a median of $0.34, which is 55% higher than native and 79% higher than Flutter. The top quartile of React Native apps is also making more money than the top quartile of Native or Flutter apps.

Despite React Native’s numbers looking good, there is a huge difference between apps using the same stack. Some apps are only making $0.10 per install, compared to some making $2.58. Similar patterns exist across every stack. The difference between top-performing and bottom-performing apps is far larger than the difference between the stacks themselves.

Second key learning: feedback loops

Stack choice appears to have a relationship with monetization outcomes. One possible explanation is that successful subscription businesses tend to optimize relentlessly based on customer feedback.

As discussed in the previous section, building great products is largely about shortening the time between learning something from customers and acting on it. The faster a team can understand what customers want, which features they value, and what they are willing to pay for, the faster it can improve the product. Over time, this creates a powerful feedback loop that compounds into a better user experience and stronger monetization.

React Native can be a strong fit for this style of development. Services such as EAS and Codemagic allow teams to ship many changes instantly without app reviews, while tools like RevenueCat enable teams to experiment with pricing, offerings, and paywalls without requiring a new app release. Together, these tools can reduce the time between identifying an opportunity and delivering an improvement.

That said, the chart still suggests that execution matters more than stack choice. The difference between the highest- and lowest-performing apps within each stack is much larger than the difference between the stacks themselves. While React Native apps generate more revenue per install on average, the data does not suggest that React Native is a prerequisite for strong monetization.

React Native pulls further ahead by day 60

Download to paid percentage, and revenue after 14 days tells about the early success React Native apps have with customers. Looking at the revenue per install after 60 days starts to tell a stronger story of React Native’s monetization performance. React Native not only seems to hold the gap, but actually widens it to other development stacks.

With median revenue per install at $0.51, compared to the $0.31 for native apps and $0.29 for Flutter apps, React Native apps earn almost 65% more revenue per install than the former, and 76% more than the latter. For reference, the numbers were x and y for 14-day revenue per install.

However, as with the day 14 data, the biggest differences are not between stacks but between apps. Within React Native alone, revenue per install ranges from roughly $0.16 at the lower end to $3.60 at the upper end.

Third key learning: monetization is a product problem

If monetization gains persist for two months, the explanation probably isn’t a better payment process. Realistically, it’s about the product being great. Monetizing well beyond the first month means that apps built with React Native are clearly valuable products that users want to pay for. To get to that, you need to be a product-oriented person or a team.

Something in React Native makes product-oriented teams choose it. Reasons are many, but they most likely come down to the benefits that it provides, most of which I’ve already mentioned. When I originally posted about how well React Native is monetizing, all the people who challenged the results were engineers. From an engineering perspective, React Native is easy to challenge; there’s a bunch of weird stuff if you compare it to something like Swift.

However, most customers are not engineers, and even if they are, they don’t approach the products they use from an engineering perspective. For them, it’s more important if the product solves the problem, not how.

What does this mean in practice for a developer who is building an app? First, focus on evaluating the benefits of the development stack from a product perspective: what gives you the best results with your current capabilities. Second, validate with a stack that gives you results the fastest. Nothing’s stopping you from going from React Native to Swift UI after you’ve built the first version of the app, and you feel that your technology of choice is the limit. As long as you don’t choose a technology based on what other engineers said, you’re probably good.

Year-1 Retention by plan type shows only modest differences across stacks

Here’s the real story of this article: retention at one year barely differs between Native, Flutter, React Native, or any other stack. That means React Native’s massive lead in conversion and revenue cannot be explained by better long-term retention. Users don’t stay subscribed longer in React Native apps. They stay about the same.

And that is the interesting part, because it tells us exactly where the advantage must be coming from:

React Native apps convert more users earlier
React Native apps extract more revenue per install
But when it comes to keeping customers for a year, all stack perform similarly

In other words, React Native wins by front-loading value, not by keeping users longer. If an app reliably solves a recurring problem, users stay subscribed. Data tells us that technology choices matter less in the long term, at least when it comes to keeping your customers.

Fourth key learning: play long-term games

The retention data tells an important story: stack choice has very little impact on whether customers stay subscribed over the long term. Annual retention rates are remarkably similar across Native, Flutter, and React Native apps.

Your app business should not be about stacks and hacks, at least if you’re in it for the long term. It’s possible to build a decent business by monetizing a loved product with a small but significant audience. As long as you keep those customers.

Frameworks can help teams move faster, experiment more often, and improve their products more quickly. But they cannot replace the fundamentals: understanding customer problems, building features people genuinely need, and delivering enough value to justify an ongoing subscription. Do that, and you keep your customers for longer. The longer you keep your customers, the more money they make. More money long term will eventually win over apps that convert better, or charge more (unless they also retain users better).

Retention data here is a reminder that customer loyalty is earned through product value, not technology choices. If customers continue finding value in your product months after they subscribe, they’ll keep paying regardless of whether the app was built with React Native, Flutter, or native technologies.

React Native delivers the highest RLTV per paying user — by a wide margin

While the previous section brought some hope for people thinking that React Native is just an anomaly in early-stage monetization, our last chart about realized lifetime value (RLTV) is going to shatter that hope (at least a bit).

RLTV measures how much revenue a paying customer generates during their first year. In other words, once someone becomes a subscriber, how much are they actually worth to the business?

And the results are hard to ignore. The median React Native app generates $31.78 in first-year lifetime value per payer. Native and Flutter apps, meanwhile, are clustered around $21. That’s a difference of roughly 50%.

The gap isn’t limited to the median either. The top React Native apps generate more value from paying customers than the top Native and Flutter apps, reaching $95.32 in RLTV compared to $74.68 for Flutter and $61.81 for Native.

At this point, a pattern starts to emerge. React Native apps convert more users into customers. They generate more revenue after 14 days. They generate more revenue after 60 days. And now we can see that their paying customers are worth substantially more over the course of a year. As we saw in the last section, there’s no meaningful difference in retention between the stacks. Yet React Native apps still generate significantly more value per payer.

That suggests the explanation is not retention alone. React Native apps appear to be doing a better job of monetizing the customers they acquire, whether through pricing, packaging, product positioning, customer quality, or a combination of all four.

Fifth key learning: valuable customers beat more customers

One of the most encouraging things about this data is that it doesn’t suggest you need millions of users to build a successful app business. The apps that perform best are not necessarily the ones attracting the most customers. They’re often the ones creating the most value for the customers they already have.

Looking at the retention data, React Native apps don’t appear to keep subscribers significantly longer than Flutter or native apps. Yet those same subscribers end up being worth substantially more over the course of a year.

That should be good news for builders. It means success isn’t just about growth at all costs. You don’t need to win every download, dominate every category, or have the largest audience. Sometimes the biggest opportunities come from deeply understanding a smaller group of customers and building something they’re genuinely happy to pay for.

The best subscription businesses are often built this way. They solve a real problem, deliver enough value that customers stick around, and continuously improve over time. When you do that, each customer becomes more valuable. Not because you’re extracting more from them, but because you’re giving them more reasons to stay.

Predictions for next year’s State of Subscriptions app report

We now have two years of React Native leading the framework monetization section (report from 2025 showed similar results). The question is, of course, whether we still see similar results next year.

Last year we started a little bit of the agentic coding workflow, which is now the default for most developers. It will be interesting to see how that might change the results. Previously, React Native was argued to be the easy stack to land on if you were a beginner, or came from, for example, a web development background. Now that advantage is gone. You can easily build apps with any language, without having to understand it yourself.

What most likely happens is that we will get more apps than ever before, built in a variety of technologies. If developers focus on the principles of building great apps, the ones that this article has hammered on as well, we most likely see stabilization in the data. Perhaps a slightly hopeful prediction is that differences between frameworks will get smaller. Hopefully not at the cost of conversion, retention, and LTV. Realistically, we will see all of those go down, as the quality of new apps is generally low still.

But that could, of course, change as we are only halfway through the year.

We recently rolled out support for tracking ad revenue and impressions alongside your subscription data. We will hopefully have this in next year’s report, as it might tell a completely different story when it comes to monetization. Who knows, maybe Flutter apps take the lead because they are better at utilizing subscriptions and ads together?

Conclusion

In this article, we’ve looked at all the different ways React Native apps are monetizing better than native and Flutter apps, and the reasons behind that. At each section, I’ve done my best to summarize how a developer should interpret this data and make use of it. Even if they’re not building with React Native.

The lesson for developers is simple: focus on building a tight feedback loop with your customers. Whether you’re using React Native, Flutter, or native technologies, the teams that learn fastest, iterate fastest, and continuously improve their product are the ones most likely to win. The strongest monetization outcomes don’t appear to come from a secret framework feature or growth hack. They come from building products that people truly value.

Why you should build another to-do list app (with a little help from Claude)

Wed, 03 Jun 2026 12:47:46 GMT

The conventional wisdom in the indie developer community is clear: do not build a to-do list app. It is the ultimate crowded market. It is the “hello world” of app development, a space dominated by Apple’s native Reminders, venture-backed giants, and a million abandoned weekend projects.

But when Austin Blake decided to go all-in on his indie career, he dropped five other projects to focus exclusively on Stuff, his aggressively delightful task management app.

“People will tell you that you can’t compete in a space,” Austin says. “And I’ve gotten tons of emails and feedback, some of which are pretty harsh. Like, ‘We don’t need another to-do list app, why are you wasting your time on this?’ But there’s always room for additional competitors. You just have to commit to it and spend time on it.”

In a conversation with Launched host Charlie Chapman, Austin shares how he built a native Mac app using AI agents, why he cut his free trial by 75%, and the brutal realities of launching on macOS.

The “vibe coding” workflow: Letting AI agents peer-review each other

Austin had never built a Mac app before. He started the traditional way—buying Paul Hudson’s Hacking with Swift: macOS Edition—but quickly pivoted to a highly modern, AI-driven workflow. He didn’t just ask Claude to write code; he built a multi-agent system to write and review his development plans.

“I make plans for everything, and then pass them between the agents and have them review each other’s plans,” Austin explains. “And then I review all of the code before it goes in.”

By letting one AI agent generate a technical plan, another critique it, and a third write the code, Austin bypassed the steep learning curve of AppKit and macOS-specific APIs. This collaborative loop saved him hundreds of hours of manual troubleshooting.

“Just the amount of things that I didn’t have to spend hours learning how to do on the Mac, and just letting that give me a first-pass prototype, saved me a ton of time and honestly let the app come out sooner than it would have.”

The hidden design differences between iPad and Mac

Porting an iOS or iPadOS app to macOS is rarely as simple as checking a box in Xcode. Even though modern iPads support larger screens, the user expectations on desktop are entirely different.

One major realization was the concept of selection states. On an iPhone, you tap a task and it immediately opens. On a Mac, users expect to navigate using arrow keys, highlight a task without opening it, and press Enter to expand the details.

“There’s this intermediate state that I had to add,” Austin says. “And then there are things like undo. Check a task complete and being able to undo it with Command-Z—that’s something you just expect to work. On iPhone, people don’t shake their phone violently to undo a task, but on Mac, it has to be a thing.”

Furthermore, while mobile design focuses on making full-screen experiences look good, desktop design requires optimizing for the incredibly small. Desktop users rarely full-screen their notes or reminders; they want to shrink them into tiny pockets of information pinned to the corner of their screen.

“You can make Stuff windows pretty dang small to the point where you could just have your monthly goals sitting up in a tiny box in the corner of the screen. There are a lot of affordances like that on Mac that make productivity apps in particular very fun to design for.”

The 7-day trial experiment: Why less time means more conversions

Like many subscription-based apps, Stuff initially launched with a one-month free trial. It felt generous, giving users plenty of time to experience the app. But Austin noticed a massive drop-off. With 30 days on the clock, users lacked the urgency to build a daily habit, and eventually forgot about the app entirely.

Without complex A/B testing tools, Austin trusted his gut and slashed the trial period down to seven days.

“I am a very bad tester, I’ll be honest. Everything I do is basically through gut,” Austin admits. “I saw a lot of drop-offs with trials, and I said, ‘One month is probably too long, I’ll drop it down to one week.’ And I did see a rise in conversions.”

Slashing the trial length kept the app top-of-mind. Users had to actively decide whether Stuff fit into their workflow while their initial excitement was still high, leading to a direct bump in paid subscriptions.

The App Store review trap: Budget three weeks, not three days

When Austin prepared to launch the Mac version of Stuff, he gave himself what he thought was a generous buffer: he submitted the app for review a full week before the scheduled launch date.

It wasn’t enough. The app was rejected multiple times—not for new Mac features, but for existing iOS features that had been approved in the App Store for years.

“I was rejected for a lot of different things over the Mac app, which are part of the reason it took so long,” Austin says. “But all of those things were already present on the iOS app. It was just me saying, ‘Hey, this is already approved. We’ve already talked about this.’ It was a lot of back and forth.”

Austin ended up launching three days later than planned, disrupting his coordinated marketing push. His advice for anyone launching a new desktop app? “Next time, I would give it honestly, probably three weeks. Just to give you plenty of time.”

In the full episode, Austin also talks about his path from a BYU film major to working as a contractor at Apple, how Stuff was featured in the Apple Newsroom for its on-device foundation models, and his transition to joining the RevenueCat team as a Developer Advocate.

Guest links:

20% of your churned users will come back – but are you ready?

Thu, 28 May 2026 08:16:41 GMT

Imagine you’re dating someone you really like and they suddenly end the relationship. Do you jump straight back onto the apps, chasing someone new? Or do you pause and ask the harder question: why? And maybe, if it feels fixable, try to convince them to give it another go.

I’m very glad my husband chose the second option when I got a classic case of cold feet months into our courtship. Otherwise, nearly ten years later, we wouldn’t still be together.

Most apps default to the first approach. They get caught up in the chase – dating as acquisition – endlessly pursuing the rush of new users rather than asking the ones who leave why they left. But reactivation is a huge, often-overlooked opportunity for apps that truly engage their audience.

Of course, not every relationship is salvageable. Sometimes they’ve found a better fit (whether that’s another app or another person), you’re out of their price range (a high-maintenance relationship), or they simply no longer need what you offer (they prefer the single life). But in many cases, users do come back. They might need your app again, or they might just be open to giving you a second chance.

Reactivation isn’t a universal strategy, but for the right apps, it’s one worth serious consideration.

When reactivation happens, the most

Reactivation is fascinating because it varies widely by price point, category, subscription length, and even geography. For one app, it can be a huge growth lever; for another, barely worth the effort.

Let’s break down the five key factors that shape reactivation:

The use case
Subscription duration
Category
Price point
Geography

I’ve tried to rank them by impact on reactivation.

1. The use case

Dan Layfield, founder of Subscription Index, makes a great point in the SOSA 2026 report: “Users reactivate when the problem comes back, not when your win-back email lands.”

All the factors we cover are irrelevant if there is no reason for your users to come back. With a short-term use case, you won’t see high reactivation, no matter what the category and price point data suggest. As Dan puts it:

“The best products at win-back strategies serve a problem that recurs in the user’s life. Think about dating apps – you cancel when you’re in a relationship and come back when it ends. The same pattern plays out in fitness, entertainment, and any category where need is cyclical.”

Dan also highlights that there are different durations apps get used for on a Sub Club episode, and which one you fall into will impact your reactivation potential, and also how and when you can reactivate users:

Cyclical apps. These are the gold standard for reactivation. The user’s need naturally returns, often predictably. Dating, fitness, and weight management all fall into this bucket, whether it’s a breakup, a New Year reset, or a looming holiday. If you have a strong user context, you can almost anticipate when they’ll be back.
Daily habit apps. Here, usage is ongoing, but fragile. Users don’t “finish” the product; they drift away. Reactivation is less about timing and more about emotion: why did they fall out of the habit, and what would pull them back in? Think meditation, language learning, or journaling. Winning these users back means tapping into motivation, guilt, identity, whatever drove the habit in the first place.
Project-based apps. These are tied to specific, short-term goals. Once the task is done, the user leaves, but may return when a similar need arises. Photo editing, CV builders, productivity tools, and reactivation exists, but it’s irregular and often harder to predict.

And then there’s a potential fourth category worth calling out:

AI apps (the wildcard)

AI products don’t fit neatly into any one bucket. Users often cycle through them by trying, churning, experimenting with competitors, and occasionally returning when something falls short elsewhere. That creates a unique dynamic: higher churn, but also surprisingly high reactivation potential. The trigger isn’t always a life event; it’s comparative value.

Before investing in reactivation, ask a more fundamental question: Does your user have a reason to come back at all?

If you’re seeing strong activation and usage but consistently low reactivation, it may not be a failure of strategy. It might just be the nature of your product.

2. Subscription duration

Monthly subscriptions have always been tied to a more “let me give it a go” mindset, so it’s no surprise that, across geographies, price points, and most categories, they consistently deliver the highest reactivation rates.

This usually ranges from 18% to 24%, far exceeding the annual reactivation rate, which is more commonly around 4-6%. While the SOSA report only looks at overall reactivation rather than by subscription type, I’ve seen monthly subscriptions reactivate as annual subscriptions; users cancel their monthly plan after testing the app and then upgrade to an annual plan.

Annual subscription churn, it is sad to say, is much harder to reverse. They’ve spent a lot, they’ve decided to leave, and they aren’t likely to come back soon. At a 4-6% reactivation rate, you’re going to have to do a lot of sweet talking and work to get them back.

Interestingly, monthly reactivation exceeds the weekly reactivation rate, while weekly subscriptions are often used to try out an app; they reactivate at only 7-10%. My theory is that this is likely due to short-term use cases or users not having enough time to really get into the habit of using the app.

Now there are some categories where this varies, which brings us on to another major factor: category.

3. Category

From the State of Subscription App Report, we can see high variance in reactivation rates across categories.

There are a few key honorary mentions among the many categories covered:

A. Productivity

36.1% reactivation rate for monthly subscriptions. This category is heavily skewed toward monthly subscriptions due to the nature of SaaS products, but I also believe AI is playing a role in driving this even higher, especially as it has increased significantly since last year (more on this later).

There is a lot of “serial dating” with AI tools, with users testing and trying a variety of new products. We know from the report that there is higher churn in AI apps, which could also be contributing to this greater reactivation opportunity.

B. Gaming

Here, users rarely come back; it is the lowest average reactivation category. Lose them, and you’re gone for good, despite their addictive nature. This may be a case of player fatigue. Churn seems to be more permanent in this category. I’m an example of this for sure; since beating my Township addiction driven by their strong gamification, I haven’t been back (sorry, my little farm).

C. Shopping

Shopping and gaming are the only categories where weekly reactivation outperforms monthly subscriptions. For shopping, this reflects the more transactional and seasonal usage of shopping apps.

So, certain categories need to consider reactivation more seriously than others, as do certain price-point apps. A health & fitness app on mid-range monthly pricing can expect around 12% reactivation from its churned pool. A productivity app at the same price point sits at 36% for monthly subscriptions. Same effort, three times the return, which is why category is a key variable to consider.

4. Price Point

The higher the price point, the more likely a monthly user will come back. The difference is significant: high-priced monthly apps reactivate at 28.9%, nearly double the 15.4% seen in low-priced apps.

With high-priced apps, this could result from a higher initial commitment and a higher perceived value, making users more willing to return.

Interestingly, price point reactivation varies barely between weekly and yearly subscriptions. Only high-priced annuals are notably lower (4.4%) than low- and mid-priced apps (5.8% and 5.6%, respectively). Once a high-paying annual user is gone, they are hard to win back, so the focus should be on retention rather than reactivation.

So, high-priced apps with monthly subscriptions tend to have a bigger opportunity around reactivation. Now, what about geography?

5. Geography

I’ve seen some interesting differences in behavior from analyzing the geography graphs from SOSA (yes, I’m a huge nerd, I know). But reactivation – I am sad to admit – disappointed me.

Compared to other factors, geography plays only a minor role, especially compared to acquisition and retention, where we tend to see more variance.

Overall, Asia-Pacific leads in monthly reactivation at 24%, while North America is the lowest at around 18%; US users tend to be more decisive when canceling, at least when it comes to monthly subscriptions. MEA and Western Europe show slightly stronger yearly retention, indicating potentially longer-term user commitment.

Given how small the variance is compared to category and price point, geography is the least actionable of the five factors for most apps.

Now, with so many factors that cause variation, how on earth do you know if reactivation matters for you? Slow down. First, you need to make sure you’ve got a strong foundation in place.

Reactivation only comes after activation and habit building

Even if your calculations show that reactivation is a huge opportunity, before you get excited and start working out how to win users back and give them another chance, there’s another factor you need to check first:

When are they zoning out of the relationship? Were they ever in it to begin with?

If we were to stick with the dating trope, it would be: did they lose feelings, or did they never really have them in the first place?

Okay, I’ll drop the analogy now, that’s enough from a married woman.

Start by reviewing activation

If someone canceled after three days and never used your core features, winning them back isn’t a reactivation problem – it’s an activation problem wearing a reactivation costume (a real reactivation catfish).

Check your activation first. The signals that suggest you need to fix this before anything else:

Trial-to-paid conversion is lower than you’d expect
New users aren’t reaching your core features in the first week
Day 7 retention is low

The most useful thing you can do here is identify which early behavior best predicts long-term retention for your specific app. That’s your activation benchmark. If users aren’t hitting it, that’s where the work is.

Then check habit formation

It’s possible users activate fine, but never build the habit of coming back. Think of the journaling app you enthusiastically started in January. The stretching app that worked great until you went on holiday and somehow never picked it back up (the New Year’s subscription hangover is a real thing).

The signals here are slightly different:

Monthly subscribers churning at higher-than-expected rates in months 2-4
Annual subscribers canceling before they’ve had a chance to get value
Usage dropping off sharply around weeks 4-8

You need to ensure you’re building lasting habits.

If activation looks healthy and habit formation is holding up, then yes, reactivation is the lever worth pulling. And if the data backs it up, it’s worth pulling hard.

Reactivation is a growing opportunity

Here’s what makes reactivation different from almost every other growth lever: the opportunity gets bigger without you doing anything.

Every month that passes, more of your users churn. That’s the bad news.

The good news is that each of those churned subscribers joins a pool that only ever grows. Unlike acquisition, where you have to constantly work to fill the top of the funnel, the reactivation pool accumulates automatically.

An app churning 200 subscribers a month has 2,400 former subscribers after a year, and 4,800 after two years. At the SOSA 2026, the average reactivation rate of 20% for monthly subscribers, that’s already 480 to 960 subscribers a year coming back without a single win-back campaign running.

To put that in revenue terms: if your monthly plan is $12, that’s between $23,000 and $46,000 in recovered annual revenue, just from organic return behavior, assuming a modest four-month average hold period post-reactivation.

Now imagine actively working on it.

It is even growing year on year

Reactivation rates aren’t static, and the shift from 2025 to 2026 is significant enough to be worth paying attention to.

Overall, monthly reactivation has jumped from 13.7% in SOSA 2025 to 20.1% in SOSA 2026. That’s nearly a 50% increase in a single year. Most of this movement is largely explained by one category.

Productivity went from 17.1% to 36.1%, more than doubling in twelve months. The timing aligns directly with the mainstream adoption of AI tools. In 2024, users were still discovering AI apps. By 2025, they’d had enough time to try several, be disappointed by at least one, and circle back to tools they previously wrote off. The churn-and-return cycle that defines AI app usage has become a defining feature of the Productivity category, and it’s pulling the entire industry average up with it.

But even by geography, we see that every region saw monthly reactivation rise substantially, though North America rose the least, moving from 14.1% to 18.0%.

Whilst productivity skews the overall averages, almost all categories saw a slight increase:

I expect this trend will continue, with competition leading to more “let me test a few apps” behavior in other categories too.

Lean into the compounding effect as you grow

This has a compounding effect that most teams don’t account for. As your app grows, the churned pool grows with it. Reactivation as a share of total growth becomes more significant over time, not less. It’s why the most mature consumer apps – think Duolingo, dating apps, streaming services – treat reactivation as a core pillar of growth strategy, not an afterthought. They’ve simply been around long enough for the maths to become impossible to ignore.

So while reactivation might not be worth prioritizing when you’re just starting out, and your churned pool is small, it’s worth putting a flag in the calendar to revisit. The question to ask yourself every six months is: how big is my churned pool now, and what percentage of my growth could come from there rather than from new acquisition?

The answer tends to get more interesting over time.

Is reactivation worth it for you?

Here’s a rough decision guide before you use the calculator:

Reactivation is likely worth prioritizing if:

Your use case is cyclical (dating, fitness, weight management, seasonal) or a daily habit (meditation, language learning, journaling)
Monthly subscriptions make up a meaningful share of your base
You’re in Productivity, Photo & Video, Media & Entertainment, or Social & Lifestyle
Your activation and early retention metrics are healthy

Deprioritize reactivation if:

You’re in Gaming, the data suggests that once they’re gone, they’re gone
Your use case is genuinely one-and-done with no natural trigger for return
You haven’t yet solved activation or habit formation – fix the leaky bucket first

Now, if you think reactivation is an opportunity for you, it’s time to bring out the big guns. By which I mean my reactivation impact calculator.

The reactivation impact calculator

I’ll be honest about how this started. I was going to include a simple calculation in this article – a back-of-the-envelope number you could plug your churn rate into and get a rough revenue figure out of. That was the plan.

Then I started doing it properly. I pulled the SOSA data, started adjusting for category, then for price tier, then for subscription mix, and about an hour in I had a spreadsheet with seventeen tabs and a mild obsession I couldn’t quite explain to my husband.

The rough number I’d originally planned wasn’t just imprecise; it was misleading. A productivity app at a high price point and a gaming app at a low price point have almost nothing in common from a reactivation standpoint. Giving them the same benchmark would be worse than giving them no benchmark at all.

So I went back to the drawing board and built a proper one.

I’m slightly ashamed to admit how excited I got about the second version. My goal was simple: make something that could take your actual RevenueCat data (which is easy to access and doesn’t take long to pull) and tell you whether reactivation is worth your time, and if so, roughly how much it’s worth. Not a generic industry average, but your number, for your app, accounting for the factors that actually move the needle.

It took longer than expected, partly because the maths kept getting more interesting the deeper I went, and partly because I kept finding new edge cases (quarterly plans, anyone?). I stripped it back in the end to keep it simple.

A huge thanks to Ethan Garr, fellow growth advisor, who answered my increasingly specific questions with patience I did not deserve and gave suggestions that meaningfully improved the model.

The result gives you three scenarios – conservative, realistic, and optimistic – based on your category benchmark from SOSA 2026, adjusted for your price tier and subscription mix. It uses your actual subscriber data from RevenueCat, where available, and falls back to the SOSA benchmark otherwise.

The calculator takes into account everything we’ve covered – your category benchmark from SOSA 2026, your price tier, and your actual subscriber data from RevenueCat. It shows you three scenarios (conservative, realistic, optimistic) based on your specific profile, not a generic industry average.

Here’s how to fill it in:

Select your app category. This sets your SOSA 2026 reactivation benchmark.
Enter your pricing per plan type: monthly, annual, weekly, or quarterly. This adjusts the benchmark for your price tier (high-priced monthly apps reactivate at nearly double the rate of low-priced ones).
Find your active subscriber counts in RevenueCat → Charts → Active Subscriptions. Segment by Product Duration. Take the last 3 months and average them.
Find your monthly churn in RevenueCat → Charts → Active Subscriptions Movement. Segment by Product Duration. Same 3-month average.
Add your reactivation count if you have it. The same chart, but filter by Product Duration rather than segment. This makes the model significantly more accurate.

It should take you about five to ten minutes to fill in. Please don’t take the output as gospel; it still doesn’t capture everything (regional pricing differences, for instance, which I consciously decided not to include before I ended up with twenty-three spreadsheet tabs). But it should give you a defensible enough number to answer the question that actually matters: is this worth focusing on?

You’ll get a worst / mid / best case scenario, and you can even play through different scenarios. If you want to share this internally, I’ve written copy-and-paste text explaining how the calculator works.

Again, a special thanks to Ethan Garr, a fellow growth advisor, who helped me build this, taking all the lessons he learned from vibe coding a subscription app.

The churned list is getting bigger every month

The problem isn’t that reactivation doesn’t work. The data shows it does – significantly, for the right apps. The question is whether it works for yours, and whether the opportunity is big enough to act on right now.

What we know: a meaningful share of your churned subscribers will come back whether you do anything or not, but there is still a lot you can do to improve that – from winback campaigns to retargeting ads to improving your cancellation flow. The ones who return are the ones for whom your app genuinely solved something. Your job isn’t to convince people who were never going to stay; it’s to be ready for the ones who are.

The churned list you’ve been ignoring is getting bigger every month. The question isn’t whether reactivation works. The question is whether you’re there when your user is ready to come back.

In Part 2, we’ll get into what a reactivation program actually looks like: timing, segmentation, channels, Apple win-back offers, web billing discount flows, and retargeting – the how behind the why.

She turned down $500k a year in brand deals to build trust. Result? A trial CVR of 68%.

Wed, 27 May 2026 12:57:26 GMT

The experiment that came from a podcast episode

Nancy Anderson’s biggest win of the past year didn’t come from her own product team. It came from listening to a previous Sub Club episode featuring Zumba.

The tip: remove the free trial from the monthly subscription option. Anderson was skeptical. “I was shocked that it worked personally. I was like, is that going to work?” She ran the experiment anyway. Monthly subscriptions went up 2,000%. Quarterly subscriptions rose 46%. Annual subscriptions rose 21%.

The result wasn’t just a win for the revenue line. It validated the core thesis she’d been building her business on for eight years: if you build enough trust before the paywall, users don’t need a test drive. “They come in, they don’t even want or need a trial. They’re ready to buy.”

The 68% trial conversion rate (and why it has nothing to do with the paywall)

Natal’s conversion metrics are hard to explain through conventional CRO logic. When users hit the web checkout, 93% of them download the app. Their trial conversion rate is 68%, against a health and fitness industry average of around 38%. They achieve this at $25 a month — a premium price for the category.

Anderson’s explanation is simple and inconvenient for anyone who prefers a spreadsheet: it’s trust, built long before the paywall.

“It’s just a signal that trust has been built before the paywall,” she says. “So when they get to the paywall, it’s not feeling risky to them, it’s not feeling scary… They already trust us.”

That trust is operationalized in a way that most apps would find unscalable. For eight years, every DM, comment, and email across all platforms has been answered within 24 hours — not by AI, not by a customer service script, but by real coaches, physical therapists, and pelvic floor specialists. It costs more per hour than a standard support rep. Anderson considers it the most important line item in the budget.

“Our organic content outperforms our competitors by 90%,” she notes. The paywall conversion numbers are the downstream signal of that investment.

The growth lever no dashboard can measure

The central tension in Natal’s growth strategy is that its most powerful levers produce no direct data point. You can’t run an A/B test on empathy. You can’t isolate the ROI of a specific DM conversation in a Shopify report.

“Growth would be easier if I could [A/B test trust],” Anderson admits. “You go to these meetings with men and women who are just so data driven… well, why would we do that? We can’t measure it. And it’s like, you can’t measure everything in your dashboard.”

This is also how Natal’s hero program — Ab Rehab, which has driven over a million users to the app — was built. Not from a market analysis, but from noticing a recurring pattern in Facebook group comments and Instagram DMs from women asking for help with postpartum core recovery. “I never would have built it if I wasn’t close to the customer,” Anderson says. “That never would have showed up in my Shopify reports.”

The downstream signal of all this unmeasurable trust? 20% ARR growth in Q1 — while raising prices.

HSA payments: unlocking a whole new audience

Natal is also among the first fitness apps to accept Health Savings Account (HSA) and Flexible Spending Account (FSA) payments at checkout, through RevenueCat’s integration with Flex.

The motivation was straightforward: Anderson had been hearing for years from women who wanted the app but couldn’t afford it. Because Natal’s programs include corrective exercise and physical therapy protocols for postpartum recovery, they qualify as eligible HSA expenses. Accepting those pre-tax dollars effectively cuts the out-of-pocket cost by 30–40% for eligible users.

What surprised Anderson was how quickly users found it without any promotion. “People are just finding it at checkout and using it,” she says. The end-of-year HSA spending deadline — when users must spend their remaining balance or lose it — creates a natural, high-intent promotional window that most health and fitness apps aren’t yet capitalizing on. “Don’t lose your HSA. You can use it to do our programs, to use our app.” For apps in the health, fitness, or mental health space, this is one of the most concrete near-term growth opportunities available.

In the full episode, Nancy and David also discuss why she turned down $500k a year in brand deals, the mistake of building four separate apps instead of one, and why free workouts attract the wrong audience.

Guest links:

How to build a UA system when you’re a one-person team

Tue, 26 May 2026 16:28:26 GMT

I’ve said this many times, but here we go again: AI has flooded the stores with vibe-coded apps as the barrier to building an app has been drastically lowered.

There are more and more solopreneurs trying to make a living from their apps, but the more I talk to them about User Acquisition, the more I see the same pattern: they try to replicate what they see in success stories from 5 or 10-person teams. The result? Everything gets done halfway.

And the solution isn’t working more hours. It’s designing a smaller but complete system that covers all the basic aspects you need to scale UA until you get to the point where you can afford to bring someone else onto the team.

Warning before starting: AI is needed

Although this point can be unnecessary, I have to say it before I start elaborating the whole article: You will need to rely on AI for multiple parts of the system because the day only has 24 hours and you also have to get some time to eat, sleep and be a human being.

I assume that for most solopreneurs developing apps, AI is already like a third arm for them and they probably use it better than I do but if not, stop reading now and start learning how to use Claude or any other LLM and then come back here to build your UA system.

Besides that, I also want to clarify that I don’t have all the answers. I am just explaining what I have done for small projects and how you can apply what I have learned after running UA strategies for more than 125 apps in the last 7 years. This means that you may agree or disagree with some points or maybe you even do some processes faster or more efficiently already. That is completely fine. I am just elaborating on this system to help all those people who don’t know where to start.

The four pillars you can’t skip in UA even when you’re flying solo

Running UA efficiently is not that complicated when you’re trying to go 0 to 1. Things get more messy as you grow but for this system we’ll focus on having something that works well for apps going 0 to 1.

In this regard, there are four pillars that need to be addressed or controlled if you really want to achieve decent success with your paid campaigns:

Channels
Creative Production
Tracking
Schedule

If you manage these four variables more or less efficiently with the tricks and strategies that I’ll explain in the corresponding sections, you won’t need to spend money hiring someone until reaching a decent level of growth. Moreover, you will also learn how UA works along the way, so when the time to hire comes, you will at least understand the foundations and principles of UA.

With that being said, it’s time to lay out the plan.

Pillar 1: Channels – Where should you promote your app?

The biggest mistake solopreneurs make is launching on three channels (Meta, TikTok, ASA) at once. As Lucas Moscon explains in his piece on ad channel diversification, launching more channels does not necessarily mean lower risk. Quoting the article as it explains it perfectly in its first paragraph:

“Ad channel diversification can reduce performance when budgets, audiences, or team capacity are too limited to support multiple learning phases, creative pipelines, or attribution workflows.”

I know that when you’re starting you feel the FOMO for not being running campaigns in all the possible channels and figuring out which one brings the best performance for you but that feeling is actually counter-productive. Based on my experience, if your product has PMF and the main metrics are within the benchmarks of the category (discover your benchmarks with RevenueCat’s calculator), the difference that you will observe across channels is simply not determining your success or failure when running UA.

You can get 15-20% better CPAs just by changing the channel but that potential improvement comes with a high cost for a one-person team: new creative formats, new attribution logic, new account management. In the best-case scenario, you get an improvement that is not going to determine your viability to grow but in the worst-case scenario, you will burn out in less than a month for not seeing results in any of the channels after investing an unnecessary amount of time.

So the first learning is simple: Pick one channel and make it work at a decent level of spend. Once you start to struggle with scalability and your creative production system can double the production with no issues, then you can start considering other channels.

Since I’m assuming that you’re solo, I will briefly talk about the main channels as these must be the ones to consider when you want to start UA for the first time:

Meta Ads → It fits well for most app categories and gives you 5 different networks at the same time to deliver your ads (Facebook, Instagram, WhatsApp, Threads and Audience Network). This gives more than enough to find your ICP and prepare ads specifically for them. This is my pick in +90% of the subscription apps I work with.
TikTok → If your ICP is below 40 years old, TikTok is definitely a channel to consider although it demands a higher velocity with the creative production as the algorithm tends to burn creatives out much faster than any other channel. Sometimes you can get better CPAs here but you will need to rotate twice as many creatives easily compared to Meta.
Google → They launched OCM+IDM this year to offer real-time signals and more accurate reporting for app campaigns but it’s still too inconsistent. If you want to go with Google, you must go with web-to-app campaigns. DemandGen and Search campaigns are in this case the first ones to test.
Apple Ads → If your category has a clear search intent you can try this channel but right now, Apple Ads is very competitive and if you target the US, you won’t likely win many bid auctions at the price that you need to be profitable.

Except for Apple Ads, all the other channels allow you to optimize your campaigns either for installs, events or value. My recommendation is to focus directly on events if you really want to see how the algorithm looks for potential subscribers for you.

The quality that install campaigns bring is just too low to be sustainable and I only run these campaigns in very specific cases for creative testing but never as a growth pillar in my UA campaigns.

Regarding VO campaigns, these are a next step further as they rely on the value that you send to the ad network and if your subscription value happens on day 3 or day 7 because you offer a free trial, that is too late to get a proper learning so you’d need to work with proxy values and that is definitely a topic that you don’t need to know in the beginning (watch the Signal Engineering webinar with Thomas Petit if you want to learn more about this topic).

Pillar 2: Creative Production – How many creatives do you need? And how should you structure them?

It doesn’t matter how good you are with AI: You will never outproduce a 5-person team. So don’t try it.

I started with that sentence because after creating an X account this year, I see an endless amount of posts every day where solopreneurs brag about the complex systems they have for their paid campaigns. While they make less than $10k MRR.

Let me tell you something: Having successful paid campaigns is not that hard if you apply common sense. You just need to steer the algorithms to deliver your creatives towards the audiences that you consider valuable for your business.

I’ve already written about how I approach creative testing for each stage, but this time I will elaborate a bit on the logic behind the flowcharts rather than the rotation process, which the article already covers in detail.

When you’re starting from scratch, you have an idea of what audiences can work best but you don’t have the data to confirm it. Therefore you must create different creatives that attack all the pain points your potential customers may face and show how your app solves those problems.

Applying the first structure from that article ($0 to $500), your first task is to find which angles resonate best for your target event. Start your campaign with a single ad group and put different creatives that attack different angles and audiences. Check the metrics and then start to pick winners and losers every week while you keep refreshing the campaign according to performance.

This first stage won’t give you deep granularity on the performance per audience or angle of creative but it will help you to confirm the main hypotheses you can test in this first step:

What is the average CPI and CPA you can expect from a CPA campaign and whether that aligns with the LTV that you have projected
What conversion rates you get from paid campaigns vs organic at each step of the funnel and if these metrics are within benchmarks for your category
What angles get the best performance
How the algorithm distributes the spend towards the different angles
What age groups and placements absorb more spend for each angle

I have also written about creative fatigue and how to detect when it’s time to rotate creatives in your campaigns, so if you wonder what metrics you should look at, go and check that article.

Once you have found the answer to all these questions and while you have scaled to over $500/day, it is time to move to the second structure where you will have much more granularity and space to test more and also push the audiences that work better.

In that second scenario, you will likely be at a point where you need someone else helping you to produce creatives as you will have multiple ad groups that need to be fed with different creatives, every single one at least once a week (but likely twice according to my experience).

Pillar 3: Tracking – What tools do you need to track the performance and how you should track it in the beginning

Let’s be clear: You don’t need a $30k/year MMP setup to start any campaign and see if you can really scale UA. In fact, you don’t need to spend anything on tracking tools for your campaigns as all the main networks (Meta, TikTok and Google) offer free solutions to track the campaigns.

Facebook and TikTok have their own SDKs
Google has Firebase (which demands another SDK)

So the only tools that you need to measure your campaign performance are:

RevenueCat for LTV, Cohorts and subscription data (non-negotiable)
The SDK of the ad network that you start with
App Store Connect
A spreadsheet

In today’s market, you will likely get close to zero pure organic traffic from the store, but if you are running organic videos on Facebook, Instagram and TikTok, you may get some installs and in-app purchases from there. So when you start your paid campaigns, you won’t really know what can be attributed to the campaign by just looking at App Store Connect.

I think this is the most likely scenario for all solopreneurs trying to scale their apps and that is why I will show what I recommend in this stage.

Once you set up the ad network SDK and start running your first paid campaigns, you will start seeing conversions attributed to your campaigns. The first thing is to realize how many real conversions are happening, as the ad networks normally use probabilistic attribution for iOS campaigns and that can result in campaigns under- or over-reporting (in Android, you can fully rely on the number that you see in the ad network).

The simplest way to measure that is by checking the difference in the baseline before and after running the campaign across all the data points that you may have in place and attribute the uplift in the baseline to the paid campaigns.

Obviously, you need a stable period to establish your baseline across your data points (RevenueCat, ASC and your HDYHAU survey in case you have it in the onboarding). Then, you will clearly see how that baseline jumps the moment that you start the paid campaigns, so attributing that difference will tell you how much you are basically paying per trial or direct subscription.

Moreover, by creating different baselines across different data layers (RC, ASC, HDYHAU), you will start to see what the usual discrepancy is between platforms, so you will start to learn what kind of margin you have when you make decisions when looking at your campaign’s numbers.

After getting that CPA, you should go to your RC chart section and pull the LTV data for paying users so you can see if that CPA is low enough to cover:

Your LTV in the timeframe that you need (in case it’s a direct subscription)
Your trial start and trial conversion rate (in case you optimize for trials).

In parallel to this rudimentary (but reliable) attribution for your only active channel, you must create a blended report that gives you a high-level overview of your business: How much you spend and generate per day across all channels, how many installs you get, how many trials and how many subscriptions based on your average trial conversion rate. You must also create LTVs for different periods of time and then project the revenue on that period of time so you can see where things stand today (ROAS) and what the expected profitability is for the trials that you acquired today across all your channels.

I have a real example of one of these reports that I helped create last month:

As you can see, it is pretty straightforward and gives you a really clear vision of how your business is doing today and how much margin you have in the future based on your investment and conversion rates. This is also great because it quickly tells you if you are suffering any drop-off on the product side or if you are losing efficiency at any step of the funnel.

Pillar 4: Schedule – How often should you execute?

The main advice here is pretty clear: Consistency will always beat intensity, so drill this into your head: Checking campaigns 5 times a day and making reactive changes will hurt your paid performance more than help it.

If you are running a campaign with less than $500/day, you will need to execute changes twice a week at most. The reason is that your budget is simply not high enough to feed your creatives enough to make more changes, and since in the first stage you must simply have one ad group with different angles, the only iterations you must do is to pause the creatives that don’t perform and upload others to test.

In order to give you a more detailed plan rather than rough recommendations, I took the liberty of creating a plan specifically for UA so you can use the rest of the time for other tasks that are also super important for your business (product improvements, A/B testing, organic distribution, finance, etc):

Monday (1-2 hours): Refresh your campaign report and blended report and analyze how the week closed compared to the previous one (creative distribution, placements, age, engagement metrics, etc). Decide if any creative needs to be paused and analyze the distribution and metrics of the winning ones so you can think of more ideas related to that winning angle. Sketch out a potential A/B test you would like to test in the paywall and plan a 1-week test for it.
Tuesday (3-4 hours): Plan the new batch of 3-5 assets you want to produce this week after you gather all the insights from the reports that you refreshed yesterday, and try to produce them within the same day if possible.
Wednesday (1 hour): Check the campaign and see how the creatives you uploaded on Monday are performing. Pause older creatives that didn’t get spend or didn’t perform well and upload 1 or 2 from the batch that you created.
Thursday (20 minutes): Refresh the reports and make sure everything goes right. Pause bad-performing assets if and when they have enough impressions (10k+).
Friday (1 hour): Refresh the campaign again with the remaining assets that you have from the batch from Tuesday if it’s necessary. If performance is good, save them and simply decide if you want to scale or decrease the budget by looking at the performance of the week.

Besides these tasks, you must spend 15 minutes extra every day. During these 15 minutes, only look at two things:

Is the pacing correct?
Are there any major anomalies that need to be investigated right away?

You can also automate some of the decisions with automated rules as both Meta and TikTok let you set rules like “pause this ad group if CPA exceeds $X over the last 3 days.” Set them up once and let the platform handle the routine decisions. This is the one place where you let the algorithm work for you instead of against you.

When and how to hire your first external help

If you start scaling, there will be a point of course when you will be overwhelmed by any of these pillars and that is totally fine. You will simply start hitting the ceiling of what one person can manage, and that’s not because the system is broken, but because the opportunity will outgrow the system. That’s when you start thinking about your first hire or freelancer to delegate: a creative producer, a data analyst or a part-time UA manager. These are the main roles that would free up the time you’d otherwise spend on UA.

The best process to see which role suits your company the best is to analyze your own bottlenecks:

If creatives are slowing you down → freelance creative on a per-project basis
If analytics is overwhelming → data analyst by the hour
If campaigns are eating all your time → consider a part-time media buyer

The rule here is to outsource what is repetitive and executable, not what is strategic.

I hope this guide helps you to thrive in this competitive market, whether you’re starting UA from scratch or your current system isn’t working.

I will happily help anyone with further questions on my LinkedIn or X.

Meet the RevenueCat AI Toolkit

Fri, 22 May 2026 17:48:34 GMT

For a growing number of app teams, setup now starts with an agent. The agent sees the codebase, knows the platform, can edit files, can run commands, and can help connect RevenueCat with the app.

Meet the RevenueCat AI Toolkit. It brings RevenueCat into your AI coding assistant, starting with a Claude Code plugin that can help configure RevenueCat, integrate the Purchases SDK, inspect project health, pull RevenueCat Charts data, and troubleshoot in-app purchase issues from the tools where you already write code.

The AI Toolkit gives your agent access to both the RevenueCat context and the skills it needs to understand it.

Meet the RevenueCat AI Toolkit

The RevenueCat AI Toolkit is distributed as a plugin you install from your AI coding assistant’s marketplace. It is available for Claude Code, and it also works with OpenAI Codex, Gemini CLI, and Visual Studio Code. Cursor support is coming soon; for now, Cursor users can connect the RevenueCat MCP server directly.

The plugin gives your agent two things. First, it includes RevenueCat MCP server configuration, which lets your agent access RevenueCat after you authenticate with OAuth. Second, it includes RevenueCat-specific skills, which guide the agent through setup, SDK integration, paywalls, purchases, testing, analytics, and troubleshooting.

Think of it as access plus knowledge. MCP gives your agent a way into RevenueCat. Skills tell it which steps to take next.

Feature	What it gives your agent	Why it matters
Plugin	RevenueCat inside Claude Code, OpenAI Codex, Gemini CLI, and Visual Studio Code agent plugins beta.	You can work on monetization where your app code already lives.
MCP server configuration	A connection to RevenueCat through OAuth.	Your agent can read and update RevenueCat configuration with your account permissions.
Skills	RevenueCat-aware playbooks for common workflows.	Your agent follows the right order of operations instead of guessing from generic docs.

What you and your agent can do

Subscription infrastructure from the editor. Instead of coordinating every setup step by hand, you can ask your agent to create or select a project, add apps, create products, define entitlements, build offerings, attach packages, and return the public SDK keys your app needs.

This matters because order matters in RevenueCat. Products need to map to entitlements. Offerings need packages. Packages need products. Apps need the right public SDK keys. The AI Toolkit helps your agent follow that order.

SDK setup with RevenueCat context. Your agent can detect whether your app is native iOS, native Android, React Native, Flutter, or Kotlin Multiplatform. Then it can install the right Purchases SDK, configure Purchases once at app launch, enable debug logs during setup, and verify the expected SDK output.

That saves more than tab switching. It reduces the classic mismatch between product configuration and app code: the wrong key, the wrong app identifier, or a configure call in the wrong place.

Paywalls and purchases where the code lives. If you use RevenueCat Paywalls, your agent can add the right RevenueCatUI package and present the dashboard-configured paywall from your app. If you need custom UI, it can guide the purchase flow around getOfferings(), purchase(package), restore purchases, and entitlement checks.

Analytics and troubleshooting inline. Your agent can inspect project status, query RevenueCat Charts, and help diagnose common setup issues like empty offerings, missing products, inactive entitlements, or sandbox purchase failures.

How to install it

Start with Claude Code. From inside Claude Code, run:

/plugin

Choose Marketplace, select + Add Marketplace, enter:

RevenueCat/ai-toolkit

Then install the RevenueCat plugin.

You can also install it from the command line:

claude plugins marketplace add RevenueCat/ai-toolkit
claude plugins install RevenueCat

For OpenAI Codex CLI, add the marketplace first:

codex plugin marketplace add RevenueCat/ai-toolkit

Start Codex, run /plugins, search for RevenueCat, and install the plugin.

For the OpenAI Codex desktop app, run the same marketplace command in your terminal:

codex plugin marketplace add RevenueCat/ai-toolkit

Then open Plugins in the Codex app, select RevenueCat from the plugin source dropdown, and click the plus button next to the plugin.

For Gemini CLI, install the extension directly from GitHub:

gemini extensions install <https://github.com/RevenueCat/ai-toolkit>

For Visual Studio Code, use the agent plugins marketplace beta. Add this repository as a plugin marketplace, then install the RevenueCat plugin.

Cursor support is coming soon. Until then, configure the RevenueCat MCP server directly in Cursor using the setup instructions in the RevenueCat docs.

For other AI coding environments, you can install the skills with:

npx skills add RevenueCat/ai-toolkit

That fallback installs the skills, not the MCP server. If you want live RevenueCat project access in an unsupported environment, configure the MCP server manually.

What you can ask it

Start with the job you would otherwise split across your editor, RevenueCat setup, store consoles, SDK docs, and logs.

Set up RevenueCat for my fitness app. I’m building for iOS and Android. I want monthly and annual subscriptions.

Integrate RevenueCat in this React Native app and configure the SDK with the correct public API key.

What’s the status of my RevenueCat project?

What was my revenue last month, and how does churn look over the last 90 days?

My offerings are empty on iOS sandbox. Diagnose the RevenueCat setup and tell me what to fix.

Frequently Asked Questions

What can an agent do through the AI Toolkit?

Your agent can use RevenueCat MCP access and RevenueCat skills to help configure projects, apps, products, entitlements, offerings, packages, and public SDK keys. It can also inspect project health, query chart data, and diagnose common purchase setup problems.

Can an agent change live RevenueCat configuration?

Yes, if your authenticated RevenueCat account has permission to make that change. Treat agent access like any other privileged product access. Review changes to projects, products, entitlements, offerings, packages, and webhooks before accepting them.

How does authentication work?

The plugin uses OAuth. Your agent gets access based on your RevenueCat account permissions and can work with the projects your account can access.

Should you use this directly in production?

Use the same judgment you would use with dashboard or API changes. For setup, testing, and debugging, start with sandbox data, test stores, or non-production projects when the change could affect live users. Confirm purchases in RevenueCat, not only on the device.

Does this replace the RevenueCat dashboard?

No. The dashboard remains the place to see, review, and manage RevenueCat visually. The AI Toolkit gives teams another way to work with RevenueCat: the coding agent where more app work now starts.

Skills included in the AI Toolkit

The AI Toolkit includes thirteen RevenueCat skills. Each one gives your agent a focused playbook for a common developer workflow.

Skill	Use it when you want to…	What your agent does
integrate-revenuecat	Add RevenueCat to an app for the first time.	Sets up the RevenueCat side through MCP, retrieves the public SDK key, detects your app platform, installs the Purchases SDK, configures it once at launch, and verifies the SDK logs.
create-revenuecat-project	Bootstrap a RevenueCat project from scratch.	Creates or selects the project, creates platform apps, adds products, entitlements, offerings, and packages, attaches everything in the right order, and returns public API keys.
revenuecat-paywall	Show RevenueCat Paywalls in your app.	Installs the right RevenueCatUI package, presents the dashboard-configured paywall, handles callbacks, and verifies that your configured template renders instead of a fallback layout.
revenuecat-purchase-flow	Build a custom purchase and restore flow.	Fetches offerings, selects a package, calls purchase, handles cancellations and errors, exposes restore purchases, and treats entitlements as the source of truth.
revenuecat-entitlements-gate	Gate paid features behind subscription access.	Checks customerInfo.entitlements.active, listens for entitlement changes, avoids product-ID-based gating, and verifies that access updates without restarting the app.
revenuecat-identify-user	Connect RevenueCat identity to your auth system.	Wires logIn and logOut, uses stable opaque app user IDs, avoids PII, handles anonymous users, and preserves purchases when users identify later.
revenuecat-testing-setup	Test purchases without charging real money.	Picks the right testing channel, configures RevenueCat Test Store or store sandboxes, separates sandbox and production views, and verifies purchases in RevenueCat.
revenuecat-troubleshoot	Diagnose empty offerings, missing products, inactive entitlements, or failed sandbox purchases.	Reads SDK debug logs, inspects RevenueCat configuration through MCP, checks products, entitlements, offerings, packages, app IDs, and webhooks, then proposes concrete fixes.
revenuecat-status	Get a quick project health check.	Summarizes apps, products, entitlements, offerings, packages, and webhooks, then flags orphaned products, empty offerings, or apps without products.
revenuecat-charts	Ask questions about RevenueCat Charts and analytics.	Queries chart schemas and chart data, reasons about acquisition, conversion, retention, and reactivation, and builds dashboard links for the charts it references.
revenuecat-customer-center	Add self-service subscription management.	Installs and presents RevenueCat Customer Center, connects it to identified users with purchases, and verifies restore, cancel, refund, support, and dismiss callbacks.
revenuecat-migrate	Move from raw StoreKit or Google Play Billing to RevenueCat, or upgrade SDK major versions.	Chooses the migration path, uses observer mode when adopting RevenueCat alongside existing purchase code, preserves user continuity, and verifies sandbox and existing-subscriber behavior.
revenuecat	Handle a RevenueCat task without a more specific skill.	Uses the MCP server and RevenueCat docs as the fallback path.

The skills stay narrow on purpose. Paywall work differs from entitlement gating. Testing differs from migration. Project creation differs from SDK configuration. Smaller playbooks make your agent easier to steer and easier to review.

Get started

Install the RevenueCat AI Toolkit in Claude Code:

claude plugins marketplace add RevenueCat/ai-toolkit
claude plugins install RevenueCat

Then ask your agent to set up RevenueCat, integrate the SDK, inspect your project, or debug the purchase flow that’s blocking your launch.

The RevenueCat AI Toolkit is available on GitHub at RevenueCat/ai-toolkit.

You shipped a subscription app with AI — so why does it feel like you’re losing?

Thu, 21 May 2026 12:46:34 GMT

I’m staring at a MacBook I bought on eBay a few months ago so I could run OpenClaw, and at times it’s made me feel terrible.

By most measures, I am in a very small group. I shipped a vibe-coded subscription app, which probably puts me in the top 1% of builders globally. And yet I feel like I’m constantly falling behind. That OpenClaw machine isn’t even powered up.

A few months ago, it felt like the big unlock was having a good claude.md file. Then a few weeks later it was agents. Then everyone was talking about OpenClaw. Then skills. Every couple of weeks there is a new AI thing I’m supposed to be doing.

I can’t keep up, and you probably can’t either. But that’s okay.

The reality gap

There’s a big gap between reality and what we’re reading on LinkedIn and X every day. Someone right now is telling you they built an app in a weekend and it made $8,000 in its first week.

On the other hand, I vibe-coded a mobile app and it took me about four months. Then the App Store rejected it four times. It wasn’t a caffeine-fueled overnight success, but it taught me a lot and I’m still genuinely excited each time I see a new subscription trickle in.

To be honest, I’m a little scared to publish this. You’re going to know the truth — that I’m not keeping up. That agents aren’t doing my laundry. That my app isn’t making me rich yet.

Well, f*ck it.

Don’t misunderstand, I’m really excited about what AI is unlocking for me and for you. Whether you’re thinking about building your first app, already launched, or starting to think about growth, you should feel excited about all of it.

We are living in an amazing moment, and you can build awesome things. However, behind the scenes I think there’s an unspoken feeling of playing catch-up. A fear of being out-of-the-loop, or anxiety to say anything not-entirely-positive about AI. These feelings, and the opportunities AI brings, aren’t mutually exclusive. So here’s how you can do that without losing your mind as AI-pace anxiety accelerates and makes us all a bit crazy.

Asking AI to think for me was a bad idea

When I uploaded RevenueCat’s State of Subscription Apps report 2026 into ChatGPT with a prompt that said, “review this in detail and tell me what we should apply to OnTimer”, I knew it was bad.

That report is probably the most valuable thing I read each year as I help developers grow their mobile apps. And here I was phoning it in for my own app. I did read the report a few days later, but this delegation motion was becoming a bad habit.

I’d see a LinkedIn post about best practices for AEO and I’d delegate it to Claude Code. Someone would share a skill from their Github repo and I’d thoughtlessly dump it into Claude. And so on. No learning, just action.

Was the output better than nothing? Yep! In fact, often it was pretty good (LLMs are incredible). But did I learn anything? Nope!

I can justify it in my head: building OnTimer is my side project. I’m a professional growth advisor and I have work to do; I have a daughter who I want to spend time with before she goes off to college; I am busy, and it feels like I’m constantly trying to jump on a moving train.

Regardless of how busy I was, I came to realise that outsourcing learning wasn’t making me feel good about what I was building. And delegating my thinking wasn’t making me better at growth.

AI is amazing at helping us speed up processes, and that’s awesome. We should embrace that. But if it is replacing learning, creativity, and curiosity what’s the point?

There’s pressure to keep up (even when no one says it out loud)

The tech world has always been fast-paced. If you weren’t working long hours and sleeping on conference tables you were doing it wrong, but AI has taken that to another level.

There’s a new kind of pressure where it feels like if you say something negative about AI, or even just admit that you’re not using the latest tools, then you’re signaling that you’re behind. That you’re not technical enough — or worse, that you’re resisting progress.

So instead we leave it unsaid, and we just try to keep moving faster.

As I write this, Coinbase is laying off 14% of their workforce and their CEO’s letter all but says, ‘if you are not AI-first, you are last’. So I get the angst.

At the same time, every day I see posts that say you can’t build anything real with vibe-coding, that nobody is excited about the apps they vibe-code, and so on. Meanwhile, my vibe-coded app is available in the App Store.

So which is it? If no matter how fast you move and no matter how much tech you embrace, it will never be enough, how can you ever win? For a while I just tried to blindly accelerate. I bought the OpenClaw machine that still isn’t turned on. I outsourced my thinking to ChatGPT, and I tried to keep up with everything.

It didn’t work, and it certainly wasn’t making me smarter or happier.

Exit the echo chamber and find your footing

The loop that makes your head explode looks like this:

New shiny AI thing → X post says “winners are already doing this” → try to catch up → feel behind → next new shiny AI thing

When you’re in a loop like this, you don’t always realize it. For a while, the speed itself starts to feel like progress. You’re trying things, generating outputs, checking boxes, but your focus is all over the place.

That’s what happened to me. When I started outsourcing everything to AI, it felt like action. Things were getting done, and some of it was okay, but a lot of it wasn’t.

As an example, agents are awesome, and you can do some really cool things with them. But for the development phase of OnTimer, they were more of a distraction than a value-add. I had a simple goal to build and ship a subscription app, but I felt this heavy pressure to keep up with everything. So instead of thinking through how and why I needed agents to achieve my goal, I just started building them.

I was breaking my own rules:

I wasn’t thinking things through
I wasn’t building intuition
I was just reacting

At some point, you have to stop and ask yourself a different question. Instead of asking “what am I missing?” ask “what actually matters for what I’m trying to accomplish?”

When I focused on that, everything changed. Moving forward became more important than moving faster, and for the first time in a while, I felt like I was getting ahead.

Focus on meaningful things, instead of everything

So what do we do? We have this amazing toolset. It’s getting more amazing every day, and we have no possible way to stay on its leading edge. We need a simple playbook to help us focus, learn, and keep building.

For me, the same rules that apply to growing a product apply here. Focus on value, understand your North Star, relentlessly prioritize.

The framework that worked for me was:

Create an evaluation layer
Build a backlog
Operationalize

1. Create an evaluation layer

This is easy. Right now my LinkedIn has two headlines that are piquing my interest: “Build and Run Your First MCP Server” and “1,000 AI Marketing Prompts”.

My North Star today for OnTimer is to validate product-market fit. I just simply look at everything I see through the lens of “Does this help me achieve the goal or is it a distraction from the goal?

2. Build a backlog

Eventually emailing yourself articles and sticking post-it notes all over your desk gets overwhelming.

Do yourself a favor and create a repository. I just use a Google Sheet with a one sentence description of the new tool or approach, copy in links to where I can learn more, and add a score based on importance and urgency (as it relates to my North Star).

3. Operationalize

I schedule time on my calendar to dig into AI learnings each week. I even have an app that makes sure I don’t forget to do it (guess what the app is). The evaluation layer helps me focus on what I want to learn, and what the most meaningful learnings are for me right now.

Then my backlog helps me feel less anxious that I will miss out on things that might be important but just not super-urgent today.

I still offload and delegate a lot of actions to ChatGPT and Claude, but I force myself to never do that without first spending some time building a basic understanding of what the tool or system is, what it does, and why it is important.

The system that works for you might be different, but some version of an evaluate, backlog, operationalize approach can help you.

It’s not about keeping up with everything, it’s about keeping up with the right things to help you keep building what matters (including your own knowledge).

Take the wins, you’re further ahead than you think

AI should make you faster. But if it replaces the part where you actually think things through or develop your understanding, it doesn’t move you forward. It just makes you quicker at doing things that don’t move the needle.

Last week I was showing a friend OnTimer over Zoom. After he onboarded I watched him try to tap on a calendar event on his homescreen. When nothing happened, I realized there was a mismatch between user expectation and functionality.

Five minutes after the call I was in Claude Code building ‘event cards’ to fix this. I hadn’t thought through how these would actually be valuable for users, I just started building. Eventually I caught myself. I thought about my North Star and what I’m trying to achieve, and quickly realized this wasn’t the thing I should be focused on right now.

With AI it’s super-easy to get ‘ahead of your skis’. You can do anything, so you try to do everything. But there’s too much to consume: there are new tools, new playbooks, and new opportunities emerging faster than you can digest them. This isn’t going to slow down anytime soon, so we need to adjust our expectations of what ‘keeping up’ means in an AI-driven world.

The anxiety is compounded by social media which often overstates impact, over-hypes new and shiny things, and over-indexes on huge wins instead of the normal grind. There’s a lot of noise, and as a builder if you can’t cut through it, you’ll probably lose your mind.

AI is giving us incredible access to unlock ingenuity and innovation. If you’re building a mobile app or have already launched one, you are already in an elite group, and you should feel awesome about it. You’re further ahead than you think. Don’t let the feeling of being behind convince you that you actually are.

The three-week COVID pivot that saved an 11-year indie business

Wed, 20 May 2026 17:36:22 GMT

Buying a house with RealBasic

Developers love to argue about which framework is best. Daniel Kennett’s career is a reminder that users rarely care.

As a teenager in the UK, Daniel wanted to learn how to program a hand-me-down Mac LC2. After failing to grasp Java and C++, he found RealBasic — a cross-platform visual language. He used it to build Music Rescue, an app that let users copy music off their iPods back onto their Macs.

The app was born in the back of a physics class, but it hit the market at exactly the right time. When the popular website iPod Lounge used Music Rescue in a tutorial on how to back up an iPod, sales took off. “I always find it funny when people these days are like, ‘Well, you have to use X programming language or X framework to build an app,'” Daniel says. “It’s like, come on, I bought a house with RealBasic.”

The lesson was clear early on: if an app is polished, solves a real problem, and fits well on the platform, the underlying technology is just a detail.

The human cost of going broke

The success of Music Rescue meant Daniel went from working part-time in a hardware store to earning a senior developer salary while still at university. But the financial education didn’t match the income.

“I just buy stuff, credit card, credit card. Oh, credit card’s maxed out, pay it all off, whole thing and do that,” he recalls. When the iPhone arrived and Spotify launched, the iPod market began to shrink. Music Rescue’s revenue dipped. At the same time, Daniel and a friend started building a new app, spreading their focus too thin. Because of his spending habits and the delayed reality of credit card debt, by the time he realized the business was in trouble, it was too late.

“We lost a car, just suddenly came and took the car one day, fighting to keep the house and eventually sold it to avoid it being taken basically. Lost friends, everything my entire life was kind of destroyed,” he says.

He avoided bankruptcy “by the skin of my teeth” and took a job at a then-small Swedish startup called Spotify to rebuild his finances. The experience didn’t shake his confidence as a developer, but it fundamentally changed how he approached business risk. Years later, when he decided to go indie again with Cascable, he did it with strict financial guardrails, rolling goals, and the support of his wife, who had lived through the crash with him.

Pricing for a $4,000 camera

When Daniel launched Cascable Studio — an app that lets photographers remote-control non-iPhone cameras via WiFi — he faced a market that expected mobile apps to be cheap. He rejected that expectation immediately.

“If you can afford $4,000 for a camera, you can pay more than $2 for my app,” he says.

Cascable targets advanced amateurs and professional photographers who use expensive gear from Canon, Nikon, Sony, and Fujifilm. Because the app genuinely unlocks new capabilities for that hardware — like complex automation for astrophotography — the audience understands its value. The app’s non-subscription purchase option is currently $99, and Daniel notes that they rarely get complaints about the price.

This pricing confidence extended to how they handled the industry’s shift toward subscriptions. When Adobe moved its photography tools to a subscription-only model, it angered the entire photography community. Watching that backlash, Daniel chose to offer both a subscription and a one-time purchase option. He avoids the word “lifetime” — which creates unrealistic expectations — and instead promises that buying the non-subscription version and paying for occasional major upgrades will always be cheaper over the long run than subscribing.

The result? A healthy business with a paid-to-free ratio of about 25%, which is exceptionally high for a freemium app.

The three-week COVID pivot

Cascable Studio grew slowly and steadily for years. But in early 2020, the pandemic hit. Events were cancelled, event photographers lost their jobs, and they stopped buying photography apps. Cascable’s revenue dropped.

At the same time, remote work exploded, creating a massive shortage of webcams. People wanted to use their expensive DSLR and mirrorless cameras as high-quality webcams for Zoom calls.

Years earlier, Daniel had made an architectural decision to pull Cascable’s camera connection logic into a standalone SDK. It was originally done to license the technology to other developers, but in March 2020, it became a lifeline. Because the SDK already knew how to talk to 250 different cameras, Daniel was able to build a Mac virtual webcam app in just three weeks.

“From idea to money was three weeks and I’m very proud of that,” he says. The new app, Cascable Pro Webcam, filled the revenue gap left by the core app and effectively saved the company during the worst of the pandemic. It was a stark reminder that clean architecture isn’t just about code quality — it’s about business optionality.

In the full episode, Daniel also talks about his time at early Spotify, reverse-engineering the iPod using SCSI commands, why he still buys expensive cameras just to test them, and his new app PhotoScout.

Guest links:

Google I/O 2026: What’s New in Google Play and Play Billing Library 9.0

Wed, 20 May 2026 01:39:35 GMT

If you spent keynote day refreshing the Play Billing release notes wondering when v9 would land, same. It dropped on May 19, 2026, the same day as the I/O announcements, and the rest of the Play story landed in the same window. v9 itself is a smaller surface than v8 was last year (breathe out), but it stacks on top of a bigger Play story this year: AI infused discovery, churn cutting billing changes, and a Play Console that drafts your store listings for you.

TLDR

Play Billing Library 9.0.0 (May 19, 2026): in app messaging for opt in price increases, blocked Play Store now returns BILLING_UNAVAILABLE, getLinkUri is @Nullable, target SDK 35.
Discovery moves into Gemini: 450,000 plus movies and shows surface in the Gemini app. Engage SDK Collections hits 30M MAU and 45% YoY lift in app opens.
Play Shorts and Ask Play: short form video on store, plus a Gemini backed search overlay answering 95% of queries.
Sidekick: AI overlay for games. No SDK work. Global rollout in summer 2026.
AI in Play Console: CSV or Sheets driven listing pre population, agentic catalog management, AI Q and A on metrics.
Billing aimed at involuntary churn: delayed charging for low risk users, account recovery extended 30 to 60 days, new in app subscription management API.
Protected with Play: one dashboard for integrity, distribution, and fraud. 160M spam reviews and $3.2B in fraud blocked last year.

In this article, you’ll explore each of these in turn: Gemini and Ask Play, Play Shorts and Sidekick, the AI assisted Play Console, the three billing changes that target involuntary churn, the four code level changes in Play Billing Library 9.0.0, the analytics, and Protected with Play surfaces.

Discovery moves into Gemini and conversational surfaces

The single biggest shift announced at I/O 2026 is that Play discovery no longer ends at the Play Store. Google is pushing app and content recommendations into the Gemini app on Android and on the web, so a query that used to land a user on a generic answer page can now deep link them into your app’s relevant screen. The first wave covers entertainment, with over 450,000 movies and TV shows surfaced through Gemini, including live sports streaming links that route directly into the partner app.

For developers, this means your store listing is no longer the only place Google’s recommendation engine reads. The Engage SDK, which already exposed in app content to Play surfaces like Collections (the widget on the Android home screen that resurfaces your in app content), has grown to over 30 million monthly active users and is driving a 45% year over year lift in the number of app opens for participating titles.

Store listing integration ships next month, with new tablet surfaces including home screen Collections, and every Engage SDK surface now scales across 80 plus Play markets. If you publish content with structure beyond the package name (articles, episodes, products, levels), the cost of adopting Engage SDK is the same as last year and the surface you reach is now substantially larger.

The pattern to internalize is that any single piece of content inside your app has a real chance of being its own discovery entry point. Build deep links for everything that has a stable identifier, keep them indexed through Engage SDK, and assume the user lands on a screen mid app rather than at your home tab.

Play Shorts and Ask Play change the on store experience

Inside the Play Store itself, two surfaces are new. Play Shorts is a full screen, portrait, short form video feed rolling out to US users and select developers, with broader market expansion in the coming months. The feed sits next to traditional app browsing and lets you place short form promotional video against an audience that is already in store and primed to install.

The second surface is Ask Play, a conversational search overlay backed by Gemini. The on store Q and A feature that has been quietly running for a year already answers 95% of user queries, and Ask Play extends that with summary recommendations rendered as natural language responses to questions like “what app should I use to learn guitar.” For developers, the implication is that the keywords in your store listing are no longer the only thing that determines whether your app shows up. The descriptions, screenshots, and review text all feed Gemini’s answer construction, so listing copy now has to read well for both a human user and an LLM.

Sidekick: an AI overlay for games

For games specifically, Play Games Sidekick is the biggest games announcement at I/O 2026. Sidekick is an in game overlay that surfaces AI generated tips, rewards, and achievements without requiring any new SDK work from participating titles. Over 100 games have launched with Sidekick already, and Google is opening eligibility to all participating titles globally in summer 2026, along with new social features that let players track friends, share achievements, and discover what friends are playing.

Sidekick lives at the platform layer rather than inside each game. You opt in through Play Console rather than wiring up an SDK, and the AI tips draw on Google’s own model of the game rather than on data you ship. This keeps the integration cost low and explains how Google can promise the feature works for any participating title rather than only those who invest in custom integrations.

AI in the Play Console: localization and catalog

The Play Console itself got a substantial AI pass focused on two operations that consume disproportionate time for monetization teams: localizing store content and managing SKU catalogs.

For localization, you can now upload a CSV or Google Sheet and have the Play Console pre populate the multi language fields, with Gemini handling the translations. A separate capability turns your keyword set into listing copy automatically. Subscription benefits, which are notoriously easy to mistranslate when handed to a generic translation service because the source phrasing is short and context light, are now translated by a model that has been tuned on Play’s own corpus of subscription copy. The practical effect is that adding a new market goes from a week of agency turnaround to an afternoon of review.

For catalog management, the Play Console adds agentic bulk price changes, SKU import, and metadata configuration automation. The word “agentic” is literal here: the system chains operations on your behalf, ingesting a SKU list, generating regional pricing recommendations, applying them across markets, and surfacing the result for approval. Teams that maintain hundreds of SKUs across dozens of regions can move from manual entry to a review and approve workflow.

Billing changes that reduce involuntary churn

The billing announcements at I/O 2026 are the parts of the keynote that translate most directly into recovered revenue. Three changes work together to reduce involuntary churn, the kind that happens when a renewal payment fails and the subscription expires before the user has a chance to fix it.

The first is delayed charging. When a renewal payment fails and Google’s risk model classifies the user as low risk, Google Play continues to retry the charge in the background while granting the user continued access. The user does not see a payment failure dialog, the app does not lose the entitlement, and a successful retry resolves the situation transparently. From the app’s perspective the purchase stays in the PURCHASED state during the retry window. If a final retry fails, the standard grace period and account hold flow takes over. The risk model gates this behavior because granting access on a failed payment carries fraud risk, so the feature applies only when the model is confident the user is genuinely going to pay.

The second is the extended account recovery window. Account hold, the state a subscription enters when grace period runs out without a successful payment, used to last 30 days. I/O 2026 extends that window to 60 days. Google’s published figures from the extension test are an 18% reduction in involuntary churn and a 9% reduction in total churn for top developers, so smaller apps should expect more modest effects. The longer recovery window costs nothing on the developer side: the subscription state is identical, the same RTDN notifications fire, and recovery surfaces through the existing SUBSCRIPTION_RESTARTED event the same way it did at 30 days. Your app keeps the user’s data available longer, and your backend gets more time to surface payment fix prompts before the subscription expires.

The third is flexible subscription management. A new in app subscription management API lets you offer plan changes and downgrade offers at the moment of cancellation without bouncing the user out to the Play Store subscription settings screen. Prorated refunds for downgrades are handled through replacement modes on the existing subscription update flow, so a user who downgrades from annual to monthly receives the correct credit automatically.

The three changes compound. If your subscription business sees 5% involuntary churn per month and you adopt the extended recovery window, even a fraction of the published 18% reduction takes that to roughly 4.1%. Over a year, that translates into a larger active subscriber base for the same gross adds.

Play Billing Library 9.0.0: what actually changed in code

Play Billing Library 9.0.0 shipped on May 19, 2026, and if you already migrated to v8 last year, you can relax: the API surface this time is intentionally small. v8 was the breaking release. It retired the SkuDetails era methods (querySkuDetailsAsync, the no argument enablePendingPurchases, the legacy queryPurchasesAsync overload), introduced sub response codes on BillingResult, and renamed alternative billing to user choice billing. v9 builds on that foundation and adds a single new in app messaging capability, two compatibility adjustments, and a target SDK bump. Sub response codes like PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS and USER_INELIGIBLE carry forward from v8 unchanged.

The dependency update is straightforward:

The v9 changes that actually require code attention are in three areas.

In app messaging for opt in price increases

The main addition in v9 is a new category on the in app messaging API. Pre v9, showInAppMessages with InAppMessageCategoryId.TRANSACTIONAL displayed Google’s recovery prompts for users in grace period or account hold. v9 extends the same surface to display an outstanding opt in price increase, letting the user confirm the new price without ever leaving your app.

You call the same method you would for payment recovery:

The SUBSCRIPTION_STATUS_UPDATED response code covers both outcomes: payment recovery and price increase acceptance. The purchase token in the result tells you which subscription changed, and a refresh from your backend (or RevenueCat) tells you what the new state is. The two messages have different frequency caps. The price increase message shows at most once every 7 days, starting the first day the user can accept the new price. The payment issue message during grace period and account hold shows at most once per day. Either way, calling showInAppMessages on every app launch is safe, and the library returns NO_ACTION_NEEDED when there is nothing to show.

The practical impact is on the opt in price increase flow that previously required users to navigate to the Play Store subscription settings screen to accept a new price. Spoiler: most of them never made that trip, and their subscriptions auto canceled at the first renewal at the new price. The in app surface keeps the user inside your app and gives you a higher acceptance rate. If you have a planned price increase, adopt this first.

Updated error code for a blocked Play Store

The second v9 change is a reclassification of one error code. The Play Store app can be blocked by the system. This happens in OEM customized kids modes, on managed devices with parental controls, and on enterprise devices with policies that disable the store. In v8 and earlier, billing calls in this state returned a BillingResult with response code ERROR and no specific debug message. v9 reclassifies these cases as BILLING_UNAVAILABLE and attaches a “Play Store is blocked” debug message.

The migration step is a one liner in your error handling code:

Detecting this case requires androidx.core 1.9 or later, which most modern apps already pull transitively. If your app supports kids tablets or enterprise distribution, this reclassification lets you show a more specific message than a generic billing error and avoids a confusing dead end at the paywall.

DeveloperProvidedBillingDetails.getLinkUri is now nullable

The third v9 change is a nullability adjustment on developer provided billing. DeveloperProvidedBillingDetails.getLinkUri() now returns @Nullable rather than non null. The direct link URI for external payments is not always available at the payment selection stage. It sometimes resolves later in the flow. The old non null guarantee forced the library to return an empty string in those cases, and apps that tried to parse the empty string as a URI crashed at the call to Uri.parse.

The migration step is to handle both null and empty string before launching a browser intent:

If you do not use developer provided billing, this change has no effect on your code. If you do, the migration takes a single nullness check and a fallback branch.

targetSdkVersion bumped to 35

v9 targets API 35 (Android 15). If your app builds against an older compile or target SDK and consumes the billing library directly, you may see manifest merger warnings until you bump your own targetSdkVersion to match. The library itself runs on the same minSdk 23 floor that v8.1 established, so this is purely a target side bump.

Analytics and AI powered insights

The analytics surface inside Play Console got the matching upgrade. The new metrics fall into three buckets. The first is reach measurement: total visibility, store listing indirect value, and traffic source breakdowns split across engagement, retention, and monetization. The second is conversion granularity: cart conversion rates, subscriber tenure distributions, and churn reason data. The third is AI assisted interpretation: chart descriptions on the Reach and Devices and Store Performance pages, interactive Q and A on metrics you select, and proactive monetization recommendations surfaced inline.

The interactive Q and A is the surface most likely to change how teams use Play Console day to day. Instead of clicking through to a docs page to understand why a metric moved, you can ask the question directly in the console and Gemini answers with the chart context already loaded. This collapses the loop from observation to hypothesis to corrective action.

The new churn reason data deserves separate attention. Cancellation surveys have always returned reason codes, but Play Console previously surfaced them only as a flat list. The v9 console adds tenure aware breakdowns, so you can see which reasons dominate at month one versus month twelve. If your top cancellation reason at month one is “too expensive” and your top reason at month twelve is “not using it anymore,” those map to two entirely different retention interventions.

Protected with Play

The security side of I/O 2026 introduces Protected with Play, a centralized dashboard that consolidates integrity configuration, distribution defense, and monetization fraud controls into a single Play Console surface. The numbers Google published for the year are large: 160 million spam ratings and reviews blocked, and $3.2 billion in fraudulent and abusive transactions blocked automatically. The dashboard does not change those automated protections. What it changes is your ability to see them and configure where the thresholds sit for your app.

One performance related change is worth flagging. The Play Integrity API warm up latency has been reduced for latency sensitive user journeys. If you call Play Integrity at the start of a purchase flow, a sign in, or a checkout, the latency you pay for the integrity verdict is now lower. The reduction matters most for short sessions where every hundred milliseconds at the start of the flow risks losing the user.

What v9 means for the v7 sunset

Google’s Play Billing Library deprecation page shows the August 31, 2026 deadline for new apps and updates built against v7. v7 binaries already published continue to function, but no new release built against v7 can be uploaded after that date. v9 does not change this calculation. If you are still on v7, the v9 migration guide is a single page that walks through every cumulative removal: querySkuDetailsAsync, the no argument enablePendingPurchases, the legacy queryPurchasesAsync overload, the user choice billing rename, and the v9 polish on top. The v7 to v8 work is the bulk of the effort. The additional v9 step is the four changes covered above and adopting the in app messaging extension for price increases.

Still on v7? August 31, 2026 is your hard deadline. There is no shortcut from v7 straight to v9: you do the v8 work first. Pair this article with the complete v7 to v8 migration guide, which walks through the six migration steps, every removed API and its replacement, and the v8.1 to v8.3 additions you also pick up along the way. The four v9 changes covered above are what you tack on at the end.

For teams already on v8, the v9 jump is small enough to fit into a single sprint. The new in app messaging category is opt in, the error code reclassification only requires touching code that already handles BILLING_UNAVAILABLE, and the nullability change only affects developer provided billing integrations. The targetSdkVersion bump is the only forced change, and it is one line.

Conclusion

In this article, you’ve explored the I/O 2026 wave of Play updates: Gemini powered discovery and Ask Play moving recommendations beyond the Play Store grid, Play Shorts and Sidekick reshaping on store and in game engagement, AI assisted localization and catalog management in the Play Console, three billing additions that target involuntary churn directly, the four code level changes that make up Play Billing Library 9.0.0, and the new analytics and security surfaces.

The release sits in clear contrast with v8: where v8 reshaped the API surface, v9 picks up a single new capability worth adopting and consolidates the v8 foundation. For the official source material, refer to Google’s I/O 2026 Play announcement, the Play Billing Library release notes, and the Play Billing Library 9 migration guide.

This is not a playbook: how Mimo grew customer LTV by 65%

Tue, 19 May 2026 15:07:31 GMT

Many in the app business are looking for the playbook. You know the one — a canonical set of moves that will grow LTV, lower CAC, and compound into a healthy, scaling business.

After a decade of growing mobile apps and working at every step of the funnel as an IC, I still don’t have a playbook. What I do have by now is a good picture and a wealth of lessons on how businesses can turn around within 6–12 months, once the funnel is understood and the right problems are tackled.

This article isn’t a magic playbook, but I will share examples of what to watch out for when it comes to a fully-functioning funnel vs. a set of hectic moves that barely move the needle, and how to engineer growth in your favor.

Viewing the funnel as more than the sum of its parts

I’ve been lucky to have worked with a few apps at their inflection point, when the LTV/CAC math stops working, and the path forward isn’t obvious. Some we turned around in six months. Others grew MRR 10 to 25x in a year.

Regardless of where I’ve worked, I’ve seen a throughline: there is a dense web of interdependencies between every part of your funnel. It may sound obvious, but, in practice, it’s so easy to end up looking at the KPIs in silos instead of seeing the funnel as a whole.

A change to your paywall affects your plan distribution, which in turn affects lifetime value (LTV) and ultimately determines how much you can spend on acquisition. A change to your acquisition strategy affects who enters your funnel, which in turn affects activation rates, retention, word of mouth, and the revenue that cohort generates.

Pull one thread, and the whole fabric moves — sometimes in the direction you wanted. So, the most valuable thing one can do is learn to manipulate how the fabric moves.

When I took on the growth challenge at Mimo (back then, it was an app that taught you how to code, but it has since evolved significantly), we were facing a situation that every growth-stage app eventually hits: LTV had plateaued while customer acquisition costs kept climbing.

Standing still wasn’t an option for a bootstrapped company. Scaling down (in the worst-case scenario) meant giving market share to competitors, losing the event volume needed to optimize campaigns, and losing data, organic downloads, and momentum. Paid acquisition was one of our core growth loops alongside organic traffic, and we had to fix the unit economics or stop spending.

I was fortunate to lead both product growth and marketing simultaneously, allowing me and my teams to optimize the funnel end-to-end. What I learned from that vantage point is that the critical skill lies in understanding what you’re actually testing, and what the downstream consequences might look like.

One prerequisite for success

At that point at Mimo, we didn’t sit down and debate if we should ‘increase LTV’ or ‘decrease CAC’. We already knew from user research and data where people got stuck, what made them question the upgrade, and what made them leave. We knew that:

The trial anxiety was causing friction because we read it in store reviews every day
Users didn’t perceive the app as a serious learning tool because we weren’t always consistent in communicating it this way
The language barrier was costing us because the users were vocal about it

Example of one of the many research projects we were regularly conducting

But we also knew our target users, what they needed, and what set us apart from the competition. If you don’t have a foundation from user research, don’t know the qualitative signals, or don’t have an honest analysis of where value breaks down, start there.

Interdependency #1: your paywall changes a lot downstream

The paywall is the most obvious lever for conversion. But it’s also a distribution mechanism: for plans, price points, user intent, ultimately LTV.

The trial screen that changed our trajectory

The paywall change that had the biggest impact at Mimo was shifting to the ‘honest trial paywall’ or ‘Blinkist paywall’: a clear, transparent explanation of how the free trial works. When Blinkist shared the results of this experiment, I wanted to test it immediately because we were seeing the same anxieties about trials in our reviews every day.

Our results were great: trial opt-in rates more than doubled, and conversion from trial-to-purchase improved by 50%. The push notifications and emails I’d set up to remind users of the trial expiration didn’t have a strong negative effect on trial cancellations, which was a relief.

But the downstream effect on LTV was the more interesting story: most of Mimo’s trials and purchases were happening during onboarding. Users who started a trial and didn’t cancel were our primary paying customers. The secondary segment was coming through a discount campaign later. So by dramatically increasing the number of users opting in and converting at full price, we shifted the plan mix: more users paid full price rather than a discounted rate. The improvement in trial conversion rate cascaded directly into an LTV lift.

Before

After (1)

After (2)

The general principle: paywall changes don’t just move trial and/or purchase rates. They shift who pays, how much, and at which stage of their journey.

Price changes don’t just change revenue

When we raised Mimo’s yearly price by 20%, the obvious effects were higher ARPU and higher subscriber LTV, as the conversion rate hadn’t changed. But pricing changes also shift how users distribute across plans. A more expensive annual plan makes the monthly plan look like a lower-commitment alternative (which most of your users need at the beginning), and affects renewal behavior down the line.

These distribution effects are often invisible in short-term (30-day) analysis, so you need to model them across the full cohort lifecycle.

I’ve also seen the reverse: prices that are way too high for where the app sits in users’ minds. Most users won’t have had a deep (or any) experience with the product by the time they hit the paywall. For better or worse, your app has already fallen into a mental category with a certain willingness-to-pay before they even open it. If the price doesn’t match that expectation, you can:

Lower your price
Make sure you nail communicating the value through your onboarding, before the paywall
Do both of the above

Lowering the price can sometimes be the price you need to pay to get those first paying customers in. From there, you can analyze these segments, how they use the product, and whether they derive any value from it. This paves the way to the product-market and product-model fits.

It’s not every app’s case, and most of the time, increasing the price is what apps end up doing, but if your users are telling you that’s why they’re not upgrading, I recommend treating it as an investment in the insights you need.

The general principle: A price change can reshape your subscriber mix, not just your ARPU. The right price isn’t the highest price the market will bear, it’s the one that attracts users with the intent and means to stay.

Offering a trial on only one plan can change how users perceive other plans

Similarly, offering a free trial only on the yearly plan makes the yearly plan more attractive, which is usually the goal, as we want a higher share of yearly subscribers.

But depending on your target markets and demographics, users who aren’t ready to commit to a year, who still feel anxious about trials (no matter how much reassurance you add), and who are unsure about the product value, might be treating the monthly plan as their trial. They subscribe for a month to test the product, cancel immediately to avoid being charged on the stores’ schedule rather than their own, and leave silently.

The monthly conversion numbers look fine; you see your total active subscribers number growing, but the churn rates a month later tell the real story.

If this sounds (or looks) like your reality, start asking your short-plan customers why they are canceling. It might be they see no other way to try out your paid plan, but believe they’ll re-subscribe later if they like it.

The general principle: some users might treat shorter plans as a trial run. Learn if this is happening, and make sure to separate ‘real churn’ from plan upgrades.

Trial duration is not universal

Data from RevenueCat’s State of Subscription Apps report shows shorter trials have huge day 0–1 cancellation spikes (over 55% for three-day trials vs. 31% for 30-day trials), but there is no universal trial length that will boost conversion. The right trial length depends on your product’s activation curve, which is invariably linked to your app category.

Trial durations, by category — State of Subscription Apps report 2026

Put simply, three-day trials can work well for utilities and for weekly plans, where time-to-value is short, and users quickly know whether they want to continue. Seven or 14 days often work better for education and health apps, where habit formation takes more time.

At Mimo, we were offering 30-day trials for a long time. Trial opt-in rates were high, but by day 30, so were the cancellation rates: users assumed they’d exhausted the content, or they hadn’t built a habit and drifted away. Shortening the trial to 14 days and communicating the depth of content more clearly helped address this.

The general principle: trial length should match your product’s activation curve, not your optimism about how quickly users will fall in love with it. A longer trial doesn’t automatically mean better conversion. If users aren’t getting activated and retained, you’re just giving them more time to cancel.

Layout and design should help address purchase barriers

For years, trial timeline screens showing users exactly how and when they’d be charged were among the most successful paywall formats. But it doesn’t have to be the only one.

Do your users understand the trial mechanic? Is trial anxiety a barrier for them? Do they understand the difference between your free and paid plans? Are they even aware of the paid plan? Maybe your free plan is too good, and you’re not pushy with upgrades?

The concerns users have before upgrading should help you prioritize experiments between premium feature lists, benefit-led copy, explanations of how the trial works, and promising the reminder or social proof and cancellation policy FAQ. Start from the upgrade barriers and find a way to solve them with design and copy.

Last year, I came up with this ‘paywall anatomy’ to visualize the multiple areas one can leverage. In my experience, most of the leverage lies in pricing and packaging.

Interdependency #2: acquisition quality flows through the entire funnel

Who you acquire determines how they activate, retain, convert, and refer. Changes to your acquisition strategy don’t just affect CAC but many other downstream metrics, often with a delay that makes the connection easy to miss.

Creative concepts aren’t just for solving ‘the click problem’

At Mimo, our earlier ads were animated and visually playful. Hook rates and CTRs were good. But cartoon-style visuals were likely signaling ‘game’ and ‘easy’ rather than ’serious learning tool’, which subtly suppressed the intent of users who did download.

When we shifted toward more professional imagery and videos in ads and store listings — cleaner, expert-looking, with more prominent references to coding — we didn’t just see top-funnel improvements. The profile of users entering the funnel changed. Also, over time, this helped us shift the narrative that learning to code on mobile was not only possible but also worth paying for, before we rebranded a few years later.

This was evolution, not revolution, though

The general principle: the creative that brings someone in sets their expectations for everything that follows.

Seasonal campaigns and discounts can bring high-volume, but low-intent cohorts

Seasonal moments are real: Q5 with New Year resolutions, Black Friday sales, or Back-to-School. Conversion rates are naturally better, and revenue spikes. It feels great. But the problem can manifest as subscriber churn a few months later.

Users acquired during such seasons often have strong momentary motivation but lower sustained intent. I worked with a few apps where paying subscribers who started in late December would barely open the app in January. The revenue was real, but the retention wasn’t.

Similarly, frequent discounting generates revenue in the moment while degrading your customers’ LTV.

Here’s the dynamic I often see when teams try to ‘manipulate’ growth by attracting users and customers via cheaper ad networks, false claims in ads, and non-stop discounts, until users develop ‘discount blindness’:

The general principle: observe your subscriber cohorts over their lifetimes, not just at the outset. Check trends from previous years to see how the seasonal cohorts developed, as not all revenue is created equal.

Interdependency #3: what happens inside the app doesn’t stay inside the app

User retention doesn’t just affect users’ and customers’ lifetimes. It can also flow back up the funnel in ways that are easy to miss.

The language barrier was costing us across every metric

Years ago, we decided to localize the Mimo app into six languages after testing it in two languages. The intent was to remove the language barrier for users who were already downloading the app and had already cleared many psychological hurdles: thinking they weren’t smart enough, or young enough, or were bad at math, or that coding just wasn’t for them.

The positive results rippled up through the entire funnel. A better in-app experience led to higher ratings and reviews, which increased our download conversion rate and helped lower blended CAC. Better retention in core markets (D7 retention increased by +40% on average), and to a 25%-100% increase in purchase rate.

The lower the market’s adoption of English, the higher the activation metrics moved. An activation and retention investment became a lever across the full funnel.

The general principle: activation and retention improvements don’t stay in their layers. They impact CAC, organic growth, and word-of-mouth.

Where you invest in retention depends on where your revenue actually comes from

We invested significant effort into managing churn and improving subscriber retention by implementing payment-failure reminders, trial-expiration reminders, extensive value messaging via automated lifecycle campaigns, and in-app cancellation flows to reactivate users and customers. None of it significantly moved the needle on LTV.

In hindsight, this was not truly necessary. Most of our revenue at that stage came from new subscriptions, and the churn cohorts simply weren’t large enough to drive a meaningful uplift, even if we convinced them to stay.

Resubscribe offer evolution

Payment failure reminders

These days, some of these solutions are much easier to implement. I’d recommend covering your bases with:

Adding subscription benefits on Google Play
Utilizing Apple’s Retention Messaging API
Improving handling of refund requests on the App Store
Introducing automated (or personal) emails asking for trial and purchase cancellation reasons

The general principle: subscriber retention optimization is the right investment when recurring revenue is a significant portion of your total revenue, or when you’ve hit your growth ceiling (when the number of churning subscribers starts exceeding the newly acquired ones). Before that, you might be solving a problem that doesn’t exist.

Interdependency #4: organic loops for lowering blended CAC

Viral and organic levers feel like free growth. But, most of the time, they have natural ceilings set primarily by your product category and your users’ actual behavior. And it’s worth testing at a small scale before a big investment.

3x our k-factor wasn’t the win it sounds like

We rebuilt our referral program: double-sided rewards, 14 days of free premium for both parties, simplified sharing options, and multiple bug fixes to ensure rewards are delivered. These efforts tripled our k-factor.

Tripling sounds significant. But, in this case, a triple from 0 was still pretty much 0. The work was directionally correct and cost-effective. We didn’t let it distract us from the primary focus after we determined it wouldn’t be a significant growth driver.

Before

After

The general principle: the ceiling is usually determined by your app’s category, your target segment, and how much they want to and can share the word about your app. Less often by the size of the reward.

At Mimo, we were among the first apps to implement the share-to-stories feature, working directly with Facebook when the feature was still in beta. We embedded sharing buttons at aha! moments throughout the user journey, such as starting and continuing a streak, moving to a higher league, and other milestones. Many users were motivated by it and shared their progress on social media daily.

But I’ve seen this feature fail when working with other apps or trying to add it to other parts of the journey. It works when the product generates genuinely shareable moments: when progress is visible, meaningful, and something the user actually wants to show off (for example, this was not the case with Playgrounds, where users could practice and build their projects but were far from being proud of them).

The very first iteration of the Share-to-Stories feature

The general principle: you can’t retrofit shareability. Sharing buttons on top of a mediocre experience just get ignored. The foundation needs to be users feeling proud of their progress.

What actually grew our LTV, and three questions before every experiment

Ultimately, over about three quarters, we managed to reverse the trend and grow cLTV by 65%, decrease paid CAC by 20%, and increase monthly proceeds by 35%. In less than 12 months, we were back on track, with a healthy blended LTV/CAC ratio, which we maintained for the years ahead.

For the record, here’s what ultimately moved the needle at Mimo:

The honest trial paywall: doubled trial opt-in, lifted purchase rate by 53%, and improved LTV by increasing the percentage of full-price subscribers
Change in creative direction: changed the perception of users entering the funnel via ads and search visibility on the stores
Localization: produced retention and conversion improvements and positive effects at the top of the funnel
A 20% yearly plan price increase: raised ARPU and cLTV, while we monitored the distribution shift and conversion rates carefully
Improvements in organic acquisition: extensive ASO work, as well as less meaningful initiatives such as increasing the referral program’s efficiency and implementing a content-sharing loop
Many other improvements that compounded

None of the above are universal prescriptions. But there is a discipline: understand what you’re testing, track what it changes beyond the primary success metric, and follow the KPIs all the way down (or up) the funnel.

Before making a change, ask:

What is the expected first-order effect and primary KPIs?
What’s the downstream consequence and secondary KPIs: plans distribution, user intent level, cohort quality, etc.?
What might get worse as a result of this getting better, aka the tradeoffs?

The dangerous scenario is when you optimize aggressively in one area, see a metric improve, declare a win, and miss the lagging negative effects elsewhere. Seasonal campaigns look like wins in December and early January. Heavy discounting makes you feel like a monetization genius until the cohort’s LTV matures and users start complaining.

There’s no playbook.

The apps that scale well aren’t the ones that find the best individual tactics. They’re the ones that build the clearest picture of how their funnel and value delivery actually work, then optimize with this picture in mind.

Flexible Discounts for Web Billing

Mon, 18 May 2026 16:44:47 GMT

If you want to run a seasonal sale, partner with an influencer, or win back churned subscribers, you need promo codes. But if you rely solely on the App Store or Google Play, you are fundamentally limited in what you can offer.

Both platforms restrict promo codes to free trials and introductory pricing. Neither supports percentage-off or fixed-amount discounts on your regular subscription price. If you want to offer 30% off to a win-back segment, the web is the only place you can do it.

Flexible Discounts for Web Billing is now available to all RevenueCat Web customers. You can create and manage percentage-based discounts and promo codes directly from your dashboard and apply them via URL, through the SDK, or via a code input field through the checkout UI.

Control your pricing on the web

With Flexible Discounts, you can create percentage-based discounts and manage specific discount codes (like “SUMMER30”) directly from your RevenueCat dashboard. When you create a discount, you control exactly how long it lasts.

You have three duration options:

One-time: The discount applies only to the user’s first invoice.
Forever: The discount applies to all future invoices indefinitely.
Time-window: The discount applies to all invoices generated within a specific calendar period (e.g., all invoices within the next 3 months).

The time-window duration is calendar-based, not cycle-based. If a user buys a weekly subscription with a 1-month discount, they get the discount on the initial purchase and the renewals within that month. If they buy an annual subscription with a 1-month discount, they only get the discount on the first payment.

How it works

Discounts can be applied in three ways:

URL parameter: Append the code to your Web Purchase Link (e.g., ?discount_code=SUMMER30). This is ideal for email campaigns, influencer links, and targeted landing pages where the discount is pre-applied.
SDK: Apply discounts programmatically via the RevenueCat SDK for in-app or server-side flows.
Checkout UI: End users can enter a promo code directly in the web checkout field.

You can also control exactly where the coupon field appears. Visibility is configurable per Web Purchase Link or Funnel checkout, so you only show it when it makes sense for that flow.

Discount codes can be scoped to specific products or applied globally across all products. Eligibility criteria can also be configured to control which users can redeem a given discount.

Discounts do not stack with introductory offers or trials. If a discount is applied, any configured intro offer is ignored.

Funnels support and discount code analytics are on the way. Head to your RevenueCat dashboard to set up your first discount code, or read the docs to get started.

Announcing RevenueCat Kotlin Multiplatform SDK 3.0.0: a cleaner iOS setup

Thu, 14 May 2026 21:31:36 GMT

The hardest part of shipping a Kotlin Multiplatform subscription app has never been Kotlin. It has been the iOS side: maintaining a Podfile alongside a Gradle build, pinning a separate PurchasesHybridCommon version next to your Kotlin SDK version, and reconciling two dependency graphs every time either side moves. RevenueCat’s Kotlin Multiplatform SDK 3.0.0 removes that second graph entirely.

The iOS integration now flows through Gradle-managed Swift package dependencies, the purchases-kmp-datetime add on is folded back into the main module, and the Android side jumps directly to purchases-android 10.x with Play Billing 8.3.0. This release also resets the minimum versions: Android 6.0 (API 23), Kotlin 2.3.20, and Compose Multiplatform 1.9.3.

In this article, you’ll explore what changed in 3.0.0 and why, the new iOS architecture built on the kn-core and kn-ui facade modules, the step by step migration from a 2.x project that still ships a Podfile, the datetime module removal and its kotlin.time.Instant replacement, the Amazon Appstore opt in change, the Android Billing 8.3.0 caveat for restored consumable purchases, and the new PostHog user ID setter.

What changed at a glance

Before 3.0.0, a Kotlin Multiplatform app using RevenueCat had two parallel native integrations. The Android target pulled in purchases-hybrid-common from Maven Central, which transitively pulled purchases-android. The iOS target pulled in PurchasesHybridCommon and optionally PurchasesHybridCommonUI through CocoaPods or Swift Package Manager, and you had to keep its version in sync with the version that your KMP release was built against. The “common files version” column in the SDK’s VERSIONS.md history is a long record of that constraint, and the version string on each 2.x release was a composite like 2.10.2+17.55.1 to make the pairing explicit.

3.0.0 collapses that pairing. The iOS target now builds directly against the native purchases-ios Swift package via a Kotlin/Native cinterop binding generated by Gradle. The Android target depends on purchases-android 10.4.0 directly, with Play Billing 8.3.0 included as a transitive dependency. There is no more “hybrid common” intermediate layer to pin, and the version table in VERSIONS.md shows Common files version: N/A for 3.0.0 for that reason.

The headline numbers:

Surface	Before (2.10.2+17.55.1)	After (3.0.0)
iOS native library	`PurchasesHybridCommon` 17.55.1 via CocoaPods or SPM	`purchases-ios` 5.71.0 via Gradle (automatic)
iOS UI library	`PurchasesHybridCommonUI` 17.55.1	bundled into `kn-ui` facade
Android library	`purchases-hybrid-common` (transitive)	`purchases-android` 10.4.0
Android Billing Library	8.0.0	8.3.0
Android minSdk	21	23
Kotlin	2.0.x	2.3.20
Compose Multiplatform	1.7.x	1.9.3
`purchases-kmp-datetime` module	required for `Instant` accessors	removed (folded into main)
Amazon Appstore	implicit when using the Android target	opt in via `purchases-store-amazon`

The good news for application code: the public API surface of Purchases, CustomerInfo, Offerings, StoreProduct, and the rest of the model layer is unchanged. Most of the migration effort lives in your build files, your Xcode project, and a couple of import lines on the temporal accessors.

The new iOS architecture: Gradle owns the Swift dependency

The iOS rewrite is the largest change in this release, and it is the change that motivates almost every other one. Before walking through what to remove, it helps to understand what the new architecture actually does.

Two new Gradle modules ship inside the SDK: kn-core and kn-ui. The kn stands for Kotlin/Native, and these modules exist for one reason: to declare the iOS Swift dependency on purchases-ios so that Gradle can generate the Kotlin/Native cinterop bindings against it. If you examine the kn-core module’s build file:

Two things are worth pointing out.

First, the swiftPackage block is a custom Gradle DSL defined inside the SDK’s build-logic. It tells the build to compile a Swift target out of the purchases-ios checkout, then run cinterop against its generated Objective C headers, and finally expose the result under the Kotlin package swiftPMImport.com.revenuecat.purchases.kn.core.

Second, purchases-ios is consumed as a git submodule at upstream/purchases-ios. The 3.0.0 release pins that submodule to version 5.71.0. You do not need to clone it yourself when you use the published SDK artifact: the bindings are pre generated and the Swift sources are compiled when the SDK is published. From the application developer’s point of view, you simply add a Gradle dependency on com.revenuecat.purchases:purchases-kmp-core and everything else flows through Gradle.

The kn-ui module follows the same pattern for the SDK’s UI support, plus a Compose Multiplatform dependency for the Kotlin paywall composables:

The practical consequence is that your Xcode project no longer needs to know about RevenueCat at all. The framework that lands in your iOS app is the same Kotlin framework that contains your shared code, and the RevenueCat symbols are already statically linked into it through the Kotlin/Native bindings. You do not import PurchasesHybridCommon in Swift, you do not import RevenueCat in Swift, you simply call the shared Kotlin API from Swift the same way you call any other shared Kotlin symbol.

Migration step 1: Remove the iOS hybrid common dependency

The first concrete change is to remove the iOS dependencies that 3.0.0 no longer needs. The instructions differ depending on whether you added them through Swift Package Manager or CocoaPods, and the SDK ships both paths in the official migration guide.

If you used Swift Package Manager, open Xcode, select your project in the navigator, click Package Dependencies, then select PurchasesHybridCommon and PurchasesHybridCommonUI and remove them with the minus button. There is nothing else to do on the Xcode side. The Kotlin framework that your shared module produces already pulls in purchases-ios through Gradle, so removing the SPM entries does not leave your iOS target without a RevenueCat dependency.

If you used CocoaPods, the removal is in two places. The Podfile at your iOS project root might contain:

Delete those lines and run pod install once to update your Podfile.lock. Then check your Gradle build, because the KMP project might have been using the Kotlin CocoaPods plugin to declare the same dependency:

These blocks are the most common source of stale state when migrating, because they live in a Gradle file rather than in the iOS project itself. Search your KMP build.gradle.kts files for pod( and remove every entry that references PurchasesHybridCommon or PurchasesHybridCommonUI. If after that removal you have no pod( blocks left at all, you can remove the cocoapods plugin and the cocoapods { ... } configuration block from the KMP module entirely, which also removes the need to run pod install as part of your KMP build.

The end state on iOS in 3.0.0 is a shared module that declares its iOS targets with regular iosX64(), iosArm64(), iosSimulatorArm64() framework configurations and no CocoaPods plugin. The SDK’s own sample app does exactly that. Its iOS source set declares the framework and nothing else:

Migration step 2: Replace the datetime module with kotlin.time.Instant

The purchases-kmp-datetime module was a small companion artifact that added extension properties for converting the SDK’s millisecond timestamps into kotlinx.datetime.Instant values. Since 2.2.0+17.8.0, the recommended approach has been to use kotlin.time.Instant instead, and the previous kotlinx.datetime accessors were deprecated. In 3.0.0, the deprecated accessors are removed.

In 3.0.0, the same functionality lives in the main module and uses the kotlin.time.Instant type from the Kotlin standard library. It is annotated with @ExperimentalTime because that type itself is still experimental in the standard library.

If you upgrade through an intermediate 2.x version first, Android Studio can often auto-apply these renames via the @Deprecated(ReplaceWith = ...) hints. Otherwise, the replacement is mechanical. Find any usage of an Instant suffixed property in your code, for example firstSeenInstant, and rename it to drop the suffix: firstSeen. Then add the experimental opt in either at the file level or at the call site:

The import line is the second thing to watch. kotlinx.datetime.Instant and kotlin.time.Instant are different types in different packages, so if you switch the property name but forget to switch the import, the compiler points you at the right fix immediately. Make sure your import line reads import kotlin.time.Instant and not the kotlinx.datetime one. After that, remove the purchases-kmp-datetime dependency from your libs.versions.toml and your build.gradle.kts files.

If you look at the source of CustomerInfo in 3.0.0, you can see how the millisecond fields and the Instant accessors now live side by side in the same class, with the latter computed lazily from the former:

firstSeenMillis, latestExpirationDateMillis, and the rest of the *Millis companions remain public and stable. If you do not want to opt into the experimental API, you can keep using the millisecond fields directly and do your own conversion. The Instant accessors are a convenience layer, not a required path.

The same pattern applies across EntitlementInfo, SubscriptionInfo, and Transaction. Every temporal accessor on these classes is annotated @ExperimentalTime, and every one returns a kotlin.time.Instant. If you previously had a serialization layer that mapped kotlinx.datetime.Instant to a wire format, you have two options. Either map from kotlin.time.Instant going forward, or stay on the *Millis accessors and serialize the long values directly. The latter is the safer choice if your serialization library does not yet have a converter for kotlin.time.Instant.

(Optional) Migration step 3: Add the Amazon Appstore module explicitly

In 2.x, the Android target of purchases-kmp always pulled the Amazon Appstore support along with it, even if your build only ever shipped to Google Play. In 3.0.0, Amazon support is opt in and lives in its own artifact, com.revenuecat.purchases:purchases-store-amazon. If your KMP app does not ship to the Amazon Appstore, you do not need to add anything. If it does, the migration is a two line addition.

In gradle/libs.versions.toml:

And in your Android source set of the KMP module:

The Amazon module is published from the purchases-android repository, not from purchases-kmp. Use the version that matches the purchases-android version pulled in by your KMP release. For 3.0.0, that is 10.4.0. RevenueCat’s installation docs list the current version next to the Maven coordinate, so check there if you are pinning explicitly.

If you forget this step on a build that previously shipped to Amazon, the symptom is a runtime check inside Purchases.configure(...) that complains the Amazon store is not registered. The compile passes because the SDK’s public API does not reference Amazon classes directly. It is worth running your Amazon build variant through a smoke test after the upgrade for this reason.

Migration step 4: Raise Android minSdk to 23 and adopt Billing 8.3.0

The Android side of 3.0.0 ships with Play Billing Library 8.3.0 through purchases-android 10.4.0. That bumps the SDK’s minimum supported Android version from API 21 to API 23 (Android 6.0). If your KMP app still advertises a minSdk of 21 or 22 in its Android source set, the merged manifest will fail to compile with an uses-sdk:minSdkVersion 21 cannot be smaller than version 23 declared in library [com.revenuecat.purchases:purchases-android-...] error.

The fix is to raise your minSdk to 23:

The device tail below API 23 has been a fraction of a percent for several years, and most app teams have already crossed this line for unrelated reasons. If you have a hard requirement to keep API 21 support, you cannot upgrade to KMP 3.0.0 yet. Stay on the 2.x line until that requirement is removed.

There is one behavior change inside Billing 8.x that is worth flagging even though it is technically in purchases-android, not in purchases-kmp. The 3.0.0 release notes call this out explicitly:

This release updates to Billing Library 8.3.0 with min SDK supported of Android 6 (API 23), previously min was 21. It also removes a previous workaround used to be able to restore consumed one time products which is not available anymore.

The workaround in question was a path inside the older Billing Library that allowed purchases-android to surface already consumed one time products when a user called restorePurchases. Play Billing 8.x no longer exposes consumed purchases, and there is no longer a way for the SDK to reconstruct them client side. For more detail (and the recommended approach for consumables), see the RevenueCat docs.

Toolchain upgrades: Kotlin 2.3.20, Compose Multiplatform 1.9.3, Gradle 9.4.1

3.0.0 raises the floor of every part of its build toolchain. The SDK itself compiles on:

Kotlin 2.3.20
Compose Multiplatform 1.9.3
Gradle 9.4.1

You do not strictly need to match every one of these in your app, but Kotlin and Compose Multiplatform are constraints because they ship metadata that the consumer side has to be compatible with. In practice, that means you cannot consume KMP 3.0.0 on a project pinned to Kotlin 2.1 or earlier, and you cannot consume the kn-ui paywall composables on a project pinned to an older Compose Multiplatform that does not yet have the matching compiler plugin.

A complete before and after of a KMP module

To pull all of this together, here is what a typical KMP module’s build file looked like in 2.x with the iOS hybrid common and datetime dependencies declared:

The same module in 3.0.0 drops the cocoapods plugin and the pod(...) declarations, drops the purchases-kmp-datetime dependency, and adds an explicit Amazon dependency only on the Android source set if needed:

The Xcode side is similarly empty of RevenueCat configuration. Your Podfile no longer needs PurchasesHybridCommon or PurchasesHybridCommonUI entries, and if those were the only pods you had, you can stop running pod install entirely.

Verifying the migration

A few checks worth running after you make the changes above:

Run a full clean build on Android and iOS. The Kotlin compiler points you at any remaining Instant accessor that you forgot to rename, and the build fails fast if a stale pod(...) block still references PurchasesHybridCommon.
Open the merged AndroidManifest and confirm com.google.android.play.billingclient.version is now set to 8.3.0.
On iOS, search your Xcode project for PurchasesHybridCommon. There should be zero hits in Package.swift, in your project’s Package Dependencies list, and in your Podfile. The only RevenueCat symbols visible to Swift should be those re exported through your shared Kotlin framework.
Run a smoke test on a real device against a sandbox account. Configure the SDK, fetch offerings, present the paywall, and complete a purchase. The 3.0.0 release ships a Maestro E2E sample under e2e-tests/MaestroTestApp if you want a reference for an end to end test flow.
If your app ships to the Amazon Appstore, confirm the Amazon variant still works. The runtime check inside Purchases.configure is the canary if you forgot the purchases-store-amazon dependency.

Conclusion

In this article, you’ve explored the architectural shift that defines RevenueCat Kotlin Multiplatform SDK 3.0.0: you no longer need to worry about keeping the PurchasesHybridCommon version matched, the purchases-kmp-datetime module is folded into the main module behind the experimental kotlin.time.Instant type, the Android target ships with Play Billing 8.3.0 with a minSdk of 23, the Amazon Appstore is opt in, and the toolchain floor rises to Kotlin 2.3.20 and Compose Multiplatform 1.9.3.

The goal of purchases-kmp 3.0.0 is to make integrating the library as convenient as it should be. Please let us know what you think! All thoughts, comments and remarks are welcome.

How to know if your free tier is generous enough

Thu, 14 May 2026 10:00:00 GMT

Going freemium is supposed to unlock organic growth. You give away the core product, users fall in love, and they tell their friends. But for many apps, it doesn’t play out that way. The free tier feels like a stripped-down trial, users churn before forming a habit, and the word-of-mouth engine never starts.

The standard freemium diagnostics don’t help much here. Conversion rate, paid penetration, and LTV — they all measure what your paying users are doing. None of them tell you whether your non-paying users are an asset or dead weight.

On a recent episode of the Sub Club podcast, Opal CEO Kenneth Schlenker shared the question he uses instead: would a non-paying user recommend the app to a friend?

If the answer is no, you need to give away more.

Why this question matters more than conversion rate

“If you want the freemium dynamic to really pay out, you need to make sure that the free users are recommending the app,” Kenneth says. “Otherwise, that doesn’t work.”

Freemium works only if free users stick around long enough to build a habit and recommend the app. If your free tier is too restrictive — it’s missing core features to achieve users’ job-to-be-done, or it just feels like a countdown to a paywall rather than a useful product — then neither happens. You get a small percentage converting to paid and zero organic pull.

That’s the trap. A free tier designed to demo the product instead of be a product.

How to actually answer the question

The recommendation question is a heuristic, not a metric. But you can triangulate toward an answer by watching two things in parallel:

LTV of installs
Overall retention across both free and paid users

When Opal tested how much to give away in their core ‘blocks’ feature — the scheduled restrictions that block distracting apps during specific times — the team tried everything from one block (very restrictive) to several, measuring these two metrics at every step.

The goal was to find the point where both metrics were moving up. Rather than focusing on just paid conversion, or free-to-paid funnel efficiency, this would show the combined health of the user base.

“Turns out that three [blocks] is enough for free users to get a great experience,” Kenneth explains. “They can actually really use the app, try out a few different things, and then also really power users that are convinced will pay because they want more.”

Three blocks gave non-payers enough utility to build a habit — and recommend the app. It also left enough headroom that committed users still had a reason to upgrade. If LTV and retention don’t both improve as you adjust your free tier, you’re optimizing one segment at the other’s expense.

What ‘yes’ actually unlocks

When Opal moved from a hard paywall to a genuinely generous free tier, their pay penetration — the share of monthly active users on a paid plan — dropped from 20% to 9%. That sounds like a disaster, but it wasn’t.

The free tier unlocked a segment Opal couldn’t reach behind a paywall: high school and college students, who now make up two-thirds of Opal’s DAUs. These users dragged pay penetration down — but they were doing something more valuable: telling their classmates, then telling their schools. Students recommending the app to administrators created Opal for Schools, now a contracted B2B revenue line. That distribution channel didn’t exist when there was only a hard paywall.

Overall, the shift pushed Opal past one million daily active users. “It’s a short-term, scary drop, but what happens in the long-term is that it pays back tenfold,” Kenneth says.

The takeaway

If your non-payers wouldn’t recommend the product, you don’t have freemium — you have a trial in disguise.

The fix isn’t always to give away more. Sometimes it’s to give away differently — more of one feature, less of another, restructured so the free experience is genuinely useful rather than a teaser. But the recommendation question is the compass. Pair it with parallel tracking of LTV and overall retention, and you have a way to find the line for your own product.

Think about:

Does it unlock enough utility to build a habit or progress towards their goal?
Does it unlock enough to make them recommend the app?
Does it keep enough back to give users a reason to upgrade?

Most teams optimize their free tier to maximize conversion. The teams that win optimize it to maximize recommendation, and let conversion follow.

A machine learning test doubled Life360’s top-tier subscriptions — without losing a single mid-tier user

Wed, 13 May 2026 13:34:45 GMT

The freemium bill of rights

Six months into his role as VP of Product at Life360, Giordano Contestabile ran an experiment. The numbers came back showing a massive revenue upside. He ran to the executive team, expecting a celebration. Instead, he got yelled at.

He had violated what former CEO Chris Hulls called the “freemium bill of rights” — a core set of principles dictating that certain features, particularly those related to family safety, must never be taken away from free users to force a conversion.

“The reason number one why people tell us they don’t subscribe is because the free tier is good enough,” Contestabile says. “Our philosophy is that literally we want to do something about it, but that something is not making the free tier worse — is trying to provide more value and really diversify the subscription offering.”

For an app with nearly 100 million monthly active users, that free tier is the ultimate moat. Life360 relies heavily on network effects; the app isn’t useful in “solo mode,” and the primary discovery channel is parents telling other parents. Locking core utility behind a paywall might juice short-term revenue, but it would fundamentally break the viral loop that built the company.

Why an inconclusive experiment is the only true failure

To find new ways to drive revenue without degrading the free experience, Life360 had to scale its experimentation. But Contestabile doesn’t view experimentation as a series of isolated tests; he treats it as a portfolio.

The effectiveness of that portfolio comes down to three levers: velocity (how many experiments ship), win rate (what percentage succeed), and average win size. But surprisingly, Contestabile doesn’t mind a low win rate.

“The only experiments that we are sad about is an experiment that is inconclusive,” he explains. “Then we feel we wasted our time — we didn’t set up the experiment correctly or the hypothesis wasn’t right.”

A loss, on the other hand, is just data. It proves or disproves a hypothesis. Often, a losing experiment reveals that a feature didn’t work broadly, but resonated deeply with a specific cohort — like users in the suburbs who have been on the platform for a month and own a dog.

Those granular learnings feed directly into the next cycle of tests.

How ML doubled Platinum subscriptions

That granular approach to segmentation recently led to one of Life360’s biggest wins.

The app offers three subscription tiers: Silver, Gold, and Platinum. Historically, the vast majority of users chose Gold. In paywall flows, it’s difficult to clearly articulate the value of all three tiers without overwhelming the user, so the team typically defaulted to presenting the Gold option.

To challenge this, the team deployed a machine learning model utilizing about 900 distinct data points to identify users with a high propensity to buy the Platinum tier. When the model detected a high-propensity user, it dynamically presented the Platinum offer instead of Gold.

The results were staggering. “It doubled the percentage of new users subscribing to Platinum,” Contestabile says. “But it did that without losing a single gold subscriber, which was super surprising.”

The model successfully identified users who wouldn’t have converted on the Gold tier anyway, but were perfectly matched for the specific benefits of Platinum.

Parents aren’t viral

Not every data-driven bet pans out. Knowing that 40% of Life360’s users discovered the app through word-of-mouth — usually parents talking at school pickup — the team tried to digitize that behavior.

They built in-app referral mechanics. They offered free Silver subscriptions to users who invited friends. They tested multiple variations of sharing buttons.

“Nothing. Really failure across the board,” Contestabile admits. “And the reason is people my age, families, older people — they are not viral. Parents are not viral.”

The demographic that actually exhibits viral sharing behavior on mobile devices are teenagers. But while teens are on Life360, the parents are the ones making the purchasing and installation decisions. The team learned the hard way that you can’t force a digital referral loop onto an audience whose natural sharing behavior is entirely offline.

In the full episode, Giordano and David also discuss how Life360 incorporates physical hardware like Tile into its subscription ecosystem, why the company is pushing to make growth a mandate for every department including HR and Finance, and the strategic value of the new “pet profile” feature.

Guest links:

Giordano Contestabile on LinkedIn
Life360
Life360 Careers

Testing subscriptions on Compose Multiplatform: one test suite for iOS and Android

Tue, 12 May 2026 00:22:09 GMT

You wrote your subscription logic once in commonMain, your Compose Multiplatform paywall renders the same on iPhone and Pixel, and your CustomerInfo flow works on both platforms without a single expect/actual. Then you sit down to test it and find that the same product still has two sandboxes, two test account systems, two CI jobs, and two completely different ways for the platform to say “the purchase succeeded.” The unified codebase from Compose Multiplatform Subscriptions stops at the test boundary, and most teams either skip purchase testing entirely or maintain two parallel test suites that drift apart.

In this article, you’ll work through a complete subscription testing setup for a Compose Multiplatform app, exploring why Google Play and StoreKit sandboxes resist unification, how RevenueCat’s Test Store collapses both into one sandbox, how to wire the Test Store into a KMP build with a single BuildConfig field, why the right testability boundary is a PaywallsRepository interface in commonMain, how to write coroutine and StateFlow tests in commonTest so a single suite runs against both targets, why fakes beat mocks for KMP subscription code, and how to layer instrumented tests on top so the same code path is exercised end to end.

Every snippet uses the same source layout as cat-paywalls-kmp, the official CMP demo, so you can drop these patterns into a real project without renaming anything.

The fundamental problem: One product, two sandboxes

Subscription testing on a native Android app is already an undertaking. The ultimate guide to Android subscription testing lists license testers, internal tracks, closed tracks, the android.test.purchased static response, and a handful of BillingClient quirks before you can reliably run a single purchase end to end. The equivalent path on iOS adds StoreKit configuration files, sandbox tester accounts, accelerated renewal cycles, and TestFlight rate limits that change throughout the year.

When the same product ships on both stores, you do not get to pick one of these paths. You run both, and you reconcile the differences yourself. A purchase that goes through in the Google Play closed track does not appear in App Store Connect. A StoreKit Transaction that arrives over the iOS testing pipeline does not flow through your Android PurchasesUpdatedListener. Even when the entire app is one Kotlin codebase, you write two @Test annotations, two CI matrices, and two test data setups.

There is also the unit test gap. Google Play does not expose any way to simulate a purchase inside a JVM unit test. StoreKit configuration files run in the iOS simulator, not in kotlinx-coroutines-test. So even before you worry about cross platform reconciliation, you cannot get a working purchase flow inside commonTest at all. The standard advice is to push everything below the SDK boundary into integration tests, which means most teams end up testing only the parts of their code that do not actually touch Purchases.

Look at the CatArticlesDetailViewModel from the cat-paywalls-kmp demo and you can see the shape of the problem:

This class has real business logic. It decides whether to fade an article body, whether to surface a “Join Now” CTA, what to do when the network call fails, and when to recompose. None of that logic depends on whether the underlying receipt came from Google Play or StoreKit. But if PaywallsRepository.fetchCustomerInfo() only emits values when a real billing SDK is connected to a real store, you cannot reach any of this logic from a unit test. The KMP win disappears at exactly the boundary where you most need it back.

The rest of this article is about getting it back.

The Test Store: A sandbox built into RevenueCat itself

The shortest path out of the two sandbox problem is to stop using the two sandboxes for development purchases. RevenueCat’s Test Store is a sandbox built into the platform itself, not into Google Play or the App Store. You configure it once in the dashboard, set a different API key in your app, and the SDK routes every purchase through RevenueCat’s own purchase modal instead of asking the native store to open its dialog.

The modal it shows is small and deliberate. When the user taps “Subscribe” inside the Paywall composable, the SDK overlays a three button sheet: Test valid purchase, Test failed purchase, and Cancel. Tapping the first one is what a successful purchase looks like from your app’s perspective. The SDK marks the receipt valid on the backend, awaitPurchase resumes with a StoreTransaction, the CustomerInfo flow emits a new value with entitlements["premium"].isActive == true, and your gated UI unlocks the same way it would in production. The other two buttons exercise the failure and cancellation paths without you having to fake an exception by hand.

There is no Play Console setup, no App Store Connect tester account, and no license tester opt in URL. The Test Store works in the simulator, the emulator, debug builds on a real device, and CI runners. Auto renewal still happens, just on accelerated cycles: a monthly subscription renews every five minutes, an annual subscription renews every hour, both stop after five renewals so a test session never runs longer than around five hours. Every Test Store purchase shows up in the same RevenueCat dashboard as production data, which means the same CustomerInfo shape, the same webhook payloads, and the same entitlement transitions you ship against.

Two practical rules. First, you need purchases-kmp 2.2.2 or newer for the Test Store path; the cat-paywalls-kmp demo pins 2.10.2+17.55.1. Second, a Test Store key is a debug only artifact. It looks like test_... instead of goog_... or appl_... and is rejected by the server if the SDK is configured against a production project. Treat it the same way you would treat a debug signing key: useful for development, never in a release.

Setting up the Test Store in a KMP project

The whole setup is one extra BuildConfig field on the Android side and one decision in your Application.onCreate about which key to use. iOS does not need a separate change because the same Kotlin code reads the same configuration when the shared module initializes on the Swift side.

Start with the Gradle build. In composeApp/build.gradle.kts, read the Test Store key from local.properties and expose it through buildConfigField. Pulling the key from a local property file (which is already gitignored by Android Studio) keeps it out of source control by default:

Notice the default value of an empty string. If local.properties does not contain revenuecat.test.api.key, the field is still defined and compiles cleanly. That matters for two reasons: release builds pulled from a clean CI checkout do not see the key at all, and any developer who has not opted into the Test Store keeps the regular production path without any source changes.

The local.properties entry on a developer machine is one line:

revenuecat.test.api.key=test_YOUR_KEY_HERE

The key selection happens in CatArticlesApplication, which is the Android entry point for the shared Compose surface. The pattern is “prefer Test Store key when present, fall back to the production key otherwise”:

Two design decisions here are worth pulling out. The first is that the same Purchases.configure call routes either to the Test Store or to production. The KMP SDK does not have a separate “test mode” flag; it picks the backend based on the key prefix and behaves identically otherwise. Your commonMain code never has to ask which backend it is talking to. The second is that this is a debug only ergonomics, not a build flavor. Every developer can flip on Test Store for their personal build by adding one line to their own local.properties, without any branches in the source tree.

The iOS side does not need an analogue. When the Kotlin runtime starts on iOS, it shares the same Purchases.sharedInstance configured by the platform App struct. If you want the iOS app to also use the Test Store during development, configure the same test_... key in the SwiftUI entry point:

Read testStoreApiKey from an .xcconfig, a Info.plist entry, or a build setting. The shape is the same as on Android: take the key from a local source of truth, fall back to a production constant.

The testability boundary: wrapping Purchases behind a repository

Even with the Test Store wired up, you do not want every unit test to depend on a running Purchases.sharedInstance. The SDK assumes a platform context that is not present in commonTest: an Android Context, a BillingClient, an iOS StoreKit transaction listener. The cat-paywalls-kmp demo solves this by funneling every call into the SDK through a single repository interface in core/data:

There are three things to notice about this interface. First, every method returns a Flow<Result<T>> instead of a suspend function. That choice gives StateFlow consumers something to .map and .collect without paying for an extra viewModelScope.launch, and it lets the implementation choose between cold flow semantics and stateIn caching without changing callers. Second, the types in the return positions are all from com.revenuecat.purchases.kmp.models.*. They are pure Kotlin data classes that exist in commonMain, which means a test can construct or hold them without expect/actual gymnastics. Third, there is no platform specific code in the signature, which is what lets the same interface back both androidMain and iosMain consumers.

The production implementation wraps Purchases.sharedInstance with suspendCancellableCoroutine and a small Flow builder. The shape is straightforward:

This is the only place in the entire codebase that imports Purchases.sharedInstance. Every ViewModel, every Compose function, every test is on the other side of the interface. That is the boundary you need to make commonTest viable, because anything above this line can be exercised against a fake.

Unit testing in commonTest: the patterns that work on both platforms

A Kotlin Multiplatform unit test cannot use MockK, Mockito, or any reflection based mocking framework. Those libraries are JVM only. They will compile in commonTest if MockK is on the version catalog, but the iosTest target will fail to link when Kotlin/Native tries to resolve the bytecode generation runtime. The cat-paywalls-kmp demo even declares MockK in gradle/libs.versions.toml and then never uses it, because the moment you adopt the convention plugin that runs commonTest against both targets you cannot import it from shared code.

What does work in commonTest is kotlin-test, kotlinx-coroutines-test, and Turbine. The cat-paywalls-kmp KmpLibraryConventionPlugin wires them into every feature module at the source set level:

The reason this is in a convention plugin and not in each feature module’s build.gradle.kts is that you want this to be free. Every module that hosts a ViewModel or a state holder needs the same test dependencies, and forcing each module to opt in by hand is exactly the kind of friction that ends with someone writing logic they cannot reach from a test. The plugin makes “write a unit test” the default, not a setup task.

A feature module then only declares what is unique to its tests. For feature/subscriptions, the only extra dependency is core/data, because the test uses the real PaywallsRepository interface:

That is the entire test wiring. From here, you can write a class SubscriptionManagementViewModelTest in feature/subscriptions/src/commonTest/kotlin/... and it will be picked up by androidUnitTest and iosTest automatically. One file, both targets.

Why fakes beat mocks for KMP subscription code

With MockK off the table, your options are hand written fakes or expect/actual mock factories. The cat-paywalls-kmp demo picks fakes for every test, and the choice is more deliberate than it looks. Subscription code has two properties that make fakes the better fit even in a JVM only project. First, the surface area of PaywallsRepository is small. Three methods, all returning Flow<Result<T>>. There is nothing to mock that a small data class with a few setters cannot already express. Second, the same fake is reused across many tests with different setup, which makes a stateful builder more readable than a stack of every { ... } returns ... lines.

Here is what the canonical fake from FakePaywallsRepository.kt looks like:

The constructor takes no arguments. The fake starts in a deliberately empty state where every flow emits a “not configured” failure. A test then sets the slots it cares about and leaves the others alone. That asymmetry is the value of fakes over mocks: you do not have to enumerate every method up front, you only describe the scenario you are testing.

The flow methods themselves are one line each, with the empty case routed through a recognisable exception so a misconfigured test fails loudly rather than hanging on an empty flow:

The IllegalStateException here is not for production semantics. It is a test ergonomic. When a future contributor adds a test that calls a method without setting it up, the test fails with a message that names the missing slot, which is much faster to debug than an empty Flow that just never emits.

One limitation to call out. The fake holds and returns Offering and CustomerInfo values, but it does not construct them. Those types come from purchases-kmp and do not currently expose public constructors. That means you can test the failure paths through the fake directly, but a successful “purchase completed and entitlement is now active” assertion has to be exercised against a real Purchases.sharedInstance. That is exactly the seam the Test Store fills, and the next two sections show how.

Writing tests against the fake

A ViewModel test in commonTest looks almost identical to its androidx counterpart. The only differences are the kotlinx.coroutines.test.StandardTestDispatcher instead of TestCoroutineDispatcher, and Turbine instead of LiveData observers. Here is the setup pattern that the cat-paywalls-kmp SubscriptionManagementViewModelTest uses:

Dispatchers.setMain replaces the main dispatcher that viewModelScope uses with the test dispatcher. Without that swap, any StateFlow.stateIn(viewModelScope, ...) would post to the real main thread and the test would hang, because there is no Android main looper in commonTest. Dispatchers.resetMain after each test is the symmetric tear down. Together they give you deterministic scheduling: nothing runs until you ask it to.

The actual test reaches into the fake, instantiates the ViewModel, and asserts on its state through Turbine. The pattern for an error path:

Three details earn their keep here. The first awaitItem() returns the initial Loading value because StateFlow always replays its current state on collection. testDispatcher.scheduler.advanceUntilIdle() then drains every queued coroutine in the test scope, which is what causes the repository’s flow to emit, the ViewModel’s combine chain to run, and the next state to land in the StateFlow. The second awaitItem() picks that state up, and the assertion confirms the error message survives the pipeline.

If you write four or five tests like this, you cover the entire surface of the ViewModel’s state machine. The initial loading state, the offering error path, the customer info error path, the combined error path, and the cancellation path are each one fake setter plus an awaitItem(). None of these tests need a billing client, none of them need a network, and the same suite runs against the JVM target and the iOS target without modification.

What this suite cannot cover is the actual purchase. Because the fake cannot construct an Offering with real packages, you cannot run a test that says “the user taps subscribe, the SDK validates the receipt, and the entitlement flips to active.” For that path you need the Test Store, and the right place for it is an instrumented test on top of the unit suite, not inside it.

Integration testing with the Test Store on Android

The Testing Test Store post on the RevenueCat engineering blog walks through this end to end, and the same approach applies to a CMP project because the Android target compiles down to a normal androidTest source set. Put the integration test in composeApp/src/androidTest/kotlin/.... Configure Purchases once with the Test Store key, launch a small activity that drives a real purchase, and use Espresso to tap one of the three buttons that the Test Store modal presents.

The setup uses InstrumentationRegistry.getInstrumentation().targetContext because the test runs in a real Android process, not in a JVM unit test. The configuration call is the same one your Application makes, but pinned to the Test Store key:

The actual purchase test then resolves the test offering, launches the activity, and waits for the Test Store modal to appear before tapping the “Test valid Purchase” button:

Two things to call out. The delay(2_000) before the Espresso tap exists because the Test Store modal is rendered through the host activity, and Espresso needs the view hierarchy to settle before it can find the button. The 30 second timeout on the assertion accounts for the round trip to the RevenueCat backend that validates the receipt and updates CustomerInfo. Both numbers can be tuned for your CI environment, but they are intentionally generous because the test is doing real network work.

The companion tests are the other two buttons. Tapping “Test failed Purchase” lets you assert that the entitlement stays inactive and the error propagates through your domain layer. Tapping “Cancel” lets you assert that the PurchaseCancelled exception is mapped to a no op rather than surfaced as a user facing error. Three tests, three modal buttons, one Test Store key, no Play Console.

The iOS side: StoreKit configuration files and what the Test Store unifies

On iOS, the equivalent of an instrumented test is a StoreKit configuration file driving an XCUITest. Apple introduced StoreKit configuration files in Xcode 12, and they remain the canonical way to test purchases inside the iOS simulator without setting up a sandbox account. You describe the products in a .storekit file, attach it to a scheme, and run the app under that scheme. Purchases then resolve through the configuration file instead of the App Store backend, and you can use XCUITest to drive the resulting native StoreKit modal.

This works, and for an iOS only app it is often the right answer. In a Compose Multiplatform project, the trade off looks different. The StoreKit configuration file only covers the iOS side. It does not interact with your Android tests, it does not flow data through your PaywallsRepository, and a successful purchase against it does not show up in the RevenueCat dashboard the way a real purchase does. You end up with two parallel integration suites that test the same Kotlin code through two completely different driver layers.

The Test Store collapses this. When the same commonMain code is configured against a Test Store key on both platforms, an iOS purchase goes through the same RevenueCat modal as an Android purchase, the same backend validates the receipt, and the same CustomerInfo flow emits the same shape on both sides. Your iOS integration test can then drive the same three button modal with XCUITest:

The pattern mirrors the Android Espresso test almost line for line. Find the subscribe button, find the “Test valid Purchase” button, wait for the gated content to unlock. The same three Test Store buttons cover the same three scenarios. The same CustomerInfo update unlocks the same composable. You still write two driver layers because the OS testing frameworks are different, but the data plane is shared, the network calls are the same, and the dashboard sees both runs as the same Test Store activity.

For most teams, this is enough. If you also want to exercise the native StoreKit error paths (parental controls blocking a purchase, sandbox account expired, region restrictions), keep a small .storekit based suite for those edge cases. The bulk of your purchase path coverage moves to the Test Store and shrinks the size of the iOS only suite to a handful of platform specific tests.

A three layer testing strategy

Putting it all together, a Compose Multiplatform subscription app has three useful test layers, and each one answers a different question.

The first layer is commonTest unit tests against FakePaywallsRepository. This is where you cover your ViewModel state machine: initial loading, error paths, cancellation handling, derived UI states, and any business logic that lives above the SDK boundary. These tests are fast, deterministic, run on both targets from a single source set, and never touch the network. They are the layer you run on every PR, in pre push hooks, and on every CI build.

The second layer is instrumented tests against the Test Store. On Android this is androidTest with Espresso. On iOS this is XCUITest. Both drive the same RevenueCat purchase modal, both produce real CustomerInfo updates, and both verify the end to end flow from subscribe button to unlocked content. These tests are slower and a little flakier because they include real network calls, but they are the only layer where you can prove that the purchase path works for a real receipt. Run them on merges to main, on release branches, and as part of your release qualification.

The third layer is optional and platform specific. A StoreKit configuration file based suite for iOS edge cases that the Test Store does not model. A Google Play closed track for the rare bugs that only reproduce against the real billing client. Both are valuable, but neither is the workhorse. They exist to plug specific gaps, not to cover the core purchase flow.

The numbers shift the right way too. The unit tests are tens of milliseconds each and run on every commit. The instrumented Test Store tests are seconds each and run on merge. The native edge case suites are minutes each and run on release. Most of your purchase coverage ends up in the layer that runs most often, which is the opposite of what happens when you only have a closedTrack and a StoreKit configuration file.

CI considerations: one matrix, three jobs

The CI shape that falls out of this is straightforward. One job runs commonTest for both targets:

allTests is the umbrella task that Kotlin Multiplatform creates when you have both Android and iOS targets configured. It dispatches to jvmTest, iosX64Test, iosSimulatorArm64Test, and any other target you have enabled. A failure in any one fails the job. Run this on every push, every pull request, and every nightly build.

The second job runs the Test Store instrumented tests on Android. The blog’s CI snippet works as written:

Two practical notes. The Test Store key needs to be available to this job, but not to forks or to release builds. The cleanest way is a repository secret that the job writes to local.properties at the start of the run, so the same buildConfigField pattern picks it up. The job should also run on merges to main and on release branches, not on every PR, because it includes real network calls and consumes Test Store renewals.

The third job runs the iOS XCUITests. A standard xcodebuild test invocation against the same scheme that ships the app, with the Test Store key injected through the same mechanism your local builds use. Both Android and iOS integration jobs read from the same RevenueCat project, which means a single dashboard view shows test activity from both platforms.

The result is a CI surface that mirrors the test layers. Fast feedback from the unit suite on every commit. Slower but realistic feedback from the Test Store suite on merge. The expensive native suites only when you cut a release. None of these jobs require coordinating two sandboxes, and the same PaywallsRepository and ViewModel code is exercised end to end at every layer.

Conclusion

In this article, you’ve worked through a complete subscription testing setup for a Compose Multiplatform app. You configured the RevenueCat Test Store from local.properties and a single buildConfigField, drew the testability boundary at a PaywallsRepository interface so the SDK never leaks into your ViewModels or your tests, wrote commonTest unit tests against a FakePaywallsRepository using kotlin-test, kotlinx-coroutines-test, and Turbine, then layered instrumented tests on top with Espresso on Android and XCUITest on iOS that drive the same three button Test Store modal. The same shared code path is exercised from commonTest all the way through to the receipt validation backend, on both platforms, without two parallel test suites.

The thing worth internalizing is what changed at each layer. Subscription testing usually fragments because the sandboxes do. By moving the development sandbox up into RevenueCat itself, the Test Store turns the two platform problem back into one. By putting a small repository interface between Purchases.sharedInstance and the rest of your app, commonTest becomes a viable home for the bulk of your business logic tests. By using fakes instead of mocks at the unit layer, the same suite runs against both Kotlin targets without expect/actual or a JVM only mocking framework. Each of these choices is small. Together they collapse what used to be two test suites into one.

Whether you are porting an Android subscription app to iOS, starting a new CMP product from scratch, or trying to get purchase testing into CI for the first time, this layered setup gives you the smallest surface area you can ship a cross platform subscription app on with real confidence. The full source for every snippet in this article lives in cat-paywalls-kmp, and a free RevenueCat project with a Test Store key is the only thing you need to run all three layers locally.

Revenge of the brand manager: why ‘pretty’ ads fail at direct response

Mon, 11 May 2026 14:42:25 GMT

There’s a persistent temptation in app growth to make things look beautiful. When a team finally gets budget for creative production, the instinct is to hire a slick agency, shoot in 4K, and write a punchy, conceptual slogan. It feels like real marketing — like you’re finally building a brand.

But when those ads hit the Facebook and Instagram feeds, they often bomb.

I framed this pattern during a recent Sub Club Live as “revenge of the brand manager”. This happens when you optimize for aesthetics rather than addressing the messy, stressful reality your users actually inhabit.

Selling a vibe instead of a solution

Take a recent ad campaign from Granola, a popular AI note-taking app. Granola’s ads were undeniably gorgeous — exactly what a brand manager wants to see on a billboard.

The problem? The ads didn’t speak to the user.

When I look at creative like this, I see an ad made by somebody who hasn’t taken the time or trouble to really understand the world their users inhabit. While it checks a lot of boxes for traditional advertising best practices, in direct response advertising, it doesn’t really speak to what the users are going through.

When a user is scrolling through Instagram or TikTok, a conceptual slogan doesn’t stop them. They don’t care about your brand identity — they care about their own immediate problems. If your ad looks like it was made simply to be beautiful, it registers as an ad. An interruption rather than a solution. As we’ve seen with the shift toward value-first UGC ads, users have developed a profound blindness to anything that feels overly produced or disconnected from their reality.

Designing for the lived experience

If beautiful slogans don’t work, what does? The fix is to root your creative entirely in the user’s lived experience. You have to depict a specific scenario that the user recognizes immediately.

For a note-taking app like Granola, I would suggest focusing on a visceral moment of panic.

Take a specific instance from your user’s life, like a CEO asking what the client said. You freeze. But then you look at this app, and remember your notes. That kind of lived experience ad works much, much better versus a slogan where I don’t even know what the product does for anyone.

This approach works because it leverages the emotion that comes with a solved problem. The user isn’t buying an AI note-taker; they’re buying an escape hatch for when their boss puts them on the spot. By visualizing the panic of the problem and the relief of the solution, the ad earns the click.

Why ‘ugly’ often wins

This reality is often frustrating for founders and designers. As David pointed out during our live session, it is easy to err on the side of polish because we all love the ideal of pristine brand advertising. But in direct response, the ‘ugly’ design — the one that clearly and bluntly states the problem — is frequently what wins the creative testing phase.

When you’re scaling paid user acquisition, you cannot afford to let aesthetic preferences dictate strategy. If you overanalyze your creative through the lens of brand purity, you miss the scrappy, relatable angles that actually drive downloads and trial starts.

So the next time you brief a designer or a creator, ban the conceptual slogans. Ask them to show you the moment your user sweats, and the moment your app makes them breathe a sigh of relief.

About the Author: Shamanth Rao is the founder and CEO of RocketShip HQ, a boutique growth marketing firm with over $100 million in managed spend. He hosts the Mobile User Acquisition Show, where he’s launched Intelligent Artifice, a deep dive on how AI is transforming performance marketing.

Meet the subscription app pre-mortem: how to plan for failure before you ship

Fri, 08 May 2026 10:45:34 GMT

When I started out in the app industry, I worked at a growth agency that partnered with a development agency. As a result, a lot of our projects involved launching entirely new websites or app redesigns.

It was amazing — a fresh slate to use all our customer insights and improve performance! …But also slightly terrifying. Not because of the work itself, but because of the waiting.

That horrible in-between phase after you’ve shipped something, where you’re refreshing dashboards, overanalyzing early feedback, and catastrophizing every dip in the numbers.

What helped me wasn’t positive thinking. It was the opposite: leaning into pessimism.

Deliberately imagining everything that could go wrong before launch. Thinking through every possible scenario. Having the trickiest, most uncomfortable conversations with clients and teams to explore all the what-ifs.

It’s called a pre-mortem. (A bit morbid, but it works.)

Since then, I’ve used it for everything from website redesigns to subscription app launches; especially in products where feedback loops are fast and the stakes compound quickly.

And it’s become one of my favorite planning tools.

What is a pre-mortem?

A regular post-mortem happens after something fails, the classic sprint retrospective. You gather the team, ask not only ‘what went right’ but also ‘what went wrong’ or ‘what could have gone better’, and try to learn from it.

It often comes with a few cringe-inducing “we could have predicted that” moments, where Captain Hindsight suddenly looks like a genius.

The problem is, it’s reactive rather than proactive. You’re analyzing what went wrong after the fact, but it doesn’t change the outcome.

A pre-mortem flips that. The concept is simple: before you launch, imagine it’s three months later, and the launch has completely flopped. Really put yourselves in that moment: the disappointment, the stress, and the why-is-this-happening panic. Bring it to life.

Then ask the full team: why did it fail?

I called it pessimistic, but honestly, it’s not. It only becomes pessimistic if you assume failure is inevitable and stop there. The real goal is to surface risks while you can still do something about them.

If anything, it’s more realistic — and even optimistic — because it assumes you can fix and prevent those risks.

And the interesting part? The things that come up in a pre-mortem are rarely surprising. They’re usually the things everyone already half-knows but hasn’t said out loud.

Who came up with such a morbid concept?

The credit goes to Gary Klein and his often-cited Harvard Business Review article from 2007. But Gary (and yes, given how much I love this concept, we’re absolutely on a first-name basis) had been using the method for a good 30 years before that. He first developed it in the early 90s, so no one needs to do confusing maths back from 2007.

A psychologist by trade, he was fascinated by how people make decisions under pressure and uncertainty. He studied this in one of the most high-stakes environments imaginable: the US Air Force. Later, he developed the idea of pre-mortems further within his own research company, drawing not only on that work but also on medical post-mortems.

What Gary understood — and what more of us need to recognize — is the flawed reality of group decision-making. We’re wired for harmony. We want to get along. No one wants to be the negative Nancy, pointing out risks or poking holes in a plan.

I recently emailed a client outlining all the risks in their current target-setting model and ended with, “sorry, this is a bit negative…”. I felt bad raising those risks, but I also knew, from experience, what happens when you don’t. When you let people believe targets are promises rather than stretch goals. Still, it sucks to be the one to say it. That’s exactly the tension Gary Klein was trying to solve. A pre-mortem removes the pressure to keep up a ‘rah-rah, everything is great!’ mindset.

Instead, it creates a space where calling out risks isn’t awkward; it’s expected.

Since then, the concept has taken off. You’ll find pre-mortems everywhere now: in startups, corporate boardrooms, and even back in the military (a full-circle moment, really).

Daniel Kahneman — who many people know from his book Thinking, Fast and Slow — even called it his single most valuable decision-making technique. Not bad for something that started as an internal fix at a small research company.

Gary later expanded on the idea with what he calls the ‘double-barreled pre-mortem’. After imagining failure, you run a second round where you daydream about wild success — and what could go wrong there, too.

It sounds more optimistic, but the goal is the same: surface risks. Even success can break things. If only Ticketmaster had done that before the Taylor Swift Eras Tour ticket sales…

So that’s how, and why, pre-mortems started. But beyond making it easier to speak up, why else is this tactic so useful?

Why do pre-mortems actually help?

There are five reasons why pre-mortems are so powerful:

1. They make you a better fortune teller

Pre-mortems use a technique known as prospective hindsight (a fancy way of saying imagining the future), which Deborah Mitchell at Wharton found can increase your ability to correctly identify reasons for future outcomes by 30%. All that by pretending it has happened. You basically become a better fortune teller, pretty cool, right?

So it helps you surface real potential risks more effectively than just thinking about them without a specific prompt.

2. It creates psychological safety to talk about risks

We’ve talked a bit about this already. By making the goal ‘identify risks’, you make it safe to say them out loud. People are often all thinking “the founder keeps changing priorities” or “pretty sure this plan was ChatGPT and hasn’t been checked”, but they might be too scared to say it out loud.

As you see others be more open, you’ll also end up being more open.

I think this is especially valuable when you have a room full of young, smart people. I remember at my first job, I assumed whatever senior leadership said was the right call. It felt intimidating to challenge someone with 20 years more experience than me.

Now, as a leader, I know you can tell people to speak up — but the reality is, not everyone will. A pre-mortem helps level that playing field. It gives people permission, and a clear prompt, to question assumptions, raise concerns, and say the thing they might otherwise keep to themselves.

3. It makes the fear concrete

Vague anxiety is paralyzing; we’ve all catastrophized over endless, nameless what-ifs. Specific risks, though, are manageable.

Once you’ve written “what if no one buys it?” on paper and mapped out a plan for it, it stops being a powerful fear. It becomes just another scenario to handle.

Even better, involving the whole team in a pre-mortem helps counteract the planning fallacy — that tendency to be overly optimistic, assume everything will work out, and underestimate time, costs, and risks. By making the risks concrete, you can create a clear action plan.

Think of it as a bit of growth group therapy.

4. It removes panic from decision-making

Have you ever stood in line for coffee, and suddenly it’s your turn way faster than you expected? The barista asks, “What would you like?” and you stammer out, “Um… errr, a vanilla matcha latte, wait, an iced vanilla matcha latte!” Only to take a sip and think, “What was I thinking?”

Okay, that might have just been my own therapy moment the other day, but the point stands: under pressure, we’re terrible at making decisions on the spot.

The same goes for post-launch problems — you’re stressed, stakeholders are asking questions; you’re tempted to make snap, reactive decisions. You blurt out the first thing that comes to mind, and hope for the best.

A pre-mortem changes that. If you’ve already decided, ‘If X happens, we do Y’, then you don’t have to think under pressure. You execute the plan. You’ve already discussed the right course of action as a team, ahead of time. I do this for every experiment I run because it makes ‘failed’ experiments easier to handle: we know what failure looks like, we can learn from it, and we already have a sense of what to test next.

5. It gives you permission to take action imperfectly

I once worked with a Head of Product who was basically a pre-mortem specialist, though he probably didn’t realize it, since we’d never talked about pre-mortems. He had an uncanny ability to spot every possible risk, think it through, and tackle it. Sometimes, it felt frustrating, as it could slow projects down. Until I realized that if I named the risk and laid out a plan, he was more than happy to roll with imperfection.

The extreme opposite of optimism in project planning isn’t pessimism, it’s perfectionism. Try to control everything, and you’ll never go live.

A pre-mortem shows you that even if things go wrong, you have a path forward. That makes it easier to ship. The goal isn’t to prevent every risk, it’s to be conscious of which risks you’re willing to accept and which you aren’t.

By now, hopefully, you’re convinced and starting to wonder how to run your own pre-mortem.

How to run a pre-mortem

While the concept itself is simple, a few small tweaks in setup and approach can make your pre-mortem far more powerful.

Step 1: Gather the relevant individuals

While you can do a pre-mortem alone, I can’t recommend doing it with your team enough. Different people spot different risks based on their expertise, and hearing others’ perspectives can reveal risks you might never have considered.

Even better: bring in someone outside the project; someone who won’t have rose-tinted glasses. Ideally, a classic naysayer who can look critically at what’s being assessed (kind of like that Head of Product I once worked with).

Step 2: Set the scene

Next, set the scene.

Say something like: “It’s [date 2–3 months from now]. This launch has failed. Not a minor disappointment, but a proper flop. What happened?”

Pick a timeframe that feels realistic for the project. Then lean into the drama — think back to high school theater class and really bring it to life. The goal is to make it feel real, to transport yourself to that future moment, and look back with hindsight.

You can even get creative: have AI mock up a founder email, a critical internal memo, or an article in a relevant newspaper or magazine. The more tangible and vivid the scenario, the easier it is to uncover the real risks.

Step 3: List every reason it might have failed

Have everyone list reasons separately. Write down everything, even if they seem unlikely. For example:

We couldn’t reach enough of our target audience
The trial-to-paid conversion rate is too low
We saw very high initial churn
We struggled to get downloads
The price felt wrong (too high, too low, confusing)
A competitor launched something similar at the same time
We got bad press or reviews early on
The team burned out before we could iterate

The more specific, the better. We aren’t aiming for perfection here; quantity over quality is the key at this stage. The goal is to surface as many potential risks as possible.

Step 4: Go through the risks and group them by theme

There will inevitably be some overlap in the concerns people raise. That’s okay, this is a no-judgment moment. At this stage, you’re not prioritizing; you’re organizing.

Give everyone a chance to voice their concerns. Whatever you do, don’t try to diminish them or explain why something won’t happen, especially if you’re the leader or founder.

Instead, focus on grouping the concerns by theme. This helps you see more clearly:

Which concerns are the most common
Which areas seem to carry the most potential risks

Optional additional step: When pre-mortems require a culture change

In some companies, getting into the pre-mortem mindset can be tricky. When things are busy or deadlines are tight, it’s easy to skip it. Or sometimes, people just feel uncomfortable bringing up the uncomfortable.

Here, the framework Shreyas Doshi suggests can be really useful. He recommends categorizing risks into three types:

Tiger: a real threat — something that will hurt the company if left unaddressed.
Paper tiger: a perceived risk/threat that, on closer inspection, is unlikely to cause real problems. These are the things the team might be stressing over, but are actually minor and manageable.
Elephant: unsurprisingly, this is ‘the elephant in the room’ — a risk that is present but isn’t being talked about.

Using this playful, visual language helps build the psychological safety that’s so important for effective pre-mortems. It makes discussions lighter and more approachable, and it gives you a way to raise risks in other settings too. For example: “This might be a paper tiger, but have we considered…?”

Step 5: For each risk theme, ask two questions

Now that you’ve done some idea spring cleaning, it’s time to assess risk levels and impact:

Certainty assessment: how likely is it to happen?
Impact assessment: how bad is it if it happens?

This helps you map everything onto a simple 2×2 grid, so you don’t get stuck debating unlikely scenarios or low-impact risks. Instead, you can focus your energy on the ones that actually matter.

Depending on the size of the group and the scope of the project, this might even be a separate session. The goal here isn’t to solve everything yet; it’s to start identifying which risks deserve your attention first.

Step 6: Determine whether you need to plan or prevent those risks

Next, focus on those biggest risks and decide whether they’re preventable, plannable, or both:

Prevent: can we reduce the likelihood of this happening?
Plan: if it happens anyway, what will we do?

If you try to prevent every single risk, nothing will ever go live, so this is where you need to be critical. Ask yourself: Is this something we can realistically mitigate, or is it a risk we need to consciously accept?

The goal isn’t to eliminate all risk. It’s to understand it and feel prepared for what might happen.

Step 7: Work out potential solutions

Now, depending on the complexity of the risk, this might require an extra session — or a few — to properly think through. Don’t get caught trying to solve everything on the spot. Some risks need deeper brainstorming or input from others.

What does help is summarizing your plans into simple if/then statements. They’re clear, practical, and bring a sense of calm to the unknown.

For example:

If activation is below 10%, we’ll simplify the first-time experience and retest
If we attract the wrong customers, we’ll adjust our targeting and messaging before scaling spend
If nobody hits the paywall, we’ll move it earlier and test different copy
If day 1 churn is above X%, we’ll investigate whether the paywall is creating impulse conversions

Each of these should be tied to a specific metric you’re already tracking — trial conversion rate, activation rate, churn, and MRR. Set your trigger thresholds before launch, so you’re not debating what ‘bad’ looks like after the fact.

If you’re running paywall or pricing experiments, RevenueCat’s Experiments feature lets you set up A/B tests and define success metrics before you launch — so you’re not making decisions under pressure.

Step 8: Review and revisit

One last thing: don’t let your pre-mortem gather dust in a shared doc like so many other strategy decks. Depending on your timelines, set a few clear check-in points, for example, Day 7, Day 30, and Day 90 post-launch.

At each one, revisit your if/then statements and ask: are any of these scenarios actually playing out?

This is where the pre-mortem really earns its keep. The planning is valuable, but the follow-through is what helps you avoid those “we should have seen that coming” moments later on.

For longer projects, it can even be worth running a second pre-mortem closer to launch; a fresh look, with more context, often surfaces new risks you couldn’t see earlier.

Example: subscription app pre-mortem

Before launching a new subscription tier for a client last year, we ran a quick pre-mortem.

One of the risks we identified: ‘Existing customers might feel cheated if new customers get a better deal’.

We couldn’t fully prevent that. The new tier genuinely offered better value, and it needed to. It unlocked a segment of customers we were previously pricing out. But by naming the risk, we could prepare for it:

We spent more time positioning the existing tier, not just promoting the new one
We added a relevant feature to the higher tier to reduce cannibalization
We communicated proactively with existing customers, explaining the new tier and who it was for
We prepared responses for the support team

The result? Far fewer complaints than expected, and only a small increase in support tickets (mostly from customers who missed the updates).

More importantly, the new tier drove growth rather than cannibalizing the existing one, with overall MRR increasing significantly.

When to use pre-mortems

Pre-mortems work in a wide range of scenarios:

Launching a new product or SKU
Changes to subscription models
Pricing adjustments
Entering a new market or channel
Rebrands or major website overhauls
Paid campaign pushes

I even run them with new advisory clients to make sure I can support them effectively and drive real impact.

Basically, try a pre-mortem anytime failure would hurt, and you want to have thought it through in advance.

A pre-mortem won’t make launches less scary

You’ll probably still refresh dashboards too often and overanalyze early data — I certainly do.

But the quality of your anxiety changes. Instead of a vague dread that something might go wrong, you have a clear list of what could go wrong, and a plan for each scenario.

The best launches I’ve been part of weren’t the ones where nothing went wrong. They were the ones where we’d already talked through what we’d do if things did go wrong.

So before your next paywall test, pricing change, or new tier launch, take 30 minutes with your team. Imagine the worst, write it down, make a plan.

Then ship it anyway.

A complete guide to migrating from Google Play Billing v7 to v8 (and preparing for v9)

Fri, 08 May 2026 00:41:42 GMT

Every Android subscription team lives on the same two year clock. The Play Billing Library you shipped with last year is on a deprecation timer, and the Play Console will refuse new uploads the moment the timer runs out. v7 is the next version to hit that wall. After August 31, 2026, you can no longer publish a new app or update built against v7, and v8 has been generally available since June 30, 2025 with significant additions still arriving in v8.1 through v8.3. This guide walks you through the migration end to end, then sets you up for v9.

In this article, you’ll explore the v7 to v8 deprecation timeline and what each date actually means, the full list of removed APIs and their replacements, a step by step migration of the connection, query, and purchase flows, the new behaviors v8 adds that are worth adopting today, what v8.1 through v8.3 layer on top, and how to prepare for v9 before Google publishes a single line of its API surface.

The deprecation timeline that sets your deadline

Google has run a two year deprecation cycle for the Play Billing Library across several major versions. Every major version gets two years of support after release, then the Play Console stops accepting new builds compiled against it. The deprecation FAQ publishes the exact dates:

Library version	Last date for new apps and updates	Extension request deadline
5.x	2024-08-31	2024-11-01
6.x	2025-08-31	2025-11-01
7.x	2026-08-31	2026-11-01
8.x	2027-08-31	2027-11-01

The phrasing in the FAQ is precise and worth reading carefully: “This deprecation prevents only new apps and updates from using older versions of the Play Billing Library. Existing apps that use a deprecated version of the library will continue to function as expected.”

That distinction matters. The deadline is a publishing gate, not a runtime kill switch. Already published v7 binaries keep transacting after August 31, 2026. What stops is your ability to ship a new release. If your app receives any updates at all, including security patches and bug fixes, you need to be on v8 before that gate closes. The extension request deadline of November 1, 2026 is for teams that need to file a formal request through the Play Console to keep shipping v7 builds for a brief additional window. It is not a free extension you receive automatically.

The Play Console signals this through a warning and an inbox message on the Policy status page once your app is on a deprecated version. If your AndroidManifest.xml does not contain the entry named com.google.android.play.billingclient.version, the Play Console cannot detect your library version, and the warning never reaches you. That entry is added automatically by the library, but manifest merging in multi module projects sometimes drops it. Verify it exists in your final merged manifest before you trust the absence of warnings.

What changed in v8: the removals at a glance

v8 removed several APIs that had been deprecated for one or two prior versions. If your code still uses any of these, the v8 upgrade will fail to compile until you replace them.

Removed API	Replacement
`querySkuDetailsAsync()`	`queryProductDetailsAsync(QueryProductDetailsParams, ProductDetailsResponseListener)`
`queryPurchaseHistoryAsync()` (all overloads)	No direct client API. Track history server side.
`enablePendingPurchases()` (no arg)	`enablePendingPurchases(PendingPurchasesParams)`
`queryPurchasesAsync(String skuType, PurchasesResponseListener)`	`queryPurchasesAsync(QueryPurchasesParams, PurchasesResponseListener)`
`BillingClient.Builder.enableAlternativeBilling()`	`enableUserChoiceBilling(UserChoiceBillingListener)`
`AlternativeBillingListener`	`UserChoiceBillingListener`
`AlternativeChoiceDetails`	`UserChoiceDetails`

The signature of ProductDetailsResponseListener.onProductDetailsResponse() also changed. The callback now returns a QueryProductDetailsResult that splits the response into a fetched list and an unfetched list with per product status codes, replacing the older single list signature. Any class that implements this listener has to be updated, even if the rest of its logic is unchanged.

Two terminology changes accompany the API removals. “In app items” are now called “one time products” throughout the documentation and the API surface. The class names themselves did not change, the documentation simply uses the new term, but the rename carries a behavioral implication: one time products in v8 can have multiple purchase options and offers, the same way subscriptions did in v7.

Step 1: Bump the dependency and your minSdk

The first change is the Gradle coordinate. v8.0.0 was the first release in the v8 line, but most teams should target the latest patch in the v8 series instead of pinning to 8.0.0:

The library raised its minSdkVersion to 23 starting at v8.1.0. If your app still supports API 21 or 22, you have two choices: pin to 8.0.0, which keeps the original v7 minSdk of 21, or raise your own minSdk to 23 and adopt the latest v8 patch. The latter is the right call for almost every team, since API 23 was released in 2015 and the device tail below it has been negligible for years. v8.1 is also built against Kotlin 2.2.0, which can affect projects on older Kotlin versions if you consume the billing-ktx artifact, though this is a small jump for any project already on a recent Kotlin Compose stack.

Step 2: Migrate enablePendingPurchases

The no argument enablePendingPurchases() was deprecated in v7 and removed in v8. It used to be a single method that turned on pending purchase support for in app items implicitly. v8 replaces it with a builder that forces you to declare which product categories you want pending support for.

In v7, you had:

In v8, the equivalent call is:

Notice that .enableOneTimeProducts() is not implicit. The deprecated zero argument version was, by Google’s own description, equivalent to a builder with .enableOneTimeProducts() set, so if you do not include this call you will silently lose pending purchase support for one time products. That regression is invisible in unit tests and in most countries with credit card based purchase flows. It surfaces as broken purchases in markets where users pay with cash at convenience stores or with bank transfers, primarily Japan, Germany, Brazil, Mexico, and Indonesia. Add .enableOneTimeProducts() even if you think you do not need it.

If you sell prepaid subscription top ups, also add .enablePrepaidPlans() to the builder. This was added in v7 specifically for prepaid plan pending transactions and carries over into v8 unchanged.

Step 3: Update queryProductDetailsAsync to the new callback shape

queryProductDetailsAsync itself is not removed, but its callback was. The pre v8 listener received a BillingResult and a List<ProductDetails>. The v8 listener receives a BillingResult and a QueryProductDetailsResult that splits products into two lists. Any product that failed to fetch shows up in the unfetched list with its own status code, instead of being silently dropped.

The pre v8 callback looked like this:

The v8 version exposes both the successful fetches and the failures:

The reason this matters is that pre v8, if you queried five products and one of them was misconfigured in the Play Console, the whole call could return successfully with that product silently missing from the list. Your paywall would render four products and you would have no idea the fifth was even attempted. The new shape makes the partial failure explicit. Each unfetched entry carries a status code that tells you whether the product is unavailable in the user’s country, has not yet been published, or hit a transient error.

This is also the moment to rebuild any abstraction layer that wraps queryProductDetailsAsync in a coroutine or flow. The return type of your suspending wrapper has to change from List<ProductDetails> to a sealed class or pair that carries the unfetched information forward. If you have a typealias for the listener type itself, the typealias has to be updated, since the lambda signature is different.

Step 4: Replace the deprecated queryPurchasesAsync overload

v8 removed the overload of queryPurchasesAsync that took a raw SKU type string. The replacement uses a QueryPurchasesParams builder that wraps the same product type with the new typed enum.

Before:

After:

The behavior is identical when invoked correctly. The SkuType constants are gone, replaced by ProductType.SUBS and ProductType.INAPP. If you have a single shared method that accepts a string for the SKU type, refactor it to accept a String that matches the new enum values, or convert it to use BillingClient.ProductType directly.

Step 5: queryPurchaseHistoryAsync has no client side replacement

queryPurchaseHistoryAsync was deprecated in v7 and fully removed in v8. There is no equivalent client API. This is the only v8 removal that does not have a direct one to one replacement, and it tends to surprise teams the most.

Google’s reasoning is straightforward, even if undocumented in the migration page itself: purchase history is not authoritative source of truth on the client. Any history a client builds up can be incomplete, since the device may have been offline during a refund or revocation. The Play Developer API on your server has the authoritative record, and any analytics, audit, or reconciliation flow that depends on knowing past purchases should query it server side instead.

If you previously used queryPurchaseHistoryAsync for one of these reasons, you now have two paths. The first is to call the Play Developer API endpoint purchases.subscriptionsv2.get from your backend whenever you need to inspect a subscription’s full history, including its linkedPurchaseToken chain. The second is to lean on Real Time Developer Notifications and persist the events as they arrive, building your own purchase history table. Most teams already do the latter for analytics and revenue reporting, in which case the v8 removal is a no op.

If you used queryPurchaseHistoryAsync for entitlement restoration on a fresh install or after a reinstall, switch to queryPurchasesAsync with the new params builder. queryPurchasesAsync returns active purchases tied to the current Google account, which is what restoration actually needs. Active purchases is a smaller set than full history, but it is the correct set for entitlement granting. Note that v8 also stops returning consumed one time products and expired subscriptions from queryPurchasesAsync, so configure your one time products as non consumable in the Play Console if you need them to survive a reinstall.

Step 6: Move from alternative billing to user choice billing

v7 already deprecated the enableAlternativeBilling builder method, and v8 removed it entirely. The replacement is enableUserChoiceBilling, which takes a UserChoiceBillingListener instead of an AlternativeBillingListener and exposes a UserChoiceDetails payload instead of AlternativeChoiceDetails.

The functional contract is the same: when the user picks your billing system over Google Play’s at checkout, the listener fires with the purchase details so your backend can complete the transaction outside of Google Play’s payment flow. Only the type names changed. If you carry a per region build flavor where user choice billing is enabled in some regions and disabled in others, the build flavor logic does not need to change, only the type references.

One time products and the multi offer surface

v8 renamed in app items to one time products and gave them the same multi offer capability subscriptions had since v5. A single one time product can now carry multiple purchase options, each with its own price, regional availability, and offers attached. This is the change that motivates the bulk of v8’s surface, and it is also the reason the unfetched product list now exists. With multiple offers per product, the partial failure modes multiplied, and a flat list could no longer represent what happened.

The class names did not change. ProductDetails is still ProductDetails. What changed is the oneTimePurchaseOfferDetails accessor, which can now expose multiple offers and pre-order details starting at v8.1.0. If your paywall renders a single price for an in app item, you are still on the v7 mental model. v8 lets you expose a discounted offer or a regional offer on the same product without creating a duplicate SKU. This is opt in: existing one time products continue to surface a single offer until you configure additional options in the Play Console.

New behaviors worth adopting in v8

Two of v8’s additions are not strictly required but are worth turning on at migration time, since they reduce code you would otherwise carry yourself.

The first is enableAutoServiceReconnection(). The Play Billing service can disconnect for a number of reasons: the user installs an update to Google Play, the device wakes from a long sleep, the system reclaims the bound service. Pre v8, you had to implement onBillingServiceDisconnected() and call startConnection() again with appropriate backoff. v8 ships an opt in builder method that handles this for you:

When auto reconnection is enabled, your onBillingServiceDisconnected() override can be a no op, and the library handles retry with backoff internally. Auto reconnection is opt in rather than the default. If you want to manage connection lifecycle yourself, leave it disabled and continue handling onBillingServiceDisconnected() directly.

The second addition is BillingResult.subResponseCode. Pre v8, the BillingResult returned for purchase failures grouped many cases under BILLING_UNAVAILABLE or ERROR. v8 adds a sub response code on BillingResult that distinguishes specific failure cases:

PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS: the user’s payment method does not have sufficient funds.
USER_INELIGIBLE: the user is not eligible for the offer they tried to redeem, typically because they have already used a one time intro offer.
NO_APPLICABLE_SUB_RESPONSE_CODE: the failure does not map to a more specific sub code.

The ineligibility code is the one you almost certainly want to handle, because it lets you steer the user back to a fallback offer instead of leaving them at a failed purchase screen. The sub code arrives in the BillingResult delivered to your PurchasesUpdatedListener.onPurchasesUpdated callback:

What v8.1, v8.2, and v8.3 add on top

v8 has been moving fast since GA. Three minor releases between November and December 2025 added significant capabilities that are easy to miss if you only read the v8.0 migration guide.

v8.1.0, released November 6, 2025, introduced suspended subscription handling. A subscription enters the suspended state when Google detects abuse or a payment dispute and pauses delivery of entitlements without canceling the subscription. Pre v8.1, suspended subscriptions were invisible to client side queries. v8.1 adds an isSuspended flag on Purchase and a parameter to queryPurchasesAsync to include suspended purchases in the result. The pattern is to filter purchases by isSuspended before granting entitlement, and route suspended ones into a separate UI branch that explains the hold to the user:

v8.1 also reworks subscription replacement. The old SubscriptionUpdateParams.setSubscriptionReplacementMode() is now deprecated in favor of SubscriptionProductReplacementParams set on the per product builder. The new shape supports a KEEP_EXISTING replacement mode that lets you upsell a second subscription on the same account without canceling the existing one, which is useful for bundled offerings.

v8.2.0 and v8.2.1, released in December 2025, generalize what used to be the External Offers Program into a broader Billing Program surface. The old methods (enableExternalOffer, isExternalOfferAvailableAsync, createExternalOfferReportingDetailsAsync, showExternalOfferInformationDialog) are deprecated and replaced by enableBillingProgram(int), isBillingProgramAvailableAsync, createBillingProgramReportingDetailsAsync, and launchExternalLink. v8.3.0, shipped December 23, 2025, adds the developer provided billing flow on top, with BillingProgram.EXTERNAL_PAYMENTS, EnableBillingProgramParams, and DeveloperBillingOptionParams. This consolidation is Google’s response to the regulatory pressure that emerged from the Epic Games ruling and similar requirements in other jurisdictions, where Google is required to support developer provided billing and out of app payment links.

If your app uses the External Offers Program today, the deprecation is a clear signal to start migrating. The methods still work in v8.2 and v8.3, but they will likely be removed in v9. Migrating to the Billing Program surface now is a one time cost that buys you out of a forced migration later.

Preparing for v9 before its API surface exists

At the moment, the release notes top out at v8.3.0. The deprecation FAQ does not list a v9 row. There is no public alpha, beta, or release candidate. So how do you prepare?

By understanding the cadence and the direction of change. Google has shipped a new major version of the Play Billing Library roughly once a year, with v7 released in May 2024 and v8 reaching GA on June 30, 2025. On that pattern, v9 is expected to land in mid 2027, lining up with the v8 sunset deadline of August 31, 2027.

The direction of change is also predictable from the rapid v8.1 through v8.3 releases. Google is consolidating the external billing surface (External Offers Program, user choice billing, developer provided billing) into a unified Billing Programs API. v9 is likely to remove the deprecated External Offers methods, formalize the Billing Programs surface, and possibly extend it further to handle additional regulatory regimes.

Three things you can do today to be ready:

Opt in early: adopt every opt in API v8 ships, including enableAutoServiceReconnection() and the new SubscriptionProductReplacementParams. The opt in surface in one major version is the default surface in the next.
Migrate off External Offers: the Billing Programs surface in v8.2 and v8.3 is the forward path, and it gives you a non breaking migration window before v9 forces it.
Move history server side: v8 removed queryPurchaseHistoryAsync for a reason, and v9 will not reintroduce it. Build your purchase audit trail server side from RTDN events and the Play Developer API.

If you do these three things in your v8 migration, the v9 migration in mid 2027 becomes incremental rather than disruptive.

How RevenueCat absorbs the v7 to v8 transition

The recurring nature of Play Billing Library migrations is the kind of work that taxes a small team disproportionately. Every two years, someone has to read the migration guide, refactor the connection layer, retest pending purchases in cash payment markets, audit the queryPurchaseHistoryAsync removal, and verify that no listener signature change broke a downstream module. The work is rarely interesting, and it always lands on the team that least wants to do it.

RevenueCat absorbs this migration on your behalf. The RevenueCat Android SDK 9.x ships with Play Billing Library 8 already integrated, and the SDK API surface most apps interact with did not change between RC SDK 8.x and 9.x. The only meaningful changes for app code are a Kotlin minimum of 1.8.0 and the removal of data class modifiers from a handful of public types, which means copy() and component destructuring no longer work on those types. equals() and hashCode() are preserved. The migration path is documented in the RevenueCat 8.x to 9.x Android migration guide, and the rationale and feature set are walked through in the Play Billing Library 8 support in Purchases SDK v9.0.0 engineering post.

The practical implication is that the v7 to v8 migration steps in this article reduce to: bump your RevenueCat SDK from 8.x to 9.x, bump your Kotlin to 1.8 or later, replace any copy() or destructuring on the affected RC types with explicit constructors, and verify your one time products are configured as non consumables in the RevenueCat dashboard (since v8 cannot query consumed one time products). That is the entire migration. The v8 specific work, including the new PendingPurchasesParams builder, the queryProductDetailsAsync callback shape, the queryPurchasesAsync overload swap, the user choice billing rename, and the unfetched product handling, is already done inside the SDK.

The same property holds for v9. When v9 ships, RevenueCat will release a new SDK that integrates it, and your app code moves forward with the same pattern: bump the SDK, possibly bump your Kotlin or minSdk, and run your test suite. The recurring Play Billing Library migration stops being something your team has to schedule.

Conclusion

In this article, you’ve explored the full v7 to v8 migration: the deprecation timeline that sets your August 31, 2026 deadline, the removed APIs and their replacements, the six concrete migration steps from Gradle bump through user choice billing, the new behaviors v8 ships with enableAutoServiceReconnection and BillingResult.subResponseCode, the three minor releases that added suspended subscriptions and the unified Billing Programs surface, and a pattern based read on what v9 will likely require.

Understanding the structural reasons behind each removal helps you make better decisions during the migration itself. queryPurchaseHistoryAsync is gone because purchase history was never authoritative on the client. The new enablePendingPurchases builder is explicit because the implicit version silently regressed cash payment flows in some markets. The unfetched product list exists because partial failures had to become visible once one time products gained multiple offers. Each change reflects a problem the prior surface failed to handle, and the v9 changes will follow the same logic.

Whether you’re migrating to v8 this quarter, planning the v9 transition for 2027, or evaluating whether to outsource billing infrastructure to a platform like RevenueCat, this foundation lets you ship Android subscriptions without losing weeks every two years to a forced upgrade. For the official source material, refer to Google’s migrating to Play Billing Library 8 page, the deprecation FAQ, and the release notes.

Meet Rico: Your tireless app growth advisor

Wed, 06 May 2026 16:35:37 GMT

You’ve got the charts. You’ve got the cohorts. You’ve got the experiment results. But somewhere between the data and your next decision, there’s a question you’re not sure how to answer.

Meet Rico, RevenueCat’s app growth advisor built directly into your RevenueCat dashboard and available in Slack. Ask why conversions dropped, which experiment to run, or how your churn rate compares to similar apps. Rico turns your RevenueCat data into your next move.

An advisor, not a search bar

Rico is an embedded domain expert with access to your RevenueCat data, the App Store and Google Play Billing Library documentation, and the industry-wide State of Subscription Apps (SOSA) benchmarks.

Not only can you ask Rico straightforward questions like “show me MRR by country” or “compare this month’s performance vs last month,” you can ask Rico real, business-outcome questions:

“Where am I leaving money on the table in the trial-to-paid flow?”
“Based on the A/B test, should we do a 0 vs 7-day trial next?”
“What is the average conversion to paying for a fitness app?”

What Rico can do for you

Rico’s capabilities span across data analysis, technical debugging, and growth strategy. Here is what your new advisor can do:

Diagnose revenue and retention

“Why did MRR drop in Germany last week?”

Rico can pull your overview metrics, fetch chart data with complex filters, and compare periods to spot anomalies. If revenue drops, Rico can surface exactly which cohort, country, or product is driving the change.

Review product and entitlement setups

“Is my annual product configured correctly in the App Store?”

App Store and Google Play configurations are notoriously easy to get wrong. Rico can review your products, entitlements, offerings, and packages to verify that everything is attached correctly and properly configured in the stores.

Analyze experiments and strategy

“Based on the A/B test, should we do a 0 vs 7-day trial next?”

Rico lists your A/B test results and helps you interpret the winners and losers. It can provide paywall and pricing strategy recommendations, trial optimization advice, and retention analysis.

Benchmark against the industry

“How does my app’s trial conversion compare to similar apps in my category?”

Rico has a dedicated benchmarks tool that compares your project’s actual metrics against industry peers. Ask how your trial conversion, churn rate, or MRR growth stacks up against apps in your category. Rico surfaces where you’re ahead, where you’re behind, and what to test next, using data from the SOSA reports.

Deep-dive into customers

“Look up user abc123: they say they paid but don’t have access.”

When a user writes in with a billing issue, give Rico their app user ID. Rico pulls their full profile: active entitlements, subscription status, purchase history, and any custom attributes your app has set.

Then Rico tells you what it sees. Is the subscription in billing retry? Did they cancel but still have access? Have they been refunded before? Are they enrolled in an experiment that might explain unexpected behavior? For most support tickets, that’s enough to diagnose the issue and respond with confidence.

Research documentation and SDKs

“How do I implement a custom paywall in React Native?”

Rico has full access to the RevenueCat docs and all open-source SDK repositories across iOS, Android, Flutter, React Native, Unity, KMP, and JS. Ask about an implementation detail and Rico finds the exact code snippet or proven approach. Ask about a recent SDK release and Rico pulls the changelog. If something seems broken, Rico can check the live status of RevenueCat’s API.

Learn from the best in the industry

“What do high-retention apps do differently in their first 30 days?”

Rico can search the RevenueCat blog and pull insights from the SubClub podcast. Hundreds of conversations with the founders and operators who have built the most successful subscription apps. Ask Rico what high-retention apps do differently, how apps in your category structure their trial strategy, or what operators have figured out about reducing involuntary churn.

Project and team management

“Who changed the annual product entitlement yesterday?”

Rico can list your apps, API keys, and collaborators, and pull your project’s audit log. Every entry records who made a change, what they changed, and when. That covers everything from product and entitlement config to experiment activity, webhook updates, and collaborator role changes.

Feature adoption audit

“Which RevenueCat features am I not using that I should be?”

Ask Rico to run a feature adoption audit on your project. It checks every RevenueCat feature against your actual usage data and returns three things: what you’re actively using, what’s gone dormant, and what you’ve never tried.

Rico might flag that your Refund Handling integration stopped flowing data three months ago, meaning Apple has been approving refunds without your input. Or it might notice you’re running Customer Center but haven’t enabled the Retention Messaging API, which gives you a second chance to retain users when they try to cancel in the App Store.

App and competitor research

“What’s Duolingo’s monetization strategy?”

Give Rico any app’s bundle ID or package name and it will pull the App Store and Google Play metadata side by side. Ratings, pricing, category, IAP structure, localization breadth, release cadence, the full picture.

Ask Rico to look up a competitor and it will flag what their monetization strategy tells you: whether they’re running a trial-led conversion model, how their content scope affects willingness to pay, what their rating trajectory suggests about product-market fit.

Rico in Slack

Most revenue questions start in Slack. Someone posts a screenshot and asks, “Anyone know why this dropped?” Then everyone waits for the one person who knows how to pull the number.

With the Slack integration, you can now tag @Rico in any channel with a question. The answer lands in the thread: the data, the context, and what to do next. Visible to everyone in the conversation.

To connect Rico to your Slack workspace, go to Account Settings in the RevenueCat dashboard, open the Rico tab, and click Connect to authorize the integration.

Try Rico today

Rico is available in public beta.

Head to your RevenueCat dashboard and ask for a health check. Tell Rico to run a feature adoption audit, or ask: “What’s the biggest bottleneck to my revenue growth right now?”

Open the dashboard or add Rico to Slack. Ask your first question.

Build a paywall by describing what you want

Wed, 06 May 2026 13:49:08 GMT

At the RevenueCat World Paywall Speed Building Championships 2025, the winner built a complete, production-ready paywall in 3 minutes and 16 seconds. It was an incredible feat of human engineering and drag-and-drop mastery.

You can now make that record completely obsolete.

You know you need to test your paywalls. The difference between a mediocre paywall and a great one is often the difference between a struggling app and a thriving subscription business.

But for anyone who isn’t a speed-building champion, the reality is different. Creating a paywall that looks good, handles every edge case, and is ready to publish requires design skills and engineering time you don’t have. Iterating on it takes even longer.

The result is a “good enough” paywall that never gets tested.

RevenueCat’s Paywalls AI Editor changes this. It’s a conversational paywall agent that lets you generate a production-ready paywall from a text prompt in seconds.

From drag-and-drop to done-in-seconds

You can edit any aspect of your paywall using natural language. Type “make the annual plan more prominent” or “use a darker color palette.” Every change streams live in the preview.

RevenueCat Paywalls AI Editor handles the entire paywall creation process from end to end. Whether you’re starting from a blank canvas or adapting an existing template, the AI Editor gives you complete control over every layer of your paywall.

Copywriting and conversion

Great paywalls live and die on their copy. You can ask the builder to rewrite your headlines, subheads, and CTA text to match your brand voice. Personalize the copy using custom variables like {{ custom.first_name }} or rewrite pricing language with variables like {{ product.price }} and {{ product.relative_discount }}. Clean up awkward copy, fix mismatched monthly and yearly labels, and rebalance plan emphasis, for example, changing the default selected plan, updating badge wording, or anchoring users toward the annual option.

Visual design and layout

You control the entire visual mood through natural language. Ask the builder to restyle your colors, adjust spacing, update typography, or fix contrast issues. Add or refine your layout for light and dark modes separately, for example, a white background with dark text in light mode and a deep navy with a glowing CTA in dark mode. Generate and swap imagery for your hero sections and backgrounds to better match your brand on the fly.

Components and structure

Building a paywall means assembling the right pieces. The AI Editor drops in whatever you need on command. You can add headers, feature lists, testimonials, comparison tables, timelines, carousels, and package groups. Remove, duplicate, reorder, or move any existing section, for example, pulling a testimonial block above the pricing cards to build trust before the ask. Ensure compliance by adding sticky footers and updating your Terms and Privacy URLs.

Localization

Scaling your app means translating your paywall. The AI Editor adds localizations directly to your layout and updates translated copy across every component. Fine-tune individual localized strings, for example, shortening a German CTA that overflows its button and test how different languages affect your layout before you push the changes live.

Pre-launch auditing

Before you ship, the builder acts as a second set of eyes. Ask it to audit your paywall for common conversion killers. It flags issues like a low-contrast CTA button, a pricing card that clips on iPhone SE, a missing restore purchases link, or an annual plan that looks identical to the monthly one. Get a list of fixes you can apply instantly with a single follow-up prompt.

Try the AI Editor today

The RevenueCat Paywalls AI Editor is available in public beta.

Log into your dashboard, click “Create paywall,” and select “Generate with AI”. Describe what you want to build. Try to beat 3 minutes and 16 seconds. We think you will.

The Hail Mary pitch that launched a #1 App Store hit

Wed, 06 May 2026 13:16:16 GMT

The Hail Mary pitch

Bria Sullivan had already found success with her game Boba Story, but she wanted to experiment with monetizing a creator’s audience through an app. After a chance dinner meeting with YouTuber Hank Green, she secured a pitch meeting. The goal was to build something for one of his educational channels, Crash Course.

The meeting didn’t go well. The team wasn’t interested, and the answer was a polite “no.” But as the call was wrapping up, Bria threw out one last idea: “What about a Focus Timer, a Crash Course focus timer?”

That single question changed the trajectory of the project. While the Crash Course team still passed, Hank Green himself loved the concept. An hour later, he texted her to say he couldn’t stop thinking about it. They decided to partner up and build it specifically for his core audience—the “Nerdfighters.” It was a reminder that sometimes the best opportunities come from simply putting yourself in the room and refusing to let the meeting end on a rejection.

Live-streaming user research on TikTok

Rather than building in a vacuum, Bria used her existing TikTok audience to validate the app’s design in real time. During long live streams, she would draw different art styles, show color palettes, and ask her viewers directly what they preferred.

She presented six different variations of the app’s central character—a “bean”—and let the audience guide the direction. “When it comes to female audiences too and anything gamified, the look and feel matters so much for organic reach,” she explains. “It’s like what’s going to make someone convert, and the way something looks is a huge reason why people convert.”

This public validation ensured that by the time the app was ready, it already matched the exact aesthetic preferences of its target users. The original, lo-fi “Bee and Puppycat” style she initially favored was scrapped entirely based on this immediate, unfiltered feedback.

The backlash of monetizing a fanbase

Partnering with a massive creator solves the distribution problem, but it introduces a unique set of challenges. When Focus Friend quietly launched via a YouTube community post, the initial reaction wasn’t purely celebratory.

Despite getting 20,000 downloads in the first week, Bria was flooded with angry emails and negative reviews. Users were upset that the app used a subscription model instead of a lifetime unlock, and they were highly sensitive to standard app practices like ad tracking. Because the app was tied to Hank Green—a beloved public figure known for his philanthropy—users felt a personal betrayal that they wouldn’t feel toward a faceless corporation.

“I learned that,” Bria says. “Every app on your phone uses those things, but for some reason he’s not allowed to.” To protect Hank’s reputation and maintain trust, they made the difficult decision to strip out advertising tracking IDs entirely. It was a move that essentially killed their ability to do paid user acquisition, but it preserved the core relationship with the audience.

Why creators make terrible product managers

Bria’s experience with Focus Friend taught her a crucial lesson about creator partnerships: influencers rarely know what makes a good standalone app.

“I don’t think that influencers really know what a good idea is for them to do for their audience,” she observes. “They always, for some reason, they always want a social media or they want a feed of information. And I’m just like, no, I just don’t think that those are good ideas for apps personally.”

Her advice to developers looking to partner with creators is to act as the product manager. Creators understand their audience’s content preferences, but developers understand utility. The most successful collaborations happen when the developer steers the product toward a clear, functional use case—like a focus timer—rather than trying to build another content feed.

In the full episode, Bria also talks about her journey from learning Android development in 2010 to winning an App Store Award, the reality of being a solo developer while raising a newborn, and why she believes product instinct is far more valuable than pure engineering skill.

Guest links:

AI-generated ads: balancing attention and trust in user-generated content

Wed, 06 May 2026 13:02:26 GMT

User-generated videos are no longer exclusively user generated.

With the rise of AI, advertisers can now generate creator-style ads in a matter of hours using synthetic avatars, automated voiceovers, and video tools. What used to require weeks of coordination and creator involvement can now be executed in an afternoon.

This shift is not just technological, it reflects a deeper change in how advertising operates — the pace of modern platforms has outgrown traditional content production.

But this raises a fundamental question. If content no longer needs to be created by real people to perform, what actually drives trust, and where does artificial intelligence start to break it?

Based on what we’ve tested at Mojo, the answer is more nuanced than the current hype suggests. But there’s a few key learnings:

Replication beats interpretation
The cost of failure has collapsed
AI knows what looks real, but humans know what feels real
You are no longer building an ad; you are building a system

The real driver: ad fatigue

The rise of AI-generated ads is not driven by novelty alone. While it is undeniably fueled by the fact that technology has finally crossed a critical threshold of fidelity, the primary catalyst for its adoption is a structural constraint: ad fatigue

On platforms like TikTok and Meta, videos are consumed at a relentless pace. A highly-effective ad can lose its impact within days. For subscription-based products, this rapid decay directly increases the cost of acquiring a new customer.

Today, those stakes couldn’t be higher — with RevenueCat data showing the top 25% of subscription apps grew 80% year-over-year in 2026, while the bottom 25% shrank by 33%. In a winner-take-more market, efficient acquisition isn’t just about optimization, it’s about your app surviving at all.

The natural response is to produce more videos. But this is where the traditional system breaks:standard production is slow and requires a lot of resources. Even highly efficient teams operate on multi-week cycles. Meanwhile, the algorithms shift in real time.

This creates a fundamental mismatch: the algorithm evolves faster than your production process. AI removes that constraint. Instead of asking what the next ad should be, teams can now ask how many variations they can test today. The primary advantage of AI is not that it produces better ads. It’s that it allows you to discover better ads faster.

Case study: Scaling the Mojo ‘Auto Edit’ winner

At Mojo, one of our highest-performing ads was a simple 30-second split-screen video featuring a speaker explaining the product on top and a screen recording of the app on the bottom. This video converted trial users to paid at 23%.

The secret was the person. Our creator was our Product Manager. When he explained the product, he was walking through something he deeply understood. His conviction came from ownership. That kind of authenticity is extremely difficult to synthesize from scratch.

Baseline: Our top-performing human UGC. Notice the genuine conviction of our PM talking about the feature he built.

Phase 1: why replication outperformed native creators

To scale this ad internationally, we initially recruited local creators in several countries to recreate the video. The result was disappointing — despite strong production quality, performance dropped across markets.

The issue came down to execution: each creator interpreted the script slightly differently. Pauses were shortened, pacing changed, and gestures were misaligned. Individually, these differences seemed minor, but collectively, they killed performance.

There was also a constraint regarding legal rights. We often did not have the rights to extend a creator’s content into other languages. This highlighted a critical point: the best-performing creator is the one you actually own.

So we changed strategy. Instead of adapting the ad, we replicated it: we used video translation tools like HeyGen to dub the original video, while strictly preserving the timing, the pauses, the gestures, and the exact energy. In Brazil, the dubbed version achieved a 40% lower acquisition cost compared to native creators.

The lesson here is that execution mechanics matter just as much as the message. AI does not reinterpret; it preserves.

AI Dubbing: 95% perfect lip-sync preserving our PM’s original high energy.

Phase 2: AI avatars (the 80% failure rate)

Encouraged by these results, we moved to fully AI-generated avatars. We expected the speed of production to compensate for a slight dip in quality. Instead, the outcome was binary: most of the profiles we tested failed almost immediately.

The generic avatars we initially generated did not work, and the reasons went beyond mere technical fidelity.

First, we encountered a fundamental perspective and staging issue. As you can see in the variations above, the avatars were placed in hyper-polished environments — studio microphones, cinematic lighting, and stylized backgrounds. Some were even positioned at slight three-quarter angles rather than looking directly into the lens. This immediately broke the native, informal visual code of UGC. The user’s brain categorized the content as a commercial within the first second.

Second, there was a major casting issue. The avatars simply did not match our Product Manager’s original profile or conversational energy. We were trying to scale a specific type of raw, founder-led credibility, but we were using avatars that looked like generic stock models or polished influencers. The disconnect between the message and the messenger was jarring.

These flaws, combined with the expected rigid expressions, caused rapid drop-offs. One avatar had a mere 0.2-second lip-sync delay on a key word, which resulted in a 68% drop in click-through rate compared to the human baseline. Users couldn’t articulate why they did not trust it, but the data was brutal.

But one avatar worked.

Instead of using a generic, polished profile, we used HeyGen to create a custom digital twin based strictly on our original Product Manager. We stripped away the studio mics and cinematic lighting. We matched his raw facecam perspective, his specific look, and his exact baseline energy.

Because the source material already had natural presence and inherent credibility, the output felt believable. That version reached 87% of the original human conversion rate.

The economics changed dramatically:

Traditional creator: $500
Generating the custom AI avatar: $20

RESULT: 31% lower cost per acquisition.

The $20 Winner: Natural head tilts and accurate micro-expressions driving a 31% lower CPA.

Phase 3: the double AI stack

Once we identified a winning creative, we introduced a two-step process: generating the base video using the custom avatar, then instantly translating it into multiple new languages using ElevenLabs for localized, natural-sounding voice cloning.

The results (Brazil localized metrics):

CPA: $8 (31% lower than the human control)
CTR: 4.5%
Conversion Rate: 3.1%
ROAS: 2.1x

The cultural limit: This ‘double layer’ stack (a synthetic avatar that is then dubbed into another language) worked flawlessly in Brazil and Spanish-speaking markets, where users are highly receptive to direct-response UGC formats. However, when we pushed this exact same dubbed avatar to Europe (France, Germany), it failed. The European audience was far more sensitive to the uncanny valley, and the double layer of AI broke their trust.

This highlighted to us that sensitivity to artificial media is not just technical. It is geographic and culturally dependent. You can’t assume universal adoption.

Key takeaways: how AI-generated UGC impacts ad performance and trust

Ads are our business, so we had the luxury of being able to test AI-generated ads and finesse the output. Many apps won’t be able to take this same risk and time, so here’s my top learnings from our creative experiments with AI user-generated content.

Why natural execution beats polished authenticity

There is a common assumption that videos made by users perform well because they’re authentic. In practice, authenticity is only part of the story. These videos work because — even when users are following a script — they feel natural.

The best-performing ads rely on familiar patterns like direct-to-camera delivery, informal conversational tones, and simple visuals. AI is highly effective at replicating these patterns. By mimicking the structure of successful content, AI-generated ads can improve early metrics like views and watch time.

Balancing algorithmic attention vs. user trust

One of the most important insights from our experiments is that these ads operate across two distinct layers:

The algorithm rewards attention
The user decides based on trust

AI helps you win the first, but it doesn’t guarantee the second.

In our tests, fully synthetic avatars struggled in formats that rely on credibility, especially testimonials or personal stories. People are sensitive to anything that feels artificial in emotional contexts. We subconsciously scan for micro-expressions, subtle changes in eye contact, and the natural hesitation that signals genuine human experience. When an algorithm tries to simulate a heartfelt story, it misses these imperceptible cues. The result is a subconscious rejection by the viewer.

Conversely, AI thrives in structured, utility-driven formats. For product demonstrations, tutorials, and feature breakdowns, clarity and pacing matter far more than emotional authenticity. The rule is simple: use AI to explain, and use humans to convince. This principle was at the heart of our strategy when we decided to scale our own top-performing content at Mojo.

The economics of failing fast

The real advantage of AI was not just cost. It was speed.

With traditional methods, creative testing five human creators takes $2,500 and three weeks of production to find one potential winner. Testing five AI variations takes $100 and just two hours.

The downside of testing creatives has collapsed. You’re no longer optimizing for perfect execution upfront, you’re optimizing for iteration speed. You are no longer buying videos, you’re buying iterations — and iteration compounds.

From production to decision-making

Before, production was the bottleneck. Now, production is instant. But a new bottleneck emerges: decision-making.

When you only have five videos a month, you can rely on intuition. When you can generate 50 variations a day, intuition fails. Teams no longer need to figure out how to produce content. They need to figure out what to test and what to cut.

AI did not remove the need for creativity. It made taste and data analysis the new competitive advantages. Bad decisions now scale just as fast as good ones.

The hidden risks

Like any new approach to ad creatives, there are payoffs you have to consider:

We’re already seeing a specific aesthetic emerge among AI-generated ads: perfect lighting, lack of breathing pauses, and synthetic enthusiasm. If every brand starts using similar avatars, these videos will become the new fatigued format. Ad fatigue won’t disappear; it just shifts from the individual video to the format itself.

Navigating the legal maze

There’s also a significant legal challenge. Building your acquisition engine on a digital copy of a real person is a liability maze. Who owns the likeness if that employee leaves the company?

With external creators, the problem is worse. If you don’t secure rights to use their digital likeness, you’re essentially renting your growth. Owned content scales, rented content does not. Brands need to rethink their talent contracts entirely. You need specific likeness agreements that outline exactly how, where, and for how long a synthetic avatar can be used, including clauses that allow the company to run the digital copy for six to twelve months after an employee departs.

Audience backlash and reputational risk

The risk of audience backlash is a reality that cannot be ignored. Audiences are becoming increasingly sophisticated at identifying synthetic media, and for subscription-based apps, the stakes are uniquely high. Because the business model relies on an ongoing relationship, being perceived as using deceptive or low-quality AI creative at volume can be devastating.

It creates what is essentially a ‘trust tax’, if a user feels tricked by an advertisement, they might install the app, but will inevitably churn. It doesn’t just hurt immediate acquisition; it erodes the fundamental trust that drives long-term retention. Every app audience is different, so it’s vital to consider your specific consumer group’s sentiment. The challenge for brands moving forward is finding the balance between being transparent, efficient, and maintaining a sincere human connection.

Best practices for scaling AI-generated ads

Before you generate new AI content, you need to answer a few fundamental questions:

Do you own the source material and likeness rights?
Is the format utility-driven rather than an emotional story?
Can you kill the campaign in 24 hours if the data shows it is failing?
Have you tested your specific market’s tolerance for synthetic media?

Most importantly, you have to break the perfection. Perfect delivery feels like a commercial. Here’s what we’ve found works:

Lower the resolution slightly so it does not look like a studio shoot
Let the audio retain a bit of background room tone.

Artificial intelligence naturally gravitates toward a flawless output, so you have to actively force it to be messy.

Checklist: when to use AI or real users for ads

If you’re deciding between a human creator and a synthetic avatar, use this quick reference guide based on our testing:

Opt for AI-generated ads when:

The goal is utility: product walkthroughs, feature demos, or screen-recording tutorials
You need scale: testing 10+ hook variations or localizing an ad into five different languages
Speed is critical: you need to respond to a creative trend within 24 hours
Cost is the bottleneck: you have a winning script but a limited budget for multiple creators

Opt for real humans when:

The goal is trust: personal testimonials, ‘storytime’ formats, or founder-led brand intros
Emotional nuance is key: content that requires subtle micro-expressions or genuine empathy
High-value markets: targeting regions (like Europe) with high sensitivity to ‘uncanny valley’ media
Originality: creating the source material that will eventually be replicated by AI

The new UGC

We’re entering an era of infinite content where the true bottleneck is no longer creation, but judgment. While the technological barrier to generating an ad has effectively dropped to zero, the psychological barrier to earning consumer trust has never been higher.

Algorithms are exceptionally good at replicating familiar patterns to buy attention, compress feedback loops, and scale distribution. What they cannot do, however, is synthesize genuine conviction. The top growth teams of the future won’t merely be those who test the fastest. Instead, they will be the ones who understand exactly when to automate a system for efficiency, and when to rely on a real human heartbeat for persuasion.Ultimately, AI didn’t make advertising smarter — it simply revealed the clear boundary between what machines can execute and what they cannot. Speed and automation will always buy you attention, but it takes a human to earn trust.

The post-purchase screen: how to stop Day 0 cancellations

Tue, 05 May 2026 10:21:34 GMT

There are a lot of things that keep me up at night: my ADHD medication, whether I locked the back door, my dog trying to get on the bed… and these trial cancellation numbers. Yep, stats like these are enough to steal my Zs (and now they’re about to do the same to you, sorry in advance).

A staggering 55.4% of 3-day trials are cancelled on Day 0. Ouch.

That’s over half gone before they’ve even had a chance to use what they signed up for. Talk about not giving an app a fair shot. So what’s happening, and how can apps combat it?

Whilst the number does drop a bit with longer trials, even with a 30-day trial nearly a third of users cancel on the very first day. Combine Day 0 and Day 1, and you’re looking at 84% of 3-day trial cancellations happening in that first 24 hours. For 7-day trials, it’s still 64%.

% of trial cancellations, by day and trial duration — State of Subscription Apps 2026

Do you see why those numbers keep me up at night?

And it’s not just trials, even annual subscriptions see almost 35% of cancellations within the first month.

Cancellation timeline for annual subscriptions — State of Subscription Apps 2026

Why 55% of free trials cancel on day zero

This data from the State of Subscription Apps Report 2026 really surprised me. Users are churning fast, losing faith in the app from the outset, feeling disappointed. It’s like your date slipping out after the first drink. You’re left wondering… how did it go so wrong so fast?

The first place we tend to look is onboarding. While I’ve seen plenty of wins from improving onboarding and paywalls, it’s not enough. These early cancellations show a clear pattern: people want to try your product. They hand over their payment details, click subscribe… and then something goes wrong immediately after.

Most advice on reducing early cancellations focuses on the in-app experience, pre-trial onboarding or improving your lifecycle marketing. All this is important, but there’s one step almost nobody talks about: the post-subscription screen. The very thing your users see the moment after they convert.

Introducing app aftercare: aka, the post-purchase screen

I first realized this when I interviewed Rosie Hoggmascall, Head of Product & UX at Fyxer.ai, on her approach to paywalls. She emphasized thinking about what happens after purchase, and it stuck with me. I call it aftercare, because that’s exactly what most apps are missing: care.

Think about it like this: you walk into a shop, buy something, and the minute your transaction goes through, the salesperson turns away. No “Great choice!”, no bag, no receipt, no guidance on how it works. Just… nothing. You’d feel weirdly used. Embarrassed. Probably just awkwardly standing there wondering, “Now what?”.

That’s exactly what most apps do.

I walked through a ton of post-purchase screens to see how different apps handle this moment. (Confession: I didn’t spend hundreds of pounds on subscriptions. I have to be very strict on my app subscriptions, given how many I test. So I used Mobbin for examples, though I did peek at some in the wild too.) What I found was a spectrum: some apps completely miss the moment, and some absolutely nail it.

6 Levels of post-purchase screen optimization

Here’s how to level up your post-purchase screen, step by step. I see six levels of post-purchase screens:

The basic version: straight into the app
A clear confirmation screen
Celebrate the moment
Remind them what they are getting
Highlight what you’ll help them achieve
Give them one clear next step

Each is slightly better than the last, and more in tune with what the user needs.

Now, I will say that as much as I love a neat little framework, some apps I reviewed broke the mould, choosing to use the post-purchase moment to push users to sign up for an account or pursue an upsell. That also works in certain scenarios, so I’ll cover when to go with those approaches as well.

I’ve also made a Mobbin board with 13 examples of different app onboarding-to-post-purchase screen journeys. Check it out here.

Level 1: the default straight-into-app version

The most common approach is to rely on Apple’s default “You’re all set” confirmation, then dump users straight into the app. That’s it. No intermediate screen, no acknowledgement of what just happened, no guidance on what to do next.

Take Zero, a weightloss and metabolic health app. You subscribe, get the standard Apple pop-up, and then you’re deposited straight into the app. What next?

MasterClass, the online learning platform, does the same. You could argue it makes sense — MasterClass has a massive library, and users potentially already know what they want to watch or were attracted by a specific expert to subscribe. But even here, a little extra care would go a long way. If someone clicks through that confirmation screen too quickly (and they will), they might not even register what they just signed up for — or how much they’re paying.

It’s the same as the store example I shared earlier: no acknowledgement, no guidance, just an abrupt ending.

Level 2: a clear confirmation screen

Level two is a simple but meaningful upgrade — after the standard Apple confirmation, add your own screen that acknowledges what just happened.

Pillow Talk, an AI journaling app, does this really well. It welcomes you to Pillow Talk Plus, confirms that everything in the plan is now yours — the insights, the support, the space to process — and then guides you straight into the app.

It doesn’t list every feature exhaustively, but it gives a reassuring tick that you made the right choice. It also helps clarify that your subscription went through, in case you clicked past the Apple pop-up too quickly (as I tend to do).

Lifesum, a calorie-counter and meal-planning app, takes a similar approach: “Your journey has begun”. Simple, warm, and focused on the outcome rather than the features. That small moment matters more than you might think, especially for someone on a trial who could still talk themselves out of it.

That little moment of “You made the right choice, here’s what’s ahead” can do a lot of heavy lifting. It’s the same as a salesperson in a store saying, “All set — enjoy!”

You can take it even further by reminding users of their original reason for signing up (their Job to be Done) to reassure them and reinforce why they’re here. It’s such a simple screen, and not a huge effort to implement, which is why I think this should be the minimum standard for any app.

Level 3: celebrate the moment

Now we can do even better. Be the store employee who doesn’t just say, “You’re all set,” but adds a little enthusiasm: “I have that shirt too” or “Those shorts have been so popular, I love them”. The tiny extra phrase that makes you feel good about your purchase (and less guilty about spending money when you swore off clothes shopping for the month… ahem, not talking about me here).

In-app, you can take the same approach: make the post-purchase screen feel like a genuine celebration. Not cringe or over-the-top, but a moment that acknowledges they made a good decision, and this is something worth celebrating.

This is what Duolingo does. When I first explored this topic with Rosie, she mentioned their celebratory animation, which quickly makes you feel good about the decision you just made.

I mean, we rarely see that owl so happy — it’s nice to see.

Animations are a great way to spark that energy. Take Kitchen Stories, a recipe app: their fun confetti screen welcomes you with, “You can now start using Kitchen Stories Plus!” It could be a bit clearer about exactly what’s included in Plus, but the moment of celebration is there, and it works. (And there is confetti, who doesn’t love a bit of confetti.)

Level 4: remind them what they’re actually getting

Here’s something app teams do too quickly: assuming users remember what’s included in the plan they just upgraded to. Spoiler: they don’t. Especially on a trial, where part of the decision might have been, “Well, I can always cancel”.

It’s like making a big order at a restaurant; it’s nice when the waiter repeats it back to you, reassuring you they’ve captured your order. The same applies here. Especially if the upgrade came through a feature-specific paywall, users might not even know all the premium features they now have access to.

Use the post-purchase screen to remind the user of their purchase. It provides clarity, removes nerves, and also reminds them of all the great features now available.

AllTrails, the hike, bike, and run app, does this really well for their Peak subscription. First, there’s a simple animation welcoming you. Then, after suggesting push notifications, they clearly list everything included in the plan.

For users who were previously on Plus, they even reassure you that you’re still getting all the Plus features too.

That prompt to enable push notifications, with a clear explanation like “We’ll remind you before your trial ends”, is also a clever way to tackle Day 0 cancellations. It’s a double win: you get permission to send notifications, and the user feels less anxious about forgetting to cancel if they want to — preventing the pre-emptive trial cancellation.

This point about notifications is worth dwelling on. You can promise users reminders upfront, but if they haven’t enabled notifications yet, that promise doesn’t land. The post-purchase screen is the perfect moment to set this up, in context, when the reason is obvious, and the value is immediate.

Level 5: highlight what you’ll help them achieve

Beside, an AI receptionist app does this particularly well. It congratulates you on starting your trial, then immediately reminds you of the outcome you’re here for: your clients will get instant answers, and you’ll get time back.

It also backs that up with three concrete stats:

100% of business calls answered
80% of inquiries handled automatically
30% more bookings

You haven’t even opened the app properly yet, and you’re already thinking about results, instead of fighting buyer’s remorse and wondering whether to cancel.

Headway, the bitesized book summaries and personal growth app, is one of my favorites here. It combines the celebratory approach from earlier with a satisfying star animation: “Congrats! Now you are a member of Headway Premium, together with 1.7 million learners.”

That community framing is smart. It immediately signals that this isn’t some scrappy app you should second-guess. 1.7 million people made the same choice you just did.

We often assume that because someone signed up for a trial or subscribed, they already trust us. But really, they’ve only trusted us enough to make that first purchase (that’s free!). The post-purchase screen is your chance to keep building that trust, step by step.

Then it reframes the moment around the Job to Be Done: “It’s Day 1 of your self-growth journey”. That’s more than a confirmation, it’s a feeling of excited expectation. This is a new me. I’ll finally stop doomscrolling Instagram and start learning!

Headway reinforces this by focusing on outcomes — grow your productivity, get daily motivation, improve your soft skills — rather than just listing features. It’s about making the user feel the value they just unlocked.

Level 6: give them a clear next step

For some apps, the biggest barrier after subscribing isn’t doubt, it’s paralysis. Where do I start? What should I do first? If your app has a lot of content or options, that first decision can feel overwhelming enough to make someone close it entirely.

Now you don’t want to hit users with ten questions right after purchase — I don’t know about you, but when that happens, I just blank or pick the first thing that comes to mind.

The solution isn’t more information, it’s fewer choices. Greg, a plant care app, handles this brilliantly. The post-purchase screen gives you one job: start adding your plants. Take a photo or upload one. No menus to navigate, no features to explore, no extra decisions. Just one clear first step that gets you using the product immediately.

I had a similar experience with Picnic, a photo-organizing app. The moment I subscribed, it took me straight to a folder of my 2017 photos and had me swipe left or right to decide what to keep — Tinder-style.

As someone who hasn’t used a dating app in ten years, I got to enjoy the fun of swiping again. Once I finished that folder, the app celebrated how much space I’d freed up and let me delete the photos. Then I could move to the next folder at my own pace, making the process clear, fun, and completely manageable.

What that did (and I don’t think it was accidental) was make me feel immediate progress. I wasn’t thinking about whether the weekly subscription was worth it; I was busy clearing out my 2017 camera roll. By the time I came up for air, I was already invested, and honestly, it was kind of fun sifting through years of photos.

Another approach is to provide a brief instruction on what to do next. After the celebratory owl, this is exactly what Duolingo does: a simple, clear set of steps showing how the app works and what to do first:

While many apps include this guidance in their onboarding — and yes, most users will see it on Day 0 — for anyone signing up later, it’s a helpful reminder of what they’ll get and how it works.

Alternative post-purchase onboarding strategies

Now we’ve covered the six levels of app aftercare, let’s push it just a little further. Depending on your app, you can also use this moment to encourage users to create an account or present a subtle upsell, making the post-purchase screen do double duty.

1. Push for the account setup

If account creation is important to your app — for saving progress, personalizing the experience, or staying in touch — and you haven’t already collected it, the post-purchase screen is a good moment to ask for account creation. Not perfect, sure — ideally, you’d have it earlier, but better late than never.

The key is giving users a real reason to hand over their details right now. Not “create an account to continue” (that feels like a gate), but motivation to pass over that info. Back to our shop example: if setting up an account comes with a perk, like 10% off, we’re much more likely to go for it.

Alan Mind, a previous CBT-guided journaling app, does this well: “Save your progress and secure your journal”. That’s a reason that actually matters to the user, showing that their data and privacy are safe.

What would make this even better is offering frictionless sign-up options, like Apple or Google. It removes effort at exactly the moment users are least motivated to fill out forms.

As it stands, it’s not entirely clear what the password requirements are either, which can make this step feel unnecessarily clunky, and that’s the last thing you want right after someone has just subscribed.

Calm, the meditation app approaches this a bit better:

Post-purchase, you get a how did you hear about us survey, and are then encouraged to sign up for an account to track progress.

2. Go for the upsell

One final option — and one to use carefully — is leveraging the post-purchase high to push for a longer commitment or additional purchase. This tends to show up more in larger, well-known apps that are focused on increasing realized LTV per paying customer.

Flo, a cycle-tracking and women’s health app, does this with confidence. After congratulating you on starting Flo Premium, it presents a ‘gift’, which turns out to be a 44% lifetime discount on an annual subscription.

The framing is smart: it’s positioned as a gift, not a sales pitch. And by locking in annual subscribers at the moment of highest trust, they’re tackling both trial drop-off and long-term churn in one move.

Headway takes a slightly different approach. After the celebratory screen, they offer a one-time deal on a Self-Reflection Ebook at a discounted price.

This is a more classic upsell moment, the kind you’d usually see in e-commerce. You’re already in a ‘yes’ mindset, trust is high, and a complementary product can feel genuinely helpful rather than pushy.

That said, sequencing matters. Focus on getting the basics right first, making sure users feel good about what they’ve just committed to, and only then, ask for more.

How to build your first post-purchase screen

Getting started is easy. If you’re currently at Level 1, don’t try to jump straight to Level 5, as tempting as it is. Start with Level 2. It’s a single screen you can ship in a sprint: acknowledge what just happened, remind users why they signed up, and make them feel good about it. That alone puts you ahead of most apps.

Once that’s live, start layering in improvements. Add a celebratory moment or a clear first step, depending on what your app needs. If your product has a lot of content and users tend to feel overwhelmed, prioritize a clear next step or simple instructions (like Duolingo). If your product is simple but the commitment feels big (like Headway), lean into celebration and reassurance.

The main metrics to watch are your Day 0 and Day 1 cancellation rates. Track before and after launching the new screen to measure impact. If you offer a free trial, also monitor your trial-to-paid conversion rate, especially if you’ve added things like push notification opt-ins or feature reminders (like AllTrails has).

If you go down the upsell route, focus on realized LTV and retention, not just the conversion rate on that single offer. A pushy upsell that damages trust will cost you far more in churn than it generates in upgrades.

Because ultimately, the goal isn’t to optimize the post-purchase screen in isolation, it’s to get the moment after someone subscribes right, because that sets the tone for the entire relationship.

Don’t skip this onboarding moment

There are many ways to approach the post-purchase screen, and not every approach will fit every app. But the one thing I’d strongly push back on is doing nothing, dropping users straight into the app, and hoping they figure it out.

At a minimum, give users clarity on what they’ve just subscribed to. Add a moment of celebration, a clear next step, or a reminder of the outcome they’re working towards. These aren’t big product investments, but they can make a real difference to those Day 0 cancellation numbers.

You’ve already done the hard work of earning someone’s trust to the point that they’re willing to subscribe. Don’t stop guiding them the moment they do.

Compose Multiplatform subscriptions: single codebase for iOS and Android

Thu, 30 Apr 2026 01:40:16 GMT

You ship a subscription app on Android and your team starts the iOS port. Suddenly you are maintaining two paywall implementations for Android and iOS, two billing integrations, and two sets of receipt verification code with different APIs and different bugs. RevenueCat’s purchases-kmp SDK collapses that duplication. You write your subscription logic once in commonMain, the SDK wraps Google Play Billing on Android and StoreKit on iOS, and a Compose Multiplatform paywall component renders the same UI on both platforms.

In this article, you’ll set up a Kotlin Multiplatform project with the RevenueCat KMP SDK, configure dashboard products and entitlements, initialize Purchases on Android and iOS, gate premium content from common code, run an in app purchase from commonMain, and drop in a server driven paywall built with the dashboard’s Paywall Editor. You’ll work directly with the same source layout used by cat-paywalls-kmp, the official KMP demo app.

What you’ll build

You’ll end up with a Compose Multiplatform app that lists premium articles, fades the body until the user is entitled, opens a server driven paywall, runs the purchase through the platform native dialog, and refreshes the entitlement state. The same screen runs on both iPhone and a Pixel without a single line of duplicated UI code.

The repository structure is a normal multi module KMP project: a composeApp module with commonMain, androidMain, and iosMain source sets, a few feature modules (home, article, paywalls, subscriptions), and core modules for data, network, and design system. Every line of subscription logic in this tutorial lives in commonMain.

Why single codebase changes the math

Building cross-platform subscriptions without a shared SDK means writing every subscription concept twice. You query Google Play with BillingClient and a purchase token, and you query StoreKit with Product.products(for:) and a signed JWS. You verify receipts with two completely separate server APIs, store them in two different shapes, and reconcile them with a backend mapping layer. None of this work is the part of your product that users care about.

The RevenueCat KMP SDK gives you four shared concepts that hide all of that:

Offerings are the set of products you currently sell, configured in the dashboard rather than in your app.
Packages are the buyable units inside an offering (monthly, annual, lifetime).
Entitlements are the access levels your app cares about (premium, pro, family), independent of which store the user paid through.
CustomerInfo is a single object that aggregates every active entitlement for the current user, regardless of platform.

Once you have these four objects, your app stops asking “did this user buy through Google Play or App Store?” and starts asking “is customerInfo.entitlements["premium"] active?” That single property check works the same on iOS and Android.

Prerequisites and dashboard setup

Before any code, you’ll set up four things in the RevenueCat dashboard:

A project with one Android app and one iOS app, each linked to its store credentials.
Products imported from Google Play Console and App Store Connect.
An entitlement named premium (or whatever identifier you prefer).
An offering with one or more packages attached, marked as the current offering.

Two codelabs walk through the dashboard side end to end. If you have not configured products yet, go through them first:

The two important screens to land on are the entitlement and the offering. The entitlement is the unit your app code checks:

The offering is what your app fetches at runtime. It bundles the packages you want this version of the app to display, and you can change its contents without shipping a new build:

After both apps are set up, copy the public SDK API keys from Project Settings > API Keys. There is one key per platform, and you will use both of them in Step 2.

Step 1: Add the RevenueCat KMP SDK

The KMP SDK ships as two artifacts: purchases-kmp-core for the subscription logic and purchases-kmp-ui for the Compose Multiplatform paywall component. Both are published to Maven Central with a single version coordinate of the form <sdk>+<hybrid-common>. The number after the plus sign matters when you link the iOS pod, so do not strip it.

Start by adding the version and library entries to gradle/libs.versions.toml:

Then declare the dependencies inside the commonMain source set of your app module’s build.gradle.kts. In the cat-paywalls-kmp demo this lives in composeApp/build.gradle.kts:

Notice that both Android and iOS pull the same commonMain dependency. There is no androidMain.dependencies { implementation("com.revenuecat...") } block. The KMP artifact carries platform specific bindings inside it.

Linking the iOS native framework

The KMP SDK depends on PurchasesHybridCommon, a native iOS framework that wraps StoreKit. The cleanest way to bring it in is through the Kotlin CocoaPods plugin. Apply the plugin to your composeApp module:

Then declare both pods inside the kotlin { cocoapods { ... } } block. Pin the pod version to the same major as your purchases-kmp artifact so the Kotlin and Swift sides agree on protocol shapes:

Run ./gradlew podInstall once. Gradle generates a .podspec for your shared module and writes a Podfile.lock next to your iOS app. From now on, opening the iOS workspace in Xcode pulls everything down through CocoaPods.

The KMP SDK uses Kotlin/Native interop bindings that are still flagged as experimental, so opt in inside any iOS source set that touches them:

That is the entire setup. No platform-specific source files yet. Everything else lives in commonMain.

Step 2: Initialize Purchases on each platform

Purchases is a singleton. You configure it once early in the app lifecycle, then every other call goes through Purchases.sharedInstance. Initialization is the only place where Android and iOS code differ, and only because each platform has its own application entry point.

On Android, initialize from your Application.onCreate. The cat-paywalls-kmp demo does this in CatArticlesApplication:

The PurchasesConfiguration(apiKey) { ... } builder is a small DSL. Inside the trailing lambda you can set appUserId, purchasesAreCompletedBy, verificationMode, and other options. Passing appUserId = null tells the SDK to generate an anonymous identifier in the form $RCAnonymousID:<uuid>. When the user later signs in to your backend, you call Purchases.sharedInstance.logIn(userId) and RevenueCat transfers any purchases to that account.

Do not forget to register the Application class and the INTERNET permission in AndroidManifest.xml:

On iOS, initialize from your SwiftUI App struct. You import the native RevenueCat pod here, not the KMP wrapper, because configuration runs in Swift before the Kotlin runtime starts:

ContentView then hosts the shared Compose surface inside a UIViewControllerRepresentable:

The Kotlin side of that bridge is a one liner in iosMain:

App is the same @Composable you call from MainActivity on Android. From this point on, every screen you build runs on both platforms.

The reason initialization is split is that Purchases.configure reaches into the platform billing client immediately. On Android it asks BillingClient to open a connection. On iOS it registers a StoreKit transaction listener. Both need to happen before any Compose composition starts, which is why you do not configure inside commonMain.

Step 3: Check entitlements from common code

Once Purchases is configured, you can ask “is the current user entitled to premium?” from anywhere in commonMain. The KMP SDK exposes coroutine friendly suspend variants of every callback API. The one you want here is awaitCustomerInfo():

CustomerInfo.entitlements is a map keyed by the entitlement identifier you set up in the dashboard. The value is an EntitlementInfo with an isActive flag, an expirationDate, a willRenew boolean, and a store enum that tells you which platform the underlying purchase came from. For access decisions, only isActive matters. The entitlement is active whether the user subscribed through the App Store, Google Play, Stripe, or a promotional grant from your support team.

Most apps wrap this in a repository so the rest of the app can collect a Flow and forget about callbacks. The cat-paywalls-kmp demo defines PaywallsRepository in core/data:

The fetchCustomerInfo implementation is a thin Flow wrapper around the SDK call, with Dispatchers.IO to keep network work off the main thread:

A ViewModel collects this flow and exposes a StateFlow<CustomerInfo?>:

The Compose Multiplatform UI then reads it like any other state and decides whether to render the article body or fade it behind a paywall prompt:

DetailsContent applies a fadingEdge modifier when isEntitled is false. Subscribed users see the article through to the end. Free users see the first few paragraphs fade into a “Join Now” CTA. The same composable runs on both iOS and Android.

Step 4: Run a purchase from `commonMain`

Triggering a purchase is two suspend calls: fetch the current offering, then call awaitPurchase with one of its packages. The SDK takes care of opening Google Play’s billing dialog or StoreKit’s purchase sheet, validating the receipt with the store, and posting it to RevenueCat for tracking.

The awaitPurchase helper from purchases-kmp-core accepts a Package:

Offering exposes convenience accessors for common cadences (monthly, annual, lifetime) and a generic availablePackages: List<Package> if you want to build a custom plan picker. The cat-paywalls-kmp demo wraps this in PaywallsRepository.awaitPurchase(packageId):

Two things to know about the return value. First, the StoreTransaction is informational only. The receipt has already been validated server side by the time awaitPurchase resumes, and the user’s CustomerInfo has been updated on RevenueCat’s backend. Second, the next call to awaitCustomerInfo() will reflect the new entitlement, which means any UI bound to your customerInfo flow recomposes automatically. You do not need to manually invalidate state.

If the user cancels the dialog, the SDK throws a PurchasesException whose code is PurchaseCancelled. Catch it and treat it as a no op rather than an error.

Step 5: Drop in a server driven paywall

You could build the package picker yourself, but RevenueCat’s Paywall Editor lets you design the entire screen in the dashboard and update it without shipping a new build. The purchases-kmp-ui artifact includes a Paywall composable that renders the configured paywall on both Android and iOS.

You design the paywall in the dashboard’s visual editor:

In your KMP code, the entire paywall screen is one Paywall call. The cat-paywalls-kmp demo lives in feature/paywalls/CatCustomPaywalls.kt:

PaywallOptions is where you pass callbacks for dismissal, purchase completion, and restore. With no offering passed, the component renders the current offering assigned to the user in the dashboard. If you are running an A/B test, RevenueCat picks the variant for this user automatically and attributes any conversion to the right experiment arm.

This is the part that pays for itself. The entire visual design of the paywall, including which packages to show, how to highlight the recommended plan, what copy to use for the trial CTA, and which offering to display, is configurable from the dashboard. You can tweak headline copy or swap a one screen layout for a feature comparison layout in the morning, watch conversion metrics in the afternoon, and revert by clicking a button if the new variant underperforms. None of this requires a Play Store or App Store review cycle.

Putting it all together: the architecture

Here is how all the pieces line up in a finished KMP project. In code, the cat-paywalls-kmp demo organizes responsibilities by module:

composeApp is the only module with platform specific code. Its androidMain configures Purchases from the Application, its iosMain exposes a MainViewController() to SwiftUI, and its commonMain holds App.kt plus a Navigation Compose NavHost.
feature/* modules are screens (home, article, paywalls, account, subscriptions). They depend on core/* and contain Compose Multiplatform UI plus ViewModels.
core/data owns PaywallsRepository, the only place that calls into Purchases.sharedInstance. Everything else reads Flow<Offering> and Flow<CustomerInfo> from this repository.
core/model, core/network, core/designsystem, core/navigation hold the data classes, Ktor client, theme, and navigation graph respectively.

The final UX you ship looks like this. Subscribed users see the full article and a subscription management screen sourced from the same CustomerInfo object:

The same SubscriptionManagementScreen reads customerInfo.activeSubscriptions, customerInfo.entitlements["premium"]?.isActive, and customerInfo.originalAppUserId to render its content, and runs without modification on both platforms. There is no if (Build.VERSION...) and no #if os(iOS). The code lives once, in commonMain, and the SDK does the platform translation underneath.

If you want to inspect the full source as a reference, every file shown in this article is in cat-paywalls-kmp. The minimum surface to get a working integration is the four steps above plus the dashboard setup. Everything else is product specific UI.

Conclusion

In this article, you’ve configured the RevenueCat KMP SDK in a Compose Multiplatform project, initialized Purchases on Android and iOS, gated a premium screen with CustomerInfo.entitlements, run a real purchase through awaitPurchase, and rendered a server driven paywall with the Paywall composable from purchases-kmp-ui. Every piece of subscription logic except platform initialization lives in commonMain, which means your iOS and Android apps stay in lockstep without any code duplication.

The thing worth internalizing is what the SDK takes off your plate. You no longer think in terms of purchase tokens versus signed transactions, two notification pipelines, or two receipt verification servers. You think in terms of offerings, packages, entitlements, and CustomerInfo, and the SDK collapses both stores into those four concepts. That same abstraction is what makes the visual Paywall Editor possible, since it is far easier to ship one server driven UI when there is only one shared state model underneath.

Whether you are porting an existing Android subscription app to iOS, starting a new product on KMP from scratch, or experimenting with paywall variants without burning a release cycle, this setup gives you the smallest surface area you can ship a cross platform subscription app on. The remaining engineering time goes back into the parts of your app that actually differentiate your product.

As always, happy coding!

— Jaewoong (skydoves)

How a switch from hard paywall to freemium led to a 75% LTV lift and a 50% conversion drop

Wed, 29 Apr 2026 16:06:13 GMT

For the vast majority of subscription apps, the most reliable path to profitability is simple: lock your core value behind a hard paywall.

The data backs this up. According to our State of Subscription Apps report, hard paywalls convert downloads to paid at a median of 10.7% — five times better than the 2.1% median for freemium apps. The floor for hard paywalls (4.2%) is actually double the median for freemium.

“If you’re a bootstrapped startup or you’re operating with limited outside capital, it’s a much more reliable and low-risk way of growing your business,” explains growth advisor Phil Carter in a recent episode of the Sub Club podcast.

But what if you want to build a billion-dollar company?

“There are a lot of examples of apps like Spotify, Duolingo, Strava that have done that through freemium,” Phil says. “You’re just going to attract a much larger user base at the top of the funnel if you have a free version of your product.”

The transition from a hard paywall to freemium is the highest-ceiling growth lever a mature app can pull. It’s also the most dangerous. To illustrate the stakes, Phil shared the story of his biggest win — and his biggest failure — from the past year. Both involved the exact same strategy.

The win: a 75% increase in LTV

Phil’s biggest win came from helping an established subscription app move away from a traditional hard paywall. But rather than simply opening up the app and hoping users would eventually subscribe, his team implemented a “multistep paywall.”

The strategy reframed the value proposition. Instead of saying, You have to pay for this product now, the new onboarding flow communicated a different message: This product is free and will always be free, but we want you to try the best version of it for seven days. After that, we’d love to have you continue paying to get maximum value.

The results were staggering.

“We saw a 75% increase in LTV per user through the implementation of this multistep paywall along with some other pricing and packaging optimizations,” Phil says.

By removing the hard gate, the app widened its top-of-funnel significantly. More users experienced the core product, organic acquisition accelerated, and the multistep paywall successfully captured the revenue upside.

“It pretty fundamentally altered the full potential size of this business,” Phil notes.

The fail: a 50% drop in conversion

The success of the multistep paywall might suggest that every scaling app should immediately drop its hard paywall. But Phil’s biggest failure of the year serves as a stark warning against treating freemium as a silver bullet.

With a different client, Phil’s team attempted a similar shift to freemium. The results were disastrous.

“The initial results didn’t work at all,” he admits. “We saw more than a 50% reduction in subscriber conversion. We very quickly pulled off of it after a couple of weeks.”

Why did the exact same strategic move produce such radically different outcomes?

It comes down to product-market fit and the inherent complexity of managing a freemium model. When an app relies on a hard paywall, it forces a binary decision before the user has fully experienced the product. The conversion is driven by the promise of value, the quality of the marketing, and the friction of the paywall itself.

When you remove that friction, you’re entirely reliant on the product’s ability to demonstrate ongoing, undeniable value. If the free experience is too generous, users have no incentive to upgrade. If it’s too restrictive, they churn before forming a habit.

According to State of Subscription Apps 2026, 55% of all 3-day trial cancellations happen on Day 0 — meaning the battle for the subscriber is won or lost in the first session.

As Phil puts it, moving from a hard paywall to freemium is “like moving from playing checkers to playing chess because it requires a lot more sophistication.”

When should you make the switch?

If you’re considering dropping your hard paywall, the data and Phil’s experience suggest a clear framework for the decision:

1. Stay with a hard paywall if:

You’re bootstrapped or highly capital-constrained
You need immediate cash flow to fund paid acquisition
Your product solves an acute, immediate problem rather than building a long-term habit
You don’t have the product analytics infrastructure to rigorously test feature gating

2. Consider testing freemium if:

You’ve achieved strong product-market fit and high retention among your core users
You’ve got the runway to absorb a temporary dip in conversion rates while you optimize the model
Your product benefits from network effects or user-generated content (like Duolingo’s massive free experience)
You’ve hit a growth ceiling with paid acquisition and need to unlock organic, word-of-mouth growth at scale

Freemium isn’t a pricing strategy; it’s a product strategy. If you treat it simply as a different way to display your paywall, you risk halving your conversion rate. But if you treat it as a fundamental shift in how you deliver value, it might just be the move that turns your app into a billion-dollar business.

The counterintuitive freemium strategy that scaled Opal to 1M daily active users

Wed, 29 Apr 2026 12:58:49 GMT

Why dropping conversion to 9% was the right move

When Opal, the popular screen time and focus app, hit $5 million in annual recurring revenue (ARR), they were scaling efficiently with a hard paywall. The business model was working, but user growth was plateauing.

To build a product capable of reaching a billion users, CEO Kenneth Schlenker made a terrifying decision: transition to a true freemium model. The immediate result was a massive drop in their download-to-paid conversion rate, plummeting from 20% down to 9%.

But that drop was exactly what the company needed. By giving away the core product for free, Opal unlocked entirely new segments—specifically high school and college students, who now make up two-thirds of their daily active users (DAUs). These free users became the app’s marketing engine. The initial hit to conversion was eclipsed by an explosion in organic growth, pushing Opal past 1 million DAUs and $10 million in ARR.

“We’ve seen a decrease in our conversion to paid, but we’ve also seen as a consequence of that an explosion of our DAUs and revenue with it,” Schlenker explains. “It’s a short-term, scary drop, but what happens in the long-term is that it pays back tenfold.”

The success of a freemium model hinges on a single question: would a non-paying user recommend the app to a friend? If the answer is no, the paywall is too restrictive.

Schlenker argues that many apps fail at freemium because their free tier feels like a crippled trial rather than a complete experience. If users hit aggressive limits before they can extract real value, they won’t stick around, and they certainly won’t tell their friends.

To find the right balance, Opal experimented heavily with their “blocks” feature. They tested giving free users just one block, then two, then more. They eventually landed on three free blocks per day. This proved to be the sweet spot—enough functionality for free users to get a great experience and build a habit, while still leaving power users hungry enough to upgrade.

You can’t “vibe code” a brand

With the rise of AI coding tools, the narrative of the “billion-dollar one-person company” has gained traction. The idea is that a single developer can spin up a functional app in a weekend and scale it to massive revenue. Schlenker calls this a lie.

While AI is incredibly efficient at generating functional tools, it cannot generate emotional resonance. A screen time app is technically simple to build—Schlenker notes that people frequently launch Opal clones—but building a category-defining company requires more than just code.

“Teams create product soul. You can’t vibe code a brand,” Schlenker says. “I think that a recipe for failure in my mind is just to create something that has a function, which AI does really, really well… but you need more than that to be able to be successful.”

That “soul” is evident in Opal’s design choices, like the highly engineered, tactile interaction of cracking open a digital gemstone when a user hits a focus milestone. It’s an expensive, difficult feature to build that doesn’t directly move a metric on a spreadsheet, but it’s the exact kind of magical moment that builds brand affinity and long-term retention.

Expanding beyond the App Store into schools

Opal’s organic growth among students led to an unexpected B2B opportunity. A high school in Los Angeles reached out to the company because their students—who were already using Opal independently—suggested the app as a solution to the state’s impending phone ban.

This organically birthed “Opal for Schools,” a specialized deployment that blocks distracting apps while students are on campus, but allows access to educational tools and emergency contacts. Crucially, it’s not just a “bell-to-bell” restriction. Students keep the app after school, using it to manage their own study time and sleep schedules.

By partnering with schools, Opal is essentially building the next generation of professional users while solving an immediate crisis for educators.

In the full episode, Kenneth also discusses why retention is the only real moat for consumer apps, how they turned a viral user video into their most successful ad, and why every AI feature should be evaluated by whether it makes the user win.

Guest links:

Apple’s new monthly subscriptions with a 12-month commitment: useful, but probably not magic

Tue, 28 Apr 2026 15:45:38 GMT

Apple has introduced monthly subscriptions with a 12-month commitment: an annual subscription that customers pay for month by month. Developers can configure and test them now, and Apple says they’ll be available to customers in May everywhere except the United States and Singapore.

This is a meaningful new pricing tool, especially for markets where paying a full year upfront is a real barrier. But it is probably not a new default subscription model for most apps. In fact, Google Play has worked similarly for a while, but is not wildly popular. The best use case is localized experimentation: making annual-style commitment more accessible without giving up the long-term retention benefits of a yearly plan.

What Apple announced

Apple’s new option lets developers offer an auto-renewable subscription that behaves like an annual commitment, but bills the customer monthly.

Instead of asking someone to pay, say, $59.99 today for a year of access, you can ask them to commit to 12 monthly payments. The customer can cancel at any time, but they will still be charged monthly for the remainder of their 12 month period. At the end of their commitment they will lose access to paid features and will no longer be charged.

Apple is also handling some of the customer-facing transparency. Customers can see completed and remaining payments in their Apple Account, and Apple says it will send email and push notifications before renewal.

The important availability note: Apple says this will be available worldwide except in the United States and Singapore.

This is not just “a monthly plan”

The implementation detail that matters is that Apple is modeling this as an annual subscription product with multiple billing plans.

In App Store Connect, developers create an annual auto-renewable subscription and choose between billing plan types, including “1 Year Upfront” and “Monthly With 12-Month Commitment.” Those billing plans can exist under the same product ID.

That means a single subscription product can now have multiple ways to pay:

One annual price paid upfront
One monthly price paid over a 12-month commitment
Different intro, promo, win-back, or offer-code behavior per billing plan

The customer does not simply pick from an Apple-generated menu at random. Your app or paywall still needs to present the right option and initiate the purchase with the intended billing plan. Developers also need to clearly show both the monthly payment and the total commitment amount before purchase.

This is all very similar to Google Play’s installment base plan for subscriptions: one subscription concept, multiple purchasable configurations.

Why this probably won’t change everything

The obvious first reaction is: this is huge. Annual subscriptions, but paid monthly, should reduce friction and increase conversion.

Maybe. In some cases.

But Google Play has supported installment-style subscriptions for a while, and they have not become the default way most apps monetize. There is a reason for that: for many apps, the standard annual plan is still better.

A paid-upfront annual subscription gives the developer cash today. It improves short-term payback, reduces monthly billing failure risk, and creates cleaner revenue recognition for the business. If your audience can comfortably pay upfront, the traditional annual plan is still a very strong product.

Monthly annual commitments are different. They may lower the purchase barrier, but they do not give you all of the cash upfront. They also add complexity to pricing, paywall copy, analytics, support, and cancellation expectations.

So the goal should not be “replace annual subscriptions.” The goal should be “test whether this unlocks customers who wanted the annual value proposition but could not or would not pay the whole amount upfront.”

Where it gets interesting

The strongest opportunity is localization.

In many markets, the problem with annual subscriptions is not that users dislike commitment. It is that the upfront price is too high relative to local purchasing power. A $50 or $60 annual subscription can be a meaningful expense. Breaking that into monthly payments while preserving a yearly commitment changes the decision.

That makes this especially worth testing in markets where:

Annual conversion is low, but monthly retention is healthy
Users respond to annual discounts but hesitate at checkout
Local purchasing power makes upfront annual pricing feel too steep
You already localize pricing and paywall strategy by country

This is not currently useful for the US, especially because Apple is excluding the US (and Singapore) from launch. But that actually reinforces the point: this is less about a universal monetization shift and more about giving developers another regional pricing lever.

As of writing, Google Play only supports their installments based plans for subscriptions in Brazil, France, Italy, and Spain. This may be a good signal that these regions are more likely to be interested in these types of offers.

What not to use it for

This should not be used to cover up weak retention.

If users do not keep finding value in your app, putting them into a 12-month payment commitment is unlikely to create a better business. It may create more support tickets, more refund requests, more negative reviews, and more payment failures.

The right apps to test this are apps with proven long-term value. If users already stick around, but upfront annual pricing is the barrier, monthly commitments could help. If users churn because they stop using the product after two weeks, this won’t help.

What developers should watch

The obvious metric is conversion: does a monthly annual commitment convert better than a paid-upfront annual plan?

But that alone is not enough. Developers should also watch:

Annual-plan cannibalization
Payment failure and recovery rates
Refund and support volume
Renewal into the next 12-month commitment
Subscriber sentiment in reviews and support conversations
Net revenue by country compared with standard monthly and annual options

This is a pricing experiment, not just a checkout experiment. The upside is incremental revenue from users who would not have bought annual upfront. The downside is replacing high-quality upfront annual purchases with slower, riskier monthly payments.

How RevenueCat supports this

Over here at RevenueCat we are, of course, all over this — and support is now live.

RevenueCat models each billing plan as its own product. You create the upfront annual product as usual, then add a second RevenueCat product for the monthly commitment plan (enabling the 12-month commitment option in the dashboard). RevenueCat automatically appends :monthly to the App Store product ID to distinguish it, so your monthly commitment product appears as <apple_product_id>:monthly across the API, webhooks, and charts.

Purchasing the commitment plan works just like any other product — pass the package or product to purchase(). The installmentsInfo property on the product lets you surface the monthly billing price and total commitment amount on your paywall, both of which Apple requires you to display before purchase.

Because the monthly commitment plan requires iOS 26.4+, use RevenueCat’s Targeting feature to show it only to eligible devices, with a fallback paywall for older OS versions. Native iOS SDK support is in versions 5.76.0+; hybrid SDK support is coming soon.

For the full implementation details, see the Apple Monthly Subscription with 12-Month Commitment guide in our docs.

Stop building features: why early-stage apps need a learning roadmap first

Tue, 28 Apr 2026 10:11:45 GMT

Most early-stage founders have a roadmap full of features they want to build. It feels productive; you’re shipping, you’re making progress.

And while I love fast shipping over perfection, when that speed is focused purely on features, it can be dangerous — especially when you start planning months ahead. You’re assuming you know what users need before validating it, and you’re also committing to features and improvements in a space that is still highly volatile.

Then the roadmap becomes a to-do list of guesses; outputs rather than outcomes. You ship features with great excitement, but you don’t necessarily learn whether they actually matter. Or, at the very least, learning happens much more slowly than it should.

I’ve seen new subscription apps spend months building features that nobody actually uses, because they never paused to ask: what do we need to learn right now?

For early-stage subscription apps, roadmaps shouldn’t be about what to build, as you really can’t reliably predict more than a quarter ahead anyway.

Instead, they should be about what to learn.

That’s exactly what we’ll focus on: building a learning roadmap.

A learning roadmap is a structured plan built around questions and hypotheses rather than features — designed to validate assumptions before committing to a build.

Focus on validating over shipping features

There’s a difference between a shipping mindset and a validating mindset.

Shipping feature mindset: What features can we release this quarter?
Validating mindset: What’s the most important question we need to answer right now?

Pre-Product-Market Fit, you’re not trying to build a complete app that does everything. Instead, you’re trying to figure out whether you’re building the right thing.

The goal is to learn what actually matters to your early users, and what drives them to pay.

The beauty of switching to a validating mindset is that it often doesn’t require building a full feature to generate insight. You focus on the smallest possible test that lets you learn.

How Robinhood validated pre-launch

Before building their trading app, Robinhood launched a waitlist landing page. The value prop was simple: ‘Commission-free trading.’ The main goal was a basic email sign-up, plus a referral loop that encouraged people to move up the list by sharing.

Source: kickofflabs.com

The result was over 1 million sign-ups before the app even existed.

But sign-ups alone weren’t the signal they focused on. They tracked several behaviors to understand the quality of that early audience:

Referral behavior: Were people sharing unprompted? (Yes, the viral coefficient was strong)
Email engagement: Did waitlist users open updates and ask about launch timing?
Willingness to act: When early access was offered to top referrers, did people actually work to earn it?

When you do eventually build a feature, it should usually be because something has been validated, and even then, you’re building it to answer a question, not just to add another piece to the product.

What does a learning roadmap look like?

A learning roadmap is structured around questions rather than features.

For each question, you should be clear on what you think the answer might be, how you’ll test it, and what would indicate whether you’re right or wrong.

The structure looks like this: Strategic Goal → Question → Hypothesis → Test → Success Criteria → Next Step.

It’s important that every question you try to answer is directly tied back to a broader strategic goal.

This forces you to be specific about what you’re trying to learn rather than just shipping and hoping.

For example, imagine you aren’t sure whether users understand the app’s value before they reach the paywall.

Strategic Goal: Improve the download-to-trial-started conversion rate.
Question: Do users understand the value before they hit the paywall?
Hypothesis: Users will better understand the app’s value if we show more visualizations of what the app looks like, directly linked to the benefits we’re measuring.
Test: Add a screenshot of the app to the benefits section instead of illustrations.
Success Criteria: A significant increase in the conversion rate at the first paywall.
Next step: If confirmed, explore other ways to communicate value more strongly. If disproven, test alternatives; for example, adding a short video before onboarding that shows the outcomes users can achieve.

Each question you’re trying to answer is essentially an opportunity to create value for your users.

The key insight, drawn from the work of Teresa Torres on continuous discovery, is to think about opportunities the way your customers would describe them, rather than in internal product language.

For example, you can reframe the question from the user’s perspective: “I don’t understand what this app does before I have to pay.”

Customer-centric framing like this helps you consider multiple possible solutions, and that’s why it’s important not to jump to the first test idea.

If a test, such as “adding a screenshot instead of illustrations,” fails, it doesn’t necessarily mean the underlying question is answered. You may need to explore several different ways to test the same hypothesis before reaching clarity.

The way I approach this is by noting down a few things first:

The quantitative data behind the question or hypothesis, for example, we see a very low trial-start rate while onboarding completion is already high.
The qualitative data that helps us understand the behavior further, for example, during user testing, we observed that people who clicked away from the paywall were still trying to figure out what the app actually does.
According to SOSA 2026, 55% of all 3-day trial cancellations happen on Day 0 — making the question of whether users understand your value before the paywall one of the most critical assumptions to test early.

From there, I work out multiple possible test ideas. For instance, in this example, you could also try:

Adding a short video to the onboarding that shows the app in action
Testing a feature carousel at the start
Showing a simplified “what you can do in the app” overview during onboarding

You can then return to the original question and evaluate which approach is most likely to help you gain clarity, given the insights you’ve gathered.

The three buckets: Now, Next, Later

If you’re wondering what you should be building 2–3 months from now, don’t worry, you really don’t need to know.

I’ve always said that a quarter in a startup can feel like a year in a corporation. Honestly, a month in an early-stage startup can feel like a quarter in a later-stage one. Things move fast, and thank goodness for expensive skincare and blonde hair to help hide the grey hairs I’m convinced startups are responsible for.

While your vision and strategy should be long-term, your roadmap can stay short-term. Trying to plan much beyond that usually just leads to endless rework.

I like structuring a learning roadmap into three time horizons: Now, Next, and Later; a framework popularised by Janna Bastow, which gives you permission not to do everything at once.

Your buckets can look like this:

Now (1–2 weeks): The most critical question you need to answer right now. Just one question. Maximum focus.
Next (2–4 weeks): The questions that are likely to come next, depending on what you learn from what you’re testing now. These are tentative rather than fully committed — for example: “If this happens, then we will do X”, based on the signals you’re seeing.
Later (backlog): Ideas and questions you want to explore eventually, but aren’t scheduling yet. These can and will change as you learn.

This approach keeps you focused while still allowing you to capture ideas without getting distracted.

If you’re anything like me, you probably generate a million ideas during the early phase. While long-term planning is hard, ideation usually isn’t, so having a backlog helps you park ideas and return to them later.

And honestly, a lot of ideas won’t survive that process (I have so many post-it notes with article ideas that, days later, make me wonder what I was thinking). So make a habit of tidying the backlog regularly.

How to prioritize what to learn

You can’t test everything at once; all those ideas and questions you want to explore will need to be prioritized ruthlessly.

This is where assumptions come in. Start by testing the assumptions that would undermine your strategy if they turned out to be wrong.

I usually think about three types of assumptions:

Problem assumptions. Do users actually have this problem and care enough to change behavior?
Value assumptions. Does our solution genuinely help in a way that users recognize?
Willingness to pay assumptions. Will enough users pay enough at this price point for the product to be sustainable?

It’s very simplified, but as a new subscription app, you are essentially trying to answer these questions pre–product-market fit:

Do users have this problem strongly enough to change behavior?
Do they understand the value before reaching the paywall?
Are they willing to pay at this price point?
What makes them come back after day one?
What’s the core action that predicts retention?

My suggestion is to test in that order. If the problem isn’t real, there’s no point in testing around value assumptions. If the solution doesn’t work, there’s no point in testing pricing.

From there, group related questions together; you’ll often find that many of them are connected. For example, returning to the paywall scenario, the question of “understanding value before the paywall” might break down into sub-questions such as:

Do they see what the app looks like?
Do they understand the outcomes they can achieve?
Do they know how long it will take to see results?

Grouping questions this way helps you identify the parent question to prioritize, and also reveals which sub-questions are likely to be answered together.

For example, if you’re building a sleep app and you’re unsure whether your audience struggles more with falling asleep or with staying asleep, that’s a problem assumption you can validate through user research.

Smaller tests, faster learning

Hopefully, you’re convinced by now that you don’t need to build a full feature to learn — and that, as a result, a traditional feature roadmap is somewhat limiting. The goal, instead, is to test assumptions with the least possible effort.

You’ve already seen how the waitlist approach worked for Robinhood, but there are many other options, too:

Prototypes. It’s never been easier to mock up prototypes using AI tools like Lovable.
Painted door tests. Here, you basically fake it till you make it, literally. You could show a fake feature button that isn’t yet functional.
Manual versions of features. If you eventually want to automate something, start by testing the human version first. For instance, you might want to build automated skin analysis and recommendations, but initially test having someone manually provide the advice.
Start with the first part only. For example, if you’re building a community feedback loop, you might begin by testing whether a simple “like” interaction is used, even if the downstream functionality isn’t built yet. In one case, the like action didn’t even trigger any visible response at the start, but it helped validate that users were willing to engage with that behavior.

If you want to go even lighter, you can start with research, such as browsing forums to validate the problem space or conducting user interviews before creating any mockups. For early-stage startups, user research is almost always a good investment of time.

What happens when you learn

Every test will lead to one of three outcomes:

Confidence goes up
Confidence goes down
The result is inconclusive

I’ll be honest, that last one kind of sucks, but I promise it can still teach you something. This gives you clarity on what to do next:

If confidence goes up, decide whether you need further validation, whether there’s more to learn, or whether you can move on to the next question.
If confidence declines, decide whether you need further validation, whether there’s more to learn, or whether you can move on to the next question.
If the result is inconclusive, it could mean several things: perhaps the change didn’t have the expected impact, there wasn’t enough data, or the test itself wasn’t the right way to answer the question. You can then decide the best next step based on the cause.

The goal isn’t to be right. In early-stage work, you will be wrong quite often, and that’s completely normal.

The real objective is to learn quickly enough that being wrong doesn’t become costly.

How to know you’re making progress

A learning roadmap can sometimes feel slower because you’re not shipping visible features. This is where trust can start to waver, for founders and teams alike.

Progress simply looks different, and part of adopting a validating mindset is redefining what progress means.

Progress can be seen in several ways:

You can articulate what you now know that you didn’t know before
You’ve eliminated solutions that don’t work (negative results are progress)
Your questions are getting more specific and focused
You’re converging on a smaller set of high-confidence opportunities
Your success criteria are becoming more measurable over time

Discussing regularly in sprint meetings what you’ve learned and understood, as well as small wins, helps you better see the progress that might not show up yet in your dashboards.

Common traps with planning your roadmap

Across the startups I’ve worked with, the same roadmap mistakes keep repeating. They’re rarely about effort or intent; they’re about how decisions are made.

1. Building before validating

This often shows up in disguise.

Teams will sometimes say they aren’t following a feature roadmap, yet a specific feature or update suddenly starts feeling inevitable. Everyone becomes convinced it’s important. When you ask what that belief is based on, the answer is usually something like, “we just know” or “we have to do this.”

That’s still building before validating.

Confidence is not the same as evidence. Even strong intuition needs to be grounded in research, data, or real user signals. The more excited you are about an idea, the more disciplined you need to be about pressure-testing it.

2. Too many priorities

If everything is a priority, nothing is.

A strategy is not ten parallel projects; it’s a clear commitment to one or two things that matter right now. Your roadmap should reflect that focus.

Be ruthless with your “now” bucket. If you’re trying to answer several big questions at once, you’ll likely make shallow progress on all of them and meaningful progress on none.

3. Vague success criteria

“We’ll see if users like it” is not a success criterion.

“It’s slightly better” isn’t either.

Early on, statistical significance isn’t always possible, and that’s fine. What matters is being explicit about what success looks like before you start.

Ask yourself:

What signal would make you confident enough to continue?
What outcome would clearly tell you to stop?

Also, think through secondary metrics in advance. For example:

If the main metric doesn’t improve but another one does, what would you do?
If the main metric improves but something else worsens, is that acceptable?

Planning these scenarios early prevents a lot of post-hoc rationalization.

4. Ignoring negative results

It’s tempting to explain away data that doesn’t confirm what you want to believe. As one speaker once said, “If you torture the data enough, it will always confess.” That idea has stuck with me because it’s painfully true.

There will almost always be a way to frame results as “not that bad” or to cherry-pick supporting slices of data. Clear success criteria help protect against this, but mindset matters too.

Negative results aren’t something to be ashamed of. Most things won’t work; that’s completely normal. Treat failed experiments as learning rather than something to justify away. That’s what actually moves teams forward.

5. Never moving on

The final trap is getting stuck in testing mode.

Testing can feel safe because there’s always one more variant to try or one more week of data to collect. But at some point, you need enough signal to make a decision and move forward.

Roadmaps are not about infinite validation — they’re about building confidence and then committing.

Be honest with yourself about whether more testing will actually change your decision, or whether it’s just a way to avoid making one.

Some signs you’re ready to move on:

You’ve tested across 2–3 cohorts, and the pattern is consistent
The signal is strong enough to justify allocating resources (not just “slightly positive”)
Further testing is unlikely to change your decision
You’re delaying commitment rather than genuinely learning

Use this list of common mistakes to keep yourself in check; you can even use it as part of a sprint retrospective. Going through the following questions as a team:

Were there any cases where we built before validating?
What are our top priorities? Do we need to narrow them down?
Are the success criteria of all the experiments clear enough?
What were the ‘negative’ results this sprint? What did we learn from them?
Is it time to move on from any focus areas?

Stay the course, refine or pivot?

In Eric Ries’s Lean Startup framework, there’s a recommendation to hold regular (often monthly) meetings to decide whether to pivot or persevere, essentially, whether to change direction or stay the course.

I agree with the methodology, but the binary framing can feel a bit too black-and-white. The decision is usually not as simple as either killing an idea or continuing unchanged. Sometimes something is working partially, and the pressure to choose between pivoting and persevering can push teams toward perseverance because pivoting feels scarier. That’s where sunk cost fallacy starts creeping in; you’ve invested so much that it’s hard to step away.

Instead, I prefer thinking about it in three options:

Stay the course (persevere). When the core hypothesis is confirmed, focus on execution and iteration.
Refine. The direction is generally right, but some details are wrong. This isn’t about small optimization; it’s about making a meaningful adjustment, such as changing the target audience, refining positioning, or altering features.
Pivot (or kill). The core hypothesis is disproven, meaning you need to fundamentally rethink the problem, the user, or the solution.

Most launches don’t need a pivot; they need refinement. A true pivot should only happen when evidence clearly contradicts your core assumption about the problem or user, such as when target users don’t perceive value or when there are no meaningful signals of monetisation.

A well-known example of a major pivot is that of Instagram. Originally launched as Burbn, the product started as a check-in app with many features.

After launch, the data showed that:

Most features were being ignored
Photo sharing had unusually strong engagement

The founders stripped away everything except photos because they realised their core hypothesis was wrong: users weren’t primarily looking for a check-in app or the broader feature set. Instead, they doubled down on the signal with the strongest user engagement and pivoted around that.

When can you move on from a learning roadmap?

A learning-style roadmap isn’t meant to last forever.

At some point, it can start to lose its usefulness. Instead of providing clarity and direction, it may begin to feel like a long list of unresolved questions. As teams scale and the number of initiatives grows, a pure learning roadmap can sometimes create more noise than focus.

This is usually a sign that you’re getting closer to product–market fit.

As confidence increases, the balance naturally shifts. Post–product–market fit, you tend to have a clearer understanding of who your users are, what they want, and which problems truly matter. At that stage, a more traditional, feature-oriented roadmap (still focused though on outcomes) often becomes more practical.

That doesn’t mean learning stops.

Markets evolve. User behavior changes. Competitors improve. The difference is that the focus moves from mostly learning with some building to mostly building with some learning.

You’re no longer questioning everything, but you still leave room to validate key assumptions and challenge strategic direction when necessary.

In that sense, a learning roadmap is what helps you reach the point where a feature roadmap actually starts working.

Building roadmaps around questions, not outputs

So remember, in early-stage subscription apps, strong roadmaps are built around questions — not features, not incremental improvement points, and definitely not growth for growth’s sake.

A simple structure works well:

What are we doing now?
What are we doing next?
What comes later?

Your backlog belongs firmly in the later bucket.

The real work is being ruthless about identifying the assumptions that could undermine your idea if they turn out to be wrong, and prioritizing those first.

Start by testing small and moving quickly. Only then should you expand and build with greater confidence.

This approach can sometimes feel slower because you’re shipping less. In practice, it’s usually faster. Teams that default to constant building often spend months delivering features that nobody actually wants. Starting with learning helps avoid the waste of building things just for the sake of building.

If you want to go deeper into defining your strategy and identifying the right questions to answer, you can explore my full course on building an app that people will pay for.

Recapping App Monetization Seoul

Fri, 24 Apr 2026 10:46:55 GMT

On April 10, monetization leaders from Korea’s top apps came together at Boutique Monaco in Seoul for a night of honest conversation about how apps actually make money. The event, App Monetization Seoul, was co-hosted by DARO, RevenueCat, and EHVM Apps Capital.

There was a great turnout with C-levels, growth leads, and product folks from companies like Google, AppsFlyer, Toss (Viva Republica), Healing Paper, Moloco, Criteo, SNOW, and CJ. The mix of ad-side and subscription-side practitioners in the same room was what made the evening work.

Two levers that drive ad revenue

Eungil Cho, BD Manager at DARO, opened the evening. His framing was simple and hard to argue with. Ad revenue comes down to two levers: eCPM and impressions. Getting one of them right is not enough. The teams that win are the ones that balance both and build a culture of continuous experimentation around them.

The point landed because the insights came out of DARO’s own experience running ad monetization for Alarmy, the number one alarm app globally built by Delightroom. Real numbers, real trade-offs, no slideware.

What actually moves subscription revenue

Rik Haandrikman, VP of Growth at RevenueCat, spoke next: his session pulled from the State of Subscription Apps 2026 data across 115,000 apps on the RevenueCat platform. The talk cut through a lot of the rumours floating around about paywalls, pricing, and trials, and replaced it with what the numbers actually say.

If you have been guessing at what drives subscription revenue, the answer is that most of the industry is guessing too. The signal, when you zoom out across that many apps, is sharper than you would think.

The global opportunities founders keep missing

The night closed with a panel on global monetization. Evelin Herrera, CEO of EHVM and the person behind more than 150 mobile app and game M&A deals, joined Rik and Seunghwan Stephan Seo, Chief of Staff and Product Owner at Delightroom.

The conversation kept coming back to the same point. Korean app founders have world-class products, but many of them leave real revenue on the table because they underinvest in markets outside their core. Evelin’s view from the deal side, paired with Stephan’s operator view from Alarmy’s global playbook, made the case concrete.

Finger food and frank Q&As

The last 90 minutes were networking over finger food. This is the part of these events that is hard to engineer and easy to get wrong, but conversation flowed and the food was great. Conversations that started in the Q&A kept going through the networking, which is usually the sign of a room full of the right people.

Thanks to everyone who came out.

Yes, you can build a subscription app with AI (but it might hurt a bit)

Thu, 23 Apr 2026 12:03:43 GMT

We’re in the middle of an AI-fueled hype cycle where it feels like everyone is building apps in a weekend and making $100K a month. It is as exciting as it is misleading.

“Your app, OnTimer – Never Be Late, is ready for distribution.”

When I finally saw that message from Apple’s review team, I knew two things were true:

Yes, you can build your own mobile app with AI
You’re probably not going to do it in a weekend (it took me four months)

I like to joke that any idiot can build an app now — just ask me how I know. But we really are living in an amazing moment. Great ideas have never been limited to a specific set of people; anyone of any background, education, or technical ability can have a million-dollar idea. The limit has always been whether those same people have the technological know-how to turn that idea into reality. Now, as we’ve all seen, AI has erased that limitation.

The reality behind vibe coding your first app

I don’t know how to code.

When I started building the app in November 2025, I was just trying to see what was possible with vibe coding. But each time I got something to work, or fought through a bug, I got more determined to see it through.

Seeing the app in the App Store and getting my first customers has been incredibly rewarding. It was also harder than I expected.

So yes, you can vibe code a real subscription app. Is it as easy as everyone says? That’s a more nuanced answer. But I’m going to share what I learned so you can do it too, and maybe even avoid some of my mistakes.

Lesson 1: don’t wait for the perfect idea, build something

If you’ve ever gotten a frustrated text from a colleague saying, “We’re all on the Zoom, are you joining?” then you’ll understand OnTimer’s origin story.

Every morning, I used to check my calendar and set alarms two minutes before my meetings. I hate being late, and regular calendar notifications are too easy to ignore. I needed something more persistent, otherwise I’d just keep writing that email or staring at a chart.

So when I wanted to see what was possible with vibe coding, I didn’t go looking for the perfect idea, I just automated my own behavior.

I didn’t know if it could make money, I didn’t know how many other people shared the problem. I just knew I didn’t want to wait.

In a world where you can build anything, paralyzing yourself in search of that perfect, differentiated idea, is a great way to get stuck doing nothing.

So when I saw a LinkedIn post for Supervibes, ‘The vibe coder for native apps’, I got to work.

Lesson 2: pictures are not products, and AI often doesn’t know the difference

I was blown away when my initial prompts transformed my vision for OnTimer onto the screen in minutes. It’s almost intoxicating to see your app come to life like that.

But I quickly learned that there is a big difference between what you’re seeing and what is actually working. This has been a recurring theme throughout the process.

I knew oAuth would need real setup, that was expected. What I didn’t expect was that the AI would fake things that actually mattered to the user experience.

When Supervibes initially coded the app with fake calendar data, that seemed acceptable as a starting point. But it also ‘faked’ things that would come back to bite me. On the homescreen it had created a sync icon with text that said, “Auto-syncs every 15 minutes”. As it turned out, this wasn’t a feature or setting — it was pure window-dressing, but I didn’t know to question it.

It took me about a week to get oAuth and the initial calendar connections working. When my Xcode-connected test phone fired its first OnTimer alarm for a meeting, it was the first time I started to believe this could work.

But remember earlier how I told you I was an idiot? This is where that comes back into focus.

With the core functionality ‘working’, I spent my nights and weekends slogging through the App Store’s somewhat-convoluted process and finally sent a first build to TestFlight.

That was eye-opening, and not in a good way. The full screen alarms that worked so well on my test phone, when the app was in the foreground, didn’t work at all when the app was in the background. And since the automatic sync was fake, OnTimer’s never be late promise was pretty empty.

I eventually switched from Supervibes to Claude Code, but this is a ‘gotcha’ across AI tools. The ‘pictures’ they paint feel real, but pictures aren’t products. The inconsistency between what was hard-coded in, and what wasn’t, made it near-impossible to differentiate between whether something was built and functional, or just a convincing visual.

If I could go back, I would have spent a few hours with a whiteboard before writing my first prompt and asked:

What does success look like at each stage?
What qualifies as working?
What are my expectations as a user?

Lesson 3: your simple app might actually be more complex than you think

Sharing that first version on TestFlight early turned out to be a great decision. The feedback was swift and painful.

Connecting oAuth turned out to be the easy part. Building a persistent notification system that works in the background is not. Making the never be late guarantee work when a phone is silenced is not. Syncing multiple calendars reliably is not. Every time I solved one challenge, a new one seemed to appear.

This is somewhat the nature of AI: what you see from the outside appears functional and sleek. Even when a problem arises, it seems to be resolved fairly simply. But behind each challenge and subsequent resolution, the respective jerry-rigged solutions become knots that come back around to haunt you. Because we only see the front of the AI tool, it often appears problems are solved, when actually they’ve just been plastered over.

I learned quickly that there is a lot of complexity in building a ‘simple’ app. As a vibe coder, this is where you are kind of on your own.

On a team, you have people and experience to think this stuff through. Often you avoid pitfalls because your engineers have already run into them before. With vibe coding it’s just you and an LLM. If you don’t ask the right questions, it’s hard to know what’s coming next.

Here’s what I should have done differently:

Asked an LLM to compare my plan to app store rules and iOS limitations
Created a ‘Perfect.md’ file that described the ideal end-to-end user experience and forced Claude to align every change to it
Talked through my idea with others (humans!) to uncover challenges early

Lesson 4: the vibe coding landmines are scary, but they aren’t deadly

Three or four times as I was building OnTimer, I hit walls that seemed insurmountable. I ran into issues that brought everything to a halt, and pushed me to the edge of my sanity.

A few weeks in I got caught in a cycle. Identify bug → prompt Claude to fix → Claude says “Perfect, I fixed it” → nothing changes → repeat

My prompts eventually devolved into me telling Claude to “Go F%ck itself” which didn’t help.

In a moment of desperation, I asked Claude to show me how to manually make a change to one word on my homescreen. I was losing my mind, and Claude couldn’t even make the simplest of changes, let alone fix the bug.

Then I saw my manual change instantly revert itself. I didn’t know why, but I finally saw what was happening. It turned out an update I made was causing new code to save to a backup drive, while the live file stayed static.

It was a week of hell, for what turned out to be a five-minute fix.

The problem with vibe coding is that you don’t have the same instincts or approach engineers have. We can’t look at the code the way they can. When things break, it’s easy to get lost.

But here is what I learned: don’t keep doing the same things over and over that aren’t working, and don’t let Claude (or *insert AI tool*) do it either. Even when you try to prompt root cause analysis, it can have a tendency to just keep trying to fix the same area of your code. You have to get it out of its own way.

A good tactic I have found is to use another LLM to challenge Claude. If a fix doesn’t work I bring in ChatGPT:

I share the Claude Code thread and relevant files, and ask ChatGPT for a fresh analysis and prompt
I send the prompt to Claude in Plan mode, and go back and forth between the two LLMs
When it’s fixed, I update my Claude.MD file with a detailed explanation to prevent similar issues in the future

Bugs are probably the worst part of vibe coding. They’re not just time-killers; they rob you of your confidence. It’s not fun, but the more you battle through these, the faster and better you get at it.

Lesson 5: monetize early, you won’t regret it

From the beginning I knew I was going to launch OnTimer as a subscription app. Monetizing your app forces you to focus on value delivery and product-market fit. Those are great forcing functions, even when you are still learning.

You will have to make real decisions: freemium vs. paid, free trial lengths, what lives behind the paywall and what doesn’t. I chose freemium with an annual subscription. The free tier lets users experience the core alarm functionality. The paid tier unlocks multiple calendars and Time-to-Leave departure alerts.

Figuring out what to place behind the paywall forced me to ask myself what was valuable enough to pay for, and what needed to be free to get someone hooked. That thinking made OnTimer a better app.

Monetization adds layers:

App Store complexity: subscription apps get more scrutiny from reviewers, and rejections are more painful when you’re trying to ship
Entitlement logic: your app needs to know what a user has paid for, and show it appropriately
Paywall considerations: a bad paywall doesn’t just hurt conversion, it can get your app rejected entirely

Fortunately, RevenueCat makes this a lot faster and easier. They provide an integration prompt for vibe coders, which was like magic.

I fed it into Claude and within minutes I was walking through RevenueCat’s setup guide. In less than a day I had a working paywall.

It wasn’t perfect. I did get rejected from the App Store twice because of a paywall issue — a nuance in the RevenueCat UI builder looked correct visually but wasn’t behaving right in practice, reverting to a default state rather than the one I’d selected. I hit customer support, quickly got it sorted, and finally got OnTimer approved.

What was cool though, is that I went back into the paywall builder a few days ago, and the issue I ran into had been fixed. It’s great when your feedback helps the next developer avoid the same pitfall.

RevenueCat did the heavy lifting so that I could focus on developing the app’s core value. They handle the logistics of your subscription infrastructure so you can stay focused on building something people want to pay for.

So, I really encourage you to monetize early because:

It forces honest conversations about value: if someone won’t pay for it, that’s information — find out early
Subscribers give better feedback than free users: they have skin in the game and they want it to work
Revenue changes your psychology: even a few dollars a month makes you more serious about shipping and improving

Go build your first app, it’s worth it

You should absolutely go build your first app. It’s not as easy as the hype makes it sound. Things break, and you hit walls. You have moments of real frustration and doubt.

But you also have moments of amazing accomplishment. Yesterday I had a doctor’s appointment, and OnTimer’s Time-to-Leave feature fired off an alarm based on traffic and distance.

I built that!

…Okay, Claude helped.

The point is that vibe coding is real. You may not make $100K/month right off the bat like many on LinkedIn and X would have you believe — it will probably take longer than you expect. It took me about four months to launch. But if you push through the hard parts, you can build something you are proud of.

Now I’m shipping, learning, and even starting to see the first signs of revenue. The next challenge is growing it, and that’s going to be hard too.

But I’m in it now, and you can bet this won’t be the only app I build.

AI got me started. Persistence is what got me here.

Check out OnTimer – Never be late on the App Store!

How to add trial notifications to your subscriptions

Wed, 22 Apr 2026 14:50:05 GMT

Free trials are one of the best ways to convert users into paying subscribers — but they can backfire. When a user forgets they started a trial, the unexpected charge feels like a betrayal. They refund, leave a bad review, and never come back. Even worse, that one bad experience can make them reluctant to try any subscription app again.

A simple reminder notification a day or two before the trial converts changes the dynamic entirely. The user feels respected, not tricked. They either cancel (which they would have anyway) or they convert knowing exactly what they’re paying for. Either way, you build trust — and trust is what drives long-term retention.

I’ve written about building trial reminders before using RevenueCat and Zapier to power email-based notifications. In this tutorial, we’ll build a similar system using local and remote push notifications in React Native — though the same concepts apply to Kotlin and Swift.

How to plan trial reminders

Trial reminders don’t have to be complicated, but sending out more than one reminder builds trust, and removes uncertainty. I would recommend a lightweight three-notification pattern:

1. Activation nudge (same day)

Send a notification on the first day, highlighting a feature they have not yet tried, in order to signal that the notifications work, and to get them to experience their first “aha moment” during the trial.

2. Mid-trial reminder (two days before end)

Two days before the trial is about to expire, remind them that the trial is ongoing and that it will expire in the next few days. You will most likely see users cancelling their trial at this point — that is to be expected. That gives you a chance to capture them with a win-back offer, for example.

3. Trial-ending alert (morning of last day)

On the morning of the last day, send a transparent, helpful reminder:

“Your trial ends today. Keep access by staying on your plan — or cancel anytime.”

How to implement trial notifications in React Native

There are two approaches: local notifications (no server needed) and remote notifications (requires a small backend). We’ll walk through both, starting with local.

Local notifications approach

With local notifications, all the reminder logic lives on the device — no server needed. When a user starts a trial, you grab the trial expiration date from RevenueCat’s customerInfo.entitlements (specifically the expirationDate on the active entitlement), then schedule notifications relative to that date.

Local notifications are the simplest approach — very little code and no backend to maintain. The trade-off is that the notification schedule can only update when the user opens your app. If someone cancels their trial through the App Store settings page, for example, the app won’t know to unschedule the reminders until it’s opened again. The same applies if they switch to a plan without a trial.

Additionally, local notifications will fail if the user’s device is powered off, and orchestrating other notification channels such as email is harder with local notifications. Some Android phones also have limitations on delivering local notifications at the exact scheduled time.

Remote notifications

The alternative to local notifications is a server-driven approach. You run a lightweight backend that listens for RevenueCat webhook events and schedules or cancels trial reminders accordingly.

This approach takes more work to set up, but it’s significantly more reliable. You can update notification content without shipping an app update, use multiple channels (push notifications and email, for instance), and cancel reminders immediately when a user unsubscribes — no app open required. The backend itself doesn’t need to be complex: a single endpoint that digests webhooks and schedules notifications is all you need.

On the client side you only need to take care to store users’ push notification token, which is something RevenueCat can actually help you manage. You can save push tokens in Attributes, from which they are available using either REST API or Webhooks.

Choosing a notification package to use

React Native does not come with notifications included, so you need to install and configure an external dependency to run them. Here are a few options that support both remote and local notifications:

Expo Notifications
Expo notifications is excellent for notifications, especially if you have an Expo project. This tutorial will use Expo Notifications for the examples.
react-native-notifications
Wix has been maintaining their own notification package for React Native for over 10 years already. It’s stable and has all the features you need for notifications.
@notifee/react-native
Notifee is a feature rich notification library for both iOS and Android. It’s especially powerful when you want rich notifications, with images, custom sounds and interactability.

Subscription reminders with local notifications

The next parts assume that you’ve installed and configured your notification package for your project.

Step 1: create a trial schedule object

We will want to remind users three different times, so let’s build a trial object that will be used for scheduling when and containing the messages we want to send. The following trialSchedule follows the 3-part trial reminder structure we discussed earlier.

Step 2: schedule notifications during subscription process

Scheduling the trial reminders will happen when users subscribe. We can use getCustomerInfo to check if user is running a trial:

Step 3: unschedule notifications on unsubscribe

Subscription reminders with remote notifications

Step 1: store users’ push tokens

The first step to adding remote trial notifications is to track the users’ push tokens. This is made easy with RevenueCat Attributes, where you can store additional structured information about customers. These attributes can later be read using the REST API.

If you take a look at the documentation for Attributes, you see that both $apnsTokens and $fcmTokens are reserved attributes. This means that we can store push tokens in RevenueCat as well. Doing that through code is just a few lines:

That is all that is needed from the client side, as long as you have configured your notifications correctly. The rest of the tutorial will focus on what needs to happen on the server side.

Step 2: build a notification backend

All of the logic for trial reminders will happen on the backend side. For this we need to build an endpoint that accepts webhooks from RevenueCat and then schedules notifications based on those. To understand which types of Webhook events we need to support, we can take a look at the webhook sample events.

In this example we are going to use a Cloudflare worker, but it’s not a requirement. You could also build this using Zapier and OneSignal.

Here’s some example code:

Let’s go through the main functions of the code.

Unwrapping the webhook payload is the first step.

The POST request from RevenueCat webhook is sent to our worker which then unwraps the contents. In this case the interesting parts are:

period_type, tells us if the subscription is TRIAL type
purchased_at_ms, tells us when user made the purchase
expiration_at_ms, tells us when the trial will convert
subscriber_attributes, from here we can get the push notification token to use

Scheduling notifications

In our code we check first if the purchase is trial type, then we schedule a notification 6 hours from that if the purchase was made before 12pm, otherwise we schedule it for the next day. Then we schedule a mid-trial reminder 2 days before the trial ends. Last scheduled reminder is set for the morning of the expiring subscription. If the subscription expires in the morning, we schedule it for the evening of the previous day.

Unscheduling notifications

The last logic we have for the apps is that we unschedule the notification if the user cancels the trial. In this case we monitor for the cancel_reason being UNSUBSCRIBE and then remove the scheduled notifications.

Running logic to send notifications periodically

The last part of the code is that we run a different worker every hour to send notifications to users based on their scheduled times. This is done through a cron job.

Step 3: enable webhooks in the RevenueCat dashboard

Navigate to the RevenueCat dashboard, and select the Integrations tab from the sidebar. Under Core Tools, select Webhooks. Click Add Webhook and set the Delivery URL to your worker endpoint (e.g. https://your-worker.your-subdomain.workers.dev). Set the Authorization header to match the RC_WEBHOOK_SECRET you configured in your worker. Make sure to enable at minimum the INITIAL_PURCHASE, CANCELLATION, EXPIRATION, and TRIAL_CONVERTED event types.

Wrap-up

Trial notifications are one of the fastest, lowest-effort ways to improve trial quality and conversion. With clear data (purchasedDate, expiresDate) and a small amount of React Native code, you can build a trust-first notification flow that feels more like Blinkist — transparent, helpful, and user-centred.

Start with the three-message sequence, keep the messaging honest, and iterate based on user behavior. You’ll see the lift.

How an email list became a 15-year safety net for a solo app developer

Wed, 22 Apr 2026 12:58:17 GMT

The personal workaround that became a business

Teleprompter Pro didn’t start with market research; it started with a frustrating freelance video gig. In 2010, Joe was a 19-year-old freelance videographer working on a low-budget pilot. They needed a teleprompter, but he was “too cool to write on a piece of paper and hold it.”

He tried using Apple Pages on a first-generation iPad to scroll text, but the experience was clunky. He couldn’t even easily get a black background. Having recently downloaded Xcode, he decided to build a simple scrolling text app himself.

“It just sort of moved some text up,” he recalls. But when he put it on the App Store alongside a few other random projects, it was the only one that gained traction. It solved a genuine problem for people doing video production. For the next seven years, that simple utility app generated steady, organic revenue while Joe worked a full-time job in web and graphic design. It wasn’t until 2018 that the app’s revenue allowed him to quit his job and go full-time indie.

The App Store river and the illusion of control

Many developers attribute every spike in downloads to a brilliant new feature they just shipped. Joe takes a more humbling view of his app’s growth trajectory.

“I think we assume that literally everything is happening to us and that we’re responsible for any of the success,” he notes. The reality is that the App Store is a massive river. Sometimes your app is just sitting right in the current, benefiting from a small algorithmic tweak or a new search trend.

Joe embraced this reality early on. “We’ve never, ever had a day of zero revenue ever,” he says, even during the years when he was barely updating the app. Accepting that he didn’t control every single variable freed him from constantly chasing the algorithm. Instead, he could focus on building a reliable product and let organic momentum do the heavy lifting.

The unexpected ROI of personal customer support

When Joe finally transitioned to full-time indie development, he found himself spending an enormous amount of time answering customer support emails. Many were simple questions—like explaining that a user’s orientation lock was on—but he felt a deep responsibility to ensure every user got a helpful answer.

While it consumed his working days, that direct line to users became his most valuable product research tool. “A lot of questions we get are just super simple… but I sort of feared that that would turn into one-star reviews or someone abandoning the product,” he explains.

Those conversations led to crucial feature additions, like adding a video recording option, and eventually highlighted the need for better onboarding. More importantly, taking the time to personally respond built immense goodwill. Users who were initially frustrated often became loyal advocates, simply because they received a genuine reply from the app’s creator rather than an automated corporate response.

Why an email list is the ultimate safety net

If there is one piece of advice Joe insists on, it’s the importance of owning your audience. From the very early days, he asked users for an email address. He didn’t have a grand marketing plan; he just liked the idea of being able to announce cool things to people.

That simple decision became the foundation of his business stability. “I’m quite convinced that that is the single most important thing I ever did for my career,” he says.

When he transitioned Teleprompter Pro from a paid upfront model to a subscription model in 2020, he didn’t have to rely on App Store release notes to communicate the change. He could email his users directly, explain that existing customers were grandfathered in, and offer a discount to those on the fence. When he launched his new app, Captions (Recap), earlier this week, he emailed a segmented list of users who actively record video, offering them the Pro upgrade for free if they pre-ordered.

The App Store algorithm can change overnight, but an email list ensures you never have to start from zero.

In the full episode, Joe also discusses the stress of navigating an unexpected “spam” rejection from App Store Review for his new app, the benefits of attending industry events, and why slow, steady growth is often the healthiest path for indie developers.

Guest links:

Build web funnels with Stripe Billing and Managed Payments in RevenueCat Web

Wed, 22 Apr 2026 12:03:04 GMT

If you build on Stripe and want a merchant-of-record path for web, you can now do more in RevenueCat Web: by using Stripe Billing and Stripe Managed Payments across Web Purchase Links, Web Paywalls, Funnels, and the Web SDK.

This gives you a powerful toolkit to build web purchase flows, with Stripe at the center of billing and checkout. For eligible flows, you can also use Stripe Managed Payments, which adds a Stripe-native merchant-of-record option to the same web monetization path.

Stripe in RevenueCat Web

As web monetization becomes a bigger part of your app business, your stack needs to hold together. You want purchase flows on the web, billing that still makes sense, and tools that don’t force you to rebuild everything around a new system.

With RevenueCat Web, you can now combine Stripe Billing and Stripe Managed Payments with the touchpoints you already use to launch and scale purchase flows like your paywall and checkout. Billing, checkout, and web monetization can now work together in one Stripe-based path inside RevenueCat Web.

Across paywalls, links, funnels, and the Web SDK

This support shows up in the places where you build and sell. You can use Stripe-backed billing and checkout across the main RevenueCat Web features that shape your web monetization journey.

Features	What you can do
Funnels	Build end-to-end acquisition and conversion flows on top of Stripe
Web SDK	Build Stripe-powered purchase flows directly into your web experience
Web Purchase Links	Launch shareable purchase flows backed by Stripe Billing and Managed Payments
Web Paywalls	Present web paywalls tied to Stripe-backed products and checkout

That range matters. You are not adding one checkout button to one page, you’re bringing Stripe into RevenueCat Web across the touchpoints that support acquisition, conversion, and lifecycle flows.

Stripe Managed Payments in RevenueCat Web

If merchant-of-record matters to you, this release matters even more. It affects how you handle tax, operational overhead, and the structure of your checkout flow.

Alongside Stripe-backed billing in RevenueCat Web, you now have a path to use Stripe Managed Payments for eligible flows through Stripe Checkout — which is especially relevant if you want a merchant-of-record model without moving away from Stripe.

The benefits are straightforward:

More choice in how you build on web
More continuity with your existing Stripe setup
A clear Stripe-based path to merchant-of-record in RevenueCat Web features you use to drive conversion

How the stack works

Each part of the Stripe stack plays a different role:

Stripe Billing handles your subscription and billing setup
Stripe Managed Payments gives you a merchant-of-record model for eligible flows
RevenueCat Web brings those pieces into the paywalls, links, funnels, and SDK flows you use to sell on the web

Layer	What it means for you
Stripe Billing	Your subscriptions and billing system live in Stripe
Stripe Managed Payments	You get Stripe’s merchant-of-record model for eligible flows
RevenueCat Web	You use these capabilities across paywalls, links, funnels, and SDK-driven experiences

You can keep Stripe at the center while using RevenueCat Web to launch and optimize the purchase experience around it.

More app teams now treat web as a serious monetization opportunity. This changes what you need from your stack. You need purchase flows that fit your product, billing that fits your business, and infrastructure that supports how you test, package, and iterate on the web.

By combing Stripe Billing and Stripe Managed Payments with RevenueCat, you now have a stronger option to do just that.

Start building

If you already use Stripe and want to bring merchant-of-record into your web monetization setup, now is a good time to take a closer look. You can build Stripe-powered purchase flows in RevenueCat Web with support for both Stripe Billing and Stripe Managed Payments.

Start with the docs, review the setup and eligibility details, and map the first flow you want to launch. You can also join us at our Stripe Sessions pre-event on April 28th to see how app teams are approaching web funnels, web-to-app, and app-to-web growth: Reserve your spot.

If you are building on web with Stripe, you now have a stronger path to do it in RevenueCat.

Announcing Paywall rules: show or hide paywall components

Wed, 22 Apr 2026 10:02:06 GMT

RevenueCat Paywalls is the easiest way to build custom paywalls for your app. Combined with RevenueCat Targeting, it allows you to serve a different paywall to different customers without having to make new releases. And now, with the release of the new Paywall Rules feature you can take personalized paywalls even further, without having to make new paywalls.

Paywall Rules allow you to customize the visibility of paywall components based on both preset and Custom Variable based rules, enabling you to customize a single paywall to support multiple scenarios.

Hides components when a package is selected, and more

What do Paywall Rules look like in practice?

One example is using Paywall Rules to show a trial timeline only when a trial is available, or to display a different package based on a custom variable.

Paywall Rules supports the following rules at the moment:

Rule	When the rules will take effect	What Rules are available
offer.intro	If the user selects a package that includes an introductory offer	Visibility and text overrides
offer.promo	If the user selects a package that includes a promotional offer	Visibility and text overrides
package.identifier	If the user selects a package that matches the defined identifier	Visibility only
Custom variable	If the paywall is rendered with or without the defined custom variable.	Visibility only
offer.multiphase	If the user selects a package that includes a promotional offer	Text overrides only

How to create your first Paywall Rule

To create a Rule for your paywall, navigate to paywall editor and select the Paywall logic tab from the left sidebar. You will see the following button to create a new rule:

Creating a rule has two parts:

Selecting the Rule that will control component visibility
Selecting either existing or new components that the rule will be applied to

A purple highlight around the preview indicates that you’re viewing how paywall look like with Rule applied.

When viewing your rule, any component that you add will be set to only be visible for that Rule. You can edit this later if you require the component to be visible in more cases.

Rules are evaluated at runtime, after publishing your paywall, which allows multiple rules to exist on a component. Rules are applied to a component in the order defined in the table above. Custom variable rules are evaluated in alphabetical order.

Current limitations of Paywall Rules

Paywall Rules are supported on most components that you can add to your paywall, with the following limitations:

Express checkout buttons
Individual pages of a carousel
Individual tabs
Footer
Sheet
Purchase Button

Wrapping up

Paywall Rules make it easier than ever to build smart, context-aware paywalls without the overhead of maintaining multiple paywall variants. Whether you want to highlight a trial offer, swap out packages based on a custom variable, or tailor messaging for promotional offers, a single paywall can now handle it all.

As we continue to expand the supported components and rule types, we’re excited to see the creative ways developers and growth teams use this feature to drive conversions.

Give Paywall Rules a try and let us know what you think 👉 Paywall Rules documentation

Exit Offers in RevenueCat Paywalls: A Practical Guide for Android

Wed, 22 Apr 2026 00:39:29 GMT

When a user dismisses your paywall without purchasing, the conversion opportunity is lost. Exit offers change this by presenting a second offer at the moment of dismissal, typically a lower price, a longer trial, or a different plan. This is the same strategy e-commerce sites use for cart abandonment: catch the user on the way out with an alternative they might accept. RevenueCat’s paywall system supports exit offers as a dashboard configured feature that requires no code changes, but only if you present your paywall the correct way.

In this article, you’ll explore how exit offers work on Android, why the presentation method matters, how to configure them in the RevenueCat dashboard, the correct code for both PaywallDialog and PaywallActivityLauncher, and the common mistake that silently prevents exit offers from appearing.

What exit offers are and when they trigger

An exit offer is a secondary paywall that appears automatically when a user dismisses your primary paywall without making a purchase. The flow looks like this:

User sees the main paywall (e.g., an annual plan at $49.99/year)
User taps the close button or swipes to dismiss
Instead of closing, a second paywall appears with the exit offer (e.g., a monthly plan at $4.99/month)
User either subscribes to the exit offer or dismisses again, which closes everything

The exit offer is a separate offering configured in the RevenueCat dashboard. It has its own paywall design, its own packages, and its own pricing. The SDK handles the transition between the main paywall and the exit offer automatically.

Exit offers do not trigger when the user has already completed a purchase. If the user subscribes on the main paywall, the paywall closes normally without showing the exit offer.

The presentation mode requirement

This is the most important point in this article: exit offers only work with PaywallDialog and PaywallActivity on Android. They do not work with the Paywall composable embedded directly in your layout.

Presentation method	Exit offers supported
`PaywallDialog` (Composable)	Yes
`PaywallActivityLauncher` (Activity)	Yes
`Paywall` composable (embedded)	No

The reason is structural. PaywallDialog and PaywallActivity control their own dismiss flow. When the user taps close, the SDK intercepts the dismiss action, checks if an exit offer is configured, and presents the exit offering before actually closing. The Paywall composable, on the other hand, is embedded directly into your Compose layout. It has no concept of “dismiss” because it is just a composable in your navigation graph. There is nothing to intercept.

If you are currently using the Paywall composable and want exit offers, you need to switch to PaywallDialog or PaywallActivityLauncher. The migration is straightforward and covered in the sections below.

Setting up exit offers in the dashboard

Exit offers are configured entirely in the RevenueCat dashboard. No code changes are required once your paywall is presented with a supported method.

Create the exit offer offering. In your RevenueCat project, create a new offering (e.g., “exit_offer_monthly”) with the packages you want to show as the exit offer. This could be a discounted monthly plan, a longer free trial, or a different product entirely.
Create a paywall for the exit offer offering. Attach a paywall to the exit offer offering using the Paywalls editor. Design it as you would any other paywall. This is the screen the user will see after dismissing the main paywall.
Link the exit offer to your main paywall. In the Paywalls editor for your main paywall, open the exit offer settings and select the exit offer offering you created. This tells the SDK which offering to present when the user dismisses.

Once linked, the exit offer is live. The SDK handles preloading the exit offering data, intercepting the dismiss action, and presenting the exit offer paywall.

Presenting with `PaywallDialog`

PaywallDialog is the recommended way to present paywalls in Compose. It displays the paywall as a full screen dialog on compact devices and a standard dialog on tablets. Exit offers work automatically.

The simplest setup uses setRequiredEntitlementIdentifier to show the paywall only if the user does not have a specific entitlement:

If you need custom display logic, use setShouldDisplayBlock:

No additional code is needed for exit offers. The PaywallDialog handles the flow internally: it preloads the exit offering on display, intercepts the dismiss action, and transitions to the exit offer paywall if configured. The setDismissRequest callback fires only when the user has fully dismissed both the main paywall and the exit offer (or if no exit offer is configured).

When using setShouldDisplayBlock together with an exit offer, the SDK also evaluates the block before showing the exit offer. If the condition returns false (for example, the user purchased on the main paywall and now has an active entitlement), the exit offer is skipped and the dialog closes directly.

Presenting with `PaywallActivityLauncher`

For apps that do not use Compose or prefer an Activity based approach, PaywallActivityLauncher launches the paywall as a separate Activity. Exit offers work automatically here as well, the SDK launches the exit offer as a second Activity on top of the first.

When the user dismisses the main paywall Activity, the SDK automatically launches the exit offer Activity on top. If the user purchases from the exit offer, the result is PaywallResult.Purchased. If they dismiss the exit offer too, the result is PaywallResult.Cancelled. The onActivityResult callback handles both scenarios uniformly.

To launch without an entitlement check, use launch() instead of launchIfNeeded():

The embedded `Paywall` composable: Why exit offers do not work

If you are embedding the Paywall composable directly in a navigation graph, exit offers will not trigger:

The Paywall composable renders the paywall content directly in your layout. When the user taps the dismiss button, onDismiss navigates back via navController.popBackStack(). The paywall has no opportunity to intercept this dismissal and show an exit offer because the navigation action happens immediately.

If you want exit offers while keeping a navigation based flow, replace the embedded Paywall with a PaywallDialog placed inside the screen composable:

The behavior is identical from the user’s perspective, a full screen paywall appears and can be dismissed, but the PaywallDialog manages the dismiss flow internally, enabling exit offers.

How exit offers work under the hood

When a paywall loads, the SDK calls preloadExitOffering() in the background. This method checks whether the current paywall’s configuration includes an exit offer reference (an offering ID stored in PaywallComponentsData.exitOffers.dismiss.offeringId). If it does, the SDK fetches that offering from RevenueCat’s backend and holds it in memory.

When the user taps close, the SDK checks two conditions:

Has the user completed a purchase? If yes, close normally. No exit offer.
Is there a preloaded exit offering? If yes, present it instead of closing.

For PaywallDialog, the transition works through a state swap. The current dialog offering is set to null (closing the current paywall), and the exit offering is set as a pending offering. A LaunchedEffect detects this transition and opens the exit offer as a new dialog.

For PaywallActivity, the transition launches a new Activity. The exit offer Activity uses the same PaywallActivity class but with the exit offering’s ID passed as an argument. The result from the exit offer Activity is forwarded back to the original caller.

The SDK also tracks exit offer events for analytics. When an exit offer is shown, a paywall_exit_offer event is recorded with the exit offer type (dismiss) and the exit offering identifier. This data appears in RevenueCat Charts, letting you measure how exit offers affect your conversion funnel.

Platform differences

iOS

Exit offers on iOS work with presentPaywall() and presentPaywallIfNeeded(). They do not work with PaywallView embedded in SwiftUI. This is the same structural limitation as Android: the presentation method must control the dismiss flow.

One important consideration: Apple’s App Store Review Guideline 5.6 (Developer Code of Conduct) has been cited in some rejections for apps that show additional offers when the user tries to dismiss a paywall. Apple’s definition of “manipulative practices” is subjective, and enforcement is inconsistent across reviewers. Some apps use exit offers on iOS without issues, while others have been rejected. If you want to start with a safer approach, use RevenueCat’s Targeting feature to enable exit offers only for Android users.

React Native

Exit offers work with the presentPaywall and presentPaywallIfNeeded functions. They do not work with the <RevenueCatUI.Paywall> component embedded in your layout. The pattern is consistent across all platforms: only presentation methods that control the dismiss flow support exit offers.

Kotlin Multiplatform

Exit offers are not yet supported in the RevenueCat KMP SDK.

Conclusion

In this article, you’ve explored how exit offers work in RevenueCat’s paywall system on Android, from dashboard configuration to the correct presentation methods. The key takeaway is that exit offers require PaywallDialog or PaywallActivityLauncher. The Paywall composable does not support them because it has no dismiss flow to intercept.

Understanding this distinction helps you choose the right presentation method from the start. If you plan to use exit offers, build your paywall integration around PaywallDialog (for Compose) or PaywallActivityLauncher (for Activity based flows). If you are already using the embedded Paywall composable, switching to PaywallDialog is a small change that unlocks exit offers without altering the user experience.

Whether you are implementing exit offers for the first time, migrating from an embedded paywall to a dialog based one, or evaluating how exit offers could affect your conversion funnel, the patterns in this article give you a clear path to get them working correctly on Android.

As always, happy coding!

— Jaewoong (skydoves)

Write the Tweet before you build the product

Tue, 21 Apr 2026 14:06:04 GMT

In the early 2000s, Amazon popularised a product development framework that has since become Silicon Valley folklore: the Working Backwards method. Before writing a single line of code, Amazon product managers were required to write the press release announcing the product’s launch. The logic was simple but ruthless: if the press release wasn’t compelling, the product wasn’t worth building.

Today, consumer attention spans have shrunk from the length of a newspaper article to the length of a TikTok video. As growth advisor Phil Carter noted in a recent episode of the Sub Club podcast, the Amazon memo has evolved for the AI era:

“Now instead of a news article, it’s a Tweet or a TikTok video,” Carter explains. “It is really helpful to start with the end in mind because the reality is no matter how good your product is, if people aren’t willing to give it a shot, it’s not going to matter.“

For modern subscription apps, especially those leveraging AI, the new forcing function for product development is this: write the Tweet before you build the feature.

The ElevenLabs approach to feature launches

This isn’t just a theoretical exercise. It’s how some of the fastest-growing consumer AI companies actually operate.

Take ElevenLabs. In a separate Sub Club episode featuring their mobile growth leads, the team revealed that their product specs often begin as a literal Twitter thread. Before building launch assets, landing pages, or writing code, they ask one question: can the value of this feature be explained clearly in a Tweet?

If the answer is no, it’s a red flag. Writing the narrative first forces clarity. It prevents engineering teams from falling in love with a technically-impressive feature that users won’t actually care about. By starting with the Tweet, ElevenLabs ensures every feature they ship has a built-in hook for organic distribution.

The TikTok filter: demonstrability is distribution

This concept extends beyond X (formerly Twitter) to video-first platforms like TikTok and Instagram Reels. In fact, visual demonstrability is arguably the most important attribute a new feature can have.

“It’s almost a good filter when building products,” says Sub Club host David Barnard. “Would this make a good TikTok video?”

Consider the rise of Cal AI. In a crowded health and fitness category dominated by established giants like MyFitnessPal, Cal AI broke through by building a product experience that was inherently viral. Their hook was entirely visual: take a photo of your meal, and the app instantly calculates the macros.

Is machine vision calorie tracking perfectly accurate every time? No. But as a product experience, it’s magical. More importantly, it’s demonstrable in three seconds. That demonstrability fueled a massive wave of user-generated content (UGC) and paid ad performance, propelling the app’s rapid growth.

As Joseph Choi highlighted in another Sub Club conversation about TikTok virality, platforms with algorithmic feeds reward products that can instantly communicate their value proposition visually. If your core feature requires a three-minute tutorial to understand, it will struggle to find organic traction.

Building for the ‘automagical’ moment

The ‘write the Tweet’ philosophy is ultimately about engineering an ‘automagical’ first-time user experience. In an app ecosystem where the average consumer is bombarded with thousands of ad impressions daily, and where hard paywalls often convert 5x better than freemium models, you have a very narrow window to prove your worth.

When you write the Tweet first, you are forced to distill your product’s value into its most potent form. You are designing for the aha! moment; for the exact moment a user realizes your app solves their problem in a way they’ve never seen before.

A perfect example of this is the screen time app one sec. Founder Frederik Riedel built the initial prototype in a weekend to solve his own social media habit. A single, well-crafted Tweet demonstrating how the app forced a deep breath before opening Instagram drove months of sustained organic growth. The product was the marketing.

How to apply the tweet first framework

If you want to implement this in your own product development cycle, start by adding a mandatory section to your product spec templates. Before detailing the technical requirements or user flows, require the product manager to draft:

The hook: a 280-character Tweet announcing the feature. What is the single most exciting thing about it?
The visual: a description of the three-second video clip that would accompany the Tweet or serve as a TikTok ad. What exactly is happening on screen?
The user testimonial: what is the specific, enthusiastic quote you want a user to leave in an App Store review after trying it?

If your team struggles to write these three elements, you likely have a positioning problem — or worse, a product problem.

As Phil Carter puts it, “You need to start with the end in mind, which is how are you going to get your first hundred or first thousand users? And part of that is writing the Tweet upfront or figuring out what the TikTok video needs to look like upfront.”

In the AI era, shipping fast is table stakes. Shipping features that actually resonate requires clarity. So next time you’re debating a feature on your roadmap, don’t ask if you can build it. Ask if you can tweet it.

6 steps to design a freemium tier that drives upgrades

Tue, 21 Apr 2026 11:49:45 GMT

It’s tempting to jump straight to tactics when it comes to freemium. There’s so much more you can do than just a hard paywall: engagement moments, upgrade triggers based on usage, contextual nudges… I’m getting excited just writing about it!

But what deserves more attention is working out what to offer free vs. paid. There’s a lot of generic advice out there:

“Give them a taste of premium”
“Provide value”
“Balance value and pushing upgrade”

None of which answers the tricky question: what do you offer in your free versus premium tiers? How did freemium giants like Duolingo, Slack, and Strava figure out what belongs in each?

That’s what I want to cover here. I promise to stay strategic rather than tactical, but practical enough that you and your team can actually use this to decide what belongs in each tier. Follow this step-by-step process, and you’ll end up with a clear, defensible freemium strategy.

What does the data say about free vs. paid?

Before we begin, a quick note: the numbers can make freemium look like the underdog: hard paywall products have median conversion rates of about 10.7%, compared to 2.1% for freemium models, and can generate roughly 8× more revenue per install after 14 days. While it’s true that hard paywalls can be huge performers, it’s not the rule. And that’s only the median story.

The strongest freemium products — think of companies like Duolingo, Slack, and Strava — show how wide the performance spread can be. Top freemium apps can achieve retention rates between 42.4% and 58.1%, far outperforming average outcomes.

Retained subscribers after 1 year, by access methods — State of Subscription Apps 2026

In other words, freemium rewards exceptional execution: the difference between a mediocre strategy and a great one is enormous, and getting the tier design right is what determines whether you land in that top bracket.

So, let’s jump into six steps to creating a freemium strategy that actually drives upgrades.

Step 0: is freemium even right for you?

I’d be doing you a disservice if I skipped this step, but if you’ve already thought this through, no offence taken at all — jump straight to Step 1.

Still with me? Let’s cover the considerations when deciding if freemium is right for your app.

Understanding audience size in free vs. paid

The first consideration is audience size. If you’re building a product you want to scale broadly, freemium is usually the default choice. The word-of-mouth potential and advantage of a large top-of-funnel reach often outweigh the downside of a lower conversion rate. On the other hand, if your product serves a very niche audience, you may want to save yourself some time and go straight to a hard paywall model (possibly paired with a trial).

If you compare day 35 downloads to paid for freemium vs. hard paywall, the averages differ greatly:

Day 35 download-to-paid, freemium vs. hard paywall — State of Subscription Apps 2026

That means that, in a freemium model, you typically want at least ~1,000+ free users to build a meaningful paid cohort. Based on these ranges, if you have around 5,000 users, freemium might yield roughly 110–225 paying customers, whereas a hard paywall could convert closer to 325–1,085.

If you’re unsure whether your audience is large enough to support a freemium strategy, it’s worth estimating your Serviceable Addressable Market (SAM) to see whether you can realistically reach the scale needed for freemium to work.

Unless you have a very good reason why people would convert at a higher-than-average rate — Slack converts at over 30% because of its business case and strong freemium strategy — the math needs to work for lower conversion rates.

Revenue delay within freemium apps

Freemium apps tend to lean toward more habit-forming, viral products. That virality comes at a cost: there is a delay in revenue. Hard paywall users mostly convert on Day 0, while a larger share of freemium users convert weeks after download, meaning you need the runway to wait:

Average revenue per install (RPI) after 14 days, split by access method and pricepoint — State of Subscription Apps 2026

Willingness to pay and pricing confidence

It’s harder for newer apps to understand willingness to pay with a freemium model because you need a bigger audience to learn from. Is it not converting because people won’t pay — or is it converting less because of freemium? For new apps, it could be worth temporarily starting with a hard paywall to learn, then switching to freemium once you understand your price sensitivity better. Alternatively, if you expect word-of-mouth to be your primary growth driver or you’re in a crowded market, you can take the Headspace approach: start with a very generous free tier and then, over time, move more behind the paywall.

Don’t let freemium make you timid on pricing

There’s no published data directly showing that freemium apps charge less than hard paywall apps, but in my experience, the tendency is there — and it’s a trap. RevenueCat’s data shows that higher price points actually drive better Day 35 conversion rates (2.8% median vs. 1.4% for low-priced apps) and higher revenue per install.

Day 35 download-to-paid, by pricepoint — State of Subscription Apps 2026

The logic is counterintuitive but sound: if someone has experienced genuine value in your free tier and still chooses to upgrade, they’re a high-intent buyer. Price accordingly. Your generous free tier should give you confidence to charge more, not less.

Step 1: what is your goal with freemium?

You’ve decided freemium is right for you. Now the question is what you want that free tier to do for your business.

Your goal shapes everything that follows: how generous your free tier is, where you draw the paywall line, and how aggressively you push for upgrades. People often think freemium’s main benefit is purely for word-of-mouth or volume, but freemium can serve many goals.

1. Stand out in a competitive market

Healthi, a weight-loss app, intentionally went freemium because its major competitors — Weight Watchers and Noom — didn’t offer a free version. This helped them gain traction and stand out in a crowded market.

When standing out from the competition is your goal, you’ll typically want a generous free version to begin with. You’re using free as a wedge against incumbents. Over time, as you establish your position, you can tighten the free tier and charge more — similar to what Headspace did and what we see with several larger AI apps.

2. Drive organic growth through word-of-mouth

People are much more likely to recommend a free app than a paid one, and many freemium apps benefit from running fewer ads as a result. Duolingo’s former VP of Product, Cem Kansu, put it bluntly on the Sub Club podcast: at Duolingo, free users were never treated as freeloaders. They were the primary distribution channel. Around 80% of new users arrive organically, powered by viral loops, shareable progress, and the app’s built-in motivation systems.

When this is your goal, you need to think carefully about how to ensure free users get enough value to recommend you, and whether you can build viral loops into your freemium model. If free users don’t love the product, there’s nothing to spread.

3. Help build a habit

Some apps naturally take longer to build value or to understand. In these cases, freemium can give you time to convert users who a trial (rarely longer than 30 days) simply can’t.

When this is your goal, think about the actions needed to get the user far enough along to pay. For example, Fitbod, a fitness app, offers three workouts completely free before you need to pay. After three workouts, you’re starting to get into the habit of using the app and seeing the value. The free tier isn’t about generosity, it’s about giving users enough runway to form the habit.

4. You need volume for your app to work

Some apps need scale for their core product to function, whether that’s data, community, or network effects.

For example, I worked with an IBS app that was just starting out. Their main feature of value was a powerful scanning tool that helps you understand what you can and can’t eat based on what triggers your gut health issues. They were intentionally very generous with the scanning tool — more generous than they needed to be — because every new market they entered, they needed a lot of data on what foods to include, and this was cheaper and easier to source through user data than external data sources. For one new market they were testing, they went so far as to omit a paywall entirely because their data outweighed short-term revenue.

If their goal had been just word-of-mouth, they could have offered less, which is exactly what they did in their main market, where they already had enough data. They still grew substantially organically, resulting in YoY revenue up 70%–80% and paid conversions rising from 6.6% to 13.7% (well above average for freemium).

Strava is another example: free users recording activities generate the route data, segment data, and social activity that make premium features like heatmaps, leaderboards, and route suggestions valuable. The more people tracking for free, the better the paid product becomes making it worthwhile having a generous free tier.

5. Have a positive impact on the world

The final reason is a tricky one. I’ve worked with an app that genuinely grew out of a desire to help people (one of the best parts about specialising in wellness apps). They had a very generous free tier: you could use the main features without ever paying. But people weren’t activating as much as premium users — we’re talking 1%-2% active for freemium vs. 60% for premium.

With free user activation being extremely low, they weren’t actually achieving their impact goal. You need to find ways to stay true to this mission while actually delivering value. For example, when Headspace removed its freemium content, it still offered free meditations on YouTube to stay true to its goal of having a positive impact, just through a different channel.

So start by defining your main goals to ensure you design your model the right way. Depending on your goal, you may intentionally choose to be more or less generous.

Step 2: define what user success looks like

Your users have a job they’re trying to achieve with your app, and when they achieve it, they retain. If you have the data, look at what it shows for paying users; if you don’t, define the actions that will predict success.

I like how Alice Muir Kocourková explains it:

“Free users should be able to achieve meaningful progress toward their goal — but not reach the full solution.”

So you need to know not only your goal, but theirs too. That then allows you to work backwards to what actions get them to that point.

Step 3: choose your freemium architecture

Based on the above, you can now think through how to shape your freemium setup. Not all freemium models are built the same way. Some apps offer very different features for free vs. premium users, while others offer a taster of premium features. Before you map individual features to free and paid, you need to decide how the free tier relates to the paid tier. There are three broad approaches, each suited to a different type of product.

1. The taster model: same product, with limits

Here, users get the full product experience up to a certain limit. The free version doesn’t feel stripped down, it feels complete enough to use and get real value. The upgrade trigger comes from usage growth, not from missing features.

Loom, the video-sharing platform, is a great example. I used it for free for a good year, maxing out at 5-minute recordings and saving up to 25 videos. I didn’t use it often, so I’d occasionally delete older videos to make room. Over time, I started seeing the value, and I reached a point where five minutes felt frustrating, and sending four separate videos to a client did not exactly scream professional. I switched to paid and have been a loyal customer for years.

Other examples include Zoom (free users get the same tools but hit a 40-minute limit) and Notion (same editor and workspace, but with block limits and limited guest invitations).

When this works well:

Usage impacts value: saving more videos, longer recordings, more storage are genuinely more valuable as you use the product more.
Your core value is what drives word-of-mouth, so you want or need free users to experience the real thing.
There’s a natural inflection point where casual usage becomes serious usage. Think of it as the ‘defining the relationship’ moment — you don’t want an app situationship.

For this to work, you need to identify, or create, that natural inflection point where casual clearly becomes serious. Set limits too high and users never hit them; set them too low and the free tier feels like a trial with extra steps.

2. The split model: different features for different jobs

Here, free and paid users get distinctly different capabilities. Premium isn’t ‘more of the same’ — it’s a different set of tools serving a different (usually more advanced or professional) use case.

For example, CapCut, the video editing app, offers basic video editing features for free, but as I edited my video and wanted fancier subtitles and better editing tools, it was indicated that these were premium features. I could edit without them, but for a business use case where I wanted a more polished result, paid made sense.

Surfline, a surfing app, works the same way. Casual once-a-year surfers only need a basic forecast, and the free app handles that well. Serious surf fanatics want extended forecasts, wave timeline features, and detailed swell data.

As a casual surfer myself, I just want to know whether I can surf (and hope I can stand up). I have no clue what the wavelengths and frequencies mean. But as those casual users start to fall in love with surfing (or move closer to a beach), they may become paid users at a later stage.

When this works well:

You serve distinct user segments with different needs (casual vs. power user, personal vs. professional, individual vs. team)
Paid features have meaningfully higher value, or higher cost to serve, that justifies a separate tier
Free features are strong enough to stand alone — they’re not just a teaser for what’s behind the paywall

The risk: If the split feels artificial, e.g. if users constantly bump into locked features during their normal workflow, it creates frustration. So the locked features should feel like a different destination, rather than a roadblock on the same path.

3. The hybrid model: taster limits + split features

Many of the best freemium apps combine both approaches: some features are available to everyone with usage limits, while others are exclusively premium. This gives you two distinct upgrade triggers: “I need more of what I already use” and “I want access to something new”.

Slack offers you a taster, or well, practically a full free meal. You get the full workspace experience, but message history is limited to 90 days, and you’re capped on integrations. Yet features like Slack Connect (cross-organisation channels) are fully premium, because they’re classic business features that signal a team should be able to pay. Casual teams never need them; business teams can’t live without them.

ChatGPT works similarly too: free users get access to capable models with usage limits (taster), while advanced models, deeper reasoning tools, and higher-volume image generation are premium-only (split).

And Duolingo also does the same: free users get all lessons (the core product) with ads and limited ‘hearts’ (taster), while unlimited practice, progress quizzes, and offline access are premium-only (split).

When this works well:

You have both a broad casual audience and a smaller power-user segment.
Some features scale with usage (good for limits) while others are binary; you either need them or you don’t.
You want multiple upgrade triggers at different points in the user journey.

Which approach is right for you?

If you aren’t sure, these questions can help:

Does your product’s value increase with usage volume? (More messages, more storage, more recordings.) Lean toward the taster model. Set limits where casual use flips into serious use.
Does your product serve clearly different user types? (Hobby vs. professional, individual vs. team, consumer vs. business.) Lean toward the split model. Gate features by segment, rather than usage.
Is your user base very broad, with a wide spectrum of needs? Lean toward the hybrid model. Use taster limits for the core experience and split features for power tools.

Don’t feel like you need to set and forget; this may be something you test and evolve as you learn. Your architecture can change over time, it’s much easier to tighten a generous free tier than to loosen a restrictive one.

Step 4: map your free vs. paid offering

Now, this is likely to be something you will optimize and experiment with vs. set-and-forget, but you need to start somewhere. Based on the above, if you’ve worked that out already, this step should feel quite natural.

Now, this is likely to be something you’ll optimize and experiment with rather than set and forget, but you need to start somewhere. If you’ve worked through Steps 1–3, this step should feel quite natural.

For each feature, map out whether it’s free, paid, or limited — and critically, write down the strategic rationale for why. This forces you to articulate the reasoning, which makes it much easier to revisit later and to align your team. For example, here’s how some of Strava’s features map out:

Feature	Free	Paid (Summit)	Strategic rationale
GPS activity recording	✓ Full access	✓	The product is about tracking. Gating it kills the network. Every recorded activity = content for the social feed.
Activity upload from devices	✓ Garmin, Apple, Wahoo etc.	✓	Device integrations expand the top-of-funnel. Every synced watch is a distribution channel.
Segment leaderboards	Limited (personal only)	✓ Full leaderboards	This is the upgrade hook. Competitive athletes need to see where they rank so this is a natural “aha moment” trigger.
Power analysis (cycling)	✗	✓	Niche but extremely high willingness-to-pay. Cyclists already spend thousands on gear.
Clubs & group challenges	✓	✓	Clubs are viral loops: each club invite is organic acquisition. Free access maximises reach.

A few additional considerations as you map this out:

1. Keep AI costs in mind

If your app uses AI features, some things you’d like to offer for free may simply be too expensive to give away. This is reshaping freemium for AI-first apps: rather than gating features, many are adopting usage-based models where free users get a set number of credits or queries.

ChatGPT, for example, doesn’t lock features so much as it limits how much of the best model you can use before you need to upgrade. When mapping your features, note the cost to serve alongside the strategic rationale — it may override your preference.

2. Consider platform-specific differences

Your strategy may need to differ for iOS and Android, based on the differences in how those user groups monetise. Lose It! has a platform-specific paywall strategy: the same feature (barcode scanner) is free-with-ads on Android, but paid on iOS. Some apps also lean more heavily on ads for Android because there’s a lower likelihood of paying. This breaks the “sacred rule” of platform parity, but Lose It! led with data and adjusted based on what actually worked per platform.

3. Having your Bill of Rights in place

This might be the most important part of this step. As you map features to free and paid, you also need to define what you’re not willing to move.

Here’s the problem: it’s very easy to slowly shift more and more of your offering to premium, one experiment at a time, until the free tier offers little value. Each individual experiment might show a lift in conversion rate. But over time, the cumulative effect of reducing free value — on word-of-mouth, on user experience, on brand love — is almost impossible to measure until it’s too late.

Chris Hulls, Founder and CEO of Life360 (the family safety platform used by over 80 million active users), talked about exactly this on the Sub Club podcast. Life360 recently wrote a ‘Bill of Rights’ for their free users, an internal document that acts as a constitution for what cannot be touched. Whilst their Bill of Rights isn’t publicly available, to give you an idea of what it includes, Chris did share:

“This is probably the most important: the core map, location history, and place alerts, they must be free. Doesn’t mean we can’t move the paywall a bit, but real value there, no deceptive tactics… The real anchor is all around the lifeblood to who we are.”

Jacob Eiting, RevenueCat’s CEO, nailed why this matters in that Sub Club podcast: nobody runs a holdout group long enough to see the cumulative effect of chipping away at the free tier. You can A/B test removing any single feature, and retention looks fine. Do it 20 times, and you’ve quietly eroded the thing that made people love you.

I love the concept of the Bill of Rights and recommend taking notes on your own. This is likely a longer-term project, and if you are larger already, an internal discussion, but worth thinking through the following questions:

What must always be free, no matter what? These are the features that are the product. If you gated them, you’d kill the thing that keeps people coming back. (Life360: core map + location sharing + place alerts. Duolingo: daily lessons. Strava: GPS tracking and the social feed.)
What is the core value that free users receive, and is it real value, not a teaser? Chris’s test is simple: real value forever for free, period, rather than some crippled demo or a countdown to a paywall. A genuinely useful product someone could use indefinitely without paying.
What can we experiment with, and what’s off-limits for testing? Some things you A/B test aggressively (paywall copy, timing, pricing) and some things you never touch because they are core to the free experience.
What would make a free user feel cheated if we moved it behind the paywall? This surfaces the emotional contract, not just the functional one. Users might not churn immediately, but they’ll stop recommending you.
What dark patterns or ‘growth hacks’ are we explicitly ruling out? Life360 included this in their Bill of Rights: no deceptive tactics, no ads that interrupt the Job to be Done, no springing changes on users without notice. Writing down what you won’t do is as important as what you will.

Step 5: work out if a trial is needed

Sometimes newer freemium apps default to offering a free trial, thinking they need to. It’s well-intentioned, but definitely not a requirement. Rather, trials should be strategic: offering them when users need to experience premium features to understand their value, or only to highly engaged users or win-back users.

A few considerations:

1. Do users need to experience premium to understand it?

If your premium features are the kind of thing people need to try (like advanced analytics or personalized coaching), a trial makes sense. If the free-to-paid gap is self-evident from the free tier, e.g. “I can see the leaderboard exists but I can’t use it”, a trial may be unnecessary.

2. Consider reverse trials

Rather than a traditional free trial that ends and asks users to pay or leave, a reverse trial gives new users premium access for a limited time, then drops them to the free tier. This is increasingly popular in freemium apps because users experience the gap between paid and free from the perspective of losing something (loss aversion), which is a stronger motivator than never having had it.

It’s distinct from a traditional trial because the user lands on freemium rather than churning entirely.

3. Don’t go too long

In general, avoid overly long trials to prevent further delay of monetization. Daily-use apps can get away with a 3-day trial, while weekly-use apps may need 7 days. Match trial length to your app’s usage cadence so users have enough time to experience value but not so much that the urgency to decide disappears.

Step 6: start working on how you communicate and push for upgrade

Only once you’ve designed a strong setup can you jump to the part I got all excited about at the beginning: the tactics. It’s not to underestimate them; they just work 10x better once you’ve designed the foundations well. Alice Muir Kocourková shares some great pointers on how to do this in her article How to turn freemium users into loyal subscribers. I’d recommend prioritizing the following areas first:

1. Communicating freemium value

Not getting caught up on listing everything, but zooming in on the few drivers that matter to that user to upgrade. First, work on your overall upgrade message, then get fancier by improving based on user intent and usage (Alice has some great tips for this).

2. Onboarding for expectations

If your goal is word-of-mouth, you need to be much more intentional in onboarding so that the free experience is strong; if you are focusing on long-term conversion, you may push a bit harder for paid upfront.

How much you communicate about premium during onboarding is a strategic choice. But no matter your goal, don’t be too discreet. Nothing is worse than thinking an app is fully free, only to get a nasty shock after you’ve invested effort in setting it up and using it. That erodes trust fast.

3. Working hard on paywall timing and visibility

A common mistake in freemium is low paywall visibility. I was watching a show on the Channel 4 app (Okay, it was Married at First Sight: Australia, don’t judge me too much) and I got about 11 episodes in, being driven absolutely mad by the ads. I ended up Googling and discovered that I could upgrade to ad-free for £3.99. Maybe they earned more from me through the ads, but I was at the point of abandoning the show in frustration at the 10–15 minutes of ads per episode. Not knowing about premium nearly caused me to churn entirely.

Consider what the right moments in the journey are to surface your upgrade offer. Spotify is the gold standard here: their ad interruptions aren’t random annoyances, but carefully calibrated strategic friction — a reminder of what premium feels like, placed at the exact moment you’re most annoyed by the free experience. It’s no coincidence they achieve a 46% freemium-to-paid conversion rate.

The best freemium apps don’t just build a great free tier and hope people upgrade. They design specific moments throughout the user journey where the value of premium becomes undeniable, and then make it effortless to act on that feeling.

Freemium isn’t glamorous

Freemium is one of the hardest monetization models to get right, but when it works, it compounds: free users drive word-of-mouth, which drives more free users, which strengthens your product (through data, network effects, or community), which makes premium more valuable, which funds more investment in the free tier. It’s a flywheel, but only if the foundations are strong.

The work in this guide:

Deciding your goal
Defining user success
Choosing your architecture
Mapping features with rationale
Determining if you need a free trial
Writing your Bill of Rights

All of this isn’t glamorous. But it’s the difference between the median freemium app (2.2% conversion) and the top 10% (where freemium apps outperform even hard paywalls), so do the strategic work first, and then I give you full permission to go wild on the tactics.

We made our whole company vibe code apps — here’s what we learned

Mon, 20 Apr 2026 11:59:03 GMT

At RevenueCat we’ve seen a strong trend in first-time developers shipping apps and making their first dollars using vibe coding tools. The trend is clearly visible in number of developers making their first API call:

i still don't think i've fully comprehended the implications of this pic.twitter.com/U0KPe6F0TR
— Jacob Eiting (@jeiting) November 19, 2025

To understand this new wave of developers, we decided to become them.

Making everyone a customer

At the end of last year we kicked off an internal hackathon, titled Vibeathon, here at RevenueCat. The idea was simple: get everyone in the company to build apps using the same tools our customers are using. This included tools such as Vibecode, Rork, Claude, Cursor, and other agentic development tools — tools that allow non-engineers to build software.

Shipping quickly and often is one of the core values at RevenueCat, so we gave everyone until the end of January to build an app, add the RevenueCat SDK, and ship it to app stores. Out of the full RevenueCat company, 44 signed up for the hackathon, close to 30 apps got built, and 12 made it to app stores in time. The best part was that most people were from non-engineering functions.

Learning through building

Unsurprisingly, people ended up solving their own problems: building apps to track golf progress, recognize good firewood, scan receipts for taxes, and get book suggestions. Our hackathon showed the democratizing effect of vibe coding in microscale: cheaper build process makes it easier to target underserved niches.

One of the apps that was built during Vibeathon is Bygone. Bygone helps you understand today’s weather by showing how it’s changed since yesterday

Before publishing this article I took a look at how much money the built apps have made, and at the moment these apps sit at a bit over $700 in revenue since the beginning of the year. Not enough for anyone to retire, but enough to signal that we built things people found valuable. Comparatively, the two batches of Shipathon (2024 and 2025) have collectively made over $5.5 million, so our apps have some catching up to do still.

Fast to build, hard to understand

The focus of this hackathon was learning, and we ended up learning about our product, customers, and the vibe coding movement more than we could have expected.

During the Vibeathon people were building fast and iterating quicker, but a lot of people emphasized how little they actually gained understanding in what was being built. Apps ended up being blackboxes that rely on AI to make improvements. When Apple would reject the app because of a bug, the participants could not diagnose the problem themselves, but had to go back to the AI and hope that it could fix it. Vibecoders are not authors of the product, but operators.

Some participants wanted a more structured approach and created SPEC.md and AGENTS.md to describe how agents should approach the tasks and what patterns to avoid. After that Codex was capable of one-shotting the app during dinner time, signalling that skill in vibecoding is not prompting, but specification writing. Good spec of course requires good understanding of the development concepts that the agent needs to follow. Essentially you’re aiming at getting a good output from a junior developer.

Most apps were built with React Native (with few Swift exceptions), and all but one targeted iOS. This was also the only platform most of the vibe coding tools support, despite React Native being a cross-platform framework.

The App Store was the hard part

Vibeathon brought in a lot of people who had not previously built apps, or had maybe built an app a decade ago and not touched App Store Connect or Play Store Console after that. For most people it turned out that building the app is the actual easy part, and getting it approved through Apple’s and Google’s reviews is the hard part.

This could be called the last mile problem of vibe coding, when code and implementation become cheaper and more approachable by masses, the real moat is in turning those things into apps and services that users can actually download.

People also struggled with setting up accounts, in some cases it taking Apple a few weeks to ensure that all required documentation was in order to deploy an app. The contrast is huge, when building an app can take just 5 minutes, but becoming able to distribute can take weeks. This is one of the topics we plan to focus on in the new StartApp School program, by providing detailed guidance on how to set up your Apple and Google Developer accounts.

Monetizing remains a big hurdle as well. Adding RevenueCat SDK is easy, but Apple and Google have both made it very difficult to be compliant with all their in-app purchases rulings on the first try. Almost no app got through the review process the first submission, and most people reported the constant back and forth between fixing reported issues, to end up just getting new ones.

Make your people code

Even before we kicked off Vibeathon, RevenueCat was working on better support for different vibecoding tools. Last year we released our MCP, which allows you to setup and manage products in RevenueCat and App Store Connect through agents. We’ve since improved the MCP with more features, and improved the support for it in different vibe coding tools. RevenueCat dashboard also now supports more agent friendly setup flow, giving you the prompts to setup the SDK without having to do it yourself.

Vibeathon was the first time we forced people to work solo on these projects. The promise of vibecoding being that anyone from sales to marketing, and operations to engineering could build and monetize apps, without spending considerable time on learning how to code, or having previous technical experience. Understanding this is important as it is being embodied in our new customers as well, who are building apps with a similar setup: no technical background.

Your app got cloned. Now what? A developer’s guide to protecting your work from copycats

Thu, 16 Apr 2026 16:33:24 GMT

Building a successful app is hard enough — even in the age of vibe coding. So watching someone else copy your hard work, slap a new logo on it, and siphon away your revenue is infuriating.

The app ecosystem has always had a copycat problem, but recent advancements in AI and vibe coding have poured fuel on the fire — making vibe coded app clones one of the fastest-growing threats to original developers. Today, a functional clone of a validated app idea can be generated in days, complete with scraped marketing copy and a nearly identical user interface. When OpenAI launched its official Sora mobile app in late 2025, the App Store was immediately flooded with over a dozen “Sora” and “Sora 2” branded fakes, accumulating hundreds of thousands of downloads and generating significant revenue before Apple intervened.

For developers, the question is no longer if your successful app will be copied, but when. And more importantly: how do you protect your app from copycats — legally and practically?

In theory, intellectual property (IP) law provides a robust shield. In reality, the gap between legal theory and the practical experience of navigating App Store disputes is wide. Here is a breakdown of the IP instruments available to app creators, from copyright, patents, and trademarks, to how the platforms handle infringement claims, and the real-world strategies to actually protect your app.

The intellectual property toolkit

When developers discover a clone, their first instinct is often to claim, “They stole my idea!” Unfortunately, IP law does not protect ideas or concepts. It only protects the specific expression or implementation of those ideas. Understanding the different types of mobile app intellectual property protection is the first step in building your defensive moat.

First, here’s your toolkit at a glance:

IP instrument	What it protects	Cost and timeline	Practical utility for indie devs
Copyright	Source code, UI graphics, text	Low cost, automatic	Moderate (easy to circumvent by rewriting code)
Trademark	App name, logo, icon	~$350/class, 6-12 months	High (best tool for stopping deceptive clones)
Utility Patent	Algorithms, functional methods	$10k-$38k+, 2-4 years	Low (too slow and expensive for most)
Trade Secret	Proprietary backend logic	Cost of security measures	Moderate (only works if kept confidential)

Note: the table above is specific to the US. While many of the terms and tools work the same way across the world, we’ve gone into more depth on global IP tools further down.

Copyright: protecting the expression

Copyright law automatically protects the original expression of your ideas as soon as they are fixed in a tangible medium. For a mobile app, this includes the source code, user interface graphics, original text, and promotional materials.

However, copyright is limited by the tension between an idea and the expression of that idea. You cannot copyright the concept of a habit tracker or a meditation timer. If a competitor sees your app, understands how it works, and writes entirely new code to achieve the same functionality with different visual assets, they have not committed copyright infringement.

While copyright is automatic in most places — the Berne Convention ensures that a work is automatically protected as soon as it’s created — registering your work with the relevant authorities (such as the US Copyright Office) is highly recommended. Registration provides a public record of your ownership, makes enforcement significantly easier, and is often a prerequisite for filing a lawsuit or claiming statutory damages. In the US in particular, registration is a prerequisite for filing a federal infringement lawsuit and for claiming statutory damages, making it a practical necessity rather than a mere formality.

Trademark: protecting the brand

For most independent developers and small studios, trademarks are the most practical and effective legal tool. A trademark protects the elements that identify the source of your app — primarily its name, logo, and potentially a distinctive slogan.

When copycats strike, they often try to confuse users by adopting a name or icon that is deceptively similar to the original. A registered trademark gives you direct, actionable leverage to stop this — and is the clearest basis for an App Store trademark infringement complaint. Both Apple and Google have mechanisms to remove apps that infringe on registered trademarks, and having that registration certificate in hand dramatically speeds up the process.

There have even been instances where copycat apps claim a trademark before the original has, meaning these apps them generally win out in App Store battles. So it’s crucial to sort your trademark out before launching and giving anyone time to catch up.

While you establish “common law” rights simply by using a name in commerce, a formal federal registration provides nationwide protection and a presumption of validity. App trademark registration typically costs around $350 per class in the US — a worthwhile investment for any app showing traction.

Patent: protecting the functionality

Utility patents offer the strongest form of protection, safeguarding the novel and non-obvious functional aspects of an invention — the underlying methods, algorithms, and processes that make your app work. Unlike copyright, a patent prevents competitors from using your technical innovations even if they write their own code from scratch.

However, software patents come with significant hurdles. The process is notoriously slow, often taking two to four years, and prohibitively expensive for many indie developers, with costs frequently ranging from $10,000 to $38,000 or more. Not only that, but following the 2014 Supreme Court decision in Alice Corp. v. CLS Bank, obtaining patents for abstract software concepts has become increasingly difficult in the United States.

For well-funded startups with truly novel backend technology, patents are a critical asset. For the average indie developer building a utility app, they are rarely a practical first line of defense.

The exception: Frederik Riedel successfully patented onesec’s intervention mechanism, that is used to reduce users’ screen time, because he was worried about big tech companies copying his invention.

The global dimension: national vs. international protection

A common misconception among developers is that securing IP rights in their home country provides global protection. In reality, IP rights are territorial. A US trademark does not automatically protect your app in Europe, and vice versa.

For developers targeting a global audience, navigating international IP can be daunting. However, several frameworks simplify the process:

The Madrid System (Trademarks): Administered by the World Intellectual Property Organization (WIPO), the Madrid System allows you to apply for trademark protection in up to 132 countries by filing a single international application and paying one set of fees. This is significantly cheaper and easier than hiring local attorneys in dozens of jurisdictions.
The EU Trade Mark (EUTM): If Europe is a key market, filing a single EUTM application with the EUIPO provides immediate protection across all 27 EU member states for a base fee of €850. This is vastly more efficient than filing national trademarks in each European country.
The Patent Cooperation Treaty (PCT): For the rare indie developer pursuing software patents, the PCT provides a unified procedure for filing patent applications to protect inventions in over 150 contracting states, delaying the expensive process of entering national phases.

When deciding where to file, follow your user base and your revenue. If 80% of your subscribers are in the US and the UK, prioritize trademark registrations in those two jurisdictions before worrying about the rest of the world.

How the app stores handle disputes

When you spot a clone, your immediate goal is to get it removed from the store. Both Apple and Google provide dispute resolution processes, but navigating them requires understanding their underlying philosophies.

The Apple App Store process

Apple’s App Review Guidelines explicitly forbid copycats. Guideline 4.1(a) states: “Come up with your own ideas… Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own”.

When you submit a claim to report a copycat app through the Apple App Store Dispute Form, Apple typically forwards your complaint to the accused developer and encourages both parties to resolve the issue directly. Apple’s stated position is that it does not mediate IP disputes or investigate the underlying merits of complex legal claims.

If the accused developer fails to respond or provide a satisfactory defense, Apple may eventually remove the app. In clear-cut cases of trademark infringement—especially when the complainant provides a valid registration number—Apple often acts swiftly. However, in murkier cases involving UI similarities or copyright claims, the process can drag on, leaving the original developer frustrated.

The Google Play Store process

Google’s approach is structurally similar. Developers can submit a policy violation notice regarding intellectual property. Google forwards the complaint, encourages direct resolution, and may remove the app if the issue remains unresolved.

Both platforms have faced criticism for operating what some legal experts call a “black box” dispute system. Outcomes are decided privately, often with little explanation. This system can also be weaponized; there are documented cases of larger companies or bad actors filing baseless IP complaints that result in legitimate apps being temporarily removed without due process, simply because the platform wants to avoid liability. Beyond the legal routes, your subscription metrics can also serve as an early warning system — often long before a formal complaint is needed.

Using subscription data as an early warning system

Before you ever receive an angry customer support email intended for a copycat, your subscription metrics will likely show the first signs of trouble. Clones that successfully siphon your traffic don’t just steal random users—they steal your highest-intent users who are actively searching for your brand.

According to RevenueCat’s State of Subscription Apps 2026 report, which analyzed over 115,000 apps and $16 billion in revenue, the battle for a subscriber is won or lost almost immediately. You can use these benchmarks to detect if a copycat is impacting your funnel:

1. Monitor your Day 0 cancellation rate The report found that 55% of all 3-day trial cancellations happen on Day 0. If a copycat is intercepting your branded search traffic, users who intended to download your app will quickly realize they’ve been duped and cancel immediately. A sudden spike in Day 0 trial cancellations, especially from organic search traffic, is a strong indicator of brand confusion.

2. Watch your Download-to-Paid (D35) conversion Hard paywalls convert at a median rate of 10.7% by day 35, five times better than freemium models (2.1%). If you run a hard paywall and your D35 conversion rate suddenly drops while top-of-funnel installs remain steady or grow, it may mean lower-intent or confused users are entering your funnel while your high-intent users are being diverted to a clone.

3. Track involuntary churn anomalies If your app is cloned and the copycat aggressively monetizes users who thought they were buying your product, those users will often issue chargebacks or cancel their cards when they realize the error. The global benchmark for involuntary billing failures on Google Play is 31% of all cancellations (14% on the App Store). A sudden deviation from your baseline involuntary churn rate can signal that users are disputing charges related to brand confusion.

Theory vs. reality: the developer experience

The legal theory suggests a clear path: register your IP, file a complaint, and watch the copycat disappear. The reality experienced by developers is often much messier.

Consider the case of the Bend app, a popular stretching utility. When a near-identical clone appeared on the App Store, the original developers didn’t just rely on a simple form submission. They meticulously documented the similarities, creating side-by-side video comparisons of the onboarding flows and UI mimicry. They leaned heavily on Apple’s Guideline 4.1, engaged legal counsel to send formal cease-and-desist letters, and maintained constant pressure on both the platform and the infringing studio. It was this combined, multi-front approach that ultimately led to the clone’s removal.

Conversely, relying solely on the platforms can backfire. In one notable case involving the video app Reely, a major tech company filed a trademark complaint claiming logo similarity. Google, following its standard procedure, removed Reely without investigating the merits of the claim. The developer was forced to initiate federal litigation and secure a temporary restraining order just to force the parties to the negotiating table and get the app reinstated.

A practical playbook for protecting your app from copycats

Given the limitations of the legal system and the opacity of the app stores, how should developers protect their work? The most successful strategies combine proactive legal steps with strong business fundamentals.

1. Trademark early and often: Do not wait until you are successful to protect your brand. File a trademark application for your app’s name and logo as early as possible. When a clone appears, a registered trademark is the sharpest weapon you can wield to remove a clone from the App Store.

2. Document your development: Maintain meticulous records of your design process, code commits, and asset creation. Date-stamp your work. If you ever need to prove that you are the original creator and hold the copyright to the UI or code, this paper trail will be invaluable.

3. Build a comprehensive case: If you find a copycat, do not just send an angry email to Apple Support. Build a dossier. Create side-by-side visual comparisons. Highlight identical text strings, stolen marketing assets, and UI mimicry. Make it as easy as possible for the platform reviewer to see the blatant theft.

4. Utilize cease-and-desist letters: Often, a formal letter from an attorney on legal letterhead is enough to scare off a low-effort copycat. Many clone developers are looking for easy money and will fold at the first sign of genuine legal resistance.

5. The ultimate moat: brand and community: Legal tools are necessary, but they are reactive. The most sustainable defense against copycats is building a brand that users love and trust. A clone can copy your pixels, but they cannot copy your community, your customer support, or your reputation.

As one developer noted in a recent Hacker News discussion about the surge in AI-generated clones: “Your best moat against low effort copycats? Stamina”. Copycats are opportunistic; they rarely have the dedication to maintain the app, fix bugs, respond to user feedback, and continuously iterate. By moving faster and building deeper relationships with your users, you ensure that even if someone steals your interface, they can never steal your business.

RevenueCat Charts v3: fresher data, better decisions

Thu, 16 Apr 2026 02:12:49 GMT

We’ve rebuilt RevenueCat’s data infrastructure from the ground up.

That rewrite powers a big upgrade we’re excited to share today: Charts v3 — a new Charts experience that gives you fresh data in seconds, plus a bunch of new ways to slice, segment, and understand your subscription business.

At a high level, this new infrastructure unlocks two big things:

Real-time updates across almost every chart: instead of waiting hours or days for metrics from App Store Connect or Google Play Console, our new real-time events now flow into your charts as soon as they happen, so you can actually watch launches, experiments, and promos play out in real time.
A much faster path to new charts: because we rebuilt our analytics on a unified subscription model, it’s now way easier for us to ship new charts and dimensions — which is why, just in the last year of testing and refining this system, we’ve already added a ton of new charts and charting features.

You can see Charts v3 in your project today by enabling the “v3” toggle on the top right of any chart. When disabled, you will see the legacy chart data and new features enabled by Charts v3 will not be available.

What ‘real-time’ actually means

Previously, charts updated in batches every 2–12 hours depending on the dataset. Now, almost all charts refresh in real time as events come in, giving you:

Immediate feedback on launches, paywall tests, and promos
Better intra-day monitoring for spikes, dips, or anomalies
More consistent behavior across charts, since they’re all driven by the same live pipeline

Charts v3 currently supports App Store, Play Store, Stripe, and RevenueCat Web Billing apps, with support for our other supported stores coming soon.

Data shifts you may notice

When you enable Charts v3, you may notice some numbers shift compared to the “legacy charts”. That’s expected — and while we understand this may be temporarily disruptive, it’s ultimately a good thing. Here’s what’s going on at a high level, based on the new Charts v3 architecture:

A unified subscription model across stores

Behind the scenes, all charts are now powered by a single, normalized subscriptions model. Instead of treating each store slightly differently, we map store-specific behaviors into a shared model that’s consistent everywhere.

This new model lets us:

Distinguish product changes (e.g. switching from plan A to B) from simple renewals
Treat resubscriptions (coming back after a lapse) differently from continuous renewals
In our Active Subscriptions Movement chart, resubscriptions after a lapsed subscription are now called out as a separate positive line item. In the past, resubscriptions on the Apple App Store were instead shown as negative churn.

Other charts, like Subscription Retention and Trial Conversion, now align more closely with how you actually think about subscriber behavior (e.g. “this user changed products” vs. “this user renewed as normal”).

Refunds no longer rewrite history

Previously, when a payment was refunded, it could change metrics in already-completed periods. That made it harder to trust historic reports, and could cause numbers to ‘wiggle’ days or weeks after the fact.

With Charts v3, historical data stability is crucial:

Revenue is added on the day the purchase happens
If that payment is later refunded, the revenue is subtracted on the day of the refund, not retroactively

This means historical revenue for completed periods stays stable, and you’ll see negative revenue entries on refund dates.

The same behavior applies to conversions and LTV. The original purchase contributes to all relevant timeframes, and if it’s refunded, those contributions are removed only in the periods where the refund falls. Completed periods don’t keep shifting under your feet.

Changes to cohorting

We’ve also updated the cohorting methodology for Cohort Explorer and Prediction Explorer. Instead of defining big cohorts (like a whole month) using just the first and last calendar days, we now calculate each customer’s lifecycle relative to when they actually started, then aggregate the data.

In practice, this means:

Late-joining customers no longer have their early revenue ‘pushed’ into the next period
Cohort-based metrics like 0–30 day LTV are more consistent and easier to compare across time

Quick Reference: expected metric changes

Metric	Expected change	Reason for change
Trial Conversion Rate	Likely decrease	Only direct trial-to-paid conversions counted
Historical Revenue	May shift between periods	Refunds impact the refund date, not purchase date
Active Subscriptions	Minimal change	Counting method changed, not actual subscribers
MRR/ARR	Minimal change	Based on same active subscription count

RevenueCat mobile app charts may look different

The official RevenueCat mobile app has not yet switched to Charts v3, so you may see slightly different data until we have switched that over as well.

New charts and capabilities unlocked

Because the data model is now more flexible, we’ve been able to ship a bunch of new charts and features on top of Charts v3 already — with more on the way.

Period-over-period comparisons

A big upgrade built on Charts v3 is period-over-period comparisons. You can now compare your selected date range against the previous period with a single toggle in the Compare dropdown.

Churn rate over the last 12 months compared to the previous 12 months.

When enabled, charts will:

Plot both the current period and comparison period as separate lines
Show total values and percentage change in the summary
Let you hover over any point to see the percentage change vs. the previous period at that moment in time

Period-over-period is available on key charts like Active Subscriptions, MRR, ARR, Churn, New Customers, New Trials, Conversion to Paying, Refund Rate, and more.

New and improved dimensions

Charts v3 introduces new dimensions and tightens some existing ones, so segmentation matches how you actually reason about your business.

The segment picker has new grouping and now includes search to make it easier to find the right dimension.

New dimensions include:

Custom attributes: segment by the custom attributes you set on customers
Experiment: filter/segment charts by experiment and variant
App version: analyze metrics by the first app version a customer used
Attribution: filter/segment using Source, Campaign, Keyword, etc.

We’ve also improved existing dimensions:

Platform now refers to the customer’s first seen platform (where they originated), not the last platform they touched — so segmenting by platform is more stable over time
Country now prioritizes the app store storefront over IP-based location, aligning charts more closely with how revenue and subscribers are actually distributed across markets

For full definitions and edge cases, see the Charts v3 docs.

New Active Customers Chart

The new Active Customers chart plots all users that were seen in the period being measured, regardless of whether they’ve made a purchase. This works well to plot out your daily active users (DAU). An important note is that this chart does not yet correct for aliased customers, so in cases where the same customer appears under multiple linked app user IDs, active customer counts may be overstated.

Trial Conversion Rate

The new Trial Conversion Rate chart is cohorted by trial start date and focuses purely on the trial-to-paid step conversion, making it easier to understand how changes to acquisition, pricing, or paywalls affect payment behavior over time.

Updated Active Subscriptions Movement (state bar chart)

We’ve refreshed the Active Subscriptions Movement chart to better visualize how subscribers move between states (new, renewed, churned, product changes, resubscriptions, etc.) using a more intuitive state bar format.

Paywall charts

New Paywall Charts give you a dedicated place to understand paywall performance: conversion, drop-off, and downstream value, all segmented by the same dimensions you already use across RevenueCat.

You can also now filter and segment other charts by RevenueCat Paywalls, making it much easier to tie conversion and revenue outcomes back to specific paywall experiences and experiments.

Try Charts v3

Charts v3 is available in your dashboard today for apps using the supported stores.

If you notice differences in your metrics after switching, refer to the Charts v3 docs for a chart-by-chart breakdown of what’s changed and why — and, as always, we’d love your feedback as you start using it in your day-to-day decision making.

Why a hard paywall is the right answer for your app (until it isn’t)

Wed, 15 Apr 2026 12:52:51 GMT

As an independent growth advisor and angel investor, Phil Carter helps consumer subscription companies scale their growth engines. In a conversation with David Barnard on the Sub Club podcast, he breaks down the tension between maximizing short-term revenue with hard paywalls and building massive businesses through freemium models—and why the most powerful AI features might not need the most expensive LLMs.

Moving from checkers to chess: The multi-step paywall

For the vast majority of subscription apps, a hard paywall is the right answer. The data is clear: hard paywalls often convert five times better than freemium models. If you’re a bootstrapped startup operating with limited capital, it’s the most reliable and low-risk way to grow your business.

But for companies trying to build a billion-dollar business, freemium is often the only way to attract a massive user base at the top of the funnel. Phil Carter calls the transition from a hard paywall to freemium “moving from playing checkers to playing chess” because it requires significantly more sophistication.

Recently, Carter worked with a client to navigate this transition. Instead of simply dropping the paywall, they implemented a “multi-step paywall.” The product is free, but users are offered a seven-day trial of the best version. After the trial, they are prompted to subscribe to maintain that maximum value. Combined with pricing and packaging optimizations, this shift resulted in a 75% increase in LTV per user. The business moved from excluding users with a hard paywall to growing much more quickly through organic acquisition.

The trap of the value-to-noise ratio

With AI dramatically lowering the cost of software development, the pace of innovation has accelerated. It’s easier than ever to ship new features constantly. But this speed can become a trap.

“A fallacy that a lot of companies fall into is like, well, more products and more features equals more value and therefore we should just ship products and features as fast as we possibly can,” Carter explains.

The bottleneck isn’t development speed; it’s the capacity of the human brain to absorb the product experience. As an app becomes bloated with new capabilities, the absolute value might go up, but the complexity and noise increase alongside it. This causes the “value-to-noise ratio” to plummet. To combat this, teams must rigorously analyze which features actually drive long-term retention and aggressively prune the rest.

Why cheaper LLMs can build better products

It’s tempting to default to the most powerful frontier models from OpenAI or Anthropic when building AI features. But Carter points to Gamma, an AI-powered presentation tool that reached profitability within six months of launching its AI features in early 2023.

One of the reasons for Gamma’s rapid path to profitability was their savvy use of underlying LLMs. They didn’t always use the most powerful models. Instead, they found that for their specific use cases, longer-tail models provided performance that was “good enough” while delivering significantly faster response times and drastically lower compute costs.

“The product experience is a function not just of the output that the LLM provides, but also how fast it provides that output and how expensive it is to generate that output,” Carter notes. For many consumer apps, speed and affordability are more critical to the user experience than peak AI performance.

The 400-creative-per-month advantage

AI isn’t just changing the core product experience; it’s fundamentally altering user acquisition. Carter highlights Runna, a running app that used AI tools to exponentially increase their creative testing volume.

Runna went from producing tens of creative concepts per month to over 400. This massive increase in volume isn’t just about lowering CAC by finding winning ads faster. It creates a much more rapid learning cycle. By testing hundreds of permutations—using tools like ElevenLabs for voiceovers or Suno for background music—the marketing team learns exactly what resonates with users. Those insights don’t just optimize ad spend; they feed directly back into product roadmap decisions.

In the full episode, Phil also discusses how AI can turn the first 60 seconds of onboarding into a magical experience, why nicheification is the new strategy for crowded app categories, and the importance of building extrinsic triggers to form user habits.

Guest links:

Phil Carter on LinkedIn
Elemental Growth
Subversive Podcast
Consumer Subscription Growth Course (Maven)
@philgcarter on X

Frederik Riedel expected 12%. His app cut screen time by 57%.

Wed, 15 Apr 2026 10:37:16 GMT

After building between 50 and 100 apps, Frederik Riedel coded a weekend prototype to solve his own social media habit. When he accidentally triggered the app’s blocker just 20 seconds after installing it, he knew he had a real business. In a conversation with Charlie Chapman, the one sec founder breaks down how a single tweet drove months of growth, why ironic social media advertising works, and how an indie developer ended up with peer-reviewed research and a US patent.

The weekend prototype that proved itself in 20 seconds

Frederik Riedel had been building apps since he was 14 years old. By 2020, he had shipped somewhere between 50 and 100 apps—at one point releasing a new app every week, and even breaking App Store Connect tools that didn’t expect developers to have that many products.

But his most successful app started simply as a tool to solve his own problem during the COVID-19 lockdowns. Frustrated by how much time he was spending on Instagram and Twitter, but unwilling to go cold turkey, he built a prototype that intercepted social media app openings and forced him to do a brief breathing exercise.

The validation was immediate. “I built the first prototype on a weekend, put it on my own phone,” Frederik recalls. “Actually, when I installed the app on my own phone, 20 seconds afterwards, I accidentally ended up opening Twitter and I ran into my own app. And I was like, really, okay, I’m onto something here.”

Even the developer who had just written the code was operating on autopilot. Within two weeks of using his own prototype, his screen time dropped by 50%. He spent another two weeks polishing the app and released it as one sec.

When one sec launched, a simple screen recording of the app in action on Twitter went viral, driving thousands of downloads in the first few days. That single organic tweet fueled growth for months. But when Frederik wanted to scale, he turned to an ironic strategy: paying for ads on the very platforms his app was designed to block.

He started running ads on Instagram, and the results were explosive. “My revenue was kind of like doubling every single month,” he says.

The strategy worked because it was the ultimate form of targeted advertising. “Of course on social media, I find my target group of people that spend a lot of time on social media and want to spend less,” Frederik explains. Every single person scrolling through Instagram was a potential customer, and the ads caught them in the exact moment they were experiencing the problem one sec solves. It was the digital equivalent of his earlier strategy for a climbing app: putting physical posters up in climbing gyms.

The 57% constant and the power of peer-reviewed indie apps

Most indie developers rely on App Store reviews for social proof. Frederik went a different route: he partnered with the Max Planck Institute to conduct rigorous scientific research on one sec’s effectiveness.

The collaboration started when a researcher who used the app reached out. They set up an opt-in study where users donated their usage data. Frederik was hoping for a statistically significant 12% reduction in screen time. Instead, the data showed a massive 57% drop.

“All the experiments that we ran, they were always showing numbers around 57% reduction, which is kind of like almost seems like a nature constant of attention that you can steal from someone without noticing it,” he says.

That research became a massive competitive advantage. In a market flooded with snake-oil productivity apps, one sec had peer-reviewed evidence. Therapists began recommending it to patients. The app became a proxy for researchers who couldn’t get data directly from Meta or Snapchat, leading to partnerships with Stanford, Cambridge, and the governments of Germany, Denmark, and the UK.

Why an indie dev filed a US patent

With the research proving the app’s massive effectiveness, a friend from Silicon Valley pushed Frederik to do something unusual for a solo developer: file a patent.

The logic was simple. If the intervention worked this well, the big tech companies would eventually notice. A patent wouldn’t necessarily stop them from building their own version, but it would change the dynamic.

“This is the only way you can protect yourself from getting copied at some point,” Frederik says. “At least I wanted to give the big companies a reason to talk to me first before just copying or stealing my idea.”

It was an expensive and energy-intensive process, but having the peer-reviewed research data made the application much stronger. The US Patent Office approved it, giving this bootstrapped indie app a protective moat usually reserved for venture-backed startups.

In the full episode, Frederik also talks about getting an email from Apple for being an underage developer, how he manages a team of 18 people with zero management layer, and why he thinks Mastodon is the perfect non-addictive social network.

Guest links:

•Frederik Riedel on Mastodon

•one sec

RevenueCat supports app-to-web checkout — here’s why you shouldn’t use it

Tue, 14 Apr 2026 13:38:58 GMT

There is a version of this post that would probably perform better on social. It would say app-to-web is finally here, the economics are obvious, the app stores have been weakened, and every subscription app should rush to move checkout to the browser

I do not think that version would be very helpful

The honest version is simpler: yes, we support app-to-web checkout. We support it today with RevenueCat Billing / Web Billing, we support it with Paddle, we support Stripe Billing as a web billing system that can sync into RevenueCat, and we support Stripe Managed Payments in private beta

The other honest part is the one fewer people want to say out loud: most apps probably should not do app-to-web checkout

Not because it is impossible. Not because it is non-compliant in every case. Not because the tooling is not real. But because the financial upside is often overstated, while the operational, conversion, support, and retention side effects are understated. If you’re a large app with meaningful leverage, sophisticated lifecycle marketing, strong experimentation capabilities, and enough margin pressure to justify the work, app-to-web can make sense. If you are not, there is a good chance you are trading a simple problem for a much messier one

First, what we actually support today

If you strip away the noise and just look at the platform, RevenueCat Web is now a real product category for us. It includes a Web SDK, Web Purchase Links, a Web Purchase Button to link out from in-app paywalls, Web Paywalls, Web Funnels for web-to-app flows, and Redemption Links that help tie an anonymous web purchase back to the correct app user

The app-to-web flow we promote is straightforward in concept. A user starts on a paywall in your app, taps through to a web checkout, completes the purchase there, then comes back to the app via deep link or redemption flow and gets access unlocked. We keep entitlements in sync across app and web once the purchase is recognized

That sounds clean on a diagram because, to be fair, it is fairly clean on a diagram

In practice, the capability picture depends heavily on which billing engine you choose

Billing option	What we support today	Important caveat
RevenueCat Billing / Web Billing	Our own web billing engine with Web SDK and Web Purchase Links support, plus hosted purchase flows, subscription lifecycle handling, and customer management portal support	It uses Stripe as the payment processor underneath, but is a separate RevenueCat billing engine. Some limitations still apply, including localization gaps in some surfaces and country-specific billing-data limitations
Paddle Billing	We support importing Paddle purchases and support Paddle across Web SDK, Web Purchase Links, Web Paywalls, Web Funnels, and Redemption Links	Paddle-specific operational constraints still exist; for example, our Paddle integration does not currently support Paddle’s abandoned cart emails
Stripe Billing	We support importing external purchases from Stripe Billing and syncing entitlements back to the app Very soon, we’ll also support Web SDK, WPLs, Funnels, and Redemption Links	The main caveat is “which Stripe path are you actually choosing?.” Stripe Billing, Stripe Checkout, and Stripe Managed Payments solve slightly different problems, so teams should be precise about the implementation path they want
Stripe Managed Payments	We support this through the Stripe Billing integration, with Stripe acting as merchant-of-record for eligible transactions	It is currently a private beta / invite-only feature

That is the part I want to be very clear about, because ‘supports app-to-web’ can mean a few different things depending on what people hear. We do not just mean ‘you can hack a link into a button’. We mean there is now an actual product set for hosted web checkout, redemption, and entitlement sync. But it also does not mean every billing provider has identical maturity, identical feature coverage, or identical rollout status

There is another important nuance here. In the US, iOS developers are now permitted to guide users to web-based payment flows without additional Apple fees or restrictive design requirements following the Epic v. Apple ruling from early 2025. That’s in the US and on iOS only. For other platforms and other markets, app-to-web is sometimes possible, but always comes with additional fees, and reporting requirements. That means app-to-web is not a blanket ‘turn this on everywhere’ strategy. You need to make sure you control exactly who sees it and where

So why should most people not use app-to-web?

When people say ‘app-to-web’, what they often mean is ‘save 15% or 30% on store fees’. And what they often forget is that the fee is not the only thing that dictates how much money you take home at the end of the day

The first issue is the most obvious one:

1. Conversion usually gets worse

Every additional step between intent and payment hurts. Sending someone out of an app, into a browser or hosted checkout, through another authentication context, into a billing form, then back into the app is simply more fragile than native in-app purchase. Even if the flow is well designed, you are introducing context switching, more points of abandonment, more places for attribution to break, and more opportunities for a user to decide they’ll do it later. You might recover margin on the users who complete checkout, but if enough of them fail to complete it, the math stops looking clever

This is one of those areas where teams can accidentally fool themselves. If you only look at completed payer margin, web checkout looks great. If you look at paywall visitor to activated subscriber, it can look much worse. And for most subscription apps, the second number is the one that matters

The second issue is more uncomfortable because it can make your retention chart look better for the wrong reason:

2. People are often less aware of how to cancel web subscriptions

That can create the appearance of stronger retention or lower churn, but in many cases what you are really seeing is lower customer clarity. App store subscription management is not perfect, but users broadly understand where to go. The moment you split billing systems, some of your customers now manage on Apple, some on Google, some in Stripe, some in Paddle, some in RevenueCat Billing-backed web flows. That can absolutely reduce voluntary churn. It can also absolutely increase frustration, support load, refund requests, chargebacks, and a long tail of unhappy users who feel like billing became harder the moment they gave you money

In May of 2025, we launched a (much publicized) in-app purchase vs. web checkout experiment with an app we own. That experiment saw 6% fewer paying customers when we added web checkout. That same experiment currently has 2.7x (+170%!) more subscribers set to renew on web

	IAP only	IAP + web	Difference
Conversion to paying	7.8%	7.4%	– 5.1%
Active subscribers	211	209	-1%
Active subscribers (set to renew)	46	101	+ 119.4%
Churned subscribers	121	104	– 15%
Refunded customers	28	38	+ 35.7%

Those subscribers aren’t set to renew because, by paying on the web, they enjoy the app much more than they would if they paid via in-app purchase. They’re set to renew because they’ve forgotten to opt out of renewal

And that brings us to the third issue:

3. Chargebacks and disputes tend to become more material when you own more of the payment experience

App stores absorb a lot of mess for you. Once you move payment to the web, you get more control, but you also inherit more exposure. Tax handling, billing descriptor clarity, payment recovery behavior, lifecycle comms, cancellation UX, and support all become more consequential. Paddle and Stripe Managed Payments can help with the merchant-of-record and tax side for eligible flows, which is precisely why they exist, but that does not magically remove the conversion or support complexity of app-to-web. It just moves one painful category of operational burden off your plate

The fourth issue is the one small teams underestimate most:

4. The savings are often not that dramatic once you include all costs

We do not charge extra for RevenueCat Web itself, but the payment rails still do. In the US you pay 2.9% + 30¢ for Stripe processing, plus optional Stripe Tax fees where relevant. For Stripe Billing, our docs cite the same transaction fee plus Stripe Billing fees of 0.7% of volume, again before any tax tooling you may need. So say you’re selling a weekly subscription of $5 — you’d effectively pay Stripe close to 9%. Add the fee for Managed Payments, and you’re getting awfully close to the 15% most developers pay

If you are on Apple’s Small Business Program and paying that 15%, that is where the simplistic ‘save 12 percentage points’ narrative starts to fall apart. Between processor fees, billing software fees, tax tooling, engineering time, experimentation time, support cost, revenue leakage from lower conversion, dispute loss, and the long tail of operating multiple billing systems, your net improvement can get very small very quickly. In some businesses it will still be worth it. In many, it will not

And even if it works in a narrow segment, the fifth issue remains:

5. You are creating permanent complexity, not a temporary experiment

This is the part that almost nobody models properly

If you run an app-to-web experiment for three months and decide it was a bad idea, your web-billed users do not politely disappear. You still have to support them. You still have to honor their renewals, manage their cancellations, answer their billing questions, reconcile their subscription state, and maintain enough infrastructure so their access remains correct. Congratulations: your test is now a durable second billing stack

The app stores are opinionated, expensive, and frustrating. They are also operationally simple in ways people stop appreciating once they leave them

The hidden cost is organizational, not technical

Most discussions about app-to-web are framed as product or finance decisions. In reality, they are company decisions

You need product and growth to redesign the purchase journey. You need engineering to build routing, redemption, instrumentation, and edge-case handling. You need support to answer “Where do I cancel?” forever. You need lifecycle marketing to own the web renewal and churn experience. You need finance and ops to reason about taxes, disputes, reconciliations, and payout differences. You need legal or policy confidence on where you can and cannot show external payment paths. And you need analytics clean enough to tell whether the whole thing actually worked

That is a lot of machinery to spin up in order to maybe improve unit economics

This is why I think the average team should be much more conservative than the current conversation implies. The relevant question is not “Can I avoid app store fees?” The question is: “Am I capable of operating a better billing business than Apple or Google for this segment of users?”

For a lot of teams, the honest answer is no

When app-to-web probably does make sense

All this being said, there are real cases where I would absolutely consider using app-to-web

If you have a large US user base, high average revenue per paying user, meaningful paid acquisition economics, strong experimentation infrastructure, and enough support capacity to absorb billing fragmentation, then app-to-web can be rational. If you already have a serious web business, or if the web is strategically important beyond payments, it becomes even more attractive. If your app category naturally supports account-based behavior and cross-platform usage, users may tolerate the extra checkout friction better than they would in a lightweight impulse-purchase app

Likewise, if merchant-of-record complexity is the blocker, the fact that Stripe Managed Payments now exists, is genuinely interesting. If you want the most integrated RevenueCat-native route, RevenueCat Billing / Web Billing is what we support most directly today. If Paddle fits your tax and merchant-of-record preferences better, our Paddle path is a very capable option

If this topic is top of mind for you, on Tuesday April 28 (the day before Stripe Sessions) we’re co-hosting The Web for Apps Opportunity in downtown San Francisco:

A full day event that includes talks by RevenueCat and Stripe on how, where, and when to use web payments for your app. The afternoon concludes with a private executive dinner at 54 Mint

Apply to attend here

So this is not me saying never do app-to-web. It is me saying do it for the right reasons, with open eyes

My actual recommendation

If you are curious about app-to-web, do not start by trying to replace in-app purchases broadly. Start by treating it like a constrained experiment, with a proper hypothesis

Pick a narrow, eligible segment. Measure full-funnel conversion, not just net revenue on completed purchases. Track refunds, disputes, support tickets, cancellation confusion, and cohort quality. Check back one month, 3 months, 12 months after the experiment ends. Assume your support burden will be higher than the first spreadsheet suggests. Assume that billing fragmentation will last longer than the experiment does. Assume fee savings will compress after you include everything

And if, after all of that, the economics still work out, great. You probably have a real business case

But most teams will arrive at a less exciting and more useful conclusion: app-to-web can work, but not well enough to justify everything that comes with it

Stop measuring downloads: what to track before product-market fit

Tue, 14 Apr 2026 13:36:11 GMT

It’s such an exciting moment when you launch your app. You finally put it out into the world… now what?

It’s tempting to focus on what feels productive: building new features, testing prices, running ads. But if you don’t know whether you’re actually solving a real problem, most of that is just optimisation in the dark.

The metrics that feel good in that early phase — downloads, signups, even revenue — don’t necessarily tell you if you’re on the right track. They tell you people are showing up and trying the app, not whether they’re getting real value from it.

I see this constantly in growth audits. One client had over 90% onboarding completion, which sounds fantastic. But most users were gone by day two. Onboarding wasn’t the issue, but value was.

In this first, exciting phase of launching your new app or finding product-market fit, it’s critical to focus on metrics that reflect real value creation, not the shiny, ego-boosting ones.

We’ll talk about how to make that mindset shift, and from there:

Which metrics to ignore so you don’t get distracted
What metrics you simply can’t measure yet
What to focus on instead
How to find the one overarching metric to guide you.

We’ll also cover some traps and risks along the way, such as why retention alone doesn’t equal product-market fit.

And despite focusing on metrics here, please (she begs politely) don’t ignore qualitative signals. At this stage, qualitative feedback will guide you just as much — if not more — than quantitative data. You don’t have the luxury of large data sets yet, and that’s okay.

From there, I’ll help you define what finding product-market fit actually looks like for your app, so you leave with a clear list of metrics to focus on. This is the super-quick crash course version. If you want more depth, I highly recommend checking out my free course, How to make an app people will pay for, where I walk through this in detail and give you a full Product Strategy Canvas to apply to your own app.

Focusing on the right metrics helps you learn faster and move forward with confidence. At this early stage, that clarity makes everything feel a lot less overwhelming.

What really matters pre-product market fit

Product-market fit means building an app that solves a specific problem for a specific audience — with a solution that genuinely fits their needs.

It’s the point where you’re no longer persuading people to use your product — they want it. They love it, get consistent value from it, and choose to keep using it.

What finding product-market fit is about

The reality is that pre-product-market fit isn’t about growth.

Yes, you need some growth, enough to generate data, learn, and validate what’s working. But the core questions you’re trying to answer are:

Does my solution actually solve the problem?
Who values it the most?
What makes them come back?
What would they pay for?

A common trap at this stage is getting pulled into growth too early. Sometimes that pressure comes from investors. Sometimes it comes from a few early wins that make you feel ready to scale. You rush into paid ads, burn through runway, watch users churn, panic… and try to acquire even more users.

This is what Eric Seufert calls The Growth Trap.

Ironically, an over-focus on growth won’t help you grow. Product-market fit will.

When you fixate on growth metrics too soon, you might achieve short-term spikes, but not long-term, sustainable growth.

Instead, shift your mindset. At this stage, your job is to learn and to look for strong signals that product-market fit is emerging.

And here’s the good news: there are so many metrics you could track that I give you full permission to ignore most of them.

What metrics to ignore

It’s buzzword bingo for an early-stage founder; millions of metrics and fancy phrases thrown at you, from Cost of Acquisition to Lifetime Value. The problem? Not all of them actually matter at this stage.

So here are some of the most common metrics I give you 100% permission to ignore, or at least not obsess over:

Total downloads: Just because people download your app doesn’t mean they even open it or get value from it.
Total signups: Same idea.
Social media followers: Great for the ego, but meaningless if it isn’t actually driving awareness or value.
App store ranking: Might help growth a little, but it tells you nothing about whether you’re solving a real problem.
Day 1 download spikes: Don’t over-interpret early spikes; first users often behave differently than your eventual audience.

Other metrics, like time in app or number of sessions, can feel encouraging; they make free users look active, but none of them truly reflect value.

And that’s the key at this stage: are a specific group of users getting repeated value? If a metric doesn’t help answer that, toss it out.

Now, there are metrics that reflect value, but at launch, you often can’t measure them yet.

What metrics should you measure instead?

With this mindset shift, the metrics that matter pre-product-market fit are behavioral. It’s not about whether users showed up; it’s about whether they did the things that indicate they’re actually getting value.

Ask yourself:

Are users coming back on their own?
Are they using the core feature?
Are they willing to pay?
Are they telling others?

Together, these behaviors give you a clear picture of where users are dropping off and what you need to focus on.

The key concept here is activation. If you’re activating users, they’re more likely to retain and pay. Activation has a domino effect in early-stage startups. People won’t pay for an app they haven’t truly experienced; they haven’t reached the moment where the value clicks.

You’re looking for the behaviors that, over time, predict whether someone will stay and pay. Look for patterns across at least 2–3 cohorts before drawing conclusions. Even with small numbers, consistency matters more than volume.

Time to first value and time to core value

Two useful activation metrics building on product-led growth thinking popularised by Wes Bush:

Time to first value – Did the user experience something valuable?
Time to core value – Did they start building a habit?

For example, in a meditation app:

Time to first value might be the time to complete their first meditation session
Time to core value is when they’ve meditated at least four times in a week and started building a routine

These metrics help you understand not just whether users are signing up, but whether they’re actually engaging with and benefiting from your product.

The goal isn’t to over-index on speed, as some actions naturally take time. But in the early days, it usually takes too long, so you need to help users reach that value moment faster. It’s more about relative timing than absolute speed.

For example, in a food-scanning app, users who scanned at least 7 foods in a week were much more likely to stay than those who took 2-3 weeks to reach the same milestone.

The scanning feature was the main way users could check whether a food was safe to eat.

So the team could focus on how to help more users complete that action within a defined period, rather than just letting it happen organically, e.g., more in-app nudges to scan, examples of what you can scan with it, etc.

Active users

Alongside activation, having a measure of active users, defined by meaningful behaviors rather than just app opens, is extremely important.

Tracking whether you’re activating a higher percentage of users and doing it faster gives you a clear signal that you’re on the right track.

And, as always, this should be tied to the key behaviors you’ve identified as indicators of value.

Percentage of customers through word of mouth

Referrals are huge. If 15% or more of new users come through referrals, that’s a strong signal of product-market fit.

Word of mouth takes time to build in a new app, but if you start seeing more people talking about your product and your percentage of users acquired through word of mouth grows, that’s another clear positive signal.

What you can’t measure yet at launch

We’ve covered what you should ignore and what you should focus on.

Not to add confusion, but there are also valuable metrics that are hard to measure at launch:

Retention curves need weeks
Realized lifetime value per customer can take months to start to pin down
Same with sustainable growth

It’s not that you shouldn’t measure these metrics at all; it’s just that at launch, you can’t judge success by them yet.

Instead, focus on leading indicators — the behaviors that signal value early — rather than lagging indicators, which reflect outcomes further down the line.

Leading indicators: activation, early retention, qualitative feedback
Lagging indicators: lifetime value, revenue, long-term retention

Leading indicators act as your early warning system. They show whether something might be off track before the final results are in, letting you be proactive rather than reactive.

Retention

One of the most common metrics people tell you to track in this early phase is retention.

While it takes time to really understand your retention curves, you can start by looking at 7- and 30-day retention.

But here’s the trap: over-indexing on retention too early can be dangerous.

Apologies for the upcoming rant, but honestly, it felt much-needed. We can’t talk about pre-PMF metrics without diving deeper into the risks of equating retention with PMF.

The retention trap

Often, it feels like product-market fit is the same as retaining customers. But you can keep people around without actually solving their problem.

Strange, but I’ve seen it happen. Good retention can make an app feel like it has product-market fit before it really does.

There are four ways this can happen.

1. Gamification over value

The first trap is relying on mechanics — streaks, reminders, badges — to drive retention without delivering real value. These are classic forms of gamification.

I’ve experienced this myself. I got completely hooked on a game, loving the streaks that kept me coming back. But eventually, I realized I wasn’t really enjoying myself anymore. I was returning because of the mechanics, not the value. And yet, I couldn’t bring myself to delete the app until I quit cold turkey.

2. Retention is driven by a small group of power users

This isn’t inherently bad, but it’s something to watch closely.

It’s all about balance: are you too specific, or is your core group too small to scale? If growth only happens within this small group, your product-market fit might not be ready to scale.

You need to be specific enough to stand out, but not so niche that you’re building for only a handful of users who aren’t representative of a larger market.

3. Pricing that masks weak product-market fit

This happens when heavy discounts or extended trials are offered. Sure, it attracts a lot of users, but often bargain hunters. You might see strong retention numbers from users who signed up for an annual subscription at a very low price, but they’re not actively using your app.

4. Annual subscriptions can delay churn rather than prevent it

Annual subscriptions are great for cash flow and have plenty of benefits. But if most users aren’t actively engaging with your app, locking them in doesn’t mean they value it.

The lesson: commitment isn’t the same as conviction. Someone locked into an annual plan is not the same as someone who would be devastated to lose your app.

To avoid this trap:

Pair retention data with engagement data: if users are renewing but not actually using the app, dig deeper before celebrating
Rely on qualitative signals to understand your users’ experience and motivations

Qualitative signals to focus on

In the early days, you don’t have massive numbers, and that’s completely normal. With small sample sizes, it’s hard to distinguish noise from signal, and the variance in metrics can make even the steadiest founders nervous.

This is why qualitative signals are extremely valuable. Remember: product-market fit is qualitative first, quantitative second. You’ll feel it before you can measure it: users reaching out unprompted with feedback, telling you how much they love it, asking when features are coming, referring friends without being asked. It’s little moments like that, where growth also feels easier that tell you long before you hit statistical significance that you’re on the right track.

The Sean Ellis test

Sean Ellis studied hundreds of startups to find what separated the ones that went on to succeed. He discovered that successful startups typically had at least 40% of users who would be very disappointed if the product no longer existed.

He created a simple PMF test to measure this:

Ask users: ‘How would you feel if you could no longer use [app name]?’
- Very disappointed
- Somewhat disappointed
- Not disappointed
- I no longer use this
Follow up with: ‘Could you explain your answer?’

That second question is critical; it helps you understand what actually drives product-market fit, even if your sample size is too small for statistical significance.

That second question means that even if you don’t have enough data for significance, you can start to understand what drives PMF.

A few practical tips:

You need enough responses to get meaningful insight: at least 100 for a general sense, and 500–1,000 if you want to segment by signup reason, main feature used, or other factors
Survey the right users at the right time, ask those who should have reached their aha! moment:
- Don’t survey day-one users if it normally takes 7 days to get value
- Don’t limit it to users who’ve been around for months, either, or you risk skewed optimism

This test gives you a qualitative measure of product-market fit, helping you identify both the level of engagement and the reasons behind it.

Net Promoter Score (NPS)

The Net Promoter Score correlates strongly with this. For example, Ladder found that users who said they’d be ‘somewhat disappointed’ had much lower NPS scores than those who said ‘very disappointed’.

It can be valuable to ask, alongside your PMF question, why users would or wouldn’t promote your app. This gives insight not only into how much people value your product, but also what drives advocacy and highlights areas you can improve to turn more users into promoters.

User interviews

If you don’t have enough users for the Sean Ellis test or measuring NPS, the best recommendation I can give you is to conduct user interviews to hear first hand from customers why they love and don’t love your product.

Starting with even just 5-10 Jobs-to-be-Done (JTBD) interviews will teach you so much about:

What drives users to stay
What matters most to them

I recommend prioritizing users with whom you suspect you might have product-market fit as well as recently churned users with a similar need. That way you can understand what the difference is and what to prioritise to improve.

This also ensures you don’t get distracted by noisy users and keeps your focus on the behaviors and needs that really indicate product-market fit.

Finding your North Star Metric

As you start to narrow down which metrics actually predict value and gain insights from qualitative research, it’s incredibly helpful to have an overarching metric to guide you.

This is known as the North Star Metric: the single best metric that indicates whether users are getting value, whether you’re getting value, and whether you’re building a sustainable business.

Post-product-market fit, North Star Metrics often look like active subscribers or monthly recurring revenue. But pre-product-market fit, it’s crucial that this metric is behavioral, focused on the actions that show users are truly experiencing value.

For example:

Spotify focuses on time spent listening
Slack focuses on messages sent
Dropbox on files uploaded.

They’re all measuring core actions that signal value.

These are companies that have already found product-market fit. For you, the goal isn’t to copy their metric; it’s to find the equivalent for your app at your stage. Start with a core hypothesis:

What is the core problem you’re solving?
What behaviors would indicate it’s being solved?
And how often should that behavior occur?

For instance, a budget-tracking app might hypothesize that users who categorize at least 5 transactions per week are deriving value. Ideally, your metric includes both the specific action and the time frame you want to see.

Post-product-market fit, your North Star Metric should remain stable unless you make a major pivot. But pre-product-market fit, it’s okay to refine it as you learn more. You probably won’t know with confidence exactly what that action is or what the North Star Metric should be, and that’s completely fine.

Defining PMF for your app

Now it’s time to get practical. You’ll want to write down what your PMF definition looks like in behavioral terms.

The template I use and share in my ‘Make an app people will pay for’ course is the following:

I’ll know I’m approaching PMF when [specific user type] repeatedly [specific behavior] because my app helps them [specific outcome].

For example:

I’ll know I’m approaching product-market fit when busy parents repeatedly open the app after dinner to plan tomorrow’s meals because my app helps them save 20 minutes of decision-making stress.

Or:

I’ll know I’m approaching PMF when people trying to build new habits repeatedly log at least one habit daily for 10 days because my app helps them make it satisfying to see their streak grow.

One important note: PMF signals are directional. At this stage, you might see them in just one segment, one use case, or one geography, and that’s perfectly fine. You’ll probably start niche and expand.

If you find PMF in an unexpected segment, that’s actually valuable information. It might mean doubling down on that audience rather than trying to force-fit your original target.

Stress testing your PMF definition

To test whether your definition is strong enough, ask yourself:

Do activated users who engage in that behavior retain significantly better?
Does the pattern hold across cohorts?
Does improving the metric improve downstream outcomes?

In case you haven’t noticed, I love making you ask yourself questions. It’s so easy to rush as a startup, so it is important to force yourself to reflect on your decisions.

When to move on from this phase

So how do you know when you’ve done enough to get PMF and it’s time to shift focus?

There’s no perfect moment, but there are signals that suggest you’re ready:

40% or more of users say they’d be ‘very disappointed’ without your app
Your retention curve starts to flatten after a few weeks rather than dropping off completely
Users are coming back on their own without push notifications or reminders
You’re seeing organic referrals — people telling others without being asked
Users are willing to pay without heavy discounts or extended trials

You don’t need all of these, but if you’re seeing a few of them consistently, especially within a specific segment, that’s a good sign you’ve found something worth building on.

From here, you move into what’s often called product-model fit, making sure your monetization model matches how users experience value. That’s where pricing, packaging, trials versus paywalls, and funnel decisions come in.

You also start to focus more on channel metrics, trying to work out which channels will drive scale for you.

But those decisions around monetization and channels are so much easier when you’ve already validated that you’re solving a real problem for a specific group of people.

Time to define your metrics

Pre-product-market fit, your job isn’t to grow. It’s to learn. That means ignoring the metrics that feel good but don’t tell you anything and focusing on the behavioral signals that show whether users are actually getting value:

Ignore	Focus on
Total downloads	Users returning on their own
Total signups	Core feature usage
Social media followers	Willingness to pay
App store ranking	Users telling others
Day 1 spikes	Repeat usage in the first week
Time in app (without context)	Active users (defined by behavior)

Here’s a quick checklist to keep you on track in this pre-PMF phase:

Shift your mindset from growth to learning
Identify the vanity metrics you’re going to ignore
Define what time to first value and time to core value look like for your app
Set a behavioral North Star hypothesis
Write your PMF definition in behavioral terms
Talk to users → PMF surveys, NPS, user interviews
Focus on leading indicators, not lagging ones

It’s hard to resist the pull of growth, especially right after launch when the numbers are moving. But if you nail product-market fit first, everything that comes after — your funnel, your pricing, your ads — will work so much better.

If you want to go deeper on defining your strategy and finding the right audience before diving into metrics, that’s exactly what I cover in the StartApp School course: Early product decisions: How to build an app people will pay for. I’m excited to hear what you think!

Track in-app ad revenue alongside purchases: get the full picture on monetization

Mon, 13 Apr 2026 14:09:18 GMT

For apps monetizing through a mix of ads and in-app purchases, understanding your total revenue has historically been a fragmented, frustrating process. You’re forced to stitch together dashboards, export CSVs, and build custom pipelines just to answer basic questions: What is my actual revenue across all channels? How valuable is a user who never subscribes but watches ads for six months? What percentage of my revenue comes from ads versus subscriptions?

The result is a blind spot in your data. You’re left making slow decisions based on incomplete Lifetime Value (LTV) metrics and guesswork.

That’s why we’re excited to release In-App Ad Revenue Tracking in RevenueCat in public beta. You can see your complete monetization health, blending ads alongside subscriptions and one-time purchases, all in one place.

One dashboard for your complete revenue picture

RevenueCat now ingests ad revenue events in real time alongside your purchase data. This means no more bouncing between ad network dashboards and RevenueCat to understand your total revenue.

Here is what you can explore as part of the beta:

Unified revenue and realized LTV

Ad revenue is now folded directly into your main Revenue Chart. ‘Total revenue’ finally means total revenue. Furthermore, your Realized LTV now incorporates ad revenue, giving you a complete picture of cohort value. You can finally understand the true worth of your users, not just what your subscribers paid.

Dedicated ads reporting

We’ve added a dedicated Ads section in the Charts tab. Here, you can track the metrics that matter most to your ad monetization strategy:

Ad Revenue: The foundational number of total revenue generated from ads.

ARPDAU (Ad Users): Average Revenue Per Daily Active User, the key blended health metric for hybrid apps
Ad Monetized Users: track the number of times users clicked on ads in your app — clicks indicate user engagement with ads and can help you understand which ad placements and formats are most effective
Ad Impressions & Fill Rate: total ad displays and the percentage of ad requests successfully filled, letting you keep an eye on targeting issues or limited ad inventory
Ad RPM & CTR: revenue per thousand impressions and click-through rate to measure monetization efficiency and engagement quality
eCPM: compare monetization efficiency across different time periods, countries, or platforms regardless of total impression volume

Per-user ad visibility

The Customer Details page now includes a dedicated Ads tab. You can dive into individual user profiles to see their Total Ad Revenue, Impressions, Clicks, Fill Rate, CTR, eCPM, and impression timestamps.

How it works: one SDK, one integration

It’s incredibly simple to set up with the RevenueCat SDK. If you’re using Google AdMob, you simply replace your standard AdMob loading calls with the loadAndTrack methods from the RevenueCat SDK and that’s it. All ad events are tracked automatically.

If you’re using any other mediation platform that provides impression-level revenue data — such as AppLovin MAX, ironSource, Unity Ads, and many more — you simply call RevenueCat’s AdTracker methods in your ad SDK callbacks at the right time.

Whether you use AdMob or another platform, it’s still the same reliable RevenueCat SDK under the hood. For full integration details and code examples, check out our ad monetization docs.

What’s next for Ad Revenue Tracking

This beta is focused on getting the foundational data right and giving you a unified view of their revenue. While we do not measure campaign attribution (we are not an MMP) and we aren’t replacing your mediation platform, we are adding the crucial subscription context to your ad data.

Note: Because RevenueCat uses real-time SDK data and mediation platforms like AdMob use post-processed, fraud-filtered data, you may see slight discrepancies in the exact numbers. This is expected and fully documented.

Looking ahead, we’re working on bringing even more powerful insights to this feature. Fast-follows will include blended ARPDAU across all users, and future updates will introduce predicted LTV with ads and analytics showing how ad exposure impacts subscription conversion and churn.

Unify your data and start making better decisions based on the full picture — get started today

If your app monetizes with ads through platforms like Google AdMob or AppLovin, you can start sending ad events to RevenueCat today.

Check out the docs for more >

Any customer can request access to the feature by navigating to the Ads page in their RevenueCat dashboard.

Russia’s App Store payment block: how it impacts your MRR and what to do next

Thu, 09 Apr 2026 17:07:21 GMT

Following a recent Russian government directive, as of April 1, Apple has officially stopped processing payments for all App Store purchases and Apple Media Services in Russia. This means Russian users can no longer make new purchases or renew existing subscriptions using traditional payment methods.

While card payments have been blocked for some time, a popular loophole allowed users to top up their Apple ID balance via mobile phone operators. This new change firmly ties that loophole closed.

The status quo

For subscription app developers, this is a hard stop on a major revenue channel in the region. Unless a user already has existing funds in their Apple Account balance, their subscription will not renew.

The good news for users is that they won’t immediately lose everything. Apps and content previously purchased will remain available, and Apple has confirmed that iCloud+ data will remain accessible even after a subscription lapses. However, premium features tied to active subscriptions will inevitably be cut off once the current billing cycle ends and the renewal fails.

What we know about the block

According to reports, the Russian government ordered mobile operators to disable the Apple ID top-up option. This move is widely seen as part of a broader crackdown on online information, specifically targeting the use of paid VPN apps that allow citizens to bypass internet censorship.

By cutting off the ability to pay for these services, the government effectively restricts access to them. As a result, this blanket ban catches all subscription apps in its net, regardless of their developer HQ, app category or purpose.

Some users have already found workarounds by using gift cards to top up their Apple balance, while others are changing the country of their Apple account, or even making a second account in another country with a different bank account. The consequences (from the Russian government or Apple) of pursuing either of these methods remains unclear.

What developers can do now

For most developers, the impact on global MRR will be minimal. However, if you have a significant user base in Russia, you stand to lose a chunk of revenue. Here are a few practical steps you can take right now:

Assess the impact: check your RevenueCat dashboard to see exactly how much of your active MRR comes from Russia. This will help you forecast the upcoming drop in revenue as renewals begin to fail.
Communicate with users: send an in-app message or email to your Russian subscribers. Inform them of the change and remind them that they can still use existing Apple Account balances or redeem any App Store codes they already have.
Offer alternative payment routes: if your app is multi-platform (e.g. accessible via the web), you can direct users to complete their purchases outside the App Store ecosystem. Just keep in mind that international sanctions and financial regulations around Russia are complex and constantly shifting – make sure you understand the rules that apply to your business before accepting payments from the region.

While the situation is largely out of developers’ hands, proactive communication, a clear understanding of the data, and alternative methods (like web-to-app) can help cushion the blow.

Inside Noom’s web-to-app onboarding funnel: how 113 screens build commitment before the paywall

Thu, 09 Apr 2026 14:00:03 GMT

Noom’s web-to-app funnel is extensive, like really extensive. The weight loss subscription app has one of the longest app onboarding funnels I’ve ever analyzed. Walking through it carefully and taking notes took around an hour and a half, and even a faster ‘quick’ run-through as a typical user still clocked in at 10-15 minutes, with up to 113 screens along the way.

Yet somehow, it never feels exhausting.

Instead, the experience feels personal, thoughtful, and surprisingly educational.

Why is Noom’s onboarding flow so long?

What makes Noom’s approach worth studying isn’t just the length of the funnel, but how intentionally that length is used. Every question clearly builds toward a payoff, sensitive moments are met with reassurance, and by the end, you genuinely feel as though the plan was designed specifically for you. Noom strikes a rare balance between asking for input and delivering value, and that’s what makes the funnel work.

Before we dive in, one important note: I’m human. I know, shocking. While I’ve worked to walk through as many variations of Noom’s flow as possible, there are inevitably moments I may have missed or paths I couldn’t fully test.

At one point, users are asked ten questions with four possible answers each, that’s 262,144 potential combinations. But fear not: this human did the homework to surface the most meaningful patterns and takeaways, testing roughly 20 different paths to ensure the core learnings are well represented.

So let’s walk through what makes this quiz-based onboarding funnel work and see what you can apply to your own web-to-app funnel. You can check out the full flow here.

1. Goal selection that reduces pressure

Noom opens with a question that’s refreshingly direct: What’s your weight loss goal? That clarity matters. If you’re a weight-loss app, hiding it creates uncertainty later.

But the clever part lies in the options themselves. It’s not just “lose weight.” Users can also choose “maintain weight and get fit” or “I haven’t decided.” That final option may seem small, but it does important work: it removes the pressure to have a perfect answer on the very first screen and prevents users from feeling like they’ve already ‘failed’ before they’ve even started, especially critical when the first step is often where drop-off is highest.

Noom also allows users to switch units (stones or kilos). It sounds minor, but it matters. Confusion at this stage leads to inaccurate inputs, and inaccurate inputs erode trust. I may live in the UK, but I still couldn’t confidently tell you how much a stone is, and Noom smartly removes that friction before it becomes a problem.

2. Handling sensitive questions with care

Where Noom really stands out is in how they handle personal, potentially uncomfortable questions. The flow next asks about:

Sex assigned at birth
Gender identity
Pregnancy status
Current weight
Medical conditions

These aren’t casual questions. In a category like weight loss, where vulnerability and self-judgment often show up early, the way questions are framed is critical. Noom addresses this by consistently doing four things:

A. They explain why before you can overthink it

Noom asks sex assigned at birth. This can easily feel intrusive or irrelevant:

Noom does something many apps skip: it explains why, and it does it on the same screen. The framing is straightforward: hormones can affect how our bodies metabolize food. Whether or not every user fully agrees with the science, the key point is that it doesn’t feel like a random data grab.

They also introduce a progress indicator early on, which matters because at this stage, users are silently asking one question: How long is this going to take?

This isn’t just UX politeness, it’s trust-building. When users understand why information is being collected and how it will be used, they’re far more willing to share personal details.

Next, Noom asks about gender identity, separate from sex assigned at birth. This is one of those subtle moments where product design quietly signals: we’ve thought about real people.

Asking this way reduces the risk of mispersonalization and makes users more comfortable sharing personal information, because the app demonstrates care in how questions are framed.

Since I selected “woman,” Noom followed with a pregnancy question. They don’t let you simply continue if you indicate you are pregnant; instead, they clearly explain the app isn’t designed for that situation and require you to sign a waiver to proceed. This thoughtful approach balances user safety with transparency.

B. They reduce the mental load to keep you moving

I loved the age banding here:

Instead of forcing users to enter exact ages or navigate fiddly brackets (20–24, 25–29, etc.), Noom uses broad ranges like twenties, thirties, and forties. I mean, 21 vs. 29 years old… very different, but at least they are making it easy for us.

In a long onboarding flow, this kind of simplification matters. It maintains momentum without sacrificing the usefulness of the data, and it reduces the pressure or overthinking that can come with sharing personal information.

C. They reassure you right after the hardest moment

Next comes height and current weight. Noom knows this can be sensitive, so they soften the request with: “We don’t mean to pry, we just need this to build a plan that’s right for you.”

When you submit your weight, the app responds immediately with: “Thank you for sharing. That’s an important and hard first step.” This isn’t just polite copy, it’s a micro-moment of emotional safety, arriving right when a user might feel judged.

One interesting choice: there’s no ‘I don’t know’ option for weight. That could create friction for users who avoid weighing themselves, but my guess is that weight serves as the anchor for the results graph later. In this case, Noom prioritizes data completeness over comfort. But perhaps that same clarification it offered earlier would be helpful here, so users understand the need.

D. Personalization that feels real (even when it isn’t)

Noom asks about health conditions next, with a multi-select list and a simple UI pattern that makes it clear you can choose more than one.

What stood out is what happens after you select something: you get a supportive message (“We’re so glad you shared…”), and it works even though it’s probably not truly personalized to your exact condition (the message remains the same no matter what you fill in).

That’s a smart tradeoff. With dozens of possible condition combinations, you don’t need custom copy for every branch. A single, well-written reassurance screen can still feel personal because it addresses the emotional reality of what just happened: the user admitted something vulnerable.

Noom also continues to explain why questions are being asked as they get more serious (e.g., diabetes, eating disorders). Not every condition needs the same level of explanation, but the consistency builds trust.

Additionally, Noom adapts follow-up questions based on your answers. For example, if you indicate you have diabetes, the app asks up to two additional questions tailored to the type.

These moments of conditional logic make the experience feel tailored without requiring every question to branch infinitely.

The eating disorder question that follows is a tricky one:

As someone with close friends who have struggled with eating disorders, the waiver alone doesn’t feel sufficient. I understand that if the flow stopped entirely, some users might be tempted to skip ahead, but even with the additional confirmation step, it still feels a bit too easy.

Notably, if you answer ‘no,’ the app doesn’t ask about any previous eating disorders, so that’s something to be aware of. This feels more like a moral consideration than a UX flaw, but I do appreciate that Noom at least doesn’t continue as if nothing happened when someone answers ‘yes.’ It shows some level of responsibility in handling sensitive health information.

Their slight redemption in my eyes? Two steps later, if I enter a weight that isn’t medically healthy, they won’t let me continue until I enter a weight that isn’t classified as underweight.

3. Turn a long form into a series of small wins

After filling in a lot of personal questions, Noom takes a moment to pause and shows the following screen:

The image of people on a hand is playful and approachable, especially paired with the phrase ‘you are in trusted hands.’
The visual of climbing the line subtly signals that weight loss isn’t a straight downward journey, showing that Noom will support users through the hardest parts, like when weight temporarily increases.
The statistic, “we’ve helped 3,627,436 people lose weight,” is both specific and significant, giving the claim credibility.
The stat is backed with a data source and a defined minimum result (at least 2%), which further strengthens trust.

One minor issue: the stat is dated October 2021. Specificity builds credibility, but an older timestamp can create tension, slightly undermining the message.

4. Set expectations early, then repeat them on purpose

Throughout the flow, Noom constantly manages your expectations for what the app can and can’t do. There are three clever ways they do this:

A. The goal weight becomes the backbone of everything

Now Noom asks for your ideal weight and explains how it will use that number to predict a timeline and build a custom plan:

When you enter something unrealistic or unhealthy, the flow blocks you:

That’s a rare and important signal. Noom is willing to sacrifice a conversion rather than encourage harmful behavior, as noted earlier. It stands out as one of the clearest examples in the entire experience of the principle: we won’t optimize conversion at any cost.

B. The 0.5-1 kg message is repeated strategically

This is where Noom starts repeating a key expectation: subscribers typically lose 0.5-1 kg per week. They say it:

On the goal screen
Next to testimonials
With your projected timeline

Normally, repetition can be a UX sin. Here, it’s strategic and serves as clear expectation management. If users expected to lose three kilos a week, they’d assume the product was broken. Noom anchors users to a healthier, realistic pace before they ever pay a dime.

C. The graph reframes the competition

Noom then shows the projected journey: a steady trend line versus the yo-yo effect of restrictive dieting:

This is a subtle but important move: Noom’s competitor isn’t just ‘another app.’ It’s crash dieting, inconsistency, and short-term motivation. The graph makes that comparison visual, which is far more persuasive than simply stating it in copy.

Next, Noom asks what you want to focus on: nutrition, movement, habits, or ‘other.’ I noticed a few of these practical questions appear throughout the flow. At first, they felt a bit random, but it soon became clear that this is likely strategic: spacing out the practical, must-ask questions keeps users engaged and prevents them from getting ‘bored’ with the flow.

5. Make the payoff visible before you ask for the email

A. The event question creates a deadline

Next, Noom tries to identify a motivator, often framed as an upcoming event such as a holiday, wedding, or reunion. This makes sense: events create deadlines, and deadlines create urgency.

It can feel a bit superficial if a user’s true motivator is health, confidence, or energy. Noom softens this by including a ‘no event’ option, but the flow still nudges users to pick something, even asking them to specify a date.

B. Pace gives you control

Then you choose your pace: fast, slow, and steady, or in between.

This is a simple control mechanism that addresses a common objection: ‘This won’t fit my life.’ Even if it doesn’t drastically change the plan, it gives users a sense of agency.

Noom follows with a testimonial and repeats the weight-loss pace statistic. Here, repetition is intentional as they want that expectation firmly embedded before users even see their results.

Interestingly, how fast I indicated I wanted to lose weight didn’t seem to affect the projected end date, even though I might have expected it to.

C. The loader does conversion work

Noom shows a short ‘calculating your plan’ screen before asking for your email.

That pause does two things. It makes the result feel earned, and it gives them a natural moment to introduce the idea that something valuable is about to be revealed.

D. The email gate appears at exactly the right time

About a third of the way through, Noom asks for my email, right before showing the results graph. The timing is smart: I’ve already invested enough in the flow that I want to continue, but I’m not so deep that I feel frustrated they’re only asking now.

The CTA isn’t a generic “Submit,” it’s “See my results.” They immediately clarify what I’ll get: a personalized weight-loss timeline and an estimate of how much I can lose before my holiday, a goal I indicated earlier.

They also separate the marketing opt-in into its own step, framed as “occasional research, advice, and special offers,” signaling both low volume and higher value.

6. Deliver the ‘this was built for me’ moment

Then Noom delivers the payoff: a results screen with your goal date, your event marker, and a realistic projection.

Tone matters here. Noom doesn’t overpromise; for example, if your event is in two months, they don’t suggest you’ll magically hit your ultimate goal by then. That realism builds more trust than aggressive promises ever could.

This is also where you see why some of the earlier questions were non-negotiable. Without a starting weight, a goal weight, and a deadline, this personalized results screen couldn’t exist.

7. Use an onboarding quiz to increase buy-in, not just collect data

After the initial health questions, Noom shifts into what they call a ‘behavioral profile quiz.’

It uses sliders between two statements, repeated across 10 questions. The structure is deliberately consistent:

You always know what to do
You always see progress (“Question X of 10”)

There are also subtle visual cues built in. For example, if you choose “Agree a little more,” the background color is slightly lighter than if you select “Agree most.” These small touches guide the user’s perception without being overt.

The end result is an analysis of my profile, this time with a shorter loader and no message, followed by the presentation of my personalized profile.

I tested extreme answers, including negative self-image, to see if Noom would respond poorly. What impressed me is that it frames the results constructively, acknowledging what you said without reinforcing shame.

They’re not ignoring what I said, but they’re also not reinforcing negative self-talk. This feels like a careful balance.

8. Teach the ‘method’ inside onboarding

Rather than waiting until you have the app to start learning, Noom integrates small learning moments throughout the onboarding flow in various ways.

A. Selective empathy screens

After the profile, Noom asks practical questions about things like gym memberships, apps, and meal kits, another small, seemingly random question checked off early in the flow.

Next, the flow moves into agreement statements covering habit barriers, social impact, convenience, and decision fatigue. Interestingly, some answers trigger an additional reassurance screen, while others do not.

This creates a sense of responsiveness without forcing the flow to branch endlessly. It’s selective empathy, applied where it’s most likely to reduce drop-off.

B. The plan starts to feel more achievable

They also ask about lesson timing — “When would you like daily lessons?”—which is a smart operational detail disguised as personalization. In reality, it’s about choosing a routine that will stick.

The flow returns to the graph, with the dates moving forward, interspersed with a few practical questions along the way.

C. A product demo without showing the product

This is where Noom’s onboarding effectively becomes a product demo, without ever showing the app interface.

They introduce the green/yellow/red system through questions about what you’ve eaten, then explain calorie density. The messaging is carefully non-shaming: there are no ‘bad foods,’ only foods that help you feel fuller for longer.

Even the cravings question — mine was sweet, so I picked honey (though I wished chocolate had been listed) — becomes a teaching moment: “There’s room for it. Just be mindful.”

This is objection handling at scale, addressing questions like:

‘Will I be hungry?’
‘Will I have to give up foods I like?’
‘Is this going to be restrictive?’

Noom answers these before you even reach the paywall.

The flow then returns to another slow loader, which Noom uses again as a teaching moment to explain how the app works.

The screen slowly switches as it continues to build your plan:

D. Personalization only feels real when it cashes the cheque

When Noom asks about dietary restrictions or physical limitations, you naturally expect an immediate follow-up.

Earlier in the flow, every meaningful answer led to a tailored next step. When that doesn’t happen here, it stands out.

It’s a reminder that personalization isn’t just about collecting data; it’s about showing users how their answers shape what they see next.

This creates a sense of progress and reward: the more I share, the faster I can achieve my goal.

It doesn’t feel manipulative. Instead, it’s as if Noom is saying, “Based on what you’ve told us, we think you can do this faster than we initially thought.”

Interestingly, even when I indicate a limitation or provide ‘negative’ answers, the goal always moves forward.

9. Use a relevant bonus to turn intent into action

From there, it asks about what else you want to achieve:

Interestingly, even if you don’t provide answers about reducing stress or emotional wellbeing, you still go through a mini quiz on the topic.

Noom uses this to calculate a stress score and offers to add stress management to your plan, using a low-pressure line: you can remove it later.

This immediately raises a question: What does it cost?

Strategically, that uncertainty works in Noom’s favor, because the pricing reveal comes later — paired with a time-limited incentive. At this point, I don’t know the cost, but I’m willing to continue because the framing feels low-pressure.

This becomes important during the pricing step, where the stress management course is offered as a ‘free enhancement’ if I sign up within 15 minutes. This approach is smart for two reasons:

The 15-minute countdown creates urgency.
A free course feels more believable than a discount — I’m less likely to think ‘this countdown is fake.’

The flow then continues with a few questions about motivation and emotions, mainly to reinforce the value of the plan being offered.

Finally, they check about other goals too:

Before moving into another mini quiz on nutrition, which ties back to the earlier point about teaching the method during onboarding.

I love how, even when you get an answer wrong, Noom stays positive and non-judgmental, maintaining a consistent tone of voice throughout the entire flow.

Another final standard question to check off, and the flow is almost complete. My main thoughts: 1) Why so many options? 2) The order feels a bit random.

10. Show how the insights are used

Believe it or not, after about 100 screens, we’re nearly there! The final act brings everything together into the ultimate plan.

A. When questions turn into a plan

You see the loading screen that says Noom is ‘building your plan,’ but it’s more than just a spinner. In the background, the product is combining everything you’ve shared so far, from weight-loss goals to eating and nutrition habits.

This moment matters because it shifts the psychological contract. Up until now, you’ve mainly been answering questions; now it feels like Noom is actively working for you.

That shift is what makes the next section feel earned, rather than frustrating after a long flow.

B. The fake loader that actually does real work

Noom uses loading screens in two ways throughout the flow:

Short loaders that create a brief pause after effort.
Longer loaders that mix in additional questions, like this section.

Even if the ‘processing’ is partly theatrical, it feels more believable because the interruptions show your inputs actively shaping the plan.

They further reinforce credibility by referencing “millions of successful users,” using social proof framed as evidence of model quality.

Even after this, the app loads again, but this time it feels conversational, almost like “We’ve heard you. Now we’re doing something with it.”

It gradually reveals what’s happening and builds excitement for the final result.

11. The ‘pay what you want’ trial

Then comes one of the most unusual pricing moments I’ve ever seen: Noom asks how much you’re willing to pay for a 14-day trial, offering three options.

It’s framed with cost transparency (“it costs us X to offer this trial”) and an altruistic nudge (“help others access Noom”). Functionally, your choice doesn’t change the offer, but psychologically, it reframes pricing as a contribution rather than an extraction.

That said, I did notice the outdated date (September 2021)… yes, I’m nitpicking. On one hand, it probably costs them more now, so I’m getting a deal. On the other hand, it made me wonder why it hasn’t been updated in over three years.

Regardless of which trial price you choose, you proceed to the same offer in terms of costs after the trial.

12. What the app actually looks like? Unclear.

My biggest critique: after all of this, I still don’t know what the app experience actually looks like. I understand the plan, the psychology, the framework, and the promise, but I haven’t seen:

What food logging looks like
What the daily lesson experience looks like
What ‘success’ looks like day-to-day inside the product

For a flow this long, one or two UI glimpses could likely increase confidence right before purchase, especially for users wondering, ‘Will I actually use this?’

What makes Noom’s quiz funnel effective?

Here’s a quick recap on the key takeaways from Noom’s web-to-app onboarding funnel:

Reduce pressure at the first step. Let users ease into commitment. An ‘I haven’t decided yet’ option can prevent early drop-off without weakening intent.
Explain why you’re asking personal questions. Sensitive questions feel safer when users understand how their answers will be used to help them.
Offer reassurance immediately after vulnerable moments. A simple ‘thank you for sharing’ at the right time can dramatically increase trust.
Use progress indicators to make long flows feel lighter. Showing how far someone has come reduces perceived effort and keeps momentum high.
Set expectations early and repeat them on purpose. Repetition isn’t a UX failure when it anchors users to realistic outcomes.
Visualize the alternative you’re competing against. Noom doesn’t just sell itself. It shows why crash dieting fails and reframes the real competitor.
Make the payoff visible before asking for commitment details. Show users what they’ll get before asking for their email. Results first, data second.
Reward effort with visible progress. As users invest more, Noom moves dates forward and sharpens projections. That feedback loop motivates completion.
Use quizzes to increase buy-in, not just collect data. Consistent structure, clear progress, and non-judgmental framing turn quizzes into commitment devices.
Teach your framework during onboarding. Introducing the green/yellow/red system early removes objections before pricing ever appears.
Build commitment before introducing price. By the time Noom shows pricing, users have already invested time, effort, and emotional energy — a proven driver of paywall conversion.
Show the product, not just the promise: After such a long, thoughtful flow, users still need clarity on what day-to-day app usage actually looks like, a key area where Noom falls short.

Noom’s funnel is a masterclass in onboarding conversion — building commitment through personalization, education, and empathy. It’s long, but it never feels tedious — every step serves a clear purpose. By the end, you genuinely feel like this plan was built just for you, even while knowing some of it is smoke and mirrors. When 55% of trial cancellations happen on Day 0, Noom’s investment in pre-paywall commitment-building looks less like a quirk and more like a calculated response to that reality.For subscription apps, especially in sensitive categories like health, finance, or mental wellness, Noom’s approach offers valuable lessons in trial-to-paid conversion: how to ask for personal information thoughtfully, build trust, and convert users through education rather than pressure — making it a blueprint for any wellness app funnel.

The blended ARPU framework: how to measure hybrid monetization

Thu, 02 Apr 2026 12:31:04 GMT

Hybrid monetization may be a hot topic, but it’s not a passing fad. Today, utilizing multiple avenues for revenue is a survival tactic — a lever to counter AI-induced variable costs, increased UA pressure and rising competition from the new 14,000 subscription apps joining the market each month.

Yet according to the State of Subscription Apps 2026, only 10% of apps run true hybrid models (subscriptions + ads, consumable, or lifetime subscriptions). Why? Because there’s a barrier, not a technical one, but a measurement challenge. Without a unified metric, teams default to evaluating the performance of hybrid monetization in silos. In this blog, I’ll provide a solution to that exact problem.

The clash of ads vs. subscription mental models

Part of the difficulty in measuring hybrid monetization is the divided mental models between ad-first and subscription-first teams — and the subsequent division that comes with monitoring hybrid performance.

The mental model for ads-first teams is: more sessions = more impressions = more revenue.

So when subscriptions become a strategic priority, the first reaction is usually caution. Typical concerns sound like:

“If we push paywalls, impressions will drop”
“If users subscribe, we lose high-value ad traffic”
“Retention might fall if we add friction”
“We shouldn’t disturb what’s already working”

Teams panic when ads ARPU dips, even if total revenue per user is rising. There can be concern that introducing stronger monetization would:

Hurt retention
Trigger uninstall spikes
Reduce session depth

And because ads performance responds instantly while subscriptions compound, ads movement often shows up first in dashboards.

On the flip side, if you introduce ads into a subscription-heavy culture, you’ll often hear:

“Leaning into ads discourages higher-value subscriber growth”
“Ads revenue hides product problems”
“Free users aren’t our priority”
“Free users get too comfortable”
“The funnel isn’t pushing hard enough”

Tracking blended ARPU is one way to solve this. It becomes your primary subscription app KPI, while ads and subscriptions become supporting metrics. When you monitor total revenue per user instead of individual streams, you stop killing good subscription experiments because of short-term ads volatility.

Why do ads and IAP behave differently?

In hybrid monetization apps, advertising and in-app purchases operate on fundamentally different time horizons, yet this distinction is often overlooked in how teams measure and optimize revenue.

Advertising revenue responds immediately — users see ads, clicks generate income, and the impact shows up in your metrics within hours or days. Subscription revenue, on the other hand, compounds gradually over time as users renew month after month, building predictable recurring revenue that may take quarters to fully materialize.

When you evaluate these revenue streams separately, as some teams do, they naturally appear to compete with each other. You might see that showing more ads increases ad ARPU but seems to hurt subscription conversion, or that pushing subscriptions harder reduces ad impressions. This apparent tension is reinforced by how some analytics dashboards are structured: Ad ARPU lives in one report, IAP ARPU sits in another, and the two rarely interact.

This organizational split encourages teams to optimize locally — the ads team pushes for more impressions, the subscription team advocates for aggressive or contextual paywalls — rather than thinking globally about total user lifetime value.

In a recent monetization review across a large utility app portfolio, we made a deliberate shift in our approach: ads and IAP would no longer be evaluated as competing channels, but rather as one unified revenue system.

Making this shift required developing a shared metric that could capture the combined contribution of both streams and reflect their true interdependencies. This allowed us to move beyond the misleading choice between ad revenue and subscription revenue, and instead optimize for the mix that maximized total value per user.

What is blended ARPU?

When you’re running an app with hybrid monetization, you need a way to see the complete picture of how much revenue each user is generating on average. That’s where ‘blended ARPU’ comes in. ARPU (or average revenue per user) is one of the most fundamental metrics in the app business. The ‘blended’ part means we’re combining all your different revenue sources into one number, rather than looking at them separately.

The formula itself is straightforward:

Blended ARPU = ad ARPU × % free users + IAP ARPPU × % paid users.

Let’s break down what this means:

Ad ARPU is the average ad revenue you make per user (usually the free users who see ads)
You multiply that by the percentage of your user base that’s on the free tier
Then you take IAP ARPPU (the average revenue per paying user from subscriptions or purchases) and multiply it by the percentage of users who’ve paid for something

Add those two pieces together, and you get your blended ARPU: the true average revenue you’re making per active user across your entire app, regardless of whether they’re paying subscribers or ad-supported free users. This is the exact structure we use in our internal tracking spreadsheet to monitor monetization health across different apps.

What makes this metric so powerful is how it reframes the questions you ask. Instead of fragmenting your analysis by asking “Did ad revenue drop this month?” and separately “Did subscriptions increase?”, you can ask one unified question: “Did total revenue per active user increase?”. That shift in perspective changes everything about how you make decisions. It prevents you from accidentally optimizing one revenue stream at the expense of overall profitability, and it helps you see whether changes you’re making, like adjusting ad frequency or changing paywall triggers, are actually improving your business or just shifting money around between buckets.

How to implement a blended ARPU tracker

You can talk about unified monetization strategy all you want, but until you actually build it into your regular cadence of meetings and reviews, teams will default back to optimizing in silos. That’s why we introduced a biweekly blended ARPU tracker across our focus apps and committed to reviewing it consistently with product managers. The key word is ‘consistently’ — this isn’t a metric you check once a quarter when someone asks about it. It’s the framework for every monetization conversation, reviewed every two weeks.

Each app snapshot in our tracker includes a carefully-chosen set of metrics that tell the complete story:

We track monthly IAP revenue and monthly ad revenue separately so we can see the individual components
We calculate free user ARPU (how much ad revenue we’re generating from non-paying users) and subscriber ARPU (how much paying users contribute)
We include paid user percentage because the mix between free and paid users dramatically affects your blended number — an app with 5% paid users will look very different from one with 20% subscribers, even if both have similar total revenue
Then we calculate the blended ARPU itself using the formula we discussed
We also include D1 retention (the percentage of users who come back the day after installing) because monetization changes always need to be balanced against user experience and engagement
Finally, we track biweekly deltas (the change from the previous period) so we can immediately see if experiments or product changes are moving the needle in the right direction

What’s crucial about this structure is the hierarchy: blended ARPU is the primary KPI. Everything else is context. When we sit down for a review, we don’t start by debating whether ad revenue went up, or whether a new paywall performed well. We start with one question: did blended ARPU improve? Then we use all the other metrics to understand why it moved and what levers we can pull to improve it further.

For example, the tracker may look like this:

App	Active users	% Paid	Ads revenue	IAP revenue	Ad ARPU	Sub ARPPU	Blended ARPU	Key insight
App 1	8.3M	0.23%	$567k	$20k	$0.07	$2.82	$0.07	Sub share stabilizes blended ARPU despite install decline
App 2	5.4M	0.44%	$171k	$72k	$0.05	$3.29	$0.06	Higher sub penetration clearly lifts blended ARPU
App 3	2.3M	0.08%	$82.7k	$13.5k	$0.04	$7.71	$0.05	Even low penetration adds measurable lift

Even at low paid percentages, subscriber ARPPU is dramatically higher than ad ARPU. That means small increases in paid share can meaningfully shift total revenue per user. That insight alone reshaped prioritization across the portfolio.

Hybrid monetization framework: how to tell the difference between revenue cannibalization vs. false alarms

Once you’ve committed to blended ARPU as your north star metric, you need a clear system for monitoring it — not just tracking the number, but understanding when to react and when to stay the course. We formalized our monitoring system into three distinct layers that create a structured escalation process, preventing both overreaction to normal fluctuations and delayed response to genuine problems.

Primary KPI: blended ARPU

At the top sits the primary KPI: blended ARPU. This is what we care about most, the ultimate measure of whether our monetization is getting stronger or weaker. Beneath that, we track a set of monitoring metrics that help us diagnose what’s happening under the hood. These include:

Ads revenue per free user (are we monetizing our free tier effectively?)
Impressions per DAU or daily active user (are users seeing the right volume of ads?)
Retention metrics at key intervals: D1, D3, and D7

These monitoring metrics aren’t goals in themselves; they’re diagnostic tools that explain movements in blended ARPU and help us identify which specific lever might be broken or underperforming.

Escalation triggers

The third layer consists of escalation triggers: the conditions that prompt us to actually intervene or reverse a change. We escalate when:

Blended ARPU falls meaningfully and stays suppressed
Ad ARPU drops without a corresponding lift in subscription revenue to compensate for it
We see a sustained retention collapse that threatens the underlying health of the app

Sustained is important here — we expect volatility in app metrics, that’s the nature of the business, so minor dips in ad impressions from one week to the next are completely normal. Small retention fluctuations during funnel optimization experiments are par for the course. What matters is the trend, not the daily noise.

This discipline is what prevents us from making costly mistakes. When you run a subscription experiment that reduces ad impressions, e.g. by showing an earlier paywall, ad revenue will naturally dip in the short term. Teams that only monitor ad metrics in isolation will panic and roll back the change prematurely, never giving the subscription revenue time to compound and overtake the lost ad income. By anchoring to blended ARPU and only escalating when it remains meaningfully suppressed, we give experiments the runway they need to prove themselves while still catching genuinely harmful changes before they do lasting damage.

Revenue vs. ads calculator: how many subscribers do you need to offset ad revenue loss?

One of the biggest obstacles to unified monetization thinking is that the tradeoffs feel abstract and therefore scary. When you’re considering a change that might reduce ad impressions — like introducing a paywall earlier in the user journey or limiting interstitial frequency — the ad revenue loss is immediate and visible, while the subscription gain is hypothetical and delayed. This asymmetry paralyzes decision-making.

To make these tradeoffs tangible and give teams confidence to experiment, we built a simple calculator that answers one critical question: if ad revenue dips, how many new subscribers do we actually need to offset that loss?

The math is straightforward:

Subscriber ARPPU ÷ ad ARPU = the number of free users equivalent to one subscriber.

In other words, this tells you how many ad-supported users one paying subscriber is ‘worth’ in pure revenue terms.

Let’s walk through a real example from one of our apps: in this case, subscriber ARPPU is approximately $2.82 per month. Ad ARPU is about $0.07 per month. Divide $2.82 by $0.07, and you get ~40.

That means one subscriber generates the same monthly revenue as 40 free users watching ads. Put another way, if you convert just one user out of every 40 free users into a subscriber, you’ve maintained exactly the same revenue — while dramatically improving your monetization quality and reducing your dependence on ad networks.

Note that this ratio varies significantly across different apps depending on their monetization mix, subscription pricing, and ad density. In our portfolio, we’ve seen numbers ranging from as low as 60 free users per subscriber in apps with lighter ad loads and premium subscription tiers, all the way up to nearly 190 free users per subscriber in apps with aggressive ad monetization but lower-priced subscriptions.

Regardless of where your specific app falls, knowing this number transforms the conversation. When product managers see that converting a relatively small number of users — say, improving your paywall conversion rate by just 2–3% — can offset the loss of thousands of ad impressions, the fear of “losing ad revenue” to push subscriptions becomes manageable. The tradeoff is no longer a vague anxiety; it’s a quantifiable bet with clear success criteria. You know exactly what conversion rate you need to hit to break even, and anything above that is pure upside.

Let’s look at how this would look in practice:

1. Core exchange rate example

Here, there’s a subscriber vs. ads tradeoff:

Metric	Value	Explanation
Subscriber ARPPU	$2.82	Avg monthly revenue per subscriber
Ad ARPU (free users)	$0.07	Avg monthly ad revenue per free user
Free users per one subscriber	40.3	$2.82 ÷ $0.07

In this scenario, one subscriber generates the same revenue as ~40 free users. So if you convert one out of every 40 free users, revenue remains flat. Anything above that is incremental upside.

2. Breakeven scenario example

For this example, imagine ads dip but there’s subscriber lift:

Scenario variable	Value
Monthly active users	5,000,000
% Free users	99.7%
Ad ARPU	$0.07
Subscriber ARPPU	$2.82
Hypothetical ad ARPU drop	-$0.005

After this, the revenue impact would be:

Calculation step	Result
Revenue loss from ad ARPU drop	$24,925
Required new subscribers to break even	8,841
Formula used	$24,925 ÷ $2.82

For this scenario, if your experiment generates more than 8,841 additional subscribers, it is revenue-positive — even if ads ARPU dips slightly.

Blended ARPU benefit: revenue stability

One of the often-overlooked benefits of using blended ARPU as your primary metric is that it’s inherently more stable than looking at ad revenue or subscription revenue in isolation — and that stability is what allows you to make better decisions with more confidence.

Ads ARPU fluctuates wildly on a daily basis. Ad network fill rates change, eCPMs (effective cost per thousand impressions) vary based on advertiser demand and seasonality, and even small changes in user behavior — like slightly fewer sessions per day — can cause noticeable swings in ad revenue. If you’re monitoring ads ARPU closely, you’ll see it jump up and down constantly, which creates anxiety and makes it difficult to distinguish between meaningful trends and random noise.

Similarly, IAP ARPU fluctuates with the rhythm of your promotional calendar and trial cycles. When you run a discount campaign or offer a special trial period, you might see a short-term spike in conversions followed by a drop-off once the promotion ends. You’ll also see natural cycles tied to when trials convert to full subscriptions or when annual renewals come through. Each of these creates peaks and valleys that can look alarming if you’re only tracking subscription metrics.

Blended ARPU smooths those movements because it’s averaging across two revenue streams that often move in different directions or on different timescales:

When ad revenue dips slightly one week, subscription revenue might be steady or growing
When a promotion ends and new subscription sign-ups slow down, ad revenue from your stable free user base continues flowing

The result is a much clearer signal of your total monetization health — one that cuts through daily volatility and helps you see the actual trend. This doesn’t mean blended ARPU never moves or that you should ignore changes in it. Rather, it means that when blended ARPU does move significantly, you can have much higher confidence that something meaningful is happening, not just normal statistical noise. That clarity is what enables disciplined decision-making and prevents teams from overreacting to the everyday ups and downs that are simply part of running a hybrid monetization business.

The chart shows ads and IAP moving independently while blended ARPU remains comparatively stable. That stability allows teams to make rational long-term decisions.

Embracing blended ARPU

Ads and subscriptions do not have to compete with each other, cannibalizing revenue in an endless internal tug-of-war. They can and should work together as complementary parts of a single, coherent monetization strategy. The problem is that without a unified metric to measure their combined contribution, teams will inevitably optimize in silos — the ads team pushing for maximum impressions, the subscription team advocating for aggressive paywalls — each defending their own territory and reacting to short-term noise in their individual metrics rather than long-term trends in overall business health.

Blended ARPU gives you a stable lens through which to view total revenue health. It cuts through the confusion of competing dashboards and contradictory signals. It tells you, in one number, whether the changes you’re making are actually improving your business. And perhaps most importantly, it creates alignment across subscription app growth teams — everyone is now optimizing for the same thing, which means product decisions can be made faster and with more confidence.

The beauty of this approach is that it isn’t complicated. You don’t need sophisticated machine learning models or expensive analytics platforms. The formula fits in a single spreadsheet cell. What it requires instead is discipline: to review the metric consistently, to let experiments run their course instead of panicking at the first sign of volatility, and to escalate only when blended ARPU shows sustained weakness (rather than reacting to every minor fluctuation!). In hybrid monetization, discipline beats fear every time. Fear tells you to protect your existing ad revenue at all costs. Discipline tells you to measure holistically, experiment thoughtfully, and trust the data. That shift in mindset is what ultimately unlocks the full potential of a hybrid model, allowing you to serve both free and paying users well while maximizing the lifetime value of everyone who comes through your door.

Google Play’s billion-dollar billing leak: How to recover the subscribers you’re losing to payment failures

Thu, 02 Apr 2026 10:51:51 GMT

When a subscription cancels on Google Play, most developers assume the user decided to leave. The billing infrastructure is Google’s problem, right? You build the product, Google handles the payments. If a charge doesn’t go through, that’s between the user and their bank.

The data tells a very different story.

In our 2026 State of Subscription Apps report – covering 115,000+ apps and over $16 billion in tracked revenue – 32.3% of all Google Play cancellations are involuntary billing errors. Not users churning. Not users who decided your app isn’t worth it. Users whose credit card expired, whose prepaid balance ran out, or whose bank flagged a routine charge. They wanted to keep paying. They just couldn’t.

On the App Store, that number is 15.2%. Still significant, but less than half the Google Play rate.

As we put it in the report: “The primary platform difference is not unsubscribe behavior – it’s billing reliability.”

For a $1M ARR Android app, a 32% involuntary cancellation rate translates to north of $300K/year walking out the door. And unlike voluntary churn – which requires product changes, retention experiments, and long feedback loops – involuntary churn is a recoverable revenue stream with well-documented playbooks and near-immediate ROI.

This is probably the highest-return retention work most Android developers aren’t doing. We’ll walk through why the gap exists, what Google Play gives you to fix it, what you need to build yourself, and what recovery actually looks like.

Why Google Play leaks more than Apple

The 2x gap between Google Play and the App Store isn’t a quality problem on Google’s end. It’s structural – a consequence of how each platform’s users interact with payments.

As Jacob Eiting discussed on the Sub Club podcast episode covering the report: “The Apple platform is way more oriented around keeping your credit card up to date. Everything is Apple Pay. You’ve got your Apple subscription to keep your photo library in the cloud. It feels like as a platform, they do kind of more strongly incentivize you to keep your billing updated, keep money flowing through their systems.”

Google Play users, particularly in developing markets, often don’t have that same web of tied services. Their Play Store payment method can go stale for months before they notice. Google also allows prepaid cards and carrier billing in markets where balances frequently run dry – payment methods that Apple doesn’t support at the same scale. As Jacob put it: “Your balance runs out and then the billing fails. The physics are just very different.”

Our report’s retention data reinforces this pattern. Jeff Morris Jr., writing in the expert commentary section, notes that the challenge in emerging markets isn’t long-term retention of a good user – it’s “overcoming initial billing or usage friction.” By the 3rd renewal cycle, all geographies converge to within a few percentage points of each other. The users are there, the payment infrastructure just isn’t keeping up.

The underlying decline categories tell you everything about why this is recoverable. The vast majority of billing failures are “soft” declines – generic declines, insufficient funds, expired cards – that are temporary, situational, and recoverable with retries and a little nudging. By some industry estimates, roughly a quarter to a third of US payment cards are reissued annually, creating a constant background rate of stale credentials even among engaged, willing-to-pay subscribers.

The user didn’t leave, their card did.

The practical upshot: Android developers have both a bigger problem and more granular tools to fix it. The question is whether they’ve configured those tools.

The 60-minute fix: platform tools most developers haven’t touched

Here’s the thing that makes involuntary churn different from almost every other retention problem: the highest-impact interventions are configuration changes, not code. Google provides a 60-day total recovery window with built-in retry logic, payment update prompts, and user notifications. But the default settings leave significant recovery on the table.

If you do nothing else after reading this post, do what’s in this section.

Grace periods: keep the user subscribed while Google retries

Google structures its recovery window into two phases. The grace period keeps the user subscribed with full access while Google retries the payment. If recovery fails during that window, the account hold suspends access but continues retry attempts. As of Google’s December 2025 policy change, the total window is capped at 60 days, with the account hold duration auto-calculated as 60 minus whatever grace period you configure.

Grace periods are now enabled by default on all auto-renewing base plans and can be set for up to 30 days (expanded from earlier limits at Google I/O 2025). During this period, Google retries the charge, emails the user, and sends notifications prompting a payment update. Your app still returns the subscription as active via queryPurchasesAsync(), meaning apps that check entitlements through the standard API handle grace periods automatically with no code changes. If payment recovers during the grace period, the original billing date is preserved – the user never knows anything went wrong.

Google’s published data on the impact is hard to argue with: enabling grace periods delivers a 57% higher recovery rate from renewal declines.

Account holds: the second-chance window

Account holds kick in when the grace period expires. The user loses access, the subscription state shifts to SUBSCRIPTION_STATE_ON_HOLD, and queryPurchasesAsync() stops returning the subscription. This is important – you need to explicitly check for the on-hold state to show the right messaging in your app. Google continues retrying in the background for the remainder of the 60-day window. If the user fixes their payment during account hold, access resumes but the billing date resets to the recovery date.

Google reports that adding account hold on top of grace periods produces 35% higher payment decline recovery and 8% lower involuntary churn. In early cohort data, combining grace period and account hold tripled the decline recovery rate from roughly 10% to 33%.

The In-App Messaging API: two lines of code, 2x recovery

Now, the tool that almost nobody uses. The In-App Messaging API is a single call – BillingClient.showInAppMessages() with InAppMessageCategoryId.TRANSACTIONAL – that displays a Google-rendered snackbar when a user in grace period or account hold opens your app. It shows once per day, includes a direct link to fix payment on Google Play, and requires no custom UI work on your end.

Google’s data shows this produces a 2x increase in user recovery and growth in overall subscriber spend. Two lines of code. Call it on every app launch. If you implement one thing from this post, make it this.

If you’re using RevenueCat, this is already handled – the SDK shows Google Play’s In-App Messages automatically starting in v7. No additional code needed. You can disable it via .showInAppMessagesAutomatically(false) if you want to manage it yourself, but for most apps, the default behavior is exactly what you want.

What about Apple?

The App Store’s involuntary churn rate is less than half of Google Play’s, and more of the recovery happens automatically – billing retry is always on for all auto-renewable subscriptions, and since iOS 16.4, Apple shows a Billing Problem Message to users without any API call on your end. The one thing you should actively opt into is the Billing Grace Period in App Store Connect – set it to 28 days. Apple’s own data shows 90% of billing issues resolve within that window. That’s it for iOS. The rest of this post focuses on Google Play, where the problem is bigger and the developer toolkit is more hands-on.

The Google Play configuration checklist

The total time investment here is about an hour: verify grace periods are enabled and set to the maximum appropriate duration for each base plan (up to 30 days), confirm account hold is set to auto-calculated for a full 60-day window, and add the In-App Messaging API call to your app launch flow.

That’s it. You’ve just recovered a meaningful chunk of your involuntary churn.

If you’re using RevenueCat, grace period and account hold states configured in the Play Console are detected automatically – subscriptions in a grace period remain “active” in your entitlement checks, and a BILLING_ISSUE event fires to your webhooks and connected integrations the moment a payment fails. The Subscription Status chart in the dashboard also surfaces a dedicated “Billing Issue” status, so you can see at a glance what percentage of your active MRR is currently at risk from payment failures. It’s a useful gut check after you’ve made configuration changes – you can watch the billing issue cohort shrink in real time.

Subscription Status chart in RevenueCat

But platform-level tools are a floor, not a ceiling.

The full dunning stack: push, email, and deep links

Once you’ve configured the platform defaults, the next layer of recovery comes from developer-side dunning – the industry term for communicating with users about failed payments and prompting them to fix it. This is where you move from “configuration” to “engineering investment,” but the ROI remains strong.

Push notifications and in-app messaging

The timing cadence matters more than the copy. Fire the first push notification on Day 0 when the decline is detected via Google’s Real-Time Developer Notifications (RTDN). Follow up on Days 1–3, then Day 7, then Day 14. After that, diminishing returns set in.

Keep the tone helpful, not alarming. “We’re having trouble renewing your subscription – tap to update your payment method” works better than anything that sounds like a warning siren. The user didn’t do anything wrong; their card did.

Calibrate your in-app messaging to the subscription state. During the grace period, the user still has access – a non-blocking banner or snackbar is appropriate. During account hold, escalate to a more prominent modal explaining that access is suspended, with a clear call-to-action.

Google’s In-App Messaging API already handles a once-daily in-app prompt during grace period and account hold, so your developer-side push notifications serve as a complementary channel – catching users who haven’t opened the app.

To trigger all of this, you need Real-Time Developer Notifications set up via Google Cloud Pub/Sub. The billing-related notification types to handle are SUBSCRIPTION_IN_GRACE_PERIOD (type 6), SUBSCRIPTION_ON_HOLD (type 5), SUBSCRIPTION_RECOVERED (type 1), and SUBSCRIPTION_EXPIRED (type 13). After receiving any RTDN, call purchases.subscriptionsv2.get to fetch the full subscription state – RTDNs signal that something changed but don’t carry complete details.

If you’re using RevenueCat, this plumbing is already done for you. The BILLING_ISSUE event fires automatically to your connected integrations – Braze, OneSignal, Iterable, Customer.io, and others – so you can trigger dunning campaigns directly from the tools you’re already using without building your own RTDN processing pipeline. The event includes grace_period_expiration_at, giving your campaigns the exact deadline to work with.

Deep linking to payment settings

Every extra tap between your dunning message and the payment update screen costs you recovered subscribers. The best recovery flows route users directly to the right screen with a single tap.

On Android, link to: https://play.google.com/store/account/subscriptions?package={packageName}&sku={skuId} – this takes users directly to their specific subscription on Google Play.

On iOS (for your cross-platform setup), use AppStore.showManageSubscriptions(in:) in StoreKit 2 (iOS 15+) to display the subscription management sheet without leaving your app.

If you’re using RevenueCat, the managementURL property on CustomerInfo returns the correct platform-specific URL automatically. This means your in-app billing error UI can include a one-tap “Fix payment” button that works across both stores without hardcoding store-specific URLs or maintaining platform branching logic.

Email dunning sequences

Email catches users who aren’t opening your app or aren’t seeing push notifications. A 3–5 message sequence over 14–28 days works well, shifting from friendly notification (“Heads up – we couldn’t process your payment”) to urgency (“Your subscription is at risk”) to final warning (“Last chance to keep your subscription”). Personalize with the user’s name and the specific features they’ll lose access to. Make the call-to-action button prominent and link directly to payment update.

One nuance worth flagging: pre-dunning emails that warn about upcoming card expirations – sent before a failure happens – sound good in theory but can backfire in practice. They can prompt users to reconsider whether they want the subscription at all, especially if the app isn’t top-of-mind. For active users, in-app prompts about expiring cards tend to be safer than email.

Recovery benchmarks: what to expect

Recovery rates vary based on how many of these tools you actually activate. Here’s what Google’s published data suggests, supplemented by their developer case studies:

Platform defaults only (no grace period optimization, no developer intervention): roughly 10–15% recovery of failed payments. This is where most apps sit today.
Optimized grace periods + account holds + In-App Messaging API (about an hour of configuration): roughly 30–35% recovery on Google Play. Google’s published data shows the combined effect of grace period and account hold triples recovery from the baseline. The In-App Messaging API doubles user recovery on top of that.
Full dunning stack (push notifications + email sequences + deep links on top of the platform tools): the incremental gains from each channel compound. In Google’s published Truecaller case study, implementing RTDN-triggered messaging alongside grace periods and account hold recovered 40% of at-risk subscribers – up from 15% before the changes.

Now consider what a recovered subscriber is actually worth. Our 2026 State of Subscription Apps data shows that a subscriber who survives their 1st monthly renewal has a 73–82% chance of making it to their 3rd. Every billing failure you recover in cycle 1 is a subscriber who gets the chance to become one of those high-retention renewals. Conversely, our reactivation data shows that once a monthly subscriber actually churns, only about 20% come back within a year – and for annual subscribers, it’s a dismal 5%. Preventing the loss is dramatically more valuable than winning the user back later.

Whichever tier you’re operating at, make sure you’re measuring the impact. Track your billing error cancellation rate by platform (RevenueCat’s Subscription Retention chart excludes unresolved grace period transactions, so your retention numbers reflect actual recovered subscribers). Compare cohorts before and after you extend grace periods. The feedback loop here is fast – you should see movement within a single billing cycle.

Fix billing before you buy more users

Involuntary churn is one of those rare problems where the diagnosis is clear, the tools already exist, and the returns are immediate. The instinct to treat billing failures as the platform’s problem is understandable – but the data is unambiguous. A third of your Google Play cancellations are subscribers who wanted to keep paying.

The highest-impact work is configuration, not code. Extend your grace periods. Enable account hold. Add Google’s In-App Messaging API. That’s an afternoon of work that recovers real revenue starting the next billing cycle.

Fix billing before you buy more users.

“Money will come” – How Super Unlimited built the #1 VPN by not optimizing for revenue

Wed, 01 Apr 2026 12:56:35 GMT

Tanuj Chatterjee is the CEO of Super Unlimited VPN — the #1 VPN app in the world by downloads, with over a billion installs and more than a million new downloads every day, almost entirely organic. In a conversation with David Barnard and RevenueCat CEO Jacob Eiting, he breaks down the product-driven growth loop that got them there, the deliberate decision to leave money on the table, and what five years of A/B testing has taught him about the gap between what looks good and what actually converts.

The screenshot redesign that kept losing

Super Unlimited’s App Store screenshots are, by Tanuj’s own admission, a little stale. The team has spent years trying to fix that. They’ve tested modern layouts, updated colors, new content arrangements, and contemporary design trends. The results have been consistent: 80% of the time, the new version loses.

“People just like to see what they were used to seeing,” Tanuj says. “In many cases, we have gone back to the original ones that we had.”

The finding cuts against one of the most common instincts in app growth: that better design means better conversion. For an app sitting at the top of App Store search, the risk of a major visual overhaul is asymmetric. Disrupting a proven asset is more dangerous than the upside of a marginal lift. The team still tests — methodically, one variable at a time — but they’ve learned to treat the data as the authority, not their aesthetic judgment.

Why a low conversion rate is part of the strategy

Super Unlimited’s free-to-paid conversion rate is, by most subscription app standards, quite low. Tanuj is fine with it.

“Our free version is that good,” he says. “You don’t want to throttle or take things away from the free version. There’s a reason we have the word unlimited in our name.”

Free users can access dozens of countries and cities, watch a couple of ads, and use the VPN without restrictions. The paywall exists — premium subscribers get no ads, top-tier servers, multi-platform access, and priority support — but it’s designed to be easy to dismiss. There’s a large X in the corner. No dark patterns.

The logic is a numbers game. Super Unlimited’s LTV is modest compared to a Spotify or a Netflix. But their top of funnel is enormous, and it’s almost entirely organic. The free experience generates the ratings volume and return-visit signals that feed the App Store algorithm, which keeps the downloads coming. “Our top of the funnel is our superpower,” Tanuj says. “Don’t mess with it.”

The countries where they lose money on purpose

Super Unlimited serves users in countries where the economics don’t work. Turkey, Myanmar, and other markets with low CPMs, high infrastructure costs, or active internet censorship are not profitable. The team knows this and serves them anyway.

When Turkey banned Instagram for 11 days last year, Super Unlimited received 15 million downloads in four days — roughly 30-40% of Turkey’s internet population. The revenue from those users didn’t cover the cost of serving them.

“We just think it’s the right thing to do,” Tanuj says. “People should have access to information. They should not be constrained by just propaganda.”

This isn’t purely altruistic. The geopolitical spikes that come with being a global VPN have a compounding effect: each spike drives the app to a new normal at a higher baseline once the event passes. But the decision to serve loss-making markets is a deliberate one, made on values grounds, not just financial ones.

What happened when support moved into the product team

At most companies, customer support is a separate organization. It presents KPIs to the product team once a month. The feedback loop between user pain and product fix takes weeks.

At Super Unlimited, the head of support reports directly to the head of product.

“I have been at companies where product and support was a totally separate organization,” Tanuj says. “The pace at which the feedback loop goes into the product side is a lot less.”

When a spike in support tickets from Uganda signals a service quality issue, the product team knows the same day — not next month. A recurring question about a feature becomes a UX fix in the next sprint, not a FAQ entry. For an app where service quality is the primary competitive advantage, the speed of that loop is the speed of improvement.

The episode also covers how Super Unlimited thinks about paid search when you’re already the #1 organic result, why they’re betting on Windows as their next growth vector, and the infrastructure decision — bare metal servers for the data plane, cloud for surge capacity — that makes their unit economics work at scale.

Guest links:

Tanuj Chatterjee on LinkedIn
Super Unlimited VPN
Hiring in Asia and Europe: jobs@superunlimited.com

Kotlin Coroutine bridges: converting any callback-based Android API to suspend functions

Tue, 31 Mar 2026 23:26:22 GMT

Most Android platform APIs and third party SDKs were designed around callbacks. The Google Play Billing Library uses PurchasesUpdatedListener. Location Services uses LocationCallback. Bluetooth GATT uses BluetoothGattCallback. Camera2 uses CameraCaptureSession.StateCallback. If you have been writing Android code for more than a few months, you have written deeply nested callback chains that are hard to read, hard to test, and hard to reason about when errors occur at any stage. Kotlin coroutines solve this with suspend functions, but the platform and most SDKs do not hand you suspend functions out of the box. You need a bridge.

In this article, you’ll explore the suspend coroutine bridge pattern in detail, tracing how it converts callback based APIs into clean suspend functions, how to handle different callback shapes from single value results to multi parameter success and error pairs, how to design exception hierarchies that preserve error semantics across the bridge, why you should always reach for suspendCancellableCoroutine rather than the older suspendCoroutine — even when the underlying callback API has no native cancellation — and how production SDKs like RevenueCat apply these patterns at scale across 20+ API surfaces.

The fundamental problem: Callbacks do not compose

Consider a common billing flow on Android. You need to connect to the billing service, query products, then initiate a purchase. With the raw callback API, this looks like:

Each callback nests inside the previous one. Error handling is scattered across if checks and separate override methods. There is no structured way to propagate failures up the chain. And this is only two callbacks deep. A full billing flow, connecting, querying, purchasing, acknowledging, involves four or five nested levels.

The suspend function equivalent reads like sequential code:

This is not a language feature you get for free. Each of those await functions requires a bridge that converts the underlying callback into a coroutine suspension point. Let’s trace through exactly how that bridge works.

The core bridge: `The core bridge: suspendCancellableCoroutine`

Kotlin provides two primitives for bridging between callback based code and coroutines: suspendCoroutine and suspendCancellableCoroutine. They look almost identical — both suspend the current coroutine and hand you a continuation that you later resume with a result or resumeWithException with an error — but only one of them is safe to use in real code: suspendCancellableCoroutine.

The plain rule, stated up front: do not use suspendCoroutine in application or library code. Its continuation is not tied to coroutine cancellation, so when a parent Job is cancelled the leaf cannot tear down. The coroutine stays parked, holding references to its scope and context, until (or unless) the callback eventually fires. That is a structured concurrency hole and, in practice, a latent memory and resource leak.

Worse, cancellation and exceptions further up the tree can’t propagate past a coroutine that refuses to finish, which is how a single stuck bridge wedges a whole screen’s scope. suspendCancellableCoroutine closes the hole by giving you a CancellableContinuation that participates in cancellation, even when the underlying callback based API has no cancellation support of its own. Every example in this article uses it.

The simplest bridge handles a single value callback:

The pattern has three parts. First, call suspendCancellableCoroutine to pause the coroutine and receive a CancellableContinuation. Second, call the callback based API, passing an anonymous implementation that captures the continuation. Third, inside the callback, call resume or resumeWithException to deliver the result and unfreeze the coroutine. When the underlying API supports teardown, register a cleanup block through invokeOnCancellation so cancellation actually releases the resource instead of waiting on a callback that may never come back.

One important rule: you must call resume or resumeWithException at most once per non cancelled continuation. Calling it zero times means the coroutine hangs forever (unless cancelled from outside). Calling it twice on a live continuation throws IllegalStateException. After cancellation, CancellableContinuation.resume simply drops the value, so you do not need to guard every resume with an isActive check — but every non-cancelled code path through your callback must reach exactly one resume call.

Success and error callbacks: The two-path bridge

Most SDK APIs split their callbacks into success and error paths. This maps naturally to resume and resumeWithException. Let’s examine how RevenueCat’s Android SDK bridges its offerings API.

Looking at the awaitOfferings extension function:

Notice the structure. The onSuccess path uses a method reference continuation::resume directly. When the callback signature matches (T) -> Unit and the continuation expects T, a method reference is the cleanest form. The onError path wraps the raw PurchasesError in a PurchasesException before passing it to resumeWithException. This is necessary because resumeWithException expects a Throwable, but the SDK’s error type is a plain data object, not an exception.

The @JvmSynthetic annotation prevents this extension function from appearing in Java code, since Java callers should use the callback version. The @Throws annotation generates the throws clause in the bytecode so Java interop and documentation tools correctly report what this function can throw.

The callback factory: Abstracting interface boilerplate

Before the suspend bridge can work, there is another layer of bridging. Many Android SDK APIs accept typed callback interfaces, not lambda pairs. For example, Google Play Billing uses PurchaseCallback with onCompleted and onError methods. RevenueCat’s internal API uses ReceiveOfferingsCallback with onReceived and onError.

Writing anonymous implementations of these interfaces inside every suspend function creates noise. The solution is a set of factory functions that convert lambda pairs into typed callback objects.

Looking at the callback factory for offerings:

This is a small function, but it matters at scale. RevenueCat’s SDK has factory functions for offerings, customer info, store products, purchases, login, sync, and more. Each one converts the (onSuccess, onError) lambda pair into the specific callback interface the underlying API expects.

The purchase callback factory handles a more complex shape:

Notice the asymmetry. The success callback delivers two values: the transaction and the updated customer info. The error callback also delivers two values: the error and a boolean indicating whether the user cancelled. This is not a simple (T) -> Unit shape. Bridging this to a suspend function requires additional design decisions.

Multi-value callbacks: Wrapper classes

When a callback delivers multiple values, you need a container to return them from a single suspend function. The approach is straightforward: define a data class that bundles the values.

Looking at RevenueCat’s PurchaseResult:

The suspend bridge then constructs this wrapper in the success path:

Two things are worth noting here. First, the success path wraps both values into a PurchaseResult so the caller gets a single typed return value. Second, the error path uses PurchasesTransactionException instead of the regular PurchasesException. This is because the error callback carries an extra userCancelled boolean that callers need to distinguish user initiated cancellation from actual errors. The exception hierarchy preserves this information.

Exception hierarchies: Preserving error semantics

A common mistake when bridging callbacks to coroutines is losing error information. Wrapping every error in a generic Exception(message) throws away the structured error code that callers need for programmatic error handling.

Looking at RevenueCat’s exception design:

The exception wraps the original PurchasesError object, preserving the typed PurchasesErrorCode enum. Callers can use a when expression on the code to handle specific error conditions:

The transaction exception extends this with the cancellation flag:

This hierarchy means callers can catch PurchasesException for all errors, or catch PurchasesTransactionException specifically for purchase errors where they need to check whether the user cancelled. The is check works naturally:

The key observation: the exception hierarchy mirrors the callback signature shapes. A callback with (error) maps to PurchasesException. A callback with (error, userCancelled) maps to PurchasesTransactionException. This is not accidental. It is a deliberate design that makes the suspend API as expressive as the callback API.

The `Result<T>` variant: Exceptions are not always what you want

Not every caller wants to use try/catch. Some prefer kotlin.Result<T> for composable error handling. RevenueCat provides a second variant for every suspend bridge:

The key difference: the error path calls continuation.resume(Result.failure(...)) instead of continuation.resumeWithException(...). From the coroutine’s perspective, the function always completes successfully. It returns a Result that the caller unwraps:

This pattern is useful in pipelines where you want to chain operations without try/catch blocks:

The purchase Result variant follows the same pattern:

The error information is not lost. The PurchasesTransactionException is still inside the Result.failure, so callers who need the userCancelled flag can check it:

This dual API approach, throwing suspend functions and Result returning suspend functions, gives consumers the choice without forcing one style. The SDK does not pick winners. It supports both.

The lambda convenience layer: Bridging before the bridge

There is a middle layer between the raw callback interface API and the suspend bridge that is worth examining. RevenueCat provides extension functions that accept lambda pairs instead of typed callback objects:

This is a two step bridge design. The lambda extension (getOfferingsWith) converts lambdas to a typed callback. The suspend extension (awaitOfferings) converts the lambda extension to a coroutine. Each layer does one thing.

Notice the default error handler:

internal val ON_ERROR_STUB: (error: PurchasesError) -> Unit = {}

This allows callers who do not care about errors to omit the error handler. This is useful for fire and forget operations, but should be used carefully since silently swallowing errors is a common source of bugs.

The purchase version has its own stub:

internal val ON_PURCHASE_ERROR_STUB: (error: PurchasesError, userCancelled: Boolean) -> Unit =
    { _, _ -> }

Two separate stubs for two different callback shapes. Each matches the exact lambda signature its callback requires.

Real-world application: Bridging Google Play Billing directly

The same suspendCancellableCoroutine pattern applies to any callback based Android API. Here is how you would bridge Google Play Billing’s acknowledgment API:

And the consume API follows the same structure:

Even the billing client connection, which has two separate callback methods (onBillingSetupFinished and onBillingServiceDisconnected), bridges cleanly:

The onBillingServiceDisconnected method is called after a successful setup when the connection is later lost, not as an alternative to onBillingSetupFinished during the initial connection. This is an important subtlety. If both methods could fire during setup, you would need additional state tracking to ensure exactly one resume call.

Why `suspendCancellableCoroutine` is always the right default

The earlier rule — “do not use suspendCoroutine in application or library code” — deserves its own section, because it’s easy to look at the two function names and assume they are equally valid tools for different jobs. They are not. suspendCoroutine is a low level primitive whose semantics predate the structured concurrency model we actually build on today, and its behavior is fundamentally incompatible with cancellation.

Here is what actually happens when you call suspendCoroutine inside a cancellable scope. The continuation you receive is a plain Continuation<T>. It has no knowledge of the Job that invoked it. When the parent Job is cancelled — because a ViewModel is cleared, a LaunchedEffect leaves composition, a coroutineScope { } block throws, or the user navigates away — the cancellation signal travels to every child that participates in structured concurrency. Your suspendCoroutine leaf does not participate. It cannot be cancelled, so Job.cancelAndJoin() cannot complete, sibling failures cannot propagate past it, and the entire scope is held open waiting for a callback that may never fire.

The practical consequences are the ones you would expect from a leak:

The continuation retains the calling coroutine’s context, including references to lifecycle-scoped objects like ViewModels, Activitys, or Composers. Those objects can no longer be garbage collected.
Any resource registered in the surrounding scope — a database session, a Bluetooth GATT handle, an open socket — stays alive until the callback eventually comes back.
Exceptions in sibling coroutines cannot be delivered in a timely way; the scope can’t finish cancelling its other children while the leaf is stuck, so failures silently disappear or surface seconds (or hours) later, detached from their cause.

suspendCancellableCoroutine is the fix, and it is the fix even when the underlying callback based API has no native cancellation to hook into. Its continuation participates in the coroutine’s Job graph: cancellation of the parent immediately resumes the continuation with a CancellationException, the leaf tears down, the scope unwinds, and references are released. The underlying callback can still fire later — you just ignore it, because CancellableContinuation.resume on an already-cancelled continuation is a safe no-op. The in-flight network request or SDK call keeps running to completion on its own, but it no longer holds your coroutine hostage.

The upgrade from suspendCoroutine to suspendCancellableCoroutine is almost always free. For callbacks you have no control over, the change is a single-word rename:

For callbacks whose underlying operation can be cancelled or whose resources should be released eagerly, add invokeOnCancellation for cleanup:

That’s it. You get correctness at no complexity cost. There is no category of “short lived, non cancellable” callback where suspendCoroutine is the pragmatic choice — short lived operations still need to honor cancellation, because the thing that is actually short lived is only short lived on average. Network calls stall. App processes freeze mid request. An SDK callback that “always fires quickly” has a long tail of cases where it doesn’t, and those are exactly the cases where a leaked scope matters most.

Treat suspendCoroutine as a platform primitive that exists mainly so that suspendCancellableCoroutine can be built on top of it. In the code you write, always reach for suspendCancellableCoroutine.

Applying the pattern beyond billing

The bridge pattern is not limited to billing APIs. The same approach works for any callback based Android API. A few examples:

For FusedLocationProviderClient, which delivers location through LocationCallback:

The Google Tasks API doesn’t expose a cancellation hook on lastLocation, but the bridge still uses suspendCancellableCoroutine: when the caller’s scope is cancelled, the continuation tears down immediately and the in-flight Task is left to complete on its own — its eventual callback simply finds an already-cancelled continuation and is a no-op.

For SharedPreferences, which uses OnSharedPreferenceChangeListener for change notifications:

The common structure is always the same: wrap with suspendCancellableCoroutine, register the callback, resume when the callback fires. What changes is the callback shape, how many values you need to capture, and whether cancellation cleanup is needed.

Common mistakes to avoid

Resuming zero times

If there is a code path where the callback never fires, the coroutine suspends forever. This is especially common with connection listeners that have multiple callback methods:

Using suspendCancellableCoroutine here means a parent-scope cancellation can still tear the coroutine down, but if no cancellation arrives the bridge is still wedged forever waiting on a callback that never came. The right primitive doesn’t save you from a missing resume path.

The fix is to ensure every callback path reaches a resume call, or use suspendCancellableCoroutine with a timeout:

Resuming twice

If a callback can fire multiple times (like a location listener that delivers updates continuously), the suspend bridge is the wrong tool entirely. Each call to resume after the first throws IllegalStateException, regardless of whether you used suspendCoroutine or suspendCancellableCoroutine. For repeating callbacks, use callbackFlow instead:

suspendCancellableCoroutine is for one shot callbacks. callbackFlow is for streaming callbacks. Choosing the wrong primitive leads to crashes or hangs.

Losing error type information

Wrapping all errors as Exception(error.message) strips away the structured error data callers need:

The extra work of defining a typed exception class pays for itself every time a caller needs to handle specific error conditions differently.

Conclusion

In this article, you’ve explored the suspendCancellableCoroutine bridge pattern from its simplest form, a single value callback, through the production patterns used in RevenueCat’s Android SDK: multi value wrapper classes, typed exception hierarchies, callback factory functions, and dual API styles with both throwing and Result returning variants. The pattern is always the same three steps: suspend the coroutine, register the callback, and resume exactly once. And it always uses suspendCancellableCoroutine, never the older suspendCoroutine, so every leaf in your coroutine tree honors structured concurrency.

Understanding this bridge is practical knowledge for any Android developer. Most of the platform APIs you use daily, billing, location, Bluetooth, camera, were designed around callbacks. Converting them to suspend functions makes your code sequential, testable, and composable. The patterns covered here, especially the callback factory layer, the typed exception hierarchy, and the Result<T> variant, are directly reusable in your own projects.

Whether you’re bridging Google Play Billing’s PurchasesUpdatedListener, wrapping a legacy networking library, or building a suspend friendly API for your own SDK, these patterns provide the foundation for clean, correct coroutine integration on Android.

As always, happy coding!

— Jaewoong (skydoves)

AI features are eroding your subscription app’s margins — here’s how to fix it

Thu, 26 Mar 2026 13:16:10 GMT

Right now, many subscription apps are adding AI features as quickly as possible. And it’s working — the product demo looks impressive, engagement spikes, the feature quickly becomes central to the app and user experience. But something else starts happening underneath the surface. With every generation, every prompt, and every “generate again” button click, the cost of serving your users is quietly (but rapidly) increasing.

Working with several AI-powered subscription apps recently, I started noticing this pattern. The very behavior you are trying to encourage — more usage, more exploration, more interaction — can now compress your margins if monetization and infrastructure are not designed in tandem.

AI is not just another product feature. It is infrastructure. So if you’re not modeling AI usage against ARPU, churn, and LTV before you ship it, you may be increasing engagement while quietly destroying your economics.

User engagement isn’t free anymore

Subscription businesses are structurally efficient. Or they used to be. Once you’ve built the core product experience, the marginal cost of serving an additional subscriber inside the app is typically close to zero, and the economics compound as you scale. (Thomas Petit talks about this in his blog on why hybrid monetization should now be the default for subscription apps.)

AI, on the other hand, disrupts that elegance. By introducing AI-powered features, you introduce variable cost at the feature level. Every time a user triggers an AI interaction, tokens are consumed, inference endpoints are called, and a third-party provider bills you for compute (the hardware resources used to make AI models work).

In short, your cost structure becomes inextricably linked to usage.

This creates a subtle but important tension — the same engagement you’ve worked so hard to increase now drives incremental cost. Higher engagement increases AI calls → more AI calls increase infrastructure spend. And unless revenue expands proportionally, your gross margin begins to shrink.

5 Ways to reduce AI spend in your app

So what does this mean? AI features are inherently a margin shrinker? No, not quite. AI means subscription businesses need to think more like cloud infrastructure businesses. Meaning usage is no longer just a growth metric, but also a cost driver.

1. Apps should buy AI infrastructure, rather than build it

I recently spoke with a portfolio Ops Manager working across several AI products and they described a familiar problem — the music generation API powering one of their apps became unstable, and suddenly even paying users couldn’t access the core feature. Complaints rose, reviews worsened, and monetization performance became harder to interpret.

This is what makes AI different from traditional app features. The question isn’t just whether users want the feature, it’s whether your infrastructure can deliver it reliably enough to support retention and revenue (without breaking your economics).

This is why I’d generally encourage thinking carefully about the infrastructure you choose. Training large datasets or creating your own models can make sense if you’re running a large-scale AI platform, but most subscription apps are far better served by using third-party APIs (e.g. Open AI’s ChatGPT, Google’s Gemini, Anthropic’s Claude) — particularly if you’re still experimenting with monetization and feature or product-market fit.

Running your own models introduces a number of challenges:

GPU overhead
DevOps complexity
Model maintenance risk
Fixed monthly burn (regardless of usage)

It’s a dangerous position to be in. So for many growth-stage subscription apps, using API-based foundation models makes more sense:

Paying per token converts AI into a variable cost that scales with actual usage
If a feature fails to move install-to-paid conversion, trial starts, ARPU, or retention, you can shut it down and your cost disappears with it

TL;DR: Variable cost preserves strategic agility. Fixed infrastructure locks you into experiments that may not justify themselves.

2. Treat AI usage like paid media spend

Subscription teams are usually obsessive about acquisition cost. They track CAC, payback periods, and ROAS down to the decimal. But many of the same teams treat AI usage casually, even though AI tokens are just another form of spend.

Every time a user triggers an AI feature, you pay for it. The longer the prompt, the longer the response, and the more often users hit ‘regenerate’, the higher your cost becomes. Think of it the same way you think about paid ads: every impression costs money, every click costs money. AI works the same way — every request has a price.

One AI team I spoke with saw this effect immediately when they changed their credit system. They moved from a restrictive daily allowance to a flexible monthly pool. Generation volume increased overnight. Some users burned through a large portion of their credits on the first day. The feature hadn’t changed, the usage constraints had. And with AI products, usage constraints directly affect infrastructure cost.

Smart teams design AI features with cost in mind. They limit how long responses can be, and avoid unnecessary explanations from the model unless the user actually needs them. Small decisions here matter more than you think. For example, asking an AI model to write a 600-word explanation is far more expensive than asking it to return a structured, 30-word answer.

At scale, those choices can significantly reduce AI costs. Across millions of requests, that is not a small optimization. It is a meaningful gross margin lever.

3. Use the cheapest AI model that gets the job done

Another common cost leak is sending every AI request to the most powerful model available. It feels safe. Teams assume the best model will produce the best experience. But in many cases, it just produces the highest bill.

Not every task requires a powerful model. Many AI features are doing relatively simple work; things like tagging content, formatting text, summarizing information, or generating short outputs. Smaller, cheaper models can handle these tasks perfectly well and deliver the same user satisfaction. Users won’t be able to tell the difference between a premium and mid-tier model, but your infrastructure bill will definitely show it.

Reserve expensive models for complex work that genuinely requires deeper reasoning, and use cheaper models for everything else. Choosing the right model for each task is one of the highest-leverage cost optimizations available to AI-powered apps.

4. Reuse AI results instead of regenerating them

User behavior is more repetitive than most teams expect. Especially in productivity and utility apps, users tend to ask for the same kinds of things again and again. Similar prompts, similar transformations, similar workflows. If your app generates a brand new AI response every time, you may be paying repeatedly for answers that have already been generated. Similarly, users may ask something then come back another time and ask again, rather than scrolling back to find the original conversation.

These are prime times to reuse results whenever possible: save common outputs, store reusable templates, and pre-generate responses for frequent requests so they can be served instantly instead of regenerated. Even small improvements here can have a big impact. If you can reuse results for just 20% of requests, your AI costs can drop significantly.

5. Gate AI features behind monetization

We’re already seeing a pattern of apps limiting AI usage in their free tier and gating advanced capabilities behind subscription plans — typically spread across pricing tiers to reflect compute cost, as well. Changes like this are not shocking to users, but can make a big financial impact to you.

Some apps even implement daily or monthly usage caps to prevent a small group of heavy users from driving disproportionate infrastructure cost. Consider a heavy AI user that costs you $0.15 per month, but later purchases an annual plan that generates $29.99; the economics are comfortable. But if that same user never converts and continues consuming AI indefinitely, the economics quietly deteriorate.

One team I spoke with introduced a quota system in their AI-powered learning product. New users received an initial credit allowance, with additional usage unlocked through paid packages. Models like this understand that usage and cost are relative.

Another AI app team I worked with chose not to offer a traditional free trial, since trial users were able to generate large volumes of output, consume API cost, then churn before ever paying. Instead, the team tested a one-time credit allowance that let users evaluate the quality of the product without exposing the business to unlimited inference cost.

The real risk with free AI credits is not simply that users use them. It’s that they use them before the product is good enough to make them convert. In that case, you’re funding churn, not activation.

This is what makes AI monetization for subscription apps fundamentally different from traditional subscription packaging — you’re not just pricing access to value. Every change made to monetization or pricing and packaging affects a wider infrastructure economy. Usage and retention analysis are invaluable; work to understand who uses what, how often, and why, then revisit your P&P and compute costs hand-in-hand.

The unit economics of AI

The whole conversation around AI’s hidden cost is difficult to quantify, though it’s easier if you already have your own AI features or app running, so let’s anchor it in familiar subscription metrics.

Assume you have a subscription app with these stats:

Monthly ARPU: $6.00
Normalized annual ARPU: $4.20
Blended ARPU across the user base: $5.10
Monthly churn: 5%
Gross margin (before AI): 85%

You then introduce an AI feature. The average AI-active user makes 10 requests per month, each consuming 1,000 tokens. Each token costs you $0.002, making the cost per active AI user (and 1,000 tokens) $0.02.

With 300,000 MAU and 15 percent AI engagement, you have 45,000 AI-active users. That results in a monthly AI cost of $900, or $10,800 annually. That is manageable.

Now imagine usage increases and routing shifts toward more expensive models. Cost per active AI user rises to $0.10 per month. With the same 45,000 AI-active users, monthly cost becomes $4,500, or $54,000 annually.

Whether or not that sounds like a lot depends on many factors. But ultimately, it depends on whether the AI feature increases LTV more than it increases cost per user. In other words…

Is the AI feature worth the cost?

Suppose install-to-paid conversion is 4% across one million annual installs, producing 40,000 paying users. With an average LTV of $42, baseline annual subscription revenue is $1.68 million.

If the AI feature increases install-to-paid conversion by just 0.5 percentage points, paid users rise to 45,000. That is 5,000 incremental subscribers, representing $210,000 in additional revenue.

Against $54,000 in annual AI infrastructure cost, the feature generates far more revenue than it costs to run. Ergo, it’s worth the cost.

However, if conversion doesn’t move enough and retention does not improve, you’re spending $54,000 to increase engagement metrics that do not affect revenue. Gross margin declines, contribution margin per MAU shrinks, and the feature becomes an expensive distraction.

This is how AI quietly kills subscription businesses.

Everyone is fixated on AI, but no one is fixing retention

Does this mean AI needs to increase conversion in order to justify its cost? Ideally, yes. But it can also improve retention.

With monthly ARPU of $6 and churn of 5%, theoretical steady-state LTV is approximately $120. If AI reduces churn to 4.6%, LTV rises to roughly $130. That is a $10 increase per subscriber, and across 20,000 subscribers, that’s $200,000 in incremental value.

Going back to the original figure, if AI costs $54,000 annually but produces even modest retention improvements (in the example, a 0.4% reduction), it can be one of the highest-return investments available.

Before getting too excited and adding new AI features, it’s worth remembering that retention improvements need to be observed in cohort data, not inferred from engagement alone. The improvements from AI need to be measurable.

Reading AI’s value: AI cost belongs in your revenue dashboard

RevenueCat already gives you a clear view of the metrics that drive subscription performance: ARPU, churn, LTV, and cohort retention. That’s half of the puzzle. If your app includes AI features, you need to be analyzing your AI infrastructure costs alongside those metrics.

In practice, this means combining your AI usage data with your subscription metrics to understand how usage affects margins.

You should know things like:

AI cost per MAU
AI cost per AI-active user
AI cost per paying user
AI cost as a percentage of ARPU
AI cost relative to blended ARPU

Looking at these numbers next to your subscription metrics makes it much easier to understand whether AI is strengthening your business or quietly eroding your margins.

At $6 ARPU and $0.18 AI cost, you’re spending ~3% of revenue. Fine. At $3.50 ARPU and $0.60 cost, that jumps to 17%. That’s not a feature cost, it’s a structural margin problem.

Blended ARPU in hybrid monetization

In hybrid monetization models combining ads and subscriptions, the analysis becomes more nuanced — if AI cost applies broadly to free users as well as subscribers, then cost per MAU needs to be evaluated against blended ARPU.

Putting that into numbers, imagine subscriber ARPU is $6, ad ARPU is $0.20, and blended ARPU across MAU is $0.95. If AI costs $0.06 per MAU, then that is ~6% of revenue. If AI costs $0.20 per MAU, it consumes >20% of blended revenue.

Analyzing the metrics is crucial in understanding how AI is reshaping your monetization model. Hybrid operators must be especially disciplined in protecting blended margin, but any teams working with AI features must be conscious of how it impacts margins.

Operator checklist: before shipping AI

Before launching any AI feature, you should be able to answer the following with numbers:

Which metric are you targeting? Install-to-paid conversion, trial starts, trial conversion, retention, or ARPU expansion?
What lift do you hypothesize? A 0.3 conversion increase? A 0.2 churn reduction?
What is the projected AI cost per active user and per paying user?
What percentage of ARPU will AI consume at expected usage levels?
At what usage threshold does AI push gross margin below your acceptable range?

If you can’t answer these questions, shipping isn’t strategic.

AI only works if the economics do

For years, subscription apps benefited from a simple economic model, and more engagement usually meant more value and better retention, with barely any increased cost. AI has changed that for good.

This doesn’t mean AI is bad for subscription businesses. In many cases, it can improve retention, increase conversion, and expand LTV. But those outcomes aren’t guarantees; they happen when teams treat AI as both a product feature and a cost layer.

Teams need to manage AI the same way they manage acquisition spend or infrastructure. Reuse results, route tasks to cheaper models, gate access behind monetization, and track AI cost alongside subscription metrics like ARPU and LTV. The most successful AI apps are not simply adding features, they are designing the entire system around the economics of usage.

“Solve time, and they’ll pay you”

Wed, 25 Mar 2026 14:30:28 GMT

Antoine van der Lee is the developer behind SwiftLee, a wildly popular iOS development blog, and RocketSim, a developer tool that supercharges the Xcode simulator. In a conversation with Charlie Chapman on the Launched podcast, he explains how RocketSim grew from a personal side project into a business approaching $100K ARR, entirely without traditional marketing. It’s a masterclass in building for your own needs, listening to your users, and understanding that the most powerful thing a developer tool can sell is time.

The pitch that writes itself

When it comes to selling developer tools, the value proposition can sometimes get muddy. Are you selling a better UI? A new workflow? For Antoine, the pitch for RocketSim is much simpler, and it comes directly from his head of sales.

“He just tells me it’s so easy to sell RocketSim,” Antoine says. “And the reason is RocketSim is focused on reducing time spent, and it creates more time to work on actual features. There are so many solved problems in the world, but if you manage to solve the one limitation factor, which is time, and give more time to people, they will pay you.”

It’s a framing that cuts through the noise. When you pitch a “network monitor” or a “recording tool,” you’re asking developers to change their habits. When you pitch “five minutes saved every day,” multiplied across a team of engineers over a year, the ROI becomes undeniable. You aren’t selling a feature; you’re selling the ability for developers to get back to the work they actually enjoy.

The 2-year open GitHub issue

In an era of AI agents and instant answers, it’s easy to feel like every technical problem should be solvable in an afternoon. But Antoine’s journey with RocketSim proves that some problems just require you to grow into the solution.

For two years, he had an open GitHub issue for a feature that would allow developers to slow down the network specifically for the simulator, without affecting the rest of the Mac’s connection. “Every single answer you would basically find on Stack Overflow,” he recalls. “But I created that issue like, ‘Okay, I want to create a solution that works just for the simulator.’ And that issue has been open for two years. I just couldn’t find the answer.”

Instead of forcing a bad solution, he let it sit. He went to conferences, talked to other developers, and waited for new APIs. When he finally cracked it, the payoff was immense. “The moment that it worked was so amazing because I was literally thinking about it for two years,” he says. It’s a reminder that persistence is often just as important as raw technical skill.

How 40 trials became 120

When deciding what to build next, it’s easy to get distracted by shiny new APIs or personal pet features. Antoine took a different approach: he maintained a public roadmap and let his users vote.

The top-voted feature was a network monitor. When he finally released it, the impact was immediate and measurable. “I saw the active trials going from 40 a day to 120 a day,” he notes.

The lesson is straightforward but often ignored: building exactly what your users are asking for doesn’t just satisfy your current audience—it acts as a powerful re-engagement tool for developers who churned because the app lacked a specific capability. “That really just proves if you build what your users want, the real fields will follow,” he explains.

The focus trap of going full-time

The dream of going “full-time indie” is having five uninterrupted days a week to work on your app. But when Antoine finally made the leap—having already matched his salary and built RocketSim to nearly $100K in recurring revenue—he discovered a counterintuitive truth: more time doesn’t automatically mean more output.

“When I was full-time indie, I let loose of all the things that I learned as a side hustle,” he admits. “So I didn’t prioritize anymore. I didn’t plan anymore. I just started the day and I was like, ‘Okay, let’s see what I’m going to do today.’”

When you’re building a side project on nights and weekends, the extreme scarcity of time forces you to be ruthless about prioritization. When those constraints vanish, it’s easy to fall into the trap of doing everything at once and finishing nothing. To succeed as a full-time indie, Antoine had to consciously rebuild the strict habits and boundaries that made him effective when he only had a few hours a week to spare.

In the full episode, Antoine also discusses the irony of AI agents killing the blogs they were trained on, why he actively cross-promotes with competing newsletters, and the time he tried to become a world champion in darts.

Guest links:

The Android paywall conversion gap: why the problem isn’t your trial, it’s your funnel entrance

Wed, 25 Mar 2026 06:46:34 GMT

Android’s subscription conversion rate, compared to iOS, looks like a platform problem. When RevenueCat analyzed over 115,000 apps and $16 billion in revenue for the 2026 State of Subscription Apps report, the numbers were clear: on Android, the median download to paid conversion at day 35 sits at 0.9%, while iOS lands at 2.6%. That’s a nearly threefold gap. The instinct is to blame the trial, or the audience, or some fundamental difference in how Android users behave. The data says otherwise.

Looking one level deeper in the same dataset, trial to paid conversion on Android is 32.5%. On iOS, it’s 32.6%. Once a user starts a trial on either platform, they convert at statistically the same rate. There is an important caveat: Android’s trial-starter pool is likely more filtered. Because Android surfaces fewer trials overall, the users who do start one tend to be higher-intent. That selection effect partly explains why the rates equalize. Even so, the primary lever is clear: Android apps are sending far fewer users into that first stage. Closing the gap starts with getting more users to begin a trial in the first place.

In this article, you’ll explore the two-stage Android paywall funnel and where Android apps lose users, how Google Play’s offer and tag system controls which subscription option is surfaced to users, how RevenueCat’s SubscriptionOptions selection works and where silent misconfigurations occur, what the data shows about hard paywalls versus freemium models, and how to use RevenueCat Experiments to close the gap systematically.

The fundamental problem: Two stages, one broken

The download to paid journey has two distinct stages, and they behave differently.

The first stage is download to trial start: the user installs your app, reaches your paywall, and decides whether to begin a free trial. The second stage is trial start to paid: the trial ends, and the user decides whether to continue as a subscriber.

The RevenueCat data shows these two stages behave very differently on Android. A user who starts a trial converts at 32.5%, close to the 32.6% on iOS. But Android apps are sending far fewer users into that first stage. The bulk of the conversion gap lives in stage one.

One data point makes this concrete: 89.4% of all trial starts happen on the day of install. Users who download with high intent act immediately. Users who do not start a trial on install day rarely return to do so later. That makes the first paywall impression on Android the moment that determines most subscription revenue. Everything downstream from that moment, including your trial experience, your onboarding, your product, performs about as well on Android as on iOS. The question is whether users reach that moment at all.

Stage one: What determines whether users see a trial

Two things control whether a user is presented with a free trial on Android: what you show (the paywall type) and when you show it (the timing). Both are fully within your control.

The paywall type gap

The RevenueCat data breaks down paywall models by D35 download to paid conversion, RevenueCat’s measurement window for capturing conversion across trial lengths up to one month. Hard paywalls, where users must interact with a subscription offer before accessing core features, achieve a median D35 conversion of 10.7%. The top 10% of hard paywall apps reach 38.7%. Freemium models, where users get some access without paying, convert at a median of 2.1%.

That’s a fivefold difference in conversion with nearly identical annual retention. Hard paywalls retain 27% of subscribers at 12 months. Freemium retains 28%. For most app categories, the hard paywall numbers are substantially better. If your product delivers clear, immediate value in a single session, a hard paywall is almost certainly the right model. Categories where freemium remains appropriate are those with network effects or long value-discovery cycles, such as social apps and community tools, where acquiring a broad user base matters before monetization.

Paywall model	Median D35 conversion	Top 10% D35 conversion	12 month retention
Hard paywall	10.7%	38.7%	27%
Freemium	2.1%	—	28%

There is one case where freemium shows a late-conversion advantage: at week six, freemium apps convert 22.9% of that cohort compared to 15.3% for hard paywalls. If your product has a long discovery cycle where value builds gradually over weeks, freemium captures users that a hard paywall would lose.

The paywall timing gap

The 89.4% Day 0 trial start rate has a direct implication for timing: show your paywall in the first session. Every session after the first is a sharply diminishing return.

This doesn’t mean presenting the paywall before any onboarding. Apps that show a paywall before a user understands the product’s value typically see worse opt-in rates. The pattern that works is: deliver one compelling value moment first (a single completed task, a key feature reveal, a concrete output), then present the paywall. On Day 0.

The hidden failure: When offer misconfiguration silently suppresses trials

Even if your paywall type and timing are right, there’s a second source of trial failures on Android that is harder to spot: the subscription offer itself may not be visible. This is a Google Play configuration issue, and it can happen without any error.

How Google Play structures subscription offers

Every subscription on Google Play consists of a base plan and, optionally, one or more offers. An offer defines a promotional pricing phase (a free trial, an introductory price, or both) that precedes the base plan price. Offers are represented in the Billing Library as ProductDetails.SubscriptionOfferDetails.

Each SubscriptionOfferDetails object has a list of pricing phases, a set of offer tags, and an offer token used to initiate the purchase. The pricing phases tell you the price and duration of each stage. The offer tags are strings you define in the Play Console at either the base plan level or the offer level. The Billing Library returns the union of both sets in getOfferTags(), so a tag set on the base plan automatically appears on all offers under it.

When RevenueCat fetches your products, each SubscriptionOfferDetails is converted to a GoogleSubscriptionOption. Looking at the conversion in subscriptionOptionConversions.kt:

The offerId is null for base plans and set for offer-based options. The offerToken is what gets passed to the billing flow when the user taps “Start free trial.” The offerTags carry the labels you assigned in the Play Console.

How RevenueCat selects the default offer

Once your product has a list of GoogleSubscriptionOption objects, RevenueCat groups them in a SubscriptionOptions collection and exposes a defaultOffer property. This is the option your paywall shows unless you explicitly select a different one.

The selection algorithm in SubscriptionOptions.kt works as follows:

The algorithm filters out any offer tagged rc-ignore-offer or rc-customer-center, then selects the offer with the longest free trial. If there is no free trial, it selects the offer with the lowest introductory price. If no offers pass those checks, it falls back to the base plan with no promotional phase at all.

That fallback is the silent failure. If your trial offer is tagged rc-ignore-offer, if it is not attached to the right base plan, or if it simply has no offer tags at all and your app relies on tag-based filtering, defaultOffer returns the base plan. Your paywall renders. Everything looks fine. No error appears. But the trial is gone.

Detecting what your paywall is actually showing

Before optimizing anything else, verify that defaultOffer on your product resolves to an offer with a free trial. The SubscriptionOption interface exposes a freePhase property for exactly this check:

A non-null freePhase means the option includes a free trial phase. introPhase similarly checks for introductory paid phases. If your defaultOffer has a null freePhase and a null introPhase, no promotional phase will be shown. You can also check defaultOffer?.isBasePlan directly: a true value means the SDK found no eligible offer and fell back to the base plan. Either way, inspect your offer configuration in the Play Console.

You can check this in code after fetching offerings:

Run this during development and confirm the output matches your Play Console offer configuration. If hasFreeTrialOption is false and you expected a trial, the offer is not being selected. Check offer tags, verify the offer is in the correct base plan, and confirm the offer is active in the Play Console.

One structural difference to be aware of

Before moving to tracking and experimentation, it is worth naming one platform-level difference that the Android-iOS comparison does not fully capture.

On iOS, Apple sends a system-level push notification before a trial ends, reminding the user it will convert to paid. Google Play does not send an equivalent system notification. This means iOS gets a built-in re-engagement nudge at the critical trial to paid moment, and Android does not. On Android, that reminder is entirely your responsibility: an in-app banner, a push notification from your own backend, or a re-engagement flow triggered when the user returns near the end of their trial.

This structural difference partially explains why the trial to paid rates look similar despite the very different trial-starter pool sizes: iOS has a platform assist at the conversion moment. On Android, the same result requires explicit implementation. If your Android trial to paid rate is below your iOS rate, the absence of a trial-end reminder in your app is a likely contributor.

Tracking paywall performance with PresentedOfferingContext

Once your offer configuration is correct, the next step is understanding which paywall placement drives the most trial starts. RevenueCat’s PresentedOfferingContext lets you attach a placement identifier to every purchase, so your analytics can segment by where in the app the paywall appeared.

PresentedOfferingContext carries three fields:

The offeringIdentifier is the offering from your RevenueCat dashboard. The placementIdentifier is a string you define to label the surface: "onboarding_paywall", "settings_upgrade", "feature_gate", and so on. The targetingContext carries rule data when you are using RevenueCat’s targeting feature.

When you initiate a purchase, this context travels with the transaction and appears in your RevenueCat dashboard and webhook events. You can then compare trial start rates and D35 conversion across placements and determine which surface is worth optimizing first.

Trial length: The overlooked variable

Beyond offer visibility and paywall type, trial duration has a measurable impact on trial to paid conversion. The RevenueCat data shows a clear pattern:

Trial length	Trial-to-paid conversion
4 days or fewer	25.5%
17 to 32 days	42.5%

Apps offering longer trials show roughly 17 percentage points higher trial to paid conversion in the dataset. This is a correlation: apps that offer longer trials tend to be more deliberate productivity and creative tools where longer trials reflect a conscious product strategy, not just an arbitrary setting. Extending your trial duration does not guarantee a 17-point improvement. Yet the pattern suggests that for apps where value compounds over time, a 4-day trial may end before a user has had a meaningful product experience, while a 14 or 30-day trial gives the product enough time to demonstrate its value.

Yet 55% of all trials in the dataset are now 4 days or shorter, up from 42% the previous year. Only 5% of apps offer 17 or more days.

If your trial to paid rate is below the 32.5% Android median, trial length is worth testing. It is one of the higher-leverage variables to run through RevenueCat Experiments without needing to ship new code.

Measuring and iterating with RevenueCat Experiments

All of the variables discussed so far (paywall type, timing, trial length, offer selection) interact in ways that are hard to reason about without measurement. What works depends on your specific product, your audience, and your category.

RevenueCat Experiments lets you run A/B tests against these variables without shipping code changes or building backend infrastructure. You create a variant offering in the RevenueCat dashboard with a different configuration: a different trial length, a different default offer, or a different package lineup. RevenueCat randomly assigns users to control or variant, tracks their behavior through the full trial and conversion cycle, and surfaces D35 conversion, LTV, and trial start rate broken down by variant.

Once your experiment is running, you can monitor trial state per user via EntitlementInfo.periodType in CustomerInfo:

The periodType tells you the current phase of the user’s subscription. This is useful for building trial-aware UI: showing a banner when a trial is about to expire, adjusting messaging based on subscription phase, or triggering a re-engagement paywall for users whose trial ended without converting.

Putting it together

The Android conversion gap is primarily a funnel-entrance problem with identifiable causes. The threefold difference in D35 download to paid between Android and iOS does not reflect a platform ceiling. It reflects the aggregate effect of offer misconfiguration, freemium models that suppress trial uptake, and paywalls shown too late or not at all. A structural platform difference also contributes: Android does not send system-level trial expiration reminders the way iOS does, so re-engaging users near trial end requires explicit implementation on your side.

The path to closing the gap follows a specific sequence. First, confirm that defaultOffer on your active offering resolves to an option with a non-null freePhase. If it doesn’t, fix the Play Console offer configuration before changing anything else. Second, if you are running freemium, run an experiment against a hard paywall variant and measure both trial start rate and 12-month retention. Third, if you are already running a hard paywall, test a longer trial duration. Fourth, add placementIdentifier to your PresentedOfferingContext so you can attribute trial starts to specific surfaces.

Each of these changes is measurable. RevenueCat Experiments gives you the infrastructure to test without guessing, and the D35 and trial to paid metrics give you the signal to act on.

In this article, you’ve explored how the Android paywall conversion problem lives primarily in stage one of a two-stage funnel, how Google Play’s offer and tag system determines which subscription option is surfaced, how RevenueCat’s SubscriptionOptions.defaultOffer algorithm selects a trial and where silent misconfigurations occur, what the data shows about paywall model choice and trial length, the structural platform difference around trial reminders, and how to diagnose and iterate using RevenueCat’s tooling.

Understanding where the gap lives changes what you build. Most of the work is in stage one: getting users to see and start a trial. The Android user who starts a trial converts at nearly the same rate as the iOS user. The work is making sure they get the chance to start, and giving them a reason to convert before that trial ends.

Why free trials don’t make sense anymore (and what user acquisition tactic to try instead)

Mon, 23 Mar 2026 17:54:54 GMT

Since subscription apps first started to gain in popularity, free trials have been a foundation for most user acquisition (UA) marketers, serving as the main proxy event to attract real long-term subscribers. But this tactic, like so many other elements of our industry, has been changed by AI and vibe-coding. It’s now harder than ever to run campaigns optimizing towards a free trial, largely due to the enormous competition and overall declining trial conversion rates.

As the State of Subscription Apps 2026 shows, there’s a growing trend of trials shortening to three days — despite data encouraging the opposite; showing that trials with 17+ days convert 70% better (42.5% paid conversion rate vs. 25.5%).

State of Subscription Apps 2026 — trial-to-paid, by trial duration

Even with this huge discrepancy, nearly half of all apps now use trials of four days or less, seeking immediate revenue and shorter payback periods that make publishers’ margins more affordable from the UA perspective.

This is not a coincidence. AI has drastically changed the whole market: by adding variable and rising costs to the use of its technology, AI has forced publishers and developers to look for higher average revenue per user (ARPU) in the shortest time possible, in order to can’t cover these costs and sustain the business. Otherwise, the apps become unmarketable themselves, making the product-market fit (PMF) process harder than ever.

If you also consider the popularity of how web-to-app campaigns can help you to nail signal engineering, we can easily draw the conclusion that free trials don’t make much sense anymore. But is that a fair blanket statement? I think it’s true, but that doesn’t mean free trials are over. We can still play with a more advanced version of this conversion event.

Before exploring what that looks like, let’s dive into the reasons why free trials became so popular on subscription apps.

Free trials: the purchase proxy event

The title speaks for itself: The free trial event has been the foundation of endless companies’ UA strategies for a simple reason — a free trial is the closest event to purchase. What’s more, the event can filter purchase intention, without sacrificing the volume that ad networks need to optimize performance efficiently.

When AI didn’t exist and the offer of apps was more limited, free trials were widely used as a technique to convince the user to convert, with publishers heavily relying on their products and UX to make the conversion effective. But that doesn’t apply anymore. Today, hard paywalls with direct subscriptions are becoming more present, with data showing they generate close to double the upfront revenue vs. freemium apps.

State of Subscription Apps 2026 — day 35 download-to-paid, freemium vs. hard paywall

This growing shift away from free trials is clearly visible when you compare 2026’s report vs. 2024. We can see how all categories have seen a 14% increase in the non-trial strategies (28% in 2024 in non-trial strategies vs. 32% in 2026) where free trials are non-existent.

State of Subscription Apps 2024 — trial strategy

State of Subscription Apps 2026 — trial strategy, by category

With such a fast evolution, publishers need to adapt to the new reality since ChatGPT normalised paying $20/month for an AI chatbot. And the shortest path for that is playing with pricing, which explains this change in the overall trial strategy.

Web campaigns: a lever pushing free trial extinction

At this point, it’s no longer a new topic: web and web-to-app funnels are now the norm for the biggest publishers due to multiple reasons:

The 30% fee you save due to Apple or Google’s commissions
Higher flexibility and speed to run multiple A/B tests with the onboarding and pricing
Higher accuracy on campaign attribution without relying on SKAN and its limitations
Higher purchase intention in users
More and new inventories where you have more control to filter purchase intention
Retargeting is real for iOS users

Although it’s true that, at the moment, web onboarding doesn’t make too much sense for small publishers that are under the 15% commission — due to the additional complexities you have to handle (tax compliance, 3% fee to Stripe or similar, managing refunds internally, platforms to build onboarding, etc.) — the change in strategy of the biggest players has directly affected the trends in the market. Now, even small devs are pushing to copy these strategies.

With this current outlook, the question is no longer whether to move away from the classic free trial, it’s about what you replace it with, and when. The market has split:

Hard paywalls with direct subscriptions: for apps with strong PMF and vitality
A more sophisticated version of the free trial mechanic, that preserves the volume ad networks need while dramatically improving signal quality

The second option is what I like to work with — and in my opinion, it will be the future standard when it comes to signal engineering.

At App Growth Annual 2025, I did a workshop where I explained the immediate effect that paid trials (introductory offers) have in your activation metrics and UA performance. Today, I see more and more companies applying this strategy on their web campaigns, as these normally target users with real purchase intention easier than app campaigns.

Trial qualifier or paid trial events aren’t mutually-exclusive

As shown in my article on intro offers, introducing paid trials in your app or web campaigns can drastically change your numbers. But you have to pay close attention to monitoring the conversion rate after the paid trial — this strategy effectively harms your short-term lifetime value (LTV), compared to a hard paywall with a direct subscription.

The State of Subscription Apps report shows that ~30% of new subscribers now enter through intro offers (median).

State of Subscription Apps 2026 — share of new payers acquired via an intro offer, by category and revenue tier

The $0.99 first month model doesn’t just improve conversion — it fundamentally changes what signal you’re feeding the algorithm. You’re no longer training the network on “users who clicked a free button”. You’re training it on users who handed over a credit card, which is a completely different behavioral profile. That’s a gamechanger if you’re able to target those users efficiently with a correct creative strategy in your paid campaigns.

This started to become more popular on web and web-to-app campaigns since you could use specific channels to filter purchase intent in the upper funnel part of the metric, just by launching channels with inventories with high control capabilities — unlike the automated app campaigns which are now the norm in all ad networks that offer app campaigns promotion.

For example, when launching Google Ads with a search campaign, you have the possibility of creating specific ad groups for each audience segment. Within these, you can target different purchase intent levels by just playing with the keywords. A good strategy would be using keywords with and without “free” in the term, to see what’s the performance towards that trial qualifier event.

Using this type of advanced targeting with a paid trial has become a really successful tool for many publishers that wanted to boost the algorithm with real paying signals on day 0, instead of proxy events whose median averages 30–35% vs. the real subscription (source: SOSA).

But for me, this isn’t going to be the norm in the near future. Trial qualifiers will take this role. And the most positive news is that you don’t have to do one or the other, you can keep paid trials for your web campaigns where you have more control over the intention of the users, while utilizing trial qualifiers for app campaigns.

Looking again at the State of Subscription Apps 2026, we see that nearly all trial starts happen on day 0 across categories. Users who don’t try immediately during the onboarding rarely try at all.

State of Subscription Apps 2026 — time to trial, by category

With this data, the main takeaway is clear: trial qualifier events are the best tool for advertisers right now. Here’s why:

You still feed the algorithm with signals on day 0, but without forcing the user to use a credit card
You still optimize towards an event that happens immediately before the purchase, but with a deeper intent than the classic trial
And most importantly (in my opinion) you have full control to play with the signals that you send for this trial qualifier event, because you have access to the purchase behaviour of your users

So how do you get started implementing this in your campaigns?

The new free trial: how to set up an advanced free trial

Personalisation of the trial qualifier event will heavily depend on the app category, subscription tiers offered in the paywall, and the historical behaviour and data you can analyze from the classic trial start event. But as an initial setup, you can create the trial qualifier event based on the following conditions:

1. Time without cancelling the free trial

Most trial cancellations happened within the first two hours after starting the trial. The data shows cancellation is at its highest on day 0, closely followed by day 1.

State of Subscription Apps — % of trial cancellations, by day and trial duration

These cancellations are users who just want to see what’s behind the paywall but they will never purchase. However, they will contaminate the signals you send to ad networks when working with the trial, making your overall performance worse — so these are the first users that need to be filtered out. In this case, you should analyze the historical data to see which time filter accommodates better to your app.

2. Time without cancelling the free trial + engagement

Some products have drastic differences in LTV, retention, and payback periods between users; specifically those who stick to the product and use it actively, versus those who just subscribe and forget about the app. So a smart way of nailing the trial qualifier is to add engagement signals [that happened in the first session] to the time without cancelling metric. This creates a more robust and reliable signal that you can send to the ad network to optimize your campaigns.

One word of warning is to avoid being very picky with the engagement points during this first session, otherwise you will sacrifice too much signal volume and your campaigns will struggle to optimize.

3. Time without cancelling the free trial + sending an additional signal the day after the trial started

This is similar to the first point, but with a deeper complexity, as you send two signals per user instead of just one. This strategy is based on sending the initial signal two hours after trial starts, and then another extra signal the day before the trial ends. For example, if you have a 3-day trial, you would send one initial signal two hours after the trial starts, and another signal if the user keeps the trial active on day 2. This helps with the volume of events, making the optimization of campaigns easier for ad networks. At the same time, it adds difficulty to calculate the real trial conversion rate and incrementality.

4. Automate trial qualifier mapping

If you want to go one step further, you can now use the new RevenueCat integration with Appstack, and automate mapping your trial qualifier events in just a couple of clicks. With this integration you’re able to send campaign users to specific paywalls made with RevenueCat, allowing you to fully customize the user experience, from when they watch an ad all the way to completing onboarding in your app. I think this is a unique feature in the market which will dramatically change the way paywalls are made and tested, since you can now feed these tests to users with deep purchase intent.

Ultimately, I suggest you take these initial ideas and start playing with the trial qualifier event, then compare the performance of these campaigns against your classic free trial campaigns. Once you find a winning path, you can start an ongoing process of filtering your signals until you reach the perfect balance between signal quality and quantity for the ad network.

Ready to revamp your free trial?

I know this article may sound somewhat dramatic, and of course there will be cases where you still get a better performance with classic free trials. However, according to what I see everyday working with different apps, we’re rapidly moving to the immediate pursuit of results (thanks to the increasing marginal costs attached to AI). So I believe in the near future we’ll have most apps refining their free trial signals in this way, allowing them to be more accurate with ad delivery — and overall maximizing the efficiency of every dollar invested in their UA.

The State of Subscription Apps in 10 minutes: lessons, trends, and benchmarks for 2026

Thu, 19 Mar 2026 16:16:53 GMT

Each year, our State of Subscription Apps report sets out to understand what’s changing in the industry; what’s new, what’s over, and what’s on its way. This year, our dataset grew again: over 115,000 apps, representing more than $16 billion in revenue. And we analyzed the data from all 115k+ of them.

If you thought last year’s report was a behemoth, look away now. This year, we’ve delivered 338 pages, ready to give you every metric, benchmark, or trend you could possibly need.

To summarize David Barnard’s own words, “There’s a lot of apps making a lot of money.”

But, if you (shockingly) don’t have time to read every single page (like David and Jacob did), then this rundown’s for you. Strap in.

1. Subscription app growth is no longer a spectrum

2026 shows a huge polarization in app growth. Where maintaining steady growth (e.g. 5–15% YoY) was previously considered safe and healthy for an app business, today’s data shows this middle ground evaporating beneath our feet.

Market dynamics — user acquisition costs, algorithm changes, platform fees, AI unit economics — now heavily reward the top performers, creating a mobile app economy that mirrors broader wealth inequality: the rich get richer, and indie developers struggle to stay afloat.

The data:

Top quartile: the top 25% of subscription apps grew their monthly recurring revenue (MRR) by 80% or more year-on-year
Bottom quartile: the bottom 25% of apps saw their MRR shrink by more than 33%
The divide: this creates a massive 113-point gap between the winners scaling aggressively and the apps bleeding revenue
Comparison to 2025: last year’s data saw the revenue gap increase between the top 5% and bottom 25% (with the top earning 400x more, up from 200x in 2024) – a trend the 2026 data confirms and quantifies for the first time in growth rate

Median year-on-year monthly recurring revenue growth rate, by developer HQ — State of Subscription Apps 2026

What next?

App teams can no longer rest on ‘good enough’. There is no safety blanket. If you’re growing at the median rate (5–17%), you’re at risk of falling into the bottom quartile and slipping through the cracks. Teams need to shift from maintenance mode to aggressive growth optimization.

→ Your next step: learn about the Subscription Value Loop, a framework for app growth

2. Hard paywalls convert 5x better than freemium

We’ve all heard the rhetoric that “hard paywalls kill user experience”. Well, consider that mythbusted. Across categories, Day 35 trial-to-paid conversion is 5x better when apps feature a hard paywall. Contrary to popular belief, hard paywalls are not scaring users away or ‘forcing’ them into buying before ready — this narrative only belittles users, who are subscription-savvy and will only convert when they want to. Today, users are engaging with hard paywalls, and it’s giving apps faster payback.

This choice [hard paywall vs. freemium] changes your unit economics completely. Same ad spend. Dramatically different revenue on day one. — Sven Jürgens, Mobile Growth Consultant

While paywall type impacts conversion, long-term retention equalizes across both access methods. Freemium apps continue to convert well into Week 6 and beyond, meaning the full conversion picture is a longer game than you may think.

So freemium doesn’t mean less success — and there are many successful freemium apps that prove this — but the data definitively proves that hard paywalls convert better, and convert quicker. In 2026, freemium may feel like the safer option, but it’s not necessarily the best choice.

The data:

Conversion: hard paywalls have a median Day-35 trial-to-paid conversion rate of 10.7%, compared to just 2.1% for freemium apps — this is roughly a 5x advantage
Retention: freemium apps retain 28% of yearly subscribers after 1 year, while hard paywall apps retain 27%, making the difference statistically negligible
Revenue per install: hard paywall apps generate 8x higher RPI at day 60, compared to freemium ($3.09 vs. $0.38)
Comparison to 2025: while freemium D35 conversion has remained at 2.1% since 2025, hard paywall conversion has gone down ~2% (12.1% in 2025), suggesting a broader reluctance to convert

Day 35 download-to-paid, freemium vs. hard paywall — State of Subscription Apps 2026

What next?

Switch to a hard paywall (if you dare 😈). Hard paywalls offer an upfront ROI, giving you a chunk of cash to reinvest in growth. If you’re relying on a freemium model to build goodwill, you’re sacrificing massive top-of-funnel revenue for a just 1% retention bump a year later. Given the aggressive market, it’s a risky move to take.

→ Your next step: discover what the best subscription apps get right about paywalls

3. The Day 0 buyer’s remorse window

Plot twist: your 3-day trial is actually a 1-hour trial. Yep. 55% of all trial cancellations happen on Day 0. So while developers are designing a three-day experience, the modern consumer’s attention span is demanding instant proof of value.

Teams can no longer assume users spend days exploring all app features before making a decision; the reality is that users treat app trials like impulsive retail purchases. They subscribe to get past the paywall, immediately experience and assess the core features, then cancel to prevent being charged. If you don’t deliver an aha! moment in the first 60 minutes, the subscriber is already gone.

The data:

Day 0 cancellations: exactly 55.4% of all 3-day trial cancellations occur on Day 0
The drop-off: an overwhelming 84% of 3-day trial cancellations happen between Day 0 and Day 1
Comparison to 2025: last year, ~51% of 3-day trial cancellations happened on Day 0 (showing a ~4% increase this year), suggesting users quickfire cancel instinct is only increasing

% of trial cancellations, by day and trial duration — State of Subscription Apps 2026

What next?

Treat your onboarding flow as your primary retention mechanism. If a user doesn’t hit the aha! moment in their very first session, they’re going to quickly toggle off auto-renew. Revisit your trial length — does it need to be three days? (More on this next.)) Consider the features you give access to in a trial — what shows value instantly, and what takes up space? Figure out the most direct route to proving value, then build it.

→ Your next step: stop chasing growth hacks — learn how how to fix your onboarding first

4. The 7 day trial is alive and kicking (sometimes)

The subscription app industry is obsessed with short trials, but what do the numbers actually show? Is the 7-day trial really dead?

In short, no.

Trials of 17-32 days convert 70% better than 3-day trials (42.5% vs 25.5%). Yet, 46% of apps are moving to trials of 4 days or less. Why? Growth teams are under market and economic pressure to show fast revenue.

Most developers do 3-day free trials for cashflow. You want the money in three days, not 30 days. [Or you’re looking to] get conversion data faster, to compound onboarding and paywall experiments. — David Barnard and Jacob Eiting speak about on Sub Club

Short trials force a fast decision from users, often resulting in high abandonment (see the Day 0 cancellation rate of 3-day trial vs. longer), while longer trials give users time to integrate an app into their daily habits, and reduces nerves about accidental auto-renewal. 3-day trials are useful for app teams, but the reality is you’re sacrificing long-term conversion for a short-term dopamine dashboard spike.

The data:

Long-trial conversion: trials of 17–32 days convert at an incredibly high median of 42.5%
Short trial conversion: trials of <4 days convert at just 25.5%, meaning long trials convert ~70% better
Comparison to 2025: last year, trials were increasing in length, but today, despite the data, trials of <4 days rose from 42.1% in 2025 to 46.5% in 2026

Trial-to-paid, by trial duration — State of Subscription Apps 2026

What next?

Deep dive into your category’s trial and retention data. Watch the crowd, but don’t feel locked in to follow them. Try experimenting with longer trial length and see how your conversion and retention changes. Show value upfront, then give users adequate time to experience it.

→ Your next step: determine the optimum trial length for your app

5. Annual subscriptions aren’t the guarantee you think they are

When users buy an annual subscription, it feels like a sigh of relief for the developer. You relax, assuming that annual sub means 12 months to prove the app’s value. 12 months to demonstrate each carefully-designed feature, and deliver a clear message of “I should keep using this app” come Year 2.

But the data reveals a harsh truth: over one third of users cancel auto-renewal within the first month. Users aren’t stupid, and they don’t think of an annual subscription as a rolling purchase — they consider it a one-off payment for this year, then immediately protect their wallet. Meaning that Year 2 revenue you’d already relied on? It’s gone before Year 1 has even really begun.

The data:

Month 1 churn: the first month accounts for 35% of all annual cancellations
The cancellation curve: after the Month 1 spike, cancellations drop to just 3–10% for the middle of the year, before spiking again in Month 12 (pre-renewal)
Comparison to 2025: ~56% of annual subscribers cancelled in Year 1 in 2025, while this worsened to ~72% in 2026; however the Month 1 cancellation spike remains fairly comparable between years

Cancellation timeline for annual subscriptions — State of Subscription Apps 2026

What next?

App teams can no longer rely on users ‘forgetting’ about an annual subscription. The battle for Year 2 starts in Week 1. You don’t have 11 months to win an annual renewal, you need to preemptively convince users to not cancel auto-renew. This means intensive value reinforcement from the moment they download, and win-back campaigns throughout the first two months to persuade users to toggle auto-renew back on, while they’re first engaged.

→ Your next step: explore the pros and cons of annual subscriptions, then learn how to improve your annual subscription uptake

6. The Google Play tax

For Android devs, growth is actually an engineering problem. 31% of Google Play cancellations are involuntary billing failures — over double the rate of the App Store (14%).

When an app loses a subscriber, blame usually falls to the product features or pricing. However, for Android apps, nearly a third of churn isn’t because the user hated the app, it’s simply because their credit card failed, expired, or was declined, and the app’s billing infrastructure wasn’t robust enough to recover it.

This money is unclaimed revenue: growth isn’t just about ads; it’s about plugging the technical leaks in Google Play’s ecosystem through better retry logic and grace periods.

The data:

Google Play billing failures: a massive 31% of all subscription cancellations on Google Play are due to billing errors
App Store comparison: on the App Store, billing errors account for only 14% of cancellations
Comparison to 2025: Google Play’s billing errors have worsened, from 28.2% in 2025 to 31% this year; meanwhile the App Store’s improved, reducing billing errors by 1.1% (15.1% in 2025 vs. 14% in 2026)

Cancellation reasons, by app store — State of Subscription Apps 2026

What next?

If you have a significant Android user base, your highest ROI activity is optimizing your dunning process (billing retries) and enabling grace periods. Handled appropriately, Android apps can almost instantly recover 15-20% of lost revenue, without acquiring a single new user.

→ Your next step: learn how to counteract the Google Play billing leak, and set up winback campaigns for lapsed subscribers

7. The AI paradox: acquisition beast, retention nightmare

AI sells like crazy, but it doesn’t stick. While AI-powered apps generate 41% more revenue-per-user, those same apps churn 36% faster than non-AI apps. The problem isn’t convincing users to download your AI app (clearly, users want to pay for AI), the challenge is keeping them invested.

Amidst the vibe coding hype and established developers watching as new apps dilute market real estate, the data proves AI apps aren’t in it for the long haul (yet). AI features are driving massive trial revenue, yet many AI apps suffer from an alarming lack of product-market fit. Users may be willing to pay a premium to try AI tools, but once they download, they’re not finding the long-term utility to justify its hefty pricetag.

Yes, vibe coded apps can ship fast. Yes, AI features act as a massive top-of-funnel magnet, but this doesn’t guarantee the same audience further down the line. It doesn’t mean they can sustain a user base. Experienced developers still have an edge: stamina. They know how to maintain an app, build trust with an audience, and grow revenue. That is the real differentiator between what apps succeed and which fall behind — not who can build an app fastest, what AI features it has, or whether a human or agent wrote the lines of code.

The data:

The AI premium: AI apps sustain a 41% Year 1 realized LTV premium compared to non-AI apps ($30.16 median vs. $21.37 median)
The churn problem: Despite the high revenue, AI monthly plans retain 36% worse over 12 months than traditional apps
Comparison to 2025: AI apps showed 12-month payer retention of 9.2% (App Store) and 11.5% (Google Play), comparable to traditional apps in respective categories; suggesting 2026’s sharp dip in retention is a problem emerging after AI apps settled into mainstream and users had longer to assess them

Retained subscribers after 12 months, by AI vs. non-AI — State of Subscription Apps 2026

What next?

Shipping fast or relying on AI hype isn’t enough. If you add AI to your app, use the influx of cash to build a genuine user experience and robust backend. Don’t rely on novelty or one-off AI gimmicks. These will only churn in a few months. Look to established apps for retention and growth lessons, then use AI to make them happen fast. The long game will be won not by AI vs. non-AI, but by whoever can utilize AI and human expertise.

→ Your next step: revisit core value offered to users and secure product-market fit

Looking to 2027

The data from 2026’s State of Subscription Apps report highlights emerging shifts in the app industry, from the influx of new apps (14,000+ a month!) to the rapid dissolving of the average app’s revenue safety net. But many of these trends are not surprising — Google’s billing leak has been a prominent issue for several years, and the relationship between trial length and conversion isn’t new either. What is clear from 2026’s data is that apps can no longer afford to ignore these accumulating changes and known issues.

‘Good enough’ is no longer good enough. Just as quickly as top apps are growing their revenue, the lower quartile are churning it. Subscription apps that are designed with user value as the core and marketed with intention have found their place in the ecosystem. Their success compounds over time, and the rest of the app store is left fighting over scraps. All that’s left is for teams to decide which side of the line they wish to sit on come 2027’s report.

The 7-day trial, and other free trial myths: how to choose the right trial length for your subscription app

Thu, 19 Mar 2026 14:28:56 GMT

I once got a 34-day free trial. Not 30 days, not ‘one month’, but thirty-four days.

It was for YNAB, a personal budgeting app. At first, it felt completely random. Most free trials hover between five and nine days, so why 34?

But when I opened the app, it all made sense.

Budgeting doesn’t deliver instant value; you need a full cycle:

A payday
Bills going out
Real behavior over time

YNAB wasn’t trying to impress me in a week. They were giving me enough time to actually experience the product.

That moment really stuck with me. It made me wonder: are we, as an industry, selling ourselves short by defaulting to seven-day trials?

In 2024, just over half of all trials fell within the 5–9 day range, up from 2023. In 2025, trials are getting even shorter. Trials of four days or less gained share, rising to almost half (46.5%) of all trials.

Trial duration, year-on-year — State of Subscription Apps 2026

While we’ve all heard “the 7-day trial is dead” generalization thrown around, that seems to be because trials are only getting shorter. So, despite all the nuance we’re about to explore, the industry default is becoming more entrenched, not less.

And that’s the problem. A seven-day trial isn’t inherently bad; it’s just rarely questioned. Trial length deserves the same level of thought as onboarding, activation, and retention.

Because at the end of the day, trial length isn’t a pricing decision. It’s a product decision.

Hannah Parvaz, Founder of Aperture, puts it:

“I’m very much in the ‘trial length is a design decision, not a default’ camp. Across multiple subscription apps, the biggest mistake I see is treating trial length as a growth lever in isolation, rather than anchoring it to time-to-value and confidence-building.”

That idea — that trial length is a product decision — sent me down a classic Daphne rabbit hole: what actually determines the right free-trial length?

Before trial length: should you even offer a trial?

Before we dive into different trial lengths, there’s a more important question to answer first:

Do you even need a trial?

Optimising trial length is meaningless if the trial itself is the wrong strategy.

I used to think trials were a must. After all, most apps across categories offer some form of trial, according to the State of Subscription Apps 2026:

Trial strategy, by category — State of Subscription Apps 2026

Not a single category has a majority of apps without some form of trial. The closest is from Social, who have the highest no-trial strategy at 43.6%.

I read an article by David Vargas that completely changed how I think about trials — he frames it this way:

“We have to remember that a free trial is just one strategy. It relies on how ‘sticky’ the product and features are to convince users to subscribe.”

What really caught my attention was an experiment where David removed the free trial entirely.

It felt bold (my favorite type of experiment) and slightly terrifying. But the context mattered. They were seeing strong trial-to-paid conversion, yet paid acquisition wasn’t working; the cost per acquisition was too high once they factored in how many trial starts were needed to land a single paying customer.

Removing the trial nearly doubled lifetime value and unlocked paid growth.

That’s an important consideration, even if you keep a trial. Unless your trial is very short, you’ll usually end up optimising paid channels for trial starts rather than purchases. And if conversions occur outside the attribution window, ad platforms optimize for people who like starting trials, not for those who actually pay.

So the first principle is this:

Don’t touch trial length until you’re clear on whether a trial should exist at all.

Testing removal sounds scary, but if your trial isn’t pulling its weight, it’s worth questioning the assumption or focusing first on adding real value with your trial. As Dan Layfield, Founder of Subscription Index (ex-Codeacademy and Uber), puts it:

“Trials are your friend so long as they are visible, clear, and appealing to your users.”

Once you’re convinced your trial should exist, then it’s time to debunk some trial myths.

The myth: shorter trials convert better

Our instinct is simple: shorter trials create urgency, urgency drives action, and action drives conversion. Simple, right?

It’s the same line of thinking as running a 24-hour sale or telling users an item is almost sold out. It’s a massive kick up the rump.

And sure, there are situations where short trials help, especially if you want to quickly optimize paid campaigns for purchases. But the data shows it’s more nuanced.

According to RevenueCat’s State of Subscription Apps report, shorter trials come with huge day 0-1 cancellation spikes. For three-day trials, over 55% of users cancel almost immediately. Compare that to around 31% for 30-day trials.

% of trial cancellations, by day and trial duration — State of Subscription Apps 2026

That early cancellation doesn’t automatically mean poor intent. Often it’s driven by:

Lack of trust
Fear of forgetting to cancel
And the classic: “I’ll cancel now just in case”

What’s interesting is that the longer the trial, the less cancellations. 84% of 3-day trial cancellations and 64% of 7-day trial cancellations happen between day 0–1. The risk isn’t late, it’s right at the start.

So no, shorter isn’t automatically better. But now I’ll get annoying: longer isn’t automatically smarter either.

Longer trials: when they help, and when they hurt

When people hear this, they often jump straight to: “Longer must be better.”

But blindly following aggregate data is just as dangerous as defaulting to a seven-day trial.

Yes, 17–32 day trials do show higher trial-to-paid conversion on average (a 42.5% median conversion vs. <4 day trials’ 25.5% conversion rate):

Trial-to-paid, by trial duration — State of Subscription Apps 2026

That sounds great, but we often assume trial-to-paid conversion automatically equals a better outcome, and that’s where things get tricky.

For example, I worked with a wellness app where our key activation metric was consuming two long-form content pieces within 14 days. Each piece lasted about 45 minutes and was tied to (but not exclusively) a weekly live session. That behaviour was a strong predictor of long-term retention.

So we asked the obvious question: why run a seven-day trial when our activation window is 14 days?

Time for an experiment: we A/B tested a 7-day vs 14-day trial. While the longer trial drove slightly more trial starts, fewer people converted overall.

Not because people were abusing it or needed more time, but because activation didn’t improve. People weren’t consuming more content; they were delaying. Classic procrastination. It performed worse in converting to paid, and we reverted to the 7-day trial.

That’s the dark side of long trials we’ve all experienced. A long gym trial feels painless to postpone, but a short, paid intro lesson you need to book within seven days forces action. “I’ll use it later” quietly becomes “I never really did.”

The takeaway: trial conversion is just a leading metric. What actually matters is:

Revenue per user over time
Retention
Sustained engagement

There’s even a great SaaS study by Hema Yoganarasimhan, Ebrahim Barzegary, and Abhishek Pani showing that shorter trials (seven days) can outperform 30-day trials on acquisition, retention, and profitability.

That being said, a user who converts on day seven and churns on day eight is not a win.

So if you’re feeling a little confused right now, that’s fair, I’ve just dismantled both extremes (sorry!). But fear not, there is an answer: trial length only makes sense in context.

Across teams, Hannah Parvaz has seen a few consistent patterns emerge:

“If the core value is experienced in one session, long trials often hurt paid conversion. In these cases, shorter trials (or even no trial at all, with strong reassurance) outperform because users either get it quickly or they never will.
“If value compounds over time (habits, learning, behaviour change), a longer trial can work, but only if the onboarding actively guides users to the aha! rather than passively waiting for it to happen.
Seven days is rarely optimal by default. It’s often too long for fast-value products and too short for slower, trust-based ones. We’ve seen better outcomes with everything from three days to 30 days, depending on how quickly users hit a meaningful milestone.”

Let’s dive deeper into that context to better understand the nuances, then we’ll outline a framework to determine the right trial length for your app.

Pricing matters for trial length

One thing that’s easy to forget when discussing trial length is how closely it’s linked to pricing and packaging.

A 14-day trial before a $5 monthly plan behaves very differently from a 14-day trial before a $120 annual commitment. In the first case, the user’s risk is low. In the second, the psychological bar is much higher: users need more proof, more confidence, or simply more time before paying feels justified.

This is why you’ll often see longer trials attached to annual plans, or trials offered only on annual pricing. It’s not about generosity, it’s about reducing perceived risk. A higher price or longer plan requires potentially a longer trial.

Headspace saw a strong conversion lift by offering a 14-day free trial with its annual plan, while offering seven days with its monthly plan. It sounds like it made users more comfortable to commit to a longer plan and helped make their annual plan more attractive.

Not only that, but with shorter subscription periods, adding a trial can almost be overkill and may even devalue your app. Weekly subscriptions, for example, already act like a trial, so you might not need another free trial on top of that. For apps that do offer a free trial with a weekly plan, they often offer only three days vs. a full week, since giving a full week free essentially devalues the subscription.

Category matters more than you think

There is no universal ‘best’ trial length (though the data would suggest leaning towards longer). When you break down trial data by category, the differences are striking:

Trial durations, by category — State of Subscription Apps 2026

Gaming apps overwhelmingly favor very short trials, often under four days. Longer trials invite abuse, with players optimising for completion rather than habit formation.

Photo & Video apps also skew short, because value is immediate; users can edit meaningful content quickly and see the tool’s benefits.

By contrast, Health & Fitness, Education, and Travel apps require more time for progress or focus on more serious commitments (e.g. booking a vacation). Trials of 5–9 days are far more common here, which helps explain why seven days became the industry default.

But common doesn’t mean correct. Hence my polite begging: please don’t default to seven days. The key principle is that trial length should align with activation time, not pricing norms or industry practices.

Engagement is the silent killer of long trials

Long trials often look good on the surface, but in reality, they’re much harder to manage. It’s a classic case of Instagram versus reality — the gorgeous holiday photo versus the food poisoning that left you bedbound.

A long trial with YNAB works because the burden shifts to the product; they actively guide users through workshops, live sessions, and a clear methodology.

YNAB’s web-to-app funnel is focused on you attending a live free workshop

The trial isn’t passive. Rather, it’s structured, and sadly, that’s rare.

For most apps, the question isn’t: “Can we get someone to try it once?” It’s: “Can we build a habit before they lose momentum?”

To do that, you need to:

Drive repeat usage
Prevent procrastination
Continuously build perceived value

I experienced this recently with GOWOD, a mobility app offering a 14-day trial. The onboarding was strong; they started with a mobility assessment, which is great (my hip mobility definitely needs some work).

But mobility is one of those things we know we should do, but rarely prioritize. A long trial made it easy to delay. I started the trial during a busy period, thinking I’d surely find time to complete some sessions.

In reality, I didn’t manage more than two in 14 days, definitely not enough to build the habit. If I’d had a clearer goal or challenge, I might have stuck to it, e.g. committing to X sessions per week for the two weeks and measuring my mobility again afterwards.

Freemium and free trials

Freemium complicates things even further. I’ve seen apps offer such generous freemium access and long trials that I honestly start wondering if they want people to pay at all.

A study by Ling Zhang and Jiang Duan, focused on a freemium SaaS company, found that longer trials increase trial starts but don’t necessarily improve conversion. If users aren’t getting enough value to pay, trial length won’t save you. But here is where the study gets interesting: longer trials did boost delayed conversion: users who had more time to test premium features come back to convert later on.

This explains why apps like Strava and Medium deliberately offer 30-day trials despite appearing ‘simple’. They’re not optimizing for immediate conversion — they’re playing a longer game.

Take into consideration the various factors that impact a lot of freemium apps:

The value of network effects: a lot of freemium apps depend on word of mouth for growth — and also for valuable data, e.g. Strava needs enough users in an area for a sport to segment leaderboards. Medium readers feed the algorithm on which content is engaging and which isn’t.
Value accrues over time: in Strava’s case, I can also imagine that many of their data features (e.g. analyzing your performance) take more than a week to appear. Freemium apps tend to be ‘slow burns’, and if you’re offering premium features only behind a paywall (vs. allowing a taster of features upfront) a longer trial may add value. The same goes for Medium, where readers build up a list of writers and content they like. This also increases the switching costs over time.

So there’s an additional layer of complexity: does a longer trial create network effects or switching costs that outweigh lower immediate conversion? For platform businesses, the answer is often yes.

If you’re freemium, the real question isn’t trial length — it’s how much value must be locked behind the paywall for paying to make sense, while still keeping free users engaged enough to strengthen the ecosystem.

The psychology behind trial length

Once you zoom out, trial length is really about psychology.

Loss aversion is the big one. Ending a trial can feel like losing something you already own, especially when users have:

Invested time
Created data
Built routines

This isn’t strictly about duration; it’s about investment. Photo editing apps can create loss aversion in just a few days. Games can do it even faster. Other products need longer.

That links closely to the endowment effect. The more effort users put in, the harder it feels to walk away. Think IKEA furniture: frustrating to build, yet weirdly hard to get rid of once assembled (unless, like me, you manage to break it while building).

But longer trials only work if investment feels natural and repeatable, not a one-off setup task, but something that builds over time.

On the flip side, urgency is where shorter trials shine. They force early engagement and reduce procrastination.

Every trial sits on a tension line:

Urgency vs. habit formation
Speed vs. depth

Usage frequency matters:

Daily-use apps can build habits quickly.
Weekly or monthly cadence products need longer exposure.

Now add cognitive load into the mix (slight psychology 101 here, but bear with me!):

Complex products require learning time
Simple products don’t — causing unnecessary friction

The simplest way to frame it is this: your trial should be long enough to form a habit, but short enough to avoid being forgotten.

A practical framework to choose your trial length

To make this actionable, I like thinking in terms of natural usage habits — a concept popularized by Phiture’s Mobile Growth Stack.

Before choosing a trial length, ask three key questions inspired by this model:

How often must users engage to experience value? Consider the balance of usage frequency and number of engagement moments. For example, with one app, helping users make five new friends vs. just one hugely improved retention.
When does the first real aha! moment happen? This isn’t the end goal (like running a marathon with Strava), it’s the point where users see clear progress, like completing the first few workouts, or achieving some measurable milestone.
What behavior must exist before paying makes sense? Identify the minimum meaningful behaviour that signals the product is valuable and worth paying for. This is the threshold where the trial converts into a paying experience.

Even then, I can’t recommend enough that you should run a test: measure both the short and long-term impact of any trial duration change. That’s why thinking through the questions above first is so important.

If you’re still unsure, here are some rough guidelines (not rules!) to help:

3–7 days: simple utilities, games, and quick-value apps
7–14 days: daily-use apps where time is needed for habit formation
14–30 days: weekly cadence tools, like a project management app, where users need 2–3 cycles to see value
30+ days: complex analytics or reporting tools, where onboarding, guidance, and meaningful data collection take time

Advanced thinking: not all users need the same trial

If you have a big enough user base, you can take trial experimentation further. Different users may benefit from different trial lengths:

Fast activators vs. slow starters
Freemium-activated users vs. cold starts
Monthly vs. annual plans (some teams only offer trials on annual plans)
Trials as part of win-back flows

The caveat: complexity only helps if you execute it well. Over-engineering monetization often creates confusion rather than clarity.

It’s also worth noting that there are App Store limitations around trial length and setup. To get fancy like YNAB, you may need a web-based trial (luckily, web-to-app is all the rage these days). Just ensure the user experience matches what users see in-app—otherwise, Apple may reject your app.

Alternatively, if you want to test extended trials for specific users, you could use promotional offers on iOS. On Android, you can defer a subscription’s expiry via code.

This kind of segmentation is typically only viable once you have strong activation signals and enough volume to avoid muddying your results.

Beyond the 7-day default

So please don’t default to seven days. While it isn’t a bad starting point for most apps, there are plenty of cases where shorter or longer trials could have a more meaningful impact.

First, decide whether a trial should exist at all, and ensure it effectively activates users. Be bold, like David, and test removing it entirely. If you test trial length, use the right measures of success: trial starts, and trial-to-paid conversion rates aren’t the full scorecard — activation, retention, and revenue are.

Next, understand your users’ psychology. Do they need urgency or time to invest? Does loss aversion play a role? Context matters, as gaming thrives on short trials, while Health & Fitness apps often default to longer ones for good reason.At the end of the day, the right trial length isn’t the one that converts the most users. It’s the one that creates customers who actually stick around.

Announcing StartApp School: Free courses from the experts who’ve scaled what you’re building

Thu, 19 Mar 2026 09:24:10 GMT

At RevenueCat, we get a front-row seat to what separates the apps that scale from the ones that stall. We see the pricing experiments that work, the paywalls that convert, and the retention strategies that keep users coming back month after month. We wanted to package those insights into something builders can learn from directly – so we’re launching StartApp School, a completely free educational resource to help you turn your app into a profitable, lasting business.

We’ve partnered with operators who’ve done this work firsthand to build practical, strategy-focused courses covering the pillars of app growth. No fluff, no theory for theory’s sake — just the frameworks and decisions that matter at each stage.

Four courses, available now

We’re launching with four courses that cover the ground where most apps either break through or break down: monetization, acquisition, retention, and product strategy.

Finding the idea worth building

Most apps don’t fail because of bad code – they fail because nobody validated whether people would pay. Daphne Tideman (Growth Advisor & Consultant) walks you through finding your niche, pressure-testing willingness to pay, and building a launch roadmap that doesn’t waste your first six months.

Turning your paywall into a revenue engine

Most apps leave serious money on the table at the paywall. Vahe Baghdasaryan (Founder & CEO, Tangent) breaks down the psychology behind when and why users pay, and teaches you how to run repeatable pricing and placement experiments that compound over time.

Acquiring users without burning your budget

Paid UA is easy to start and expensive to get wrong. Natalia Drozd (Marketing & Growth Lead) covers how to pick the right channels, build creatives that actually convert, and scale spend without watching your CAC spiral out of control.

Keeping the users you already have

Acquisition gets the glory, but retention pays the bills. Alice Muir Kocourková (Growth Consultant) teaches you how to build lifecycle messaging that converts free users, reduces churn, and wins back the ones who slipped away.

Built for people who are already busy

Each course is made up of short video lessons you can work through at your own pace – binge a full course in an afternoon or knock out one lesson over coffee. Complete a course and pass the quizzes to earn a certificate.

Test your understanding as you work through the lessons

More courses coming throughout 2026

We’re starting with four, but we’re not stopping here. We’ll be adding new courses throughout the year covering more of the problems you’re actually dealing with as you grow.

Enrollment is free and open now.

Explore StartApp School →

Have a topic you want us to cover? Tell us on Twitter or LinkedIn.

How Coconote hit $1M ARR in 4 months with no paid ads

Wed, 18 Mar 2026 13:41:04 GMT

As co-founders of the AI-powered note-taking app Coconote, Brett Bauman and Zack Hargett bootstrapped their way to $6.7M in ARR and an exit to Quizlet in under two years. In a recent episode of Sub Club, they explained the counterintuitive growth engine that got them there: a disciplined focus on organic content, a premium pricing model that built trust, and a series of small product bets that delivered huge conversion wins. It’s a playbook for anyone trying to build a durable consumer subscription business in a world where paid acquisition is no longer the default answer.

The growth engine wasn’t ads — it was creators

From day one, the Coconote team made a critical decision: they would not rely on paid ads. Instead, they went all-in on organic content, building a small, agile team of about 25 part-time content creators. Their insight was that in an algorithm-driven world, the quality of the content matters more than the size of the audience.

“The strategy wasn’t to find an influencer who had an audience,” Zack explained. “The strategy was to find a content creator who produces great content.”

They actively avoided creators represented by agencies, which they saw as a signal that the “alpha” was already gone. Instead, they looked for creators with 5-10K followers and a personal email in their bio — a sweet spot for finding raw talent. This hands-on approach allowed them to build a growth engine that was not only cost-effective but also more authentic and resilient than a traditional ad-based model.

For retention, trial extensions beat discounts

When it came to retaining users, the team tested the standard playbook of offering discounts to users who tried to cancel. But the data revealed a more powerful strategy: offering a trial extension. They found that many users weren’t canceling because of the price; they just hadn’t had enough time to fully experience the product’s value.

“We’re able to retain 25% of people from canceling,” Brett noted. “And [the trial extension] was the most successful one by far, and it really keeps people on that auto-renew.”

By offering seven more days, they addressed the user’s real objection without devaluing the product. It was a simple, non-obvious insight that had a significant impact on their conversion and retention rates, proving that sometimes the best way to keep a user is to give them more time, not a lower price.

Small onboarding changes, big conversion wins

Coconote’s growth wasn’t just about marketing; it was also driven by a relentless focus on product optimization. The team ran numerous experiments to improve their onboarding flow, and two changes, in particular, stood out.

First, they doubled the length of their onboarding to 15 screens. While this might seem like adding friction, it actually increased trial starts by 16% by giving users a more personalized and value-driven introduction to the app. Second, they moved the login screen from the beginning of the onboarding to after the paywall. This simple change eliminated a 10% drop-off from users who were unwilling to create an account before seeing the product’s value.

The takeaway

In the full episode, Brett and Zack go deeper on their pricing strategy, the psychology of building a premium brand for a student audience, and the emotional journey of navigating an acquisition while still running the business day-to-day.

Guest links:

Brett Bauman: LinkedIn, X/Twitter
Zack Hargett: LinkedIn, X/Twitter
Quizlet Careers

Apple guidelines explained: remote testing your iOS app (without getting your account banned)

Wed, 18 Mar 2026 13:00:14 GMT

If you’re a developer trying to optimize your app’s revenue, A/B testing and remote configuration aren’t just nice-to-haves – they’re how you find your edge. You need to test paywalls, tweak onboarding flows, and roll out features gradually to see what actually moves the needle

But there’s a lingering fear: If I change my app remotely without going through App Review, will Apple ban my account?

Short answer: No, as long as you understand the rules of the game

Apple isn’t against A/B testing. In fact, they offer their own Product Page Optimization tools for testing App Store assets. The key to testing safely inside your app comes down to understanding the difference between changing data and changing code – and respecting the spirit of the review process

Let’s break down what you can (and should) be testing remotely, how to do it safely, and where the hard lines are drawn

The green light: what you should be testing

The golden rule for remote testing is Guideline 2.5.2. It states that apps “may not download, install, or execute code which introduces or changes features or functionality of the app”

Notice the word code

If you are using remote config (like Firebase or RevenueCat Offerings) to change data – JSON payloads that tell your existing, pre-compiled code how to behave – you are generally in the clear. Here are the high-impact areas you should absolutely be testing:

Paywall UI and copy: changing the background color of your paywall, swapping out the hero image, or testing “Start Free Trial” versus “Subscribe Now” is perfectly fine. The code to render a button is already in the app; you’re just telling it what text to display. This is the lowest-hanging fruit for conversion optimization
Pricing and packaging: swapping which StoreKit products are shown on your paywall (e.g., testing an annual vs. monthly default, or introducing a new tier) is standard practice. As long as the products themselves are approved in App Store Connect, dynamically choosing which ones to display is safe and encouraged
Feature flags for gradual rollouts: if you’ve built a new feature, included the code in the binary you submitted to Apple (and made sure the reviewer could actually access it), and just want to turn it on for 10% of your users to monitor crash rates or engagement, you’re safe. The feature was there during review, even if it was dormant
Onboarding flows: re-ordering the screens in your onboarding flow or changing the text on those screens to better explain your value proposition is a great use of remote config. You’re optimizing the user journey using existing components

The nuance: it’s about the spirit of the review

Where developers get into trouble isn’t usually the mechanism of remote config, but what they are configuring. The most common trap is bypassing the spirit of the App Review process

Let’s look at a classic example: testing a hard paywall versus a soft paywall

A soft paywall allows users to dismiss it and use some limited version of the app. A hard paywall blocks all access until the user subscribes. Developers often want to A/B test these two approaches to see which yields higher LTV

The problem? A hard paywall fundamentally changes the nature of the app. If your App Store metadata and screenshots show a free app with optional premium features, but a remote config flag suddenly locks 50% of your users out of the app entirely, you’ve created a discrepancy

Apple reviewed and approved a freemium app. You are now delivering a paid-upfront experience. This violates Guideline 2.3.1 (Accurate Metadata) because customers don’t know what they’re getting when they download the app

It’s not the remote config that gets you rejected here; it’s the bait-and-switch. If you want to test a hard paywall, the safest approach is to submit the app with the hard paywall active for review, ensuring your App Store presence accurately reflects that experience

The red light: what will actually get you banned

While Apple is generally fine with data-driven A/B testing, there are a few lines you absolutely cannot cross. Apple’s Introduction to the guidelines is very clear: “If you attempt to cheat the system (for example, by trying to trick the review process… your apps will be removed from the store and you will be expelled from the Apple Developer Program”. Here’s what to watch out for.

The ‘Review Detection’ pattern

This is the most common fatal mistake. Developers use remote config to detect when their app is being reviewed by Apple (often by checking IP addresses or looking for specific test accounts) and show a clean, compliant version of the app. Once approved, they flip a switch and turn on aggressive monetization tactics. Apple actively looks for this, and if they catch you, your account is gone

The web checkout swap

Following the Epic v. Apple ruling, developers in the US can now link to external web checkouts. But many developers misinterpret this ruling and use remote config to swap their IAP paywall for a web checkout after review. This is a fast track to rejection for several reasons:

The ruling requires most apps to still offer IAP alongside the external link. You can’t just replace it entirely
The ruling only applies to the US storefront. If your remote config enables web checkout globally, you’re violating guidelines in every other country
Changing the fundamental payment mechanism post-review is seen as hiding functionality

The native Stripe SDK trap

Another common misunderstanding of the Epic ruling is thinking you can now use Stripe’s native mobile SDK (like Payment Sheet) to process digital subscriptions inside your app. You can’t. Apple allows a link that opens the default browser (not a WebView) to an external checkout page. If you use remote config to turn on a native Stripe checkout for digital goods, you will be rejected. If you turn it on after passing review with an app that didn’t show this checkout, you risk an account ban

Downloading executable code

You cannot download new JavaScript or native code that adds entirely new screens or functionality that wasn’t in the reviewed binary. You can change the data that populates a screen, but you can’t download the screen itself

The yellow light: navigating the grey area

Even when you’re playing by the rules, you might stumble into Guideline 5.6: Developer Code of Conduct. This guideline states that apps should not engage in “manipulative practices” to trick users into making unwanted purchases

Because “manipulative” is subjective, this creates a grey area for certain types of tests:

Exit offers: when a user tries to close your paywall, you pop up a secondary offer with a discount. Is this a smart e-commerce win-back strategy, or is it manipulative? We’ve seen apps get rejected for this under Guideline 5.6, yet many top-grossing apps do it every day
Aggressive back-to-back paywalls: showing a paywall during onboarding, and then immediately showing another one if the user declines, often triggers a 5.6 rejection

If you’re going to experiment in these grey areas, transparency is your best friend. Never try to hide your experiments from App Review. If you’re testing an exit offer, make sure it’s active in the build you submit. Use your App Review notes to explain your A/B testing setup: “We are currently running an A/B test on our paywall flow. The reviewer may see either Variant A or Variant B”

Remote testing is a powerful tool for growth. As long as you’re using it to optimize the user experience and find the right pricing – rather than trying to sneak unapproved features past Apple – you can test with confidence.

A loving note from our editor: you may have noticed this blog post is missing periods at the end of many paragraphs. Please don’t be thrown off or think we haven’t spotted this; it is simply the signature trademark of Rik Haandrikman, VP of Marketing at RevenueCat. For more of his antics, follow Rik on X (you’ll know you’ve found the right account when you stop seeing periods).

Build web-to-app funnels to convert more traffic

Tue, 17 Mar 2026 13:45:33 GMT

The path from ad click to paying subscriber is rough. Users move through app store listings, download waits, onboarding screens, and a paywall. Each step bleeds users, and by the time someone reaches your paywall, you’ve already lost most of the people you paid to acquire.

Web-to-app funnels flip this. You capture, qualify, and convert users on the web before they ever touch the App Store. But building one has always meant stitching together landing page tools, payment processors, analytics platforms, and custom code to connect it all back to your app.

RevenueCat Funnels is now in public beta, and it replaces that entire DIY stack.

A no-code builder for web-to-app onboarding funnels

RevenueCat Funnels lets you design multi-step web experiences in a visual editor, connect them with branching logic, and deploy them to a hosted URL — build and deploy without touching web development, infrastructure, or engineering queues.

If you’ve used the RevenueCat Paywall Builder, the editor will feel familiar. It’s the same drag-and-drop system, expanded into a full canvas where you connect multiple screens into complete acquisition journeys.

Here’s what the end-user experience looks like: a prospect clicks your ad, lands on your funnel, taps through onboarding screens and survey questions, hits a web checkout, and completes their purchase. They get a Redemption Link, download your app, tap the link, and their subscription is already active.

Inside the editor

You build funnels by placing steps on a canvas and connecting them. A step can be either a screen (a customizable page with text, images, buttons and surveys), a checkout (powered by RevenueCat, Paddle or soon Stripe Billing), or even your own custom authentication flow.

Connect steps with triggers like button taps or form submissions. Then layer in branching logic to personalize the journey:

Show a different offer to visitors arriving from a specific ad campaign by branching on URL parameters
Route users to different onboarding paths based on their survey answers
Detect a visitor’s country via IP and localize the experience automatically

When you’re happy with the flow, hit publish. You’ll get a hosted URL to point your ads, emails, and social posts at.

Templates get you live fast

You don’t have to start from a blank canvas. RevenueCat Funnels ships with pre-built templates you can customize. Pick one, drop in your branding, tweak the copy and flow, and publish. Going from zero to a live funnel takes minutes.

Analytics that show where the money goes

Every funnel includes built-in analytics right in the RevenueCat dashboard.

The General Metrics tab shows unique sessions, conversion rate, and revenue over time. Segment the data by traffic source, campaign, country, or other dimensions to understand which channels drive the highest-value subscribers.

The Step-by-Step Metrics tab breaks down conversion and drop-off at every step, so if users are dropping off at a specific screen, you’ll know exactly where to focus. This view is early in the beta and will get more detailed over time.

The analytics also include a customer lifetime selector, letting you measure revenue from a given day’s sessions over a defined window (day 0, 7-day, 14-day, and more). This is the same concept as Realized LTV in Charts, useful when you’re running trials and need to compare true ROI across campaigns.

Funnels captures UTM parameters (source, medium, campaign, content, term) automatically, so you can tie every dollar of funnel revenue back to the campaign that generated it.

Who should try RevenueCat Funnels

Running paid acquisition?

Build a funnel that takes ad traffic through a quiz, presents a tailored offer, collects payment on the web, and sends users to your app with their subscription already active. You keep full attribution visibility and skip app store commissions.

Growth marketer tired of waiting on engineering?

Swap screens, test different survey questions, and adjust branching logic yourself. Check results in the analytics dashboard. Ship changes in minutes, not sprints.

Indie developer without a web team?

RevenueCat hosts everything and handles checkout through Web Billing. This makes it much easier to get started.

Running influencer or campaign-specific promotions?

Create one funnel, then add a branch where visitors with a specific campaign code see a special discount or promotional content. A single funnel can serve multiple audiences by branching on campaign codes.

What’s included in the public beta

The public beta includes everything you need to build, deploy, and measure web-to-app funnels:

Visual funnel editor with drag-and-drop screen builder
Pre-built templates
Survey components (multi-select and single-select)
Branching logic based on URL params, country, browser info, and survey answers
RevenueCat Billing checkout
Paddle Billing checkout
Custom domains
Hosted deployment with a shareable URL
Redemption Links connecting web purchases to app entitlements
Analytics dashboard with conversion rates, drop-off, revenue, and customer lifetime value selector
Automatic UTM parameter tracking
Integrations with Amplitude, Mixpanel and Meta
Localization management
Autosave

Funnels is included in your RevenueCat plan at no additional fee. Purchases made through Funnels count toward your MTR, same as any other RevenueCat transaction.

What’s on the roadmap

The team is building A/B testing within funnels now. The AppsFlyer integration is on the roadmap. Stripe Billing support is coming shortly after launch. More input types like email collection and freeform text are also on the way. If there is anything missing that you’d like to see us build, we’d love to hear from you.

Get started

Here’s how to create your first funnel:

Set up RevenueCat Web with Paddle or RevenueCat Billing with a connected Stripe account
Open the Funnels section in your RevenueCat Web dashboard
Create a new funnel from a template or start from scratch
Design your screens, add branching logic, and connect a checkout step
Publish and share your funnel URL

The full setup guide is in the Funnels documentation.

RevenueCat Funnels is available now in public beta for RevenueCat customers. Open your dashboard and build your first funnel.

Firebender now supports RevenueCat MCP and OAuth

Tue, 17 Mar 2026 02:17:41 GMT

Android developers spend most of their time in Android Studio, but managing a subscription business has always required a browser. You write code in the IDE, then switch to a tab to check MRR, open another to configure offerings, and switch again to design a paywall. Each switch breaks your flow and fragments your attention. Firebender eliminates this by connecting to RevenueCat’s MCP server directly from the IDE, letting the AI agent create paywalls, manage offerings, packages, and entitlements, and query revenue metrics through conversation.

In this article, you’ll explore how Firebender integrates with RevenueCat’s MCP server, including how OAuth sign-in establishes the connection, how you manage offerings, packages, and entitlements through natural language, how AI paywall generation works end-to-end, and how you can query revenue analytics using the Charts API without leaving Android Studio.

Firebender connects to RevenueCat’s MCP server using OAuth 2.0. To get started, open Firebender’s settings inside Android Studio or IntelliJ and add the RevenueCat MCP server. Once added, you’ll see an option to sign in with your RevenueCat account.

Clicking sign in opens your browser for authorization. Firebender handles the token exchange automatically and stores your credentials securely. After authorization, the agent fetches your projects and prompts you to select which one to work with. From that point on, the agent operates within the scope of that project.

The OAuth flow requests scoped permissions for project configuration, charts and metrics, and customer information. This means the agent can read and modify your offerings, packages, entitlements, and paywall configuration, and query your revenue data, but only within the bounds of the permissions you’ve granted. Tokens refresh automatically when they expire, so you stay connected across sessions without manual intervention.

Once you connect your RevenueCat account to the Firebender, then you’ll see the result below with the available MCP tasks:

Managing your subscription infrastructure through conversation

Once connected, you can manage your entire RevenueCat project configuration through conversation. The agent supports creating, reading, updating, and deleting offerings, packages, entitlements, and products. You describe what you want, and the agent takes care of the API calls.

Creating offerings and packages

To set up a new offering with packages, you can ask the agent directly:

“Create a new offering called Premium with a monthly package at $9.99 and an annual package at $79.99”

The agent creates the offering, sets up both packages, and attaches the appropriate products. If any of these resources already exist, the agent detects the duplicates and reuses them instead of creating new ones.

You can also add products to existing packages without having to rebuild the entire structure:

“Add a weekly package to my existing Premium offering”

The agent fetches your current offering structure, confirms what’s already configured, and adds the new package without touching anything else.

Configuring entitlements

Entitlements connect your products to feature access in your app. Setting them up manually through the dashboard involves navigating through multiple screens and attaching each product one by one. Through conversation, the same setup takes a single prompt:

“Set up an entitlement called pro_access and attach it to all my subscription products”

The agent creates the entitlement, lists your existing products, and attaches each one. If some products are already attached to a different entitlement, the agent reports that back so you can decide how to proceed.

You can also set up entitlements for specific products only:

“Create an entitlement called premium_features and attach it to my annual and monthly products”

The agent handles the lookup, creation, and attachment in sequence without requiring you to provide product identifiers manually.

Querying your project

Beyond creating and modifying resources, you can ask the agent to describe what’s currently configured in your project. This is useful for auditing your setup or understanding what might be missing before submitting a build for review.

“Show me all my offerings and which ones have paywalls”

The agent fetches your offerings and paywall data and presents a summary of what’s configured and what’s missing. Offerings without paywalls are called out explicitly.

“What products do I have configured? Which ones aren’t attached to any package?”

The agent cross references your products, packages, and offerings to surface orphaned resources. Finding these manually through the dashboard is time consuming, especially as your project grows. The agent does it in a single query.

AI Paywall generation

The most direct use of the Firebender and RevenueCat MCP connection is end to end AI paywall generation. You describe what you want, and the agent handles every step: creating the offering, setting up the packages, attaching products, and triggering AI paywall generation with your app context.

A prompt like this is all you need to get started:

“Generate a paywall for my fitness tracker app targeting health conscious users”

The agent creates the supporting offering and package structure if it doesn’t exist, then submits the paywall generation job with context from your prompt. RevenueCat’s AI uses that context to generate copy, imagery, styling, and template selection suited to your app and audience.

The agent monitors the generation job in the background. When the paywall is ready, a notification appears with a direct link to the paywall builder where you can review the design and publish it. You don’t need to poll the dashboard or wait in a tab for the job to finish.

You can run multiple generation requests in sequence. The agent tracks each job independently, so you can ask for a “premium” paywall and a “freemium” paywall back to back, and both are monitored separately without conflict.

If you want to iterate on a paywall for a specific promotion or seasonal campaign, you can generate a new one based on an existing offering:

“Generate an AI paywall for my existing Premium offering. The campaign is a summer fitness challenge with a discount on the annual plan.”

The agent picks up the existing offering and package structure and submits the generation job with the campaign context you’ve described. Once Firebender generates a new paywall, you will see the result in the paywall editor like below:

Analyzing revenue with the Charts API

The agent has access to 21 chart types from RevenueCat’s Charts API, including MRR, ARR, churn rate, trial conversions, active subscriptions, new paid subscriptions, and retention cohorts. You can ask analytical questions in plain English and get data backed answers without opening a browser.

“What’s my MRR trend over the last 6 months?”

The agent queries the MRR chart with the appropriate date range and resolution, then presents the trend in a readable format. If there are notable changes in the data, you can follow up with more specific questions.

“Show me trial to paid conversion rate by week”

The agent queries the trial conversion chart with weekly resolution and returns the breakdown. You can then compare specific weeks or ask for the overall rate across a custom date range.

“Compare revenue this month vs last month”

The agent fetches revenue data for both periods and presents the comparison. This kind of quick check is useful between code reviews, before a release, or when you’re iterating on paywall design and want to see whether recent changes have affected revenue.

“What’s my churn rate for annual subscribers?”

The agent queries the churn chart and applies any available segment filters to narrow the results to annual subscribers. Segmented churn data gives you a clearer picture of how different subscription tiers are performing independently.

Because the agent can combine analytical queries with project configuration, you can move from a data question directly into action:

“My trial conversion rate dropped this week. Show me what paywalls I have live and which one is attached to my default offering.”

The agent pulls the chart data and your current paywall configuration in the same session, giving you both the signal and the context to act on it without switching tools.

Conclusion

In this article, you’ve explored how Firebender connects to RevenueCat’s MCP server through OAuth 2.0 sign-in, how you can manage offerings, packages, and entitlements through natural language conversation, how the agent handles end-to-end AI paywall generation, including job monitoring and notification, and how the Charts API integration lets you query revenue data directly from the IDE.

This changes the shape of the workflow. Checking MRR, creating a new offering for an A/B test, or generating a paywall for a seasonal campaign used to require opening a browser, navigating through the dashboard, and context switching back to the IDE. With the MCP connection in place, all of those operations happen inside Firebender through conversation. The agent carries out the API calls, monitors async jobs, and brings results back to where you’re already working.

Whether you’re launching a new app and setting up your subscription infrastructure for the first time, iterating on a paywall to improve conversion, or tracking churn after a pricing change, Firebender keeps you in your development flow. You spend less time switching tabs and more time building.

Beyond SKAN: why standard app campaigns no longer define mobile UA

Mon, 16 Mar 2026 11:22:31 GMT

For years, mobile app user acquisition (UA) was built almost entirely around SKAdNetwork (SKAN), Apple’s privacy-first attribution framework. While SKAN is still required for iOS compliance, modern app teams are now embracing web-to-app funnels, experimenting with creative testing, and exploring first-party attribution methods. UA has evolved, and SKAN is no longer its center of gravity. It’s a baseline signal, rather than a source of truth.

Today, teams are moving beyond standard app campaigns and rebuilding their campaign structures. Read on to understand the user acquisition strategy from top-performing app studios in the world, and how they run enhanced ad campaigns to make more money.

App campaigns under the hood: what isn’t working

As everyone knows, if you work with a mobile app and plan to spend money on paid ads, ad networks (Meta, Google, TikTok, etc.) offer a dedicated campaign type for advertisers to use. While each ad network has different naming — e.g. Meta and TikTok call it ‘App promotion’, while Google calls it ‘Google app campaigns’ — the goal is the same: to offer a dedicated advertising product for mobile apps looking to drive installs or specific user actions, like purchases.

For the sake of this article, I’ll refer to this type of campaign as a ‘standard app campaign’ (SAC).

SACs have been the standard way for almost every single app to run ads. They are pretty straightforward to set up, easy to understand, and designed specifically for mobile apps by sending all users to the same place: the app store product page.

Surrounding that moment, there are three crucial levers to make profitable paid ads:

Pre-app store: test new ad creatives
App store: app store optimization (ASO)
Post-app store: onboarding and paywall optimization

But, even if you successfully use those levers, SACs have four main problems that impact all app advertisers:

Measurement and attribution problems, caused by the implementation of SKAN and native models like Meta’s aggregated event measurement (AEM)
Limited reach, since most app campaigns’ inventory cannot reach what web campaigns do — based on Paddle data, there is only a 15% overlap between app campaigns and web campaigns
Limited control over ad placement and campaign types, caused by campaign automation
Retargeting constraints on iOS due to privacy limitations, which make it hard to target with precision

Because of these problems and consequences, a new trend has emerged in the last two to three years: web-to-app.

The web-to-app trend

So, what the hell is web-to-app?

A good definition is: it is a marketing approach that brings users to a dedicated web-to-app funnel before guiding them to a mobile app. Here, users complete a personalized onboarding flow, subscribe, and then install the app.

Over the past few years, more and more apps have been testing and adopting web-to-app campaigns. By doing so, some companies have come to view SACs as no longer part of their marketing strategy.

Nathan Hudson, Founder & CEO at Perceptycs, wrote a good article on the reasons web-to-app became popular:

Don’t pay any fees to Apple or Google
Get your money faster
Say goodbye to SKAN and ATT attribution struggles
Build and deploy onboarding experiments faster
Reach new audiences
More control and more customization

For these reasons, lately, many app growth teams are focused on web-to-app. And new startups have emerged offering no-code tools to build and customize your web onboarding experience.

However, as Thomas stated on the Sub Club podcast, some apps are adopting this trend for the wrong reason: just to avoid app store fees. What these apps don’t know is that web-to-app also has a set of hidden costs, like:

Managing your transactions online introduces a host of additional complexities that can outweigh the benefits for many businesses
Apps still have to pay a 3% (often higher) fee to a payment processor like Stripe
Paying for expensive third-party tools to build the web onboarding experience
Dealing with global tax compliance and legal structures
ASO rankings will take a hit because fewer people see your product page and download the app

Based on my personal experience, web-to-app can become a nightmare for apps making less than $1M a year — since they pay app stores just 15% (rather than 30% like >$1M apps), the savings are almost non-existent.

Based on this report from AppFigures, only 0.28% of new apps made more than $1M a year in 2024, which basically means — if you’re pursuing web-to-app solely for the purpose of avoiding app store fees — then for 99% of apps it doesn’t make much financial sense.

But what if there’s a middle ground? A user acquisition strategy that could combine the best of both worlds between standard and web-to-app campaigns

Enhanced app campaigns: 8 benefits

Enhanced app campaign (EACs) is a new marketing protocol we’ve developed at Appstack. They consist of web campaigns that redirect all users to the app stores, without needing a website.

Enhanced app campaigns aim to combine the top benefits of standard app campaigns with the flexibility and control of web-to-app, giving you a new way to run paid ads for your mobile app.

Standard app campaigns	Web-to-app
No impact on ASO rankings ✅	No more attribution struggles ✅
No web funnel is needed ✅	Reach new audiences ✅
No tax or legal complications ✅	More control and customization ✅

The results for enhanced app campaigns speak for themselves: looking at a dataset containing data from dozens of subscription apps, we saw an average decrease in cost per subscription of 25%, and an average decrease in cost per start trial of 20%. One fact worth noting is that, in most cases, these numbers were achieved even after increasing daily ad spending.

Enhanced app campaigns are great for apps looking to:

Expand paid reach
Improve profitability
Target B2B or specific niches
Engage older audiences
Improve attribution or seek clarity

We’ve seen great success with EACs, and it’s fast becoming the dominant way to run ads for mobile apps. Let’s break down these reasons why.

1. Superior attribution

If you believe the term ‘superior attribution’ is misleading, you are wrong. EACs genuinely have far superior attribution than standard app campaigns run through ad networks. Let me explain:

Firstly, to run enhanced app campaigns, apps only need to install the Appstack SDK. This enables running ads across multiple ad networks simultaneously with consistent measurement.
Enhanced app campaigns rely on probabilistic matching with an accuracy rate of +95%, allowing app advertisers to pass encrypted PII (Personally Identifiable Information) to improve the quality of the signal (optional), which is as good as it can be. EACs don’t rely on SKAN for iOS attribution, enabling apps to get real-time, high-precision data.
EACs rely on APIs to send in-app event postbacks (signals) to ad networks, creating a more stable and reliable way to keep the signals pipeline in the correct numbers compared to the SDK method.
Since EACs rely on ad links (tracking links), they enable data at the most granular level (ad or keyword, depending on the campaign type). This means apps can see ROAS, profit, rLTV, and many other metrics with greater precision than ever before.

Enhanced app campaigns have unified measurement, enabling apps to get the clearest picture of their app’s success. You can see the entire user history, including all engagements before and after installation — and it works with the most popular ad networks, including Meta, Google, and TikTok. It also lets apps see multiple attribution models, such as last-click, multi-touch or first-click.

2. Fast integration

All apps that use RevenueCat can benefit from a quick, easy implementation to start running enhanced app campaigns with the RevenueCat and Appstack integration.

Using RevenueCat to run EACs will help you to unlock:

A light-speed integration process: no need for developers to map any in-app events or debug to ensure that client-side events (Appstack SDK events) are triggered properly
Avoid untrustworthy data caused by poor implementation or changes to the codebase that could affect in-app events mapped by the Appstack SDK
Easily access server-to-server events like trial_converted or renewals to use them for paid ads

3. Paywall customization

Apps running enhanced app campaigns can show ad-targeted paywalls based on where your users came from, using RevenueCat targeting capabilities and paywalls.

Mobile apps can show a paywall depending on five different paid ads parameters:

Ad network (Meta Ads, TikTok Ads, Google Ads, etc.)
Ad campaign name
Ad set name
Ad name
Keyword

This opens up entirely new testing opportunities, such as:

Keeping organic users with free trials and paid ads users with hard paywalls
Showing a trial-only paywall for campaigns optimizing for trial starts
Customizing design and copy for gender-targeted or interest-targeted campaigns
Presenting higher pricing to users coming from high-intent keywords
Matching the tone and visual language of the ad, the user originally clicked

Follow Appstack’s docs to send user attributes to RevenueCat and start customizing your paywalls.

4. Campaign control

Over the last few years, ad networks have shifted towards automation. This means app advertisers have less control over ad placements during campaign setup, with the algorithm deciding where to allocate the budget.

With EACs, you can take back control and choose where your money is spent. This makes a lot of sense for apps looking to spend money on Google and TikTok Ads.

For example, on Google Ads, an EAC can let you:

Unlock search-to-app campaigns that allow apps to bid on specific keywords or search terms to acquire users. The reporting capabilities enable apps to see revenue and ROAS at the keyword level.
Run YouTube Shorts only, by selecting demand gen as campaign objective and choosing shorts as the only placement on YouTube. This enables apps with traction on Meta or TikTok to deploy the same creatives in a new channel, using the same ad format, to keep growing.

On the other hand, TikTok search-to-app is a new campaign type that allows apps to select a specific set of keywords while using the same ads. Currently, only apps running EACs can run this campaign type.

5. Expanded reach

As Daphne commented in her guide to web-to-app funnels, “Paid optimization looks very different for app campaigns compared to web campaigns. By focusing on the web, you can unlock an entirely new audience you may not have reached before.”

Like Daphne, even after working with dozens of mobile apps, I rarely see an app campaign advertised to me on Meta or TikTok. So I’m definitely in that web audience bucket!

Just like web-to-app campaigns, EACs unlock a new inventory of potential users. This is great for apps of all sizes. Either because their current audience is not performing well, or because apps are saturating an audience and need to look for new users.

6. Retargeting

If you thought that retargeting on iOS was dead in 2026… well, you were right. But EACs are bringing it back. The question is: how is it possible now, given that before everyone said running retargeting campaigns on iOS after the end of IDFA was no longer viable?

The enhanced app campaign protocol allows sending enriched signals to the ad network, which can be used to create custom audiences for retargeting.

For example, these are some of the parameters that the signal includes (data encrypted), which EACs send to Meta for campaign optimization:

Email
Phone number
First name
Last name
Date birth
IP address
User agent
Browser ID
External ID
Zip code
City
State
Click ID

As you can see, there are many parameters that help Meta (and the other ad networks) to identify the right users.

Using these retargeting capabilities, you can leverage EACs to:

Use custom audiences as an exclusion to avoid showing ads to users who already have your app
Reduce the CPM and ad frequency
Launch retargeting campaigns for users who installed the app but didn’t complete the target event, such as a purchase or sign-up (highly recommended for e-commerce or gaming apps!)

7. ASO friendly

Everyone knows that most users only install the app that ranks between the top three results after a search.

So investing money in ads through web-to-app campaigns means you are also investing in minimizing your chances of improving your ranks and getting more app reviews, because fewer users see your product page.

Since EACs redirect users directly to the app store and let everyone install the advertised app, you won’t be hurting your ASO efforts.

This is a strong point for small- to medium-sized apps considering the web-to-app option, given better measurement capabilities.

8. Zero overheads

I know how hard it is to actually make a living out of a mobile app. So imagine adding extra responsibility and problems to it. EACs are built so apps focus on what matters most for your business in 2026: actually reaching customers.

There’s three key benefits to EACs for your UA strategy:

Frictionless: apps remove the need for a website and maintain it; saving money.
Smart economics: incremental revenue without the need to implement third-party services like an onboarding builder or new payment provider. With EACs, apps don’t need to change their existing stacks; they pair easily with what’s already in place.
Operational efficiency: Eliminate the need for web funnels, global tax compliance, and legal structures. Since all users are redirected to the app stores, users use the app stores’ payment systems.

Sounds good, right?

Key takeaways

Enhanced app campaigns equip apps with an infrastructure that runs quickly and helps apps focus on optimizing the two most important things: ad creatives and their actual product (including onboarding and paywall optimization).

The good news is that, technically speaking, every company can build an infrastructure like this, giving them total control over their own data, vendor independence, and a strong moat that few app companies can achieve. (However, it’ll be fairly expensive, so — even if I’m biased — I’d recommend looking at Appstack’s SDK to get started.)

To wrap up, here are the main things to remember:

Standard app campaigns are structurally broken: attribution is unreliable, reach is capped, and automation removed real control from advertisers
Web-to-app has underlying complexities that most apps ignore, and can cause ASO damage
Enhanced app campaigns fix the real problem: they restore device-level insight without adding web funnels, fees, or compliance overhead
EACs give advertisers back what automation took away: control over targeting, placements, keywords, and retargeting
Winning apps will not out-hack SKAN or dodge fees; they will own their data and optimize creatives and products with clarity

The Turkish government now pays 50% of your RevenueCat bill

Thu, 12 Mar 2026 15:07:01 GMT

Every so often, a government does something that makes the entire app industry sit up and take notice. We saw it with the Digital Markets Act in the EU, and we’ve seen it with the ongoing antitrust debates in the US. But it’s rare to see a government step in not to regulate, but to accelerate.

That’s what’s happening in Türkiye right now. And it’s a big deal.

As of January 1, 2026, a new presidential decree (No. 10962) has gone into effect, completely overhauling the country’s support for service-based exports. While some of these supports have been around for a while, this new decree consolidates them, simplifies the rules, and in many cases, massively increases the amount of money developers can get back.

And the big news for RevenueCat users? RevenueCat is now on the official “approved software” list, which means if you’re an eligible Turkish company, you can get 50% of your RevenueCat subscription fees reimbursed by the government.

This isn’t just another tax credit. It’s a direct subsidy on the cost of growth. Let’s break down what’s changed, and why it matters for developers both inside and outside of Türkiye.

Bigger, better, simpler: what’s new in 2026

For years, Türkiye has offered support to its IT sector. But the old system (under Decree 5447) was a complex web of tiered limits and inflation-adjusted caps. The new Decree 10962 sweeps that away in favor of a simpler, more generous framework. The support rate is still 50% for most programs, but the annual limits have been substantially increased across the board.

Here’s a quick comparison of the old vs. new annual limits for a typical app developer:

Support Program	Old Decree 5447 (2024 limits)	New Decree 10962	Change
Software License	50%, ~1.83M TL/yr	50%, 2.5M TL/yr	+37%
Platform Commission	50%, 2.5M TL/app (top 3), 600K TL/app (rest)	50%, 4M TL/app (all 10), 20M TL total	~70% effective increase
Digital Product Promo	50%, 10M TL/app (top 3), 1.2M TL/app (rest)	50%, 15M TL/app (all 10), 50M TL total	~50% per-product increase
Hosting	50%, 1M TL/yr	50%, 5M TL/yr	5x increase
General Marketing	50%, ~11M TL/yr	50%, 25M TL/yr	~2.3x increase

Two changes are particularly massive:

The end of tiered limits: Under the old system, support for platform commissions and marketing dropped off a cliff after your first few apps. Now, every app (up to 10) gets the same high per-product cap. This is a huge win for studios with a portfolio of apps.
Huge cap increases: The total amount you can claim for platform commissions has nearly doubled, and the hosting support has gone up 5x. This is a direct injection of capital into the growth loop of an app business.

RevenueCat is now on the approved software list

The Software License Support program isn’t new, but our inclusion on the approved list is. As of the latest update to the “Desteklenen Yazılım Lisansları Listesi” (Supported Software Licenses List), RevenueCat is now officially included.

What this means is simple: If you are an eligible Turkish company, you can now get 50% of your RevenueCat subscription fees reimbursed by the government.

This fundamentally changes the ROI of using RevenueCat for Turkish developers. The best-in-class infrastructure for managing subscriptions, analyzing data, and running experiments now comes with a 50% government-funded discount. It makes the decision to build, measure, and grow your app with proper tooling a no-brainer.

It’s about more than just a discount

Getting 50% back on your RevenueCat bill is great. But the real power here is how these incentives work together. The Turkish government isn’t just giving you a discount on tools; it’s subsidizing the entire engine of your app’s growth.

Think about it:

You use RevenueCat to manage your subscription infrastructure and get a single source of truth for your revenue data
The government reimburses you for 50% of your RevenueCat subscription under the Software License Support program
You use RevenueCat’s charts and analytics to create the reports you need to claim 50% of your App Store and Play Store commissions back from the government
You use RevenueCat’s Experiments and Paywalls to optimize your pricing and increase conversion, growing your top-line revenue
You take that extra revenue and the money you got back from commissions and reinvest it into user acquisition, knowing the government will reimburse you for 50% of that marketing spend

This is a virtuous cycle. RevenueCat becomes the system of record that not only helps you grow faster but also unlocks the government funding to fuel that growth. The data you need to claim your commission and marketing reimbursements is right there in your RevenueCat dashboard.

How to take advantage of this program

If you’re a developer in Türkiye, you’re probably wondering how to get started. The program is administered through the Ministry of Trade, and requires membership in the Service Exporters’ Association (HİB) and applications via the Destek Yönetim Sistemi (DYS).

Navigating government programs can be complex, but the opportunity is too big to ignore. To make it easier for local developers, we’ve been working closely with our partners in Istanbul, Neon Apps. The Neon Apps team provides free, local-language support to RevenueCat users, and they have deep expertise in helping Turkish companies navigate these incentive programs. If you’re a RevenueCat customer in Türkiye and want hands-on help to make sure you’re getting every lira you’re entitled to, get in touch with us and we’ll connect you with the team at Neon.

The future is bright for Turkish apps

This new decree is a clear signal that the Turkish government understands the power of the app economy and is willing to make serious investments in its growth. For developers in Türkiye, it’s a golden opportunity to scale faster and more profitably than ever before. For the rest of us, it’s a fascinating development to watch – and a reminder that the next great app can come from anywhere.

We’re incredibly excited to be a part of this new chapter for the Turkish app community and to help them build the next generation of globally successful apps.

From spite-driven development to community-powered success

Wed, 11 Mar 2026 18:47:43 GMT

What happens when you get laid off from your dream job at Disney? If you’re Adrian Eves, you take some advice from Paul Hudson, add a dash of spite, and finally launch the indie app you’ve always talked about making.

In the latest episode of Launched, host Charlie Chapman sat down with the developer and community organizer to discuss his journey from working on Apple’s accessibility team to building apps rooted in his own life. His story is a candid look at the messy, non-linear, and deeply rewarding path of an indie creator.

The push you didn’t know you needed

For years, Adrian was the developer who was going to ship an app. “Oh, I’m going to do it this year,” he’d say. But it took an unexpected layoff from Disney to turn the idea into a reality. Feeling “pretty mopey,” he got some crucial advice from a friend. “Paul [Hudson] said, ‘At the very least, you need to make an indie app so that way you always have something you can fall back on.’”

That conversation was the spark. The problem to solve came from his own life: a chaotic jumble of Apple Notes trying to track his child’s health data. “I kept getting lost in all these notes that my partner and I would share,” Adrian recalls. “I was like, ‘My child who’s like three years old, I know she’s not like 11 inches.’ So that’s like an old note.” That frustration became PediaPal, a health hub for kids and his first real foray into indie development.

The bet that built an app in a month

After the emotional rollercoaster of launching PediaPal—and the subsequent letdown of not getting featured by Apple after a massive redesign—Adrian found a new, more potent form of motivation: spite.

“Paul encouraged me to get into something he called spite driven development and I made a second app out of it.”

This time, the problem was even more personal: managing his chronic, debilitating migraines. He needed a tracker that was effortless to use in a moment of intense pain. The idea for Auralog was born. But it was a friendly challenge that got it over the finish line. “One of my friends issued a challenge and they said they bet that I couldn’t release my app in a month,” Adrian laughs. “The stakes were real high. Let me tell you, it was ice cream.”

He won the bet. By focusing on a single, search-driven problem and designing for a moment of extreme user need (the core feature is a giant “Save Now, Log Later” button), Auralog quickly found traction and became his first project to generate meaningful, growing revenue.

Building spaces for others to succeed

Adrian’s story isn’t just about apps; it’s about the community that surrounds them. He’s a natural organizer, driven by a desire to pay forward the support he’s received. “This community has given me so much,” he says. “It would not be right to be like a dragon and hoard a bunch of gold.”

From helping run iOS Dev Happy Hour to co-founding CommunityKit—the unofficial “glue” of WWDC week—he creates spaces for developers to connect and learn. Now, he’s channeling that passion into his own conference, Swift Sonic, a music-festival-inspired event with a unique twist: pairing veteran “headliner” speakers with first-time “opener” speakers.

It’s this commitment to building up others that defines his journey. Adrian Eves’s story is a powerful reminder that indie success isn’t just about shipping features or hitting revenue goals. It’s about solving real problems, learning in public, and building relationships that lift everyone up.

RevenueCat now integrates with Appstack

Wed, 11 Mar 2026 05:23:02 GMT

Running paid acquisition without connecting it to subscription revenue means flying blind. Attribution data lives in one tool, subscription events in another, and the relationship between your ad spend and actual LTV stays murky. RevenueCat’s new Appstack integration closes that gap.

Using RevenueCat’s Appstack integration

With the Appstack integration you can:

Send RevenueCat subscription events directly to your Appstack webhook endpoint (optional).
Attribute subscription revenue to campaigns tracked by Appstack using the Purchases SDK.
Identify users in Appstack using the $appstackId subscriber attribute.

Integrating with Appstack requires that Appstack SDK is installed in your app. Refer to the Appstack developer documentation for the latest installation instructions.

1. SDK attribution mapping

A single call — setAppstackAttributionParams() — pulls attribution data from the Appstack SDK and forwards it to RevenueCat. Under the hood, it sets $appstackId, campaign attribution attributes ($mediaSource, $campaign, $adGroup, $ad, $keyword), click IDs, and device identifiers. No need to call collectDeviceIdentifiers() separately.

The call also syncs attributes to the RevenueCat backend and fetches fresh offerings before returning. That means by the time the callback fires, your paywall is already reflecting the user’s Appstack targeting data.

Set the following attributes after configuring the Purchases SDK and before the first purchase occurs.

This is enough for RevenueCat to start storing attribute subscription revenue information from Appstack.

Keep in mind that AdSupport framework is required to collect the IDFA on iOS.

2. Subscription lifecycle event forwarding

The Appstack integration uses a reserved subscriber attribute to associate RevenueCat events with users in Appstack if the integration is configured to send events. Event forwarding supports following properties:

Includes Revenue	Supports Negative Revenue	Sends Sandbox Events	Includes Customer Attributes	Sends Transfer Events	Optional Event Types
✅	✅	❌	❌	✅	❌

Configure Appstack in the RevenueCat dashboard under Integrations → Attribution → Appstack. You’ll need your webhook URL and an authorization header from Appstack.

Once set up, RevenueCat forwards the full event suite. This lets you measure subscription revenue and LTV from your acquisition campaigns in Appstack, rather than just top-of-funnel installs. Following events are sent to Appstack

Initial Purchase
Renewal
Cancellation
Uncancellation
Non-Renewing Purchase
Subscription Paused
Expiration
Billing Issue
Product Change
Transfer
Subscriber Alias

Get started today

Integrate RevenueCat with Appstack for attribution and targeting to get a clear picture from ad click to paying subscriber to long-term LTV. The integration is live now on iOS and Android SDKs, available for all apps from the Attribution section of your RevenueCat dashboard. Check out the full docs

Inside the product org at RevenueCat

Mon, 09 Mar 2026 12:42:53 GMT

RevenueCat’smission is to help developers make more money. Our CEO, Jacob, reminds us in every biweekly all-hands meeting that we do this by “building a winning team” and “shipping and selling stuff that helps developers make more money”. The latter, shipping stuff, is the remit of Engineering, Product & Design (EPD), and one of the three pillars of the winning team is our team of product engineers.

That product team currently consists of five product engineers, with several roles open and more to be hired over 2026. So I want to share a bit more about what it’s like to be a product engineer (PE) at RevenueCat, what it takes to be a successful PE here, and what challenges we’re facing.

What makes the RevenueCat product special

There are many products you could work on as a product person, from consumer products everybody knows (including your parents!) to niche products that baffle anyone not privy to the specific industry. RevenueCat definitely falls into the second category, but nonetheless, it’s a very special product.

Obscure problems, meaningful impact

One of the defining features of RevenueCat is that we’re solving really complex, somewhat-arcane problems. Understanding what each field in an in-app purchase payload represents, what edge cases exist across Apple, Google, and Stripe, and how to best handle them is complicated and rarely glamorous.

We often say we eat pain for a living — meaning, we solve painful infrastructure problems so developers don’t have to. That alone would make RevenueCat a complex product to work on. But what makes it meaningful is the reason behind all that work: we help app developers monetize their apps, because…

We believe that more software is (when averaged out), a net good for the world
We believe that allowing people to create software and make a living from that is the best way to help humanity create more software

If you buy into these beliefs, then RevenueCat is a great product to work on, because the problems we solve help tens of thousands of developers monetize their apps.

Many of us at RevenueCat come from app backgrounds and/or still have indie apps on the app stores. We relate to the problems we solve and the value we bring to the industry, simply because we’ve been in the shoes of our customers. That makes us unique.

A product loved by its customers

RevenueCat is a product with many fans. Not every customer is a fan, of course — some have legitimate gripes with the product, and for some it’s just a tool for their day-to-day work. But we have many customers who really love the product, because they see us enable them to get paid doing what they love: building apps.

Whether it’s meeting customers at conferences who seek our booth out to talk about the app, or people coming to App Growth Annual, it’s wonderful hearing people love the product you work on. We regularly see customers proudly post on social media about their first RevenueCat invoice — this means they’ve crossed the threshold of our free plan and are now making real money from their app. There aren’t many products customers are so happy to pay for!

The bill we all want to pay — and paying it is an achievement for mobile developers. Our first invoice paid to RevenueCat! pic.twitter.com/pThxeErMcN
— Camilo Peñalver (@camilopenalver) October 28, 2025

This kind of feedback makes working on RevenueCat extremely rewarding, and also provides that motivation to help customers who run into issues.

Aligned business-customer incentives

Speaking of first invoices, one of the best features about RevenueCat and its business model is how it aligns our incentives with those of our customers. We charge customers a percentage of their revenue. This means that when they grow, we grow. When they make money, we make money.

There is almost no purer business model. We want our customers to succeed because we will, too. Our incentives and the incentives of our customers are perfectly aligned. This makes decisions about the business viability of product choices much easier.

A few years ago, we decided to simplify our pricing structure so every customer gets access to all features, regardless of whether they’re on the free tier or an enterprise plan. We can do this because our revenue scales with our customers’ revenue anyway, so naturally, bigger customers will pay us more. We also believe that everyone should be able to benefit from the growth tools we provide. If we limited access to those tools to smaller developers on a cheaper plan, we would be limiting our own growth potential.

Different surface areas and challenges

The last distinct characteristic of the product that I want to highlight is the different surface areas we have; all of which come with their unique (technical) challenges.

Backend: our backend is critical infrastructure for our customers. We need to prioritize reliability to ensure we don’t jeopardize our customers’ revenue streams, and we need the backend to be ultra-scalable. Our backend processes billions of API requests every day. Our most used API endpoints need to be fully cached or our database would be a smoldering wreck in an instant.
SDKs and APIs: these need to be designed in a way that they remain stable for years to come, since developers will build their apps and backends relying on them. For the SDKs in particular, the quality bar is extremely high, because a buggy SDK that gets implemented by a developer could be out in the wild for a very long time if someone installs an app using that SDK and never updates it.
Web dashboard: here we have a much higher degree of freedom to innovate and iterate quickly, and therefore deploy changes extremely rapidly.
Consumer-facing UI: recently, we’ve shipped more and more consumer-facing UI: our paywalls, customer center, web checkout, and web customer portal are all used by our customers’ customers and therefore need a high degree of polish in order to inspire trust.

How we approach product work

Our approach to product work is shaped by our values as well as our talent vision.

Product engineering, not product management

We recently made the decision to change the roles from product managers to product engineers, and folded product engineers into the engineering org. In a world where AI assisted development is making writing code less of a bottleneck, product and engineering need to move even closer together: product people can ship changes to the product without involving a software engineer, and when writing code no longer becomes the main task of software engineers, they need to show greater product sense and judgment in order to be successful. It also means a greater need than ever for product people and software engineers to be aligned and walk in lock step, and this role change is strengthening that alignment.

Deciding what to build

Every year, we decide on a product strategy. The product strategy determines the main focus areas for the coming year. In general, the yearly product strategy is an evolution of the one that came before it, rather than a revolution or radical pivot. The strategy is set at leadership level, and PEs provide critical input as it is being shaped.

In line with the strategy, we also revisit our team setup. We have relatively stable cross-functional teams where a PE works together with a team of engineers, reporting to an engineering manager (EM), as well as a designer.

The roadmap is mostly determined in our quarterly planning process. We’ve gone through a number of iterations of this process over the years. Currently, the process is as follows:

Each team, represented by its PE, EM and designer, proposes a set of priorities for the team These are then reviewed and discussed with leadership (CEO, CTO, Head of Product). There can be some adjustments to the roadmap in these discussions, but by and large, the teams own their roadmap and prioritization. Product engineers play a pivotal role in this process — often, they are the ones who have the most holistic view of their product area and the value that we can deliver to our customers through product improvements.

On a day-to-day and week-to-week basis, product managers work closely with their EM and designer counterparts, with at least weekly meetings and even more frequent interactions via async communication. The discovery and delivery of features in the team is owned by the whole team, and achieved through tight collaboration.

Living our values in the product team

As mentioned, the other aspect that shapes our approach to product are the company values. These aren’t a list of values stuck in a Notion doc and forgotten about, they’re an ethos we actively work toward and measure ourselves against.

Customer obsession

At RevenueCat, we believe in focusing on delivering value to our customers above everything else. This means several things:

PEs are expected to talk and interact with customers frequently: this includes 1:1 conversations and research calls, but also support tickets, social media posts, sales conversations, shared Slack channels with customers, conference booth chats, etc.
- There is no barrier between PEs and customers: if a conversation is going to help you make a better product decision, just set it up
Customer anecdotes are often the most convincing way to argue for product decisions at RevenueCat. Of course, we don’t blindly build everything that customers ask for, but we try to find the underlying needs and problems. Generally, we believe that if a customer cares enough about the product to tell you their issues and unsolved problems, it’s wise to listen.
Teams will be attentive to customer needs, regardless of problem scale — even the small issues that bug our customers. Our strategy is important, our roadmap is important, but if we can show a customer we care by quickly fixing a bug they encountered or removing a limitation they ran into, that will often make their day and turn doubters into fans (or fans into evangelists).

Always be shipping

Always be shipping impacts our approach to product by pushing us to reduce the scope of whatever we are planning to the MVP version. There’s a couple reasons to do so:

It means delivering value to customers more quickly
It allows us to get feedback and validation from customers as early as possible

Shipping goals

One way of forcing us to truly always be shipping and minimize scope is setting internal deadlines.

When we have set such a shipping goal, we’ll do everything we can to ship it by the internal deadline, like adding resources to allow the team to go faster. It often also forces us to make painful scope cuts, where we reduce some aspect from a ‘must-have’ to a ‘nice-to-have’ (which, if you know anything about software development, more often than not means it won’t actually get done).

What frequently happens is that once we launch a feature and get it into customers’ hands, the first requests we get aren’t for the thing we deprioritized, but for something completely different. This proves the value of shipping quickly: neither us nor our customers are good at predicting how they will actually interact with a feature once it’s actually live in the product. The only reliable way to determine that is to ship fast and iterate after.

Bias for action

One other aspect of always be shipping is our bias for action. We’re always acting with imperfect information. If we waited for perfect information, we would never make any decisions. Therefore, as product engineers, we’re responsible for pushing decisions forward, even in the face of uncertainty. It is rare that decisions can’t be corrected later on, so moving forward beats endlessly deliberating. Act, don’t talk.

Own it

Ownership is very important at RevenueCat. For product engineers, it means that nothing is someone else’s problem. We all win together, we all lose together. If you notice a problem, do something about it — even if it’s not your area.

Of course, that doesn’t mean that PEs have to fix all problems. However, since they’re often the ones with the broadest, most end-to-end understanding (from customer problem to solution design to technical approach), they’re often the ones who are best positioned to notice problems (and are expected to do so).

RevenueCat product engineers also have high agency, meaning we believe in their ability to affect change even in adverse conditions. Our PEs will do everything they can to address the problems they see, and sometimes even a bit more than that (i.e. learn something new to better solve problems). They dig through the code base to see if they can find the root cause of a bug, they query our data warehouse to better understand our data, or they get on a call with a customer on short notice to debug their issues.

AI-assisted development also means that product managers are now making contributions to our code base on a somewhat regular basis. In cases where the changes are straightforward, it is often significantly faster for a PE to make a change directly via Cursor or Claude Code and get it reviewed and shipped, versus writing a ticket for an engineer to pick up.

TL;DR: there’s a lot going on, and it’s all hands on-deck.

Balance

Our balance value is perhaps the most misunderstood — it doesn’t mean we’re slacking off (on the contrary, RevenueCat is still a startup and working here is deliberately intense). We only win if we continue to move fast.

However, our balance value reminds us that there is a fine line between moving fast and burning out. Hard work can be extremely rewarding if we are working on interesting problems with teams of highly-motivated people. PEs are often pivotal in upholding the motivation and interest level of the team; it’s their job to connect the problems we’re solving with the customer impact, e.g. sharing customer ‘good feels’ and showcasing contagious excitement.

Our balance value also covers being empathetic and kind toward others, and building a cohesive team environment where there’s mutual trust and appreciation of everyone as a human being. Product engineers, as natural leaders, can play a key role in modeling and facilitating these behaviors.

RevenueCat’s talent vision

RevenueCat’s talent vision is to build a winning team of high-caliber team members. This means that we have a high standard for all team members, which we uphold through our hiring and performance management processes.

There are a few implications of that on our approach to product work. Firstly, our teams consist of relatively senior and product-minded engineers and engineering managers. This means that PEs at RevenueCat generally need to be less in-the-weeds in managing projects, creating super detailed tickets, etc. Instead, they need to be better at communicating the necessary context and understanding of the problem space, in order for engineers to not get bottlenecked by PE decision making.

It also means that our team is rather lean. We believe that smaller teams of high-caliber people can move much faster than bigger teams with a lower talent bar.

The main challenges our product team is facing

Here are some of the main challenges that we face as product engineers at RevenueCat.

Too much to do, too little time

This might be the quintessential startup issue, and it’s definitely true at RevenueCat: we always have more ideas, and more customer problems to solve than we have the capacity to work on. This means that as a company, as individual teams, and as PEs, we have to prioritize well, and be able to communicate that prioritization to the market, to customers, and to internal stakeholders. We solve this through our strategy and planning process to make sure we continuously focus on the highest-impact opportunities.

Balancing customer obsession and strategic priorities

Related to the need for prioritization outlined above, we’re often drawn in different directions by our customer obsession value and our strategic priorities. Strategic projects can take a while before showing impact, and our customer obsession value makes us consider smaller customer requests with urgency. Getting drawn to either extreme is not great: if we deprioritize customer feedback completely to focus on long-term strategic priorities, we will seem unresponsive and risk losing the customer love we’ve built up. On the other hand, if we only prioritize being attentive to customer feedback, we miss out on big swings, following the market, or unlocking the next big opportunities for the product and the company.

Growth means increasing coordination

RevenueCat has shown a great growth trajectory over the past few years. We have grown our team less quickly than our revenue (part of the winning team talent vision), but we still have grown and are planning to continue to do so. A bigger EPD team means more capacity to improve our products, but it also means increased coordination needed. Doubling our engineering team doesn’t mean we can ship twice as many changes, since some of that capacity will need to go toward coordinating work. Plus, adding more teams increases the risk of building experiences that are inconsistent between different corners of the product (which again requires coordination to prevent).

Becoming a multi-product company

The biggest strategic challenge we have in front of us is moving from a single-product company to a multi-product company. RevenueCat has long been the best way of adding in-app purchases to your app. This means that a large proportion of subscription apps on the app stores launch with RevenueCat today. However, the market of new subscription apps is limited.

To keep growing, we need to both be able to provide more value to our existing target market, and sell to customers for which the current RevenueCat product is not a good fit. Both of these require becoming a multi-product company: either adding completely new products or unbundling our existing product into pieces that can be sold separately.

We’re planning both, and that means fundamentally changing the process for how we make product decisions. We need to build experiences that make sense when you are using only part of the platform. We need to set up pricing and billing models. We need to conceive onboarding flows that find the right product and set it up.

We are only at the beginning of this journey, and it will keep us busy for the foreseeable future.

What makes for a good RevenueCat product engineers

Still with me? Okay, let’s jump into what makes a good fit for product engineers at RevenueCat. Maybe you’re the right fit, or perhaps you know someone who is?

Builders, not managers: RevenueCat PEs see themselves as product builders. We don’t manage backlogs or juggle stakeholders — we collaborate, advocate for the best solutions, and help our teams move faster.
Missionaries: Our mission is to help developers make more money, and PEs embrace that fully. We’re customer-obsessed because we believe more software is good for the world, and thriving developers means more software.
Extreme ownership: RevenueCat PEs do everything it takes to solve customer problems and make the product successful. They don’t point fingers, blame others, or accept failure; they find a way forward while contributing as true teammates and carrying shared weight, rather than being a lone wolf.
Decisive with imperfect info: In a fast-paced startup, PEs gather just enough information to make a decision quickly. They act based on current data, commit to the action path, and rally the team, but stay open to changing course if needed when new information arrives.
Deep technical understanding: RevenueCat meets multiple personas, but at its core it’s a developer tool. PEs need to have deep technical knowledge and be able to explain and evaluate decisions about APIs, distributed systems, SDK constraints, and data models.
Strong asynchronous communicator: As a globally remote team, RevenueCat PEs excel at clear async communication — whether through docs, Looms, or FigJams — and they know when to switch to real-time conversations to keep the team aligned.

We’re hiring!

We’re almost constantly growing the product engineering team at RevenueCat. If you’re a builder who loves solving hard problems with meaningful impact — and you want to help tens of thousands of developers make a living doing what they love — we’d love to talk. Check out our open roles on our careers page!

Exit Offers in RevenueCat Paywalls

Fri, 06 Mar 2026 21:07:45 GMT

RevenueCat Paywalls offer a powerful feature for earning the business of more price-sensitive users: exit offers. With exit offers you can present an alternative offering, usually a discounted plan, to users the moment they dismiss a paywall, giving you a second chance to convert a user who might otherwise be lost.

This is a common and effective strategy used in e-commerce to reduce cart abandonment, and it is a valuable capability for mobile app developers. However, the implementation of such offers on the App Store has been a topic of much discussion and some confusion. In this post, we’ll walk you through how to use Exit Offers, discuss the potential for App Review issues with Apple, and provide our recommendation on how to proceed.

What are Exit Offers?

An exit offer is a secondary offer you present to a user when they attempt to close your primary paywall without making a purchase. Instead of simply losing a potential subscriber, you can present them with an alternative, such as a lower price, a longer trial, or a different subscription term.

For example, if your main paywall promotes an annual plan, your exit offer could be a monthly plan. This allows you to capture users who may have been interested but were not ready to commit to a full year.

How to Implement Exit Offers with RevenueCat

We’ve integrated Exit Offers directly into the Paywall Builder in the RevenueCat dashboard, so you can enable them without any code changes. When editing a paywall, you can now designate another one of your offerings to be presented as an exit offer.

This makes it easy to experiment with different win-back strategies and measure their impact on your conversion rates and revenue.

An important implementation note is that exit offers only work when using the presentPaywall or presentPaywallIfNeeded functions that display paywalls in iOS and cross-platform SDKs. On Android, they are automatically enabled when utilizing the PaywallDialog and PaywallActivity classes.

Crucially, exit offers will not work if you manually embed paywall views or components directly into your UI (e.g., PaywallView, Paywall composable, <RevenueCatUI.Paywall> component, etc.). Full details can be found in the paywalls documentation.

A Note on Apple’s App Store Review

While exit offers are a standard practice on the web, their use on the App Store has been inconsistent. Some developers have reported that their apps have been rejected for using them, with Apple’s App Review citing Guideline 5.6 – Developer Code of Conduct. This guideline states that apps should not engage in “manipulative practices” to trick users into making unwanted purchases.

The rejection messages are often similar to this one reported by a developer on Reddit:

“The app attempts to manipulate customers into making unwanted in-app purchases. Specifically, your app still displayed an additional discount offer when we attempted to exit the subscription page.”

Here’s what Apple’s App Review Guidelines explicitly say in Guideline 5.6:

Apps should never prey on users or attempt to rip off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app.

This has created a gray area for developers. The guideline itself does not explicitly forbid exit offers, and the term “manipulative” is subjective. Many popular apps currently use exit offers, yet some App Reviewers do seem to be rejecting apps based on this guideline.

Note that we have not heard any reports of rejections from developers submitting Android apps to the Google Play app store. As of this writing, exit offers seem to be in compliance with Google Play Policies and Guidelines.

Our Recommendation: Try on Android but be careful on iOS

At RevenueCat, we believe that a well-implemented exit offer is a legitimate marketing tool that can provide value to users by giving them more options. However, given the current ambiguity and the risk of rejection from Apple’s App Review, we advise developers to use this feature at their own risk for their iOS apps.

It is worth trying on your Android apps to see how it impacts your conversion before running the risk on iOS. You can use RevenueCat’s Targeting feature to only send paywalls with exit offers to your Android users.

DO NOT try to trick App Review

We want to be very clear on this point: you absolutely should not attempt to circumvent App Review by remotely enabling this feature after your app has been approved. This is a direct violation of the Apple Developer Program License Agreement and could result in the termination of your developer account. The risk is not worth the reward, we promise.

Conclusion

Exit offers are a powerful new tool in your monetization arsenal. They can help you recapture lost subscribers and increase your revenue. However, the current App Review landscape means that you must be cautious when implementing them.

We will continue to monitor the situation and provide updates as we learn more. We encourage you to be prepared for a potential rejection if you use this feature and to have a plan to address it. We look forward to hearing about your experiences with exit offers and App Review.

What Google Play’s new merchandising and optimization page means for Android developers

Thu, 05 Mar 2026 23:35:13 GMT

Most Android developers think about monetization in terms of what happens inside their app: launching a billing flow, presenting a paywall, handling purchase results. But Google Play also merchandises your products outside your app, recommending them to users on store surfaces, in notifications, and during the browsing experience. These out-of-app surfaces drive purchases that many developers never actively manage. Now, Google is consolidating three separate merchandising features into a single ML-driven page, and there is a hard deadline to prepare.

In this article, you’ll explore what the three existing out of app merchandising features are and how they work, what Google Play is changing by unifying them into the new Merchandizing and optimization page, the timeline and March 16 cutoff that affects your existing configurations, special considerations for each feature during the migration, concrete steps you should take before the deadline, and how out of app purchases connect to your billing stack.

Background: How Google Play merchandises your products outside your app

Before diving into what is changing, it is important to understand what Google Play already does to promote your products beyond your app’s own UI. Out-of-app merchandising is significant because it reaches users who are not currently inside your app. A user browsing the Play Store, receiving a notification, or exploring related content may encounter your products without ever opening your app first. This creates an additional acquisition and conversion channel that operates independently of your in-app purchase UI.

There are three distinct features that handle out-of-app merchandising today, each configured separately in the Google Play Console.

Purchase flow recommendations

Purchase flow recommendations allow Google Play to suggest your products to users as they browse the Play Store. When a user is exploring apps, viewing related content, or navigating purchase surfaces, Google Play can display your in-app products or subscriptions as recommendations. These suggestions are based on the user’s purchase history, browsing behavior, and contextual signals.

You configure purchase flow recommendations by selecting which SKUs are eligible for promotion and optionally targeting specific countries. Google Play then decides when and where to show these recommendations to relevant users. The configuration lives on its own dedicated purchase flow recommendations page in the Google Play Console.

Featured products

Featured products give you more direct control over promotion. Rather than letting Google Play choose which products to surface, you explicitly configure which products to highlight on Google Play surfaces. You can set start and end dates for promotions, associate them with specific offers or events, target specific audiences and countries, and limit them to licensed testers during development.

Featured products are useful for time-limited promotions, seasonal campaigns, or highlighting new premium content. They give you granular control over what gets promoted, to whom, and for how long.

Cart abandonment reminders

Cart abandonment reminders address a different part of the purchase funnel. When a user begins a purchase flow but does not complete it, Google Play can send a notification reminding them to finish the transaction. This is a common e-commerce pattern adapted for the app store context.

For cart abandonment reminders, you do not configure individual products. Instead, Google Play automatically tracks abandoned purchase attempts and sends reminders for users who started but did not finish a transaction. You can opt out of this feature entirely using a form in the Google Play Console if you prefer not to have reminders sent for your products. Currently, the opt-out is managed separately for one-time products and subscriptions.

What’s changing: A unified, ML-driven approach

Google is replacing these three separate tools with a single Merchandising and optimization page in the Google Play Console. Instead of managing purchase flow recommendations, featured products, and cart abandonment reminders independently, you will configure everything from one place.

The fundamental shift is from manual configuration to algorithmic optimization. Here is how the new approach works:

You select eligible SKUs: On the new page, you choose which of your products are eligible for out-of-app promotion.
Google’s ML decides the rest: Google Play’s machine learning models determine the optimal surfaces, timing, and audiences for displaying your selected products.
Broader reach, less manual control: The ML system can place your products across all out-of-app purchase flows that Google Play supports, potentially reaching more users than manually configured promotions would.

This means you lose some of the granular control that the featured products provided. You will no longer be able to set audience targeting, country targeting, or associate promotions with specific offers and events at the merchandising level. If you need country-level restrictions, you must configure them at the SKU level instead.

The trade-off is straightforward. You give up manual configuration in exchange for Google’s ML optimizing placement across a broader set of surfaces. For most developers, this should result in better performance because the ML models can test and iterate on placement strategies far faster than any manual configuration can.

For developers who have never configured any of these features, the new page is an opportunity. Previously, managing three separate configuration surfaces was enough friction to discourage many developers from engaging with out-of-app merchandising at all. A single page with a simpler interface lowers the barrier to entry. If you have products that could benefit from being promoted on Google Play surfaces, the new Merchandising and optimization page makes it easier to opt in.

The timeline: What happens and when

The migration follows a phased approach with a clear cutoff date. Here is what happens at each stage:

Date	What happens
Before March 16	Last chance to modify existing purchase flow recommendations and featured products configurations. Last chance to use the cart abandonment reminder opt out form for one time products.
March 16	Existing purchase flow recommendations and featured products pages become frozen. The cart abandonment reminder opt out form is disabled for one time products. No further changes can be made on these pages.
After March 16	Existing selections remain active according to the migration rules described below. Your configurations continue to function but cannot be modified.
New page launches	Google Play automatically migrates your existing selections to the new Merchandizing and optimization page. You can then modify your selections on the new page. The old pages for purchase flow recommendations and featured products are deprecated. The cart abandonment reminders opt out form for one time products is also deprecated.

The key takeaway is that March 16 is the hard deadline for any changes to your current setup. If you need to adjust your merchandising configurations, do it before that date.

Special considerations for featured products

Featured products have the most complex migration path because they support the most configuration options. Here is what happens to each aspect of your featured products configurations:

Configuration aspect	What happens after March 16
No end date set	The featured product remains in place and continues to be merchandized. No action needed.
End date after March 16	You have two options before March 16: make the product available indefinitely by removing the end date, or delete it if you do not want it merchandized past March 16.
Offers and events	Offers and events associated with featured products will no longer be supported. If you rely on these associations, plan accordingly before the cutoff.
Audience and country targeting	Audience and country targeting associated with existing featured products will not be supported. If you need to restrict country selection, you must configure that at the SKU level.
Licensed testers	Products that only target licensed testers will no longer be available for merchandizing. If you have products in a testing only configuration, they will be excluded from out of app promotion.
Performance reporting	Performance reporting and associated metrics remain visible on the featured products page until it is deprecated when the new Merchandizing and optimization page launches.

The most impactful change for developers who actively use featured products is the loss of audience and country targeting. If your merchandising strategy depends on showing different products to different regions, you need to rethink that approach. Moving country restrictions to the SKU level is the only remaining option.

Special considerations for purchase recommendations

Purchase recommendations have a simpler migration path because they offer fewer configuration options than featured products:

Active SKUs remain active: Any SKUs you have configured for purchase flow recommendations will continue to be eligible for out-of-app purchases after March 16.
Country targeting removed: Country targeting associated with your purchase recommendations will no longer be supported. Like featured products, you must handle country restrictions at the SKU level if needed.
Licensed testers excluded: Products that only target licensed testers will no longer be available for merchandising.
Performance reporting visible: Performance reporting and associated metrics remain on the purchase recommendations page until they are deprecated when the new page launches.

For most developers using purchase recommendations, the migration is straightforward. Your products continue to be recommended. You just lose the ability to fine-tune which countries see those recommendations.

Special considerations for cart abandonment reminders

Cart abandonment reminders have the simplest migration considerations, but there is one important detail to understand:

One-time products only in initial launch: The new Merchandising and optimization page will initially only include one-time products for cart abandonment functionality. Subscriptions are not part of the initial launch scope.
Subscription blocklist unchanged: If you have an existing blocklist for subscription cart abandonment reminders, it remains in place and is not affected by this migration.
Opt out mechanics: You can opt out of cart abandonment reminders for one-time products using the existing form until March 16. After that, you will need to wait until the Merchandising and optimization page launches to opt out. If you have already opted out, your opt-out remains in effect. If you want to stay opted in, no action is required.

What you should do before March 16

Here is a concrete checklist of actions to take before the cutoff:

Audit your featured products: Open the featured products page in Google Play Console and review all active configurations. Identify any that have end dates after March 16 and decide whether to make them indefinite or delete them.
Remove reliance on offers and events: If any of your featured products are associated with specific offers or events, note that these associations will stop being supported. Plan alternative promotion strategies for those products.
Move country restrictions to the SKU level: If you currently use country targeting on featured products or purchase recommendations, reconfigure those restrictions at the SKU level before March 16. This ensures your geographic targeting strategy survives the migration.
Review licensed tester configurations: If you have products configured only for licensed testers, understand that they will be excluded from merchandising. If you want these products to be promoted to real users, update the targeting before the cutoff.
Decide on cart abandonment opt out: If you want to opt out of cart abandonment reminders for one-time products, submit the opt-out form before March 16. After that date, you will need to wait for the new page to launch.
Save performance data: Export or screenshot any performance metrics from the featured products and purchase recommendations pages that you want to retain for historical analysis. These metrics will remain visible until the pages are deprecated, but it is good practice to save them now.
Communicate with your team: Make sure anyone on your team who manages Google Play Console configurations is aware of the March 16 deadline and the changes that are coming.

How out-of-app purchases connect to your billing stack

A common question when discussing out-of-app merchandising is how these purchases actually flow through your billing infrastructure. The good news is that out-of-app purchases initiated from Google Play surfaces go through the same Play Billing Library flow as any in-app purchase.

When a user taps on a recommended product, a featured product, or a cart abandonment reminder on a Google Play surface, the resulting purchase is processed through the standard Google Play Billing infrastructure. Your app receives the purchase through the same PurchasesUpdatedListener or queryPurchasesAsync calls that handle in-app purchases. The purchase token, product ID, and acknowledgment requirements are all identical. If your backend processes Real Time Developer Notifications (RTDN), you will receive the same notification types for out-of-app purchases as you do for in-app ones.

This means if you are using RevenueCat to manage your billing infrastructure, out-of-app purchases are processed automatically. RevenueCat’s SDK and backend handle purchase verification, entitlement granting, and acknowledgment for these transactions just like they do for purchases initiated within your app. There is no special SDK integration or code change needed to support purchases originating from out-of-app surfaces.

RevenueCat Charts can also track revenue from out-of-app surfaces alongside your in-app revenue. Since all purchases flow through the same billing pipeline, your existing analytics and reporting infrastructure captures these transactions without additional configuration. This is particularly useful after the migration, when you want to monitor whether the ML-driven approach is producing more or fewer out-of-app conversions compared to your previous manual configurations.

The important point is that the Merchandising and optimization page is a Console-side change. It affects how Google Play promotes your products to users, not how those purchases are processed once they happen. Your billing code, RevenueCat integration, and backend systems continue to work exactly as they do today.

Conclusion

In this article, you’ve explored Google Play’s upcoming consolidation of three separate merchandising features, purchase flow recommendations, featured products, and cart abandonment reminders, into a single ML-driven Merchandising and optimization page. The March 16 cutoff is the deadline for modifying any existing configurations, and understanding the migration rules for each feature ensures your products continue to be promoted effectively.

The shift from manual merchandising configuration to ML-driven optimization reflects a broader trend in how app stores manage product discovery. For most developers, the reduced manual control is offset by the potential for broader, algorithmically optimized reach across Google Play surfaces. The key is to prepare before the deadline by auditing your existing configurations, moving country restrictions to the SKU level, and making deliberate decisions about featured product end dates.

Whether you manage your billing with the Play Billing Library directly or use RevenueCat, the merchandising changes happen entirely on the Console side. Your billing code, purchase processing, and entitlement logic remain unchanged. Focus your effort on the Console configurations before March 16, and let Google’s ML handle the optimization from there.

How to personalize your paywalls with Custom Variables

Tue, 03 Mar 2026 19:55:08 GMT

Paywalls that feel personal convert better. With Custom Variables, you can now pass values from your app directly into your paywall, letting you customize the experience for each customer.

In this tutorial, I’ll walk you through setting up Custom Variables in a React Native app. We’ll take a simple tipping feature and personalize the paywall title with the customer’s name.

Prerequisites

Before getting started, make sure your app is running a compatible version of the RevenueCat SDK. Custom Variables require the following minimum package versions:

SDK	Mimimum version
purchases-ios	5.57.0
purchases-android	9.21.0
react-native-purchases	9.10.0
purchases-flutter	9.12.0

If you’re working with a platform other than React Native, check out the Custom Variables documentation for platform-specific instructions.

The example app

Here’s what we’re working with. I’ve built a simple app with a tipping feature that lets customers tip the developer if they enjoy the app. When the user taps the “Tip the developer” button, it presents a paywall configured in RevenueCat.

Right now, the paywall title is generic, showing only “Hey, You. You should buy me a pizza”. What I want to do is display the customer’s actual name in the paywall title to make it feel more personal.

Creating a Custom Variable in the Paywall Editor

To get started, open the Paywall Editor in your RevenueCat dashboard. In the left sidebar, select the Variables section. You’ll see a new “Create variable” button at the top.

Click it to define a new custom variable. I’ll name mine customerName, since that’s what we’ll be passing from the app.

You’re required to provide a default value. This is important because it ensures the paywall still looks good even if the variable isn’t set for some reason. In this case, I’ll use “You” as the fallback, so the title reads naturally either way.

Using the variable in your paywall

Now that the variable exists, we can reference it in the paywall content. Switch back to the Layers view, select the title text layer, and find the spot where you want to insert the variable. Replace the static word “You” with the new customerName variable using the “Add variable” button.

Once you’re happy with how it looks, publish the changes.

Passing the variable from your app

With the paywall side ready, let’s update the app code. The presentPaywall function now accepts a customVariables key, which takes an array of objects. Each object needs a key that matches the variable name you defined in the Paywall Editor, and a value wrapped in CustomVariableValue.string.

Here’s what the code looks like:

The key here is "customerName", which matches exactly what we defined in the editor. The value can be anything you pull from your app’s user data, authentication state, or wherever you store customer information.

The result

Save the changes and force a refresh so the app fetches the latest version of the paywall. Now when the customer taps “Tip the developer” and the paywall appears, you’ll see their name displayed right in the title.

That’s all it takes. A few lines of code in your app, a quick setup in the Paywall Editor, and your paywalls feel like they were built for each individual customer.

What’s next

Custom Variables open up a lot of possibilities beyond just names. Think about passing subscription status, usage stats, or any other value that might make your paywall more relevant and compelling.

For more details on Custom Variables and other RevenueCat features, check out the full documentation.

Meet the AI agent that creates paywalls, writes code, and tracks revenue in your Android Studio

Fri, 27 Feb 2026 00:13:11 GMT

Managing subscriptions, paywalls, and revenue metrics typically involves constant context switching between your IDE and the RevenueCat dashboard. You write code in Android Studio, switch to a browser tab to check MRR, open another tab to configure offerings, and switch again to design a paywall. Each context switch breaks your flow and fragments your attention. The RevenueCat IntelliJ Plugin eliminates this friction by bringing your entire subscription business directly into your development environment.

But this plugin is more than a dashboard mirror. It includes a full-featured AI agent that understands your RevenueCat project and can take action on your behalf. You can ask it to create offerings, generate paywalls with AI, analyze your revenue charts, debug integration issues, and even edit your source code, all through natural language prompts without leaving your IDE.

In this article, you’ll explore the key features of the RevenueCat IntelliJ Plugin, including how OAuth sign in replaces manual API key configuration, how the dashboard panel surfaces real time metrics without browser context switching, how the AI agent generates paywalls and manages your entire project through conversation, and how AI powered code editing lets the agent modify your project files with full diff preview and undo support.

The plugin uses OAuth 2.0 authorization with PKCE flow, replacing the older API key configuration. When you open the RevenueCat tool window for the first time, you’ll see a welcome screen with a “Sign in with RevenueCat” button.

Clicking the sign-in button opens your browser for authorization. The plugin starts a local callback server, handles the token exchange automatically, and stores your credentials securely. Once authorized, the plugin fetches your projects and lets you select which one to work with.

The OAuth flow requests scoped permissions for project configuration, charts and metrics, and customer information. Tokens refresh automatically when they expire, so you stay authenticated across sessions without manual intervention.

AI Agent code editing: Agent-powered file modifications

Beyond querying data, the AI agent can read, search, and edit your project’s source files directly. This enables workflows like “Add the RevenueCat SDK initialization to my Application class” or “Update my paywall screen to use the new offering ID.”

Staged edit system

When the agent proposes code changes, they appear as staged edits with inline diff preview. You can review each change before applying it:

Accept individual edits: Apply specific changes while rejecting others
Accept all: Apply all proposed changes at once
Reject: Discard proposed changes without modifying your files

AI paywall generation

The most powerful feature of the AI agent is end-to-end paywall generation. You describe what you want, and the agent handles everything: creating the offering, setting up packages, attaching products, and generating a fully designed paywall with AI, complete with copy, images, styling, and template selection.

he agent monitors the generation job in the background. When the paywall is ready, a notification appears with a direct link to the paywall builder where you can review and publish the design. The monitoring works reliably even when OAuth tokens expire, using your API key as an independent fallback.

You can generate multiple paywalls in sequence. The agent tracks each job independently, so you can ask for a “premium” paywall, then a “freemium” paywall, and the monitoring handles both without conflicts.

Managing your project through conversation

The agent supports full create, read, update, and delete operations across your RevenueCat resources. Here are some examples of what you can ask:

Creating resources:

"Create a new offering called Premium with a monthly package at $9.99 and an annual package at $79.99"

The agent creates the offering, creates both packages, and attaches the appropriate products. If any of these resources already exist, the agent detects the duplicates and reuses them instead of failing.

"Set up an entitlement called pro_access and attach it to all my subscription products"

The agent creates the entitlement, lists your existing products, and attaches each one.

Querying your project:

"Show me all my offerings and which ones have paywalls"

The agent fetches your offerings and paywall data, presenting a clear summary of what’s configured and what’s missing.

"What products do I have configured? Which ones aren't attached to any package?"

The agent cross references your products, packages, and offerings to find orphaned resources.

Paywall management:

"Generate an AI paywall for my premium offering. The app is a fitness tracker called FitCat targeting health conscious millennials."

The agent uses your app context to generate a paywall with relevant copy, styling, and design that matches your brand.

"Duplicate my current paywall and name it Holiday Promo"

The agent duplicates the paywall through the API and provides the builder link for customization.

Analyzing your revenue with Charts API

The agent has access to 21 chart types including revenue, MRR, ARR, churn rate, trial conversions, active subscriptions, and retention cohorts. You can ask analytical questions and get data driven answers:

"What's my MRR trend over the last 6 months?"

"Show me my trial to paid conversion rate broken down by weekly"

"Compare my revenue this month vs last month"

"What's my churn rate for annual subscribers?"

The agent queries the Charts API with the appropriate parameters, including date ranges, resolutions, and segment filters, and presents the results in a readable format.

Debugging and integration help

The agent isn’t limited to CRUD operations. It understands RevenueCat’s SDK and can help you debug integration issues:

"I'm getting a 'Configuration not found' error when presenting my paywall. What's wrong?"

The agent checks your project configuration, verifies that your offerings have packages with products attached, and identifies the root cause.

"Walk me through setting up RevenueCat in my Kotlin Multiplatform project"

The agent has access to Codelabs content and can provide step-by-step guidance tailored to your platform.

"What's the difference between offering lookup keys and offering IDs? Which one should I use in my code?"

The agent explains concepts with context from your actual project configuration, not just generic documentation.

Model selection

The AI agent supports multiple models that you can switch between using the gear icon in the input bar. Available models include GPT-4.1, GPT-4.1 Mini, Claude Sonnet 4, and Claude Haiku 4.5, letting you balance capability and response speed based on your needs.

Dashboard panel: Metrics without context switching

The dashboard panel gives you a live view of your RevenueCat project without opening a browser. It organizes your subscription data into collapsible sections that load when you open the tool window.

Revenue overview

The top section shows your key metrics at a glance: active subscribers, active trials, MRR, and revenue. These numbers pull directly from the RevenueCat API, so you’re always looking at current data.

Milestones

Below the metrics, a milestones section tracks your subscription business achievements. These are the same milestones you’d see on the RevenueCat dashboard: first subscriber, revenue thresholds, and trial milestones, all surfaced directly in your IDE.

Configured offerings

The offerings section lists all your offerings with their packages and attached products. You can expand each offering to see its package structure, which products are attached, and whether it has a paywall configured. Offerings with paywalls show a direct link to the paywall builder.

Paywalls section

A dedicated paywalls section shows all your paywalls with colored status badges: Published (green), Draft (yellow), and Has Unpublished Changes (orange). Each paywall has context-aware action buttons based on its status: Edit, Publish, Unpublish, Discard, Duplicate, and Delete. The Edit button opens the paywall builder in your browser. Lifecycle actions call the API directly and auto-refresh the panel.

Conclusion

The RevenueCat IntelliJ Plugin transforms your IDE into a complete subscription management environment. OAuth sign-in eliminates manual API key configuration. The dashboard panel surfaces metrics, milestones, offerings, and paywalls without browser context switching. The AI agent goes far beyond a simple chatbot. It creates offerings, generates paywalls with AI, analyzes your revenue data through the Charts API, debugs integration issues, and edits your source code with safe, reviewable changes.

The AI paywall generation alone saves significant time. Instead of navigating through the dashboard to create an offering, set up packages, attach products, and design a paywall manually, you describe what you want in one sentence, and the agent handles every step. The result is a fully designed paywall ready for review in the builder.

Whether you’re checking your MRR between code reviews, generating a paywall for a new offering, analyzing churn trends, or asking the agent to scaffold your SDK integration, the plugin keeps you in your development flow. The goal is simple: spend less time switching tabs and more time building your subscription business. You can install the RevenueCat IntelliJ Plugin from the JetBrains Marketplace: RevenueCat Dashboard.

Announcing the Shipyard: Creator Contest 2026 winners

Thu, 26 Feb 2026 15:01:09 GMT

What happens when real influencers hand you a brief and say, “Build the app my audience actually needs“? Shipyard: Creator Contest set out to answer that question. In just four weeks, more than 900 builders competed to design, launch, and monetize an MVP for seven creators ready for long-term app partnerships. Now, we’re proud to introduce the seven winners.

Eitan Bernath

In Eitan Bernath’s category, the task was to help people actually cook what they’ve been meaning to make. Think of tools that turn inspiration into action: an app that can generate a grocery list from a recipe video/link, organize what you want to cook, and make it simple to get started.

Winning app: Preplo – turning cooking videos into actionable recipes

Preplo turns cooking inspiration into something you can actually make. Drop in a YouTube, TikTok, or Instagram link and it instantly generates a structured recipe with quantities, step-by-step instructions (with timestamps), estimated costs, and nutrition info. It makes the jump from “I saved this” to “it’s on the table” much easier.

You can also tweak recipes on the fly — make it spicier, vegan, or low-carb, and everything updates accordingly. Built with Expo React Native and a Next.js backend, Preplo also caches processed videos so the same clip is never analyzed twice.

Devpost link

Gabby Beckford

In Gabby Beckford’s brief the goal was to build an upbeat, motivating app that turns goals into daily micro-actions, with challenges, streaks/wins, tracking, and gamified moments that make progress feel fun. Designed for ambitious women who want to embark on dream trips and life upgrades, but often get held back by the mundane day-to-day, or stuck between inspiration and action.

Winning app: Bloom – turning big dreams into daily wins

Bloom is a gamified personal growth app for women who need help taking the steps to turn dreams into daily life. Instead of another to-do list, Bloom connects goals, money confidence, mindset, and travel into one motivating system.

At the center is the Digital Garden: daily habits fuel visible growth, so progress feels real. Users can set ‘Dreams’, play bite-sized financial mini-games, journal with AI guidance, and track travels on an interactive map. Built with Flutter and powered by Supabase and Mapbox, Bloom focuses on making self-development feel encouraging rather than overwhelming.

Devpost link

Quin Gable

Dating and making friends on the road is hard when you’re always moving. Digital nomad Quin Gable wanted a van-life app with nomadic dating, activity-based friend finding, and even a paid ‘builder help’ section for van projects. To keep the community protected, the app needed to be invite-only or verified access to ensure the app remained safe and connection was intentional.

Winning app: WanderBase – dating and community for life on the road

WanderBase is a dating and community app built specifically for van-lifers and nomads. Instead of endless swiping, users explore hand-illustrated, customizable van avatars that reflect your lifestyle and travel vibe; a playful twist that feels true to life on the road.

It’s invite-only, with route-based matching, mutual chat unlocks, and a help-finding forum for van projects. Built with React Native and Firebase, with server-side matching and strict security rules, WanderBase guarantees trust, and prioritizes safety and fun in equal measure.

Devpost link

Sam Beckman

Sam lives by reminders, but switching between Android and iOS means rebuilding his entire system from scratch. His brief was to build a beautiful, fully-functional reminders app on both iOS + Android. It needed custom snoozes from notifications, powerful recurring rules, and true sync, so dismissing once clears everywhere.

Winning app: Remy Reminders – cross-platform reminders, finally in sync

Remy solves a real frustration: switching between iOS and Android without rebuilding your reminder system from scratch. It delivers a polished reminders app regardless of your platform choice, offers simple but effective rule-making, built-in notification pauses, and more.

Behind the scenes is a custom offline-first sync engine and a notification system that talks directly to APNs and FCM to keep everything aligned. Built with React Native (Expo), and Convex, Remy focuses on making reminders reliable, no matter what device you’re using.

Devpost link

Simon from Better Creating

Simon’s audience loves productivity, great design, and building systems for self improvement. Coaching is a key part of this, so Simon wanted to make the growth and self-assurance that comes from coaching accessible. This meant creating a clean, minimal mobile app where users can browse, create, and share AI coaches, add personal context/values, and start chatting immediately.

Winning app: Editor – decide with clarity

Editor flips the typical coaching or AI chat experience on its head. Instead of encouraging endless conversation, it’s designed to help builders and creators reach decisions quickly and deliberately. Going beyond a coaching app, users choose structured thinking modes like prioritizing, reviewing ideas, or weighing trade-offs.

Each session is built to get you to a decision quickly, then end. Outcomes can be turned into decision briefs or roadmaps and exported to Notion. Built as a native SwiftUI app, Editor stays intentionally minimal and focused.

Devpost link

Rebecca Louise

Rebecca hears it constantly: mums are short on time, want financial independence, and need practical help. Her brief was to build an app that offers everyday money-saving guidance (shopping swaps, batch cooking, cost comparisons, home reno savings) plus an approachable path into investing basics, so users can grow what they have without overwhelm.

Winning app: Sunny Money – Financial confidence for busy mums

Sunny Money helps busy mums build financial confidence in just a few minutes a day. It combines everyday money-saving guidance with simple introductions to saving and investing.

Bite-sized lessons, practical calculators, daily challenges, and an AI assistant make financial progress feel manageable. Built with React Native and Expo, Sunny Money respects mums’ time while still delivering real, useful tools.

Devpost link

Josh from VisualFaktory

Investors juggle stocks, gold, funds, fixed income, real estate, and more across multiple platforms. It’s messy to track and hard to understand at a glance. Josh wanted a single app where users can log everything, get real-time price updates where possible, set amortization/reminder alerts for non-listed products, and unlock premium risk + diversification analysis (like country/sector exposure).

Winning app: Folio – see your entire portfolio at a glance

Folio brings scattered investments into one clean iOS dashboard. Stocks, ETFs, crypto, property, savings — everything in one place so you can see your full net worth and understand your exposure on one screen.

It includes live pricing, performance breakdowns, widgets, alerts, and an AI assistant that understands your actual holdings and can help rebalance or adjust positions. Built with React Native and Supabase, Folio keeps portfolio tracking straightforward and actionable.

Devpost link

That’s a wrap

Across seven very different briefs, the winning apps had something in common: focus.

They didn’t try to do everything. They picked a specific audience, a clear problem, and built around it. The van-life app prioritized trust and safety. The reminders app obsessed over cross-platform sync. The finance apps respected their users’ time. The AI coach constrained itself on simplicity. Each team made deliberate trade-offs instead of chasing features.

While this is the end, we hope all of you continue building your apps, and most importantly, work on getting them out for people to download.

How did you find Shipyard? Did you have fun? Were there things you wish we had done differently?

We’d love to hear your thoughts. Let us know on Twitter or LinkedIn, and keep an eye out for a survey we’ll be sending to all participants to gather your feedback.

Cross-platform subscription state: sharing entitlements between Android and iOS

Tue, 24 Feb 2026 02:49:36 GMT

Subscription apps rarely live on a single platform. A user might subscribe on their iPhone during their morning commute, then open your Android tablet app at home expecting full access. This expectation is intuitive from the user’s perspective, they paid for a subscription, so it should work everywhere. But from a developer’s perspective, making this work is one of the hardest problems in subscription infrastructure. Google Play Billing and Apple’s StoreKit are entirely separate systems with different receipt formats, different verification mechanisms, different notification systems, and fundamentally different assumptions about how purchases are represented. There is no built in interoperability between them.

In this article, you’ll explore why cross platform subscription state is so difficult to implement, examine the fundamental incompatibilities between Google Play Billing and StoreKit, walk through what it takes to build cross platform entitlement sync from scratch, and see how RevenueCat’s identity system provides a natural solution that dramatically reduces the engineering effort required, especially for small teams and indie developers.

The fundamental problem: One user, two ecosystems

Consider a fitness app with a “Premium” subscription. A user subscribes through the App Store on their iPhone. A week later, they buy an Android tablet and download your app. They log in with the same account and expect to see their premium features. What actually happens?

Without cross platform infrastructure, the Android app has no idea this user has an active subscription. Google Play Billing only knows about purchases made through Google Play. The App Store receipt sitting on Apple’s servers is invisible to the Android app. The user sees a paywall asking them to subscribe again, even though they are already paying.

This is not a bug. It is the expected behavior. Each billing system operates in isolation, and bridging them requires significant infrastructure that neither platform provides.

Two billing systems, zero interoperability

To understand why cross platform sync is so difficult, you need to understand how differently Google and Apple represent purchases. These are not minor API differences. They are fundamentally different architectures.

Receipt formats and verification

Apple and Google use entirely different mechanisms to prove that a purchase happened.

Aspect	Google Play Billing	Apple StoreKit
Purchase proof	Purchase token (opaque string)	Signed receipt (JWS in StoreKit 2)
Verification endpoint	`purchases.subscriptionsv2.get` REST API	App Store Server API (`/inApps/v1/subscriptions`)
Authentication	Google service account with JSON key	JWT signed with App Store Connect private key
Response format	`SubscriptionPurchaseV2` JSON object	`JWSTransactionDecodedPayload` (signed JSON)
Subscription ID format	`productId:basePlanId`	Simple `productId` string
Renewal tracking	`expiryTime` field on subscription resource	`expiresDate` in transaction info

Google Play uses a purchase token model. When a user subscribes, your app receives a purchase token. You send this token to the Google Play Developer API, which returns the current subscription state. The token is an opaque string with no inherent meaning.

Apple uses a signed transaction model. In StoreKit 2, purchase information is delivered as JSON Web Signatures (JWS) that your server can verify using Apple’s public key. Each transaction is a self contained, cryptographically signed record.

These are not just different APIs wrapping the same concept. They represent different philosophies about where trust lives. Google says “ask our server, we’ll tell you the state.” Apple says “here’s a cryptographically signed proof, verify it yourself.”

Real-time notifications

Both platforms offer server-to-server notifications for subscription events, but the notification systems differ substantially.

Aspect	Google Play RTDN	Apple Server Notifications V2
Delivery mechanism	Google Cloud Pub/Sub	HTTPS POST to your endpoint
Notification format	`DeveloperNotification` with type enum	`signedPayload` (JWS) with `notificationType`
Event types	`SUBSCRIPTION_RENEWED`, `SUBSCRIPTION_CANCELED`, etc.	`DID_RENEW`, `DID_CHANGE_RENEWAL_STATUS`, etc.
User identification	`purchaseToken` in notification	`originalTransactionId` in signed payload
Setup	Configure Pub/Sub topic in Play Console	Register URL in App Store Connect

Google delivers notifications through Cloud Pub/Sub, requiring you to set up a Pub/Sub subscription and a processing service. Apple sends HTTPS POST requests directly to a URL you configure. The event names differ, the payload structures differ, and the information included in each notification type differs.

This means your backend needs two completely separate notification processing pipelines with different authentication, different parsing logic, and different state machine interpretations.

Product configuration

Even the way you define subscription products differs between platforms.

Google Play introduced base plans and offers in 2022, creating a hierarchical product model: a subscription contains one or more base plans, each of which can have multiple offers with different pricing phases. A single subscription product ID can have monthly and annual base plans, introductory offers, and promotional pricing, all configured through the Play Console.

Apple’s product model is flatter. Each product ID in App Store Connect represents a single subscription with a single duration. To offer both monthly and annual options, you create two separate product IDs and group them in a subscription group. Introductory offers and promotional offers are configured per product, not as nested objects.

This structural difference means there is no one to one mapping between a Google Play subscription product and an Apple subscription product. Your backend must maintain a mapping layer that translates platform specific product identifiers into a unified entitlement concept.

Building cross platform sync yourself

If you decide to build cross platform subscription sync without a third party service, here is what the architecture looks like. Understanding this effort is important even if you ultimately choose a managed solution, because it reveals why the problem is genuinely hard.

Step 1: Unified user identity

The first requirement is a user identity system that works across platforms. Each platform has its own notion of a user, but neither knows about the other. You need a server side user account that both platforms can associate purchases with.

For iOS, there will not be much difference from the Android side:

Both clients send purchase data to your backend, tagged with the same userId. Your backend must verify each purchase against the correct platform’s API and record the entitlement against the unified user account.

Step 2: Dual receipt verification

Your backend needs to verify purchases from both platforms, which means integrating with two completely different verification APIs:

Each verification path has its own authentication setup, error handling, and response parsing. Google requires a service account credential. Apple requires a JWT signed with a private key from App Store Connect. The response formats share no common structure.

Step 3: Unified entitlement storage

Your backend needs a data model that maps platform-specific products to platform-agnostic entitlements:

When either client queries for entitlements, your backend checks whether the user has any active entitlement, regardless of which platform it originated from:

Step 4: Dual notification processing

To keep entitlements in sync in real time, your backend must process notifications from both platforms simultaneously:

Each notification handler has different event names, different payload structures, and different state machine semantics. Grace periods work differently. Refund flows work differently. Even the concept of “cancellation” has subtle differences between the two platforms.

The true scope of effort

You need an infrastructure, building a cross-platform subscription sync involves. Even both Google and Apple regularly update their billing systems. Google introduced base plans and offers in 2022, requiring significant backend changes. Apple launched StoreKit 2 with an entirely new transaction model. Each major update requires engineering time to adapt your infrastructure.

For a large team with dedicated backend engineers, this might be manageable. For a small team or an indie developer trying to ship a subscription app on both platforms, this represents months of work that has nothing to do with the core product.

RevenueCat’s identity system: The natural solution

RevenueCat solves the cross platform problem at its foundation through a unified identity and entitlement system. Rather than requiring you to build the infrastructure described above, RevenueCat provides it as a service. The key design decision that makes this work is the app user ID abstraction.

How the identity system works

When you configure the RevenueCat SDK, you can either provide your own user ID or let RevenueCat generate an anonymous one:

For iOS will be like so:

The same appUserID on both platforms creates a single subscriber record in RevenueCat’s backend. When the user subscribes on either platform, RevenueCat verifies the receipt, records the entitlement, and associates it with this user ID. When the other platform’s SDK queries for customer info, it receives the complete entitlement state, including subscriptions from the other platform.

Anonymous to identified user flow

RevenueCat also handles the common scenario where users start anonymously and later create an account. When a user first opens your app, RevenueCat generates an anonymous ID in the format $RCAnonymousID:<uuid>. If the user subscribes before creating an account, the subscription is associated with this anonymous ID.

When the user later creates an account and logs in, RevenueCat’s logIn method transfers all purchases from the anonymous user to the identified user:

The created boolean indicates whether this was a new user or an existing one. If it is an existing user, RevenueCat merges the purchase histories. This is critical for cross platform scenarios: a user who first subscribed on iOS and later installs the Android app gets their entitlements transferred automatically when they log in with the same user ID.

CustomerInfo: One object, all platforms

The CustomerInfo object is RevenueCat’s answer to the cross platform entitlement problem. It aggregates subscription state from every platform into a single, easy to query object:

The store property on each entitlement tells you which platform the subscription originated from. But for granting access, you do not need to check it. The isActive property is the only thing that matters, and it works across all platforms.

This is the key insight: RevenueCat transforms a cross platform infrastructure problem into a single property check. Your Android app does not need to know how to verify Apple receipts. Your iOS app does not need to know about Google Play purchase tokens. RevenueCat’s backend handles all of that and presents a unified view through CustomerInfo.

What happens behind the scenes

When a user subscribes on iOS and later opens the Android app, the following sequence occurs:

The iOS SDK posts the App Store receipt to RevenueCat’s backend.
RevenueCat verifies the receipt with Apple’s servers and records the entitlement against the user’s app user ID.
RevenueCat registers for Apple Server Notifications to track renewals, cancellations, and billing issues.
When the Android app launches and calls getCustomerInfo, the SDK sends the same app user ID to RevenueCat’s backend.
RevenueCat returns the complete entitlement state, including the iOS subscription.
The Android app sees isActive == true on the premium entitlement and grants access.

All renewal events, grace periods, cancellations, and expirations are tracked server side by RevenueCat. Both platforms always see the current subscription state without any platform specific code.

Handling subscription management

One practical detail that cross platform subscriptions introduce is management URL routing. A user who subscribed on iOS needs to manage their subscription through the App Store, not Google Play. RevenueCat handles this through the managementURL property:

This prevents the confusing scenario where a user tries to cancel their subscription through Google Play but cannot find it because the subscription lives on Apple’s side.

The impact on development velocity

The difference in implementation effort between building cross platform sync yourself and using RevenueCat is substantial. Let’s compare the two approaches for a team shipping a subscription app on both Android and iOS.

Without RevenueCat

You need to build and maintain: a backend server with two receipt verification integrations, two notification processing pipelines, a user identity system, an entitlement database, and client side code on both platforms to communicate with your backend. This is 10 to 18 weeks of initial development, plus ongoing maintenance as both platforms evolve.

With RevenueCat

Your implementation reduces to: configure the SDK with an app user ID on each platform, check CustomerInfo for active entitlements, and display paywalls. The backend infrastructure is handled entirely by RevenueCat.

This is the complete code needed to support cross platform subscriptions on Android. The equivalent iOS code is similarly concise. No backend server, no receipt verification, no notification processing, no entitlement database. RevenueCat manages all of it.

For indie developers and small teams, this difference is not just about saving time. It is about feasibility. Building cross platform subscription infrastructure from scratch requires backend engineering expertise, server hosting, monitoring, and ongoing maintenance. Many small teams simply cannot afford this investment, which means they either skip cross platform support entirely or build something fragile that breaks when platform APIs change. RevenueCat makes cross platform subscriptions accessible to teams of any size, letting developers focus their limited time on the features that make their app unique.

Conclusion

In this article, you’ve explored why cross platform subscription state is one of the hardest problems in mobile monetization. Google Play Billing and Apple’s StoreKit are fundamentally different systems with incompatible receipt formats, different verification APIs, different notification mechanisms, and different product structures. Bridging them requires a unified identity system, dual receipt verification, platform agnostic entitlement storage, and two parallel notification processing pipelines.

Building this infrastructure from scratch takes months and requires continuous maintenance as both platforms evolve. For large teams, it is a significant but manageable investment. For small teams and indie developers, it can consume more engineering time than the core product itself.

RevenueCat’s identity and entitlement system provides a natural solution by abstracting away the platform differences behind a single CustomerInfo object. A shared app user ID across platforms, combined with RevenueCat’s server side receipt verification and notification processing, transforms a months long infrastructure project into a few lines of SDK configuration. Whether a subscription originated from the App Store, Google Play, Amazon, or the web, your app simply checks isActive and grants access.

For teams building subscription apps that serve users across platforms, understanding the scope of this problem helps you make informed build versus buy decisions. The time saved by using a managed solution can be redirected toward improving your app, optimizing your paywall, and building the features that actually differentiate your product.

Building a hardware-enabled subscription business

Wed, 18 Feb 2026 13:39:21 GMT

Hardware alone doesn’t build enterprise value. And layering a subscription on top of hardware only works if the product becomes part of daily life.

In this episode of Sub Club, Skylight’s CEO and CPO share how they built a profitable hardware business with strong subscription attach — and the hard lessons they learned about daily usage, emotional pricing, product readiness, and retail distribution.

Here are five takeaways for anyone building a hardware-enabled subscription business.

Hardware-enabled subscriptions need daily usage to work

A hardware device can justify a subscription — but only if it’s used daily.

If a device sits idle, recurring revenue quickly feels optional. Customers start questioning what they’re paying for. But when a product becomes embedded in daily routines — organizing schedules, surfacing tasks, anchoring family communication — the subscription feels like a natural extension of its value.

Daily attention creates subscription leverage.

For Skylight, the turning point came when the Calendar product became the “heartbeat of the home.” Once families relied on it every day, the subscription became less about upselling features and more about unlocking deeper utility.

Without habitual usage, subscriptions struggle. With it, they compound.

Stop optimizing when you should be building

A/B testing and funnel optimization can drive incremental gains. But sometimes the biggest growth lever isn’t conversion — it’s product.

With limited resources, Skylight had to prioritize carefully. Instead of spreading effort across endless micro-experiments, they focused on building genuinely valuable features that strengthened the overall experience.

Optimization matters. But step-function growth often comes from shipping something that makes the product meaningfully better.

When resources are constrained, prioritization becomes strategy.

Price based on customer emotion, not just data

When Skylight revisited its subscription pricing, testing showed $99/year would maximize revenue.

On paper, it was the ARPU winner.

But qualitative research told a different story. While $79 felt fair, $99 approached what the team described as “disgust territory.” That emotional reaction mattered.

For a company focused on long-term brand equity, short-term revenue optimization wasn’t worth risking customer resentment. They chose $79 — prioritizing goodwill and trust over squeezing every dollar.

Pricing isn’t just math. It’s emotional positioning.

The spreadsheet can tell you what maximizes revenue. Only customer conversations tell you what preserves loyalty.

Build a great product before scaling marketing

Marketing can’t fix a weak product.

In 2021–22, Skylight tried to scale its Calendar product aggressively. Paid acquisition ramped up. Growth stalled. The numbers didn’t work.

The problem wasn’t the ads — it was the product.

Until the team pushed the experience to a 40+ Net Promoter Score, marketing dollars produced false negatives and wasted spend. Once the product truly resonated, scaling became viable.

If product-market fit isn’t solid, scaling marketing only amplifies friction.

Get the product right first. Then turn on growth.

Retail partnerships are the ultimate influencer

In hardware, distribution is influence.

Retail partnerships with companies like Costco and Best Buy provide a stamp of quality that paid ads can’t replicate. Being on trusted shelves signals credibility to customers at scale.

While direct-to-consumer channels often drive higher subscription attach rates, multi-channel distribution expands reach and strengthens brand legitimacy.

Hardware can be copied. Distribution is harder to replicate.

For Skylight, retail wasn’t just a sales channel — it was a growth engine and a positioning advantage.

Balancing growth, profit, and long-term trust

Across all five lessons, a deeper theme emerges: growth and profit often pull in different directions.

Making subscriptions frictionless can reduce margin.
Raising prices can increase ARPU but hurt long-term trust.
Cutting hardware prices could accelerate growth but compress profitability.
Over-optimizing can distract from building durable value.

Every decision involves trade-offs.

Skylight’s approach shows that scaling a hardware-enabled subscription business isn’t about maximizing every metric at once. It’s about choosing which levers matter most — and when.

Hardware-enabled subscriptions aren’t about layering recurring revenue onto a device. They’re about earning daily relevance, pricing with emotional intelligence, and building a product strong enough to deserve scale.

🎧 Listen to the full episode of Sub Club to hear the complete conversation and the experiments behind these lessons.

Building Helm: turning App Store pain into a product developers love

Wed, 11 Feb 2026 13:53:22 GMT

If you’ve shipped more than one iOS app, you already know the feeling: App Store Connect works — but only barely. Releases are slow. Metadata updates are clunky. Translations are painful. And every launch feels harder than it needs to be.

That frustration is exactly where Helm came from.

In this episode of Launched, host Charlie Chapman sits down with Hidde van de Ploeg and Pol Piella, the co-founders of Helm, to unpack how a deeply personal pain point turned into a tool indie developers now recommend by name.

This isn’t a story about chasing a market. It’s a story about improving an experience that was lacking.

Build for the pain, not the platform

Helm wasn’t born out of market analysis or trend-chasing. It came from Hidde’s repeated frustration shipping his own apps. App Store Connect wasn’t broken enough to replace — but it was broken enough to slow him down every single time.

Instead of brainstorming abstract opportunities, Hidde and Pol focused on the workflows that consistently caused friction in their own day-to-day work. By starting with problems they personally experienced, they ended up building something instantly useful to the exact audience they belong to: indie app developers.

That closeness to the problem shaped everything — from what Helm does to what it very intentionally does not do.

Focus beats feature parity

Helm doesn’t try to replicate App Store Connect. It rebuilds only the parts developers actively dread — and makes them effortless.

Rather than matching Apple feature-for-feature, Hidde and Pol obsessed over friction points like fast TestFlight access, AI-powered translations, and smoother release workflows. The goal was never completeness. It was relief.

By doing less, but doing it brilliantly, Helm turns a clunky chore into something developers actually enjoy using. The product succeeds not by breadth, but by precision.

Delight is the best growth strategy

Helm didn’t grow through paid ads, SEO funnels, or launch gimmicks. It grew because developers felt seen.

As Helm spread, a pattern emerged on social media: when someone complained about App Store Connect, another developer would often jump in to recommend Helm. That kind of advocacy only happens when a product genuinely removes pain for the right people.

Helm’s growth is a reminder that for indie tools, delight can be a far more powerful growth engine than distribution tactics.

Marketing is about memory, not metrics

Some of Helm’s most talked-about moments weren’t designed to convert at all.

Sponsoring a small amateur football team named Swift wasn’t about customer acquisition. It was about building brand lore. Playful initiatives like Helm Passport followed the same philosophy — they were meant to be fun, human, and memorable.

In a world of perfectly optimized funnels, Helm stands out by embracing personality. That personality sticks with people long after they forget feature lists.

Mobile is a chance to surprise

When Helm expanded to iOS, the team didn’t simply shrink the desktop experience to fit a smaller screen. They leaned into what mobile does best.

Features like Helm Passport, built with App Clips, introduced a playful, real-world interaction that sparked conversation and sharing. Mobile wasn’t treated as a secondary surface, but as an opportunity to rethink how the product could show up in people’s lives.

Great mobile experiences don’t just adapt existing products. They reimagine them.

Shared ownership beats rigid roles

Although Hidde and Pol come from different backgrounds — design and engineering — they don’t operate in silos. Both founders touch the whole product, jump in wherever needed, and stay deeply familiar with the entire codebase.

That shared ownership keeps Helm fast, resilient, and aligned. For small teams, overlapping responsibility often matters more than clearly defined roles.

A product built from real frustration

Helm’s story is a reminder of why Launched exists in the first place.

You don’t need a grand vision to start something meaningful. Sometimes, you just need a problem that won’t leave you alone — and the willingness to fix it properly.

🎧 Listen to the full episode of Launched to hear Hidde van de Ploeg and Pol Piella share how they turned everyday frustration into one of the most loved indie tools in the iOS ecosystem — and where Helm is headed next.

How kotlinx.serialization generates code: a compiler plugin deep dive

Wed, 11 Feb 2026 03:56:08 GMT

Kotlinx.serialization has become the standard serialization library for Kotlin, offering compile time code generation, multiplatform support, and format agnostic design. Most developers know the surface level usage: annotate a class with @Serializable, and the library handles the rest. But the deeper question remains: how does the compiler plugin actually generate serializers? What happens between your @Serializable annotation and the working KSerializer<T> implementation?

In this article, you’ll dive deep into the internal mechanisms of the kotlinx.serialization compiler plugin, exploring how the two pass IR generation pipeline works, how the plugin generates the $serializer nested class with its descriptor, serialize, and deserialize methods, and the clever optimizations like golden mask validation that make deserialization both safe and performant. Also, you’ll explore with the real use cases of kotlinx.serialization from the RevenueCat SDK.

The fundamental problem: Reflection is expensive and platform dependent

Consider a simple data class that you want to serialize to JSON:

Without code generation, serialization libraries must use reflection to discover properties, their types, and their values at runtime. This approach has significant drawbacks:

The problems with this approach are substantial. First, reflection is slow. Discovering properties, checking accessibility, and invoking getters at runtime adds overhead to every serialization operation. Second, reflection is platform dependent. Kotlin/Native and Kotlin/JS have limited or different reflection capabilities than the JVM. Third, there is no compile time safety. Type mismatches and missing properties are only discovered at runtime.

The kotlinx.serialization plugin solves these problems by generating serialization code at compile time. The generated code knows exactly which properties exist, their types, and how to read and write them, with no reflection required.

The compiler plugin architecture

The kotlinx.serialization compiler plugin operates as an extension to the Kotlin compiler, hooking into multiple stages of the compilation pipeline. The plugin is organized into several components that work together:

Frontend (K1 or K2): Detects @Serializable annotations and generates synthetic declarations (the $serializer class, companion methods).
IR Generation: Transforms the intermediate representation in two passes. Pass 1 creates function stubs, Pass 2 generates method bodies.
Backend: Emits platform specific code (JVM bytecode, JavaScript, or Native binaries).

The plugin registers itself through a CompilerPluginRegistrar that hooks into these extension points. The critical registration looks conceptually like this:

The key observation here is that the plugin operates at multiple levels. It first generates synthetic declarations during the resolve phase, making the compiler aware of generated classes and methods. Then it generates the actual implementation bodies during the IR lowering phase.

Two pass IR generation: Stubs before bodies

One of the most interesting aspects of the kotlinx.serialization plugin is its two pass IR generation strategy. Understanding why this is necessary requires understanding how generated code references itself.

Consider what the plugin needs to generate for a serializable class:

The generated serialize() method might call a helper method like write$Self(). The deserialize() method needs to call the class constructor. These methods reference each other and reference other generated elements. If the plugin tried to generate everything in a single pass, it would encounter undefined references.

The solution is a two pass approach:

In the first pass, the plugin creates function declarations with empty bodies. This establishes all the symbols that generated code might reference. In the second pass, the plugin fills in the actual implementation bodies, now able to reference any symbol created in the first pass.

This is elegant. The two pass strategy mirrors how compilers handle forward declarations in languages like C, but applied to code generation within a single compilation unit.

The generated serializer structure

When you annotate a class with @Serializable, the plugin generates a nested class named $serializer that implements GeneratedSerializer<T>. Let’s trace through what gets generated for a simple class:

The plugin generates a structure that conceptually looks like this:

Notice the structure. The $serializer class is an object (singleton) that holds the immutable descriptor and implements the serialization logic. The companion object provides a convenient serializer() accessor.

Descriptor generation: Metadata for format agnostic serialization

The SerialDescriptor is a critical piece of the generated code. It describes the structure of the serializable class in a format independent way, enabling different serialization formats (JSON, Protobuf, CBOR) to use the same serializer implementation.

The plugin generates descriptor initialization code that builds the complete metadata:

The descriptor includes the serial name of the class (which might differ from the class name if @SerialName is used), the number of elements, each element’s name and whether it’s optional, type information for nested serializers, and any @SerialInfo annotations applied to the class or its properties.

This design is clever. By separating the structural metadata from the serialization logic, formats can make intelligent decisions about encoding. A JSON encoder might use the element names directly as keys. A Protobuf encoder might use element indices. The serializer implementation remains the same.

Golden mask optimization: Efficient required field validation

One of the most important optimizations in the generated code is the golden mask pattern for validating required fields during deserialization. When deserializing, the plugin needs to ensure all required (non optional) fields are present in the input.

The naive approach would be to check each field individually:

Instead, the plugin generates bitmask based validation:

This is a gold. A single bitwise AND operation validates all required fields simultaneously. The golden mask is computed at compile time based on which properties have default values (optional) and which don’t (required).

For classes with more than 32 properties, the plugin generates multiple mask integers:

The error reporting is also smart. The throwMissingFieldException function uses the seen mask and golden mask to determine exactly which fields are missing, providing a clear error message without requiring additional bookkeeping.

Serializer resolution: Finding the right serializer for each type

When generating serialization code for a property, the plugin must determine which serializer to use. This resolution follows a priority order:

This resolution happens at compile time, and the result is baked into the generated code. The generated childSerializers() method returns an array of all serializers needed for the class’s properties, enabling format implementations to introspect the complete serialization structure.

Real world application: Custom serializers in production SDKs

Understanding the generated serializer structure helps when building custom serializers. Production SDKs like RevenueCat’s Android SDK leverage this knowledge to build robust serialization for complex API responses.

For example, when dealing with backend responses that might include unknown enum values or polymorphic types, a custom deserializer with defaults becomes necessary:

This pattern mirrors how the plugin generates deserializers but adds fallback behavior for unknown types. It reads the type discriminator, looks up the appropriate serializer, and falls back to a default when the type is unknown. This is essential for backward compatibility when servers add new types that older clients don’t recognize.

Similarly, enum deserialization with defaults handles unknown values gracefully:

These patterns work because they follow the same interface contract that the generated serializers implement. Understanding the generated structure makes building compatible custom serializers straightforward.

K1 vs. K2: Supporting both compiler frontends

The Kotlin compiler is undergoing a major transition from the K1 frontend to the K2 frontend (based on FIR, Frontend Intermediate Representation). The kotlinx.serialization plugin must support both during this transition.

The K1 support uses descriptor based APIs:

The K2 support uses the new FIR based APIs:

The key observation is that both frontends ultimately feed into the same IR generation phase. The IR lowering code that generates method bodies is shared between K1 and K2. This separation of concerns allows the plugin to support both frontends while maintaining a single implementation of the actual code generation logic.

Conclusion

In this article, you’ve explored the internal mechanisms of the kotlinx.serialization compiler plugin, from its two pass IR generation strategy to the golden mask optimization for required field validation. The plugin transforms simple @Serializable annotations into efficient, type safe serializers without requiring reflection or runtime code generation.

Of course, you don’t have any issues without understanding these internals mechanisms, but it will definitely help you make informed decisions when building custom serializers, debugging serialization issues, or evaluating kotlinx.serialization for your projects in any ways. The design choices, like compile time code generation, format agnostic descriptors, and bitmask validation, reflect careful engineering for both performance and flexibility.

Whether you’re building a multiplatform application that needs consistent serialization across JVM, JS, and Native, implementing custom serializers for complex API responses, or simply curious about how your @Serializable classes become working serializers, this knowledge provides the foundation for working effectively with one of Kotlin’s most important libraries.

Running custom built paywalls alongside RevenueCat Paywalls

Tue, 10 Feb 2026 14:24:01 GMT

RevenueCat paywall offers powerful customization of paywalls that render full native views. However, there might be situations where you want to implement your own custom paywall while still leveraging RevenueCat to manage entitlements, offers and packages. This blog post will guide you through how to effectively run your custom paywall alongside a RevenueCat-powered paywall.

Why run multiple paywalls?

You might be wondering why you’d want to manage multiple paywalls simultaneously. Here are a few scenarios where this approach can be highly beneficial:

Transition periods: You might have built a custom paywall before and are interested in progressively moving away from it to RevenueCat paywalls.
A/B testing: You have your existing hard coded paywall, and you’ve now built a new paywall in RevenueCat that you want to test against.
Targeted offers: For specific user segments, you might have unique pricing or promotional offers that require a highly customized presentations,
Advanced logic: For complex onboarding flows or specific user journeys

Your app decides which paywall UI to show, but all purchases still flow through the RevenueCat SDK. This avoids duplicated logic, pricing mismatches, and entitlement bugs while giving you full control over presentation when needed.

Example end-to-end flow with

At a high level, an app with two different paywall types functions like this:

User reaches a paywall decision point
- For example: end of onboarding, feature gate, or promotional entry point
App requests Offerings for a specific Placement
- The Placement represents where the paywall is shown in the user journey
RevenueCat returns the appropriate Offering
- The returned Offering may vary per user based on targeting rules
App inspects Offering metadata
- Metadata determines which paywall should be displayed
App chooses a paywall UI
- RevenueCat paywall UI
- Or a fully custom built paywall UI
User selects a product
- Product and pricing data always come from RevenueCat
Purchase is initiated via the RevenueCat SDK
- Identical purchase flow regardless of paywall UI
RevenueCat updates entitlements
- App unlocks or restricts content based on CustomerInfo

This keeps presentation flexible while keeping the subscription system centralized and consistent. If you make use of RevenueCat’s Experiment feature, you can even test and compare how the different placements and paywalls perform in conversions.

Understanding RevenueCat Paywalls

RevenueCat’s paywalls are designed to simplify the process of displaying your products to users. As outlined in the RevenueCat Paywalls documentation, they allow you to create, manage, and test different paywall designs directly within the RevenueCat dashboard. They handle the fetching of product information and present it in a user-friendly way. All this without having to create new releases of your app when you make changes to your paywall.

For most new apps, implementing your paywall with RevenueCat is the best choice, allowing you to iterate and update your paywall without having to push new releases of your app to stores.

Implementing a custom built paywall

As mentioned earlier, there are cases when RevenueCat paywalls might not be enough. One such case could for example a key design element in your app that you want to also show in your paywalls. In a gamified app this could be for example a broken streak visualisation, that you want to surface in the paywall to communicate to the customer that subscription would allow them to amend the broken streak.

When you decide to implement a custom built paywall, you’re essentially taking control of the UI/UX. However, you’ll still rely on RevenueCat SDK for the backend operations: fetching product information and making purchases.

Step 1: Fetching Product Information

The first step in your custom built paywall implementation is to fetch the product information from RevenueCat. This is crucial for displaying the correct subscription options, prices, and introductory offers to your users. Refer to the Displaying Products documentation for detailed instructions.

In Swift, you’ll typically use the Purchases.shared.getOfferings() method to retrieve your configured offerings. Similarly, on Kotlin, you’ll use Purchases.sharedInstance.getOfferingsWith().

This will provide you with the Offering object, which contains all the necessary product details:

Step 2: making purchases

Once a user selects a product on your custom built paywall, you’ll use RevenueCat’s SDK to initiate the purchase. The Making Purchases documentation provides comprehensive guidance on this.

On iOS, you’ll use Purchases.shared.purchase(package:), and on Android, Purchases.sharedInstance.purchaseWith(). Remember to handle the purchase completion and any potential errors.

Step 3: Entitlement Management

Regardless of whether you use a RevenueCat paywall or a custom one, RevenueCat will handle entitlement management. After a successful purchase, RevenueCat will update the user’s CustomerInfo, which you can then use to grant or restrict access to premium features. In Swift you can do this using the Purchases.shared.customerInfo()

In Kotlin

Conditional display logic for paywalls

You can control the logic for showing different paywalls and offerings using either Placement or Offering metadata. With Placement you can define where each type offering is shown, and with Offering medata you can attach additional information to the offering that is then used in the app to differentiate between showing a custom built paywall or a RevenueCat paywall.

Targeting by Placement

Using Targeting by Placement you can define paywalls locations in your app to serve unique Offerings at each paywall location. This could mean for example displaying a different paywall at the following different locations:

At the end of onboarding (e.g. onboarding_end)
When a customer attempts to use a paywalled feature (e.g. feature_gate)
When a sale is running (e.g. sale_offer)

The basis for deciding Placements is to understand how they would compliment your ideal customer journey. If you’re running a sale, you most likely want to show a different offer and copy to onboarded customers, compared to those using the app for first time. Do this by defining a sale_offer placement.

When your app fetches Offerings by Placement, RevenueCat returns the Offering to be displayed for that customer at that Placement, letting you display unique paywalls based on the customer journey. In Swift you can accomplish this in the following way:

Similarly in Kotlin:

Targeting using Offering metadata

The key to running different types of paywalls and customizing what is shown in your custom built paywall is Offering metadata. In the RevenueCat dashboard you can add valid JSON in to the Metadata field, by navigating to an Offering and clicking Edit or Configure metadata (in case you haven’t configured metadata yet):

Metadata that you configure in the dashboard could look like this for example:

This metadata is attached to the Offering data when you call the SDK to get available Offerings. You can then use it to dynamically make changes to how paywalls are displayed in your app.

Using Offering metadata with the SDK

You can access metadata directly from the Offering object in RevenueCat SDK using the offerings method in Swift

and in Kotlin with the same method:

Metadata values are optional by nature, so all access should be built so that your app and paywalls still work even if the values are not defined in the dashboard.

Example Conditional Logic

Now the last remaining step is to use the logic for showing your custom built paywall or a RevenueCat paywall:

and in Kotlin:

Conclusion

Running your own custom built paywall alongside a RevenueCat paywall provides flexibility for experimentation and targeted offers. By leveraging RevenueCat for product fetching and purchase management, and your engineering skills for custom UI, you can create a highly optimized and engaging subscription experience for your iOS and Android users. This hybrid approach empowers you to maintain control over the front-end presentation while relying on a robust, battle-tested backend for your subscription infrastructure.

R.I.P. toggle paywall: we hardly knew ye

Mon, 09 Feb 2026 15:34:08 GMT

UPDATE: APRIL 23, 2026

As Axel Le Pennec (@alpennec) pointed out on X, it seems subscription giant Flo Health has found an alternative to the toggle paywall, which appears to be compliant with the latest Apple Guidelines.

Flo have replaced their “Enable free trial” toggle with a specific 14-day free trial plan option when showing a multi-plan paywall. Keeping the same “Not sure yet?” copy, this feels like the closest subscription apps can get to matching user intent within this paywall moment, while staying within the guidelines Apple has set.

Credit: Axel Le Pennec

It started with a few whispers, then a handful of tweets. Now, it’s a full-blown trend we can’t ignore. Over the past few weeks, we’ve had several industry figures reach out to us, all asking some version of the same question: “Is Apple killing the toggle paywall?”

Short answer: yes. It sure looks like it

Developer after developer is getting the same rejection notice from App Review, and it’s always about the same thing: a paywall design that includes a toggle to turn a free trial on or off. If you’re using this pattern on iOS, you need to pay attention. This isn’t a drill

What is the toggle paywall?

For the uninitiated: the “toggle paywall” is a paywall design where users are presented with a subscription offer and a toggle switch that lets them add or remove a free trial. In most implementations, the toggle defaults to off – meaning the user sees a plan without a trial. If they flip the switch, they get a different plan (usually weekly instead of annual) that includes a trial period

The mechanic was popularized by Adam Lyttle in mid-2024, when he documented how implementing this exact design doubled his weekly app revenue from ~$2,500 to over $5,300. The numbers were staggering. His introductory offer conversion rate hit 63%, and subscription retention sat at 68%

It was a masterclass in behavioral psychology. The toggle defaulted to “off,” with the cheaper-looking annual plan pre-selected. Users who wanted the free trial had to actively flip the switch, which then moved them to the more expensive weekly plan. Many users, seeing the lower annual price, would just hit “continue” without toggling, skipping the trial entirely and paying upfront. The result? A massive boost in immediate revenue and a higher average revenue per user (ARPU)

It was so effective that it spread like wildfire. Within months, you could see variations of the toggle paywall in apps across the App Store. It became the go-to strategy for developers looking to juice their monetization. We even featured it in our own paywall redesign case studies, where one app saw a 17% boost in ARPU and another saw a 64% uplift in revenue after implementing it

But here’s the thing about patterns that feel a little too effective: eventually, the platforms catch on

The rejection wave

Starting in mid-January 2026, the rejections started rolling in. Axel Le Pennec was one of the first to post about it publicly, sharing a screenshot of Apple’s rejection notice along with a resigned “My app got rejected for that”. Adam Lyttle himself – the man who popularized the pattern – quote-tweeted it the very next day with a simple, three-word eulogy: “RIP paywall toggle”

Since then, the reports have kept coming. Aivars Meijers, Sergey, Ingo, and others have all shared their rejection stories. A Reddit thread about it has dozens of developers confirming the same experience. It’s not an isolated incident – it’s a pattern

The rejection notice from Apple is brutally clear:

Guideline 3.1.2 – Business – Payments – Subscriptions

The purchase screen includes a toggle to add or remove a free trial from the subscription purchase. This design is confusing and may prevent users from understanding that they are committing to an auto-renewing subscription that will begin charging them after the free trial period.

Next Steps: Remove the toggle for adding or removing a free trial from the subscription purchase screen. Users should be presented with a clear subscription offer that explicitly states whether a free trial is included.

No ambiguity there

Why now?

So why is Apple cracking down on this now, after the pattern has been in wide use for over a year?

The honest answer is: we’re not 100% sure. Apple hasn’t published an explicit policy update or blog post about it. But we can connect a few dots

First, Apple has been on a broader mission to clean up subscription practices for a while. Their guidelines on subscriptions (3.1.2) have always emphasized transparency, and their scam-prevention rules (3.1.2(a)) specifically call out apps that “trick users into purchasing a subscription under false pretenses” [10]. The toggle, with its default-off state, arguably falls into that bucket. A free trial that you have to opt into via a hidden toggle is, from Apple’s perspective, a trial that most users will never see – which defeats the purpose of offering one

Second, the pattern became too popular. When a handful of indie apps use a clever design, it flies under the radar. When thousands of apps across the store are using the same mechanic- and when YouTube videos about it are racking up tens of thousands of views – it gets noticed. Apple’s App Review team is clearly aware of the trend, and they’ve decided it crosses the line

Third, and perhaps most importantly: users were getting confused. The whole point of the toggle was that many users wouldn’t toggle it. That’s not transparency – that’s obfuscation. And Apple, whatever you think of their policies, has a legitimate interest in making sure users understand what they’re signing up for

The plot twist: It’s only dead on iOS

Okay, so the toggle paywall is dead. Pour one out. We hardly knew ye

But wait – it’s dead on iOS. And that’s an important distinction

As of today, there is no indication that Google has any issue with this design. The same goes for web-based paywalls. If you’re running a multi-platform app, the toggle might still be a viable, high-performing strategy on Android and the web

This is where having a flexible, remotely configurable paywall setup becomes essential. With a tool like RevenueCat, you can use Targeting to display one paywall on iOS (compliant, toggle-free) and another on Google Play or the web (the classic, high-ARPU toggle design). Don’t throw the baby out with the bathwater – just make sure you’re showing the right paywall on the right platform

What to test instead

So, what’s an iOS developer to do? Get back to the drawing board. The good news is that there are plenty of high-converting, fully compliant paywall designs to test. And some of them might actually convert better than the toggle ever did

Here are the patterns we’d recommend testing first:

1. The “honest” timeline paywall

The famous ‘Blinkist paywall’

This design, popularized by Blinkist, shows a clear, step-by-step timeline of what happens after the user taps “Start Free Trial.” Something like: Today: Full Access → Day 5: Reminder → Day 7: You’re Charged. Blinkist reported a 23% increase in conversion rate and a 55% drop in complaints after implementing this pattern. It builds immense trust, and in many cases, trust converts better than tricks

2. The multi-package selector

Instead of toggling a trial on and off, present multiple subscription packages side by side – say, weekly, monthly, and annual. Badge the one that includes a trial. Users select the package they want; no toggle needed. The trial is inherent to the package, not a separate mechanic. This uses classic price anchoring to make the annual plan (with the trial) the obvious choice

3. The value-first paywall

This approach front-loads the value proposition. Strong visuals, benefit-oriented copy, social proof, App Store ratings – all before the user ever sees a price. When users are genuinely convinced of the value, the friction of payment decreases significantly. Shift the conversation from “how much does it cost?” to “what am I getting?”

4. Personalized paywalls with conditional visibility

This is the more sophisticated play. Use conditional logic to show different paywall content based on user attributes – like whether they’re eligible for an introductory offer. If they are, show trial messaging prominently. If they’re not, show a direct purchase flow. No toggle required, and the experience is tailored to each user. RevenueCat supports this through Targeting and conditional visibility in our paywall builder

5. The exit offer

Duolingo has been experimenting with a ‘web purchase-first’ paywall design

What if you could get a second chance to convert a user who’s about to leave? That’s the idea behind an exit offer. When a user dismisses your paywall, instead of just closing the screen, you can present them with a different, often better, offer. Think a lower price, a longer trial, or a monthly plan after they’ve rejected an annual one

We just shipped this feature in our Paywall Builder. It’s all configured remotely, no code changes needed. It’s a great way to capture intent that would otherwise be lost. But be careful: Apple is also getting stricter on instant paywall abandonment offers, so test this one carefully and make sure it doesn’t feel like you’re trapping the user

6. The web purchase button

Here’s a curveball: route your US-based iOS users to a web checkout entirely. You avoid Apple’s 30% commission, you have full control over the purchase flow, and you can design whatever paywall you want – toggle included – because Apple’s App Store guidelines don’t apply to web purchases. Note that you still have to include in-app purchases in your in-app screen, but you can offer a discount on web (or increase your prices in-app) to nudge people towards the web option. We’ve shipped a Web Checkout Button component that makes this easy to test. The results have been… interesting.

Alternative	Key benefit	Compliance risk
Timeline / “Honest” Paywall	Builds trust, reduces refunds, proven conversion lift	None
Multi-Package Selector	Clear, uses price anchoring, no toggle needed	None
Value-First Paywall	Shifts focus from price to value	None
Personalized / Conditional Paywalls	Tailored experience per user segment	None
Exit Offer	Second chance to convert abandoning users	Low (if not overly aggressive)
Web Purchase Button	Full design freedom, avoids 30% commission	None (web rules apply)

The key is to start experimenting now. Don’t wait for your next app update to get rejected. Proactively test these alternatives and find a new champion for your iOS paywall

One more thing

Here’s an interesting data point that might ease the pain. Ludwig Henne, founder of Fits, ran an A/B test comparing a Adam Lyttle-style toggle paywall against a Blinkist-style honest paywall. The toggle paywall won on ARPU (+19%), but when he isolated the toggle mechanic specifically, he found that the toggle itself wasn’t the main driver. The real conversion lift came from the visual hierarchy: normalized yearly pricing, a “Most Popular” badge, and a larger UI for the annual plan

In other words, you might be able to remove the toggle and keep most of the revenue gains – as long as you maintain the other design elements that made the paywall effective. The toggle was the headline act, but the supporting cast was doing most of the heavy lifting

The end of an era

The death of the toggle paywall on iOS marks the end of an era. It was a wild ride, and it made a lot of developers a lot of money. But the App Store is Apple’s house, and they make the rules

Ultimately, this is probably a good thing for users. And what’s good for users is, in the long run, good for the ecosystem. It forces all of us to be more creative, more transparent, and more focused on communicating the genuine value of our products. The best paywalls have always been the ones that make users want to subscribe, not the ones that trick them into it

So pour one out for the toggle paywall. And then get back to testing

RevenueCat React Native SDK adds React Native Web support

Mon, 09 Feb 2026 11:13:50 GMT

Starting from release 9.7.6 of react-native-purchases, teams building with React Native can manage subscriptions across iOS, Android, and web using the same SDK and the same RevenueCat entitlements system. If your app already runs on mobile and you’re extending it to the web — or you’re starting with a shared codebase from day one — this makes it easier to support subscriptions everywhere without rethinking your architecture.

Add react-native-purchases to your Expo or React Native project, and you have power subscriptions, in-app purchases, entitlement management on three different platforms with a single code-base.

Why we built this

As more React Native apps expand beyond mobile, the web has become part of the product rather than just a marketing surface. Teams want users to sign up, upgrade, or manage subscriptions in a browser, while still unlocking access inside their iOS and Android apps. Until now, that often meant maintaining a separate billing system for web and stitching everything together with custom logic.

React Native Web support removes that split. Web purchases flow into the same RevenueCat backend as native purchases, so you can rely on a single entitlements system instead of reconciling multiple sources of truth.

How billing works on web

On iOS and Android, RevenueCat integrates directly with the App Store and Google Play. On the web, purchases are handled through RevenueCat Web Billing, which uses Stripe or Paddle as the payment processor. Web Billing is separate from native in-app purchases, but it connects to the same entitlements system, making it possible to grant access across platforms using a shared appUserID.

From your app’s perspective, subscription state stays consistent regardless of where a user originally subscribed. A customer who signs up on the web can immediately access premium features on mobile, without you needing to write platform-specific logic.

Getting started with React Native Web

Enabling React Native Web support starts with configuring RevenueCat using the appropriate API key for each platform. When your app runs on the web, you’ll initialize the SDK with a Web Billing public API key, while iOS and Android continue to use their native keys.

Here’s what that looks like in practice:

Once configured, entitlement checks work the same way across platforms. Your app logic doesn’t need to branch based on where a subscription was purchased.

To enable web purchases, you’ll also need to create a Web Billing app in the RevenueCat dashboard and configure your products for web. These live alongside your iOS and Android products, but are billed through Web Billing rather than native stores.

Using Expo

If you’re building with Expo, React Native Web support also improves the development experience. You can preview subscription UI, test entitlement logic, and validate integration flows directly on the web without immediately creating a custom development client. This makes it easier to iterate early and confirm that your setup works end to end.

To fully test real in-app purchases on iOS and Android, you’ll still need an Expo development build. Web support doesn’t replace that requirement, but it does remove a lot of friction during early development.

Current limitations

Because web billing works differently from native app stores, there are a few limitations to be aware of. Web purchases require RevenueCat Web Billing and can’t process native iOS or Android in-app purchases. In addition, some operations that depend on native store APIs aren’t supported on web environments, including getProducts, purchaseProduct, and restorePurchases. Expo Go and similar sandbox enviroments don’t support purchasing either.

Users can manage their web subscriptions through the RevenueCat-hosted customer portal, which provides a consistent way to update or cancel subscriptions outside of native app stores.

What’s next

As subscription apps increasingly span mobile and web, we’re continuing to invest in making cross-platform subscription management simpler and more reliable. React Native Web support is a foundation for that work, and we’ll keep improving the experience as teams push it further in production.

If you’re already using RevenueCat with React Native on mobile, adding web support is now a natural next step.

You can still win Shipyard — multiply your changes by shipping to another brief

Fri, 06 Feb 2026 12:30:16 GMT

There are less than six days left to submit your final entry to Shipyard, and if you’re thinking you’re already too late, I have just one word for you: wrong.

Even if you haven’t started building yet, there’s still enough time to get an app to beta and ship it through TestFlight or Google Play’s testing tracks. Shipyard isn’t about perfection, it’s about shipping — and a focused MVP can absolutely be competitive at this stage. And if you already have one app ready to submit, this is your chance to multiply your odds by building and submitting another app for a different brief.

In this post, we’ll walk through a few of the creator briefs and explore concrete ideas for how you could realistically ship an app for each of them. The goal is to help you move from “maybe” to “shipped,” even if you’re starting late or considering a second (or third) submission.

Make use of the vibecoding tools included in the Shipping Container

Anthropic recently released a new version of their Claude Code Opus 4.6 model, and it’s already supported by the tools included in the Shipping Container. That means you’re not just reading about more powerful AI-assisted coding, you can actually use it right now, as part of Shipyard, without any extra setup.

With these tools, building an app is no longer about writing everything from scratch or spending weeks on boilerplate. You can scaffold features, iterate on UI, and explore ideas at a pace that simply wasn’t possible before. Shipyard is a perfect excuse to take these tools for a real-world test drive and see how far you can get in a single weekend with focused execution.

Briefs that you could target

Shipyard offers seven different creator briefs for you to choose from, and you’re allowed to submit one app for each brief. That gives you a lot of flexibility — but it also comes with a few important constraints. You can’t submit multiple apps to the same brief, and you can’t submit a single app to multiple briefs. Each submission needs to clearly map to one brief, so it’s worth being deliberate about which problems you decide to tackle.

With just about a week left to build, it’s easy to assume that the window has already closed — but that’s not the case. To show what’s still possible, we’ve picked a few very different briefs and explored how you might realistically approach each of them in a short time frame. The goal isn’t to overwhelm you with ideas, but to help you see how a focused MVP can still be competitive.

Whether you’re only now jumping into Shipyard, or you already have one app submitted and are considering building a second — or even a third — these examples should give you a clearer sense of how to scope your work, pick the right brief, and maximize your chances of shipping something meaningful before the deadline.

“Investment tracker for all assets” — Josh from VisualFaktory

Investors juggle stocks, gold, funds, fixed income, real estate, and more across multiple platforms — messy to track and hard to understand at a glance. Josh wants a single app where users can log everything, get real-time price updates where possible, set amortization/reminder alerts for non-listed products, and unlock premium risk + diversification analysis (like country/sector exposure).

This brief can seem intimidating at first. Supporting many different asset types sounds complex, but it’s exactly the kind of problem modern LLMs excel at: turning messy, unstructured information into clean, usable data.

A strong approach is to lean on the APIs from OpenAI, Anthropic, or Google and build an app that accepts almost any input — spreadsheets, screenshots, PDFs, or dictated descriptions — and converts them into structured assets your app can work with. The key is designing prompts that normalize the data and then visualizing it clearly. You can also use AI to analyze the portfolio and generate insights, pulling in real-time finance data when needed.

On the business side, this works naturally with usage based pricing. Using RevenueCat’s virtual currencies, you could offer AI-assisted imports and advanced risk analysis as credit based features, tying monetization directly to value delivered.

“Powerful reminders with cross-device sync.” – Sam Beckman

Sam lives by reminders, but switching between Android and iOS means rebuilding his entire system from scratch. He wants a beautiful, fully functional reminders app on both iOS + Android* with custom snoozes from notifications, powerful recurring rules, and true sync so dismissing once clears everywhere.

*For the purpose of the hackathon, you only need to build an MVP for iOS or Android

This brief is fundamentally about cross-platform thinking. Frameworks like Flutter, Kotlin Multiplatform, and React Native are a natural fit here — and if you’re building with React Native, you’re in especially good shape. Tools like Rork, Blink, Fastshot, Vibecode, and Replit make it surprisingly easy to scaffold and ship polished React Native apps quickly.

The app itself is once again the easy part. The real challenge — and the real opportunity — lies in reminders and notifications. Doing this well requires reliable sync and state management across devices, which usually means running your own backend. Instead of building everything from scratch, you can lean on tools like Firebase or Supabase to get a real-time database, auth, and sync set up quickly, without spending your limited hackathon time on infrastructure. Supabase especially, has a really good MCP, which you can make use by telling your AI agent to set up everything there

With a focused MVP, even a single-platform reminder app with rock-solid notifications and sync can stand out. Especially if it’s beautifully designed and clearly solves a problem Sam’s audience deeply cares about.

Dating and making friends on the road is hard when you’re always moving—and van life is a tight, protective community. Quin wants a van-life app with nomadic dating, activity-based friend finding, and even a paid ‘builder help’ section for van projects, with invite-only or verified access to keep it safe and intentional.

This brief gives you a chance to flex skills you don’t often get to use: building a social network from scratch. The surface level requirements are fairly simple, but making this work will still require a backend for accounts, messaging, and locationaware discovery. For tooling and infrastructure, it’s worth revisiting the previous brief for suggestions on how to get this set up quickly.

Where this brief really stands or falls is differentiation. To stand out, you need a clear hook that immediately resonates with van-lifers. One approach could be building a kind of mobile friendship book, where you collect connections as you travel from place to place. Layer in location based discovery and messaging, and you already have a well scoped app that feels built for this community.

Wrap up

Hopefully this post sparked a few ideas, whether that means submitting your very first app to Shipyard, or doubling down with a second one. If you’re still feeling stuck on what to build, how to scope it, or how to turn your work into a compelling story, I’d recommend checking out another post I wrote for exactly that situation, modestly titled How to win Shipyard.

With only a few days left before Devpost submissions close, it’s also worth revisiting the mechanics of a strong submission. I’ve covered that in a separate post,How to submit your app for Shipyard, where I break down what you actually need: a working app, a clear description, and a short three minute video showcasing what you built. That video matters more than most people expect, so make sure you spend some time getting it right.

Now get hacking.

Why hybrid monetization is the default model for subscription apps in 2026

Thu, 05 Feb 2026 17:38:12 GMT

At the start of the year, we always see a deluge of prediction articles. In January 2022 on this very blog, I mentioned the rise of hybrid monetization for subscription apps. I spoke about this prediction multiple times, for Techcrunch and at in-person events.

At the time, it didn’t take off. The pressure wasn’t strong enough yet. Fast forward a couple of years, and AI has quietly turned usage into a revenue drag. 2025 showed signs that hybrid monetization was on the rise, but in 2026, pretending otherwise will be fatal for subscription apps. 2026 is the year of take off for hybrid monetization!

Incidentally, this 2022 blogpost was also where I discussed non-store payment options — and here we are now in 2026 with new uncertainty following App Store’s term changes…

Before we jump into what moving your growth model towards hybrid monetization means for subscription apps, let’s look at the ‘why now’. (Spoiler alert: it’s AI again.)

Pre-AI: subscriptions won because marginal costs were invisible

For most of the past decade, subscription apps benefited from a hidden advantage: there were virtually no variable costs, whether you served one user or one million users — development and design aside, serving an additional user was effectively free.

That shaped how the entire pricing ecosystem evolved:

Flat pricing felt fair
Power users were an upside, not a risk
Monetization focused on conversion and retention, not cost containment

We couldn’t imagine a time where more users or more active users could be a bad thing. This is why ‘all you can eat’ subscriptions became the norm outside of gaming. The model worked because the economics were forgiving.

AI breaks that forgiveness. 2026 is the year this shift becomes impossible to ignore. Not because AI is new, but because its economics are now colliding with a maturing subscription market.

The growing cracks

Lately, subscription-based apps are ‘winning’ the App Store. We see non-gaming App Store revenue overpassing the flatlined gaming sector and attracting founders, talent, capital, tools and more (many of whom are from the gaming vertical, ironically). But things are getting harder.

The cracks in the all-you-can-eat subscription model have been visible for years, but today they’re becoming an increasing headache for app profitability:

Plateauing ARPU
Converting barely a low single digit of user to premium features
Rising churn
Declining marginal returns from optimization
Growing concerns for subscription fatigue

Why now? Three underlying factors accelerating hybrid

Predicting hybrid monetization’s rise back in 2022 was early. What’s different in 2026 is that multiple pressures are converging at once.

There are several factors that are making the shift to hybrid monetization not a nice-to-have but a necessity:

1. AI has massively increased competitive density

AI-assisted development has seen the amount of new apps explode. Vibe coding has lowered the cost of shipping and iterating apps. More teams are building faster, copying proven monetization patterns, and competing in the same categories.

The result: more apps, similar funnels, and less room for monetization mistakes.

2. Optimization is no longer a lasting edge

Paywall design, pricing tests, and onboarding flows used to be meaningful differentiators. Today, they’re table stakes. Today, paywall optimization is showing declining marginal return: it’s no longer a competitive edge, see it as a base requirement!

Vahe Bagdasaryen once made $1m selling easy-to-apply paywall layouts in his first year of consulting — great, but now everyone is using the same layouts (hence the limits of Blinkist-like paywalls). These tactics are mandatory to master, but they quickly become commoditized; incremental gains shrink while costs keep rising as new apps vie for attention in the same few places.

3. User acquisition keeps getting harder

Attention hasn’t scaled with supply. More apps, same amount of eyeballs on the Tiktok feed or the App Store. User acquisition (UA) costs continue to climb, while conversion rates and ARPU plateau in many non-gaming categories. Ad bids are harder to win, big fish are taking over ASO real estate, and there’s more competition than ever. Increasing ARPU by 20-25% yearly is just the beginning to compensate for UA inflation, it’s only what comes on top that is a win.

Why now? The variable cost of AI is an ignition towards hybrid monetization

For a long time, most subscription-based businesses had variable costs of virtually zero. AI-based features make this obsolete. It’s a structural break: apps using AI as part of their core value are actively spending more money with each user they acquire.

If your most engaged power users cost more than they pay, or free users can generate cost, the model needs to be rewritten.

While primarily thought for SaaS businesses, Anh Tho Chuong’s article So you want to price your AI features is applicable to any AI app:

“The zero marginal cost era of software is over the minute you touch LLM APIs. AI has real COGS and it is something we will have to learn to deal with.” — Anh Tho Chuong, CEO & Co-founder of Lago

High variable cost means a few outliers can literally bankrupt you. But it also threatens the ‘all-you-can-eat’ nature of most subscription-only models:

Power users were your best asset, now they can become a liability!
Free users were generating indirect value for free (ratings, virality, late conversions…) but now carry negative unit economics
Free trials have to be thought very differently
ARPU averages hide catastrophic tail risk

It doesn’t mean subscriptions shouldn’t be the core of monetization for AI-based apps, but there is the need to build on top and adjust to those costs. I’m aligned with Anh Tho’s bet that hybrid pricing will be more common, keeping recurring revenue stable while increasing LTV.

Put together, the variable cost of AI plus the pressures discussed above look like this:

More app competition + similar monetization and acquisition playbooks + higher variable costs = a forced evolution of the subscription monetization model.

But what does that model look like in practice?

Access is predictable: subscriptions still anchor revenue, expectations, and retention
Consumption is bounded: usage-heavy behaviors are capped, metered, or monetized separately
Power users self-select into higher spend: instead of being subsidized by everyone else, they fund the costs they generate.

Here are two inspirations to move you to action:

Learn the fundamentals: my recent article covers how subscription apps can capture more revenue through hybrid monetization, outlining key techniques and models, with real app examples.
Delve into the specifics: Alice Muir Kocourková wrote a detailed explanation of how AI has disrupted app pricing models, with examples of how AI apps are pricing their top features.

Hybrid monetization is the natural evolution

Despite all of the above, I still believe subscriptions are a powerful model — just not in the static, all-you-can-eat form that has dominated monetization, retention, and acquisition for the past decade.

All these factors are pushing for the natural next phase of model maturity: it’s not about abandoning subscriptions at all, but getting smarter and building on top.

AI apps barely have a choice. AI apps need to better reflect the usage-based costs of heavy users. But this isn’t just for AI apps. Even apps without heavy AI features now compete in markets shaped by these dynamics — even without the variable cost issue, growth is business model competition.

What to do if you’re building a subscription app today

This blog isn’t a tactical checklist per se, but there are a few directional implications from my observations which are hard to ignore:

If your app has AI features: you’ll eventually need to separate access from consumption; ignoring this early only makes the correction more painful later, and risks you being swamped by competition
If your app doesn’t use AI (yet): don’t rest on your laurels or think you’re exempt from the pressure — you’re still competing in an ecosystem shaped by AI economics, so expect pricing shifts, faster imitation, and shorter monetization half-lives
If you’re early-stage: defaulting to all-you-can-eat subscriptions is no longer the safe choice it once was — design pricing that can evolve as usage patterns emerge, but consider the added complexity of hybrid models

Ultimately, the wisest thing you can do is keep an eye on your revenue streams. Watch for any outliers or heavy users if you have AI variables, and start thinking how you can protect your pricing model against the coming changes.

The bottom line

Subscriptions aren’t failing. They’re being asked to do a job they were never designed for.

AI makes usage expensive. Hybrid monetization is how subscription apps adapt, by preserving predictable revenue while aligning pricing with real costs and value. 2026 is the year hybrid monetization stops being an experiment and becomes the default shape of modern subscription businesses.

Your Shipyard: Creator Contest questions answered

Wed, 04 Feb 2026 17:19:28 GMT

It was great to see so many of you join our Shipyard LIVE on Tuesday. We didn’t have time to answer every question live, so we’ve pulled together the most commonly-asked ones here. We hope this info helps on your journey to building a monetizable MVP — keep building, and we’ll see you at the finish line!

Building your app

Q: Can I build for both iOS and Android?

A: Yes. Cross-platform frameworks like React Native or Flutter are allowed — your app just needs to be a mobile app (iOS or Android).

Q: How do I get access to the Shipping Container?

A: Once you register for the contest on Devpost, you will receive an email within 48 business hours with information on how to redeem all of the offers. Reach out to our team in Discord if you encounter any issues.

Q: Do I need to use the tools included in the Shipping Container?

A: No. You are free to use any tool you want; it’s not a requirement to use the tools contained in the Shipping Container to build your app, and this does not impact judging.

Q: Do I need a working backend, or is it enough to have demo userflows that explain the function and demonstrate how it should work?

A: Everything in the app should be working. Your backend doesn’t need to scale to a large user base — this is an MVP — but documentation or user flows alone aren’t enough.

Q: Does a TestFlight Expo app that uses WebView for some screens still qualify, or does it need to be fully native to be compliant?

A: An Expo/React Native app distributed via TestFlight still qualifies, even if some screens use a WebView. More information on using RevenueCat with React Native is available in our documentation here.

Monetization

Q: Is a RevenueCat integration required?

A: Yes, your app must have RevenueCat installed and active to be eligible.

Q: Is an integration with RevenueCat’s Test Store sufficient?

A: No, this does not count as an integrated SDK. More info here.

Q: Do I have to charge for my app, or can I just use RevenueCat to introduce a ‘Donate to Developer’ experience?

A: Yes — this is allowed and within the rules. That said, creators are ultimately looking for apps that meaningfully monetize their audience, so you should think carefully about whether this approach aligns with the brief.

Q: How do I decide what features to monetize? How do I price correctly?

A: This is up to you. You should be pitching how and why you’d monetize your app as part of your submission — not just what you’d charge for. Hear more from our Judges on this here.

Submission and testing

Q: Do I need to publish to the App Store?

A: Apps must be accessible via TestFlight (iOS) or Play Internal Testing (Android). Your app does not need to be on the public stores (App Store or Google Play Store). If your app is also live on an app store, this will not affect the judging of your submission (positively or negatively).

Q: Can I submit multiple projects for the same brief?

A: No, you can only submit one submission per brief (seven submissions total). Choose wisely!

Q: Can changes be made after the Feb 12 deadline? How do we know which version of the app will be judged?

A: Yes, you can continue working on your app after the Feb 12 submission deadline. The Intellectual Property remains yours, and we can’t (and don’t want to) restrict ongoing development.

However, you should clearly specify which version of your app is being submitted for judging in your Devpost submission. Judges will evaluate the version you reference there and the one that features in your demo video.

Q: Do I need to upload to GitHub if the app is vibe-coded?

A: No. You don’t need to upload your code to GitHub.

Q: What tester emails should I use for TestFlight or Play Internal Testing?

A: All the information on how to submit, including what tester emails to use, is available here.

Q: Should I ensure the judges can access and test premium features, or will seeing a paywall suffice?

A: You should ensure all the features that you want the judges to evaluate are available.

Q: Since the App Store URL is allowed, can we provide instructions to redeem free credits for judges to test the app?

A: Yes, this is fine.

Judging

Q: For the video submission, should I screen record on my phone to demo the app, and do I need to have a face cam?

A: Up to you! How you record the feature and whether you feature yourself/voice/face in it is entirely your call. The only thing that will affecting judging is the quality of your app and the effort put into submission — better quality videos or more engaging demos might stand out more, but you won’t be penalized for not showing your face.

Q: Will the Creators use my app or just watch the demo video I provide?

A: Due to the expected number of submissions, we can’t guarantee that every app will be fully installed and tested. The only requirement is that judges watch your demo video — this is how all submissions are reviewed before shortlisting. Shortlisted submissions will be fully tested. Make sure your video clearly shows the core experience and value of your app. Hear more about this here.

Q: How long should my demo video be?

A: We recommend keeping your demo video to 2–3 minutes. Shorter videos may hold attention spans more, but judges will watch videos of any length. This isn’t a hard limit — longer videos won’t be rejected.

Q: Should we disable paywalls for testing?

A: No, don’t worry about this. In TestFlight and Play Internal Testing, the transactions won’t be charged.

Q: Are sandbox purchases sufficient, or do the Judges need to see a real transaction flow?

A: TestFlight / Sandbox purchases are sufficient.

Q: What would you say matters more, how the app looks and feels, or the level of functionality?

A: See the response from our judges here.

Q: Will it impact the judging if a Creator specifically mentions a preference for iOS vs. Android?

A: If a creator mentions a platform preference, it’s smart to factor that into what you build. It can help your app better fit their audience.

That said, you won’t be disqualified for building on the other platform. If you do, make sure to explain your choice and include a clear roadmap for supporting the creator’s preferred platform. Judges will focus on overall audience fit, product quality, and long-term potential — not just the initial platform.

Q: Any bonus points if your app is launched with users?

A: No, judging isn’t based on user numbers. The focus is on the quality of your MVP, how well it fits the creator’s audience, and its monetization potential. Having users won’t hurt, but it won’t give you extra points on its own.

Creator-specific questions

Q: Can you share more information on the Creator’s audience demographics

All the information we have is available here.

Q: Gabby, do your followers typically DM you, and what sort of questions do they ask?

See Gabby’s response here.

Q: Gabby, do you think it’d be useful to include a feature that allows users of your app to interact with one another?

See Gabby’s response here.

Q: Eitan, can I use recipes from your website (https://www.eitanbernath.com/recipes/) in my app?

Yes, you can use recipes from Eitan’s website for the purposes of the hackathon. However, once the competition ends and your app is published to an app store, those recipes will need to be removed. This is to ensure content rights are respected beyond the scope of the contest.

How ElevenLabs builds and grows consumer AI apps without losing speed or clarity

Wed, 04 Feb 2026 13:50:55 GMT

ElevenLabs is best known for pushing the boundaries of voice AI — but what’s just as interesting is how the team turns powerful technology into consumer products that actually scale.

In this episode of Sub Club, host David Barnard sits down with Tanmay Jain (Mobile Growth Lead, ElevenLabs) and Jack McDermott (Mobile Growth Lead, ElevenReader) to unpack how ElevenLabs approaches mobile growth, pricing, launches, and team structure in one of the fastest-moving categories in tech.

What emerges isn’t a story about AI models or technical breakthroughs. It’s a story about clarity, speed, and systems — and the decisions that make those possible.

Below are the most relevant lessons from the conversation.

Pricing should match how users think — not how AI works

One of the biggest wins Tanmay and Jack share came from simplifying pricing.

For ElevenReader, the team moved away from tokens and credits — concepts that make sense internally, but confuse consumers — and instead sold listening time. The result was clearer value communication and materially better conversion.

The lesson is simple but often missed: Abstracting away AI complexity isn’t “dumbing things down.” It’s good product sense.

If users have to learn a new mental model just to understand pricing, friction is already too high.

Small, autonomous pods turn speed into a moat

ElevenLabs doesn’t operate as one large, centralized org. Instead, it functions more like 10–12 small startups inside a single company.

These small, autonomous pods have full ownership — from product decisions to experiments, pricing, and paywalls. That structure allows teams to ship quickly, iterate relentlessly, and stay accountable to real outcomes rather than internal process.

In fast-moving AI markets, this isn’t just an org preference — it’s a competitive advantage.

Earned media compounds — and makes paid growth work better

Jack breaks down how ElevenLabs thinks about launches as compounding assets, not one-off moments.

Each successful launch generates earned media, which increases branded search, improves trust, and lowers the cost of paid acquisition. Over time, this creates a flywheel where narrative, brand, and performance marketing reinforce each other.

Growth isn’t paid versus organic.
It’s the interaction between the two that matters.

Start launches with the tweet thread, not the feature

Before building launch assets, landing pages, or ad creative, ElevenLabs starts with a single test:

Can the value of this feature be explained clearly in a tweet thread?

If the answer is no, that’s a red flag. Writing the narrative first forces clarity and keeps teams focused on user value instead of shipping features that look impressive but don’t resonate.

In practice, the tweet thread becomes the first product spec.

Consumer apps are a strategic advantage for platform companies

ElevenLabs doesn’t see its consumer apps as competing with its platform or API business. They’re a force multiplier.

By being their own best customer, the team uncovers UX friction, performance constraints, and emotional use cases that are hard to see from dashboards or API logs alone. Those insights flow back into the core product, making the platform stronger for everyone.

Mobile isn’t just a distribution channel — it’s a learning surface.

Conclusion: Clarity, Speed, and systems matter more than hype

The core lesson from this episode isn’t about AI at all.

It’s about building systems — pricing, teams, launches, and feedback loops — that let great products move fast without breaking trust or usability.

For founders, growth leads, and product teams working in fast-moving categories, ElevenLabs offers a clear example of how to scale thoughtfully without slowing down.

🎧 Listen to the full episode of Sub Club to hear Tanmay Jain and Jack McDermott break down the experiments, decisions, and trade-offs behind ElevenLabs’ consumer growth strategy.

Handling edge cases in Google Play Billing

Mon, 02 Feb 2026 02:06:07 GMT

Google Play Billing provides a comprehensive API surface for handling in-app purchases and subscriptions on Android. Most developers are comfortable with the standard purchase flow: launch the billing flow, receive a result, acknowledge the purchase, and grant entitlements. But production billing systems must handle a wider range of scenarios that are often underrepresented in tutorials and sample code. Pending purchases, multi-quantity consumables, subscription downgrades with proration, and the ITEM_ALREADY_OWNED response are all situations your app will encounter in the real world, and mishandling any of them can result in lost revenue, confused users, or failed purchases.

In this article, we’ll explore the most common edge cases in Google Play Billing, understand why they occur, examine how to handle each one correctly with the Play Billing Library, and see how RevenueCat simplifies these scenarios so you can focus on your product instead of billing infrastructure.

The fundamental problem: the happy path is not enough

Most billing implementations start from the sample code in the Android documentation:

This handles a successful, immediate purchase. But what happens when the payment is delayed by 48 hours because the user is paying at a convenience store? What happens when the user already owns the item because a previous acknowledgment failed silently? What happens when a subscription downgrade takes effect at the next renewal instead of immediately? Each of these scenarios requires specific handling, and ignoring them leads to support tickets, refund requests, and lost subscribers.

Pending purchases: when payment is not immediate

Not all purchases complete instantly. Certain payment methods, including cash payments at convenience stores, bank transfers, and some carrier billing options, require asynchronous processing. When a user initiates a purchase with one of these methods, Google Play returns a purchase in the PENDING state rather than the PURCHASED state.

Why pending purchases happen

Pending purchases are common in markets where credit card penetration is low:

Payment method	Common regions	Typical processing time
Cash payments (convenience stores)	Japan, Mexico, Indonesia	24-48 hours
Bank transfers	Germany, Netherlands, Brazil	1-3 business days
Carrier billing (some carriers)	Various	Minutes to hours

If your app is available globally, you’re bound to encounter pending purchases. Ignoring this state means users in these regions cannot purchase your products at all — or worse, they see confusing behavior where their purchase ‘disappears’.

Detecting and handling the pending state

The PurchasesUpdatedListener receives pending purchases alongside completed ones. The critical distinction is in the purchaseState field:

The key rule is: do not grant entitlements for pending purchases. The user has not paid yet. Instead, record the pending purchase and communicate the status clearly:

Completing a pending purchase

When the payment is eventually confirmed, your app receives an updated purchase via onPurchasesUpdated or through queryPurchasesAsync. The purchaseState will now be PURCHASED, and you can proceed with acknowledgment and entitlement granting.

However, there is a subtlety: the user might not have your app open when the payment completes. Your backend should handle this through Real-Time Developer Notifications (RTDN). When you receive a ONE_TIME_PRODUCT_PURCHASED or SUBSCRIPTION_PURCHASED notification for a previously pending token, your backend should update the entitlement and notify the user:

Enabling pending purchases in your BillingClient

Pending purchase support must be explicitly enabled when building the BillingClient. Without this, purchases from delayed payment methods will fail entirely:

Starting with Play Billing Library 7, calling enablePendingPurchases() is required. Without it, BillingClient initialization will fail.

The `ITEM_ALREADY_OWNED` response: a common source of confusion

One of the most frequently encountered edge cases is BillingResponseCode.ITEM_ALREADY_OWNED. This response occurs when a user attempts to purchase a non-consumable product or subscription they already own. While it sounds straightforward, the scenarios that trigger it are often surprising.

Why `ITEM_ALREADY_OWNED` happens

The most common cause is not the user deliberately trying to buy something twice. It’s a previous purchase that was not properly acknowledged. Google Play’s acknowledgment requirement means that unacknowledged purchases exist in a limbo state: the user has been charged, but the purchase has not been confirmed by your app. If the user tries to buy the same item again, Google Play returns ITEM_ALREADY_OWNED because the unacknowledged purchase still exists.

This happens more often than you might expect:

The app crashed after receiving the purchase but before acknowledging it
A network error prevented the acknowledgment call from completing
The user force-closed the app during the purchase flow
The acknowledgment API call returned an error that was not retried

Handling `ITEM_ALREADY_OWNED` correctly

The correct response to ITEM_ALREADY_OWNED is not to show an error message. Instead, you should query for existing purchases and process any unacknowledged ones:

This pattern turns a frustrating error into a seamless recovery. The user does not need to know that a previous purchase failed to acknowledge. From their perspective, they tap ‘Buy’ and get the item.

Preventing `ITEM_ALREADY_OWNED` proactively

The best approach is to prevent this scenario by processing unacknowledged purchases on app startup:

Call this method when the BillingClient connects successfully. This ensures that any purchases that slipped through the cracks are recovered before the user encounters problems.

Consumable purchases: `acknowledge` vs. `consume`

For consumable products like in-game virtual currency, extra lives, or token packs, the distinction between acknowledgment and consumption is a common source of bugs. Both are required for consumable products, but they serve different purposes and have different timing requirements.

The acknowledgment and consumption flow

Acknowledgment tells Google Play you’ve delivered the purchased content. It must happen within three days of the purchase, or the purchase is automatically refunded.

Consumption resets the purchase so the user can buy the same item again. Without consuming a product, the user cannot repurchase it, and attempting to do so returns ITEM_ALREADY_OWNED.

For consumable products, you should consume the purchase, which implicitly acknowledges it:

The multi-quantity edge case

Google Play supports multi-quantity purchases for consumable products. A user can buy multiple units of a consumable in a single transaction. The quantity is available in the Purchase object:

If you ignore the quantity field and always grant one unit, users who purchase multiple units will receive fewer items than they paid for. This leads to support tickets and refund requests.

To enable multi-quantity purchases, you must configure the product in the Google Play Console with ‘Allow multi-quantity purchases’ enabled. Additionally, your BillingFlowParams can specify a maximum quantity the user is allowed to select:

The consumption retry problem

If the consumeAsync call fails (due to a network error, for example), the user has received their content but the purchase has not been consumed. This means:

The user cannot buy the same consumable again
The purchase may be refunded after three days if not acknowledged (though consumption implicitly acknowledges)

You should implement a retry mechanism for failed consumptions:

Call retryPendingConsumptions() each time the BillingClient connects, alongside your unacknowledged purchase recovery logic.

Subscription downgrades and proration modes

When a user changes their subscription plan, the billing behavior depends on whether they are upgrading or downgrading and which proration mode you specify. Downgrades in particular have behavior that surprises many developers.

The default downgrade behavior

When a user downgrades their subscription (moves to a cheaper plan), the default behavior is DEFERRED: the downgrade takes effect at the next renewal date, not immediately. The user continues to have access to the higher-tier features until their current billing period ends.

Understanding replacement modes

Each replacement mode has different implications for billing, access, and user experience:

Mode	When Change Takes Effect	Billing Impact	Best For
`IMMEDIATE_WITH_TIME_PRORATION`	Immediately	Remaining time credited toward new plan	Upgrades where user gets immediate access
`IMMEDIATE_AND_CHARGE_PRORATED_PRICE`	Immediately	Prorated charge for remainder of period	Upgrades with fair billing
`IMMEDIATE_AND_CHARGE_FULL_PRICE`	Immediately	Full new price charged, new billing period starts	Premium upgrades
`DEFERRED`	Next renewal	No immediate charge	Downgrades
`IMMEDIATE_WITHOUT_PRORATION`	Immediately	No charge until next renewal	Lateral moves or trials of higher tiers

The deferred downgrade pitfall

The most common mistake with deferred downgrades is checking the subscription state immediately after the purchase flow completes and expecting to see the new plan. With DEFERRED mode, the original subscription remains active with the original product ID until the next renewal. The new subscription only appears after renewal.

This means your entitlement check must account for the transition period:

The linked purchase token on plan changes

When a subscription replacement is processed (whether upgrade or downgrade), a new purchase token is generated. The new purchase includes a linkedPurchaseToken field pointing to the old subscription. Your backend must handle this correctly to avoid creating duplicate entitlements:

Failing to invalidate the old purchase token when processing a replacement is a common bug that leads to inflated subscriber counts and incorrect revenue reporting.

Network failures and retry strategies

Billing operations are network dependent, and network failures or low latency are inevitable. The critical operations that can fail are the purchase flow itself, acknowledgment, consumption, and purchase verification.

The acknowledgment window

Google Play gives you three days to acknowledge a purchase. If you fail to acknowledge within this window, the purchase is automatically refunded. This is a safeguard for users, but it means your acknowledgment logic must be resilient to transient failures:

BillingClient disconnection

The BillingClient can disconnect at any time, and operations performed on a disconnected client will fail. You should implement reconnection logic with exponential backoff:

How RevenueCat handles these edge cases

Each of the edge cases described above requires careful implementation, retry logic, and backend infrastructure. This is where RevenueCat provides significant value by abstracting away the complexity and handling these scenarios automatically.

Pending purchases

RevenueCat tracks pending purchase states internally and updates CustomerInfo when payments are confirmed. Your app only needs to check entitlements:

RevenueCat’s backend processes RTDN notifications from Google Play, so when a pending purchase completes, the entitlement is updated RevenueCat’s server-side. The next time your app queries CustomerInfo, the entitlement is active. No custom notification handling or purchase token tracking is needed on your side. If you’re a sole developer, building the overall backend infrastructure is a ton of resources.

Acknowledgment and consumption

RevenueCat handles acknowledgment and consumption automatically. When a purchase is received by the SDK, it is verified with RevenueCat’s backend, and RevenueCat acknowledges the purchase with Google Play on your behalf. For consumable products, RevenueCat handles consumption after verification. You never need to call acknowledgePurchase or consumeAsync yourself.

This eliminates the entire class of bugs related to failed acknowledgments, missed consumption calls, and the ITEM_ALREADY_OWNED problem.

Subscription plan changes

RevenueCat provides a clean API for subscription upgrades and downgrades through purchaseWith:

RevenueCat handles the linked purchase token logic, entitlement transitions, and deferred downgrade tracking on the backend. Your app simply checks CustomerInfo for the current entitlement state.

Network resilience

RevenueCat’s SDK includes built-in retry logic for all network operations, caches CustomerInfo locally for offline access, and synchronizes with the backend when connectivity is restored. This means your app can check entitlements even when the device is offline:

The SDK distinguishes between stale and fresh data, retries failed operations with exponential backoff, and ensures that entitlements are eventually consistent with the server-side state.

Wrapping up

In this article, you’ve explored the edge cases that separate a sample billing integration from a production one.

Each of these scenarios has a well defined solution using the Play Billing Library directly, but the cumulative implementation effort is significant. You need client-side handling, backend RTDN processing, retry mechanisms, and careful state management across all of them. For teams that want to ship subscription features without building and maintaining this infrastructure, RevenueCat handles these edge cases automatically, letting you check a single CustomerInfo object instead of managing the complexity yourself.

Whether you build the billing infrastructure directly or use RevenueCat, understanding these edge cases is essential. They represent the difference between a billing system that works in testing and one that works reliably for millions of users across diverse markets and payment methods.

As always, happy coding!

— Jaewoong

How to submit your app for Shipyard

Fri, 30 Jan 2026 12:17:47 GMT

Submitting your app to Shipyard should be straightforward, as you don’t need to navigate app store reviews or production release requirements to participate. What matters is that judges can install and evaluate your app reliably during the hackathon.

This article explains exactly what is required, what is optional, and how to submit your app correctly.

Shipyard rule recap

Before you submit your app, make sure your app adheres to the rules of Shipyard:

Mobile apps only — iOS, Android, or cross-platform (no web/desktop apps)
All projects must be started and completed within the hackathon timeframe
Participants can only submit one app for one brief — choose wisely!
RevenueCat integration is mandatory — subscriptions or in-app purchases
Apps must be on TestFlight (iOS) or Play Internal Testing (Android) — you can have the app live on app stores, but this isn’t required
Developers retain full ownership of all intellectual property
If you use an influencer’s name or likeness, you must remove it before public launch (unless agreed with the influencer)
Any post-hackathon collaboration with influencers is separate from RevenueCat

Let’s take a closer look at a few key rules next.

What can you build your app with?

The main goal of Shipyard: Creator Contest is to build an MVP of a mobile app for the selected creators’ audience. You can use any technology (Swift, Kotlin, Flutter, React Native, etc.) or tool (Cursor, Xcode, Claude, Vibecode, Rork, etc.), as long as it produces a mobile app that can be uploaded to either Apple App Store or Google Play Store. This means that web apps are out of the scope of this hackathon. Tools such as Capacitor are allowed, in case you’re turning a web app into a native mobile app.

Your app must have RevenueCat integrated

Your app must have a version of the RevenueCat SDK installed on it, and you must have your in-app purchases configured for the platforms your app is targeting, and the in-app purchase products need to be purchasable. Test store configuration is not counted as an integrated SDK.

Full configuration of RevenueCat requires you to have either an Apple Developer account or Google Play developer account.

Your app must have RevenueCat SDK integrated
App must have subscriptions and/or in-app purchases
Test store integration is not enough

Apps must be on TestFlight (iOS) or a Google Play testing track (Android)

Your app must be distributable through either TestFlight in App Store Connect, for iOS apps; or Google Play Public/Closed/Internal testing track, for Android apps. This means that you need to have an account on at least one of those stores for the app you’re submitting. Sadly RevenueCat is unable to cover the cost of the developer account for participants.

For TestFlight distribution, at least one app has to have been submitted to App Store Connect, and made available for distribution on the TestFlight tab. The app you submit to Shipyard should have External testing enabled, with a public link. Attach the public link to your Devpost submission.

For Google Play Console testing tracks, your app has to be uploaded to Google Play Console and made available through an Internal, Closed, or Public testing track so judges can install and evaluate it.

You CAN publish your app (but it’s optional)

Making your app public and publishing for people to download from the App Store and Google Play Store is allowed during and after the hackathon. Doing this will not affect judging, but you’re also not required to wait on publishing your app.

Publishing during Shipyard is allowed
Publishing does not disqualify your app
Publishing does not affect judging

How to submit your app to Shipyard

Your app needs to be testable on either iOS or Android devices, with distribution done either through TestFlight for iOS, or one of Google Play Console testing tracks for Android.

App testing and RevenueCat verification

Due to the number of submissions, we do not guarantee that every app will be fully installed and tested by judges. The required demo video is the primary way judges will be viewing all apps, before shortlisted apps will be viewed in more detail.

However, all winning apps will be installed and tested to verify correct integration of the RevenueCat SDK and confirm that subscriptions and/or in-app purchases are implemented as described. If a winning app cannot be installed or does not have a working RevenueCat integration, it may be disqualified and the award reassigned.

To avoid issues, make sure your submitted build is installable, stable, and matches what is shown in your demo video.

How to submit your iOS app

First, upload at least one build of your app to App Store Connect using Xcode. Once the build is processed, go to the TestFlight tab and enable External Testing. Create a public TestFlight link so anyone with the link can install the app without being added manually.

Make sure the build you share is stable, launches correctly, and allows judges to reach the core functionality of your app. If your app includes subscriptions or in-app purchases, they must be purchasable, meaning that you’ve integrated RevenueCat with App Store connect.

Finally, copy the public TestFlight link and include it in your Shipyard (Devpost) submission. Judges will use this link to install and evaluate your app.

How to submit your Android app

To submit an Android app to Shipyard, your app must be installable by judges through one of Google Play’s testing tracks.

Internal testing

Upload your app to the Google Play Console and create an Internal testing track. Add shipyard-android@revenuecat.com as a tester email so judges can access the app. Once the build is approved for internal testing, verify that the app installs correctly and that all core functionality is accessible.

If your app includes subscriptions or in-app purchases, they must be purchasable, meaning that you’ve integrated RevenueCat with Google Play Console.

Closed testing

Alternatively, you can use a Closed testing track. Upload your build to the closed track and add shipyard-android@revenuecat.com to the tester list (either directly by email or via a Google Group that includes this address). Make sure access is granted before submitting.

Confirm that the app installs cleanly and that judges can reach the main features without additional setup.

Public testing

You may also use Public testing. Upload your app to a public testing track and ensure the app is available for anyone to install without requiring approval. Share a link to your public testing version in the Devpost submission.

Summary

Shipyard does not require you to launch your app publicly, but it does require that judges can reliably install and test it. As long as your app is available through TestFlight (iOS) or a Google Play testing track (Android) and includes a working RevenueCat integration, you’re good to submit.

Publishing your app to the App Store or Google Play during or after the hackathon is optional and does not affect judging. Focus on shipping a solid, testable MVP. If judges can install your app and experience its core functionality, you’ve met the submission requirements.

If anything is unclear, ask in Discord. We’re happy to help you get unstuck quickly. Happy shipping!

RevenueCat Paywalls changelog

Thu, 29 Jan 2026 15:33:17 GMT

RevenueCat Paywalls is our native paywall builder that lets you build and optimize paywalls in real-time through RevenueCat’s dashboard, no app updates or code changes needed. In summer 2025 we rebuilt RevenueCat Paywalls from the ground up. What was once a simple, template-first tool is now a fully flexible, component-based editor where you can design fully custom layouts, localize every string, and tailor the experience to every segment.

But we’re not stopping there, we’ve been on a particularly rampant shipping spree as of November 2025. We’re shipping the most-requested and most impactful updates to Paywalls with a clear goal to make it the best paywall builder for every app.

This blog will serve as a living changelog for all-things RevenueCat Paywalls, so bookmark it to follow along and keep up with everything new.

A new Paywalls editor layout

We’ve refreshed the Paywalls editor with a sidebar-based layout that replaces the old dual-panel interface. Core areas like components, layers, branding, media, and localization now live in clearly labeled tabs, making the editor easier to navigate and simpler to learn.

The new layout keeps the canvas front and center while giving us room to keep expanding Paywalls over time. As features grow, the editor stays organized instead of crowded, even when you’re working on more complex paywalls.

Explore the new editor ↗

Keyboard shortcuts for faster editing

When you’re iterating quickly, small interactions add up. The Paywalls editor now supports Figma-style keyboard shortcuts for common actions like moving, duplicating, selecting, and deleting components.

To make shortcuts easy to discover, we added a help icon inside the editor that shows the full list of supported commands. You can open it at any time, pick up shortcuts as you go, and keep your focus on the layout instead of the UI.

View all shortcuts ↗

Copy and paste components between paywalls

You can now copy and paste components across different paywalls, not just within a single one. This makes it much easier to reuse layouts that already work, like hero sections, benefit lists, or pricing blocks.

When you paste a component into another paywall, its structure, styling, and bindings come with it. For teams running multiple campaigns or experiments, this cuts down on repetitive work and helps keep designs consistent across variations.

A dedicated Branding tab

We’ve added a new Branding tab to the Paywalls editor to centralize your visual system. You can now manage saved colors, gradients, and custom fonts in one place and reuse them across all paywalls in your project.

Branding assets appear directly in color and typography pickers while you edit, which makes it easier to stay on brand and avoid one-off values. This also simplifies collaboration, since teams can standardize styles once and confidently build on top of them.

A new Media gallery

Managing images across paywalls is now smoother with the new Media gallery. You can see all uploaded assets in one place, preview them at a glance, and clean up files you no longer need.

Uploading images is as simple as dragging and dropping them into the gallery. When editing a paywall, you can reuse existing assets instead of uploading the same file again. This is especially helpful for teams running many paywalls that share artwork or campaign visuals.

Safer localization with out-of-date alerts

Localization is now more transparent. When you update text in the default language, the editor automatically detects which translations are out of date.

A warning badge appears in the sidebar, along with a clear list of affected locales and fields. From there, you can update translations with one click or dismiss the warning if the change is intentional. This helps prevent silent copy drift and keeps global paywalls aligned as content evolves.

Learn more about localization ↗

Exit offers on paywall dismissal

You can now configure an exit offer that appears when a user closes a paywall without purchasing. Instead of ending the flow immediately, you can present a second paywall with an alternative offer.

This is useful for scenarios like offering a different billing option, a lower price, or a final reminder before the user leaves. Exit offers work across iOS, Android, and hybrid SDKs, and integrate cleanly with existing paywalls and experiments.

Configure an exit offer ↗

Auto-save for paywall drafts

The Paywalls editor now auto-saves drafts as you work. Changes are saved continuously in the background, which reduces the risk of losing progress if you navigate away or refresh the page.

Auto-save also surfaces validation issues earlier, since drafts are saved more frequently. Publishing behavior stays the same. Nothing goes live until you choose to publish, but editing feels safer and smoother, especially during longer design sessions.

Export Figma designs straight into Paywalls

Design handoff shouldn’t mean starting over. And now, it doesn’t.

You can export Figma mockups directly into the Paywall editor. Your layout comes in as native Paywalls components, so you can immediately:

Edit copy without touching the structure
Swap products and packages
Localize text
Add experiments
Target specific audiences

The practical win is speed. Designers stay in Figma, and the team shipping paywall tests can go from final mock to live variant, without recreating the layout by hand.

Import a Figma design ↗

Keyboard shortcuts in the Paywalls editor

When you’re iterating quickly, little clicks add up.

The Paywalls editor now supports keyboard shortcuts for the actions you use most, including adding components, duplicating sections, undoing and redoing changes, and deleting blocks. It keeps you in flow and makes fast iteration feel genuinely lightning quick.

View all shortcuts ↗

Preview your paywall on more devices

A paywall can look perfect on one screen and awkward on another. That used to be something you discovered after publishing, but now you can preview paywalls across a wider set of iOS and Android phones and tablets. The canvas updates to real screen sizes, so you can flip through devices in seconds to:

Catch spacing issues early
Confirm font sizes
Check crops and media positioning
Sanity-check scroll behavior
Make sure your CTA lands where you want it

It’s a simple change that prevents a lot of last-minute fixes.

Filter paywall templates

Templates are only helpful if you can find the right one quickly.

The template gallery now includes filters by purchase method, tier, or package. It’s especially useful when you know the pattern you want up front, like a trial-first layout, a pricing grid, or a promo-ready design. You spend less time searching and more time shipping.

Start with a template ↗

Countdown component for your paywall

Promos can be a great paywall technique, but they only work best when urgency is clear and real. To help, you can now add a countdown timer to any paywall. Set an end date once and the timer updates automatically. No extra code, no manual updates.

This is built for campaigns like Black Friday, launch promos, limited-time discounts, or any offer where timing helps people decide.

Add a Countdown ↗

Project level brand color settings

Setup brand colors now in project settings that are available in the Paywalls editor (and soon more places).

Real prices displayed in the Paywalls Editor

Previously, placeholder values displayed for product prices while being viewed in the dashboard editor. This latest update makes it so that you now see the real prices in the editor. This makes it much easier to get a more realistic version of the paywall while you’re working on it. (The one caveat is we will need to have seen at least one test purchase with this product for it to display).

Use AI to create a paywall

You can now use artificial intelligence to create a paywall based on data from an app store page. A great way to get inspiration or a solid starting point to adjust from and test.

Videos in Paywalls

Paywalls now support videos being added as their own component, just like images.

Video backgrounds

Videos can now be set as backgrounds on the root paywall, footer, or any parent component (stacks, packages, etc).

Intercept purchase intent

Native iOS & Android SDKs now offer a method to intercept purchase intent (tapping on the purchase CTA) to display custom UIs before choosing to proceed with the purchase flow. Use cases that apps find for this include: Age gate/parental consent: display a UI that acts as an age gate before letting someone proceed to purchase, Disclosures: If there’s additional info you want/need to present to a customer and have them confirm before proceeding (country specific terms, legal language, etc.)

View all plans (sheets)

You can now choose to have your button navigate to a sheet that can be used to display additional content. When you select a sheet as the destination to navigate to, you’ll see a new Sheet component inside of your button in the Components panel. When the sheet or any component within it is selected, you’ll see the sheet displayed in the paywall preview. You can add components to the sheet just as you would to any other stack.

Sheet’s can have their own packages & purchase buttons so that customers can directly make a purchase from the options displayed within the sheet.

Learn more in our Documentation ↗

How Sebastian Röhl built HabitKit by sticking with what worked (and starting over when it didn’t)

Wed, 28 Jan 2026 13:50:47 GMT

Sebastian Röhl didn’t stumble into success as an indie app developer. He shipped an app that went nowhere, burned out, started again, and only then saw momentum compound.

In the latest Sub Club episode, Sebastian—the indie developer behind HabitKit and FocusKit—walks through the slow, uncertain middle of app building: stalled growth, unclear signals, and the decision to keep going even when nothing looks like it’s working yet.

This isn’t a story about overnight success. It’s a story about persistence, timing, and doing enough of the basics well that growth eventually has somewhere to land.

From a safe job to a self-imposed deadline

After studying computer science and software engineering in Germany, Sebastian took a stable enterprise software job working with C#, .NET, and Angular. The work wasn’t exciting, but it gave him strong fundamentals and exposure to experienced engineers.

At the same time, he was quietly drawn to the idea of building his own business. After three years, he quit without a concrete plan and gave himself a clear constraint: 12 months to make something work.

As Sebastian explains in the episode, he didn’t leave with a polished business idea. He left knowing only that he wanted to build something for himself—and that mobile apps felt like the right medium.

The first app didn’t fail—but it didn’t work either

That first attempt was LiftBear, a workout tracker Sebastian built for his own use. He shipped quickly, skipped beta testing, and marketed it only by sharing progress publicly on Twitter.

The result was discouraging but instructive.

LiftBear attracted a small number of users and eventually settled at around $150 in monthly recurring revenue. It wasn’t dead—but it wasn’t growing, either. After six months of updates and incremental improvements, progress had stalled.

Sebastian describes this period as deeply demotivating. The app wasn’t clearly failing, but it wasn’t giving him any signal that doubling down would change the outcome.

HabitKit started with one visual that resonated immediately

HabitKit came from a much simpler idea: Sebastian wanted a habit tracker that visualized consistency using a GitHub-style contribution grid.

When he shared the first screenshot publicly, the response was immediate. Engagement spiked, new followers arrived, and for the first time, there was clear interest before launch.

That signal changed his energy entirely. He focused fully on HabitKit and released the first version after about two months of development.

The launch was modest by startup standards, but meaningful for an indie developer: roughly $150 in revenue on day one. More importantly, it showed that people understood the product instantly.

Building in public helped early—but wasn’t the long-term growth engine

Early on, building in public played a critical role. It helped HabitKit get its first users, early ratings, and initial momentum. It also gave Sebastian accountability and motivation during the quiet early months.

But the biggest growth moment didn’t come from social media.

Months after launch—after Sebastian had already returned to a four-day-a-week job—HabitKit suddenly began ranking for “habit tracker” in multiple App Store regions, including Germany and the UK. Shortly after, Google Play followed.

There was no viral post, no major metadata change, and no obvious trigger. Sebastian still isn’t sure why it happened. What was clear is that once HabitKit crossed a certain threshold, downloads and revenue accelerated quickly.

This was the moment when earlier work—product quality, reviews, consistency—finally paid off.

Going back to a job wasn’t the end of the story

When the original 12-month deadline expired, HabitKit still couldn’t support Sebastian full time. He returned to his previous company, working four days a week and reserving Fridays for his apps.

That fallback plan gave him stability—and time.

Six to seven months later, HabitKit’s growth was no longer ambiguous. With organic discovery compounding and revenue climbing steadily, Sebastian felt confident quitting again. This time, the decision was grounded in traction, not hope.

FocusKit was about motivation, not diversification

After years focused almost exclusively on HabitKit, Sebastian noticed something else stalling: his own motivation.

Updates became incremental. Public writing felt repetitive. To reintroduce novelty, he started FocusKit, a minimalist Pomodoro timer built natively with SwiftUI.

FocusKit wasn’t created to replace HabitKit or immediately match its revenue. It was a way to learn new technologies, lean into native iOS design, and regain creative momentum.

The launch was intentionally low-pressure. Early revenue has been modest, but the project serves a different purpose: keeping Sebastian engaged, curious, and shipping.

What Sebastian’s journey shows about indie app growth

Sebastian’s story isn’t built around clever hacks or aggressive growth tactics. It’s built around fundamentals:

Shipping products he personally wants to use
Sharing progress honestly, especially early on
Iterating longer than feels comfortable
Letting distribution compound after the product earns it

Growth felt sudden only in hindsight. In reality, it arrived after months of quiet, compounding work.

🎧 Listen to the full Sub Club episode to hear Sebastian unpack the slow parts, the setbacks, and the decisions that didn’t make sense at the time—but mattered in the end.

Why most activation metrics don’t predict who will stay (and what to use instead)

Wed, 28 Jan 2026 12:13:55 GMT

If you start researching activation metrics, you’ll find no shortage of suggestions:

Signups
Trials completed
Session length
Onboarding completion

On the surface, these all sound like reasonable things you should probably keep an eye on.

The problem? Most of these metrics focus on volume, not quality. They tell you how many people moved through a step, not whether those people became meaningful users, paying users, or users who actually stuck around.

In short, they don’t show whether someone truly activated in a way that drives retention or monetization.

Activation isn’t the same as signing up, and it’s not the same as completing onboarding — which means many ‘activation metrics’ will lead you astray.

What happens when you focus on the wrong metrics

Case 1: onboarding is performing, but activation isn’t happening

I see this all the time in growth audits and client work. In one example, onboarding completion rates were stellar — over 90% on both iOS and Android. The team felt confident that activation was in a good place.

But when we dug deeper, most of those users were gone by day two.

The onboarding flow was easy, short, and clear, but users weren’t engaging with the parts of the product that actually mattered or experiencing real value. Onboarding completion looked good, but the activation issue persisted.

Case 2: feature usage looks good, but only for a segment

In another example, activation metrics looked strong at first glance:

Good engagement
Healthy feature usage

But once we segmented free versus paid users, the picture changed entirely. Free users were inflating almost every metric; they were active, engaged, and numerous, but weren’t converting, renewing, or contributing to revenue.

After we isolated paid cohorts, it became clear that activation quality for the users who actually mattered was much poorer than topline numbers suggested.

These two cases highlight the risks of misinterpreting activation metrics, either by focusing on the wrong metric or by failing to segment your data meaningfully.

How to get to the right metrics

We’re going to look at:

Which activation metrics actually matter for subscription apps
How to avoid metrics that sound useful but don’t predict retention or revenue
How to define your own activation metric instead of copying someone else’s
How to test whether your chosen metric is real or just a vanity signal

I wish I could give you a magical activation metric and call it a day, but every app and use case requires a slightly different approach. The best I can offer is a framework to distinguish metrics that truly matter from those that merely look good.

Because here’s the truth: retention doesn’t happen without activation.

Many apps think they have a retention or monetization problem, but zooming out often reveals that users drop off before they experience meaningful value or form a habit.

Credit: Diagram created together with Thorsten Strauss, Hello Growth

The metrics you need to focus on depend on whether the problem is activation or retention.

The real question is: are people not sticking around because your product isn’t useful, or because they never truly activated in the first place?

That’s exactly what the right activation metrics help you figure out.

What activation really means for a subscription app

Before defining the right activation metric, we need to be clear on what activation actually is, because this is where things often get muddled.

I frequently see teams conflate activation with acquisition, label generic engagement metrics as activation, or treat it as simply ‘the steps a user completes’ rather than whether those steps actually move them toward becoming a long-term subscriber.

But we’re not here to get lost in terminology debates. Let’s keep it simple.

Activation happens when a user reaches meaningful value early enough in their journey that it becomes likely they will:

Convert (if they’re on a trial or freemium path)
Stay through their first renewal
Retain beyond that initial period

It’s not about completing an onboarding flow or ticking off a checklist. It’s about whether early behavior predicts survival and long-term value.

Or put another way:

Activation isn’t “Did they do the steps?”
Activation is “Did the steps they took meaningfully increase their odds of getting value and, as a result, staying and paying?”

You can test this by comparing retention curves for users who performed a particular action versus those who didn’t.

But here’s the catch: almost any action will look better than doing nothing, so you need to focus on actions that truly predict long-term retention and monetization.

Hypothetical retention curves for two different in-app behaviors

The real question is whether that specific action is truly predictive of retention and high-value users. The goal isn’t just to track activity; it’s to identify behaviors that correlate with long-term subscribers, versus actions (or inaction) that signal faster churn or low-value usage.

Two layers of activation: first value and core value

When thinking about activation in subscription apps, it helps not to treat it as a single moment. Your first session matters of course, but according to the State of Subscription App Report 2025, the largest share of trials occurs on Day 0 across both freemium and hard-paywall apps.

SOSA 2025: Day at which trials are started for freemium vs. hard paywall apps

That said, activation is just one moment in building a habit. In subscription apps, it’s rarely a single step.

I like how Product-Led Growth by Wes Bush breaks it up into three moments:

Moment of value perception: users understand the value, e.g. by seeing an example or visual
Moment of value experience: users experience the value themselves, e.g. using the app’s main feature for the first time
Moment of value adoption: users begin using the app in a meaningful way, e.g. building a habit

What we often talk about for apps is this idea of ‘Time to First Value’ and that usually covers the first two moments. The core value only emerges once behavior starts to repeat.

Credit: Slightly adjusted diagram based on original diagram from Product-Led Growth by Wes Bush

Let’s dive deeper into those two parts.

1. Time to first value (TTFV): moment of value perception and experience

TTFV is the user’s perceived and experienced value. It’s often small, but it matters because:

The steepest drop-off happens right at the beginning
Many users decide whether to continue or disengage very early

If users don’t see value early, they may never reach meaningful activation, no matter how strong the product becomes later.

This first-value moment should feel like progress, not just effort or friction for its own sake. Long onboarding flows might be trendy, but don’t use them just to fill time; they rarely help activation.

2. Time to core value (habit or sustained usage): moment of value adoption

Core value usually takes longer to reach. This is where users move from trying the product to using it in ways that predict retention.

It’s especially important for:

Habit-forming products
Wellness or tracking apps
Financial or budgeting tools
Apps with more complex workflows (e.g. B2B apps)

For example, for a language-learning app, completing a single lesson might signal the first value. But core value emerges once someone completes several lessons over multiple days and starts to build a routine. It may be measured by the moment they know 30 words in the new language or can form five complete sentences.

Many teams get stuck optimising only for the first session, without checking whether users reach the behaviors that matter later. For one app I worked on, we used day-7 retention as a success metric by ensuring experiments extended beyond session one, including push notifications and sessions two and three, to identify what would get users back enough in the first week to stick around.

When defining activation, don’t just ask: “What happens on day one?”

Also ask: “What must occur before a user behaves like a retained user?”

The key is that both layers matter, but in different ways.

First value helps prevent early drop-off
Core value predicts whether users will sustain and ultimately retain

Metrics that actually matter for activation

Now we’ve defined activation, the next question is: which metrics really matter?

It depends on your app (I know, such an annoying answer!), but if you’ve done the thinking above and run the numbers, you should already have a sense of:

Which behaviors predict retention
Which features deliver meaningful value
What your first value and core value moments look like

From there, the most important metrics are the ones that show whether users are reaching those value moments in ways that drive retention and conversion, not just ticking off steps or generating volume.

To help you better distinguish between noise and signal for your subscription app, here are examples of metrics that matter, metrics that inform, and ones that just distract.

Metrics that matter

These metrics are most likely to reflect real activation quality.

1. Percentage of users reaching the first value

This metric shows how many users reach the initial mini aha! moment, aka the first value.

Measuring this early step (perceived value) can be tricky in apps, but you can get a good sense by tracking whether users:

Complete a meaningful setup step
View a personalized insight
Return within 24 hours after their first session

Why it matters: It shows whether drop-offs are happening before users ever reach the value.

You’re not trying to force everyone to reach it instantly. The goal is to ensure enough users experience value early enough to avoid churning before activation.

If not enough of your users are reaching the first value moment, you have an activation problem, not a retention problem.

2. Percentage of users reaching the core value

This is the deeper signal, the next step in the journey. It shows whether users are forming patterns or habits that support retention.

This metric is often far more predictive of long-term success than anything that happens in the first session. The core value usually doesn’t happen immediately; it often emerges later, once users engage repeatedly with the product.

3. Time to first value (used thoughtfully)

Time to first value can be useful, but only as a diagnostic metric, not a goal in itself.

For first value, faster is generally better, but only if the experience still delivers genuine value. It’s better to provide meaningful value slightly slower than superficial value quickly.

For core value, timing matters relative to behavior. If reaching core value in week one versus week two predicts very different retention outcomes, then timing becomes a meaningful signal.

How timing of behavior can impact activation and in turn retention

The insight here isn’t ‘shorter is always better’. It’s that timing tells you something about activation quality.

4. How activation shows up in your funnel

Once you know how many users reach first and core value, these standard subscription metrics tell you whether that activation is turning into revenue:

Trial start rate (if you offer a trial)
Trial-to-paid conversion rate (if you offer a trial)
Download-to-paid conversion rate

The key: never look at these metrics in isolation.

For example, you might see a high trial start rate but a low trial-to-paid conversion rate. That doesn’t necessarily mean the trial itself is the problem. Often, users are starting a trial before they’ve actually experienced value, then canceling quickly ‘just in case’.

The right move might be to:

Slow down the path to trial
Improve value delivery first
Accept lower trial volume in exchange for higher-quality users

Again, when it comes to activation metrics, quality over volume is what drives retention.

Metrics that inform (but shouldn’t be success KPIs)

Some metrics are useful for understanding activation, but they shouldn’t be treated as proof of success.

1. Onboarding completion rate

Onboarding completion is one of the most overused activation metrics. A high completion rate does not guarantee activation is working.

In some cases, adding positive friction actually improves activation quality by helping you understand users, tailor experiences, and build trust before asking for commitment.

Instead of asking “How do we increase onboarding completion?”, ask:

Do users who complete onboarding retain better?
Are we helping the right users progress?
Are we losing good users too early, or filtering out low-intent users later than we should?

Completion is a signal, not a goal.

2. Feature adoption (with the right segmentation)

Feature adoption can be insightful, but only if you look at it through the right lens.

Average adoption rates often hide the story. A feature may appear lightly used overall, but be heavily used by high-LTV or paying users. Meanwhile, some features add complexity without contributing to retention.

Feature adoption is most useful for understanding:

Which features support retention
Whether free users understand the value of premium features
Which features are adding noise rather than helping users activate

I had an app where very few free users tried the main premium feature (it was available with limited usage to free users). As a result, they weren’t activating properly and were unlikely to pay — they didn’t see the value.

Feature adoption is also useful for spotting noise. If only 2% of users use a feature, and they aren’t your most valuable users, so ask whether it’s adding complexity rather than contributing to activation.

On that note, check out this great podcast on the adoption thresholds used at Netflix.

Metrics that distract

These metrics are easy to over-optimize and often pull growth teams in the wrong direction.

1. Total signups

More signups don’t automatically mean better growth. While signups are necessary to feed volume into the funnel, optimizing for quantity alone can:

Attract lower-quality users
Mask activation problems
Give acquisition teams the wrong incentives

Sometimes the right move is fewer signups, but higher-quality traffic that is more likely to activate and retain.

2. Trials started

A high trial start rate doesn’t automatically create more paying customers. In some cases, users start a trial before truly experiencing value, which can lead to:

Low trial-to-paid conversion
Poor first renewal
Weaker retention overall

3. Session length

Longer sessions can indicate engagement, especially for apps like video platforms or games, but they can also signal confusion or difficulty finding content.

For many subscription apps, efficient value delivery is more important than raw time spent. Context matters far more than total minutes.

4. Raw daily active users (DAU) or monthly active users (MAU) without a quality lens

DAU and MAU are only meaningful if ‘active’ reflects meaningful usage, and the frequency matches your product’s natural cadence.

A common recommendation is to look at the stickiness ratio that measures app stickiness:

However, there are two issues with this standard app stickiness metric:

Your app’s ideal usage frequency might not be daily
Active users’ often means ‘opened the app’, which isn’t the same as ‘experienced value’

Once you adjust for these factors, stickiness can still be useful, but it’s better to define your ideal usage frequency and compare it over a longer period to identify what drives retention.

For example, for a wellness app I worked with that offered workshops and meditations, consuming at least two pieces of content in 14 days was a stronger predictor of retention than using the app once a week.

How to test whether your activation metric is real or vanity

Defining an activation metric is just the first step. Next, you need to demonstrate that it reflects real activation, not just a vanity signal.

A metric only counts as true activation if it passes these tests:

1. Activated users retain significantly better than non-activated users

Compare retention curves for users who reached the activation milestone versus those who didn’t.

Think back to the diagram I showed earlier:

Hypothetical retention curves for two different behaviors in-app

You’re looking for a sustained difference, not a short-term bump that fades after a few weeks. If the curves reconverge later, the metric is likely just an engagement step, not true activation.

Put simply: if users who ‘activated’ don’t retain or pay significantly more, your metric isn’t real activation, it’s just noise.

2. The relationship holds across (most) cohorts and channels

Check whether the activation metric predicts retention consistently across:

Cohorts over time
Acquisition channels
Web vs. iOS vs. Android
Device types
Geography (if relevant)

You don’t need perfection, as some variation is normal. You might see:

A channel where the relationship is weaker
Users on one platform are activating differently

What matters is that the pattern holds broadly, and you understand where and why it breaks. In some cases, you may need different activation metrics for web, iOS, Android, or different regions.

3. Improving the metric improves downstream outcomes

Some activation effects take time to appear in retention curves, especially if you’ve only recently started tracking them. Another key check is whether improving the activation metric drives the outcomes it should influence.

For example:

If it’s an early value milestone → does it improve trial-to-paid conversion?
If it’s a deeper habit milestone → does it improve first renewal?
If it sits later in the journey → does it reduce early churn?

If the metric moves but nothing downstream improves, it may look meaningful, but it isn’t actually creating better, more durable users.

Practical checks to strengthen confidence in your metrics

If you have enough data, stress-test your activation metrics with a few deeper cuts:

Compare activated vs. non-activated users within the same cohort
Split by paid vs. free users (if you have a freemium path)
Break down by channel or device quality
Check whether high-LTV users follow the same activation pattern

This helps you avoid building your activation model around users who were never likely to pay or retain in the first place.

Work out your activation window

Activation is not just about what happens; it’s also about when it happens.

Look at your retention curve and identify where the steep early drop-off stabilizes. That point often marks the transition from activation to retention and helps define the window where your metric truly matters.

The activation window

If the activation window is very long, it may indicate that users aren’t deriving value quickly enough, or that your product simply requires a longer window to activate. This could mean:

Users aren’t reaching value fast enough
They need more guidance or support to progress meaningfully early on

Back to a language-learning app, a single lesson isn’t enough to signal commitment. Users may need to complete several lessons over a week or two before they meaningfully engage as long-term learners (or start fearing the owl enough to keep going). The window isn’t just about capturing that first lesson; it’s also about the time required to significantly increase the user’s likelihood of staying.

The goal isn’t to force activation sooner than makes sense. It’s to understand when it happens today and whether that timing supports retention.

How to use this in practice

After all that, you might have a long list of metrics you could track, but you don’t need dozens. Stay focused by categorizing metrics into three clear buckets.

Metrics that matter should directly predict conversion, retention, or renewal: optimize these
Metrics that inform help you understand why activation is or isn’t happening: investigate these
Metrics that distract are easy to improve, but often optimize volume over quality — keep an eye on them, but resist chasing them

If there’s one takeaway, it’s this: activation is not about getting users through steps. It’s about helping the right users reach value in a way that makes them likely to stay.

When teams think they have a retention or monetization problem, it’s often because activation never truly happened. The earlier you define what real activation looks like for your product, the easier everything downstream becomes.

How to win Shipyard

Tue, 27 Jan 2026 14:14:03 GMT

RevenueCat has a new hackathon, Shipyard: Creator Contest. Similarly to our previous hackathons, this one is also about building a real, monetized mobile app (MVP is enough, check the rules here). This time, however, your target audience are the community of real influencers — who will also be judging your submission!

This hackathon is a lot shorter than Shipaton, so it’s more important than ever that you focus on building the right thing, quickly. RevenueCat wants to support you in doing that, so we’ve written this hackers’ guide to building a winning app, based on four core lessons:

Coming up with a great app idea
Building your app fast
Growing your user count
Telling your story in the final submission

On top of these lessons, we’ve curated a bundle of tools, credits, and resources to help you build, launch, and monetize your app in the four weeks of Shipyard. Once registered, check your email (including your junk!) to receive your Shipping Container.

Without wasting any more time, here’s how you win Shipyard.

Step 1: Come up with a great app idea

The first step into winning a hackathon is coming up with an idea for your app. Preferably this idea should be a really good one, as it will make building a great app significantly easier, but that is rarely that easy to do. So how do you come up with a great app idea?

First, start by watching the creator briefs, there’s seven of them, and they are all quite different. Be open, and don’t use come to this hackathon with an existing idea that you’ll then try to make fit one of the briefs. That rarely works, and to be frank, what you think is a great idea for an, usually isn’t. So take your time with the briefs, and pick the one that resonates the most. At this point your idea can be very simple, and it certainly does not have to be a groundbreaking one, we will distill it into a one next.

Talk to people

A common misconception is that people come up with great app ideas on their own. In reality people come up with average ideas on their own, and once they start talking with customers about the problem they have, it gets turned into a great idea. So take your preliminary idea, and go to the potential users with it. Watch the creator brief again, this time focusing on who is the target audience, and figure out where you could find someone that represents the target customer, then simply go talk to them.

Don’t just pitch your idea to the target customer, instead start with open ended questions. Build empathy to understand what the problem is that your customers are having, and how they feel it could be solved. Your goal is to understand your customers in such a way that you can instantly know what the real problem they are struggling with is, and what kind of solution they would fall in love with.

With all of this you should aim to get to a state where you feel that you have to build this specific app, because you’re the only one who really understands your customer, and therefore the only one who can get it right. For more pointers about getting to this state and coming up with a great app idea, take a look at our How to win Shipaton: coming up with an idea blog post.

Step 2: Build your app fast

Once you have your problem and idea nailed, it’s time to start building. The first lesson in building quickly is setting a timeline for yourself and sticking to it. Don’t wait for inspiration to start coding your app, that stuff is for amateurs. Winners just get to work and build.

You can approach your build timeline in multiple ways, but we have one that tends to work very well, and it only has three parts that all have a specific purpose:

1. Build your concept in 4 hours

In these four hours your focus is on proving that your concept works. The only person you need to convince that your app is great is you yourself. This is the part where you make something that barely works, but works nonetheless. There’s a bit of UI there already, but no polish, and there certainly shouldn’t be big infrastructure in your app at this point.

2. Build your MVP in 8 hours

Now take what you built in the first 4 hours, and start polishing it so that you could show it to a potential customer. Things don’t have to work at this point, they just have to feel like they work. Use mock data, make fake requests to services, be like the Wizard of Oz: it’s not magic but for users it feels like it is.

If you feel embarrassed to show your app, good. That means you’re going to your customer early enough with your idea and getting feedback that will set you on the right track.

3. Build your app in 24 hours

After you’ve shown your 8-hour making to customers, take what they have to say and incorporate it into your app. Drop things that users didn’t care about, add the things that enough people asked for. At this point your app will most likely still be embarrassing. You just need to get it to a stage where you could leave the customer alone with it and check back later how it worked. So launch the app if you can.

And keep launching and relaunching your app. Multiple times. Every day if it requires it. Add features, fix bugs, but never take more than day or two from getting those improvements in the hands of your customers.

This process should highlight to you that great apps are built iteratively honing the product, not building it once and leaving it at that. So ship as often as you humanly can. We’ve collected more guidance on building quickly using this same method in this How to win Shipaton: building your app fast blog post.

Step 3: Grow your user count

After you’ve built your idea, comes the actual hard part: getting users. Shipyard does not require you to launch your app to app stores, but doing so doesn’t hurt either. After all, customers can only pay you if your app is available to them, and more customers means more revenue.

However there are other reasons for growing your user count than just converting them to customers. In the beginning especially, the more users you have the more feedback you get, and you might have already learned from the previous two lessons that gathering feedback and acting on it is the best way to build something that wins.

For a more extensive lesson on growing your app, take a look at this blog post on Winning Shipaton by growing your app, but here’s a few key points to growing.

First make use of the Shipyard discord to recruit users to test your app. Get as many as you can, people will churn, meaning that they’ll stop using your app when it stops being useful to them. With your first version of the app, this will most likely happen with all of the users, that’s why it’s important to continue improving your app and launch it again and again. The most valuable learning you can get is talking to the users who stopped using your app, they know best what features your app is lacking, so try to get a hold of them.

Step 4: Tell your story

Last lesson to winning Shipyard has actually quite little to do with your app itself, and all to do with how you talk about your app. When you take a look at the submission guidelines for Shipyard, you’ll notice that two of the requirements besides the app are a short video and a written proposal. These are the two things the judges will be scrutinizing the hardest, so it’s important to communicate clearly what your app is about.

Clear messaging is however only half of the story. If you actually want to win, you need to tell a compelling story. This means framing the problem so that it elicits feelings from the people looking at the video, and in such a way that paints you and your app as the heroes of the story.

Now this all sounds rather complicated, but fear not, RevenueCat is here to help you with this as well. In our fourth guide How to win Shipaton: pitching your app guide, we go through a simple storytelling mechanic called the “Story circle”. Check out that article, apply it to your video and written submissions (and don’t do it on the last night before submissions close), and making both of them should not take you more than a few hours.

Make use of the Shipping Container

Last but certainly not least, we have partnered up with a group of companies to give you the best tools for building your app, a curated bundle called the Shipping Container. You can of course use any tools you want for building your app, but these freebies will help you a lot if you decide to make use of them.

Get inspired and brainstorm with AI

The Shipping Container includes tools for ideation and brainstorming. Study real-world UI and UX patterns in Mobbin, and jump over those design hurdles with ease. You can even outright steal the best onboarding and paywall patterns from popular apps, and use them in your app to improve your monetization and app experience.

Put Manus to work to do analysis in the ideation phase and growth phases, by brainstorming with it and using it to build beautiful looking landing pages. You can essentially use Manus as your team member in this hackathon, and you don’t even have to share the price money with them.

Build fast with vibecoding tools

The Shipping Container comes bundled with multiple different AI-assisted tools for building apps as well. You can build your app with Fastshot, Anything, Replit, and Rork, either using the mobile apps or the web based editors they have. All of these tools give you the power to build your idea into a real app, and most importantly all of them make it very fast to do that.

All these tools also support RevenueCat, it’s enough to authenticate with your RevenueCat account and after that you can start telling the AI to add subscriptions, lifetime upgrades, entitlements, RevenueCat powered paywalls and more into your app with just prompts. If you’re feeling lost, take a look out for an in-depth video guide to doing all of this with Vibecode below.

Once your in-app purchases are working, you can explore other payment options. The Shipping Container comes bundled with Paddle as well, so you can add web-based payments alongside your in-app purchases, and experiment with additional monetization paths.

Time to set sail

Now get cracking and go build that winning app. Take a look at the linked and articles and most importantly: build something that people love, but something you love to work on. Don’t lose track of the end goal, building an app, not a concept. Get your app out to people, as soon as you get feedback I guarantee that your productivity will soar higher than in any other way.

The 15% App Store fee you’re probably not paying (but should be)

Tue, 27 Jan 2026 14:10:39 GMT

As a developer, you’ve probably complained about the 30% App Store fee. It feels like a mandatory slice of your revenue that goes straight to the platform holders, just for the privilege of your app existing

But here’s the thing nobody talks about enough: for the vast majority of developers, the 30% fee is a myth

For years now, both Apple and Google have had programs that cut that commission in half, to just 15%. Yet every day I talk to developers who have no idea these programs exist, or they think it’s some complicated process they don’t have time for. They’re leaving tens of thousands of dollars on the table. Money that could be used to hire another engineer, run a marketing campaign, or just, you know, pay the bills

This isn’t some secret loophole. It’s a public program. And if you’re making less than $1 million a year from your apps, you qualify. Today, we’re going to fix this. No more excuses. Here’s your step-by-step guide to claiming the 15% you’ve earned:

The program you need to join right now

Both Apple and Google call it something different, but the core idea is the same: if your annual earnings are below $1 million, you get a reduced commission rate of 15%. It’s that simple

Apple: the App Store Small Business Program

Apple’s program is a lifesaver for indie devs and small studios. It drops the commission from 30% to 15% on everything: paid app downloads, in-app purchases, and subscriptions

The rules:

You must have earned no more than $1 million in total proceeds (after Apple’s cut) in the previous calendar year
All of your ‘Associated Developer Accounts’ count toward that $1 million threshold
If you’re a new developer, you automatically qualify

How to enroll in Apple’s program (it takes 10 minutes):

Go to the enrollment page: first, make sure you are the Account Holder for your Apple Developer account. Then, head straight to the enrollment page
Review your accounts: Apple will ask you to confirm your developer accounts. If you have multiple, you’ll need to list them
Accept the terms: you’ll need to review and accept the latest Paid Applications agreement in App Store Connect if you haven’t already. Then, accept the terms of the Small Business Program

That’s it. Once you’re approved, the 15% rate kicks in. You just gave yourself a massive raise

Google: the 15% Service Fee Tier

Google’s program is just as crucial. They charge 15% on the first $1 million of your earnings each year. If you cross that threshold, the rate goes to 30% for the rest of the year. For most of us, that means a permanent 15% rate

The rules:

The 15% rate applies to the first $1 million in revenue you earn each calendar year
Like Apple, you need to declare your Associated Developer Accounts and create an ‘Account Group’

How to enroll in Google’s Program (also takes 10 minutes):

Go to your Play Console: log in and navigate to the Associated developer accounts page
Create an Account Group: follow the on-screen prompts to create a group. This is where you’ll link any other developer accounts you own
Enroll: once the group is set up, a banner will appear prompting you to enroll for the 15% service fee. Click ‘Review and enroll’
Accept the Terms: read and accept the Terms of Service

Done. You’re now enrolled. It’s a few clicks that will fundamentally change your app’s financial trajectory

The other secret: subscription commission discounts

Okay, so the Small Business Programs are the main event. But there’s another layer to this that a surprising number of developers miss, especially when it comes to subscriptions

Apple: the year-two reward

For auto-renewing subscriptions, Apple has a built-in discount. For any given subscriber, you pay 30% for their first year. But if you can keep them subscribed for a full 12 months, Apple rewards you by dropping the commission to 15% for that subscriber’s second year and beyond

Of course, if you’re in the Small Business Program, you’re already paying 15% from day one. But if your app grows and you graduate out of the Small Business Program, this year-two discount becomes incredibly important. It’s a direct incentive to focus on long-term retention

Google: 15% from day one

Google simplifies things. For all auto-renewing subscriptions on Google Play, the service fee is 15% from day one. It doesn’t matter if you’re in the reduced fee program or not. It doesn’t matter if it’s the subscriber’s first month or their third year. For subscriptions, the rate is 15%

This is a huge advantage for subscription apps on Android, making the unit economics much more favorable right from the start

Here’s how that breaks down:

Platform & program	Subscription commission (year 1)	Subscription commission (year 2+)
Apple (standard)	30%	15%
Apple (Small Business Program)	15%	15%
Google Play (all developers)	15%	15%

Telling RevenueCat about your enrollment

If you’re using RevenueCat, there’s one more step you’ll want to take: letting RevenueCat know you’re enrolled in these programs. This ensures your charts, metrics, and integration data all reflect the correct commission rates

For Apple

Since a developer could have multiple apps from different companies in their RevenueCat account, the Small Business Program status is set on a per-app basis. Here’s how to set it up:

Go to your RevenueCat Dashboard: select ‘Apps & providers’ at the bottom of the left navigation sidebar
Select your App Store app: scroll down and expand the Apple Small Business Program dropdown
Enter your entry date: this is the effective date your membership began. If you enrolled before December 18, 2020 and were notified by December 30, 2020, then enter January 1, 2021
Add an exit date (if applicable): if you’ve left or been removed from the program, enter that date here

Once you save, RevenueCat will correctly calculate your proceeds in charts and send accurate pricing data to your integrations. If you set the entry date in the past, charts will recalculate within 24 hours.

For Google

Good news: RevenueCat automatically assumes you’re enrolled in Google’s reduced service fee tier. For subscription transactions, RevenueCat uses the 15% rate by default

If you cross the $1 million threshold during a calendar year, RevenueCat will automatically switch to the 30% rate for the rest of the year. If you have multiple apps or have transferred apps and the calculation seems off, just reach out to RevenueCat support and they can manually adjust your project’s service fee rate

Stop leaving money on the table

That’s it. No complex legal battles, no risky side-loading schemes. Just two official, easy-to-join programs and a clear set of rules for subscriptions that can save you half of your commission fees

If you take one thing away from this post, let it be this: check your enrollment status right now.

For Apple: go to your App Store Connect agreements
For Google: visit the Associated developer accounts page in your Play Console
For RevenueCat: head to your app settings and confirm your Small Business Program status is set correctly

If you’re not enrolled, take the ten minutes to do it. It will be the highest ROI you get all year. You’ve built a great app; you deserve to keep the revenue you’ve earned

Ship early, learn faster: speed as a strategy for early-stage app growth

Wed, 21 Jan 2026 16:45:08 GMT

We’ve all been in a meeting and had this question asked over and over again:

“When will the experiment go live?” The dream answer: “It already did.”

The reality? A familiar list of reasons and delays that you awkwardly have to explain to a Zoom-ful of people:

We’re waiting on development
We still need someone else’s sign-off
Brand isn’t happy with the design yet

When this happens once, it’s not the end of the world. But when moving slowly becomes the default, it compounds. Especially for startups, where every delay means less learning and a shorter runway.

There’s the ‘ideal world’ we’re often taught: all stakeholders aligned, experiments neatly queued, and decisions made only after lifetime value has fully played out.

And then there’s reality… every month costs money, most early ideas won’t work, and waiting for perfect data often means waiting too long.

At some point, you have to let go of rigid rules and choose fast feedback over perfect planning. That’s uncomfortable, but it doesn’t mean being reckless; it means being intentional about where you move fast, where you slow down, and how quickly you decide what to learn from.

Here’s what you’re about to learn (and hopefully actually use):

The hidden risks of waiting for certainty
Why fast feedback beats false confidence
When to kill experiments early
How to ship faster without breaking trust
And when slowing down is actually the right move

Certainty is what you get after shipping

I once worked with a client testing a landing page as part of a pre-launch experiment. The founder was a designer with an incredible eye for detail, and I joined her in double- and triple-checking every element. We’d done the work: months of research, competitor analysis, and even a painted-door test to validate interest before committing to a full build.

Then the page finally went live. Celebration time!

We waited for the pre-launch commitments to roll in. The painted door test (which gauges interest by showing a feature or offer before it exists) had signaled demand, so expectations were high. But almost nothing happened. No meaningful subscription sign-ups.

What we did learn, quickly, was far more valuable:

Meta ads were extremely expensive at that time of year, and we needed more video content to build trust and lower costs
People hesitated at the subscription price, so we introduced an intermediate step first, and found that it converted better

We’d done everything ‘right’ to build confidence before launch. But certainty about what worked and what didn’t only came after shipping, once real people interacted with the page.

This is where many growth teams get stuck. Early on, most bets are wrong. You’re operating with limited data, few returning subscribers, and barely any meaningful lifetime value (LTV) signal. Monetization metrics at this stage are directional at best, and not something you can wait on with confidence.

Early monetization decisions aren’t about precision; they’re about momentum. You’re not trying to predict lifetime value; you’re trying to understand whether an offer is viable at all. Signals like trial-to-paid conversion, early churn, or price sensitivity tell you where to look next, not where you’ll end up. Waiting for perfect LTV before acting assumes a level of certainty that simply doesn’t exist yet.

Your simple rule for moving faster

Reid Hoffman describes blitzscaling as prioritizing speed over efficiency in the face of uncertainty. That’s exactly what early growth requires — not recklessness, but a willingness to accept that clarity comes from exposure, not preparation.

We don’t gain certainty by thinking harder or planning longer. We learn by putting things into the world and observing how they behave. I’d love to build a campaign or feature that’s guaranteed to work. I can’t. No one can.

So what’s the strategy?

Your simple rule for moving faster should be as follows:

If the cost of being wrong is reversible and contained, move fast.
If it’s irreversible or erodes trust, slow down.

Growth isn’t about building confidence before you ship, but about earning confidence after you do, which is why fast feedback is critical.

Fast feedback is a competitive advantage

You’ll hear all kinds of stats about early-stage growth: ‘only 20% of what you do drives impact’, ‘only 10% really works’, simply that ‘most experiments fail’… I don’t know the exact number that’s accurate. What I do know, from leading growth at an early-stage startup and working with many others, is how frustrating it is just how much doesn’t work.

The teams that win aren’t the ones with a higher success rate. They’re the ones who find out faster.

Fast feedback isn’t about shipping more features or running more experiments. It’s about constantly asking: what’s the smallest possible way we can test this and learn something meaningful? That might mean testing a value proposition through Meta ads before touching the app, or experimenting with App Store messaging to see which feature focus actually drives conversion.

That might mean questions like:

Which engagement behaviors reliably predict retention?
What early revenue signals indicate higher-value users?
Where do users hesitate before committing?

Most subscription apps know that annual plans typically produce higher LTV than monthly ones. The default response is to push annual as hard as possible, or remove monthly entirely. That may optimize monetization in the short term, but it slows learning.

Streema deliberately did the opposite. As Martin Siniawski has shared, they kept monthly subscriptions prominent so they could see churn sooner, understand what drove real, repeatable value, and actually talk to users who left.

Rules for fast feedback in practice

That’s what fast feedback looks like in practice: prioritizing learning speed over delayed certainty. It means doing the following:

Design tests to fail quickly, not to be statistically significant
Use proxy metrics intentionally, knowing they’re directional, not definitive (but good enough)
Prefer reversible changes over big, one-way launches
Optimize for insight velocity, not just conversion rate and monetization
Create earlier moments of truth, even if they temporarily hurt top-line metrics
Speak to your users rather than just relying solely on quantitative data
Acting on what you learned, even if it isn’t the result you hoped for

Fast feedback isn’t just a product problem. It breaks down when teams can’t make decisions without multiple sign-offs, or when learning has to be approved before it’s acted on. Too many cooks spoil the broth and all that.

So the final rule is simple: build an organization designed for speed, creating autonomy and trust instead of relying on complex sign-offs.

I promise you: fast feedback compounds over time and helps you grow faster.

Kill your darlings… fast, but confidently

The hardest part of moving fast isn’t shipping. It’s the moment after, when you’ve moved quickly, intentionally built a real alternative, and it simply doesn’t work. Like the pre-launch landing page that just wasn’t performing. It’s heartbreaking, and that’s usually when the temptation to ‘wait it out creeps in.

Back to the pre-launch experiment I mentioned earlier. We were about a week post-launch. Long enough for people to convert, long enough to have some data, but not nearly enough to feel officially certain. Still, when I ran the numbers, it was hard to ignore what they were telling us. Even if we improved the creatives and lowered the cost-per-click (CPC), we would still land far above our target cost-per-acquisition (CPA) for driving subscriptions.

At that point, waiting stops being patience and starts just being hope. When early data is that far off, you can be confident it won’t pivot into winner. It might improve a bit, but not enough to justify the time, budget, and attention it would continue to absorb.

That’s why — thanks to a great suggestion from the founder — we didn’t try to patch it up. We killed it, and moved on to a two-step page instead, a fundamentally different setup.

But this is where it gets tricky.

With another client, where I was running an A/B test, I did the thing we’re not supposed to do: I peeked early. The results weren’t great. The new variant was tracking slightly worse than the original. I didn’t like what I saw, but I also didn’t kill it. With only a handful of conversions per variant, there simply wasn’t enough signal yet. In that case, giving it time proved to be the right call, and the variant ultimately won.

There are instances when you need to give experiments time. This is especially true for pricing experiments: the initial conversion rate may suggest a new pricing strategy or package offering is underperforming, but after one–two renewal cycles, you’ll see that overall revenue is up.

So I’m not saying kill all your darlings, but I’m also not saying give everything endless time. Fast shipping and fast learning don’t mean a blanket kill-it-all approach. There are times when you should stop quickly, and times when you should deliberately wait.

Rules for killing your darlings

What helps is being explicit about why you’re continuing or stopping. In practice, this is how we kill our darlings:

Peek strategically, but don’t broadcast early results in a way that invites emotion-driven reactions
Ensure there’s enough data to see direction, even if you’re far from statistical certainty
Run the maths on how far off you are from the target, not just whether something is ‘up’ or ‘down’
See experiments as part of a bigger system, not one-off tests: you can still believe in the hypothesis, even if this execution isn’t it
Decide in advance which darlings deserve more time, such as pricing experiments that need renewal cycles to show their impact

Killing something early isn’t pessimistic. It’s often the most direct way to protect focus and create space for the next, better bet. There’s a real opportunity cost to not killing: every experiment you keep alive is one you’re choosing instead of something else that might actually move the needle.

Think of it like pruning a plant. It feels awful to cut off healthy leaves, but you do it knowing the plant will be stronger and grow better because of it.

Speed doesn’t have to come at the cost of quality or user trust

One of the biggest fears teams have when they talk about moving faster is that quality will inevitably go down. And while that can happen, it’s not what moving fast actually has to mean. Speed doesn’t mean:

Sloppy work
Broken experiences
Shipping things users weren’t ready for

I was advising a client with a community-based app who wanted to improve moderation to ensure the community remained a genuinely good place to be. It was a strong idea, but also a big one. There were multiple concepts on the table, each requiring coordination across backend (to build a scoring system), frontend, design, and product. Because of that complexity, the initiative kept getting pushed out, not because it wasn’t important, but because it felt too big to start.

When we zoomed out, one thing became very clear. The entire moderation system they wanted to build depended on a single assumption: that users would actually provide the input needed to make it work — likes, reactions, or signals about positive and negative interactions. If users weren’t willing to do that, or didn’t behave in the way the system expected, the whole model would either fail or require a fundamental rethink.

So instead of building the entire moderation system, we focused on testing that assumption first.

The first step wasn’t a scoring model or a full moderation flow. It was simply introducing — and observing — whether users would actively use like/reaction buttons when interacting with others. That single behavior would tell us whether the broader idea had a foundation to build on.

If usage was low, the priority wouldn’t be better moderation logic, but understanding how to encourage or redesign that input. If it worked, the team could move forward with much greater confidence.

What does Minimum Viable Product actually mean?

What’s important here is that this didn’t feel half-baked to users. They weren’t exposed to an unfinished system or asked to tolerate a worse experience. From their perspective, they simply had more ways to react and express how interactions felt. In fact, it already gave them a greater sense of control over what good and bad interactions looked like, without needing to know anything about the system being tested behind the scenes.

This is what speed looks like when it’s done well: not rushing to build everything, but narrowing down what you actually need to learn first. What is the smallest test that meaningfully de-risks the idea? Which assumption, if wrong, would make everything else irrelevant?

This is why I like how Ethan Gar reframes the idea of a Minimum Viable Product (MVP):

“People get the minimum viable product idea wrong. They focus on the minimum, but not the viable. If I give you an app whose core functionality is broken, you won’t get value, and it won’t perform. When we are focusing on speed, we are focusing on the simplest viable version that delivers value.”

That distinction matters. The moderation example wasn’t about speed for its own sake or cutting corners. It was about delivering value early while learning which assumptions actually mattered — without overcommitting to complexity too soon.

Of course, as you move faster, things will break more often. That’s part of the trade-off. But most of the time, users won’t even notice. And when you get this right, the value gained from faster learning usually outweighs the cost of the occasional misstep.

Which brings us to the harder question: when is speed no longer the right choice, and when does slowing down actually protect quality and trust?

When should perfection take priority over speed?

Speed isn’t universally correct. There are moments where slowing down isn’t cautious, it’s responsible. Moments when perfection is the right way to ship. These are often situations where a generalist mindset no longer helps, and moving too fast creates more risk than value.

The mistake teams often make is treating perfection as the standard mode of operation, when in reality it should be reserved for specific moments. To move past that tension, it helps to be explicit about which situations actually deserve slowness.

Not all of these will apply to every app or brand, but walking through them helps clarify where slowing down is intentional rather than accidental.

1. Core functionality of your app

When it comes to the core value your app provides, there’s a minimum bar that needs to be met. Not ‘perfect’ in the abstract sense, but good enough that users clearly experience the value early in their journey.

This aligns closely with Ethan Gar’s idea of minimum viable value. The goal isn’t to ship everything, but to make sure what you do ship genuinely works. If users are paying for the app, performance and reliability matter. You can still move fast in how you validate and iterate, but the underlying experience needs to meet a clear standard from the start.

2. Large, one-way technical decisions

Some technical choices are hard to undo. For example, when advising an app considering a transition to Flutter, it became clear just how much was at stake. Migrations like this touch almost everything and create long-term consequences.

This is where slowing down is justified. You want clarity on why you’re doing it, what problem it actually solves, and how success will be measured. A common trap is using a technical rewrite as an excuse to ‘fix everything’, which often leads to long delays.

Perfection here doesn’t mean dramatically improving everything. It often means ensuring the new version performs at least as well as the old one, without introducing instability. That bar is usually lower than teams expect, but still worth protecting.

3. Data privacy and security

Whenever you’re handling user data, speed takes a back seat. This includes privacy, consent, tracking, and compliance. Carelessness here erodes trust quickly, and it’s difficult to recover from.

This is not an area for rough experiments or shortcuts. It’s one of the few places where being overly-cautious is usually the right call.

4. Vulnerable user groups

If your app serves vulnerable audiences, extra care is required. I once spoke to someone working on a mental health app for children (a double dimension sensitive topic).

In cases like this, teams often invest heavily in research and exploration before shipping anything meaningful. That doesn’t mean nothing ever gets released, but it does mean the bar for thoughtfulness and validation is higher, and the cost of getting it wrong is taken very seriously.

5. Brand-defining moments

Some releases don’t just add functionality; they reshape how users perceive the brand. These moments deserve extra care.

A good example is Ladder, a fitness app that expanded into nutrition, repositioning itself from purely fitness-focused to a broader health platform. That’s a significant shift in both competitive space and user expectations.

The first version wasn’t perfect, but it felt deliberately more complete than it strictly needed to be. Features like nutrition input via voice, image, and text were available from the start, rather than offering just one method. That choice wasn’t about speed or scope; it was about ensuring users felt the new positioning immediately.

6. Irreversible decisions (one-way doors)

Jeff Bezos describes decisions as either one-way or two-way doors. Two-way doors can be reversed; one-way doors cannot.

Changing your target audience, fundamentally shifting your app’s purpose, or making promises you can’t easily walk back are all one-way doors. These are moments to slow down, pressure-test assumptions, and be honest about the long-term implications.

7. Proven functionality being rebuilt or scaled

Finally, when something has already been validated, rushing the implementation can be counterproductive. That’s how teams end up with fragile systems, spaghetti code, and a growing backlog of bugs.

I’m painfully aware of this one, partly because my husband works as a developer at an edtech startup and spends a large part of his time untangling exactly these kinds of rushed implementations. The time saved upfront is almost always paid back with interest later.

Speed is the default. Perfection is selective.

Most subscription teams don’t fail because they move too fast. They fail because they wait too long to learn. Certainty doesn’t come from better planning, more sign-offs, or cleaner spreadsheets; it comes from shipping, observing, and deciding.

It’s a balancing act between certainty and risk:

Fast feedback is a competitive advantage, not because it guarantees success, but because it helps you stop wasting time on the wrong things sooner. Speed doesn’t have to mean sloppy work or broken trust. When done well, it’s about narrowing the learning question, testing the smallest meaningful assumption, and moving on quickly when something isn’t working.

There are moments where slowing down is not only justified but necessary. When trust, safety, irreversibility, or core values are on the line. But these moments are the exception, not the rule. For most early-stage teams, speed should remain the default. Perfection is something you apply selectively, when the cost of getting it wrong outweighs the cost of waiting.

How Cem Kansu helped Duolingo scale monetization without breaking freemium

Wed, 21 Jan 2026 13:46:55 GMT

Duolingo is one of the clearest examples of freemium done right. Tens of millions of daily users. A massive free experience. And a subscription business that generates the vast majority of its revenue—without gutting what made the product valuable in the first place.

In this episode of Sub Club, Cem Kansu—former VP of Product at Duolingo—walks through the decisions, trade-offs, and hard calls behind that balance. What stands out isn’t a clever pricing trick or a perfectly tuned paywall. It’s a philosophy: protect the free experience, even when short-term revenue is tempting.

Here are the core lessons every subscription app builder can take from Duolingo’s journey.

Protect the free moat—always

One of the biggest traps in freemium is also the easiest win: take something free, make it paid, and watch revenue spike.

Cem has seen this play out repeatedly—and warns it rarely works long-term.

At Duolingo, the free experience wasn’t just a funnel. It was the product’s moat. Locking too much behind a paywall might boost metrics for six months, maybe a year. But it weakens the growth engine and creates space for competitors to offer what you just took away.

Free value isn’t charity. It’s strategy.

Duolingo’s early success came from doing something incumbents wouldn’t: offering high-quality language learning completely free. Undoing that advantage would have meant undoing the company’s differentiation. So instead of extracting more from free users, the team focused on preserving—and often expanding—the free experience, even when it meant saying no to revenue-positive ideas.

Freemium isn’t a trade-off—it’s the growth engine

At Duolingo, free users were never treated as freeloaders. They were the primary distribution channel.

Word of mouth fueled growth, and word of mouth only worked if the free product delighted people. When free users learned more, progressed faster, and felt respected, they told their friends. That loop compounded.

This is why Duolingo was willing to do something that feels counterintuitive to many subscription teams: move features from paid back to free.

When features like Practice Hub or “Explain my answer” didn’t justify their revenue impact—or became cheaper to run thanks to AI efficiency—the team intentionally took a revenue hit to strengthen the free experience. The short-term numbers dipped. The long-term growth engine got stronger.

That trade-off only makes sense if you believe free users are part of your business, not a cost center.

Monetize with empathy, not extraction

Introducing monetization to a previously free product is as much a cultural shift as a product one.

When Duolingo added ads, the team expected backlash—and they got some. But instead of reacting emotionally to negative reviews, they zoomed out. They measured everything: retention, app closes, review volume per million DAUs, complaint rates across different issues.

What they found was grounding. Ads created noise, but they didn’t meaningfully damage the core experience when done carefully.

The rule was simple: optimize for trust, not ARPU.

Ads only appeared after a lesson—never before, never during. Categories that felt off-brand or unsafe were blocked, even if it cost revenue. Over time, Duolingo went further, partnering directly with advertisers to create custom ad formats that fit the product’s tone and even extended its character-driven world.

The goal wasn’t to squeeze users harder. It was to monetize in ways that felt fair, predictable, and respectful.

A/B test relentlessly—but know when to ignore the data

Duolingo runs hundreds of experiments at any given time. Testing is foundational to how the product evolves.

But Cem is clear: experimentation isn’t the same as outsourcing judgment to dashboards.

Many tests surface uncomfortable trade-offs—revenue up, learning quality down; engagement up, trust eroding slowly. In those moments, the job of product leadership isn’t to follow the green line. It’s to decide whether the result aligns with the company’s long-term goals.

Some of Duolingo’s most important decisions required taking a measurable loss: lower revenue, lower short-term engagement, worse-looking graphs. Those calls often needed senior buy-in because the upside—stronger learning, deeper trust, long-term growth—couldn’t be fully captured by a single metric.

Data informs decisions. It doesn’t make them.

Ads can be strategic—and even creative

Duolingo didn’t just “add ads.” It treated ads as part of the product experience.

Placement mattered. Timing mattered. Quality mattered.

Ads only appeared at natural breaks, never interrupting learning. Programmatic categories were aggressively filtered. And increasingly, Duolingo shifted toward direct brand partnerships, embedding its own characters into ads to make them feel less jarring and more native.

Internally, ads weren’t just monetization. They were another surface to reinforce brand, tone, and user expectations—while still funding free education at scale.

Build for everyone, not a persona

One of Cem’s most contrarian takes: personas are often a liability at scale.

Language learners don’t fit clean buckets. People learn for work, for travel, for family, for identity, for fun. Optimizing for a single “core persona” risks alienating the long tail that actually drives growth.

Instead of narrowing the audience, Duolingo built systems flexible enough to serve wildly different motivations—without forcing users into rigid paths. That inclusivity is part of how the product scaled from millions to tens of millions of users without fragmenting.

The throughline: take the long view

Across monetization, experimentation, ads, subscriptions, and AI, Duolingo followed a consistent principle: build the company you want to exist in 100 years, not the one that looks best this quarter.

That mindset made some decisions harder. It meant leaving money on the table. It meant resisting obvious optimizations. But it also built trust, sustained growth, and a freemium model that didn’t collapse under its own incentives.

For subscription app builders, the lesson is clear:
If you burn your free moat, you burn your future.

🎧 Listen to the full Sub Club episode with Cem Kansu to hear the stories, experiments, and trade-offs behind Duolingo’s monetization journey—straight from the person who led it.

Understanding Google Play’s subscription price changes: a complete guide

Wed, 21 Jan 2026 01:49:31 GMT

Subscription pricing is rarely static. Market conditions change, costs fluctuate, and business strategies evolve. At some point, you will likely need to adjust your subscription prices, whether increasing them to reflect added value or decreasing them to attract more users. However, changing subscription prices on Google Play is not as simple as updating a number in a dashboard.

Price changes affect existing subscribers differently than new customers, require specific notification flows, and must be handled carefully to maintain user trust and comply with Google Play’s policies. Luckily, this article will explain how subscription price changes work on Google Play in-depth. We’ll cover:

Mechanics of changing prices for both new and existing subscribers
Differences between opt-in and opt-out price increases
Notification requirements and timelines
Implementation details (with a walk through example)
How RevenueCat can help manage price changes gracefully across your subscriber base

How price changes affect different subscriber groups

When you modify a subscription price in the Google Play Console or via the API, the change doesn’t affect all users in the same way. Here’s how Google Play handles new subscribers and existing subscribers differently:

New subscribers

For new purchases, price changes take effect relatively quickly, typically within a few hours of making the change. Once the new price is active, anyone who initiates a new subscription purchase will see and pay the updated price. No special handling is required for this group; they simply see the current price when they reach the purchase screen.

Existing subscribers: the legacy price cohort

Existing subscribers are a different matter entirely. By default, when you change a subscription price, current subscribers are placed into what Google calls a legacy price cohort. These users continue paying their original price at each renewal, completely unaffected by the price change. This default behavior protects users from unexpected billing changes and gives you control over when and how to migrate them to new pricing.

This legacy cohort mechanism means changing a price in the Play Console does not automatically change what existing subscribers pay. You must explicitly choose to migrate subscribers to the new price.

Ending a legacy price cohort

When you decide to move existing subscribers from their legacy price to a new price, you use the price migration API. This initiates either a price increase or price decrease flow, depending on whether the new price is higher or lower than what users currently pay.

Using the migration API

To migrate subscribers to a new price, you call the monetization.subscriptions.basePlans.migratePrices endpoint on your backend side:

The migration is specific to each region, allowing you to roll out price changes gradually across different markets or handle regional pricing differences independently.

Price decrease flow

When the new price is lower than what users currently pay, the migration process is straightforward and easy for users. Price decreases are automatically applied without requiring explicit user acceptance.

How price decreases work

When you migrate subscribers to a lower price, Google Play sends email notifications informing users of the price decrease. Users then begin paying the lower price at their next renewal, and no user action is required since the decrease happens automatically.

There is one timing nuance to be aware of: Google Play may authorize payment up to 48 hours before renewal (or up to five days in India and Brazil). If a user’s payment was already authorized at the higher price before the decrease was applied, they will pay the higher price for that renewal but will receive the lower price on subsequent renewals.

Handling price decreases in your app

From an implementation perspective, price decreases require minimal handling. You may want to communicate the good news to users:

Price decreases are generally positive events for users, so your primary concern is ensuring they are aware of the change rather than managing any acceptance flow.

Price increase flow: opt-in increases

Price increases are more complex because they require user awareness and, in most cases, explicit acceptance. The default method for price increases is the opt-in flow, where users must explicitly agree to the new price before being charged.

The opt-in timeline

The opt-in price increase flow follows a specific timeline with distinct phases:

Phase	Duration	What Happens
Freeze period	Days 1 to 7	Google Play sends no notifications; developer can notify users
Notification period	Days 8 to 37	Google Play sends email and push notifications
Effective date	Day 37 onwards	Price increase takes effect; charged at next renewal

The seven day freeze period at the beginning is intentional. It gives you the opportunity to notify users through your own channels before Google Play’s automated notifications begin. This allows you to control the messaging and potentially explain the value users receive for the increased price.

User acceptance requirement

For opt-in price increases, users must explicitly accept the new price. They do this through the Play Store subscription management screen, where they see a dialog explaining the price change and can either accept or decline.

If a user doesn’t accept the price increase before their first renewal at the new price, their subscription is automatically canceled. They retain access until the end of their current billing period, but the subscription will not renew.

Handling opt-in increases in your app

Your app should detect pending price increases and guide users through the acceptance process:

Communicating value during price increases

The freeze period is your opportunity to communicate directly with users about why the price is increasing. Effective communication can significantly improve acceptance rates:

Price increase flow: opt-out increases

In certain regions and under specific conditions, Google Play allows opt-out price increases. With opt-out increases, users are notified of the price change but are automatically charged the new price unless they explicitly cancel or change their plan.

Eligibility requirements

Opt-out price increases are not universally available. Eligibility depends on several factors including regional availability (only certain countries support opt-out increases), frequency limits on how often you can use them, maximum percentage or absolute amount restrictions per country, and additional developer eligibility requirements. Because of these restrictions, opt-out increases should be considered a supplementary option rather than your primary approach to price changes.

Opt-out timeline

The opt-out timeline differs from opt-in increases:

Aspect	Opt In	opt-out
Freeze period	7 days	None
Notification period	30 days	30 or 60 days (varies by country)
User action required	Must accept	Can cancel to avoid
Default behavior	Subscription cancels	New price charged

The notification period for opt-out varies by country. Some require 30 days notice, while others require 60 days. Google Play handles these regional requirements automatically when you initiate an opt-out migration.

Handling opt-out increases

From an implementation perspective, opt-out increases are simpler because users do not need to take action to continue their subscription:

However, you should still communicate clearly with users about the upcoming change, even though their action is not required.

In-app notification requirements

Regardless of whether you use opt-in or opt-out price increases, Google Play requires you to display in-app notices about price changes. This requirement applies across all device types where your app runs.

Mandatory notification surfaces

You must show price change notifications on mobile devices (phones and tablets), Android TV, and other streaming devices. The only exception is watches, where in-app notification is recommended but not strictly required due to the limited screen real estate.

Notification timing

For opt-in increases, the recommended approach is to show your own custom messaging explaining the value proposition during the freeze period (days one to seven), then continue showing reminders and use Google’s In App Messaging API after the freeze period ends (days eight onwards).

Handling overlapping price changes

What happens if you initiate a new price change while a previous one is still pending? Google Play handles this by canceling the previous price change and applying the new one.

The cancellation and replacement flow

When overlapping price changes occur, the old price migration is marked as CANCELED and you receive a SUBSCRIPTION_PRICE_CHANGE_UPDATED Real-Time Developer Notification (RTDN). The new price migration then takes effect, and users only need to respond to the latest price change. This behavior prevents users from being forced to accept multiple sequential price increases, which would create a poor user experience.

Tracking price change status

Your backend should process RTDN notifications to track price change status:

Recovering from accidental price changes

Mistakes happen. If you accidentally change a price or initiate a migration you did not intend, the recovery process depends on the type of change and how much time has passed.

Reverting opt-in increases

For opt-in price increases, the timing of your revert matters significantly. If you revert within seven days (the freeze period), users will not have received any notifications from Google Play, so the change is essentially invisible to them. After seven days, reverting will cancel the price change for users who have not yet been charged at the new price, but some users may have already received notifications, which could cause confusion.

Reverting opt-out increases

For opt-out price increases, reverting to the original price cancels the increase for users who have not yet been charged. Keep in mind the authorization timing. Users whose payment was already authorized (up to five days before renewal in some regions) may still be charged.

Reverting price decreases

If you need to cancel a price decrease and return to the original higher price, start by reverting to the original price in the Play Console and choosing whether the increase should be opt-in or opt-out. The timing relative to user renewals determines the outcome: if the time between revert and user renewal is greater than the notification window (30 to 60 days depending on country), users will pay the original price at their next renewal. If the time is less than the notification window, users will be charged the lower price once, then go through the standard price increase notification flow.

Installment subscriptions and price changes

If your subscription uses installment plans (where users commit to a certain number of payments), price changes behave differently.

For installment subscriptions, price changes only apply at the end of the active commitment period. You cannot change the price for users in the middle of an installment, and the new price takes effect at the first renewal after the commitment ends. For example, if a user is on a 12 month installment plan followed by monthly auto renewal, any price change you make will only take effect after their 12 month commitment completes and they move to the monthly renewal phase.

Testing price changes

Before rolling out price changes to your production subscriber base, you should thoroughly test the flows using Google Play’s testing tools.

Using license testers

License testers can receive price change notifications without affecting real subscribers. Configure license testers in the Play Console and use them to verify notification delivery and timing, in app messaging display, acceptance and decline flows, and state transitions in your backend.

Play Billing Lab

Google provides the Play Billing Lab app for testing billing scenarios. Use it to simulate price change scenarios and verify your app handles each state correctly.

Audit trail

The Play Console maintains a change log of all price modifications. Use this to review when prices were updated, who initiated the changes, and which regions were affected. This audit trail is invaluable for investigating issues or reviewing the history of accidental changes.

How RevenueCat simplifies price change management

Managing price changes across a large subscriber base involves significant complexity. This includes tracking migration status for each user, processing RTDN notifications, displaying appropriate in-app messaging, and handling edge cases. RevenueCat abstracts away much of this complexity while providing additional tools for managing price changes effectively.

Automatic state tracking

RevenueCat processes Google Play’s RTDN notifications on your behalf, maintaining up to date subscription state including pending price changes. Instead of building infrastructure to receive and process notifications, you simply query RevenueCat for the current customer state:

RevenueCat’s CustomerInfo includes a managementURL property that provides a direct link to Google Play’s subscription management screen. This is where users can accept or decline price changes:

Cross-platform consistency

For apps that span multiple platforms, RevenueCat ensures consistent subscription state across Android, iOS, and other platforms. If a user accepts a price change on one device, the updated status is reflected across all their devices without additional implementation.

Webhooks for server side handling

RevenueCat provides webhooks that notify your server of subscription events in a normalized format. This is simpler than processing raw RTDN notifications and includes events related to price changes:

Analytics for price change impact

RevenueCat’s Chart provides analytics that help you understand the impact of price changes, including churn rates correlated with price change timing, conversion rates for subscribers who received price increase notifications, and revenue impact analysis before and after price changes. These insights help you make informed decisions about pricing strategy and identify the optimal timing and communication approach for future price changes.

Best practices with RevenueCat

When using RevenueCat for price change management, focus on proactive communication by using customer attributes to identify users with pending price changes and send targeted communications during the freeze period. Monitor key metrics such as the conversion rate from price increase notification to acceptance and the churn rate among affected users. Always provide users with an easy path to the Play Store subscription settings via the management URL. Finally, leverage RevenueCat’s normalized data to handle edge cases gracefully, such as users who change plans during a pending price increase.

Best practices for subscription price changes

Based on the mechanics we have covered, here are key practices to implement for successful price changes:

Plan your communication strategy

Before initiating a price change, plan how you will communicate with affected users. Prepare messaging that explains the value users receive, decide whether to use the freeze period for custom outreach, and consider offering alternatives such as annual plans or grandfathered pricing for users sensitive to price changes.

Use regional rollouts

If you are increasing prices globally, consider rolling out changes region by region. Test in smaller markets first to gauge response, adjust messaging based on early feedback, and allow time to address issues before they affect your largest markets.

Monitor acceptance rates

Track how many users accept opt-in price increases versus letting their subscriptions cancel:

If acceptance rates are lower than expected, you may need to adjust your communication strategy or reconsider the price increase amount.

Provide alternatives

Users who are unwilling to pay the higher price may be willing to continue at a different tier. Consider offering a downgrade path to a plan with lower pricing, providing an annual option at a discounted effective monthly rate, or creating a ‘lite’ tier that retains users who would otherwise churn.

Handle the transition gracefully in your app

Ensure your app gracefully handles all states during a price change. Users with pending price increases should see clear messaging, users who decline should not lose access immediately, and the transition between prices should be seamless for users who accept.

Conclusion

Subscription price changes on Google Play involve a carefully orchestrated process designed to protect users while giving developers flexibility. The key concepts to understand are the legacy price cohort that shields existing subscribers from automatic price changes, the distinction between opt-in and opt-out price increases and their respective timelines, the notification requirements that apply across device types, and the regional variations that affect timing and eligibility.

For price decreases, the process is straightforward. Users automatically receive the lower price at their next renewal. For price increases, the default opt-in flow requires explicit user acceptance, with a seven day freeze period followed by 30 days of Google Play notifications before the effective date.

Implementing price changes directly requires processing RTDN notifications, maintaining subscription state on your backend, and building UI to guide users through the acceptance process. RevenueCat simplifies this by handling notification processing automatically and providing normalized data, analytics, and the management URL for user actions, so you can focus on your business and more important work.

Whatever approach you take, successful price changes require clear communication with users about the value they receive. The freeze period is your opportunity to control the narrative before automated notifications begin. Use it wisely, and you can maintain user trust while adjusting your pricing to reflect the value your app delivers.For complete documentation on subscription price changes, refer to the official Android Developer documentation and RevenueCat’s subscription management guide.

How subscription apps can use hybrid monetization to capture more revenue

Mon, 19 Jan 2026 12:10:22 GMT

Hybrid monetization means combining subscriptions and additional ways to earn money from users — think in-app purchase (IAP), consumables, ads, or partnerships.

But before we go much further, I want to emphasize something: the goal isn’t to replace subscriptions. It’s about complementing them. As different users discover, use, and leave your app, hybrid monetization captures as many of them as possible.

Why hybrid monetization? The limits of subscription-only models

I’ve been advocating for hybrid monetization for a long time because acquisition is essentially a business model competition: more ARPU = a better position in the paid auctions, faster payback, and more margin to invest in retention, onboarding etc. So while subscriptions are great, they come with a fundamental flaw: a high floor, low ceiling nature (more on this in a moment).

Subscriptions are binary: pay, or don’t.

But real demand is not binary — it’s distributed across willingness to pay.

Based on the graph above (from the State of Subscription Apps 2025), it’s expected that 90% of users won’t convert, and for a number of verticals, regions, and non-iOS platforms, it gets even worse. Last year, I saw an app attract over a million users in one country, only to get less than 1,000 paying subscribers!

The problem is that a single recurring price assumes that most users have roughly the same willingness to pay. But in reality, some users are happy to pay a premium, others get occasional value but can’t justify a recurring commitment, many will never subscribe at all.

This creates two common blockers:

The high-ceiling problem

A single offer presents too much friction for low-intent users. You can try to discount it or shorten the subscription length, but some users (such as Android users in developing countries) still won’t engage.

Many will never subscribe. They still generate value (attention, data, virality), and some may be willing to be something — if offered differently (enter in-app purchases, for example) or at a lower price point.

Problem: you’re leaving revenue on the table from low-intent users. Users who value the app, but won’t cross the psychological or financial barrier of a subscription.

The low floor problem

Maybe even worse than a high ceiling… The majority of subscription models have no ‘whales’ (aka, mega spenders). Gaming apps, who pioneered hybrid monetization (typically IAP + ads), can see a handful of users accounting for a large share of revenue, even if other users contribute less. For example, I once saw numbers from a large ‘match three’ game showing that <2% of its 2% payers (i.e. 0.04%) actually generated more than half of revenue. Subscription-only apps lose this possibility.

Problem: you under-monetize high-intent users, as your subscription price can’t move higher without hurting conversion of other users.

At its core, hybrid monetization is about matching price granularity to demand granularity.

Adapting to the demand curve

Most apps serve users with very different levels of intent, frequency, and urgency. A single subscription price flattens those differences.

Visually, you can think of your audience as a demand curve:

On the left: users willing to pay more for power, speed, or convenience
On the right: users who won’t pay anything
In the middle: users who want value occasionally, but resist subscriptions=

Hybrid monetization places the correct monetization lever at the ideal point on that curve, for every user, and avoids forcing everyone into the same choice.

The demand curve of app monetization is extreme, and could be represented this way:

By choosing a single point on the line, binary subscriptions models are leaving a lot of money on the table:

There are a variety of options to improve the offer and increase ARPU by adapting to your demand curve. Here are some of those levers:

Techniques for hybrid monetization (with app examples)

All the instances of hybrid monetization that I’ve worked on and observed keep subscriptions as the core center of gravity, then add layers on top. Let’s go through some examples.

1. Pricing and packaging

I won’t go into this in much depth, but the most obvious and first step towards more sophisticated monetization is adjusting pricing and packaging. This is already happening a lot, thanks to increasingly-easier ways to A/B test paywalls.

In this step, developers can (and should) experiment with different pricepoints, combinations of plans (e.g. how many plans do you offer? Are they weekly/monthly/yearly?), segmentation (which I predict will finally become a thing thanks to AI after years of lag), price localizations etc.

A fairly extreme example is the discount flow from Headway, which moves offers all the way from €89.99 to €21.99 in my personal case:

2. Subscriptions tiers

While offering multiple tiers of subscription isn’t strictly ‘hybrid’ (as it’s still only subscriptions), it moves towards hybrid monetization by adjusting to the demand curve.

Software-as-a-service (SaaS) businesses have done this successfully for some time by offering tiered-features to different user profiles. One example is Photoroom, which offers Photoroom Pro, Max and Ultra to different segments of users , based on usage patterns.

Subscription behemoths Noom and Tinder both user tiers as well:

While not strictly a subscription tier per se, many developers with a portfolio of different apps choose to bundle as a way to upsell a higher pricepoint. Examples include Monkey Taps (in-app and in the app stores) or Reflectly (on web).

3. Subscriptions + ads

Ads are maybe the most obvious ways to monetize the 90% of users who show zero willingness to pay for anything (regardless of pricepoint). I remember trying a 99% off discount only to have little incremental uplift on conversion rate. If you have users like this, supplementing with ads can be a good technique.

A well-known example of this use case is subscription role model Duolingo, who combine their core freemium offer with ads, plus premium plans to remove ads, and IAP. Some case studies suggest developers can expect revenue uplift of 10-30% with subs + ads, depending on their user base and execution.

However, it’s worth bearing in mind that revenue here is limited for hard paywall apps. Spotify, for example, makes less than 5% of its revenue from its majority users: free users who put up with ads. In another case I worked on it was as low as 1%.

Considerations when implementing subs + ads

Privacy laws, apps with ad SDKs, effect on churn and many more things should be considered when including ads in your app. Some good resources to look at are:

Techniques for subscription + ads

Some apps think of ads not as a way to add revenue, but a way to create friction and promote the ad-free offering: a subscription. For instance, Impulse prompts users to remove ads in different strategic places:

In this flow (from GrowthGems), you can see how closing the ad triggers a subscription paywall with weekly and lifetime plans. When closed, there’s then a non-renewable IAP to remove ads for $4.99!

Gaming experts Matej Lancaric and Felix Braberg have agood video analyzing Impulse’s hybrid model. You can also use ad placements to promote your own subscription: this video shows Duolingo’s ad break — two ads show, one for NYT Games, then one for Duolingo MAX. It’s a bit meta, but it can work!

Finally, a simple banner can go a long way, like in this example from park4night (which interestingly drives to an off-store, even outside the US).

4. Subscriptions + partnerships

By ‘partnership’, I mean an alternative to the common ads model sold via SDK with partners such as Applovin, Unity or Admob. In specific verticals, partnering up with a relevant brand can yield significant impact — and potentially revenue — depending on the vertical, as they may add value, including for premium customers.

See for instance Strava’s Sponsored Challenges:

Such partnerships can be implemented at very different trigger points of the journey, as illustrated below with Prematch:

5. Subscriptions + ecommerce/affiliates

As mentioned earlier, one of the limits of the subscription-only model is that it doesn’t offer your bigger power users and ambassadors any opportunity to engage further with the brand. So one way to supplement subscriptions is by adding ecommerce or affiliate strategies.

For example, a few mega fans might be willing to buy brand swag or physical goods, like Lingokids:

Sometimes, the ecommerce opportunity lives within the product, such as the anglers’ social network app, Fishbrain, having a marketplace:

As a more indirect tactic, you can partner with other businesses to offer deals or discounts to your users, like Revolut does:

6. Subscriptions + consumables/one-off in-app purchases (IAPs)

Finally, here is the biggest potential uplift (for most apps): offering consumables and one-off IAPs alongside your subscriptions. These have great rewards for app businesses, yet are still vastly underutilized.

RevenueCat’s State of Subscription Apps 2025 report shows limited use of consumables — except in gaming (~40%) — with only 5–15% of apps using these monetization models.

While few apps are taking this route, the few that do monetize much better: a recent stat showed that hybrid buyers make up only 7% of buyers, but generate 25% of total revenue.

Non-renewable/consumable items fit many use cases that subscriptions don’t cover, either substituting for a subscription (which wouldn’t be purchased) or slotting on top as an additional spend. Depending on the app, those consumables may be very different things — one example is ‘boosts’ which are pretty common in dating apps or marketplaces, such as Tinder or Wallapop:

In-app purchases can also be used to enable price-sensitive users to unlock premium features individually, or for a limited time. For instance, one learning app I worked with added a one-time IAP which granted access to all content for a couple of days (a ‘weekend pass’). We also added IAPs to gain access to very specific lessons without having to unlock the rest of that content tier.

Consumables can also be upsells, which have proven particularly effective in the health and fitness space; for example, guides to train specific body parts, certain individual coaches, dedicated workout or meal programs… These are sometimes even sold as a direct upsell right at onboarding, though this is a tactic I’ve seen work better on web (once the payment is recorded) than in-app.

The possibilities for IAP are endless: Nebula sells one-off tarot readings and 1:1 chats with psychics, Duolingo offers individual tests and certifications. Many apps offer tipping, stickers, customization, and more.

One caveat for consumables, and probably the elephant in the room here, is AI.

Because AI comes with significant costs, the cost of use can vary massively between users who are charged the same. Maybe the first hybrid AI model I’ve seen was Lensa AI, which was selling 200 AI avatars for $9.99, but entering the subscription allowed you to get 50% off the credit price. (I thought it was interesting that they specify why it’s a paid feature.)

Alongside tiered subscriptions like ChatGPT, these single-payment purchases for extra use are becoming more common among AI apps.

7. Pile them up: combine hybrid monetization options

Hybrid options are additive, not mutually exclusive, so why not stack them? The most advanced subscriptions apps don’t just pick up one way to upsell — they combine several.

This diagram from Phil Carter, creator of the Subversive podcast and the famous Subscription Value Loop, shows how Tinder adapted to the demand curve. Ravi Mehta, Former Chief Product Officer at Tinder, spoke about their strategy in depth on the Sub Club podcast — I highly recommend giving it a listen for examples of hybrid monetization in action.

Here are some ways you can combine multiple non-subscription revenue streams.

Offer everything!

For instance, weightloss app Simple offer users an upsell to skip the trial period, then offer different subscription tiers, and then also offer one-off purchases for in-app guides. It’s a lot.

Me app also has a similar pattern, with coaching, goodies, and upsells in addition to the core subscription:

Bundle physical and digital goods

Another innovative example, albeit less common, is to bundle digital and physical goods. This feels suited to luxury brands or designers, but it could work for any app. Arya does this in its initial offering and later through store upsells:

While the specifics of those examples differ, the logic is the same: it’s hard enough to convert users into paid subscribers, so if there’s an opportunity to monetize subscribers in extra ways, take it. Demolish that low floor and find your big spenders, even if they’re few and far between. If there’s an opportunity for a big ARPU increase, whether on the spot (e.g. onboarding) or later (e.g. merch), it’s worth pursuing.

Offer them even more

More and more subscription businesses operate beyond pure B2C models, often with a mix of end consumer, ‘prosumer’, small businesses, and even larger businesses. This is particularly common in graphics, photo, and video tools. One example is Photoroom: on top of its several subscription tiers, Photoroom offers B2B plans for clients that go beyond heavy user requirements:

Caveats and considerations before implementing hybrid monetization

Hybrid monetization isn’t a free win, it takes planning and practice. And like anything in app monetization, there are risks. But the most common blockers are predictable:

For users, choice overload can hinder conversion

Every new monetization path should earn its place, especially at decision points. Otherwise you risk too many options leading to no decisions. How and when the options are offered is critical. For example, Netflix has found when it shows more than seven titles per row, user engagement drops. This is also a good blog detailing examples of Hick’s Law and other choice overload instances, featuring the likes of Duolingo, Zapier, Airbnb and Trello.

For developers, complexity creeps up quickly

More SKUs = more logic and more edge cases.

This might be the biggest caveat: hybrid monetization is definitely not for everyone. Hybrid models fail more from organizational structure than product design: various teams will see their current KPIs affected, so new alignment needs to happen between monetization, UA, and product teams.

Offering multiple options requires stronger product, data, and ops discipline, and can add up on data and tech debt quickly — especially if many rounds of experimentations are required to find what clicks with your audience from the get-go.

For many earlier-stage or smaller teams, this is actually a very good reason to stick with a pure subscription model initially.

Hidden signals and risk of cannibalization

Measuring the actual uplift of hybrid monetization might look straightforward, but it isn’t! Discounts can be detrimental. Poorly designed IAPs can undermine subscriptions. Aggressively-priced consumables can just be shifting revenue to earlier (which arguably, is still great for cash flow even under similar LTV), but hurt renewal revenue later and eventually decrease LTV. Ads could inflate short-term ARPU while depressing long term retention and late conversions.

Even simple pricepoints changes can have multiple, long-lasting impact on renewals, retention, upsell potential.

In short: be conscious of the analytics required before jumping in — hybrid monetization creates some of the most convincing false positives.

Country and culture dependencies

There’s a massive monetization gap in subscriptions between platforms (this is the reason the Google Play team was an early advocate for mixed models). For example, low-amount IAPs are often more impactful on Android than iOS, due to different user profiles and intent.

Payment habits, ad tolerance, and price sensitivity also vary massively by location. Spotify didn’t scale meaningfully globally for some time, while Tencent music (which offers pay-per-song, one-off purchases, and tipping) is a global success. Some cultures are currently just more reluctant to engage with long-term subscriptions (e.g. China), while others are skeptical of silent auto-renewals (e.g. Germany), so mixed models can benefit hugely in these contexts.

On top of local habits, you have specific regulations, from Japan and Korea’s 2025 changes plummeting renewal rates, and California’s ‘click to cancel’ law being proposed.

Wrapping up: is your app ready for hybrid monetization?

We’ve covered a lot. You have many potential frameworks for hybrid monetization, and many pros/cons to consider before getting started. So to finish up, here’s the questions to ask yourself before introducing a new revenue stream:

Do we clearly understand who our high-, mid-, and low-intent users are?
Do we have reliable cohort-based retention and revenue data?
Can we run clean experiments without stacking changes?
Do we know which metric we’re willing to trade off — and which we aren’t?

If you can’t answer these yet, fix that first. Hybrid monetization only works if you introduce it deliberately. Otherwise, it’s messy, chaotic, and reactive. Don’t get caught out misreading misread short-term gains while harming long-term retention.

Hybrid monetization works when:	Hybrid monetization is *not*:
You have a large group of users who get value but won’t commit to a recurring price Your users’ willingness to pay varies widely You want to increase ARPU without relying solely on higher subscription prices	Throwing every possible paywall and ad format at users A shortcut to growth without proper measurement A substitute for a strong core subscription offering

Remember there is no hack: Hybrid monetization is not a shortcut to fixing poor ARPU. If subscriptions aren’t delivering clear, repeatable value, adding more monetization layers will only make things worse. Bad products monetize badly, and they will only do so in more ways with more sophisticated models.

NaadSadhana — the app that teaches classical music like a guru

Wed, 14 Jan 2026 13:51:40 GMT

When a long-time student still couldn’t distinguish close intervals, Sandeep Ranade didn’t write another lesson plan — he wrote code. NaadSadhana blends Indian classical music with real-time, AI-assisted feedback so vocalists can train like professionals. This is how passion, patience, and purpose shaped the product.

From Microsoft to music mastery

“I’m from Pune… I did my master’s in computer science from Johns Hopkins University in America in Baltimore. I’ve worked at Microsoft… then at Google,” Sandeep says. After more than a decade in Silicon Valley, he and his wife — then at Apple — moved back to India “to do something that we were interested in, that we wanted to do.”

He had been teaching Hindustani classical music since 2005. “There was a student … she said, please help me. I’m frustrated with my journey. I’m not making any progress.” That single conversation revealed the problem that would define his next decade.

Solving a real problem, one note at a time

“In the first 10 minutes, it became painfully clear that she had major problems in note recognition itself,” Sandeep recalls. “She couldn’t recognize half of them. She would just know the big ones and then all the minor notes she would sort of miss out on.”

A doctor ruled out tone deafness, leaving Sandeep to diagnose the issue himself. “She had gotten into some bad habits … when she was learning and practicing, she didn’t get enough guidance to course-correct as she was making the mistakes. So those mistakes became the habit.”

He wanted a tool that could give her feedback whenever she practiced — something a human teacher couldn’t provide around the clock. “I thought, hey, it’s 2017. There must be an app that does this by now.” But, he found, “sadly, there was no single app that did this for human vocals. There were thousands of guitar tuners on the App Store, but not a single app that did human vocal tuning and guidance.”

To fix that, he dove deep into digital-signal processing and psychoacoustics. “It took my iPhone 7 Plus battery from about two days to 20 minutes. I could have probably made an omelet on my phone,” he laughs. After nine iterations, he finally had “an algorithm that was correct, accurate, fast, and battery efficient.”

When he tested it with his student, the results astonished him. “She was able to go from a score of 5 percent to 80 percent. It took her two weeks. I was not expecting this.”

Tech meets tradition

“There was an ancient system of learning in India called the guru-kul. Guru is the teacher, kul is the home. So the student would go live with the guru traditionally and learn the craft for years and would be instructed and guided for eight, ten hours a day or more.”

That continuity, he says, produced extraordinary precision. “Today, students are learning an hour a week, practicing by themselves many times a week without any guidance. And the danger is that if you practice something multiple times without knowing whether you have gotten it right or not, that is where things start to become kind of dangerous.”

NaadSadhana became a digital re-creation of that traditional mentorship — a tireless teacher able to correct singers in real time.

Building slowly, scaling sustainably

“I never realized that an app needs to be promoted and there’s marketing involved,” Sandeep says. “I just put it up on the App Store … I probably broke even on my developer fees.”

Early users spread the word organically. “Some people said to other people that, ‘Hey, I’ve been using this app, my notes are improving.’ I told it to a few people that I know and that was it.”

In 2021, that quiet persistence led to worldwide recognition. “I attended the Apple Design Award ceremony [as an audience member], looking at all of these beautifully designed apps … and in 2021 NaadSadhana won for innovation. I’m only the second Indian to ever win this award.”

Evolving the sound of the future

“I’ve had offers to buy out the app, and the only question I ask them every time is: What feature would you add next? … It now truly seems that I’m the only person who’s passionate enough to evolve this app in the way that I care about.”

For Sandeep, NaadSadhana is an artistic calling, not just a product. “There are things that people don’t know that I’ve done that will not matter to the vast majority of people, but it’ll matter to me. From a business point of view it’s not truly necessary, but from an artistic point of view it makes the world of a difference.”

What app builders can learn from NaadSadhana

“I typically tend to solve problems for me or people who are close to me,” he says. “Because I am the first customer of my solution … there are no compromises.”

That builder-first mindset shaped every decision. “It has to behave a certain way … nothing less than that will be acceptable.”

And rather than chase growth, he focused on depth. “I was focused more on the feature set and capability of the app … I thought that the more capable I make the app, the more attractive it’ll be to people … and that has been happening.”

Final takeaway

Sandeep calls NaadSadhana’s underlying technology “artistic intelligence.” “What my app is doing is enhancing humans. I’m giving them a flight simulator, not a self-driving car.”

That philosophy extends to accessibility. “Music without any barriers, without any boundaries,” he says. “Just because a person doesn’t have eyesight shouldn’t make it a barrier to be a musician or to create content.”

NaadSadhana shows how technology can deepen — not dilute — tradition. Design for mastery, not virality, and you’ll earn trust that lasts.

Introducing one-tap purchases for paywalls on the web

Tue, 13 Jan 2026 17:01:11 GMT

Your customers already decided to buy.

Checkout is where too many of them slow down, hesitate, or drop off.

Express Checkout adds a native wallet purchase button directly to your paywall when it’s shown in the browser, so customers can complete a purchase in one tap without being sent to a separate checkout page.

Checkout slows customers after they’ve already decided

By the time someone reaches your paywall, the work is mostly done. They understand the value, they’ve accepted the price, and they’re ready to move forward.

Then the flow asks them to leave.

They wait for a checkout page to load, choose a payment method, re-enter information their device already knows, and confirm a decision they already made. None of those steps build confidence or clarify value. They only introduce delay.

Checkout doesn’t persuade. It drains momentum at the exact moment it matters most.

Moving the purchase onto the paywall removes a full step

In a typical web flow, the paywall creates intent and hands customers off to another page to finish the purchase.

With Express Checkout, the purchase completes where the decision happens.

Customers tap a native wallet button on the paywall and the transaction is done. There’s no redirect, no form entry, and no extra decision between “yes” and “paid.”

That change removes an entire page from the funnel and several chances to abandon. It isn’t a visual tweak or a copy experiment. It’s a structural improvement to how purchases work in the browser.

What Express Checkout does

Express Checkout adds a native digital wallet button directly to your paywall when it’s shown on the web.

The component automatically renders the right option for each user, such as Apple Pay on iOS or Google Pay on supported Android devices and browsers. When a customer taps it, the device’s native payment prompt appears immediately and the purchase completes without going through the standard checkout flow.

On mobile, this feels closer to an in-app purchase than a traditional browser-based flow. The most failure-prone step in the journey disappears.

See the docs for configuration steps and wallet requirements.

It works for web, app-to-web, and web-to-app flows

Express Checkout improves conversion anywhere a paywall is the moment of decision.

Pure web entry

A customer taps an ad, a social post, or a link in your newsletter and lands on a paywall in the browser. They read the offer, decide it’s worth it, and complete the purchase immediately using their device’s native wallet. There’s no detour into checkout and no quiet moment where a new page loads and the impulse fades.

App-to-web completion

A customer starts in your app, hits a paywall, and finishes the purchase on the web. Instead of landing on a checkout page that feels disconnected from the decision they just made, they arrive at a paywall in the browser that mirrors the offer and lets them complete the purchase in one tap. The transition feels continuous rather than transactional.

Web-to-app journeys

A customer discovers your product on the web, purchases through a paywall in the browser, and then continues into the app. Even though the journey spans platforms, the purchase step stays fast and familiar. The paywall acts as a clean entry point, not a temporary stop.

In every case, the benefit is the same. When customers reach your paywall in the browser, Express Checkout removes unnecessary steps at the exact moment they’re ready to buy.

Standard checkout stays available automatically

When a native wallet is available and supported on the user’s device and browser, Express Checkout appears on the paywall and completes the purchase directly.

When a native wallet isn’t available, customers see a standard purchase button and continue through the full checkout flow as usual. Both options can coexist, guiding users to the fastest path while always preserving a reliable fallback.

Taxes, compliance requirements, and edge cases are handled behind the scenes. You reduce friction when you can, without ever blocking a purchase when one-tap payment isn’t available.

Full setup details, supported wallets, and fallback behavior are covered in the Express Checkout docs.

Get started

If you’re already using RevenueCat Paywalls on the web, you can add the Express Checkout in the Paywall Builder.

If you’re new to selling on the web, this is the fastest way to offer a one-tap purchase experience in the browser. It works with your existing products, trials, and offers, you’re changing the last step of the funnel, not your pricing model. We’ll share conversion results once teams start running experiments, and this same button also lays the groundwork for more advanced app-to-web paywall flows coming next.

5 web-to-app funnel examples that actually convert

Mon, 12 Jan 2026 15:11:46 GMT

We all say you shouldn’t copy your competitors, but the truth is, a handful of great examples can save you a lot of time. When it comes to web-to-app, some subscription apps have been doing this long before it was trendy, tirelessly testing and optimizing their funnels along the way. Besides, didn’t our parents always say imitation is the sincerest form of flattery?

To help you on your own web-to-app journey, here are a few of my favourite examples — plus what you can learn from them. Because there’s no point copying a funnel if you don’t understand why it works, or how to adapt it to your own brand. And don’t worry, this isn’t just a list of quiz funnels. There are plenty of ways to approach web-to-app, so we’ll cover a variety of funnel types.

That said, let me start with one of my favourite quizzes, and then I promise we’ll move on to some alternative approaches.

1: Calm’s web-to-app quiz funnel

Web funnel type: web quiz → trial offer → app install

Let’s start with what Gen Z would call the GOAT of quiz funnels (Greatest Of All Time, according to my little sister). Calm, the meditation app has long been a standout example of a web-to-app quiz funnel: simple, elegant, and remarkably effective.

I reviewed every quiz variant to understand why this flow has remained largely unchanged for years. Here’s what the full funnel looks like, but don’t panic at the sheer detail. I’ll walk you through it step by step. If you want to explore this flow (or any of the other examples) at your own pace, you can see them all in their full flowchart glory here.

The first thing to note is that Calm only truly personalizes the sleep flow; the other four options all lead to a standardized journey. This is a great example of intent-based segmentation, dividing up users according to their goals. Sleep is a high-urgency, emotionally-charged problem, so it makes sense to invest in deeper personalization. The other goals are more exploratory, so a lighter-touch flow is a pragmatic choice.

This is a tactic I often recommend to app testing teams: don’t try to personalize everything at once. Start with your highest-priority audience, then measure, learn, and iterate from there.

The sleep quiz flow

Let’s walk through the sleep flow first. It starts by asking how frequently you face this challenge.

It does something simple but effective: it gives immediate feedback on your answer.

This isn’t a separate screen; it’s a quick reassurance: “You’re in good hands.” From there, the quiz delves deeper, distinguishing whether you struggle to fall asleep or stay asleep, before exploring potential causes of your sleep challenges.

As a struggling insomniac, this felt great. There’s no judgment or irrelevant questioning, just a respectful interest in my challenges. I also like that you can select multiple options for both questions, rather than being forced to choose just one.

Next, a relevant review appears from someone I can relate to. The imagery and name make it feel personal, though not knowing the source slightly undermines its credibility. That said, Calm’s brand is already well known in the space, so the funnel doesn’t need to lean heavily on social proof beyond a simple, relatable review.

I also appreciate that Calm asks for context: Am I trying to sleep right now? Too often, we assume someone is using an app the moment they open it, when for many fitness and wellness apps, that may not be the case.

Interestingly, selecting either option doesn’t change the immediate next steps. But I can imagine it influences what comes later in the flow; for example, what Calm sends or shows you after signing up, like a general meditation versus a sleep story tailored to the moment.

Next, they ask you to set your preferences for the type of content you’re interested in. My only issue is that you may not yet know what you want; you may simply be seeking recommendations or open to exploring. Calm could do a better job of highlighting their suggestions and explaining why they recommend these.

Before we move on to the final screens (which are the same for all flows), let’s take a look at what happens when you select one of the other options:

Reduce stress or anxiety
Improve focus
Self-improvement
Something else

Calm’s alternative quiz flow

I tested all four options and ended up with the same flow each time. It starts with a clarification question about how I’m feeling, accompanied by the same kind of reassuring feedback used in the sleep flow.

Here, the flow first explores the cause — interestingly — and then loops back to dig deeper into understanding the problem.

We see a similar review slide again; this one is quite generic and doesn’t change across different responses. Given what I’ve shared so far, I would have expected a bit more personalization.

I do like that Calm asks about my level of experience and provides reassurance based on that. As someone who has endlessly tried to meditate, having the basics repeated over and over isn’t helpful; it’s frustrating. This step also signals to the user that the app works for them, whether they’ve meditated before or not.

The final part gives the user a sense of control:

Meditating can feel like just another task, so the app aims to strike a balance: not asking the user to do too much, nor too little, when they’re in a mindset of full dedication. It then attempts to understand the user’s current emotional state and when they plan to meditate, so the app can tailor push notifications and emails.

While I appreciate the continued focus on emotional state and problem-solving, the order of the questions sometimes feels random.

Post quiz steps (all flows)

The final steps are the same for all flows. There’s an additional review that, while identical for everyone, focuses more on sleep before prompting the user to sign up for an account.

This pattern isn’t uncommon in web funnels, especially quizzes: by this point, the user has already provided substantial input, and Calm subtly leverages loss aversion by encouraging them to save their preferences.

I find it interesting that Calm doesn’t provide any content feedback at the end of the quiz. While the quiz clearly aims to personalize the experience, that personalization only becomes visible after account sign-up. Users can access recommended content for free, but at this stage, they don’t yet know that.

This suggests the quiz is designed less for immediate conversion gratification and more for downstream personalization. Rather than rewarding the user right away, Calm seems to optimize for what happens later inside the app, through recommendations, notifications, and lifecycle messaging. This approach also makes sense given the sensitivities around mental health, but it does leave the ‘look what you could get!’ factor on the table.

By this point, the user has invested time, emotion, and data, making the trial feel like a natural next step rather than a hard sell.

The payment page is deliberately simple: a single 7-day trial tied to an annual subscription, without overwhelming the user with choices. If you don’t sign up right away, Calm often follows up with an additional discount to encourage conversion.

What can other apps learn from Calm’s web-to-app funnel?

Here are the lessons to learn from Calm:

1. Personalize where intent is highest
Calm doesn’t try to personalize everything. Sleep gets a dedicated flow; other goals don’t. That’s a good reminder that effective personalization is about focus, not coverage.

2. Emotional reassurance builds commitment
The quiz works because it validates the user before requesting any information, such as an account or trial sign-up. By the time pricing appears, the user already feels understood.

3. The real value of the quiz shows up later
Calm collects a lot of input without immediately providing feedback. This suggests the quiz is designed more for later personalization and retention than for immediate conversion payoff.

4. Simplicity still wins at the paywall
After a long quiz (though not unusually long compared to other apps), Calm deliberately removes choice: one plan, one trial — no extra decisions.

5. Brand trust can replace heavy social proof
Some elements — such as generic reviews and limited sourcing — would disadvantage smaller apps. Calm can rely on its brand within the funnel, but other apps would need more social proof to build trust.

6. Even strong funnels aren’t perfect
The order sometimes feels random, and some personalization is underused. But this is actually reassuring. You don’t need perfection for your first (or even your hundredth) web-to-app funnel to work well.

2. Blinkist Content Led Funnel

Web funnel type: landing page → app install

The value of Blinkist, the learning and personal development app, is rooted in content, so it makes sense that content sits at the very front of their acquisition funnel. Rather than leading with app features or promises, Blinkist leads with ideas: you learn something first, then discover the product that enables you to experience more of it.

Over time, Blinkist has built a strong content growth engine around short, insight-driven articles that summarize ideas. These articles are distributed both organically and through paid channels, helping build trust before asking users to download or subscribe. The same content formats are reused across paid ads, partnerships, and owned media, making this approach highly scalable.

Marcus Burke noted that, at one point, approximately 70% of Blinkist’s acquisitions came through web-to-app flows, proving just how central this content-led approach has been to their growth.

What does the typical Blinkist web-to-app journey look like?

A typical Blinkist journey starts with an ad promoting a piece of content, rather than the app. The ad leads to an in-depth article exploring a concept, principle, or idea. Within that content, Blinkist positions itself as the tool that helps you go deeper or learn more efficiently.

This is just one of many variations on the same pattern, but the overall structure remains consistent.

Here are several other articles Blinkist is currently driving paid traffic to:

Across their content, Blinkist relies heavily on social proof. Sometimes this appears as Apple features or App Store recognition. Other times, it comes from the authority of the author, thinker, or public figure behind the idea being explained. This approach transfers credibility from the content to the product, without feeling overly salesy.

The calls to action are usually either “Start your free trial” or “Create an account”. Trial CTAs often lead into a web onboarding quiz similar to Calm, while account CTAs keep users on the web, letting them continue exploring content.

Where does monetization happen?

Once users create an account, they can browse a range of book summaries. Clicking any summary triggers a paywall prompting a web subscription. On mobile, Blinkist also nudges users to download the app, creating a true hybrid of web discovery and app-based consumption.

What’s powerful about this approach is that Blinkist brings its aha! moment forward. Users experience “I learned something useful” before ever creating an account or starting a trial. While the sign-up rate may be lower than on a direct, conversion-focused landing page, this strategy allows Blinkist to reach a much broader audience and build trust upfront. That trust likely translates into stronger intent and higher-quality conversions once users do decide to sign up.

Trade-offs and risks to be aware of

There are trade-offs to this strategy. Organic traffic to Blinkist’s website appears to have dropped significantly over the past two years, likely influenced by shifts in search behavior and AI-driven content discovery.

Source: SemRush — Worldwide Organic Traffic for Blinkist.com

Meanwhile, what Semrush measures as paid traffic is more stable, but still smaller.

While this can be a powerful way to build trust online, especially with larger audiences, it’s important to be strategic about ensuring the content is seen and stays relevant.

What can other apps learn from Blinkist’s web-to-app funnel?

1. Bring the aha! moment forward
Blinkist shows that demonstrating value before asking for a sign-up can drive stronger intent later. Users convert because they’ve already learned something, not because they were sold on features.

2. Content can be the product preview
For content-driven apps, the web funnel doesn’t need to explain the app. It can demonstrate value directly and make the app the natural next step.

3. Web doesn’t need to convert immediately to be effective
Many Blinkist flows use web to educate, qualify, and build trust. Conversion happens later, either through account creation, a quiz flow, or an in-app paywall.

4. Social proof can come from ideas, not just reviews
Blinkist relies less on generic testimonials and more on the authority of thinkers and concepts. This is especially effective for educational apps.

5. Distribution matters as much as content quality
A content-led funnel only works if the content continues to reach new audiences. Changes in search behavior or platform dynamics can quickly impact performance, so it’s crucial to consider how people search today and ensure your content ranks effectively for AI-driven search.

3. PlantIn landing page funnel

Web funnel type: landing page → web purchase or app install

PlantIn, an AI plant care app, uses a fairly classic web-to-app setup, but what stands out is how intentional it feels without being overly fancy. It blends content, app promotion, and a web-based subscription flow in a way that gives users plenty of opportunities to buy in before being asked to actually buy.

See the full flow here

The journey usually starts with content. Ads lead to a dynamic in-between page that introduces the app and its purpose. From there, the experience changes depending on the device: on mobile, users are nudged to download the app (even if they try to click away), while on desktop, they’re directed to the website instead. It’s a small detail, but a smart one, and shows PlantIn doesn’t force an app-first experience where it doesn’t make sense.

PlantIn’s landing page

For some web-to-app landing pages, it isn’t always clear that they lead to an app. This can be tricky if you only offer web payments, since you don’t want users clicking through to the app store by mistake. For PlantIn, this isn’t an issue. They lead with a QR code for easy app download, include app store links, and show an in-app screenshot. The screenshot clearly highlights the value users can get from the app.

The next section, “What is PlantIn?”, appears to explain what the app does, but it’s actually a statistical trust builder. It highlights six key stats designed to build credibility and confidence in PlantIn.

Before moving on to the app’s key benefits, each stat should be explained clearly so users understand how it works. The section then wraps up with a brief social proof example and links to relevant articles — for example, the one on using coffee grounds for your plants (which I can personally recommend).

What’s great about PlantIn is that it doesn’t rush users into conversion. Instead, it focuses on sign-ups and deeper content. It offers a wealth of in-depth pages, like showing plant types, plant diseases, and even mushrooms you can identify. This doesn’t take away from the core value of the app — the ability to identify plants with confidence — or distract from conversion, it shows value and builds trust.

It’s the same classic flow of signing up to purchase. This matters for apps because – without it – if buyers purchase without an account, it creates an awkward post-purchase flow to try and get them set up on the app. It also allows you to encourage them to sign up for emails so you can guide them further.

What I really like about PlantIn’s pricing step is that it clearly shows users how much they save by subscribing online. The app delivers lower fees via the web and stronger retention to the end user.

Free trials are less common on web due to fraud risk, so it’s notable that PlantIn offers one. They keep it short, likely to prevent abuse, and because users can see the app’s value relatively quickly.

The checkout appears in a pop-up, making it clear what you’re paying for and what you’ll unlock. By this point, it feels less like a hard sell and more like the logical next step after everything you’ve already explored.

What stood out to me overall is how often PlantIn repeats its value proposition without it feeling aggressive. Each step adds a bit more context, rather than simply pushing the same message harder.

That said, I do find the wording slightly misleading. The title says “subscribing on the web,” but all the plans use the term ‘access’. Only the small text — which oddly omits the dollar sign on the first charge — clarifies that it’s a recurring subscription. This risks unhappy customers who didn’t realize they subscribed. I would use the word subscription or ‘per X period’ clearly in the prices, to ensure it’s clear which options are subscriptions and which are not.

What can other apps learn from PlantIn’s web-to-app funnel?

1. Meet users where they are
Routing mobile and desktop users differently avoids forcing an app download when it doesn’t make sense, rather than treating all users the same.

2. Show the breadth of your app, not just the main feature
PlantIn does a great job of making the subscription feel like access to an ecosystem, rather than just a single tool, while avoiding the trap of presenting itself as an ‘all-in-one’ solution.

3. Use content to reduce anxiety
Especially for users who feel like they’re ‘bad at plants’, the content reassures them before trying to sell.

4. Keep the app visible throughout the journey
Even when monetizing on the web, the app remains front and center.

5. Don’t be afraid to communicate web-specific offerings
The cheaper web subscription is presented as added value, not merely a way to avoid fees.

4. YNAB Workshop Funnel

Web funnel type: workshop → web purchase or web onboarding → email → app install

YNAB… You Need a Budget, don’t we all? This subscription app, which unsurprisingly is a budget app, has an extensive web experience. Given the complexity of entering all the data needed to set up and track a budget, YNAB lets users complete the entire process on the web, with the app introduced much later in the customer journey than you might expect. So late, in fact, that I started doubting they even had an app — but they do!

Workshops and webinars aren’t just effective for B2B apps; they can work really well for consumer apps too, especially when you want to build trust or stand out in a competitive market. I previously worked with a meditation and mindfulness app that offered weekly workshops. They ran multiple 3- and 7-day challenges you could join live, each centered around a theme like stress or gratitude.

These free workshops helped users connect with the coach, and afterwards, they were encouraged to purchase the app. This approach not only drove short-term boosts but also often led to longer-term growth, as users realized they wanted more content from the coach.

Workshops to help you learn

YNAB is built around its unique methodology and does a great job of supporting users and helping them learn.

Signing up for a workshop is simple via Zoom, and you receive a confirmation email. At this stage, there’s no mention of the app, and so the approach is refreshingly un-salesy. The focus is purely on delivering value to both existing and new users.

So what happens if you start the web flow? Get ready for a long web onboarding. This flow can be accessed via the website or after a webinar. Note that YNAB also runs ads to a 34-day free trial page, which is personalized to the user’s pain point and also leads into the same web onboarding.

The web onboarding process

I found it fascinating how many steps you go through without any mention of the app or sales. The focus is really on creating a sense of investment, with enough ‘sunk costs’ that you’re naturally engaged. I also didn’t expect the setup to be so easy and enjoyable, despite the multitude of steps.

Talking about money can feel a bit icky, and the questions can get personal. Still, I felt surprisingly comfortable sharing complete insight into my financial approach — bet you didn’t expect that in a web-to-app example article!

I did find the setup a bit unusual: the content sits at the bottom of the screen, with the rest left blank throughout the onboarding process (shown in the screen one, but not in the following ones). Given the length of the flow, it sometimes felt incomplete.

In essence, strong web quizzes often blur the line with onboarding, but for YNAB, there is no blurred line: this is pure onboarding. A few highlights are worth noting:

Customized reviews: I got a completely different review depending on what I said my goal was
Gradual build-up of the ‘thinking power’ required: the questions started easy and get progressively more in-depth
Personalization of relevant follow-up questions: e.g. if I indicated I owned a house, there were later questions about home insurance etc.
Initial questions were easy to answer on the spot: later, more in-depth questions arose that felt personal or needed calculation, e.g. how much you want or need to save per month, or your combined income
Breaking up the questions: it is a lot of questions, but the pauses between for reviews, explanation, and feedback lighten the flow

Even at the end of the quiz, there’s no mention of the app or YNAB’s costs. Since it’s a tool designed to help you save money, spending on it might feel odd until you’ve experienced the value, which is likely why they offer an extensive 34-day free trial. This period spans over a calendar month, allowing you to input data, start achieving your financial goals, and learn more about YNAB.

There’s also a part two questionnaire for account setup and connecting to your bank account, followed by a more explanatory, passive onboarding phase.

Two highlights stand out here. First, after completing part two of the setup, there’s a celebration moment. When the goal is long-term, celebrating progress like this is powerful; who doesn’t love a bit of colorful confetti? Budgeting has never felt so fun.

Second, the flow is reassuring. I’m quite far along before they make a big, high-trust ask: connecting my bank details. They gently reassure me that it’s secure, which builds confidence before the action.

Yet… still no mention of the app? Not even in the menu.

The first time I saw the app was in a follow-up email sent the same day I signed up:

This demonstrates that a strong flow doesn’t need to lead with your app. If your app is primarily a retention tool or requires significant setup and context, it can be more effective to provide an extensive, educational setup on the web first.

What can other apps learn from YNAB’s web-to-app funnel?

1. Web-to-app doesn’t have to lead with the app
YNAB delays the app reveal almost to an uncomfortable degree, and that’s intentional. The app itself isn’t the core value proposition; the methodology is. The web experience does the heavy lifting by teaching, building trust, and getting users mentally invested before the app even enters the picture.

2. Workshops work when education is the product
The workshops aren’t a gimmick or a lead magnet tacked on for growth. They’re a natural extension of YNAB’s philosophy. If your product requires a mindset shift or the adoption of new behaviors, workshops can achieve what landing pages never will.

3. Long onboarding can work if it feels earned
This is a long flow, but it doesn’t feel that way. Questions start easy, gradually get more personal, and are regularly punctuated with reassurance, reviews, and explanations. In this case, pacing matters far more than the number of steps.

4. Delay the ‘big ask’ until trust is established
Connecting bank accounts is a major trust moment. YNAB waits until you’ve invested time, seen progress, and felt understood before asking for it. By then, it feels reasonable rather than risky.

5. Celebrate progress, not outcomes
Budgeting is a long-term game. YNAB celebrates setup milestones, not financial wins. That confetti moment after part two isn’t about money saved, it’s about momentum towards a goal.

6. Free trials should match the job to be done
The 34-day free trial isn’t arbitrary. It gives users enough time to complete a full monthly budgeting cycle and experience the benefits before being asked to pay. The trial length supports behavior change, not just conversion.

5: Photoroom’s free tool funnel

Web funnel type: free tool → web onboarding → trial offer → app install

Photoroom, the photo editing app, is one of my favorite examples of how a B2B-focused app can use web-to-app without feeling pushy. Instead of gating everything behind an account or trial, they let you do real work upfront. You can remove a background for free, directly on the web, with zero friction, and that alone delivers value.

What’s interesting is that the web experience doesn’t feel like a stripped-down teaser; it feels like a useful product in its own right. Yet, at every step, it subtly nudges you toward deeper commitment.

The moment you upload an image and see the result, you’ve already had the aha! moment, and that’s when Photoroom starts layering in the next steps.

Reminder: you can zoom in on all the detail right here

Give value first, then ask for commitment

Photoroom offers a range of tools that can be accessed and used directly online:

One of the smartest decisions Photoroom makes is not forcing account creation too early. You can complete your first action without signing up, which reduces initial friction, especially for people solving a one-off problem.

But it doesn’t stop there. They use that first success to justify the next ask. If you want to continue editing, export in higher quality, or explore additional features, you’re encouraged to create an account. At that point, it feels reasonable. You’re not being asked to pay, or download anything. You’re not even signing up just to try it; you’re signing up to continue something you’ve already started.

This is a good reminder that web-to-app doesn’t always need a hard gate. Sometimes, letting people experience the core value first is the fastest path to building intent.

Self-employed vs. business: two very different journeys

Once you create an account, Photoroom quickly asks how you plan to use the product. This is where the funnel clearly becomes B2B-focused.

If you indicate that you’re using it for personal purposes, the flow stays relatively lightweight. Even then, it checks whether you have a brand to import:

But if you indicate you’re using Photoroom for a business, the experience changes. The onboarding goes much deeper: they ask about your company, your needs, and your expected volume. This doesn’t feel like unnecessary questioning; rather, it feels like qualification.

Photoroom is clearly trying to understand what kind of customer you are and what pricing and setup will make sense for you. From a growth perspective, this achieves two things at once:

Improves relevance by tailoring the experience
Sets expectations early for more advanced, higher-value plans

This is a strong example of using web onboarding not just to convert, but to properly segment users before the app experience even begins.

Team setup as part of the funnel

One of my favorite parts of the Photoroom flow is how early they introduce team setup. For business users, inviting teammates isn’t treated as an advanced feature you’ll discover later; it’s positioned as a natural next step.

The interface makes it easy to invite your team and set up a shared workspace. This does two important things:

Increases switching costs early
Turns one user into multiple users before monetization even happens

By the time pricing is introduced, you’re no longer thinking as an individual evaluating a tool; you’re thinking as a team adopting a workflow. That shift alone changes how pricing is perceived.

Repetition without feeling repetitive

Photoroom does something subtle but highly-effective throughout the pricing flow: no matter which free tool you start with, you continue to see the same core features and value propositions repeated.

At first glance, it might feel like they’re under-selling the breadth of the product. But I think this is intentional. Rather than overwhelming users with everything Photoroom can do, they focus on a small set of core capabilities and reinforce them consistently.

This repetition builds clarity. It’s a good reminder that focus often converts better than completeness.

Pricing clarity and trial positioning

When Photoroom finally introduces the free trial, it doesn’t come out of nowhere. By this point, you’ve already:

Used the product
Created an account
Seen how it fits into your workflow
Possibly invited your team

The trial feels like a natural extension rather than an aggressive push. They’ve asked several questions and set you up with an account, which helps reduce the risk of failed online charges.

I also appreciate how clearly Photoroom communicates pricing. You know exactly what you’re getting, what you’ll be charged, and when. There’s no sense of being tricked into a trial you might forget about. This transparency builds trust, which is especially important for business users.

What can other apps learn from Photoroom’s web-to-app funnel?

1. Let users do real work for free
Photoroom shows that giving away meaningful value upfront doesn’t cannibalize conversion. It creates it.

2. Use web onboarding to qualify, not just convert
Asking whether someone is a business user unlocks deeper segmentation and more relevant pricing later.

3. Design for teams early
Introducing team setup before monetization increases commitment and expands account value.

4. Subtle repetition builds clarity
Focusing on a few core features across multiple entry points helps users understand (and remember!) what the product is really for.

5. Trials work best when they feel earned
By the time the free trial appears, it feels like the obvious next step rather than a risky decision.

There’s no single ‘best’ web-to-app funnel

Looking across all five examples, the biggest takeaway is that web-to-app isn’t a one-size-fits-all template. Calm, Blinkist, PlantIn, YNAB, and Photoroom all approach it differently because their products, audiences, and jobs to be done vary:

Some lead with emotion
Some lead with education
Some lead with utility

What they all have in common is intention and user value. None of these funnels treats the web as a thin acquisition layer whose only job is to push users into the app as fast as possible. Instead, the web is used to:

Build trust
Create commitment
Reduce uncertainty
And, in some cases, even deliver the core value itself

If there’s one thing to take away, it’s this: your web funnel should do the hardest work before the app ever opens.

That might mean helping users understand themselves better, like Calm. Or it might mean teaching them something useful, like Blinkist or YNAB. Maybe it’s letting them experience real value immediately, like Photoroom or PlantIn.

The right approach depends on your subscription app, of course, but the opportunity is the same. Web-to-app works best when it’s not just a bridge, but a meaningful part of the product experience that drives high-quality users.

Building apps for an existing audience: why distribution is the new moat

Mon, 12 Jan 2026 11:46:34 GMT

Remember when shipping an app meant months of coding, debugging, and praying your launch didn’t coincide with an iOS update that broke everything? Those days aren’t quite gone, but they’re fading fast. Thanks to AI-assisted development tools like Cursor, Bolt, Replit, and a growing army of ‘vibecoding’ platforms, the barrier to building has dropped dramatically.

Andrej Karpathy coined the term ‘vibe coding’ in early 2025 to describe a workflow where you guide an AI tool to generate code through conversation, rather than writing it line by line. In its purest form, you can almost “forget that the code even exists”.

This is genuinely exciting: more people can build. More ideas can ship. The app stores are about to get a lot more crowded..

But here’s the thing nobody’s talking about enough: if everyone can build, then building isn’t the competitive advantage anymore. The new moats are having a great idea and getting it in front of people who want it. And there’s a shortcut to both that smart developers (and smart creators) are starting to figure out.

The influencer app playbook isn’t new, but it’s never been more relevant

Cast your mind back to 2014. Kim Kardashian partnered with Glu Mobile to launch Kim Kardashian: Hollywood, a freemium game where players climb the celebrity ladder through fashion choices, relationships, and strategic selfies. The gaming press was skeptical. The app world shrugged. Then it made $1.6 million in its first five days. By the end of 2014, it had generated over $43 million in revenue. At its peak, the game was pulling in $700,000 per day.

The game wasn’t revolutionary from a mechanics standpoint. It was a narrative dress-up game with energy timers and premium currency. What made it work was that Kim Kardashian had 25 million Instagram followers at launch (she’s now north of 360 million), and her audience was exactly the demographic that would love a game about becoming famous. The distribution was built in. The idea was validated by the audience that already existed.

That playbook has only gotten more sophisticated since then.

From Hollywood to your home screen

Chris Hemsworth launched Centr in 2019, a premium wellness app featuring workouts, meal plans, and mindfulness content from a hand-picked team of elite trainers. It wasn’t just “Thor tells you to do pushups”. It was (is) a genuinely comprehensive fitness platform with cinematic production values. But the reason it could command premium subscription pricing from day one was that Chris Hemsworth’s 60+ million Instagram followers already trusted him on fitness. The app didn’t need to convince anyone that the guy who got jacked for Marvel movies knew something about working out.

Arnold Schwarzenegger took a similar approach with the Pump Club app, packaging 50+ years of fitness expertise into daily workouts, nutrition guidance, and habit-building tools. Conor McGregor’s FAST app sells the same conditioning protocols he uses in fight camps.

The pattern is clear: take an existing audience that trusts you on a topic, then give them a product that serves that trust. But it’s not just A-list celebrities anymore.

The creator economy meets the app economy

The really interesting shift is happening with creators who aren’t household names, but have built dedicated audiences in specific niches.

Kayla Itsines built her following on Instagram with ‘Bikini Body Guide’ workout programs. When she launched the Sweat app, she had a direct line to millions of people who had already done her workouts via PDF. The app reportedly sold for around $400 million in 2021. That’s not celebrity money. That’s creator-to-app-founder money.

Likewise, Chloe Ting went viral on YouTube with free workout challenges that racked up hundreds of millions of views. Her app translates those viral programs into structured plans with calendars, timers, and progress tracking. Her 25+ million YouTube subscribers didn’t need to be convinced that her workouts were effective — they’d already sweated through them.

And then there’s Hank Green.

When your audience IS your product insight

Hank Green (of VlogBrothers, Crash Course, and SciShow fame) launched Focus Friend in 2025: a cozy, gamified focus timer designed to help people with ADHD actually get things done. It features a ‘Bean Friend’ character that focuses when you focus, turning productivity into something closer to a Tamagotchi than a stern Pomodoro timer.

The app hit #1 in the US App Store. Above ChatGPT. Above TikTok. Above Instagram.

What makes Focus Friend interesting isn’t just that Hank Green has millions of followers (he does). It’s that he’s been openly discussing his own ADHD for years. His audience includes a massive number of people who relate to that experience. When he built an app to solve a problem he personally has, he was also building for an audience that had self-selected around that exact problem.

This is the real insight: creators don’t just bring distribution. They bring validated demand. They’ve spent years learning what their audience struggles with; what they want — what they’ll pay for. That’s market research that most app developers would kill for, and creators have it for free.

The two-sided opportunity

So what does this mean for you?

If you’re a developer who can build, but struggles with ideas or distribution, consider this: somewhere out there is a creator with an engaged audience and a problem worth solving, but no technical skills to build the solution. That’s a partnership waiting to happen. You bring the building. They bring the audience and the insight. You both bring the upside.

If you’re a creator sitting on an audience that trusts you, consider this: the technical barrier to building an app has never been lower. You don’t need to learn to code (though you can vibecode easily enough if you want to). You need to identify the problem your audience would pay to solve, then find a builder who can make it real. Or use the new AI tools to prototype something yourself and see if it resonates.

The best apps in this model aren’t vanity projects or cash grabs. They’re genuine solutions to problems the creator understands deeply because they’ve been talking to (and often experiencing alongside) their audience for years.

What’s next

We’ve been thinking a lot about this intersection of creators, builders, and audiences at RevenueCat. The explosion of AI-assisted development tools means more apps will ship in 2026 than ever before. But the apps that break through — the ones that find real users and generate real revenue — will increasingly be the ones that start with distribution and work backward to the product.

In the meantime, if you’re a developer looking for your next project, maybe spend less time on Product Hunt and more time in the comments of your favorite creators. And if you’re a creator wondering whether an app makes sense for your audience, the answer is probably yes — you just need the right building partner.

The hard part isn’t building anymore. The hard part is finding something worth building, and people who want it. Turns out, some people have been solving that problem for years. They just didn’t know they were doing app market research the whole time.

Enter the Shipyard

Speaking of using creators to find proven audiences… we just might have something to help you in your next app adventure.

Shipyard: Creator Contest is an app-building challenge where real influencers enlist you to build, launch, and monetize an MVP app for their audience. In four weeks or less.

From January 15, 2026, you can get involved in our new hackathon, Shipyard. There’s a $140k prize pool, briefs from influencers with huge follower counts, and the opportunity to build something for a ready-and-waiting audience.

Learn more here

How to add subscriptions to a Bolt app

Fri, 09 Jan 2026 11:42:34 GMT

In this guide we’re going to look at how to add in-app purchases, meaning simple monthly and yearly subscriptions, into an app we have created with Bolt. We’ll also add a paywall to monetize part of the content in the app, and implement logic for checking whether the user is eligible to access content.

We are first going to create our project with Bolt, then you can start making your own changes to the apps. In this guide we’ll build an app that works on both iOS and Android, but you can of course choose to build for only one of those platforms if you prefer. Our example app is from this repository.

As the first step let’s open bolt.new and give the following prompt to get things started:

Why not just add subscriptions as part of the prompt?

This prompt should provide you a working app that has all the UI parts and code necessary for handling subscriptions. If you navigate around the application, you’ll notice that everything appears functional, and even the subscription logic is already in place. However, when you press the ‘subscribe’ button, nothing happens.

You might have noticed that the prompt includes the react-native-purchases package. This is RevenueCat’s React Native SDK, required for enabling in-app purchases. The reason subscriptions still don’t work at this stage is because Bolt uses an app called Expo Go to preview your app. Expo Go is a prebuilt preview app that comes bundled with a fixed set of native modules. These allow for rich interactions with native code — like building advanced UIs or accessing the camera — but they don’t include the native modules required for in-app purchases.

How RevenueCat’s SDK solves this

To address this limitation, react-native-purchases automatically detects when it’s running in Expo Go. When Expo Go is detected, the SDK enters Preview API Mode. In this mode, all native calls are replaced with mock APIs. While this means subscriptions won’t actually function in the preview, the integration won’t break either. Instead, you can safely navigate your app and verify that your subscription-related logic is wired up correctly, without interrupting your development flow.

At this point, you have a fully-functional app created with Bolt, including subscription logic and the RevenueCat SDK. All features should work as expected — except for actual subscription flows, which require native modules not available in Expo Go. You can continue using Bolt to build and enhance your app. Once you’re happy with the result, proceed to the next section to learn how to deploy your app using Expo Application Services (EAS), which will enable full subscription functionality.

Testing with Test Store

RevenueCat also has a built-in testing environment that works immediately without platform setup, called Test Store. Setting up Test Store does not need any additional configuration, the only requirement is using a Test Store API key. Test purchases made through Test Store behave like real purchases and subscriptions and allow you to build your app logic around subscriptions without having to configure App Store and Google Play subscriptions. Test Store also works on Expo Go.

We won’t cover Test store in this blog post, but it’s worth considering if you’re still testing out your app idea, and don’t want to spend time on setting up different stores before your app and subscription logic is fully built.

Now that our app has the basic UI for subscriptions in place, we can integrate the actual subscription logic using the react-native-purchases SDK from RevenueCat. Since the SDK includes native code, and our app uses Expo, we need to configure it to work with EAS Build, Expo’s custom build service.

To get started, download the project you have created with Bolt to your computer and open it in your IDE of your choice (e.g. VS Code, Cursor). You will also need the command line, so open that and navigate to your project folder to run the following command:

This will install the depencies of your app.

Prepare Expo for native modules

To enable native code in an Expo project, we need to switch from Expo Go to EAS Build. This is required for react-native-purchases and any other library that depends on native modules.

Follow the official Bolt Expo integration guide to configure your app. The key steps are:

1. Install eas-cli if you haven’t already:

2. Log in and configure the project:

3. Once configured, use eas build instead of expo start to build your project for iOS or Android:

This will create a production build of your application that you can then submit to the app stores. If you run into any errors or need additional support, check out Expo’s guide for creating production builds for Android and their guide for creating production iOS builds.

We now have a working production version of our app for Android and iOS that we can start adding subscriptions to. Before we do that we need to set up Google Play Console, App Store Connect, and RevenueCat, connect these three, then add products for our users to purchase.

Before we work on enabling subscriptions for our app, let’s set up RevenueCat and configure our products.

Start by creating a new RevenueCat account at revenuecat.com for free.

Connect RevenueCat to Google Play Store

Start by connecting your Google Play account to the RevenueCat dashboard, which will allow RevenueCat’s servers to communicate with Google Play Store on your behalf. To do this we need to provide RevenueCat with a set of service credentials. The process for configuring all of these is a bit complex, but this is all done to keep security high by only granting necessary access to RevenueCat.

To get access to the Google Play console, where all your distributed apps will live, you need to sign up for a Google Play developer account, which currently costs a one time fee of $25. Learn more about setting up a Play Console developer account from Google’s official documentation.

Once you’ve set up your Play Console account, follow RevenueCat’s guide to connect Google Play console and RevenueCat.

Configure Google Play with Products

With our RevenueCat account connected to the Google Play Store, we’re now ready to configure in-app subscriptions for our app. First, log into Google Play Console, select your application, and navigate to Monetize > Products > Subscriptions in the sidebar.

Click the Create subscription button and configure your pricing and billing periods (e.g., monthly and yearly). Be sure to take note of the Product ID for each subscription — you’ll need this when connecting your app to RevenueCat.

For more detailed information follow our Google Play product setup guide.

Connect RevenueCat to App Store Connect

To set up products for iOS, iPadOS, macOS, tvOS, and watchOS, start by logging into App Store Connect. App Store Connect is Apple’s central hub for managing app releases, TestFlight, in-app purchases, and more. To do this you need an Apple Developer account, which costs $99 a year.

Once you’ve set up your App Store Connect account, follow RevenueCat’s guide on connecting App Store Connect and RevenueCat.

Configure App Store Connect with Products

Navigate to your app and in the left navigation column under monetization select the Subscriptions section. Here you can define your subscriptions for your app. You need to app a new subscription group, then create a new subscription and include the subscription in the previously created group.

For more detailed information follow our iOS product setup guide.

Import Products into RevenueCat

Now that your subscription products are live in both app stores, head back to the RevenueCat dashboard.

Navigate to your project’s Products tab and click + New > Import Products. RevenueCat will automatically fetch your available subscriptions from Google Play and App Store Connect. Select the ones you want to import and click Import. Your subscriptions will now appear in your RevenueCat project, ready to use.

Create an Offering

Offerings in RevenueCat are how you define which products to show in your app. This makes it easy to test pricing, paywalls, and product combinations, all without needing to update your app.

Go to the Offerings tab and click + New to create your first offering. You’ll assign the products (like your monthly and yearly subscriptions) to this offering, which your app will reference when displaying a paywall.

Follow the steps in RevenueCat’s Offering documentation to complete setup.

You should now have RevenueCat, Google Play Console, and App Store connect configured with subscriptions. Before continuing with the guide, navigate to the API keys section of RevenueCat dashboard and copy the Android and iOS SDK keys. We will need these in the next step to connect our app to RevenueCat.

Create a paywall

RevenueCat has paywall builder that allows you to remotely configure your entire paywall without any code changes or app updates. You can use paywalls to display different offerings and your app can multiple different types of paywalls. You can also test how paywalls perform with RevenueCat Experiments.

We are going to add a simple paywall to show our possible subscription options. You can find the Paywalls RevenueCat dashboard in your project’s Monetization tools section. Pick from the pre-made paywall templates or make a fully custom one, and choose the offering you created in the previous sections. Once you are happy with the changes hit ‘publish’ to make the paywall available for your app. Learn more about RevenueCat Paywalls in our overview video.

The prompt from before should have installed both react-native-purchases and react-native-purchases-ui in both already. Verify this by checking that the package.json file has the lines below:

The versions should be 8.11.4 or higher. If either of these are missing or the version are lower than the mentioned, install the RevenueCat SDKs, by running:

Initialize the RevenueCat SDK

You can now initialize RevenueCat in your app. This is typically done once when your app starts. Creating our app with Bolt created a commented section where to place the following code parts in our app. Most likely it is in a file called _layout.tsx

Paste the API keys you copied in the previous section of this guide into the apiKey part. This enables your app to interact with RevenueCat’s servers.

To check if the user has an active subscription, query getCustomerInfo() and look for an active entitlement:

Use this in both the Feed and Profile tabs to reflect the user’s subscription status.

Implement the paywall logic

Now we can update the paywall screen to show available offerings and handle purchases:

This fetches the product offerings from RevenueCat and initiates a purchase flow. After a successful purchase, the entitlement is checked and the paywall is dismissed if the subscription is active.

Update the OverlayImage component

Finally, use the isLocked value in your OverlayImage component to lock or unlock content:

This ensures that only subscribed users can access the full list of cat pictures.

Wrapping up

With the RevenueCat and Google Play Console set up, the RevenueCat SDK integrated, and the necessary code changes made to the Bolt-created app, our app is now ready to accept and react to users subscribing. You’ll now want to create a new EAS build of your app; once the build finishes processing, test your app and the subscriptions. If you run into any problems, check that you have placed the code provided in the correct places.

These guides can also help you:

Using Bolt with Expo to create mobile apps, covers everything you need to deploy new versions of your app
RevenueCat’s updated guide to working with Expo, if you want to dive deeper into integrating your app with RevenueCat
The ultimate guide to Android subscription testing, RevenueCat’s guide to testing Android subscriptions.

Building animated custom Paywalls in Jetpack Compose

Fri, 09 Jan 2026 01:00:31 GMT

Paywalls are the critical touchpoint between your app and revenue. While pre-built templates can get you started quickly, there are compelling reasons to build custom paywalls that match your brand identity and create memorable user experiences. An animated paywall that responds to user context, like one that transitions between day and night themes, can create an emotional connection that static templates simply cannot achieve. The psychological impact of a well-crafted paywall extends beyond mere aesthetics; it signals to users that your app is polished, professional, and worth their investment.

In this article, you’ll explore how to build sophisticated animated paywalls in Jetpack Compose. We’ll dive deep into a “Day & Night” paywall implementation, examining each animation technique step by step. You’ll also learn how to use Firebase for agile A/B testing of your custom paywall content, and discover when RevenueCat’s Paywall Builder might be the better choice. By the end, you’ll have a complete understanding of when and how to build custom paywalls that convert.

Building custom paywalls: Day & Night deep dive

Let’s examine a production-quality animated paywall that transitions between day and night themes on a 16-second cycle. This implementation demonstrates several advanced Compose animation techniques working together harmoniously. The paywall creates an immersive environment that changes dynamically, with the sun rising and setting, stars twinkling into view, clouds drifting across the sky, and UI elements adapting their colors to match the time of day. This continuous cycle captures attention and creates emotional engagement that static paywalls cannot achieve.

Architecture overview

The Day & Night paywall follows a layered architecture that separates concerns cleanly. At the foundation sits the DayNightBackground composable, which handles all environmental animations including the sky gradient transitions, the procedurally generated star field with individual twinkling behaviors, the sun and moon following arc trajectories across the sky, a parallax cloud layer that drifts continuously, and a landscape gradient that grounds the scene.

Above this animated background, the content overlay presents the actual paywall information: a greeting that crossfades between “GOOD MORNING” and “GOOD EVENING” based on the cycle, a feature list with animated checkmarks whose colors shift with the day/night state, price display with an animated accent color, and a call-to-action button that transitions between warm golden tones during the day and cool indigo at night.

This layered architecture provides several benefits. The background animation logic remains isolated from the content presentation, making both easier to modify independently. The background can be reused in other contexts if needed, and the content layer can be updated without touching the complex animation code. This separation also improves performance by allowing Compose to optimize recomposition independently for each layer.

Setting up the animation cycle

The entire paywall is driven by a single cycleProgress value that loops from 0 to 1 over 16 seconds. This duration was chosen carefully, long enough to appreciate the transitions without feeling rushed, but short enough that users experience the full cycle during a typical paywall viewing session:

This pattern is important for complex animations: use a single progress value as the source of truth, then derive all other animations from it. This ensures perfect synchronization and makes the animation easy to reason about. When multiple animations need to coordinate, as they do in this paywall, having a single driver eliminates timing drift and makes the relationship between elements explicit.

The LinearEasing choice is deliberate. For a continuous cycle representing time passing, linear progression feels most natural. Non-linear easing would make certain parts of the day feel faster or slower than others, which would break the metaphor. The RepeatMode.Restart ensures the cycle loops seamlessly from midnight back to sunrise.

The cycle splits into two phases. The day phase spans from 0.0 to 0.5, during which the sun rises, crosses the sky, and sets. The night phase covers 0.5 to 1.0, when the moon performs the same journey. This symmetrical division creates a balanced experience where users spend equal time in day and night modes, maximizing exposure to both visual treatments.

Implementing the animated background

The DayNightBackground composable handles all environmental animations. This is where the magic happens, transforming a simple progress value into a living, breathing scene. Let’s break down each layer and understand how they work together.

Procedural star generation

Stars are generated once and remembered, with randomized properties for natural variation. The procedural approach means every session produces a unique star field, adding subtle variety to the experience:

Each star has its own twinkle phase and speed, ensuring they don’t twinkle in unison. This desynchronization is critical for realism, synchronized twinkling would look artificial and mechanical. The y coordinate is capped at 0.6 to keep stars in the upper portion of the sky where they belong, preventing stars from appearing in the landscape area at the bottom of the screen.

The 60-star count balances visual density with performance. Fewer stars would make the night sky feel sparse, while significantly more could impact rendering performance on lower-end devices. The size range of 1 to 3 pixels (from Random.nextFloat() * 2f + 1f) creates a sense of depth, with smaller stars appearing more distant.

The remember block ensures stars are generated only once per composition, maintaining consistency as the paywall cycles. Without this, stars would regenerate on every recomposition, creating a chaotic flickering effect.

Frame-accurate delta time

For smooth animations independent of frame rate, we track actual elapsed time. This technique is fundamental to professional-quality animation and ensures consistent behavior across devices with varying performance characteristics:

This approach has two benefits. First, animations remain smooth regardless of device performance, a device running at 30fps will show the same animation speed as one running at 120fps. Second, animation speed is consistent across devices, so users see the same experience whether they’re on budget hardware or flagship phones.

The coerceIn(0f, 0.1f) prevents animation jumps when the app returns from background. Without this cap, the delta time could be several seconds if the app was suspended, causing jarring jumps in continuous animations like cloud movement. By capping at 0.1 seconds (100ms), we ensure smooth recovery even after brief suspensions.

The withFrameNanos function is key here, it suspends until the next frame and provides the precise frame timestamp in nanoseconds. This is more accurate than alternatives like delay() which can accumulate timing errors over long running animations.

Multi-phase sky gradients

The sky transitions through eight distinct color phases, creating a believable progression from dawn through day through dusk through night and back. Each phase uses a three-color gradient to add depth to the sky:

The color choices are intentional and based on observation of real skies. Sunrise features warm oranges and golds, transitioning through the top of the gradient to paler tones. Day uses familiar sky blues with lighter tones toward the horizon. Sunset intensifies the warm colors with deeper oranges and reds. Dusk introduces muted blue-grays as light fades. Night reaches deep navy and near-black at the top, while dawn adds hints of warm tones as the cycle prepares to restart.

The phase calculation normalizes progress within each half-cycle, creating a local progress value that runs from 0 to 1 within either the day or night phase:

This normalization simplifies the transition logic, each phase can work with a consistent 0-to-1 range regardless of where it falls in the overall cycle. The day phase occurs when cycleProgress is below 0.5, while the night phase covers the upper half.

Then each phase transitions smoothly using lerp (linear interpolation), which blends between color values based on a progress parameter:

This creates natural-feeling transitions with quick sunrise/sunset phases occupying 20% of each half-cycle and stable midday/midnight periods holding steady for the remaining 60%. This pacing mimics real daylight patterns where transitions happen relatively quickly at the horizon while the bulk of day and night are stable. The 20/60/20 split also ensures that users spending even brief time on the paywall will likely see some transition, keeping the experience dynamic.

Star twinkling with fade transitions

Stars need to fade in and out at dawn and dusk, while also twinkling individually throughout the night. This dual-animation requirement demonstrates how to layer effects cleanly:

The fade timing uses 15% windows at the edges of each phase, creating smooth transitions. The multiplier of 6 (derived from 1/0.15) ensures the fade completes exactly within the window. During the day phase, stars are invisible (alpha 0) for 70% of the time, only appearing during the dawn and dusk transitions.

The twinkle effect uses a sine wave offset by each star’s unique phase. The sine function naturally oscillates between -1 and 1, so (sin(...) + 1f) / 2f normalizes this to 0-1. Multiplying by starAlpha creates the overall fade effect, while the inner calculation (0.4f + twinkle * 0.6f) ensures stars never fully disappear, they oscillate between 40% and 100% brightness, mimicking the atmospheric twinkling of real stars.

The performance optimization if (starAlpha > 0f) skips the star drawing loop entirely during the day, avoiding unnecessary computation when stars aren’t visible.

Sun and moon arc trajectories

The sun and moon follow identical arc paths across the sky, creating a believable celestial motion. The trigonometry here creates a natural horizon-to-horizon path:

The trigonometry creates a smooth arc through parametric calculation. At dayProgress = 0, the angle is PI (180 degrees), so the sun is at the left side of the screen since cos(PI) = -1. At dayProgress = 0.5, the angle is PI/2 (90 degrees), placing the sun at the center top since cos(PI/2) = 0 and sin(PI/2) = 1. At dayProgress = 1, the angle is 0, positioning the sun at the right side since cos(0) = 1.

The 0.5f multiplier on the Y component creates an elliptical arc rather than circular, giving a more natural horizon-to-horizon path that doesn’t extend too high into the sky. The height * 0.1f offset shifts the entire arc downward so the sun and moon rise from and set to below the visible area, creating a proper horizon effect.

The horizon check if (sunY < height * 0.7f) prevents drawing the celestial body when it’s below the landscape area. This simple culling ensures clean transitions at sunrise and sunset, with the sun and moon appearing to rise from and sink below the horizon naturally.

Sun rendering with animated rays

The sun is composed of multiple layers for a luminous, living effect. Each layer serves a specific purpose in creating the overall impression of radiant warmth:

The outer glow uses a radial gradient that fades to transparent, creating a soft halo effect around the sun. This atmospheric glow adds depth and prevents the sun from looking like a flat circle floating in space.

The main sun body uses an offset gradient center (shifted 8 pixels up and left) to create a subtle 3D effect. This offset makes one edge appear brighter, as if the sun has volume and the light is coming from a consistent direction. The color progression from pale yellow at the center through gold to orange at the edge mimics the color gradation seen in photographs of the sun.

The rays animate in two ways. First, totalTime * 20f in the angle calculation makes them rotate slowly, creating a spinning effect. Second, sin(totalTime * 3f + i) * 5f makes each ray’s length oscillate independently, with the phase offset + i ensuring different rays pulse at different times. This combination creates an organic, breathing quality that makes the sun feel alive.

Parallax cloud movement

Clouds create depth through independent movement speeds, a technique known as parallax that’s fundamental to creating perceived depth in 2D scenes:

The five clouds have varying scales and speeds. Larger, slower clouds appear more distant, while smaller, faster clouds seem closer. This variation creates a sense of atmospheric depth, even in the flat 2D canvas. The Y positions are constrained to the upper third of the screen (0.1 to 0.4 of height), keeping clouds in the sky area where they belong.

Each cloud is rendered as overlapping circles with wrapping horizontal movement:

The wrapping formula % 1.4f - 0.2f ensures clouds exit on the right and re-enter from the left seamlessly. The 1.4 range (140% of screen width) combined with the -0.2 offset means clouds are generated slightly off the left edge of the screen, drift across the entire visible area, and continue slightly past the right edge before wrapping. This creates smooth, continuous motion without visible popping at the edges.

The cloud color and alpha change between day and night. Daytime clouds are bright white at 90% opacity, clearly visible against the blue sky. Nighttime clouds become dark gray at only 15% opacity, creating subtle silhouettes that are visible but don’t dominate the starry sky.

Animating UI elements with the cycle

The UI layer animates in response to the day/night state using animateColorAsState, which provides smooth interpolation between colors whenever the target changes:

The 800ms duration creates smooth transitions that don’t feel rushed. This timing was chosen to match the overall pacing of the paywall, fast enough to feel responsive, but slow enough to be perceivable and pleasing. The color choices reinforce the day/night theme: warm golden tones during the day suggest sunshine and energy, while cool indigo and silver tones at night suggest calm and sophistication.

The label parameters are important for debugging and tooling. When using Android Studio’s Animation Preview or Compose debugging tools, these labels help identify which animation is which in the visualization.

Greeting crossfade animation

The greeting text switches between “GOOD MORNING” and “GOOD EVENING” using Crossfade, which automatically handles the enter and exit animations for content that changes:

The Crossfade composable handles the transition automatically, fading out the old content while simultaneously fading in the new content. This creates a smooth handoff without any jump or flicker. The 800ms duration matches the other UI animations, creating a cohesive feel.

The greeting text itself serves an important purpose beyond decoration, it creates a personal connection with the user. Time-appropriate greetings are a small touch that makes the app feel aware of and responsive to the user’s context. Combined with the animated environment, this creates the impression of a thoughtful, polished experience.

Custom checkmark drawing

Feature list items include animated checkmarks drawn with Canvas, demonstrating how to create custom graphics that respond to animation:

Drawing the checkmark with Canvas instead of an icon gives you precise control and eliminates asset dependencies. The checkmark path is defined using relative coordinates (percentages of the canvas size), making it scale correctly at any size. The StrokeCap.Round and StrokeJoin.Round create smooth, friendly-looking line endings and corners.

The background color comes from the parent composable and animates with the day/night cycle. This means the checkmark circles smoothly transition from warm golden during the day to cool indigo at night, maintaining visual harmony with the rest of the paywall.

Integrating RevenueCat for purchases

The paywall integrates RevenueCat through the rememberPaywallState helper, which encapsulates all purchase logic and provides a clean interface for the UI layer:

The PaywallState class encapsulates all purchase logic, keeping the UI composable focused on presentation:

This separation of concerns follows a clear architectural principle: UI components should be responsible only for presentation, while business logic belongs in separate classes. The PaywallState manages all RevenueCat interactions, loading states, and error handling, exposing only the interface the UI needs. This makes the code easier to test, maintain, and modify—changes to purchase logic don’t require touching the UI code, and vice versa.

Firebase for agile A/B testing

Custom paywalls give you creative control, but testing different messaging and offers requires a mechanism for remote configuration. Firebase Real-Time Database or Firestore provides this capability, enabling you to iterate on paywall content without app updates.

Why Firebase for paywall content

RevenueCat excels at managing subscription products, pricing, and analytics. However, when you’ve built a custom paywall, you need remote control over the content layer, the headlines, subheadlines, feature lists, price display formats, and call-to-action text that influence conversion. These elements often benefit from experimentation, and waiting for app store review cycles to test changes dramatically slows iteration.

Firebase lets you change these values without app updates, enabling rapid experimentation. You can launch a test in the morning, gather data throughout the day, and roll out the winner by evening, a pace impossible with traditional app updates. This agility is particularly valuable in the early stages of monetization when you’re still learning what resonates with your audience.

The combination of custom UI (for brand expression and advanced animation) with remote content (for rapid iteration) gives you the best of both worlds. Your paywall looks and feels unique, but you can still optimize messaging as quickly as teams using templated solutions.

Setting up Remote Config for paywall content

First, define your paywall configuration structure in Firestore. This structure should capture all the text elements you might want to vary:

The default values serve two purposes. First, they provide a fallback if the network request fails, ensuring the paywall always displays something reasonable. Second, they document the expected content, making it clear what each field is for.

The variant field is important for analytics. By including the variant identifier in the configuration itself, you ensure that analytics events always include the correct attribution. This eliminates a common source of A/B testing bugs where the variant assignment and the displayed content become desynchronized.

Fetching configuration at paywall display

The hash-based variant assignment ensures consistency, the same user always sees the same variant across sessions. This is critical for valid A/B testing; if users saw different variants on different visits, you couldn’t accurately measure the effect of any particular treatment.

The fallback to default values (via the ?: PaywallConfig() null coalesce) ensures the paywall always works, even if Firestore is unavailable. This defensive approach prevents network issues from blocking purchases entirely.

Integrating dynamic content into the paywall

Modify the paywall to accept configuration:

By parameterizing the paywall with a config object, you’ve created a flexible system that supports unlimited variations. The animations and visual design remain constant (and distinctive), while the content can be tuned remotely. This separation reflects the insight that users respond to both form and content, the form (design) builds brand perception, while the content (messaging) drives conversion.

Tracking conversion events

To analyze A/B test results, log conversion events with the variant identifier:

These three events create a conversion funnel that lets you analyze where users drop off. By filtering each event by variant, you can compare performance across treatments. The paywall_type parameter supports analysis across different paywall designs if you have multiple.

Analyzing results in Firebase

Create a funnel analysis in Firebase Analytics by examining the progression from paywall_viewed to purchase_started to purchase_completed, filtering each step by variant. Compare conversion rates across variants to determine winners.

When interpreting results, remember that statistical significance matters. Small differences in conversion rates may be noise rather than signal, especially with limited sample sizes. Firebase’s audience features can help you understand segment-specific effects, a variant that works well for new users might underperform for returning users, or vice versa.

Best practices for paywall A/B testing

Several principles help ensure your A/B tests yield actionable insights. First, test one variable at a time whenever possible. Changing the headline, feature list, and CTA simultaneously makes it impossible to know which change drove the result. If you must test multiple changes together, treat the entire bundle as a single variant and don’t draw conclusions about individual elements.

Second, use consistent user assignment so the same user always sees the same variant. This prevents the noise that would come from users experiencing different treatments on different visits. Third, run tests long enough to achieve statistical significance, which typically requires 1000 or more conversions per variant depending on the effect size you’re trying to detect.

Fourth, consider segment-specific testing. New users and returning users often respond differently to messaging, and testing within segments can reveal insights that aggregate analysis misses. Finally, document and archive your results. Over time, you’ll build organizational knowledge about what works for your audience, informing future experiments and reducing the need to retest ideas.

RevenueCat Paywall Builder: Beyond custom

While custom paywalls offer maximum flexibility, RevenueCat’s Paywall Builder provides compelling advantages for many scenarios. Understanding when each approach makes sense helps you allocate development resources effectively.

What Paywall Builder offers

RevenueCat’s Paywall Builder is a server-driven UI system that lets you design paywalls without code changes, using a visual editor in the RevenueCat dashboard. Once designed, paywalls can be updated remotely without app updates, you can change colors, fonts, layouts, images, and copy at any time. Built-in A/B testing lets you test different designs with statistical rigor, automatically allocating traffic and tracking results.

Localization support manages translations in one place, with automatic serving based on user locale. Analytics integration provides automatic conversion tracking without additional instrumentation. And a template library gives you proven starting points that you can customize.

Server-driven UI advantages

The key advantage of Paywall Builder is server-driven UI. Your app renders whatever configuration the server provides, decoupling the paywall appearance from the app release cycle:

This single composable renders any paywall design you configure in the RevenueCat dashboard. No app update required to change colors, fonts, or layouts, swap images or icons, modify copy or pricing display, launch A/B tests, or roll out winning variants.

The operational implications are significant. Your product team can iterate on paywalls independently of engineering, accelerating the experimentation cycle. Bugs in paywall content can be fixed immediately rather than waiting for app store review. Seasonal promotions can be created and removed on exact schedules without app update coordination.

When to choose Paywall Builder

Paywall Builder is often the better choice when iteration speed matters most. If you’re optimizing for conversion and need to test many variations quickly, the visual editor and built-in A/B testing dramatically accelerate the feedback loop. The product team can create and launch tests without engineering involvement, freeing developers for other work.

Engineering resource constraints also favor Paywall Builder. Custom paywalls require development time for initial implementation and ongoing maintenance. Paywall Builder shifts this work to product and design teams, who can work in the visual editor without writing code.

If you don’t need advanced animations, Paywall Builder supports basic animations and transitions. If your paywall concept doesn’t require complex custom effects, the templates may be sufficient. Many successful apps use straightforward paywalls that focus on clear messaging rather than elaborate motion design.

Cross-platform consistency is another consideration. Paywall Builder renders consistently across iOS, Android, and web. Custom implementations require separate development for each platform, multiplying the engineering investment.

When custom paywalls still win

Custom paywalls remain the right choice when brand expression is paramount. If your paywall must match a distinctive visual identity with custom animations, templates can’t replicate that. The Day & Night paywall we examined could never be created in a templated system, the procedural star generation, trigonometric sun/moon paths, and synchronized multi-layer animation require custom code.

You need unique interactions that templates don’t support. Gamified paywalls, AR previews, gesture-based navigation, or mini-demos of premium features require custom implementation. These interactive elements can significantly impact conversion by letting users experience value before committing.

Sometimes the paywall is a product differentiator. If the paywall experience itself is a selling point, like a meditation app’s calming paywall that sets the tone for the premium experience, custom development is worthwhile. First impressions matter, and a distinctive paywall can signal the quality users should expect from the premium tier.

Hybrid approach

Many successful apps use both approaches strategically. A custom implementation for the primary conversion flow provides the brand expression and distinctive experience that first-time subscribers see. Paywall Builder handles promotional paywalls for seasonal offers, win-back campaigns, or experiment variations where rapid iteration matters more than custom design. Secondary surfaces like settings screen upsells or feature-gated prompts also use Paywall Builder, since these are seen less frequently and benefit more from easy configurability than custom treatment.

This hybrid approach maximizes both brand expression and iteration speed. The primary paywall creates the distinctive first impression, while Paywall Builder provides flexibility for ongoing optimization and promotional needs.

Conclusion

Building animated custom paywalls in Jetpack Compose opens creative possibilities that templated solutions cannot match. The Day & Night paywall demonstrates how layered animations, sky gradients, twinkling stars, celestial body trajectories, parallax clouds, and synchronized UI elements, can create an immersive experience that engages users emotionally. These techniques transform the conversion moment from a transaction into an experience, potentially improving both conversion rates and brand perception.

Firebase provides the remote configuration layer needed for agile A/B testing of paywall content. By externalizing headlines, features, pricing display, and CTA text, you can iterate on messaging without app updates while maintaining your custom animated experience. This combination, custom design with remote content, gives you both brand distinctiveness and operational agility.

However, custom paywalls aren’t always the right choice. RevenueCat’s Paywall Builder offers server-driven UI, built-in A/B testing, and rapid iteration capabilities that often outweigh the benefits of custom development. Consider your team’s resources, iteration needs, and brand requirements when choosing between custom and templated approaches. Many successful apps use both, custom for the primary experience, templates for promotional and secondary surfaces.

For complete documentation on RevenueCat’s SDK integration, refer to the official RevenueCat documentation. For full source-code covered in this blog post, check out the GitHub repository.

How Jeff Morris drives growth and monetization in mobile

Wed, 07 Jan 2026 14:06:35 GMT

Jeff Morris, former VP of Product at Tinder and now a partner at Chapter One, brings years of experience in mobile growth and monetization strategies. In this episode, he shares actionable insights on building a scalable product, optimizing revenue streams, and staying agile in the fast-evolving app ecosystem.

Product-market fit comes first

Before jumping into monetization, Jeff emphasizes the importance of ensuring product-market fit. Building a product that genuinely solves user problems and resonates with your audience is the key to long-term success. Monetization should follow naturally once you’ve built a loyal user base that values your product.

Test and adapt monetization strategies

The pressure to monetize early is rising, but Jeff advises against rushing into rigid strategies. Founders should test different models—such as subscriptions, paywalls, or in-app purchases—and adapt based on user responses. Flexibility and adaptation are critical in today’s competitive market, as the same monetization strategy doesn’t work for every app.

Experimentation is essential

Testing is not just necessary; it’s essential to growth. Jeff encourages founders to continually experiment with various aspects of their app, from creative assets to pricing strategies. Analyzing data and adjusting based on real-time results leads to smarter decisions that ultimately fuel growth and optimize revenue.

Quality over quantity in creative testing

When it comes to creative testing, Jeff advocates for fewer, more meaningful experiments over testing hundreds of creatives without understanding why they work. Focus on strong hypotheses and ensure every test is geared towards discovering what truly resonates with your audience. Effective creative testing should be iterative and data-backed, not just about numbers.

Innovate, don’t copy competitors

While learning from competitors is essential, Jeff warns against copying their playbooks without tailoring strategies to your app’s unique needs. Use competitor insights as inspiration, but adapt them based on your own data and user behavior to find what truly drives success for your app.

Accurate data is key

Data is at the core of Jeff’s approach to growth. He stresses the importance of accurate data instrumentation to make informed decisions. Whether it’s understanding user behavior, monitoring in-app analytics, or analyzing creative performance, having reliable data allows you to optimize your efforts and avoid costly mistakes.

Embrace unconventional approaches

Jeff encourages founders to think outside the box and not shy away from unconventional strategies. Small changes, such as how you map events or introduce new features, can significantly impact performance. Sometimes, doing the opposite of what’s considered conventional can open doors to new opportunities.

Conclusion

Jeff’s experience shows that mobile growth and monetization aren’t about blindly following best practices—they’re about continuous testing, learning from data, and persistence in the face of challenges. By focusing on building a great product, testing frequently, and listening to user feedback, founders can find what works for their specific app and achieve sustainable, long-term growth.

How Peloton lost me after a price hike and what they could have done differently

Mon, 05 Jan 2026 13:40:24 GMT

Even before the big debacle in the pilot episode of Sex and the City’s spin-off And Just Like That, Peloton was all the hype, and I ran quickly away from it. I’ve never been great at following the crowd, and its cult-like following? Intimidating.

Fast forward a few years: the craze had cooled, I had a slightly bigger space, and I got an irresistible offer. A friend was willing to give me his bike — barely used — for a third of the original price… if I could pick it up and haul it across London on a freezing February morning. Challenge accepted.

Here’s my story: from falling in love with Peloton, to struggling with the monotony, surviving a price hike, and eventually canceling my subscription. Think of this as interval training: after the high-intensity bits of my painful memories, you’ll get a lighter, easy-breathe moment with the takeaways you can actually apply to your subscription app.

Interval 1: jumping into my personalized plan

My first hiccup came during account setup. Reading the fine print has never been my strong suit, and sure enough, I couldn’t use the bike to its full potential without the All-Access subscription at £39 a month.

Whoops. But I was determined to give it a go. Plus, the subscription meant my partner could also use the bike, which seemed to excite him. Escaping the rain outside, I doubled down on bike rides.

The real highlight? Peloton’s personalized plan feature:

Peloton email around personalising your plan

I’ve long struggled to fit into the box of a set plan that most apps offer. They usually focus on one type of exercise, while I thrive on variety. I’m the kind of person who never makes a recipe more than twice — yes, seriously.

With Peloton, I quickly customized a routine that mixed biking, running, and strength training, and I was off.

Here’s what their onboarding flow looks like:

Peloton quiz

The onboarding is easy to navigate and never makes you feel stupid:

If you’re unfamiliar with a workout type, like HIIT Cardio, they explain it clearly
Visuals show exactly how to use the equipment
Goals are asked about in simple, straightforward language

Clear explanations of exercises

I loved the variety of instructors and music, which perfectly complemented the high-energy workouts. My weekly streak grew quickly — just one workout a week was enough to keep it going — so no matter where I was in the world, I always did at least one session.

Takeaway 1: help users get the most out of your app, fast

Finding content with Peloton was effortless. A few simple questions helped the app understand me and offer workouts I actually enjoyed. ‘Fast’ doesn’t necessarily mean a short onboarding, but even if your onboarding is longer, it should give users a clear sense of value right away.

Peloton excels at this. They don’t just create a personalized routine; they also help you find your favorite instructor with a separate, quick quiz. It’s like Tinder meets Strava, and it made me realize that matchmaking is exactly what had been missing from my workouts.

Instructor quiz on the Peloton website

Interval 2: the downward hill of using Peloton

You can’t stay in the honeymoon period forever, and ours ended over the summer. That’s when I noticed I was doing fewer and fewer workouts on Peloton. At first, I had a million excuses for the distance between me and Peloton; after all, I’d invested in the bike:

I’d been injured, so I couldn’t run
It was summer, and I was biking and swimming outside
My sister was staying with me, and wanted guided strength workouts
I’d been traveling

But I persisted, trying to get back into it. I even reset my personalized plan to mix things up, but it felt like I was getting the same workouts on repeat.

The plan offered a fixed week of classes, but there was no sense of progression or adjustment over time — just new versions of the same routines. It started to feel less like personalization and more like a static template that simply shuffled itself; making it harder to stay motivated when I was craving change.

Personalization without visible evolution can feel stagnant. When users can’t see their progress, even the best content library starts to feel repetitive.

I was already picking the most advanced workouts and experimenting with different instructors. I wasn’t a top performer (my power output on the bike could improve) but I didn’t know how to progress:

More workouts?
Different workouts?
If it was personalized, where was the guidance?

What was I even working toward? Slowly, the cracks started to show.

Takeaway 2: help users understand how recommendations are personalized to them

Peloton’s personalized plan quiz was great for generating recommendations, but it missed a critical step: explaining why those recommendations were made.

Users need to understand not just what to do, but why it’s tailored to them and what goal it serves. Explaining the reasoning behind recommendations maintains trust and motivation. Sometimes products make the assumption users come to them because they don’t want to think, but that isn’t always true — we want the hard part done, but that doesn’t mean we don’t care about the ‘why’.

If you’ve asked 10–20 questions during onboarding, don’t just hide behind a fake ‘thinking’ loader. Show users that their answers were heard. At a basic level, feed back their responses; at a more advanced level, demonstrate that you understand and confirm it with them. AI apps make this easier than ever.

For example, Noom’s weightloss app has a lengthy onboarding process, but it breaks it up with little screens that reflect what it’s learned from your answers, making the personalization feel real:

Noom’s personalization in the onboarding flow

It takes your answers to give you feedback on your profile and where you should focus, making you feel that Noom is truly personalized just from going through the onboarding process.

Takeaway 3: understand what drives short vs. long-term retention

When you look at your monthly versus annual subscribers, you’ll often find that those canceling after a few months churn for very different reasons than those who leave after a year or two. Short-term and long-term retention are not the same game.

There’s the initial activation phase, getting users to start using your app, which is easier for Peloton since many users have already made a big investment in the bike. That’s followed by the habit-building phase. But long-term retention requires something else entirely. Your user evolves, and your app has to evolve with them.

This isn’t the first time I’ve outgrown an app. With ADHD, I quickly tire of repetition. I’ve had the same experience with mindfulness and recipe apps. Once you’ve mastered the basics and explored what an app has to offer, you start craving the next level.

To sustain engagement, an app needs to grow and adapt alongside its users as their jobs-to-be-done evolve. Peloton did allow you to retake your quiz to refresh recommendations, but it missed an opportunity to introduce clear levels, milestones, or a sense of progress, something to make users feel like they’re moving forward.

Interval 3: getting the email all users dread… a price increase

At this point, my two core personality traits were at war:

The stubborn part of me that refused to give up on something I’d bought only nine months ago
The restless part of me that craves newness

That’s when it landed in my inbox: the email every subscriber dreads. Subject line: “Changes coming to your Peloton Membership”. I knew exactly what the changes would be.

Long before I’d finally joined the Peloton hype train, I’d actually used one of their previous price increase emails as an example of great communication. It was clean, clear, and transparent, mapping out exactly what was changing and why. They had this great table showing just how much had changed between 2014 and 2022, from the number of workouts to the addition of programs.

Peloton comparing the 2014 offering vs. the 2022 offering

Of course, it’s always easier to admire a price hike email when you’re not the one paying for it.

I still stand by it as a great email. I’m not a hater, and I can appreciate a good pricing update. So I opened this new one with an open mind, hoping for the same clarity. But instead of understanding, I was left confused. Here’s Peloton’s new price update email:

Email announcing price increase

I appreciated the clarity around when and how the change would happen. You’d be shocked at how often this is missed! As well as that, they gave me at least a month’s warning so that it wouldn’t come as a surprise.

However, this time there was no clear table overview, just a list of changes — many of which I wasn’t personally interested in:

Number of classes: “12,000 classes” does sound impressive, though at a certain point it borders on unnecessary — that’s 32 years’ worth of daily classes
Club Peloton: feels like something they use for engagement versus something I should pay more for
Injury prevention: whilst that in itself is interesting, the way it was phrased around Special Surgery meant I wasn’t sure if it was relevant for me
Personalized Training with Peloton IQ: felt a bit vague — I wasn’t sure what this was, I think it was a few stats I’d received whilst using the app which were helpful, but didn’t really change my training

But there was one line in the email really threw me off:

“Breathwrk, now a part of Peloton — science-backed breathing exercises to help you reduce stress, recover faster, and stay focused.”

What is Breathwrk?! I hadn’t seen any breathing content in the app, nor was it something I’d been looking for; I already used Calm for that. It feltThis would be like a hotel upgrading your room to include a karaoke machine — very cool, probably fun for someone, but completely irrelevant to why I booked the room — something you never asked for, and then charging you for it!

Takeaway 4: Communicate major new offerings in-app before the price increase

Ironically, I only understood what Breathwrk was after I canceled. It turned out to be a separate app Peloton had partnered with, but I never saw it mentioned anywhere inside the product.

Source: Breathwrk

I might have actually used it, or at least recognized it as added value, if it had been communicated before the price increase. A quick check of my inbox confirmed: they’d never emailed me about it either.

While it’s fine to highlight new features in a price increase email, this felt like over-explaining. Like attempted justification. A better approach is to show the value first, let users experience it, then communicate the price change. If you can’t ensure users have seen the updates, add more communication to build excitement before raising costs.

This sounds like an excellent partnership for them, but a pricing email might not be the time to name-drop it without any context.

Interval 4: searching for another membership option

Now, I’d be remiss not to acknowledge Peloton’s hybrid monetization model. They combine an in-app subscription with a physical product, which is a powerful move. But, while it’s bold, it also leaves very little room for choice.

I’d already realized I needed the top-tier subscription to unlock the bike’s full potential. Then, after a 15% price increase, I started hunting for alternatives that would let me keep using my bike: could I downgrade to a lower-tier subscription?

The answer was a solid no.

Peloton subscription options

To give credit where it’s due, Peloton’s app subscriptions do offer a sense of choice:

Monthly vs. annual subscriptions
A ‘basics’ tier, or access to all workout types

These options give users flexibility, at least on paper, but when it comes to actually using the bike I already own, that flexibility disappears. Once you’ve committed to the top tier, there’s little room to adjust without losing access to features you’ve grown attached to.

App One vs. App+ plan

I liked that Peloton offers options here, but I quickly realized that with my All Access subscription, the only choice was at £45/month. It almost felt like I was being punished for having the bike: some classes I could use on other equipment, but for the Peloton bike itself, access came at a premium.

Takeaway 5: reward customers who invest in your brand

Rather than penalize someone for buying pricey equipment, reward them with better pricing to keep them loyal. Imagine if it were more expensive to use Peloton on other bikes?

Suddenly, buying the bike, treadmill, or other equipment becomes an investment that pays off for sticking around. I’ve always hated how endless discounts are offered to new customers while existing users aren’t acknowledged for their loyalty.

A simple way Peloton could have done this is by ensuring that it is cheaper to use the app with their equipment vs. other brands, or delaying the price increase for existing subscribers.

Takeaway 6: give customers a sense of choice

Have you ever told a kid to eat broccoli? Chances are, it didn’t go well, for you or for the broccoli. But I learned a valuable lesson from my cousins when dealing with little ones under five: make it seem like an option. “Do you want to eat the broccoli or the carrots?” Suddenly, vegetables are being consumed either way, and we can all breathe a sigh of relief.

The takeaway? We all like to feel like we have a choice (even if it’s between two pre-selected options).

Peloton does this well with their standard app subscriptions, but I missed it when it came to owning Peloton equipment: one subscription, one duration. There was no way to scale back usage (e.g. subscribe for 4x a month) or pay upfront for a year to save.

From a psychological perspective, this matters. Research on self-determination theory shows that autonomy is a key driver of user satisfaction. When customers feel trapped by pricing or product limitations, perceived value drops fast, even if the product hasn’t changed. Monthly subscriptions may allow companies to charge more, but they also make it easier for users to say stop.

Interval 5: so I canceled my subscription

I apologized to my bike and went to cancel, thinking a monthly plan would make it easy to restart if I missed it.

That’s when things got a bit messy. I logged in on my phone… no subscription showing. Checked the website… still nothing. Confused, I contacted customer service.

First impressions: they were super helpful. No fuss, no issues. My subscription was stopped just days before the renewal. I really want to celebrate Peloton for this, as I’ve known some brands that make canceling near-impossible. I won’t name names…this time.

Chat conversation to cancel subscription

But then I waited for the questions… Why did I want to cancel my subscription? Did they want my feedback?

They didn’t come. Maybe they’d include a survey in the confirmation email later.

The confirmation email arrived… and still, no survey.

It felt like dumping someone with a heartfelt speech, only to get a shrug. Like, don’t you want to know why I’m ending it? Don’t you feel desperate to find out if there’s someone else? (For the record: I never cheated on Peloton.)

Confirmation of subscription cancelled

Overall, Peloton did a lot of things well:

Super clear confirmation that your account is cancelled — no fluff or noise
No guilt-tripping; it showed understanding
Clear timeline so you know when changes take effect
Easy instructions for how to restart or change your subscription

The missed opportunity? After a conversation and an email, I was never once asked to explain why. This is valuable feedback for a brand.

Takeaway 7: make cancelling an enjoyable experience

Hiding cancellations or creating a complicated process never pays off. I don’t know why my membership didn’t show up on my account at first — probably a glitch across devices — but once I contacted support, everything was handled politely, and I was able to cancel in two minutes.

Even if some people cancel directly through the app store, for web or in-app subscriptions, a clear, simple cancellation flow is key.

Takeaway 8: ensure you have a ‘clean’ cancellation email

A good cancellation email covers:

Confirmation that the subscription has been cancelled
When the account stops
A thank-you for being a subscriber
A chance to provide feedback if they haven’t already

Keep it short, concise, and skip the “DON’T ABANDON US” panic. Guilt tripping isn’t professional, and doesn’t work.

So about that feedback…

Interval 6: I got a feedback request!

I did eventually get a survey, but I’m not 100% convinced it was because I cancelled. It was a Net Promoter Score (NPS) survey.

NPS survey email

Interesting timing, right after cancelling? I rolled with it anyway.

Answering the questions, it became clear the timing probably wasn’t intentional, as the survey didn’t seem to even know my subscription had been canceled:

Questions in the feedback survey

I couldn’t select “I don’t have a membership” for the statement, “I’m happy with my Peloton membership”.

For Peloton, I wasn’t a raging ex blocked on all social media; I was the ex you’re still friends with, where potential still exists. But even then, you don’t ask your ex:

Am I evolving to meet your needs?
Do I value you as a friend/partner?

It felt… weird. If I had been the raging ex:

Let’s be honest, I probably wouldn’t have given feedback
This would have annoyed me even more

Still, I played the game, social niceties and all, trying to answer as best I could, even though I couldn’t indicate “I’ve cancelled!”

What Peloton did get right, though, was checking whether I’d seen their announcements.

Asking about which features I’d seen

A bit of a random mention, but too often apps assume their users just know what they’re doing. The other day, I discovered a core feature in an app I’d been using daily for three weeks, oops.

Takeaway 9: have a specific feedback form post cancellation

Keep it short, and ideally link it to the moment of cancellation to gather insights on why users are leaving. Here’s more on the best practices of a strong cancellation survey.

To give Peloton some grace (told you I’m a nice ex), they did send a survey one day after I cancelled and noted that the system takes 72 hours to update. Maybe I just got unlucky with an NPS survey during that window. That said… I still haven’t received my actual cancellation survey.

The cooldown: life after Peloton

What surprised me most was how emotional the experience felt. I’d built rituals around Peloton: the instructors, the playlists, the feeling of showing up for myself. That emotional connection kept me subscribed longer than any discount ever could. But once that connection faded, the price increase simply accelerated my exit.

For other apps, this is a powerful reminder: retention isn’t just about utility, it’s about identity and belonging. Once users stop feeling seen or progressing, they stop showing up.

It had nothing to do with working out; I’m still a fitness addict, training six days a week. Since cancelling, I’ve been testing a new app that I love: it challenges me, tracks my weights and reps, and shows me tangible progress.

But it doesn’t include biking workouts. And my Peloton bike, still sitting in my workout space, quietly calls me as the nights get darker and the days rainier.

I gave it a go without a subscription. Two short free classes brought back a wave of nostalgia. It was like running into my ex at the coffee shop we used to visit together.

The free tester class

Peloton’s story isn’t unique to fitness apps. Every subscription app faces the same challenge: evolving alongside its users. Whether you’re building a meditation, language-learning, or gaming app, these lessons are universal:

Help users get value fast
Explain how personalization works
Evolve with users as their goals change
Communicate new value before raising prices
Reward loyal customers, don’t penalize them
Offer flexible, fair pricing options
Make cancellation simple and respectful
Send clear, thoughtful confirmation emails
Collect timely, relevant feedback

When users feel both understood and in control, retention follows naturally.

For now, it wasn’t enough to bring me back, but I’m not ready to sell the bike either. Maybe, in time, we’ll find a way to make this expensive relationship work again…

Reduce support time with auto-attached app diagnostics

Wed, 31 Dec 2025 13:35:44 GMT

Most support emails start the same way:

“The app does not work!”

No device info. No OS version. No context. Your team wastes time asking follow-up questions and your customer waits for help.

You can fix that in one afternoon. Add a small diagnostics block to support emails your app sends. It gives your team everything they need to solve problems fast and your customers get better support without back-and-forth.

Give your team context before the first reply

Without context, support tickets turn into guesswork. Agents can’t see the customer’s setup or state. Maybe notifications are disabled, or large text pushed buttons off-screen.

Adding metadata changes that. When every support email includes the customer’s environment, accessibility settings, and subscription state, agents can spot the issue immediately instead of asking for details.

Add a diagnostics block that explains the problem before the customer does

Include a compact summary of the customer’s setup in each support email. Include the granted or denied permissions, important configuration options that might affect the user experience in the app. It might look something like this:

App: 3.5.2 (302) • iOS 17.2 • iPhone 14
Notifications: allowed (alert/badge/sound)
Text size: XL (Accessibility Large)
Locale/TZ: en-US / PST
Network: reachable (Wi-Fi)
RC User ID: abcd1234 • entitlement=active
Last screen: Paywall • Last sync: 2025-10-14T09:32Z

This one block replaces several messages of troubleshooting. Keep it short and human-readable. Five to seven lines is plenty.

Include details that help the agent act fast: app version, OS, permissions, accessibility settings, locale, timezone, and key RevenueCat context like user ID and entitlement status. Avoid personal data or tokens, and mention in your help center that diagnostics are attached to support emails.

Build it yourself in a few lines of code

You can add this now. On iOS or Android, pull data like notification settings, device info, locale, and entitlement status.

Track how much faster support gets

Once diagnostics are attached, measure the impact. Look at first-response time, time-to-resolution, and how often your support agents have to ask follow-up questions. You’ll see faster responses and fewer repetitive tickets.

Be transparent with customers

Tell customers what’s included in the diagnostics and why. Keep it visible in your privacy notice or support screen. And if you want to go the extra mile, add a toggle so they can choose not to include it.

Handle email support with Customer Center

If you don’t want to maintain your own diagnostic block, Customer Center does it for you.

A new Support tab in Customer Center brings all your support email settings into one place. You can decide who sees the “Contact Support” action, set the address those messages go to, and connect tools like Intercom or Zendesk without touching code.

The tab also adds a powerful improvement for debugging. You can turn on Support Metadata and Customer Center will attach a compact diagnostics block to every support email your customers send. It gives your team the context they need to resolve issues faster; app version, device details, permissions, subscription state, and other relevant signals.

Everything runs server side. When a customer taps “Contact Support,” the email routes through RevenueCat, matches the message with backend data, and inserts the selected metadata into the footer before delivering it to your support inbox. You get accurate, up-to-date context without asking customers for screenshots or extra details, and your team cuts troubleshooting time dramatically.

If you already rely on Zendesk or Intercom, the setup is automatic once you connect the integration. If you use a different tool, you can still forward emails normally and keep the metadata block intact. This update turns support emails into a reliable source of truth and makes Customer Center a complete home for managing support flows.

Add metadata to your support emails now.

Craft, Seasonality, and the Long Game

Wed, 31 Dec 2025 13:29:17 GMT

Jordan Morgan’s journey as an indie app developer is shaped by patience, experimentation, and a deep respect for craft. With years of experience building, selling, and even reacquiring apps, Jordan has navigated multiple phases of the indie landscape—from passion projects to sustainable businesses. Best known for apps like Elite Hoops and Alyx, Jordan’s work reflects a thoughtful balance between creativity and pragmatism.

In this episode of Launched, Jordan joins Charlie Chapman for an annual, reflective conversation on what it truly means to build apps that endure. Together, they explore seasonality, growth plateaus, paid acquisition, and the often-overlooked emotional side of long-term product building.

From Passion Project to Sustainable

Elite Hoops, Jordan’s flagship app for basketball coaches, began as a focused solution to a specific problem: helping coaches organize plays, drills, and practices more effectively. Over time, it evolved into a reliable, revenue-generating business—one defined not by explosive growth, but by consistency.

Jordan explains that Elite Hoops is highly seasonal, with most revenue generated during the basketball season. Rather than fighting this reality, he embraced it. Each year, the app grows during peak months and stabilizes during the off-season, resulting in a steadily rising baseline. This predictable rhythm has enabled Jordan to reinvest with confidence, plan for the long term, and resist the pressure to chase constant growth.

Learning the Realities of Acquisition: Growth VS Paid

A central theme of the conversation is Jordan’s evolving relationship with paid advertising. For years, he ran ads intuitively—without deep attribution or advanced tracking—relying instead on instinct and observation. While this approach worked early on, it eventually revealed its limits.

By working with a professional marketing agency, Jordan began to understand where his growth was truly coming from. He discovered that seasonal demand and strong App Store search performance were driving much of Elite Hoops’ success, while some paid campaigns were offering little real impact. This realization marked a turning point: moving from indie intuition toward more disciplined, data-informed decision-making.

The experience reinforced an important lesson—scaling sustainably often requires uncomfortable shifts, including better instrumentation, clearer attribution, and a willingness to admit what isn’t working.

Reconnecting with Craft Through Alyx

Alongside the business-focused Elite Hoops, Jordan built Alyx, a caffeine-tracking app designed as a creative outlet. Unlike his sports apps, Alyx was intentionally crafted as a playground for iOS features—integrating HealthKit, widgets, shortcuts, App Intents, and system-level APIs.

Alyx wasn’t built to maximize revenue. Instead, it served as a reminder of why Jordan started building apps in the first place: joy, curiosity, and craftsmanship. Shipping Alyx alongside a new iOS release became a personal milestone, symbolizing a return to playful experimentation and platform-native design.

This dual-track approach—one app focused on sustainability, the other on creative freedom—has allowed Jordan to balance business responsibility with creative fulfillment.

Building for Longevity in a Changing Indie Landscape

Jordan and Charlie also reflect on the broader indie ecosystem. They discuss how conversations around app development have shifted from craftsmanship toward growth metrics and monetization strategies, and how parts of the once-vibrant indie community have fragmented over time.

Jordan’s perspective is grounded and optimistic. Rather than chasing trends, he believes longevity comes from solving real problems, respecting users, and staying aligned with personal values. Not every app needs to scale endlessly; some are meant to grow steadily, support their creators, and evolve thoughtfully over time.

Conclusion

Jordan Morgan’s story is not about overnight success or viral growth. It’s about building apps that last—through seasonality, plateaus, and changing platforms—while staying connected to the joy of making things well.

Whether through a sustainable business like Elite Hoops or a craft-driven passion project like Alyx, Jordan’s journey offers a powerful reminder: meaningful products are built patiently, intentionally, and with a long-term mindset.

For builders navigating the tension between craft and commerce, this episode is a thoughtful exploration of how to keep both alive—and why the long game is often the most rewarding one.

Paywalls now work on the web

Wed, 31 Dec 2025 13:12:59 GMT

If you already use RevenueCat Paywalls on mobile, you can now use those same paywalls in the browser.

The paywalls you’ve designed for iOS and Android now render on the web, using the same layouts and components.

One paywall across mobile and web

Web paywalls aren’t a separate object or a new paywall type. They’re the web version of the paywalls you already create at the Offering level.

An Offering can include mobile products, web products, or both. When it includes both, the same paywall layout serves mobile and web users.

Your structure, copy, and experiments carry over automatically. You design a paywall once and use it across platforms.

Where web paywalls show up

You can use web paywalls in two places, depending on how your product is set up.

Inside Web Purchase Links
Web Purchase Links are RevenueCat-hosted checkout URLs. If a link uses the default package selection page, you can replace that step with your paywall.

Users see your messaging, layout, and pricing context before checkout begins. You control the experience earlier in the flow, where it matters most.

Embedded in your web app with Purchases.js
If you use Purchases.js, you can now render paywalls directly inside your web app. Call presentPaywall, pass the HTML element where it should appear, and RevenueCat handles the rest.

The paywall renders in place and continues into checkout without custom UI or hand-built flows.

Works with Web Billing and Paddle

Web paywalls support both RevenueCat Web Billing and Paddle.

Which products appear depends on the web config attached to the surface showing the paywall. A Web Purchase Link connected to a Paddle config shows Paddle products. Switch that same link to a Web Billing config and it shows Web Billing products instead.

The paywall layout stays consistent while the product source changes based on configuration.

Change paywalls without shipping updates

Web paywalls are hosted and server driven.

You can update copy, layouts, pricing blocks, and calls to action from the dashboard. When you publish, changes go live immediately.

You can also target paywalls by country, platform, app version, or custom segments. Experiments work the same way they do on mobile, so you can test pricing, layout, or messaging on the web with the same tools.

When something stops converting, you can respond the same day.

Run subscriptions from one place

You can embed web paywalls directly into your app or link to them through hosted URLs. Either way, you manage subscription flows for mobile and web from the same system, using the same paywalls and workflows.

Paywalls on the web are available now.

How Alper Taner Navigates the Evolving World of Mobile Growth

Wed, 24 Dec 2025 14:48:37 GMT

Alper Taner has spent over a decade in mobile growth, working across a wide range of verticals and managing large marketing budgets. In this episode, he shares his insights on what it takes to drive growth in today’s ever-changing app landscape.

Focus on Data-Driven Decisions

Alper emphasizes that while best practices can be helpful, they shouldn’t be followed blindly. The key is to prioritize what works for your specific app, based on your own data and current stage. Whether it’s testing creatives, bidding strategies, or incrementality, always ground your decisions in your app’s data, the same approach might not work for every account, so testing and adapting are crucial.

Don’t Rush to Call Something a Problem

One of Alper’s most critical insights is the importance of understanding the facts before reacting. For example, low trial conversions may seem problematic, but they may simply reflect the business model or user acquisition strategy. Test, iterate, and diagnose before labeling something as an issue. Often, low metrics are just the starting point for valuable insights.

Creative Testing: Quality Over Quantity

Alper challenges the standard approach of testing hundreds of creatives with little focus on why they work or don’t. He advocates for testing fewer creatives with strong hypotheses and focusing on what makes them successful. It’s not about the numbers—it’s about finding what resonates with your audience and optimizing accordingly. Vigorous creative testing should be both iterative and radical to uncover real winners.

Control Your Spend, Guide the Algorithm

A major theme in Alper’s approach is taking control over your budget. He advises setting clear spend limits, adjusting bids based on performance, and using tools like budget caps to guide the algorithm. Don’t let platforms dictate your spend—use intelligent, strategic control to optimize your campaigns effectively.

Learn From Competitors, But Don’t Copy

Alper cautions against blindly copying competitors. While it’s helpful to learn from what others are doing, the real value lies in customizing those insights for your app and audience. Competitor ads can inspire, but success comes from tailoring strategies to fit your unique goals and data.

The Importance of Accurate Data and Instrumentation

Accurate data is at the heart of Alper’s marketing approach. He stresses the importance of proper data instrumentation to ensure that you can make informed decisions. Whether it’s MMP, in-app analytics, or creative performance, interpreting data accurately is essential to guiding your marketing efforts and avoiding costly mistakes.

A Holistic Approach to Testing and Learning

Alper advocates for testing everything from bidding strategies to event mapping. He explains that small changes, like adjusting how events are mapped, can significantly impact performance. At the same time, always be open to radical testing—sometimes, doing the opposite of what’s commonly recommended can unlock new opportunities.

Conclusion

Alper’s story is a reminder that in the world of mobile growth, success is about innovative experimentation, data-driven decisions, and constantly challenging what’s considered “best practice.” Be persistent, iterate based on results, and stay focused on long-term growth—it’s all about finding what truly works for your specific app and market.

Understanding Google Play’s subscription lifecycle: a complete guide

Mon, 22 Dec 2025 00:05:47 GMT

Managing subscription lifecycles on Android is one of the most complex aspects of in-app billing implementation. Subscriptions go through numerous states throughout their lifetime, from initial purchase to renewals, grace periods, account holds, pauses, cancellations, and eventual expiration. Each state transition requires specific handling in your app to ensure users receive the correct entitlements, while your backend maintains accurate subscription records. Understanding these lifecycle events is essential for building a robust subscription system that minimizes involuntary churn and provides a seamless user experience.

To make it a little clearer, you will break down the complete Google Play subscription lifecycle in depth. We’ll cover every subscription state and the transitions between them, examine how Real-Time Developer Notifications (RTDN) inform your backend of changes, understand the differences between auto-renewing and prepaid subscriptions, and see how proper lifecycle handling can recover revenue from failed payments. Finally, we’ll look at how RevenueCat simplifies this complexity by abstracting away much of the lifecycle management.

The subscription lifecycle at a glance

Before diving into the details, let’s establish a mental model of how subscriptions flow through different states. A subscription begins with a purchase, enters an active state, and eventually either renews successfully, encounters payment issues, gets canceled, or expires. The complexity arises from the numerous intermediate states and recovery mechanisms that Google Play provides.

Each state has specific implications for user entitlements and requires different handling in your app and backend.

New subscription purchases

When a user purchases a subscription, your app receives a SUBSCRIPTION_PURCHASED notification, and the subscription enters the SUBSCRIPTION_STATE_ACTIVE state. This is the starting point of the lifecycle.

The critical acknowledgment requirement

One of the most important aspects of handling new purchases is acknowledgment. Google Play requires you to acknowledge a subscription purchase within three days of the transaction. If you fail to acknowledge within this window, the user automatically receives a refund, and the subscription is revoked.

The acknowledgment serves as confirmation that you have granted the user access to their purchased content. It’s a safeguard that protects users from situations where a purchase succeeds on Google’s side but fails to register in your app.

Understanding the purchase response

When you query a new subscription purchase using the purchases.subscriptionsv2.get API endpoint, you receive detailed information about the subscription state:

Field	Value for new purchase
subscriptionState	SUBSCRIPTION_STATE_ACTIVE
acknowledgementState	ACKNOWLEDGEMENT_STATE_PENDING
autoRenewEnabled	true
expiryTime	Next renewal date

The expiryTime field indicates when the current billing period ends and renewal will be attempted. For a monthly subscription purchased on January 15, this would be February 15.

Linking purchases to user accounts

Google Play provides ExternalAccountIdentifiers to help you associate purchases with user accounts in your system. When configuring the billing flow, you can pass your internal user ID:

These identifiers are returned in the purchase response and RTDN notifications, allowing your backend to correctly attribute purchases to user accounts even in edge cases like upgrades, downgrades, or resubscriptions.

Subscription renewals

For auto-renewing subscriptions, Google Play automatically attempts to charge the user’s payment method when the billing period ends. Successful renewals trigger a SUBSCRIPTION_RENEWED notification.

What happens on successful renewal

When a subscription renews successfully, the subscription remains in SUBSCRIPTION_STATE_ACTIVE, and the expiryTime is updated to reflect the new billing period. Importantly, renewals do not require acknowledgment, only the initial purchase does.

Your backend should update the stored expiry time when receiving the renewal notification:

Renewal date behavior

Google Play follows specific rules for renewal dates that you should be aware of:

Subscriptions started on 29, 30, or 31 of a month will renew on day 28 (or 29 in leap years) when the following month has fewer days
Once a renewal shifts to an earlier date (like 28), it stays on that date for subsequent months
For example, a subscription starting March 31 renews April 30, then May 30, June 30, and so on

This behavior can affect analytics if you’re tracking renewal patterns, so keep it in mind when building reports.

Grace periods: the first line of defense

When a renewal payment fails, Google Play doesn’t immediately suspend the subscription. Instead, it enters a grace period: a recovery window during which the user retains full access while Google retries the payment.

Grace period configuration

Grace periods are enabled by default in the Play Console and can be configured per subscription:

Billing period	Available grace period options
Weekly	3, 7 days
Monthly	7, 14, 30 days
Annual	7, 14, 30 days

During the grace period, the subscription state changes to SUBSCRIPTION_STATE_IN_GRACE_PERIOD, but autoRenewEnabled remains true because the user hasn’t canceled; they just have a payment issue.

Handling grace period in your app

When you detect a user is in the grace period, you should encourage them to update their payment method. Google provides the In-App Messaging API to display a standardized payment update dialog:

The key point is that users retain access during the grace period. Your app should continue providing the subscribed features while simultaneously nudging users to fix their payment method.

Silent grace period

Even if you configure a zero–day grace period in the Play Console, Google Play still provides a minimum one–day silent grace period for payment processing retries. During this silent grace period, the subscription appears as SUBSCRIPTION_STATE_ACTIVE (not IN_GRACE_PERIOD).

This is important to understand because you might receive a delayed notification about payment issues. After 24 hours, the subscription will transition to one of several states depending on the outcome:

SUBSCRIPTION_RENEWED if the retry succeeded
SUBSCRIPTION_ON_HOLD if account hold is enabled
SUBSCRIPTION_CANCELED if the user canceled during this time
SUBSCRIPTION_EXPIRED if no recovery mechanisms are enabled

Account hold: the second chance

If the grace period expires without successful payment recovery, the subscription enters account hold. This state represents a more serious payment failure where the user loses access to subscribed content.

Account hold duration

Account hold is enabled by default with a duration of 60 days minus the grace period length. For example, if you have a seven–day grace period, account hold lasts 53 days. During this time:

The subscription state is SUBSCRIPTION_STATE_ON_HOLD
The expiryTime is set to a past timestamp
The subscription is not returned by queryPurchasesAsync()
The user should lose access to premium features

User experience during account hold

Your app should detect when a user’s subscription is on hold and display appropriate messaging. Since subscriptions on hold are not returned by queryPurchasesAsync(), you need to query your backend or the Google Play Developer API directly to check for this state:

This implementation requires some infrastructure: your backend must receive and process RTDN notifications, store subscription state, and expose an API for your app to query. You also need to handle edge cases like network failures, state synchronization, and ensuring your backend state matches Google Play’s state.

With RevenueCat SDK, this complexity is taken away entirely across platforms. RevenueCat processes RTDN notifications on your behalf and maintains subscription state that you can query with a single call:

RevenueCat’s CustomerInfo automatically reflects the current subscription state, including account hold status via the billingIssueDetectedAt field. The managementURL property provides a direct link to Google Play’s subscription management screen where users can fix their payment method.

During account hold, users can still cancel, restore, or resubscribe. If they fix their payment method, you’ll receive a SUBSCRIPTION_RECOVERED notification, and the subscription returns to SUBSCRIPTION_STATE_ACTIVE with the same purchase token — it’s a recovery, not a new purchase.

The billing date reset

An important detail: when a subscription recovers from account hold, the billing date resets to the recovery date. If a user’s subscription was originally set to renew on day 15 of each month, but they recover from account hold on day 22, their new renewal date becomes day 22.

Subscription pausing

Google Play allows users to pause their subscriptions — a feature that can reduce cancellations by giving users a temporary break without losing their subscription entirely.

Pause configuration and availability

Pause functionality is enabled by default in the Play Console but is only available for certain billing periods:

Billing Period	Available Pause Durations
Weekly	1, 2, 3, 4 weeks
Monthly	1, 2, 3 months
Three-month	1, 2, 3 months
Six-month	1, 2, 3 months
Annual	Not available

Annual subscriptions cannot be paused, this is a deliberate limitation because the pause period could potentially exceed the subscription duration.

The pause lifecycle

Pausing involves multiple notifications as the pause progresses through its stages:

User initiates pause: SUBSCRIPTION_PAUSE_SCHEDULE_CHANGED notification
- State remains SUBSCRIPTION_STATE_ACTIVE
- User retains access until current billing period ends
Pause takes effect: SUBSCRIPTION_PAUSED notification
- State becomes SUBSCRIPTION_STATE_PAUSED
- User loses access
- PausedStateContext contains the expected resume date
Subscription resumes: SUBSCRIPTION_RECOVERED notification
- Can be automatic (pause period ends) or manual (user resumes early)
- State returns to SUBSCRIPTION_STATE_ACTIVE

If the user manually resumes their subscription before the pause period ends, their billing date changes to the date they resumed. This is similar to the billing date reset that occurs after account hold recovery.

Handling pause in your app

Handling subscription pauses requires tracking multiple states and coordinating between your app and backend. The challenge is that paused subscriptions behave differently from other non-active states, a scheduled pause still grants access, while an active pause does not.

Your backend needs to process RTDN notifications to track pause state changes:

On the client side, your app needs to query the backend to determine the current pause state and display appropriate UI:

The complexity here involves distinguishing between a scheduled pause (where users still have access) and an active pause (where access is revoked). You also need to handle the case where users cancel their scheduled pause, and provide a way for users to resume early if they choose.

With RevenueCat, pause state management becomes straightforward:

RevenueCat automatically tracks pause state through its server-side RTDN processing. The managementURL property provides a direct link to Google Play’s subscription settings where users can view their pause status, cancel a scheduled pause, or resume early. This eliminates the need to build custom deep links or track pause scheduling on your backend.

Additionally, RevenueCat’s webhooks notify your server of pause events in a normalized format, making it easy to trigger pause-related communications like “We miss you!” emails or special offers to encourage early resumption.

Cancellations and expirations

When a user decides to cancel their subscription, the lifecycle enters its terminal phase, but cancellation doesn’t mean immediate loss of access.

The cancellation grace period

Upon cancellation, users retain access until the end of their current billing period. The subscription enters SUBSCRIPTION_STATE_CANCELED, and the expiryTime indicates when access will be revoked.

Understanding cancellation reasons

The canceledStateContext field provides valuable information about why the subscription was canceled:

User voluntarily canceled (check userInitiatedCancellation for the survey response)
Developer canceled via API
Subscription was replaced (upgrade/downgrade)
Payment failed and all recovery mechanisms were exhausted
Google canceled due to policy violations

This information is valuable for understanding churn patterns and improving retention strategies.

Expiration: end of the line

When the expiryTime passes for a canceled subscription, or when account hold ends without recovery, the subscription expires. You receive a SUBSCRIPTION_EXPIRED notification, and the state becomes SUBSCRIPTION_STATE_EXPIRED.

At this point, you should:

Revoke all entitlements associated with the subscription
Mark the purchase token as invalid in your database
Optionally, offer win-back promotions to the user

Restore and resubscribe: bringing users back

Google Play provides two mechanisms for users to return to a subscription they previously had: restore and resubscribe.

Restore: before expiration

If a user cancels but then changes their mind before the subscription expires, they can restore it. This uses the same purchase token and continues the subscription as if it was never canceled.

Your app receives a SUBSCRIPTION_RESTARTED notification, and the subscription returns to normal active status. Importantly, you don’t need to acknowledge restored subscriptions because you already acknowledged the original purchase.

Resubscribe: after expiration

If the subscription has already expired, users can resubscribe, but this is treated as a new purchase with a new purchase token. You’ll receive a SUBSCRIPTION_PURCHASED notification and must acknowledge within three days.

The resubscribe response includes helpful fields for linking the new subscription to the user’s existing account:

Upgrades, downgrades, and plan changes

When users change their subscription plan, whether upgrading to a more expensive option or downgrading to save money, it creates a new subscription while invalidating the old one.

The linked purchase token

Plan changes generate a new purchase token, but the response includes a linkedPurchaseToken field pointing to the previous subscription:

Proration modes

When implementing plan changes in your app, you can control how billing is handled using different proration modes:

Mode	Behavior
IMMEDIATE_WITH_TIME_PRORATION	User is credited/charged immediately, billing date unchanged
IMMEDIATE_AND_CHARGE_PRORATED_PRICE	User charged prorated amount immediately
IMMEDIATE_AND_CHARGE_FULL_PRICE	User charged full new plan price immediately
DEFERRED	Change takes effect at next renewal

The choice of proration mode affects user experience and revenue recognition, so consider your business requirements carefully.

Revocations and refunds

Sometimes subscriptions end abruptly due to revocation or refund, bypassing the normal cancellation flow.

When revocation occurs

You receive a SUBSCRIPTION_REVOKED notification when:

You revoke the subscription via the Developer API
A chargeback occurs
Google revokes due to policy violations

Revocations are immediate, the subscription jumps straight to SUBSCRIPTION_STATE_EXPIRED, and you should revoke access immediately:

Prepaid subscriptions: a different lifecycle

While this article focuses primarily on auto-renewing subscriptions, it’s worth understanding how prepaid plans differ. Prepaid subscriptions don’t automatically renew; users explicitly purchase additional times.

Key differences for prepaid plans

Aspect	Auto-Renewing	Prepaid
Renewal	Automatic	User-initiated top-up
Grace Period	Yes	No
Account Hold	Yes	No
Pausing	Yes (if enabled)	No
States	All states	Only Active, Pending, Expired

Prepaid acknowledgment timing

Prepaid plans have stricter acknowledgment requirements:

Plans ≥ 1 week: acknowledge within three days
Plans < 1 week: acknowledge within half the plan duration

For a three–day prepaid plan, you must acknowledge within one and a half days, or the user receives a refund.

How RevenueCat simplifies lifecycle management

Managing all these lifecycle states, notifications, and edge cases requires sophisticated backend infrastructure and careful implementation. This is where RevenueCat provides substantial value by handling most of this complexity automatically.

Automatic state management

RevenueCat maintains subscription state in real-time, processing Google Play’s RTDN notifications on your behalf. Instead of building infrastructure to receive, validate, and process notifications, you simply query RevenueCat for the current customer state:

The CustomerInfo object reflects the current state of all subscriptions, including:

Active entitlements
Expiration dates
Whether the user is in a grace period
Billing issues that need attention
Management URL for subscription settings

Handling grace periods and billing issues

RevenueCat’s CustomerInfo includes a billingIssueDetectedAt timestamp when a subscription has payment problems. You can use this to show appropriate messaging:

RevenueCat also provides webhooks that notify your server of subscription events in a normalized format, making server-side integration much simpler than processing raw RTDN notifications.

Cross-platform subscription state

One of RevenueCat’s most convenient features is maintaining subscription state across platforms. If a user subscribes on Android and later opens your iOS app, their subscription status is automatically recognized. This is particularly valuable for lifecycle events, a subscription that enters grace period on Android will be reflected in the iOS app’s CustomerInfo without any additional implementation.

Revenue recovery

RevenueCat’s Billing Alerts feature can automatically attempt to recover failed payments by:

Sending customizable email notifications to users with billing issues
Prompting users to update payment methods at optimal times
Tracking recovery rates and providing analytics

This automates much of the grace period and account hold handling that would otherwise require custom implementation.

Analytics and insights

Understanding your subscription lifecycle patterns is crucial for optimization. RevenueCat provides detailed analytics including:

Churn analysis by cancellation reason
Grace period and account hold recovery rates
Subscription duration and renewal patterns
Revenue metrics across lifecycle stages

These insights help you identify where users are dropping off and opportunities to improve retention.

Best practices for lifecycle management

Based on the lifecycle stages we’ve covered, here are key practices to implement:

Always verify on your backend

Never trust the client-side subscription state alone. Your backend should:

Process RTDN notifications (or use RevenueCat’s webhooks)
Verify purchases using the Google Play Developer API
Maintain authoritative subscription state

Handle grace periods proactively

Users in grace periods are at high risk of churning. Implement multiple touchpoints:

In-app messaging using Google’s API
Push notifications reminding users to update payment
Email campaigns for users not opening the app

Make cancellation reversible

Since users retain access until their billing period ends, make it easy to restore:

Show clear ‘Resume subscription’ options
Don’t punish users who explore cancellation
Consider exit surveys but don’t make them mandatory

Plan for edge cases

Real-world subscription management involves many edge cases:

Users switching devices mid-subscription
Multiple purchases from the same user
Refunds and chargebacks
Subscription transfers between accounts

Build your system to handle these gracefully, or use a service like RevenueCat that handles them automatically.

Summary

Google Play’s subscription lifecycle is comprehensive but complex. From the initial purchase through renewals, grace periods, account holds, pauses, cancellations, and expirations, each state requires specific handling to ensure users receive correct entitlements while your business captures all possible revenue.

The key states to understand are:

Active state where users have full access
Grace period where users retain access while you attempt payment recovery
Account hold where access is suspended pending payment fix
Paused state where users voluntarily pause their subscription
Canceled state where users retain access until their paid period ends
Expired state where access should be revoked

Whether you implement subscription lifecycle management directly or use RevenueCat, understanding these lifecycle stages is essential for building a robust subscription business on Android. The difference between losing a subscriber to involuntary churn and recovering them often comes down to how well you handle grace periods and account holds. The difference between a confusing user experience and a seamless one depends on how gracefully you handle pauses, cancellations, and restorations.

For complete documentation on subscription lifecycle management, refer to the official Android Developer documentation and RevenueCat’s subscription guidance.

Monetize faster with RevenueCat Test Store by testing purchases without App Store or Play Console

Fri, 19 Dec 2025 16:13:33 GMT

A hosted test store that behaves like a real store

Test Store is a first-class store object inside RevenueCat; it stores products, serves offerings, accepts purchases, and records transactions for testing only. It is not a simulator or a local mock. When your app uses a Test API key, the SDK fetches Test Store products, runs the test purchase flow and returns customerInfo and entitlements that match production shapes. Test activity is marked sandbox and kept separate from production.

Skip store setup and get a working paywall in minutes

You can skip the slow parts of early monetization. No need to configure App Store Connect and Play Console credentials. Test Store is provisioned automatically with every new project so you can design paywalls, test purchases, and iterate on subscriptions without waiting for platform setup.

Start testing paywalls instantly and run repeatable subscription tests

Start immediately; a Test Store appears with every new project
Validate paywalls end to end; receipts, entitlements, and customer objects match production
Run subscription lifecycle tests quickly
Test in Expo, web previews, simulators, and dev builds that lack native store APIs
Rotate Test API keys for safety and keep test traffic out of revenue metrics

Never ship an app with a Test Store API key

Enforce production keys at release. Test Store uses its own key so you control which store your app talks to during development, but production builds must switch to your platform-specific API keys. RevenueCat enforces this for a reason; if a release build initializes with a Test Store key, the SDK will show an alert and crash the app. That hard stop protects the security of your entitlements and prevents test purchases from leaking into production.

To lock things down even more, use the Sandbox Testing Access allowlist. You can restrict Test Store and other sandbox purchases so only approved App User IDs receive entitlements or virtual currency during testing. That way, non-production purchases stay in a safe, controlled lane while your real customers remain unaffected.

Create a project and run your first test purchase in minutes

Create a new project in the RevenueCat dashboard and the Test Store is ready by default. Point your dev build at the Test API key, fetch offerings, and make a test purchase; you’ll see customerInfo update and entitlements change just like production.

Test Store removes the biggest speed bump in early monetization: no platform credentials, instant provisioning, and realistic test purchases so you can iterate faster and ship with confidence.

To learn more, head over to the Test Store docs.

What app buyers really want: insights from 10 leading acquirers

Thu, 18 Dec 2025 14:40:24 GMT

Despite the fact many app developers dream of selling their app, the world of app buying is still rather uncharted territory. Much like job interviews or talking about personal finance, people seem to shy away from frank conversations.

Luckily, we don’t. And it seems about time someone demystified these questions.

Questions like:

What’s my app worth?
Do I need to stay after the acquisition?
Can I stay after the acquisition?
Do buyers prefer organic or paid traffic?
How good does my retention need to be?
What’s a multiplier and how do I get it/do it/be it?

Answering those (and some others) is the goal of this article. Currently most app acquisition advice floating around the internet is either outdated, generic, or coming from people who’ve never actually bought an app.

For various reasons, many buyers keep their perspectives private; but just as job interviews are getting more transparent in what to prepare, we think founders deserve reliable acquisition guidance. So, we went straight to the source!

This is the real state of industry acquisitions, straight from the people shaping the vertical: buyers.

If you’re a founder looking for an exit, or even just a newbie planning ahead, we promise you this is worth 10x the hours you’ll spend watching interviews, listening to podcasts, and in 1:1 conversations.

Featured app buyers

Evelin Herrera is Founder of EHVM App Capital, the mobile app M&A firm working with high-growth app founders on exits and strategic acquisitions. Every day, Evelin is in the field working directly with founders and buyers, facilitating deals. So who better to get the real answers from buyers on what they’re looking for?

After scouring her network, Evelin interviewed ten experienced, international buyers on everything from valuation to founder status post-acquisition. We’ve taken those interviews, and unpicked the answers to all those questions you haven’t had ticked off yet (or are too afraid to ask).

Here’s who Evelin spoke to:

🇺🇸 Dan Novaes, Co-Founder & CEO at Mode Mobile
🇫🇷 Guillaume Larrieu, VP of Business Development at Quiet
🇨🇦 Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital
🇸🇰 Matej Lancaric, Independent User Acquisition & Marketing Consultant
🇪🇸 Michael McPhee, Head of Business Development and M&A at Leadtech Group
🇵🇱 Paweł Pochowski, Head of Business Development at Nova Sphere
🇬🇧 Ryan Thorpe, Director of Growth at Reflective Apps
🇺🇸 Tom Kenney, CEO & Co-founder at LOYAL
🇹🇷 Yalçın Özdemir, Founder & CEO at AppNation
🇺🇸 Zach Tobin, Founder of Product Growth LLC

These are the people acquiring, integrating, and scaling apps today, spanning app categories like gaming, health & fitness, productivity, utilities, and lifestyle. Read on for a peek into their world…

TL;DR: the real state of app acquisitions (according to the people writing the checks)

If you’re just here for the quickfire facts, we’ve got you covered. From 10 hours of interviews, here are the highlights you need to know if you’re interested in selling your app.

The majority of buyers prefer keeping original talent (including the founder) in place post-acquisition: they benefit from product knowledge, quick iteration, and being able to scale without delays.
The starting point for valuing your app is 3–5x EBITDA (earnings before interest, taxes, depreciation, and amortization), provided your app is older than two years and has four plus months of subscriber retention.
Strategic acquisitions (not purely financially-motivated) do happen, but they’re rare and require a lot of matchmaking.
Most companies offer 100% upfront cash as standard, but some offer variants like earnouts or equity. Consider these options carefully, as they can increase/decrease your overall valuation.
Different buyers favour more organic or more paid traffic; organic builds reliable growth, but paid user acquisition (UA) drives scale. Try targeting a 50/50 mix to show strong metrics and reduce the risk of algorithmic reliance.
Why are buyers looking to acquire in the first place? Buyers have seen double revenue in 12–18 months for <$500k acquisitions, so financial incentives are high. Many acquirers also prefer buying versus building from scratch to reduce risk, accelerate growth, and start with apps that benefit from proven product-market fit (PMF).
The top green flags for acquisition are: high retention, low running costs, organic compounding, domain authority, proven PMF and market momentum.

What actually drives app valuation, and the truth about multipliers

This is the first question developers always have: how much can I get for my app business? But valuation is tricky — you have to reflect potential future growth, stickiness > trends, technology moats (if any), and multiple other factors.

The best way to answer the crux of this question is by hearing it from the folks who put the capital on the table. But, before we dive in, let’s cover a couple of basics: acquisition types and multipliers.

Strategic vs. financial acquisitions

Believe it or not, not all apps are bought just for financial gain. In fact, most are a mix of strategic moves, financial motivation, and passion projects. But broadly-speaking, there’s two types of acquisition: financial and strategic.

Financial acquisition are valuations are solely based on the financial performance of the company:

“Financials are the priority, but if something lines up strategically with what we’re building, we’ll go there too.” — Dan Novaes, Co-Founder & CEO at Mode Mobile

Strategic acquisitions consider the strategic value (e.g. a gap in their app portfolio, or particularly strong market value) an acquisition is bringing to the business — typically these come with a premium price:

“We’re always looking for acquisitions that help us advance our strategy of building a portfolio of high-quality life improvement-focused apps. We then base our valuation on a number of factors.” — Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

Are multipliers the defining factor in an acquisition?

In the world of mobile app acquisitions, multipliers are tossed about left, right, and centre. Along with all the wonderful acronyms that come with them.

In short, a multiplier is a simple way buyers estimate a business’ value, based on core financial metrics. It’s about saying “we value your app at X times what it earns”, aka thinking about what it could earn.

Most acquisitions use a core metric like monthly recurring revenue (MRR), annual recurring revenue (ARR), or EBITDA as the baseline. A multiple is the price per unit. So if an app makes $100k EBITDA, and buyers typically pay 3-5X EBITDA, then the app is worth $300-$500k. Buyers anchor value on these metrics because they’re disciplined, and it minimizes risk of overpaying.

“Valuations are always based on multiples. If you’re not disciplined, you’ll overpay which makes it that much more difficult to succeed. Valuations need to create a win/win for all parties, including the buyer.” — Tom Kenney, CEO & Co-founder at LOYAL

Many founders obsess over multipliers and assume they’re the be-all and end-all for getting acquired. But the reality Evelin heard from every buyer was that multipliers are a starting point, not a golden rule. The real valuation moves up or down depending on a number of factors (which we’ll get into shortly) like retention, scalability, growth, team etc.

For example, Yalçın Özdemir, Founder & CEO at AppNation, explained how, for the right app, valuations can be flexible:

“When we identify opportunities where our strengths can quickly improve the revenue, we’re willing to stretch valuations. In these cases, we see the real value in the match between what the founder has built and what we can contribute.” — Yalçın Özdemir, Founder & CEO at AppNation

When multipliers don’t tell the full story

As Yalçın says, multipliers aren’t the sole deciding factor in whether a buyer is interested. The big picture matters too, and certain industries, like gaming, can be less rigidly-reliant on multiples:

“Multipliers are a useful tool, but they’re not the only method we rely on — and certainly not always the most accurate. For example, games often experience revenue decline once user acquisition spend is reduced. In these cases, a valuation based solely on the past 12–24 months might not reflect the true potential.” — Paweł Pochowski, Head of Business Development at Nova Sphere

Early-stage apps or products in emerging niches can also be poorly reflected by multiples alone. Paweł explained that these categories may not have had a chance to prove their value through performance metrics yet: “In these scenarios, we look beyond historical data and consider market trends, strategic fit, and growth potential. If we see strong momentum or a unique positioning, we’re open to offering above-standard valuations.”

“We start with financial performance, then dig deeper into the performance metrics, and build a comprehensive model that allows us to understand an app’s history, its current place in the market and value to current and past users.” — Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital, also says many buyers factor in their current app portfolio when valuing new apps: “We consider how complimentary it is to our overall portfolio and ultimately determine what price we are able to pay. We can, and do, pay higher multiples for assets that accelerate our overall plan, but within a range that is based on financial discipline.”

How to hack the high-multiple tier

So what’s the secret to your app sitting in that magic high-multiple tier?

Typically, valuations are a multiplier range e.g. 3–5x EBITDA. Different factors make apps lower or higher, and a handful of buyers will stretch beyond standard ranges when an app unlocks something bigger for their app portfolio.

These reasons could be:

Cross-sell potential
Category expertise
Shared users
Proven PMF in a target market
A feature set they lack internally

This is why founders should talk to multiple buyers. Your best valuation may come from the buyer who sees the most synergy between your app and their current portfolio, not the highest revenue multiple.

Across every buyer Evelin spoke to, there was an unmistakable pattern. If you want the upper end of the multiplier range, you need these three things:

Strong retention: this signals undeniable product-market fit, and is the best predictor of long-term cash flow
Low operational burden + clean architecture: buyers want to scale quickly and easily — they can’t do that if there’s missing documentation, inconsistent analytics, or messy code
Organic or compounding distribution: this equals an efficient growth engine; think untapped markets, clear opportunities to expand features, early traction in a category etc.

Not much to ask, right?

Takeaway: valuation + multipliers

While multipliers are simple to understand and have a quick potential for evaluating your app, it’s more important to find a buyer that’s the right fit. If your app helps a buyer advance faster towards their goal, offers a strategic or portfolio fit, or has growth momentum, you’re far more likely to get a much higher multiplier.

Likewise, if a buyer can clearly see where they’ll create value, the app becomes more attractive — and more expensive. Early trajectory and category dynamics also influence valuation almost as much as financials. But remember: financial responsibility still holds out. Most buyers put stock in EBITDA/MRR multiples, and won’t take a big financial risk.

The app buyer wishlist: what founders should optimize before acquisition

While multipliers play a part in getting that offer, there’s a lot of factors that influence whether buyers move a deal forward. Evelin asked about the top three things buyers look for in an app, and do you know how many said the same top three factors?

Yup, zilch. There’s no one-size-fits-all approach.

But just like the signals influencing your multiplier, there were frequent recurring factors that all buyers put as priorities. Primarily, everyone mentioned retention and having ‘sticky’ users.

“Ultimately, the lower the price of the acquisition, the better. And the faster the return-on-investment, the better. But we look at so many factors and how they relate to each other.” — Ryan Thorpe, Director of Growth at Reflective Apps

Here’s what our buyers are looking for:

Retention
Organic growth
Monetization potential
Valuation and ROI
Technical infrastructure
Product-market fit
Familiarity with the vertical and/or strategic/portfolio fit
Market momentum

Let’s break these down.

Priority	Why?	Relevant metrics
Retention	Retention is a key signal your user base isn’t going anywhere (and therefore has financial potential). Buyers see this as a quality signal and a sign you’ve got PMF. They want to see low churn and user ‘stickiness’; people keep coming back, even when the product doesn’t have new features, or has the odd bug. Retention is the strongest signal of PMF, future cash flow, and downside protection. High retention reduces risk, even if growth slows.	DAU/MAU Cohort retention Churn rate Conversion rate
Organic growth	Buyers are looking for growth, domain authority, and demand driven by organic channels. While not all buyers care whether traffic is organic or paid (more on this later), everyone agreed that organic growth indicates positive brand association and compounding growth potential.	% of installs from organic Keyword rankings (ASO + SEO) for core terms Review volume + average rating
Monetization potential	While it may feel counterintuitive, buyers see under–monetization as a plus, since it indicates the app can make more money than it currently is. They’re looking for proven monetization success, clear room for improvement, and revenue quality as well as quantity.	ARPU Annual vs. monthly subscription mix RPI Subscription pricing and offer structure
Valuation and ROI	This is our multiplier moment. Buyers mentioned that the deal needs to make financial sense for both parties. Some had specific cash offer ranges in mind, while others specified that payback periods factor into their decision. Several said they’d pay more if the app was a good ‘fit’.	LTV/CAC Payback period Gross margin
Technical infrastructure	Buyers are looking for apps that are easy to maintain. The infrastructure should be stable and scalable. Clean architecture, well-documented processes, and a reliable backend were all directly called out.	App stability metrics Infrastructure cost as % of revenue Billing failure rate
Product-market fit	Across the board, buyers want to see evidence that the app truly solves a problem for a defined, existing audience. Without PMF, even the best-looking app is a no-go.	Retention Long-term subscribers Churn rate Social proof
Familiarity with the vertical and/or portfolio fit	Buyers prefer markets they already understand, where existing analysis can be repurposed and userbases overlap. A number of buyers said they prioritize apps in familiar markets which fit within their portfolio. However, some buyers were category-agnostic and instead looked for niche verticals with room for growth, even outside their expertise. Others said they look to plug gaps in their existing offering.	Category benchmarks vs. peers (e.g. retention, ARPU) Overlap with buyer’s existing portfolio Pricing alignment with competitors
Market momentum	Apps in growing or emerging spaces are popular. Category leaders and UA are used as a proxy for measuring momentum. Acquirers want to see a ‘booming niche’ or high-potential in a vertical.	Install growth rate (MoM/YoY) Revenue growth rate Category growth indicators Category benchmarks
Timing	Two buyers explicitly mentioned timing and looking for signals that the app can go further, but needs some help. Bottlenecks like bandwidth limits, founder fatigue, little knowledge of marketing, or hitting an execution ceiling were all mentioned.	Qualitative signals

Almost no one values pure revenue alone. High multiples and desired apps come from alignment, across retention, distribution, monetization, and personal buyer fit.

Above all, everyone was looking to see an app that has found its place with strong audience and market fit. If it slots into a strategic or portfolio gap, even better. The recurring theme is this app works, but we can make it work much better.

Okay, we know that multipliers don’t always tell the full story, and we know what buyers look for — let’s dig a little deeper into how you can illustrate these points when your app’s being assessed.

Retention signals that tell buyers your app is ‘healthy’

Retention is a crucial point for many buyers — and it makes sense; if you’re paying years in advance of the business’ success, you want to retain paying users for a considerable time. Buyers consistently ranked retention as one of their top three valuation drivers, but how can founders prepare a retention story that clearly demonstrates stickiness, and reduces perceived risk?

Based on Evelin’s conversations, retention signals fall into three buckets:

1. Retention matches category benchmarks: Buyers aren’t looking at universal stats, they’re evaluating retention relative to category norms, price point, subscription length, frequency of use etc.

“I look at who’s the biggest player in the category? How much revenue are they earning? What kind of UA channels do they run? This then serves as a benchmark for the app I’m considering. All this comes into my decision matrix.” — Matej Lancaric, Independent User Acquisition & Marketing Consultant

The State of Subscription Apps report shows how drastically retention shifts between categories. Make sure you know your industry, what competitors are doing, and how you hold up.

2. Clear stories behind early churn: With 30% of subscriptions cancelling in the first month, churn doesn’t mean an automatic ‘no’ from buyers. But you need to show that you understand why the churn happened, and have used it as a lesson to course-correct. If you can explain churn, you can defend your valuation.

3. Cohorts that stabilize over time: Even if churn is high, you can still gather evidence that the most important long-term users stick. Create a holistic view of your retention, across different subscription plans, user segments, and attribution sources.

Now, if you’re looking at your RevenueCat dashboard and panicking about your retention rate, hold on a moment. The threshold considered ‘strong retention’ varies considerably between buyers:

Ryan Thorpe, Director of Growth at Reflective Apps, said “We have some apps as low at 25%, others as high at 60% on yearly subscriptions. It massively depends on what you class as ‘healthy’, and the kind of subscription model you’re running.”

Meanwhile, Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital, said: “Generally, I would say 60–70% is a decent range for annual subscription retention, depending on the app category and age. But there are a number of factors that can impact retention (like pricing strategy). It’s just one of many metrics we look at to determine whether an app is a fit for us and what its value is.”

Takeaway: retention signals

This is a breath of fresh air for developers: it’s not all about subscriber retention — all the other signals we outlined on the app buyer wishlist matter too. Consider payback periods, your pricing model, and LTV/CAC ratio; all of these add up to tell your retention story. And even then, ‘good’ retention can be anywhere between 25–70%, depending on who you’re asking.

Make sure you understand your app’s metrics, know your category benchmarks, and can explain (or defend) any questions that may be thrown at you. Resources like the State of Subscription Apps report are a great place to start when comparing what ‘good’ looks like. You can also use tools like RevenueCat’s Subscription App Healthscore calculator to see how you measure up to competitors.

Paid or organic? Buyer preferences on traffic and UA

Another question Evelin gets all the time is whether organic traffic or scaling paid user acquisition (UA) matters more in valuations. This was one of the most polarizing questions in her interviews — some buyers want pure organic, others want pure paid. Most fall somewhere in between.

Buyers who strongly prefer organic growth

Organic traffic is seen as lower risk and higher value for money. Zach Tobin, Founder of Product Growth LLC, prefers organic: “It’s less effort to maintain, though it carries risk of algorithm changes. Ideally we want 100% organic, but I’ll invest in paid up until the breakeven point, which usually works out to an 80/20 split.”

Ryan Thorpe, Director of Growth at Reflective Apps, agreed: “Organic traffic is more reliable in distribution, predictable in its yearly returns, and has no additional high marketing costs.”

These buyers value defensibility, and compounding growth. Organic growth is perceived as a sign of quality and secure product-market fit; making it an indicator for future reliability.

“The higher the organic traffic, the better. High organic traffic that is compounding is what we’re looking for: a predictable trend, where distribution is effectively free with product-market fit attained and momentum accelerating.” — Ryan Thorpe, Director of Growth at Reflective Apps.

Buyers who prefer paid user acquisition

But for other buyers, paid UA is seen as more predictable and thus scalable:

“Paid traffic is the backbone of our strategy… We’ve seen way too many examples of young apps rapidly showing growth through pure organic activities, but being unable to sustain that for the long run. Long-term profitability and scalability means paid UA.” — Guillaume Larrieu, VP of Business Development at Quiet

Tom Kenney, CEO & Co-founder at LOYAL, explained that paid traffic can be a tactic to “break through the app store noise”, while other buyers preferred paid UA for its clearer insight into CAC, ROAS, funnel performance, and channel trends — helping prevent costly future mistakes.

Buyers who want a balance of organic and paid traffic

While some buyers said solely paid or organic traffic would turn them off an app, the majority of buyers said they wouldn’t be closed off to a split traffic mix, with many buyers actually preferring this for its balanced growth potential.

Guillaume Larrieu, VP of Business Development at Quiet, said 75/25 paid/organic is a good mix for his acquisitions: “It’s even better if organic installs are driven by organic activities, like viral videos or social content, rather than ASO implementations.”

Other buyers, like Dan Novaes, Co-Founder & CEO at Mode Mobile, were happy with a more even split:

“I like paid traffic with a strong organic multiplier. Paid is predictable and scalable if you know what you’re doing. Algorithms change, so you can’t just rely on organic. A perfect world is 50/50 organic/paid.” — Dan Novaes, Co-Founder & CEO at Mode Mobile

Takeaway: organic vs. paid traffic

Both types of traffic are relevant, but it’s clear that having paid UA is useful for buyers wanting to see metrics, profitability, or avoid old mistakes. While organic tells a story of pure growth, paid is seen as more predictable.

You don’t need a perfect traffic mix before selling, but you need to be able to back your traffic split:

If organic is your strength, quantify defensibility
If paid is your strength, present UA profitability + failed experiments + learnings

Make sure you can offer buyers clarity on what channels work, what channels don’t work, why, and where you’ve built efficiency.

“We don’t have a preference for type of traffic, but if the app is doing paid acquisition then we really need to understand the UA metrics and what’s driving paid user performance, so we can determine how sustainable and scalable it is.” — Jon Walsh, Managing Partner at Kodeon and Partner at Push Capital

Closing the deal: how to find (and actually talk to) a buyer

So you know what buyers are looking for, you’ve cleaned up your numbers, and coordinated the story of your app’s success. Now you just need to get in front of a buyer.

Sometimes a buyer may approach you, but if you’re ready to go right away, here’s how to get started.

Research different types of buyer: individuals and businesses acquire apps for many reasons, and these different buyer types will look for different things. Spend some time familiarizing yourself with who buys apps, and where your app would fit best.
Find your buyers: once you know the type of buyer you’re looking for, it’s time to network. There are websites and marketplaces where you can advertise your app, or you can speak to an M&A expert. Your best bet is typically networking in-person and LinkedIn. You’ll normally be looking for folks with business development, M&A, or partnership in their job title.
Build a target list: after identifying your buyers, start tracking everyone in a spreadsheet. Record buyer info, typical deal size, recent acquisitions, and how to contact them. You can use this to document your outreach progress, too.
Reach out via channels that don’t waste time: warm intros (founders, angels, lawyers, accountants, UA consultants) will always outperform cold calling/emailing. If you can’t find a mutual connection, direct outreach can work through the proper channels. You can also check out founder or buyer forums or marketplace websites, where buyers may be discreetly lurking. And don’t forget in-person networking opportunities!
Lead with a message, not your life story: your first message shouldn’t be a pitch. It’s a qualifier. Keep it simple, straightforward, and factual. Add top compelling metrics (think MRR, margin, growth), any relevant info (like similar apps they’re acquired, mutual connections etc.) and ask for a follow-up call.

Once you get to the first call, your next moves will depend on who you’re talking to and what they’re looking for. Remember to lead with a combination of facts and storytelling, and keep momentum up in your conversations.

What does receiving an acquisition offer look like?

You know how job ads frame ‘compensation packages’ versus individual salaries? Well, acquisition offers are similar. Typically, there’s three main structures to offers:

Cash: fixed purchase price, paid upfront when the deal closes — this is the lowest risk for sellers, and most common kind of offer
Equity: part (or all) of the price is paid in shares of the buyer’s company; tying your payment to their growth
Earnout distribution: a portion of the price is paid only once hitting agreed revenue, profit, or growth targets post-acquisition

Of the buyers Evelin spoke to, 66% do cash offers, with the remainders doing a mix of cash and equity or earnouts. While cash offers won’t necessarily pay out in one chunk (most buyers do 50% at a time, sometimes 6/12 months after the deal), they’re typically the best outcome for sellers, though equity can be valuable if being acquired by a successful company.

What makes a deal close fast?

This section answers one of founders’ biggest questions: What makes a buyer say ‘yes’ quickly?

Across interviews, buyers described what makes a deal feel ‘clean’ and easy, opposed to risky or slow. Here’s what speeds up decisions:

Clean, consistent financials: speed requires all the numbers to be in order. No messy revenue classifications. No unexplained cliffs. No ‘miscellaneous’ line items. Anything but clear numbers will add a red flag and significantly slow down the process.
Clear handover documentation: buyers moving quickly need to know they can pick up the new app and keep it ticking over without any trouble. This means getting access to: architecture overviews, data taxonomies, analytics events, roadmap history, experiment logs, growth playbooks, and anything else you have lurking in your Google Drive!
A transparent founder: yes, fast-closing deals rely on a solid business, but they’re also impacted by trust. Buyers who click with a founder and feel they’ve made a trusted connection will overlook imperfections and move faster.
A believable growth story: quite simply, buyers want to clearly be told what happens after they buy the app. Help plot their success, and they’ll be eager to sign on the dotted line.

The talent taboo: Do app buyers want founders to stay?

Most founders assume a buyer will want them gone immediately. But in reality, the answer is more nuanced — and varies depending on the buyer’s operating model.

Across all interviews, we noticed three things:

Historical learnings can be very useful to support product scale
Developers bring product and vision, then acquirers add marketing and monetization expertise
Acquirers are interested in long term relationship-building

Buyers value product knowledge more than headcount

Many acquirers prefer the original team to remain during the transition (or longer) for the undeniable reason that they deeply understand the product’s history, vision, and technical decisions.

“We like the teams to stick around as long as they’re still committed. The history of what they’ve tried is useful context, and we can build on that. Where they’re weaker, we plug in our expertise.” — Dan Novaes, Co-Founder & CEO at Mode Mobile

Michael McPhee, Head of Business Development and M&A at Leadtech Group, said they ‘absolutely’ want founders to stay: “We always try to keep the team behind the app engaged after the acquisition. They know the product best, and their expertise is crucial for continued development and fast iterations.”

Paweł Pochowski, Head of Business Development at Nova Sphere, agreed: “From a practical standpoint, having the original developer onboard ensures smoother maintenance and faster implementation of changes.”

For many buyers, acquisition is about combining skillsets of the founding team and the new owner. Michael explains: “At Leadtech, we focus on scaling marketing, monetization, and UA, while the original team focuses on product enhancements. This balance builds strong long-term partnerships and is one of the keys to our success.”

Buyers don’t want to relearn the product from scratch. They want continuity, and to capitalize on existing success.

Founder involvement signals belief and influences valuation

Some buyers also explicitly said that a founder wanting to stay post-acquisition can influence higher valuation. Paweł Pochowski, Head of Business Development at Nova Sphere, said the team prefers original creators to remain involved:

“Their continued commitment is a strong signal they believe in the product and are motivated to see it evolve.” — Paweł Pochowski, Head of Business Development at Nova Sphere

Founders wanting to stay part of the team not only indicates belief in the product, but a level of passion and commitment that’s desirable of any team member. Rather than wanting to grab the cash and jump ship, founders who stay involved can support future growth, and enable smooth handovers when (or if) the time comes to part ways.

Some acquisitions are structured to absorb the product

Despite the benefits of creators remaining involved, large app studios or portfolio operators — particularly those with their own internal product, engineering, and UA teams — are less dependent on founders staying. However, this doesn’t mean they’re kicking you out of the door.

As Yalçın Özdemir, Founder & CEO at AppNation, puts it:

“We don’t expect founders to stay on after an acquisition. As a large app studio, our in-house teams, systems, and expertise allow us to integrate products efficiently and unlock value independently. That said, in rare cases where founders are deeply embedded in the product and critical to its continuity, we may ask them to remain for a transitional period of a few months.”

This is why it’s crucial to talk about your future as a founder with any potential buyers — wanting to leave or stay with the app won’t necessarily impact the sale, but it’s vital you’re all on the same page.

Takeaway: closing the deal

Once your numbers and story are tight, closing the deal is primarily about:

Finding the right buyer
Making it easy for them to say yes

Get to know your buyer types, build a focused list of targets and start networking. Deals move fastest when financials are clean, handover docs are ready, and founders are transparent. You don’t need to commit years of your life post-acquisition, but you do need a clear transition plan. If you’re hoping to exit, consider how you can still convey confidence and historical product context to the new owners, be it through roadmaps, documentation, or a new advisory role.

Checklist: founder prep-list for getting acquired in 2026

If you’re simply looking for a to-do list that answers “What do I need to do to get my app acquired?” then your wish is our command.

Below is a foolproof checklist, distilled from Evelin’s app buyer interviews, ready for you to take the next steps towards acquisition. Think of this as ongoing prep for any founder looking to exit, be it today or five years from now.

1. Prepare your metrics

Metrics are the evidence buyers need to decide whether your app is worth their time. Prioritize clarity and consistency — confusing or contradictory metrics slow deals more than ‘bad’ metrics.

Top-level data points to prepare:

LTV by cohort and LTV/CAC ratio
Retention curves (D7, D30, D90+ where possible)
Churn reasons (voluntary vs. involuntary)
Organic vs. paid traffic split
UA profitability (by channel + key experiments)
Revenue breakdown (subscription vs. IAP vs. ads)
% of users on annual plans (if applicable)

2. Prepare your product

Think of yourself as a salesperson: for the highest valuation, you need to make it as simple and appealing as possible for buyers to pick up the product and make money.

Remember: Buyers aren’t looking for perfection, they’re looking for low friction.

Clean up any messy code paths or one-off hacks
Reduce reliance on fragile third-party dependencies
Improve onboarding clarity
Tighten paywalls and pricing logic as necessary
Grow your organic traffic where possible (ASO, reviews, SEO)

3. Prepare your financials

Messy or unclear financials are one of the fastest ways to kill a deal. If a buyer has to infer what’s going on with your numbers, they’ll assume the worst. Make sure they don’t need to guess.

Before talking to buyers:

Review and cut non-essential costs (this will improve EBITDA and optics)
Clean and reconcile your profit and loss statement
Clearly document add-backs and one-off expenses
Prepare MRR breakdowns (country, store, plan, platforms)
Be ready to explain any revenue spikes, anomalies, or drop-offs

4. Prepare your team

Buyers care less about headcount, and more about continuity and protected knowledge. Make sure you have conversations with your team before speaking to buyers.

You need to decide:

Who’s staying post-acquisition, and for how long?
What knowledge or responsibilities need to be transferred?
Whether you’re open to staying involved, and in what capacity
Updated contracts, NDAs, and IP assignments

5. Prepare your handover

Deals move faster when buyers can clearly see how they’ll run the app without you. Document things only you currently know, or product decisions and historic context that may be helpful for the team:

Current and historic product roadmaps
Feature gating logic
Paywall logic and pricing history
Onboarding flows and funnels
Architecture overview (simple is fine)
Brand assets and press kit
A master doc of tools, SDKs, dashboards, logins

6. Prepare your deal

Don’t wait until an offer appears to think about what you want, how you’ll approach acquisition conversations, and who else needs to know.

Here’s what you should think about:

Decide your minimum accepted offer and structure (cash vs. earnout vs. equity)
Identify your ideal buyer type (studio, roll-up, strategic)
Build a target buyer list
Talk with at least five potential buyers before choosing
Prep your first message and practice your pitch
Be honest with yourself about timing, motivation, and trade-offs

You don’t need to tick off every item on this list at once, it’s a big job. But each checkmark is something prepared ahead of time, so when the right buyer shows up you can move forward quickly.

Final thoughts: the reality of selling apps in 2026

After speaking to buyers, and having spoken to many founders over the years, Evelin says the biggest misconception founders have about acquisitions is that buyers are looking for perfection.

They’re not.

They’re looking for:

Predictable revenue
A product with real PMF
Retention that holds
A growth story that makes sense
A clean, transparent business

Founders who can clearly communicate these signals, both in narrative form and in hard data, are going to consistently earn higher valuations and close deals faster. So if you’re wanting to sell in the next 12–24 months, start preparing now. You don’t need a perfect app or perfect pitch — you need a clear story, transparent figures, and the right buyer.

Looking for more? Here are some related readings and tools to help you on your path to acquisition.

Interview transcripts: read the full interview questions and answers
RevenueCat’s subscription healthscore calculator
Report: State of Subscription Apps (perfect for industry benchmarking!)
Blog: How to sell an app, lessons from David Barnard
Podcast: What makes an app worth buying? Lessons from BlueThrone’s shift from volume to value
Podcast: How real demand turned a hobby app into a business
Evelin’s template: App learnings and experiments documentation
Evelin’s template: Profit and loss statement

The play-once game that sparked an indie dev career

Wed, 17 Dec 2025 09:47:26 GMT

When Taiwo Omisore set out to make mobile games, he didn’t plan on building a business. He simply wanted to make something fun during his long commute. Over time, those experiments turned into a catalog of 15 quirky, joyful, and highly personal apps. One of them, a game designed to be played only once, changed his life.

This week on Launched, we talk with Taiwo about how a side hobby became a full-time indie business powered by constraints, shareability, and unexpected virality.

The app that turned everything around

In 2020, Taiwo released One Chance, a game you can only play once. No retries. No replays. One Chance consisted of 14 quick mini-games, a leaderboard, and that’s it. He shared it quietly on TestFlight and Reddit. Then it started spreading—first in Germany, then globally. Soon, it was featured on the App Store.

What surprised him most wasn’t the downloads but the behavior. People dug up extra devices just to try again. Friends and coworkers turned it into a competition. And the game’s single ad, shown only after gameplay, became a smart trade for attention.

Real users and measurable feedback

Taiwo’s apps are playful, often strange, and always rooted in real-world input. Early on, he handed his phone to strangers on trains for feedback. Later, he’d bring folding tables to public spaces and host multiplayer games live with passersby.

That same openness shaped everything from features to monetization. After One Chance took off, Taiwo experimented with subscriptions in apps like MultiWords and 10 Games. By focusing on simple mechanics, thoughtful UX, and low-friction monetization, he found a model that worked.

Many of Taiwo’s apps have no ads or in-app purchases. Some, like Who Am I?, even inspired physical art exhibitions. Others, like Of The Day, are updated daily with curated content and community submissions. He answers emails personally and celebrates being a one-person studio.

Social media became a way to connect, not just promote. On TikTok, he shares coding sessions, street interviews, and app concepts. One clip even prompted a journal entry by Harry Styles.

A developer-first approach

Today, Taiwo is a full-time indie. But his approach hasn’t changed. He builds fast, ships often, and keeps the focus on fun. His apps aren’t optimized for retention. In fact, some are designed to be deleted. And yet, they continue to find an audience, thanks to the care he puts in them and their contagious charm.

Conclusion

From single-play games to curated journals, this episode captures what’s possible when an indie dev leads with curiosity. Taiwo Omisore shows that with honesty, experimentation, and a little bit of joy, even the simplest ideas can turn into something lasting.

Monetize from Your IDE: AI assistant + RevenueCat MCP in the IntelliJ Plugin

Wed, 17 Dec 2025 01:32:17 GMT

We’ve announced the RevenueCat IntelliJ plugin and now it’s even got smarter. With the new AI Assistant feature, you can now query your subscription metrics, explore offerings, and get answers about your RevenueCat integration, all without leaving your IDE. Behind the scenes, this AI Assistant is integrated with the RevenueCat MCP Server, bringing the power of AI-assisted subscription management directly into your development workflow.

In this article, you’ll explore how the AI Assistant works in RevenueCat’s IntelliJ plugin, what you can accomplish with it, and how this feature can help you make data-driven decisions that boost your subscription revenue.

What is the RevenueCat MCP Server?

Before diving into the AI Assistant, let’s understand the foundation it’s built on. The Model Context Protocol (MCP) is an open standard that allows AI assistants to interact with external tools and data sources. RevenueCat provides an official MCP Server that exposes subscription management capabilities to AI models.

The MCP Server provides tools for fetching subscription metrics like MRR, active trials, and revenue. It can list and inspect offerings, packages, and products. It retrieves customer subscription information and provides documentation and resource links.

The IntelliJ plugin’s AI Assistant uses the same underlying tool architecture as the MCP Server. This means you get consistent, reliable access to your RevenueCat data directly inside your IDE with our preferred AI model.

Setting up the AI Assistant

Getting started with the AI Assistant takes just a few steps.

First, open IntelliJ Settings and navigate to RevenueCat, then AI Settings. Enable the AI Assistant toggle to activate the feature.

Next, choose your AI provider. The plugin supports OpenAI (GPT-4o, GPT-4o Mini), Anthropic (Claude 3.5 Sonnet, Claude 3 Haiku), and Google (Gemini 2.5 Flash, Gemini 2.5 Pro). Each provider has different strengths—GPT-4o and Claude Sonnet excel at complex reasoning, while GPT-4o Mini and Gemini Flash offer faster responses for simpler queries.

Then enter your API key for your chosen provider. The key is stored securely in IntelliJ’s credential storage on your local computer.

Finally, make sure your RevenueCat API credentials are configured in the main RevenueCat settings panel.

Once configured, you’ll find the AI Assistant panel in the RevenueCat tool window. The interface is simple: a chat-style conversation where you can ask questions and receive responses.

What can you do with the AI Assistant?

The AI Assistant exposes four core capabilities through its tool set. Let’s explore each one with practical examples.

Fetching subscription metrics

The most common use case is checking your subscription health without leaving the IDE.

Ask the assistant “What are my current metrics?” or “Show me my MRR” and you’ll get a formatted response with your Monthly Recurring Revenue (MRR), active trials count, active subscriptions count, and total revenue. More than just querying, it’s your mini consultant. You can play with these metrics and get useful strategies to boost your revenue.

This is invaluable during development. You can push a new paywall implementation, then immediately check if metrics are trending in the right direction. No dashboard tabs, no context switching.

You can also ask follow-up questions like “How does my trial conversion look?” or “What’s my revenue growth?”, and “What can I do for boosting my revenue?” The AI will analyze your metrics and provide insights based on the data.

Exploring offerings and packages

When implementing purchase flows, you need to know exactly what offerings and packages are available.

Ask “What offerings do I have configured?” and the assistant will list all your offerings with their lookup keys, display names, and whether each is marked as the current offering. For each offering, you’ll see the packages it contains.

This is particularly useful when you’re implementing a paywall and need to reference the exact package identifiers. Also, you can get directly the SDK API codes, by asking like “How should I fetch offerings on Android using Kotlin?”

No more switching to the dashboard to double-check package names. Ask the assistant, get the answer, keep coding.

Checking project configuration

Before diving into implementation, verify your setup is correct.

Ask “What’s my project status?” and the assistant will show whether your API key is configured, your project ID, whether the SDK API key is set up, and the status of notifications and webhooks.

This quick health check catches configuration issues before they become runtime bugs. If something’s missing, the assistant will tell you exactly what needs to be configured.

Finding documentation and resources

When you need help with implementation, ask “Where can I find documentation for Android integration?” or “How do I set up webhooks?”

The assistant provides curated links to relevant RevenueCat documentation, SDK guides for Android, iOS, Flutter, and Kotlin Multiplatform, community forums and GitHub issues, and the RevenueCat dashboard and API reference.

Choosing the right AI model

The plugin supports multiple AI providers and models. Here’s how to choose:

For complex analysis and detailed explanations, use GPT-4o or Claude 3.5 Sonnet. These models excel at understanding nuanced questions and providing comprehensive answers. They’re ideal for questions like “Analyze my subscription trends and suggest improvements.”

For quick queries and fast responses, use GPT-4o Mini, Claude 3 Haiku, or Gemini 2.5 Flash. These models respond faster and cost less per query. They’re perfect for simple lookups like “What’s my MRR?” or “List my offerings.”

For balanced performance, Gemini 2.5 Pro offers strong reasoning capabilities with good response times.

You can switch models at any time in settings. Try different models to find what works best for your workflow.

Boosting revenue with AI-assisted insights

Beyond convenience, the AI Assistant can actively help you improve your subscription business.

Identify optimization opportunities

Ask “What do my metrics tell me about my subscription health?” The AI will analyze your MRR, trial counts, and active subscriptions to identify patterns. Low trial conversion? The AI might suggest reviewing your onboarding flow. High churn? Consider implementing win-back campaigns.

Validate A/B test implementations

When implementing offering experiments, verify your setup is correct. Ask “Show me all my offerings and their packages” to ensure your test and control offerings are configured properly before running the experiment.

Debug purchase issues faster

When a user reports a purchase problem, you can quickly check your configuration. “Is my project configured correctly?” gives you an instant health check. “What packages are in my default offering?” helps verify the user should see the right products.

Getting help and exploring more

The AI Assistant includes a help icon that links directly to the RevenueCat MCP usage examples documentation. This resource provides additional query examples and advanced usage patterns.

You can also explore the RevenueCat IntelliJ plugin’s other features. The metrics dashboard, offerings explorer, SDK release notifications, and webhook listener all complement the AI Assistant to create a complete subscription development environment.

Conclusion

The RevenueCat IntelliJ plugin’s AI Assistant brings subscription intelligence directly into your development workflow. By combining the power of modern AI models with RevenueCat’s comprehensive tooling, you can query metrics, explore offerings, check configuration, and find documentation—all without leaving your IDE.

The result is less context switching, more flow state, and faster development cycles. Whether you’re building your first paywall or optimizing a mature subscription business, having AI-assisted access to your RevenueCat data makes the process smoother.

The feature is available now in the RevenueCat IntelliJ plugin. Configure your AI provider, connect your RevenueCat credentials, and start asking questions. Your subscription metrics are just a chat message away.

How to monetize your app without ads

Tue, 16 Dec 2025 11:58:46 GMT

Ads are a common way of monetizing apps — providing a way to extract value from users without making them pay for the app directly. However, due to the scale they require most in-app ads never end up providing enough money to justify the downsides they bring. Additionally the negative effect on user experience and the dependency on ad networks to end up tilting the scale to the negative.

At RevenueCat we aren’t against ads by default, but for most apps asking customers to pay for the app is a better way. This reasoning comes into effect especially when you’re monetizing a new app, where retention is more important than acquiring. That’s why we made this guide to monetizing your app without ads, going through all the other monetization methods you have at your disposal.

This guide takes an indie developer friendly approach, suggesting methods you can adopt from already before you launch your app, and offering guidance on moving from one monetization method as you scale.

Why indie developers should not choose ads

When you’re an indie developer, ads are most likely the worst choice for monetizing your app. Hear me out. You most likely built your app because you yourself had use for it? Or perhaps you wanted to build something cool, or perhaps you just like building apps. Whatever the case is, what you’re predominantly not interested in is money in most cases, but building something people want to use.

There is a certain thrill that you get when you see people using your app that is hard to beat. It can almost become a goal to get more users. At the same time, you wouldn’t mind getting a little bit of monetary recognition for your work. At that point you start to think “I don’t want to restrict my app from anyone, I’ll just put ads”. But ads come with multiple downsides:

Massive downgrade to user experience and messy looking UIs
Plenty of privacy concerns due to user data tracking
Performance issues (draining more battery, more data usage)
Your personal brand will take a hit

In general, it’s hard to position your app as a serious app with ads. There are plenty of ways to monetizing your app that have way fewer tradeoffs. Not to mention how little money ads usually bring you.

To give an example let’s look at the 1000 true fans hypothesis, an article by Kevin Kelly about how you can build a business or side hustle by just having 1000 true fans who all pay a little bit for the things you’re producing. 1000 people paying just a dollar a month is $12k a year. If you had 1000 users using your app with ads, you would only get a few dollars per month.

The core non-ad monetization models

Whether you’re targeting iOS or Android, the ways you can monetize your app are the same. Let’s go through all the ways you can monetize your app beyond ads.

Pay to download

Pay for the full version of the app used to be a common model back when software was still sold on CDs (ask your father). Back then developers could release a new every year and capture more revenue from users as they bought the new version of your app.

App Store and Google Play Store still support putting a price on your app, but Apple for example considers this model outdated. As developing and supporting an app is a continuous process, the only time you should consider adopting pay to download is if you’re going to release your app once, and make only very limited changes to it in the future.

In-app purchases (IAP)

Once the user has downloaded your app, whether that was for free or for a charge, you can actually ask users for more money. Both Play Store and App Store support payments inside apps for purchasing digital goods inside the app, hence the name in-app purchases. There are few different in-app purchase options: consumables, non-consumables, non-recurring subscriptions, and recurring subscriptions: the latter which we will talk about in its own section. Let’s first go through the other options.

Consumables

Consumable in-app purchases are payments for things in the app that the user purchases and then consumes, such as extra lives in a game. They grant users the access to contents only until they are used in the app, so they work well for example in games where you can build custom economies based on them.

Non-consumables

These purchases never expire and the user is for example able to recover the purchases after uninstalling and reinstalling the app, as the purchase information is stored by Apple and Google. You can make non-consumable purchases unlock features in your app for permanent use. You could almost think of these as a way of moving the pay to download further into the actual app itself.

Non-recurring subscriptions

These purchases as the name suggests only grant the user access to features of the app for a certain period of time, for example one month, after which Apple and Google (TK check if google has this type actually) mark them expired. You can build for example limited time

Subscriptions

Of all the mentioned in-app purchases options, only consumable in-app purchases (through repeated use) and recurring subscriptions (through periodic payments) bring you that much needed recurring revenue to continue building your app. Building your monetization around consumable purchases can be difficult, so recurring subscriptions is your best option for monetizing your app if you’re looking for recurring revenue.

The fundamental concept behind subscription is simple: the user pays a periodic subscription fee and has access to all features of your app during the subscription period. If they do not cancel their subscription their access to the app continues, and they keep paying you.

Both App Store and Play Store provide extensive options for configuring subscriptions with different billing periods, prices, and offers such as free trials. Deciding on the pricing can get tricky, but benchmarking against your competitors is a good way to go. You can learn about these from our State of subscription apps report.

Donations and tip jars

Perhaps you don’t want to limit your users’ access to your app or its features, but if they feel like sponsoring you in any way, you wouldn’t say no to that? These types of payments, whether they are sponsorships, donations, or tipping also have to go through Apple’s and Google’s in-app purchase infrastructures.

Donations and tipping and essentially just consumable purchases. If you’re interested in learning more about implementing these in your app, I suggest you take a look at this blog post about building a tip jar in your app.

Virtual currencies

Virtual currencies are in-app currencies that allow your users to pay for using features and services of your app, without having to go through the in-app purchase infrastructure. This could be for example something like Duolingo Gems, which allow you to restore your broken streak. Another type of currency could be a second of video generation in an AI video creation app.

The power of virtual currencies is that you can grant users with virtual currencies either through purchases or by completing certain actions. RevenueCat’s Virtual currencies feature allows you to grant them through both subscriptions as well as consumable purchases, meaning users could receive 500 gems every month for their subscription, but on top of that they can still purchase additional gem packs. Alternatively you could also grant a few gems for watching an ad (if you decide to keep those around).

Games and gamified apps often use some form of virtual currencies, but as mentioned they can also be a flexible monetization method for AI powered tools, where the AI usage can be directly tied to usage. If you’re building an AI-powered app, take a look at this tutorial on monetizing your AI app with virtual currencies.

Hybrid models

Sometimes the best monetization strategy is one that combines multiple different models. Your app could offer both recurring options for monthly and yearly subscriptions, with an extra lifetime subscription that uses a non-consumable in-app purchase to do that. Hybrid models are becoming far more popular and effective than they were in the past. According to the 2025 State of Subscription Apps report, more than 35% of apps now combine subscriptions with consumables or lifetime purchases, and the fastest-growing categories (Gaming at 61.7% and Social & Lifestyle at 39.4%) are leading the shift.

If your app currently has ads, one option is not to transition away from them completely, but instead make it so that the free version of the app has ads, which users can then remove by subscribing. You can learn more about this approach from our building ad-free subscriptions with RevenueCat article.

Virtual currencies is the most flexible option for hybrid models, as mentioned above, since it allows you to add two different recurring revenue models, subscriptions and consumable in-app purchases, without having to manage the complex in-app currencies yourself.

How to find the best model for your app

Since there are multiple ways to monetize your app, it might not be instantly evident what model suits your app the best. This is also something where RevenueCat can help you

Use State of Subscription Apps report to understand your competitors

Every year RevenueCat publishes a report called the State of Subscription Apps, a preview into our insights on in-app subscription performance benchmarks, drawing from the world’s largest and most comprehensive subscription app data set.

The report is a valuable tool for understanding how apps are performing under different monetization scenarios, across both the iOS and Android ecosystems. You can find the latest report here.

Experimentation is the key

Once you have a hunch on what kind of monetization method and pricing could work for your app it’s time to get to work by experimenting. RevenueCat allows you to build different paywalls, target specific types of users, build multiple pricing options with offers, and best of all extensively experiment and test which of these changes convert best to paying users. RevenueCat’s blog has articles around price testing your app’s subscriptions and a study guide for building paywalls that you should go through, should run into a wall.

Wrapping up

Ads promise easy revenue, but for most indie developers they deliver the opposite: low earnings, lower retention, and a worse user experience. Sustainable growth comes from models that align your incentives with your users — and that almost always means asking people to pay for the value you’re building.

Subscriptions remain the most reliable path to recurring revenue, but they’re not the only one. Consumables, virtual currencies, and hybrid approaches let you monetize different user segments without compromising the product experience. As the 2025 State of Subscription Apps shows, the top-performing apps increasingly mix models to boost LTV and give users more flexibility.

Where you start matters less than how quickly you learn. Experiment with pricing, trials, paywalls, and offers. Use data to refine your approach. And lean on tools like RevenueCat to test, iterate, and scale your monetization without rebuilding infrastructure every time.

Build something people love — then choose a monetization model that helps you keep building.

HDYHAU surveys as an attribution source: when they work (and what to do when they don’t)

Tue, 16 Dec 2025 10:50:07 GMT

Uncovering where users first heard about your app and how they came to download it is an age-old problem for app businesses. Tracking attribution is key to tapping into your best user acquisition (UA) sources, but with advertising spread across multiple channels and things like word-of-mouth hard to track, teams are often left in the dark.

‘How did you hear about us?’ (HDYHAU) questions seem to solve this problem, but are they really the solution?

Why use HDYHAU?

Many subscription apps face growing data discrepancies when it comes to tracking attribution. This is largely because iOS remains the primary source of revenue — but while these users typically have higher conversion rate (CVR) and stickiness, iOS offers limited attribution tracking. Structured frameworks for modelling attribution on iOS can help, but that’s only part of the equation.

To address these gaps, teams have opted for a simple way to measure the impact of ads: directly asking users “How did you hear about us?”. This question, commonly shown during onboarding or purchase flows, allows users to self-report their acquisition source. The answer options typically include:

Facebook
Instagram
TikTok
YouTube
Google
Friend
Other

(There are some apps that randomize the order of the options to ensure answers from users are intentional, but in my experience, this doesn’t tend to impact the distribution of the answers.)

For early-stage teams running a small number of social channels (often Meta or TikTok) HDYHAU data has been a gamechanger; helping surface under-attribution in probabilistic systems and align performance with blended results. In these cases, self-reported data often appears more consistent than network or mobile measurement partner (MMP) reporting. However, as apps scale and expand into additional channels, HDYHAU responses become increasingly unreliable as an attribution source (more on this later).

The HDYHAU question fixes a common issue that all advertisers have with iOS: it gives the possibility of comparing like-to-like in a landscape where every attribution methodology works in a different way. If you use tools like Amplitude or Mixpanel, you can have graphics like this:

As you can see, this graphic is simply showing the answers for the HDYHAU question on a weekly basis, so if you take the campaign data, the MMP data, and compare them against this first-party data, you have a very simplistic way of seeing if your campaigns are underattributing or not.

According to my experience, when you use probabilistic methodologies like ADC for TikTok or AEM for Meta, you will likely track less conversions in your campaigns than have actually happened — leading you to make wrong paid UA decisions.

However, with HDYHAU, you quickly solve that problem by comparing both sources, so you can see if certain attribution channels are over- or under-attributed. That looks like this:

Since you (understandably) expect the user-reported data to be most accurate, marketers using HDYHAU as an attribution source typically place more importance on this first-party data than the MMP or ad network data. In most cases, they see greater impact on the blended results when they enable campaigns (like in the screenshot above, from a current project of mine).

Example: how HDYHAU impacts revenue

In my example above, the average difference between HDYHAU and the installs reported by Meta on a daily basis is 95. Assuming you have a 5% CVR, you’re roughly missing ~5 subscriptions per day (150/month) comparing the two attribution sources.

Note: You can also have direct subscription reports on Amplitude, if you group users by the answer they gave in the HDYHAU step, but for the sake of this example let’s keep it simple.

Let’s consider two scenarios where we follow this first-party data:

Scenario one:

On day 90, your app has a lifetime value (LTV) of $50; on day 60, it has an LTV of $30
You don’t have HDYHAU in place, so you’re relying on MMP and ad network data for attribution
You spend $10k on paid campaigns during one month, then crosscheck Meta and MMP data, reporting 200 purchases — resulting in a $50 customer acquisition cost (CAC)
In this scenario, your LTV would cover that CAC in 90 days, so from day 90 you would start to make profits

Scenario two:

Imagine the same scenario, but you do have HDYHAU in place:
You see the same difference on conversions as in my example above (~150/month)
With your first-party data in place and spending $10k on paid, you report 350 subscriptions in the same period of time, giving you a CAC of ~$29
In this scenario, you begin making profit from day 60

In a business model where cash flow is critical, this difference is hugely impacting every decision on weekly optimization of paid campaigns, and how aggressively you can scale them.

This is why first-party data has become a highly-valued data source for app teams relying on social ads. In a world shaped by ATT, SKAN, and privacy constraints, it’s one of few reliable ways of ensuring paid campaigns get the credit they deserve — because the answer is coming directly from users, rather than depending on probabilistic attribution methodologies that rely on fingerprinting.

At a first glance, HDYHAU feels like the perfect solution to address all this attribution mess happening in iOS. No black boxes, no delayed postbacks, no large discrepancies. Just a direct answer from your user collected within your product.

But there’s two significant flaws in this:

The easy-to-read attribution breaks down when you diversify paid ad channels
And what’s more, HDYHAU relies on users accurately recalling and recording where they first heard about you

Most companies begin with the classic ad networks (Google, Meta, TikTok) when they start paid UA, and using first-party data with this setup is smart — it’s likely more accurate than relying on probabilistic attribution. But when you have a large budget for these channels and run alternative ad channels (e.g. a demand-side platform (DSP)), HDYHAU begins losing accuracy.

On a high level of spend, you have a large presence across social media due to paid ads and multiple channels — users will likely have come across an advert, logo, or app name long before they actually download the app. So when they click ‘Facebook’ or ‘TikTok’ as where they first heard about you, they’re actually selecting:

What they think influenced them
What options feel familiar to them

At this point, HDYHAU surveys aren’t capturing causal attribution; they’re identifying perceived influence, brand familiarity, and recall under pressure.

Example: how distribution of spend impacts HDYHAU

This fundamental flaw of HDYHAU at a large business level is also why the distribution of media mix and ad spend will likely affect the distribution of answers.

For example, if your media mix is 60% Meta, 20% TikTok, 20% Google, you’ll likely have a HDYHAU attribution that reflects this, even after running campaigns in an alternative channel. This interpretation becomes critical the moment you introduce these channels into your media mix.

This screenshot is real data from a recent Applovin campaign I ran for a new client. They have a rough $50–60k spend, with 90% to Meta and the remainder to TikTok. We started Applovin for the first time in November and began monitoring the answers to ‘Other’ in the HDYHAU survey.

As you can see, there’s no difference in the baseline after running the campaigns for more than 10 days and spending more than $10k (the minimum budgets in these platforms are much higher). The MMP reported +200 conversions to the campaigns based on last click, so we would have to see an uplift in this baseline.

The reason behind this is simple — platforms like Applovin operate very differently from traditional social ads: they buy inventory across thousands of apps, and show ads beyond social media platforms e.g. playing a game, scrolling, or waiting for a reward. So later, when users reach the HDYHAU question, they just select the most familiar option.

Meta, Google and TikTok benefit massively from this bias, since they’re culturally-dominant and top-of-mind. So even if users didn’t discover the app on these platforms, they’re a safe choice.

The result? HDYHAU surveys over-attribute conversions to the most recognizable platforms → you draw conclusions based on inaccurate data → you base budget allocation and channel optimization decisions on this.

TL;DR: when to use/avoid HDYHAU for attribution

When HDYHAU is treated as accurate attribution, demand-side platforms are set up to (look like they) fail. This doesn’t make HDYHAU surveys useless, but it does limit their use to specific scenarios. Here’s a summary:

✅ When HDYHAU surveys can be reliable:	❌ When HDYHAU may be misleading:
– Paid acquisition is limited to one–two major social platforms – Spend is relatively concentrated (e.g. Meta or TikTok) – The goal is detecting under-attribution in probabilistic systems – Teams are early-stage and optimizing for speed over precision – You want to get indicators of shifting channel familiarity and trends – You need directional insights on brand awareness	– Multiple channels run simultaneously (social + DSPs + search) – Brand presence is already high across platforms – Users are exposed to ads outside recognizable environments

How to measure attribution with DSPs

If you read to this point you’re probably wondering what you should rely on for attribution. HDYHAU surveys are still useful, but only on the small–medium level. Exploring how to measure attribution for larger ad budgets is another article in itself — but broadly-speaking, these are the most effective approaches to see if DSPs are really bringing impact:

Incrementality tests with GEO holdouts
Incrementality tests with Ads ON/OFF
Incrementality tests with budget ramps
Blended performance analysis
SKAN analysis (less effective because it tends to underattribute)

In my opinion, it’s valuable to run incrementality tests where you maintain the classic channels with a stable spend for a few days, and then you substantially increase the budget on the DSP. You can then measure how the baseline of conversions changed before and after starting the campaign in the DSP — and attribute the difference in the baseline to the MMP.

With this approach, you don’t need to pause your main growth driver, since you normally start with DSPs when you’ve already reached a nice volume of spend on the classic channels.

Yes, these methods are slower, less intuitive and harder to justify but they measure causality, not memory.

The value of HDYHAU is how you use them

In the current privacy landscape, first-party data feels like a safe fallback; but data being first-party doesn’t automatically make it correct. The work of growth teams and marketers is to adapt your framework to track data to the current channel mix and then compare how it evolves when a new channel is introduced.

If you want to understand whether your spend is working, you need measurement frameworks built for causality: incrementality tests, controlled experiments, and blended performance analysis. Surveys can still play a role, but only as qualitative context — not as evidence.

Announcing RevenueCat IntelliJ Plugin

Mon, 15 Dec 2025 01:30:14 GMT

Building subscription-based apps involves constant context switching. You write code in your IDE, check metrics in the RevenueCat dashboard, monitor webhook events in a terminal, and browse documentation in a browser. Each context switch may break your flow and add friction to the development process. What if you could bring RevenueCat directly into your IDE?

Today, we’re announcing the RevenueCat IntelliJ plugin, which is a tool that integrates RevenueCat’s core functionality directly into your IDE. You can track metrics, receive purchase notifications, integrate SDKs, set milestones, and stay updated with releases without leaving your development environment.

The plugin works across the entire JetBrains IDE: IntelliJ IDEA, Android Studio, WebStorm, PyCharm, Fleet, and 10+ other IntelliJ-based IDEs. Whether you’re building Android apps in Android Studio, cross-platform apps in IntelliJ IDEA, or React Native apps in WebStorm, the plugin provides a consistent experience.

Getting started

The plugin is available on the JetBrains Marketplace. You can install it directly from your IDE:

Open Settings → Plugins → Marketplace
Search for “RevenueCat”
Click Install

After installing the plugin, open the RevenueCat tool window from the right sidebar. If you don’t see it there, you can enable it via View → Tool Windows → RevenueCat. Then first, configure your API credentials in the settings panel, and you’ll see your metrics appear immediately. You can get all of these keys on your RevenueCat dashboard.

Track key metrics

The plugin displays your RevenueCat dashboard metrics directly in your IDE. You can monitor MRR, active subscriptions, active trials, revenue, and other key metrics at a glance while you’re working on your app.

The metrics panel shows your current subscription values without requiring you to open a browser. When you’re debugging a purchase flow or implementing a new subscription feature, having immediate visibility into your metrics helps you verify that changes are working as expected. The data refreshes by clicking the refresh button, or when you change any configurations.

This is particularly valuable during feature development. When you’re implementing a new subscription tier or modifying your paywall, you can immediately see the impact on your metrics. You can start your morning by exploring the metrics on the IDE directly and focus on your code right away.

Receive notifications for purchases and webhook events

Want a little dopamine hit from new purchase notifications while you’re building? Stay informed about what’s happening with your app’s subscriptions in real-time. The plugin can receive RevenueCat’s webhook events and display notifications for new purchases, renewals, cancellations, billing issues, and other subscription lifecycle events directly in your IDE.

You can set up a webhook for your IDE in the RevenueCat settings. This plugin includes a lightweight local server to listen for webhook events, so you’ll need to configure webhook integration on the RevenueCat dashboard and install ngrok by following the plugin guide. Once it’s set up, the webhook listener will automatically start whenever you restart your IDE.

Once you’ve finished the configuration, you can send a test event from the dashboard by going to Integrations (left menu) → Webhooks → Send test event.

The webhook integration works by running a local server managed by a plugin that receives events from RevenueCat server. When a purchase occurs, a renewal process, or a subscription cancels, you get an immediate notification in your IDE. This creates a tight feedback loop during development, you make a test purchase, and within seconds you see the confirmation appear in your IDE.

This is particularly useful during development and testing. When you’re testing purchase flows with sandbox accounts, you can immediately see whether the transaction went through without checking the dashboard or digging through logs. The notification shows you the event type, the product involved, and relevant details, giving you instant feedback on your implementation.

Browse and manage offerings

Your offerings define what subscription products are available to your users. The plugin displays your offerings directly in the IDE, showing each offering with its packages, current status, and paywall configuration.

Each offering card shows the offering name, the number of packages it contains, and the individual packages with their display names and identifiers. You can quickly scan your product catalog without opening the dashboard. For offerings marked as current, a badge indicates which offering your app serves by default.

The plugin provides a part of RevenueCat’s paywall functionality. If an offering has a paywall configured, you can click the Paywall button to open the paywall tab of your offering directly in your browser. If an offering doesn’t have a paywall yet, the Add Paywall button creates one for you and opens the paywall builder so you can start customizing immediately.

The Manage button takes you directly to the offering’s configuration page in the RevenueCat dashboard. This provides quick access when you need to modify packages, update metadata, or configure advanced settings. Instead of navigating through the dashboard hierarchy, you jump straight to the offering you’re working with.

Integration wizard: Easy SDK and Paywall setup

Setting up RevenueCat in a new project involves multiple steps: adding dependencies, configuring the SDK, setting up entitlements, and integrating paywalls. Each platform has its own requirements, and getting the configuration right requires consulting documentation and copying code snippets. The integration wizard guides you through this entire process.

The wizard supports Android, Kotlin Multiplatform, and Flutter projects. It detects your project type and generates the correct dependency configurations with the latest SDK version for your build system, whether that’s Gradle, or pub.yaml. Beyond dependencies, the wizard suggests initialization code tailored to your platform.

You can choose between SDK-only integration or full paywall integration. The SDK-only option sets up the core RevenueCat functionality for fetching offerings and processing purchases. The paywall integration option adds RevenueCat’s UI components, generating the code to render the paywalls that you can customize in the RevenueCat dashboard.

The wizard eliminates the friction of initial setup. Instead of spending time on boilerplate configuration, you can focus on building your subscription experience.

Set milestones and monitor progress

Building a subscription business is a long-term endeavor. Having concrete goals to work toward helps maintain momentum during development. The plugin lets you define revenue and subscriber milestones to track your app’s growth.

You can set targets for MRR, active subscriptions, active trials, new customers, or total revenue. The plugin monitors your progress against these milestones and displays your current standing. When you hit a milestone, the plugin celebrates with you, providing a moment of recognition for your progress.

This feature transforms abstract business goals into tangible targets visible in your development environment. When you’re deep in implementation work, seeing that you’re 80% of the way to your next subscriber milestone provides motivation to push through. It connects the code you’re writing to the business outcomes you’re working toward.

Stay up to date with SDK releases

RevenueCat’s SDKs are actively developed, with regular releases that include bug fixes, new features, and performance improvements. Staying current with SDK versions ensures you have access to the latest capabilities and fixes, but manually checking GitHub for new releases is tedious.

The plugin fetches release notes from RevenueCat’s GitHub repositories and displays them in a dedicated dialog. You can view the latest releases for Android, iOS, Kotlin Multiplatform, Flutter, and React Native SDKs. Each release shows the version number, publication date, and full release notes, so you can quickly assess whether an update is relevant to your project.

More importantly, you can enable notifications to get alerted when new SDK versions are released. When a new version drops, you’ll see a notification in your IDE with the version number and a link to the full release notes. This helps you stay current with bug fixes, new features, and breaking changes without manually checking GitHub or subscribing to release notifications.

The notification system is opt-in on a per-platform basis. If you’re only building Android apps, you can enable notifications just for the Android SDK. If you’re building cross-platform, you can enable notifications for multiple SDKs.

Browse blog posts and get notified

The RevenueCat blog publishes articles about new features, engineering insights, best practices, and mobile subscription industry trends. Staying informed about these updates helps you make better decisions about your subscription implementation.

The plugin fetches recent articles from the RevenueCat blog and displays them in a browsable list. Each article shows the title, publication date, and a brief description. Clicking an article opens it in your browser, letting you read the full content when you’re ready.

You can enable notifications to get alerted when new articles are published. This keeps you informed about RevenueCat updates, new SDK features, and industry insights without manually checking the blog. When a new article is published, you’ll see a notification in your IDE with the title and a link to read more.

Conclusion

The RevenueCat IntelliJ plugin brings subscription management more convenient directly into your IDE. Instead of context switching between your IDE, the RevenueCat dashboard, GitHub, and the blog, you can access everything from a single tool window. Track metrics while you code, receive instant notification on purchases, set up new projects with the integration wizard, monitor your progress toward business goals, stay current with SDK releases, and keep up with the latest articles.

RevenueCat Blog

Launch Party June ’26: The New Features You Should Know

Paywalls

AI Editor

Paywall Rules

Funnels

Funnels Builder

A/B Testing

Web

One-Tap Purchases via Express Checkout

Stripe Billing & Stripe Managed Payments

Discounts and Discount Codes

Experiments

pLTV Winner, Credible Intervals, Astra Analysis, Winner Rollout

AI Tools

Rico

AI Toolkit

Charts & Dashboard

Benchmarks

In-App Ad Revenue in Charts

Store Updates

Apple 12-Month Commitments

Join our next office hours

Introducing the RevenueCat Codegen Gradle Plugin: type safe entitlements and offerings on Android

The fundamental problem: Dashboard keys as raw strings

Setting up the plugin

Step 1: Apply the plugin

Step 2: Configure the extension

Step 3: Build

What gets generated

Entitlement ID constants

Type safe EntitlementInfos extensions

Convenience CustomerInfo extensions

Offering and package accessors

Naming styles: From lookup keys to Kotlin identifiers

Caching and offline mode: Builds that don’t depend on the network

Refreshing after dashboard changes

How it works: Two Gradle tasks and a schema cache

Keeping the secret key out of version control

Trade offs: When generated accessors fit and when they don’t

Conclusion

How to build a reactivation strategy that actually works

1. Start at the moment of churn: Your cancellation flow is step zero

What to implement

What to ask

What to offer

What data to capture

2. The post-churn relationship: how to stay present without being annoying

Channel strategy

3. Timing matters more than what you say

4. Offer strategy: what works vs what feels desperate

5. Make it frictionless to return

6. Ultimately, the quality of your product determines reactivation success

Final thought

WWDC26: What’s new for subscription apps

Annual subscriptions can now bill monthly

What changes in your code

What changes on your server

What this means for RevenueCat customers

Retention Messaging lets you save subscribers at the moment they cancel

What this means for RevenueCat customers

Subscriptions can now be sold to groups and organizations

Entitlement design is the hard part

Cross-developer Bundles and Suites

What this means for your RevenueCat Dashboard

App Store Merchandising: new placements for Creative Assets

Personalized Collections and App Notes

Offer Code Redemption gets a proper result

Unified App Review submissions

App Review Guidelines: saturated categories now face removal, not just rejection

Summary

Don’t trust your Flutter app: verifying RevenueCat entitlements with the Firebase Extension

What are we building?

Level 1: Client-only check

Level 2: Client-only check + Firebase App Check

Level 3: Server-verified entitlements

Identifying Firebase users in RevenueCat

Understanding Firebase Cloud Functions

Implementing Cloud Function for movie-playing functionality

Option 1: Direct calls to RevenueCat API

Type safe `EntitlementInfos` extensions

Convenience `CustomerInfo` extensions