First of all, you don’t need to update your RevenueCat SDK or change your configuration because of Apple’s In-App Purchase metadata API changes. Your purchases, renewals, restores, entitlements, webhooks, and product sync are unaffected.

RevenueCat uses the affected App Store Connect endpoints in our product editing tools, but we’re migrating those tools to Apple’s replacements and will complete the migration before Apple removes the deprecated endpoints.

What Apple is changing

App Store Connect API 4.4.1 introduced a version-based workflow for In-App Purchase, subscription, and subscription group metadata. Previously, localizations and images were attached directly to an In-App Purchase, subscription, or subscription group. To change them, you updated the metadata on that product.

With the new workflow, localizations and images belong to a version: a container for metadata that goes through App Review. You create a new version when making changes, keeping the proposed updates separate from the metadata already live on the App Store.

Existing integrations can still use the deprecated endpoints during the transition. Apple’s migration guide explains the replacement workflow.

What this means for RevenueCat customers

These changes affect how RevenueCat creates or edits product metadata in App Store Connect through Product Editor and the product tools available through our MCP server.

They don’t affect the services your app uses to sell subscriptions and deliver access:

• Purchase processing and receipt validation
• Renewals and restores
• Entitlements
• Webhooks and integrations
• Product import and sync from App Store Connect

There’s no minimum RevenueCat SDK version for this migration, and you don’t need to change your RevenueCat configuration.

Migration status

We're migrating Product Editor and the MCP product tools to the version-based endpoints. We'll complete the migration before Apple's removal date, and we're targeting December 2026. Until then, these features keep working on the current endpoints, which Apple still supports.

The new flow has more steps on Apple's side. Products need a draft version, localizations are attached to that version, and the version goes through a review submission. RevenueCat will handle all of that for you. You'll keep using Product Editor the same way.

FAQ

Has RevenueCat migrated off the affected endpoints?

Not yet. We use them only in Product Editor and the MCP product tools, and the migration is in progress.

When will the migration be done?

Before Apple's removal date. We're targeting December 2026

Do I need to update the SDK or change any configuration?

No. This change only affects how RevenueCat talks to App Store Connect, and there's no minimum SDK version tied to it.

Are purchases, renewals, restores, entitlements, webhooks or product sync affected?

No. None of these use the affected endpoints.

Where can I find updates?

We'll update this page when the migration is complete.

At first glance, Bundles and Suites sound very similar. A subscription bundle is one in-app purchase that combines up to five subscriptions customers can also buy separately, at a lower combined price. It can include subscriptions within one app, across your apps, or across apps from multiple developers.

A subscription suite is a single subscription that provides access across a set of up to 15 apps from one developer. Its included subscriptions exist only within the suite, and apps’ subscriptions aren’t sold separately. Customers subscribe to the collection, rather than choosing individual subscriptions.

In this guide, we’ll explain how bundles and suites differ, how to get your apps ready for them, and how you should plan your new subscription offerings. Since Bundles and Suites are currently in early access, you’ll need to request access from Apple, something we cover at the end of this guide.

Bundles and suites at a glance

When should you use App Store bundles (+ types of Bundle)?

Use a bundle when you want to keep selling subscriptions individually while offering customers a combined deal. There are three configurations to consider:

• Single-app bundle: CatNavigator sells subscriptions for Norway, Sweden, and Finland individually, and combines all three in its Nordic bundle
• Multi-app bundle from one developer: TodoCat and CalendarCat each have a subscription, and their developer offers both together in a bundle
• Multi-developer bundle: TodoCat and CalendarDog come from different developers, who partner to sell their subscriptions together

A multi-developer bundle also creates a cross-promotion opportunity: customers who already value another developer’s app may discover yours through the combined offer. Bundling subscriptions from two different apps can also give customers a better deal than buying each app individually.

A bundle can contain up to five subscriptions, and a multi-developer bundle can involve up to five developers. Each included subscription must have the same duration, so you can’t combine monthly and annual products in one bundle. Customers must also be able to buy the included subscriptions individually.

Single-app bundle

The following configurations are illustrative. CatNavigator is a navigation app with separate subscriptions for Norway, Sweden, and Finland. A customer who only needs Norway can subscribe to that country. A customer traveling around the region can choose the Nordic bundle, which includes all three subscriptions at a lower combined price.

Everything is unlocked inside CatNavigator. You’re combining subscriptions within one app, so the bundle doesn’t require a second app or another developer. The individual country subscriptions remain available, and their durations must match within the bundle.

Multi-app bundle from one developer

Take a developer with two apps: TodoCat for tasks and CalendarCat for scheduling. Each app has its own subscription, but the developer now has the option to offer both in a bundle at a lower combined price. The bundle gives customers access to both services through one purchase while keeping the standalone subscriptions available. When canceling, customers can also decide to keep parts of the bundle.

Multi-developer bundle

Multi-app bundles can also combine apps from different developers, for example, a calendar app from one developer and a to-do app from another. The customer proposition stays similar: TodoCat and CalendarDog offer their monthly subscriptions together for less than the combined standalone price.

If the customer is already subscribed to TodoCat, joining the bundle upgrades their access and triggers a prorated refund for the unused standalone period. If they later decide they only want TodoCat, they can keep that subscription and leave the rest of the bundle at renewal.

When should you use App Store Suites?

Use a suite when you want to sell one subscription across a related set of your apps. Apple Creator Studio illustrates that use case by combining creative tools such as Final Cut Pro, Logic Pro, and Pixelmator Pro in one subscription. It’s a useful reference for the purchase experience:

A suite can cover up to 15 apps from the same developer. Apple’s explanation says the subscriptions included in a suite can’t be purchased individually. This makes suites more limited when it comes to offering both bundled and individual subscriptions. For most developers, bundles might therefore be the better option due to their flexibility with existing business models.

A suite example: PhotoCat, VideoCat, and SoundCat

Imagine one developer offering PhotoCat for photo editing, VideoCat for video editing, and SoundCat for audio editing. Customers buy the suite subscription and receive access across all three apps. The subscriptions included in that suite aren’t sold individually.

Get access to Bundles and Suites from Apple

Start with Apple’s request form in App Store Connect. Have the participating apps’ identifiers ready, along with the configuration you want to offer.

Check the technical requirements

Apple lists support for Bundle and Suite purchases on iOS 27, iPadOS 27, macOS 27, and tvOS 27 or later. Check that all participating apps meet the requirements before submitting the request.

Choose your configuration

After entering your contact details, confirm that you’ve implemented StoreKit 2 across the apps you plan to include. Select a single-developer bundle, a single-developer suite, or a multi-developer bundle.

For a single-developer bundle or suite, provide the App Apple IDs for the participating apps. These are the numeric app identifiers in App Store Connect you can find on each app’s submission page.

For a multi-developer bundle, the form also asks whether you’re the primary or secondary developer. The primary developer acts as the seller of record and Apple’s main contact. The secondary developers contribute subscriptions to the bundle. Include the App Apple IDs for your apps and your partners’ apps, so agree on the participating apps before anyone submits.

Apple’s public overview and WWDC26 session don’t explain how revenue is split between developers or how secondary developers receive payment. Confirm the revenue split and payment arrangements with Apple during onboarding before agreeing to a partnership.

Submit the request and complete onboarding

Each developer in a multi-developer bundle must submit their own request and sign Apple’s program addendum. One partner’s application isn’t enough. After approval, Apple gathers subscription details and works with the participants on pricing and the go-live date.

Get started with Bundles and Suites

Decide which services belong together, whether customers should be able to buy them separately, and which apps and developers will participate. For bundles, choose matching subscription durations and a combined price that gives customers a reason to buy the package.

Apple supports introductory and promotional offers on Bundles and Suites, so you can offer a discounted starting period or a promotion alongside your standard price. Our guides to introductory offers and promotional offers explain how these offer types work.

Already have access from Apple? If you’re using RevenueCat on a self-serve plan, contact RevenueCat support from your dashboard to discuss your configuration and next steps. You can also contact the RevenueCat team to discuss your requirements.

Watch on YouTube

Cycle tracking, the core use case, stays free. What Flo does instead is watch how each user's needs evolve and step in when it has something new to offer, whether that is trying to get pregnant, following a pregnancy, or understanding perimenopause. "When we see that there is something of value that we can bring to the user besides our core product offering, we do. And this is, you know, what lets us convert users from freemium" into paying, three, six, and 12 months later.

Mike is clear that this is a luxury, not universal advice. A younger app under pressure to pay back acquisition from day zero can't wait six months for its subscribers. But he also thinks the alternative has a ceiling. There are only so many ways to squeeze the lemon, he says, "and suddenly, you know, like there are not that many ways to keep squeezing that lemon." Flo would rather protect the relationship: "We don't feel the need to try and monetize the user like on day one and day seven, you know, because we know that, you know, one day something may change."

"Your paywall conversion is not your monetization strategy"

That line is Mike's, and David Barnard read it back to him on the show. The argument behind it: growth teams overestimate two things. "One of them is that short term conversion wins smoothly translates to business wins, which is not true." The other is that subscription conversion is a single event. "There are lots of things like starting a trial, activating a trial, you know, retaining the user and so forth. So it's a life cycle." An onboarding paywall is the beginning of that journey, and a test that lifts it can still lose money further down.

David's counterexample came from an earlier Sub Club guest, Anada Lakra of BoldVoice, whose team removed the X from its paywall, watched conversion jump, and then watched refunds spike until the win became a drain. Mike's answer is to keep analyzing experiments long after rollout, and to run one exercise at the end of every year. "Over the course of a year, you kind of ship tons of successful experiments, you know, with five, seven, 10% uplift, you know, and at the end of the year, you just, you know, do this exercise and check. Did your business grow by the same percentage that you've reported over the course of the year?" If it didn't, the difference is the share of wins that were never business wins.

The onboarding step that lost 10% twice and then won 23%

Mike's biggest win of the year started as a failure. Flo's web onboarding team added a step to work out which perimenopause phase a user was in. "It made so much sense to us at the very beginning. The hypothesis was strong," Mike says. "And the first test came back with almost 10% drop in conversion rate."

What happened next is the part he wants other teams to hear. Instead of looking for evidence, the team reached for an explanation. "Maybe something was, you know, something was wrong with the design. Let's just do it. One more run and nothing happened. You know, we got the same job and conversion rate." Only after the second loss did they dissect the audience, and the finding was blunt: the question was written in a way users couldn't answer, so "almost 75% of the users were not assigned any perimenopause phase." Those users, who had just clicked an ad promising to tell them their phase, got a screen that said sorry, we couldn't pinpoint it, carry on.

Flo rewrote the question with its medical team and changed the logic so that a user who still couldn't be placed moved quietly to the next section instead of hitting a dead end. "It was the third iteration based on the evidence, and it came back with 23% win." The team didn't trust it. A fourth, blackout test removed the new section entirely, and lost, which confirmed the uplift was real. Mike's summary: "All the iterations that were based on explanation loss, the one that was built on evidence One."

His rule for any failed test follows from that. "Explanation usually tells you what you want to be true," he says, whereas "the evidence tells you where to look." You iterate when you have new evidence, not a new explanation, because explanations are unlimited and chasing them is "this vicious cycle of, you know, experimenting."

Flo's marketing team found the need before product did

One of Flo's best onboarding branches began as an ad the product team hadn't planned for. The user acquisition team noticed that "a specific kind of narratives around enhancing your sex life, kind of started to gain traction at meta. And the numbers were pretty good, even with the existing funnel." Product took the signal apart and concluded there was a user need the onboarding had never explored. So they built for it: a dedicated branch that acknowledges which ad the user arrived from and asks a tailored set of questions so the narrative carries straight through. "It turned out to be a great revenue driver for us."

The mechanism matters more than the example. "Marketing team has a bad insight into things that resonate with your audience, and they can validate those insights much faster than you ever can do with your product funnel," Mike says (the transcript's "bad" is almost certainly "better"; check the audio). At Flo's scale, the marketing team can scan the market and test hypotheses in volumes a product funnel never could, so the practice is to share every change, weekly, whether or not it seems to matter: "you never know what insights will be valued by different teams." He doesn't claim the relationship is comfortable. "It's not like a happy marriage." It is, in his view, the only way to make the growth engine stronger than either team alone.

The Blinkist paywall didn't work at Flo, or anywhere Mike has tried it

Since joining Flo, Mike has been pitched silver bullets by product leaders at other companies. "We did this. We tracked 10% uplift in conversion rate. This is like your silver bullet. You got to do this. And we did exactly the same thing. Pixel to pixel, you know. And it just did not work." He has no tidy explanation. He does have a rule, which David restated as "borrow the idea, not the solution," and he thinks most product teams get it backwards: they "borrow the solution before understanding the problem."

The clearest case is the Blinkist-style paywall, the one that promises to remind you before your trial ends. It has worked for plenty of apps. "We did tested it at Luna, we did test it at the flower, and it did not work for both of the teams," Mike says, referring to Loóna, the sleep app where he was CPO, and to Flo. The trial toggle went the same way. His conclusion is not that the pattern is bad, but that a result from another product is not evidence it will work in yours: "You have to understand the underlying problem first."

In the full episode, Mike also explains why he thinks streaks have become a cargo cult, how Flo uses proxy events to make early calls on experiments when the real conversion is a delayed trial activation, and why putting partner mode, a feature with more than 2 million pairs using it, into the onboarding funnel was his biggest fail of the year.

Guest links

• Mike Charniatsou on LinkedIn
• Flo Health website
• Flo Health Careers

Paid acquisition says customer acquisition cost (CAC) is $42 when finance says it’s $67. Meta says one campaign is outperforming everything else, when the mobile measurement partner (MMP) is much less enthusiastic. Product is celebrating an 18% improvement in trial starts, but the revenue data suggests trial-to-paid is falling…

The meeting inevitably ends with someone opening a dashboard to clarify the numbers, only to find it sparks three new debates.

Everyone has data, and everyone can defend their number. Yet, no one can figure out what to do next. And this isn’t usually happening because a company has no data. It frequently happens when a company has lots of data, but no shared understanding of it.

This measurement dysfunction is one of the most underestimated barriers to app growth.

ATT broke the illusion of perfect attribution

If you were running mobile growth in 2021 and you’re still here, you’re already battle-tested. Apple’s App Tracking Transparency (ATT) framework became a reality with iOS 14.5 in April 2021, pushing the industry into a much more aggregated and privacy-preserving measurement world.

Lucas Moscon’s guide to SKAdNetwork (SKAN) describes the pre-ATT period as a time when user-level metrics made deterministic attribution much more accessible. Then came ATT, SKAN postbacks, conversion values, anonymity thresholds, shorter windows, and far less visibility at a user and creative level.

There was a fog around data: everyone was trying to work out what numbers they could still see (not many), what they could send back to the platforms (not much), and which parts of the old playbook still worked (again, not many).

But the industry adapted. We learned SKAN. We added more tracking. We got better at first-party data. Platforms built modeled attribution (hello, Meta’s Aggregated Event Measurement, or AEM). Teams got big into web funnels, incrementality tests, cohort analysis, marketing mix modeling (MMM) and more sophisticated internal business intelligence.

Five years later, the problem is almost the inverse of where we started: most subscription businesses now have more measurement than they did before ATT, but less alignment on what the numbers actually mean.

The numbers are going to disagree

Today, each team working on a subscription app has gotten better at measuring their own part of the journey, but the connections between those views have definitely not improved at the same speed.

UA teams look at platform models and MMPs; product has richer behavioral analytics; finance keep their own revenue view; and subscription teams get better cohort and renewal data. But this segregated measurement is how you end up with five sophisticated systems and a basic argument about whether CAC is $42 or $67.

That does not mean the post-ATT measurement stack failed. It means we have to stop expecting each layer to produce the same answer.

One example is Meta: for one of our recent clients, Meta is reporting less than a third of the conversions we see in App Store Connect across the same period. That’s a huge gap if you look at the two numbers and assume they are supposed to match.

We don’t panic about it. We don’t believe the campaigns suddenly became 3.5x worse. Most importantly, we don’t spend the week trying to make Meta and App Store Connect display the same conversion total. What we do do is understand the gap:

• Is it broadly stable?
• Does it widen or narrow when we change how spend is deployed?
• Does Meta still correctly identify the campaigns and creatives that are relatively stronger or weaker?
• What happens to the business-level numbers when we scale?

Once you know those answers, an under-reporting platform can still be very useful. It just cannot be treated as a complete representation of reality.

This is something David Vargas has talked about - his LinkedIn is basically a running catalog of what iOS measurement looks like in the real world. In one example, RevenueCat showed 90 free trials while Meta AEM reported 33. In another, the App Store produced a materially lower cost per trial than AEM.

The point is not that Meta is uniquely bad. It’s that discrepancy in your data is normal.

Identify your normal disagreement

The way we solve this at Aperture is by defining what ‘normal disagreement’ looks like. E.g. if Meta usually reports 35% fewer trials than your baseline, that’s your normal disagreement. Seeing 100 trials on your baseline tool and 65 on Meta isn’t concerning. But if that gap suddenly becomes 70% disagreement, then that is worth investigating. A stable mismatch is very different from a new mismatch.

This is the part a lot of measurement frameworks miss. Reliable data doesn’t mean identical numbers. It requires the team to understand why the numbers differ, roughly by how much, and what would count as an anomaly.

In short, the useful question is not “which dashboard is right?” It is: what decision am I trying to make with this number?

Build the measurement system around decisions

A lot of companies experiencing this kind of measurement pain respond by building another dashboard to bring all the numbers into one place. And sometimes — on rare occasions — that is useful.

But if the numbers are already inconsistent, then a new dashboard is only a means to display those inconsistent numbers together.

I would start somewhere less exciting: write down the decisions your team repeatedly needs to make, like:

• Should we increase channel spend next week?
• Which ad set gets the next $1,000?
• Did the paywall test improve the business?
• Is the US cohort genuinely better than the UK cohort?
• Can we afford to acquire a customer at $60?
• Is this channel adding customers or mostly taking credit for demand we already had?

Then, for each decision, decide four things:

1. The fastest useful signal: what can move quickly enough to help you act?
2. The downstream guardrail: what stops you from declaring a false win?
3. The business anchor: what blended outcome should ultimately move if the strategy is working?
4. The evidence threshold: how certain do you need to be given the size and reversibility of the decision?

Here’s what that looks like for four common decisions:

The same measurement stack should use different signals for different kinds of decisions. Only after sorting that would I worry about whether the company needs another reporting tool.

Match the evidence to the decision

Once you accept that no single metric can do every job, the next question becomes much easier: how much evidence does this decision actually require?

I’ve had versions of this debate for years. In a Singular Growth Masterminds conversation, John Koetsier and I talked about teams wanting to judge every product experiment on lifetime value. The intention is good, and LTV is important, but you cannot necessarily use lifetime value to judge a week-long experiment. You would never learn anything quickly enough.

We must also consider the stakes of each decision. Looking at our four common decisions above — each differs drastically. A $500 creative-allocation decision tomorrow does not require the same evidence as moving $3 million of annual spend between channels next week. For the first decision, platform data can be perfectly adequate, if you understand the usual reporting gap and you are watching the blended business outcome.

For a paywall or pricing change, I want a controlled experiment and downstream subscription guardrails. For a large channel reallocation, I want cohort quality, blended performance and, where possible, incrementality evidence. For financial planning, I care far more about realized financial data and explicit assumptions.

This is also why directional data is not dirty data. The obsession with perfect measurement can become another form of paralysis.

If Meta consistently finds one creative at half the reported cost per trial of everything else, I do not need to wait a year to put more budget behind it. But I do want to know whether the creative is bringing in a cohort that converts and retains sensibly, and whether blended economics remain healthy as spend increases.

The standard of evidence rises with the cost of being wrong.

How Opal kept it simple

A good example is Opal. On Sub Club, Opal’s CEO, Kenneth Schlenker, shared that the seven-person team had reached $5 million annual recurring revenue (ARR) (and they’ve since doubled that).

Opal invested in paid acquisition early, but rather than trying to build an enormous measurement framework, they focused on Day 8 return on ad spend (ROAS) as a practical growth signal. Kenneth described the approach as “just focusing on this one metric: Day 8 return on ad spend.”

That number wasn’t the final answer to every question about the business. But it was useful because it was available quickly enough to make decisions, and close enough to the economics they cared about.

Use blended metrics as your business reality

When the attribution gets noisy, I like to retrace my steps back to the boring numbers.

How much did you spend? How many customers did you acquire? How much revenue did those customers generate?

That blended view is your anchor.

If the business spent $200,000 during a period, and acquired 4,000 new paying customers, the blended acquisition cost is $50. There will still undoubtedly be debate about which channels caused those customers, which captured demand, or how organic growth contributed. But before you have that debate, you at least know the economic boundary the models have to fit inside.

• Platform data helps us make decisions inside the platform
• Attribution helps us understand where growth appears to be coming from
• Blended performance tells us whether the business as a whole is actually becoming more efficient

Blended reporting does not solve attribution. It doesn’t tell you whether Meta caused customer #4,382 to subscribe, but it does tell you what you put into the machine and what came out.

Perhaps even more importantly, it also gives you somewhere to sanity-check the stories your channels are telling you. E.g. if every ad platform claims more conversions than the business acquired in total, you know the channel reports cannot all be interpreted literally.

I often think of this as working from the outside in. Start with the size and economics of the whole pie, then use attribution and segmentation to work out how it’s being divided. If you start with the individual slices, you risk scaling a channel that looks brilliant in isolation, while the overall business barely moves.

Beware: blended truth still hides averages

There is a catch to everything I have just said about blended metrics: averages can hide important differences too.

Blended CAC is a fantastic anchor. But it is not a segmentation strategy.

Eric Crowley made this point years ago when discussing LTV: “The problem with this metric, and lots of other metrics, is that they are derived from an average.”

You’ve probably heard about ‘tourists’ and ‘locals’ — tourists may subscribe quickly, but also churn quickly. On the other hand, locals can become deeply engaged, long-lived customers. Put both groups into one average and you can end up with a number that represents neither.

The same problem appears everywhere in subscription growth. A blended trial-to-paid rate can hide one country converting brilliantly and another badly; overall LTV can hide radically different monthly and annual subscribers; and average CAC can hide an audience that is cheap to trial but expensive to pay.

Time creates another complication. RevenueCat Charts distinguishes realized LTV from predicted LTV: one reflects value already generated; the other estimates future value. A Day 30 realized cohort is observed but immature. A 12-month predicted LTV is more complete, but it’s an estimate rather than observed data. Both are useful: finance may care about contribution after fees and refunds, while growth may need an earlier gross-revenue signal to decide whether to scale tomorrow.

Across all metrics, it’s never as simple as “this is always the best one to use”. The hierarchy is not ‘blended good, segmented bad’. It’s more:

Use blended metrics to understand whether the business economics work. Then segment to understand why they work, where they are breaking, and which levers you should pull next.

What good measurement actually looks like

After all of this, you can see that good measurement is actually pretty unglamorous. And it’s never as clear as it seems.

A trial-conversion lift can look great until those users cancel more often. A channel can look efficient until you zoom out and realize the blended economics are moving in the wrong direction. None of that makes the original number useless. It just means no single metric gets to answer every question.

The goal is not to make every system agree. The goal is to know:

• What each number is useful for
• When to sense-check the number against the blended picture
• Which numbers help you operate day to day
• Which ones tell you whether the business is healthy
• Which decisions are important enough to require extra evidence

The measurement stack will keep changing. We made it through ATT, SKAN, disappearing user-level signals, and several years of being told attribution was dead. There will be another version of this problem.

But if everyone can look at the data and know what to do next, the measurement is doing its job.

In this article, you'll start from that recording and trace the cost of one package tap inward: the override model behind a server driven paywall, an instrumented test and a set of kill switches for measuring a tap, what derivedStateOf skips and what it doesn't, lazy condition inputs, a regex cache, fonts without equals, work moved into the draw phase, an invisible spinner, and the limits of reordering code inside one main thread task.

The fundamental problem: One selection, read by every component

A RevenueCat paywall is designed in the dashboard and arrives in the app as a tree of components: stacks, texts, images, packages, buttons. Any component can carry overrides, which are partial property sets applied when a condition holds. If you've used a <selector> drawable with state_selected, it's the same idea, applied to any property of any component. The condition can be "the package this component belongs to is selected", "the user is eligible for an intro offer", "the selected package, wherever it is, is the annual one", or a window size. A package card that gets a thicker, colored border when it's selected looks like this in the SDK's model:

PackageComponent(
    packageId = "\$rc_annual",
    isSelectedByDefault = true,
    stack = StackComponent(
        components = listOf(planName, planPrice),
        border = Border(color = gray, width = 1.0),
        overrides = listOf(
            ComponentOverride(
                conditions = listOf(ComponentOverride.Condition.Selected),
                properties = PartialStackComponent(border = Border(color = accent, width = 2.5)),
            ),
        ),
    ),
)

Resolving overrides means checking each override's conditions against the current state and merging the matching ones over the base style. The result is the set of properties the component draws with. Every component has a state holder that does this inside a derivedStateOf, so the resolution reruns only when something it read changes. The inputs it reads, such as whether this component's package is selected or which package is selected overall, are backed by Compose state, and a derived state records every state object it reads as a dependency. Before October 2026, StackComponentState resolved its overrides like this, and every other component state did the same:

private val presentedPartial by derivedStateOf {
    val windowCondition = ScreenCondition.from(windowSize)
    val componentState =
        if (packageAwareDelegate.isSelected) ComponentViewState.SELECTED else ComponentViewState.DEFAULT

    style.overrides.buildPresentedPartial(
        windowCondition,
        packageAwareDelegate.offerEligibility,
        componentState,
        conditionContext = ConditionContext(
            selectedPackageId = selectedPackageInfoProvider()?.rcPackage?.identifier,
            customVariables = customVariablesProvider(),
            stateReader = stateStoreProvider()::currentValueOrDefault,
            windowDpSize = windowDpSize,
        ),
    )
}

Notice the order: isSelected, offerEligibility, and the selected package's identifier are all read before buildPresentedPartial looks at a single condition. A component with no overrides at all still read the selection. There's a difference between "the selection changed" and "this component's inputs changed". Every tap is the first, and it should be the second only for components whose overrides mention the selection. The old code made it the second for every component.

If you've written a selectable list in Compose, you've probably written the same shape yourself:

val badgeStyle by remember {
    derivedStateOf {
        val isSelected = selection.selectedId == plan.id
        resolveBadgeStyle(plan.badgeRules, isSelected)
    }
}

For a plan whose badge rules never look at the selection, the read is wasted, and the derived state now depends on every tap anyway. In a list of five items that's harmless. The rest of this article is about what it costs when the list is a whole screen.

Measuring before guessing: The recording and an instrumented test

The first theory was the background: maybe every tap re-rendered and re-blurred the paywall behind the sheet. The recording made that unlikely. Sampled at 30 frames per second, each tap showed the ripple starting, then about a dozen identical frames, then the new selection in one frame. Across this and a second recording, the pauses lasted 0.33 to 0.50 seconds. The background didn't change on the frame where the selection flipped, and in the second recording, where it animated, the animation paused during every delay. When unrelated animations pause at the same moment, the main thread is the usual suspect.

A blocked main thread right after a state change points at composition, layout, or something they call. To find out which, we wrote an instrumented test that renders a paywall with the real SDK on an Android runtime, changes the selected package on the UI thread, and waits for Compose to go idle:

repeat(ITERATIONS) { i ->
    val target = if (i % 2 == 0) idA else idB
    val started = System.nanoTime()
    composeTestRule.runOnUiThread { state.update(target) }
    composeTestRule.waitForIdle()
    samples[i] = (System.nanoTime() - started) / 1_000_000.0
}

Each run does 6 warmup selections and 20 measured ones and reports the median, and every timing from this test below is the median of at least three such runs. The paywall is synthetic: N plain texts with no overrides, plus two packages, and no blur at all. The cost reproduced anyway, so it doesn't need the blur. Changing N answers the first question to ask about any slowdown: does the cost grow with the number of components, or is it a constant paid once per tap?

Two caveats apply to every timing in this article. The runs use an Android 15 emulator and a debug build, so the values are only meaningful as before and after comparisons on the same bench, and phones aren't necessarily faster: during the investigation, an earlier build on a different paywall took 190 ms per tap on a Galaxy S23 against 112 ms on an Android 14 emulator. And waitForIdle advances in whole frames, so the resolution is one frame (16.7 ms) and the floor is two frames, about 33 ms.

To see what each fix bought on its own, the fixes that touch the tap got kill switches: flags in a measurement build that restore the old behavior at one choke point. With every flag off, the build is the current SDK, so every "before" number in this article is the current SDK with a fix switched off, not an old release. Next to the switches sit counters for the work a tap causes: override resolutions, text recompositions, font file loads, and variable passes, which count how many times a text template was processed. Here's one tap on 300 texts, with #4383, the main fix this article explains, switched off and on:

• #4383 switched off: 700 ms per tap, with 308 override resolutions, 0 text recompositions, and 600 variable passes.
• Current SDK: 184 ms per tap, with 0 override resolutions, 0 text recompositions, and 600 variable passes.

The chart below repeats the measurement at 20, 100, and 300 texts:

The orange and blue lines climb with the number of texts, so this is work every component does on every tap, not a one off like a file read. And the counters show where it went: 308 override resolutions and 600 variable passes per tap, against zero text recompositions. Compose correctly skipped every text on the screen, because none of them looked any different. Almost all of the 700 ms went into recalculating values only to find out they hadn't changed.

Skipping in derivedStateOf: Recomposition, not recalculation

To see why skipping can be expensive, look at what the Compose runtime does when a state object read by a derived state changes. Composition puts every scope that read the derived state on a "maybe changed" list, and right before it would recompose one of them, it checks whether the derived value really changed. In the runtime that the SDK ships with (1.11.4) and the latest stable release (1.12.1), that check is checkDerivedStateChanged in RecomposeScopeImpl:

private fun DerivedState<*>.checkDerivedStateChanged(
    dependencies: MutableScatterMap<DerivedState<*>, Any?>
): Boolean {
    @Suppress("UNCHECKED_CAST")
    this as DerivedState<Any?>
    val policy = policy ?: structuralEqualityPolicy()
    return !policy.equivalent(currentRecord.currentValue, dependencies[this])
}

currentRecord is where the work happens: if any dependency changed since the last calculation, reading it runs the calculation again. So a single tap goes through these steps:

1. The selected package changes.
2. Every derived state that read it is now out of date.
3. Before recomposing each reader, Compose recalculates the derived state and compares the result with the value the reader last saw, using ==.
4. If the two are equal, the reader is skipped.

Step 4 is what derivedStateOf is known for, and it worked: nothing recomposed. Step 3 is the part that's easy to forget, and there's no shortcut around it, because the only way to learn that the new value equals the old one is to compute the new value.

One more detail multiplies the cost. A derivedStateOf without an explicit policy stores a new record every time it recalculates, even when the result is equal, so any derived state built on top of it sees a changed dependency and recalculates too. In TextComponentState, presentedPartial is private, and composition never reads it directly. It reads about a dozen properties derived from it, such as visible, text, color, fontSize, padding, and fontFamily, and each of those recalculated and was compared on every tap, for every text.

Reading less: Condition inputs as lambdas

The first half of #4383 doesn't make that chain cheaper. It removes the dependency for every component that can't be affected. The condition inputs became lambdas, and each condition calls only the one it needs. Looking at the evaluation after the change:

private fun ComponentOverride.Condition.evaluate(
    windowSize: ScreenCondition,
    offerEligibility: () -> OfferEligibility,
    state: () -> ComponentViewState,
    conditionContext: ConditionContext,
): Boolean = when (this) {
    ComponentOverride.Condition.Compact,
    ComponentOverride.Condition.Medium,
    ComponentOverride.Condition.Expanded,
    -> windowSize.applicableConditions.contains(this)
    ComponentOverride.Condition.IntroOffer -> offerEligibility().isIntroOffer
    ComponentOverride.Condition.Selected -> state() == ComponentViewState.SELECTED
    is ComponentOverride.Condition.SelectedPackage -> evaluate(conditionContext.selectedPackageId())
    // ...the other conditions follow the same pattern
}

The real when covers more condition types, and each branch follows the same rule: a lambda runs only inside the branch that needs its value. The call sites now pass state = { if (packageAwareDelegate.isSelected) SELECTED else DEFAULT } instead of the computed value.

Why does a lambda change the dependencies? Because a derived state learns its dependencies by watching what its calculation reads, not by looking at what it could read. Inside DerivedSnapshotState, the calculation runs under a read observer, a callback Compose invokes every time a state object is read inside the block. The real code also tracks how deeply derived states are nested, but the core of it is this:

Snapshot.observe(
    {
        if (it === this) error("A derived state calculation cannot read itself")
        if (it is StateObject) {
            newDependencies[it] = /* nesting level of this read */
        }
    },
    null,
    calculation,
)

Every state object read during calculation lands in newDependencies, and nothing else does. A lambda that is never invoked never reads the selection, so the selection never becomes a dependency. A component whose overrides don't mention the selection no longer resolves them on a tap, because nothing it read has changed.

This is the habit to take into your own code. Inside derivedStateOf, or any scope that tracks reads, such as a composable body, snapshotFlow, or a layout or draw block, read a state only on the path that uses it. Here resolveBadgeStyle takes a () -> Boolean and calls it only when a rule checks the selection:

val badgeStyle by remember {
    derivedStateOf {
        resolveBadgeStyle(plan.badgeRules, isSelected = { selection.selectedId == plan.id })
    }
}

The kill switch for this half sits at the top of buildPresentedPartial. Calling every lambda up front recreates the dependencies the old code had:

if (PerfKnobs.eagerConditionReads) {
    offerEligibility()
    state()
    conditionContext.selectedPackageId()
}

With only this half switched off, the 300 text paywall took 450 ms per tap against 184 ms. On one of RevenueCat's own paywall templates, an 89 component design with selected state overrides and price variables, override resolutions per tap dropped from 99 to 22. The ones that remain belong to components whose overrides really do depend on the selection, such as the plan cards.

The other half of #4383: 3,000 regex compilations per tap

The counters exposed a second cost. Text in a paywall is a template, where {{ product.price_per_period }} is replaced with the real price, and a variable outside a package refers to the selected package. So every text outside a package reads the selection and reprocesses its template on every tap, twice: once for the screen, and once for a spoken version that screen readers read, so that "$9.99/mo" becomes "$9.99 monthly". That's where the 600 variable passes for 300 texts come from.

The spoken pass expands period abbreviations with regular expressions. Compiling a Regex costs far more than running one, which is why patterns are normally built once. Before the fix, the spoken pass compiled them on every call:

val replacements = spokenPeriodKeys
    .mapNotNull { (writtenKey, spokenKey) ->
        val written = localizedVariableKeys[writtenKey]?.takeIf { it.isNotEmpty() }
        val spokenWord = localizedVariableKeys[spokenKey]?.takeIf { it.isNotEmpty() }
        if (written != null && spokenWord != null) written to spokenWord else null
    }
    .sortedByDescending { (written, _) -> written.length }
    .map { (written, spokenWord) ->
        Regex("/\\s*${Regex.escape(written)}(?!\\p{L})", RegexOption.IGNORE_CASE) to " $spokenWord"
    }

spokenPeriodKeys has ten entries, from "day" to "annual" in their short and long forms, and English defines all ten. So every spoken pass compiled ten patterns, and 300 texts compiled 3,000 Regex instances per tap. The second half of #4383 keeps the compiled list next to the word pairs it was built from and reuses it while the words stay the same, which in a paywall means the patterns are compiled once.

That makes each variable pass cheaper, not rarer, which is why the pass count above doesn't move. With only the cache switched off, a tap took 433 ms against 184 ms. The two halves of #4383 cost about the same, and they add up: with both switched off, the 300 text paywall took 700 ms. On the 89 component template, the same comparison was 100 ms against 50 ms.

When derivedStateOf can't tell two values apart: Fonts without equals

A recalculation that ends in "equal, skip" is the cheaper case. Now consider one that can never end in "equal".

Fonts uploaded in the dashboard are downloaded by the SDK and loaded from a file. FontSpec.Downloaded.resolve() builds a FontFamily out of new LocalFileFont instances on every call, and neither LocalFileFont nor its parent, Compose's AndroidFont, overrode equals. A class without equals is compared by identity, so two fonts pointing at the same file are still different objects, and because FontFamily compares its list of fonts, two families resolved from the same file were never equal.

The text's fontFamily is a derived state over the font spec, and the font spec is derived from the resolved overrides. Before #4383, those read the selection, so a tap reached the font too, two derived states downstream. Every recalculation built a new font object that Compose couldn't recognize as the same font, so every tap looked like a font change:

1. The new FontFamily isn't equal to the previous one, so checkDerivedStateChanged reports a change and the text recomposes.
2. The text is laid out again, and FontFamilyResolver, the part of Compose that turns a FontFamily into an Android Typeface, looks the family up in its cache.
3. The cache key is a data class that includes the family. A data class compares every field, so the key matches only if the families are equal, and they never were.
4. The per font cache below it is keyed by Font equality, so it misses too.
5. The font's loading strategy is Blocking, which means it must be loaded before the text can be drawn, on the thread that asks. The file is parsed again on the main thread.

The fix in #4245 gives LocalFileFont value based equality, with a matching hashCode over the same four fields:

override fun equals(other: Any?): Boolean {
    if (this === other) return true
    if (other !is LocalFileFont) return false
    return file == other.file &&
        weight == other.weight &&
        style == other.style &&
        fileTypefaceLoader == other.fileTypefaceLoader
}

On a 300 text paywall with a downloaded font, a build with both #4245 and #4383 switched off took 833 ms per tap, with 300 text recompositions and 300 font file loads. With only #4245 restored, it took 667 ms, with zero recompositions and zero loads.

The font fix shipped while we were still investigating the bug report, and the reporter saw no visible difference with that release. The defect was real and so was its cost, but proving that a defect exists is not the same as proving it caused the symptom you're chasing. In our measurements, the two costs that #4383 later removed were larger.

The two fixes also interact. With #4383 in place, a plain text's font no longer recalculates on a tap, so switching the equals off today changes nothing for selection: 193 ms with it and 184 ms without, within one frame. It still matters anywhere the font does recalculate, for example a text inside a plan card whose overrides read the selection. A value that lives in snapshot state needs a real equals whether or not today's code path happens to exercise it.

To see all three costs on screen, the demo below renders a synthetic paywall with 148 texts and a downloaded font through the real SDK, on the same emulator and debug build, and taps the plans with adb shell input tap. The overlay at the top reports each tap's cost, with override resolutions shortened to "override calcs", and its spinner is driven by Compose's frame clock on the main thread, so it stops whenever the main thread is busy. On the left, #4245 and #4383 are switched off, and after the first tap, which is slower in both runs, a tap takes about 360 ms. On the right is the current SDK, at about 75 ms. The variable passes barely change between the two (296 and 288), because 144 of the 148 texts sit outside a package and still read the selected package. The overlay counts everything a real tap triggers, including checks the click handler runs before the selection changes, so its numbers aren't directly comparable with the instrumented test:

Smaller audit fixes: Work repeated more often than its inputs changed

A Compose audit of the paywall renderer, done a week before the recording arrived, found three more places where work ran more often than its inputs changed. None of them was measured against tap latency:

• Markdown parsing (#4194): the CommonMark parse in Markdown, the leaf renderer for every text, is now wrapped in remember(text) instead of running on every recomposition. Countdown texts recompose every second, and before #4245 so did every text with a downloaded font on every tap.
• Shadows (#4195): the outlines, paths, Paint, and BlurMaskFilter that drawBehind built on every draw are now built in drawWithCache, so each draw only clips and paints.
• Window size class (#4200): each component called currentWindowAdaptiveInfo(), which collects the window layout flow, only to read the width size class. A helper now derives it from the window size and density.

For the first two, all 279 Paparazzi screenshots were byte for byte identical before and after, which shows that nothing visible changed, not that anything got faster.

Animation in the draw phase: Dimming a button

The package tap isn't the only tap on a paywall, and the buttons had their own per frame cost. When a button's action is in progress, its content fades out and a progress indicator fades in. ButtonComponentView animated the content alpha with animateFloatAsState and passed the Float down to StackComponentView, so the whole button stack recomposed on every frame of the fade. #4201 hands the stack a provider instead, and the stack reads it inside the lambda form of graphicsLayer:

private fun Modifier.contentAlpha(provider: (() -> Float)?): Modifier =
    applyIfNotNull(provider) { alpha ->
        graphicsLayer {
            this.alpha = alpha()
            clip = true
        }
    }

Compose runs that lambda when it updates the layer's properties, so a new alpha value changes the layer without recomposing the stack or laying it out again. The provider is null while the button is fully opaque, which keeps the common case free of an extra layer, just like Modifier.alpha with a value of 1.

The shipped code still recomposes the button itself. It decides whether to pass a provider by reading the animated value in the composable body:

val contentAlphaProvider: (() -> Float)? = if (animatedContentAlpha.value == 1f) {
    null
} else {
    remember(animatedContentAlpha) { { animatedContentAlpha.value } }
}

Reading .value in the body subscribes the button to every frame of the animation, even though == 1f only flips twice. The stack skips, because it receives the same remembered lambda each time, but the button doesn't. The demo below isolates this read in a small standalone app built in release mode with Compose BOM 2026.09.00, and counts how many times the button's scope and the stack's scope run during one press. The third variant moves the check into derivedStateOf { animatedContentAlpha.value != 1f }:

Each counter includes the first composition, so one press cost the Float version about 60 recompositions of both scopes, the shipped provider about 60 of the button and 2 of the stack, and the derivedStateOf version 4 and 2. The real ButtonComponentView also reads the progress indicator's alpha in the body, so that read would have to move out of composition too.

Frames nobody asked for: An invisible spinner

A second report described a paywall that stopped updating after a package tap, this time in a Flutter app on an Android 10 phone (purchases-flutter#1954). The reporter also noticed that the paywall redrew continuously while nobody touched it: 307 frames in five seconds, according to dumpsys gfxinfo. Testing one component type at a time, the RevenueCat engineer on the issue found that only buttons did this.

The cause was the button's progress indicator. It was always composed, with its alpha animated to zero while idle:

CircularProgressIndicator(
    modifier = Modifier.alpha(animatedProgressAlpha),
    color = progressColorFor(style.stackComponentStyle.background),
)

An indeterminate CircularProgressIndicator runs an infinite animation, and alpha 0 doesn't pause it. Each animation frame invalidates the indicator's drawing, and each invalidation makes the window render a new frame, so an invisible spinner kept the whole paywall rendering at the display's refresh rate. In the Flutter app, the native paywall renders into a small queue of buffers that Flutter reads from. After the tap, the log shows that queue falling behind, then Skipped 36 frames!, and then the surface disconnecting, after which Flutter kept showing its last frame. The reporter suspected the constant stream of idle frames. Whether removing it alone fixed that phone wasn't confirmed, but the stream itself was real. #4442 composes the indicator only while it's visible:

// The indeterminate indicator animates forever, so composing it at alpha 0 redraws the paywall
// every frame while idle.
if (animatedProgressAlpha > 0f) {
    CircularProgressIndicator(
        modifier = Modifier.alpha(animatedProgressAlpha),
        color = progressColorFor(style.stackComponentStyle.background),
    )
}

On our emulator, an untouched paywall with the old behavior switched back on rendered 302 to 303 frames in five seconds across three runs. With the fix, it rendered 0. In the demo below, the "Profile HWUI rendering" developer option draws one bar per rendered frame. Ignore the bar heights, because frames on an emulator are slow to swap. What matters is that new bars keep arriving on the left. On the right, the tall strip at the right edge is left over from the first frames after launch, and nothing new arrives:

If you hide an animated component with alpha, check whether its animation is infinite. Alpha controls what the user sees, not whether frames are produced.

What reordering can and cannot do: The interaction listener

When a package is tapped, the SDK calls the app's PaywallListener.onInteraction synchronously, and it used to do so before applying the selection, so a slow listener delayed the selection. #4298 applies the selection first, which looks like it should keep the listener from delaying the frame. It doesn't, because the main thread runs one queued task at a time: the click handler, with both the selection write and the listener call inside it, is one task, and the next frame can't start until it returns. Measured from the start of the click handler to the frame that draws the new selection, on the 89 component template, with a listener that blocks for 300 ms, in two runs of ten taps:

• Listener first (before #4298): 350 to 356 ms.
• Selection first (#4298): 342 to 343 ms.
• Listener posted to the main thread: 348 to 369 ms.
• Listener deferred until after the next frame: 41 to 48 ms.

Applying the selection first saved about 10 ms, less than a frame, and posting doesn't help, because the posted task still runs before the next frame. Deferring the listener past the frame takes its cost out of the tap, though the 300 ms block then delays the frames that follow. Deferring also changes when apps receive the callback, so it's an API decision rather than a refactor. For now, keep onInteraction short and move anything slow off the main thread.

Conclusion

The habit this investigation leaves you with is a question to ask about any state that many composables observe: who reads it, and do they all need to? derivedStateOf protects you from recomposition, not from recalculation, and a calculation that reads more than it uses subscribes to more than it needs. When you fix something like this, keep a way to turn the fix back off in a measurement build, because "it fixed a defect" and "it was the cause" are different claims, and only an A/B can tell them apart.

The symptom was a short pause after a tap, and the first theories were about expensive drawing. On every paywall we measured, the real cost was invisible to tools that look at what changed on screen, because nothing changed. Composition did what it promised and skipped the components that looked the same. What made the tap slow was hundreds of components each asking, correctly, whether they needed to do anything.

On paper we fulfilled user requests, and adoption was growing rapidly. But there was a deeper issue that none of our eval or metrics could capture.

An inflection point: “it’s not even fair”

A pattern of issues started trickling in via user reports and internal feedback. On paper, the agent would accomplish the task the user asked, like creating the paywall, adding or overhauling a section of it. But the result it produced lacked the level of taste and quality that you’d expect a frontier agent to be capable of.

We worked to address this issue in several ways:

• We tried different models from various providers, with higher effort and reasoning levels
• We tweaked the system prompt and skills
• We injected messages with screenshots of the paywall, pushing the agent to check its work and maintain a high bar for quality

There were notable improvements, but the gap between what users wanted, and what the AI delivered, remained massive.

We then got some feedback from Ryan, one of our Product Managers:

(left) our old paywall editor, (right) using Fable in Claude Code(FYI: Astra is our internal term for the paywall agent)

This was a brutal inflection point. The feedback was originally about our agent getting the app’s name wrong. But the bigger issue was blatantly obvious.

How does our agent not understand that the paywall it produced is atrocious? Spacing, alignment, card within a card… there were too many issues to name. How did it think this was acceptable?

And how can Claude Code just one shot something that looks great while our agent flounders? This thought haunted me. No one would use our paywall editor if you could get that much better results with a simple Claude Code prompt.

So where did we go from here?

The old agent technically worked

To understand why our old agent was struggling, you first have to see how it worked.

Beginning with the data shape. Some remote paywall products use HTML, CSS and JS to render on all platforms. This provides the most flexibility, at the cost of feeling native, appearance, and performance.

We opted for native (well, a bit of both now). Our paywalls are stored as JSON trees: each node is a component with its own attributes. When your paywall is rendered, the component tree is mapped into the native components.

Here’s what a purchase button component can look like in our structure:

{
  "type": "purchase_button",
  "stack": {
    "type": "stack",
    "background": { "type": "color", "value": { "light": { "type": "hex", "value": "#ff8a00ff" } } },
    "shape": { "type": "pill", "corners": null },
    "padding": { "top": 12, "bottom": 12, "leading": 8, "trailing": 8 },
    "components": [
      {
        "type": "text",
        "text_lid": "PBcCWPIKbT",
        "color": { "light": { "type": "hex", "value": "#ffffffff" } },
        "font_weight": "semibold",
        "margin": { "top": 0, "bottom": 0, "leading": 0, "trailing": 0 }
      }
    ]
  }
}
// ... one of 20+ components on this screen

Our agent had a very custom harness (set of tools, prompts and loop around the model). It understood the shape through an annotated JSON schema, and would operate on the paywall JSON directly, manipulating it with a set of tools.

This was a reasonable design for the first iteration.

• The targeted JSON operations prevented it from making simple formatting mistakes we’d had in earlier prototypes
• The schema showed it what was valid
• Skills gave it reusable patterns and guidance

But we were asking a lot of the model: it needed to learn this new schema on the fly for representing UI, along with the new tools. It needed to translate the user request into visual intent, then translate that visual intent into a series of tool operations on the JSON. And lastly, it needed to self-evaluate using a screenshot.

It was a bespoke workflow and syntax — a far cry from the Jetpack Compose, JSX and SwiftUI use cases it had been extensively trained on.

But the feature shipped.

The format is cooked

Still, I couldn’t shake the feeling that we were not just “one more prompt” away from closing this gap. Something was fundamentally wrong.

I read through Claude Code’s system prompt; there’s very little in there telling Claude how to make tasteful design, and certainly nothing specific to paywalls. Yet it achieved far better results even with models the harness wasn’t built for, like GPT.

Anthropic has a frontend design skill but, in my experience, the newer models still create great UI without it.

This led me to suspect the taste was being lost in translation. In a minimal harness, the models could express taste into code. But not into JSON patching tool calls…

What if our paywall could just be code? The model knows how to build a great UI in JSX. And JSX components are a tree very similar to ours: each node has JSON attributes and an optional set of children.

So we tried it. Here’s that same purchase button from earlier, as JSX:

<PurchaseButton>
  <Stack background="#ff8a00ff" padding={{ vertical: 12, horizontal: 8 }}>
    <Text text="Continue" fontWeight="semibold" color="#ffffff" />
  </Stack>
</PurchaseButton>

It turned out to be fairly simple. A transpile step turns the JSON into this intermediate JSX, which the agent can edit as a file. Once it’s done editing, a strict compiler runs, flagging any issues that could prevent the paywall from displaying or functioning correctly. When there are no blocking issues, the compiler turns the JSX back into the same JSON structure our backend & SDKs expect.

Two days after rock bottom, the new prototype set a record on our blank paywalls eval dataset. That’s when we knew we were onto something.

Yet another coding agent

If the theory is that leaning into coding agent RL will outperform learning a new harness on the fly, why not lean in fully. Let’s give the agent a full workspace, simple mechanisms to read, and additional context as needed.

So we did just that. We gave it a folder of snippets to see examples of how to do certain component structures, which it can copy-paste as needed. It doesn’t need the full documentation for every component on every request, so I split it into multiple d.ts files that can be lazily loaded, instead of cramming 175KB of JSON schema at the start of every session. This meant paywall translations just became entries in a strings/ folder. The agent can keep context about the app, like what the app does and who it is for, in a context.md.

And most importantly, this gave us room to expand. New capabilities can be represented with files/folders, and since things are lazily loaded in, there is minimal additional cost/overhead to do so.

/workspace
├── context.md
├── paywall.tsx
├── snippets/  (read-only)
│   ├── ctas/purchase_button.tsx
│   ├── feature_lists/checklist.tsx
│   └── ... (28 snippets)
├── strings/
│   ├── es_ES.json  (14 strings)
│   └── fr_FR.json  (14 strings, 2 stale)
└── types/  (read-only)
    ├── _readme.d.ts
    ├── base.d.ts
    ├── components/layout.d.ts
    ├── components/...d.ts
    └── overrides.d.ts

We didn’t need to reinvent our own tools to work with this format. We used what the model already knows: a free loop with Read, Write, Edit and a compiler. The compiler even feels like tsc: giving line numbers and diagnostics with guidance when there are issues in the paywall code, and handing back a screenshot of the paywall when it succeeds.

With a familiar format and harness, We were also able to remove over half of our system prompt and almost all of our skills. Most of those skills and prompts were compensating for a subpar format. As we continue to iterate, we focus on improving format first, then only prompt our way out if we must.

Works on my machine

The prototype broke eval records in two days. Getting that to production was a full team effort that took several weeks.

First, we had to build our confidence that this was production ready.

Our existing offline evaluations were a good start. Your users always use the agent in unexpected ways though, so we sampled hundreds of production traces and ran them against the new agent and created a dataset of new vs. old results. Our LLM judge mechanism was able to catch functional regressions: comparing the behavior, responses and results of the new vs. old agent, and ensuring the new agent was equal or superior in all cases. We also recruited many internal humans-as-judge to blind vote which version had better taste.

Only then did we started rolling out to external users — first, those who had given us feedback about taste and capability gaps.

Once we felt confident that this agent would be a definite step up in our production quality across the board, we had some infrastructure gaps to close.

The new agent was working hard. Between the large amount of turns it was using and the compilation work, we had to allocate additional CPU and memory. We also switched to Claude models: both Claude and GPT models perform well in the new harness, but Claude models currently have an edge in taste. Our new inference provider had different failure modes: stalled streams, empty responses, and increased downtime. So we hardened our retry and fallback mechanisms around the LLM calls.

After pushing through, we finished rolling out the new editor to 100% of users on September 2nd.

Fair enough

So, did it work?

Survey says: compared to the two weeks prior to rollout, across approximately 46K requests, our rate of positive feedback grew by 83% and negative feedback fell 40%.

We saw little difference with the new agent in our simpler requests like changing copy, adding a simple button, checking app store compliance, and automatic translations. But the gains show up in large paywall edits, new paywall creation, and anything that requires taste.

Going back to Ryan’s paywall tells the story.

If you’re building your own agent

1. Lean into the model’s strengths: models have been trained extensively with certain tasks, environments and tools. Lean into that. A great example of where this is starting to show up is code mode with MCP tools; letting the model write code to string together data from several tool calls, then compose and manipulate it.
2. Needing lots of brittle system prompts and skill changes is a smell: when we got the format right, we cut the system prompt in half. We stopped fighting with tuning verbiage changes in a prompt to get the desired result. And as we continue to optimize and add features, we’re looking at making the interface intuitive first, so we don't stack more debt in this category.
3. If applicable, measure taste, not just completion: the problem flew under the radar as we didn’t have any automated, clearly-correlated measures for this. We still don’t have a great one. What’s helped is blind voting by humans between two different options, in addition to listening to user feedback.
4. Take big swings: if your agent has decent evaluation mechanisms, the cost of prototyping and measuring big agent changes is relatively cheap. Try it, test it and see if there’s a better way. The payoff can be massive.
5. Latency may be accepted for quality: the new agent takes more turns, reading in context, editing, compiling and iterating. This has significantly increased our latency. At first we anticipated users would be unhappy with this, but from the data it appears the quality of results is a far more important factor. (Of course, this can vary based on your type of application and users.)

It shows subscribers a short message from your app right before they confirm their cancellation.

When someone taps ‘Cancel Subscription’, they’re one step away from leaving. This is your chance to give them one good reason to stay.

Here’s how to choose what to say, decide whether to add an offer, set up your first message in App Store Connect, and measure the results. We’ll also cover when it’s worth using RevenueCat’s real-time Retention Messaging instead.

How does Apple Retention Messaging work in App Store Connect?

Retention Messaging appears when a subscriber starts canceling through Apple’s subscription settings. Before confirming, they see a message from your app reminding them of its value. If you set it up in App Store Connect, that’s the message you’ve assigned to their subscription.

A retention message can show text only, text with an image, or text with an offer:

The setup happens on your app’s Subscriptions page in App Store Connect. Write the message, add a translation for each language, and assign it to the subscriptions it should cover.

Each subscription can have only one message, so every subscriber who cancels that plan sees the same text. Any offer you attach goes only to subscribers who meet your eligibility rules, while the rest see the same message without the offer.

App Store Connect vs the Retention Messaging API

There are two main ways to set up retention messages: in App Store Connect, or through Apple’s Retention Messaging API.

App Store Connect is the quickest way to start. It needs no code or access request, but it comes with limitations, like one message per subscription and offers only for subscribers who’ve paid for at least a month. Using the Retention Messaging API removes those limits. Apple checks with your server every time a subscriber starts to cancel, so you can pick a different message and offer for each subscriber and run

RevenueCat handles the server side for you, so you can set up messages, targeting rules, and experiments in the dashboard.

Here’s how the two options compare:

Step 1: Start with one good reason to stay

Before writing your message, ask yourself: why do subscribers choose your app, and what makes them leave?

You probably have more clues than you think. App Store reviews, support conversations, and Customer Center cancellation surveys show what subscribers value and where they get stuck. You can also use RevenueCat Charts to check when subscribers cancel (e.g., during a free trial or at their first renewal).

In App Store Connect, everyone who cancels a subscription sees the same message text. You can only limit who gets the offer attached to it. So pick a reason to stay that fits most subscribers on that plan, without misleading the rest.

For example, Character.AI highlights the one thing subscribers lose if they cancel: daily premium chats. It also lists what comes back — full ads, slow mode, and basic memory.

With the Retention Messaging API, you can show different messages to different groups, like trial users, long-time subscribers, or subscribers who have already redeemed an offer.

RevenueCat handles the API for you, so you can set up these rules in the dashboard without building your own server.

Step 2: Decide whether to add an offer

Next, decide whether to include an offer in your message. Discounts can help when price is the reason someone leaves. That said, it’s not always the case.

In our data from Google Play cancellation surveys, ‘not enough usage’ was the top reason subscribers canceled (37%), just ahead of cost (35%). As Daphne Tideman puts it: “If someone isn’t using the app, why would they care what it costs?”

Our analysis of 22 million Apple retention messages across 309 apps also found that subscribers accepted only about 1.1% of the discount offers and 0.6% of the plan switches they were shown.

The revenue impact is another factor to consider.

In a recent experience by the audio stories app Dipsea, annual subscribers who tried to cancel saw either a message with no offer or the same message with 50% off.

The discount had a slightly higher save rate (22.1% vs 18.8%) but brought in less than half the revenue per subscriber so far ($1.24 vs $3.16).

Before deciding whether to offer a discount, try to answer the following:

• Is price a common complaint? Check reviews, support tickets, and cancellation surveys.
• Who should get it? In App Store Connect, you can set a minimum paid subscription duration to exclude brand-new subscribers, and choose which countries the offer is available in. Free trial users can’t currently get offers there at all, since the minimum is one month of paid subscription.
• How often should the same subscriber get an offer? You can set a wait time between offers, starting at two months, so nobody gets a discount every time they try to cancel.
• Is it working? Use RevenueCat Experiments to see what performs best for your audience. For example, you can show a message with no offer to one group and a message with a discount to another, then compare save rate and revenue. It requires Apple’s approval for real-time messages.

Step 3: Write your message

The retention message subscribers see in Apple’s cancellation flow has a header and a short body. Use them to remind subscribers what their subscription includes, such as specific features, content, or perks.

If you’re approved for real-time messages, RevenueCat also lets you show different messages to different groups. Think of creating personalized messages for trial users and long-time subscribers, highlighting what matters most to each segment.

Three angles for a hypothetical meditation app:

• Highlight what they’d lose: ‘Keep your bedtime routine. If you cancel, you’ll move to the free plan and lose sleep stories and most of the session library.’
• Address why they’re canceling: ‘Short on time? Premium includes five-minute sessions for your busiest days, so you can keep your practice going.’
• Tease what’s coming: ‘A new sleep series drops every Monday. Stay Premium to hear each one as it’s released.’

Whichever angle you choose, the strongest messages pair a functional point with an emotional one.

The functional part names what subscribers would give up: sleep stories, five-minute sessions, offline downloads. The emotional part says why it matters: a calmer bedtime, a few quiet minutes in a busy day.

Step 4: Add an image (optional)

You can also add an image of the premium content or features subscribers would lose, like sleep story artwork or a guided session screen for our meditation app.

This helps the message stand out on the cancellation screen and shows subscribers what they’d give up at a glance.

It’s optional, and it only appears when there’s no offer, or the subscriber isn’t eligible for it. When they are, Apple shows the offer in its place.

A few tips for getting it right:

• Match the message: Add a relevant visual that fits your header and body
• Use original screens or content: Subscribers will recognize screenshots or artwork from your app more easily than generic stock photos
• Keep it clean: Avoid long text or a cluttered layout
• Use the right dimensions: Apple accepts 3840 × 2160 or 5244 × 2950 pixels

Step 5: Set up your message in App Store Connect

On your app’s Subscriptions page in App Store Connect, select ‘Get Started’ on the Retention Messaging banner, then write the header and body. Everyone on the subscriptions you assign sees this text.

To add more languages, use the language menu next to Message Text. There’s no copy or auto-translate option, so you enter each one by hand.

In the same step, you can add an image from your asset library or upload a new one at 3840 × 2160 or 5244 × 2950 pixels.

To attach a retention offer, create it within the same flow.

First, choose how subscribers pay: a discounted price each billing period (pay as you go), one discounted payment for the whole offer (pay up front), or nothing for a set time (free).

Then set how long the offer lasts and its price. You set the price once, and Apple converts it for all 175 countries or regions. You can still adjust it for specific countries.

From here, choose the countries or regions where the offer is available. You can select all of them.

Next, set eligibility so the discount applies only to certain subscribers and excludes others, such as free trial users and subscribers who recently redeemed an offer.

There are two settings:

• Minimum paid subscription duration (required): how long someone must have paid before they qualify, starting at one month. This means free trial users currently can’t get the offer.
• Wait between offers (optional): how long after an offer ends before the same subscriber can redeem it again, starting at two months.

Then, assign the message to your subscriptions.

You can use one message for all of them, or create separate ones (up to 10 per app) if you want different copy for each plan, like weekly, monthly, and annual. Each subscription can only have one message.

Finally, check the preview and submit the message for Apple’s review, and test the cancellation flow in sandbox.

Make sure each subscription shows the right message, the copy and image display properly in every language, and the offer terms and eligibility show up as intended.

For Apple’s own instructions, see Configure retention messages in App Store Connect.

Step 6: Measure whether it works

Once your message is live, start tracking how subscribers respond on the cancellation screen and how it impacts revenue over the following weeks.

Apple’s reporting shows what subscribers chose on the cancellation screen. With the real-time integration, RevenueCat’s retention messaging charts and Experiments also track whether saved subscribers keep paying.

Focus on these key metrics:

• Save rate: The share of subscribers who didn’t cancel within 24 hours or accepted the offer
• Offer acceptance: The share of subscribers who accepted the offer
• Active and set to renew: The share still subscribed with auto-renew on, which shows whether saves last
• Churn: The share who canceled after all
• Realized LTV per customer: The revenue each subscriber has actually brought in so far

The bottom line is: a higher save rate doesn’t always mean a better message.

That’s what happened in the Dipsea experiment. The discount had a slightly higher save rate, but fewer of those subscribers stayed set to renew, and each brought in less revenue than with no offer.

Go further with RevenueCat’s real-time Retention Messaging

A retention message works best when it’s relevant to the subscriber seeing it. That means highlighting the right reason to stay, tailoring the message to each group of subscribers, and offering a discount only when it can truly change someone’s mind.

RevenueCat’s Retention Messaging connects to Apple’s cancellation flow in real time, so you can:

• Target messages and offers: Choose which message, plan, or offer each subscriber sees in Apple’s cancellation flow, based on trial status, purchase stage, and offer history
• Manage messages across languages: Auto-translate your copy, edit all locales in one screen, and copy existing messages to make setting up more products and audiences easier
• Test and measure: Compare messages and offers with RevenueCat Experiments, then see what happened after each cancellation, from saves to renewals and revenue
• Skip the infrastructure work: RevenueCat manages the real-time connection with Apple

To get started, you’ll need Apple’s approval for real-time messages. If you’ve already set up a message in App Store Connect, you can build on that with RevenueCat. The two work together, so you can add targeting and experiments when you’re ready. Our setup guide walks through each step.

Watch on YouTube

40,000 preorders, and a Google Vision bill of $20,000 a week

The first version of Touch Grass checked your photo with Google's cloud vision API, because the plan was modest. "I was expecting maybe, you know, a couple hundred people to download it in the first couple of weeks," Rhys says. He posted the polished version to Hacker News and Reddit one morning, went for lunch, and came back convinced his analytics were broken: "I was just like, what, 6000 people are on this stupid website that I built."

He put the app up for preorder the same day, and he thinks that's a big part of why it kept spreading. People could press a button without hitting a price, "because as soon as you kind of hit a paywall, no one will ever want to share it again." Around 40,000 of them ended up with the App Store notification that the app was live.

Then he did the arithmetic on Google Vision at that scale. "It would have cost something like $20,000 a week to run on the Google Vision API. And I was just like, oh my days." The fix was the kind you can only do once: "I did not sleep for three days while I rewrote the entire, like, vision detection thing to native on device." It shipped before launch, just about, as Charlie says. Launch day itself was a party with family and friends and, in Rhys's words, "something stupid, like 50,000 unique active people on the app."

The lesson is the one every viral-app founder learns in the wrong order: a per-call cloud API is a fine prototype decision and a dangerous launch decision, because the bill scales with the hook.

The website is one screen recording, and the tweet got 1.5 million impressions

The marketing for Touch Grass was unusually small. The website hasn't changed since launch day: "It's just a screen recording and then some text saying like reduce your screen time something, download Touch Grass and that's all the website is." The first post was "a very, very, very early prototype of the sort of mechanism no like UI polish or anything," which hit the top of r/SideProject in November; Rhys spent two or three months polishing it and posted again.

He has one timing tip for European developers: post in the morning. If it does well in Europe, it's the first thing the US East Coast sees when it wakes up, and then the West Coast after that. Charlie admits to setting 3 a.m. alarms for the same reason back when Product Hunt ran on a daily cycle.

Then a friend told him to tweet it. The tweet was a single sentence, "I built an app to stop me doing scrolling by touching grass. That's it.", over a screen recording, and it ended up with around 1.5 million impressions, reporters in the replies, and interview requests from TechCrunch and Fast Company. All of this while the app was still in preorder.

Charlie's observation is what makes the story useful rather than just lucky. Most viral stories hinge on one famous account picking something up. This one "landed and performed excellent on multiple separate platforms at the same time," which points at the hook rather than the channel. Rhys agrees, and says it's deliberate: "The way I start marketing is I will distill the app into one sentence," which he then says to people in real life and watches their faces before he builds. For Touch Grass, they chuckled.

Tinder's lawyers objected to one word in Tender's App Store listing

Rhys's next app after Touch Grass was Tender, a Tinder parody in which every profile is his wife and you can only swipe right. She loved it. Tinder didn't. "They sent me a scary letter saying cease and desist. But it wasn't for the name. It wasn't for the gesture. It was for the word swipe in the App Store listing." Tinder, it turns out, has trademarked "swipe." Rhys's reaction: "okay, this is scary." The listing was changed and the app is still in the store.

The twist is what happened next. TikTok didn't care much about the app, but "TikTok actually resonated with the story of Tinder sending me a cease and desist," and the legal letter became the marketing moment. Rhys shrugs at this as the natural order of things: "I do everything with the story in mind sort of thing." Charlie's version is the old line about never wasting a crisis, with a sensible caveat about being careful where lawyers are involved.

Touch Grass was the easiest app in the world to delete

The 50,000-user launch hid a flaw that took Rhys a while to see. "It is an app that is so easy to uninstall. Like if you want to get on Instagram, the first thing you're going to do is uninstall touch grass like if it's raining outside or something like that." You couldn't just switch it off, "which might have been a product oversight by me at the time." Charlie names it for him: a churn problem. He adds a detail that makes it worse. iOS now asks, at the moment you delete an app, whether you'd like to cancel the subscription too, and almost everyone says yes.

So the rebuild is about staying rather than spiking. Rhys is gamifying the whole thing, with eight-bit UI, rewards for hours spent off your phone, and critters that visit a meadow, plus "guides" modeled on the dogs he and his wife dog-sit, with a paid feature planned where your own pet becomes your guide. He's candid about the shape of the growth chart: "Touch grass graph is like this mega mega viral spike and then a very, very long tail." He's never run a paid ad for it, and he's not trying to recreate the spike. "I'm just trying to rebuild slowly and not necessarily chase the viral moment again and just work on the retention side of things."

Charlie's advice on copycats: assume nobody is copying you

Rhys isn't sure he'd post an unpolished prototype today, because people can copy you faster now. Charlie pushes back, hard. Even if a thousand clones appeared the day after a viral post, the preorder page meant the traffic had somewhere to land; without it, "there would have been 30 apps called Touch Grass" and the clones would have collected the downloads. Copying, he says, "is a tale as old as the App Store," and the fear of it mostly stops people from marketing at all. His base case: "I think it's good to have your base assumption be that nobody cares about you, and nobody's like sitting there copying you. And if people are copying you, that's a signal that you've you've gotten traction."

Rhys's answer is that character is the moat, and so is the person. "I think the idea has to have character and those apps or ideas or websites or games or whatever, they're the hardest to copy." He has clones every day now, and people on Reddit and Twitter point at them and say he did it first, because they follow him, not just the app. "Like your app is not necessarily the brand like you are your brand."

There's more in the episode: the Canadians who demanded touch snow mode (it now has touch sand and touch anything modes too), the unreleased app that charged Rhys real money every time he opened TikTok, the cinema he rented to premiere his first app's YouTube vlog, and the half-finished bird-song app that's Strava for wood pigeons.

Guest links

• Rhys Kentish on X
• Touch Grass

Let’s kick off with our main stage sessions.

1. Julie Hansen (Babbel): breaking the rules is sometimes what’s best for your app

Growth advice typically favors freemium, short funnels, recurring subscriptions over lifetime, and focusing on US markets first. But Julie Hansen, CRO and US CEO of Babbel, opened the day by walking through exactly what Babbel ignored from the industry’s rulebook.

Maybe one day we will start to do things a bit more conventionally — go against our own rule-breaking.

Many of the contrarian bets behind Babbel’s 19 years of growth — and now 30 million subscribers — trace back to a single unconventional decision: going premium in 2009. Here are the key decisions Julie shared, and the trade-offs behind them.

• Premium filters for motivated users: Babbel tried ads before going premium in 2009. For a language-learning app, they found asking for money upfront identified users who would retain better, as they were committed to putting in the work long-term. The choice funded the business and sharpened product-market fit, but it also meant a smaller audience and more pressure on marketing.
• Longer onboarding is only valuable if the product delivers: asking how many minutes a day you'll study, why you're learning, and whether you've studied before can reinforce commitment. But if onboarding promises personalization, the product must deliver it; additional questions are only valuable when they build commitment or inform the experience.
• Web checkout creates trade-offs: Babbel values its web funnel for data, speed, and economics, including avoiding app store fees. The flip side: Julie notes Babbel lost focus on app marketing for a time. It’s important to optimize the full web-to-app experience, not just checkout costs.
• Lifetime plans can match the job: language learning is a journey people dip in and out of, so short plans create performance pressure. Lifetime subscriptions remove that, and “Babbel sells a lot of them”. The downside: lifetime is the end of the monetization road, unless you have new products to offer or hybrid monetization in play.
• Win-backs matter more over time: People drop in and out of learning, so Babbel is increasingly investing in retention and reactivation, balancing it against new user acquisition.

Watch on YouTube

2. Greg Cohn (Burner): fighting churn is a missed opportunity

What do you do when your app's aha! moment is the moment users throw it away? Greg Cohn, Co-founder and CEO of Burner (Ad Hoc Labs), took to the stage to explain how Burner stopped trying to turn "tourists into locals" and instead designed a growing business that embraced its churn-by-design.

Trying to get them to stay long-term when they had a short-term use case was fighting gravity.

The impact is undeniable, with a returning Burner user's subscription now worth 25% more than a new user's, and returning-user LTV up by 35%. Here are the lessons that got Burner here:

• Strong conversion can hide the wrong retention strategy: Burner converted installs to paid at almost 6x the median, but M1 retention was 38%, below the RevenueCat median. The challenge was that many customers needed a number temporarily, not indefinitely.
• Look for returners in your data: over a quarter of people who cancelled came back within a year (2.6x the utility app median), with zero effort from Burner. Returners made up about 10% of MRR, and over 30% of new subscription revenue.
• Make leaving easy: instead of fighting cancellations, Burner offers a $1.99 ‘pause’ plan (vs. $9.99 standard) to hold a user's number. It saves about 10% of would-be cancellations. They’re also testing keeping numbers active for a period after a plan expires, so users can see what they're missing.
• Don't treat returners like new users: returning users already know why they're there. Rather than wasting their time with normal onboarding, Burner shows them what's new, offers a more generous free trial, and leads with annual pricing as the best value. As a result, returning users have 2x the trial conversion of new users, and 5x the annual take rate.

Watch on YouTube

3. Ajay Mehta (Tolan): hybrid monetization gives apps a way to balance compute cost

Two years ago, Ajay Mehta was sitting in the audience at the first App Growth Annual. This year, he was on the main stage.

In those two years, he co-founded Tolan, a voice-first AI companion app that has since grown to more than one million users and 100k+ subscribers. But with 70+ million AI conversations happening in Tolan, Ajay knew from the first OpenAI bill that its unit economics were unsustainable.

Spend your extra margin on growth and on the people who already love you.

Ajay’s session broke down the monetization models Tolan speedran while racing the compute cost countdown. Here are the key learnings that got Tolan to healthy unit economics:

• AI changes the math: for the last generation of consumer apps, a big, engaged user base was pure upside. For an inference-heavy product, tokens cost real money, and cheaper models don't automatically fix margins. Tolan quickly learned that every user conversation carried a cost, and growing was actually hurting their profit margins.
• Product-market fit should factor in conversion: Tolan first clicked with Gen Z, which drove installs but not payment. Users in their late 20s–40s found deeper, everyday uses for Tolan, and had the means to pay for a subscription. Tolan rebuilt its creator program around this ICP, and added new character designs to appeal to them.
• A hard paywall has a ceiling: a hard paywall protects margins, but it caps your audience at the people who'll pay right away. Rather than lose users who couldn’t pay (like its Gen Z audience), Tolan moved to a freemium model, with a high-intent onboarding paywall (personalized with what users shared during onboarding) and feature-gated paywalls further down the funnel.
• Price for willingness to pay and serving cost: Tolan now offers Lite, Plus, and a $200/month Unlimited plan, with tiers set by cost to serve. Expensive new AI capabilities start on higher tiers and only move to lower tiers as serving costs fall.
• Hybrid is the natural fit for AI apps: mixed monetization allows AI apps to lower the floor and raise the ceiling. Tolan combines subscriptions and one-off top-ups, while experimenting with ads and offering a family plan. Its emphasis on monthly subscriptions challenges the assumption that annual is always best. Instead, evaluate plan mix using conversion, retention, billing success, and revenue per user.

Watch on YouTube

4. Ravi Mehta: the right onboarding is whatever onboarding builds user confidence

Our closing keynote came from Ravi Mehta, former Chief Product Officer at Tinder.

Taking us on a journey from Boeing’s 1935 Model 299 bomber plane all the way through to Tinder’s two-minute onboarding, Ravi explained why one of onboarding’s most well-known ‘best practices’ isn’t always right.

Most product teams ask, "Should our product onboarding be shorter?" In reality, the right question to ask is, "What does a user need in order to feel confident at the moment of decision?"

This is how Ravi matchmakes the perfect onboarding for each app:

• Sometimes more steps convert better: when Ravi's client Sesame launched a weight loss program with Costco, its three-step checkout converted below target, and the users who did convert had so many questions that refunds were unsustainable. Replacing it with a 25-step intake (covering medical history, lifestyle, goals, and motivation) lifted conversion by 40%, and refunds went way down.
• Not all friction is created equal: good friction — like asking medical questions in a health app’s onboarding — builds confidence. Bad friction drains it, like asking for a password before you've given users any value, or asking a question they can't easily answer. (Sesame’s "When was your last physical?" became "Have you had a physical in the last six months?")
• Pick a lane: the worst onboarding sits in the "messy middle", usually the result of compromise: too long and too short at the same time. The best onboarding is opinionated, either doing the work to build confidence or cutting everything that isn't essential.
• Engineer confidence: give users the information they need, at the pace they need it, to help them make a confident decision. The right onboarding depends on both the stakes and complexity of your app. For example, a glucose monitoring app is high stakes and high complexity, a meeting reminder app may be high stakes but low complexity, and a crossword game is low stakes and low complexity.

Watch on YouTube

5. The Big App Roast: paywalls and lifecycle messaging are more connected than you realize

Lunch for our virtual audience came with a side of paywall critique, as CRO Designer Julie Buzhynskaya and CRM Strategist Luigi Forte put five pairs of popular apps head to head, including Calm vs. Headspace, and FaceApp vs. Facetune. Julie dissected the paywalls, followed by Luigi reviewing everything after that: permission prompts, push notifications, emails, and in-app messages.

Four lessons came up repeatedly:

• Show value before asking for payment: both Cal AI and FaceApp use short demonstrations or before-and-after visuals to show what the product actually does. Test whether a concrete demonstration helps users understand the offer better than generic creative.
• Make the offer and trial easy to understand: multiple apps lacked clarity around trial and offer terms. Explain what users receive, when billing starts, and how to cancel.
• Use lifecycle messaging to reinforce activation: ask for notification permissions in context and explain their value. Useful reminders should help users experience the product, with timing and frequency tested against engagement and opt-outs.
• Keep communicating with trial cancellers (where appropriate): cancellation during a trial does not necessarily mean the user has lost interest. Relevant, respectful follow-up can help people discover value before access ends.

Watch on YouTube

Other highlights from App Growth Annual

It wasn’t just the main stage sessions that got people talking at App Growth Annual. With 36 interactive workshops, a game show, and a surprising after-party guest, here are some moments you may have missed.

Hands-on workshops

Throughout the day, three blocks of time were reserved for intimate, hands-on workshops. In-person attendees had 30 to choose from, with content exclusive to those in the room. Online, attendees got to select from live workshops with Lisa Kennelly (Klarna), Marcus Burke (Ctrl Shift), Bria Sullivan (Honey B Games), Sven Jürgens, Julien Daver (SplitMetrics), and Yuliya Lennox (Genesis Tech).

Each virtual workshop is available to watch now, complete with the presenter’s full slide deck. Check out our recap on the workshop content here to see what you missed.

RevenueCat product keynote

Our annual product update saw RevenueCat CEO & Co-founder, Jacob Eiting, share news about Early Payouts, ad monetization, and everyone’s favorite in-dashboard AI advisor, Rico. We also got a glimpse into Targeting by Checkpoint, a new way to personalize your funnel to each user by matching the right experience (like a specific offer or paywall variant) to each moment on their journey.

Read the full rundown of every product announcement from App Growth Annual 2026.

From RevenueCat data land, Jacob also highlighted these stats:

• More apps are shipping than ever: 107,000 apps have gone live on RevenueCat so far this year, up from 41,000 in all of 2025, and all-time annual revenue tracked across RevenueCat now sits at $17 billion+
• Spending isn’t keeping pace: per Appfigures, app launches are up 85% year over year, while consumer spending grew just 15%, so more apps are competing for roughly the same growth
• Newer apps have begun to make a dent: as a cohort, apps that launched on RevenueCat in 2023 and after grew 124%, while apps launched before 2023 declined -2%

The takeaway? When anyone can build your features in days, software alone isn’t a moat anymore. Your edge has to come from network effects, brand, content, and what you are uniquely placed to understand about your customers.

It's never been easier to make software, but it's never been harder to make that software a successful business.

Watch on YouTube

Who Wants to Be a MillionARR?

Last year, we turned building paywalls into an e-sport. This year, we turned the State of Subscription Apps into a game show. Next year, who knows what we’ll do. There is no stopping us.

Who Wants to Be a MillionARR? kicked off with a qualifying round open to the whole room: 10 timed multiple-choice questions, answered from attendees' phones (and won by whoever answered fastest). The top three — Hamad, Daphne, and Adrian — then took to the stage for a Jeopardy-style final, complete with real buzzers and categories covering the app market, paywalls, retention, and AI apps.

The prize? Not quite a million dollars, but still very cool: $500 and a massive, wrestling-style championship belt, with $300 and $200 for second and third place.

After a rocky start that saw her drop to -800 points, Daphne Tideman staged a comeback (or as she called it, a winback), answering question after question to take the crown.

Five consecutive correct answers later, she was the proud owner of the Who Wants to Be a MillionARR belt. Proof that it pays to be persistent (and to read the RevenueCat blog), even in the face of challenging odds.

Think you'd have made the final? Try these questions from the day, then scroll down for the answers.

Answers:

1. 55%

2. 4.6%

3. 14,700

4. 17–32 days

5. “Continue”

6. Progress bars

7. Asia-Pacific (APAC)

8. 41%

Watch on YouTube

After-party with Marc Rebillet

Every year, the RevenueCat team brainstorms who should perform at the App Growth Annual after-party. And every year, it’s the most unexpected option on the shortlist that makes the cut.

This year, Marc Rebillet took The Glasshouse by storm, delivering his signature improvised electronic tunes, complete with an app monetization-themed track. There was dancing, drinks, dim sum. And (of course), custom RevenueCat silk robes for every attendee. So everyone got to party in true Marc Rebillet style.

We'll see you next year

That’s it for your whirlwind tour of App Growth Annual 2026. Five keynotes, 36 workshops, one championship belt, and more cat-themed swag than even we expected — but you can only fit so much into a blog post.

If you want to relive the day for yourself, here’s everything you need:

• Watch the highlight reel
• Replay all the main stage sessions on YouTube
• Catch up on the virtual workshops
• Read all the product news we announced
• Hear Thomas Petit and Sylvain Gauchet’s top insights from App Growth Annual
• Browse the official photo gallery in search of your candids

Lisa Kennelly (Klarna) — Copy that converts: the language-market fit teardown

AI-written onboarding and paywall copy often reads fine, but it fails at conversion. Because it doesn't use your customers' language. Lisa Kennelly (Growth and Product Market Strategist, Klarna) gave a great workshop on how to write copy with language-market fit: copy that sounds the way customers already speak.

Lisa walked through her process for mining App Store reviews, competitor reviews, cancellation reasons, support tickets, Reddit thread, and interviews, where she looks for five things:

1. The outcome users want
2. The trigger that made them download
3. The alternatives they tried (including doing nothing)
4. Their anxieties
5. The exact words they use

Everything goes verbatim into a single ‘language bank’ that every draft starts from. Before shipping, every line faces a five-point check — starting with whether it uses a phrase customers actually repeat.

Watch on YouTube

Resources:

Download Lisa's workshop slides Download Lisa’s handouts: prompt pack + language bank template

Further reading:

• 📕 From review to roadmap: how mining reviews can inform your app's features by Daphne Tideman
• 🎧 Sub Club podcast: How to Scale Your App Marketing Team from Scratch ft. Lisa Kennelly
• 📗 Start here: a paywalls study guide

Bria Sullivan (Honey B Games) — The playbook behind 23 million organic downloads

Bria Sullivan's game Boba Story has 18 million organic downloads, and Focus Friend — the gamified focus timer built with Hank Green — passed 5 million, most of them arriving long after Hank stopped posting about it. Her secret is a simple, two-pronged repeatable research funnel:

• Short surveys to find people who already use apps to solve your problem
• Customer interviews to understand them
• Disciplined pattern-finding in the feedback

Surveys ask what; interviews ask why and how, starting with the user's relationship to the problem before you show them anything. Bria’s workshop walks through her research process, including how she tests her ideas, the questions she asks, and how many interviews to aim for.

Watch on YouTube

Resources:

Download Bria's workshop slides

Further reading:

• 🎧 Launched podcast: The Hail Mary pitch that launched a #1 App Store hit ft. Bria Sullivan
• 📕 How user interviews can inform your ad creatives by Nathan Hudson
• 📗 Don't just solve a problem — solve it emotionally by Daphne Tideman

Sven Jürgens — From competitor ad to finished creative, in one hour

Your competitors have already paid to learn what works in your category — and thanks to the impression filter in Meta's Ad Library, their best performers are public. At App Growth Annual, growth consultant Sven Jürgens shared how he uses these competitor ads to inform his own creative, with AI-generated video fast-tracking the process.

Sven’s session shows his nine-step AI workflow in real time, with the audience voting on the app and actor. About 10 minutes and roughly $3 later, out came a lip-synced UGC-style Cal AI ad. With the heavy lifting done by AI, Sven spent the rest of the workshop on what actually makes a good output:

• Research into your users' pains and awareness stage
• Rich context (brand guidelines, user insights, real app footage) rather than clever prompts
• Ads built from swappable ‘Lego blocks’ (hook, body, call to action) so winners are fast to iterate

The full workshop covers Sven’s AI ad process, his golden rule for reporting, copywriting guidelines, brand examples, and how to structure your documentation.

Watch on YouTube

Resources:

Download Sven's workshop slides Download Sven’s nine-step diagram

Further reading:

• 📕 AI-generated ads: balancing attention and trust in user-generated content by Anthony Morcillo
• 🎧 Sub Club podcast: How to Go Viral on TikTok (and Profit From It) ft. Joseph Choi
• 📗 Forget chasing viral ads — build a creative testing system that scales by David Vargas

Yuliya Lennox (Genesis Tech) — Nothing works until this does: the app marketing sequence

Most apps don't stall because of bad tactics; they stall because they skipped a step. In her workshop, growth marketer Yuliya Lennox (BetterMe, Replika, Palta) presents app marketing as four stages, each one a prerequisite for the next:

1. Prove there's demand
2. Build a journey that converts to paid
3. Make the economics work
4. Scale

Her advice for stage one: charge from day one (free-user retention tells you nothing about willingness to pay), test demand with a simple funnel before building the full product, and test genuinely different creative concepts rather than 20 variations of one slogan. Once something works, she pushes teams to count every cost — store fees, payment fees, AI infrastructure, refunds — and aim for payback as close to day one as possible.

Watch on YouTube

Resources: Download Yuliya's workshop slides

Further reading:

• 📕 Finding product-market fit: a guide for subscription apps by Daphne Tideman
• 🎧 Sub Club podcast: Make Ugly Ads to Grow Your App ft. Yuliya Lennox
• 📗 Stop chasing growth hacks — fix your funnel first by Hannah Parvaz

Marcus Burke (Ctrl Shift) — 6+1 AI workflows to run and scale Meta ads from your phone

Checking whether one Meta ad is profitable can mean hopping between Ads Manager, Events Manager, your MMP, RevenueCat, product analytics, and a spreadsheet. Meta ads advisor Marcus Burke now has AI do the tab-hopping for him.

His setup is deliberately simple: Notion as a central, model-agnostic ‘brain’ holding his SOPs, client context, and a change log, with Claude connected to it, and to his data tools via MCPs. On top sit the workflows he runs across client accounts, including a regular ‘account patrol’, age and placement breakdowns that predict trial-to-paid before the data matures, and value rules. Others cover format research across ad libraries and TikTok, voice-of-customer copywriting, and an ad–onboarding fit check that flags when a scaling ad promises something your funnel never pays off.

The new workflows have cut Marcus’s time dramatically, from two hours to 10 minutes in some places. Check out his full workshop for a detailed walkthrough of his AI setup and each workflow.

Watch on YouTube

Resources:

Download Marcus's workshop slides Meta Ads account x-ray

Further reading:

• 🎧 Sub Club podcast: Selling Your Subscription App with Meta Ads ft. Marcus Burke
• 📕 7 Meta ad testing frameworks for subscription apps by Daphne Tideman
• 📺 Sub Club Live: Meta Ads for Apps: Creative, Signal & Scaling in 2026 ft. Marcus Burke

Julien Daver (SplitMetrics) — Make AI-generated ads that actually convert

In our last workshop, Julien Daver (Head of UA at SplitMetrics) shares the AI creative framework his entire team uses to find winning ad creatives.

It starts with a research agent that continuously collects your own data (brand material, audience insights, onboarding answers, campaign results) alongside external sources like competitor ads, Reddit, app reviews, and YouTube comments. A second agent turns that into concepts, angles, and hooks, kept separate so you can trace what actually moved performance — helped by naming every ad after its hook, angle, and concept.

Julien generates video, voiceover, and music as separate components, so fixing one element doesn't mean paying to regenerate the whole ad. Finally, results get fed back into the research agent to close the loop. Watch Julien’s workshop now to see the sleek workflow in action.

Watch on YouTube

Resources:

Download Julien's workshop slides

Further reading:

• 📕 Why creative fatigue is killing your ROAS by David Vargas
• 📗 The creative testing system that slashed our CAC (and scaled our spend) by Nathan Hudson
• 🎧 Sub Club podcast: The AI Growth Playbook for Subscription Apps ft. Phil Carter

Keep the momentum going

Six workshops, one common thread: AI can now do the heavy lifting on research, copy, creative, and reporting — but only when you feed it real context about your users and keep a human checking the output. Humans are uniquely placed to understand their users, and that’s where AI is most at risk of failing.

Pick the session closest to your biggest bottleneck, grab the slides, and try one idea this week.

Still hungry for more? Watch every App Growth Annual 2026 main stage session on YouTube, or read our ultimate recap blog. We'll see you at App Growth Annual 2027?

At App Growth Annual last week, we announced new tools to help with each of those jobs. Some are available today, others are entering public beta, and a few offer a preview of where RevenueCat is going next.

Together, they bring more of the work of growing an app into RevenueCat, from building your first paywall to understanding revenue across subscriptions and ads.

Available now

Build and refine paywalls with AI

Describe the paywall you want, and the Paywalls AI Editor will build it. You can also start with a screenshot, ask for changes, and keep refining the design through conversation.

Underneath the design, you still have RevenueCat’s paywall infrastructure connecting your products, purchases, and data. That means less time between having an idea for a paywall and having something ready to test.

Take customers from the web into your app with Funnels

RevenueCat Funnels lets you build and launch web-to-app funnels using the same editing engine as RevenueCat Paywalls.

Build your web experience, connect checkout, and help customers move from their purchase on the web into your app. RevenueCat handles the connections that make that transition work, so you have fewer pieces to assemble yourself.

Funnels has no additional platform fee. Funnel revenue counts toward your monthly tracked revenue and is subject to RevenueCat’s standard pricing, plus applicable payment processing fees.

See Experiment results in real time

Experiments results now update in real time, so you can follow a test without waiting for the next daily refresh.

Results also include predicted 12-month LTV, helping you compare variants beyond their initial conversion rates. A variant that converts more customers today may have a different long-term outlook, and those predictions give you more information to work with when deciding what to ship.

Once you’ve made that decision, you can roll out the winning variant in one click.

Bring RevenueCat into your AI tools

The AI Toolkit gives your AI assistant the RevenueCat context and tools to help you set up monetization, ship paywalls, troubleshoot purchases, and understand performance.

It includes skills, the RevenueCat MCP, and the RevenueCat CLI, which lets you or your agent run commands from the terminal. One plugin install sets up the skills and MCP server in Claude Code, Codex, Cursor, Gemini CLI, and VS Code.

Ask your agent to review your monetization setup, investigate trial conversion, or summarize experiment results, then keep working in the tools you already use.

Expand web checkout with RevenueCat Web

RevenueCat Web lets customers complete a purchase on the web and access what they’ve bought in your app. You can sell through RevenueCat Billing, Stripe Billing, or Paddle Billing, and use the same paywalls, funnels, and customer data across web and mobile.

RevenueCat Billing also supports app-to-web purchases, letting customers start in your app, complete checkout on the web, and return with access to their purchase.

In the EU, Apple’s new terms let you offer your own checkout inside your app at 20% commission. In-app checkout works with Stripe Billing and Paddle Billing today, with RevenueCat Billing to follow. RevenueCat handles the transaction reporting Apple requires, so you don’t have to build your own reporting integration.

Understand customer groups with Audiences

Audiences lets you group customers by shared characteristics and understand how different groups use and pay for your app.

Create an Audience using subscription status, customer attributes, or acquisition source. Membership updates in real time as customers’ information changes, keeping those groups current.

You can use Audiences to filter charts, explore customer segments, and export groups for further analysis. They’re also a foundation for the new targeting and ad monetization capabilities currently in beta.

Access your proceeds sooner with Early Payouts

The time between earning revenue and the app store paying you can make it harder to fund acquisition, cover expenses, or invest in your next release.

Early Payouts lets qualifying apps advance up to 80% of app store proceeds at a 2.5% fee. The remaining 20% arrives on your normal payday, with no fee on that remaining payout. Fees only apply to the amount you advance.

You can choose automatic advances or draw funds when you need them, with no minimum usage requirement and the ability to pause.

At RAGA, we also announced plans to expand to 13 additional countries, including the UK, France, and Canada.

See if you qualify >

$100 minimum transaction amount applies for on demand payouts. RevenueCat is not a bank. Banking services are provided by Core Bank, Member FDIC. Deposits are FDIC insured up to $250,000 per depositor, per insured bank, subject to limitations.

Now in public beta

Meet Rico, your agent inside RevenueCat

Rico is RevenueCat’s new in-dashboard AI agent. Ask Rico a question like ‘How much revenue did we make in Germany last month?’ Then, ask follow-up questions to dig into the numbers.

Rico can also take action. Ask it to set up an Experiment or build a Paywall, so you can move from a question to trying an idea without navigating every step yourself.

The AI Toolkit brings RevenueCat into your existing tools. Rico gives you a way to work conversationally while you’re already in the dashboard.

See ad revenue alongside purchases

Subscriptions and in-app purchases may only tell part of your app’s revenue story. Ad Monetization brings in-app ad revenue into RevenueCat so you can see customer lifetime value across hybrid monetization.

That gives you a fuller view of what customers earn for your business, including those who use your app without ever making a purchase.

Ad activity can also inform your Audiences and Experiments, connecting what you learn about ad engagement with how you segment customers and test monetization experiences.

Reward ad-views through the AdMob integration

Rewarded Ads lets you give customers in-app currency or temporary access to paid features in exchange for watching an ad. Through the AdMob integration, RevenueCat verifies that a customer earned the reward and delivers it. For example, a customer could watch an ad to earn coins or unlock a premium feature for 30 minutes, with RevenueCat managing those rewards alongside purchases and subscription access.

Coming next

Match each moment to the right experience with Targeting by Checkpoint

Targeting by Checkpoint is coming soon. Choose what to show customers based on where they are in your app and which Audience they belong to. Then, run Experiments to learn what works best. A checkpoint is a location or moment you add to your app, such as finishing onboarding or trying to access a premium feature. Once it’s implemented, you can configure rules in the RevenueCat dashboard to control what customers see there. For example, a run-training app could show a marathon-focused paywall to customers who selected marathon training as their goal during onboarding. At the same checkpoint, customers who arrived through a particular ad campaign could see a paywall that matches the campaign’s message.

You’ll be able to run Experiments directly within those targeting rules. Test different paywalls or multi-step flows for a specific Audience at a specific checkpoint, with the rules and variants managed together.

Targeting by Checkpoint also allows you to reuse a single Offering across multiple paywalls, so you don’t have to duplicate it every time you want to try a new paywall design.

Support for additional experiences, including ads and offers, is planned to give you more ways to tailor monetization to each customer and moment.

Interested in joining the upcoming private beta of Targeting by Checkpoint? Fill out this form and we’ll reach out if you’re a good fit for early testing. 

More time to work on what makes your app worth paying for

Build a paywall from an idea. Tailor it to your customers. Test it, see what’s working, and roll out the winner. These releases bring those steps closer together, so you can spend less time connecting tools and more time trying things that could grow your business.

Start building with the features available today, try Rico and our ad capabilities in public beta, and stay tuned for Targeting by Checkpoint. We’re making RevenueCat a place where you can put more of your ideas to work, learn from them faster, and keep improving what comes next.

Watch on YouTube

He posted it. By Adam's count it did "like 10 million views in Instagram, like another 10 million in TikTok, another 10 million in YouTube," and that was the month Praktika went from about $1M ARR to $12M. The video wasn't about the app at all. It showed a coach correcting a learner's mistakes mid-conversation, a format Adam says is now "the main structure of the video" for language-learning apps generally. His instinct had been to ask Gustavo to showcase the product instead. Gustavo's answer, as Adam recalls it, was "believe me."

Paid spend had little to do with it. "We put some budget behind it, but it was like, you know, a tiny budget," Adam says, with first-day costs per trial "literally close to zero." What turned one viral post into a $12M month was replication: "we started just replicating those videos with other creators in other countries as well." Gustavo was hired immediately and still runs Praktika's social media.

The rule behind all of this predates the video. "That was always my, like, rule since the beginning. Like, you know, do not tell influencers to do, like, how to do their job," Adam says. "If you're hiring them because they're like getting an amazing rich, right. So let them do their job." Jacob Eiting's version, from the other side of the table, is that a founder who forces everything through their own approval filter "gonna miss things that are just like, you're blind."

Under 5,000 followers, tens of millions of views

Gustavo came out of a filter, not a shortlist. Adam had no budget for established influencers in Brazil, so he went to a creator discovery platform and set two constraints: a following under 5,000, and views far above what that following should produce. "If you have big following then yeah, you're charging a lot. So I limited this to like less than 5000 followers. But at the same time I filtered out those who are getting like a lot of use these days." The creator it surfaced was doing tens of millions of views on educational videos, had no collaboration email on his profile, and "didn't even realise what he's into." Adam DMed him on TikTok.

Jacob reads it as buying an underpriced asset. Adam pushes back on the word. "Not even about underpriced, but it's more that you're approaching someone on their pick even before they're picking." The point is timing, not price. And he says the filter still works beyond one lucky find: "it can be used as a framework," not targeting micro-influencers as such but "filtering those out who are, uh, hitting like a lot of use with low followings."

How the program runs at $50M ARR

Praktika is now at $50M ARR, "reaching almost like half a million paying subscribers," Adam says, with a team of "a little bit more than 40 people," which puts ARR per employee above $1M. It is profitable. The creator program is past 100 influencers and is still being scaled country by country.

The structure is an influencer lead and country coaches, all of them former creators who were making Praktika videos before they were hired. The lead was making videos in Poland; "she had done an amazing job. And then we hired her as an influencer lead. And she's now running the world programs." Each coach runs "a roster of 20 or 30 influencers, and they just rotate various angles." Knowing what good content is, Adam says, is "the key skill you need to have," because the management side is "not that complicated especially now." The creators stay contractors. Deals are usually a fixed fee plus a bonus on views, but the coaches can restructure for talent: "if there is a good talent just do whatever to to hire this person."

The decision that keeps it working is that paid and organic never share a roster. "This is paid ads and organic content. This creator program that those two are separate streams. We don't mix them up," Adam says. Creators are left to find their own angles because the in-house team eventually runs dry on them, and "every new influencer upcoming is a potential for this." When a video goes viral, it is handed to the paid team, which "reproduce this video with like their own roster of like internal influencers or contractors."

Praktika sold Brazil a job, not a language

Brazil was chosen from a report on English-language penetration: one of the lowest-penetrated large markets, with an income multiplier for English that Adam calls "insane." The warning that came with it was that Brazilians "typically don't pay for consumer subscriptions." Praktika launched worldwide and pointed its distribution at Brazil anyway, because that is where the early adopters were.

Getting a $100-a-year subscription to sell there meant changing what was being sold. "We didn't sell English to them. We sold them an opportunity to get a better job, so it was just a bit of a different angle," Adam says. Every claim in the go-to-market followed, including the "50 x cheaper than a tutor" line he says "everybody uses now." David Barnard's generalization for anyone picking a problem: "look for a problem where you're selling money."

The avatars that worked in ads and failed in the app

Adam's biggest fail of the past year was moving a growth idea into the product. Unhinged, cursing avatars "were going viral in Upper Funnel," so the team added them to the app. It made more people unhappy than happy, and they didn't understand it. "The image is fine. Like, you know, I want to talk to this avatar, but why is it cursing, right?" The principle it clarified: "we're not serving AI companions. We're serving AI coaches."

Praktika now draws the line explicitly. Product has clear, agreed boundaries on "a one sheet of description." Growth has almost none. "We let influencers to create and to come up with like pretty much any angle that they want," Adam says, and the difference between the two sides "is pretty dramatic."

In the full episode, Adam also explains why Praktika's biggest win of the year was moving from Flutter to native iOS, why he builds for the best model quality and trusts inference costs to fall, and why fear, not skill, is the reason the app uses avatars at all.

Guest links

• Adam Turaev on LinkedIn: https://www.linkedin.com/in/adamturaev/
• Adam Turaev on X: https://x.com/adampraktika
• Praktika: https://praktika.ai/

It’s hard not to when it feels like every competitor is doing the same.

For subscription apps, there’s more to consider than sales. Discount an annual plan, and you’re accepting less revenue for a year. Offer a cheaper first month, and some subscribers may leave when the price goes up.

Does that mean holiday offers are too risky? Not necessarily. But they do require planning.

We analyzed nearly 5,000 apps worldwide during the 2025–26 holiday season to help you decide when to run a promotion and how to assess its results.

The research compares changes in new paying customers around Black Friday, Christmas, and New Year for apps with and without detected promotions. It also looks at what those buyers spent over six months, their renewals and refunds, and how apps presented their holiday offers.

Summary

• Apps with detected Black Friday promotions get more new paying customers and higher six-month revenue than in their September 15–October 12 baseline. Revenue per customer is lower, but the median app makes up for it with a larger customer base.
• Existing free users play a substantial role in Black Friday growth. Among apps with detected promotions, users who installed the app more than three months before their first payment account for about half the average increase in new paying customers.
• Christmas-only promotions show no clear acquisition advantage. Apps with offers detected only at Christmas perform similarly to apps without detected offers.
• New Year and January lead the holiday season for new paying customers, particularly in Health & Fitness and Gaming. Apps with detected New Year promotions get 14% more new paying customers per day than in September–October, while those without detected promotions get 4% fewer.
• Holiday paywalls put savings and urgency front and center. Discount claims, crossed-out prices, and limited-time messaging are common, and more paywalls show a single plan.

Holiday acquisition is lower overall, but apps with offers tend to perform better

Over the holidays, most app categories get fewer new paying customers than in their September 15–October 12 baseline. Even New Year and January, the strongest stretch of the season, come in slightly below it for the median app (3% fewer new paying customers per day).

Part of that dip comes from the baseline itself. Mid-September to mid-October is a strong stretch for new paying customers, so even ordinary weeks right after it are about 6% below. The 2024–25 season shows the same pattern.

Ad costs may also play a part. One analysis of large US Meta ad accounts found that CPMs for apps and services rose sharply around Black Friday, peaked in mid-December, and dropped below October levels in January. Higher ad prices can make new users more expensive to acquire in the run-up to Christmas.

Around New Year, new paying customers briefly rise above the September–October baseline. The peak doesn’t last, so the full period still comes out below it.

The two exceptions are Health & Fitness and Gaming, which stay above baseline across New Year and January (11% and 10% more new paying customers per day).

That’s likely when demand peaks for both: New Year resolutions for fitness apps, and new devices and time off for games.

But overall, the typical app gets fewer new paying customers per day than during that earlier period.

However, if we look at apps with detected promotions (421 at Black Friday, 208 at Christmas, and 236 at New Year), the picture changes.

During Black Friday and New Year, apps with detected promotions tend to perform better.

Black Friday shows the widest gap. During Black Friday week (November 24–December 1), the median app with a detected promotion gets 20% more new paying customers per day than in its baseline, while the median app without one gets 16% fewer. New Year and January follow the same pattern on a smaller scale: 14% more versus 4% fewer.

That said, Christmas shows a smaller gap.

Apps with detected Christmas promotions get 11% fewer new paying customers, while those without get 22% fewer. Most of that difference comes from apps that were also running promotions during Black Friday. Apps with promotions detected only at Christmas show no clear advantage.

We compare apps where we detect a promotion with those where we don’t. Most signals come from purchases, so offers with few or no sales can go undetected. Apps flagged only by holiday wording on their paywall, the one signal that doesn’t need sales, were 2% below baseline duringBlack Friday. Apps that run promotions may also spend more on ads. The results describe these two groups, rather than predict how much a discount would increase your sales.

More Black Friday buyers make up for lower revenue per buyer

Among apps with detected promotions, the increase in new paying customers during Black Friday and Cyber Monday appears large enough to make up for lower revenue per buyer over six months.

During November 24–December 1, 2025, these apps get 20% more new paying customers per day than in September–October.

Most of the extra customers are acquired in the five days from Thanksgiving to Cyber Monday. New paying customers peak on Black Friday (November 28) at 49% above baseline and stay at least 25% above it through Cyber Monday (December 1).

Each Black Friday buyer is worth a little less, but the extra buyers make up for it. Over the next six months, the median app earns 8% less revenue per buyer.

For the median app, buyers acquired on an average sale day generate 12% more revenue over six months than buyers acquired on an average baseline day. Overall, 60% of apps come out ahead.

That gain is limited to the sale week. Once the quieter weeks around it are included (November 10–December 14), the median app with a detected promotion is 1% below its baseline, versus 12% below for apps without one.

About half of Black Friday growth comes from existing free users

For apps with detected promotions, about half of the Black Friday increase came from people who’d had the app for over three months.

Black Friday buyers also look different from usual. During Black Friday week, 55% of these apps’ new paying customers had installed the app at least a day before paying, up from 45% in September–October.

So if you’re planning a Black Friday offer, don’t focus only on new installs. Some of the opportunity may already be in your free user base.

Black Friday offers also reach current and lapsed subscribers. In 9% of apps with detected promotions, these subscribers redeem at least three times as many offers per day as in September–October.

Annual plans account for nearly half of new paying customers

More Black Friday buyers start on an annual plan.

For apps with detected promotions, 49% of new paying customers bought an annual plan during Black Friday and Cyber Monday, up from 41% in September–October, mostly at the expense of monthly plans.

So far, Black Friday buyers on weekly and monthly plans renew about as often as usual. Weekly renewal rates change by less than one percentage point, while monthly second renewals are two percentage points lower.

Annual plan buyers look stable too, at least early on. Fewer of them request a refund within 30 days (2.7%, down from 4%), and auto-renew cancellations in the first 30 days don’t increase. Whether they renew is still an open question: their first renewal falls outside our six-month follow-up.

Utilities and Health & Fitness show the largest acquisition gains

The Black Friday gap varies widely by category. Among apps with detected promotions, Utilities and Health & Fitness get 46% and 37% more new paying customers per day than in their baseline, while Education and Social & Lifestyle stay roughly level.

Apps without detected promotions are below baseline in every category group. If you’re setting a campaign target, your category’s results may be a better benchmark than the overall 20% increase.

Black Friday discounts extend beyond introductory offers

Apps offer introductory deals, reduce prices on existing subscriptions, or add cheaper subscription options.

Among the apps with detected Black Friday promotions, we spotted:

• Offers for first-time subscribers. In 45% of apps, purchases using first-time subscriber offers increased, mainly through introductory deals such as a discounted first month. Both new users and existing free users can redeem them.
• Lower prices on existing products. 16% of apps sold an existing product at a lower price. About half of these may be regular price changes, not holiday promotions.
• New, cheaper subscription options. 16% of apps introduced a temporary subscription priced below their usual one.

Apps can use more than one type of offer, and some promotions were detected through other signals, such as sale-named products, so these shares don’t add up to 100%.

Christmas offers don’t show the same promise as Black Friday

The Christmas results give us less reason to expect an increase in new paying customers.

During December 15–25, apps with offers detected only at Christmas get 24% fewer new paying customers per day than in their baseline, almost the same drop as apps without detected offers (22%).

The stronger result comes from apps with promotions during both Black Friday and Christmas, which are down just 7%. But those apps were already 24% above baseline during Black Friday week, so their smaller decline doesn’t show that a Christmas discount has a notable impact.

Apps with New Year offers see more new paying customers into January

January is when apps with detected promotions pull ahead again. Over December 26–February 1, they get 14% more new paying customers per day than in their baseline, while apps without detected offers get 4% fewer.

January buyers also generate 10% more revenue per customer over six months than Black Friday buyers, with little difference in early renewal rates. That comparison is within apps with detected Black Friday promotions, so it doesn’t tell us whether New Year offers improve revenue. In apps without detected Black Friday promotions, January and Black Friday buyers are worth about the same (+2%).

The acquisition increase is strongest around New Year and smaller later in January:

• December 26–January 4: 24% more new paying customers per day for apps with detected offers, versus 4% fewer for those without
• January 5–February 1: 11% more, versus 6% fewer

The New Year lift is strongest in Health & Fitness, which goes from 28% below baseline at Christmas to 11% above over New Year and January. Gaming is also 10% above baseline over the same period.

These category figures cover apps with and without promotions, so they show where acquisition is stronger across the season (not where discounts work best).

How subscription apps present their holiday offers

Holiday paywalls differ most from ordinary ones in how they present the deal. Percentage discounts, crossed-out prices, and urgency appear far more often on holiday paywalls. Free trials remain common, and lifetime options and single-plan layouts appear more often.

The percentage off is the most common holiday addition. It appears on 61% of Black Friday paywalls and 54% of New Year paywalls, compared with 8% outside the holidays. Crossed-out prices and urgency wording jump too, from under 5% of ordinary paywalls to roughly a third or more of holiday ones.

During Black Friday week, nearly three in four paywalls showing a percentage discount offered 50% off or more.

Our acquisition findings also suggest what to test in your paywall message. Existing free users account for a substantial part of the Black Friday increase. To target these users, test a paywall built around the paid features missing from their current experience, with the discount attached to that upgrade.

Lifetime access shows up about twice as often as usual: on 35–38% of Black Friday and New Year paywalls, versus 17% outside the holidays. The buyer gets lasting access at a sale price, while the app collects revenue upfront instead of relying on future renewals.

Finally, more holiday paywalls show a single plan (30–36%, versus 20% of ordinary paywalls). A single-plan offer screen removes the need to compare subscription lengths and may help focus the sale.

What to test in your next holiday campaign

Our data gives subscription apps a good reason to experiment with holiday offers. But there’s no universal playbook. Start with how users in your category behave, then adjust your approach for each holiday.

Gaming apps, for example, tend to do well around Christmas and New Year, when people get new devices and have time off. Fitness apps, on the other hand, pick up in January, once New Year resolutions start.

It’s also worth looking beyond net new users. During Black Friday week, about half of the increase in new paying customers came from users who installed the app more than three months earlier.

Converting existing free users, winning back past subscribers, and upselling current ones can all add revenue during this period.

Beyond timing and audience, a few parts of the offer are worth testing:

• Discount size: Most holiday paywalls that state a percentage go to 50% or more. A deep cut grabs attention, but it isn’t always needed. In January, for example, when more people buy even without an offer, a smaller discount might do the job.
• Urgency: About a third of Black Friday paywalls use limited-time wording, and one in five adds a countdown. Too much pressure can feel pushy, so test different nudges for each segment, such as showing long-time free users the premium features they keep running into.
• Lifetime access vs. subscriptions: A one-time plan appeals to people tired of subscriptions and brings in revenue upfront. Those buyers never renew, though, so price it with your annual subscribers in mind.
• Plan setup: Test featuring a lifetime option, focusing on a single offer, labeling one plan as the best value, or discounting a different plan length
• Price display: Holiday paywalls show crossed-out prices more often than ordinary ones, and many break down the price by week or month. Christmas paywalls also lean on gift wording and holiday emoji, so test which presentation fits your offer.

How we collected the data

We analyzed 4,964 apps worldwide during the 2025–26 holiday season, comparing each app’s daily average of new paying customers with its own September 15–October 12, 2025 baseline. Apps needed at least 30 new paying customers a week in the baseline, and iOS and Android versions count as separate apps. A new paying customer is someone paying for an app for the first time, whether they installed it recently or had been using it for free.

• Holiday windows cover November 24–December 1 for Black Friday and Cyber Monday, December 15–25 for Christmas, and December 26–February 1 for New Year and January
• Promotion detection looks for increases in offer redemptions by new or existing subscribers, sale-named products or Offerings, lower prices on existing products, new cheaper subscription products, and holiday wording on RevenueCat Paywalls. Each signal must stand out compared with both the baseline and March 2026. Signals can overlap.
• Revenue and retention follow buyers for 180 days. Revenue is net of refunds and before store commission; cohort comparisons account for acquisition-window length. Annual renewals fall outside this follow-up.
• Paywall analysis covers RevenueCat Paywalls with holiday wording shown at least 100 times: 176 at Black Friday, 69 at Christmas, and 104 at New Year, one per app project. We compare these with 5,193 non-holiday paywalls shown October 13–November 9.

Results generally describe the median app; the install-timing split uses an average. Most promotion signals depend on purchases, so unsuccessful offers may go undetected.

The comparisons show associations, not direct proof that promotions cause growth or that particular paywall designs convert better.

The RevenueCat Codegen Gradle Plugin generates type safe Kotlin accessors for your entitlements (what a purchase unlocks) and offerings (the products your paywall shows), yet it contains no KSP processor. KSP appears in its source in one place, a fix for a build failure. So why would a code generator skip KSP, and how could KSP still break its build?

In this article, you'll start from a KSP processor you might write for this job, then trace inward through KSP's input model, the conditions where it fits, the point where it stops, the plugin's two Gradle tasks, and the one place its output meets KSP.

The fundamental problem: A generated copy that goes stale

The RevenueCat Codegen Gradle Plugin reads the entitlements and offerings configured in your RevenueCat dashboard and writes Kotlin accessors for them, so that a string lookup like this one:

val isPremium = customerInfo.entitlements["premium_access"]?.isActive == true

becomes a property the compiler can check:

val isPremium = customerInfo.isPremiumAccessActive

Generated code like this is a copy of a source of truth, and a copy is only useful while it matches the original. That gives every generator two questions to answer: where does the input come dfrom, and how does the build find out that the input changed?

If you were building this generator yourself, the obvious first attempt would be a KSP processor. Assume the dashboard's configuration, the schema, was already downloaded to a file. In a small JVM project, a processor reads the file's path from a KSP option and generates a constant, Schema.VALUE, from the file's contents. If you've ever passed room.schemaLocation to Room this way, the build script looks familiar:

ksp {
    arg("schema.path", file("schema.txt").absolutePath)
}

The first build generates the right value. Then change only schema.txt from v1 to v2, and build and run the app again. On KSP 2.3.12 with Gradle 9.8.1, the relevant console lines are:

> Task :app:kspKotlin UP-TO-DATE
> Task :app:compileKotlin UP-TO-DATE
...
> Task :app:run
Schema.VALUE=v1

The processor never ran, and the app printed the old value. The generator answered the first question and got the second one wrong: the build succeeded, and the app ran with data that was already out of date. To see why, you need to look at what KSP actually reads and tracks.

What KSP is: A processor that reads your declarations

KSP's README describes it as "an API that you can use to develop lightweight compiler plugins," and a plugin built with it is called a symbol processor. A symbol is the compiler's description of something you declared, such as a class, a function, or a property, with its name, modifiers, and types. A processor never parses your source text. It receives your program as a tree of symbols, such as KSClassDeclaration, KSFunctionDeclaration, and KSPropertyDeclaration.

It can also ask for any type to be resolved: which class a name refers to, whether it's nullable, and what its type arguments are. It responds by writing new source files, which the Kotlin compiler compiles together with your code in the same build.

To see what KSP hands a processor and what it expects back, imagine a processor the plugin doesn't have, for a world where your entitlements were declared in code instead of in a dashboard:

@Target(AnnotationTarget.CLASS)
annotation class Entitlements(vararg val keys: String)

@Entitlements("premium_access", "pro_photo")
object AppEntitlements

The processor starts by asking the Resolver, KSP's entry point for querying the code being compiled, for annotated symbols:

class EntitlementsProcessor(
    private val codeGenerator: CodeGenerator,
) : SymbolProcessor {

    override fun process(resolver: Resolver): List<KSAnnotated> {
        resolver.getSymbolsWithAnnotation("com.example.Entitlements")
            .filterIsInstance<KSClassDeclaration>()
            .forEach { declaration -> generate(declaration) }
        return emptyList()
    }

For each declaration it finds, the processor reads the annotation's arguments. A vararg argument arrives as a List:

    private fun generate(declaration: KSClassDeclaration) {
        val keys = declaration.annotations
            .first { it.shortName.asString() == "Entitlements" }
            .arguments.single().value as List<*>

Then it builds the file with KotlinPoet, a library that writes Kotlin source from builder calls instead of string templates, and hands the file to KSP:

        val idObject = TypeSpec.objectBuilder("RCEntitlementId")
            .addOriginatingKSFile(declaration.containingFile!!)
        for (key in keys) {
            idObject.addProperty(
                PropertySpec.builder(key.toString().uppercase(), String::class, KModifier.CONST)
                    .initializer("%S", key)
                    .build(),
            )
        }

        FileSpec.builder("com.example.rc", "RCEntitlementId")
            .addType(idObject.build())
            .build()
            .writeTo(codeGenerator, aggregating = false)
    }
}

Three parts of this code define what KSP is:

• Input: getSymbolsWithAnnotation returns declarations from the code being compiled. This processor doesn't open any files. It reads declarations that KSP has already parsed, and asks KSP to resolve a type only when it needs one.
• Output: the file is written with KSP's CodeGenerator, not to a path you choose. KSP places it under build/generated/ksp/.
• Origin: addOriginatingKSFile records which source file the output came from, and aggregating = false says the output depends on that file alone. KotlinPoet's KSP module, kotlinpoet-ksp, packs both into a KSP Dependencies object in writeTo.

That object is how KSP keeps incremental builds correct, meaning how it decides what to regenerate when only some files changed. Here is its declaration in KSP's CodeGenerator.kt, with the KDoc trimmed. Look at what the public constructor accepts:

class Dependencies
private constructor(
    val isAllSources: Boolean,
    val aggregating: Boolean,
    val originatingFiles: List<KSFile>,
) {

    constructor(
        aggregating: Boolean,
        vararg sources: KSFile,
    ) : this(false, aggregating, sources.toList())

    companion object {
        val ALL_FILES = Dependencies(true, true, emptyList())
    }
}

The public constructor accepts KSFiles, the source files of the current compilation, and nothing else. No other KSP API lets an output depend on a file path, a URL, or an option value either.

The aggregating flag chooses between two kinds of output. An isolating output (aggregating = false) is like the translation of a single page: it needs redoing only when that page changes. An aggregating output is like a book's index: any edited or new page might change it, and ALL_FILES ties an output to every file at once.

On the next build, KSP compares the changed source files with the origins each output recorded, hands your processor only the files that need processing again, and puts back every other output from a copy it saved on the previous build. You get correct incremental builds without writing any tracking code, as long as each output names the source files it came from and everything it depends on is code this compilation sees. The KSP incremental processing guide covers the full rules.

When KSP is the right tool: Three conditions

KSP fits a generator best when three conditions hold:

• Input declared in your code: annotations, classes, function signatures, anything the compiler parses as part of the build.
• Output that needs the compiler's knowledge: annotation arguments, resolved types, nullability, suspend modifiers, supertypes, and type parameters all arrive as symbols, so you never write a Kotlin parser.
• Regeneration tied to those declarations: the output should change exactly when the declarations change, and KSP's per file tracking gives you that for free.

The processors you already use are built around all three. Room, for example, has to know whether a DAO method is suspend to generate the right implementation, and that information is a property of a KSFunctionDeclaration.

KSP also limits what a processor can produce. Its overview says it directly: "KSP-based processors can't examine expressions or statements, and they can't modify the source code." A processor can't look inside function bodies, and it can only add new files next to yours. A tool that needs to change code you wrote has to work below KSP.

A full Kotlin compiler plugin runs inside the compiler and can change what gets compiled, which is how kotlinx.serialization adds serializers to your classes and how the Compose compiler rewrites @Composable functions. A bytecode transform works on compiled classes instead. Hilt's Gradle plugin uses one to swap the superclass of each @AndroidEntryPoint class for the generated Hilt_ class, so your source never has to name it.

Where KSP's model stops: Inputs outside your source files

The schema.txt processor fails the first condition, and the stale value follows directly from it. Before running a task, Gradle fingerprints every input the task declared, a hash of each value and file, and compares the result with the previous run. If nothing changed, it prints UP-TO-DATE and skips the task. The declared input for an arg() option is the string itself: the path, which didn't change.

Gradle never looks inside the file, and KSP's own tracking can't help either, because it runs inside the task, and the task never ran. Switching the output to aggregating = true or Dependencies.ALL_FILES, or turning off KSP's incremental mode with ksp.incremental=false, produced the same stale value. It stayed stale until some unrelated change, such as an edit to a Kotlin file, made Gradle run the task again.

Tying the output to a source file, the way EntitlementsProcessor does, makes the failure quieter. Picture a processor that finds an annotated class the same way, reads schema.txt, and records the annotated class's file as the origin of its output. Edit schema.txt and, in the same build, add a new, unrelated Kotlin file. The new file changes a declared input, so Gradle runs kspKotlin this time, and KSP hands the processor only the source file that changed: the new one.

The annotated class isn't in it, so getSymbolsWithAnnotation returns nothing, and the processor writes nothing, even though it just read v2. The origin file didn't change either, so KSP puts back the copy it saved on the previous build. The app prints v1 again, this time with kspKotlin visibly running in the build log.

Neither result is a KSP bug. KSP tracked every source file exactly as promised, and schema.txt was never one of them.

The fix has to come from Gradle's side, because Gradle decides whether the task runs. Instead of a plain string, pass KSP a CommandLineArgumentProvider: a small class whose annotated properties Gradle checks like any other task input, and whose asArguments() produces the option the processor reads. Mark the file with @InputFile, and Gradle fingerprints the file's contents, not just its path:

class SchemaArgProvider(
    @get:InputFile
    @get:PathSensitive(PathSensitivity.RELATIVE)
    val schema: File,
) : CommandLineArgumentProvider {
    override fun asArguments() = listOf("schema.path=${schema.absolutePath}")
}

ksp {
    arg(SchemaArgProvider(file("schema.txt")))
}

Now an edit to schema.txt reruns the task, and Gradle's info output shows how:

Task ':app:kspKotlin' is not up-to-date because:
  Input property 'commandLineArgumentProviders.$0.schema' file .../app/schema.txt has changed.
The input changes require a full rebuild for incremental task ':app:kspKotlin'.

The output is fresh, but notice the last line. Gradle can tell a task which source files changed, but only for the inputs the task marks as incremental. A change to any other input, this file included, makes Gradle run the task from scratch. The KSP Gradle plugin then throws away KSP's records of which output came from which file, and every source file in the module is processed again. You get the right value, but every schema edit now costs a full reprocess, which is the work KSP's incremental model exists to avoid.

Room made the same trade. Its DAOs meet all three conditions, but it also writes schema files during the build and reads them back to generate migrations automatically, so those files are inputs too. Its documentation says that if you pass room.schemaLocation as a processor option, you "must use Gradle's CommandLineArgumentProvider" for correct incremental and cached builds, and the Room Gradle plugin, added in Room 2.6.0, sets that up for you.

RevenueCat's input isn't a file at all. Check it against the three conditions: the input isn't declared in your code, the output is built from JSON and needs nothing only the compiler knows, and it should change when the dashboard changes, not when your source files do. None of them holds.

The network adds a practical problem on top. A processor that called the RevenueCat API would run only when the KSP task runs, which brings back the stale value from the first experiment. With Gradle's build cache turned on, even that run could be skipped. The KSP task is cacheable, so if an earlier build stored outputs for the same inputs, Gradle reuses them without running the task, and the API is never called.

The download needs its own rule for when to call the API again, one that runs whether or not your source files changed. The clearest home for that rule is a Gradle task of its own, whichever tool generates the code. Once that task has saved the schema to a file, a processor would only add cost: the file would have to be declared as a KSP input as well, and every schema change would reprocess the whole module. That's the design the plugin uses: no processor, and code generation in a Gradle task as well.

Two Gradle tasks: Separating the network from the generator

The plugin splits the job along the line between what Gradle can fingerprint and what it can't. In the plugin's source, RevenueCatCodeGenPlugin.apply(), the function Gradle calls when a build applies the plugin, registers both tasks. The first one owns the network. In its registration, four set calls pass along values from the revenuecat { } block in your build script. The one to watch is the fifth: cacheDir is a fixed directory under build/ that the plugin picks itself:

val cacheDir = project.layout.buildDirectory.dir("revenuecat/cache")
val outputDir = project.layout.buildDirectory.dir("generated/revenuecat/kotlin")

val fetchTask: TaskProvider<FetchSchemaTask> = project.tasks.register(
    "rcFetchSchema",
    FetchSchemaTask::class.java,
) { task ->
    task.apiKey.set(extension.apiKey)
    task.projectId.set(extension.projectId)
    task.cacheTtlMinutes.set(extension.cacheTtlMinutes)
    task.offlineMode.set(extension.offlineMode)
    task.cacheDir.set(cacheDir)
}

The second task owns the code and receives the same cacheDir. Here is its registration, with the generation flags left out:

val generateTask: TaskProvider<GenerateCodeTask> = project.tasks.register(
    "rcGenerateCode",
    GenerateCodeTask::class.java,
) { task ->
    task.packageName.set(extension.packageName)
    task.namingStyle.set(extension.namingStyle)
    task.cacheDir.set(cacheDir)
    task.outputDir.set(outputDir)
    task.dependsOn(fetchTask)
}

Notice the handoff: cacheDir is the output of rcFetchSchema and the input of rcGenerateCode. A single JSON file in that directory, revenuecat-schema.json, is the only thing the generator ever reads. Everything about the network stays on one side of that file, and everything about Kotlin stays on the other.

The fetch task: An input Gradle can't fingerprint

The real input of rcFetchSchema is the current state of your dashboard, and Gradle has no way to fingerprint that: it lives on RevenueCat's servers, and nothing on your disk changes when someone renames an entitlement. So FetchSchemaTask opts out of Gradle's check in its init block:

init {
    group = "revenuecat"
    description = "Fetches entitlement and offering schema from RevenueCat API v2"
    // Always evaluate the task action so the TTL check inside runs
    outputs.upToDateWhen { false }
}

With upToDateWhen { false }, Gradle runs the task's code on every build, and the code makes the decision itself:

val cache = SchemaCache(cacheDir.get().asFile)

if (cache.isValid(cacheTtlMinutes.get())) {
    logger.lifecycle("RevenueCat schema cache is still valid, skipping fetch.")
    return
}

isValid reads the timestamp stored inside the cached JSON and compares its age with cacheTtlMinutes, which defaults to 30. Only a missing, unreadable, or expired cache triggers the API calls. The TTL (time to live) is a policy for an input that never announces its changes: the plugin can't know when your dashboard changed, so it caps how long a successful fetch is reused. A failed fetch is a different case. The default, USE_CACHE_OR_SKIP, logs a warning and builds from the old cache, or skips code generation if there's no cache yet. Setting offlineMode to FAIL turns the failed fetch into a failed build.

The generate task: A pure function of the cache

rcGenerateCode sits on the other side of the line. Its output depends only on the cached JSON and a few settings, and it declares all of them. Here are its properties, minus the package name and the four generation flags, which are declared like namingStyle:

// Note: @CacheableTask is intentionally omitted. The cache JSON includes a timestamp that
// changes on every fresh fetch, so the Gradle build cache would never produce a hit.
public abstract class GenerateCodeTask : DefaultTask() {

    @get:Input
    public abstract val namingStyle: Property<NamingStyle>

    @get:InputDirectory
    @get:PathSensitive(PathSensitivity.RELATIVE)
    public abstract val cacheDir: DirectoryProperty

    @get:OutputDirectory
    public abstract val outputDir: DirectoryProperty
}

Because every input is declared, Gradle's ordinary up to date check decides when to skip it. On a second build with nothing changed, exactly one task does any work:

> Task :app:rcFetchSchema
RevenueCat schema cache is still valid, skipping fetch.

> Task :app:rcGenerateCode UP-TO-DATE
...
> Task :app:kspDebugKotlin UP-TO-DATE
> Task :app:compileDebugKotlin UP-TO-DATE

rcFetchSchema runs because it has to, finds a valid cache, and returns without touching the JSON file. The file's fingerprint matches the previous build, so rcGenerateCode is skipped, and everything downstream stays up to date. When a fetch writes a new file, the fingerprint changes and the generator runs again.

The comment above the class is about Gradle's build cache, which reuses outputs that any build, on any machine, stored for the same inputs. The timestamp inside the JSON changes on every fresh fetch, even when the schema doesn't, so two machines or two CI runs that each fetch on their own never have identical inputs. Marking the task cacheable would mostly store outputs that no other build could reuse.

Inside the task, generation isn't incremental at all: it deletes the output directory and writes every file again. That's the difference in granularity from KSP. A KSP processor tracks each output file so it can regenerate one out of hundreds, while this task treats its whole output as one unit and lets Gradle decide whether to rebuild it.

The generator: The same KotlinPoet, a different destination

The code that actually writes Kotlin will look familiar from the processor earlier in this article. Looking at EntitlementsGenerator:

private fun generateIdObject(entitlements: List<EntitlementSchema>, outputDir: File) {
    val objectBuilder = TypeSpec.objectBuilder("RCEntitlementId")
        .addKdoc("Auto-generated entitlement ID constants from RevenueCat dashboard.")

    for (entitlement in entitlements) {
        val constName = NamingConfig.toConstant(entitlement.lookupKey)
        objectBuilder.addProperty(
            PropertySpec.builder(constName, String::class)
                .addModifiers(KModifier.CONST)
                .initializer("%S", entitlement.lookupKey)
                .addKdoc("%L", entitlement.displayName)
                .build(),
        )
    }

    FileSpec.builder(packageName, "RCEntitlementId")
        .addType(objectBuilder.build())
        .build()
        .writeTo(outputDir)
}

Put it next to that processor and the builders are the same. The differences are where the data comes from and where the file goes. The input is a List<EntitlementSchema> parsed from the cached JSON instead of a KSClassDeclaration, and the last call writes to a plain directory instead of to KSP's CodeGenerator. There's no addOriginatingKSFile call, because no source file exists for the output to originate from.

Where the plugin meets KSP: Generated sources are KSP inputs

Generated code only helps if it's compiled with your app, so the plugin adds its output directory to the main Kotlin source set. The registration that takes effect is equivalent to:

android.sourceSets.getByName("main").kotlin.srcDir(outputDir)

Here outputDir is that same directory, resolved to a plain java.io.File: just a path, with no record of which task writes to it. That detail matters in a moment. Every task that reads the main source set now reads build/generated/revenuecat/kotlin.

That includes compileDebugKotlin, and it also includes kspDebugKotlin, because KSP processes the same sources the compiler compiles. In a test app with a small processor that logs every file getAllFiles() returns, KSP listed each generated RevenueCat file next to the app's own source. The plugin has no processor, yet KSP still reads everything it generates, and that's where the build can break.

The plugin's first prototype made only the compile tasks wait for rcGenerateCode. Take the clause that matches ksp task names out of the shipped plugin's wiring, shown below, and the test app fails on Gradle 9.8.1 with AGP 9.4.1 and KSP 2.3.12:

* What went wrong:
A problem was found with the configuration of task ':app:kspDebugKotlin' (type 'KspAATask').
Property has implicit dependency
  Gradle detected a problem with the following location: '.../app/build/generated/revenuecat/kotlin'
    Task ':app:kspDebugKotlin' uses this output of task ':app:rcGenerateCode' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed

Gradle isn't saying the tasks ran in the wrong order. In all six failing runs, across AGP 8 and 9, with KSP 2.3.11 and 2.3.12, rcGenerateCode had already finished before kspDebugKotlin started. It's saying that nothing guarantees that order. Gradle can see that kspDebugKotlin reads files from a directory that rcGenerateCode declares as its output, but no rule says KSP must wait for it. A java.io.File can't supply that rule, because it's only a path. Without a rule, a later build could run the two tasks in either order, so since Gradle 8.0 this fails the build instead of printing a warning.

Failing is the better outcome here. With the same broken wiring, running only :app:kspDebugKotlin succeeds silently: rcGenerateCode isn't part of that build at all, so nothing gets flagged, and KSP processes an empty or stale directory.

This is the one place KSP appears in the plugin's source. The shipped plugin declares the rule by task name: any task whose name looks like a Kotlin compile, KSP, or KAPT task runs after rcGenerateCode.

private fun configureKotlinTaskDependencies(
    project: Project,
    generateTask: TaskProvider<GenerateCodeTask>,
) {
    project.tasks.configureEach { task ->
        val isKotlinTask = task.name.endsWith("Kotlin") && (
            task.name.startsWith("compile") ||
                task.name.startsWith("ksp") ||
                task.name.startsWith("kapt")
            )
        if (isKotlinTask) {
            task.dependsOn(generateTask)
        }
    }
}

configureEach applies the rule to every task in the project, including the ksp and kapt tasks whenever those plugins register them, so the rule holds for every Android variant without the plugin knowing which processors you use. Matching by name covers the consumers the plugin knows about. A new consumer with a different naming scheme would need a new clause.

The Variant API alternative: Registering the directory with its producer

The alternative is to never hand Gradle a bare File. AGP's Variant API, the androidComponents hooks that let a plugin adjust each build variant, can take the task that produces a directory instead of just its path. This isn't what the plugin ships today, but in the same test app, this wiring replaced both the source set call and the name matching:

val androidComponents = project.extensions.getByType(AndroidComponentsExtension::class.java)
androidComponents.onVariants(androidComponents.selector().all()) { variant: Variant ->
    variant.sources.java?.addGeneratedSourceDirectory(generateTask, GenerateCodeTask::outputDir)
}

addGeneratedSourceDirectory receives the task and the property that holds its output, so Gradle works out the order by itself: every task that reads the variant's sources, the compiler and KSP included, now runs after rcGenerateCode. Without name matching or any dependsOn on the Kotlin and KSP tasks, the test app built on both AGP 9.4.1 and AGP 8.13.2, with rcGenerateCode running first and KSP seeing every generated file.

The trade off is a closer coupling to how AGP behaves across versions. The registration goes through sources.java, even though the files are Kotlin. On AGP 8, Kotlin support comes from the separate org.jetbrains.kotlin.android plugin, and that plugin and KSP pick up a variant's generated directories only from sources.java. In the test app, a directory added to sources.kotlin was silently ignored, and the build failed with unresolved references to the generated code.

The call itself has also changed between releases. Before AGP 8.12, addGeneratedSourceDirectory overwrote the output location a task had set. Since 8.12, it only supplies a default. The test app covered only AGP 8.13.2 and 9.4.1, and SQLDelight and Apollo Kotlin both carry version checks for these differences. None of this affects apps that use the plugin today, because it never calls addGeneratedSourceDirectory. It registers its directory through the main source set and orders the compile, KSP, and KAPT tasks by name.

Conclusion

Before you write a generator, find its source of truth and ask who notices when it changes. If the compiler parses it, a KSP processor gives you incremental builds without any tracking code of your own. If it lives anywhere else, such as a schema file or a .proto, make it a declared input of a Gradle task, because the build only sees what you declare. Then make sure every task that reads the generated sources, KSP's included, knows which task produces them.

KSP asks one question: which of your source files changed? A Gradle task asks another: which of my declared inputs changed? A dashboard on a server can answer neither, so the plugin turns it into a file that can. Choosing where code generation runs is choosing which of those two questions your input can answer.

iPhone Duo gives your paywall two very different spaces to work with. Closed, vertical space is tight. Open, a layout designed for a narrow phone can leave text and purchase buttons stretching across a wide display.

With RevenueCat, you can improve both experiences by controlling component widths, keeping fixed footers compact, and spreading longer benefit lists across multiple screens. Start with your existing paywall and work through these adjustments.

Give your content a maximum width

A full-width purchase button can look right on a narrow screen and oversized on an open Duo. The same goes for a stack of headlines, benefits, and subscription options.

RevenueCat’s new min/max sizing controls let you put limits on components whose width or height is set to Fill. They use the available space until they reach the limit you’ve set.

BEFORE:

AFTER:

For a starting point:

These are starting values to adjust for your design. A short headline, a detailed benefit list, and an image-heavy paywall may need different widths.

The limits apply wherever the paywall appears. You don’t need to target the Duo specifically: content can fill a narrower space and stop growing in a wider one.

Min/max sizing works with Fill, rather than Fit or Fixed. On iOS, it requires RevenueCat SDK 5.93.0 or later. Older SDKs ignore the limits.

Make room on the closed screen

On the closed Duo, pay attention to how much space your fixed footer occupies.

A footer containing plan choices, a purchase button, supporting copy, and generous spacing can leave little room for the content above it. Review the whole screen together: can someone understand the offer, read the price, and reach the controls comfortably?

Start by tightening unnecessary spacing and shortening repetitive copy. Keep pricing, subscription details, and purchase controls clear.

If the screen still feels crowded, consider changing how much you ask it to communicate at once.

Give your benefits their own screen

A multi-step paywall is worth trying when your current design packs several benefits into one screen.

You might introduce your benefits on one screen, and then present the subscription offer on the next screen. RevenueCat lets you build a multi-step paywall, design each screen separately, and add buttons in the editor to move between screens. Customers choose a subscription plan and purchase on the final screen.

The Paywall AI Editor makes it even easier to turn a single-screen paywall into a multi-step flow. Add a blank screen before your existing paywall, then ask the AI Editor to move your benefits onto it. It will match your paywall’s branding, generate a relevant headline, and move the benefit copy to the new screen, leaving more room for the offer on the final screen.

Review the generated copy, navigation, and final purchase screen before publishing. Adding steps changes the experience, so treat it as a design to test with your audience.

Let the Paywall AI Editor handle the adjustments

You can also ask the Paywall AI Editor to optimize your existing paywall for iPhone Duo. It can make the layout edits for you, helping your content fit comfortably on the outer display and use the extra room on the inner display.

Start with a simple request:

Optimize this paywall for iPhone Duo so it looks good on both the open and closed displays.

Review the changes, then preview your paywall in both configurations. You can keep refining it through follow-up prompts, whether you want a more compact footer, narrower content, or more room for your benefits.

Keep your close button in the right place

If your paywall includes a close button so customers can dismiss it without subscribing, check its placement on iPhone Duo. Depending on the display, orientation, and how your app presents the paywall, iOS can move navigation controls to the side. A close button inside your paywall won’t automatically move with them.

To let iOS handle its placement, select the button in the RevenueCat Paywall Editor and enable Use system navigation in the button’s properties. This replaces the close button with a native iOS close control.

If you have a multi-step paywall, review the close and back buttons on each screen and enable the setting where appropriate. Then preview and test the flow on both displays.

Check the whole experience

Once you’ve made the adjustments, test your paywall closed, open, and rotated, using the same presentation your app uses.

Look for:

• Readable content: Headlines and benefit copy wrap cleanly, with no clipping.
• Balanced widths: Buttons and text remain comfortable to read on the open display.
• Usable footers: Fixed content leaves enough room for the rest of the paywall.
• Accessible controls: Close, back, continue, and purchase controls remain visible and usable.
• Complete navigation: Every step works, and customers can reach the final offer.

Check the SDK version shipped in your app, too. Multi-step paywalls require iOS SDK 5.83.0 or later; older versions display only the final screen. Using min/max sizing alongside them requires 5.93.0 or later.

See the SDK requirements for other frameworks.

Start with the paywall you already have

With iPhone Duo arriving today, it’s a good time to give your paywalls another look. Keep content at a comfortable width, make room above your footer, and consider multiple screens when your benefits need more space.

You can make these adjustments in RevenueCat today, with the Paywall AI Editor helping you rework the layout. Start with your existing paywall, check it folded and open, and make sure your offer is easy to read and act on in both.

Google's documentation covers every piece of this, spread across dozens of pages that you have to connect yourself. RevenueCat has published two free handbooks that each put the whole lifecycle in one place: one for building directly on the Play Billing Library, and one for building on the RevenueCat Android SDK.

In this article, you'll explore what each handbook covers, how the two line up chapter by chapter, which reading path fits your situation, how the companion skills bring the same material into your coding agent, and what has shipped since the handbooks were written.

The Google Play Billing Handbook: Building it yourself

The Google Play Billing Handbook is written for Android developers who know Kotlin, Activities, ViewModels, and Gradle but know Google Play Billing only partly or not at all. It takes you from zero billing knowledge to a production ready integration.

The 18 chapters are organized in seven parts that build on each other:

1. Foundations (chapters 1 and 2): how Google Play's billing system fits together, and how to set up your environment.
2. Products (chapters 3 and 4): one time products and subscriptions.
3. Client side integration (chapters 5 to 8): the Play Billing Library, the purchase flow, plan changes, and error handling.
4. Server side integration (chapters 9 and 10): purchase verification with the Google Play Developer API, and RTDN.
5. The subscription lifecycle (chapters 11 to 14): the subscription state machine, payment recovery, cancellations, pauses, winback, and price changes.
6. Production readiness (chapters 15 to 17): security and fraud prevention, testing, and catalog management at scale.
7. Beyond standard billing (chapter 18): alternative billing and external offers.

Five appendices, A to E, collect the material you look up rather than read: a complete RTDN reference table, a BillingResult response code reference, a Google Play Developer API quick reference, a migration guide from PBL 7 to PBL 8, and a pull out subscription state diagram.

The code is Kotlin on both the client and the server, so you read the whole integration in one language, and the client code uses the coroutine extensions from the billing-ktx artifact. The handbook targets Play Billing Library 8, specifically versions 8.0.0 through 8.3.0, and the last section of this article covers what has shipped since. You can read every chapter on the web or download the whole handbook as a 287 page PDF, and neither requires signing up.

The RevenueCat Android SDK Handbook: The same problems, solved with the SDK

The RevenueCat Android SDK Handbook is for developers who have read the first handbook or have equivalent experience with Google Play Billing, and it solves the same problems with the SDK. Because it assumes that background, it uses concepts like base plans, offers, replacement modes, and purchase tokens without explaining them in full again. Its structure mirrors the first handbook chapter for chapter. Where the SDK simplifies an implementation, the chapter shows the code. Where the SDK removes a problem entirely, the chapter explains what RevenueCat handles on your behalf and what, if anything, you still need to do.

Two appendices close the handbook. Appendix A is a quick reference for the SDK's API. Appendix B compares what RevenueCat replaces on the client and on the server, and lists what remains your responsibility.

The code uses the SDK's coroutine extensions, such as awaitOfferings() and awaitPurchase(), and targets RevenueCat Android SDK 9.x, which wraps Play Billing Library 8.x. The handbook is available on the web and as a free 63 page PDF, whose cover calls it The RevenueCat Handbook.

Reading the handbooks side by side

Because the chapter numbers match, you can open the same chapter in both handbooks and see how the work changes. A few pairs show the pattern:

Not all of the gap between 287 and 63 pages, both at A4 size, is work that the SDK takes over. The first handbook has 38 pages of appendices against 7, explains concepts the second one assumes, and spends 19 pages on Google's alternative billing programs, which the second covers in one page because the SDK had no dedicated APIs for them when the handbook was written. Where the SDK does take over the work, the gap is real: the chapters on integrating the library, the backend, notifications, and subscription states run 60 pages in the first handbook and 11 in the second.

Choosing a reading path

The Google Play Billing Handbook's preface suggests two paths depending on where you start, and a third one fits if you're evaluating RevenueCat:

• Building a new integration from scratch: read the first four parts (chapters 1 to 10) in order, then the subscription lifecycle chapters as you prepare for production, and the production readiness chapters before launch.
• Upgrading an existing integration from PBL 7: start with Appendix D, the PBL 7 to PBL 8 migration guide, then read the chapters that cover your knowledge gaps.
• Deciding whether to use RevenueCat: start with Appendix B of the RevenueCat handbook, then read the chapter pairs for the parts of the lifecycle that matter most to your app.

The handbooks as agent skills

A coding agent doesn't need a 287 page book to handle one failed renewal. It works better with short, task oriented instructions that it loads only when your request calls for them. Play Billing Skills turns both handbooks into 45 agent skills, split into two collections that answer the same questions at two layers. The google-play/ collection has 25 skills for the raw Play Billing Library, the Google Play Developer API, and RTDN, derived from the Google Play Billing Handbook. The revenuecat/ collection has 20 skills for the RevenueCat Android SDK, RevenueCat's REST API, and webhooks, derived from the RevenueCat Android SDK Handbook.

Most skills distill one chapter or appendix of their source handbook into a numbered workflow, and the YAML frontmatter at the top of every skill records where it came from. In the repository, the webhooks skill starts like this:

name: webhooks
description: Use this skill when consuming RevenueCat webhooks on your backend. Covers the normalized event schema, the full event type list, idempotency via the event id field, and the correct handling for CANCELLATION versus EXPIRATION versus RENEWAL.
license: Apache-2.0; see LICENSE
metadata:
  author: RevenueCat
  source: revenuecat-handbook chapter 10
  keywords:
  - android
  - revenuecat
  - webhooks
  - event-types
  - idempotency
  - cancellation
  - expiration

The description is what the agent matches your request against, and the source field ties the skill back to the chapter you can read yourself.

Installing the skills

The revenuecat/ collection also ships as the revenuecat-play-billing plugin in the RevenueCat AI Toolkit marketplace. In Claude Code, add the marketplace, then install the plugin next to the main revenuecat plugin, which connects the agent to your RevenueCat project through the MCP server:

claude plugin marketplace add RevenueCat/ai-toolkit
claude plugin install revenuecat@RevenueCat
claude plugin install revenuecat-play-billing@RevenueCat

The plugin is also available in Cursor, in Codex after codex plugin marketplace add RevenueCat/ai-toolkit and codex plugin add revenuecat-play-billing@RevenueCat, and in VS Code, where plugin marketplaces are still experimental. Gemini CLI installs one extension per GitHub repository and only picks up the main plugin, so on Gemini CLI, install the skills from the Play Billing Skills repository instead.

The google-play/ collection isn't in the plugin. To install both collections, clone the repository and run its install script:

git clone https://github.com/RevenueCat/play-billing-skills.git ~/play-billing-skills
~/play-billing-skills/scripts/install-skills.sh

he script links every skill into ~/.claude/skills and prefixes each link with gp- or rc-, so both collections can be installed side by side even where they share a name, such as setup and purchase-flow. If you already installed the plugin, run the script with --only google-play so that the RevenueCat skills aren't installed twice. The repository's README covers the script's other options, such as installing into a single project, and how to point Android Studio's agent mode, Gemini CLI, and Cursor at the skill files.

Once the skills are installed, you describe the task in plain language:

"Handle RevenueCat webhooks on our backend. Ignore duplicate deliveries, and don't revoke access on a cancellation until the subscription actually expires."

Claude Code picks skills by matching your request against each skill's description, so this request can load the webhooks skill shown above, installed as rc-webhooks. The skill has the agent deduplicate events by event.id, treat CANCELLATION as a subscriber turning off auto renew rather than as an access change, and revoke access on EXPIRATION.

Beyond the handbooks: Play Billing Library 9 and SDK 10

Both handbooks target Play Billing Library 8, which has been the minimum for new apps and app updates since August 31, 2026, with an extension available on request until November 1, 2026. Since the handbooks were written, Google has shipped PBL 9.0.0 (May 19, 2026) and 9.1.0 (June 18, 2026).

For Play Billing Library 9.0, read Google I/O 2026: What's New in Google Play and Play Billing Library 9.0. It walks through the four code level changes in 9.0.0 and the billing changes aimed at involuntary churn, so it picks up where the Google Play Billing Handbook stops. Version 9.1.0 added the Billing Choice APIs, which the complete guide to Google Play's Billing Choice covers. If you're still on v7, the v7 to v8 migration guide pairs with Appendix D.

The skills have already moved past the handbooks on library versions. The google-play/ collection targets Play Billing Library 9 and adds two migration skills for it: one for apps on 8.x, and one that takes a 7.x integration to 9.x in two stages, through the v8 changes first.

One lifecycle figure is out of date in both the Google Play Billing Handbook and the google-play/ skills, which describe account hold as lasting up to 30 days. Since December 1, 2025, Google sets the account hold length automatically by default, to 60 days minus any grace period, and you can still choose a custom length in the Play Console.

On the RevenueCat side, the Android SDK is on 10.x today and still wraps Play Billing Library 8.3.0, so the handbook's PBL 8 basis matches the SDK's billing layer. The handbook's main APIs are still in the SDK, with one deprecation: 10.3.0 introduced StoreReplacementMode and replacementMode(), which replace the GoogleReplacementMode enum and the googleReplacementMode() builder method that chapter 7 uses.

Conclusion

Keep the Google Play Billing Handbook close when you need to understand what Google Play is actually doing, such as why a subscription is on hold or what happens to the purchase token after a plan change. Its appendices work best as the reference material they were written to be.

Reach for the RevenueCat handbook when you're evaluating RevenueCat or integrating it, and read Appendix B before you decide what to build yourself. If you work with a coding agent, install the skills so that its billing answers start from these handbooks instead of from whatever version of the library it happened to be trained on.

Reading the same chapter in both handbooks is a direct way to see what an SDK takes on for you. The subscription lifecycle doesn't get any simpler when you change layers. What changes is which parts of it live in your code.

This year, the Shippies got a night of their own. And because we never do things by halves, we held it on a real ship: the Intrepid Museum aircraft carrier in New York. Surrounded by great company (and a retired space shuttle), we had finalists, founders, and family gathered in one room to celebrate remarkable apps and the thinking behind them.

Every winner took home a personalized Golden Shippy trophy, and a spot on a Times Square billboard during New York App Week. Plus bragging rights, of course.

Here’s our seven winners, and the why behind their wins.

Full Steam Ahead: Runna

This award celebrates subscription growth excellence: the app that found the smartest routes to growth, not just the most obvious ones.

Runna has built a growth engine that reaches well beyond the App Store: web subscriptions, onboarding, and win-backs. Since joining Strava in 2025, Runna has been sold as part of a combined annual subscription. That gives Runna a new route to customers and puts its training plans right where runners already track and share their activity.

Why it won:

• Distribution where users already are: the Strava + Runna bundle puts Runna inside runners’ existing routine and is available directly through Strava’s app and website
• Growth across the funnel: web subscriptions, onboarding, and cancellation recovery all pull their weight
• A place on the start line: an official training partner for the TCS New York City Marathon and the Boston Marathon, Runna reaches potential users at their most committed moment
• Thinking beyond the paywall: growth comes from partnerships and lifecycle work, not just price tests

Runna is a strong reminder that your biggest growth lever might not live inside your app at all.

Treasure Chest: Audiomack

Treasure Chest recognizes the app with the most creative monetization: the most inventive ways to turn value into revenue.

Audiomack reaches more than 50 million listeners a month, with a truly global audience. Audiomack recognizes that a global audience varies widely in how willing and able people are to pay. So rather than forcing one model onto every listener in every market, it combines ads, subscriptions, and direct artist support.

Why it won:

• Built for global reality: monetization reflects real differences in willingness and ability to pay, like offering day/week/month passes to Audiomack+ in Nigeria
• Several ways in: hybrid monetization offers value to (and from) all types of listener — free listening with ads, a subscription priced for local wallets, and direct ways for fans to support the artists they love
• Fans and creators both win: direct artist support ties revenue to the community at the heart of the app, via premium plans allowing fans to buy badges and hear music before release
• Paying the way people actually pay: partnerships with Flutterwave and MTN add bank transfers, local cards, and mobile money

Audiomack shows that creative monetization often means offering more ways to pay, rather than trying to force different users through the same funnel.

Clear Waters: Structured

This category is about making the complicated simple. The award goes to an app that takes something messy, and makes it feel effortless for the user.

Structured turns a scattered day into one clear picture. Tasks, to-dos, and calendar events all sit on a single visual timeline, so you can see your whole day and what’s coming next. There’s no juggling between apps and no wading through detail.

Why it won:

• One timeline for everything: tasks, to-dos, and appointments live together in one visual timeline at the core of the app
• Works with the tools you already use: Structured syncs with your calendar and Apple Reminders, and imported to-dos land straight in your inbox or timeline
• Guardrails against overplanning: the optional Energy Monitor warns you when you schedule more than you can handle
• Somewhere for loose thoughts: the inbox holds ideas and tasks until you’re ready to schedule them, enabling you to capture thoughts without becoming overwhelmed
• Recognized by Apple: App Store Editors’ Choice, a 2025 finalist for iPad App of the Year, and a 2026 Apple Design Awards finalist for Inclusivity

Structured is proof that there’s a surprising amount of complexity behind design that appears simple.

Level Up: Reading.com

Level Up is about the best learning experience: celebrating the app that helps people learn in a way that actually sticks.

Reading.com gives parents a structured way to teach their children to read, no teaching background or extra resources needed. The lessons are built to support two people at once: the child who's learning, and the parent who's helping them. Lessons are fully scripted and built on phonics and the Science of Reading.

Why it won:

• Designed for two learners: lessons support both the child and the parent in their respective roles
• No training required: simple UI and fully scripted lessons removes any guesswork, meaning any parent can step into the teacher’s role with confidence
• Grounded in science: lessons use explicit phonics instruction that follows the Science of Reading
• A clear path: the experience follows how learning actually happens, with step-by-step lessons building letter recognition towards different reading levels
• Practice that reinforces every lesson: interactive, decodable storybooks come with videos, games, and printables

The best learning products are designed around the learner, and Reading.com goes one step further by designing around the whole household.

Beyond the Chatbox: Suno

This award goes to the app that offers the best AI experience; using AI to create something more than a text box and a reply.

Suno lets anyone turn an idea into a song, then keep shaping it until it sounds right. The model is impressive, but the real magic is the creative workflow built around it. An editor, studio tools, and personalization keep users in the creative seat long after the first take.

Why it won:

• A workflow, not a one-off: the Song Editor lets users rearrange, extend, and replace sections and rewrite lyrics — continuing to edit and develop songs as long as they like
• Creative control stays with the user: Covers, Personas, and Remaster let people explore new takes on a song, while Stems split a track into as many as 12 editable parts
• Personal by design: Voices, Custom Models, and My Taste shape what Suno creates around each user’s personality and preferences, creating a truly unique experience for every user

Suno shows what an AI app looks like when the prompt is simply the creative jumping point, rather than the entire product.

Worth Coming Back For: Fitbod

Recognizing the app that has the best ongoing value, this category is about earning a subscription month after month.

Fitbod builds every workout around where you are right now. It tracks how recovered each muscle group is, learns from the sets you log, and adjusts as you get stronger. Your training keeps pace with your progress, and the app changes as your needs do, which gives people a strong reason to stay subscribed.

Why it won:

• Progress you can see: Strength Score and Estimated Strength show how you’re improving over time and give users motivation to stay long-term
• Workouts that respond to your body: every muscle group gets a recovery score, and Fitbod builds each session around the freshest muscles, meaning the lessons never get stale
• Learns from you: Fitbod’s adaptive AI learns from your edits to its recommendations, alongside your goals, equipment, and experience

Fitbod is a textbook case of recurring value supporting recurring revenue.

Small Crew, Big Ship: CardPointers

This award celebrates the indie developer proving that you don't need a big team to build an exceptional app business.

CardPointers is the work of independent developer Emmanuel Crouvisier, who built a focused product around one problem: helping people get more value from the credit cards they already have. It started in 2019 as an evenings-and-weekends project. Within a year, it was earning him more than his day job.

Why it won:

• A sharp focus: it solves one specific problem, and solves it well
• Takes on mental load: CardPointers tells you which card to use for each purchase, so you get the most from category bonuses without memorizing them
• Everywhere you spend: works across iPhone, iPad, Mac, Apple Watch, CarPlay, and Android, plus browser extensions
• Smart business decisions: web checkout through Stripe saves Emmanuel as much as 27% in fees, and staying in Apple’s Small Business Program saves another 15% on in-app purchases

CardPointers is proof that with a clear problem and a lot of focus, a small crew can sail a very big ship.

Until next year…

The 2026 Shippies was a memorable night, not only celebrating our seven Shippies winners, but also recognizing the winners of Shipaton 2026, RevenueCat’s global mobile hackathon. Check out the list of all 58 Shipaton winners right here.

To the finalists, winners, and everyone who shipped something this year: congratulations! Like any voyage, it's not always smooth sailing, but shipping anything is a huge accomplishment. We’re excited to see what you build next.

So keep shipping — we'll see you at the Shippies ’27. Maybe next time, it'll be your app up on that billboard.

From all those submissions, our judges ended up choosing 58 winning apps that showcase the best apps in their categories. These decisions were not easy, and were made harder by the sheer amount of apps that made it to the final judging stage.

And now it's time to reveal the winners of Shipaton 2026:

Grand Prize Winner

The Grand Prize was about what happened after an app shipped. We looked for developers who kept improving the product, found their first users, and gave people a reason to stay. Downloads, retention, and revenue helped tell that story, alongside the decisions that moved the app forward during Shipaton.

1st Place: Mio

When we looked at the revenue and growth across all the apps submitted to Shipaton, Mio was a clear winner. Mio’s traction is even more impressive, when you take into account that it competes in a very tough category of habit trackers.

Mio is a cozy, self-care and habit tracker, where building habits earns you coins, levels, new companions and collectibles. Gamification is a big part of the app, with the user leveling up a pixel companion as they build their own habits. On top of the gamification, Mio also has social features, allowing you to add friends and create groups.

App Store Google Play

#BuildInPublic

Building in public means inviting people into the process while there's still time for their feedback to change things. For this award, we looked at how developers shared their progress, what they learned from the conversations, and how those lessons made their way into the app.

1st Place: Boop

Boop turns the cats and dogs you meet on walk into a collection: point your phone at a pet, identify its breed, and save it as a sticker in your book. Taiwo took the idea out into the world through his 100 Boops challenge, handing owners printed portraits and letting their feedback shape the app. A very different take on building in public, but one that worked.

The judges particularly liked the effort Taiwo put into building in public, describing it as unmatched.

App Store

2nd Place: Scroll Survival

Putting your phone down feels a little more rewarding when there's a village growing while you're away. Scroll Survival turns focus sessions into buildings, villagers, and unfolding stories. Eric Vargas shared the build through daily updates and a public roadmap, with community feedback becoming dark mode, widgets, and even a story-based consequence for ending a session early.

The judges highlighted how thoroughly Eric documented the public build, with a clear record of the journey and its key moments.

App Store

Google Play

3rd Place: FeedbackThread

Anyone juggling several apps knows that customer feedback rarely arrives in one tidy place. Aivars Meijers built FeedbackThread to bring reviews, bug reports, and feature requests into a single queue, with public boards showing what's happening next. He also opened up the build through livestreams, sharing the decisions and detours between an early prototype and an App Store release.

The judges appreciated how the livestreams and social posts made the whole development journey easy to follow.

App Store

Best Game Award

For the Best Game Award, we looked for games that made us want to play another round. That meant engaging mechanics, a distinctive world, and care in the details, from controls to sound and animation. We also considered how paid features fit into the experience of playing.

1st Place: Nitelore

Nitelore brings the neon tracks and hovering vehicles of classic anti-gravity racers to the phone.

There are ghost time trials for chasing your own best run, combat races for causing trouble, and online multiplayer when you want company. Its tracks, vehicles, and sounds are generated in code, giving the game a distinctive retro-futurist world to race through.

Free tracks give players a way into the game before paid content unlocks, with daily and weekly challenges adding reasons to return for another race.

The judges singled out the game's art style, effects, and haptics.

App Store

Google Play

2nd Place: Keepsweeper

Michael Flarup took the familiar logic of Minesweeper and hid a small fantasy kingdom underneath it. In Keepsweeper, uncovering a tile might reveal resources, a threat, or another chance to grow your economy. Farms benefit from windmills, recruits need blacksmiths, and the whole thing lives inside a Windows 95-style window. It's a lovely setting for a surprisingly involved strategy game.

App Store

Google Play

3rd Place: Hearsay

Every family has a story that nobody remembers quite the same way. Hearsay puts that to good use: one person answers a personal question truthfully, everyone else invents a lie, and the group tries to spot the real answer. There's a separate vote for the funniest response, too, so a wildly implausible story can still earn its place at the table.

App Store

RevenueCat Peace Prize

The RevenueCat Peace Prize celebrates apps built to make life a little better for someone. That might mean helping people understand an invisible difference, make sense of their health, or feel closer to one another. We looked for a clear understanding of the people behind the problem and a thoughtful way to help them.

1st Place: See as Me: Colorblind

Javier Jiménez discovered he had protanopia after painting a figure green as a child.

See as Me gives him a way to answer the question that followed: what does the world look like to you? Its split-screen camera shows different forms and degrees of color blindness side by side, while a shareable link lets someone else see the comparison without installing the app.

Javier describes the app as free, with no ads or accounts. That keeps the focus on helping classmates, colleagues, and friends understand a difference they might otherwise never see.

The judges highlighted the personal story behind the app: its creator lives with the very problem he's helping others understand.

App Store

2nd Place: Josie

Josie's founders have PCOS themselves and built the app they wished they'd had while trying to understand it. Lab markers, cycle information, and daily habits sit together, making changes easier to follow over time. The care extends to the language: Josie avoids judgmental normal-or-abnormal alerts, helping people build a clearer record to discuss with their clinicians.

The judges appreciated that Josie addresses a real problem and that the founder's involvement with it extends beyond the hackathon.

App Store

Google Play

3rd Place: Loomi

Loomi makes room for the relationship skills that are easy to put off until something goes wrong. Couples get short lessons, daily questions, shared memories, and date ideas, with each lesson ending in something to try together. Nik Shevchenko connects the idea to his parents' divorce and a wish to help people start those conversations earlier.

The judges particularly liked the interface and the interactive features that give couples more ways to use what they're learning.

App Store

RevenueCat Design Award

The RevenueCat Design Award was about the care you can feel when using an app. We looked at how the interface, interactions, and animation worked together, with room for original ideas and a little personality. The best entries made everyday tasks feel clear, considered, and enjoyable.

1st Place: Clucky

Clucky is an alarm clock with a rooster's determination to get you out of bed.

Dismissing it can mean solving a problem, moving around, or finding an object, and the character follows you from setup through your morning missions. Even choosing the alarm time becomes part of the design: scroll the rooster's eyes and use its yellow beak as the pointer.

The same character appears throughout onboarding, missions, and paywalls, while animation and haptics carry its personality into the details. It's the consistency of that little world that makes Clucky memorable.

The judges singled out the rooster's eyes as a time picker, a small detail that shows how much creativity went into the design.

App Store

2nd Place: Aweigh

Catching a ferry is a pretty good reason to want clear, reliable information on your phone. Aweigh brings Washington State sailing times, vessel locations, cameras, and service alerts to iPhone and Apple Watch. Zach Coleman gives that changing information a familiar shape: a departure board that flips and reshuffles like the signs at a terminal, complete with haptic feedback.

App Store

3rd Place: Buck

A box of coins inherited from his grandfather gave Buck's creator a collecting project and plenty of research to do. Buck makes that first step easier, identifying coins and banknotes and helping users explore their history and estimated value. The scan reveal gets its own little celebration, with animation, sound, and haptics before the find joins a digital collection.

Reviewing its monetization, the judges particularly liked the personalized paywall, which shows the user's own scanned coin at a clear moment of value.

App Store

Google Play

Catvertising Award

For the Catvertising Award, the challenge was to find a creative place for RevenueCat Ads within the app experience. We wanted to see how an ad could connect to something a user already wanted to do, and how that choice worked alongside the app's other ways of earning revenue.

1st Place: Adversary

Niv Ben-porath wondered whether trying to avoid an ad could become the game itself.

Adversary hides an unpaired Danger card among a board of matching pairs; reveal it, and the advertising becomes part of the board you're trying to remember. It's a small twist on a familiar memory game that gives the ad a role in the action.

Players get an initial ad-free period, then choose whether to keep playing with ads or buy a permanent unlock that removes them and adds more difficulty options.

The judges particularly liked how the ad became part of the gameplay itself, calling it the most creative integration they'd seen while judging.

App Store

2nd Place: WALLO

WALLO turns the guestbook at a gathering into something everyone can contribute to at once. Scan a code, add a photo or sticker, and watch the shared canvas fill up. Its rewarded-ad idea is particularly fun: one guest becomes the Room Hero, shortening the posting cooldown for everyone. That's an ad whose reward the whole room gets to enjoy.

The judges highlighted the shared reward: one person watching an ad unlocks more for everyone in the room.

Google Play

3rd Place: ate

Egor Kabantsov wanted a place for food memories without another set of numbers to track. ate turns a meal photo into a cut-out sticker, building a collection of dishes and cuisines over time. When the free scans run out, an optional rewarded video unlocks another one, giving someone a way to save the meal already in front of them.

The judges liked how naturally the rewarded ad fits into the experience, giving users a choice about whether to keep the sticker they've just created.

Google Play

Next Gen Award

The Next Gen Award gave student developers a place to show what they could build. Entrants shared demos and public source code, letting us see both the idea and the work behind it. The category made room for promising projects that hadn't yet reached an app store.

1st Place: Bubble Games

Bubble Games asks everyone to put their phones on the table, then turns those screens into one shared game board.

Objects travel between devices as friends race, compete, and pass a virtual hot potato. Built by four software engineering students at Université Laval, it's a playful answer to the problem of everyone sitting together while looking at separate screens.

The submission includes ten minigames and public source code, showing how the students made several separate devices behave like one playful surface.

Google Play

2nd Place: 1% Lock

Ryunosuke Ishigami built 1% Lock after seeing how much time on his phone had affected his studies. The app pairs blocking with a motivational feed focused on studying and work, giving the familiar urge to scroll somewhere else to go. Built solo in SwiftUI and shared as open source, it's a student's very personal take on finding focus.

App Store

3rd Place: After You

Finding time to play together gets harder when your friends live in different time zones. Aamir Abdul Azeez built After You around that reality: each person plays when they can, then watches a replay where both runs appear together. The phone recreates the players' actions inside the game, making a shared moment possible without coordinating another evening online.

Google Play

HAMM Award (Help Apps Make Money)

Our mission is to help apps make more money, and the HAMM Award asked developers to put that into practice. We looked at how pricing, paywalls, packaging, and purchases fit the product and its audience. A thoughtful RevenueCat integration should make it easy to understand what's worth paying for.

1st Place: GRIDLOCK

Ayush Chaurasia's question was how far tic-tac-toe could grow while still feeling recognizable.

GRIDLOCK answers with matches for up to four players, online rooms, and eleven special moves. Its monetization is built around a shared Credits currency: players can earn through rewarded ads, buy packs, or subscribe, while the core modes remain available for free.

The subscription combines ad removal, recurring credits, and other extras. That gives regular players a different option from someone who only wants an occasional credit pack.

The judges highlighted the thoughtful mix of subscriptions, consumable packs, and ads.

App Store

2nd Place: DramaSip

DramaSip serves up short dramas in a vertical feed, with the next episode a swipe away. Vadim Savin gave viewers several ways to keep watching: free episodes, Premium subscriptions, permanent episode unlocks with coins, and rewarded ads. RevenueCat connects those choices to the same customer identity, carrying purchases along as someone moves from guest viewing to an account.

The judges particularly liked the range of revenue streams, with subscriptions, coin purchases, and ads working within the same app.

Google Play

3rd Place: Ritmo – Dating & Sport

Adel Benzehda kept hearing the same question at run clubs: who's single? Ritmo builds a dating app around that natural overlap, with sport-based profiles, shared activity suggestions, and local clubs. Subscriptions sit alongside individual Boost and Super Like purchases, while the team experiments with pricing and paywalls that appear when someone wants to use a particular feature.

The judges highlighted how closely the subscriptions, Boosts, Super Likes, and contextual paywalls fit into the product.

App Store

Google Play

Influencer Award - Nutrition & Healthy Eating: Abbey's Kitchen

In Abbey Sharp's challenge, the goal was to make satisfying meals easier to put together. Developers were asked to start with what someone already wanted to eat and suggest useful additions, such as protein, fibre, or healthy fats. The emphasis was on enjoying food and feeling satisfied, without calorie counting or rigid meal plans.

1st Place: Just Add

Just Add began with someone close to the creator who found food noise and counting-focused nutrition tools exhausting.

Describe what you feel like eating, take a photo, or say it aloud, and the app suggests three meals built around it. Protein, fibre, and healthy fats come in as useful additions, with shopping help and hands-free cooking to carry the idea through to dinner.

Remembered preferences, a cookbook, and a quick question about how satisfying the meal was help the app learn what someone actually wants to cook again.

The judges liked the approach to meal building, especially the dinner-host feature that includes other people's preferences.

App Store

2nd Place: satisfed

Irem Duran and Burak Eren Demir recognized their own experiences of nutrition guilt in Abbey Sharp's challenge. Their answer, satisfed, starts with the meal you already want and suggests easy additions to make it more satisfying. A visual Trio Ring brings protein, fibre, and healthy fats into focus, leaving room for leftovers, restaurant meals, and cravings along the way.

The judges particularly liked the welcoming design, which felt less rigid than other meal trackers and calorie counters.

App Store

3rd Place: The Plate

The Plate starts with a useful dinner question: what could I add to this? Describe a meal, take a photo, or say it aloud, and the app suggests additions that account for time, price, and preferences. Ramy Magdy's Egyptian and MENA-aware catalog also makes space for dishes such as koshari, fuul, and molokhia. The food you actually eat belongs here.

Google Play

Influencer Award - Productivity: Christopher Lawley

In Christopher Lawley's challenge, the goal was to make the things you use repeatedly easier to find and reuse. Think of the reply you keep typing, the document you always need, or the image buried in your library. Developers were asked to give that material a fast, focused home that fits naturally into everyday work.

1st Place: SnipStash

SnipStash is for the reply you've typed twenty times, the PDF you can never find, and the image you keep scrolling back for.

It keeps reusable material in one library across iPhone, iPad, and Mac, then brings it into reach through a keyboard, quick palette, hotkeys, and Shortcuts. Templates can hold several kinds of content together, so a repeated task takes fewer trips between apps.

Private iCloud sync keeps the library available across devices. At submission, Pro was offered as a one-time universal purchase rather than another subscription to manage.

The judges felt SnipStash delivered exactly what they'd hoped for in the challenge, particularly praising its speed and native interface.

App Store

2nd Place: Ribbons

Paul Waweru's travel-agent wife kept losing saved photos as they slipped back to their original dates in her library. Ribbons gives those useful bits of information a home organized around what they're for. A Drawer can hold bookings, scans, links, and photos together, with search inside images and PDFs and shared Drawers for the material someone else needs too.

The judges particularly liked shared Drawers, making it easy to keep a useful set of snippets available to someone else.

App Store

3rd Place: Ledge

Copy something new, lose the thing you copied before it. Gaurav Kukreja built Ledge around that everyday annoyance, keeping clipboard history and reusable snippets close at hand on the Mac, with an iPhone companion alongside it. A quick palette handles search and paste, while Halo puts pinned items around the pointer. The things you keep reaching for stay within reach.

The judges particularly liked the capture tab, where having the options together made saving content fast.

App Store

Influencer Award - Career Coaching: Leadership Heather

In Leadership Heather's challenge, the goal was to help people practice the conversations they tend to put off. Giving feedback or pushing back on a request can feel very different once another person responds. Developers were asked to make that practice realistic, with useful feedback people could take into the actual conversation.

1st Place: Rehearse - Hard Conversations

As a new product manager, Akil Saji struggled to push back when his manager promised more work than the team could take on.

Rehearse gives people a place to practice those conversations aloud with an AI counterpart that responds. Feedback points to the line where things changed, and a prep card helps carry the practice into the conversation that matters.

There are 33 prepared scenarios alongside custom situations, with feedback covering clarity, empathy, assertiveness, and structure.

The judges particularly liked the simplicity of Rehearse, which let it focus on doing its main job well.

App Store

Google Play

2nd Place: Bravy — The work journal that teaches real conversations

Leon Kraus had to give difficult feedback to the working student who'd helped onboard him. Rehearsing in his head hadn't made saying it aloud any easier. Bravy connects a work journal with voice, text, and avatar-based practice, so users can rehearse situations involving their actual colleagues and agreements. Feedback from early testers helped make that personal context central to the app.

App Store

3rd Place: Firmly

It's easy to prepare a good opening line. Staying clear when the other person pushes back takes practice. Firmly gives managers characters who argue, dodge the issue, or appeal to friendship, with different levels of resistance to work through. Debriefs quote the user's own words and suggest what to try next, followed by a check-in after the real conversation.

The judges loved how challenging the practice felt, giving users a chance to work through a genuinely difficult conversation.

App Store

Influencer Award - Gaming: Mr Lewis Blogs Gaming

Mr Lewis Blogs Gaming's challenge started with a familiar problem: seeing a game you want to play, then forgetting about it. The goal was to help people save discoveries, organize their backlog, and keep track of what they finished. Ratings and sharing would give those collections a life beyond the wishlist.

1st Place: Game Magnet

Kundan Sai Pannuru kept seeing games in short videos, then forgetting their names when he wanted to play them.

Game Magnet lets you share the clip instead: it identifies the games and saves them to your backlog. From there, shelves, ratings, and ranked lists help turn a fleeting discovery into something you might actually get around to playing.

Clips process in the background, with a notification when the result is ready. That means saving a discovery doesn't have to interrupt watching it.

The judges liked how fully Game Magnet answered the challenge, with a layout they found easy to use.

App Store

2nd Place: GameNight

Sometimes choosing a game takes longer than anyone wants to admit. GameNight brings friends' Steam libraries, wishlists, and ratings together to find the overlap, then offers a slot-machine-style pick when the discussion still goes nowhere. Matthew Walmsley also built in reviews, challenges, and leaderboards, giving the group somewhere to keep the conversation going after they've finally picked something.

The judges particularly liked how the rewards and challenges made using the app and getting around to playing games feel fun.

App Store

3rd Place: Slyko

Enzo De la pena wanted the pleasure of keeping a film diary, applied to games. Slyko brings wishlists, reviews, library sync, and public favorites into one place, helping players remember what they've enjoyed and what they want to try. Share a social post and it can identify the game for you, saving that discovery before it disappears down the feed.

The judges appreciated having games from different libraries in one place, saving players from checking across multiple platforms.

App Store

Google Play

Influencer Award - Yoga & Fitness: Simone Sharice

In Simone Sharice's challenge, the goal was to make choosing how to move feel more manageable. Developers explored ways to account for someone's energy, available time, and recovery needs, then offer a clear plan for the day. The focus was on helping people get started with something that fits how they feel.

1st Place: FeelGood: Movement Menu

Sometimes the hardest part of moving is choosing what to do.

Yusra Salam and Ameena Malik built FeelGood around a short check-in, turning your energy, available time, and desired feeling into a small movement menu. An appetizer, main, and optional sides make the choices approachable; rest counts, and coming back after a break doesn't bring a broken streak with it.

The menu spans Pilates, yoga, strength, walking, stretching, and breathing, with a plain-language reason for each suggestion.

The judges particularly liked the theme and colors, describing the app as inviting, calm, and easy to look at.

App Store

2nd Place: GO: Chair Yoga for Seniors

Subham Bhalawat wanted older adults to get the same care in fitness programming as everyone else. GO builds a daily plan from mobility goals, movement preferences, and available time, with chair-based and supported-standing sessions. Real trainer videos, previews, and voice guidance make the next step clear. Users get one workout to start, rather than another library to sort through.

The judges highlighted the clean onboarding and how well it was tailored to the intended audience.

App Store

3rd Place: Sadhana – Yoga & Meditation

Sadhana grew out of a yoga teacher's frustration with conflicting instructions and too much choice. It offers one daily Hatha practice combining movement, breathing, and meditation, then asks whether it felt too gentle, just right, or too much. That feedback shapes the next session, with room for rest and a gradual return after a break. Hand-painted artwork completes the calm setting.

The judges particularly liked the hand-painted images, which they found beautiful and calming.

App Store

Ship Kotlin Everywhere

JetBrains' Ship Kotlin Everywhere award challenged developers to build a polished experience across platforms using Kotlin Multiplatform or Compose Multiplatform. We looked at how shared technology supported the finished product, from the interface to the work underneath it. The goal was an app that felt considered wherever someone picked it up.

1st Place: BoatBrawl

BoatBrawl brings the cheerful chaos of couch multiplayer to friends playing across phones and computers.

Up to eight players steer, fire, and scramble through interactive arenas, with bots and shared-screen play available too. Rehaan Cubes and Ashwin K M used Kotlin Multiplatform and Compose Multiplatform to share the game across platforms, keeping the same rules underneath every battle.

The shared approach covers the interface and much of the rendering and networking, across iOS, Android, Mac, Windows, and web.

The judges were especially impressed by how smoothly BoatBrawl played in the browser.

App Store

Google Play

2nd Place: AfterFade

Kanon Fujita could look back at photos and remember how a day looked, but not how it sounded. AfterFade turns seven five-second clips into a music video, composing a lo-fi soundtrack from their colors and ambient sound. Kotlin and Compose share the interface and music engine across iOS and Android, with composition happening privately on the phone.

The judges particularly liked the ingenuity and creativity behind the idea.

App Store

Google Play

3rd Place: Lumeo

Some thoughts arrive while you're walking, commuting, or doing anything except sitting at a keyboard. Lumeo lets you speak them, then transcribes, organizes, and connects them with earlier notes. Piotr Prus uses a constellation view to make those links visible. Kotlin runs through the project, from shared mobile code to the backend and even the module that rendered its demo film.

The judges singled out the project's contributions to the Kotlin community.

App Store

Google Play

Most Viral App

Noise's Most Viral App award focused on the creative work of getting an app noticed. Developers experimented with videos, hooks, and formats that could introduce the product to new audiences. We looked for a clear connection between the content people wanted to watch and the value waiting for them inside the app.

1st Place: Trazo: Golf Ball Tracer

Trazo gives amateur golf videos the ball-flight line usually seen on a broadcast.

Julian Praest built the processing to run on the phone, starting from two selections of the ball. For the app's marketing, golf humor and advice became repeatable formats, with the tracer reveal giving viewers a reason to care about the product at the end.

The team evaluated formats for how well they could attract attention, be repeated, and lead to interest in the app, then stopped weaker ideas and kept working on stronger ones.

The judges highlighted the team's understanding of how to use organic content to introduce people to the app.

App Store

2nd Place: PlateDiary – Food Journaling

Most of us have a few good meals buried somewhere in our camera roll. PlateDiary gives those photos a home, organizing food and drink into a visual journal worth returning to. John Michael Degojas carried that familiar behavior into creator campaigns, testing hooks and formats that move from a recognizable habit to the pleasure of seeing the finished collection.

The judges saw the value in turning a food photo into a saved memory, particularly with its location on a map.

App Store

Google Play

3rd Place: Quenched – Water Tracker

Jason Clardy built Quenched after a doctor's visit revealed he was dehydrated despite feeling normal. The app brings together a personal water goal, reminders, widgets, and quick logging, with water that reacts as you tilt the phone. That little physical detail gives the daily habit some personality, while marketing experiments tested different ways to introduce it to new users.

App Store

Google Play

Best App for Galaxy

Samsung's Best App for Galaxy award asked developers to think about what their app could do on Galaxy devices. Publishing to the Galaxy Store was part of the challenge, along with adapting the experience to the hardware. Foldables offered particular room to explore how layouts and interactions could change with the screen.

1st Place: Grandfolio: OPTCG Card Game Scanner

For One Piece Card Game collectors, two cards that look almost the same can be very different finds.

Aris Guimerá Orozco built Grandfolio to identify exact artwork variants, manage duplicates, and track a collection's prices and progress. Its Galaxy version adapts across folded, tabletop, and open-screen layouts, giving a growing collection more room when the device has it.

A dedicated Galaxy Store build also connects Samsung billing to RevenueCat, making distribution and purchasing part of the platform work.

The judges particularly liked the polish and foldable optimization, applied to a distinctive collecting use case.

App Store

Google Play

2nd Place: Rainroam

Rainroam lets players switch from a 3D adventure to pixel art in the middle of a fight. Both views run the same game, so the islands, quests, and bosses carry on without a restart. Hanna Shcharbakova and Yauheni Draitsau also worked through Galaxy folding, unfolding, and multi-window behavior, bringing that flexibility to the device as well as the art style.

App Store

3rd Place: SugarCurve: Gestational Diabetes Coach, Meal Planner & Glucose Tracker

A husband-and-wife team's experience of gestational diabetes became the starting point for SugarCurve. Glucose records, meal planning, food information, and reminders follow the journey through pregnancy and postpartum. On Galaxy foldables, readings, targets, and trends sit side by side, using the extra screen space to make a personal record easier to look through.

The judges liked the overall presentation and noted the work on foldable optimization.

App Store

Google Play

Replit's Idea to Income

Replit's Idea to Income award followed the journey from an idea to an app someone could download and pay for. Developers used Replit and RevenueCat to build the product, get it into users' hands, and set up purchases. The category celebrated taking those first practical steps toward an app business.

1st Place: Let’s Get Support by 3Dadz

Let's Get Support focuses on the people affected by someone else's addiction: partners, parents, and friends who need support themselves.

Joshua Burgess and Aaryn B. built it from community conversations in Abbotsford and the Fraser Valley, bringing together check-ins, journaling, boundary-setting tools, and local resources. Replit helped the pair turn those conversations into a live app, with the core tools available for free.

Optional Plus purchases support the app, while journals and weekly calculations stay on the device. The team's submission describes an early launch with working purchases and community-led distribution.

Google Play

2nd Place: Quarterday

Home maintenance has a habit of becoming urgent just after you've forgotten about it. Quarterday starts with a quiz about your home, builds an annual schedule, and shows what's due now. Adrian Ferguson used Replit to get the first version working, then added a logbook and photo receipts to help homeowners keep track of the jobs they've actually done.

App Store

Google Play

3rd Place: Family Prayer

Family Prayer began with a mother's experiments in helping her sons build a daily prayer habit. Children get stories, achievements, and points, while parents choose real-world rewards that suit their family. Replit, Expo, and RevenueCat helped a first-time builder take that idea to the App Store. At submission, the team reported its first two annual subscribers.

App Store

The Growth Loop Award

Layers' Growth Loop Award was about learning what helps an app grow. Developers were asked to run focused experiments, measure what happened, and use the results to decide what to try next. An experiment that challenged the original plan could be just as useful as one that confirmed it.

1st Place: PoquitoTalk: Bocas del Toro

After 14 years in Bocas del Toro, Dorien Van den Abbeele had seen how often textbook Spanish misses the way people actually speak there.

PoquitoTalk turns English into local Spanish voice notes for WhatsApp and helps translate the replies. Recipients don't need the app, making it useful in a community where a voice message is often how everyday things get arranged.

Dorien's growth experiments compared automated clips with handmade local content. The submission also records where the evidence was inconclusive and where measurement needed fixing.

The judges highlighted the team's extensive experimentation, along with its openness about a measurement bug that the Layers data confirmed.

Google Play

2nd Place: Better Yoga

Better Yoga turns a quick check-in about energy, soreness, and time into one manageable yoga or Pilates session. Fakher Hakim applied the same willingness to adapt to the app's marketing, testing humor, product demos, and rest-positive messages through Layers. When the results challenged the original idea, the messaging changed. The submission makes the learning visible, including the surprises.

The judges appreciated that the team followed through on its experiment even when the results disproved the original hypothesis.

App Store

Google Play

3rd Place: Green Hour: Time Outside

Natasha Wilson found that short breaks outside helped her days, but winter made the habit easy to lose. Green Hour records mood before and after time outdoors, helping users see their own pattern. Its Layers experiments bring similar care to growth, separating social attention and store visits from installs the team could actually attribute. The early learning stays grounded in the evidence.

The judges singled out the thorough use of the platform, including nine experiments, separate channel links, audience personas, and bot filtering.

App Store

Keep Them Coming Back Award

OneSignal's Keep Them Coming Back award asked developers to give people a useful reason to return. That could be an alert they'd requested, a timely update, or a message connected to their own progress. We looked at how communication supported the app's purpose and continued to help between visits.

1st Place: Parky!

Chase Van Derrick brought his experience as a Disney Cast Member to Parky!, a companion for Disney and Universal visits.

It combines wait times, dining availability, and park-day memories with the kind of timely help a guest might ask for at a front desk. Dining alerts can even become a conversation from the Lock Screen, where you can ask about another time or restaurant.

Requested alerts, queue Live Activities, and recap messages give the app reasons to get in touch that fit the visit, from planning a meal to remembering the day afterward.

The judges particularly liked the interactive notifications, including the ability to reply directly.

App Store

2nd Place: Inference

Samuel Anozie found that budgeting money and time still left a harder question: where was his energy going? Inference uses journal entries to spot patterns around work, health, relationships, and rest. OneSignal carries follow-ups through push, in-app messages, Live Activities, and email, including a monthly letter that connects the user's history with the goals they're working toward.

The judges highlighted the thoughtful use of Live Activities, in-app messages, emails, and journeys to keep the conversation going between sessions.

App Store

3rd Place: Tikku

Tikku joins two things that make more sense together: choosing what to do and protecting the time to do it. Tasks and routines connect directly to distraction blocking, while OneSignal messages wait until focus sessions finish. The device adds personal Screen Time figures locally, keeping those details on the phone. Even its reminders respect the time someone set aside.

The judges praised both the polish of the app and its use of OneSignal, from rich push notifications and journeys to Live Activities and in-app messages.

App Store

Funnel Vision Award

Stripe's Funnel Vision Award focused on the journey from the web into an app. Developers built payment funnels with RevenueCat Funnels and Stripe, connecting an introduction to the product with checkout and access in the app. The challenge was to make that whole path work, from the first question to a completed purchase.

1st Place: In Your Own Words

In Your Own Words gives people a minute to practice saying something they might otherwise avoid.

Natasha Wilson's app offers real-world conversation scenarios and feedback on pace, hesitation, and filler words, with speech analysis happening on the phone. Its web quiz starts that journey before download, guiding visitors to a relevant practice deck and letting a web purchase unlock it in the app.

The submission documented a £2.99 web purchase successfully unlocking the right deck on an anonymous install, a small but complete demonstration of the path from quiz to practice.

App Store

2nd Place: Kettlebell Body

Kettlebell Body gives kettlebell training the room it deserves as a discipline of its own. Built with coach Trevor Shan, it pairs an eight-week Foundation program with weekly workouts, coaching videos, timers, and progress tools. Different formats, from EMOM to ladders, get their own structure, helping users follow a program beyond picking an exercise from a general fitness library.

App Store

Google Play

3rd Place: Bravy — The work journal that teaches real conversations

Bravy gives visitors something useful before asking them to subscribe. Its web-to-app funnel starts with a three-question quiz, then offers an opening line and a practical conversation tip tailored to the result. Monthly, three-month, and annual plans follow, with a Stripe-backed purchase and redemption link unlocking Pro in the app without an account. The first bit of coaching happens before download.

App Store

Conflict of Interest Award

Last year was the first time we allowed RevenueCat employees and Shipaton sponsor employees to participate in the hackathon. That year we only got two submissions so it was refreshing to see that this year we increased that number to 23 submissions. Most were RevenueCat employees (some of them even submitting more than one app).

This year we decided to open the judging of these apps to the other Shipaton participants. Seemed only fair that after judging the apps you built, you should judge the apps we built. Judging was done through a custom judging platform where you were shown two apps at a time, and had to pick the better one. After a week, we had a pretty clear winner:

Winner: Friendpire

RevenueCat employee Erik MacInnis wanted to bring back Catan nights with friends who could rarely find time to play together.

Friendpire turns that idea into a shared hex-tile world where friends gather resources, build farms and docks, and expand their little empires. Erik used Fable in Cursor to work through the art direction, mechanics, and social features, shaping a familiar board-game ritual into something easier to fit around everyday life.

App Store

See you next year

Every year, Shipaton keeps growing and you’ve once again outdone yourself. We saw so many great apps, and it’s a shame we can’t award every great app. The work all of the Shipaton participants put in is nothing short of inspiring.

Finally, from all of Team RevenueCat: congratulations to all the winners! And thank you to everyone who contributed, mentored, or simply encouraged someone else to ship. While it might be the end of Shipaton 2026, it's just the beginning of your apps. We can't wait to see where they go.

How did you find Shipaton? 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.

Now, my argument is easy to agree with, but it’s harder to act on. Heart alone won’t get you to the top of the App Store. The apps that win in this environment need three things working at the same time:

• Heart: something that resonates — real problems, messaging that lands
• Distribution: well-tuned paid acquisition engine and product loop that earns organic growth
• Monetization: an onboarding flow, paywall, and pricing strategy that systematically converts attention into revenue

Pick one and you are halfway there. Pick all three and you are dangerous. Here's what heart looks like when apps actually do it — and what happens when they don't.

What ‘heart’ actually means in practice

I want to be careful here, because ‘heart’ is the kind of word that sounds meaningful in a conference talk, and fuzzy in a product review. Here is what I mean when I’m talking about building with heart.

1. A sharp understanding of a specific user

Not "women aged 25–40 interested in wellness". Something much more specific: a first-time mom who is three months postpartum, exhausted, and looking for something that fits into five-minute windows between feeds. Or someone with ADHD who has tried 17 productivity apps and abandoned all of them because the onboarding was too long.

The specificity shapes everything: the tone, the visuals, the questions you ask, the order you ask them in. The more specific the mental model of who you are building for, the more everything else follows naturally.

2. Speaking their language

This sounds obvious, but is almost never done well. Speaking your user's language does not mean labelling them ("for busy moms!"). It means formulating onboarding questions the way the user would actually think about the problem: not the way a product manager would write a spec.

A good test: read your first onboarding screen out loud. Does it sound like something a person would say? Or does it sound like a SaaS landing page?

A personal example: when I was leading the onboarding team at Flo Health, I suggested adding an interrupting popup during the loader screen that runs right before the paywall. The popup asked: "Do you drink more than two cups of coffee a day?"

The question came directly from my own experience. I am a mother, and I was pregnant before. Pregnant women are told early and often: no more than two cups of caffeine per day. It is one of those rules that becomes part of how you think. When I was pregnant, I was counting. Every day.

So when we were testing copy for the interrupting popups on the web funnel, I threw this one into the mix. It stuck. From what I can tell, nothing has beaten it since.

Can you guess why the second popup asked about chocolate?

Chocolate also contains caffeine. Most people do not think about this. Pregnant women and women trying to conceive do, because they are already tracking everything. The moment a user sees that question, something clicks: this app knows what I know. It is the feeling of being seen by someone who has been in your exact situation — not a demographic guess.

That is what speaking the user's language actually means. Not clever copywriting, but a question that only makes sense if you genuinely understand the specific situation your user is in. And in this case, I understood it because I had lived it.

3. Small moments of delight

These are the things that die in the roadmap meeting because someone asks "what is the point in this?" and nobody had a good answer. A small animation that responds to user input. Copy that has a point of view. A screen that acknowledges something specific about what the user just told you: not generically, but in a way that shows you were paying attention.

These moments are often cheap to build. But their effect on retention is significant. I've seen 10% lift in onboarding paywall conversion from such aha! moments.

4. Early aha! moments

This is where I spend most of my time when working with apps, and it is where the ROI is highest.

An aha! moment is when the user thinks: “ah, this is exactly what I need”. It is the point where curiosity becomes commitment. The mistake most apps make is placing it too late: after signup, after onboarding, sometimes only after a purchase.

In B2C apps, the first aha! moment should happen before the paywall. Often before signup, and ideally in the ad itself.

5 types of aha! moment to try

Before we move onto a framework for building apps with heart, let’s dig a little deeper into the forms that these heartfelt aha! moments can take.

Calculations and projections

The user inputs something and gets a meaningful, personalized result back. Noom built much of its reputation on this: after a long onboarding asking about weight, goal date, and lifestyle, the user gets a loader followed by a graph showing exactly when they will reach their target weight. The user thinks "Aha, I can lose this amount by that date. Where do I sign up?" Dozens of apps have since copied this sequence, and it still works, because the graph transforms a generic product into something that feels built for this specific person.

Another weightloss app takes the same principle further by building the aha! across several screens rather than one. When the user enters their weight, a BMI traffic-light scale appears in real time, making the concept easier to understand. The user thinks "Aha, I am in the orange zone."

The next screen pre-fills a reasonable weight loss goal — not the aggressive one the user might have entered themselves — and gives feedback if the user insists on a dangerous weight loss goal: "Aha, they’re not going to sell me an unrealistic target." Then the graph arrives. By the time the paywall appears, the user feels the product is already looking out for their best interest and working for them. Each screen adds a layer of trust before the ask.

Seamless transitions into the product itself

Numo, an ADHD management app, asks users during onboarding about the tasks they keep postponing — the exact struggle someone with ADHD relates to. How do they know? The users have told them.

At the end of the flow, it reveals that those answers have already been turned into tasks inside the app, with reminders pre-set. The user goes from just ‘answering questions’ to feeling that the app is already personalized to their life and working to help them. This aha! moment means they’re not being asked to pay for something they might like; they’re being asked to keep something they now already have.

Aha! moments that start in the ad

Simply Sing does something rare: the aha! begins before the user even opens the app. Their ads show someone who cannot sing; another person tells them to do simple actions they need to do right now: say ‘hey, hey, hey’ in their loudest voice, hum etc; the song immediately adjusts to the user's voice.

By the time the user taps through to onboarding, they’ve already felt the product's core promise. The onboarding then confirms it, guiding them through vocal range detection, after which all available songs are adjusted to their range. They think: "Aha, I am an alto and can sing these songs.” While most apps treat the ad as traffic and the app as the goal, Simply Sing treats the ad and the onboarding as one continuous experience.

The value proposition itself as the aha! moment

Opal is an app that blocks distracting apps from the user. To illustrate this, their onboarding skips the elaborate quiz format and shows users, in plain numbers, how much time they lose to their phone — and how much they could get back. No graph. No personalized projection. Just the number, framed as time: years of your life.

The user thinks: "Aha, that’s how much time I’m getting back with this app.” It works because the aha! is not about product features; it’s about connecting emotionally, and making the cost of not using the product feel real.

Loaders and processing screens

Some people say they hate loaders, but the data says otherwise. A loader that implies the system is actively working on the user's behalf — building their plan, processing their answers — creates anticipation even when the calculation is instant.

What all of these have in common is that the user feels something before they are asked to pay. They are connecting with the value of the product, and feel the product understands them in return.

Aha! moments are rarely a single screen. Flo Health's opening sequence spans four screens to route the user to the correct product mode, while simultaneously making them feel understood. It’s the same with the BMI screens mentioned earlier. The overall effect is one aha!, but it is built from a series of small confirmations. When mapping your own onboarding, look for the cluster of screens where something shifts for the user, not just the single moment.

Why most apps still feel empty (even when optimized)

Here comes the uncomfortable part. I’ve said this to clients in the past, and I’m sure I’ll say it again. Maybe you’re doing all of these things. That’s fine; awareness is a starting point.

A lot of apps are well-optimized. Clean funnel, tested copy, best-practice paywall, A/B tests run. Yet the app still feels like nothing. There’s content, there’s onboarding, but it just feels… empty.

Here’s what I think is happening:

Optimized funnels with no emotional hook: the flow moves users efficiently from screen to screen, but there’s no moment where they feel understood. The questions are generic. The responses are generic. The user arrives at the paywall having been processed, not engaged.

Surface-level personalization: the onboarding collects the user's name, age, and goal. Then shows them a paywall that is identical to every other user's paywall. The personalization collected data but did not use it. Users notice this mismatch — maybe not consciously, but it registers. It damages trust precisely because the app set the expectation of something tailored, then delivered something generic.

Paywalls before value: a user downloads an app, answers four questions, and hits a paywall before they have experienced anything. Early paywalls assume the user arrived with enough intent to pay before seeing what they are paying for. In reality, most users aren’t ready to pay — they’re curious. The app needs to bridge that curiosity gap before asking for money.

Same messaging everywhere: across the onboarding, the paywall, the post-purchase screen, and the first few in-app experiences, the copy is interchangeable. There is no voice. No point of view. It could belong to any app in the category.

The industry spent years (and a lot of money) optimizing for conversion rates. But in doing so, it has quietly stripped out the things that make users stay. We’ve optimized our way to being forgettable. A high paywall conversion rate is not the goal — high LTV is. And LTV is earned by making users feel, early and repeatedly, that the product is genuinely for them.

The bridge: heart + method framework

Heart without method is invisible. You can build the most thoughtful, specific, emotionally-resonant app in your category. But if no one finds it, or if the people who find it cannot convert, it doesn’t matter.

Likewise, method without heart is forgettable. You might run a clean acquisition funnel, have a well-tested paywall, a solid pricing strategy. If the product feels like every other product in the category, you are just another app in the same auction, competing on who spends more. Some apps do win that way — but only if the creatives are as strong as the funnel, and the budget can sustain it.

Don’t get me wrong, acquisition is a valid strategy. But it isn’t a moat. Users convert, then leave. The apps that will keep users long-term are the ones that have heart and method. Right now, most apps have one of the two. You probably know which it is.

So how do you get both? Here’s my framework for building apps that feel like something, and convert. It’s not a complete growth system, but it is a starting point for connecting the ‘heart’ work to the ‘method’ work.

1. Design early aha! moments before the paywall

Map your onboarding flow. Mark the point where a user first experiences genuine value. If that point is after the paywall, your job is to move it earlier.

Ask yourself: what is the smallest thing we could show or give the user (a result, a projection, a personalized output) that would make them feel like the product is already working for them? Then build it before the paywall.

The benchmark I suggest aiming for is to retain at least 75% of users from the first screen to the second. If you’re retaining less than that, the first screen is not confirming that users are in the right place fast enough. And if they don’t feel confirmed in the first two screens, they will not reach the aha! moment you built further in the flow.

2. Let onboarding feel human

Bring back the things that got killed in previous roadmap meetings because they were hard to measure: question phrasing. Tone of voice. A moment of warmth when a user shares something personal. A screen that doesn’t just collect information but acknowledges it.

These are the differences between a user who converts and stays, and one who converts and churns within the first billing cycle. The former tells their friends. The latter leaves a one-star review because they forgot they subscribed.

A practical starting point is to rewrite every onboarding question in the voice of the user, not the voice of the product. Then read the flow aloud. Fix anything that sounds like copy. Repeat until it sounds like a real user.

3. Use onboarding to tell the story — whatever got them there

Good onboarding does two things at the same time. It tells the user this is for them. And it sells them the better version of their life if they hire this product. When it does both, you get conversion and retention together, not one at the cost of the other.

This is also why your creatives might not always need to be perfectly on-brand to work. Some of the best-performing ads I have seen look almost random — images of discharge, self conscious mirror selfies, things you would never put on a brand moodboard. But they perform because they trigger a deep fear, a curiosity, a problem, or a life moment the user recognizes. The thing they clicked on at 11pm without fully knowing why. I’ll be honest: I have been almost embarrassed by how well some of these perform on CPA. But they do.

If the creative gets the click, then the onboarding tells the story. A user who arrived with low intent can become a paying subscriber — if the onboarding picks them up and walks them toward the better version of themselves.

The creative is the first sentence. The onboarding is the rest of the story.

4. Measure heart experiments on conversion and LTV

When testing heart-led changes to your onboarding, do not measure conversion rate alone.

Sometimes the conversion stays flat. Price plans redistribute, revenue looks the same on paper, you conclude that the experiment did nothing.

Then you look at LTV 60 days later and users are staying longer. The onboarding sold them on committing, not just paying. That’s a win — it just didn’t show up when you expected it to.

TL;DR: measure paywall conversion and cohort LTV together. That is where the real answer lives.

Let’s build heart back into apps

Building has never been easier. Getting noticed has never been harder. The apps that will cut through are not necessarily the most technically sophisticated, or the ones with the largest acquisition budgets. They’ll be the ones that make users feel seen, and give them a reason to stay.

Delight is the one thing you can't A/B test your competitor into having. You can copy a paywall layout in an afternoon — you cannot copy a product that genuinely understands its users.

Start by building the heart in. Then build the method around it.

You'd think that only applies to obvious habit-building use cases, like utilities, fitness, or diet apps. At least that's what I assumed.

But guess what? It's not that straightforward.

I spoke with Patrick Stuart-Constant, Sociaaal's CEO, and Pablo Sánchez, its founding head of product. Their team is behind Celebs - Celebrity Look Alike, an app that tells you which celebrity you look like.

It's a classic novelty AI use case, the kind where many apps focus on monetizing fast. Sociaaal encourages repeat usage instead: it offers a free trial and lets users reach their first generation before they see any paywall.

The result? Celebs ranks in the 94th percentile for retention among the AI apps in our study. More than half of its weekly subscribers renew after the first week, compared with 37.7% for the median AI app on weekly plans. After a year, it keeps about four times as many weekly subscribers as that median app.

Why Celebs users keep coming back

I was curious about this. How does a celebrity lookalike app with millions of users get people to come back again and again?

Here are the most important bits the team highlighted during our chat:

• Putting the algorithm's quality above everything else. Sociaaal built a strong matching algorithm and prioritized its quality over any growth hack. Because the result is fast and accurate ("in one second you get someone that looks like you"), people keep using it. A week later, they're out with friends and do a few new generations. A month later, it happens again.
• Giving people ideas for what to try next. Sociaaal has tested guiding converted users on what to try next, like taking a photo with their grandma or with friends at school. According to Pablo, many people don't know what else to use the app for, and prompts like these can work well.
• Removing everything between the ad and the result. The team behind Celebs refused to add a long onboarding with email collection, and the tests backed them up. Now people get their first generation right away, then see the paywall offering the free trial.

Pablo sees the simplified experience as one of the big reasons Celebs retains so well:

"We simplified the funnel, and the core feature is super good. We really let the user go deeper and try the app before having any friction."

The app looks simple, but that took a lot of work.

"That simplicity is a result of years of testing with hundreds of tests, with millions of users going through these different flows."

How Sociaaal runs experiments

A big part of that work is iteration. The team tests continuously, knowing that most hypotheses won't win on the first attempt.

That's why many parts of the app are designed parametrically: instead of a fixed screen design, elements such as layout, imagery, wording, bullet points, CTAs, and trust elements are variables the team can change and test independently.

New hypotheses are first tested on smaller cohorts in secondary geographies, and only promising variants go up against the existing baseline. It's also partly a volume game: more well-defined hypotheses create more opportunities to find something that works.

The first screen users see is a good example. It has gone through many transformations. For a long time, a white background with a squared CTA was the clear winner, and the team struggled to find anything that could beat it.

Later, as consumer trends shifted and the onboarding became more colorful, a blue background started showing stronger engagement in smaller test cohorts. Eventually, it produced up to a 10% lift in trial conversion.

The lesson for the team: a winning design is contextual and can stop winning as the rest of the product and user expectations change.

How to apply this to your AI app

Don't get me wrong. Not every AI app needs a free trial or has a use case that people come back to.

But most apps benefit from building for repeated use and testing until the setup works.

For Sociaaal, retention isn't a goal in itself. The studio is built around unit economics, so retention matters when it helps the studio earn more from users than it spends to acquire them.

So treat the ideas below as ideas to test, not steps to copy.

1. Make the core result worth repeating

Celebs users keep coming back because the main result is good enough to try again, and that took a lot of product improvements.

Sociaaal replaced the app's old matching algorithm with a new system that combines several algorithms. It matches people based on their facial features rather than their expressions, and compares them against Sociaaal's own library of celebrity photos.

Getting there took more than one algorithm swap. The team tested several approaches with controlled cohorts, from asking users for images from multiple angles to matching the user's pose to a celebrity photo. Most were discarded.

Even when a feature looked more sophisticated, users didn't engage or convert better. The team picked the most promising direction and refined it for several months until it beat the previous baseline.

It paid off. With better matches, people kept generating matches with new photos and new people. Extra AI features, like transforming your photo, didn't move the needle as much.

Here's what that means for your own AI app:

• Treat output quality as a retention lever. If your app's value comes from one AI result, a generic model with a prompt on top is easy for competitors to copy and may not be good enough to try twice. Celebs' edge is its combined algorithms and its own photo library.
• Judge quality by what users do. A more sophisticated matching approach lost at Celebs whenever users didn't engage or convert better. Ratings help, but repeat behavior tells you more. Check how many users generate again in their first session or come back within a few days (and why), and compare cohorts before and after product improvements.
• Give a big change time to win. A major product change doesn't have to be an immediate winner to be valuable. Sociaaal's new matching only beat the baseline after months of refining. Sometimes the question is whether it gives the team something promising to keep improving.
• Resist the urge to add features for their own sake. When retention is low, it's tempting to keep building new features. But if the main result isn't good enough, more features won't make up for it. At Celebs, improving the main match did more for retention than extra AI features.

2. Get users from the ad to the aha moment as fast as possible

Once your core AI result is good enough that people want to use it again, getting them to it fast can pay off more than charging them on the first visit.

Yes, many AI apps do the opposite. They put users through a long onboarding, or hide the result behind a paywall. For an app people might use once, that looks like fast revenue.

But at Celebs, the path with the least friction won. Patrick described it as getting people from the ad to "the core experience and the aha moment" as quickly as possible, and said removing sign-up and email collection worked "much, much better."

Keep the generation itself fast, too. Celebs used to play fancy animations while it processed the match. They might impress someone the first time, Pablo said, "but when you generate seven times, it's like, why do you even want this animation?"

The team tested removing them and cutting the generation time from five seconds to 1.4, and both changes moved the needle.

3. Let the data pick your monetization

The free trial at Celebs is a good reminder to test your monetization instead of assuming what an AI app should (or shouldn’t) do.

I expected Celebs to charge before showing any result. Sociaaal tested that against a three-day free trial, and the trial won. Patrick sees the trial as the icebreaker.

"Before using our app, quite a lot of people would have doubts as to whether this app really tells you who your celebrity lookalike is. We show them who they look like, who their friends and their partner look like, and then they keep on using the app and do more and more generations."

That's how Sociaaal approaches everything. The team runs about 100 A/B tests a month and uses RevenueCat to read the results. Patrick describes it as "a philosophy of constantly testing and iterating and running as many A/B tests as you can in a very rigorous way."

A few habits make that volume useful:

• Re-run tests that lost. A result only holds for the version of the app it ran on. Patrick has seen failed tests win "a few years later" because "the rest of the app has changed so much."
• Pick an early signal for retention. Renewal data takes weeks to come in, which is slow when you run 100 tests a month. At Celebs, users who open the app three to five times in their first two or three days usually stick around, so the team uses early sessions as another key signal.

4. Personalize only after you've cracked the baseline

Personalization can add another layer of performance, but it comes with a cost: every personalized flow is one more variant to build and maintain, which slows a small team down. So Pablo’s advice is to get the default experience working first and only then personalize.

When it does work, the gains add up. At Celebs, after dozens of iterations, personalizing parts of the experience with user signals lifted conversion by around 15% in the segments where it was applied.

Geography is one of those signals. When testing how much of the doppelgänger to reveal before the trial, Sociaaal found a large blurred image won in some Asian markets, while a much smaller preview did better in the US.

The question becomes less “Which variant wins?” and more “Which variant wins for whom?”

The team also works with more complex setups at scale, like systems that gradually send more users to whichever version performs best for each audience while a test is still running. But you need a lot of traffic, engineering work, and constant monitoring to make it work.

The trade-offs to test for yourself

The Celebs app keeps its users by making the core match good enough to repeat, getting people to it quickly, and testing everything around it, including a free trial most people would bet against.

Each of those choices has a cost, though. Dropping accounts and email collection shortened the path to the first match, but it also gave up the easiest way to bring users back. Celebs makes up for it with paid ads and retargeting.

Free usage costs money, too. Every free generation and every trial is compute you pay for, including for people who never subscribe. If your generations are expensive, you can cap trial generations or sell extra credits on top of the subscription. And a trial only pays off if enough people keep using the app after it ends. Celebs shows you can't always tell that from the use case alone.

There's no right answer to any of these trade-offs, only experiments that tell you what works for your app. After hundreds of them, Sociaaal keeps landing in the same place: the simpler version wins. Or, in Pablo's words, "simplicity pays."

That default is Google App Campaigns (GAC, formerly UAC), and it has been the status quo for app advertisers for years.

Thomas Petit's practical guide to Google App Campaigns documents the limitations better than anyone:

• Valuable search inventory you can't pick keywords for
• No keyword reporting
• No way to run search-only campaigns
• Brand searches silently inflating your campaign performance

Thomas’s guide is the best resource for surviving within Google’s current restraints. But it’s a tight box. This article is about enhanced app campaigns — a new way to get out of the box.

Why do enhanced app campaigns matter most on Google?

In my previous article, I covered what enhanced app campaigns are and why apps are shifting budgets to them. Quick refresher: enhanced app campaigns (EACs) are web campaigns whose final URL redirects users straight to the app store. No landing page, no web funnel, no SKAN dependency.

This article is the execution manual for EACs — specifically focused on Google, because Google is where EACs unlock the most. On Meta and TikTok, running EACs mainly gets you better measurement and enriched signals. They’re valuable, but the campaigns themselves look similar to what you were running before.

Google is different. On Google, EACs unlock entirely new campaign types that don't exist for app advertisers:

• Search: bid on specific keywords and search terms, and see revenue and ROAS at the keyword level. GAC technically serves on search, but you don't choose the keywords, you don't see them properly, and you can't exclude them. It's by design.
• YouTube Shorts: get full control over placement types within YouTube. This use case is great for apps that mainly run vertical videos and want to access new inventory without creating new assets.
• Demand Gen: full control over how your budget is spent. If you have winning vertical video or static images from Meta or TikTok, this is a new home for it, same format.
• Display: the largest display network on the internet, with placement-level control.
• Performance Max (PMax): Google's all-inventory automation product, once your conversion signals are strong enough to feed it.

One important thing to note is that running enhanced app campaigns on Google Ads does not allow you to reach the Play Store inventory on Android devices. So this is a constraint you should keep in mind.

With GAC, Google's algorithm decides everything: placements, keywords, audiences, budget allocation. You upload assets, set a bid, and pray. With EACs, you're buying Google inventory the way web advertisers have for 20 years. With actual control.

Across the subscription apps I worked with, the numbers back it up:

• 100% reduction in install cannibalization — because you can now control all brand search terms (more on this below)
• 12% lower CPMs on Demand Gen EACs compared to equivalent GAC placements
• 14% higher ROAS on Demand Gen versus GAC targeting similar placements

Let's get into how it actually works.

Are enhanced app campaigns allowed on Google Ads?

I know this is the first thing on your mind. When we first started running enhanced app campaigns at Appstack, this concern came up a lot. The answer is a clear yes.

Enhanced app campaigns are web campaigns. When you run one, you're using Google Ads exactly as designed: a web campaign with a final URL, a click, and conversions reported back through Google's standard web measurement stack. The fact that your final URL redirects the user to the App Store or Play Store is not a loophole. Deep links and store redirects are a normal, documented part of the web. App stores are websites too.

There is no policy against it. You're not spoofing anything, hiding anything, or exploiting a bug. In my experience, thousands of apps run this structure at scale today, with Google account reps fully aware of it. Google gets paid either way. (And you could argue that they prefer it, because you feed their algorithm richer conversion data than SKAN ever could.)

So no, you won't get banned.

How it works under the hood

Before touching the Google Ads interface, understand the click journey — this is how app install attribution works without SKAN. It's five steps:

1. User clicks your ad: the ad's final URL is a tracking link (app store page), not your website.
2. Instant redirect: the link captures the click (with the Google click ID, campaign, keyword, and ad parameters) and redirects the user to the App Store or Play Store in milliseconds — the user never sees a webpage.
3. Install and first open: the user installs the app and opens it for the first time. On first launch, the SDK matches the install to the click using probabilistic matching. It doesn't depend on SKAN or ATT opt-in.
4. Events flow in: trial starts, subscriptions, renewals, and every event is tied back to the exact campaign, ad, and keyword that drove the install.
5. Signals go back to Google: Conversions are uploaded to Google Ads via API against the original click ID. Google's algorithm now optimizes using previously-matched conversion data rather than modeled SKAN postbacks, which are aggregated and have long delays.

That last step is what makes the whole system compound. Google's bidding is only as good as the signals you feed it, and EAC signals are cleaner, faster, and more granular than anything SKAN can deliver.

For example, you can pass data back to Google Ads hourly and have total control over which signal is mapped to an offline conversion action. A lot of the apps I work with strategically prioritize qualified events, like ‘Trial qualified’, to improve performance.

Setting up your first enhanced app campaign on Google Ads

Step 1: Offline conversion actions

In Google Ads, create web conversion actions for the events you care about. For subscription apps, the standard set is:

• Install (secondary, for diagnostics, not optimization)
• Trial started
• Trial converted (or subscription started, if you don't offer trials)

Set ‘trial started’ or ‘subscription started’ as primary, depending on your volume. Same trade-off logic as everywhere else: more signals vs. better signals.

If you want to know which event to optimize or how much to spend, my answer is to do the math and ensure you get at least 10 conversions per campaign per day. So if your subscription costs $100 and you reach breakeven status (which is great at the beginning), you will need to spend $1,000 per day to meet the threshold.

A quick note on the numbers in this guide: ~10 primary conversions per campaign per day is the floor for learning to stabilize, around 25 conversions is when performance usually starts to improve, and 50 is the minimum before you judge a campaign or change its structure.

With the RevenueCat and Appstack integration, conversions are automatically uploaded to the Google click ID once the account is connected. You don't build any of this pipeline yourself. For a walkthrough, check out this integration guide.

Step 2: Create your tracking links

Running EACs is fully within Google's policies, but building your own tracking links requires Google certification which means a two/three month review of your infrastructure — that’s a long wait, so most teams use a certified partner instead (like us at Appstack).

The tracking link must include all query parameters to properly attribute the data and return the correct information to Google. This is an example of a link:

https://appstack.link/deeplink/resolve?deeplink_id=hPSr3MG7&url={lpurl}&placement={placement}&campaignid={campaignid}&adgroupid={adgroupid}&targetid={targetid}&creative={creative}&network={network}&device={device}&gclid={gclid}&gbraid={gbraid}&wbraid={wbraid}&channel={channel}&adtype={adtype}&keyword={keyword}&keywordid={keywordid}&redirection_url=https://apps.apple.com/us/app/

The link must be set at the campaign level only (no need to add it multiple times across ad groups or ads) and should be located under ‘Campaign URL options’. You don’t need to add any suffixes or custom parameters if the link structure is correct (use the example I provided).

Step 3: Pick your first campaign type

Don't launch everything at once. Here's the order I recommend, based on dozens of subscription app accounts:

First, begin with search-to-app.

Search is the highest-intent inventory on the internet, and app advertisers have been locked out of it for years. With an EAC, you create a standard Search campaign, add your keywords, and set the tracking link. That's it. Users search, click, and land directly on your store page.

Two plays, in priority order:

1. Brand defense first: here's a dirty secret about GAC that Thomas already called out in his guide: a big chunk of its ‘performance’ is cannibalized brand traffic. Someone searches your app's name (a user you already won), GAC serves them an ad, they install, and Google takes credit and your money for an install that was coming anyway. You can't see it, and you can't stop it, because GAC doesn’t give you the keyword control.
2. Then category and competitor keywords: this is where keyword-level ROAS reporting changes how you operate, as you'll know, per keyword, what a subscriber costs and what they're worth. No app advertiser running GAC has ever seen this data. Start with exact and phrase match — broad match plus a fresh conversion history is how you burn a week's budget on garbage queries.

Starting with search-to-app helps you warm up offline conversions at low cost and start getting some ad spend (sometimes the issue is that the campaign doesn’t spend). So my recommendation is to set the campaign to maximize for clicks with a cap if needed. Once you collect some conversions, you can move to maximize conversions or value.

Demand Gen (YouTube and Shorts)

If you have winning vertical videos (or even static images) on Meta or TikTok, Demand Gen is the cheapest expansion you'll ever run: same creative, same format, new audience.

I recommend you structure your Demand Gen into two different campaigns:

1. Create a Demand Gen campaign, select YouTube Shorts as the only placement for a pure Shorts play. You will need to upload the assets to a YouTube account to select them at the ad level.
2. Have a second Demand Gen campaign for the remaining placements (excluding YouTube Shorts). This way, you control the vertical content and avoid placing the same ad in two different campaigns.

Based on the data I can access, Demand Gen EACs delivered 12% lower CPMs and 14% higher ROAS than Google App Campaigns running on comparable placements. The reason is simple: you control the placement, and Google receives better conversion signals, so the algorithm wastes less.

Step 4: Launch checklist

Once you’ve completed the above, here’s your final checks:

• Tracking link tested end-to-end on a real device (click → store → install → in-app event)
• Offline conversion actions receiving data and marked primary/secondary correctly (you need to run a campaign to test that the offline conversion action is actually receiving the right signals)
• Create custom columns using the offline conversion actions to see them in Google Ads
• One campaign, few ad groups — maximum liquidity, faster learning phase
• Budget floor: enough daily spend to generate ~10 primary conversions per day; below that, learning never stabilizes

Feeding Google better signals

This is where subscription apps have an unfair advantage, and where most of them leave money on the table.

Google optimizes toward whatever conversion you tell it to optimize for. Most apps tell it ‘install’, which is like training a hunting dog to fetch anything that moves. Installs are cheap and mostly worthless; what you want is subscribers.

With EACs, the events you can optimize toward are only limited by what your backend knows:

• Trial started: the volume play. A good starting point for most apps.
• Trial converted: the money event. It fires days after install, when the user isn't in the app. That makes it nearly impossible to send reliably through SKAN without a custom server-side setup, and trivial through an EAC, because the postback is an API call rather than a device-side postback. Although I don’t recommend optimizing for ‘Trial converted’ (due to the delay in the event), you can configure this event as a secondary action to improve performance.
• Trials qualified: trials filtered by early engagement signals that predict conversion. Best of both worlds: more volume than converted trials, more quality than started trials.

If you're on RevenueCat, this entire layer is free work. The RevenueCat + Appstack integration forwards server-to-server events (trial conversions, renewals, cancellations) directly into the attribution pipeline. No SDK event mapping, no developer time, no risk of a codebase change silently breaking your events. RevenueCat is already the source of truth for your revenue; this just wires it into your ads.

The compounding effect is real: better signals → better bidding → cheaper subscribers → more conversion volume → even better signals. Apps running GAC are stuck feeding Google delayed, aggregated, threshold-gated SKAN data. You're feeding it revenue events straight from your backend, tied to the original click, in near real-time. Same auction, different weapons.

When to judge, when to scale, when to kill

Most EAC setups don't die because the strategy is wrong. They die because someone judged a campaign at the wrong time, with the wrong metric. So instead of a generic ‘be patient’ speech, here are the rules I give every app I work with:

Judge brand search in days, not weeks.

• Brand campaigns have no learning curve worth respecting: intent is maximal, and volume is predictable.
• If it isn't printing cheap installs within the first week, the setup is broken (link, match types, store redirect), not the strategy.
• Debug, don't wait.

Judge category search and Demand Gen at the ROAS level, never at the install level.

• Give them two to three weeks and at least 50 primary conversions before touching anything structural.
• During that window, your only job is to cut obvious garbage: irrelevant search terms and placements that make no sense. Everything else stays untouched.
• Use cohorts to actually see if more money is hitting the bank account than what is going out.

Kill keywords with data, not vibes.

• This is the muscle GAC never let you build.
• 200 clicks, decent CTR, zero trials: Dead. Kill it without mercy.
• Expensive installs but strong trial-to-paid conversion: Keeper, even if your CPA dashboard says otherwise.
• You now have keyword-level ROAS. Use it as the judge, jury, and executioner.

Scale winners vertically before expanding horizontally.

• Raise budgets and bids on proven keywords and placements before adding new campaign types.
• Only once Search and Demand Gen are profitable do you open Display (isolated, audited weekly) and eventually PMax.
• Expanding while your core campaigns are still learning splits your conversion volume and slows everything down.

TL;DR: key takeaways

We covered a lot in this article, so let’s recap on the top points to remember:

• GAC is the legacy way; no keyword control, no keyword reporting, brand traffic silently inflating performance. EACs are the way out of the box, not a hack inside it.
• This is 100% allowed. EACs are standard web campaigns with a store redirect. No policy issue, no gray area, no ban risk.
• Start with search-to-app brand defense. Less install cannibalization is the fastest, most measurable win in this entire playbook.
• Recycle your Meta/TikTok winners into Demand Gen. Same assets, new audiences and segments at a lower CPM.
• Your signals are your moat. Optimize toward trial started or qualified trial, not installs, and send trial converted as a secondary signal.
• Google Ads has always had the inventory. What app advertisers were missing was the control and the data to buy it intelligently. Now you have both.

The main plugin now ships 24 skills, a second plugin adds 20 skills for Google Play Billing, and the new RevenueCat CLI gives agents another way to reach your account. Most of the new skills take your agent past the integration step, into work you used to leave your editor for. The difference from Rico, RevenueCat's own agent, is whose agent does that work: the toolkit equips the coding agent you already use, with your codebase as context.

In this article, you'll explore what's new in the AI Toolkit since launch: the RevenueCat CLI, reviewable plans for store products, paywalls designed with your codebase as context, experiments, SDK compatibility checks, the new analytics skills, the Play Billing plugin, and how to install or update the toolkit.

The RevenueCat CLI: Beyond the MCP server

Until late August, every skill assumed that the MCP server was the agent's only connection to RevenueCat. The RevenueCat CLI (rc), in public beta since August 25, adds another one. It manages projects, apps, store credentials, the product catalog, customers, and paywalls from the terminal, and it behaves the same way whether a person, a script, or an agent runs it.

brew install RevenueCat/tap/rc
rc auth login
rc projects use

For CI and agent sandboxes, the @revenuecat/cli npm package ships the same native binary, and npx @revenuecat/cli <command> runs any command without installing anything. Scripts can skip the browser login by passing a RevenueCat API v2 secret key through the RC_API_KEY environment variable.

Three details make the CLI practical for an agent. Every command describes itself at runtime through rc commands --json and rc schema, so the agent discovers flags from the binary instead of guessing them from its training data. Every command also supports --json, and in that mode errors come back as JSON too, with stable error types and exit codes. And --no-input makes a command fail instead of waiting on a prompt, which keeps an agent or a CI job from hanging.

For CI and agent sandboxes, the @revenuecat/cli npm package ships the same native binary, and npx @revenuecat/cli <command> runs any command without installing anything. Scripts can skip the browser login by passing a RevenueCat API v2 secret key through the RC_API_KEY environment variable.

Three details make the CLI practical for an agent. Every command describes itself at runtime through rc commands --json and rc schema, so the agent discovers flags from the binary instead of guessing them from its training data. Every command also supports --json, and in that mode errors come back as JSON too, with stable error types and exit codes. And --no-input makes a command fail instead of waiting on a prompt, which keeps an agent or a CI job from hanging.

rc products store plan <app-id> --file prices.csv
rc products store show <plan-id>
rc products store apply <plan-id>

You can ask for the change and the file in one request:

"Raise the monthly Pro subscription to $12.99 in the US on both stores. Write the desired prices to store/prices.csv so I can commit them, then walk me through the plan's diff."

Paywalls: Designing with your codebase as context

The revenuecat-paywall skill from launch covers presenting a paywall in your app with RevenueCatUI. The new revenuecat-paywall-design skill works on the paywall that RevenueCat serves to that code: creating, duplicating, editing, evaluating, and auditing it.

This is where a coding agent has an advantage: it can read your app. When you ask for a new paywall, the skill has the agent gather context from two places. From your RevenueCat project, it reads offerings, prices, and existing paywalls. From your codebase, it picks up premium features, brand colors, visual direction, and tone. The agent passes what it found to the create-paywall-ai MCP tool as codebase_context, the part of the request that needs an agent inside your repository, and RevenueCat's Paywalls AI Editor generates the draft from it. The result is always an unpublished draft, and generation can take several minutes when it creates images.

Other requests use a different tool on purpose. When you ask for a copy of an existing paywall, the agent uses duplicate-paywall, which copies the original instead of regenerating it from a description and losing its images and structure. Changes to an existing paywall go through edit-paywall-ai.

To evaluate a paywall, the agent renders it with render-paywall-screenshot and reads its exact configuration with get-paywall. The audit follows an order of impact: it starts with the call to action, moves through how clearly the recommended package stands out, price anchoring, content above the fold, and trust signals, and leaves copy for last.

"Create a paywall for my new premium offering that matches the app's colors and highlights the features behind the Pro entitlement, then audit the draft."

Experiments: From setup to results

The new revenuecat-experiments skill teaches your agent to prepare an experiment with the MCP server's experiment management tools. A RevenueCat experiment compares two to four offerings, and the skill keeps the variants identical except for the one thing under test:

• Control: when the control is what production serves today, the agent uses the current offering directly instead of copying it.
• Price and trial tests: prices live on store products, so the treatment needs its own products. The agent reuses products that already exist, creates the missing ones through the store state flow above, and swaps them into a copy of the control offering.
• Paywall tests: the agent duplicates the offering together with its paywall and edits only the part under test, using the paywall tools above. This needs a RevenueCat paywall on the offering. If your app draws its own paywall, there's nothing on the offering for the skill to edit, so the variants have to come from your app's code instead, for example a paywall that reads each offering's metadata, and that's code your coding agent can write.

The experiment is created as a draft, and the agent starts it only after you confirm, because starting it enrolls real customers. Pausing stops enrollment but keeps serving enrolled customers their variant. Stopping is final: enrolled customers fall back to the default offering, and the experiment can't be restarted.

Experiments also depend on your app. They only split customers evenly if the app displays the current offering it gets from the SDK rather than a hardcoded one. Checking that means reading your code, which your coding agent already has open, and the experiments skill doesn't check it on its own, so ask for it:

"Set up a price test on the annual subscription: keep the current offering as the control and try $49.99 instead of $59.99 in the treatment. Before you create it, check that the app displays the current offering instead of a hardcoded one."

Once an experiment is running, the experiment analysis skill reads it in a fixed order:

1. The experiment's setup.
2. A screenshot of each variant's RevenueCat paywall.
3. Chart data from the same period, such as revenue, trial volume, and conversion.
4. The results, which the agent can break down by platform or country.

The chart step gives the agent context that the results alone don't have, such as whether trial volume or revenue shifted across the whole app while the test ran.

SDK compatibility: Checking before you ship

Some RevenueCat features need a minimum SDK version, and your subscribers don't all update the app at the same pace, so before you rely on a feature you need to know how many of them can use it. The revenuecat-sdk-compatibility skill answers that with your own data by combining two MCP tools. list-sdk-feature-gates returns the minimum version of each SDK for every gated feature, and list-sdk-versions returns the SDK versions observed among your subscribers in the last 30 days, including wrapper SDKs such as React Native, Flutter, and Kotlin Multiplatform. The agent compares the two and tells you what share of your recent subscribers is below the requirement.

"Can I enroll existing customers in an experiment? What share of my subscribers are on an SDK version that doesn't support it?"

Analytics: Answers without leaving your agent

Several new skills answer questions about your customers and metrics while you work on the app. revenuecat-audiences filters your customers by product, spend, country, attribution, or the app and SDK version they run, and links to the filtered list. revenuecat-charts now tells Initial Conversion (a trial or subscription started) apart from Conversion to Paying (a payment made), and it looks up your experiments, offerings, and store state before it names a cause for a change. revenuecat-dashboard-links teaches the agent to link you to the exact dashboard page it's talking about. Three skills step outside the app itself: revenuecat-forecasting projects MRR or ARR month by month from the MRR that comes up for renewal, its renewal rate, and recent new subscriptions, revenuecat-billing covers what you pay RevenueCat, and revenuecat-app-valuation estimates what the app might be worth.

Google Play Billing: A second plugin

If you ship on Android, the revenuecat-play-billing plugin adds 20 skills for the Google Play subscription lifecycle with the RevenueCat Android SDK, covering the purchase flow, plan and price changes, payment recovery, subscription states, webhooks, and security. Each skill is derived from a chapter or appendix of the RevenueCat Android SDK Handbook, and the plugin is synced from the Play Billing Skills repository. [The handbooks article](TODO: link to the handbooks post) covers that handbook, its companion Google Play Billing Handbook, and the skills in more detail.

In Claude Code, install it next to the main plugin from the RevenueCat marketplace:

claude plugin marketplace add RevenueCat/ai-toolkit claude plugin install revenuecat@RevenueCat claude plugin install revenuecat-play-billing@RevenueCat

The plugin is also available in Cursor, Codex, and VS Code. Gemini CLI installs one extension per GitHub repository, so from RevenueCat/ai-toolkit it gets the main plugin only, and the Play Billing Skills README shows how to add those skills to Gemini directly.

Installation: Updating and installing the toolkit

If you already use the toolkit in Claude Code, update it first. Claude Code doesn't refresh plugins from third party marketplaces on its own by default, and installs from before August 19 still use the plugin's old name, RevenueCat, so run both of these commands:

claude plugin install revenuecat@RevenueCat claude plugin update revenuecat@RevenueCat

The first command replaces an install made under the old name, and the second updates one made after the rename. In Codex, which has no rename mechanism, uninstall the old RevenueCat plugin and install revenuecat to keep receiving updates. In Gemini CLI, run gemini extensions update revenuecat.

For new installs, here is where each client stands now:

• Claude Code: installing from Anthropic's official plugin marketplace now delivers the full plugin. Claude Code adds that marketplace the first time you start an interactive terminal session, so /plugin install revenuecat@claude-plugins-official works without adding one. The RevenueCat marketplace, RevenueCat/ai-toolkit, also carries the Play Billing plugin.
• Cursor: the plugin is listed in the Cursor Marketplace, and /add-plugin revenuecat installs it.
• Codex: add the marketplace with codex plugin marketplace add RevenueCat/ai-toolkit, install the plugin with codex plugin add revenuecat@RevenueCat, then sign in with codex mcp login RevenueCat, because installing doesn't start authentication.
• Agent Plugins clients: both plugins ship a manifest that follows the Agent Plugins 1.0.0 specification, so any client that implements it can load them.
• Skills only: npx skills add RevenueCat/ai-toolkit or rc skills install --all installs the skills without the MCP server, for environments that don't support plugins.

Conclusion

The common thread in these additions is that your agent now reaches past your code into the systems your code depends on, and it brings the code along as context. A good first task is one where that context changes the result, such as a paywall generated from your app's own colors and the features behind your entitlement, followed by a careful read of the draft and the agent's audit before you publish.

A skill is a written answer to the question of what should happen first. With that order written down, you can let an agent with access to your store catalog prepare changes to it.

While reviewing all the data, excited to find out what my plants needed (and slightly stressed about providing enough humidity during a London heatwave), I noticed that Willow had a paid subscription. Usually, when a physical product pushes you to also pay and subscribe for an online product, it feels cheeky — you’ve already paid for the thing, haven’t you? But for once, it felt great.

The combination we're used to is physical products where you need a subscription to really make use of them. They’re especially popular in the health category, like the Oura Ring, Whoop, and Peloton. But Willow is different. I got enough value from the physical product alone; so the subscription felt like a genuinely valuable add-on, rather than paying for something twice.

It made me realize how rare that is: a physical product and app coexisting perfectly.

In my 2025 monetization trends piece, I flagged the rise of hybrid monetization through combining online and offline products. Physical goods are one of the most overlooked hybrid monetization techniques, because they're the opposite of what we usually picture when we think of apps.

I've also seen this from the other side — I used to be Head of Growth at an e-commerce brand where we looked into building digital experiences — and have observed five models for combining apps going physical, and physical brands going digital. When done right, I genuinely believe it isn't a trend, but a powerful way to improve your lifetime value.

But before we even get to that, we’ve got two questions to answer.

Why physical, why now?

I touched on physical goods being on the rise last year due to the popularity of hybrid monetization, but there's more to why this is an important and growing trend.

Yes, most apps are still subscription-only: 63.5% of apps offer nothing but a subscription. However, as the number of apps grows, the median realized LTV per payer is lower: $23 per year.

This makes the economics tricky, but physical goods add a way to build on that. Here’s how that looks in practice for my plant app:

• The subscription: £25 per year (about $34 per year)
• The sensors: about £75 ($101) for three sensors (Yes, I looked up how much the gift was worth for this article)

So physical products can extend your LTV hugely. Even as we’ve gotten used to paying more and more for apps these days, physical products still have higher value.

The other reason this is more relevant than ever: web revenue completely exploded in 2025, with 41% of top-tier apps now generating revenue on the web. This makes integrating some form of store or physical-goods upsell easier.

Physical goods can't be natively and easily offered inside your app either: Apple's guidelines (3.1.3(e)) state that physical goods must be sold outside in-app purchases. The upside: they also carry no Apple commission. The downside: if you aren’t used to selling via web checkout, it makes physical products harder to set up and more hidden from users — which is where most physical goods attempts fall flat.

If it's not an integral part of your monetization system, it feels like a bad add-on: a gift shop bolted onto your app, an extra shakedown, or a cheeky ask. So how do you know if this is the right route for you?

Why fair expectations are key to success

I'm not being dramatic when I say there's one question that matters more than any other: what do customers believe they've already paid for?

I wasn't upset by Willow's subscription. Not because I work in subscription apps and love a good subscription, but because I believe I already paid (well, my husband paid) for what my plants needed to thrive. I got that. I learned when they needed water. I learned when they needed humidity, more or less light. Heck, I was even so dedicated to keeping them alive that I took them into the shower, in the hope of helping them through the summer’s dry heatwave.

So before even knowing about a subscription, I had gotten what I paid for.

The subscription was all extra: the data, the history, and the tracking. And I'll be honest, as a data and plant nerd, I am very happy to geek out on that, especially when it comes at a fair price. And as I hope to receive more sensors (they’re on my birthday list), the subscription becomes even more worth having.

Contrast that with BMW, who dropped a subscription for their heated seats after 15 months… Unsurprisingly, the subscription had been controversial from day one, because people buying a car with heated seats do not expect to pay separately to use them.

This is the golden rule for adding physical products to your subscription: fairness is key.

Now, fairness doesn't just come down to whether customers can use your product without paying again. It comes down to whether they expect to.

Take me, for example. I bought a secondhand Peloton last year and eventually canceled my subscription because the classes were becoming too repetitive for my needs and no longer fit my workout routine.

While it's annoying that I now can't use the device to its full extent without the subscription, it still functions as a basic stationary bike. And when I bought it secondhand, I knew up front I would need a subscription to get the most out of it, so it didn't feel unfair. Perception is a key part of whether your physical + digital partnership works.

From there, it's working out where physical fits into your strategy. There are five models I see subscription apps following, split across two approaches.

Approach 1: App first — you started with the app

• Model 1. Brand merch: swag for superfans, built for brand and community
• Model 2. Companion goods: physical items that make the digital product work better
• Model 3. Physical as part of the core offer: the box is part of the subscription

Approach 2: Hardware first — the device came first

• Model 4. Hardware first, subscription attached: the device is the entry point; software is the profit
• Model 5. Membership-native hardware: the hardware disappears into the subscription

Let’s break down each model.

Approach 1: App first — you started with the app

This approach is for app-first companies: you started with the app and then decided to add in physical, for whatever reason.

Model 1: Brand merch

A great example of this is Lingokids, a learning app for children. In 2022, they created an off-screen brand presence through a character store:

Self-care app Finch also did this, selling stickers, clothing, and plushies of their signature bird.

Duolingo has a brand store where the products mostly don't relate to using the app, except that if you're learning chess through Duolingo, you could also buy the Duolingo chess set (which, by the way, is ridiculously adorable).

The key thing about this model is that it's more about marketing than monetization. Duolingo said it on the record: yes, merchandise sales doubled two years running, yet "sales is secondary to spreading brand love". Not all apps build a strong brand connection, and not all apps need one. But for those that do, related merch can be a value add or, in some cases, even the basis of a referral scheme.

For example, Ladder, an app for personalized workout plans, has a merchandise store where you can buy merch with credits earned from referring other users.

Model 2: Companion goods

The next model is where added products create value but, again, aren't a must. It's a sweet spot: loyal users can get extra value from your app by buying your products, but they don’t need the physical product for the app to function or deliver its core value. Companion goods can also often be bought elsewhere.

Reading.com, a reading app for young children, created printables that you can buy as an extra. COO Tim Dikun shared on the Sub Club podcast that about 20% of people starting a trial or purchasing on the web take the $9.99 upsell. But their biggest physical good, in my opinion, is their Amazon books:

These had two purposes:

1. People were asking for them: parents often re-read the books with their children, and they liked the idea of a physical book to hold rather than doing everything on a screen
2. Amazon is additional exposure: a new platform, new reach, and a potential way to get discovered by people who never would have found the app

Two birds, one book!

Another great example is BetterMe, a personalized wellness app. As you go through their onboarding flow on the web, you get offered a Pilates kit with all the things you need to use their app. If you're new to Pilates, or at least Pilates at home, you probably don't have much of this equipment, so this add-on can be really valuable. And if you do, it’s an optional extra rather than a must-buy.

Model 3: Physical as part of the core offer

Here is where the lines start to blur. The app still often has value by itself, but the physical is a huge part of the offering. Arya, an intimacy concierge app, is a great example: you get a box of products delivered, and then the app provides guidance to help you through it all, with instructions on how to use them.

Another example is Chatbooks, which turns your camera roll into monthly photo books. The lines are blurry here: is it a subscription app or a photo book subscription? I’d argue the app is the key part because their value proposition is the ease of turning your camera roll into books and the app is the key way they do that:

Yet their subscription in the app is for a number of books per year, making the distinction between app and physical product very confusing:

In this model, physical goods are no longer an add-on but are becoming a bigger part of your business. Arya’s app value comes from the box that is delivered and from guiding you through it. Chatbooks' value is turning your photo roll into a photobook. Neither works without the physical goods. You'll need more of an operational system in place as a result because it will be near 100% of your subscribers ordering/receiving physical goods, vs. what could be a few percent for model 1 or 5–20% for Model 2.

Then there are the apps where the hardware comes first.

Approach 2: Hardware first — the device came first

One of the toughest things about physical goods is their margins. I've seen the margins of e-commerce and of apps, and they are night and day.

Peloton shares this openly on the hardware side: even though we could all agree their equipment is expensive, they only made a 13.4% gross margin on hardware in Q4 FY26, compared to 73.6% on their subscription. Hugely different. This is where expensive-to-make hardware boosts its value with a hardware subscription.

Model 4: Hardware-first with subscription attached

In this model, you buy the hardware first, then add a subscription. My plant care app and sensors from Willow follow this model. Likewise, Peloton fits into this bucket. Another popular hardware-first product is the Oura ring, where most revenue comes from the hardware (roughly an 80/20 hardware-to-subscription split), but the subscription is a growing part of the model.

Another good example is Skylight, a digital photo frame. The irony is that on their landing page, they promote that no app or subscription is needed.

And it's true, you can use the frame without a subscription. But the app allows you to do so much more, such as:

• Sharing videos and photos
• Managing remote settings via the app
• Creating photo albums and mirroring slideshows on any screen

Their digital calendar product goes further, with additional app-based tools such as meal planning and chore tracking. You buy the frame first, but the app provides the extra value. And according to the numbers their founders shared on the Sub Club podcast, while the app is only 10% to 20% of their revenue, it's about half their profit.

They keep their fairness principle in mind, though: what the customers bought the device for — displaying digital photos — stays free.

Model 5: Membership-native hardware

The most integrated model for combining offline and online products is membership-native hardware: you aren't paying for the actual hardware, just for the subscription.

This is the Whoop example, where 85% of revenue is the subscription. You get the device for free as long as you have a subscription. About 10% of their revenue is from selling accessories, like paying for a specific band: physical goods layered on top of a membership core.

For this model, if you stop paying, the device either stops working or has to be returned, but that's the deal you knowingly signed up for. Nothing you were originally promised is taken away.

This model is arguably the hardest to get right, because hardware typically runs on slim margins. Look at Mirror: the interactive fitness mirror cost around $1,500 upfront and still required a monthly subscription. Once the pandemic’s at-home fitness fad faded, demand dropped off. Lululemon, which had acquired the company for $500 million in 2020, shut it down in 2023.

That's a simplification of the story, of course. The pandemic-fueled boom in at-home fitness inevitably faded — we saw the same thing happen to Peloton — but it also highlighted just how difficult it is to build a sustainable business around both hardware and subscriptions. Tellingly, Lululemon then partnered with Peloton to offer digital fitness content instead. It kept the subscription and dropped the hardware.

Where do hardware subscriptions go wrong?

It's not just the high cost of hardware that can make this tricky to get right. It's the fairness question we started with. A hardware subscription feels fair when customers can keep using what they bought without paying again, unless ongoing payment was clear from day one. But there are a few cautionary tales to consider when planning your approach.

1. Grandfather with double care

Take the Snoo, a $1,700 smart bassinet. It's an expensive purchase for something babies typically use for only six months, so many parents justify the cost knowing they can resell it afterward. When Happiest Baby added a $20-per-month premium subscription in July 2024, it tried to handle the change fairly: anyone who had already bought a Snoo kept those features for free.

Except that's where things fell apart. The grandfathering applied to the original owner's account, not the device itself. Overnight, a used Snoo no longer came with the same features it had the week before. Secondhand buyers suddenly had to pay extra for functionality the product was advertised to have, while original owners saw the resale value of their bassinets fall. Technically, nothing had been taken away from existing customers. In practice, though, the promise of ownership had been broken — just one transaction downstream.

The lesson: if you change the deal, let existing customers keep the old one for as long as possible. And don't just think about your direct customers either. If your product has a healthy secondhand market, price or rule changes may have an additional negative backlash.

2. Never break a core function

Another cautionary tale is Whoop. For years, the company advertised free hardware upgrades after six months of membership. But when it launched the Whoop 5.0, members suddenly found that upgrading required either a 12-month membership extension or a $49–$79 fee. After widespread backlash, Whoop reversed course. The episode showed that fairness isn't just about the fine print; it becomes anchored to whatever promise customers have come to expect, even in a subscription-first business.

The lesson: if you're selling a physical product, customers should always be able to keep using it without paying another penny, unless ongoing payments are clearly part of the deal from day one (like in Model 5).

3. Price under the disgust line

Skylight lived this one. They doubled their Calendar subscription from $39 to $79 with minimal impact on attach or retention. $99 penciled even better on paper, but their customer research put it firmly in "not worth it" territory, so they stopped at $79 and left the money on the table, as they shared on Sub Club.

There's a difference between what will maximize revenue and what will build lasting trust. I've always said that high prices come with high expectations, but they also raise the stakes: when someone has already paid a premium for a physical product, they're far more likely to feel cheated if they're asked to keep paying to unlock or maintain its core value.

The lesson: In theory, you can often charge more by treating the hardware and the subscription as separate products. In practice, bundling them too aggressively can damage the relationship with your customers. Sometimes it's worth leaving a little money on the table in exchange for stronger retention, better word of mouth, and the reputation that comes from treating customers fairly.

4. Communicate what the money funds

Oura learned this one the expensive way. In 2021, they put previously-free metrics behind a new membership and asked people to trust that the fee would fund ongoing development, before showing any of it. Even with free lifetime memberships for Gen2 upgraders (which some rumors say were the ‘cost’ of the change), the move drew backlash. Five years later, the same subscription barely raises an eyebrow, because now their CEO can point at receipts: 14 new features and two integrations shipped in a year, framed explicitly as what the membership pays for.

The lesson: A subscription for a hardware product feels fair if the money visibly maps to something being made or added (e.g. storage, data, calculations) or the improvements it enables. If you can't point to what shipped or is improving, users may question it.

Note that with all of this, the takeaway is not ‘don't do physical goods’. It's really ‘think through all the levels of fairness and what the expectations of your customers are’. And keep these four rules in mind.

The e-commerce economics app people underestimate

A final consideration before you go down this route: keep in mind what it's really like to run an e-commerce business. I've worked closely with so many e-commerce founders and know the horror stories of running out of stock, high returns because of issues, couriers letting you down, and more.

There's a reason I love apps — and only work with apps these days: none of that, and all of the data.

In exploring this world, keep in mind what the margins look like. They will often be far lower than digital subscriptions. The risk and work around returns, inventory, and stock management is huge, and so are the cost and effort of building up fulfillment.

We haven't even touched on the technical setup of it all, with many apps going down the route of either building a Shopify store or working with a third-party distributor. (You can use tools like Stripe on this side too, but it's worth exploring the setup upfront.)

I believe the most successful apps win with a physical product when it fits the experience, gets your most valuable customers to spend even more with you, and builds retention loops.

Five questions to get you started

So, are physical products right for you? Which approach should you consider? These are the five questions to ask yourself:

1. Do your superfans already ask for merch? (Model 1 is permission, not strategy)
2. Is there a physical object that would make your digital product work better? (Start at Model 2)
3. Would your subscription survive shipping delays? (Go to Model 3)
4. If you sell hardware: what did the customer buy, and does it work forever without you? (Model 4)
5. Could you afford to give the hardware away? (Model 5 is a financing model, not a product decision)

I never expected to be attached to a plant sensor. To be curious what Downstairs Denise had to say about the lighting situation, to experiment with placement, or even to shower with a plant. I also never expected to be happy to pay a subscription on something that’s already doing its job. But I am, because my little sassy plants keep showing me that the subscription adds extra value: I get to track them over time and see the impact of learning and taking better care of them.

I don't feel obliged to subscribe. But as I buy more sensors, it adds value. It all comes down to fairness and thinking through (from your customer’s perspective) what they should or shouldn’t ‘need’ to pay for. I shouldn't have to pay for an app when receiving a gift, and I don’t. But I want to pay to learn, to nerd out on all my plants' data, so I’ll happily pay. The offer was worth it for me as a customer. This perspective is where you need to start.

Watch on YouTube

The explanation came from the audience data. "Is the average person watching? UFC is doing so on their couch as they're drinking beer and eating pizza with their friends," Jake says. "The last thing they want to think about is tracking their calories, because that's just like going to give them bad news." Mukbang creators, who eat 10,000 calories in a sitting, were the same mistake from the other side: viewers watching someone else's cheat day are planning their own, not counting it.

What replaced the on-paper logic was a method anyone can run from their phone. "Views can lie. Followers can lie, but comments cannot," Jake says. For a niche, read the comment sections of its biggest creators and look for people asking for a solution your app solves. For an individual creator, the comments separate the one in ten who converts from the nine who don't. Two women post the same leg-day routine; under one it is fire emojis from men, under the other it is "thank you so much for posting this video. I was really unsure of how to work out my hamstrings or quads or glutes." Jake's line on which one converts: "I think it's pretty obvious which one will."

The magic moment test

Before any of that, Cal AI had to pass a test of its own. "What we called it was the magic moment," Jake says. "It was like a one, two, three punch. You scan, analyse results." When a fitness creator making a what-I-eat-in-a-day video scanned a plate on camera, viewers did a double take, and the double take is what sold the app. "If your app doesn't have a magic moment, it doesn't lend itself well to a seamless integration because it's not going to cause that double take." An app that needs a paragraph of explanation should run paid ads with a hard sell instead, because "if it feels like an ad, it's not going to go viral. If it's not going to go viral, it's not going to be profitable."

The test shaped details most people copying the playbook never saw. A streaks pop-up fired after the first scan of the day and broke the three-beat rhythm, so "we would make sure our influencers didn't show their first scan of the day." Creators with subtle integrations got an on-screen caption naming the app; creators whose integration was already obvious didn't, because the caption cost views. A dedicated creator build put the logo on every screen. "No marketing program should ever feel like a finished product," Jake says.

The one number that caps what you can pay

The deal math starts with revenue per thousand views, which Jake says is easy to find early on: with nothing else running, a creator's post shows up as a spike in a flat download chart. "Once you get that number, it's like you can't pay like a CPM that is higher than that RPM. Otherwise you are guaranteed to not be profitable." Creators will push back. "They may say no, like that's not I want to get paid more. But it's like you need to understand there is no other no other alternative."

From there the structure follows the shape of the returns. Break-even is set by average views; the profit is in the outlier. "Where you make your real money is when they have like one video go mega viral. And like all that is profit," Jake says. "So whenever possible, I would try to do flat rate deals because it allows you to capture the asymmetry that is algorithmic content." The creator in the byline is the case for it, and for the bets Jake says the UFC miss never stopped them taking: signed somewhere around the 12th or 15th deal on the strength of his content, doing "like 10,000, 12,000 views" for two months, then "month three, he had a video get 7 million views and then like for like from that point forward, it was like never under 500,000 views." Jake's framing: "A cult like following is a lagging indicator. If you're a great creator. The cult like following will come." Sign before it does, and the price is lower.

At scale the same discipline became a system. Cal AI had "50 to 70 influencers posting on a day," which makes attribution murky, so Jake built what he calls a renewal score that weighs the secondary signals before anyone gets re-signed. He ran it from spreadsheets for a long time, and is releasing the software he eventually built in its place at the end of October.

Jake Castillo on why the Cal AI clones were never going to make it

Cal AI posted its wins and losses on Twitter as they happened, and clones followed. Jake wasn't worried. "We knew that if people were building a Carly clone just because they heard about our success, they were never going to make it," he says, Carly being the transcript's rendering of Cal AI. "The reason why we were successful was like, we were obsessed." He was dreaming about influencer deals, and the obsession produced "a bunch of little, small, incremental improvements in those small incremental improvements compound over time to be an insurmountable mountain that competition can't climb." The Twitter threads about clone revenue sent traffic to Cal AI anyway.

He is equally direct about people copying him. "The easiest way for an app founder to blow a ton of money is to copy what I did or copy what you saw on a podcast because like, my app is not your app." The creator thesis worked because health and fitness has more creators than any other niche and almost no brands for them to work with, and those creators were already filming the food Cal AI scans. An astrology app, he points out, has a few hundred creators and the rival astrology apps have probably already signed them to exclusivity. The price is the other thing not to copy. Cal AI sat among the cheapest calorie trackers at roughly $30 a year because, in co-founder Blake Anderson's framing, "we're not optimising for profit. We're optimising for mindshare," and because a young audience that hasn't lived with the problem for long won't pay much to solve it. Different audience, different answer.

In the full episode, Jake also explains why Cal AI's viral creator posts underperformed as paid ads until the team made dedicated creative, how a five-star hotel lobby with a rickety elevator explains funnel congruence, and what he can and can't say about the MyFitnessPal acquisition.

Here's a quick breakdown of what's new:

• Paywall AI Editor v3: get from idea to working design faster with new starter screens, better image generation, and custom variables created right from the conversation
• Multi-step awareness: the AI Editor now sees your whole multi-step paywall while you edit any single screen
• Custom components: build your own components that read your paywall's Offering, Packages, and variables, and react when they change
• Localized images: assign a different image to each locale, including light and dark variants
• Foldable previews: preview folded and unfolded layouts for the upcoming iPhone Duo and the Galaxy Z Fold7
• Paywall interaction callbacks: send interaction events from native and hybrid SDKs to your own analytics tools
• Custom-paywall views in charts: see inferred views of your custom paywalls in the Conversion, LTV, and Abandonment charts
• Faster housekeeping: duplicate published paywalls and batch-delete assets in the media gallery

To try the updates, open your project's 'Paywalls' page. Keep reading for the details on each change.

Build faster with the new Paywall AI Editor

The third version of the Paywall AI Editor is out now for all users, with new starter screens and onboarding to help you go from an idea to a working design in less time.

What's new

• Better image generation: generate visuals that fit your design — now including images with transparent backgrounds, and refine them as you work
• Custom variables from the conversation: ask the editor to create the variable your dynamic content needs without leaving the chat; your app still supplies the runtime values, such as customer-specific information
• Awareness of multi-step paywalls: when you edit one step, the editor can see the rest of the workflow, so its suggestions keep layouts and messaging consistent across screens

Explore the Paywall AI Editor and learn about custom variables.

Design for every customer, language, and screen

A paywall that converts in one market on one device can fall flat in another. These updates give you more control over how your paywall adapts to each customer.

More design flexibility with custom components

Go beyond the standard paywall components with your own HTML, CSS, and JavaScript. Build custom comparison tables, animations, and visuals that fit your app’s design.

What's new

• Use your paywall’s data: custom components can now access your Offering, Packages, custom variables, and device context
• Update as customers choose a plan: change the content or appearance of your component when a customer selects a different Package

Build a comparison table using your available Packages, or an animation that highlights the selected plan, with control over how it looks and behaves.

Learn how custom components work.

Localize your images, not just your copy

A translated headline next to an English-language screenshot only gets you halfway. You can now assign a different image to each locale — including light and dark variants — all within one paywall, instead of a separate design per language.

Set localized images in the Paywall Editor, on the 'Paywall Localization' page, or by asking the Paywall AI Editor. See how to localize images.

Preview foldable layouts ahead of the iPhone Duo launch

A layout that works on a folded display may need another look once the screen opens up. The editor now includes folded and unfolded previews for the upcoming iPhone Duo, plus previews for the Galaxy Z Fold7, so you can catch layout issues before customers do.

Read more about preparing your paywalls for iPhone Duo.

See how customers respond

Purchase results tell you whether someone converted. The new updates help you understand what happened along the way.

Send paywall interactions to your own analytics

Paywall interaction callbacks are now available across native and hybrid SDKs, so your app can receive interaction events and forward them to your analytics tools. Study paywall engagement alongside the rest of the customer journey and decide what to test next.

What's new

• Interaction callbacks across native and hybrid SDKs
• Real-time listeners in React Native and Flutter for the presentPaywall and presentPaywallIfNeeded APIs

Explore paywall integration options.

See custom-paywall views in your charts

If you build your own purchase screens, the Paywall Conversion, LTV, and Abandonment charts now include inferred views of your custom paywalls. That gives you more context on conversion, customer value, and abandonment without leaving RevenueCat. Keep in mind that inferred views are inferred, rather than directly recorded impressions.

Spend less time on housekeeping

Two smaller updates to cut the busywork between one paywall version and the next.

• Duplicate published paywalls: duplication now works for published paywalls, so a new headline, layout, or offer test can start from a design you know works
• Batch-delete assets: select several assets in the paywall media gallery and remove them at once, making clean-up quicker after a round of design exploration

Ready to get started?

Open your project's 'Paywalls' page to try the new tools. A good first step: Duplicate a paywall you already have, pick one improvement (like a localized screenshot or a custom component built on your Packages), and test that version.

For the SDK features, update your RevenueCat SDK and follow the platform-specific instructions in the paywall integration docs.

Turning visitors into customers takes two things: a clear path to purchase, and reliable data about what happens along the way. This release improves both, with automatic Paddle discounts, custom checkout URLs, and better visibility into which visitors become customers.

Here's a quick breakdown of what's new:

• Automatic Paddle discounts: apply Paddle discounts from URL parameters and target them to specific Packages, with no code entry at checkout
• Custom checkout URLs: point purchase buttons at your own checkout and use RevenueCat Funnels to build the journey leading up to it
• Hashed checkout email in Google Tag Manager (GTM) events: give your downstream tags an extra signal for conversion matching
• Bot filtering: funnel analytics and ad pixels now skip bot traffic, and we've cleaned up affected historical reports
• PostHog funnel events: send web funnel and web purchase redemption events to PostHog to see where visitors drop off
• Workflow awareness in the Paywall AI Editor: the editor now sees every screen in your funnel while you edit one
• Language detection across regional locales: match more visitors to a translation they can read
• Numeric input validation: set minimum and maximum values for numeric answers such as age, height, or weight

All updates are available in RevenueCat Funnels now. Here's a closer look at each one and how to put it to work.

Make checkout work the way you want

Every extra step between a visitor's decision and a completed purchase is a chance to lose them. These updates remove friction at checkout and give you more control over where the purchase happens.

Carry your promotion through to checkout with automatic Paddle discounts

A customer who clicks a promotional link shouldn't have to remember a code and enter it again at checkout.

What's new

• Discounts from URL parameters: RevenueCat Funnels now applies Paddle discounts automatically from URL parameters
• Package-level targeting: select a Paddle discount in the dashboard and apply it to specific Packages, so you control which plans get the offer

For example, you could promote a discount on an annual subscription while leaving the monthly plan at its regular price. Customers who pick the eligible Package get the discount with no extra code-entry step, and your campaign's offer carries all the way through to purchase.

Connect your funnel to the checkout that works for your business

You can now configure purchase buttons in web-to-app funnels to use a custom checkout URL. If you already have a checkout experience you want to keep, use RevenueCat Funnels to build the journey leading up to it, then send customers there when they're ready to buy.

For teams whose checkout requirements previously blocked a funnel launch, this opens a path forward. Work on the questions, messaging, and offer presentations that lead to purchase while keeping the checkout you've chosen.

Make acquisition decisions with better data

Knowing which campaigns bring paying customers is essential when you decide where to spend your next acquisition dollar. These updates improve purchase matching, remove misleading traffic, and show you where visitors drop off.

Match more purchases with hashed checkout email in Google Tag Manager

Funnel purchase events sent to GTM now include the hashed checkout email – an additional signal for conversion matching. With the right downstream tags configured, it can help connect purchases to acquisition activity and give you a clearer basis for judging campaign performance.

RevenueCat loads your configured GTM container on published funnels and sends events into its data layer. You control how those events map to your analytics and advertising tools. See the GTM setup guide for more info.

Only see real prospects with bot filtering

Crawlers inflate visitor counts and make conversion rates look worse than they are. Now, you can evaluate the behavior of real prospects and avoid changing a funnel, or cutting a campaign, because automated traffic distorted the results.

What's new

• Bot filtering: funnel analytics and ad pixels now skip bot traffic
• Historical cleanup: we've cleaned up affected historical reports

Find where visitors drop off with PostHog events

If your team uses PostHog, you can now analyze web-to-app funnel behavior in the same place as the rest of your customer journey. The PostHog integration now receives web funnel events and web purchase redemption events, alongside the purchase and paywall events it already gets.

See how visitors progress through your funnel, find where they leave, and connect more of the journey from web purchase to redemption. That gives your next experiment a sharper focus.

To turn it on: Open 'Project settings → Integrations → PostHog', enable 'Send funnel events to PostHog', and set the event names to match your reporting conventions. Web purchase redemption has its own event-name setting.

Build funnels that are easier to complete

A few smaller updates help your funnel speak the right language, collect better information, and stay consistent as you edit.

• Workflow awareness in the Paywall AI Editor: when you edit one funnel screen, the editor can now see the other screens in the workflow. Its edits fit the surrounding experience, so you spend less time keeping messaging and design consistent across steps.
• Language detection across regional locales: RevenueCat Funnels now matches supported localizations using the language part of a visitor's locale, even when the region differs. More visitors see a translation they can read instead of missing it on an inexact regional match.
• Numeric input validation: set minimum and maximum values for numeric answers such as age, height, or weight. Customers catch invalid entries as they go, and you get more reliable data for the experience you're building.

Ready to get started?

Pick the update that matches where revenue is getting stuck:

• Visitors reach your offer but don't buy? Start with automatic Paddle discounts and your checkout setup.
• Need to decide which campaigns or steps deserve attention? Start with conversion matching, cleaner traffic data, and PostHog events.

Not sure which to tackle first? Ask Rico, RevenueCat's AI-powered app growth advisor, in your dashboard or in Slack. Rico can benchmark metrics like trial conversion against apps in your category, flag RevenueCat features you aren't using yet, and answer setup questions from the RevenueCat docs.

Open RevenueCat Funnels in your project to get started, or follow the RevenueCat Funnels guide to build your first web-to-app journey.

We’ve all had it happen: an app is running paid user acquisition campaigns on one specific ad network and getting really bad results. There’s multiple reasons that could explain the performance, but after weeks (or even months) trying to address these issues, the performance hasn’t improved. Eventually, the Founder or CEO asks the questions:

• When should we give up on this channel?
• How far should we go with different testing and experimentation?
• Should we explore cheaper channels?

In my UA playbook for one-person teams, I said to pick one channel and make it a success before even thinking about a second one. But a few months ago I also said on LinkedIn that you should explore cheaper channels if you’ve been trying one channel for three weeks with no results.

So which one is it? Should you persist, or should you move on?

The honest answer is: both, depending on the situation. And that’s exactly the problem. I’ve seen founders killing a channel after five days because “TikTok doesn’t work for us”, and others continuing to burn money on a channel for months because the modeled conversions in the dashboard still look nice.

This decision is only getting harder with new privacy limitations, AI deleting barriers, CPMs increasing, and a whole new generation of app builders shipping apps at an unimaginable speed.

But there is a clear way to decide when to hold onto or let go of a channel — keep reading for my fix, pause, kill framework.

Quitting too early vs. holding on too long

When this challenges comes up, you typically see the same two profiles again and again:

The tourists: They launch Meta, TikTok, and Apple Ads at the same time with $100–200/day budgets while they check hourly delivery. After five days, they discard most of them and only stick with one channel, concluding that the other channels “don’t work for our app”.

When you look at the channels, you’ll see that none of them got a proper setup (campaign optimization goal or creative strategy are often the main mistake) or none of them got enough signals. As Lucas Moscon explained in his article on ad channel diversification, launching more channels doesn’t mean lower risk if your budget, audiences, or team capacity can’t afford multiple learning phases at once.

The loyalists: This is the opposite case — and in my experience, the most expensive one. These are marketers that used to have a working channel bringing consistent growth. For some reason, it stopped working and yet, they keep burning money on it, even when customer acquisition cost (CAC) has been going up for weeks. Sometimes it’s an emotional tie (“it worked last year”), sometimes it’s down to knowledge gaps (the UA responsible “owns” that channel) and very often it’s a data problem: they’re either cannibalizing organic or trusting modeled conversions too much.

To support these people and guide your decisions, you need a clear framework for when a channel deserves more time, and when it doesn’t.

7 Checks to see if it’s you: the pre-kill channel checklist

Let’s be super honest here: most of the time when someone says “this channel doesn’t work for us”, the problem is not the channel, it’s something on the company’s side that is being exposed by the channel. So before blaming the channel or cutting it off, go through this checklist. If you answer ‘no’ to any of these questions, the problem might be on your end.

1. Does your product convert within benchmarks?

First off, is your product converting as it should be. Use the RevenueCat App Health calculator or the State of Subscription Apps report to find the relevant benchmarks for your vertical, then examine:

• Install rate
• Install-to-trial rate or install-to-paid rate (if you don’t have a free trial)
• Trial-to-paid rate

Obviously, if your conversion rates (CVR) are far below your category, no channel will save you. You will just see the same numbers but with different CPMs.

I personally lived this scenario with one of my clients: we tested Google, TikTok, Meta, Apple Ads, even influencers, and we struggled for months, testing thousands of creative angles. Ultimately, our install-to-paid rate was simply too low for the CAC that we needed to achieve in order to sustain business margins. Until we stopped trying to fix that with an introductory offer, and focused on creating a solid activation journey, we couldn’t run paid UA consistently.

2. Does your optimization event have enough volume?

The theory is that you need around 10 events per day (or 50 per week) to exit learning phases. According to my experience, the reality is that after 30 per week, you can judge the quality you get on that channel. However, if you’re running campaigns with $50/day optimizing towards subscriptions, you should expect your performance to fluctuate constantly — because you’re not feeding the algorithm enough signals.

Thomas Petit has said this multiple times: focus on actions that happen within the first 24 hours. 55% of 3-day trial cancellations happen on Day 0, so first-24 hours actions are critical. On top of that, I recommend moving to a proxy event if you can’t afford optimizing directly towards your subscription event.

3. Did you test enough creatives?

We all know that targeting is now done through creatives, not audience settings (with some exceptions) so having a proper creative mix with enough volume is key to really see if your CTRs, hook rates, and hold rates are according to the benchmarks for every user persona you think you can target.

If you tested a channel with three creatives and never rotated them, you didn’t test the channel. You tested three creatives. As a reference, in my $0–500 framework, I recommend starting with 8–10 creatives and rotating the ones that don’t spend every 48 hours in Meta and every 24 hours on TikTok (creative fatigue is much faster there).

4. Is your budget enough for that specific channel?

There are some specific channels where small budgets won’t work. For example in Moloco, you will never see the reality of the channel if you spend $100 a day because the algorithm needs a much longer time and a greater amount of signals to exit the learning phase (minimum is $500/day).

Another example is Apple Ads, where you can’t have a $50/day budget if you want to test 15 generic keywords and 20 competitor keywords. You would need weeks to really figure out the performance. So before cutting a channel off, consider whether your budget is feeding it enough to see any real impact.

5. Are you measuring correctly?

This one is especially critical on iOS. Probabilistic attribution estimates which ad led to an install by modeling aggregated signals (like timing, IP address, and device type) rather than matching a confirmed user ID — so the numbers are educated guesses, not exact counts. This technique and modeled attribution (AEM, ICM, ADC, etc.) can under-report or over-report what a channel is really bringing. I've seen channels that looked unprofitable in the dashboard but were bringing dozens of unreported trials per week when checking the baseline uplift. And I've seen the opposite with DSPs and 24 hour view-through windows. If you haven't checked the baseline before vs. after launching the channel, you don't really know how it performs.

6. Is the delivery going to the right audience?

A cheap CPA can hide a terrible channel, and an expensive CPA can hide a great one. Check the age and placement distribution (when you can) and try to ask basic demographic questions on your onboarding so you can use first-party data to analyze before and after launching a channel.

If the algorithm is sending most of your budget to 18–24-year-olds who start trials but never pay, your cost per trial will look amazing while your return-on-ad-spend (ROAS) goes down. In one of my Meta cases, the core audience was men over 45, and the biggest win was shifting the delivery to the placements where they actually spent time.

7. Are you testing all the possible setups?

This one is critical in some cases: if your subscription app is struggling to convert with app campaigns but your metrics are within benchmarks or close to them, you should test other setups before discarding the channel. In these cases, I always start with app campaigns but in some channels these campaigns don’t use view attribution for example so switching to a web-to-app setup with web sales campaign can really help you to make the numbers work. If this doesn’t work, I always try a web-to-app funnel as the last option since the campaigns for web funnels behave completely different from the CVR perspective.

Your honesty when answering these seven questions makes the difference between profit and losing out. So if, after going through this checklist, you can answer ‘yes’ to all of the questions, then yes: it’s time to look at the channel itself.

5 Signals that indicate that it’s actually the channel

Sometimes the channel is just more expensive for your audience at the moment you’re testing due to multiple reasons (higher competition, seasonality, user behavior within that placement, etc.) and no optimization will fix that. Here’s how to tell if that’s the case:

1. There's a structural cost gap

A few months ago, Meta was struggling on some of my accounts for two to three weeks despite having a correct targeting and setup so I moved part of the budget to a web-to-app campaign in YouTube Shorts through Google DemandGen campaigns. I used the same creatives and the same conversion event but I got a much different result: YouTube Shorts got a CPM of $2–3 while Meta was giving me $7–8.

That’s an almost 3x cheaper (!) inventory without compromising quality (obviously I checked this after doing the switch) which brought my CAC down consistently.

2. The platform broke (and it's not your fault)

Sh*t happens, and sometimes we can’t do anything about it. While this is the least common case, it does happen. One recent case I had was with TikTok after they merged Manual and Smart+ campaigns in one single flow. I compared TikTok and Meta using the exact same creatives during 30 days:

• Travel app: Meta CPI $3–5 vs. TikTok CPI $27.50
• Fitness app: Meta CPI $4.77 vs. TikTok CPI $30.50
• A third app: +$40 CPI on TikTok

CPMs and CTRs were almost the same on both channels so the gap wasn't coming from the audience or the creatives, but most likely from the real-time attribution for iOS after the merge. On top of that, TikTok was reporting 80–100% fewer installs than App Store Connect (it used to be 25–35%), and all the spend was going to one single ad.

Another example: a social casino app with a purchase-optimized Google campaign that had been running since November 2023. We tried to launch web-to-app on iOS, and the whole account got rejected due to a domain issue. After four days without activity the campaign never recovered its performance. Nothing changed internally, but with Google App campaigns, you literally control nothing over placements or creative combinations. So sometimes relaunching and praying is basically the only option.

In these cases, the answer is not ‘kill’, but ‘pause’: stop the bleeding, monitor the platform, and test again when the issue is fixed or you feel ready to have a new headache.

3. There's no incrementality

This is one that really fools many teams. The channel reports conversions and the MMP even confirms them but the business doesn’t move.

If the blended baseline doesn't move after adding extra spend, the channel is not bringing new users — it's taking credit for users you would have got anyway. It doesn’t matter how nice the CPA looks in the dashboard, that's a channel you have to stop (or at least re-test with a much more restrictive setup).

I have seen this with DSPs like AppLovin working with 24 hour VTA windows. I normally go with a six-hour view attribution window, and even then I sometimes see cases like this: when I test static banners on any DSP, they eat my organic conversions. You can clearly see how the organic baseline starts to decrease the exact same day I upload the banners (and the CPA of the campaign decreased by +50%!).

Some of the formats that DSPs recommend are tricky: 320x50, 300x250, and other tiny formats that are normally integrated into the UI of the apps where ads are served. The user in this case is just using that app and the ads are part of the interface... so you end up counting a ‘view’ that is not an effective view.

4. The conversion improves, but the unit economics don't close

Sometimes a channel or campaign type does exactly what it promises, and it still doesn't make sense for your business because of the unit economics.

When I tested Meta ROAS campaigns with AEM for a casino app, the results were really interesting: better age distribution (less spend on 18–24), better CVR, but CPMs were 100% higher than the mid-funnel CPA campaign. We were clearly accessing a more expensive tier of inventory but the CVR improvement couldn't compensate for it. Better users, better conversion, but still worse business overall.

5. The opportunity cost is eating your main channel

This is the silent killer. The reason that most teams overlook when they decide to start a new channel.

Every new channel (and every new ad group) puts pressure on your creative production. A new channel needs new formats, new creatives rotated, new attribution logic, and more time checking data to see the incrementality.

If that pressure comes at the cost of your main cash generator getting fewer fresh creatives or less attention, you're not diversifying, you're weakening what already works.

The decision framework: fix, pause or kill

Once you go through the checklist and the five signals, your channel decision becomes much more straightforward. Broadly, there are three possible ways to move forward:

• Fix: the checklist shows a problem on your side (not enough creatives, events with low volume, budget below the channel minimum, wrong audience distribution etc.). You can fix it and give the channel another full cycle before judging it.
• Pause: the problem is temporary or external: a platform bug, a product change on the ad network side, seasonality, an account issue. Pause, monitor what other advertisers are reporting (you can freely ask about that on growthsociety.co), and re-test once waters are calmer.
• Kill: you have a structural cost gap, zero incrementality after a clean test (following the list of questions from the first section), or a CAC that your LTV doesn't cover even in the most optimistic scenario. You need to kill the channel and move on.

One more thing: killing a channel doesn't mean killing it forever. Channels change a lot; they change the algorithms’ functioning, introduce new campaign optimization goals, new creative formats, and more, so failing doesn’t mean forgetting that channel forever.

I always say that bad performance is never random. There’s always a driver: setups, signals, unit economics… Sometimes channels drive the bad news. Your job is to know which of those you're dealing with before you move the money.

Watch on YouTube

Formula One noticed Box Box, and sent lawyers

Kamal is clear that there is no formal relationship with Formula One yet. The first interaction came from the other direction. "I think the first interaction that we had from Formula One was a legal notice that they sent us," he says. The app was listed as "box, box, club, F1 widgets," as Kamal says it, and F1 is a trademark. It also used the sport's official font, and photos of drivers and cars.

They read the rules, renamed the app, rewrote the App Store subtitle and description, dropped the font, and replaced the driver photos with their own 2D and 3D representations made with outside artists. None of which dented the mood. "We were quite happy about it, that it was not a huge deal," Kamal says. "We knew that, okay, formula one is actually noticing us." Ranjith puts it more bluntly: "Even if it was getting the legal notice. We were happy that they are using the product."

The relationship that did come was with Formula 2. Juan Manuel Correa, a former F2 driver, messaged Kamal on LinkedIn to ask what they were building. The founders had already turned down investors who talked only about money; after two or three calls they decided Juan shared the vision, and he joined the registered company's board as a strategic partner and brand ambassador rather than an investor. At the Abu Dhabi race he showed them his helmet, covered in Box Box logos, and the logo was on his car too. Charlie asks whether they paid for the sponsorship. They did not. "You imagine your logo on the products," Kamal says, "but then again, we saw it on a formula two car."

A Mexican fan's TikTok and a Mercedes tweet did the marketing

Neither founder had a marketing background, and their first guess about the market was India. Then the download spikes showed up in Brazil and the US. Kamal: "We were wondering, you know, why is this happening? How could this happen?" The answer was a fan in Mexico who posted the app on TikTok, a platform the founders couldn't even open from India. The video went to a million views and the downloads followed it across Mexico, Brazil, and the US. The first week brought close to 5,000.

The bigger wave came with iOS 16. Box Box already had home-screen widgets, so when Apple added lock-screen widgets the team converted its concepts and was live on day one. A share-your-lock-screen trend started the same week, and the Mercedes F1 account joined it, asking fans to post lock screens with Mercedes wallpapers. The screenshots carried Box Box's widget with no name on it. "The other Mercedes fans, they were like intrigued, like, what is this?" Kamal says, and the fans who knew answered them. "I think in that one week after the tweet, we had like 250,000 downloads." Haas and Aston Martin followed on TikTok, and the second viral moment arrived when a user spotted the lock-screen widget on Charles Leclerc's phone in one of his own vlogs.

Charlie's read on the TikTok moment is the lesson for anyone building something visual: luck was involved, but the app had to look good enough to catch an eye in a video before any of the rest could happen. Ranjith has a name for that. He designs for the first-open "wow" and for what he calls the multiplayer effect, where "you see the app and you become the UGC" and show it to the next person.

Users asked for a way to pay, so Ranjith designed things worth paying for

The first version had no paywall at all, on purpose. The founders added a WhatsApp support line, bought a SIM card for it, and answered every message, expecting feature requests. What they got was different. "The users were like, you guys are doing such a good job, I would like to pay you," Kamal says. "And you're like slightly taken aback." Charlie's response: it's always a good sign when your users are asking to give you money.

Charging came with a rule. So much had been given away that the founders refused to take any of it back from the community that had supported them, which meant the paid tier had to be built from new things: widget themes, an Apple Watch app, complications. The first goal was small, earning back the $100 developer account fee. The subscription was yearly and timed to the racing season, so a fan pays for a season and decides again the next year.

They priced it, as Kamal remembers it, at $5.99 a year, and users told them it was too little. "You are doing so much, but then you are asking so little," he recalls them saying. "Why don't you add like a place in your app where I can give you more money?" The answer was tiers through RevenueCat, including a higher-priced option, with lower-tier subscribers still receiving some of the new features. The end-of-season survey that settled the pricing drew around 5,000 to 6,000 responses, which Ranjith admits he pads with eight or nine questions when he only wants two or three answers.

Ranjith hides new designs from Kamal, because Kamal builds them overnight

The two met because Ranjith, a designer who doesn't code, posted an F1 widget concept on Twitter after every developer he knew turned him down. Kamal replied: "bro, I'm interested." They had, it turned out, been sharing a wallpaper album with a mutual friend for a year without ever speaking. Ranjith's due diligence was Instagram, where he found a photo of an F1 car tattoo and decided, in his words, "he is the person."

They built the first version in about a month, working, as Ranjith puts it, like Batman: after his US work calls ended at 10 p.m., messages from 11 until 3 or 4 in the morning. The working relationship has one quirk. Kamal is so keen on the sport that if Ranjith shows him a half-finished concept, there's a build in his inbox the next morning. "So I need always to hide from him any new future," Ranjith says. "I'll hide him. And until I finally myself. Oh, this is fine to show him. Then I'll put it there."

Charlie's takeaway is one he gives often on the show: a designer-and-engineer pair forces the design to happen before the code, and the engineering problem of making a beautiful design work is more fun than designing around what's easy to build. Kamal agrees from the other side. The healthcare and fintech apps he'd built before were, in his word, boring; Ranjith's designs were what kept him up at night.

There's more in the episode: the Apple developer centre email that looked so much like spam that Ranjith half expected a kidnapping when he drove there, the day both founders quit their jobs, the end-of-season beta trick that gives fans a cliffhanger, and why the team's second app, Go Club, is blue.

Guest links

• Ranjith Ramanan on LinkedIn
• Kamal Kumar on LinkedIn
• Learn more about Box Box Club
• Learn more about GO Club
• Learn more about Arkade Club

But is that reason enough to send some users to the web?

If fees are your only reason, and you’re not among the highest-revenue apps, the answer is probably no. You still pay Apple, your payment provider charges on top, and even a modest drop in conversion can eat up the savings. Not to mention the extra work of handling refunds, disputes, and customers who don’t know how to cancel.

You’d also be committing to those payment options for 12 months, even if they turn out to cost you more than they save.

For larger apps with brand recognition and enough sales in the EU, lower fees might still save enough to cover the extra billing and support work, especially if in-app checkout converts better than sending customers to the web.

Anyhow. Let’s unpack what we already know.

New commission rates, and IAP is no longer an either/or choice

The new terms change both what Apple charges and how you can combine payment options, applying to sales on EU storefronts (wherever your company is based).

First, developers can now offer alternative checkout inside their app or link to web checkout without removing Apple IAP. The in-app option lets customers pay without switching to a browser, which could mean fewer lost purchases.

But if you offer it alongside IAP, Apple's option must appear at least as prominently, though nothing stops you from pricing the two differently.

Customers still have to choose how to pay, so you’ve removed one source of friction without necessarily removing the others.

With the standard EU IAP commission down from 30% to 26%, there’s also less to save by moving purchases to an alternative checkout.

Apple charges 20% for alternative payments inside the app, just six percentage points below IAP, or 15% for web link-out. That’s a very different deal from the US, where Apple currently takes no commission on linked web purchases, although that remains subject to ongoing litigation.

Here’s what the full fee breakdown looks like for the EU:

What lower commissions really mean for your take-home revenue

At standard EU rates, web link-outs offer the biggest potential fee savings. That gap narrows fast, though.

Your provider takes a share on top, and it adds up quicker than the headline processing rate: on a €9.99 subscription in the EU, Stripe charges around 1.5% + €0.25 to process, 0.7% for Billing, and 0.5% for Tax, so roughly 5% in total. A merchant of record adds about 3.5 points more. And the smaller your transactions, the worse that fixed €0.25 looks.

Suppose you're making €100,000 in EU sales, paying your provider 5%, and losing 5% of purchases because customers have to go through a checkout they don't recognize.

Here’s what you’d be walking out with:

In this scenario, IAP wins in three of the four comparisons. The only path that beats it is a web link-out at standard rates, and only by €2,000 on €100,000 in sales, which a slightly worse conversion rate would wipe out entirely.

Finally, you’d also need to cover maintenance and support. If you use RevenueCat Billing, payment retries, billing emails, a customer portal, and dashboard refunds are handled for you. However, refund requests, chargebacks, and support tickets still take your team’s time.

The 12-month commitment is the biggest catch, but it’s not clear how far it goes

Apple’s developer terms say you elect which payment options you offer, and that election holds for twelve months across all EU storefronts:

“Each election you make applies across all the EU storefronts, and subsequent elections also remain in effect for twelve (12) months.”

So you can’t really plan on simply removing web checkout a month later if the numbers don’t look great. And you need to account for the billing, support, and reporting work even if the savings disappoint.

Rolling it out to a limited audience looks acceptable, as long as the experience stays consistent for the customers who do see it, but Apple’s wording leaves room for interpretation.

Apple’s published terms also don’t spell out how targeting or A/B tests fit into the commitment. This might leave room to test the waters with a smaller group through RevenueCat Experiments, comparing revenue and LTV across IAP, in-app alternative checkout, and web link-out.

So, should you add alternative checkout in the EU?

At the end of the day, there’s no definite rule on whether web billing is something you should try.

On the one hand, it’s not as straightforward as “paying less and saving on App Store fees,” because the reality is more nuanced. On the other hand, the actual impact on conversion, your existing resources, sales volume, and openness to experimentation can make this path more appealing for some developers.

While we’re running new experiments to estimate the impact on conversion, here are some directional tips on how to approach this based on where you are now.

For smaller apps, it may not be worth the trouble

Alternative checkout may not save enough to justify the effort, especially if you’re already paying Apple’s reduced 15% rate. The five-percentage-point difference gets smaller once you pay your provider, and lower conversion rates can wipe it out altogether.

Even if the calculation comes out somewhat positive, consider what that saving is worth against the time you’d spend maintaining another purchase flow. The 12-month lock-in also makes that decision more serious.

Where it might make sense is when the reason isn't revenue at all:

• A pricing model Apple doesn't support, like consumption-based or per-seat billing
• A custom payment setup your use case specifically requires
• Long-term benefits from managing the subscription lifecycle on web, like the pricing and promotion control we cover below

If you have limited time and budget, testing pricing and packaging or improving engagement may do more for revenue at this stage. That doesn’t rule out web purchases, but it gives you something to compare it with before deciding where to put your effort.

For larger apps, there may be more to gain

Web monetization may be worth testing if you have substantial EU sales and the resources to support another billing flow. Especially now that it's no longer all or nothing: under the previous terms, selling outside IAP meant removing Apple's checkout from that storefront entirely. Now you can add web checkout alongside IAP and leave your existing flow running.

The maths also improves with scale, since setup costs don't grow proportionally with sales. And conversion is less of a gamble when customers already know your brand, which is part of why this works for the likes of Duolingo and Spotify.

You don't have to show web checkout to everyone either. Apple's rules govern what appears on each paywall, not who sees it, so you can start with your most loyal customers and keep IAP as the only option elsewhere.

Finally, the value of web monetization goes beyond fee savings if you've already built a growth engine that can use the extra levers:

• Pricing and promotions: Web-specific prices, discounts, and win-back offers applied directly at checkout, without going through App Store Connect
• Checkout experience: Control over the purchase page and the payment methods you offer, with room to test both
• Lifecycle marketing: RevenueCat already sends billing events to your email and CRM tools on IAP. What alternative checkout adds is the ability to act on them — like a win-back email that lands on a checkout with the offer already applied, or a cancellation flow that counters with a different price and takes the payment there

Lower fees come with more reporting. RevenueCat handles that part.

Say you've done the math and decided to enable web purchases in the EU. Under Apple's October 1 terms, your purchase flow has to pass App Review, and every transaction has to be reported back to Apple.

What’s more, that reporting doesn’t end with the first payment. Renewals, refunds, product changes, and cancellations all need to be accounted for.

Even if a customer opens checkout and leaves without buying, the token Apple issued still needs a report.

With RevenueCat, you don’t have to build all of this yourself:

• Reporting: Purchases through the Stripe Billing, Paddle Billing, and RevenueCat Billing integrations are matched to Apple’s tokens and reported automatically, along with subsequent subscription activity and unused tokens.
• Purchase buttons: Apple-styled IAP buttons are built into Paywalls for when you offer IAP alongside alternative checkout.
• Targeting: You can show the alternative-payment paywall on EU storefronts and keep your existing IAP paywall elsewhere.
• Checkout: Your customers can follow a link to pay in their browser, or pay in a checkout sheet inside your app (currently in private beta).

The bottom line

If you have the purchase volume and resources to experiment, web monetization is worth considering. Especially if you also want to test different offers, payment methods, or lifecycle campaigns.

Start with a clear hypothesis about what you expect to improve, then measure conversion, revenue after fees, renewals, and the support work that comes with it.

A lower commission isn’t a reason to rush on its own. In the EU, you still pay Apple and your provider, and you’re committing to your chosen payment options for 12 months. The experiment needs to show whether the savings and additional control justify that commitment for your app.

We’re running our own experiments to understand how the new EU options affect conversion and longer-term revenue. Stay tuned for updates.

Then one week becomes two, two becomes four, and as the graph keeps drifting down, a low-level panic starts to set in.

What’s happening? What are we doing wrong? Whose fault is it?

Every great growth story I've heard has a stall somewhere in it: a plateau, a setback, a period when nothing seemed to work. It's almost never the clean hockey-stick graph we love to post on LinkedIn. #GrowingInPublic — but not that publicly.

Growth stalls are normal, but finding the answers for what causes them is tough. I've experienced it both as Head of Growth at Heights and while advising clients, telling myself the same reassuring things I'm about to tell you. So I know how it feels, not just how to fix it.

What not to do when your app’s growth stalls

It's tempting to play the blame game. Meta is often the favorite culprit, or perhaps a teammate who isn't pulling their weight (or refilling the coffee). But when you dig into the data, most stalls are actually within your control. Research into why companies stop growing found that only around 13% of growth stalls are driven by external factors. The rest come down to internal decisions — and most companies experience at least one major stall.

The worst response is to become a headless chicken: changing everything at once, chasing every new idea, and hoping something sticks.

Instead, I want to help you work through a growth stall methodically, from diagnosing what's actually causing it to getting growth moving again.

The growth stall diagnostic

Think of this as growth therapy. My goal is to reassure you, reduce the panic, and leave you with a clear plan rather than a long list of random experiments.

Over the years, I've developed a simple framework for working through these moments. It comes down to four questions:

1. Is it a blip or a stall?
2. Is it within your control?
3. Where exactly is growth breaking down?
4. What should you do about it?

Most people panic and jump straight to question four. But the real value lies in taking the time to answer the first three questions — that’s what tells you which action will actually work.

Step 1: Is it a blip or a stall?

If we chased every number that dipped for a week, we'd be very fit from all the running around — and completely exhausted.

There’s a lot of noise in growth, especially early on when numbers can swing wildly. So before you panic, define your thresholds: what counts as a real miss vs. normal variation?

If you typically grow 5–10% week-on-week and occasionally dip, is a 20% drop the point where you investigate? The answer will be different for every business, but having those guardrails is how you separate real signals from seasonality and one-off blips.

Seasonality is especially easy to miss. Once you have enough data, patterns start to emerge, and you can look back at a slowdown with more context. I have a client now in their eighth year who told me: “We’ve grown a bit this quarter — not loads — but these aren’t the months we usually grow in, so we’re not worried. We’re using the time to fix things and build our infrastructure.”

That perspective is much harder to have when you’re smaller, which is why you need to look for trends over several weeks, and resist reacting to a single bad one. Don’t obsess over daily swings; focus on week-on-week movement.

And when you catch yourself thinking, “This doesn’t look like a blip anymore”, treat it as a stall. Bring the team together and approach it like an experiment. Start with a pre-mortem: imagine it’s three months from now and growth is still flat. What went wrong?

Step 2: Is the blocker within your control?

Your circle of control is everything you can actually influence: the internal factors that shape your growth.

Things like:

• What you’re focusing on
• What your processes look like
• Which channels you’re investing in
• How you’re positioning yourself

There’s usually more within your control than you think. Then there’s everything outside it:

• Seasonality
• New competitors
• Policy shifts
• Platform changes
• Market saturation

The first job is to figure out which bucket your stall belongs in.

Even when something external is clearly playing a role, the next question is: how do you bring it back into your circle of control? You can’t delete a new competitor, but you can decide how you respond, through your pricing, positioning, product, or messaging.

As the research suggests, external factors are rarely the whole story. Once you’ve ruled them in or out, focus your energy where you have the most leverage: the things you can actually change.

I spoke to a wellness app last year at App Growth Annual that was facing this exact challenge. They told me AI had become an easy replacement with just a few smart prompts. And it wasn’t only a fear; their growth was slowing.

That can feel completely out of your control. But the more useful question is: what parts of the problem are within your control?

The advice I gave them was to go back to their core value proposition and ask:

• What value can we offer that AI cannot?
• What other ways can we help users achieve their Job to Be Done?
• What parts of the experience become more valuable when technology gets better, rather than less?

For example, yes, AI can generate a similar wellness plan. But it’s much harder for it to keep users accountable, automatically collect behavioral data and insights, and continuously adjust the plan based on what’s actually happening in someone's life.

Competing with AI would be like David vs. Goliath, but they can differentiate their app from AI and double down on the parts of the experience that create deeper, longer-term value.

Step 3: Where exactly is growth breaking down?

This is the step people skip, and it’s the one that matters most. Instead of guessing at a cause, audit your growth the way an outside consultant would: look at every part of your funnel and (just as importantly) at how you’re working. It can feel like you’re slowing down when every instinct is telling you to move faster. I promise you, this is the thing that speeds you up.

Start by getting clear on your North Star metric: the one metric that best defines success for your business. What is it, and what inputs actually drive it?

Then evaluate each area separately, as if you were looking at someone else’s company:

• Acquisition
• Activation and engagement
• Retention and revenue
• Monetization
• Team structure and approach

For each area, ask:

1. What’s working?
2. What isn’t?
3. How are these pieces influencing each other?

The trap here is auditing each area in isolation and declaring victory the moment one number improves. Ekaterina Gamsriegler, who led growth at coding app Mimo, has a great example of this: LTV had plateaued while acquisition costs kept climbing, the classic growth-stage stall.

The solution came from understanding the funnel as a connected system. A paywall change shifted which plans users chose, which changed LTV, which then changed how much the company could afford to spend on acquisition. The result: Mimo increased customer LTV by 65% and reduced paid CAC by 20% in under a year.

Ekaterina’s rule applies here too: before any change, ask three questions:

1. What is the first-order effect?
2. What are the downstream effects?
3. What could quietly get worse as this gets better?

The third is about accepting tradeoffs. I've seen price increases give ARPU a big lift, while the number of new customers dropped. Is that a tradeoff you are willing to make?

10 reasons for your growth stall

As you go through each area, it helps to have a list of the usual suspects to compare against what you’re seeing. These aren’t every possible cause, and they’re not a diagnosis on their own, but they are the internal patterns I see behind stalls again and again. And luckily, nine of the 10 are firmly within your control.

Running a growth audit: early-stage startups

If you’re early, keep it simple and go straight to the foundation:

• Do you have product-market fit?
• Do you have an app that at least 40% of users would be very disappointed to lose?
• Are they willing to pay for it?

If that foundation isn’t there, more channels won’t fix your growth. They might create some initial buzz, but they won’t solve the underlying problem.

One place you’ll often see this is in early drop-off. Some churn in the first few days is normal; in State of Subscription Apps 2026, 55% of three-day trial cancellations happen on day zero. But if your drop-off is significantly worse than benchmarks, or stays high even after improving onboarding and communicating your value more clearly, the issue is probably deeper. It’s likely a mismatch between what you’re offering and what people actually need.

Mob, the meal-planning app, is a great example of what fixing that foundation actually looks like. Founder Ben Lebus has spoken openly about how they went from £1.2 million in debt to becoming the number one app in the App Store (I shared their story here). It started with focus: they cut the food truck, the spice mixes, the side apps, everything that wasn’t working, so they could go all in on one thing. Then they spoke to users every week and realized they were a “vitamin” — something nice to have, rather than something people truly needed.

They kept narrowing until they found a sharper Job to Be Done: “When weekday meals keep coming, I want a reliable, low-effort way to choose what to cook, so I can eat well without stress.” From there, they built around that need, and growth followed. Two of the 10 reasons were at play: a lack of focus and overly-broad messaging. Speaking to users is what helped them uncover both.

Running a growth audit: scaling and mature

If you’re further along, you’ve probably got some level of product-market fit, so that’s less likely to be the core issue. The problem is more likely elsewhere: you haven’t found the right channels to scale, your monetization model has room to improve, or early retention starts declining as you expand to a broader audience and need to create more ongoing value.

It can also be that your pricing and packaging were never properly pressure-tested. Reading.com, the kids' learn-to-read app, is a good example. As Tim Dikun, COO of Teaching.com, shared on Sub Club, they tested prices from $4.99 all the way up to $19.99 before landing on $12.49. They also replaced the free trial on their web funnel with a 30-day money-back guarantee. It converted fewer people, but those users sent a stronger, higher-intent signal to the ad networks. They found the answer through testing, not guessing. These are common causes — not the only ones — which is exactly why you audit rather than assume.

And when you look at the numbers, don’t just focus on what happened last week. Zoom out and look for trends over time. Find the moments where something suddenly dropped or jumped, then ask what changed. Compare against benchmarks where you can, but always account for what’s genuinely different about your app, audience, and business model. For quick checks, I like using the RevenueCat App Health Calculator. When I want to go deeper, I use the State of Subscription Apps report for broader subscription benchmarks and trends.

Step 4: Scale, fix, or kill

By now, you should have a shortlist of hypotheses rather than one panicked guess. Step four is working through them, and being honest about what each one needs: scale it, fix it, or kill it. The only way forward is to test them one at a time: does this actually get us back on track or not? Sometimes that takes a few weeks; sometimes it takes months.

Be careful about fixing the wrong thing though — at Mimo, the team initially focused on reducing churn and improving retention before realizing most of their revenue came from new subscribers, and the churning cohort was too small to materially move the needle. They were solving a problem they didn’t actually have yet. The audit is what helps you avoid that trap.

It’s also worth turning the audit on yourself. One of my favorite parts of the Mob story (part two here) is their fourth lesson: at an offsite, the team told Ben — a founder who had poured everything into the business — “let me do my job.” He stepped back, even leaving Slack channels where he wasn’t needed, and the team moved faster. I promise he took it well!

Part of diagnosing a stall is asking honestly whether your own involvement is helping or quietly getting in the way.

When to kill a channel

One rule I give clients for the kill decision: if a channel is sitting at four to five times your target cost of acquisition, and it’s still there after you’ve tried genuinely different approaches – not just new ad copy, but new formats and angles – it’s probably time to make a bigger change or kill the channel. Optimizing the edges of something fundamentally broken just burns time you don’t have.

I’ve seen this happen with Meta Ads all too often. In some cases a major shift broke them out of the endless high CACs: invested in brand awareness, really narrowed down and defined their positioning, or completely revamped their creative or landing page. In others, after trying major shifts they turned to other channels, or focused instead on improving their ARPPU to break out of their growth stall.

A related exercise I love is re-costing your struggling channels to include the team hours they consume. Founders often keep a channel because the media spend looks acceptable, then realize that once they account for everyone’s time, the true cost of acquisition is much higher. Meanwhile, the “boring” channel quietly working in the background was the better investment all along.

And occasionally the honest answer is bigger than a fix. Slack began life inside a games company whose game didn’t work out; the internal chat tool the team had built for themselves turned out to be the real business. Most stalls don’t require a pivot that dramatic, but it’s worth remembering: sometimes the thing you’re trying to save isn’t the thing worth saving.

A growth stall is a gift

They say the hardest moments in a relationship are often the ones that bring you closest — the same is true for growth, and for teams.

A stall is the ultimate test.

• It tests founders: how they react, whether they stay calm or start pointing fingers, whether they create clarity or chaos.
• And it tests the team: can they come together, focus on the few things that matter, and work towards the changes that will actually move the needle?

I recently learned that the best Formula One drivers are said to respond the same way whether they win or lose. They don’t get swept away by the emotion of the result. They step back, review the data, and work out what’s working and what isn’t.

We should approach growth stalls the same way. Don’t panic. Don’t spiral. Look at the data with the same curiosity you would bring when things are going well. You might not find the answer immediately, but finger-pointing, stressing, and trying to fix everything at once won’t get you there. I can promise you that.

Mob is proof of what can be on the other side. The same company that was £1.2 million in debt now has 280,000 premium subscribers and $12.5 million in ARR, not because of one clever hack, but because they worked through the fundamentals: cutting distractions, finding their real Job to Be Done, testing their way to a scalable acquisition channel, and learning when a founder needs to step back.

You come out of a stall with a stronger organization. Your processes improve. Your understanding and control of growth improves. And you usually come away with a few hard lessons too, whether that’s letting one channel dictate your growth, getting so focused on acquiring new users that you neglected retention, or being slow to recognize how much AI has changed your landscape.

It might not feel like it in the moment, but a stall can be a gift. It forces you to understand your business more deeply, build more resilience, and ultimately grow faster and more sustainably.

The biggest apps are moving first. Nearly half of apps tracking $1 million or more in monthly App Store revenue through RevenueCat have tried it, even ahead of the wider rollout.

We analyzed 22 million recorded messages across 309 apps to see how they set up their messages, how often subscribers leave without canceling, and how much those results vary.

Larger apps are getting an early start with Retention Messaging

Among App Store apps using RevenueCat, 44% of those making $1 million or more a month have tried Retention Messaging through RevenueCat. That falls to 17% for apps making $100,000–$1 million a month, and below 5% for smaller apps.

For a large subscription business, even a small improvement at cancellation could affect thousands of subscribers. But these figures also reflect an early rollout: apps currently need Apple's approval to use the real-time Retention Messaging API.

Smaller apps can request access, too. Once Apple approves the request, RevenueCat handles the server side. You'll still need to pass Apple's performance test and get each message approved before it goes live, so build that into your timeline.

What a typical save rate looks like

The save rate shows how many subscribers who see the retention message don’t cancel within 24 hours, or take the offer instead. If you use RevenueCat, this is the same metric as the App Store Save Rate in Charts.

At the median app in our analysis, it was 17%, or 17 in 100 subscribers. That's based on 309 apps that showed at least 100 messages between March and September 2026.

The range between apps is wide. At a quarter of apps, fewer than 10 in 100 subscribers didn't cancel. At another quarter, more than 27 in 100 didn't. And at the top 10% of apps, it was 42 or more.

The save rate is a useful benchmark, but a limited one. It doesn’t show how many subscribers stayed because of the message, since some would have stayed anyway. Someone who cancels a few days later still counts as saved, and the metric doesn’t track whether they renew. (The cancellation data below points the same way.)

Most apps offer a discount or plan switch, but few subscribers accept

Almost nine in 10 apps (87%) in our analysis regularly show subscribers a discount or plan-switch offer when they try to cancel. Yet subscribers accept only about one in 100 of those offers.

Apps combine offers with text messages in several ways. The most common setup pairs text messages with promotional offers (27% of all 309 apps), followed by primarily promotional offers (22%). Another 38% use setups that include plan switches.

Together, these groups account for 87% of apps; the remaining 13% primarily use text.

We count a message type for an app only if it makes up at least 15% of the messages the app sends. So an app labeled 'promotional offer only' may still send a few other types. Text messages may include images. Percentages are rounded.

Between March and September, subscribers saw about 4.3 million promotional offers and 1.3 million plan-switch offers. Based on June–September data, when offer tracking was complete, they accepted only about 1.1% of promotional offers and 0.6% of plan-switch offers.

In other words, subscribers rarely take the discount or switch plans, even though most apps offer those options. Most recorded saves happen without either: the subscriber doesn’t accept an offer, but also doesn’t cancel within the next 24 hours.

One possible explanation is that subscribers are still deciding when they reach this screen. Some may reconsider or postpone canceling without taking an offer. For developers, it’s also worth testing messages that explain which features or benefits subscribers will lose if they cancel, alongside messages offering a discount.

Early data shows no clear effect on cancellation rates

In our analysis, cancellation rates fell at many apps after they introduced Retention Messaging. But comparable apps not using the feature saw even larger declines.

We looked at 64 apps with at least 500 paying customers and compared paid cancellations (excluding trials) in the three months before launch with the launch month and the two months after.

Of these apps, 34% saw their cancellation rate fall by at least 10%, compared with 46% of comparable apps without Retention Messaging.

Besides, both groups were already on a similar downward trend before launch.

Afterward, cancellation rates at apps using the feature fell less than at comparable apps without it: 3.6% versus 7.3%. With 64 apps, a gap this size could easily be chance, so the data doesn’t show a measurable effect either way.

The next step is testing Apple Retention Messaging in practice

Our early data doesn't show a clear, immediate reduction in cancellations from Retention Messaging. We're already working on experiments to understand its impact more directly, and we'll share those findings as they come in.

For developers preparing to try it, the best strategy is to compare different approaches before making discounts the default. Low offer acceptance doesn't necessarily mean the discount needs to be bigger. Price may not even be the issue.

Start with what you know about why subscribers cancel, drawing on cancellation surveys, support conversations, and product usage. Then test messages that address those reasons: a discount for affordability concerns, a different plan for subscribers whose needs have changed, or a reminder of useful features they may have overlooked.

If you do offer discounts, be selective about who sees them. When every subscriber who opens the cancel screen gets one, some may learn that starting to cancel is an easy way to get a lower price. With RevenueCat, you can control who sees an offer, for example by excluding subscribers still in a free trial or those who've already redeemed an offer. Setting up Retention Messaging directly in App Store Connect doesn't offer this kind of targeting.

About the data

This analysis covers Apple Retention Messaging activity recorded through RevenueCat from March 22 to September 20, 2026, with data compiled on September 24.

We identified 406 apps with at least one message. Save-rate and message-setup analyses include the 309 apps with at least 100 messages, totaling 21,960,020 recorded messages. Messages are counted once per subscription per day, so the total does not represent unique subscribers.

The median and percentile benchmarks give each app equal weight. Message-type setup groups use a 15% threshold. Adoption shares compare apps that tried the feature with App Store apps tracking revenue through RevenueCat in the last 90 days.

These are early participants in Apple’s access program, not a representative sample of all subscription apps. The analysis describes recorded outcomes; it does not establish that messages caused subscribers to stay or renew.

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 every chart now runs on the same rebuilt data 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.

Charts v3 is now live in the RevenueCat dashboard.

Watch on YouTube

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.

Why some numbers look different

We’ve also made some improvements to our data definitions, so some numbers in Charts v3 can differ from those in legacy Charts. Here are the three biggest changes:

Subscriptions from every store, treated consistently

We’ve used this opportunity to treat subscriptions from different stores more consistently. Instead of handling each store’s behavior slightly differently, Charts v3 applies the same rules 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”).

The change you’re most likely to notice is in Trial Conversion Rate, which will probably go down slightly. It now only counts direct trial-to-paid conversions. Previously, someone who resubscribed after completing a trial would also have counted as a trial conversion.

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

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
• 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

One thing to note: customers you create through the RevenueCat API don’t have a platform, country, or SDK version attached, so they can’t be segmented or filtered by those dimensions.

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.

Read on for the full rundown of everything on offer.

Sunday, October 18

Welcome to NYC!

📅 4:30–5:30 PM 📍 Details shared after approval

Landed early? Meet local and visiting app builders before the week kicks off, with drinks on the house. Hosted by EHVM, Tangent, and RevenueCat, join for a chilled start to a busy week — sightseeing included (but weather-dependent!). Request to join →

Monday, October 19

Warm Start: An Evening at Othership

📅 7:00–8:15 PM 📍 Othership Flatiron, 23 W 20th Street

A wellness evening for mobile founders and product leaders, pairing sauna and cold plunge sessions with a candid conversation about what it takes to build great mobile products. Come to relax those tense muscles after a busy day, stay for the new connections. Hosted by STRV and RevenueCat. Request to join →

Sail & Scale: The RAGA Launch Cruise by Paddle

📅 5:00–7:00 PM 📍 Details shared after approval

A relaxed evening cruise to kick off New York App Week, with skyline views, drinks, bites, music, and casual app growth conversation. Hosted by Paddle. Request to join →

iOSoho IndieDev Talks

📅 6:00–9:00 PM 📍 307 West 38th Street, Studio 1701 (in person and online)

Practical app growth talks for indie iOS developers, plus community updates, pizza, drinks, and networking. Can't make it in person? Tune in online. Hosted by iOSoho and RevenueCat. Request to join →

Growth Gems & Screw-Ups

📅 6:30–9:30 PM 📍 TALEA Beer, Penn District

An opening-night meetup where consumer app founders and growth practitioners trade their best subscription growth insights (and their most expensive mistakes) over delicious tacos. Hosted by Growth Gems and RevenueCat. Request to join →

AI App Founders Dinner

📅 6:30–9:30 PM 📍 Details shared after approval

No speakers, no agenda. Just good food, good wine, and candid conversation for founders building consumer AI apps. Hosted by Koah and RevenueCat. Request to join →

AI For NYC Hackathon

📅 6:30–10:00 PM 📍 Pursuit, 47-10 Austell Place, Long Island City

A hands-on hackathon where you'll use open data and APIs to build practical solutions for New York City, then pitch your project for prizes. Hosted by Pursuit. Request to join →

Spirits Night: A Growth Leaders Happy Hour

📅 7:00–10:00 PM 📍 Details shared after approval

An open-bar happy hour for B2C app growth leaders to swap the launch flops, flatlined metrics, and failed features teams rarely talk about — plus, snacks and a Superwall-curated playlist. Hosted by Superwall and AppCap. Request to join →

Apps Capital Dinner: Founders & Investors

📅 7:30–10:00 PM 📍 Details shared after approval

An exclusive dinner bringing consumer app founders together with the angels, VCs, PE firms, and M&A and acquisition partners who back and buy apps. Hosted by EHVM and Tangent. Request an invite →

Tuesday, October 20

App Owners Workout

📅 8:30–9:30 AM 📍 Barry's Chelsea

A private workout and breakfast for app founders, CEOs, and growth or monetization leaders to compare notes on profitable scaling, subscriptions, acquisition, and retention. Hosted by Scalebay and RevenueCat. Request to join →

Pickleball Social by Noise & RevenueCat

📅 9:00 AM–12:00 PM 📍 CityPickle Times Square, 1501 Broadway, 8th Floor

A morning of pickleball, coaching, and friendly competition, with snacks and candid conversation about content-led app growth. Hosted by Noise and RevenueCat. Request to join →

Deadly Good Growth Session

📅 9:30 AM–4:30 PM 📍 Superwall, 135 W 20th St, Suite 600

A full-day monetization session for growth and product leaders, with a live paywall teardown, customer panel, lunch, and hands-on demo. Hosted by Superwall. Request to join →

Climb the Paywall

📅 10:00 AM–12:00 PM 📍 Details shared after approval

A beginner-friendly bouldering session where the routes are named after real growth challenges, followed by coffee and candid growth stories. Hosted by An Nayal (consumerxai) and RevenueCat. Request to join →

Women in Apps Brunch

📅 11:00 AM–1:00 PM 📍 Details shared after approval

An intimate brunch for women building, growing, designing, marketing, investing in, and shaping apps, focused on honest conversation and new connections. Hosted by Molly Williams (Wild Minds) and RevenueCat. Request to join →

Scaling Paid Ads from $100K to $1M and Beyond: Q&A for Growth Operators

📅 2:00–3:30 PM 📍 Details shared after approval

A no-slides Q&A on scaling paid acquisition, covering creative systems, predictive LTV, unit economics, and the dashboards behind more than $100M in ad spend. Hosted by Tyler Scheviak and Will Kent. Request to join →

Oversubscribed

📅 4:00–6:30 PM 📍 One Times Square

An invite-only gathering for C-suite product, growth, and revenue leaders at consumer subscription apps with $100M+ ARR. Hosted by RevenueCat, Houlihan Lokey, and Goldman Sachs; invitations are issued directly.

Women in Apps Art Cafe x the gapp

📅 4:00–6:00 PM 📍 Details shared after approval

An intentionally small art cafe for women working in apps to put their phones down, paint ceramics, and meet the people behind the products, campaigns, and growth charts. Hosted by Larissa Morimoto and the gapp. Request to join →

App Week Padel: Founders Racket Club × RevenueCat × Paddle × BlueThrone

📅 4:00–7:00 PM 📍 DUMBO, Brooklyn

An intimate padel session for founders, executives, and app builders to play, meet, and connect away from the conference floor. Hosted by Founders Racket Club, RevenueCat, Paddle, and BlueThrone. Request an invite →

The Pre Game Audit

📅 4:30–6:30 PM 📍 Details shared after approval

A casual pregame with free drinks, app owners, and growth practitioners. Bring your app for a live audit and leave with practical ideas for your growth plan. Hosted by Fload. Request to join →

(H) Appy Hour with Botsi

📅 4:30–7:00 PM 📍 Hell’s Kitchen

A relaxed happy hour for app founders and growth leaders, with free drinks, food, and a private lounge for swapping growth wins and losses (or just unwinding after a busy day). Hosted by Botsi. Request to join →

Dinner for App Founders

📅 4:30–6:30 PM 📍 NoMad

A small dinner for founders, CEOs, and growth leaders running subscription apps to share food, drinks, and candid stories from the trenches, with a secret guest joining the table. Hosted by Superwall. Request to join →

App Founders Dinner

📅 5:00–7:00 PM 📍 Hell's Kitchen

A candlelit dinner for a small group of founders and growth operators who've scaled real subscription businesses, designed for candid conversation away from the conference crowd. Hosted by Superwall and Elemental Growth. Request to join →

The Shippies Award Show

📅 7:00–11:00 PM 📍 Intrepid Museum

All aboard The Shippies award ceremony! RevenueCat’s annual awards celebrate the people, ideas, and apps shaping the future of the subscription economy. And this time, it’s on a literal ship. Complete with red carpet, retired space shuttle, and unbeatable views of the Manhattan skyline. Join us to celebrate the best in app growth, monetization, and subscription innovation, plus every winner of Shipaton. Request to join →

Wednesday, October 21

App Growth Annual

📅 8:00 AM–9:00 PM 📍 The Glasshouse + online worldwide

RevenueCat's flagship event for the people building, growing, and shaping what's next in apps. Keynotes include Ravi Mehta (Tinder), Julie Hansen (Babbel), Greg Cohn (Burner), and Ajay Mehta (Tolan). You'll also get a first look at RevenueCat's 2027 roadmap, side quests in The Meowtrix challenge, plenty of time to network, and six workshops from industry experts like Lisa Kennelly (Klarna), Marcus Burke (Ctrl Shift), Sven Jürgens, and Bria Sullivan (Honey B Games). Attend online for free →

Building & Scaling a Successful UGC Program with Amazing Margins

📅 6:00–7:00 PM 📍 Details shared after approval

A hands-on workshop for app founders. Discuss building and scaling a high-margin UGC program, leave with your own program mapped out on paper: what it costs to run, what it should return, and where your current setup is leaking margin. Hosted by GlossKit. Request to join →

Thursday, October 22

New York App Week 5K with RevenueCat & Runna

📅 8:00–10:00 AM 📍 Bluestone Lane Chelsea Piers Café

Start the morning with a relaxed 5k along the Hudson, starting and finishing at Bluestone Lane Chelsea Piers. Breakfast and coffee's waiting at the finish line (+ finisher medals and limited edition swag!). Run, jog, or walk — all paces welcome. Receive a two-week free trial to Runna ahead of the event. Hosted by RevenueCat and Runna. Request to join →

Software Sommelier by Lickability

📅 10:00 AM–12:30 PM 📍 Manhattan

A cozy, caffeinated design lab: bring an app or prototype for live, actionable product and UX feedback from the Lickability team, then compare notes with fellow app builders. Hosted by Lickability. Request to join →

Shipaton Demo Day in Times Square

📅 10:00 AM–6:00 PM 📍 Times Square

We’re taking #buildinginpublic to a whole new level as Shipaton winners take over demo pods in Times Square to show off their apps and get real feedback all day long. Open to the public, no registration required. Hosted by RevenueCat.

RAGA Apps Cowork

📅 10:00 AM–4:00 PM 📍 Details shared after approval

A shared workspace for app builders to get things done between App Growth Annual and New York App Week events. Open to locals and visitors, with limited, time-slotted seating. Hosted by EHVM and Tangent. Request to join →

Apple Ads Masterclass: Maximum ROI, End to End

📅 11:00 AM–12:00 PM 📍 Details shared after approval

A hands-on masterclass that uses a real client case to connect Apple Ads acquisition and ROAS with RevenueCat subscription and paywall data, so you leave with a practical end-to-end ROI framework. Hosted by Asapty and RevenueCat. Request to join →

Appstore Connect — NYC

📅 6:30–9:30 PM 📍 Details shared after approval

A community meetup for founders and builders in mobile apps and games to exchange ideas and explore consumer app trends, user acquisition, and monetization. Hosted by Appstore Connect. Request to join →

A/B or Not to Be

📅 6:30–9:30 PM 📍 Details shared after approval

An interactive evening of real growth experiments and strong opinions. Attendees vote A or B on real growth experiments before the team reveals the actual results. Followed up with Would You Rather: App Industry Edition, and a live app growth roast. Hosted by Apptuitive. Request to join →

Scaled Consumer App Founder Dinner

📅 7:00–9:00 PM 📍 Brooklyn

A small dinner for founders of scaled consumer subscription apps to share candidly what is, and isn't, working. Hosted by Will Kent. Request to join →

What’s on your schedule?

Whether you’re hosting a meetup or jogging along the Hudson, there’s an event for every type of app pro, and enough going on to quickly fill your calendar. Join as many events as you like, or show up to a single co-working session and stay heads-down. The only non-negotiable in your diary is App Growth Annual, happening October 21. We’ll see you there!

What changes on October 1

Following its dispute with the European Commission under the Digital Markets Act (DMA), Apple replaced its EU fee structure:

Rates are from Apple's Payment options on the App Store in the EU. The reduced column applies if you're in the App Store Small Business Program, the Mini Apps Partner Program, or the Video Partner Program, and to any auto-renewing subscription after its first year.

Here's an overview of the changes:

• The acquisition fee, store services fee, and per-install Core Technology Fee are gone
• A single commission replaces all three, and where the buyer pays decides the rate
• From October 1, 2026, every EU developer works under one set of Apple terms, and the commission depends on where the buyer pays
• Small businesses and subscriptions after their first year pay just 10% on either alternative path
• Paying through your own checkout inside the app is now part of standard terms for every EU developer (it was already possible under Apple's Alternative Terms Addendum for Apps in the EU)
• You can offer it alongside in-app purchase, as long as Apple's button is at least as prominent as yours, or drop in-app purchase and run only your own checkout. Apple Pay is allowed as a payment method.

The catch: Apple reviews the flow and collects the reports

The lower rates come with two conditions:

1. Apple reviews the purchase flow
2. Apple collects a report on every transaction

Before a buyer reaches your checkout, your app confirms the device and storefront are eligible for external purchases, shows Apple's disclosure sheet, and requests a token from StoreKit that declares whether the purchase happens inside the app or in a browser. Apple issues a different token for each path, and reviews the order of the steps.

Every token Apple mints is a token you owe a report on. You report the first purchase, every renewal, every product change, every refund, and every cancellation it produces. You also report every token that never turned into a sale at all. Apple gives you seven days to attribute a link-out purchase back to the token that started it, and Apple wants each month's report within 15 days of that month ending. Once you pick your payment options, you keep them available for 12 months.

That's a lot to build before you even see a cent of the lower commission. Luckily, we've built all of that into RevenueCat.

What RevenueCat handles for you

From October 1, you'll get in-app checkout, paywalls that clear App Review, the Apple reporting, and revenue numbers with Apple's commission already taken out, without having to build any of the reporting yourself. Here's how:

Hands-free reporting to Apple

If the purchase runs through RevenueCat, the reporting is taken care of.

Every purchase through Stripe Billing, Paddle Billing, or Web Billing already flows through RevenueCat, so the reporting runs off data you're already sending. The SDK posts the token before the checkout opens and passes an opaque identifier along in the checkout URL. When the purchase lands, RevenueCat matches the two, works out the tax-exclusive and tax-inclusive amounts Apple's report format demands, and submits on Apple's schedule.

The hard part is that the three providers disagree about what a price means:

• A Stripe amount is tax-inclusive or tax-exclusive depending on how you configured the product
• Paddle zeroes out tax on a refund
• RevenueCat normalizes all of it into the shape Apple accepts

Renewals, product changes, refunds, and cancellations report off the same subscription as they happen. RevenueCat reports tokens that never converted as unused and enforces the seven-day window on its side, so a late purchase never gets filed against a token Apple would reject.

Purchase buttons that meet Apple's design rules

Apple's EU terms include design requirements, meaning Apple doesn't only check your reports; App Review checks your paywall too. If you offer an alternative payment next to in-app purchase, the in-app purchase button has to use Apple's standard styling and be at least as prominent. If you only offer in-app purchase, you're free to style it.

RevenueCat Paywalls get new purchase button variants for both cases. Pick the Apple-styled button when your own checkout sits next to it, or use the custom branding options when in-app purchase is the only path.

Apple's commission is tracked on every web transaction

Once the money's in, you need to know how much of it you actually keep. A web transaction with a token attached now carries two commissions: your processor's and Apple's. Until now, your payment processor reported its own fee and knew nothing about Apple's, so the moment you added a second path, the take-home figure in your revenue reporting went wrong.

RevenueCat breaks Apple's commission out on those transactions, so your charts will be able to show what you keep after both cuts (coming soon).

A web checkout that opens in your app

Tap a purchase button on a RevenueCat paywall and a bottom sheet checkout slides up over it. The buyer pays and the sheet closes without leaving your app.

Behind the tap, the SDK runs Apple's sequence: eligibility check, disclosure sheet, token request declared as in-app, token stored on RevenueCat's backend before the checkout opens.

We are actively working on bringing the bottom sheet in-app checkout to you as soon as possible. If you want to know first when it drops, sign up for early access here. At launch, the in-app checkout works with Stripe Billing and Paddle Billing, with Web Billing to follow.

Prefer the browser? The same button can link out instead at 15%, and Apple's disclosure sheet appears either way.

Show the alternative checkout only where it's allowed

Finally, Apple's terms allow external purchase flows on EU storefronts only, and not to minors. Making sure the alternative checkout appears only for eligible users is your responsibility as the developer.

RevenueCat Targeting lets you serve a paywall with the alternative button to EU storefronts only, and keep a paywall with only in-app purchases everywhere else. Rico can set that up for you: describe the rule and it builds the targeting.

Which path should you use?

Five percentage points separate the in-app sheet from the browser link-out, but the browser path costs you conversion at the disclosure sheet. We've seen this before: in our web vs. in-app purchase test, web subscriptions ended up with 6% less take-home revenue.

We're running the new experiment from October 1 and we'll share the numbers after.

Until then, model it for your own price points: our app store fee calculator takes your monthly revenue, average transaction size, provider, and program status, and shows what each path leaves you with, including the processor's fee on top of Apple's.

Getting started

1. Request the StoreKit External Purchase entitlement from Apple and list the countries you want it in. That list is fixed in your provisioning profile, so get it right before you build.
2. Update to purchases-ios 5.89.0 or later and turn on external purchase links in your RevenueCat configuration.
3. Add a purchase button to your paywall, point it at your Stripe Billing or Paddle Billing checkout, and target the paywall to EU storefronts. The app-to-web purchase docs cover the configuration.

Apple's new terms go live on October 1. With RevenueCat, your checkout, paywalls, and reporting can too.

Watch on YouTube

The press wasn't free, exactly. Yves had worked with a French PR agency at his first company and hired them again at, by his recollection, "maybe between three and 5,000 per month" — on deferred payment, because WeWard had no money yet. About seven or eight months after launch the app landed a segment on one of France's biggest prime-time shows. "I think it was in less than five minutes, we got 300,000 downloads," he says. "Of course, the app crash instantly, it was terrible."

The crash didn't matter. The inbox filled with people asking to get in, and when the team checked retention it was, in his words, "very high compared to the average market." So they added ads, on the logic that at roughly 100,000 daily users an ad-supported free app starts to pay. The retainer, meanwhile, kept producing. "Some months you have zero, but some months you have half a million downloads," Yves says. "So half a million download, you know how much it costs in UA. You can pay the agency for 10 years easily."

The same playbook produced nothing in the US

Press worked in Italy and Spain as well. Then Yves moved to New York, with money this time, and "took one of the most expensive PR agency." The French success didn't repeat. His diagnosis is unsparing: "It's just due to the fact that I'm nobody here in this country." American journalists wanted a story, and "one of the biggest app in France" wasn't one. "Did you raise money with someone impressive? Did you do something crazy?" he recalls being asked. "And no, we are a profitable startup that's coming. And so it was not enough."

Being French didn't help either. "Being French is not a benefit, except if you are in the wine or the luxury brands, or the cheese maybe." US users needed to see the product as American, and the product itself had to reach the level of polish he saw in US banking apps compared to French ones.

So he went looking for a US icon, ideally an athlete with wellness values, and started asking VCs and agencies for introductions. The search was deliberate; the meeting wasn't. At lunch with his family in a New York restaurant, Venus Williams sat down at the next table and said hello. He waited for a lull, walked over, and pitched. Williams was sitting with the founder of a European tech investment bank, and the questions turned to day-seven retention and LTV within minutes. The deal that followed went further than the ambassador arrangement Yves had in mind. "Okay, I want shares, so I want to be also investor," she told him.

Two years on, he is careful about what that bought. "There was multiple impacts and it's very difficult to quantify." But the mechanisms are clear enough to list: hiring got easier because the company had credibility, CAC comes down when creative carries a known face, co-produced content lifts retention and LTV, her social posts drive organic installs, and journalists who ignored a French founder reply when a conversation with Venus Williams is on offer. "You will not be able to quantify day one," he says. "It's progressive."

Nike, Adidas and Amazon pay WeWard a commission

WeWard may be one of the most diversified apps in the business, and the subscription came last. Ads work because the audience is huge. In-app purchases exist. The premium tier, built on RevenueCat, launched well after everything else and is "not a major source of revenue" yet, though it is growing fast. And then there is affiliate. "We have Nike, Adidas, Expedia, Booking.com, all of Amazon, it's part of the clients of WeWard," Yves says.

He is quick to say he didn't invent anything. Affiliate is a mature market with the tracking already built, and brands like it because it is performance-based. "They just pay a commission of a sales." WeWard went to affiliate platforms and to brands directly, offered to promote them for a share of the sales generated, and sold the environment: a wellness and fitness context brands want to be seen in. The team also says no. "This is why sometimes we reject to work with some specific brands because we believe that their value and the way they change the way people act is totally opposite to what we are trying to do." Jacob's aside that the best CPMs in 2026 probably come from gambling apps went unchallenged.

WeWard refuses to measure time in app

Every revenue stream sits under one rule. "We don't track the time spent into the app because we don't want to be a target for the team," Yves says. The number WeWard watches is steps, on the theory that a user whose lifestyle hasn't changed in six months leaves anyway. Every feature ships through an A/B test that has to move that number. "So for us, the success of the number of steps of people is the success of the company."

The newest test of that rule is a walking mode that locks TikTok, Instagram and other apps until the user hits a step goal, making screen time itself the reward. The head of growth in New York vibe-coded it and shipped it a few months ago. "We already measure that people that use these features walk 10% more," Yves says. For a company whose ads depend on people opening the app, building a feature that sends them outside is a strange thing to celebrate. It's also the point.

In the full episode, Yves also explains why WeWard dropped its original Ethereum-based rewards after three or four months when users said loyalty points were fine, why he considers deciding to stop the hardest part of any pivot, and why an 80-person company in 29 countries still counts B2B as its biggest failure of the year.

Guest links

• Yves Benchimol on LinkedIn
• WeWard
• WeWard careers

RevenueCat's Kotlin Multiplatform SDK took that route anyway in 3.0.0. It dropped CocoaPods and now compiles the purchases-ios Swift package from source inside two Gradle modules, kn-core and kn-ui, that contain almost no Kotlin. The question worth answering is what those modules actually do: how a Swift package becomes something the Kotlin/Native compiler can bind, cache, and publish.

In this article, you'll dive deep into how the SDK wraps a Swift package in a Gradle module, exploring the swiftPackage() DSL, swift package describe, the Swift build task, the source hash in the .def file, the facade module, the release build configuration, resource bundling, type sharing across modules, and the shims around cinterop.

The fundamental problem: cinterop reads Objective-C, and Gradle doesn't build Swift

The cinterop tool takes its instructions from a definition file, a .def, that tells it what to parse and what to link. For an Objective-C library, three entries carry most of the weight:

language = Objective-C
modules = MyLibrary
staticLibraries = libMyLibrary.a

language switches the parser from C to Objective-C, and modules names a Clang module, a named set of headers, for cinterop to read. staticLibraries names a static library, an .a archive of compiled object files, that cinterop copies into the klib it produces. A klib is Kotlin/Native's library format, the counterpart of a JAR on the JVM, and as the Kotlin documentation puts it, "When using a klib like this in your program, the library is linked automatically."

A Swift package provides none of these. Swift has no header files, so there's nothing to parse until you ask the compiler to generate an Objective-C header, and that header only contains the declarations Swift exposes to Objective-C. The package itself contains no Clang module and no archive to link, because SwiftPM, the Swift Package Manager, compiles a package as part of building whatever app depends on it. Even reading the package is a problem: Package.swift is a Swift program, and only SwiftPM can evaluate it.

Before 3.0.0, the SDK solved this the way many Kotlin Multiplatform libraries did, with the Kotlin CocoaPods plugin, which hands the build to CocoaPods and Xcode and then points cinterop at what they produce. Looking at the core of the 2.x configuration in the core module:

cocoapods {
    ios.deploymentTarget = libs.versions.ios.deploymentTarget.core.get()

    framework {
        baseName = "Purchases"
        isStatic = true
    }

    pod("PurchasesHybridCommon") {
        version = libs.versions.revenuecat.common.get()
        extraOpts += listOf("-compiler-option", "-fmodules")
    }
}

This works, but every step it hides has a cost. Building the iOS side needed a working CocoaPods installation, apps had to add PurchasesHybridCommon to their own Xcode project and keep its version paired with the Kotlin SDK, and parallel Gradle tasks could race each other inside CocoaPods' shared cache. In April 2026, the team fixed a flaky iOS CI job, and the commit message spells the problem out:

Gradle runs podInstallSyntheticIos for core, models, mappings, and revenuecatui in parallel. All four tasks hit the shared CocoaPods cache (~Library/Caches/CocoaPods/Pods/) concurrently, causing Errno::ENOENT race conditions during cp_r.

A month later, 3.0.0 deleted the plugin and the CI workaround with it. What replaced it doesn't hide the build behind another tool: it runs each step as a Gradle task, in about 1,200 lines of convention plugin code under build-logic/.../swift.

JetBrains is working on an official answer too: SwiftPM import, an Alpha feature that arrived with the Kotlin 2.4.20 release candidates. The SDK builds on Kotlin 2.3.20 with its own implementation, which makes it a readable reference for what any such integration has to handle.

Declaring a Swift package: The swiftPackage() DSL

Everything starts in a module's build file. In SwiftPM, a target is a module inside a package, and kn-core declares two Swift targets from its appleMain source set: RevenueCat, from the purchases-ios checkout that the repository tracks as a git submodule under upstream/, and AdditionalSwift, a small local package you'll meet later. The second declaration shows the shape without optional arguments:

appleMain.dependencies {
    swiftPackage(
        path = file("src/swift"),
        target = "AdditionalSwift",
        packageName = "com.revenuecat.purchases.kn.core.additional"
    )
}

path points at the directory containing Package.swift, target picks one SwiftPM target to build, and packageName is the Kotlin package the generated bindings land in. It reads like a dependency declaration, but it doesn't add anything to a Gradle configuration. If you examine the function:

fun KotlinDependencyHandler.swiftPackage(
    path: File,
    target: String,
    packageName: String,
    customDeclarations: String? = null,
    swiftSettings: SwiftSettings? = null,
) {
    val registry = project.extensions.findByType(SwiftPackageRegistry::class.java)
        ?: error("SwiftPackageRegistry not found. ...")
    val dependency = SwiftDependency(
        packagePath = path,
        target = target,
        packageName = packageName,
        sourceSetName = getSourceSetName(),
        customDeclarations = customDeclarations,
        swiftSettings = swiftSettings,
    )
    registry.add(dependency)
    project.getOrCreateGlobalSwiftRegistry().register(target, project, dependency)
}

The function records a SwiftDependency in two places, a registry on the current project and a global registry on the root project, and does nothing else. The real configuration happens later, once the build script has finished evaluating.

The one surprising call is getSourceSetName(). The build needs to know which source set the declaration came from, because that decides which Kotlin/Native targets receive bindings, but KotlinDependencyHandler doesn't expose its source set publicly. The function finds it by reflection:

private fun KotlinDependencyHandler.getSourceSetName(): String {
    var current: Class<*>? = this.javaClass
    while (current != null && current != Any::class.java) {
        for (field in current.declaredFields) {
            try {
                field.isAccessible = true
                val value = field.get(this)
                if (value is KotlinSourceSet) {
                    return value.name
                }
            } catch (_: Exception) {
                // Continue to next field
            }
        }
        current = current.superclass
    }
    error("Could not determine source set for swiftPackage(). ...")
}

It walks the handler's fields up the class hierarchy until one of them holds a KotlinSourceSet. This leans on Kotlin Gradle Plugin internals, and the full error message admits it: "This might be due to a Kotlin Gradle Plugin version incompatibility." The name then feeds a simple mapping, where appleMain covers every ios, macos, tvos, and watchos target and iosMain covers only the ios ones. That's why kn-core, which declares its packages in appleMain and adds watchOS targets, builds Swift for iOS and watchOS, while kn-ui declares RevenueCatUI, the module that renders RevenueCat's paywalls and Customer Center, in iosMain and builds for iOS only.

The global registry adds one rule: a Swift target can have only one owner. Declaring the same target from a second Gradle project fails with "Each Swift target should be owned by exactly one Gradle project." That guarantee is what later lets kn-ui find RevenueCat by name. Nothing declares that kn-core has to be configured first, though. The lookup works because Gradle happens to reach kn-core before kn-ui.

Reading the package: Letting SwiftPM describe itself

The convention plugin does its work in afterEvaluate, after every swiftPackage() call has run, and it starts by checking the host operating system. Everything that follows shells out to xcrun, which doesn't exist on Linux, so instead of failing configuration there and taking Android builds down with it, the plugin logs "Skipping Swift dependency configuration on non-macOS host" and leaves the module without Apple bindings on that machine.

On macOS, the plugin first needs the package's structure: where each target's sources live, which targets depend on which, and which resources they carry. Rather than parse Package.swift, it asks SwiftPM:

internal fun Project.getSwiftPackageInfo(packageDir: File): SwiftPackageInfo {
    val result = providers.exec {
        workingDir = packageDir
        commandLine("xcrun", "swift", "package", "describe", "--type", "json")
        isIgnoreExitValue = true
        // Avoids trying to use the iOS SDK to parse the Package.swift when building from Xcode.
        // This environment change is scoped to this subprocess only.
        environment("SDKROOT", "")
    }

    val exitCode = result.result.get().exitValue
    if (exitCode != 0) {
        val stderr = result.standardError.asText.get()
        error("Failed to run 'swift package describe' in $packageDir (exit code $exitCode): $stderr")
    }

    return SwiftPackageInfo.parse(result.standardOutput.asText.get())
}

swift package describe --type json prints SwiftPM's own model of the package after it evaluates the manifest. The purchases-ios manifest reads CI.xcconfig and environment variables while it evaluates, so no static parser could reproduce what SwiftPM sees. From the JSON, SwiftPackageInfo.parse() keeps each target's name, path, target_dependencies, and resources, plus the package's platform deployment targets.

The SDKROOT line handles a quieter problem. When Gradle runs from an Xcode build phase, Xcode has already exported SDKROOT for the iOS SDK, and SwiftPM would try to use that SDK for a manifest that has to run on the Mac itself. Clearing the variable for this one subprocess keeps builds from Xcode working.

From Swift target to Clang module: A header, an archive, and a module map

For each Kotlin/Native target that includes the declaring source set, the plugin registers a SwiftBuildTask with a name like compileSwiftRevenueCatIosSimulatorArm64. Its job is to produce what the .def file needs: an Objective-C header, a static archive, and a module map. The first step runs swift build for one Swift target and one architecture, and each -Xswiftc or -Xcc in the command forwards the argument after it to the Swift compiler or to Clang:

execOperations.exec {
    workingDir = packageDir.get().asFile
    environment("SDKROOT", "")
    commandLine(
        listOf(
            "xcrun", "swift", "build",
            "--target", targetName,
            "--configuration", configValue,
            "--triple", tripleValue,
            "--scratch-path", scratchPath.absolutePath,
            "-Xswiftc", "-sdk",
            "-Xswiftc", sdkPath,
            "-Xcc", "-isysroot",
            "-Xcc", sdkPath,
            "-Xswiftc", "-emit-objc-header",
            "-Xswiftc", "-emit-objc-header-path",
            "-Xswiftc", targetOutputDir.resolve(headerName.get()).absolutePath
        ) + extraSwiftArgs
    )
}

A few arguments carry most of the weight:

• -triple and sdk: both derive from the KonanTarget, so iosSimulatorArm64 builds for arm64-apple-ios-simulator against the iPhone Simulator SDK, and watchosArm64 builds for arm64_32-apple-watchos. Each Swift target builds once per Kotlin/Native target.
• emit-objc-header-path: tells swiftc to write the module's Objective-C header, RevenueCat-Swift.h, into the task's output directory. The header holds only what Swift exposes to Objective-C, which is why every Kotlin binding carries an Objective-C name like RCPurchases or RCCustomerInfo.
• -scratch-path: gives each Swift target its own scratch directory, the folder where SwiftPM keeps its build files. The section on sharing types explains why.
• extraSwiftArgs: carries SwiftSettings, where each define("FLAG") becomes Xswiftc -D -Xswiftc FLAG.

swift build --target stops at object files and a Swift module. It doesn't produce an archive you can hand to a linker, so the task builds one itself:

val buildPath = scratchPath.resolve("$tripleValue/$configValue")
val objectFiles = buildPath.resolve("$targetName.build")
    .walkTopDown()
    .filter { it.extension == "o" }
    .toList()

if (objectFiles.isEmpty()) {
    error("No object files found in ${buildPath.resolve("$targetName.build")}")
}

execOperations.exec {
    commandLine(
        listOf(
            "libtool", "-static", "-o",
            targetOutputDir.resolve(libraryName.get()).absolutePath
        ) + objectFiles.map { it.absolutePath }
    )
}

The walk only covers <Target>.build, so each archive holds exactly one target's code. Today, libRevenueCat.a contains 565 object files and defines the RCPurchases class, while libRevenueCatUI.a contains 333 and doesn't define it. When your app links both, RevenueCat's code comes from one archive, not two.

The last output is a module map, the file that tells Clang which headers make up a module. SwiftPM writes one of its own deep inside the scratch directory, but it points at the header's default location, and -emit-objc-header-path has moved the header elsewhere. So the task writes its own module map next to the header. For RevenueCat, the generated file is four lines:

module RevenueCat {
    header "RevenueCat-Swift.h"
    export *
}

The header, the archive, and the module map now sit together in build/swift-packages/RevenueCat/<konanTarget>/, the task's declared output directory. Writing its own module map also gives the build a place to list headers from other targets, which becomes important once two modules share types.

The .def file: A comment that keeps cinterop honest

A second task, GenerateDefFileTask, writes the definition file. Looking at the core of its task action:

val sourceHash = computeSourceHash()

val baseContent = """
    # sourceHash=$sourceHash
    language = Objective-C
    package = ${packageName.get()}
    modules = ${moduleName.get()}
    staticLibraries = ${libraryName.get()}
    linkerOpts = -L/usr/lib/swift
    linkerOpts.ios_x64 = -L$toolchain/lib/swift/iphonesimulator/
    linkerOpts.ios_arm64 = -L$toolchain/lib/swift/iphoneos/
    linkerOpts.ios_simulator_arm64 = -L$toolchain/lib/swift/iphonesimulator/
    linkerOpts.watchos_arm64 = -L$toolchain/lib/swift/watchos/
    linkerOpts.watchos_device_arm64 = -L$toolchain/lib/swift/watchos/
    linkerOpts.watchos_simulator_arm64 = -L$toolchain/lib/swift/watchsimulator/
""".trimIndent()

Most of it maps onto the three entries from earlier: the language, the module from the module map, and the archive. package sets the Kotlin package for the bindings, and the linkerOpts lines add Swift library search paths for the final link. The interesting line is the first one. # sourceHash= is a comment that cinterop ignores, and it's there on purpose:

private fun computeSourceHash(): String {
    val sourceDir = swiftSourceDir.get().asFile
    val digest = MessageDigest.getInstance("MD5")

    sourceDir.walkTopDown()
        .filter { it.isFile && it.extension == "swift" }
        .sortedBy { it.relativeTo(sourceDir).path }
        .forEach { file ->
            digest.update(file.relativeTo(sourceDir).path.toByteArray())
            digest.update(file.readBytes())
        }

    return digest.digest().joinToString("") { "%02x".format(it) }
}

It hashes every .swift file under the target's own source directory, path and contents, in a stable order, so any edit to those files, even to a comment, produces a different .def file.

The reason lives in how Gradle decides whether cinterop needs to run: it skips the task as UP-TO-DATE unless one of the task's tracked inputs changed. As of Kotlin 2.3.20, CInteropProcess tracks the .def file, option strings such as compilerOpts and extraOpts, dependency klibs, include directories registered through the Gradle DSL, and headers listed in a headers entry. This build lists a module instead of headers and passes its output directory only as -I and -libraryPath strings, so nothing inside that directory counts as an input: not the header, not the module map, not the archive.

Skipping cinterop costs more than stale bindings, because cinterop doesn't only read the archive, it copies it. After a build, the cinterop klib contains default/targets/<target>/included/libRevenueCat.a, byte for byte the archive the Swift task produced, and when cinterop doesn't run, that copy doesn't change. Here is the pipeline so far. The only tracked path from a Swift edit to the klib runs through the .def file:

Replacing the hash with a constant makes the consequence concrete:

1. A change to a function body: the Swift task re-runs and writes a new archive, the header comes out byte for byte identical, and cinterop reports UP-TO-DATE. The klib keeps the old archive, so your app would link yesterday's Swift code.
2. A new @objc method: the method appears in the generated header, and cinterop still reports UP-TO-DATE, so it never reaches the Kotlin bindings.

With the hash restored, both edits re-run cinterop, and the embedded archive matches the new one. The obvious alternative, declaring the archive as a cinterop input, is what the team tried. The comment above the hash records why it didn't stick:

We add a hash of the Swift source directory to force cinterop to re-run when Swift source changes, even if the changes are non-public. This is necessary because we found using inputs.file() on the cinterop task directly causes failures when building debug after release (e.g. publishToMavenLocal). This seems related to the cinterop commonizer.

The build logic tests pin this behavior with Gradle TestKit. Each test creates a throwaway Swift package, runs cinterop once, changes one thing, and checks the task outcome. In the implementation change test, the package starts with a greet() method that returns "hello":

// Act
val original = pkg.target.readSourceFile("TestClass.swift")
// An implementation change does not modify the header.
pkg.target.writeSourceFile(
    "TestClass.swift",
    original.replace("return \"hello\"", "return \"hello world\"")
)
val result = runBuild(pkg.cinteropTaskName)

// Assert
assertEquals(TaskOutcome.SUCCESS, result.task(pkg.cinteropTaskName)?.outcome)

Sibling tests cover an edit that only touches a comment, an added file, a deleted file, and the negative case: with no change at all, cinterop must be UP-TO-DATE. That last test matters as much as the others, because a hash that changed on every build would turn the fix into a rebuild tax.

The hash has limits worth knowing if you copy it. It covers only the target's own sources, so a change to a dependency target, to the build configuration, or to compiler defines leaves the .def file as it was and cinterop UP-TO-DATE. Switching the same sources from debug to release, for example, rebuilds libAdditionalSwift.a while the klib keeps the debug copy.

The facade module: A Gradle module with almost no Kotlin

With bindings generated, the module that owns them can be published. kn-core has exactly one Kotlin file:

@file:Suppress("unused")

package com.revenuecat.purchases.kn.core

/**
 * We need at least 1 Kotlin source file for the kn-core module to be published.
 */
internal object Dummy

The substance is in the published artifacts. For the iOS device target in version 3.10.1, Maven Central has:

• purchases-kmp-kn-core-iosarm64-3.10.1.klib: 3,726 bytes, holding the Dummy object.
• purchases-kmp-kn-core-iosarm64-3.10.1-cinterop-RevenueCat.klib: a zip of about 14 MB, holding the bindings and a 55 MB libRevenueCat.a under default/targets/ios_arm64/included/.
• purchases-kmp-kn-core-iosarm64-3.10.1-cinterop-AdditionalSwift.klib: about 60 KB for the local shims.

So a Gradle module with one placeholder object is really a delivery vehicle: a Kotlin/Native library whose payload is compiled Swift. Other modules consume it like any project dependency. core and mappings add implementation(projects.knCore) to appleMain, revenuecatui adds knCore and knUi to iosMain, and from there Kotlin code imports com.revenuecat.purchases.kn.core.RCPurchases and calls straight into purchases-ios.

For your app, this is why the Xcode side of the setup disappeared in 3.0.0. The compiled Swift travels inside the klibs and gets linked into your app's framework automatically, so there's no Podfile, no PurchasesHybridCommon package in Xcode, and no second version to keep in sync. Installing the SDK comes down to a Gradle dependency in commonMain, as the installation guide shows, and the 3.0.0 announcement walks through moving an existing project over.

Build configuration: Compiled once, in release

Publishing has a subtler consequence, which starts with how the Swift build configuration is chosen. Leaving out the validation of the property value, the order of checks looks like this:

private fun Project.getSwiftConfiguration(): String {
    val override = findProperty("swiftConfiguration")?.toString()
    if (override != null) return override

    val xcodeConfig = providers.environmentVariable("CONFIGURATION").orNull
    if (xcodeConfig != null) {
        return when (xcodeConfig.lowercase()) {
            "debug" -> "debug"
            "release" -> "release"
            else -> "release"
        }
    }

    val taskNames = gradle.startParameter.taskNames
    val isPublishing = taskNames.any { it.contains("publish", ignoreCase = true) }
    if (isPublishing) return "release"

    return "debug"
}

An explicit -PswiftConfiguration wins, then Xcode's CONFIGURATION variable, where any custom configuration name counts as release, then a check for publishing tasks, and everything else falls back to debug for faster local builds. RevenueCat's release job runs a publishing task with neither override, so the purchases-ios code inside a published artifact is always a release build, no matter how you configure your app. Every #if DEBUG in that Swift code resolves when RevenueCat publishes, not when you build.

That collided with a safeguard in purchases-ios. RevenueCat's Test Store lets you run test purchases with a dedicated API key and no App Store Connect or Google Play setup. To keep that key out of production, the iOS SDK deliberately crashes release builds that still use it. With the Swift code always compiled in release, the check would fire during everyday debug runs of a KMP app, so kn-core opts out with a compiler flag:

swiftSettings = SwiftSettings {
    define("BYPASS_SIMULATED_STORE_RELEASE_CHECK")
}

The flag exists in purchases-ios for exactly this case, and its comment states the trade off: "Setting this flag means apps shipped to production with a Test Store API key won't be caught at runtime."

The toolchain is frozen the same way. Version 3.0.1 was compiled with Xcode 26.4.1, and some apps failed to link it, with errors about SwiftUICore (#859), so CI now builds releases with Xcode 16.4. Decisions that a regular Swift app makes on every build, from #if DEBUG to the Xcode version, become decisions made once per release when the Swift code ships pre-compiled.

Resources: Shipping a Swift bundle through Compose Resources

RevenueCatUI also carries resources: asset catalogs and localized strings that SwiftPM would normally package into a resource bundle. A klib has no place for a SwiftPM bundle, so the plugin borrows a delivery mechanism Kotlin Multiplatform already has. ProcessSwiftResourcesTask sorts the resources by type, running asset catalogs through actool and keeping localized files in their .lproj directories, and the plugin registers the output as a custom Compose Resources directory:

with(resourcesExtension) {
    packageOfResClass = "${dependency.packageName}.resources"
    customDirectory(
        sourceSetName = dependency.sourceSetName,
        directoryProvider = processResourcesTask.map { it.outputDir.get() }
    )
}

On the Swift side, kn-ui compiles RevenueCatUI with define("COMPOSE_RESOURCES"), which switches the bundle it loads resources from:

static var revenueCatUI: Bundle {
    #if COMPOSE_RESOURCES
    return composeResourcesBundle
    #else
    return module
    #endif
}

composeResourcesBundle resolves a path ending in composeResources/com.revenuecat.purchases.kn.ui.resources/files, which is exactly where Compose Resources places files for the package set above. The published kn-ui artifact's resource archive contains that directory, with an Assets.car and 47 .lproj directories.

Two Swift targets, two Gradle modules: Sharing types across the boundary

RevenueCatUI depends on RevenueCat, and its public API is full of RevenueCat types. A paywall delegate receives an RCPackage when a purchase starts and an RCCustomerInfo when a restore finishes. Each target belongs to a different Gradle module, and the generated header shows what that means for cinterop. Here is an excerpt from RevenueCatUI-Swift.h as Swift 6.3 emits it:

#if __has_feature(objc_modules)
@import Foundation;
@import RevenueCat;
@import UIKit;
#endif

@class RCCustomerInfo;
@class NSError;
@class RCStoreTransaction;

The header imports the RevenueCat module, and each @class line is a forward declaration: it says a class exists without describing its methods or properties. Completing them takes either the RevenueCat module or the full @interface declarations in RevenueCat-Swift.h, and both live in another Gradle module's build directory.

The global registry is how kn-ui finds them. For each name in the target's target_dependencies from SwiftPM, the plugin looks up the owning project and keeps the dependencies owned by other projects. Then it wires each one into the Swift task:

moduleDependencies.forEach { dep ->
    val depTaskName = compileSwiftTaskName(dep.dependency.target, kotlinTarget.konanTarget)
    dependsOn(dep.project.tasks.named(depTaskName))

    val depOutputDir = dep.project.layout.buildDirectory
        .dir("swift-packages/${dep.dependency.target}/${kotlinTarget.konanTarget.name}")
    dependencyHeaders.from(depOutputDir.map { it.file(dep.dependency.headerName) })
}

The task now runs after kn-core's Swift task for the same Kotlin/Native target, and RevenueCat-Swift.h becomes one of its inputs. At the end of its action, the task copies each dependency header into its own output directory and lists it first in the module map. The one kn-ui generates:

module RevenueCatUI {
    header "RevenueCat-Swift.h"
    header "RevenueCatUI-Swift.h"
    export *
}

The RevenueCat declarations become part of the RevenueCatUI Clang module, placed before the header whose forward declarations they complete. Separately, the cinterop configuration adds each dependency's output directory to the -I search path, which is what lets the @import RevenueCat line resolve at all.

The code keeps both mechanisms because toolchains disagree about which one they need. The commit that introduced the header merge describes cinterop failing with Xcode 26 and Swift 6.2, where the forward declared types came out as stubs that Kotlin couldn't use. A later commit restored the -I paths because removing them had broken Xcode 16. On Xcode 26.5, only the -I path is essential: without it, cinterop stops at fatal error: module 'RevenueCat' not found, while dropping only the header merge still produces complete bindings. Generated headers change between Swift releases, and carrying both paths keeps cinterop working on either toolchain.

The separate scratch directory per target came out of the same investigation. -Xswiftc flags aren't scoped to the target you ask for. SwiftPM passes them to every swiftc invocation in the build, so when RevenueCatUI builds, the compile of its RevenueCat dependency also writes a header to the path meant for RevenueCatUI-Swift.h. That's harmless only when RevenueCatUI compiles afterwards and writes last. With one scratch directory shared by both modules, each module's build recompiled RevenueCat with its own flags, so simply re-running both builds could leave RevenueCat's header in that file.

Separate scratch directories stopped that, at a measurable price: after a clean build, RevenueCat's 565 object files exist three times for each iOS target, under RevenueCat, AdditionalSwift, and RevenueCatUI. They narrow the leak rather than close it, though. An edit to a RevenueCat function body recompiles only RevenueCat inside kn-ui's scratch directory, and RevenueCatUI-Swift.h then holds RevenueCat's header until something makes RevenueCatUI compile again.

Sharing types also leaves a visible mark in Kotlin. kn-ui's cinterop sees the RevenueCat classes in its own module and doesn't depend on kn-core's bindings, so it generates bindings for them too, and RCPackage exists twice: as com.revenuecat.purchases.kn.core.RCPackage and as com.revenuecat.purchases.kn.ui.RCPackage. The paywall delegate in revenuecatui shows how the Kotlin side copes:

import com.revenuecat.purchases.kn.core.RCPackage
import com.revenuecat.purchases.kn.ui.RCPackage as RCPackageFromKnUi

@Suppress("CAST_NEVER_SUCCEEDS")
override fun paywallViewController(
    controller: RCPaywallViewController,
    didStartPurchaseWithPackage: RCPackageFromKnUi,
) {
    listener?.onPurchaseStarted(
        (didStartPurchaseWithPackage as RCPackage).toPackage()
    )
}

The compiler warns that the cast can never succeed, since as far as Kotlin knows, the two classes are unrelated. At runtime, Kotlin/Native checks casts to Objective-C classes with isKindOfClass:, both bindings name the same Objective-C class, and the cast goes through, which lets the existing toPackage() mapping for kn-core types handle the value. The alias, the suppression, and the cast are the cost of the duplicate bindings, paid in a handful of delegate methods.

What cinterop can't see: Shims around the generated header

The generated header decides what cinterop can bind, and some things never reach it in a usable form. The SDK covers them with small shims, one in the .def file and the rest in Swift.

Forcing a binding with a custom declaration

Store messages are the first case. The Swift API takes a Set<StoreMessageType>, which Objective-C can't express, so purchases-ios adds a separate @objc overload that takes an untyped NSSet:

- (void)showStoreMessagesForTypes:(NSSet * _Nonnull)types completion:(void (^ _Nonnull)(void))completion;

No Objective-C signature mentions the enum. The header still declares RCStoreMessageType, but in a build without any reference to it, cinterop leaves it out: the bindings lose the RCStoreMessageType typealias and all four of its constants, while classes like RCPurchases are unaffected. kn-core's build file supplies the missing reference:

customDeclarations = """
    // Force cinterop binding generation for types otherwise not in the public API
    static inline int __forceBindings(
        enum RCStoreMessageType _1
    ) { return 0; }
""".trimIndent(),

The generator appends it to the .def file after a --- separator, a section the Kotlin docs treat as part of the header, which is why the function is static inline. Nothing calls it. Its only job is to mention RCStoreMessageType in a signature, and with it in place, the mappings module can build the Set<RCStoreMessageType> that Kotlin passes to showStoreMessagesForTypes.

Kotlin has no #available

Swift gates newer APIs with #available, roughly what an SDK_INT check does on Android, and Kotlin/Native has no equivalent. The AdditionalSwift package in kn-core/src/swift exists for gaps like this one. It's a small Swift package that depends on purchases-ios by path and exposes whatever Kotlin needs through @objc. Looking at one of its availability checks:

@objc
public class AppleApiAvailability: NSObject {
    @objc
    public func isCodeRedemptionSheetAPIAvailable() -> Bool {
        #if os(tvOS) || os(watchOS) || os(macOS) || targetEnvironment(macCatalyst)
        return false
        #else
        if #available(iOS 14.0, visionOS 1.0, *) {
            return true
        } else {
            return false
        }
        #endif
    }
}

Kotlin calls it like any other binding before it touches the gated API:

internal actual fun IosPurchases.presentCodeRedemptionSheetIfAvailable() {
    if (AppleApiAvailability().isCodeRedemptionSheetAPIAvailable())
        presentCodeRedemptionSheet()
    else Purchases.logHandler.d(
        tag = "Purchases",
        msg = "`presentCodeRedemptionSheet()` is only available on iOS 14.0 and up."
    )
}

Bridging APIs that exist only in Swift

The same package covers APIs that purchases-ios offers only in Swift. The ad tracking API lives on Purchases.shared.adTracker without an @objc form, so AdTracking.swift wraps each call in an @objc static function. Anything a Kotlin caller needs that the upstream header doesn't express gets a thin wrapper in a package the KMP SDK owns, without adding @objc surface to purchases-ios itself.

Conclusion

This approach earns its keep when the code you need ships as a Swift package rather than a pod, and when your consumers shouldn't have to open Xcode to add it. If you build something similar, write every input that decides the output into a file Gradle already tracks, as the source hash does for Swift sources, and before trusting the build, open the artifact you publish and confirm that the archive and bindings you expect are really inside.

A Gradle module doesn't need much Kotlin to be useful. kn-core is a build recipe with an artifact attached, and most of its engineering answers one question: does Gradle know about every file that decides what ends up in the klib? Each file it doesn't know about is a place where a green build can quietly ship yesterday's code.

Instead of the free trial they’d always offered, we asked people to pay upfront, with a 30-day money-back guarantee if they changed their mind. I’ll be honest: I was nervous. Free trials are the safe default, and here I was suggesting we ask strangers to hand over money before they’d even experienced the product.

But the questions it raised were too interesting not to explore: how does the length compare? What kind of signal does it send? And could it actually work better for some apps?

When I mentioned the idea in an app expert group Slack, someone replied: “I just don’t think they replace free trials.” They weren’t wrong, exactly. And that’s the point of this piece.

I’ve discovered that a money-back guarantee won’t magically transform your app. But it is a genuinely powerful free trial alternative — and one that far too few companies are using strategically.

So let’s give it a go, and if you’re not convinced by the end, you can have your 10 minutes back (100% time-back guarantee).

Money-back guarantees: free trial alternative or passing trend?

A money-back guarantee lets users pay upfront and claim a full refund (within a set window) if the app isn't right for them. These guarantees haven’t always been used in apps for a simple reason: they’re difficult to offer inside the app itself. But with the rise of web-to-app funnels, they've moved from the SaaS world into subscriptions, and were even highlighted by Nathan Hudson, founder of Perceptycs, as one of the monetization trends to watch last year.

While running this money-back guarantee experiment, I keep coming back to the same questions:

• What's the right length?
• What works well?
• Will it actually make a difference?
• Should it run alongside a free or a paid trial?

When I talk about this with the app community, there’s a lot of skepticism. Does it really work? Does it meaningfully change conversion or retention? I guess we’ll find out…

The case for money-back guarantees

The app industry has long relied on free trials as a way to let people experience an app before committing. But as subscriptions have become more common, users have become increasingly skeptical about signing up, worried they’ll forget to cancel and end up paying for something they no longer want. You can see that hesitation in the data — RevenueCat's State of Subscription Apps 2026 found that 55% of three-day trial cancellations occur on day zero, well before users have had a chance to experience the product’s value.

Cleaner signal for Meta

As Meta becomes harder to optimize, many of those trial users are effectively window shoppers. The more of them we chase, the more our cost of acquisition and trial conversion rate suffer.

A money-back guarantee flips that dynamic. On platforms like Meta, you optimize for a direct purchase event, teaching the algorithm to find people who are willing to pay rather than people who are simply willing to start a trial. Same spend, cleaner target.

Nathan captured it well when he highlighted the trend: "By pushing a hard paywall with a money-back guarantee, you can optimize your Meta and TikTok campaigns for the direct purchase event, removing the complexity and opacity of dealing with trial conversions."

There's another advantage, too. When someone takes a free trial and cancels, you've still paid to acquire them. With a money-back guarantee, most customers never claim a refund, so you're only refunding a small subset while keeping the revenue from everyone else. At the same time, the guarantee reduces the fear of committing: customers have paid, but they know they have a safety net if the product isn't right for them.

We saw this with Reading.com (owned by Teaching.com), which replaced the free trial on parts of their web-to-app funnel with a 30-day money-back guarantee. Conversion rates fell, but the purchase event gave Meta a much stronger optimization signal. They still use free trials elsewhere, but for these campaigns the guarantee became a powerful way to attract higher-intent users.

As Tim Dikun of Teaching.com shared on Sub Club, very few customers actually claimed the refund, partly because the product delivered on its promise. The lower conversion rate was more than offset by attracting users who were more likely to stick around and become long-term subscribers.

Refund fear is a common reason for not offering a money-back guarantee, but in reality refund rates are often much lower than people expect. I offered a money-back guarantee across a range of courses over five years, and across 100s of sales I had just one refund request. It came from someone who thought the course would focus on something different from what it was actually designed for (and I of course refunded them immediately).

How to run a guarantee

Like I said, we don't tend to see money-back guarantees directly inside apps, and the reason is simple: the app stores control the refund process. With Apple, users request refunds directly through Apple, and Apple takes back your post-commission share, not the full price. With Google, users can request a refund directly through Google Play within 48 hours of purchase. After that, the decision is yours, and you can issue refunds yourself from the Play Console or RevenueCat. Either way, the refund comes out of your proceeds.. Neither platform has a native ‘money-back guarantee’ feature, so there's no way to automatically approve one inside the app.

On the web, though, you don't have these limitations. You have full control over refunds through your payment provider, whether that's Stripe or another web billing tool, and the fees are usually lower too. You can also define your own guarantee policy and rules. Some apps offer a 30-day money-back guarantee, while others go as far as 100 days (typically for web purchases and first-time customers only).

That flexibility is slowly making its way in-app through app-to-web payment flows. While you can't natively configure a money-back guarantee for in-app purchases, you can use an app-to-web payment flow to achieve the same level of control you have in a web funnel.

In practice, offering a guarantee for in-app purchases isn't a setting you simply switch on. You promise the refund in your paywall and marketing copy, then honor it by issuing refunds directly on Google Play, and on iOS by using Refund Control to tell Apple you'd prefer to grant the refund. Apple still makes the final call.

Sidenote: I spotted a few apps on Mobbin promoting in-app money-back guarantees, although I couldn't find the messaging in their App Store listings. I tried reaching out to them but sadly I haven't been able to confirm exactly how, or why, they're implementing those guarantees.

Cristian Rotari, a product growth expert who has designed a lot of subscription paywalls, raised the obvious question here: how do you even run a guarantee on iOS when Apple controls the refund process?

His answer is the one I keep coming back to. You either provide Apple with consumption information to support the refund decision, or you rely on clear terms in your guarantee, something like “use the app at least three times and show that you didn’t get the promised value,” so you have a basis for approving it. It’s less a switch you flip and more a promise you honor case-by-case.

It’s also worth remembering that the app stores already allow users to request refunds, whether or not you offer a guarantee. The platform mechanisms exist; the difference is that most users don’t know about them. The guarantee is really about making the promise visible and removing the fear of committing. It’s like telling someone with an avoidant attachment style that they can leave at any time, only for them to suddenly not really fancy going anywhere.

That’s why the most powerful place to use it is usually in your web funnels, especially if you’re running paid acquisition. So how do you set one up for success? There are a few key things to consider.

The implementation playbook

1. What do you run it alongside?

Alongside a free trial, I don’t think you’ll see much lift from adding a money-back guarantee. People already have the chance to try the product for free, so you’re really just layering free on top of free.

It gets far more interesting with the upfront payments we talked about. There’s also a third option: a paid trial. Here, you offer a lower-cost paid trial upfront and then add the guarantee on top. This helps counteract the drop in conversion you often see when asking people to pay before they’ve experienced the full value.

With one client, the uptake of a paid trial is lower than a free trial, but the overall conversion to paid is higher. Adding a money-back guarantee on top, giving users that extra layer of security and trust, pushes it higher still.

2. What guarantee length should you offer?

The right length should track time-to-value, in the same way trial length does.

Roughly:

• 7–14 days for utilities and products with fast, obvious value
• Around 30 days for habit and health apps, where the benefits take a few weeks to become clear
• Longer periods where trust is lower, or the payoff takes more time to appear

Jumpspeak, operating in the competitive language-learning space, goes as far as offering a 100-day guarantee:

Interestingly, the research points in the opposite direction to what you might expect. A University of Texas meta-analysis of 21 studies (Janakiraman et al., 2016) found that longer, more generous return windows increased purchases without increasing returns. The explanation is the endowment effect: the longer someone owns something, the less likely they are to give it back.

That research is from ecommerce rather than apps, and money-back-guarantee research is still relatively limited, but it’s a good reason not to make your guarantee unnecessarily restrictive.

I tend to start clients around 30 days (I mostly work with health and wellness apps) because it's a familiar, trusted timeframe, then test longer if refund rates stay low. The downside is that guarantees take time to evaluate — you need to wait until the guarantee period has passed to understand the true impact — so starting with a sensible default helps you learn faster.

3. Positioning, design and copy

Let’s talk about how you communicate this money-back guarantee. A lot of apps go for the classic "full refund, cancel anytime". I think it's important to keep the policy easy to understand, without too many hidden conditions or contradictions. That allows your landing page messaging also to be simple and clear, like MasterClass:

Their FAQs then spell out exactly what the guarantee covers:

The best examples I see of money-back guarantees keep the messaging simple and usually will repeat it on the paywall (if in-app), often near the CTA:

They’ll often use some type of symbol to represent the guarantee and create an official feeling to it, as Monday.com does:

Should everyone be allowed a guarantee?

Maybe we’ve all got a bit of fear of abandonment when it comes to our customers.

If you're worried about abuse, or you've already tested a money-back guarantee and seen high refund rates from people who never even opened the app, you might tighten the rules. For example, you could ask users to try the app at least three times before they're eligible to claim a refund or if they exceed a certain usage (common with AI tools) you don’t get a refund.

But keep the policy simple and clear. The negative reviews and loss of trust that come from an overly complicated or overly restrictive guarantee can easily outweigh the value of offering one in the first place.

4. Preparing operations for it

When you test it, think through your refund logic and the operations around it. Have standard responses ready and a clear process for handling requests.

And yes, you'll still get the occasional person who repeatedly subscribes, claims a refund, and signs up again. They're a bit like the person at the ice cream shop who samples twelve flavors before finally choosing classic strawberry (or not buying an ice cream at all).

I don't think it happens nearly as often as people fear, but those people are out there, so it's worth deciding in advance how you'll handle repeat claims.

A few things make this painless at any volume:

1. Write two or three canned responses so your support team isn't drafting every refund from scratch: one that quickly approves a request, and another that asks a qualifying question first if your guarantee has conditions.
2. Decide upfront whether you'll automatically approve refunds below a certain amount and only manually review the rest. Fighting a $12 refund often costs more in support time and negative sentiment than simply issuing it.
3. Finally, keep a simple log of refund claims. That way, the occasional serial refunder becomes a pattern you can spot and manage, rather than a surprise.

None of it is particularly complicated, but deciding it before you launch means your support team is prepared, your process is consistent, and customers have a better experience when they do request a refund.

5. Run a test and measure the results.

Always run this as an A/B test. And when you analyze the results, wait until the full refund window has closed for the last cohort, because refund requests often come towards the end of the guarantee period.

Treat refund rate as a KPI, but the metric you really care about is net profit. Once you've accounted for refunds and measured the impact on conversion, you can work out which option actually leaves you with more money on the bottom line.

A simple way to think about it: imagine your free trial converts 10 out of every 100 visitors into paying subscribers. Your money-back guarantee might only convert 7. But if just one of those seven claims a refund, you're left with 6 full-price, committed customers — and Meta is optimizing against 7 real purchases instead of a large pool of trial starts.

Whether 6 committed buyers beats 10 trial starts depends on your refund rate, your pricing, and how much stronger the purchase signal makes your acquisition. Which is exactly why you run it as an A/B test and judge it on net profit, not conversion rate alone.

One final caveat: keep an eye on reviews and customer feedback. If the guarantee is hurting word of mouth or driving an unexpectedly high number of refunds, you may decide it isn't the right fit after all.

Pitfalls and when not to offer a money-back guarantee

Just like cilantro or pineapple on pizza, money-back guarantees aren’t for everyone — although Italians would probably argue pineapple on pizza isn’t for anyone (and I’d be inclined to agree with them).

If you're not running any web-to-app or app-to-web payments, and it's worth remembering these still aren't available in every country, I wouldn't fixate on a money-back guarantee right now.

Remember that line from the group chat: "I just don't think they replace free trials"? That was Cristian Rotari. He pushed back on some of the hype, and he’s largely right. As he puts it, a money-back guarantee “can’t sit at the level of a trial or a discounted period; it’s more of a nice-to-have,” — it’s a conversion lever rather than a groundbreaking pricing tactic.

And he had the receipts. Looking through three months of refund tickets at one of the apps he worked with, he found fewer than ten mentions of the guarantee, most from people appealing after a refund had been rejected. Hardly anyone actually uses it, which is exactly why it costs relatively little to offer, and exactly why you shouldn’t expect it to transform your numbers.

There are two more things to weigh. First, app-to-web checkout can feel unfamiliar or untrustworthy to some audiences, especially younger, app-native users. A guarantee won’t fix a payment flow they already don’t trust (Cristian makes this point too).

Second, this all depends on external payments, which have only recently become more available through changes like the Digital Markets Act in Europe and the Epic v. Apple court ruling in the US, and still aren't accessible everywhere.

To be specific about when to skip it: if your app’s value only becomes clear after weeks of use, asking people to pay upfront means asking for commitment before you’ve earned it. If you’re operating at a low price point where volume is everything, upfront payment may cost you more installs than the cleaner signal is worth. And if you’re not running meaningful paid acquisition, the biggest benefit — a stronger ad signal and potential conversion lift — largely disappears, meaning a free trial may do the job with less friction.

Should you offer a money-back guarantee?

So, should you run one? Here’s my honest take: if you’re scaling paid ads through a web or app-to-web funnel, and you have a product that people genuinely stick with, a money-back guarantee is well worth testing. The biggest upside is the signal it gives ad networks, just don’t let yourself believe it will suddenly transform your conversion rate overnight.

If you’re not running paid acquisition, or you’re still figuring out product-market fit, I’d park it for now. A trial will probably serve you better.

The way I think about it is as a risk-reversal ladder:

• A free trial removes the most risk for the user
• A hard paywall removes the least
• A money-back guarantee sits in the middle: the user pays, but they have protection if it doesn’t work out

It keeps commitment high while still saying: “If this isn’t right for you, you’re safe.”

So start small: pick one segment, one funnel, and one guarantee window — ideally a generous one — and measure two things: your refund rate and whether your ad signal actually. Then judge it on net profit, not conversion rate.

That’s exactly what I’m doing with my client right now. I’ll report back on what the refund rate really looks like, and whether the window shoppers do turn into buyers. (My money’s cautiously on yes.)

Before you test one, run through five quick checks. Try a money-back guarantee if:

• You're scaling paid UA
• You have web or app-to-web payments live
• Your value is clear within the guarantee window
• You can handle refunds operationally
• Your margin can absorb a realistic refund rate

If you can’t tick most of those boxes, a free trial is probably still the better option.

iPhone Duo gives your app two very different screens to lay out for, plus everything in between. And your paywall is the one screen where something looking ‘a little off’ costs you real money.

A paywall is already one of the hardest screens to get right on a normal iPhone. Now the same paywall has to work on a 5.4-inch outer screen, a 7.6-inch inner screen, sideways, half-folded on a table, and in Split View next to another app. If you present your PaywallView in a .sheet like most of us do today, it'll show up in every one of those states, so we want to make sure that everything still looks intentional.

This guide covers what iPhone Duo is, and what each posture does to your paywall. Plus, what Apple recommends, and exactly how to set up a RevenueCat paywall so it feels native on Duo starting today.

What is iPhone Duo?

iPhone Duo is Apple's first foldable iPhone. It has a shape like a passport and opens like a book to about the size of an iPad Mini.

iPhone Duo went on sale Friday October 23, 2026, running iOS 27.1. You can test it today with the iPhone Duo simulator in Xcode 27.1, and you can already submit iPhone Duo-optimized apps to the App Store.

The simplest way to think about it: closed, it's an iPhone; open, it's much closer to an iPad. Apple's Human Interface Guidelines (HIG) ask you to design for two sizes: compact width on the outside and regular width on the inside.

Lots of different postures

This is where things start to get really interesting...

iPhone Duo can be closed, fully open, or angled somewhere in between. Apple's hinge API (onHingeChange in SwiftUI, UIHingeInteraction in UIKit) reports these as .closed, .partiallyOpen, or .fullyOpen. On top of that come portrait, landscape, and a few ways to set the phone down.

Check your close button

RevenueCat Paywalls can now swap your close button for the system Close control. iOS puts it in the vertical side bar on iPhone Duo and in the navigation bar on iPhone and iPad. Select your close button in the paywall editor and turn on Use system navigation on the Paywall Editor. It needs purchases-ios 5.98.0 or later.

Existing buttons keep their designed look until you turn it on. It works the same way for Back buttons in multi-step paywalls. Android, web, and hybrid SDKs show your designed button.

Using presentPaywallIfNeeded? The SDK provides the navigation bar for you, so once Use system navigation is on, there's nothing else to do.

Presenting PaywallView yourself in a sheet? The SDK adds Close to your existing navigation bar. If there isn't one, wrap PaywallView in a NavigationStack:

.sheet(isPresented: $showPaywall) {
  NavigationStack {
    PaywallView()
  }
}

Using PaywallViewController in UIKit? The SDK adds its controls to the presenting navigation controller.

Keeping your designed X? If you're on an older SDK or a hybrid SDK, or you leave Use system navigation off, your X stays inside the paywall. You can opt the sheet out of the vertical bar instead:

.sheet(isPresented: $showPaywall) {
  if #available(iOS 27.1, *) {
    PaywallView()
      .toolbarVerticalBehavior(.disabled)
  } else {
    PaywallView()
  }
}

Built a custom X into your design? Any close button you've positioned yourself, like an overlay in your own code, stays exactly where you put it. On the outer display, that can put it right next to the camera or the side bar. Check it in the Duo preview in the paywall editor and in the simulator, and move it if it collides.

Then build with Xcode 27.1, check the result in the Duo simulator, and use the Duo preview in the paywall editor to tune your layout for the shorter outer screen and the wider inner one.

Official Apple recommendations for paywalls on iPhone Duo

Apple published a new HIG page for iPhone Duo and a set of tech talks alongside it. None of it is written specifically for paywalls or StoreKit, but a handful of the general rules map directly onto how a paywall should behave.

Prioritize small adjustments over big rearrangements

Apple asks you to "avoid extreme layout changes as people fold the device" and to "maintain the same functionality across device poses". For a paywall, that means the same packages, prices, trial terms, and call to action whether the phone is open or closed.

Put Close where people now expect it

On Duo, toolbars move to a vertical strip on the side. Apple says to reserve the top of that vertical axis for navigation controls like Back or Close. Turn on Use system navigation for your paywall's close button, and RevenueCat swaps it for the system control so it moves with the toolbar. The "Check your close button" section above covers the fix.

Keep anything tappable off the fold

When the device is partially folded, iOS slides sheets out of the fold for you, so a paywall presented in a sheet is covered. If you present your paywall full screen, the fold runs right through the middle of it. In that case, Apple suggests an even number of columns so nothing straddles the fold — so two package cards side by side work better than three.

Know where your sheet will land

On the inner display, sheets are centered by default. You can move one to the leading or trailing edge with presentationPlacement(_:). On the outer display, a sheet with a single button can opt out of the vertical bar and stop just short of the camera.

Adapting your existing paywall for iPhone Duo

You don't need to wait for anything new to get a good result on Duo. Here's the setup I'd use, built entirely on features that are live in RevenueCat Paywalls right now.

1. Preview your paywall on iPhone Duo in the paywall editor

The RevenueCat paywall editor now includes an iPhone Duo preview. You can switch between open and closed, portrait and landscape. The preview matches the Duo's screen shape, safe areas, and camera, and it shows your paywall as it looks in an app built with Xcode 27.1. It's the fastest way to spot problems before you open Xcode.

2. Build with Xcode 27.1 and open the Duo simulator

Install Xcode 27.1, choose iPhone Duo in Device Hub, and use the controls at the bottom of the simulator to open, close, rotate, and fold it. Walk your paywall through every posture above before you change anything, so you know what you're actually fixing.

If you present PaywallView in SwiftUI, Xcode Previews can help too. The canvas overrides picker now has a Display group for previewing content on the device's other display.

3. Present your paywall in a sheet

A sheet does a lot of Duo work for you. On the inner display, the system centers it by default. When the device is partially folded, the sheet slides away from the fold on its own.

The simplest option is RevenueCat's presentPaywallIfNeeded modifier. It checks the entitlement for you, presents the paywall in a sheet, and dismisses it once the entitlement is active. On iPad, it shows the paywall in a modal that's roughly iPhone-sized.

If you want more control, present PaywallView yourself in a .sheet. Just make sure to check the placement of your close button when you do so (see "Check your close button" above).

4. Give your content a maximum width

On the open, inner display, a paywall built for a phone can stretch edge to edge. Set your main content stack to Fill, then give it a Max width so it stops growing on wide screens. Min/max sizing needs purchases-ios 5.93.0 or later; older SDKs ignore the limits. You can also ask the Paywall AI Editor to make your paywall look good on iPhone Duo. For a design walkthrough with starting values, see Designing RevenueCat Paywalls for both iPhone Duo displays.

5. Run the checklist

Before you ship, walk your paywall through every posture and check:

• Close is reachable and doesn't collide with the camera or the side bar
• Close and Back show up as system controls, in the side bar on the closed display
• The call to action is visible without scrolling on the closed, landscape screen (or you've made peace with the scroll)
• Nothing tappable, and no price or trial term, sits on the fold when partially folded
• The inner display in landscape doesn't look stretched
• Select a package, fold, and unfold — your selection is still there
• It still looks right on a regular iPhone and iPad

Ship it

You can submit iPhone Duo-optimized apps in App Store Connect today. Starting April 2027, any app you submit will need to include iPhone Duo screenshots, so it's worth capturing your app on both displays now. App Store Connect also has a new preview tool that shows how your screenshots and product page look on iPhone Duo before you submit.

Why native paywalls help here

This is the part I'm most excited about: RevenueCat Paywalls render natively on iOS, and PaywallView is a regular SwiftUI view. That's why everything in this guide works with Apple's own tools. You present it in a system sheet, swap its close button for the system one, and let iOS move it out of the fold.

Someone who just unfolded a brand-new phone is going to notice a paywall that wasn't built for it. Make sure yours was.

What's next

We're actively working on making RevenueCat Paywalls even better on iPhone Duo and other foldable devices, and this guide will grow as that work ships.

Changelog

• October 24, 2026: Added Use system navigation for close and back buttons (purchases-ios 5.98.0) and min/max sizing, and updated for iPhone Duo going on sale.
• October 6, 2026: Updated for Xcode 27.1, App Store submissions opening for iPhone Duo, and the April 2027 screenshot requirement. Added the close button section and the toolbarVerticalBehavior(.disabled) quick fix.
• September 28, 2026: First version. Covers postures, Apple's guidance, the Duo preview in the paywall editor, and presenting your paywall with a native Close button.

Thank you

Huge thanks to the Paywalls team for all the work they've been putting into foldables. If you've built a Duo-ready paywall with RevenueCat, I'd love to see it! Send it my way on X @austnstuff, or to austin.blake@revenuecat.com.

Further reading

• Three steps to make your app shine on iPhone Duo
• Prepare your app for iPhone Duo
• Raise the bar with iPhone Duo
• Design for iPhone Duo
• Designing for iPhone Duo
• Strike a pose with adaptive layouts on iPhone Duo
• Designing RevenueCat Paywalls for both iPhone Duo displays
• Paywalls on iPhone Duo (RevenueCat docs)

Sure, shorter trials mean earlier payments, faster feedback for paid campaigns, and lower costs of providing free access. That last one matters most if you’re running an AI app, where every free session carries a real, variable cost behind it.

Yet our State of Subscription Apps 2026 report found a 42.5% median conversion rate for trials of 17+ days, versus 25.5% for trials of four days or less. That’s roughly 67% higher.

But do those subscribers keep paying? And does the pattern differ depending on subscription plans?

We analyzed 17,000+ apps to benchmark conversion and renewal across trial durations for weekly, monthly, and annual subscriptions. We also compared AI and non-AI apps and explored differences by category and subscriber region.

Which trial lengths do high-volume apps choose?

First things first: we looked at the 100 apps with the most trial starts in each category and plan duration, and checked what trial length each one runs.

Short trials tend to dominate. On weekly plans, 81–100 of those apps use trials of four days or less, depending on category.

Monthly and annual plans also lean toward trials of nine days or less, although the mix varies by category.

Education, Health & Fitness, and Travel favor 5–9-day trials, while Productivity and Photo & Video favor trials of four days or less. One possible explanation is how long users need to evaluate the app: some benefits take repeated use to assess, while others are apparent in a single session.

These are apps with the most trial starts, rather than the highest revenue or retention. Their choices show what’s common at scale. But this doesn’t establish which trial length performs best.

That leaves a useful question: how do conversion and renewal compare across those common short trials? And what changes in the less common, longer-trial groups?

How many trial users reach a second payment?

Our data actually shows that longer trials are often associated with higher renewal rates, though the pattern varies by subscription plan:

• Weekly subscriptions: The share of trial users who paid and renewed once is slightly higher after 5–9-day trials than after trials of four days or less: 14.4% vs. 11.8%. Evidence for longer trials remains limited.
• Monthly subscriptions: Longer trials are associated with more trial users paying and renewing: 30.6% after 10–16-day trials vs. 18.5% after trials of four days or less. The pattern then levels off in the 17–32-day trial group.
• Annual subscriptions: The share of trial users who paid and renewed increases with trial length across all four groups, from 3.5% after trials of four days or less to 18.5% after 17–32-day trials. Though trial duration alone may not explain higher retention.

One caveat before we go further: there is a correlational pattern, and a flattering one. Someone who’s still in your trial on day 25 of a 30-day window is simply more likely to pay than someone who bails on day two. Keep that in mind as the ceilings and floors get more specific below.

Do conversion and renewal favor the same trial length?

We also looked at conversion and first renewal separately to see whether longer trials coincide with more users paying, more paying subscribers renewing, or both.

For weekly subscriptions, the difference between the two common short-trial groups is larger at renewal. Trials of 5–9 days convert 24.3% of trial users, compared with 22.3% for trials of four days or less. Among paying subscribers, 65.9% renew after 5–9-day trials, versus 57.9% after shorter trials.

There are too few qualifying apps offering weekly plans with trials beyond nine days to extend that comparison reliably.

For monthly subscriptions, conversion is higher in the 5–9-day trial group than in the shortest-trial group: 45.9% versus 39.6%. The 10–16-day group has similar conversion, at 46.6%, but higher first renewal: 72.0% versus 62.8% of paying subscribers.

The 17–32-day group has the highest first renewal rate, at 77.5%, but lower conversion than either middle group, at 43.7%.

For annual subscriptions, both rates are higher across longer-trial groups. Comparing trials of four days or less with 17–32-day trials, conversion rise from 24% to 44.6%, and first renewal from 18.3% to 47.5%.

Of course, a trial rarely builds a year of loyalty on its own: a longer trial mostly gives annual buyers more time to be sure before a bigger, harder-to-reverse commitment. So the people who convert after that longer look might already be the ones less likely to cancel.

What if you remove the trial altogether?

Here’s another interesting finding: subscriptions purchased without a trial have lower first-renewal rates on weekly and monthly plans than those that begin with one.

The weekly gap is particularly large: 35.9% of paying subscribers renew without a trial, compared with 57.9% after trials of four days or less and 65.9% after 5–9-day trials.

Annual plans show a different pattern. No-trial renewal is higher than renewal after trials of up to nine days, but lower than after longer trials.

Note: this table measures first renewal among paying subscribers, not all trial users, so these numbers run higher. This comparison a;sp doesn’t tell us how many people purchase when shown a no-trial offer.

Lower renewal doesn’t automatically make a no-trial offer less profitable, though. David Vargas’s case study found that removing the trial, alongside changes to pricing and plans, helped one app earn enough per paying customer to support paid acquisition without it.

How does trial length relate to conversion and renewal in AI apps?

For AI apps with usage-based inference or generation costs, extra free access needs to justify its expense. Besides, higher churn with lower conversions means there's less room to get the length wrong.

The monthly results offer a useful comparison.

Trials of 5–9 days and 10–16 days show almost identical conversion, at 38.2% and 38.5%. First renewal is higher in the 10–16-day group, at 64.2% versus 57.4%.

But the 17–32-day group shows no further renewal gain: first renewal is 64.1%, while conversion falls to 31.8%. In this dataset, the longest monthly trials don’t provide a stronger conversion or renewal benchmark than 10–16-day trials.

For annual AI subscriptions, conversion is 33.8% after 10–16-day trials, compared with 23.3% after 5–9-day trials. First renewal is also higher, at 29.4% versus 19.6%. For weekly AI subscriptions, the difference is smaller. Conversion is 23.1% after 5–9-day trials versus 22.3% after trials of four days or less; first renewal is 62.5% versus 57.9%.

Without a trial, first renewal is lower on weekly and monthly AI plans. Annual no-trial renewal is 18.9%, compared with 15.1% after trials of four days or less and 19.6% after 5–9-day trials.

Does giving users more trial time improve conversion across regions?

On annual plans, North America and Western Europe have higher conversion across progressively longer-trial groups. Asia-Pacific follows that pattern up to 10–16 days, but has lower conversion in the 17–32-day group.

On monthly plans, conversion in Middle East and Africa, India and Southeast Asia, and Latin America is highest in the 5–9-day group and lower in the 17–32-day group. The largest gap among these regions is in Middle East and Africa: 38.3% versus 27.4%.

Do the same trial lengths outperform across app categories?

On monthly plans, longer-trial groups generally have higher renewal rates across app categories.

But they don’t always have higher conversion. In many categories, conversion is highest in the 10–16-day group and lower in the 17–32-day group.

When interpreting these differences, consider two timelines: how quickly users recognize the app’s value, and how often they have a reason to return. The data don’t measure habit formation, but those questions can help you decide what extra trial days should accomplish.

Three categories illustrate the differences:

• Media & Entertainment: The 10–16-day group leads on both conversion (58.9%) and first renewal (79.4%), with neither rate higher in the 17–32-day group. For streaming apps, the question to explore is whether extra trial days help users discover more content they want to keep watching.
• Utilities: Conversion is highest in the 10–16-day group, at 47.4%, compared with 44.0% in the 17–32-day group. First renewal is highest in the longest group, at 77.9%, versus 55% for trials of four days or less. A user might recognize a tool’s value after one task. The question for a longer trial is whether it gives them opportunities to use it again.
• Health & Fitness: Conversion is higher in the 5–9-day group than in the 10–16-day group: 46.8% versus 40.4%. First renewal is higher across longer-trial groups, from 51.5% for trials of four days or less to 77.1% for 17–32-day trials. If you’re considering more trial time, check whether users keep completing workouts or logging progress during those extra days. That would give you evidence of continued engagement, rather than assuming a longer trial builds a habit.

So, what's the right trial length for your app?

These findings make a case for challenging a short trial chosen by default. But they also show where longer trials have no clear advantage, helping you narrow down which alternatives deserve a test.

At the end of the day, the answer isn't "run longer (or shorter) trials," "cut trials entirely," or a number copied from the leader in your niche. It's whichever pattern matches your app:

• Time to value. How long a user needs to experience your app before they can fairly judge whether it's worth paying for.
• Habit versus motivation. Utilities' renewal kept climbing long after conversion had already peaked, because deciding fast and building a routine aren't the same thing. Health & Fitness runs the same tension the other way: a longer trial builds the habit, but it also gives motivation more time to fade first.
• Audience context. Price sensitivity and trust in recurring billing can change what a longer trial buys: more confidence to pay, or just more time to back out. So does whether users are weighing you against a free alternative, and how much they need to learn before they can fairly judge your app at all.
• Cost. Longer trial delays revenue and stretches out how long paid acquisition takes to pay for itself. If your app has a real per-user cost behind every session, that spend adds up whether or not the person converts.

The best next action? Use the benchmarks above as a starting point, then test trial length against your own subscription plans, your app's specifics, and what you know about your audience.

RevenueCat Experiments lets you get there faster. Set trial length as the variable, and let your own revenue numbers make the call.

How we analyzed the data

We compared trial conversion and paid renewal separately for weekly, monthly, and annual subscriptions on the App Store and Google Play, with breakdowns by platform, AI classification, category, and subscriber region. We also looked at the 100 apps with the most trial starts in each category.

• Period: August 2025–July 2026, based on trial starts for conversion and renewal dates for retention. The combined trial-to-first-renewal measure follows the same trials through both payments, including earlier annual cohorts.
• Measurement: Median app-level rates. Each renewal rate measures subscriptions that paid again, conditional on the previous payment.
• Sample requirements: More than 100 eligible trials or subscriptions reaching first renewal per qualifying app segment. Groups with fewer than 20 apps are directional.
• Trial coverage: No-trial subscriptions appear only in renewal comparisons. Trials longer than 32 days are excluded from conversion figures.

Watch on YouTube

The $150 Mac that couldn't build iOS apps

César had a computer science degree and a job writing C# for an ad agency when he walked past a shop window in Västerås and saw an iPhone in demo mode, scrolling through contacts. He'd been building for a Sony Ericsson Xperia X1 and hated everything about it. "I just saw it and I was like, 'Oh my God, this is amazing.'"

That night, a well-known Swedish comedian posted asking whether someone could make him an app. "And I have no idea how to build an app. I didn't have a Mac. I didn't know what Xcode was. I knew nothing," César says. Charlie's follow-up: "Well, you didn't even have an iPhone at this point, right? You just saw one?" He hadn't. He wrote back anyway, agreed a price, and went back to the store to ask what he'd need.

They sold him a returned PowerBook G4 for $150. He installed Xcode, opened the sample project, hit build, and discovered that iOS apps needed an Intel Mac to compile. "So I had to spend all the money I was getting paid to build the app to buy my first Mac. So that's how I got into app development."

The app itself was a blog reader: a WordPress plugin he wrote to expose posts as JSON, pulled into a list. "When there only was one screen size," as he puts it. The commitment came before the tooling, and the fee paid for the tooling. He's been employed as an iOS engineer since 2011.

A CloudKit experiment, forgotten, then handed to a beginner

Around the time CloudKit launched, César built a recipe app to see what the framework could do. Recipes were CloudKit records; you could see other people's. He named it Cooking, shipped it, and moved on. "I put it out there and I forgot about it."

It kept being used. One user had more than a hundred recipes in it, which mattered because of a detail Sofia raises: you couldn't reorder instructions or ingredients. Get a step wrong and you redid the recipe. Charlie: "This is the classic looking for some app as an excuse to try out a piece of technology."

Years later, Sofia wanted to learn to code. She'd started with Swift Playgrounds on an iPad, steering a character called Byte through a maze. César had an app lying around that he wanted rebuilt in SwiftUI. "Why don't you just rewrite all the views?" Charlie's verdict: "Easy first task."

"I started just building up the views and I guess I never stopped because I'm still building the views." Her biggest obstacle wasn't the logic. "I didn't have any terminology. So when I wanted to Google for something, I had to describe what I wanted." Even the word modifier wasn't hers yet. Cooking became Ambre, and Ambre started getting featured on the App Store.

Apple said the call was of utmost importance. It was a two-hour technical interview.

Sofia's plan was to get good enough to be hired as a developer somewhere. Then César saw a post from Apple's Mike Stern about Apple Entrepreneur Camp and told her to apply.

"I was terrified and César said, 'Oh, well, what's the worst thing that's going to happen?' They say no or they say yes. And I said, 'Yeah, that's the worst thing. They can say yes.'" Because then she'd have to do it.

The email that came back said it was imperative to get a call scheduled that week. She asked César what Apple could want. His guess: a five-minute welcome call, they just want to tell you you're in. "Oh, it turned out it was a technical interview for two hours."

She got in. The camp ran virtually during the pandemic, two weeks of DTS hours with Apple engineers, design sessions with Apple designers, and pitch training, on a nine-hour time difference. "We literally slept and ate and coded." What she took from it, she says, is going to sound cheesy: "my confidence, because going in, I felt like such an imposter. I was nervous at every meeting thinking, oh, they're going to call me out." The environment did the opposite. Her first client project followed, with César, across three time zones.

Everyone posted code. She posted about color.

Ambre's marketing, by their own account, has been light: an Instagram account that mostly works as a way for users to reach them. What grew was Sofia's own presence, after César and a contact at Apple all but pushed her into it.

She posted about app development with a tilt toward UI and design, and it found an audience. Her explanation: the community's feed was mostly code — someone found a new API or SDK and tried it out. "Whereas I would like, ooh, this color combination is super nice. And if you put it this way in the layout, it would read much better." Being one of the few people talking about design in a stream of code posts was the differentiation.

Charlie's own first memory of them is a marketing move too. On the roof of the Apple Park Visitor Center, Sofia handed him a card with a QR code. It opened Ambre as an App Clip, inside which another QR code led to a recipe: how to make Swedish fish. Then she pulled a bag of actual Swedish fish out and handed it over. "I watched you do this to other people after me, and we all had the same reaction." His conclusion at the time: these are very fun people.

Does the code really matter anymore?

The episode ends where the edit opens, on a question that a designer-and-engineer pair are unusually well placed to argue. César's position: "With AI today, we can build so much stuff. The thing that's going to put you apart or your product apart from the competition is the experience you offer." The feature set won't do it; design is about to matter more, not less.

He borrows an analogy from a Linux figure he'd seen quoted: complaining that you don't know what AI-generated code is doing is like complaining that you don't read the assembly. "What we own is the UX and quality of our app. Our customers are not going to read the code."

Sofia's version comes from the toolbox. "Procreate is a tool. An iPad is a tool. A pencil is a tool. When you buy watercolor, it's pigment and something that bind the pigment." AI is the next one, and it opens the door for designers who had the idea in their head but not the means to build it. This year that's been her: "I can talk directly with Claude and see my ideas come to life within minutes, hours, depending on the complexity."

Charlie pushes back a little — AI-built things feel similar unless someone is making all the small choices — and César closes with the question he wants developers to sit with: "If you make sure QA is awesome, the app looks amazing and it solves a real problem, does the code details really matter?"

Also in the full episode: what a textile engineer actually studies (geotextiles under airport runways, a thesis on getting a medical bandage to a CE standard), César's detours through blackjack dealing and Volvo factory software, the designers Sofia keeps a running iMessage thread with herself about, and the Ambre update landing with iOS 27.

Guest links

• Sofia Larsson on LinkedIn
• César Pinto Castillo on LinkedIn
• Ambre on the App Store
• Ambi Studio

We’ve been polishing the agenda for months, and it’s finally ready for your eyes: five keynotes and 36 workshops, split across exclusive virtual and in-person content. So whether you’re joining us in NYC or from the comfort of your home office, you’ll be leaving with fresh ideas and the momentum to ship them.

Keynotes

Here’s what’s heading up the main stage: five sessions from app leaders about what worked, what didn’t, and what they’d do differently — straight from the people building the apps.

All the keynotes will be available to watch on YouTube after the event. So even if October 21 is back-to-back meetings for you, there’s no need to miss anything. Register now to get sent the replays as soon as they drop.

Confidence engineering: why your app's activation flow is probably too short — Ravi Mehta, ex-CPO, Tinder

Every mobile growth team obsesses over friction — fewer screens, fewer fields, fewer taps between install and activation. It's conventional wisdom, and it's incomplete. One healthcare app replaced a three-step checkout with a twenty-five-step intake flow and conversion jumped 40%.

At Tinder, Ravi's team did the opposite — stripping onboarding to under two minutes to pull in millions who'd never have finished an eHarmony profile. In this session he'll share a framework for diagnosing your own flow: when to strip friction to the bone, when to add steps that earn trust, and how to spot the 'death zone' where teams split the difference and get the worst of both.

You'll leave with: a way to audit your own funnel, step-by-step, and a sharper question than "should this be shorter?"

Breaking the rules on purpose: the contrarian bets that built Babbel — Julie Hansen, CRO & US CEO, Babbel

Every subscription app has heard the same advice: never sell lifetime deals, don't bother with web checkout, go freemium to keep the funnel full, spend only on acquisition… Well, Babbel has ignored most of the advice — and is still here, 30 million subscriptions later.

As Babbel’s US CEO for nearly a decade, Julie had a hand in most of those bets. She’ll walk through why they made them against the advice of the day, which ones they’d make again, and what they cost Babbel.

You’ll leave with: the insight to discern which rules in your own playbook are real, and which are just habits the industry hasn’t questioned yet.

Built to burn: how to turn a high-churn product into good subscription economics — Greg Cohn, Co-founder & CEO, Burner (Ad Hoc Labs)

Burner is an app for disposable phone numbers, with a button that destroys the very thing you're paying for… yet it has been growing and profitable for almost a decade. In fact, half of Burner’s new subscription revenue on iOS is from users who previously churned.

Greg says they didn’t plan it that way. But along the ride, they learned not all churn is failure — some of it, in fact, is success. His session will tell the story of that success: from designing for profitable churn, to cohort math and monetization architecture.

You’ll leave with: analytical frameworks and mechanics you can steal — and a sneak preview of the new-to-the-market retention hack Burner’s testing next.

Speedrunning subscription monetization: what Tolan learned when the AI bill came due — Ajay Mehta, Founder, Tolan

For a decade, subscription apps ran on one assumption: the marginal cost of a subscriber is roughly zero. AI broke that. Now free users cost real money, and the heaviest users can cost more than they pay.

At Tolan, they learned this lesson in week one, when the OpenAI bill outgrew their userbase and a paywall became a survival mechanism. Since then, the team has run a decade’s worth of monetization plays in double-time. Ajay will recount each of these decisions; what they expected, what actually happened, and how they came to their ultimate monetization rule: would they be happy explaining it on a podcast?

You’ll leave with: a sense of what the end of zero marginal cost means for your own pricing, whether you're building an AI app today or adding AI to the one you have.

RevenueCat product update ahead of 2027 — Jacob Eiting, CEO & Co-founder, and Miguel Carranza, CTO & Co-founder, RevenueCat

We won’t spoil too much about our product keynote, but you can expect a retro on the last 12 months, roadmap reveals, and live product launches.

You’ll leave with: an insider's look at what's next for RevenueCat.

In-person workshops (block one)

One of App Growth Annual’s biggest opportunities is getting the right people in one room, asking the same questions you’ve been wondering about. Whatever your focus is right now, there’s a hands-on session to help, filled with genuinely useful conversations.

Apple Ads 2026, beyond the basics: what changed, what matters, and how to act on it — Thomas Petit, Growth Advisor

Apple Ads has changed more in the last two years than in the eight before it. This interactive session skips the 101 and tackles four core questions: Which numbers can you trust? Should you let Apple decide how you buy inventory? How do you test and iterate on creatives? And how much should you really buy?

Each question is unpacked with Thomas’s personal experience, how to use the functionality, and where the numbers can fool you. Expect questions, strong takes, and polite disagreement. Not recommended for ASA beginners.

You’ll leave with: a varied set of perspectives and focused examples to help inform complex ASA decisions.

Signal engineering: build your subscription app signal plan — Shumel Lais, Co-founder, Day30

Want to send better signals to Meta, Google, and TikTok, but your event tracking and measurement setup isn’t ready for it?

Shumel’s workshop will have attendees audit their own subscription funnel from install through renewal, scoring your existing events against speed, volume, intent, commercial value, and measurement reliability. Take part to identify which signals to test first and what you need to fix before you begin.

You’ll leave with: a signal readiness scorecard and prioritized action plan for your growth and data teams.

The executive roundtable: networking and problem-solving with fellow leaders at scaled apps — Ron Schneidermann, CEO, Acely

No agenda, no slides — just candid discussion and problem-solving with a small group of fellow app executives. Ron kicks the session off with lessons from scaling AllTrails to millions of subscribers, then opens the floor to questions and discussions on team building, product decisions, and growth challenges.

You’ll leave with: fresh perspectives from peers who’ve been there too.

The viral iteration loop: adapt trending content into high-converting creative — Diego Kafie, CEO & Co-founder, Noise

Viral content already exists in your niche — the opportunity is turning it into creative that drives installs for your app. In this workshop attendees will search live for what's working on TikTok and Instagram in your category, break down why it's performing, and adapt it into iterations you can test as paid or organic creative.

You’ll leave with: a shortlist of proven content angles tailored to your app, and a repeatable process for finding and adapting them.

How AI is changing subscription app monetization — Phil Carter, Founder and CEO, Elemental Growth

LLM-powered features carry non-trivial costs, but most subscription apps are still approaching monetization as though their gross margins haven't changed. Spend this session reviewing the strategies that the best AI apps are using to adapt: restricting freemium, shortening trials, adding higher-priced AI tiers. Wrap up by benchmarking your own metrics against peer apps and apply proven pricing tools (Van Westendorp, Gabor-Granger, MaxDiff, Conjoint) to your own packaging.

You’ll leave with: a benchmarking tool, a pricing study template, and playbooks for adapting your monetization to the AI era.

How to launch and grow your app in Japan and Korea — Hyerin Choe, Customer Success Lead, AB180

Japan and Korea are two of the highest-spending mobile markets in the world, but most Western apps stall at entry because the playbook that works in the US doesn't translate. Join Hyerin Choe from Korean app growth agency, AB180, to identify where your current growth strategy breaks down and build a localized go-to-market plan.

You’ll leave with: a market-entry framework covering channels, positioning, and the cultural signals that data alone won't reveal.

Build a user research system that runs itself — Ekaterina Gamsriegler, Growth Consultant & Director of Growth at DataCamp

Most apps run user research in bursts, then go dark for months. Ekaterina will walk through how to design an always-on feedback system for your app instead. From choosing the right research inputs (cancellation surveys, in-app prompts, price sensitivity polls), to writing the templates, mapping distribution channels, and building a cadence that feeds insights into your experimentation pipeline without becoming a full-time job.

You’ll leave with: a research system that’s ready to launch next week.

Roast my ASO: your App Store listing, audited live — Steve P. Young, Founder, App Masters

Bring your App Store listing and get it torn apart live. Steve will audit real participants' metadata, screenshots, and keyword strategies against what's actually driving installs in their category — with pre-prepared case studies showing where AI-assisted ASO is outperforming manual approaches.

You’ll leave with: knowledge of exactly what’s costing you rankings and downloads — and what to fix first.

Find the moment your app earns the right to ask for money — Olha Yohansen, Independent Growth Consultant

Has your app earned the user’s trust by the time it asks for money? Olha’s workshop will get you mapping your own onboarding to pinpoint where users first feel “this app gets me” — and check whether that moment lands before or after you ask them to pay. If it's after, you're converting on template momentum, not trust.

You’ll leave with: a redesigned onboarding sequence that puts the aha! moment where it belongs.

In-person workshops (block two)

Our second round of workshops offer 10 hands-on sessions packed with in-the-trenches tactics to grow your app. We know it’s hard to choose, but whichever session you attend, you’re guaranteed to leave with new ideas and experiments to try right away.

Meta UA in 2026: what still works, what's changed, and how scale changes the game — Gessica Bicego, Fractional CMO, Independent Consultant

The right Meta campaign structure depends on your spend level, but most teams use the same setup whether they're spending $10K or $500K a month. Gessica’s workshop will group attendees by budget range where you’ll work through how campaign structure, optimisation approach, setup (CBO, Advantage+, W2A, signal engineering), and creative strategy should adapt for your scale.

You’ll leave with: understanding of which structure fits your current spend and what to change as you grow.

Google Ads for iOS: how to make it work — Ashley Black, Founder & CEO, Candid Consulting

Google has been overlooked as a serious iOS acquisition channel, but the platform has changed, and the opportunity is bigger than most teams realize. Join Ashley to evaluate your own app against Google's current campaign types, identify which formats match your funnel and audience, and stress-test whether the setup pain is worth the payoff for your specific scale and category.

You’ll leave with: a clear yes/no on Google Ads for your app, and a plan for what to test first.

How your ad creative shapes your LTV — Natalia Drozd, Independent Growth Expert

The creative that lowers your CPA isn't always the creative that attracts subscribers who stay. Viral hooks and trending formats can flood your funnel with users whose expectations don't match your product — and you won't see the damage until retention data catches up. In Natalia’s workshop, you’ll map the relationship between your creative narratives and the customer segments they attract, then test your assumptions in a simulation using real campaign data.

You’ll leave with: knowledge of which creative angles to scale, and which are quietly eroding your LTV…

Hybrid monetization: add new revenue without hurting your subscription — Cristian Rotari, Independent Consultant

Not every user will subscribe, but that doesn't mean they're worth zero. In this session you’ll map your user segments, identify which audiences are under-monetized, and evaluate which hybrid tactics fit your product: ads, IAPs, credits, affiliates, partnerships.

Finish by building a monetization ladder for your app and running a cannibalization check to confirm new revenue streams are truly incremental, not cannibalizing existing subscriptions.

You’ll leave with: one experiment that’s ready to test in the next 30 days.

Design habit mechanics that don't fade after week one — Yves Benchimol, CEO & Co-founder, WeWard

Gamification mechanics lose their impact the moment novelty wears off. Most teams respond by layering on more features, rather than questioning whether the mechanic should exist at all. Join Yves to apply a motivation-first framework to your own product and identify what's actually driving repeated use. You’ll then evaluate which mechanics are earning their place, and find where simplifying or removing features would improve retention more than adding new ones.

You’ll leave with: a clear map of which habit mechanics to keep, kill, or redesign.

Ship faster with AI without learning slower — Ethan Garr, Growth Advisor, Breakout Growth Labs

AI has collapsed the time between idea and shipped feature, but most teams haven't upgraded their learning loops to match. You're deploying faster, but are you discovering what users value faster, or just building confidently in the wrong direction?

Ethan will walk through how to map your current growth initiatives across a Velocity vs. Learning Matrix, to identify where AI is genuinely accelerating progress, and where speed is masking the absence of real customer signals.

You’ll leave with: a prioritized view of where to let AI run and where human judgment is key to helping more users reach experiences they can’t live without.

Diagnose your biggest revenue bottleneck — Alice Muir Kocourková, Independent Growth and Subscription Consultant

You've spent the last quarter optimizing something, but was it the right thing? Most teams pour effort into onboarding when the real opportunity is renewal, or obsess over trial conversion when Month 3 churn is quietly draining more revenue.

Join Alice to score each stage of your subscription lifecycle against industry benchmarks, identify where the gap between your app and the norm is largest, and prioritize fixes using an Impact vs. Effort framework.

You’ll leave with: your bottleneck diagnosed, and a 90-day plan to close it completely.

Segmentation as a growth engine: how to scale across segments without breaking efficiency — Bohdan Lopatiy, Product Director - Growth, Flo

Segment smarter, not thinner. Too many segments mean too many tests nobody can read.

Bring your own user base and find the splits that actually matter.

You’ll leave with: a segmentation model that helps you scale, rather than holding you back.

From investment to exit: tactics for raising capital and selling your business — Eric Crowley, Managing Director, Houlihan Lokey

Whether you're preparing for a fundraise or positioning for acquisition, the gap between ‘growing nicely’ and ‘investor-ready’ is usually a handful of specific metrics and positioning decisions. Eric’s workshop will offer a chance to benchmark your business against what buyers and investors are actually looking for right now, identify gaps in your financial story, and pressure-test your positioning with the room.

You’ll leave with: readiness to navigate your next round or exit conversation with confidence.

Roast my web funnel — Nathan Hudson, Founder, Perceptycs / Swoopy

Your web funnel follows the playbook. But the playbook doesn't account for your category, your traffic, or the assumptions baked into every ‘best practice’ you copied.

Come along to Nathan’s web funnel roast and put your funnel on screen to get it torn apart from ad to checkout: what's cargo-culted, what's actually earning its place, and which experiments carry hidden risk.

You’ll leave with: prioritized test hypotheses and the context for why the obvious fix might not be yours.

In-person workshops (block three)

Wrapping up the day, our final block of workshops are definitely last but not least. Expect intimate conversations, practical takeaways, and new playbooks to take home.

Affiliate marketing: when it works and how to start — David Vargas, App Growth Consultant

Most apps treat affiliate marketing as an afterthought or assume it only works for e-commerce. But at scale, it can deliver high-intent users at a fraction of your Meta CPAs — if you pick the right partners and structure the right payouts.

David’s workshop will give you the chance to assess whether your app has the economics and category fit for affiliate marketing, map your ideal partner types, and design a commission structure that protects your margins.

You’ll leave with: a go/no-go decision and a 30-day launch plan.

Build an organic-to-paid acquisition engine — Shane Troy, Co-founder & Partner, Cousin Labs

Organic and paid teams rarely drive the same outcome, and the translation layer between them is where most growth teams leave the biggest gains on the table. In this session, you’ll map the exact loop that turns organic content into scalable paid creative: hypothesis design, creator selection and coaching, asset tagging, feedback loops, and the velocity payoff when winning formats feed directly into paid briefing.

You’ll leave with: a playbook to connect your organic and paid programs immediately.

Your creative pipeline is broken and more AI won't fix it — Elise Zareie, Head of Paid Social, Lingokids

AI handles analysis, iteration, and automation well, but when it's producing your actual ad creative, you often get volume without differentiation, or content that erodes trust with your audience. Join Elise’s session to audit your current pipeline and separate where AI earns its place, versus where it’s producing sameness. Finish by designing the right mix for your vertical: what stays AI, what needs human creators, and how to build that alternative without blowing your budget.

You’ll leave with: a creative production map tailored to your app and audience.

Ad monetization playbook for subscription apps — Felix Braberg, Ad Monetization, 2.5 Gamers

Your app is sitting on a monetization layer it's probably not using (or not using well). Ad revenue data reveals what each user segment is actually worth and whether they should be subscribing or staying on a free, ad-supported tier. This workshop covers how to read impression data as a willingness-to-pay signal, segment users accordingly, and set differentiated pricing.

You’ll leave with: a segmentation framework and a step-by-step tracking setup guide.

Make your app a habit: the lifecycle messaging that keeps people coming back — George Deglin, Founder & CEO, OneSignal

How do you make your app part of your customers' routine? Join this workshop to identify a behavior worth repeating, map where users drop off before they get there, and work out which of those moments can actually be fixed with messaging — and which are product problems a message won't solve. Wrap up by drafting a three-touchpoint journey with the audience, timing and rules behind it.

You’ll leave with: a brief you can hand to your team, from draft messages to behavioral rules and a measurement plan.

From 1 to 100 A/B tests per month: a practical framework for scaling experimentation — Olga Berezovsky, Head of Data & Analytics, Data Analysis Journal

Running more A/B tests doesn’t necessarily mean learning faster. As experimentation programs grow, tests often compete for the same traffic, run for months, and produce results that teams don’t trust. In this workshop, you’ll learn how to decide which ideas deserve a fully powered A/B test, which should be evaluated using faster methods, and which aren’t worth testing. You’ll then spend time scoring your current test portfolio by potential business value, identifying where rigor is slowing down learning, and redesigning your pipeline to complete more meaningful experiments.

You’ll leave with: a prioritized experimentation roadmap sized to your actual traffic and resources.

Your AI marketing team: what it can run, what it can't, and what to do about the rest — Jessica Gotti, Head of Performance Marketing, Bend

One marketer with AI can now do the work of a small team. This session breaks marketing into single functions and asks one question for each: can AI run it alone, does it just help, or is it still a person's job? Each answer comes from practice — real projects where AI took over, helped, or failed.

You’ll leave with: a map of the AI marketing team and real examples to make it work.

$1M to $10M ARR: the founder-to-CEO mistakes that stall your next stage — Josh Peleg, Vice President M&A and Business Development, BlueThrone

The skills that got you to $1M ARR won't get you to $10M, but they’ll get you to this workshop and that’s pretty close. Join M&A guru Josh to audit your own setup and mindset across four dimensions — growth, product, monetization, and team – and identify which founder habits are now bottlenecks. Bring your real growing pains; the room will workshop them together.

You’ll leave with: knowledge of the three changes needed to unlock your next stage.

Fix your activation before it kills your retention — Daphne Tideman, Growth Advisor & Consultant, Growth Waves

Your activation metric is probably measuring activity, not predicting revenue — which means every onboarding test you've shipped this year optimised for the wrong thing. Daphne’s session will help diagnose whether your drop-off is a trust, context, or value problem, before you’ll define the one user action that actually predicts LTV, and pressure-test it with the room.

You’ll leave with: a validated activation hypothesis and one test to ship next week.

Hyper-personalization in app onboarding and monetization — Thomas Cotter, Principal, Elemental Growth

Many apps invest heavily in personalizing onboarding and monetization without seeing meaningful ROI. In this workshop, you’ll learn how to make personalization actually work: what information to collect, how to identify and prioritize opportunities, where and how to experiment, and what to measure. Thomas will walk through real examples, then put attendee apps on screen for live personalization teardowns and test ideas.

You’ll leave with: a shortlist of personalization tests to run, prioritized by likely impact.

Virtual workshops

You didn’t think we’d neglect those watching from home? Our online attendees have six insightful sessions to choose from, but even better — unlike the in-person workshops, these will be recorded and shared to watch back after the day. So no need to panic if you can’t decide which one to tune in to!

Make AI-generated ads that actually convert — Julien Daver, Head of User Acquisition at SplitMetrics Growth Services

Generic AI creative tools promise to fix the production bottleneck of creative production every UA team is battling — but mostly, the output tanks your ROAS, or gets rejected by the network outright. For this session, Julien shares how his team actually integrates AI into their creative workflow, with real campaign data on what worked and what didn't.

You’ll leave with: a production framework built for mobile performance constraints, rather than a list of prompts.

From competitor ad to finished creative, in one hour — Sven Jürgens, Mobile App Growth Consultant, Sven Juergens Consulting

Your competitors have already paid to find out what works in your category, and the results are sitting in a public database anyone can open. What are you waiting for?

Sven will share the whole process live: pulling a competitor's longest-running ads from the Meta Ad Library, lining up the first three seconds of each one until the pattern is obvious, then writing the brief and building the creative that answers it. Copying their ad might get you a worse version of theirs; but answering the pattern gets you yours.

You’ll leave with: a one-page checklist of the nine steps to run this process on your own category the next day.

6+1 AI workflows to scale Meta from your phone — Marcus Burke, Meta Ads & App Growth Advisor, Ctrl Shift

With AI, small and midsized teams can get much of the operating leverage that used to require a fully staffed marketing and growth team. In Marcus’s workshop, he’ll walk through the workflows used across real clients, all drawing on a shared memory that compounds as it learns your account, and how each one makes Meta easier to operate and scale.

You’ll leave with: real workflows Marcus runs across client accounts.

Copy that converts: the language-market fit teardown — Lisa Kennelly, Growth and Product Marketing Strategist, Klarna

AI-written onboarding and paywall copy reads fine but converts flat — because nobody fed it real customer language. In Lisa’s session you’ll learn how to mine App Store reviews, support tickets, and cancellation reasons for the actual phrases, anxieties, and objections your users use, then watch a section of conversion copy rewritten live using what that turns up.

You’ll leave with: a repeatable method for mining customer language going forward.

Building apps people want: the playbook behind 23 million organic downloads — Bria Sullivan, CTO & Founder, Honey B Games

Most app developers build features nobody talks about. In this session, Bria will share the system she uses to decide what to build, and the process of making sure the ideas are compelling enough that users will tell their friends. From researching the market to running surveys, customer interviews, and testing visual directions on real people, this is Bria’s full workflow.

You’ll leave with: a repeatable process for designing features around what your target users actually want.

Nothing works until this does: the app marketing sequence — Yuliya Lennox, Genesis Tech

Most apps don't stall because of bad tactics. They stall because something earlier in the chain was never in place, and every optimization since has been built on top of that gap. This session lays out app marketing as a sequence rather than a timeline: what has to be true before the next thing works. Whether you're pre-launch or years into slow, steady growth, you'll be able to place yourself on it, spot what you skipped, and know what to fix first.

You’ll leave with: a framework for sustainable growth, and foolproof steps to remove blockers along the way

Other highlights

But App Growth Annual isn’t just about keynotes and workshops. Also on the agenda:

Who wants to be a millionARR?

The live interactive game show where app growth knowledge meets dramatic tie-breaker questions, phone-a-friend lifelines, and (of course) real buzzers. If you want to take part you’ll have to make it through the audience qualifier round, before beating fellow contestants in different categories to make it to the top of the leaderboard.

With questions covering app trivia, industry knowledge and growth benchmarks, we’d suggest you start polishing up your knowledge now… (The State of Subscription Apps is good revision material!)

Exclusive virtual content

Online attendees get access to all the main stage content, streamed live from New York, but they also get to enjoy a whole hub of virtual-only material. Including: a drop-in lounge, paywall roast, virtual RevenueCat Booth, and 1:1 networking conversations.

Best of all, you can enter The Meowtrix, an interactive challenge for your App Growth Annual experience. Gather the most points among attendees by checking off specific side quests to climb the leaderboard and claim your prize.

The legendary afterparty

Last year saw Jason Paige (of Pokémon theme fame) bring the energy with a performance of RevenueCat’s official theme song. We then had DJ Jazzy Jeff soundtrack the evening while folks networked, got airbrush tattoos, custom caricatures, and enjoyed plenty of delicious street food.

Will Jason Paige be back this year? Who knows. Will we play the RevenueCat theme song regardless? Probably. Will there be tasty food and free drinks? Of course!

And that’s our full lineup for App Growth Annual. A jam-packed schedule filled with insights, inspiration, and new connections — maybe you’ll even meet your future co-founder.

We’ll see you on October 21!

None of them were canceled because they were bad or too expensive. They were canceled because, well… I wasn’t using them. Oops.

And it turns out I’m not alone.

According to the State of Subscription Apps 2025, ‘not enough usage’ is the number one reason people cancel subscription apps, accounting for 37% of cancellations — ahead of ‘price’ at 35%. The 2026 report showed we got a little more price-sensitive, but ‘not enough usage’ is still the second biggest driver of churn; ranging from 26%–40%, depending on the category.

When I covered ‘not enough usage’ in my top five cancellation reasons article, I gave it a short and sweet section. This has bothered me ever since. I haven’t seen a single article or podcast give this mega churn reason the attention it deserves. So here we go!

By the end of this read, you'll be able to tell the difference between a usage problem and a price problem. More importantly, you’ll know what to actually do about each issue.

How to diagnose price vs. usage churn

Here's the hard part: you often don’t know for sure why someone actually left. Even when you have a stated cancellation reason (Google Play surfaces these, while the App Store is a little trickier), cancellation surveys are not the reliable source of truth many teams treat them as.

A SaaS study on 723 participants by User Intuition found that stated exit reasons matched the actual churn driver only 27.4% of the time. Price was the reason 34.2% of churners gave, but it was the real driver in just 11.7% of those cases. Whilst the study wasn’t focused specifically on mobile apps, the lesson still holds: the reason someone gives when they cancel is often the surface explanation, not the underlying cause.

“Too expensive” might actually mean “I wasn’t getting enough value.”

“Not using it enough” might actually mean “I stopped believing this would work for me.”

So don't stop at the survey data. Use quantitative signals to understand whether you’re dealing with a price problem, a value perception problem, or a usage problem. Look at things like engagement patterns, feature adoption, time-to-value, and retention cohorts.

Then layer in qualitative research (user interviews, cancellation conversations, and feedback from churned users) to understand the story behind the numbers.

1. Define your version of ‘enough’ usage

Before you can solve for usage or even start a lovely little quantitative deep dive, you need to know what ‘enough’ actually looks like for your app. And sometimes ‘enough’ is much less frequent than you expect. Sometimes it varies wildly between user groups.

I worked with a meditation and workshop app where some users opened it once every month or two and still happily paid for an annual subscription. Because the value they got from that single session was high enough to justify the cost.

Meanwhile, other users who opened the same app a few times a week didn’t think it was worth paying for. Same app, but completely different definitions of ‘enough’.

As Dan Layfield of Subscription Index argued, usage cadence should match how long and how often the user actually experiences the problem you solve. A fitness app might need three sessions a week. A meditation app might need daily engagement. A personal finance tool might only need to be opened once or twice a month. Daily active users are often the wrong metric entirely.

This is exactly the point Asya Paloni of Welltory also makes: Duolingo's daily streak and light-guilt mechanics work because the behavior is tiny — opening the app for three to five minutes gives the user an immediate reward. That model does not translate neatly to a behavior-change app where the user has to do something difficult in the real world.

Asya suggests that reminders and human support improve engagement in those contexts, while gamification (especially shallow attempts like badges and streaks) often doesn’t improve retention. In some cases, forcing the Duolingo playbook onto a health or finance app can actually make things worse, creating pressure around the wrong behavior.

The classic activation thresholds are useful reference points:

• Slack found that around 2,000 messages correlated with teams that almost never churned
• Facebook identified reaching 7 friends within 10 days.
• Twitter/X focused on following 30 accounts.

All widely reported. All completely different. All built around the natural cadence of a specific use case. So the question is: what’s yours?

Then it’s time to start running the analyses that actually matter.

2. Look at pre-cancellation usage

Start with the 30 days leading up to cancellation for churned users. Were they still actively using the app? Or had usage already dropped to almost nothing?

If engagement had fallen off a cliff before they canceled, that’s a usage problem. The cancellation was just the final step.

If they were actively using the app right up until the moment they left, then price (or another factor) becomes a much more likely driver.

The key question: did they stop because they stopped seeing value, or did they stop because the price no longer felt justified? This guide on spotting churn before it happens covers the signals to look for in more detail.

3. Segment churners by usage frequency

Look at who is saying they left because the app was ‘too expensive’.

Are your heaviest users also citing price as a reason for leaving? If so, you may have a genuine pricing or value perception issue.

But if price complaints are concentrated among your lightest users, you might actually be looking at a usage problem wearing a price mask. They’re not thinking, “This costs too much”. They’re thinking, “I’m not getting enough out of this to keep paying”.

4. Compare cancellation reasons across price tiers (if applicable)

If you have multiple pricing tiers, compare churn reasons by plan. If your lowest-priced subscribers are still saying ‘not enough usage’ rather than ‘too expensive’ — especially if their actual usage data is low — the problem probably isn’t the price. The issue is that the product hasn’t become valuable enough in their routine.

Price is often the reason people say when the value equation stops making sense. The job is figuring out whether the problem is the number on the bill or the value on the other side of it.

Why the discount reflex is the wrong response to churn

What most teams do when they see ‘not enough usage’ in a cancellation survey is slap a discount on it. But think about it. If someone isn't using the app, why would they care what it costs? The issue usually isn’t that the app is too expensive. It’s that they’re not getting enough value. Lowering the price doesn’t fix that.

I saw this play out with a previous client. The cohort that signed up with a 50% discount had a £50 lower lifetime value (LTV) and higher churn than the full-price sign-ups. Cheaper didn't fix usage, it made things worse.

A discount doesn’t repair any of those four points where a habit can break; it won’t create a trigger that brings someone back, or refresh a reward that stopped feeling valuable. So don’t try to win back usage churners with a price cut. Find where the habit is breaking, and fix that instead.

‘Not enough usage’ is actually just a broken habit

The reason this category gets so little attention is that the label itself is a catch-all. What does ‘not enough usage’ actually mean? And is it just a softer version of ‘it’s too expensive’?

Does it mean that your subscriber:

• Forgot about your app? (How dare they!)
• Used it for a bit and stopped? (But why?)
• Lost interest in your app? (Ouch.)

I quit my Peloton subscription last year. I never received a cancellation survey, but if I had, I would have selected ‘not enough usage’. And that was true; I wasn't using it enough anymore. But the real reason was that I'd fallen out of the habit because it had started to feel repetitive, and I wasn't seeing any difference in my workouts. ‘Not enough usage’ was the symptom — the actual cause was my habit coming apart.

That word, ‘habit’, is the whole thing. Almost every version of ‘not enough usage’ comes down to:

• A habit never formed
• A habit failed to deliver enough value
• A habit quietly fell apart

If you want to fix usage, you first need to understand how a habit actually holds together.

Nir Eyal's Hook Model is one of the clearest ways to think about habit loops:

1. A trigger (a notification, a time of day, a feeling, or a problem they want to solve) brings someone back to your app
2. They take an action (use the app)
3. They receive a reward that feels worth the effort
4. They invest something (a preference, a history, a streak, personal data) that makes the next cycle easier and increases the cost of leaving.

Repeat that loop enough times, and a habit forms. But remove the value from step three, and the loop collapses. You could argue that the reward is the most important part, and technically it is. But I think it goes deeper than that. You can create a short-term dopamine hit; a temporary reward, or a moment of engagement — but if the user doesn’t believe the app is delivering real value, the habit won’t survive. A habit isn’t built on activity alone. It’s built on the belief that coming back is worth it.

Usage churn is this loop breaking. And in my experience, it tends to break at one of four predictable points.

The trigger never fired

Out of sight, out of mind. This happens right at the start, or with low-frequency apps, where people quietly drift back to whatever they used before because it's easier. This is the “I forgot about it” category.

You download a new recipe app, but you still end up opening Instagram or reaching for a dog-eared cookbook (guilty!). The novelty that made you download it faded before the app earned a place in your day, and once it's off the home screen, it's gone.

How to fix a trigger that never fired

Try a well-timed re-engagement sequence (not spray-and-pray notifications). Look at when usage typically drops during the billing cycle for your product, then meet users there with something genuinely useful.

I’ve seen this work directly: for users who had hit our definition of inactive (hadn’t completed a workout in five days), we sent a small number of targeted emails that acknowledged where they were and prompted them to re-engage. It drove a 100%+ lift in people completing a workout within three days, versus the control group who received no emails.

Focus on relevance and timing, not volume.

The action never stuck

Some people get going and still don't stick. The hardest part of a new habit is usually the beginning, when the effort is real, and the results are not visible yet. A five-minute journaling practice or a morning stretch feels like more work than payoff in week one. People start with good intentions, but then they slip once or twice, and never come back. This often starts with onboarding that's too short to reach the moment where the app clicks.

The other half of sticking is finding a slot in the day for it, making it a part of your routine. My Spanish used to be decent. Then I left Spain after living there for a few months, stopped practicing, and it faded. During a trip to Ecuador, embarrassed by my Spanish and keen to pick it up again, I started using a language app: a lesson in the morning, another while waiting for the boat. But when I got home, I had no natural moment to keep it up, and I drifted. My older sister is the opposite. She practices French every night right before bed. Same time, same trigger, sticks to it religiously.

That is the difference between an action that sticks and one that doesn't: a trigger that fires on its own, not because of some push notification or email. Without one, daily becomes ad hoc, ad hoc becomes occasional, occasional becomes embarrassingly-bad Spanish. The user wasn't unmotivated. The action just never anchored to an emotional trigger.

How to fix it an action that doesn’t stick

Try these two levers, depending on whether the user never activated or never anchored:

First: get them to the core action faster. The longer someone waits after paying before they experience real value, the less likely they are to ever form a habit around the product.

Second, borrow an existing trigger rather than trying to build one from scratch. The “Try it right after your morning coffee" prompt, or the "Try it before you sleep" nudge: that anchor matters as much as the product itself. My sister's French habit holds because it's welded to her bedtime. Give users a way to weld by notifying them at the time they are most likely to take action.

The reward went flat

This is the one that most usage analyses miss, and the one I'd argue is entirely missing from most articles. Some users get all the way here. They built the routine, came back for a while, but then stop because the app ran out of reasons to pull them back.

Remember my Peloton example? I had the routine, and I'd felt the value, at first. But the workouts stopped surprising me: same format, same structure, nothing new to come back for. A reward that's identical every time stops being a reward; we need variation and excitement (especially this ADHDer).

This tends to be further down the user journey. Variability in rewards is key here; fresh content and visible progress are really powerful — these motivations are the app's responsibility, not the users’.

How to fix it

This is where variable rewards and investment earn their keep. The same reward every time gets boring. (Peloton again: same workouts, same format, no surprise, no fresh reason to come back.)

Vary your rewards, show progress, unlock rewards based on that progress; give people something new to come back for. Finch is a great example: offering a rotating daily shop, and seasonal rewards linked to repeated usage and habit-building.

Also focus on building investment early: the more someone puts into an app — preferences, history, a profile — the more they lose by leaving. It’s the same sunk-cost fallacy that keeps us in relationships longer.

AI tools like Granola or Wispr Flow are good examples. The more content I build up in them, the more useful they become, and the harder it would be to switch. Building that investment before the first renewal changes the value calculation.

The value never landed, or never fit

This one usually surfaces later. The user genuinely tried, but it just didn't feel like it was working. They used a language app for weeks and felt like the main word they learned was ‘apple’ (manzana, in my experience with Duolingo). Value can take longer than people expect, or the outcome the app delivers may be different from what they wanted.

The pattern looks like this: you journal for a month and feel no different, so you stop. You might not cancel immediately because part of you thinks, “maybe I’ll get back into it.” Then renewal comes around and suddenly the decision feels obvious: “I’m not using it enough. Might as well cancel.”

Technically, that’s true. But ‘not enough usage’ was the symptom. The root cause was a value gap.

There's a quieter, less obvious reason worth separating out, because the fix is completely different: the app works; it just doesn't fit their situation. A meal-planning app that assumes you cook most nights might be genuinely excellent. But for someone who eats out five times a week, it feels useless or unnecessary.

The value isn’t slow to arrive; rather, the product simply doesn’t match the reality of the person using it. When this happens, no reminder, notification, or re-engagement campaign can fix that (no matter how good they are). And sometimes that’s okay. Some churn isn’t a failure to prevent; it’s the right decision for the user.

How to fix it

Surface outcomes and progress, not just features. Most apps show what they do. Few show what the user has actually achieved. A monthly progress summary, a milestone email, a reminder of how far someone has come. Those moments are what shift someone from “I’m not sure this is working” to “actually, look at that.” Take Loom’s monthly recap emails — they literally show you the value in one image:

For users who've already dropped the app, your typical reactivation playbook applies, though reactivation rates are low by default, which is exactly why catching the value gap earlier matters so much. And if it's a life-fit problem rather than a delivery problem, be honest with yourself: no email can surface value that was never going to exist for that user. Qualifying the right people beats winning back the wrong ones.

Each break sits at a different point on the loop, and each needs a different fix. Not one of them responds to a discount. But before you reach for a fix, you need to know which break you're actually looking at and make sure you aren’t dealing with a price problem.

How to know which part of the habit loop is broken

You've established the churn is coming from usage, not price. Now you need to figure out which of the four breaks you’re dealing with. Luckily, each one leaves a different fingerprint on the usage curve.

Pull your churned cohorts and find the moment users actually went inactive (not when they canceled, but when they genuinely stopped coming back). Then look at the shape of the drop-off:

The usage curve will tell you where to look, but don’t stop there — to understand why the curve looks the way it does, you need to talk to churned users. The data can show you when the habit broke, but conversations tell you why.

Talk to churned users (and what to do if you can't)

The most direct way to find out why a habit broke is to talk to the people who left. It’s the equivalent of asking for directions when you’re lost.

Ask users two things:

1. What did they expect from the app?
2. What did they actually experience?

That gap is almost always where usage broke, and it usually tells you which break it was. Then ask what was going on in their life around the time they drifted, especially if you can see usage drop before they canceled.

I know churned users are harder to reach. I know they don't always reply. But trust me, it's worth it.

If you genuinely can't get to your churned users, shorten the feedback loop instead. Matthieu Rouif of PhotoRoom deliberately launched with a monthly-only plan so users would churn faster and become interviewable sooner. If you're early-stage and your usage understanding is low, that trade-off is worth considering.

Other proxies when you can't reach users directly:

• Support tickets
• App store reviews
• More in-depth post-cancellation surveys

They might not tell you the exact cause 100% of the time, but they can help you narrow down where to look.

Fix the right problem

‘Not enough usage’ can sound vague, but once you dig into the quantitative and qualitative data, it usually isn’t. At its core, it comes down to a habit loop that never fully formed, due to one of four breaks: the trigger, the action, the reward, or the value.

And none of those problems are solved by the classic winback discount. They require a better diagnosis and a better strategy.

Start by understanding what ‘enough usage’ actually looks like for your product, then run the quantitative checks I outlined. From there, work backward: where are users dropping off, and why?

Fixing this mega churn reason is a journey, but it’s worth taking the time to get it right. When an app delivers real value, users become far less sensitive to both price and usage. The value they get in the moment is enough to justify coming back, and enough to justify staying.

Usage churn is harder to fix than a pricing problem, but it’s also the lever almost nobody pulls. And that’s exactly why the opportunity is so wide open.

To help you out, I went through the categories again, and collected seven that you should consider targeting during the remaining two weeks. All of these reward work that would make your app stronger anyway: finding a route to market, testing growth, launching to a new market, or getting clearer about your audience.

Some can fit an app you already have in progress, and there’s still time to pivot or even build a new app.

Launch a web-to-app funnel for the Funnel Vision Award

If your app is nearly done, the next question is awkward but important: how will anyone find it?

The Funnel Vision Award gives you a reason to answer that now (that plus the $15,000). To enter, launch a live web-to-app funnel with RevenueCat Funnels and use Stripe for checkout. Best thing: you most likely don’t need to release a new version of your app at all.

Keep the first version laser-focused. Pick one audience, one promise, and one offer. Send people to the funnel from a post or small ad campaign, then watch where they continue, pay, or drop off. The judges will look at payment volume, funnel design, and conversion. So don’t build a generic landing page that could belong to any app, but instead make the journey feel like the first useful part of your product.

Personally, I’d spent the least amount of time on the visuals and more time making the all the steps serve a purpose. The app that understands why someone clicked has a much better shot at converting them. If web acquisition is new to you, the Web-to-App Funnels Handbook covers pretty much everything.

Take an idea all the way to income with Replit

The Idea to Income Award offers $15,000 for first place. And it’s exactly what the name suggests: start with an idea, use Replit to build it, publish it, and prove that somebody will pay for it. You’ll need to build the mobile app with Replit, integrate RevenueCat using Replit Agent, and share at least three public posts from different points in the build.

To make the best use of your time, build for iOS, with that you have the biggest chance to get your app approved in time. The scope can be small (and should be). A specialist calculator, a training companion for one sport, or a practical tool for one profession can become a real product faster than an app trying to serve everyone.

Give your Android app a Galaxy-specific advantage

Already building for Android? Publishing on the Galaxy Store opens another route into Shipaton — and another market for customers to find you. Galaxy store optimization accounts for 20% of the score, and the store listing itself needs to be polished. A thing you can work on without having to release a new version of your app.

Should you target Samsung products by focusing on their unique selling points, that is also possible. Look at the hardware your app will run on. For example a foldable can turn a recipe app into ingredients on one side and instructions on the other. A planning app can keep the calendar and task details visible together. Small updates you can make to your app to make it more suited for Samsung devices.

You don’t need to use every Samsung-specific feature. Pick the one that makes sense for your app and make it feel intentional.

The prize is three weeks of featured placement across the Galaxy Store’s Apps and Discover tabs. There’s no cash prize here, but for an app that’s ready to convert and retain users, the distribution could bring even more money.

Run one honest growth experiment with Layers

You don’t need a huge audience to enter the Growth Loop Award. You need a clear idea of who the app is for, a reason they might care, and an experiment you can learn from. That makes this a good category for a newly launched app, and the winner takes $15,000.

Install the Layers SDK, choose one growth loop , and write down what you expect to happen. Then run it long enough to see a signal. If this sounds foreign to you, Layers has good resources on how to do this, and while going through those you also learn how to market your app, something you should do even if you didn’t target this prize category.

The result you get doesn’t have to be a hockey stick. The judges want to see that you treated growth as a loop: form a hypothesis, run the test, and then decide what comes next.

Make today’s movement decision easier for Simone Sharice’s audience

The Simone Sharice Influencer Award (with $20,000 for first place) asks for a personalized wellness companion covering movement, Pilates, recovery, and other day-to-day wellness needs. This does not mean that you need to build an endless workout library and ask users to figure it out. Better to build something personalized; a plan they can actually start.

To give you an example, on a low-energy day, that may be 10 minutes of recovery work. On another, it may be a focused Pilates session. The value is in making the choice feel manageable. So personalization matters, but so does restraint. The brief specifically rewards apps that avoid overload and make the next action obvious.

A strong first version could do three things well: understand today’s context, recommend a suitable session, and learn enough from the result to improve tomorrow’s recommendation.There are multiple Shipaton submissions targeting health and fitness, if yours is one, check if you could submit it for this award.

Build a nutrition app that doesn’t turn lunch into homework

Most nutrition apps start with numbers. Abbey’s Kitchen brief starts somewhere more human: help people make meals more satisfying without calorie counting or macro tracking.

Your app could let someone photograph lunch and ask what would make it more filling or enjoyable. It could let customers turn leftovers into a workable meal, or suggest useful additions based on what’s already in the kitchen. Something that is missing completely from current calorie and meal tracking apps.

You can build the core around one simple question: “What can I add?” Answer it well, in the moment when someone is hungry and short on ideas, and you’ve built something that is perfect for Abbey’s Kitchen’s massive audience.

Let new managers rehearse the conversation they’re avoiding

New managers are expected to give feedback, hold boundaries, and say no. These are often things you don’t get to practise beforehand. That’s the opening behind the Leadership Heather Influencer Award, which also offers $20,000 for first place.

What you could build is for example a rehearsal room, giving the user a realistic situation, letting them respond by voice or text, and then offer feedback they can use on the next attempt.

Start with a handful of conversations people genuinely dread:

• Giving direct feedback to a strong performer whose behaviour is negatively affecting the team
• Saying no to an unrealistic request from a stakeholder
• Setting a boundary with a direct report

Build it so that users of the app can get personalized feedback. Did the manager state the issue clearly? Did they bury the message? Did they set a boundary? Did they leave room for the other person to respond? All of these are very easy to codify in such a way that LLM’s can answer and give personalized feedback.

A quick note on the Influencer Awards

These categories give you an audience and a problem to solve. They don’t give you permission to use someone else’s identity. Name the Influencer Award in your submission and explain how the app serves that audience. But don’t use the influencer’s name, image, likeness, voice, branding, or logos in the product or marketing without written consent.

You can enter each project in only one Influencer Award. The same project can also compete in other non-Influencer categories when it meets their requirements.

Make things easy for the judges

Each award has its own requirements: a live funnel URL, Stripe Project ID, Replit preview URL, public build posts, Galaxy Store listing, verified Layers installation, or an explanation of how you served the chosen audience. It’s crucial that you don’t make judges hunt for that information in your submission.

The rest of your submission matters too. You’ll need a live store listing, a demo video under two minutes, an app icon, the required screenshot, and a free trial or promo code that unlocks paid features for judging. Our Shipaton submission guide walks through each of these requirements so take a look at it before you submit.

Shipaton closes on September 30, 2026 at 11:45pm PDT. Store review can take days, so ship the smallest valuable version now and improve it while the review is ongoing. For guidance on submitting your app for review, see our Late submitter’s guide.

Read the full rules and enter Shipaton 2026.

In this article, you'll explore building a custom paywall against the Android Purchases SDK, every option on PurchaseParams.Builder, the five replacement modes that govern plan changes, purchase results in callback and coroutine form, and the customization surfaces on RevenueCat's own paywall UI: PaywallOptions, PaywallListener, PaywallActivityLauncher, and PaywallPurchaseLogic.

Two decisions, not one

Before any code, separate two things that get conflated. Who owns the UI and who completes the transaction are independent choices, and the SDK lets you mix them.

• Your own UI, RevenueCat completing the purchase: PurchaseParams and Purchases.purchase.
• RevenueCat's paywall UI, RevenueCat completing the purchase: PaywallOptions and PaywallListener.
• RevenueCat's paywall UI, your own code completing the purchase: PaywallOptions and PaywallPurchaseLogic.
• Your own UI, your own code completing the purchase: your own BillingClient calls, followed by syncPurchases.

Most people asking how to customize the purchase flow want one of the first two. They both let RevenueCat complete the transaction and differ only on who draws the screen. This article covers those, plus the third, where your own code completes the Google Play transaction. The fourth is a migration topic rather than a customization one and is out of scope here.

You choose who completes the transaction at configuration time:

val configuration = PurchasesConfiguration.Builder(context, apiKey)
    .purchasesAreCompletedBy(PurchasesAreCompletedBy.REVENUECAT)
    .build()

Purchases.configure(configuration)

PurchasesAreCompletedBy.REVENUECAT is the default and means the SDK acknowledges verified purchases for you. PurchasesAreCompletedBy.MY_APP means it does not, and that obligation has a deadline covered in the last section. The older observerMode(true) setter still exists but is deprecated in favor of this one.

Reading an offering into your own UI

A custom paywall starts by fetching offerings and rendering whatever the dashboard returned. The callback form takes a lambda pair:

Purchases.sharedInstance.getOfferingsWith(
    onError = { error -> _uiState.value = PaywallUiState.Error(error.message) },
    onSuccess = { offerings ->
        val current = offerings.current
        if (current == null) {
            _uiState.value = PaywallUiState.Error("No current offering")
        } else {
            _uiState.value = PaywallUiState.Success(current)
        }
    },
)

offerings.current is nullable, and an app that assumes otherwise crashes the first time someone forgets to mark an offering as current in the dashboard. From there, offering.availablePackages is the list you render. Each Package carries an identifier, a packageType, and the product itself.

There is one nullable accessor per standard package type, offering.monthly, offering.annual, offering.weekly, offering.lifetime, and so on for each PackageType. Lookup by identifier behaves differently and catches people out:

val monthly: Package? = offering.monthly
val custom: Package = offering.getPackage("my_custom_package")

getPackage returns a non-null Package and throws NoSuchElementException when the identifier is absent, as does the offering["my_custom_package"] operator form. Wrap it or use the nullable accessors.

For the price label, read through to the product:

val Package.buttonText: String
    get() = with(product) {
        if (type == ProductType.SUBS) {
            "${price.formatted} for ${period?.value} ${period?.unit?.name?.lowercase()}"
        } else {
            "${price.formatted} one time"
        }
    }

price.formatted is the localized string Google Play returned, already carrying the right currency symbol and grouping for the user's storefront. price.amountMicros and price.currencyCode are there when you need to compute something. period is returned only for Google subscriptions, so it is null for one time products and for Amazon.

Why there is no eligibility check on Android

On iOS there is an eligibility check you call before showing a trial badge. On Android there is not, and looking for one is a common dead end. getEligibleWinBackOffers and checkTrialOrIntroDiscountEligibility do not exist in the Android SDK. Google Play bakes eligibility into what it returns: an offer the user is not eligible for is not in subscriptionOptions at all.

So you read the offers you were given. Two container types are involved and the naming is close enough to confuse. SubscriptionOptions is the collection of offers on a product, and each SubscriptionOption is one offer made of pricing phases. Accessors on the collection pick an offer, accessors on an option pick a phase:

val options = packageToPurchase.product.subscriptionOptions
val trialOption = options?.freeTrial
val introOption = options?.introOffer
val defaultOption = packageToPurchase.product.defaultOption

SubscriptionOptions implements List<SubscriptionOption>, so you can iterate it directly. On an individual option, the phase accessors are freePhase, introPhase, and fullPricePhase. There is no freeTrialPeriod on a Google product. That property exists only on AmazonStoreProduct. A single option can carry both a free phase and an intro phase.

To show what a multi-phase offer costs over time, join the phases:

val pricingText = option.pricingPhases.joinToString(separator = " then ") { phase ->
    "${phase.price.formatted} for ${phase.billingPeriod.iso8601}"
}

You might reach for phase.offerPaymentMode to label each phase instead of formatting the price. It is worth knowing its shape before you do. The type is OfferPaymentMode?, one of FREE_TRIAL, SINGLE_PAYMENT, or DISCOUNTED_RECURRING_PAYMENT, and it is null for any phase that is not FINITE_RECURRING. That includes the full price phase of every recurring subscription and every phase of a prepaid plan. So branch on it with a when that treats null as the ongoing price rather than as an error.

Making the purchase with PurchaseParams.Builder

Every purchase goes through PurchaseParams. Its builder has exactly three public constructors, and which one you pick decides how much control you have over the offer:

1. PurchaseParams.Builder(activity, packageToPurchase) takes a Package.
2. PurchaseParams.Builder(activity, storeProduct) takes a StoreProduct.
3. PurchaseParams.Builder(activity, subscriptionOption) takes a specific SubscriptionOption.

The first two do not purchase the base plan. They purchase the product's defaultOption, and the builder KDoc spells out how that is chosen: offers tagged rc-ignore-offer or rc-customer-center are filtered out, then the option with the longest free trial or the cheapest first phase wins, then it falls back to the base plan. That is usually what you want, and it is why most apps never touch SubscriptionOption at all.

Pass a SubscriptionOption when you need to override that choice, for example when your paywall shows two offers side by side and the user picked the one that is not the default:

val params = PurchaseParams.Builder(activity, selectedOption).build()

The simplest possible purchase is the package form with nothing else set:

Purchases.sharedInstance.purchaseWith(
    PurchaseParams.Builder(activity, packageToPurchase).build(),
    onError = { error, userCancelled ->
        if (!userCancelled) showError(error)
    },
    onSuccess = { _, customerInfo ->
        unlockContent(customerInfo)
    },
)

Two things about that snippet need stating outright. First, the onSuccess transaction parameter is typed StoreTransaction?, nullable, unlike the non-null StoreTransaction you get from the PurchaseCallback interface. Writing onSuccess = { transaction, _ -> log(transaction.orderId) } does not compile. Discard it with _ or use transaction?.orderId.

Second, userCancelled is not extra information. It is derived, in PurchasesOrchestrator, from a single comparison:

onError(
    error,
    error.code == PurchasesErrorCode.PurchaseCancelledError,
)

So checking the boolean and checking the code are equivalent. Either way, a user tapping outside the Google Play sheet is not an error you should surface. Showing a toast that says "Purchase failed" because someone changed their mind is a common defect in hand rolled paywalls.

The callback interface

purchaseWith is a Kotlin extension. The interface form takes a PurchaseCallback, which declares onCompleted and inherits onError(error, userCancelled) from PurchaseErrorCallback, so you implement two methods:

Purchases.sharedInstance.purchase(
    purchaseParams = params,
    callback = object : PurchaseCallback {
        override fun onCompleted(storeTransaction: StoreTransaction, customerInfo: CustomerInfo) {
            unlockContent(customerInfo)
        }

        override fun onError(error: PurchasesError, userCancelled: Boolean) {
            if (!userCancelled) showError(error)
        }
    },
)

Here onCompleted hands you a non-null StoreTransaction, which is the reason to prefer this form when you need the purchase token. Note that purchaseToken is non-null but orderId is still String? even here, because it is absent for pending and test purchases.

Coroutines

The suspend variants come in two flavors per operation, one that throws and one that returns Result:

viewModelScope.launch {
    try {
        val result = Purchases.sharedInstance.awaitPurchase(params)
        unlockContent(result.customerInfo)
    } catch (e: PurchasesTransactionException) {
        if (!e.userCancelled) {
            showError(e.error)
        }
    }
}

awaitPurchase returns a PurchaseResult holding storeTransaction and customerInfo. That type gets its equals, hashCode, and toString from the Poko compiler plugin rather than from data class, which means there is no generated copy() and no destructuring. Read the two properties directly.

PurchasesTransactionException is where userCancelled lives on the coroutine path, and it exposes error, code, and underlyingErrorMessage. That last one matters for support, because PurchasesError.message is not a server message. It is a computed property returning code.description, the same canned English sentence for every occurrence of a given code. underlyingErrorMessage carries what actually went wrong, so log both.

Reading the result

Entitlements

The CustomerInfo handed to your success callback is already up to date, so gate on it directly rather than issuing another fetch. Watch which collection you read from. entitlements.all contains every entitlement the user has ever had, including expired ones, while entitlements.active contains only the live ones. Reading all and forgetting to check isActive grants access to a lapsed subscriber.

val isPro = customerInfo.entitlements["pro"]?.isActive == true
val hasAnything = customerInfo.entitlements.active.isNotEmpty()

The indexing operator reads through all, which is why the isActive check is not optional there. entitlements.active is a Map<String, EntitlementInfo>, not a list, so active.keys gives you the identifiers.

Individual EntitlementInfo properties worth surfacing in a settings screen:

• willRenew: false once the user has turned off auto renew. Always true for lifetime access.
• expirationDate: null for lifetime access. For a trial, this is the trial expiration.
• periodType: one of NORMAL, INTRO, TRIAL, PREPAID.
• unsubscribeDetectedAt: when the user cancelled, if they did.
• billingIssueDetectedAt: when a payment problem started, if there is one.

The KDoc on the last two carries the important part. An entitlement can still be active while both are set, so branch on isActive for access control and treat the dates as context for messaging.

To react to changes that happen outside your purchase call, set the listener once and clear it:

Purchases.sharedInstance.updatedCustomerInfoListener = UpdatedCustomerInfoListener { info ->
    _customerInfo.value = info
}

This fires when the SDK updates its cache after an app launch, a purchase, a restore, or a fetch. It is not a server push, so it is not a substitute for calling getCustomerInfo when your UI needs current state.

Restore

Restore is a single call with the same two shapes, and it is not optional. Both stores require a way for a user on a new device to recover access:

Purchases.sharedInstance.restorePurchasesWith(
    onError = { error -> showError(error) },
    onSuccess = { customerInfo -> refreshUi(customerInfo) },
)

One naming inconsistency to watch for when you implement the interfaces instead: ReceiveCustomerInfoCallback uses onReceived, while SyncPurchasesCallback uses onSuccess.

Switching plans: Product changes and replacement modes

Everything above buys a new subscription. Moving an existing subscriber from one plan to another is a different operation, and it needs two more builder calls:

val params = PurchaseParams.Builder(activity, annualPackage)
    .oldProductId(currentSubscriptionId)
    .replacementMode(StoreReplacementMode.CHARGE_PRORATED_PRICE)
    .build()

Product changes work in the Play Store and the Galaxy Store. The Amazon Appstore ignores them.

Getting oldProductId right

The value is the subscription id, not the id plus base plan. This trips people up because the place you naturally read it from returns the combined form:

val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()
val oldProductId = customerInfo.activeSubscriptions
    .map { it.split(":").first() }
    .firstOrNull()

activeSubscriptions returns subscriptionId:basePlanId for Google subscriptions. The builder is forgiving here, its KDoc says anything after a : is ignored, but splitting yourself makes the intent visible.

The five replacement modes

StoreReplacementMode replaced GoogleReplacementMode in SDK 10.3.0. The old enum and the old .googleReplacementMode() setter both still exist and are both deprecated, so new code should use StoreReplacementMode and .replacementMode().

• WITHOUT_PRORATION: takes effect immediately. The user pays nothing today, then the full new price on the old plan's expiration date.
• WITH_TIME_PRORATION: takes effect immediately. The user pays nothing today, and the time remaining on the old plan becomes free time on the new one.
• CHARGE_PRORATED_PRICE: takes effect immediately. The user pays the price difference today and the billing date does not move.
• CHARGE_FULL_PRICE: takes effect immediately. The user pays the full new price today and the remaining time from the old plan is credited forward.
• DEFERRED: takes effect when the old plan expires. The user pays nothing today, then the new price on the old expiration date.

One structural note if you plan to branch on the mode you were given. StoreReplacementMode is not an enum, it is a class exposing five constants, so a when over it will not compile as exhaustive. Include an else branch.

The default is WITHOUT_PRORATION. It is set in the builder's internal state, not left null, so a product change with no replacementMode call is a real decision that was made for you. For a paid upgrade that is rarely the one you want, because the user gets the better plan immediately and pays nothing until their old period ends.

If you want to have a better undertsanding on the proration mode, check out Understanding Google Play subscription proration: a developer’s guide.

Choosing a mode

• Upgrade, charge now: CHARGE_PRORATED_PRICE. The user pays the difference and the renewal date does not move. This mode is only valid when the new plan's price per time unit is higher than the old one's, which Google Play checks and rejects otherwise, so it is an upgrade only mode rather than a general purpose one.
• Upgrade, generous: WITH_TIME_PRORATION. The user pays nothing today and their unused time becomes free days on the higher tier.
• Downgrade: DEFERRED. The user keeps what they paid for until it runs out, then drops to the cheaper plan. Charging someone immediately to receive less is a support ticket.
• Crossgrade at the same price: WITH_TIME_PRORATION or DEFERRED, depending on whether the switch should be felt now.

Two constraints come straight from the KDoc and are worth encoding as guards. WITH_TIME_PRORATION fails on the Play Store when both options belong to one StoreProduct, so use a different mode for base plan changes within a single product. CHARGE_FULL_PRICE is not supported by the Galaxy Store, and passing it there surfaces a PurchasesErrorCode.UnsupportedError in your error callback rather than starting a purchase.

DEFERRED reports back differently

The deferred mode is the one that makes purchase handling code look broken. Nothing changes today, so the CustomerInfo your success callback receives still describes the old plan. Code that reads the new product id out of the callback and writes it somewhere will write the old one.

Under DEFERRED the product id is also what matches the purchase callback to the transaction Google Play returns, which is another reason to pass the plain subscription id. Treat a deferred change as scheduled rather than done, and let the entitlement's expirationDate and your webhook pipeline tell you when it happened.

Other PurchaseParams options

isPersonalizedPrice

val params = PurchaseParams.Builder(activity, packageToPurchase)
    .isPersonalizedPrice(true)
    .build()

This is a compliance flag, not a pricing feature. It tells Google Play to disclose in the purchase sheet that the price shown was personalized for this user, which EU consumer law requires when that is true. The default is false, and the Amazon Appstore ignores it. Set it only when you are actually personalizing the price.

Add-ons

For Play Store subscriptions with add-ons, the builder takes extra items:

@OptIn(ExperimentalPreviewRevenueCatPurchasesAPI::class)
val params = PurchaseParams.Builder(activity, basePackage)
    .addOnPackages(listOf(addOnPackage))
    .build()

There are matching addOnStoreProducts and addOnSubscriptionOptions overloads. All three sit behind @ExperimentalPreviewRevenueCatPurchasesAPI, and the restrictions from the KDoc are strict: Play Store subscriptions only, every add-on's renewal period must match the base product's period, and at most 49 add-ons per purchase.

Keeping RevenueCat's paywall UI

Now the case where RevenueCat draws the paywall. If the paywall you designed in the dashboard is what you want to render but you need your own code in the flow, you do not have to give up the UI.

The composable takes a single options object, and dismissRequest is a constructor parameter of the builder rather than a setter:

Paywall(
    PaywallOptions.Builder(dismissRequest = { navController.popBackStack() })
        .setOffering(offering)
        .setListener(paywallListener)
        .setShouldDisplayDismissButton(true)
        .build(),
)

setOffering(null) falls back to the current offering. setShouldDisplayDismissButton defaults to false here, while PaywallDialogOptions and the activity launch options default it to true, so an embedded paywall with no close button is the expected behavior rather than a bug.

PaywallListener: Observing the flow

PaywallListener is an interface where every method has a default implementation, so you override only what you need:

private val paywallListener = object : PaywallListener {
    override fun onPurchaseCompleted(customerInfo: CustomerInfo, storeTransaction: StoreTransaction) {
        analytics.track("purchase_completed", storeTransaction.productIds)
        unlockContent(customerInfo)
    }

    override fun onPurchaseError(error: PurchasesError) {
        analytics.track("purchase_error", error.code.name)
    }

    override fun onPurchaseCancelled() {
        analytics.track("purchase_cancelled")
    }

    override fun onRestoreCompleted(customerInfo: CustomerInfo) {
        refreshUi(customerInfo)
    }
}

The full set is onPurchaseStarted, onPurchaseCompleted, onPurchaseError, onPurchaseCancelled, onRestoreStarted, onRestoreCompleted, onRestoreError, plus onUrlOpened for links inside the paywall and onWebCheckoutOpened for the case where the user left to pay on the web. That last one is distinct from cancellation and needs handling separately, because the user has not given up, they have gone elsewhere to finish. If you also plan to supply purchase logic, read the last section first: four of these callbacks go quiet in that mode.

Gating the flow before it starts

The two hooks people want when they ask about customizing the purchase flow are not in the list above. They are the initiated callbacks, and they hold the flow open until you answer.

Each one receives a Resumable, a fun interface with resume(shouldResume: Boolean) and an invoke operator defaulting to true. So resume() proceeds and resume(false) aborts. If you never call it, the purchase never starts. Watch the import: the one PaywallListener wants is com.revenuecat.purchases.ui.revenuecatui.utils.Resumable. There is an identical com.revenuecat.purchases.customercenter.Resumable for Customer Center, and picking it gives you a confusing message about overriding nothing.

Both hooks are members of the same listener shown above:

override fun onPurchasePackageInitiated(rcPackage: Package, resume: Resumable) {
    if (userIsSignedIn()) {
        resume()
    } else {
        showSignInSheet(
            onSuccess = { resume() },
            onDismiss = { resume(false) },
        )
    }
}

onRestoreInitiated(resume) gives you the same gate for restore. This is the place to require sign in, ask for a confirmation, or check an age gate, because it runs before Google Play's sheet appears rather than after the user has paid.

Getting a result from a full screen paywall

For a paywall presented as its own activity, results come back through PaywallResultHandler. Construct the launcher in onCreate. There is no remember based helper:

class MainActivity : ComponentActivity(), PaywallResultHandler {

    private lateinit var launcher: PaywallActivityLauncher

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        launcher = PaywallActivityLauncher(this, this)
    }

    override fun onActivityResult(result: PaywallResult) {
        when (result) {
            is PaywallResult.Purchased -> unlockContent(result.customerInfo)
            is PaywallResult.Restored -> refreshUi(result.customerInfo)
            is PaywallResult.Error -> showError(result.error)
            PaywallResult.Cancelled -> Unit
        }
    }
}

PaywallResult is a sealed class, so that when is exhaustive and a new case would break the build rather than fall through silently. A user cancellation arrives as Cancelled rather than as an Error carrying PurchaseCancelledError, because the activity maps that code before returning.

To launch it with a listener or custom purchase logic attached, use the options form:

@OptIn(ExperimentalPreviewRevenueCatUIPurchasesAPI::class)
fun showPaywall(offering: Offering?) {
    launcher.launchWithOptions(
        PaywallActivityLaunchOptions.Builder()
            .setOffering(offering)
            .setListener(paywallListener)
            .build(),
    )
}

The opt in is required only because of setListener and setPurchaseLogic on this particular builder. Paywall(), PaywallOptions, PaywallListener, and PaywallPurchaseLogic themselves need none. There is also launchIfNeededWithOptions, which takes a required entitlement identifier or a shouldDisplayBlock and skips presentation when the user already has access.

One caveat shows up only in the field. The SDK passes the listener and purchase logic to the activity through an in memory store rather than through the intent, because neither is serializable. If the process dies while the paywall is open, the SDK logs that they were lost, finishes the activity, and returns PaywallResult.Cancelled. Do not treat that result as a signal that the user declined. This applies only when you attached one of them. A paywall launched without either carries no in memory key and recreates normally.

Custom variables

A dashboard paywall can contain {{ custom.player_name }} placeholders, and you supply the values:

PaywallOptions.Builder(dismissRequest = { dismiss() })
    .setCustomVariables(
        mapOf(
            "player_name" to CustomVariableValue.String("John"),
            "level" to CustomVariableValue.Number(42),
            "is_premium" to CustomVariableValue.Boolean(true),
        ),
    )
    .build()

Both {{ custom.key }} and {{ $custom.key }} resolve. Resolution order is the value you passed, then the dashboard default, then an empty string with a warning logged. Keys must start with a letter and contain only letters, digits, and underscores, and the SDK drops invalid keys with a warning rather than surfacing an error, so check logcat if a placeholder renders empty. One exception: PaywallDialogOptions.Builder.setCustomVariables skips the validator, so a bad key there is never logged and simply resolves to empty.

Owning the transaction with PaywallPurchaseLogic

This is the case where your own code completes the Google Play transaction and RevenueCat supplies only the paywall and the backend. You configure PurchasesAreCompletedBy.MY_APP and hand the paywall your purchase code.

The interface has two suspend methods. The purchase side receives the activity and a params object:

class MyPurchaseLogic(
    private val billing: MyBillingClient,
) : PaywallPurchaseLogic {

    override suspend fun performPurchase(
        activity: Activity,
        params: PaywallPurchaseLogicParams,
    ): PurchaseLogicResult {
        return when (val outcome = billing.purchase(activity, params.rcPackage)) {
            is Outcome.Success -> PurchaseLogicResult.Success
            is Outcome.Cancelled -> PurchaseLogicResult.Cancellation
            is Outcome.Failed -> PurchaseLogicResult.Error(outcome.error)
        }
    }

Restore in this mode means telling RevenueCat what Google Play already knows, which syncPurchases does, so the implementation is usually thin:

    override suspend fun performRestore(customerInfo: CustomerInfo): PurchaseLogicResult {
        return try {
            Purchases.sharedInstance.awaitSyncPurchases()
            PurchaseLogicResult.Success
        } catch (e: PurchasesException) {
            PurchaseLogicResult.Error(e.error)
        }
    }
}

If your billing code is callback based, extend PaywallPurchaseLogicWithCallback and implement performPurchaseWithCompletion and performRestoreWithCompletion instead. The base class bridges them for you.

The result type has three cases and the exact names are easy to miss. It is PurchaseLogicResult.Cancellation, not Cancelled, and the error case carries a nullable errorDetails:

• Success triggers syncPurchases. From performPurchase it also dismisses the paywall. From performRestore it dismisses only if a shouldDisplayBlock was set and no longer matches.
• Cancellation tracks a cancel event and leaves the paywall open on the purchase path. On the restore path it is silently ignored.
• Error(errorDetails) shows an error dialog only if you provide the error. PurchaseLogicResult.Error() with no argument does nothing at all: no dialog, no tracking. Always pass the error.

params is a PaywallPurchaseLogicParams, which is what makes this interface usable for plan changes. It carries rcPackage, subscriptionOption, oldProductId, and replacementMode, so a product change configured on the dashboard paywall reaches your code with enough information to reproduce it. One type detail will bite you on the next line: replacementMode is typed ReplacementMode?, the interface that both StoreReplacementMode and the deprecated GoogleReplacementMode implement. There is no public converter, so narrow it yourself with params.replacementMode as? StoreReplacementMode before passing it to a PurchaseParams.Builder.

The older PurchaseLogic and PurchaseLogicWithCallback types are deprecated in favor of these, because their performPurchase took only a Package and had nowhere to put the product change details.

Three behaviors of this mode need internalizing before you ship it:

1. The SDK no longer acknowledges purchases, so your code must. The KDoc on PurchasesAreCompletedBy.MY_APP states the consequence: failing to acknowledge within 3 days leads Google Play to automatically refund the user.
2. MY_APP with a null purchase logic does not fall back to normal behavior. validateState puts the paywall into an error state that renders instead of your paywall.
3. Four listener callbacks stop firing. onPurchaseStarted, onPurchaseCompleted, onRestoreStarted, and onRestoreCompleted live only on the REVENUECAT branch. The initiated hooks still run because they execute before the branch, and onPurchaseError, onPurchaseCancelled, and onRestoreError can still fire because they come from a catch that wraps both branches. Anything you were doing in onPurchaseCompleted has to move into your performPurchase success path.

Choosing an approach

• Full design control, standard purchase handling: PurchaseParams with purchaseWith or awaitPurchase.
• Dashboard paywall embedded in your layout: Paywall with PaywallListener.
• Dashboard paywall as its own screen, returning a result: PaywallActivityLauncher with PaywallResult.
• Dashboard paywall, your own billing code: PurchasesAreCompletedBy.MY_APP with PaywallPurchaseLogic.

The naming differences between these surfaces are not consistent, and the compiler will not always help. PaywallOptions.Builder has setPurchaseLogic, while PaywallDialogOptions.Builder calls the same thing setCustomPurchaseLogic. PaywallResult uses Cancelled while PurchaseLogicResult uses Cancellation. When something does not resolve, check which options class you are holding.

Conclusion

The habit worth taking from all of this is to treat the silent defaults as decisions you are making. WITHOUT_PRORATION is what a product change does when you say nothing about proration, and it is the mode that charges an upgrading user nothing today. defaultOption is what gets purchased when you pass a Package, chosen by a documented rule you can predict. Both are reasonable, and both are wrong for some paywalls, so pick them on purpose and write the reason next to the builder call.

The other shift is to stop reading a declined purchase as a failed one. The SDK separates a failure from a decision at every layer, from the boolean on the error callback to the result types the paywall returns to the hooks that let you abort before Google Play ever appears. Your error handling should draw the same line, because the user who backed out of the sheet is still a prospect and does not need to be told that something went wrong.

Watch on YouTube

Both looked like wins. "Both of those look so promising on the trial numbers," says Anada Lakra, BoldVoice's co-founder and CEO. "And it makes sense, right? People have already put in all the time in the onboarding flow. They actually want to see what this app is all about." The team's instinct was to ship both to everyone.

Then the refunds arrived. "The refund spiked by way more than the gain in start trials," Anada says. People who feel forced into a trial ask for their money back the moment the charge hits their bank account — and they leave with a grudge. "Anything that kind of forces or tricks people into starting a trial, you'll pay it when it comes to refunds."

The fix was a different scoreboard. BoldVoice now judges paywall tests on net revenue after refunds, per exposed user, on a matured cohort — which means waiting at least an extra week for trials to convert and two more for refunds to settle before declaring anything. It's slower, and Anada admits the hardest part isn't discipline but patience: sitting on exciting data for a month or more. Asked at the end of the episode for her worst change of the past year, she doesn't hesitate: "The paywall stuff. Just stop over-optimizing every single word and every button and everything. Optimize them for a little bit and then move on to the actual product."

Every employee does two user interviews a week — including the engineers

BoldVoice's user research isn't a function. It's a calendar rule.

Automated invites go out to a deliberate mix of users — subscribers of two or three years, people who started a trial last week and converted, people who didn't — asking for a 15-minute call. The invite automatically books whichever team members have space in their calendars. "Every single person on the team — myself, my co-founder, our engineers, our growth people — everyone is in at least two user interviews a week," Anada says.

Two more layers sit on top. A super-user group meets roughly weekly, and engineers demo unshipped features to them, so heavy users shape the product before release. Users also come into the office so the team can watch what they tap and where they linger. "Being able to actually verbally talk to users and actually see them interact with the product, I think is an underrated skill."

Anada is candid about the bias in this setup. Happy users book the calls. "People who did not have a good experience are going to be less likely to jump on those calls." For them, BoldVoice uses a three-question survey answerable by replying to an email, and a short flow at cancellation asking what went wrong. Without that correction, she says, you end up making happy people happier and building a product that gets narrower and more technical instead of wider.

Why BoldVoice charged from day one — and won't copy Duolingo

BoldVoice launched in the first weeks of Y Combinator's summer 2021 batch and charged from the start: $10 a month, one-week free trial, no experimentation. That was the point. "Charging for the product is a way to already figure out who that ICP is," Anada says. Willingness to pay correlates with the problem resonating, and it kept the team from chasing feedback from people who would never be customers. The energy went into onboarding and the core product instead of the paywall.

Pricing has since matured — BoldVoice leads with an annual plan at around $150 a year, offers monthly as a fallback, and has a $200-a-year tier with extra features like chat — but the philosophy hasn't moved toward freemium, and Anada is precise about why. "The worst thing that someone can do is take some playbooks and some elements of a playbook from one app, combine it with a playbook of a different app, and create this mishmash strategy."

Duolingo's freemium base works because it teaches the basics of every language to a huge audience of hobby learners, and monetizing a fraction is enough. BoldVoice intentionally ignores that audience. Its users are intermediate-to-advanced professionals for whom the alternative is expensive one-on-one coaching with an accent coach: "totally different ICP, different value proposition, different willingness to pay." The same logic ruled out the cliché college-campus launch, which BoldVoice tried. Students had less money, less urgency, and hadn't yet sat in the meeting where a colleague got listened to instead of them.

What BoldVoice has instead is a narrow free taste: dismiss the paywall and you get the speech assessment, the first daily plan, and a coach video, then a seven-day trial to continue on day two. David Barnard calls it a reverse trial. Anada calls it a middle ground that doesn't cost you the onboarding paywall for the people who are already ready to pay.

One Threads post, 100,000 people in Korea

BoldVoice's in-house ML team, working with the Hollywood accent coaches who help label its training data, built a tool that guesses where you're from after about ten seconds of speech. They shipped it as an ungated web app — no download, no trial — called the Accent Oracle, and Anada mentioned it in her monthly investor update.

"One of them was an angel investor. It was Korean, and he was like, 'Oh, this is cool. I'll put it on Threads,'" she says. "And then I believe the next day we had 100,000 people in Korea try this thing."

The lesson she draws isn't "build a viral tool." It's that you can't engineer virality, but you can add levers to something that already has it: a city-level guess re-spiked the Oracle, and showing users a preview of the fuller results waiting in the app lifted the number who made the jump. A TikTok trend of users crying at low scores gave the brand another unpaid spike — hundreds of millions of views for one creator, by her estimate — with the caveat that humor brings reach, not intent.

$10M ARR, 10 people, one meeting a week

Anada’s explanation for roughly $1M of ARR per employee is unglamorous. Hire founder-type doers who don't need direction. Hold one company-wide meeting, on Mondays, and leave the rest of the week for building and talking to users. Default users to the annual plan so paid acquisition pays back within the trial window and every channel's return is legible the same week.

And let everyone ship. "Everyone in the company is using Claude. For the first time in my life, I'm actually shipping PRs myself, which is crazy. I'm not a technical person." The designer takes Figma work through to prototypes that are about 80% of the way to production before engineers touch them.

The part that keeps the small team defensible is the part that took longest to build. "Still to this day, you cannot talk to ChatGPT or Claude or whatever have you and get this kind of feedback that BoldVoice gives you," Anada says — a deliberate bet that non-native English pronunciation is too narrow a niche for general models to chase and far too large a market to ignore.

In the full episode, Anada also explains why BoldVoice is expanding from accent into the "penultimate mile" of spoken fluency, why she considers "accent" an almost anti-viral word, and what a self-imposed six-month term-sheet deadline did for her focus.

Guest links

• Anada Lakra on LinkedIn
• BoldVoice on LinkedIn
• BoldVoice

But I also don’t believe apps will disappear altogether. Ethan Garr, a growth advisor, shared on a Sub Club Live about building with AI that a friend had said apps would be gone within six months. Not what you want to hear when you work in the app space. Yet here we are more than six months later: apps are still around, and more are being launched than ever before (7x more since 2022, to be specific). So I don’t believe they’ll disappear. Yes, LLM chats are replacing certain apps. Yes, the space is changing faster than ever. But the data suggests there is still hope, and I’m willing to cling to that data.

Especially as I’ve found you can win the game if you focus on the areas where an LLM chat cannot beat your app.

"...since March we’ve seen a significant spike in student interest in ChatGPT. We now believe it’s having an impact on our new customer growth rate."

When CEO Dan Rosensweig of Chegg, a homework-help subscription service, said this during an earnings call in 2023, the impact hit hard:

• The company’s stock fell 50%
• By 2025, 45% of their workforce were made redundant
• By Q2 2026, the freefall continued and they attempted to pivot away from homework toward an employability platform

Every step of the way, the blame was the same: AI.

Now take Duolingo: ChatGPT, and most LLMs for that matter, can also tutor you, for free. Google has layered live translation into its products — only a few months ago, I did a full strategy session with a subscription app startup in Portuguese (even though I don’t speak a word of Portuguese). The experience was honestly mind-blowing. I’m curious what I’m like in Portuguese.

Yet Duolingo isn’t floundering:

• Q2 2026 revenue was up 18%
• DAU rose 23% to 58.7 million
• Paid subscribers increased 17% to 12.7 million

By contrast, Duolingo’s CEO Luis von Ahn seems largely unimpressed by AI competitors:

“Just having conversations in French on something like ChatGPT gets pretty boring after a while. It doesn’t keep you there. We keep you on task with all the gamification.”

So what explains the difference between the two? Why is one being, frankly, obliterated by AI, while the other’s owl is gleefully celebrating its success?

It’s about the app itself: while both companies create educational content, Chegg’s product is essentially a one-shot answer: a lookup experience without enough built around it in terms of data, habit, and workflow. Duolingo, meanwhile, has spent 14 years building gamification systems and habit-forming product design that are much harder to replicate.

People will pay for AI apps, they just won’t stay

One thing worth separating before we dive into the numbers is what we mean by an ‘AI app’, because we often talk about these all under AI:

• An LLM chat is ChatGPT, Claude, Gemini
• An AI app is a subscription app with AI as a central feature inside it, like Cal AI or Rosebud (and quite possibly yours)

The first is the free competitor keeping you up at night. The second might be your own app. The data below is about the second.

AI-powered apps are casually out-monetizing and outperforming non-AI apps, according to RevenueCat’s State of Subscription Apps 2026:

• 41% more revenue per payer
• 52% better trial conversion

But there is a flip side to this:

• 12 month retention of 21.1% vs. 30.7%
• Refunds are about 20% higher

So consumers are willing to pay for AI apps, but the harder challenge is getting them to keep paying.

FaceApp used AI to apply an age filter, allowing you to see an aged version of yourself (why anyone would want that is beyond me). It peaked with downloads growing by 2000%, only to see a 75% drop the next month because of privacy concerns and the novelty wearing off. From 2019 to 2020, growth stagnated, with ARR remaining around $25 million (not a bad number to be stuck at, but a change in growth pace for sure). FaceApp survived the challenges, but had to optimize the app to focus on a broader use case, from photorealistic beauty (e.g. applying makeup) to selfie retouching. Broadening their use case helped them better retain users — and in 2025 they hit $150 ARR.

So the question in this article’s title is secretly the wrong one: people will pay. They’re already paying more — and faster — for AI-powered apps than for almost anything else right now.

The real question is why will they still be paying in month six? That’s a product question, not a marketing one, and it’s the question the rest of this article sets out to answer. (It’s also a much nicer question to wake up to at 2 am.)

AI alone isn't enough to win customers permanently, and Sora proves it: when the company that builds the model can't keep people, the model was never what kept them. Which is also why I don't think the other AI apps or copycat AI apps in your category are your biggest competitors.

ChatGPT is the biggest ‘window’ ever built

A while ago, I was standing in the kitchen, checking several weather apps on my phone, trying to decide whether to walk the dog now. I turned around to find my father-in-law looking at me like I’d lost it: "Why are you doing that? Just look out the window."

Weather apps’ competitors aren’t other apps; they are looking out the window, asking around, or even just going to stand outside.

In the world of apps, your window is ChatGPT, Claude, or whatever other LLM chat of your choice. The free models, for now, can do a lot, and we see growing usage in categories of apps that support them, e.g, one in five US chatbot users ask for medical advice, and as many again about diet and fitness.

The second, more meta way it is your window competitor is the ability to help you and others build faster. App launches went from about 2,000 to 14,700+ per month in four years; the volume is huge.

But in that, we still see 69% of subscription revenue going to pre-2020 apps, versus just 3% to apps launched in 2025 and 2026. Eric Seufert argues that while the cost of building is lower, the cost of distribution has increased because apps are all chasing the same attention. Rik Haandrikman echoes this: distribution is a moat.

Those who are holding on to that 69% know what a weather app can do that a window can’t, what their app can do that an LLM can’t. Those who can’t explain the differentiator of their app are the ones slowly dying under the weight of AI's growth.

Anatomy of the apps AI has actually killed

This is not a random murder spree; AI’s victims share something in common (I clearly need to stop reading Swedish noir novels). The apps replaced by LLM chats have one or more of these four things in common:

1. No structure
2. No memory
3. No habit
4. No precision advantage

Most apps being replaced are a single question or task and an answer. That was Chegg’s real problem: strip away the branding, and the product was a prompt with a subscription attached. Stack Overflow, a question-and-answer platform for developers, is on the same path, with traffic falling around 6% every month since early 2022. Why? An LLM gives you the same answer instantly, in a conversation, without posting a question and hoping a stranger replies.

Dan Layfield, Founder of Subscription Index, made a point on Sub Club that explains the pattern: your retention is dictated by how long the user has the problem you solve. Phone plans are retained for decades because the problem never goes away. An answer-lookup problem dies the second the answer arrives — and now the answer arrives in three seconds, for free. Chegg's real problem was never ChatGPT; it was that the problem they solved only lasted one homework question at a time.

The uncomfortable truth: if your app’s value fits in one prompt and one reply, you are in the blast radius.

The Blank Box Test (and six things a blank box cannot do)

I have a challenge for you called the Blank Box Test. It’ll only take two minutes:

1. Open your LLM chat of choice
2. Write out your user’s problem in their words
3. Analyze the results vs. what your app offers

Hopefully, you’ll see one of six advantages appear that you can lean into further. If not, your app is replaceable. So consider each of these six areas and see which could help you effectively beat an LLM. With all of these, yes, there are ways an LLM could do these things, but a general chat doing all six — or even one of them — to a very high level for everyone’s daily needs? Unlikely.

And to be clear, this isn't AI apps vs. non-AI apps. Cal AI, Rosebud, and Tolan are all examples that lean heavily on AI. The difference is that AI isn't what they're selling you — rather, it’s part of their infrastructure that helps them lean into one of the six differentiators against LLMs. That’s why I’ve also intentionally shared several non-AI examples.

1. Structure

I use Deliciously Ella and Mob Kitchen for recipe inspiration. Until I had what I thought was a genius idea: why not use Claude to build a weekly meal plan based on what I already have in the fridge, my dietary requirements, the foods I love, and the kinds of food that work well for me as someone with ADHD and an intense sweet tooth? A perfect, personalized plan.

So I did exactly that. I used it for a few weeks, but eventually went back to my usual apps because I missed the beautiful visuals of seeing what I was going to cook. I missed feeling inspired and getting excited about new recipes. The checklists and text in Claude just weren’t doing that.

While I probably could have forced Claude to create images and build everything into a visual weekly dashboard, the structure of the apps is what gives them their value. I can browse them on the go, discover recipes as they catch my eye, and build my shopping list along the way. It’s not worth it to me to rebuild that, and I’d argue that for most average consumers it wouldn’t be.

I also think that’s why apps like Runna are still winning against LLMs. For some people, a quick plan generated by an LLM will be enough for their daily run. But Runna gives you the full calendar, guidance during your run, and the exact structure of every workout you can follow live. It turns a plan into an experience, and that’s where the added value lies.

2. Memory

Luckily, the days when our LLM chats acted like Dory from Finding Nemo are gone. Building structures like second brains (a persistent, semantically searchable digital knowledge with AI) can allow your LLM to have so much more memory than ever before. But you still have to get it to use that data in some cases to make your experience better, and not all data sources are easy for the average AI user to connect to an LLM.

Meanwhile, your app can use the accumulation of user data so that by month six it is so much better than it was in month one, in ways you may not have even thought of. Memory + judgment of the right prompts are powerful.

This is the investment part of the Nir Eyal Habit Loop: getting users to invest in your app. If you do so, ensure that the investment pays back, and you’ll be able to add value to their experience, like Rosebud, an AI journaling app that collects your data over time and uses it to better reflect and learn with you.

3. Habit

Habit comes down to accountability: being able to push someone to take action, whether that’s through streaks, reminders, or other forms of gamification.

Duolingo is a perfect example. You can ask an LLM to help you build a habit out of something, and it can tell you the theory behind habituation. Having it embedded in your app in a beautiful, intuitive way, with all those reminders and nudges already built out — it’s technically possible with AI, but not something the average user is willing to do themselves.

The numbers behind those nudges are not small either. When Duolingo introduced leaderboards, Jorge Mazal, their former CPO, shared that overall learning time went up 17% and the number of highly engaged learners tripled.

Once a streak passes 10 days, the odds of someone quitting drop sharply. An LLM can explain habit theory to you beautifully — but it won’t cause a terrifying owl to chase you at 9pm because your streak is about to die.

4. Precision

Cal AI launched in the middle of the rise of LLM chats in May 2024. Within a year, its teenage founders were claiming around $2 million in monthly revenue, and by the time MyFitnessPal acquired it, it had passed 15 million downloads. The acquisition also gave them MyFitnessPal's food database of 20 million foods and 68,500 brands, allowing them to redesign and improve the product.

You could argue that their product is just a simple question-and-answer tool, but the precision with which they can tell you what is in your food, thanks to all that data and insight, is much better than asking ChatGPT. Especially if you combine it with their structure for organizing and tracking your calories and intake. Gives us hope, right? If two teenagers can beat LLM chatbots, so can we.

Merlin, a bird-sound app, is another great example of this. They have a curated acoustic library built from decades of eBird and Macaulay Library data and have 10 million active users. That dataset and the precision to recognize bird sounds effectively are their strengths.

5. Connection

Trust, tone, and brand feel go a long way in building a connection. Look at Tolan, the AI companion. It builds a personality that stands out and gives a feeling of connection. Its founder argues that doing this well, with voice, memory, and character, is exactly what LLM Chats are not set up to focus on.

But connection goes further than an app that knows you. It’s about belonging: Duolingo’s leagues, Strava’s clubs, the run crew that only exists because the app brought them together. People don’t cancel things that feel like a part of them. Emotional connection is a strong driver of retention. I also find it telling that AI companion apps are on track to pull in $120 million even though chatting with an AI is free: people pay for a relationship, not a reply.

In a world flooded with vibe-coded apps, those that take the time to build connection and an experience stand out.

6. Digital and physical

I also believe there’s room for another advantage in subscription apps that combine physical and digital to deliver value. I use a subscription app called Willow to better understand what my plants need and know when to water them, when to move them to a sunnier or less sunny spot, and more.

They can do this better than an LLM chat by itself because they have sensors to feel and gather this data. While we can connect LLMs to other data sources, I believe there’s room for the physical advantage of naturally creating combined experiences with reality to add extra value.

The power of multiple moats

The combination of a few of these has allowed even ‘wrapper’ apps to survive and thrive. Take Co-Star, an astrology app: readings are written by a mix of AI and human writers, and Midjourney thought its packaging and ritual were worth acquiring in 2026. Yet users pay anyway: for the packaging, the birth-chart personalization, and the daily push ritual. That is a combination of structure and habit helping them win.

What this means for what you build, say, and charge

Firstly, you need to understand which of these six differentiators are available to your category and deliberately invest in them, figuring out what can truly make you different from an LLM chat or a quickly-created AI competitor. It will help you speak to your most loyal users and understand: if they are using LLMs, why are they still choosing you? If 95% of your audience still sees that value and understands it, and it’s not just down to brand loyalty, that helps you work out which of these matters most.

With distribution being the challenge now, your existing audience is a moat in itself. Investing in retaining users through the initial experience and onboarding, by building in guidance and value, is going to help you win.

From there, communication comes down to marketing and sharing outcomes that a blank box can’t promise. You want to sell the job you helped them achieve, not the engine. I’m not the only one who cringes at the label ‘AI-powered’ — Irrational Labs conducted a study of 767 software users in which AI-powered features actually lowered the perceived value and did nothing to justify the higher price. AI is a tool, not an outcome.

Finally, don’t risk getting into a race to the bottom. Yes, competition is fierce, but competing against the $0 competitor won’t help you win. Price isn't a long-term differentiator, and we see that in the State of Subscription Apps report too: high-priced cohorts hold at 6x the LTV of lower-priced cohorts, and premium positioning signals the differential you’ve built. You just need to make sure you deliver that value for that price. Your free tier is competing with that blank box too, since it is the more limited experience, so make sure your free experience shows off the same advantages.

The irony of it all

We’ve talked about LLMs like ChatGPT as competitors. We talked about them helping your competitors build, but there’s an additional challenge; they are also your distribution channel. You can’t completely ignore them or move away from them. They need to know your app in order to suggest it to users. And they are undeniably useful — Brian Balfour recommends integrating them early in your app and if you can, letting their ecosystem help you win while you strategically differentiate.

Your users will continue to pay for you if your app knows them (memory), structures them (opinionated workflow), holds them to it (habit), gets the details right (precision), feels like somewhere they belong (connection), and helps them get more value out of the world around them (physical and digital). Run the two-minute Blank Box Test this week if you haven’t, and start building the things a blank box cannot do.

That's it. That’s the update. Rico used to answer questions about your app business and suggest what to do next. Now, it can just go get the work done.

Watch on YouTube

Rico can change your setup for you

With your approval, Rico can create and manage products, Offerings, Packages, and Entitlements, and build or edit paywalls directly in RevenueCat.

That includes real store products, not just RevenueCat-side config. Rico can create and update the subscriptions that live in App Store Connect and Google Play. These features rolled out to everyone last week, so go check out your account right now.

Experiments are the part I'd try first

Every dev I talk to says the same thing about experiments: they’re easy to come up with, but a pain to set up. You have to duplicate the paywall, name everything, wire up new Offerings and Packages, keep track of which variant is which, and only then can you finally hit start.

Rico can do that whole chain now. Ask it to test a new price or a new paywall against your current one and it builds out everything the test needs. Rico can create, update, start, stop, pause, and resume experiments, so the follow-up work is also just asking.

You still approve everything

Every proposed change requires your approval before anything happens. Rico is limited by the access level of the collaborator using it, so it can't do anything you couldn't do yourself in the dashboard. Project admins can go further and limit what Rico is allowed to do across all collaborators from project settings.

You can limit Rico to three levels of access: Read & write with permission (to enable everything we’ve talked about here), Read only (to use Rico only for gaining insights to your data, but not for changing anything), and Disabled (will completely turn off all Rico integrations for this project).

It's on your phone

RevenueCat Mobile 2.0 brought Rico to iOS alongside the Paywalls AI Editor. Ask questions about your app business, attach a screenshot, approve Rico's actions, or generate a new paywall, all from your phone.

What’s more, Siri and App Shortcuts can now pull up MRR, revenue, active subscriptions, and trials without opening the app at all.

The Android release with Rico is in testing now.

Go ask Rico

The Rico docs have the full list of what Rico can and can't touch — or of course, you can just ask Rico. Have fun with it! Use Rico to learn more about what’s working or not in your app monetization scheme, then ask it to fix it. I’m looking forward to hearing about what you do with Rico.

Watch on YouTube

So he did the only thing left. He went through the session slides, found the Apple evangelists who'd printed their email addresses on them, and wrote to six of them. Not a demand, he says, more a plea: "Please, I beg of you, tell me what I need to do." He led with how much he loved the platform, and linked to the newspaper photo of himself first in line for the iPhone in San Antonio.

One of Apple's most senior evangelists didn't email back. He called, and they talked for about three hours. He promised to get David an account. It still didn't come through in time. Trip Cubby, a mileage log for taxes and reimbursements, missed the July 10 launch and shipped in August.

David is clear-eyed about why the call happened at all. Apple wanted developers who cared about the platform, and his email showed one. "If I had said, like, I'm broke and I'm desperate, that's a very different email." It's the same rule he applies to pitching journalists and, today, to booking podcast guests: pitch what matters to the person reading, not what you need from them.

His dad refused the bridge loan, so they sold the Honda Accord

The first month on the store brought in about $5,000, which sounds fine until you remember Apple hadn't yet made clear when it would pay, and each region had a payout minimum over $100. David had already run out of money. So he asked his dad, a commercial real estate investor, for a bridge loan against the receivable.

His dad said no, and gave him a reason David hadn't considered: "this is essentially a payday loan." As David recounts it: "If I give you this 5,000 early, then by the time October comes around, you're going to need another 5,000, and then you're just going to be in the cycle of needing money every month." It was September 2008. His dad, property-rich and cash-poor as the market cracked, was broke too.

David and his wife sold her Honda Accord for four or five thousand dollars, became a one-car family, and made it to the first Apple check. He calls the missed launch and the "crappiness of everything" formative: "Had it been day one, my whole life story probably would have looked different and not necessarily for the better."

Camera+ taught him the search trick that made Mirror

David never ran paid marketing. "I've never done paid in 18 years." What he did instead was watch the top 100 obsessively, and around 2011 he became fixated on a question: why had the smart team behind Camera+ given their app such a bad name? "Camera plus is not a brand. Like, people are going to type camera and then spell the word plus."

The answer was that they were smarter than he was. Apple's search gave a huge boost to exact-match names, and it ignored symbols. Type "camera" and Camera+ was an exact match. David estimates the app made $10 to 20 million on the back of that, and it sat near the top of the results for years.

He had a mirror app, built in a weekend by repointing the kaleidoscope code of an earlier app at the iPhone 4's new front-facing camera. It was called Mirror by App Cubby. He renamed it to the single word "Mirror" plus an obscure Unicode symbol that looked roughly like a mirror, chosen because "Mirror+" and "Mirror++" were already taken and he didn't want to be quite that obvious. Downloads jumped almost immediately and stayed there: "a pretty tight range between, I think like seven and 10,000 downloads a day, every single day."

He sold Mirror in 2017 for over $400,000, having made over $1 million on it. It's still the top result for "mirror." He's a little embarrassed by how well a mirror app did, and also correct that it was a good app, with a full-screen view, zoom, and a white border that brightened the screen in low light.

Charlie's metaphor: search traffic is a raging river, and if you can put a pipe in it, you siphon off a steady flow you can build a business on. David's point is that more surviving indie developers than admit it have exactly that pipe underneath them, whether by luck or design.

Launch Center Pro went to Phil Schiller, ended up inside Shortcuts, and never paid a tech salary

Launch Center began as a hack. Persistent notifications could be made to stick in Notification Center, so David and his partner Justin built a quick launcher that lived there, using URL schemes to open apps with context: call your wife, jump straight to Instagram's camera. Their tagline was "Launch actions, not apps." Apple rejected the notification trick. They shipped the in-app launcher anyway, Federico Viticci championed it, and Launch Center Pro followed, with a grid of tiles and a tap-and-drag gesture for folders.

Getting Launch Center Pro approved, David heard later from an Apple employee, went all the way to Phil Schiller, because of the rule against mimicking the home screen. He's grateful, and also frustrated: "the fact that the app that really kicked all of this off had to go all the way to a senior VP to get approved is in some ways kind of ridiculous." Kicked off what? Workflow. The Workflow team had asked to integrate; David replied that Launch Center Pro might compete on their core product; they decided to compete instead. Workflow became Shortcuts.

Then there's the JSON file. Launch Center Pro had spent hundreds of hours building a database of URL schemes, much of it submitted by developers through a form. It sat in a public S3 bucket. David later found the same file, structure and all, in the Workflow binary, and after Apple's acquisition, in the Shortcuts binary. "Things that I typed into a JSON file were part of what Apple shipped in one of their system apps." He considered the copyright question, decided it wasn't a road worth going down, and wears it as a badge of honor.

Now the money. Launch Center Pro was featured by Apple, covered by TechCrunch and The Verge, and sat in people's docks for years at $3 or $5, with $0.99 sales. "There were plenty of people who only ever paid us a dollar for something that they put in their dock and used every single day, multiple times a day." At the peak, he and Justin each made maybe $150K in a year. Over its life the app grossed a little over $1 million, gross, before Apple's 30%. Across 18 years David estimates he's paid Apple well over $1 million in commission. And the line the episode opens on: he never made more as an indie developer than he does as a RevenueCat employee.

There's one decision he'd take back: not shipping a paid update around iOS 10, when Justin was pushing for it and David didn't think they had enough to justify it. The subscription switch years later, iPhone-only, landed on a community that had moved on. And there was the Zapier deal, early enough that Zapier could only offer stock. Justin didn't want stock in "some Silicon Valley company." By David's back-of-napkin math, it would be worth $50 to $100 million today.

Charlie puts the point plainly for anyone listening who thinks the well-known indie devs must be rich: "there's a very wide variance on the amount of money people are making, and it's not connected to how well known they are in the community."

Eighteen years in, he finally shipped an app himself

David never learned to code. He bought the Hillegass Cocoa book in 2008, got a quarter of the way through, and hired a contractor at $50 an hour. Every app since has meant a partner or a contractor and the question that comes with them: is this feature worth a dollar-for-dollar return on a programmer's time? He's never run an onboarding A/B test on his own apps. Paywall tests only happened because RevenueCat made them easy.

This spring he vibe-coded Grit Method, a habit tracker for character built from a paper journal he'd made for his kids years ago, with four daily prompts: do a hard thing, avoid a trap, be grateful, help others. He did the design with AI tools, added the staggered animations and back-swipe polish a contractor would never have been asked for, and had a blast. "It's been really fun to be able to just YOLO prompts and get a build like minutes later instead of like days later."

Then he did what he tells everyone not to do. It's made close to $2,000. He spent $2,000 on a UGC platform. He hasn't submitted it to Apple for featuring. "I just fell into all the same traps that I preach against on Twitter," he says. "I did nothing. I did none of it." He was too burnt out from building, and within days he'd started vibe-coding the next app instead. He has two more Xcode projects open right now.

Also in this episode: what he'd write into a partnership agreement after watching a 50/50 split slowly unwind, the sequencing mistake that held back Weather Up, why he thinks Launched is dessert and Sub Club is vegetables, and how The Design of Everyday Things ruined every cup holder for him except the one in his Kia EV9. If you make it to the end, reply to the episode post with one word: "Usability!"

Guest links

• Sub Club podcast
• Sub Club on YouTube
• David Barnard on X
• Weather Up
• Grit Method

According to the State of Subscription Apps 2026, 84% of 3-day trial cancellations and 64% of 7-day trial cancellations occur between Day 0 and Day 1. What’s more, nearly half of monthly subscribers, and the majority of yearly subscribers, do not renew even once.

By the end of this article, you'll have a clear picture of why that early churn happens — and a practical framework for preventing it. We'll cover the onboarding gap that quietly costs apps revenue every month, why new subscribers need to be treated like new users, and how to design a simple lifecycle journey that gets paying customers to their first 'premium win' — before buyer's remorse has a chance to set in.

Stop treating conversion as the finish line

Most subscription apps treat conversion as the finish line. But really it's the start of the retention journey. For many new subscribers, it's also where things start to go wrong.

Think about how much effort goes into getting a user to subscribe. Teams spend weeks, sometimes months, designing onboarding flows, refining paywall timing, testing trial journeys, tweaking upgrade messaging. Then the user finally converts… and the silence is deafening.

For new users, the app suddenly going quiet is a drastic 180. They were being nurtured towards the subscription they just paid for — and suddenly nothing. For app teams, that silence feels logical: the user paid, they're clearly engaged. Why interrupt them?

But subscribing doesn't mean the user actually understands what they've just unlocked. They might have converted based on a single feature they glimpsed during a trial, a discount that felt too good to pass up, or just a vague sense that this app might be useful. What they haven't done (yet) is experience the product as a paying customer. And without a little guidance, many of them will cancel before they ever do.

Why do users cancel early?

Early cancellations are rarely about product quality. They're almost always about the gap between what a user expected when they signed up, and what they actually experienced in those first few days. That gap is where buyer's remorse lives. And silence from the product team is what lets it take root.

There's another force making this worse: subscription fatigue. People are drowning in recurring charges — music, fitness, productivity, entertainment — and many have started turning off auto-renew the moment they subscribe to something new, just to feel in control.

It's a defensive habit born from too many forgotten subscriptions quietly draining bank accounts. Which means your new subscriber may have already mentally scheduled their exit before they've even opened the app a second time. The window to prove your product is worth keeping isn't weeks — it's days.

Re-onboard existing subscribers like they're new users

This is what's sometimes called the post-subscription gap: the window between a user converting and a user genuinely getting value from what they paid for.

It tends to show up in three connected ways:

1. Upgraders don’t find the premium features

This sounds almost too simple to be a real problem, but it is. And if you’re working with a freemium model, it’s quite possible the silence after conversion is what’s quietly pushing subscribers away.

Users who have already gone through free onboarding learn how to use the free version of your app. When they upgrade, nobody shows them what's changed. So they keep using the product the same way they always did — as if they're still on the free tier. The premium features exist, but the subscriber never finds them, and eventually cancels feeling like they never got much value when they started paying.

2. Most apps stop communicating once a user converts

After all that effort to nurture a potential subscriber, silence isn't a neutral choice — it's a missed opportunity. When lifecycle messaging disappears, users lack the product enablement to benefit from their upgrade, and often forget they even subscribed. They may question whether it was worth it, and cancel when renewal rolls around because they can't quite remember why they signed up.

3. “They’ve already been onboarded” is the wrong mental model

The mental model many teams use ("they've already been through onboarding, they don't need more") is a big mistake. It also misses the nuance between different types of subscriber: an experienced free user who upgrades doesn’t need the same input as instant or zero-touch buyers. But that doesn’t mean they don’t need any attention — they’ve just entered into a completely different relationship with your product. They deserve to be welcomed and shown around, just like new subscribers; simply in a different way.

What premium re-onboarding actually looks like

Re-onboarding for new subscribers isn't about repeating everything from free onboarding. It's about specifically welcoming people into the premium experience — making it immediately obvious what they've unlocked and how to start using it.

Slack does this well. When a user starts a Pro trial, they immediately receive an email that doesn't just say 'your trial has started' — it tells them exactly what's changed. The headline feature gets its own moment ('Message & file history unlocked'), followed by a clear list of everything else now available: Slack Connect channels, group huddles, unlimited canvases. There's no ambiguity about what the upgrade means. And crucially, the call to action isn't 'explore your account' — it's 'Explore in Slack', pointing users straight back into the product.

That's the whole job:

1. Confirm the decision
2. Show what's unlocked
3. Direct to first action