Watch on YouTube

A year later, an angel-turned-customer asked a question that changed the company's trajectory: have you considered crowdfunding? With 10,000 boaters already using the app, Liebrand launched an equity crowdfunding campaign with a target of £125,000 and no idea what to expect.

"Within 24 hours we're oversubscribed," he says. "Within six days we shut it down because it was triple of what we needed."

Savvy Navvy has repeated the playbook several times since, with most rounds landing around the £1 million mark: two or three angels at six figures each, then a long tail of customers investing anywhere from $10 to hundreds of thousands. The result is 2,500 investors who don't just fund the business — they answer logistics questions, make marketing introductions, and jump on calls. "We basically have this army of investors who A, believe in what we do, B, can back us with money, but also back us with knowledge."

"It's not some magic money tree. You're selling your business."

For all the success of the crowdfunding rounds, Liebrand is blunt about fundraising itself. "I actually hate the phrase raising money," he says. "It's not some magic money tree that you put some water in and you're raising this magical free money. You're selling your business."

His advice to founders who ask him about crowdfunding is even blunter: "My first bit of advice is don't raise at all. If you can get away with not raising VC or crowd or angel or anything else, just don't." And for those who do: raise half of what you were planning to.

The numbers behind Savvy Navvy's rounds are public on the platform, and they're a useful reality check. The last round valued the company at £15 million against roughly $3.5 million in B2C ARR plus a couple million more in B2B revenue — a 3–4x multiple, not the 20x founders might fantasize about. As David points out in the episode, apps are typically acquired at around 4x trailing profit, which makes a 3–5x revenue multiple on a consumer app healthy, not stingy.

The 2-year subscription that transformed CAC payback

Asked for his biggest win of the past year, Liebrand doesn't hesitate: two-year subscriptions.

The mechanics are simple. Savvy Navvy's standard price is $129 per year; the two-year plan is $183 — roughly 30% off. Boat owners keep their boats for years, so the longer commitment fits how customers actually use the product. But the real payoff is timing: "The benefit for us isn't actually, ooh, that's more money. It's more money upfront... that's had a huge impact on what we're then able to do on the marketing side and the spend that we can have, because we get that back immediately as we spend it."

If annual plans were the industry's answer to CAC payback, this is the same logic taken one step further — two years of guaranteed LTV, collected on day one.

The signup experiment that left scars

Liebrand's biggest fail of the year is one many growth teams will recognize. Account creation is a friction point, so the team tested removing it entirely — "anonymous accounts" created silently under the hood.

"Initially the results were through the roof. It was amazing," he says. Then they rolled it out to 100%, and the success rate started to drop. Users who claimed to want privacy still wanted to sync between phone and iPad — which requires an account. Support tickets piled up. And metric issues meant the original uplift was overstated anyway. "Internally people have scars from it."

His broader warning: without a billion users, most startups don't have the sample size to A/B test properly, and it's dangerously easy to read into the numbers what you want to see while something further down the funnel quietly breaks.

Word of mouth, but not every mouth is equal

Savvy Navvy runs a large program for boating instructors — no affiliate codes, no kickbacks. Many instructors explicitly don't want them, because they don't want to be seen as sales reps. Instead, they get free access, purpose-built teaching tools, and first crack at beta features.

Liebrand explains the logic with a story from his own training: an instructor teaching him to keep his thumbs clear of a winch — while missing a thumb from doing exactly that. "I'm going to trust anything that guy says," he laughs. "Word of mouth is a great thing for any business, but not every mouth is the same value."

The same thinking powers Savvy Navvy's B2B flywheel: partnerships with boat manufacturers, starting with electric boat maker Arc Boats, now put the app directly on helm displays — and an announcement timed to this episode brings CarPlay-style navigation to pontoon boats. When a manufacturer that has been building boats for decades ships your app on the dash, that's validation no ad budget can buy.

In the full episode, Jelte and David also cover the clipboard-powered user research that revealed the real market, why running freemium in the US but not elsewhere gives the company two business models, and why "if your product comes with a manual, you've already lost." Jelte also joins the Sub Club YouTube livestream on August 6th at 9:00 AM Pacific / 18:00 CET to take listener questions.

Guest links

•Jelte Liebrand on LinkedIn

•Savvy Navvy

Watch on YouTube

None of it started with credentials. Skiles is a self-taught designer from the South Island of New Zealand who built his first website at 15 from an HTML book, coding a one-pager for a tennis coach with his brother. His first app icon was for Rock'n Rockets, an iPhone game the two brothers shipped themselves — covered twice on MacStories, played by maybe a hundred people.

When paid icon work finally arrived around 2014, it didn't come through a portfolio, because he didn't have one. "My initial app icon work was people I already knew from other projects," he says. "I didn't have the portfolio of any kind to show anyone that I can do app icons, but they knew my work already and they had enough faith in me to give it a shot." From there, the strategy was simple and stubborn: only post the icon work, never the web work, first on Dribbble and later on Twitter — until Christian Selig commissioned alternate icons for Apollo and put his name in front of a massive audience.

"If I was a smart businessman, I wouldn't have made that decision"

App icons are just about the worst consulting business you can pick: short engagements, little repeat work, a constant need for the next client. Charlie asked how he squares that, and Skiles didn't pretend there was a clever strategy.

"If I was a smart businessman, I wouldn't have made that decision, but I make decisions based on it's fun," he says. "It was not a smart business decision. I'm still not sure if it's a smart business decision, but it keeps working, so I'll keep doing it."

What makes it keep working is the scale of the App Store itself. After a career's worth of icons, he's still surprised: "How can there be more apps and more people that I haven't worked with? But there's always a new person who comes along and says, 'I've got a new app and I want you to make an app icon.'" It's a job that didn't exist when he was a kid — and it exists now because Apple built an ecosystem where developers are expected to care about how their icon looks.

The most common icon mistake: your symbol is too big

Skiles's process is more analog than you'd guess. He sketches roughly ten concepts in pencil on paper printed with half-icon grids, builds the winning shape in Illustrator, refines in Sketch, and only reaches for Photoshop when something needs texture — "there's no better tool for building textured things than Photoshop," whatever people say about those apps being dead. Color comes last, only after the shape is settled.

His philosophy runs against the obvious instinct. The best icons, he argues, aren't literal representations of the app — think Transmit's truck or Coda's leaf. "The app icon will make them be like, 'I'll give it a shot because I want that in my dock.'" A utility you use every day should be something you like having around, the same way you'd rather own a nice pen than an ugly one.

And for anyone designing their own icon, he offers the single most common fix: shrink your symbol. People scale their logo up until it fills the squircle, and it almost never looks right. "Just give it a bit of breathing room. Just shrink it down just a little bit and it'll look nicer." Even Apple's own grid circle is often too generous — "you actually want to be a little smaller than that."

AI hasn't replaced him — but it has created a strange new client problem

Skiles doesn't use AI in his own work ("I love the process of doing it myself"), but it's already changed his client relationships in two opposite ways.

The good: AI images are a genuinely useful communication tool. When a client arrives with a generated reference, "it gives them a way to convey that to me, whereas it would've taken a lot longer to find what it is they're looking for."

The bad: infinite generation creates choice paralysis. Clients show up with AI-generated options, he recommends a direction, and "then they will go and generate 50 more options... at some point you have to make a choice so I can go in that direction with you." Worse is when a client falls in love with a specific AI image and just wants it reproduced: "You're almost stuck trying to replicate the AI design for people, and you're like, 'What do you want me for then, if you just want me to redraw that thing for you?'"

His overall stance is deliberate patience — the same wait-and-see approach he once took with Sketch before it won him over. Tools get easier to adopt over time, so there's little risk in watching first. The one area pulling him in: custom generators for textures and assets, where the designer keeps control over what's being generated.

He has thoughts about Liquid Glass

Skiles lived through the great flattening of iOS 7 — which, he says, made him better, because "before that you had details and textures to hide behind... you just had to have a great shape." He loved the Big Sur era, where icons fit the squircle by convention but could still break out of it: "an advised constraint versus a forced constraint, I think, gives the best results."

Tahoe's mandatory glass frame is another matter. Icon Composer saves him real time when a client wants a system-native look across platforms, but the non-negotiable edge highlight grates: "If it was up to me, that effect wouldn't exist. Let people put glass within the icon, but just don't put it on the frame... But this is the world we live in. We accept what Apple gives us and we find a way to make it work."

In the full episode, Matthew also talks about the lost golden age of the Dribbble design community, why he almost never gets Android icon work, the current trend of custom glass shaders and mesh gradients, and the delicious-era Mac designers — Jasper Hauser's AppZapper ray gun among them — that he's still chasing: "When I was a kid, that was my dream, and it's still my dream now."

Guest links:

• Matthew Skiles's portfolio
• Matthew Skiles on X
• Matthew is also on Mastodon and Bluesky as @matthewskiles

When an app starts spending its first $100 or $500 a day on performance marketing, a stable return feels like success. A user costs $30 to acquire and returns $50. The campaign is profitable. Why not scale it?

Yuliya argues that this is exactly when a team should become suspicious.

“This is bad for you actually because you stop trying and you think, oh, my LTV ROI, whatever, it looks great. I'm doing everything fine. You are not doing fine. You are doing very, very badly.”

Watch on YouTube

A predictable margin can convince a team that it has solved acquisition before it has found a genuinely exceptional creative. The stronger signal is not steady performance across several ads. It is the outlier that changes the curve: CPA falls sharply, or purchases triple in a day.

That is the difference between an ad that backs out and an idea that can move the business. Early performance marketing should search for those step changes, not settle into comfortable averages.

BetterMe’s ugliest ad was the one David remembered

David Barnard still remembers a BetterMe ad he saw roughly a decade ago. It featured a deliberately unpleasant illustration of belly fat hanging over the front of someone’s body. It was not aspirational fitness advertising. It was visually jarring—and that is why it stayed in his memory.

Yuliya calls it “the best ad ever.” The polished images of slim people exercising disappeared into the category. The ugly illustration broke the pattern of the feed.

“They want something that catches them on the first glance.” — Yuliya Lennox

For an app selling a function, the first job of an ad is not to look like a campaign from an established consumer brand. It is to make the product and the pain it solves obvious in the first second. Brand polish is valuable only after the viewer understands what is being sold.

There is still a limit. At Solid Starts, a baby-feeding brand built around trusted expert advice, the team tested a creative featuring babies made out of fruit. The image attracted attention, but it also prompted parents to question whether they should trust the company feeding their children.

The lesson is not that every app should make every ad ugly. It is that most teams invoke “the brand” too early. Performance creative should have to prove that it damages trust before polish becomes the default constraint.

The No. 2 language app kept its founder in every marketing meeting

Founders often look for a senior marketer, agency, or CMO who can take growth off their plate. Yuliya’s experience suggests that delegation works better after the founder has developed their own feel for the market.

She points to Eva Learn English, which reached the No. 2 position behind Duolingo. Its founder attended every marketing meeting, developed creative concepts, and stayed close to how the product was communicated.

“It's not hard at all to understand marketing, but to feel it with your own hands, this is something that every founder needs to know.” — Yuliya Lennox

A founder does not need to remain the company’s permanent media buyer. But they do need enough firsthand experience to recognize a strong message, challenge a weak assumption, and know whether the team understands why customers buy. An agency can execute the work; it cannot manufacture that intuition on the founder’s behalf.

Sell the idea before you vibe code the app

Cheaper development has made it easier to build a complete product before proving anyone wants it. Yuliya recommends reversing that order.

“Just start with marketing, sell a PDF, sell an idea, sell something and then refund because you don't have a product.” — Yuliya Lennox

The tactic is intentionally uncomfortable. Put the promise in front of a real audience, ask people to pay, and learn whether demand exists before investing months in development. If the product does not exist yet, refund the buyers. The point is not to collect revenue; it is to replace encouragement from friends and family with evidence from the market.

This also forces a founder to define the business they are trying to build. A niche app might be perfectly capable of supporting a $20,000-a-month lifestyle business while remaining unsuitable for venture-scale economics. Marketing the idea early exposes that distinction before the cost base is locked in.

A $10 test market can save a $1,000 US experiment

Localization is usually treated as a revenue-expansion project. Yuliya also sees it as a way to make experimentation cheaper.

AI can translate a service in hours, making it practical to test more countries without a long localization project. Teams can use markets with lower CPMs and similar conversion behavior to learn which creative concepts deserve a more expensive US launch.

“You need to test 500 ads per week. And if you do that on US CPMs, you will definitely go broke.” — Yuliya Lennox

Yuliya says a comparable market such as Indonesia can sometimes turn a 1,000−a−day US test into a 10-a-day experiment, giving a team directional evidence before it pays US CPMs.

Cheap translation is not the same as local understanding. Replika made a serious push into Japan and even had a Japanese speaker on the team, but the localization still failed to gain traction. The practical play is to use international markets to widen the testing surface while recognizing that language alone cannot reproduce cultural context.

In the full episode, Yuliya and David also discuss how organic growth can become a trap, why subscription optimization can slide into black-hat behavior, and why running three apps at once prevents the war-room focus required to scale.

Guest links

• Yuliya Lennox on LinkedIn

How do I make money?

This question comes up because many Mac developers choose to distribute their apps outside the Mac App Store. Sandboxing imposes restrictions on iOS apps, but it's even more extreme for Mac apps. Many of the things we've come to expect from "Mac-assed Mac apps" over the years are simply not possible with sandboxing. However, disabling the sandbox on a Mac app comes at a cost: you cannot ship your app on Apple's App Store. This means that all of the work of collecting money from customers, handling licensing, etc. falls squarely on the developer's shoulders. And so every couple of months, like clockwork, another developer is in the Slack group asking for recommendations on how to implement licensing.

This is a problem I've faced several times myself. I love writing Mac apps; I've got three I'm building for myself right now. On iOS, I've used RevenueCat to simplify the logic around dealing with in-app purchases, and it's been wonderful to offload that mental burden onto a reliable framework, and allow me to focus on the task of building my app. I've wished something as easy existed for Mac apps, too.

Earlier this year, I joined RevenueCat as a Senior SDK Engineer and learned more about all the ways they help developers make money. Of course, I immediately thought "Well, what about Mac developers?" One feature in particular caught my eye: web-based billing support. This is a way for web developers (and mobile developers selling outside their platform stores) to offer subscriptions to their customers. Since all the information is associated with RevenueCat's service, purchases made on the web get tied to the customer’s profile, which can then be accessed via the RevenueCat SDK in an app. And since the RevenueCat SDK works on macOS… I quickly started connecting the dots and forming a plan.

After thinking about this approach, I put it on my to-do list to see if it would actually work. As luck would have it, a couple of days later my friend Jared Sorge mentioned he was looking to solve this exact problem, and he was game to try my idea. After some careful reading of the documentation, a couple of Zoom chats, and a bit of trial and error, Jared got it to work. In the end, it was extremely straightforward:

• Configure the product offerings and entitlements in the RevenueCat dashboard, like you would for any other app
• Connect Stripe as a web provider and hook your offering up to a Web Purchase Link
• Send identified users from your Mac app to the web to purchase
• After purchase, ask the SDK to refresh, and see that they now have the purchased entitlement

That's the short version. The longer version is Jared's story—how he got there for Arborist, his new Mac app launching today.

Why not Paddle, FastSpring, or Lemon Squeezy?

Arborist is a native macOS command center for git repositories and worktrees. It works by running user-entered commands at arbitrary locations, which means sandboxing—and therefore the Mac App Store—was never an option. Jared settled on a one-time version 1 purchase of $39, "just like the Software Days of Yore," and then hit the question every direct-sales Mac developer hits: how do I do licensing on my own?

He knew the established options like Paddle, FastSpring, and Lemon Squeezy have worked for many apps like his over the years. But:

I also wanted something simple for my users. Not to mention Apple Pay was a must-have. I've experienced friction more times than I can count when an app doesn't support Apple Pay, and every time it happens I am ever so slightly less happy with that app because of it. Customers are also more familiar with the smooth in-app purchase experiences provided by the App Store, and if I could achieve something that easy I wanted to do just that.

No license server, no license keys

What Jared landed on contains three pieces:

• RevenueCat serves as the source of truth for whether or not a customer is licensed.
• Customer IDs come from local iCloud identifiers—specifically, calling userRecordID() on the app's CKContainer in CloudKit.
• When the user makes a purchase, they earn an entitlement that Arborist looks for to grant them a license.

The second bullet is the clever one:

I didn't want to have to spin up a licensing server to send out codes (much less have to store them), and I didn't want to have an email-based system. I wished for something simple like StoreKit but without using the App Store as a backend.

Because the customer ID is the user's iCloud record ID, a license bought on one Mac automatically follows the customer to every Mac signed in to the same iCloud account. There are no license keys to email, no "Restore Purchases" button, and no personally identifying information collected by the app. As Jared puts it: "Stripe handles the payment process, and the iCloud's identifiers give nothing away."

The trade-off is that this strategy requires the customer to be signed in to iCloud—a reasonable assumption for a power-user app, and Jared is working on a web-based iCloud sign-in for everyone else, coming after 1.0.

The merchant of record question

Jared initially set up RevenueCat Billing, RevenueCat's own billing engine for web purchases, but then he ran into a term he'd never encountered:

I had never heard the term merchant of record (MoR) before and when I first did I didn't know it was something to care about (spoiler alert: it very much is).

The merchant of record is the entity legally responsible for the sale: collecting and remitting sales tax, VAT, and GST, and handling refunds. RevenueCat Billing does not act as your merchant of record: you are. For solo developers, this can add a significant amount of complexity. For Jared and his first direct-sale app, it was a dealbreaker.

The good news is that Stripe offers Managed Payments, a merchant-of-record service where Stripe takes on tax collection and remittance per transaction, and RevenueCat supports it out of the box. From an app developer’s perspective, it’s the same entitlements, same SDK, and same Web Purchase Links; Stripe just carries the compliance burden. It adds a cost, but that was worth it to Jared:

Thankfully I found Managed Payments and from everything I can tell, making Stripe my MoR puts all the burden of these collections and distributions on Stripe. So I'm happy to give them a few extra percent of each sale to handle that for me.

Setting up the backend

Jared has documented his full setup, including the places he tripped up, on his blog. The condensed version is short:

1. Create the entitlement in RevenueCat that the app checks for a license.
2. Add the product in the Stripe dashboard, making sure it meets Managed Payments' eligibility criteria.
3. Connect Stripe to RevenueCat as a web provider, checking the "Use Managed Payments when available" box.
4. Create the RevenueCat product by importing it from Stripe.
5. Add an offering containing the product with a lifetime duration—effectively a one-time purchase.
6. Generate a Web Purchase Link for the offering, including the callback URL the web checkout uses to deep-link back into the app.

Hooking up the app

The full purchase flow in Arborist looks very familiar to app users: open the License screen in the Settings, click “Buy,” complete the purchase in your browser, and automatically get returned to Arborist. That’s it.

Jared had initially hoped to keep everything in-app using a WKWebView, but a known WebKit bug prevents Apple Pay from working in that context. Instead, he accepted the small friction of jumping out to the user’s browser so customers can use Apple Pay instead of typing in card details by hand.

Another caveat he found is that the RevenueCat SDK is geared toward apps that use StoreKit and doesn’t supply the corresponding web purchase link directly. Instead, he hard-codes the checkout URLs (production and sandbox) instead. When the user clicks buy, Jared's licensing view model assembles the checkout URL (shaped like https://pay.rev.cat/{web_link_id}/{user_id}) and hands it to the system browser:

func startCheckout() async {
    guard isStartingCheckout == false else { return }

    isStartingCheckout = true
    actionMessage = nil
    defer { isStartingCheckout = false }

    do {
        let checkoutURL = try await licenseManager.checkoutURL()
        guard NSWorkspace.shared.open(checkoutURL) else {
            throw LicenseCheckoutOpenError.failedToOpenBrowser
        }
        actionMessage = "Checkout opened in your browser."
    } catch {
        displayState = LicenseDisplayState.resolved(
            from: nil,
            previous: displayState,
            error: error
        )
    }
}

After a successful purchase, RevenueCat's backend associates the passed-in user ID with the entitlement and calls back into the app via the registered deep link. The handler re-fetches the customer and validates the entitlement:

func handleDeepLinkPurchase() async throws {
    let customerInfo = try await Purchases.shared.customerInfo(fetchPolicy: .fetchCurrent)

    guard
        let entitlement = customerInfo.entitlements[entitlementID],
        entitlement.isActive
    else {
        // Handle a missing entitlement; this means the
        // transaction did not succeed
        return
    }

    // Once we get here we have a validated customer who has
    // made a purchase and the app can be unlocked.
}

That first line with the fetchPolicy is important:

The fetch policy here is critical because without specifying .fetchCurrent the SDK will return cached data, and if a customer has made a purchase that won't be reflected instantly like they'll expect. Instructing the SDK to bust out of its cached data is the thing that will make this process feel seamless to my customers (and yours!).

Similar code runs at app launch to validate the user against their iCloud ID, which is how a license bought on one Mac unlocks Arborist automatically on the next.

I was thrilled to discover that not only is using RevenueCat for desktop app licensing possible, but it's actually a straightforward setup process with a relatively small amount of in-app code. There are really only about three main areas where Jared needed to make changes: the UI for offering the purchase option to users and sending them to the web, the code to handle returning from the web, and the code that runs at startup to configure everything and check for existing purchases.

Having such a simple way to offer Mac app licensing to customers is very exciting to me. There are some ways I can see for the SDK to make this even easier, and I hope to start addressing them. If you're writing a Mac app and looking for a simple way to offer licensing to your customers, RevenueCat can help you make money.

Arborist launches today—and Jared's full write-up, including everything he learned, is on his blog.

stripe projects add revenuecat/app

We built this with Stripe as part of Stripe Projects.

Watch on YouTube

Before this, monetization setup was still manual

Every other piece of your stack provisions in seconds. Database? One command. Auth? One command. Hosting? Done. But until now, monetization required you to stop and spend an afternoon creating accounts, reading StoreKit documentation, figuring out which shared secret goes where, generating API keys, configuring sandbox environments, and setting up server-to-server notifications.

It takes hours. Sometimes days. And you haven't written a single line of product code yet.

That gap between "I have a working app" and "I can charge for it" is absurdly wide for something that should be a solved problem.

So we fixed it.

One command, working credentials

If you're starting a new project today, here's what this looks like in practice.

You (or your agent) run one command. A few seconds later, you have a RevenueCat account, a configured project, and working API keys written directly to your .env file. You stay in the terminal the entire time.

$ stripe projects add revenuecat/app ✓ Created RevenueCat account ✓ Created project "my-app" ✓ Generated API keys ✓ Wrote REVENUECAT_APP_UUID to .env ✓ Wrote REVENUECAT_DASHBOARD_URL to .env ✓ Wrote REVENUECAT_SECRET_API_KEY to .env Ready. Run `stripe projects open revenuecat` to view your dashboard.

Products, entitlements, and offerings can be configured from the dashboard later, or your agent can handle them via our MCP server.

Agents provision it automatically

If you build in Cursor, Claude Code, or Warp, the provisioning step is something your agent handles between writing your UI code and wiring up the SDK. You don't type the command. You just say "add monetization."

You: "I want to add a $9.99/month subscription to this app." Agent: [runs stripe projects add revenuecat/app] Agent: [reads .env, configures Purchases SDK] Agent: "Done. I've added the Purchases SDK to your project and configured it with your API key. Want me to create a product and build a paywall next?"

The agent doesn't need special RevenueCat knowledge. It picks up the Stripe Projects CLI and the skill files that stripe projects init already created. Monetization becomes a routine provisioning step, same as adding a database or setting up auth.

Account, project, keys, full platform

When you run stripe projects add revenuecat/app, the CLI provisions:

• A RevenueCat account (or links to your existing one)
• A new project with sandbox and production environments
• API keys synced to your local .env
• Access to the full platform: paywalls, entitlements, offerings, analytics, webhooks, and our AI Toolkit for ongoing management

You'll still need Apple and Google developer accounts to go live on those stores. But RevenueCat itself (the account, the project, the API keys, the entitlement configuration) provisions from the terminal. And with RevenueCat's test store, you can test monetization on a real device without those store accounts.

From there, you integrate the Purchases SDK for iOS, Android, React Native, Flutter, KMP, or web. That's the path from "I have an idea" to "I'm making money."

Try it

1. Install the Stripe CLI with the Projects plugin:

stripe plugin install projects

1. Initialize your project and add RevenueCat:

stripe projects init my-app stripe projects add revenuecat/app

1. Your REVENUECAT_SECRET_API_KEY is in .env. Integrate the SDK and start making money.

For the full lifecycle, check our documentation or ask your coding agent to handle product creation, paywall configuration, and entitlement management using the RevenueCat AI Toolkit.

This is a developer preview. Give it a try and tell us what you think, especially if you're building with agents.

When Joe Fabisevich left Twitter to go indie, he didn't start by building his link-saving app, Plinky, in secret. Instead, he treated his TestFlight beta like a full production launch.

Watch on YouTube

For months, he ran a beta program that required real infrastructure. When he had to change Plinky's underlying data structure, he didn't just wipe the database—he built a complete export and import system so the 5% of users who were deeply attached to their links wouldn't lose them. "It was not worth it in the sense of the value of the time that I spent on it," Joe admits. But the effort paid dividends. When the app officially launched and users inevitably asked for an export feature, the system was already built and battle-tested. Treating the beta with the care of a live product meant he already had the infrastructure—and the user trust—to scale.

The $10,000 Daring Fireball email

While building Plinky, Joe took a three-month detour. Six months after ChatGPT launched, OpenAI released the GPT-3.5 API. Joe and a friend saw an arbitrage opportunity: there was no official ChatGPT iOS app yet. They built Short Circuit, a barebones wrapper, in just 19 days.

The app's success wasn't driven by complex marketing or paid ads. It came down to one email. Joe pitched the app to John Gruber, framing it not just as another AI tool, but as a specific solution for Apple users. Gruber posted it on Daring Fireball. "We started getting alerts from RevenueCat in our pocket," Joe remembers. "We made like $5,000 in the first two hours." The app pulled in $10,000 in a day and a half. The lesson was immediate and clear: "Definitely reach out to press, you idiot."

Why freemium is a trap for indie apps

When Plinky finally launched, Joe wanted to be generous. He offered a freemium tier that allowed users to save 50 links for free. His wife, a staff product marketer, warned him they would churn. She was right.

"I went back and forth on freemium versus trial, and I settled on freemium because I want to be generous. And now I regret it," Joe says. The problem wasn't just lost revenue; it was lost data. Freemium users who churned disappeared invisibly, giving Joe fewer "shots on goal" to understand exactly when and why someone decided the app was worth paying for. He eventually dropped the free limit to 10 links and is now shifting toward a standard free trial model, realizing that charging users sooner is the only way to accurately measure the app's real value.

The three-email formula for app sales

Plinky is now priced at $39.99 a year, and Joe has found that the single best way to drive revenue is through structured email marketing to his free users. He collects emails upfront via Sign in with Apple, giving him a direct line to his audience that doesn't rely on App Store release notes.

His wife gave him a strict rule for sales: nobody cares if the discount is less than 50%. So he runs 50% off sales, and he never relies on just one email. The playbook is always three touches: an announcement email, a reminder a few days later to non-openers, and a final 24-hour warning. "The last email usually drives the most people through the door," he explains. If the first email doesn't convert immediately, the strategy is working exactly as intended.

In the full episode, Joe also talks about how he organizes his launches using a "lookback calendar," why he open-sourced his database library Boutique, and how he watched an AI agent completely rewrite the Short Circuit codebase in just three and a half hours.

Guest links

• Joe Fabisevich on X
• Plinky
• Build.ms (AI Workshops)
• Joe's Personal Site

Those numbers convinced me to post a hunch on Twitter: for most subscription apps, the share of paying users on iOS 26 is probably more like 95%. And if that’s anywhere close to true, it’s time to start thinking about iOS 26 as the minimum requirement. Adding new features faster could easily pay for the small drop in paying users.

App industry folks pushed back, added data, and sharpened the argument in ways I didn’t expect. So here’s the fuller case: when cutting older iOS versions makes business sense, when it doesn’t, and how to run the numbers on your own app.

What the data says about who actually pays

I made up the 95% number. Baran Toppare, a data scientist here at RevenueCat, came back with the receipts.

Across apps on RevenueCat, about 88% of paid subscribers who opened an app in the last 90 days are on iOS 26. iOS 18 still accounts for 9.4% of subscribers and 9.6% of revenue. New transactions tell the same story: 85% happen on iOS 26.

So, not 95%. But that platform-wide average includes massive apps like ChatGPT that pull it toward the broadest possible audience. Your app probably isn’t ChatGPT. When I checked Weather Up (my side-project weather app), roughly 94% of paying users active in the past 90 days were on iOS 26.

The trade you’re actually making

Raising your minimum OS costs you two things. Existing users on older versions keep the app, but frozen at the last compatible update. And new users on older versions can’t download it at all. That second one is the real cost, because it compounds: every new customer you can’t acquire is gone for good.

David Smith wrote the best conservative case I’ve read. Nine months into the iOS 18 cycle, requiring the latest OS would have cut about 9% of Widgetsmith’s new downloads. As he put it: “If I could do something which boosted my downloads by 9% I’d be delighted”. His threshold: wait until older versions fall to about 1% of new downloads.

That’s a defensible line. Mine is more aggressive, and 2026 is a big part of why:

• Since April 28, every App Store submission must be built with the iOS 26 SDK. Your app already renders Liquid Glass for iOS 26 users, so supporting iOS 18 means shipping and QA-ing two design systems in one binary.
• At WWDC26, Apple confirmed iOS 27 runs on the exact same devices as iOS 26 (iPhone 11 and newer). Requiring iOS 26 doesn’t strand anyone whose hardware could go further. Everyone excluded is on a 2018-or-older iPhone.
• The cost shrinks every month. iOS 18 was down to about 10% of active devices by the end of June, per TelemetryDeck. An iOS 26 minimum costs you a bit today, less in the fall, and almost nothing by next spring.

Why I required iOS 26 for Grit Method

My latest side project app, Grit Method, requires iOS 26. The UI leans heavily on Liquid Glass, and I didn’t want to check every animation and UI element against older simulators, then invent workarounds for a shrinking audience. One code path, the latest best practices, no backward-compatibility debt on day one.

There’s also a more practical problem: I no longer own a device running iOS 18. My whole family upgraded in the fall. Supporting an OS version you can only test in a simulator is its own quiet risk, especially when the people on it are paying you.

To be clear about my bias: I’m an indie moving fast, and the tradeoff is much smaller for me. Moving faster is worth more to my business than the single-digit percentage of paying users I’m giving up. The bigger your app, the more carefully you should run this math.

When you shouldn’t cut older versions

Some apps shouldn’t take this trade:

• Apps where the audience skews toward older devices. Kids apps are the standout, since parents hand down old phones and buy used ones. Games with older demographics fit here too. As one reply on the thread put it, the Candy Crush crowd on iPhone 14s is still a market worth acquiring.
• Freemium apps that need reach. Free users skew toward older OS versions. If your model depends on a large free tier feeding a small paid one, cutting old versions taxes the top of your funnel hardest.
• Apps people need, not just want. If your app touches health, safety, or money, “they can buy a newer phone” isn’t an acceptable answer for the people who can’t.

The biggest companies in the world land all over this spectrum, and the split tracks business model. WhatsApp still supports iOS 15.1, a 2021 release, because reach is the product. Airbnb and Gmail already require iOS 18. Neither is wrong. They’re optimizing for different things.

One more nuance from the thread that stuck with me:

OS version is a proxy for device age, and device age is a proxy for purchase intent.

The best counterargument

Dan’s right that for some apps, maintaining backward compatibility is cheap. AI coding tools have made the #available dance easier than it used to be. If old-version support costs you almost nothing, keep it.

But “almost nothing” is doing a lot of work in that sentence. Two design systems isn’t nothing. An untestable device matrix isn’t nothing. And Dan’s own framing (better available and maybe buggy than not available) is a harder sell when the person hitting the bug is a paying subscriber.

How to run your own numbers

Don’t inherit last year’s minimum by default, and don’t inherit mine. Check four things:

1. New users by OS version: In RevenueCat, go to the Customers tab and click on “New audience”. Add a filter for “First seen” with the last 90 days. Click the “Export all” button and then have your favorite AI tool analyze the data.For Weather Up, 83% of new users in the past 90 days were on iOS 26 or newer.

2. New purchases by OS version: In RevenueCat, go to the Customers tab and select “New audience”. Add a filter for “First purchase date” with the last 90 days. Click the “Export all” button and then have your favorite AI tool analyze the data.For Weather Up, 85% of new purchases in the past 90 days were on iOS 26 or newer.

3. Active subscribers by last seen OS version: In RevenueCat, go to the Customers tab and select “Active subscribers”. Click the “Export all” button and then have your favorite AI tool analyze the data.For Weather Up, 94% of active subscribers are on iOS 26 or newer. Interestingly, 8.5% of active Weather Up subscribers are already on the iOS 27 beta.

4. What the floor buys you. If requiring iOS 26 doesn’t change what you can ship or how fast, there’s no trade to make. For a Liquid Glass-heavy UI or anything built on iOS 26-only frameworks, the velocity gain is real.

So, did the data change my mind about Weather Up? No. But this is a judgment call: potentially losing 15% of new purchases is a real cost, and more than I expected when I tweeted.

Two things tip the decision anyway. We’re deep into a 4.0 update that fully embraces Liquid Glass, and dragging that redesign through a second, older design system is exactly the tax this whole post is about.

The second: the past 90 days of data is somewhat skewed by traffic source. Most of Weather Up’s current traffic comes from App Store search and being featured, which reach the broadest (and least bleeding-edge) audience. When the 4.0 update launches alongside iOS 27 in the fall, press and launch attention should skew new downloads back toward early adopters, closer to the 94% of active subscribers. Your new-payer mix isn’t a fixed property of your app; it follows your traffic.

So pick your line on purpose, and treat it as a line, not a law. David Smith’s is 1% of new downloads. Mine is “under 10% of new paying users, if the velocity gain is real”, and Weather Up just showed you both halves of that sentence doing work. What’s not defensible is picking a minimum on vibes (or this post) without ever looking at your own data.

Five years ago, the path to building a consumer app was straightforward: raise venture capital, hire the best engineers, and build. Andrew Maguire thinks that playbook was always flawed — and now it’s irrelevant.

“You could give a founder $20 million to hire engineers and they can go hire all the best engineers,” he says. “And if they don’t have great product intuition and product taste and a process for building a great product, then they’re just going to light $20 million on fire.”

Watch on YouTube

AI has collapsed the cost of building to near zero. RevenueCat co-founder Jacob Eiting agrees that the bottleneck has shifted: “The noise has gone up so much and there’s just so many options now that almost the only way to differentiate is by having something that stands out.” Product quality drives down acquisition costs, which drives efficient scale. Engineering talent is no longer the scarce resource. Taste is.

Maguire is particularly skeptical of the “one-shot app” approach — prompting an AI to generate a complete product from a few sentences. “Build me a great personalized fitness app and here’s a couple other sentences — because there’s just too many decisions to make.” The founders who’ll win are the ones using AI to iterate faster through those decisions, not to skip them.

The clearest lane to $10 million has no VCs in it

The conversation’s most striking claim came from Maguire mid-episode: “There has never been a better time to indie developer a $10 million app.”

The logic is simple. The old dynamic required venture capital to build anything meaningful — you needed engineers, infrastructure, and runway. VCs would then ask how you planned to disrupt Chess.com’s network effects, and if you couldn’t answer that, you couldn’t raise, and if you couldn’t raise, you couldn’t build. That entire chain has broken.

“Now there’s a very clear lane to build those products super cash efficiently,” Maguire says. Subscription infrastructure, revenue-based UA financing, and AI-assisted development mean a solo developer can reach eight figures without giving up equity.

Eiting reinforced this with a real example: Curtis Herbert of Slopes, who famously bootstrapped his ski tracking app to a team of roughly 12 people. “He’s built a really amazing business and he’s very happy with how it is. He did a very thoughtful and conscious way of choosing how to build that business.”

The practical implication: if you can’t clearly articulate how your company becomes worth a billion dollars, don’t raise venture. “Those investors get preferred stock,” Maguire explains. “If you sell your company for $20 million, they get all $20 million.” The math only works if you’re genuinely building toward a multi-billion dollar exit.

What actually makes consumer investable in 2026

For the apps that do warrant venture capital, Maguire has a simple filter: “You need to have a credible path to building a low churn product.”

That means one of two things. Network effects — hard to create, nearly impossible to disrupt once established. Or deep AI-powered personalization that creates usage lock-in, where the product becomes genuinely better the longer someone uses it.

“Think about a product that is going to be much better for the user in two years or three years than it is when they first started using it,” he says. “Not because of the promise of more features being shipped, but because of the usages.” Health, finances, nutrition — any domain where a full-time personal coach with access to 100% of your data would be immensely valuable.

The catch: these inference-heavy products are expensive to run. Maguire acknowledges the tension. “Once you taste the good model, I can’t go back. I want to use it for everything, which is really expensive.” His thesis is that this is precisely where venture capital makes sense — fund the gap between viral growth and the inevitable decline in inference costs. “Let the VCs bet on the fact that the cost of inference will come down.”

Why apps aren’t going anywhere

Near the end of the conversation, Maguire dismissed two “existential threats” that keep surfacing in industry discourse: that agents will replace apps, and that everyone will just build their own bespoke software.

“One of the classic mistakes in a venture-backed business is you get some company, they’re crushing it, they’re super confident, they’re growing really fast, and then the CEO’s like, ‘I don’t like Salesforce. We’re going to build our own CRM and it’s going to be better.’ And then it becomes a total boondoggle.”

The same logic applies to consumers building their own tools. It’ll happen at the margins — and it’ll compete on price with commercial software — but it won’t eliminate the market for dedicated products built by focused teams.

“People want beautiful visual experiences,” Maguire says. “It’s not only going to be agents talking to each other. People want to interface with something using their eyeballs.” The form factor might evolve, but the demand for taste-driven, purpose-built apps isn’t going away.

In the full episode, Andrew, David, and Jacob also discuss the layered fee structures that erode LP returns in venture, why General Catalyst’s cohort-based UA financing model is interesting for mid-stage apps, and Andrew’s experiment building self-improving CRM tools with AI agents.

Guest links

Andrew Maguire on LinkedIn

Andrew Maguire on X

Volo Ventures

What if you could reach churned subscribers via email, the moment their access expires? And what if the re-subscription happened on the web, where you keep more of the revenue?

That’s what win-back campaigns for web does. It’s now in public beta.

2 settings, 60 seconds, done

You configure a campaign in the RevenueCat dashboard in about 60 seconds. There are two settings: pick the app you want to monitor for subscription expirations, and choose a Web Purchase Link with your win-back offer. That’s it.

When a subscriber’s access expires (not when they cancel, but when they actually lose access), RevenueCat sends them a transactional email with a “Claim offer” button. That button takes them to your web checkout, where they re-subscribe at whatever discounted price you’ve configured. For example, a first year at $39.99 instead of $99.99 that auto-renews at the standard price.

The trigger fires only on genuine end-user churn. If you revoke access or cancel a subscription from your side, no email gets sent.

The email is branded to your app. It pulls in your app icon, name, and appearance settings automatically. The template includes a clear “Claim offer” call to action linking to your Web Purchase Link. You don’t need to design, write, or host anything. In the current beta, the template uses a standard layout and English copy. Email customization is on the roadmap.

Reach users that native offers can’t

Native win-back offers from Apple and Google are powerful, but they rely on the user returning to the App Store, opening your app, or checking their subscription settings. They’re passive. Your offer sits there and waits.

Win-back campaigns reach out at the exact moment access expires, via email, regardless of whether the user still has your app installed or what platform they originally subscribed on. A churned iOS subscriber, an Android subscriber, or a web subscriber all get the same email.

And because the re-subscription happens on the web, you bypass the 15%–30% platform commission entirely. You can offer a generous discount and still improve your effective revenue per recovered subscriber. It’s money from users who would have otherwise left completely.

If you already have Apple or Google win-back offers configured, this works alongside them. More places for a churned user to resubscribe is a good thing.

Send them anywhere: paywall or checkout

The “Claim offer” link points to the Web Purchase Link you’ve configured. Depending on how you’ve set that up, the user can land on a paywall, a package selection screen, or go directly to checkout. You control the experience.

You can pair this with Flexible Discounts to create the right offer: introductory pricing on a yearly plan, percentage-off codes, or whatever makes sense for your audience.

Their account picks up where it left off

The email link includes the user’s existing app ID. When they complete checkout on the web, their premium access is restored inside your mobile app immediately. The purchase shows up in their existing customer history, attributed to the same user, with the same entitlements.

One campaign covers iOS, Android, and web

Win-back campaigns work with all three of RevenueCat’s supported web billing engines: RevenueCat Billing, Stripe Billing, and Paddle Billing.

The app you monitor for expirations can be iOS, Android, or web. This means the feature supports both app-to-web (a mobile subscriber churns and re-subscribes on web) and web-to-web (a web subscriber churns and re-subscribes on web) flows.

What you need before creating a campaign

Win-back campaigns build on top of RevenueCat Web. Before you create one, you’ll need:

• A web configuration. Connect a billing engine (RevenueCat Billing, Stripe Billing, or Paddle Billing) by following Getting started with RevenueCat Web.
• A Web Purchase Link with your win-back offer. Create an offering with a discounted product (like a yearly plan with an introductory price), then create a Web Purchase Link for it. This is what the email links to.
• Your customers’ email addresses. RevenueCat sends the win-back email to the address stored in the $email subscriber attribute. If your app already collects email during signup or onboarding, you’re set. If not, you’ll need to start setting it via the SDK.

Getting started

Once those are in place, creating a campaign takes seconds:

1. Go to Lifecycle → Win-back in your RevenueCat dashboard
2. Click Create campaign
3. Select the app to monitor for subscription expirations
4. Select the Web Purchase Link containing your win-back offer
5. Click Create campaign

The campaign starts monitoring immediately.

Set up your first win-back campaign →

Shipaton is back. This August and September, we’re inviting builders from all corners of the globe to ship brand-new apps and compete for a share of over $1 million worth of prizes.

There’s a lot to cover, so here’s the TLDR:

• Ship a new app in August or September, and you could win part of over $1 million worth of prizes
• New categories, including a brand-new student category
• ShipKit is back with tons of discounts and deals for participants
• Twice-a-week livestreams with expert guests and live Q&A
• Shipaton IRL in-person events are back, all over the world
• Register right now at shipaton.com

Alright, let’s dig into the details.

The challenge

Your challenge is simple:

• Ship a brand-new iOS or Android app to the App Store, Google Play Store, or — new this year — the Samsung Galaxy Store, between August 1st and September 30th
• Use the RevenueCat SDK to power at least one in-app purchase, or serve ads through RevenueCat Ads

That means a real app. In a real store. Released for the first time during the Shipaton window. Your app can be something you just started working on, or something you’ve been working on for a longer time but just haven’t shipped yet.

You can start brainstorming, building, posting, and getting people excited before August 1st. But to be eligible, your app has to be released no earlier than August 1st and no later than September 30th. We recommend shipping your 1.0 as quickly as possible to get through App Review, then pushing updates from there.

Bigger than ever

Last year, you completely blew us away. Close to a thousand new apps launched. Thousands of #BuildInPublic in TikTok and other social media. Communities all over the world hosted Shipaton IRL events. And winning teams ended up in New York, accepting their Shippy trophies on stage, with their apps lighting up a giant billboard in Times Square.

Naturally, we took that to mean that Shipaton 2026 needs to be even bigger. Here’s what’s on the line:

• Over $700,000 in cash to date, and that number may grow as more sponsors join the fun
• Winning apps featured on giant billboards in Times Square
• Flights to New York City for the Shippies red carpet award ceremony (that’s right, our own award ceremony for people who ship great apps) and RevenueCat’s exclusive App Growth Annual conference
• Press coverage for winners on 9to5Mac and 9to5Google
• Investor exposure through the brand-new Shipaton Growth Fund

And there are even more prizes we’re still finalizing — we’ll announce those soon.

New award categories

This year’s lineup of award categories celebrates all the different ways to build a great app. Many you’ll recognize from previous Shipatons, but there are some big new additions.

Grand Prize: Build & Grow Award

The big one. This award honors the app that gains the most user traction and growth momentum during the event. We want to hear what you’ve done post-release to push your app’s growth to the next level.

[NEW] Next Gen Award (students, this one’s for you)

A brand-new category exclusively for students, designed to remove one of the biggest blockers for new builders: you don’t need a paid Apple or Google developer account to participate.

If you’re an active student, you can submit a video of your app plus your open-source code, and we’ll use that to validate your submission. High school, college, university, bootcamp, campus dev club, or another academic program: Shipaton is for you too. Learn more on the Next Gen page.

And if you’re a student organizer, teacher, professor, or part of a developer club, this is the perfect excuse to bring Shipaton to your campus. More on that below.

[NEW] Catvertising Award

Celebrates the most creative and effective use of RevenueCat Ads as a monetization method. We’re looking for clever placements, smart integration with the rest of your revenue stack, and an experience users don’t hate.

[NEW] Best Game Award

Shipaton 2026 welcomes a whole new category of developers: This award goes to the best mobile game shipped during Shipaton. We’re looking for great gameplay, art direction, and a monetization fit that suits the genre.

#BuildInPublic Award

For developers who share the most interesting parts of their development journey on social media. We’re looking for compelling lessons learned or ideas incorporated from community feedback.

HAMM Award (Help Apps Make Money)

RevenueCat exists to help apps make more money. This award goes to the project with the most robust and creative monetization strategy.

RevenueCat Design Award

For the app that best represents the craft of app development, separate from its viability as a business. We’re looking for innovative ideas and/or beautiful design and animations.

RevenueCat Peace Prize

Awarded to the project that provides the greatest social good. We’re looking for apps with big benefits to communities or society at large.

On top of all that, our category sponsors will have dedicated award categories too. More details coming soon. Check the DevPost page for full judging criteria.

Supported by the industry

This year, our sponsors have shown up big. Huge thanks to Replit, OneSignal, JetBrains, Layers, Noise, Stripe, and Samsung for coming in as category sponsors for Shipaton 2026.

We’ll share more about their categories soon, but for now, just know they’re helping us make this year’s Shipaton bigger, weirder, and more rewarding for builders. And more sponsors are joining all the time — which means bigger cash prizes and more additions to the ShipKit.

ShipKit is back

ShipKit is your bundle of tools, credits, deals, and resources to help you build faster, launch better, and hopefully save a lot of money along the way.

Some of those deals are while supplies last, so the sooner you register on DevPost, the sooner you get access as ShipKit starts to roll out.

New this year: the #ShipatonSale

If you have an app, tool, service, course, template, or anything else that could help Shipaton builders, you can run a sale for participants. Share it using the #ShipatonSale hashtag, and submit it to the Shipaton website, where we’ll list sales being run by tools and services in the community.

So even if you’re not competing, there are still ways to support the builders who are, and get your apps in front of thousands of people.

Built on community

Shipaton’s success has always come back to the community. It’s more fun when everyone can see each other building, learning, getting stuck, getting unstuck, and cheering each other on. Even with lots of prizes on the line, you’ve always supported and encouraged each other along the way, and we do our best to support that:

• The #BuildInPublic award rewards sharing your building journey online — an amazing way to motivate yourself and inspire others
• The Shipaton Discord is open again for discussion, questions, feedback, finding teammates, and getting help from the RevenueCat team
• The #post-engagement-boost channel lets you share your #BuildInPublic posts and boost each other’s work so more people see what you’re building

Twice-a-week livestreams

Throughout the event, we’ll host livestreams twice a week where you can learn new skills for building, launching, and growing mobile apps. Expert guests, practical sessions, and live Q&A. So you’re not building alone for two months. You’ll have a steady stream of lessons and live support to keep you moving.

Shipaton IRL: events near you

The Shipaton community isn’t only online. Last year, builders and community organizers hosted Shipaton IRL events — meetups, co-working sessions, and launch parties — in cities all over the world. This year, we want even more of that.

Check out shipaton.com/events to find a Shipaton IRL event near you, or apply to host one yourself. Approved hosts get a Meetup-in-a-box with Shipaton swag, food vouchers, and organizer resources, and we’ll promote your event to the massive Shipaton audience.

These are perfect for new or existing developer communities, hacker clubs, and student organizers planning campus events.

Ready, set, ship!

Here’s what to do right now: go to shipaton.com, click through to DevPost, and register. That’s where we’ll share the latest news, full rules, category updates, sponsor announcements, and ShipKit access as soon as it’s ready.

Shipaton is the perfect motivator to finally build that app idea you’ve had in your brain forever or to ship something totally new, now that app development (with a little help from AI tools) is more accessible than it’s ever been.

We can’t wait to see what you build. Let’s get shipping.

Not Boring Software didn’t start with a market opportunity or a gap analysis. It started with the conceptual artist John Baldessari.

Baldessari spent the first half of his life as a self-described “mediocre landscape painter.” Just before turning 40, he took his entire body of work — decades of paintings — and burned it all. Then he wrote “I will not make any more boring art” thousands of times on camera, in a kind of performance art ritual. He went on to become one of the most influential artists of his generation.

Watch on YouTube

Andy Allen found Baldessari at almost exactly the same point in his own career. He was approaching 40, had spent the prior few years living in Amplitude dashboards at WeTransfer (which had acquired his previous company, FiftyThree), and felt himself slipping into the kind of B2B product work that was fashionable but soul-deadening.

“I felt like sometimes there’s just like good very simple heuristics,” Allen says. “If you can just say, ‘I will not make any more boring software,’ that might lead to some good outcomes.”

The timing was deliberately uncool. In 2020, nobody was starting an app business. Everyone was chasing SaaS. “It’s so funny because I just found that oftentimes the things that I’ve done that have had the most staying power or resonated the most have often been these very uncool things,” Allen says. “Whenever you try to do something cool or of the moment, it just doesn’t really go anywhere or it flubs.”

The patron plan that shouldn’t have worked

Not Boring launched with three apps — Weather, Calculator, and Timer — available individually or as a collection via subscription. For Weather, the subscription pitch was straightforward: premium data sources. For Calculator and Timer, what you were unlocking was… skins. Different visual themes. Alternative app icons.

Conventional wisdom says this shouldn’t work. People don’t pay for aesthetics in utility software. But Allen and his co-founder added something else: a “patron plan” priced at five times the standard tier. It included essentially nothing extra — a physical gift, and the knowledge that you were funding the studio’s work.

“It was shocking how many people went for that plan,” Allen says. “And that was kind of the moment that we realized, oh yeah, this is a little bit of a different business model. We’re not selling features here. People want to see this work and see us maybe as the knights fighting this battle against boring software and they want to fund this effort.”

The model has compounded over five years. Early subscribers got their price locked in permanently. Every new app (one per year) is automatically included. The incentive structure pushes Allen toward making new, interesting things rather than grinding on feature parity with competitors. “We’re not trying to chase features that are going to unlock some new audience for us or that we think are going to suddenly bump up our conversion rates,” he says.

Why every Not Boring app ships as a “complete” product

Allen’s previous company, FiftyThree, made Paper — the drawing app that became one of the first native-feeling iPad apps and eventually sold to WeTransfer. That experience taught him what happens when you raise VC money for a product that’s a great small business but not a billion-dollar outcome: you get trapped.

“The biggest fear was getting trapped in a business that you didn’t want to run,” Allen says. “And I see that happen with so many founders.”

The structural solution at Not Boring is radical simplicity. Each app ships as a complete product. No V3. No feature bloat. No chatbot in the corner. “I prefer to say like, ‘This is the calculator that we made.’ It’s complete and it does its job really well. We’re not going to change it on you.”

This creates a forcing function: if you can’t go back and iterate on old apps, you have to make new ones. And making new things — re-envisioning old software categories through a design-first lens — is the work Allen actually wants to do. The constraint is the point.

A dozen sound files for one button

The Not Boring apps feel like video games. Everything runs in Apple’s 3D engine (SceneKit), with low-poly models inspired more by the PS1 era than photorealism. But the detail that most people notice first is the sound.

Allen plays sounds even when the iPhone’s mute switch is on — something that would get most apps destroyed in reviews. It works here because the sound is the experience. But the real trick is subtler: every button tap doesn’t play one sound file. It plays one of a dozen slightly different versions of the same click.

“No button ever sounds exactly the same,” Allen explains. “Why does it sound so great to listen to someone typing on an old clickety-clackety keyboard? It’s because of all the variation. When you hit a physical button, it hits differently every time.”

This is a technique borrowed directly from game audio, where footsteps and punches need to repeat without becoming grating. Allen published the technique — along with free sound kits — hoping other developers would adopt it. “It doesn’t take much, honestly. It just takes working with a sound designer,” he says. “It’s a great way to amplify your experience that really doesn’t add much overhead or complexity to the app itself.”

3 years to build a camera that launches faster than the competition

Not Boring Camera took three years of false starts before shipping. The team explored 3D photography, spatial photos, and various experimental directions before arriving at a simpler insight: don’t reinvent what a camera does — reinvent what it feels like to use one.

Every control in the camera app is modeled in 3D. Dials turn. Sliders have physical weight. Buttons tilt based on where you press them. The preview isn’t full-screen — it’s inset, like looking through a viewfinder. And despite running in a game engine, the app launches faster than every third-party camera app Allen has tested.

But the real philosophical bet is on the image pipeline. Not Boring Camera strips out all of Apple’s computational photography — the multi-frame composites, noise reduction, and HDR tone mapping — and works directly with raw sensor data. Allen calls it “Super Raw” (a nod to Apple’s “ProRAW,” which he argues is still heavily processed).

“The default camera apps — it’s not just Apple, it’s Google, it’s everyone — their goal is to make sure that you never take a bad photo,” Allen says. “But I think the result is that you never can really take a great one.”

The app applies film-inspired LUTs in real time, lets you edit raw exposure and temperature before shooting, and embraces grain and blur as creative choices rather than flaws. “Some of my favorite photos from our app are accidents,” Allen says. “It’s like I accidentally hit the shutter button as I was putting it away so it’s like this really cool blur. I miss some of that and I think we’re trying to bring some of that back.”

In the full episode, Andy also talks about designing the never-shipped Microsoft Courier tablet, why the early Macintosh shaped his view of computers as creative tools, and his recommendations for checking out the artist John Baldessari and musician Brian Eno as models for creative thinking.

Guest links

Andy Allen on X/Twitter

Not Boring Software

Not Boring Camera on the App Store

This is not a coincidence, and it is not anyone’s fault.

For as long as apps have been a business, the advice has been consistent: look at what is already working. Find the apps that are converting, understand why, get inspired by the patterns that have been proven. This is genuinely good advice. It is how most successful products got to where they are. Learning from what works is faster, cheaper, and less risky than starting entirely from scratch. I have followed this advice myself, and I have given it to others.

But something happens when an entire industry follows the same advice all the time. The patterns converge. The quiz-style onboarding. The projection graph that dramatically reveals your results, then changes four times as you progress through the funnel promising you that dream weight goal achieved by your next holiday. The interrupting pop-ups on pre-paywall loaders. The three-tier paywall with the annual plan highlighted and the countdown timer. The CTA copy that has been A/B tested into the least interesting version of itself. These things work, until everyone is doing them, and then they stop being an advantage. They become the baseline.

This is what “get inspired by competitors” looks like when the ‘iterate’ step gets skipped. Getting inspired is fine. Leaving it there is not. When users compare apps, they notice. Please have some ethics heart.

And this pattern goes deeper than a single screen. Look at what happened with the personalized weight-loss graph. Noom built it: a projected weight loss curve tied to a personal date, a specific goal, even a life occasion. “And reach your goal by the vacation.” It was a genuinely good idea that worked.

The copies came quickly. Almost everyone who tested it saw an uplift. The headline – “the last plan you’ll ever need” – spread across the category until almost every app in weight loss was apparently offering the definitive final solution to the human condition millions have still not solved. Most of the copies stopped there.

But one app went further. It kept the projection concept, then added intermediate weight milestones along the curve so the user could see the journey in stages, not just the destination. They did it because they knew their product well, they knew the result looked like ‘steps’ with short ‘walls’ – their users told them that in these same words. Then they placed social proof from those real users directly below the graph, at the exact moment the user might feel sceptical about whether the prediction is real. That is iteration. Same starting point, genuinely different idea, serving the user better at a specific moment of doubt. This is what I call ‘heart’.

I have worked with a number of B2C apps across health, wellness, and productivity. I have seen a lot of funnels from the inside. And what I notice more and more is that the challenge has quietly shifted. Building a well-structured app, with a clean onboarding flow and a tested paywall, is no longer what separates the apps that grow from the ones that do not. There are companies out there who have onboarding funnel constructors with proven screens, sections, even CTAs. The framework is defined – nothing to invent there.

The real question now

The harder question now is: once you have paid to get someone’s attention, what makes them remember you, choose you and stay with you?

Building has never been easier. Getting memorable has never been harder. That gap is where the real work happens now.

I want to be upfront about something before we go further. This is not a case against learning from competitors. I have spent years advising apps to do exactly that, across more than twenty products I have worked with as a consultant in the past few years. Look at what is working, understand why, adapt it for your context, move fast. I still give that advice. It is the right starting point.

But there is a step that routinely gets skipped. The “iterate quickly” part, the part where you take what you have learned and make it genuinely yours, tends to get dropped in favour of just shipping. And I understand why. You need momentum. You need to see if the model works before you invest in making it feel like something. That is reasonable.

The problem is that “making it yours” never comes after, because there is always another thing to ship. And so the app stays at the “inspired by competitors” stage indefinitely.

What I am arguing here is that making it yours is not a polishing step – it is the thing that determines whether users stay. And it has two sides, read on.

The first is internal: it has to come from what you actually believe about the problem you are solving. Why did you build this product? What did you see that others were missing? What do you genuinely think users need? That conviction, when it comes through in the product, is what makes an app feel like it was made with care rather than assembled from a template. It’s usually the gut feeling you already have but might be too worried about testing – you have my permission to go ahead and test it out – those things usually work in a surprising way.

The second is external: it has to speak to the user in their own words. Not your words about them. Their words about themselves. User research, interviews, even reading App Store reviews in your category give you the vocabulary your users actually use to describe their own problems. When that vocabulary shows up in your onboarding, in your push notifications, in your emails, users feel understood in a way they cannot quite name but definitely feel.

The practical starting point is user research: interviews, App Store reviews in your category, even the language people use on Reddit threads about their problem, tweets [see above]. That vocabulary, the words real users use to describe their own situation, is what your onboarding questions should be built from. When it comes from genuine understanding of the user rather than internal product language, users feel it. They cannot always name why an onboarding feels right. but they vote with their wallet.

That combination, believing in what you are building and speaking the user’s language, is what I mean by heart throughout this article. It is specific, and it is learnable.

The shift we’re entering: from careful to alive

Building an app used to be slow and expensive. You validated carefully, prioritized ruthlessly, shipped incrementally. RICE scores ruled the roadmap. Anything that was hard to measure (delight, tone of voice, a moment of surprise) got cut. Did not score well enough. None of the competitors have that screen. Next.

AI-assisted development, simplified releases you control on the back-end and tools that have recently emerged have dramatically reduced the cost of building and iterating. No-code tools are genuinely capable. A solo founder or an IC Growth operator can ship new concepts in days. This is exciting.

Here is the catch: distribution is harder than it has ever been.

The number of new subscription apps launching monthly has exploded: from roughly 2,000 per month in early 2022 to over 14,700 by early 2026, according to RevenueCat’s 2026 State of Subscription Apps report. App Store search is more competitive. User acquisition costs always keep climbing. Organic growth is rare and unreliable.

And many of these apps, built from the same templates and UX patterns AI picked up from apps that copied each other, end up feeling identical. AI picked the design. AI picks it for everyone. [funny story – when writing this article I gave Claude the two discharge screenshots from earlier and it immediately identified ‘the original’ and cited a pattern of what got copied and why].

The missing piece: heart alone doesn’t scale

There is a tempting counter-move, and I have seen it play out. The response to “everything feels the same” is to swing the other direction entirely: build from the heart. Make it personal. Build the app you would want to use. Obsess over the details.

This is not wrong. I am a firm believer in it, and genuinely happy we are living in a moment where building from a real place is possible again, without the six-month approval process killing the idea before it ships.

But heart alone does not get you anywhere if no one finds you. And if the people who do find you cannot figure out how to subscribe.

The apps that win in this environment need three things working at the same time:

• Something that resonates: a specific user, a real problem, messaging that lands
• Distribution: a well-tuned paid acquisition engine, a product loop that earns organic growth, or both
• A system to convert and monetize: an onboarding flow, a paywall, a pricing strategy that translates attention into revenue

Pick one and you are halfway there. Pick all three and you are dangerous.

In this article, you’ll explore what Billing Choice changes about the purchase flow, the four integration scenarios that fall out of two independent decisions, the BillingProgram API surface for enabling the program and checking its availability, how each scenario launches its purchase, the external transaction token that ties every alternative sale to a server side report, how subscription upgrades and downgrades behave, and the UX rules that keep the choice screen fair.

What Billing Choice actually changes

Google describes the program plainly: the billing choice program lets you integrate your own billing system or guide users to your website for purchases using external web links. Whichever option you implement, the user must still be offered a choice between Google Play Billing and your alternative.

That last clause is the heart of it. Billing Choice is not “alternative billing instead of Google Play.” It is “alternative billing alongside Google Play, with the user deciding.” Google Play Billing never disappears from the screen. Your job is to present a fair choice and then honor whichever side the user taps.

The program is exposed through a BillingProgram enum, and the value you work with is BillingProgram.BILLING_CHOICE. You pass that value into nearly every Billing Choice call, which signals the shape of the API: alternative billing is configured as a named program you opt into, not a single global switch.

Two independent decisions define how your integration looks:

• Who renders the choice screen: Google can draw it for you (ChoiceScreenType.GOOGLE_RENDERED), or you can draw your own (ChoiceScreenType.DEVELOPER_RENDERED) as long as you follow the UX guidelines.
• Where the payment happens: the user pays inside your app through your own billing system (DeveloperBillingType.IN_APP), or you send them to your website through an external web link (DeveloperBillingType.EXTERNAL_LINK).

The DeveloperBillingType matters beyond the user experience. It is recorded inside the transaction token you generate, so Google knows whether a given alternative sale was an in app transaction or an external link transaction when it assesses the service fee.

The four integration scenarios

Those two decisions combine into the four scenarios that organize the entire integration. Everything else in this guide is a variation on one of these four rows.

Notice the pattern. The “1” versus “2” axis is about where money is collected. The “A” versus “B” axis is about who renders the screen. When Google renders the choice screen (the A scenarios), Google needs a way to tell you the user picked your option, so you register a listener up front. When you render the choice screen (the B scenarios), you already know what the user tapped, so instead of a listener you fetch the assets you need to draw a fair screen and generate the reporting token yourself.

Prerequisites: library version, enrollment, and Play Console

Before any code compiles against this API, three things need to be in place.

First, the library. Billing Choice requires Play Billing Library version 9.1 or higher. This is separate from the broader migration deadline you may already be tracking: by August 31, 2026, every new app and every update to an existing app must build against Billing Library 8 or later, with an extension available on request until November 1, 2026. That deadline is about version 8 as a floor for the whole ecosystem. Billing Choice sits well above it at 9.1, so adopting the program puts you well past that floor.

Second, enrollment. You must enroll in the program and review its requirements before calling the APIs. If you intend to offer external web links, you also declare that preference in Play Console before you ship the integration.

Third, Play Console configuration. You set your choice screen preference (whether Google renders it or you do) and your external web links preference in the Console. You can also upload an image asset that represents the payment methods your own billing option accepts, to be shown on the choice screen. That asset follows strict specifications:

Enabling the billing program

You turn on Billing Choice when you build the BillingClient. The new piece is enableBillingProgram(), which takes an EnableBillingProgramParams configured with BillingProgram.BILLING_CHOICE.

The following setup is for a scenario where Google renders the choice screen:

val params = EnableBillingProgramParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .setDeveloperProvidedBillingListener(developerProvidedBillingListener)
    .build()

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(pendingPurchasesParams)
    .enableBillingProgram(params)
    .build()

The important detail is setDeveloperProvidedBillingListener(). You register this listener only when Google renders the choice screen, because Google needs a callback to reach when the user picks your billing option rather than Play’s. The purchasesUpdatedListener you already know that standard Billing handles the case where the user picks Google Play. The two listeners sit in different places, the familiar PurchasesUpdatedListener on the client and the DeveloperProvidedBillingListener inside EnableBillingProgramParams, but together they cover the two outcomes of the choice screen.

When you render your own choice screen, you omit the DeveloperProvidedBillingListener entirely. You build the same EnableBillingProgramParams with BillingProgram.BILLING_CHOICE, but without setDeveloperProvidedBillingListener(), because you handle the user’s tap yourself and never need Google to call back into your app.

Checking availability and reading the choice configuration

Billing Choice is not guaranteed to be available for a given user, device, or region, and the configuration you set in Play Console is delivered to your app at runtime. You check both with isBillingProgramAvailable(). The Kotlin form is a suspend function that returns the result alongside an availability details object:

val (billingResult, availabilityDetails) =
    billingClient.isBillingProgramAvailable(BillingProgram.BILLING_CHOICE)

val choiceDetails = availabilityDetails.billingChoiceAvailabilityDetails
if (billingResult.responseCode == BillingResponseCode.OK && choiceDetails != null) {
    val screenType = choiceDetails.choiceScreenType
    val externalLinkSupported = choiceDetails.isExternalLinkAvailable
    \/\/ Branch your integration on these two values.
}

The BillingChoiceAvailabilityDetails object answers the two questions that decide which scenario you are in. The choiceScreenType property is either ChoiceScreenType.GOOGLE_RENDERED or ChoiceScreenType.DEVELOPER_RENDERED, telling you who is responsible for rendering the screen. The isExternalLinkAvailable property tells you whether external web links are enabled for this user. A robust integration reads both values and falls back to standard Google Play Billing whenever Billing Choice is unavailable, rather than assuming the program is always on.

For callback-style code, there is also isBillingProgramAvailableAsync(), which delivers the same BillingResult and availability details to a listener instead of suspending.

Scenario 1A: Google renders the choice, payment happens in app

This is the lightest scenario to integrate, because Google does most of the work. You enable the program with a DeveloperProvidedBillingListener, confirm availability shows GOOGLE_RENDERED, and then launch the flow with a developer billing option attached:

val developerBillingOptionParams = DeveloperBillingOptionParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .build()

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(productDetailsParamsList)
    .enableDeveloperBillingOption(developerBillingOptionParams)
    .build()

billingClient.launchBillingFlow(activity, billingFlowParams)

The call to enableDeveloperBillingOption() is what tells Google to show the choice screen instead of going straight to Play’s payment sheet. From here the flow splits down two paths depending on what the user taps:

• The user picks Google Play Billing. The purchase completes through Google, and your existing PurchasesUpdatedListener receives the result exactly as it would without Billing Choice.
• The user picks your billing option. Google invokes the DeveloperProvidedBillingListener you registered and hands you a DeveloperProvidedBillingDetails object that carries an externalTransactionToken. That token is your receipt to take payment through your own system and later report the sale.

The split is the whole point. One code path keeps the familiar Google Play purchase, and the other hands control to you with a token already minted. You did not have to draw a screen or generate the token yourself, because in this scenario Google did both.

Scenario 1B: You render the choice, payment happens in app

When you render the choice screen, you trade convenience for control. You no longer register a DeveloperProvidedBillingListener, because there is no Google screen to call you back from. Instead, you gather the pieces you need to draw a screen that treats Google Play fairly, then mint your own token when the user chooses you.

The first piece is the Google Play side of the screen. You ask Billing for the image and loyalty message to display for the Play option with getBillingChoiceInfo():

val params = GetBillingChoiceInfoParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .setPlayBillingChoiceImageLayout(GetBillingChoiceInfoParams.ImageLayout.RECTANGULAR_FOUR_BY_ONE)
    .build()

val (billingResult, info) = billingClient.getBillingChoiceInfo(params)
if (billingResult.responseCode == BillingResponseCode.OK && info != null) {
    val imageUrl = info.playBillingChoiceImageUrl
    val loyaltyMessage = info.playBillingLoyaltyInfo
    \/\/ Render these into your own choice screen.
}

The playBillingChoiceImageUrl is the payment method artwork for Google Play, and playBillingLoyaltyInfo is any loyalty message Google wants shown beside its option, such as a Play Points rewards message. You must load these every time you draw the screen rather than caching them, a requirement covered in the UX section below. For callback style code there is also getBillingChoiceInfoAsync(), which delivers the same PlayBillingChoiceInfo to a listener, and that is the form the UX guidelines reference.

Once the user taps your option, you generate a reporting token with createBillingProgramReportingDetails(), declaring the billing type as in-app:

val params = BillingProgramReportingDetailsParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .setDeveloperBillingType(DeveloperBillingType.IN_APP)
    .build()

val (billingResult, details) =
    billingClient.createBillingProgramReportingDetails(params)
if (billingResult.responseCode != BillingResponseCode.OK) return
val transactionToken = details?.externalTransactionToken

Before you charge the user, you also call showBillingProgramInformationDialog(), which presents the legally required disclosure for transacting outside Google Play Billing. The dialog request carries the BillingProgram and the transaction token you just generated. After the disclosure, you run your own payment flow and keep the externalTransactionToken for the server-side report that follows every alternative sale.

Scenarios 2A and 2B: Sending users to an external web link

The external link scenarios replace your in app payment with a redirect to your website. In both of them you generate the token yourself with createBillingProgramReportingDetails(), declaring DeveloperBillingType.EXTERNAL_LINK instead of IN_APP. This is the one place the A versus B shorthand bends: even in Scenario 2A, where Google renders the choice screen, you mint the token before launching rather than receiving it through the listener, because the token has to travel with the redirect. You should only attempt these scenarios when availability reported isExternalLinkAvailable as true.

In Scenario 2A, Google renders the choice screen, so you still launch through launchBillingFlow(). The difference is that your developer billing option now carries the destination URI, the token you just generated, and a launch mode:

val developerBillingOptionParams = DeveloperBillingOptionParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .setLinkUri(Uri.parse("https:\/\/www.example.com\/external\/purchase"))
    .setExternalTransactionToken(transactionToken)
    .setLaunchMode(DeveloperBillingOptionParams.LaunchMode.LAUNCH_IN_EXTERNAL_BROWSER_OR_APP)
    .build()

You attach this to BillingFlowParams with enableDeveloperBillingOption() and call launchBillingFlow() as before. If the user picks Google Play, the normal purchase happens. If they pick your option, Google opens your link and the token travels with the redirect.

In Scenario 2B, you render the choice screen yourself, so there is no billing flow to launch. You send the user out with a dedicated call, launchExternalLink():

val params = LaunchExternalLinkParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .setLinkUri(yourLinkUri)
    .setLinkType(LaunchExternalLinkParams.LinkType.LINK_TO_DIGITAL_CONTENT_OFFER)
    .setLaunchMode(LaunchExternalLinkParams.LaunchMode.LAUNCH_IN_EXTERNAL_BROWSER_OR_APP)
    .setExternalTransactionToken(transactionToken)
    .build()

billingClient.launchExternalLink(activity, params) { billingResult ->
    if (billingResult.responseCode == BillingResponseCode.OK) {
        \/\/ The user is on the way to your site. Report the sale when it completes.
    }
}

The LinkType.LINK_TO_DIGITAL_CONTENT_OFFER describes what waits on the other side of the link, and the launch mode opens it in an external browser or app. The result callback only confirms that the link launched successfully. It does not tell you the purchase succeeded, because that happens on your website, outside the app. Completing and recording the sale is your responsibility from this point on.

The external transaction token: reporting every alternative sale

Across all four scenarios, the same object keeps appearing: the externalTransactionToken. It is the thread that connects a tap on the choice screen to a line item in your Play revenue report, and understanding it is what separates a working integration from a compliant one.

Every alternative billing transaction, whether it happened in app or through an external link, must be reported back to Google Play. The token is how Google links your report to the original choice. It also encodes the DeveloperBillingType, so Google knows whether to treat the sale as an in app transaction or an external link transaction when it calculates the service fee. Where the token comes from depends on the scenario: in Scenario 1A it arrives through the DeveloperProvidedBillingListener, inside the DeveloperProvidedBillingDetails object, and in the other scenarios you generate it yourself with createBillingProgramReportingDetails().

The report itself is a server side call to the Google Play Developer API, on the externaltransactions resource. After the user pays through your system, your backend calls createexternaltransaction with the token in the request body. The body differs by product type. A one time product uses a oneTimeTransaction wrapper, while a subscription uses a recurringTransaction wrapper that also declares the subscription type:

{
  "recurringTransaction": {
    "externalTransactionToken": "the_token_from_the_client",
    "externalSubscription": { "subscriptionType": "RECURRING" }
  }
}

There is a distinction worth holding onto for subscriptions. The token is required for the first transaction in a recurring purchase, but renewals do not get a fresh token. Instead, you report each renewal against the original sale using initialExternalTransactionId, the identifier of that first transaction. The API also exposes getexternaltransaction to read a transaction back and refundexternaltransaction to report a refund, so the full lifecycle of an alternative sale is mirrored on Google’s side.

The service fee that results from these reports varies by transaction type and by geography, with the European Economic Area called out specifically, and the published rates live in Google’s external offers program documentation rather than in the Billing Library reference. The takeaway for your architecture is that choosing alternative billing does not remove the service fee. It moves the responsibility for declaring each sale onto your own backend.

Subscription upgrades and downgrades

Subscriptions add one more case: what happens when a user who already bought through your billing system upgrades or downgrades their plan. You do not want to show the choice screen again, because the user already made their choice on the original purchase, and Billing Choice preserves it.

You signal this by carrying the original transaction’s identifier into the replacement flow with setOriginalExternalTransactionId() on SubscriptionUpdateParams :

val developerBillingOptionParams = DeveloperBillingOptionParams.newBuilder()
    .setBillingProgram(BillingProgram.BILLING_CHOICE)
    .build()

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(newPlanProductDetailsList)
    .setSubscriptionUpdateParams(
        BillingFlowParams.SubscriptionUpdateParams.newBuilder()
            .setOriginalExternalTransactionId(externalTransactionId)
            .build()
    )
    .enableDeveloperBillingOption(developerBillingOptionParams)
    .build()

billingClient.launchBillingFlow(activity, billingFlowParams)

Because the original choice is preserved, no choice screen appears for the replacement. The user moves directly into the new plan through the billing system they already selected. Two identifiers are in play here, and they are not the same thing. setOriginalExternalTransactionId() runs on the client and names the prior purchase this upgrade replaces, which is what lets Google skip the choice screen. initialExternalTransactionId is a server side reporting field that chains a subscription’s renewals back to its own first transaction. So the new plan is still a new purchase: once the upgrade or downgrade completes, you report it as a new transaction with its own externalTransactionToken, and that transaction then becomes the initialExternalTransactionId its later renewals reference.

Designing a fair choice screen

When you render your own choice screen (the B scenarios), the UX guidelines stop being advice and become requirements you agreed to by declaring DEVELOPER_RENDERED in Play Console. The single principle behind every rule is that the user must be able to compare the two options fairly, with no thumb on the scale toward your billing system.

The concrete requirements:

• Label who is responsible. Each option must clearly identify the authorized entity, app name, or developer name, so the user understands who fulfills the purchase and handles support.
• Show the right icons. Display the Google Play icon in full color against a neutral light or dark background per Google’s brand guidelines, and display only your own app icon or brand logo for your option. You may not dress your option in Google’s branding.
• Fetch payment method logos live. Use the assets from getBillingChoiceInfoAsync() to show Google Play’s payment methods, and treat your own payment methods the same way. You must fetch and display these each time and never cache or alter them. If you cannot determine your own payment methods, you may omit them, but you must still show Google Play’s.
• Keep the buttons equal and close. Button sizes, text size, font style, contrast, tap targets, and in-button logo sizing should be equivalent, and the two buttons must sit in close proximity so the user can compare them side by side.
• Use equivalent calls to action. The primary button labels must be equivalent and consistent, for example “Pay with Google Play” next to “Pay with [your service].” You may present differentiated offers, but if you do, Google Play’s loyalty benefits must be shown in an equivalent manner.
• Treat loyalty equally. If you display loyalty information, show it for both options with equal treatment, and pull Google Play’s loyalty message from getBillingChoiceInfoAsync() each time without caching it.
• Disclose the redirect. If your option sends the user to a website, you must clearly and prominently inform them they are leaving the app, with explicit wording such as “You’ll be redirected to a web page.”

A nuance to note: the guidelines phrase the broad visual equality clause with “should,” while proximity, equivalent calls to action, in button logo sizing, and the no caching rules use “must.” When you are uncertain whether something is mandatory, the safe reading is to treat the equality requirements as binding, because the program’s entire purpose is to avoid nudging users away from Google Play Billing.

Supervised users and parental controls

One behavior is handled for you. For supervised users, Google Play automatically displays the appropriate parental control screen during the Billing Choice flow. The integration notes call this out for each of the four scenarios, so expect it whether Google renders the choice screen or you do. You do not build or trigger it yourself, so it is worth knowing the extra screen exists before it surprises you during testing with a supervised account.

What this means for your monetization

Stepping back from the API, Billing Choice is a trade. Google Play Billing handed you a great deal of infrastructure for its fee: payment processing, tax handling, receipts, refunds, renewals, fraud protection, and the entire reporting pipeline. Billing Choice lets you take some of that back, but only by taking on the work that came with it.

When a user picks your option, you own the payment processing, the fulfillment, the customer support, the refunds, and the server side reporting that keeps you compliant. The service fee does not vanish, it is assessed from the transactions you report through the externaltransactions API. And Google Play Billing remains on the screen as a first-class choice for every user, every time, which means your alternative has to earn its selection rather than being the only door.

That framing helps decide which scenario fits. If you mainly want to reduce friction without standing up a payment stack, the Google rendered scenarios (1A and 2A) carry the least integration burden, because Google draws the screen and mints the token. If you already run billing infrastructure on the web and want to route users there, an external link scenario (2A or 2B) reuses what you have. The fully developer rendered, in app scenario (1B) gives you the most control over the experience and demands the most from you in return: a compliant choice screen, your own payment flow, the disclosure dialog, and the reporting backend, all built and maintained by your team.

Conclusion

In this article, you’ve explored how Billing Choice reshapes the Android purchase flow into a fair choice between Google Play Billing and your own alternative. You saw the two decisions that produce the four integration scenarios, the BillingProgram API for enabling the program and reading its availability, how each scenario launches its purchase, the external transaction token that ties every alternative sale to a createexternaltransaction report, how subscription replacements preserve the user’s original choice, and the UX rules that govern a screen you render yourself.

Understanding these internals helps you make the decision Billing Choice actually asks of you, which is not “should I use alternative billing” but “which of the four scenarios matches what my team can build and operate.” The token flow, the reporting obligation, and the fairness requirements are the real cost of admission, and seeing them clearly up front is what prevents an integration that works in a demo but falls out of compliance in production.

Whether you are adding a single external link to an existing web checkout, building a full in app billing system behind your own choice screen, or simply letting Google render the choice while you collect payment, this foundation lets you reason about the program as a set of deliberate trade offs rather than a single switch to flip. Choose the scenario that fits, report every sale, and keep the choice honest.

Asking ratings too early is considered manipulation

Apple has started rejecting apps under App Review Guideline 5.6.3, which states:

…Manipulating any element of the App Store customer experience such as charts, search, reviews, or referrals to your app erodes customer trust and is not permitted.

This isn’t a new guideline, but Apple hasn’t previously applied it to onboarding in this way. Prompting for a review early in the onboarding flow was a common, if questionable, tactic. Some apps were collecting thousands of five-star ratings before users had done anything meaningful with the app.

It is not clear if Apple will go through apps that are already in the App Store, but apps using this pattern will get rejected during the review process for new versions of the app. It might also be that Apple was already ignoring ratings that occur during onboarding by comparing the time between install and rating; nullifying the ASO benefits.

What should you do instead?

The first step to fixing this is pretty simple: just remove all the rating and review prompts from your onboarding flows. The second step is more complicated; you should prompt only after the user has meaningfully engaged with your app. Ask for a review when there’s actually something to review. So when exactly?

Apple’s own Human Interface Guidelines say to prompt at “natural and happy moments”: after a user has completed something, achieved something, or had a genuine reason to form an opinion about your app.

That sounds straightforward, but in practice most apps don’t have a systematic way to know when that moment actually is. A user who just opened your app for the first time isn’t there yet. Neither is someone who made it through onboarding but hasn’t done anything meaningful.

Now, if you’re wondering how to do that, you’re in luck. We’ve actually written about it before in this guide for ethically hacking your App Store ratings. In the guide, you learn how to build “a happiness engine” that tracks user engagement with the app, and prompts for a review when you’re most likely to get a positive one. The same guide applies to the Google Play Store as well (although Google is not yet limiting).

Bottom line

Stop asking users to review your app during the onboarding flow. Apple will reject your app if they catch you doing it. Most likely they were already filtering out these ratings, by comparing the interval between app install and time of rating.

Instead prompt users to review the app after they’ve meaningfully engaged with it. Track those engagements and build an engine for prompting for a review when the user has both engaged with your app and is happy with their experience.

• How to hack your app store ratings (ethically)

The data says so, apps love them, and honestly, the data isn’t wrong. Annual subscriptions across all categories perform better in terms of retention according to the State of Subscription Apps (SOSA) 2026 report:

But I think we’ve overcorrected.

Annual subscriptions definitely have their advantages, but I think we are a bit mean to monthly subscriptions. I’m here to stand up for monthly subscriptions, give you the good and bad just like I’ve done for annual subscriptions, weekly subscriptions, and lifetime subscriptions (sorry, monthly subscriptions, I didn’t mean to leave you until last).

It’s not that monthly plans are always better; it’s that there are specific situations where a monthly subscription will serve your app better than an annual one. And most founders never stop to ask which situation they’re actually in.

First, retention and popularity don’t equal revenue

Yes, annual plans retain better. Look at one-year retention across categories, and they win almost everywhere. Nobody is disputing that. In most categories, annual plans are the most popular option. According to SOSA 2026:

Except in the productivity and gaming categories. But retention isn’t the same as revenue.

In most categories, monthly subscriptions generate revenue equal to or exceeding their share of subscriptions. Check out the revenue for monthly subscriptions in productivity:

The productivity category is the clearest example: 76.7% of subscriptions are monthly, but 90.7% of revenue comes from those monthly plans.

That gap exists because monthly subscribers typically pay more on a monthly basis, and while they do churn at higher rates, they’re also more likely to reactivate later on.

Your ARPPU (Average Revenue Per Paying User) over time can actually be higher than you’d expect.

The reason the industry obsesses over annuals is that they create a reliable, predictable number on your dashboard. And that number feels good. But it’s worth asking: is that number telling you the truth?

The uncomfortable truth about annual subscriptions

Here’s something nobody says out loud: annual subscriptions can mask a broken product.

Someone who paid up front might not be using your app. They might regret the purchase. They might be planning to cancel at renewal. They may have stopped opening your app entirely, but your dashboard still shows “active subscriber” for another 9 months.

That’s not retention. That’s delayed churn.

And for early-stage apps, delayed churn is dangerous. It means you’re getting false signals about product-market fit. Your retention metrics look healthy. Your team feels good. And then renewal month arrives, and you discover the cliff you didn’t know was coming.

Monthly subscribers who stay are actively choosing you, every single month. That signal is worth more than an annual commitment made once, under the influence of a good discount and some well-timed push notifications.

So when should you actually offer monthlies?

There are five situations where monthly subscriptions can be your secret weapon.

1. When you are still learning

When someone commits to a quarter or a year, you don’t really know if they’re genuinely happy until renewal time. And if they’re not, you often won’t find out why until months later, by which point their memory has faded, and their feedback turns vague. You end up with things like “I stopped using it as much” or “I just found a better alternative for me.”

With monthly subscriptions, each renewal is an active decision, so users who stay are actively choosing you. Monthly subscriptions create faster feedback loops:

• You see churn patterns in weeks, not months
• When someone leaves, you can ask why while the experience is still fresh
• Users who stay are actively choosing you, giving you a cleaner signal on what’s working

Yes, monthly churn tends to be higher, but that’s the point. You’re trading a vanity metric for something more valuable: speed of learning.

Why not just look at usage patterns? Identify who is or could be at risk? For startups, this can be challenging:

• A data infrastructure takes time and money to set up
• You aren’t always sure what the best predictors of retention are
• You don’t always know yet what normal usage patterns are to identify a drop in usage

Meanwhile, monthly subscribers who stay are genuinely choosing you, repeatedly. That signal is worth more than an annual commitment made once under the influence of a good discount and some great marketing. Think about what you can learn from monthly subscribers:

• Who’s churning? Is it a specific customer segment? A specific acquisition channel?
• When are they churning? Month 1 (onboarding issue), month 2-3 (habit formation), or later (ongoing value).
• What do they say when they leave? You can ask while it’s fresh.

Start with offering monthlies if you are still learning whether you have strong retention and what drives it. It’ll help you learn what drives product-market fit far faster and has an extra benefit for startups where trust is low.

For some brands, offering only monthly (or making it the default) for the first 6-12 months could dramatically accelerate the rate at which you learn what’s working.

2. When trust is low

For startups, you don’t have a huge number of reviews or well-known individuals shouting “use this app” to the world (well, most don’t). So monthly subscriptions can be an easier first step than annual plans as you build trust, refine onboarding, and get sharper at communicating value.

In that context, asking someone to commit to a year upfront is a big ask. Monthly plans lower the barrier significantly.

Even with a free trial, I consistently see users default to monthly first — particularly in categories where “will I actually use this?” is a real question, like productivity, health and fitness, and education. They try it, and if it sticks, they upgrade to an annual later.

This is also worth thinking about for web-to-app flows.

When a user hasn’t seen your app yet — they’ve come through a web landing page, they don’t know the product — the commitment ask is even higher. App stores provide a layer of trust: standardized billing, the familiarity of Apple or Google Pay, and that quick double-click checkout. On the web, that safety net is thinner. In that context, a monthly subscription becomes an easier first step.

There’s another benefit here, too: more conversions means more data. More signals to test and optimize your funnel with. Every monthly subscriber who converts is a learning opportunity that an unconverted annual prospect simply doesn’t give you.

3. When your users prefer it

Not every user wants to pay for a year upfront. For some, it’s a financial preference. For others, it’s cultural.

In MEA and Asia-Pacific, monthly plans are notably more popular than in Western markets.

The preference for pay-as-you-go and digital wallet payments makes monthly subscriptions a more natural fit. And it’s not necessarily about price sensitivity, it’s about how people prefer to manage money in those regions.

Geography isn’t the only factor that comes into play. Certain generations prefer shorter subscriptions. We saw this with weekly subscriptions. Gen Z seems to prefer them due to a higher commitment phobia (my favorite thing about this research was that it was done by Tinder… ironic for a dating app). So, certain generations may also be more comfortable with a monthly subscription than with an annual one. It seems Gen Z and younger millennials (under 34) value shorter subscriptions with greater flexibility, while older generations tend to prefer annual subscriptions for stability and discounts.

If your audience skews younger or you’re building for emerging markets, defaulting to annual may actually be suppressing your conversion rate.

4. When your use case suits it

We all love the idea of users using our apps forever and forever, but sometimes it isn’t needed.

Take therapy, when I used BetterHelp, a therapy platform, I never for a second considered an annual subscription. Costs aside, I hoped I wouldn’t need it for a full year, and that proved true. After 3-4 months, I stopped using the platform, happily churning.

Another great example is Hinge, the dating app, which literally advertises that they are designed for short-term usage:

You need to think about your users’ expected use case, and whilst you can extend it or grow with them, for some users, you might just be a short-term fix, and that is okay.

Some apps are genuinely short-term solutions:

• Language learning before a trip.
• A fitness app to prep for a specific event
• A productivity tool for a project that has an end date

Trying to lock those users into annual subscriptions doesn’t increase their lifetime value; it increases their likelihood of feeling trapped and leaving a negative review.

Think honestly about your users’ expected use case. If your core value proposition is a transformation that happens over three to six months, a monthly (or quarterly) subscription might actually serve both parties better than an annual one.

Simpler is usually better. Look at your average retention and choose two subscription durations that match your actual use case, rather than offering every option at once.

5. When you want to drive revenue up, not just retain users

This one surprises people. Usually, for most apps, even unbounded ARPPU is lower for monthly subscriptions.

Yet, Spotify doesn’t offer annual subscriptions. Netflix doesn’t either. These are two of the most successful subscription businesses on the planet, and they’ve built their entire model on monthly billing.

Part of that is product complexity — layering monthly/annual on top of individual/duo/family plans creates more confusion than value. But I think there’s something more interesting going on.

Monthly-only pricing works when you have two things simultaneously: high early churn and very stable long-term retention. The users who stay past a certain point become genuinely sticky — content keeps updating, the habit is formed, and the switching cost is real. For those users, not having an annual discount option means they pay full price every month, indefinitely. Your LTV on retained users actually goes up.

But Peloton is an interesting case study for this. When I canceled my Peloton subscription, I was frustrated by the lack of an annual option — the monthly price felt hard to justify. But Peloton didn’t need to win that battle, because the hardware investment locks users in and makes them willing to pay a premium monthly rate anyway.

The lesson isn’t “don’t offer annuals.” It’s about understanding what actually creates stickiness in your product before you default to discounting your way to retention.

Some of these apps may initially offer an annual subscription option and then, over time, slowly shift back to monthly once they’ve maximized revenue and retention.

How do you decide what to offer?

Most apps I work with default to annual as the primary option without ever asking: Does this actually match where we are right now?

Here’s the diagnostic I’d suggest:

Offer monthly as your primary option (or only option) if:

• You’re pre-PMF or still learning what drives retention
• Your brand is new, and trust is still being built
• Your primary market is MEA, APAC, or your audience skews under 34
• Your use case has a natural endpoint within 3–6 months
• Your conversion rate is low, and you need more data to optimize the funnel

Lead with annual, but keep monthly available if:

• You have strong evidence of what drives long-term retention
• Your product creates a genuine long-term habit
• Your audience is used to SaaS-style annual commitments (productivity, B2B-adjacent tools)
• You’re confident in your onboarding and activation — users who start are getting to value

Consider exclusively monthly if:

• You have exceptionally stable long-term retention and don’t want to discount it away
• Your product model naturally supports it (premium content, ongoing service)
• You’re deliberately running a lean paywall to maximize learning before scaling

If you’re currently offering only annual, how can you actually test this?

So you’ve read all of this, and you’re thinking: fine, maybe I should give monthly a shot. You kind of have a point, Daphne.

But how do you do it without tanking your metrics?

A few things to consider before you start:

1. Define what success looks like before you start

If you test monthly and see higher conversion but lower ARPPU in the short-term, is that a win or a loss? The answer depends on where you are.

For an early-stage app still learning retention, more converted users and faster feedback loops might be worth more than a higher per-subscriber ARPPU number right now.

Know what you’re optimizing for before you interpret the results.

2. Don’t just add monthly and hope for the best

The most common mistake is simply bolting a monthly option onto a paywall that was clearly designed for an annual plan. Where you place each option and how you promote it should depend on your goal.

If you’re trying to learn, and your paywall currently defaults to annual with a prominent “save X%” badge, then adding a small, secondary monthly option at the bottom won’t tell you much at all.

If, instead, you’re trying to meet users where they are — or reduce friction in low-trust environments — then monthly needs to be more visible and genuinely considered. You can still position annual as the better value on a per-month basis, but monthly has to get a fair test if you want meaningful insights from it.

3. Think carefully about trial interaction

A free trial plus a monthly plan is a very different psychological ask from a free trial plus an annual plan. It reduces perceived risk even further, but it can also lead to lower-quality subscribers.

For that reason, some teams deliberately choose not to include a free trial on the monthly tier.

If your trial-to-paid conversion is lower than you’d like, testing a monthly entry point is one of the cleanest ways to diagnose whether the issue is price sensitivity or commitment aversion. In some cases, you might even start by offering a trial on the monthly plan first, and then remove it later once you understand how users behave.

4. Consider the monthly-to-annual upgrade path

One of the strongest arguments for offering a monthly plan isn’t the plan itself — it’s what happens after. Users who start on a monthly plan, experience real value, and then upgrade to annual are often your highest-quality subscribers. They’ve effectively chosen you twice.

If you can design a well-timed upgrade nudge — whether that’s in-app, after a key activation moment, or around the one-month mark — monthly stops being a “discounted alternative” and becomes a lower-friction entry point that feeds into annual revenue over time.

You also want to keep in mind that reactivation data, getting monthlies to reactivate, works better when you have the lifecycle marketing in place to support it.

Give monthly subscriptions a consideration, please

Annual subscriptions feel like a win: higher LTV, stronger retention curves, cash upfront. It’s easy to see why teams default to them.

But too many apps push annual plans before they’ve actually earned the right to ask for that level of commitment — before they really understand whether retention is durable, and before they’ve built enough trust for a 12-month ask to feel safe rather than risky.

Monthly subscriptions aren’t just a concession to users who won’t commit. In the right context, they’re a more deliberate product decision: one that gives you cleaner data, lower conversion friction, and faster feedback loops that help you build something people genuinely want to keep paying for, month after month.

Give them a chance – not as a fallback, but as a deliberate choice.

Shot Pattern started as a hobby. Eric Duffett had just stepped down from coaching basketball because his second child was on the way, and he sat still for about five seconds before opening his laptop. He wanted to see if he could build a simple golf tool — one that would draw two lines on a satellite map showing the width of his landing area. No golf course data, no hole layouts. Just lines on Apple Maps.

It was $20 a year. People would download it, open it at their house, and see it pointing at their backyard. “That’s surprising,” Eric says. But on the golf course, it worked — like a compass for shot strategy.

Watch on YouTube

Within two months, something felt different. Downloads and trials were coming in without Eric understanding where they came from. The reason: serious golfers were already doing this exact thing manually on Google Maps, measuring fairway widths with the built-in ruler tool. Eric had automated a workflow that already existed in a community of strategy-obsessed players.

Then he hit a wall. To make the app actually useful — to give it awareness of golf courses, holes, and hazards — he needed to buy course data. The only option was a $5,000 upfront API purchase. He’d made about $1,000 in total sales. His wife asked the obvious question: “Is this a hobby or is this a business?”

He paid the $5,000. And buried in that API data, he found something he didn’t know he’d purchased: geo-point outlines of every fairway, bunker, water hazard, and green. That was the missing piece for running shot simulations — the “moneyball” feature that would define the app.

“This feature is highly illegal”

Eric built a half-finished prototype of the simulation feature, took a screenshot, and posted it on Twitter: “Hey, this feature is highly illegal if you were to use it during tournament play, but it’s coming soon to Shot Pattern.”

That single tweet was the first time anything he posted got real momentum with a cold audience. Phone calls started coming in from golf influencers and coaches. “Oh, now we’re off to the races,” he says. “Now we have something.”

Shortly after, he got a different kind of phone call. A respected golf company — people Eric admired, “man-crush in the golf world” level — said they’d used the app, loved it, and wanted to buy it. They’d been thinking of building something similar. “What’s your number?”

Eric asked for $250,000. He’d done $12,000 in total sales. They countered at $75,000 — with a non-compete clause thrown in at the very end. No more golf apps, ever.

He said no.

The dark winter

The high lasted about two weeks. Then Eric fell into what he describes as a “dark, dark hole.” He’d turned down real money — not life-changing, but a cushion for a family with a newborn — and the buyers had made their position clear: “We’re going to build what you’ve built. We have more distribution, more brand power. We have a full-time developer. You’re teaching and you have a newborn. It’s over for you.”

October hit. Golf season ended. Revenue dropped. Trials dropped. Subscriptions dropped. Everything went backwards. Eric did his taxes and calculated that at his current profit rate, it would take 75 years to catch up to the $75,000 he’d walked away from.

He tried to sell the app to someone else. Nobody responded. He emailed Curtis Herbert, who talked him off the ledge.

Spend a dollar, make 4

The next spring, Eric decided to try Meta ads. He’d learned from Sub Club and other podcasts that you need creative inventory and enough budget for the algorithm to learn. He paid some content creators, set a $300/day budget, and at the last second threw in a scrappy screen recording with his own voiceover — raw, unpolished, zero production cost.

That last-second addition outperformed everything else. Cost per install: $0.80. His 30-day LTV per download: over $4. “Spend a dollar, make four,” he says. He told his wife he was going to get a line of credit at the bank. She grabbed him by the collar.

The reason it worked wasn’t sophisticated targeting. The creative itself did the filtering. It showed the app doing the thing that strategy-obsessed golfers already cared about, in language they already used. People who weren’t in that niche scrolled past. People who were stopped in their tracks.

By the end of 2024 — his first full year — Eric had outrun the $75K offer. Not just in revenue, but in profit and what he paid himself. He still had the app. He still had the momentum.

$1M as a teacher with a side project

In early 2026, Shot Pattern crossed $1 million in total sales. Eric is still a full-time high school teacher. He teaches intro to business, personal finance, and next year, sports marketing. He recently showed his students a viral video he’d made for the app and explained his target customer profile: “They look like me, they dress like me, they probably think like me, they’re bald like me.”

A student raised his hand, patted his belly, and said he was working on looking more like Eric’s target customer. “He didn’t mean anything by it,” Eric says, “but it came off as quite the dis.”

The competition that threatened to crush him never built the feature. Eric hired his first contractor — not a developer, but a general business operator to handle email automation, paywalls, and experiments. He’s still the sole developer. He still loves that part.

“I still think it’s one of the coolest things,” he says. “To sit down and solve this puzzle with your mind and then show it to people and give them value in exchange for dollars and have it feel like a win for everybody.”

In the full episode, Eric also talks about his first failed meditation app for athletes, what he learned from working with UI/UX students, how he handles the emotional weight of seasonal revenue swings, and why he recommends the book The Only Way to Win by Dr. James Loehr to every high performer he meets.

Guest links:

•Eric Duffett on LinkedIn

•Shot Pattern on social media (all platforms)

•Shot Pattern app

What changed

The RevenueCat dashboard no longer allows users to select “Always decline” as a global refund preference.

The available options now are:

• Let Apple decide: Neutral, no preference expressed
• Grant in full: You prefer the refund is approved
• Grant prorated: You prefer a partial refund based on consumption

We didn’t unilaterally change settings for developers who already had “Always decline” enabled — it’s still active if that was your setting. If you do switch it off, you’ll see a confirmation prompt letting you know you won’t be able to re-enable it. That’s your call to make, but the case for keeping it on is getting weaker.

Why “always decline” was removed

This comes down to how Apple’s refund system actually works:

Refund preferences are signals, not instructions. When you set a refund preference and send it to Apple via the App Store Server API, you’re not making a binding decision. Apple uses your input as one of many factors when evaluating a refund request. The refundPreference field in a ConsumptionRequest is advisory by design.

Blanket declines erode their own effectiveness. When a preference is always set to “decline” regardless of context — whether the user barely touched the app or encountered a genuine bug that made it unusable — Apple’s systems start to discount it. A preference that clearly doesn’t account for the specifics of a transaction carries less weight over time. The signal becomes noise.

Rejecting valid refund requests can backfire. When a legitimate refund request is declined, some users go straight to their bank and issue a chargeback instead. Chargebacks are worse for developers, as a high chargeback rate puts your developer account at risk of being suspended by Apple. A blanket “always decline” policy can inadvertently push users toward the worse outcome for everyone.

What to do right now

If you want more control over refund recommendations, use Refund Control in the RevenueCat dashboard.

Refund Control lets you create multiple policies based on customer audiences, such as platform, country, first purchase date, or any custom audience you define. Each policy can express your preferred refund outcome:

• Decline
• Grant
• Neutral (no preference)

RevenueCat sends the matching preference to Apple through the Consumption Request API and to Google through the Refund Review API. In both cases, your preference is advisory only—the store always makes the final refund decision.

This approach encourages nuanced refund policies instead of blanket "decline everything" behavior, which app stores have made clear they discourage. It also lets you reserve decline recommendations for cases where they're actually appropriate, making the signal more meaningful over time

The bottom line

“Always decline” was a blunt instrument, and it was becoming less effective over time. We’ve seen enough cases of it backfiring that we felt it was important to be straight with you about this. We know it’s not what everyone wanted to hear. At the end of the day, a setting that doesn’t do what you think it does isn’t worth the risk.

See also:

• How to handle refunds in RevenueCat

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

Paywalls

AI Editor

Watch on YouTube

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

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

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

Paywall Rules

Watch on YouTube

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

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

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

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

Funnels

Funnels Builder

Watch on YouTube

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

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

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

A/B Testing

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

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

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

Web

Watch on YouTube

One-Tap Purchases via Express Checkout

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

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

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

Stripe Billing & Stripe Managed Payments

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

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

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

Discounts and Discount Codes

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

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

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

Experiments

pLTV Winner, Credible Intervals, Astra Analysis, Winner Rollout

Watch on YouTube

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

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

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

AI Tools

Rico

Watch on YouTube

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

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

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

Read more on Rico in this blog post.

AI Toolkit

Watch on YouTube

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

Explore the docs.

Charts & Dashboard

Benchmarks

Watch on YouTube

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

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

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

See the docs.

In-App Ad Revenue in Charts

Watch on YouTube

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

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

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

Store Updates

Apple 12-Month Commitments

Watch on YouTube

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

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

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

More on the blog.

Join our next office hours

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

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

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

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

The fundamental problem: Dashboard keys as raw strings

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

val isPremium = customerInfo.entitlements["premium_access"]?.isActive == true
val offering = offerings.getOffering("perplexity")
val monthly = offering?.getPackage("\$rc_monthly")

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

With the codegen plugin applied, the same logic becomes:

val isPremium = customerInfo.isPremiumAccessActive
val offering = offerings.perplexity
val monthly = offering?.perplexityMonthly

The difference is more than aesthetics:

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

Setting up the plugin

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

Step 1: Apply the plugin

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

[versions]
purchases = "PURCHASES_VERSION"

[plugins]
revenuecat-codegen = { id = "com.revenuecat.purchases.codegen", version.ref = "purchases" }

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

plugins {
    alias(libs.plugins.revenuecat.codegen) apply false
}

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

plugins {
    alias(libs.plugins.android.application)
    alias(libs.plugins.revenuecat.codegen)
}

Step 2: Configure the extension

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

revenuecat {
    apiKey.set("sk_your_v2_secret_key")
    projectId.set("proj_your_project_id")
    packageName.set("com.example.app.rc")
}

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

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

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

The full set of optional properties looks like this:

import com.revenuecat.purchases.codegen.NamingStyle
import com.revenuecat.purchases.codegen.OfflineMode

revenuecat {
    apiKey.set("sk_your_v2_secret_key")
    projectId.set("proj_your_project_id")
    packageName.set("com.example.app.rc")

    cacheTtlMinutes.set(30L)
    offlineMode.set(OfflineMode.USE_CACHE_OR_SKIP)
    namingStyle.set(NamingStyle.CAMEL_CASE)

    generateEntitlements.set(true)
    generateOfferings.set(true)
    generatePackages.set(true)
    generateCustomerInfoExtensions.set(true)
}

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

Step 3: Build

Run any standard build task:

./gradlew assembleDebug

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

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

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

What gets generated

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

Entitlement ID constants

A single RCEntitlementId object holds one constant per entitlement:

object RCEntitlementId {
    const val PREMIUM_ACCESS: String = "premium_access"
}

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

Type safe EntitlementInfos extensions

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

val EntitlementInfos.premiumAccess: EntitlementInfo?
    get() = this["premium_access"]

val EntitlementInfos.isPremiumAccessActive: Boolean
    get() = this["premium_access"]?.isActive == true

Convenience CustomerInfo extensions

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

val CustomerInfo.isPremiumAccessActive: Boolean
    get() = this.entitlements["premium_access"]?.isActive == true

Offering and package accessors

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

object RCOfferingId {
    const val PERPLEXITY: String = "perplexity"
}

val Offerings.perplexity: Offering?
    get() = this.getOffering("perplexity")

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

object RCPerplexityPackageId {
    const val MONTHLY: String = "${'$'}rc_monthly"
    const val ANNUAL: String = "${'$'}rc_annual"
}

val Offering.perplexityMonthly: Package?
    get() = this.getPackage("${'$'}rc_monthly")

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

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

Naming styles: From lookup keys to Kotlin identifiers

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

The namingStyle option controls the middle step:

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

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

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

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

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

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

A practical pattern applies each mode based on the environment:

import com.revenuecat.purchases.codegen.OfflineMode

val isCI = providers.environmentVariable("CI").isPresent

revenuecat {
    apiKey.set(providers.environmentVariable("REVENUECAT_API_KEY").getOrElse(""))
    projectId.set(providers.environmentVariable("REVENUECAT_PROJECT_ID").getOrElse(""))
    packageName.set("com.example.app.rc")
    offlineMode.set(if (isCI) OfflineMode.FAIL else OfflineMode.USE_CACHE_OR_SKIP)
}

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

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

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

Refreshing after dashboard changes

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

rm -rf app\/build\/revenuecat\/cache
.\/gradlew :app:rcFetchSchema :app:rcGenerateCode

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

How it works: Two Gradle tasks and a schema cache

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

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

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

Keeping the secret key out of version control

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

val localProps = java.util.Properties().apply {
    rootProject.file("local.properties").takeIf { it.exists() }?.inputStream()?.use { load(it) }
}

revenuecat {
    apiKey.set(localProps.getProperty("REVENUECAT_API_KEY", ""))
    projectId.set(localProps.getProperty("REVENUECAT_PROJECT_ID", ""))
    packageName.set("com.example.app.rc")
}

Then add the values to local.properties:

REVENUECAT_API_KEY=sk_your_v2_secret_key
REVENUECAT_PROJECT_ID=proj_your_project_id

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

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

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

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

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

Conclusion

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

As always, happy coding!

— Jaewoong (skydoves)

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

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

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

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

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

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

What to implement

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

What to ask

Keep it straightforward – One clear question should suffice.

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

Focus on actionable reasons like:

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

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

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

Make sure to also leave an “other” option open-ended so you’re collecting insights from users who may have discovered a bug or problem with the app you’re not aware of. Once you’ve got a breakdown of the most popular answers, you can define your list of actionable reasons further.

What to offer

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

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

Some examples:

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

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

What data to capture

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

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

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

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

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

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

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

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

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

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

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

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

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

Channel strategy

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

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

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

3. Timing matters more than what you say

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Offer strategy: what works vs what feels desperate

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

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

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

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

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

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

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

5. Make it frictionless to return

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

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

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

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

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

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

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

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

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

Final thought

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

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

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

Annual subscriptions can now bill monthly

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

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

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

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

What changes in your code

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

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

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

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

What changes on your server

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

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

What this means for RevenueCat customers

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

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

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

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

Retention Messaging lets you save subscribers at the moment they cancel

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

There are two ways to use it.

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

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

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

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

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

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

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

What this means for RevenueCat customers

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

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

Subscriptions can now be sold to groups and organizations

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

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

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

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

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

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

Entitlement design is the hard part

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

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

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

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

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

Cross-developer Bundles and Suites

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

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

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

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

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

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

What this means for your RevenueCat Dashboard

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

App Store Merchandising: new placements for Creative Assets

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

A few things worth noting about how this works:

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

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

Personalized Collections and App Notes

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

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

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

Offer Code Redemption gets a proper result

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

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

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

Unified App Review submissions

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

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

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

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

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

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

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

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

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

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

Summary

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

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

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

Now let’s build an app!

What are we building?

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

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

Here’s how it looks:

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

Level 1: Client-only check

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

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

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

In code, it looks something like this:

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/lib\/catflix_repository.dart#L127

final info = await Purchases.getCustomerInfo();

final isPremium = info.entitlements.active.containsKey('catflix Premium');

if (isPremium) {

  _playPremiumShow();

}

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

Conclusion: this approach should never be used in production!

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

Level 2: Client-only check + Firebase App Check

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

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

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

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

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

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

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

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

Level 3: Server-verified entitlements

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

Identifying Firebase users in RevenueCat

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

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

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/lib\/bootstrap_firebase.dart#L127 
 final credential = await FirebaseAuth.instance.signInAnonymously();
 await Purchases.logIn(credential.user!.uid);

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

Understanding Firebase Cloud Functions

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

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

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

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

Implementing Cloud Function for movie-playing functionality

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

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/functions\/bin\/server.dart#L14 
void main(List<String> args) async {
 await runFunctions((firebase) {
   firebase.https.onCall(name: 'play', (request, response) async { // #1
     if (request.auth == null) { // #2
       throw UnauthenticatedError(
         'Sign-in is required to play a show.',
       );
     } 
     final isPremium = /* CHECK ENTITLEMENT HERE */; //#3
     if (isPremium) { 
	 // lookup the playbackUrl in database
       return CallableResult({'playbackUrl': playbackUrl});
     } else {
       throw PermissionDeniedError('Premium required to play this title.');
     }
   });
 }
}

We’re doing several things here:

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

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

final result = FirebaseFunctions.instance.httpsCallableFromUrl(URL).call();

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

Option 1: Direct calls to RevenueCat API

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

With this approach, our architecture would look like this:

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

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/functions\/lib\/play\/play_from_api.dart#L62 
// Pseudocode: error handling, security checks, type-checks, etc. omitted for clarity.
const _rcApiBase = 'https:\/\/api.revenuecat.com\/v2';
// Plain config: RevenueCat's project id (not sensitive, not a secret).
final _rcProjectId = defineString('RC_PROJECT_ID');
// Secret: the RevenueCat secret API key. Cloud Secret Manager.
final _rcApiKey = defineSecret('RC_API_KEY');'
const _entitlementLookupKey = 'catflix Premium';

Future<bool> _hasActivePremium(String uid) async {
  final response = await httpGet(
    '$_rcApiBase\/projects\/$_rcProjectId'
    '\/customers\/$uid'
    '\/active_entitlements\/$_entitlementLookupKey',
    headers: {'Authorization': 'Bearer $_rcApiKey'},
  );
  return response.statusCode == 200;
}

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

How to access sensitive parameters in Firebase Cloud Functions

Firebase Cloud Functions have their own way of defining configuration parameters, and it separates plain config from secrets. Secrets are backed by Google Cloud Secret Manager: stored encrypted, and injected only into the functions you explicitly bind them to. Use a secret for anything sensitive, like your RevenueCat API key, and plain parameters for everything else, like your RevenueCat project ID. The experimental Dart SDK supports both, with defineSecret(‘RC_API_KEY’) for the key and defineString(‘RC_PROJECT_ID’) for the rest. Here are the docs. Now, even if a malicious user manages to change the value of isPremium to true on the client side, they still won’t be able to access the premium features because our Cloud Function simply won’t return the premium content.

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

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

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

Option 2: Custom Webhook Function

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

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

In this case, the architecture would look like this:

But the benefits are worth it:

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

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

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

Option 3: RevenueCat Firebase Extension

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

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

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

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

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

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

1. Start the integration in your RevenueCat console and generate a shared secret. You will need it in the next step.

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

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

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

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

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

Reading entitlement data from Firestore

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

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/functions\/lib\/play\/play_from_db.dart 
// Pseudocode: error handling, type-checks, and configurable
// collection paths omitted for clarity.
Future<bool> _hasCatflixPremiumInFirestore({required String uid}) async {
  final snapshot = await firebaseApp
      .firestore()
      .collection('customers') // the path you specified when configuring extension
      .doc(uid)
      .get();

  final entitlement = snapshot.data()?['entitlements']?['catflix Premium'];
  if (entitlement == null) return false;

  final expiresAt = DateTime.parse(entitlement['expires_date']);
  return expiresAt.isAfter(DateTime.now());
}

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

Reading entitlement data from Auth Custom Claims

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

What are custom claims, in a nutshell?

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

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

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

Where does the auth data come from in our function?

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

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

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/functions\/lib\/play\/play.dart 
// Pseudocode: error handling and claim-decoding quirks omitted.
bool _hasCatflixPremiumInClaims(AuthData auth) {
  final entitlements = auth.token['revenueCatEntitlements'] as List?;
  return entitlements?.contains('catflix Premium') ?? false;
}

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

The catch: claim refresh latency

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

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

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

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

// Sample in code: https:\/\/github.com\/darjaorlova\/catflix\/blob\/main\/lib\/catflix_repository.dart#L101 
// in your Flutter app
Purchases.addCustomerInfoUpdateListener((_) async {
  await FirebaseAuth.instance.currentUser?.getIdToken(true);
});

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

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

So which one should you pick?

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

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

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

Summary

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

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

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

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

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

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

Use the RevenueCat AI Toolkit to shorten development time

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

Install it with:

claude plugins marketplace add RevenueCat/ai-toolkit

claude plugins install RevenueCat

Or, for Codex:

codex plugin marketplace add RevenueCat/ai-toolkit

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

How “name your price” slider paywall works

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

There are three parts to the system:

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

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

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

Step 1: Create your price-tiered products and entitlement

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

Create products using RevenueCat MCP

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

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

Create products using RevenueCat dashboard

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

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

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

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

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

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

Step 2: Connect RevenueCat to React Native

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

Setup RevenueCat using an agent

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

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

Set up RevenueCat manually

Install the React Native SDK:

npm install --save react-native-purchases

Then configure RevenueCat when your app starts:

import { useEffect } from 'react';
import { Platform } from 'react-native';
import Purchases, { LOG_LEVEL } from 'react-native-purchases';

export default function App() {
  useEffect(() => {
    Purchases.setLogLevel(LOG_LEVEL.DEBUG); // remove for release

    const apiKey = Platform.OS === 'ios'
      ? 'appl_YOUR_IOS_PUBLIC_SDK_KEY'
      : 'goog_YOUR_ANDROID_PUBLIC_SDK_KEY';

    Purchases.configure({ apiKey });
  }, []);

  return /* … your UI … */;
}

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

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

import Purchases from 'react-native-purchases';

async function hasProAccess() {
  const customerInfo = await Purchases.getCustomerInfo();
  return customerInfo.entitlements.active.pro !== undefined;
}

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

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

Step 3: Fetch the available price tiers

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

Build the slider using an agent

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

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

Code for name your price paywall

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

import { useEffect, useMemo, useState } from 'react';
import {
  ActivityIndicator,
  Alert,
  Pressable,
  ScrollView,
  StyleSheet,
  Text,
  View,
} from 'react-native';
import { LinearGradient } from 'expo-linear-gradient';
import Slider from '@react-native-community/slider';
import Purchases, { PurchasesPackage } from 'react-native-purchases';

const ENTITLEMENT_ID = 'pro';

// Each slider position is a gem tier. All tiers map to the SAME entitlement —
// only the color, name, and product ID change.
type GemTier = {
  id: string;
  name: string;
  productIdentifier: string;
  color: string;
  gradient: [string, string]; // [light, dark] for the card + button
  tagline: string;
  level: number; // 1...5, drives the dot row
};

const SHARED_FEATURES = [
  'See data from all years',
  'Remove watermark from sharing',
  'Join the leaderboard',
];

const TIERS: GemTier[] = [
  { id: 'topaz',    name: 'Topaz',    productIdentifier: 'lifetime_topaz',    color: '#FFB233', gradient: ['#FFCC4D', '#FF991A'], tagline: 'Essential Explorer', level: 1 },
  { id: 'sapphire', name: 'Sapphire', productIdentifier: 'lifetime_sapphire', color: '#3366FF', gradient: ['#4D80FF', '#1A4DCC'], tagline: 'Sky Master',         level: 2 },
  { id: 'emerald',  name: 'Emerald',  productIdentifier: 'lifetime_emerald',  color: '#33CC66', gradient: ['#4DE680', '#1AB34D'], tagline: 'Eco Traveler',       level: 3 },
  { id: 'ruby',     name: 'Ruby',     productIdentifier: 'lifetime_ruby',     color: '#E63350', gradient: ['#FF4D66', '#CC1A33'], tagline: 'Premium Voyager',    level: 4 },
  { id: 'diamond',  name: 'Diamond',  productIdentifier: 'lifetime_diamond',  color: '#B3CCFF', gradient: ['#FFFFFF', '#99B3E6'], tagline: 'Ultimate Edition',   level: 5 },
];

export function NameYourPricePaywall() {
  const [selectedIndex, setSelectedIndex] = useState(2); // default to middle tier
  const [prices, setPrices] = useState<Record<string, string>>({});
  const [packages, setPackages] = useState<PurchasesPackage[]>([]);
  const [isPurchasing, setIsPurchasing] = useState(false);

  const selectedTier = TIERS[selectedIndex];
  const isLoaded = packages.length > 0;

  useEffect(() => {
    (async () => {
      try {
        const offerings = await Purchases.getOfferings();
        const available = offerings.current?.availablePackages ?? [];
        setPackages(available);

        const priceMap: Record<string, string> = {};
        for (const pkg of available) {
          priceMap[pkg.product.identifier] = pkg.product.priceString;
        }
        setPrices(priceMap);
      } catch (e) {
        console.error('Failed to load offerings', e);
      }
    })();
  }, []);

  async function handlePurchase() {
    const pkg = packages.find(
      (p) => p.product.identifier === selectedTier.productIdentifier
    );
    if (!pkg) {
      Alert.alert('Unavailable', 'That tier is not available right now.');
      return;
    }

    setIsPurchasing(true);
    try {
      const { customerInfo } = await Purchases.purchasePackage(pkg);
      if (customerInfo.entitlements.active[ENTITLEMENT_ID]) {
        Alert.alert('Unlocked', `You're now a ${selectedTier.name} member.`);
      }
    } catch (e: any) {
      if (!e.userCancelled) {
        Alert.alert('Purchase failed', 'Please try again.');
      }
    } finally {
      setIsPurchasing(false);
    }
  }

  async function restorePurchases() {
    try {
      const customerInfo = await Purchases.restorePurchases();
      Alert.alert(
        customerInfo.entitlements.active[ENTITLEMENT_ID] ? 'Restored' : 'No purchases found',
        customerInfo.entitlements.active[ENTITLEMENT_ID]
          ? 'Your access has been restored.'
          : 'We could not find an active purchase.'
      );
    } catch (e) {
      console.error('Restore failed', e);
    }
  }

  return (
    // Background gradient tints toward the selected tier's color
    <LinearGradient
      colors={['#FFFFFF', `${selectedTier.color}26`, `${selectedTier.color}4D`]}
      style={styles.container}
    >
      <ScrollView contentContainerStyle={styles.scroll}>
        {/* Hero: frequent-flyer style membership card */}
        <MembershipCard tier={selectedTier} />

        {/* Gem indicators on a connecting line */}
        <GemRail selectedIndex={selectedIndex} onSelect={setSelectedIndex} />

        {/* Slider — each step is one tier */}
        <Slider
          minimumValue={0}
          maximumValue={TIERS.length - 1}
          step={1}
          value={selectedIndex}
          onValueChange={(v) => setSelectedIndex(Math.round(v))}
          minimumTrackTintColor={selectedTier.color}
          thumbTintColor={selectedTier.color}
          style={styles.slider}
        />

        {/* Price */}
        <View style={styles.priceBlock}>
          {prices[selectedTier.productIdentifier] ? (
            <>
              <View style={styles.priceRow}>
                <Text style={[styles.price, { color: selectedTier.color }]}>
                  {prices[selectedTier.productIdentifier]}
                </Text>
                <Text style={[styles.priceTier, { color: selectedTier.color }]}>
                  {selectedTier.name}
                </Text>
              </View>
              <Text style={styles.priceCaption}>
                One-time payment • Lifetime access
              </Text>
            </>
          ) : (
            <ActivityIndicator />
          )}
        </View>

        {/* Unlock button — gradient matches the tier */}
        <Pressable
          onPress={handlePurchase}
          disabled={isPurchasing || !isLoaded}
          style={({ pressed }) => [{ opacity: pressed ? 0.9 : 1 }]}
        >
          <LinearGradient
            colors={selectedTier.gradient}
            start={{ x: 0, y: 0 }}
            end={{ x: 1, y: 1 }}
            style={styles.unlockButton}
          >
            {isPurchasing ? (
              <ActivityIndicator color="#fff" />
            ) : (
              <Text style={styles.unlockText}>◆  Unlock {selectedTier.name}</Text>
            )}
          </LinearGradient>
        </Pressable>

        <Pressable onPress={restorePurchases} style={styles.restore}>
          <Text style={styles.restoreText}>Restore Purchases</Text>
        </Pressable>

        <Text style={styles.terms}>
          By purchasing, you agree to our Terms of Service and Privacy Policy
        </Text>
      </ScrollView>
    </LinearGradient>
  );
}

// MARK: – Membership card

function MembershipCard({ tier }: { tier: GemTier }) {
  return (
    <LinearGradient
      colors={[`${tier.color}E6`, `${tier.color}B3`, `${tier.color}80`]}
      start={{ x: 0, y: 0 }}
      end={{ x: 1, y: 1 }}
      style={[styles.card, { shadowColor: tier.color }]}
    >
      {/* Metallic sheen overlay */}
      <LinearGradient
        colors={['rgba(255,255,255,0.12)', 'transparent', 'rgba(255,255,255,0.05)']}
        start={{ x: 0, y: 0 }}
        end={{ x: 1, y: 1 }}
        style={StyleSheet.absoluteFill}
      />

      {/* Header: brand + tier badge */}
      <View style={styles.cardHeader}>
        <Text style={styles.brand}>TRIPPITY</Text>
        <View style={styles.badge}>
          <Text style={styles.badgeText}>◆ {tier.name.toUpperCase()}</Text>
        </View>
      </View>

      <Text style={styles.userName}>Traveler</Text>

      {/* Shared features */}
      <View style={styles.features}>
        {SHARED_FEATURES.map((f) => (
          <Text key={f} style={styles.feature}>✓  {f}</Text>
        ))}
      </View>

      {/* Footer: level dots + lifetime label */}
      <View style={styles.cardFooter}>
        <View style={styles.dots}>
          {[0, 1, 2, 3, 4].map((i) => (
            <View
              key={i}
              style={[
                styles.dot,
                { backgroundColor: i < tier.level ? '#fff' : 'rgba(255,255,255,0.3)' },
              ]}
            />
          ))}
        </View>
        <Text style={styles.lifetime}>LIFETIME MEMBER</Text>
      </View>
    </LinearGradient>
  );
}

// MARK: – Gem rail (indicators + connecting line)

function GemRail({
  selectedIndex,
  onSelect,
}: {
  selectedIndex: number;
  onSelect: (i: number) => void;
}) {
  return (
    <View style={styles.rail}>
      {TIERS.map((tier, i) => {
        const isActive = i <= selectedIndex;
        const isSelected = i === selectedIndex;
        return (
          <View key={tier.id} style={styles.railSegment}>
            <Pressable onPress={() => onSelect(i)} hitSlop={12}>
              <Text
                style={[
                  styles.gem,
                  {
                    fontSize: isSelected ? 26 : 16,
                    color: isActive ? tier.color : 'rgba(150,150,150,0.5)',
                    textShadowColor: isActive ? tier.color : 'transparent',
                    textShadowRadius: isSelected ? 10 : 0,
                  },
                ]}
              >
                ◆
              </Text>
            </Pressable>
            {i < TIERS.length - 1 && (
              <View
                style={[
                  styles.connector,
                  {
                    backgroundColor:
                      i < selectedIndex ? TIERS[i + 1].color : 'rgba(150,150,150,0.3)',
                  },
                ]}
              />
            )}
          </View>
        );
      })}
    </View>
  );
}

const styles = StyleSheet.create({
  container: { flex: 1 },
  scroll: { padding: 24, gap: 20 },

  card: {
    height: 260,
    borderRadius: 16,
    padding: 20,
    justifyContent: 'space-between',
    overflow: 'hidden',
    shadowOpacity: 0.4,
    shadowRadius: 20,
    shadowOffset: { width: 0, height: 10 },
    elevation: 12,
  },
  cardHeader: { flexDirection: 'row', justifyContent: 'space-between', alignItems: 'center' },
  brand: { color: 'rgba(255,255,255,0.9)', fontSize: 14, fontWeight: '700', letterSpacing: 2 },
  badge: {
    flexDirection: 'row',
    backgroundColor: 'rgba(255,255,255,0.2)',
    borderColor: 'rgba(255,255,255,0.3)',
    borderWidth: 1,
    borderRadius: 100,
    paddingHorizontal: 10,
    paddingVertical: 4,
  },
  badgeText: { color: '#fff', fontSize: 11, fontWeight: '700', letterSpacing: 1 },
  userName: { color: '#fff', fontSize: 24, fontWeight: '700', marginTop: 10 },
  features: { gap: 6, marginTop: 8 },
  feature: { color: 'rgba(255,255,255,0.9)', fontSize: 12, fontWeight: '500' },
  cardFooter: { flexDirection: 'row', justifyContent: 'space-between', alignItems: 'center' },
  dots: { flexDirection: 'row', gap: 3 },
  dot: { width: 6, height: 6, borderRadius: 3 },
  lifetime: { color: 'rgba(255,255,255,0.6)', fontSize: 8, fontWeight: '500', letterSpacing: 1 },

  rail: { flexDirection: 'row', alignItems: 'center', paddingHorizontal: 8 },
  railSegment: { flexDirection: 'row', alignItems: 'center', flex: 1 },
  gem: { textAlign: 'center', width: 30 },
  connector: { flex: 1, height: 3, borderRadius: 2 },

  slider: { marginHorizontal: 8 },

  priceBlock: { alignItems: 'center', gap: 4 },
  priceRow: { flexDirection: 'row', alignItems: 'flex-end', gap: 6 },
  price: { fontSize: 36, fontWeight: '800' },
  priceTier: { fontSize: 18, fontWeight: '500', marginBottom: 4 },
  priceCaption: { fontSize: 12, color: '#888' },

  unlockButton: { borderRadius: 14, paddingVertical: 16, alignItems: 'center' },
  unlockText: { color: '#fff', fontSize: 16, fontWeight: '600' },

  restore: { alignItems: 'center', paddingTop: 4 },
  restoreText: { color: '#888', fontSize: 14 },
  terms: { color: '#aaa', fontSize: 11, textAlign: 'center', paddingHorizontal: 24, paddingBottom: 20 },
});

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

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

Wrapping up

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

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

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

Sources

• RevenueCat AI Toolkit
• RevenueCat React Native SDK installation
• RevenueCat entitlements
• RevenueCat offerings and product configuration

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

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

The fundamental problem: two billing stacks that share no types

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

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

private val purchasesUpdatedListener = PurchasesUpdatedListener { result, purchases ->
    if (result.responseCode == BillingResponseCode.OK && purchases != null) {
        purchases.forEach { handlePurchase(it) }
    } else if (result.responseCode == BillingResponseCode.USER_CANCELED) {
        \/\/ back out quietly
    }
}

private val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(PendingPurchasesParams.newBuilder().enableOneTimeProducts().build())
    .build()

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

private fun handlePurchase(purchase: Purchase) {
    if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED && !purchase.isAcknowledged) {
        \/\/ 1. verify purchase.purchaseToken on your backend
        \/\/ 2. grant the entitlement
        val params = AcknowledgePurchaseParams.newBuilder()
            .setPurchaseToken(purchase.purchaseToken)
            .build()
        billingClient.acknowledgePurchase(params) { \/* ack result *\/ }
    }
}

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

let result = try await product.purchase()
switch result {
case .success(let verification):
    let transaction = try checkVerified(verification) \/\/ validate the signed JWS
    await grantEntitlement(for: transaction)
    await transaction.finish()
case .userCancelled, .pending:
    break
@unknown default:
    break
}

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

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

The shared model that replaces both

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

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

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

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

What the SDK does at the platform boundary

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

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

public fun NativeAndroidStoreProduct.toStoreProduct(): StoreProduct = AndroidStoreProduct(this)

private class AndroidStoreProduct(val wrapped: NativeAndroidStoreProduct) : StoreProduct {
    override val id: String = wrapped.id
    override val title: String = wrapped.title
    override val localizedDescription: String = wrapped.description
    override val price: Price = wrapped.price.toPrice()
    override val subscriptionOptions: SubscriptionOptions? = wrapped.subscriptionOptions?.toSubscriptionOptions()
    override val discounts: List<StoreProductDiscount> = emptyList()
    override val introductoryDiscount: StoreProductDiscount? = null
}

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

public fun NativeIosStoreProduct.toStoreProduct(): StoreProduct = IosStoreProduct(this)

private class IosStoreProduct(val wrapped: NativeIosStoreProduct) : StoreProduct {
    override val id: String = wrapped.productIdentifier()
    override val title: String = wrapped.localizedTitle()
    override val localizedDescription: String = wrapped.localizedDescription()
    override val price: Price = wrapped.toPrice()
    override val subscriptionOptions: SubscriptionOptions? = null
    override val discounts: List<StoreProductDiscount> =
        wrapped.discounts().map { (it as IosStoreProductDiscount).toStoreProductDiscount() }
}

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

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

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

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

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation("com.revenuecat.purchases:purchases-kmp-core:3.0.3")
            \/\/ Optional: the Compose Multiplatform paywall component
            implementation("com.revenuecat.purchases:purchases-kmp-ui:3.0.3")
        }
    }
}

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

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

Step 2: Replace two initializers with one

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

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

Purchases.logLevel = LogLevel.DEBUG
Purchases.configure(apiKey = revenueCatApiKey) {
    appUserId = null \/\/ stay anonymous until the user logs in
}

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

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

Step 3: Replace product loading

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

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

val offerings = Purchases.sharedInstance.awaitOfferings()
val premium = offerings.current?.monthly
    ?: offerings.current?.availablePackages?.firstOrNull()
    ?: error("No current offering configured")

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

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

Step 4: Replace the purchase flow

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

The shared replacement is one suspend call:

try {
    val purchase = Purchases.sharedInstance.awaitPurchase(premium)
    val isPremium = purchase.customerInfo.entitlements["premium"]?.isActive == true
    \/\/ unlock content based on isPremium
} catch (e: PurchasesTransactionException) {
    if (e.userCancelled) {
        \/\/ user dismissed the dialog, treat as a no op
    } else {
        \/\/ surface e.error
    }
}

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

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

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

Step 5: Replace entitlement checks

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

The shared form is a property read:

val info = Purchases.sharedInstance.awaitCustomerInfo()
val isPremium = info.entitlements["premium"]?.isActive == true

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

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

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

Step 6: Bring your existing purchasers with you

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

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

\/**
 * This method will send all the purchases to the RevenueCat backend. Call this when using your own
 * implementation for subscriptions anytime a sync is needed, such as when migrating existing users
 * to RevenueCat.
 *
 * Warning: This function should only be called if you're migrating to RevenueCat or in observer
 * mode.
 *\/
public suspend fun Purchases.awaitSyncPurchases(): CustomerInfo

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

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

Purchases.configure(apiKey = revenueCatApiKey) {
    purchasesAreCompletedBy = PurchasesAreCompletedBy.MyApp(StoreKitVersion.STOREKIT_2)
}

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

Step 7: Keep user identity stable

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

val login = Purchases.sharedInstance.awaitLogIn("your-stable-user-id")
val isPremium = login.customerInfo.entitlements["premium"]?.isActive == true
\/\/ login.created is true if this registered a new backend user

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

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

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

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

Verify parity before you delete anything

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

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

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

What still needs platform awareness

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

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

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

Conclusion

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

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

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

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

How is this data collected?

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

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

Understanding the visualizations

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

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

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

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

React Native leads in download to paid conversion

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

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

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

First key learning: execution matters far more than stack choice

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

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

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

React Native apps generate more revenue per install

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

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

Second key learning: feedback loops

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

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

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

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

React Native pulls further ahead by day 60

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

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

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

Third key learning: monetization is a product problem

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

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

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

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

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

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

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

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

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

Fourth key learning: play long-term games

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

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

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

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

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

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

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

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

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

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

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

Fifth key learning: valuable customers beat more customers

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

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

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

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

Predictions for next year’s State of Subscriptions app report

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

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

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

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

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

Conclusion

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

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

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

Watch on YouTube

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

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

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

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

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

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

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

The hidden design differences between iPad and Mac

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Guest links:

• Austin Blake on X/Twitter
• Stuff on the App Store

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

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

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

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

When reactivation happens, the most

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

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

1. The use case
2. Subscription duration
3. Category
4. Price point
5. Geography

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

1. The use case

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

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

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

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

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

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

AI apps (the wildcard)

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

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

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

2. Subscription duration

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

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

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

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

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

3. Category

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

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

A. Productivity

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

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

B. Gaming

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

C. Shopping

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

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

4. Price Point

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

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

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

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

5. Geography

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

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

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

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

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

Reactivation only comes after activation and habit building

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

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

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

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

Start by reviewing activation

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

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

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

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

Then check habit formation

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

The signals here are slightly different:

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

You need to ensure you’re building lasting habits.

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

Reactivation is a growing opportunity

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

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

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

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

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

Now imagine actively working on it.

It is even growing year on year

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

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

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

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

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

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

Lean into the compounding effect as you grow

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

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

The answer tends to get more interesting over time.

Is reactivation worth it for you?

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

Reactivation is likely worth prioritizing if:

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

Deprioritize reactivation if:

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

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

The reactivation impact calculator

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

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

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

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

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

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

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

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

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

Here’s how to fill it in:

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

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

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

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

The churned list is getting bigger every month

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

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

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

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

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

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

Watch on YouTube

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

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

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

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

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

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

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

The growth lever no dashboard can measure

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

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

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

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

HSA payments: unlocking a whole new audience

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

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

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

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

Guest links:

• Nancy Anderson on Instagram
• Natal App

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

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

Warning before starting: AI is needed

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

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

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

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

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

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

• Channels
• Creative Production
• Tracking
• Schedule

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pillar 4: Schedule - How often should you execute?

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

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

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

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

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

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

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

When and how to hire your first external help

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

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

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

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

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

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

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

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

Meet the RevenueCat AI Toolkit

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

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

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

What you and your agent can do

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

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

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

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

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

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

How to install it

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

/plugin

Choose Marketplace, select + Add Marketplace, enter:

RevenueCat/ai-toolkit

Then install the RevenueCat plugin.

You can also install it from the command line:

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

For OpenAI Codex CLI, add the marketplace first:

codex plugin marketplace add RevenueCat/ai-toolkit

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

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

codex plugin marketplace add RevenueCat/ai-toolkit

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

For Gemini CLI, install the extension directly from GitHub:

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

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

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

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

npx skills add RevenueCat/ai-toolkit

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

What you can ask it

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

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

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

What’s the status of my RevenueCat project?

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

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

Frequently Asked Questions

What can an agent do through the AI Toolkit?

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

Can an agent change live RevenueCat configuration?

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

How does authentication work?

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

Should you use this directly in production?

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

Does this replace the RevenueCat dashboard?

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

Skills included in the AI Toolkit

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

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

Get started

Install the RevenueCat AI Toolkit in Claude Code:

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

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

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

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

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

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

The reality gap

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

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

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

Well, f*ck it.

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

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

Asking AI to think for me was a bad idea

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Exit the echo chamber and find your footing

The loop that makes your head explode looks like this:

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

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

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

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

I was breaking my own rules:

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

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

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

Focus on meaningful things, instead of everything

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

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

The framework that worked for me was:

1. Create an evaluation layer
2. Build a backlog
3. Operationalize

1. Create an evaluation layer

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

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

2. Build a backlog

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

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

3. Operationalize

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

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

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

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

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

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

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

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

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

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

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

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

Buying a house with RealBasic

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

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

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

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

The human cost of going broke

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

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

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

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

Pricing for a $4,000 camera

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

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

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

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

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

The three-week COVID pivot

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

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

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

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

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

Guest links:

• Daniel Kennett’s Website
• Cascable
• Daniel Kennett on Mastodon

TLDR

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

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

Discovery moves into Gemini and conversational surfaces

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

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

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

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

Play Shorts and Ask Play change the on store experience

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

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

Sidekick: an AI overlay for games

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

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

AI in the Play Console: localization and catalog

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

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

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

Billing changes that reduce involuntary churn

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

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

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

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

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

Play Billing Library 9.0.0: what actually changed in code

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

The dependency update is straightforward:

dependencies {
    val billingVersion = "9.0.0"
    implementation("com.android.billingclient:billing:$billingVersion")
    implementation("com.android.billingclient:billing-ktx:$billingVersion")
}

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

In app messaging for opt in price increases

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

You call the same method you would for payment recovery:

val params = InAppMessageParams.newBuilder()
    .addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
    .build()

billingClient.showInAppMessages(
    activity,
    params,
    object : InAppMessageResponseListener {
        override fun onInAppMessageResponse(result: InAppMessageResult) {
            when (result.responseCode) {
                InAppMessageResponseCode.NO_ACTION_NEEDED -> {
                    \/\/ Nothing to show this session
                }
                InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED -> {
                    \/\/ Payment fixed or price increase confirmed
                    refreshSubscriptionStatus(result.purchaseToken)
                }
            }
        }
    }
)

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

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

Updated error code for a blocked Play Store

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

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

when (result.responseCode) {
    BillingResponseCode.BILLING_UNAVAILABLE -> {
        if (result.debugMessage.contains("Play Store is blocked")) {
            showBlockedStoreFallback()
        } else {
            showBillingUnavailableFallback()
        }
    }
    BillingResponseCode.ERROR -> {
        showGenericError()
    }
}

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

DeveloperProvidedBillingDetails.getLinkUri is now nullable

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

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

val linkUri = details.linkUri
if (!linkUri.isNullOrEmpty()) {
    val intent = Intent(Intent.ACTION_VIEW, Uri.parse(linkUri))
    startActivity(intent)
} else {
    showExternalPaymentUnavailableState()
}

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

targetSdkVersion bumped to 35

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

Analytics and AI powered insights

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

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

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

Protected with Play

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

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

What v9 means for the v7 sunset

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

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

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

Conclusion

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

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

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

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

Viewing the funnel as more than the sum of its parts

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

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

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

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

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

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

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

One prerequisite for success

At that point at Mimo, we didn’t sit down and debate if we should ‘increase LTV’ or ‘decrease CAC’. We already knew from user research and data where people got stuck, what made them question the upgrade, and what made them leave. We knew that:

• The trial anxiety was causing friction because we read it in store reviews every day
• Users didn’t perceive the app as a serious learning tool because we weren’t always consistent in communicating it this way
• The language barrier was costing us because the users were vocal about it

But we also knew our target users, what they needed, and what set us apart from the competition. If you don’t have a foundation from user research, don’t know the qualitative signals, or don’t have an honest analysis of where value breaks down, start there.

Interdependency #1: your paywall changes a lot downstream

The paywall is the most obvious lever for conversion. But it’s also a distribution mechanism: for plans, price points, user intent, ultimately LTV.

The trial screen that changed our trajectory

The paywall change that had the biggest impact at Mimo was shifting to the ‘honest trial paywall’ or ‘Blinkist paywall’: a clear, transparent explanation of how the free trial works. When Blinkist shared the results of this experiment, I wanted to test it immediately because we were seeing the same anxieties about trials in our reviews every day.

Our results were great: trial opt-in rates more than doubled, and conversion from trial-to-purchase improved by 50%. The push notifications and emails I’d set up to remind users of the trial expiration didn’t have a strong negative effect on trial cancellations, which was a relief.

But the downstream effect on LTV was the more interesting story: most of Mimo’s trials and purchases were happening during onboarding. Users who started a trial and didn’t cancel were our primary paying customers. The secondary segment was coming through a discount campaign later. So by dramatically increasing the number of users opting in and converting at full price, we shifted the plan mix: more users paid full price rather than a discounted rate. The improvement in trial conversion rate cascaded directly into an LTV lift.

The general principle: paywall changes don’t just move trial and/or purchase rates. They shift who pays, how much, and at which stage of their journey.

Price changes don’t just change revenue

When we raised Mimo’s yearly price by 20%, the obvious effects were higher ARPU and higher subscriber LTV, as the conversion rate hadn’t changed. But pricing changes also shift how users distribute across plans. A more expensive annual plan makes the monthly plan look like a lower-commitment alternative (which most of your users need at the beginning), and affects renewal behavior down the line.

These distribution effects are often invisible in short-term (30-day) analysis, so you need to model them across the full cohort lifecycle.

I’ve also seen the reverse: prices that are way too high for where the app sits in users’ minds. Most users won’t have had a deep (or any) experience with the product by the time they hit the paywall. For better or worse, your app has already fallen into a mental category with a certain willingness-to-pay before they even open it. If the price doesn’t match that expectation, you can:

1. Lower your price
2. Make sure you nail communicating the value through your onboarding, before the paywall
3. Do both of the above

Lowering the price can sometimes be the price you need to pay to get those first paying customers in. From there, you can analyze these segments, how they use the product, and whether they derive any value from it. This paves the way to the product-market and product-model fits.

It’s not every app’s case, and most of the time, increasing the price is what apps end up doing, but if your users are telling you that’s why they’re not upgrading, I recommend treating it as an investment in the insights you need.

The general principle: A price change can reshape your subscriber mix, not just your ARPU. The right price isn’t the highest price the market will bear, it’s the one that attracts users with the intent and means to stay.

Offering a trial on only one plan can change how users perceive other plans

Similarly, offering a free trial only on the yearly plan makes the yearly plan more attractive, which is usually the goal, as we want a higher share of yearly subscribers.

But depending on your target markets and demographics, users who aren’t ready to commit to a year, who still feel anxious about trials (no matter how much reassurance you add), and who are unsure about the product value, might be treating the monthly plan as their trial. They subscribe for a month to test the product, cancel immediately to avoid being charged on the stores’ schedule rather than their own, and leave silently.

The monthly conversion numbers look fine; you see your total active subscribers number growing, but the churn rates a month later tell the real story.

If this sounds (or looks) like your reality, start asking your short-plan customers why they are canceling. It might be they see no other way to try out your paid plan, but believe they’ll re-subscribe later if they like it.

The general principle: some users might treat shorter plans as a trial run. Learn if this is happening, and make sure to separate ‘real churn’ from plan upgrades.

Trial duration is not universal

Data from RevenueCat’s State of Subscription Apps report shows shorter trials have huge day 0–1 cancellation spikes (over 55% for three-day trials vs. 31% for 30-day trials), but there is no universal trial length that will boost conversion. The right trial length depends on your product’s activation curve, which is invariably linked to your app category.

Put simply, three-day trials can work well for utilities and for weekly plans, where time-to-value is short, and users quickly know whether they want to continue. Seven or 14 days often work better for education and health apps, where habit formation takes more time.

At Mimo, we were offering 30-day trials for a long time. Trial opt-in rates were high, but by day 30, so were the cancellation rates: users assumed they’d exhausted the content, or they hadn’t built a habit and drifted away. Shortening the trial to 14 days and communicating the depth of content more clearly helped address this.

The general principle: trial length should match your product’s activation curve, not your optimism about how quickly users will fall in love with it. A longer trial doesn’t automatically mean better conversion. If users aren’t getting activated and retained, you’re just giving them more time to cancel.

Layout and design should help address purchase barriers

For years, trial timeline screens showing users exactly how and when they’d be charged were among the most successful paywall formats. But it doesn’t have to be the only one.

Do your users understand the trial mechanic? Is trial anxiety a barrier for them? Do they understand the difference between your free and paid plans? Are they even aware of the paid plan? Maybe your free plan is too good, and you’re not pushy with upgrades?

The concerns users have before upgrading should help you prioritize experiments between premium feature lists, benefit-led copy, explanations of how the trial works, and promising the reminder or social proof and cancellation policy FAQ. Start from the upgrade barriers and find a way to solve them with design and copy.

Last year, I came up with this ‘paywall anatomy’ to visualize the multiple areas one can leverage. In my experience, most of the leverage lies in pricing and packaging.

Interdependency #2: acquisition quality flows through the entire funnel

Who you acquire determines how they activate, retain, convert, and refer. Changes to your acquisition strategy don’t just affect CAC but many other downstream metrics, often with a delay that makes the connection easy to miss.

Creative concepts aren’t just for solving ‘the click problem’

At Mimo, our earlier ads were animated and visually playful. Hook rates and CTRs were good. But cartoon-style visuals were likely signaling ‘game’ and ‘easy’ rather than ’serious learning tool’, which subtly suppressed the intent of users who did download.

When we shifted toward more professional imagery and videos in ads and store listings — cleaner, expert-looking, with more prominent references to coding — we didn’t just see top-funnel improvements. The profile of users entering the funnel changed. Also, over time, this helped us shift the narrative that learning to code on mobile was not only possible but also worth paying for, before we rebranded a few years later.

The general principle: the creative that brings someone in sets their expectations for everything that follows.

Seasonal campaigns and discounts can bring high-volume, but low-intent cohorts

Seasonal moments are real: Q5 with New Year resolutions, Black Friday sales, or Back-to-School. Conversion rates are naturally better, and revenue spikes. It feels great. But the problem can manifest as subscriber churn a few months later.

Users acquired during such seasons often have strong momentary motivation but lower sustained intent. I worked with a few apps where paying subscribers who started in late December would barely open the app in January. The revenue was real, but the retention wasn’t.

Similarly, frequent discounting generates revenue in the moment while degrading your customers’ LTV.

Here’s the dynamic I often see when teams try to ‘manipulate’ growth by attracting users and customers via cheaper ad networks, false claims in ads, and non-stop discounts, until users develop ‘discount blindness’:

The general principle: observe your subscriber cohorts over their lifetimes, not just at the outset. Check trends from previous years to see how the seasonal cohorts developed, as not all revenue is created equal.

Interdependency #3: what happens inside the app doesn’t stay inside the app

User retention doesn’t just affect users’ and customers’ lifetimes. It can also flow back up the funnel in ways that are easy to miss.

The language barrier was costing us across every metric

Years ago, we decided to localize the Mimo app into six languages after testing it in two languages. The intent was to remove the language barrier for users who were already downloading the app and had already cleared many psychological hurdles: thinking they weren’t smart enough, or young enough, or were bad at math, or that coding just wasn’t for them.

The positive results rippled up through the entire funnel. A better in-app experience led to higher ratings and reviews, which increased our download conversion rate and helped lower blended CAC. Better retention in core markets (D7 retention increased by +40% on average), and to a 25%-100% increase in purchase rate.

The lower the market’s adoption of English, the higher the activation metrics moved. An activation and retention investment became a lever across the full funnel.

The general principle: activation and retention improvements don’t stay in their layers. They impact CAC, organic growth, and word-of-mouth.

Where you invest in retention depends on where your revenue actually comes from

We invested significant effort into managing churn and improving subscriber retention by implementing payment-failure reminders, trial-expiration reminders, extensive value messaging via automated lifecycle campaigns, and in-app cancellation flows to reactivate users and customers. None of it significantly moved the needle on LTV.

In hindsight, this was not truly necessary. Most of our revenue at that stage came from new subscriptions, and the churn cohorts simply weren’t large enough to drive a meaningful uplift, even if we convinced them to stay.

These days, some of these solutions are much easier to implement. I’d recommend covering your bases with:

• Adding subscription benefits on Google Play
• Utilizing Apple’s Retention Messaging API
• Improving handling of refund requests on the App Store
• Introducing automated (or personal) emails asking for trial and purchase cancellation reasons

The general principle: subscriber retention optimization is the right investment when recurring revenue is a significant portion of your total revenue, or when you’ve hit your growth ceiling (when the number of churning subscribers starts exceeding the newly acquired ones). Before that, you might be solving a problem that doesn’t exist.

Interdependency #4: organic loops for lowering blended CAC

Viral and organic levers feel like free growth. But, most of the time, they have natural ceilings set primarily by your product category and your users’ actual behavior. And it’s worth testing at a small scale before a big investment.

3x our k-factor wasn’t the win it sounds like

We rebuilt our referral program: double-sided rewards, 14 days of free premium for both parties, simplified sharing options, and multiple bug fixes to ensure rewards are delivered. These efforts tripled our k-factor.

Tripling sounds significant. But, in this case, a triple from 0 was still pretty much 0. The work was directionally correct and cost-effective. We didn’t let it distract us from the primary focus after we determined it wouldn’t be a significant growth driver.

The general principle: the ceiling is usually determined by your app’s category, your target segment, and how much they want to and can share the word about your app. Less often by the size of the reward.

Content sharing requires the product to be built for it

At Mimo, we were among the first apps to implement the share-to-stories feature, working directly with Facebook when the feature was still in beta. We embedded sharing buttons at aha! moments throughout the user journey, such as starting and continuing a streak, moving to a higher league, and other milestones. Many users were motivated by it and shared their progress on social media daily.

But I’ve seen this feature fail when working with other apps or trying to add it to other parts of the journey. It works when the product generates genuinely shareable moments: when progress is visible, meaningful, and something the user actually wants to show off (for example, this was not the case with Playgrounds, where users could practice and build their projects but were far from being proud of them).

The general principle: you can’t retrofit shareability. Sharing buttons on top of a mediocre experience just get ignored. The foundation needs to be users feeling proud of their progress.

What actually grew our LTV, and three questions before every experiment

Ultimately, over about three quarters, we managed to reverse the trend and grow cLTV by 65%, decrease paid CAC by 20%, and increase monthly proceeds by 35%. In less than 12 months, we were back on track, with a healthy blended LTV/CAC ratio, which we maintained for the years ahead.

For the record, here’s what ultimately moved the needle at Mimo:

• The honest trial paywall: doubled trial opt-in, lifted purchase rate by 53%, and improved LTV by increasing the percentage of full-price subscribers
• Change in creative direction: changed the perception of users entering the funnel via ads and search visibility on the stores
• Localization: produced retention and conversion improvements and positive effects at the top of the funnel
• A 20% yearly plan price increase: raised ARPU and cLTV, while we monitored the distribution shift and conversion rates carefully
• Improvements in organic acquisition: extensive ASO work, as well as less meaningful initiatives such as increasing the referral program’s efficiency and implementing a content-sharing loop
• Many other improvements that compounded

None of the above are universal prescriptions. But there is a discipline: understand what you’re testing, track what it changes beyond the primary success metric, and follow the KPIs all the way down (or up) the funnel.

Before making a change, ask:

1. What is the expected first-order effect and primary KPIs?
2. What’s the downstream consequence and secondary KPIs: plans distribution, user intent level, cohort quality, etc.?
3. What might get worse as a result of this getting better, aka the tradeoffs?

The dangerous scenario is when you optimize aggressively in one area, see a metric improve, declare a win, and miss the lagging negative effects elsewhere. Seasonal campaigns look like wins in December and early January. Heavy discounting makes you feel like a monetization genius until the cohort’s LTV matures and users start complaining.

There’s no playbook.

The apps that scale well aren’t the ones that find the best individual tactics. They’re the ones that build the clearest picture of how their funnel and value delivery actually work, then optimize with this picture in mind.

Both platforms restrict promo codes to free trials and introductory pricing. Neither supports percentage-off or fixed-amount discounts on your regular subscription price. If you want to offer 30% off to a win-back segment, the web is the only place you can do it.

Flexible Discounts for Web Billing is now available to all RevenueCat Web customers. You can create and manage percentage-based discounts and promo codes directly from your dashboard and apply them via URL, through the SDK, or via a code input field through the checkout UI.

Control your pricing on the web

With Flexible Discounts, you can create percentage-based discounts and manage specific discount codes (like “SUMMER30”) directly from your RevenueCat dashboard. When you create a discount, you control exactly how long it lasts.

You have three duration options:

• One-time: The discount applies only to the user’s first invoice.
• Forever: The discount applies to all future invoices indefinitely.
• Time-window: The discount applies to all invoices generated within a specific calendar period (e.g., all invoices within the next 3 months).

The time-window duration is calendar-based, not cycle-based. If a user buys a weekly subscription with a 1-month discount, they get the discount on the initial purchase and the renewals within that month. If they buy an annual subscription with a 1-month discount, they only get the discount on the first payment.

How it works

Discounts can be applied in three ways:

• URL parameter: Append the code to your Web Purchase Link (e.g., ?discount_code=SUMMER30). This is ideal for email campaigns, influencer links, and targeted landing pages where the discount is pre-applied.
• SDK: Apply discounts programmatically via the RevenueCat SDK for in-app or server-side flows.
• Checkout UI: End users can enter a promo code directly in the web checkout field.

You can also control exactly where the coupon field appears. Visibility is configurable per Web Purchase Link or Funnel checkout, so you only show it when it makes sense for that flow.

Discount codes can be scoped to specific products or applied globally across all products. Eligibility criteria can also be configured to control which users can redeem a given discount.

Discounts do not stack with introductory offers or trials. If a discount is applied, any configured intro offer is ignored.

Funnels support and discount code analytics are on the way. Head to your RevenueCat dashboard to set up your first discount code, or read the docs to get started.

The iOS integration now flows through Gradle-managed Swift package dependencies, the purchases-kmp-datetime add on is folded back into the main module, and the Android side jumps directly to purchases-android 10.x with Play Billing 8.3.0. This release also resets the minimum versions: Android 6.0 (API 23), Kotlin 2.3.20, and Compose Multiplatform 1.9.3.

In this article, you’ll explore what changed in 3.0.0 and why, the new iOS architecture built on the kn-core and kn-ui facade modules, the step by step migration from a 2.x project that still ships a Podfile, the datetime module removal and its kotlin.time.Instant replacement, the Amazon Appstore opt in change, the Android Billing 8.3.0 caveat for restored consumable purchases, and the new PostHog user ID setter.

What changed at a glance

Before 3.0.0, a Kotlin Multiplatform app using RevenueCat had two parallel native integrations. The Android target pulled in purchases-hybrid-common from Maven Central, which transitively pulled purchases-android. The iOS target pulled in PurchasesHybridCommon and optionally PurchasesHybridCommonUI through CocoaPods or Swift Package Manager, and you had to keep its version in sync with the version that your KMP release was built against. The “common files version” column in the SDK’s VERSIONS.md history is a long record of that constraint, and the version string on each 2.x release was a composite like 2.10.2+17.55.1 to make the pairing explicit.

3.0.0 collapses that pairing. The iOS target now builds directly against the native purchases-ios Swift package via a Kotlin/Native cinterop binding generated by Gradle. The Android target depends on purchases-android 10.4.0 directly, with Play Billing 8.3.0 included as a transitive dependency. There is no more “hybrid common” intermediate layer to pin, and the version table in VERSIONS.md shows Common files version: N/A for 3.0.0 for that reason.

The headline numbers:

The good news for application code: the public API surface of Purchases, CustomerInfo, Offerings, StoreProduct, and the rest of the model layer is unchanged. Most of the migration effort lives in your build files, your Xcode project, and a couple of import lines on the temporal accessors.

The new iOS architecture: Gradle owns the Swift dependency

The iOS rewrite is the largest change in this release, and it is the change that motivates almost every other one. Before walking through what to remove, it helps to understand what the new architecture actually does.

Two new Gradle modules ship inside the SDK: kn-core and kn-ui. The kn stands for Kotlin/Native, and these modules exist for one reason: to declare the iOS Swift dependency on purchases-ios so that Gradle can generate the Kotlin/Native cinterop bindings against it. If you examine the kn-core module’s build file:

plugins {
    id("revenuecat-library")
}

kotlin {
    sourceSets {
        iosMain.dependencies {
            swiftPackage(
                path = rootProject.file("upstream\/purchases-ios"),
                target = "RevenueCat",
                packageName = "swiftPMImport.com.revenuecat.purchases.kn.core",
                customDeclarations = """
                    \/\/ Force cinterop binding generation for types otherwise not in the public API
                    static inline int __forceBindings(
                        enum RCStoreMessageType _1
                    ) { return 0; }
                """.trimIndent(),
                swiftSettings = SwiftSettings {
                    define("BYPASS_SIMULATED_STORE_RELEASE_CHECK")
                }
            )

            swiftPackage(
                path = file("src\/swift"),
                target = "AdditionalSwift",
                packageName = "swiftPMImport.com.revenuecat.purchases.kn.core.additional"
            )
        }
    }
}

Two things are worth pointing out.

First, the swiftPackage block is a custom Gradle DSL defined inside the SDK’s build-logic. It tells the build to compile a Swift target out of the purchases-ios checkout, then run cinterop against its generated Objective C headers, and finally expose the result under the Kotlin package swiftPMImport.com.revenuecat.purchases.kn.core.

Second, purchases-ios is consumed as a git submodule at upstream/purchases-ios. The 3.0.0 release pins that submodule to version 5.71.0. You do not need to clone it yourself when you use the published SDK artifact: the bindings are pre generated and the Swift sources are compiled when the SDK is published. From the application developer’s point of view, you simply add a Gradle dependency on com.revenuecat.purchases:purchases-kmp-core and everything else flows through Gradle.

The kn-ui module follows the same pattern for the SDK’s UI support, plus a Compose Multiplatform dependency for the Kotlin paywall composables:

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation(compose.components.resources)
            implementation(compose.runtime)
        }

        iosMain.dependencies {
            swiftPackage(
                path = rootProject.file("upstream\/purchases-ios"),
                target = "RevenueCatUI",
                packageName = "swiftPMImport.com.revenuecat.purchases.kn.ui",
                swiftSettings = SwiftSettings {
                    define("COMPOSE_RESOURCES")
                }
            )
        }
    }
}

The practical consequence is that your Xcode project no longer needs to know about RevenueCat at all. The framework that lands in your iOS app is the same Kotlin framework that contains your shared code, and the RevenueCat symbols are already statically linked into it through the Kotlin/Native bindings. You do not import PurchasesHybridCommon in Swift, you do not import RevenueCat in Swift, you simply call the shared Kotlin API from Swift the same way you call any other shared Kotlin symbol.

Migration step 1: Remove the iOS hybrid common dependency

The first concrete change is to remove the iOS dependencies that 3.0.0 no longer needs. The instructions differ depending on whether you added them through Swift Package Manager or CocoaPods, and the SDK ships both paths in the official migration guide.

If you used Swift Package Manager, open Xcode, select your project in the navigator, click Package Dependencies, then select PurchasesHybridCommon and PurchasesHybridCommonUI and remove them with the minus button. There is nothing else to do on the Xcode side. The Kotlin framework that your shared module produces already pulls in purchases-ios through Gradle, so removing the SPM entries does not leave your iOS target without a RevenueCat dependency.

If you used CocoaPods, the removal is in two places. The Podfile at your iOS project root might contain:

pod 'PurchasesHybridCommon', '17.21.2'
pod 'PurchasesHybridCommonUI', '17.21.2'

Delete those lines and run pod install once to update your Podfile.lock. Then check your Gradle build, because the KMP project might have been using the Kotlin CocoaPods plugin to declare the same dependency:

pod("PurchasesHybridCommon") {
    version = "17.21.2"
    extraOpts += listOf("-compiler-option", "-fmodules")
}
pod("PurchasesHybridCommonUI") {
    version = "17.21.2"
    extraOpts += listOf("-compiler-option", "-fmodules")
}

These blocks are the most common source of stale state when migrating, because they live in a Gradle file rather than in the iOS project itself. Search your KMP build.gradle.kts files for pod( and remove every entry that references PurchasesHybridCommon or PurchasesHybridCommonUI. If after that removal you have no pod( blocks left at all, you can remove the cocoapods plugin and the cocoapods { ... } configuration block from the KMP module entirely, which also removes the need to run pod install as part of your KMP build.

The end state on iOS in 3.0.0 is a shared module that declares its iOS targets with regular iosX64(), iosArm64(), iosSimulatorArm64() framework configurations and no CocoaPods plugin. The SDK’s own sample app does exactly that. Its iOS source set declares the framework and nothing else:

listOf(
    iosX64(),
    iosArm64(),
    iosSimulatorArm64()
).forEach { iosTarget ->
    iosTarget.binaries.framework {
        baseName = "ComposeApp"
        isStatic = true
    }
}

Migration step 2: Replace the datetime module with kotlin.time.Instant

The purchases-kmp-datetime module was a small companion artifact that added extension properties for converting the SDK’s millisecond timestamps into kotlinx.datetime.Instant values. Since 2.2.0+17.8.0, the recommended approach has been to use kotlin.time.Instant instead, and the previous kotlinx.datetime accessors were deprecated. In 3.0.0, the deprecated accessors are removed.

In 3.0.0, the same functionality lives in the main module and uses the kotlin.time.Instant type from the Kotlin standard library. It is annotated with @ExperimentalTime because that type itself is still experimental in the standard library.

If you upgrade through an intermediate 2.x version first, Android Studio can often auto-apply these renames via the @Deprecated(ReplaceWith = ...) hints. Otherwise, the replacement is mechanical. Find any usage of an Instant suffixed property in your code, for example firstSeenInstant, and rename it to drop the suffix: firstSeen. Then add the experimental opt in either at the file level or at the call site:

@file:OptIn(ExperimentalTime::class)

import kotlin.time.ExperimentalTime
import kotlin.time.Instant

fun describeUser(info: CustomerInfo) {
    val seenAt: Instant = info.firstSeen
    val latest: Instant? = info.latestExpirationDate
    println("First seen at $seenAt, latest expiration $latest")
}

The import line is the second thing to watch. kotlinx.datetime.Instant and kotlin.time.Instant are different types in different packages, so if you switch the property name but forget to switch the import, the compiler points you at the right fix immediately. Make sure your import line reads import kotlin.time.Instant and not the kotlinx.datetime one. After that, remove the purchases-kmp-datetime dependency from your libs.versions.toml and your build.gradle.kts files.

If you look at the source of CustomerInfo in 3.0.0, you can see how the millisecond fields and the Instant accessors now live side by side in the same class, with the latter computed lazily from the former:

@ExperimentalTime
public val firstSeen: Instant by lazy {
    Instant.fromEpochMilliseconds(firstSeenMillis)
}

@ExperimentalTime
public val latestExpirationDate: Instant? by lazy {
    latestExpirationDateMillis?.let { Instant.fromEpochMilliseconds(it) }
}

@ExperimentalTime
public val originalPurchaseDate: Instant? by lazy {
    originalPurchaseDateMillis?.let { Instant.fromEpochMilliseconds(it) }
}

firstSeenMillis, latestExpirationDateMillis, and the rest of the *Millis companions remain public and stable. If you do not want to opt into the experimental API, you can keep using the millisecond fields directly and do your own conversion. The Instant accessors are a convenience layer, not a required path.

The same pattern applies across EntitlementInfo, SubscriptionInfo, and Transaction. Every temporal accessor on these classes is annotated @ExperimentalTime, and every one returns a kotlin.time.Instant. If you previously had a serialization layer that mapped kotlinx.datetime.Instant to a wire format, you have two options. Either map from kotlin.time.Instant going forward, or stay on the *Millis accessors and serialize the long values directly. The latter is the safer choice if your serialization library does not yet have a converter for kotlin.time.Instant.

(Optional) Migration step 3: Add the Amazon Appstore module explicitly

In 2.x, the Android target of purchases-kmp always pulled the Amazon Appstore support along with it, even if your build only ever shipped to Google Play. In 3.0.0, Amazon support is opt in and lives in its own artifact, com.revenuecat.purchases:purchases-store-amazon. If your KMP app does not ship to the Amazon Appstore, you do not need to add anything. If it does, the migration is a two line addition.

In gradle/libs.versions.toml:

purchases-amazon = { module = "com.revenuecat.purchases:purchases-store-amazon", version = "x.y.z" }

And in your Android source set of the KMP module:

kotlin {
    sourceSets {
        androidMain.dependencies {
            implementation(libs.purchases.amazon)
        }
    }
}

The Amazon module is published from the purchases-android repository, not from purchases-kmp. Use the version that matches the purchases-android version pulled in by your KMP release. For 3.0.0, that is 10.4.0. RevenueCat’s installation docs list the current version next to the Maven coordinate, so check there if you are pinning explicitly.

If you forget this step on a build that previously shipped to Amazon, the symptom is a runtime check inside Purchases.configure(...) that complains the Amazon store is not registered. The compile passes because the SDK’s public API does not reference Amazon classes directly. It is worth running your Amazon build variant through a smoke test after the upgrade for this reason.

Migration step 4: Raise Android minSdk to 23 and adopt Billing 8.3.0

The Android side of 3.0.0 ships with Play Billing Library 8.3.0 through purchases-android 10.4.0. That bumps the SDK’s minimum supported Android version from API 21 to API 23 (Android 6.0). If your KMP app still advertises a minSdk of 21 or 22 in its Android source set, the merged manifest will fail to compile with an uses-sdk:minSdkVersion 21 cannot be smaller than version 23 declared in library [com.revenuecat.purchases:purchases-android-...] error.

The fix is to raise your minSdk to 23:

android {
    defaultConfig {
        minSdk = 23
    }
}

The device tail below API 23 has been a fraction of a percent for several years, and most app teams have already crossed this line for unrelated reasons. If you have a hard requirement to keep API 21 support, you cannot upgrade to KMP 3.0.0 yet. Stay on the 2.x line until that requirement is removed.

There is one behavior change inside Billing 8.x that is worth flagging even though it is technically in purchases-android, not in purchases-kmp. The 3.0.0 release notes call this out explicitly:

This release updates to Billing Library 8.3.0 with min SDK supported of Android 6 (API 23), previously min was 21. It also removes a previous workaround used to be able to restore consumed one time products which is not available anymore.

The workaround in question was a path inside the older Billing Library that allowed purchases-android to surface already consumed one time products when a user called restorePurchases. Play Billing 8.x no longer exposes consumed purchases, and there is no longer a way for the SDK to reconstruct them client side. For more detail (and the recommended approach for consumables), see the RevenueCat docs.

Toolchain upgrades: Kotlin 2.3.20, Compose Multiplatform 1.9.3, Gradle 9.4.1

3.0.0 raises the floor of every part of its build toolchain. The SDK itself compiles on:

• Kotlin 2.3.20
• Compose Multiplatform 1.9.3
• Gradle 9.4.1

You do not strictly need to match every one of these in your app, but Kotlin and Compose Multiplatform are constraints because they ship metadata that the consumer side has to be compatible with. In practice, that means you cannot consume KMP 3.0.0 on a project pinned to Kotlin 2.1 or earlier, and you cannot consume the kn-ui paywall composables on a project pinned to an older Compose Multiplatform that does not yet have the matching compiler plugin.

A complete before and after of a KMP module

To pull all of this together, here is what a typical KMP module’s build file looked like in 2.x with the iOS hybrid common and datetime dependencies declared:

plugins {
    alias(libs.plugins.kotlin.multiplatform)
    alias(libs.plugins.android.library)
    alias(libs.plugins.kotlin.cocoapods)
}

kotlin {
    androidTarget()
    iosX64()
    iosArm64()
    iosSimulatorArm64()

    cocoapods {
        ios.deploymentTarget = "13.0"
        framework { baseName = "Shared" }
        pod("PurchasesHybridCommon") {
            version = "17.21.2"
            extraOpts += listOf("-compiler-option", "-fmodules")
        }
        pod("PurchasesHybridCommonUI") {
            version = "17.21.2"
            extraOpts += listOf("-compiler-option", "-fmodules")
        }
    }

    sourceSets {
        commonMain.dependencies {
            implementation(libs.purchases.core)
            implementation(libs.purchases.datetime)
            implementation(libs.purchases.ui)
        }
    }
}

The same module in 3.0.0 drops the cocoapods plugin and the pod(...) declarations, drops the purchases-kmp-datetime dependency, and adds an explicit Amazon dependency only on the Android source set if needed:

plugins {
    alias(libs.plugins.kotlin.multiplatform)
    alias(libs.plugins.android.library)
}

kotlin {
    androidTarget()
    iosX64()
    iosArm64()
    iosSimulatorArm64()

    sourceSets {
        commonMain.dependencies {
            implementation(libs.purchases.core)
            implementation(libs.purchases.ui)
        }
        androidMain.dependencies {
            implementation(libs.purchases.amazon)
        }
    }
}

The Xcode side is similarly empty of RevenueCat configuration. Your Podfile no longer needs PurchasesHybridCommon or PurchasesHybridCommonUI entries, and if those were the only pods you had, you can stop running pod install entirely.

Verifying the migration

A few checks worth running after you make the changes above:

1. Run a full clean build on Android and iOS. The Kotlin compiler points you at any remaining Instant accessor that you forgot to rename, and the build fails fast if a stale pod(...) block still references PurchasesHybridCommon.
2. Open the merged AndroidManifest and confirm com.google.android.play.billingclient.version is now set to 8.3.0.
3. On iOS, search your Xcode project for PurchasesHybridCommon. There should be zero hits in Package.swift, in your project’s Package Dependencies list, and in your Podfile. The only RevenueCat symbols visible to Swift should be those re exported through your shared Kotlin framework.
4. Run a smoke test on a real device against a sandbox account. Configure the SDK, fetch offerings, present the paywall, and complete a purchase. The 3.0.0 release ships a Maestro E2E sample under e2e-tests/MaestroTestApp if you want a reference for an end to end test flow.
5. If your app ships to the Amazon Appstore, confirm the Amazon variant still works. The runtime check inside Purchases.configure is the canary if you forgot the purchases-store-amazon dependency.

Conclusion

In this article, you’ve explored the architectural shift that defines RevenueCat Kotlin Multiplatform SDK 3.0.0: you no longer need to worry about keeping the PurchasesHybridCommon version matched, the purchases-kmp-datetime module is folded into the main module behind the experimental kotlin.time.Instant type, the Android target ships with Play Billing 8.3.0 with a minSdk of 23, the Amazon Appstore is opt in, and the toolchain floor rises to Kotlin 2.3.20 and Compose Multiplatform 1.9.3.

The goal of purchases-kmp 3.0.0 is to make integrating the library as convenient as it should be. Please let us know what you think! All thoughts, comments and remarks are welcome.

The standard freemium diagnostics don’t help much here. Conversion rate, paid penetration, and LTV — they all measure what your paying users are doing. None of them tell you whether your non-paying users are an asset or dead weight.

On a recent episode of the Sub Club podcast, Opal CEO Kenneth Schlenker shared the question he uses instead: would a non-paying user recommend the app to a friend?

If the answer is no, you need to give away more.

Why this question matters more than conversion rate

“If you want the freemium dynamic to really pay out, you need to make sure that the free users are recommending the app,” Kenneth says. “Otherwise, that doesn’t work.”

Freemium works only if free users stick around long enough to build a habit and recommend the app. If your free tier is too restrictive — it’s missing core features to achieve users’ job-to-be-done, or it just feels like a countdown to a paywall rather than a useful product — then neither happens. You get a small percentage converting to paid and zero organic pull.

That’s the trap. A free tier designed to demo the product instead of be a product.

Watch on Wistia

How to actually answer the question

The recommendation question is a heuristic, not a metric. But you can triangulate toward an answer by watching two things in parallel:

1. LTV of installs
2. Overall retention across both free and paid users

When Opal tested how much to give away in their core ‘blocks’ feature — the scheduled restrictions that block distracting apps during specific times — the team tried everything from one block (very restrictive) to several, measuring these two metrics at every step.

The goal was to find the point where both metrics were moving up. Rather than focusing on just paid conversion, or free-to-paid funnel efficiency, this would show the combined health of the user base.

“Turns out that three [blocks] is enough for free users to get a great experience,” Kenneth explains. “They can actually really use the app, try out a few different things, and then also really power users that are convinced will pay because they want more.”

Three blocks gave non-payers enough utility to build a habit — and recommend the app. It also left enough headroom that committed users still had a reason to upgrade. If LTV and retention don’t both improve as you adjust your free tier, you’re optimizing one segment at the other’s expense.

What ‘yes’ actually unlocks

When Opal moved from a hard paywall to a genuinely generous free tier, their pay penetration — the share of monthly active users on a paid plan — dropped from 20% to 9%. That sounds like a disaster, but it wasn’t.

The free tier unlocked a segment Opal couldn’t reach behind a paywall: high school and college students, who now make up two-thirds of Opal’s DAUs. These users dragged pay penetration down — but they were doing something more valuable: telling their classmates, then telling their schools. Students recommending the app to administrators created Opal for Schools, now a contracted B2B revenue line. That distribution channel didn’t exist when there was only a hard paywall.

Overall, the shift pushed Opal past one million daily active users. “It’s a short-term, scary drop, but what happens in the long-term is that it pays back tenfold,” Kenneth says.

The takeaway

If your non-payers wouldn’t recommend the product, you don’t have freemium — you have a trial in disguise.

The fix isn’t always to give away more. Sometimes it’s to give away differently — more of one feature, less of another, restructured so the free experience is genuinely useful rather than a teaser. But the recommendation question is the compass. Pair it with parallel tracking of LTV and overall retention, and you have a way to find the line for your own product.

Think about:

1. Does it unlock enough utility to build a habit or progress towards their goal?
2. Does it unlock enough to make them recommend the app?
3. Does it keep enough back to give users a reason to upgrade?

Most teams optimize their free tier to maximize conversion. The teams that win optimize it to maximize recommendation, and let conversion follow.

Six months into his role as VP of Product at Life360, Giordano Contestabile ran an experiment. The numbers came back showing a massive revenue upside. He ran to the executive team, expecting a celebration. Instead, he got yelled at.

Watch on YouTube

He had violated what former CEO Chris Hulls called the “freemium bill of rights” — a core set of principles dictating that certain features, particularly those related to family safety, must never be taken away from free users to force a conversion.

“The reason number one why people tell us they don’t subscribe is because the free tier is good enough,” Contestabile says. “Our philosophy is that literally we want to do something about it, but that something is not making the free tier worse — is trying to provide more value and really diversify the subscription offering.”

For an app with nearly 100 million monthly active users, that free tier is the ultimate moat. Life360 relies heavily on network effects; the app isn’t useful in “solo mode,” and the primary discovery channel is parents telling other parents. Locking core utility behind a paywall might juice short-term revenue, but it would fundamentally break the viral loop that built the company.

Why an inconclusive experiment is the only true failure

To find new ways to drive revenue without degrading the free experience, Life360 had to scale its experimentation. But Contestabile doesn’t view experimentation as a series of isolated tests; he treats it as a portfolio.

The effectiveness of that portfolio comes down to three levers: velocity (how many experiments ship), win rate (what percentage succeed), and average win size. But surprisingly, Contestabile doesn’t mind a low win rate.

“The only experiments that we are sad about is an experiment that is inconclusive,” he explains. “Then we feel we wasted our time — we didn’t set up the experiment correctly or the hypothesis wasn’t right.”

A loss, on the other hand, is just data. It proves or disproves a hypothesis. Often, a losing experiment reveals that a feature didn’t work broadly, but resonated deeply with a specific cohort — like users in the suburbs who have been on the platform for a month and own a dog.

Those granular learnings feed directly into the next cycle of tests.

How ML doubled Platinum subscriptions

That granular approach to segmentation recently led to one of Life360’s biggest wins.

The app offers three subscription tiers: Silver, Gold, and Platinum. Historically, the vast majority of users chose Gold. In paywall flows, it’s difficult to clearly articulate the value of all three tiers without overwhelming the user, so the team typically defaulted to presenting the Gold option.

To challenge this, the team deployed a machine learning model utilizing about 900 distinct data points to identify users with a high propensity to buy the Platinum tier. When the model detected a high-propensity user, it dynamically presented the Platinum offer instead of Gold.

The results were staggering. “It doubled the percentage of new users subscribing to Platinum,” Contestabile says. “But it did that without losing a single gold subscriber, which was super surprising.”

The model successfully identified users who wouldn’t have converted on the Gold tier anyway, but were perfectly matched for the specific benefits of Platinum.

Parents aren’t viral

Not every data-driven bet pans out. Knowing that 40% of Life360’s users discovered the app through word-of-mouth — usually parents talking at school pickup — the team tried to digitize that behavior.

They built in-app referral mechanics. They offered free Silver subscriptions to users who invited friends. They tested multiple variations of sharing buttons.

“Nothing. Really failure across the board,” Contestabile admits. “And the reason is people my age, families, older people — they are not viral. Parents are not viral.”

The demographic that actually exhibits viral sharing behavior on mobile devices are teenagers. But while teens are on Life360, the parents are the ones making the purchasing and installation decisions. The team learned the hard way that you can’t force a digital referral loop onto an audience whose natural sharing behavior is entirely offline.

In the full episode, Giordano and David also discuss how Life360 incorporates physical hardware like Tile into its subscription ecosystem, why the company is pushing to make growth a mandate for every department including HR and Finance, and the strategic value of the new “pet profile” feature.

Guest links:

• Giordano Contestabile on LinkedIn
• Life360
• Life360 Careers

In this article, you’ll work through a complete subscription testing setup for a Compose Multiplatform app, exploring why Google Play and StoreKit sandboxes resist unification, how RevenueCat’s Test Store collapses both into one sandbox, how to wire the Test Store into a KMP build with a single BuildConfig field, why the right testability boundary is a PaywallsRepository interface in commonMain, how to write coroutine and StateFlow tests in commonTest so a single suite runs against both targets, why fakes beat mocks for KMP subscription code, and how to layer instrumented tests on top so the same code path is exercised end to end.

Every snippet uses the same source layout as cat-paywalls-kmp, the official CMP demo, so you can drop these patterns into a real project without renaming anything.

The fundamental problem: One product, two sandboxes

Subscription testing on a native Android app is already an undertaking. The ultimate guide to Android subscription testing lists license testers, internal tracks, closed tracks, the android.test.purchased static response, and a handful of BillingClient quirks before you can reliably run a single purchase end to end. The equivalent path on iOS adds StoreKit configuration files, sandbox tester accounts, accelerated renewal cycles, and TestFlight rate limits that change throughout the year.

When the same product ships on both stores, you do not get to pick one of these paths. You run both, and you reconcile the differences yourself. A purchase that goes through in the Google Play closed track does not appear in App Store Connect. A StoreKit Transaction that arrives over the iOS testing pipeline does not flow through your Android PurchasesUpdatedListener. Even when the entire app is one Kotlin codebase, you write two @Test annotations, two CI matrices, and two test data setups.

There is also the unit test gap. Google Play does not expose any way to simulate a purchase inside a JVM unit test. StoreKit configuration files run in the iOS simulator, not in kotlinx-coroutines-test. So even before you worry about cross platform reconciliation, you cannot get a working purchase flow inside commonTest at all. The standard advice is to push everything below the SDK boundary into integration tests, which means most teams end up testing only the parts of their code that do not actually touch Purchases.

Look at the CatArticlesDetailViewModel from the cat-paywalls-kmp demo and you can see the shape of the problem:

class CatArticlesDetailViewModel(
  articleId: Long,
  articlesRepository: ArticlesRepository,
  paywallsRepository: PaywallsRepository,
) : ViewModel() {

  val customerInfo: StateFlow<CustomerInfo?> =
    paywallsRepository.fetchCustomerInfo()
      .map { it.getOrNull() }
      .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = null,
      )
}

This class has real business logic. It decides whether to fade an article body, whether to surface a “Join Now” CTA, what to do when the network call fails, and when to recompose. None of that logic depends on whether the underlying receipt came from Google Play or StoreKit. But if PaywallsRepository.fetchCustomerInfo() only emits values when a real billing SDK is connected to a real store, you cannot reach any of this logic from a unit test. The KMP win disappears at exactly the boundary where you most need it back.

The rest of this article is about getting it back.

The Test Store: A sandbox built into RevenueCat itself

The shortest path out of the two sandbox problem is to stop using the two sandboxes for development purchases. RevenueCat’s Test Store is a sandbox built into the platform itself, not into Google Play or the App Store. You configure it once in the dashboard, set a different API key in your app, and the SDK routes every purchase through RevenueCat’s own purchase modal instead of asking the native store to open its dialog.

The modal it shows is small and deliberate. When the user taps “Subscribe” inside the Paywall composable, the SDK overlays a three button sheet: Test valid purchase, Test failed purchase, and Cancel. Tapping the first one is what a successful purchase looks like from your app’s perspective. The SDK marks the receipt valid on the backend, awaitPurchase resumes with a StoreTransaction, the CustomerInfo flow emits a new value with entitlements["premium"].isActive == true, and your gated UI unlocks the same way it would in production. The other two buttons exercise the failure and cancellation paths without you having to fake an exception by hand.

There is no Play Console setup, no App Store Connect tester account, and no license tester opt in URL. The Test Store works in the simulator, the emulator, debug builds on a real device, and CI runners. Auto renewal still happens, just on accelerated cycles: a monthly subscription renews every five minutes, an annual subscription renews every hour, both stop after five renewals so a test session never runs longer than around five hours. Every Test Store purchase shows up in the same RevenueCat dashboard as production data, which means the same CustomerInfo shape, the same webhook payloads, and the same entitlement transitions you ship against.

Two practical rules. First, you need purchases-kmp 2.2.2 or newer for the Test Store path; the cat-paywalls-kmp demo pins 2.10.2+17.55.1. Second, a Test Store key is a debug only artifact. It looks like test_... instead of goog_... or appl_... and is rejected by the server if the SDK is configured against a production project. Treat it the same way you would treat a debug signing key: useful for development, never in a release.

Setting up the Test Store in a KMP project

The whole setup is one extra BuildConfig field on the Android side and one decision in your Application.onCreate about which key to use. iOS does not need a separate change because the same Kotlin code reads the same configuration when the shared module initializes on the Swift side.

Start with the Gradle build. In composeApp/build.gradle.kts, read the Test Store key from local.properties and expose it through buildConfigField. Pulling the key from a local property file (which is already gitignored by Android Studio) keeps it out of source control by default:

import java.util.Properties

val localProperties = Properties().apply {
  val file = rootProject.file("local.properties")
  if (file.exists()) file.inputStream().use { load(it) }
}

android {
  namespace = "com.revenuecat.catpaywalls"
  defaultConfig {
    applicationId = "com.revenuecat.catpaywalls"
    buildConfigField(
      "String",
      "REVENUECAT_TEST_API_KEY",
      "\"${localProperties.getProperty("revenuecat.test.api.key", "")}\"",
    )
  }
  buildFeatures {
    compose = true
    buildConfig = true
  }
}

Notice the default value of an empty string. If local.properties does not contain revenuecat.test.api.key, the field is still defined and compiles cleanly. That matters for two reasons: release builds pulled from a clean CI checkout do not see the key at all, and any developer who has not opted into the Test Store keeps the regular production path without any source changes.

The local.properties entry on a developer machine is one line:

revenuecat.test.api.key=test_YOUR_KEY_HERE

The key selection happens in CatArticlesApplication, which is the Android entry point for the shared Compose surface. The pattern is “prefer Test Store key when present, fall back to the production key otherwise”:

class CatArticlesApplication : Application() {

  override fun onCreate() {
    super.onCreate()

    Purchases.logLevel = LogLevel.DEBUG
    val apiKey = BuildConfig.REVENUECAT_TEST_API_KEY
      .takeIf { it.isNotBlank() } ?: REVENUECAT_API_KEY

    Purchases.configure(
      PurchasesConfiguration(apiKey = apiKey) {
        appUserId = null
      },
    )
  }

  companion object {
    private const val REVENUECAT_API_KEY = "your_revenuecat_api_key"
  }
}

Two design decisions here are worth pulling out. The first is that the same Purchases.configure call routes either to the Test Store or to production. The KMP SDK does not have a separate “test mode” flag; it picks the backend based on the key prefix and behaves identically otherwise. Your commonMain code never has to ask which backend it is talking to. The second is that this is a debug only ergonomics, not a build flavor. Every developer can flip on Test Store for their personal build by adding one line to their own local.properties, without any branches in the source tree.

The iOS side does not need an analogue. When the Kotlin runtime starts on iOS, it shares the same Purchases.sharedInstance configured by the platform App struct. If you want the iOS app to also use the Test Store during development, configure the same test_... key in the SwiftUI entry point:

@main
struct iosAppApp: App {
    init() {
        Purchases.logLevel = .debug
        Purchases.configure(withAPIKey: testStoreApiKey ?? "your_ios_api_key")
    }
    var body: some Scene {
        WindowGroup { ContentView() }
    }
}

Read testStoreApiKey from an .xcconfig, a Info.plist entry, or a build setting. The shape is the same as on Android: take the key from a local source of truth, fall back to a production constant.

The testability boundary: wrapping Purchases behind a repository

Even with the Test Store wired up, you do not want every unit test to depend on a running Purchases.sharedInstance. The SDK assumes a platform context that is not present in commonTest: an Android Context, a BillingClient, an iOS StoreKit transaction listener. The cat-paywalls-kmp demo solves this by funneling every call into the SDK through a single repository interface in core/data:

interface PaywallsRepository {
  fun fetchOffering(): Flow<Result<Offering>>
  fun fetchCustomerInfo(): Flow<Result<CustomerInfo>>
  fun awaitPurchase(packageId: String): Flow<Result<StoreTransaction>>
}

There are three things to notice about this interface. First, every method returns a Flow<Result<T>> instead of a suspend function. That choice gives StateFlow consumers something to .map and .collect without paying for an extra viewModelScope.launch, and it lets the implementation choose between cold flow semantics and stateIn caching without changing callers. Second, the types in the return positions are all from com.revenuecat.purchases.kmp.models.*. They are pure Kotlin data classes that exist in commonMain, which means a test can construct or hold them without expect/actual gymnastics. Third, there is no platform specific code in the signature, which is what lets the same interface back both androidMain and iosMain consumers.

The production implementation wraps Purchases.sharedInstance with suspendCancellableCoroutine and a small Flow builder. The shape is straightforward:

class PaywallsRepositoryImpl : PaywallsRepository {

  override fun fetchCustomerInfo(): Flow<Result<CustomerInfo>> = flow {
    try {
      val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()
      emit(Result.success(customerInfo))
    } catch (e: Exception) {
      emit(Result.failure(e))
    }
  }.flowOn(Dispatchers.IO)

  override fun fetchOffering(): Flow<Result<Offering>> = flow {
    try {
      val offerings = Purchases.sharedInstance.awaitOfferings()
      val current = offerings.current ?: error("No current offering")
      emit(Result.success(current))
    } catch (e: Exception) {
      emit(Result.failure(e))
    }
  }.flowOn(Dispatchers.IO)
}

This is the only place in the entire codebase that imports Purchases.sharedInstance. Every ViewModel, every Compose function, every test is on the other side of the interface. That is the boundary you need to make commonTest viable, because anything above this line can be exercised against a fake.

Unit testing in commonTest: the patterns that work on both platforms

A Kotlin Multiplatform unit test cannot use MockK, Mockito, or any reflection based mocking framework. Those libraries are JVM only. They will compile in commonTest if MockK is on the version catalog, but the iosTest target will fail to link when Kotlin/Native tries to resolve the bytecode generation runtime. The cat-paywalls-kmp demo even declares MockK in gradle/libs.versions.toml and then never uses it, because the moment you adopt the convention plugin that runs commonTest against both targets you cannot import it from shared code.

What does work in commonTest is kotlin-test, kotlinx-coroutines-test, and Turbine. The cat-paywalls-kmp KmpLibraryConventionPlugin wires them into every feature module at the source set level:

sourceSets.apply {
  commonMain.dependencies {
    implementation(libs.findLibrary("kotlinx-coroutines-core").get())
  }
  commonTest.dependencies {
    implementation(libs.findLibrary("kotlin-test").get())
    implementation(libs.findLibrary("kotlinx-coroutines-test").get())
    implementation(libs.findLibrary("turbine").get())
  }
}

The reason this is in a convention plugin and not in each feature module’s build.gradle.kts is that you want this to be free. Every module that hosts a ViewModel or a state holder needs the same test dependencies, and forcing each module to opt in by hand is exactly the kind of friction that ends with someone writing logic they cannot reach from a test. The plugin makes “write a unit test” the default, not a setup task.

A feature module then only declares what is unique to its tests. For feature/subscriptions, the only extra dependency is core/data, because the test uses the real PaywallsRepository interface:

plugins { id("catpaywalls.kmp.feature") }
android { namespace = "com.revenuecat.catpaywalls.feature.subscriptions" }
kotlin {
  sourceSets {
    commonTest.dependencies {
      implementation(projects.core.data)
    }
  }
}

That is the entire test wiring. From here, you can write a class SubscriptionManagementViewModelTest in feature/subscriptions/src/commonTest/kotlin/... and it will be picked up by androidUnitTest and iosTest automatically. One file, both targets.

Why fakes beat mocks for KMP subscription code

With MockK off the table, your options are hand written fakes or expect/actual mock factories. The cat-paywalls-kmp demo picks fakes for every test, and the choice is more deliberate than it looks. Subscription code has two properties that make fakes the better fit even in a JVM only project. First, the surface area of PaywallsRepository is small. Three methods, all returning Flow<Result<T>>. There is nothing to mock that a small data class with a few setters cannot already express. Second, the same fake is reused across many tests with different setup, which makes a stateful builder more readable than a stack of every { ... } returns ... lines.

Here is what the canonical fake from FakePaywallsRepository.kt looks like:

class FakePaywallsRepository : PaywallsRepository {
  private var offeringResult: Result<Offering>? = null
  private var customerInfoResult: Result<CustomerInfo>? = null
  private var purchaseResults: MutableMap<String, Result<StoreTransaction>> = mutableMapOf()

  fun setCustomerInfoResult(result: Result<CustomerInfo>?) {
    customerInfoResult = result
  }

  fun setPurchaseResult(packageId: String, result: Result<StoreTransaction>) {
    purchaseResults[packageId] = result
  }

  fun simulateOfferingError(message: String = "Failed to fetch offering") {
    offeringResult = Result.failure(Exception(message))
  }

  fun simulateCustomerInfoError(message: String = "Failed to fetch customer info") {
    customerInfoResult = Result.failure(Exception(message))
  }

The constructor takes no arguments. The fake starts in a deliberately empty state where every flow emits a “not configured” failure. A test then sets the slots it cares about and leaves the others alone. That asymmetry is the value of fakes over mocks: you do not have to enumerate every method up front, you only describe the scenario you are testing.

The flow methods themselves are one line each, with the empty case routed through a recognisable exception so a misconfigured test fails loudly rather than hanging on an empty flow:

  override fun fetchCustomerInfo(): Flow<Result<CustomerInfo>> = flow {
    emit(customerInfoResult ?: Result.failure(IllegalStateException("No customer info configured")))
  }

  override fun awaitPurchase(packageId: String): Flow<Result<StoreTransaction>> = flow {
    emit(purchaseResults[packageId] ?: Result.failure(IllegalStateException("Package not found: $packageId")))
  }
}

The IllegalStateException here is not for production semantics. It is a test ergonomic. When a future contributor adds a test that calls a method without setting it up, the test fails with a message that names the missing slot, which is much faster to debug than an empty Flow that just never emits.

One limitation to call out. The fake holds and returns Offering and CustomerInfo values, but it does not construct them. Those types come from purchases-kmp and do not currently expose public constructors. That means you can test the failure paths through the fake directly, but a successful “purchase completed and entitlement is now active” assertion has to be exercised against a real Purchases.sharedInstance. That is exactly the seam the Test Store fills, and the next two sections show how.

Writing tests against the fake

A ViewModel test in commonTest looks almost identical to its androidx counterpart. The only differences are the kotlinx.coroutines.test.StandardTestDispatcher instead of TestCoroutineDispatcher, and Turbine instead of LiveData observers. Here is the setup pattern that the cat-paywalls-kmp SubscriptionManagementViewModelTest uses:

@OptIn(ExperimentalCoroutinesApi::class)
class SubscriptionManagementViewModelTest {

  private val testDispatcher = StandardTestDispatcher()
  private lateinit var fakeRepository: FakePaywallsRepository

  @BeforeTest
  fun setup() {
    Dispatchers.setMain(testDispatcher)
    fakeRepository = FakePaywallsRepository()
  }

  @AfterTest
  fun tearDown() {
    Dispatchers.resetMain()
  }
}

Dispatchers.setMain replaces the main dispatcher that viewModelScope uses with the test dispatcher. Without that swap, any StateFlow.stateIn(viewModelScope, ...) would post to the real main thread and the test would hang, because there is no Android main looper in commonTest. Dispatchers.resetMain after each test is the symmetric tear down. Together they give you deterministic scheduling: nothing runs until you ask it to.

The actual test reaches into the fake, instantiates the ViewModel, and asserts on its state through Turbine. The pattern for an error path:

@Test
fun whenCustomerInfoFetchFails_stateIsError() = runTest {
  fakeRepository.simulateCustomerInfoError("Failed to fetch customer info")
  val viewModel = SubscriptionManagementViewModel(fakeRepository)

  viewModel.uiState.test {
    assertIs<SubscriptionManagementUiState.Loading>(awaitItem())
    testDispatcher.scheduler.advanceUntilIdle()
    val errorState = awaitItem()
    assertIs<SubscriptionManagementUiState.Error>(errorState)
    assertEquals("Failed to fetch customer info", errorState.message)
    cancelAndIgnoreRemainingEvents()
  }
}

Three details earn their keep here. The first awaitItem() returns the initial Loading value because StateFlow always replays its current state on collection. testDispatcher.scheduler.advanceUntilIdle() then drains every queued coroutine in the test scope, which is what causes the repository’s flow to emit, the ViewModel’s combine chain to run, and the next state to land in the StateFlow. The second awaitItem() picks that state up, and the assertion confirms the error message survives the pipeline.

If you write four or five tests like this, you cover the entire surface of the ViewModel’s state machine. The initial loading state, the offering error path, the customer info error path, the combined error path, and the cancellation path are each one fake setter plus an awaitItem(). None of these tests need a billing client, none of them need a network, and the same suite runs against the JVM target and the iOS target without modification.

What this suite cannot cover is the actual purchase. Because the fake cannot construct an Offering with real packages, you cannot run a test that says “the user taps subscribe, the SDK validates the receipt, and the entitlement flips to active.” For that path you need the Test Store, and the right place for it is an instrumented test on top of the unit suite, not inside it.

Integration testing with the Test Store on Android

The Testing Test Store post on the RevenueCat engineering blog walks through this end to end, and the same approach applies to a CMP project because the Android target compiles down to a normal androidTest source set. Put the integration test in composeApp/src/androidTest/kotlin/.... Configure Purchases once with the Test Store key, launch a small activity that drives a real purchase, and use Espresso to tap one of the three buttons that the Test Store modal presents.

The setup uses InstrumentationRegistry.getInstrumentation().targetContext because the test runs in a real Android process, not in a JVM unit test. The configuration call is the same one your Application makes, but pinned to the Test Store key:

@Before
fun setup() {
  val context = InstrumentationRegistry.getInstrumentation().targetContext
  Purchases.logLevel = LogLevel.DEBUG
  Purchases.configure(
    PurchasesConfiguration.Builder(context, BuildConfig.REVENUECAT_TEST_API_KEY)
      .purchasesAreCompletedBy(PurchasesAreCompletedBy.REVENUECAT)
      .build()
  )
}

The actual purchase test then resolves the test offering, launches the activity, and waits for the Test Store modal to appear before tapping the “Test valid Purchase” button:

@Test
fun successfulPurchaseUpdatesEntitlements() = runBlocking {
  val offerings = Purchases.sharedInstance.awaitOfferings()
  val pkg = offerings.all["test-offering"]!!.availablePackages.first()

  activityScenario = ActivityScenario.launch(TestPurchaseActivity::class.java)
  activityScenario.onActivity { activity ->
    activity.launchPurchase(pkg) { result, _ -> purchaseResult = result }
  }

  delay(2_000)
  onView(withText("Test valid Purchase")).perform(click())

  withTimeout(30.seconds) {
    while (purchaseResult == null) delay(500)
  }

  assertTrue(purchaseResult!!.customerInfo.entitlements.active.isNotEmpty())
}

Two things to call out. The delay(2_000) before the Espresso tap exists because the Test Store modal is rendered through the host activity, and Espresso needs the view hierarchy to settle before it can find the button. The 30 second timeout on the assertion accounts for the round trip to the RevenueCat backend that validates the receipt and updates CustomerInfo. Both numbers can be tuned for your CI environment, but they are intentionally generous because the test is doing real network work.

The companion tests are the other two buttons. Tapping “Test failed Purchase” lets you assert that the entitlement stays inactive and the error propagates through your domain layer. Tapping “Cancel” lets you assert that the PurchaseCancelled exception is mapped to a no op rather than surfaced as a user facing error. Three tests, three modal buttons, one Test Store key, no Play Console.

The iOS side: StoreKit configuration files and what the Test Store unifies

On iOS, the equivalent of an instrumented test is a StoreKit configuration file driving an XCUITest. Apple introduced StoreKit configuration files in Xcode 12, and they remain the canonical way to test purchases inside the iOS simulator without setting up a sandbox account. You describe the products in a .storekit file, attach it to a scheme, and run the app under that scheme. Purchases then resolve through the configuration file instead of the App Store backend, and you can use XCUITest to drive the resulting native StoreKit modal.

This works, and for an iOS only app it is often the right answer. In a Compose Multiplatform project, the trade off looks different. The StoreKit configuration file only covers the iOS side. It does not interact with your Android tests, it does not flow data through your PaywallsRepository, and a successful purchase against it does not show up in the RevenueCat dashboard the way a real purchase does. You end up with two parallel integration suites that test the same Kotlin code through two completely different driver layers.

The Test Store collapses this. When the same commonMain code is configured against a Test Store key on both platforms, an iOS purchase goes through the same RevenueCat modal as an Android purchase, the same backend validates the receipt, and the same CustomerInfo flow emits the same shape on both sides. Your iOS integration test can then drive the same three button modal with XCUITest:

func testSuccessfulPurchase() throws {
    let app = XCUIApplication()
    app.launch()
    app.buttons["Subscribe"].tap()
    app.buttons["Test valid Purchase"].tap()

    let unlockedHeader = app.staticTexts["Premium Article"]
    XCTAssertTrue(unlockedHeader.waitForExistence(timeout: 30))
}

The pattern mirrors the Android Espresso test almost line for line. Find the subscribe button, find the “Test valid Purchase” button, wait for the gated content to unlock. The same three Test Store buttons cover the same three scenarios. The same CustomerInfo update unlocks the same composable. You still write two driver layers because the OS testing frameworks are different, but the data plane is shared, the network calls are the same, and the dashboard sees both runs as the same Test Store activity.

For most teams, this is enough. If you also want to exercise the native StoreKit error paths (parental controls blocking a purchase, sandbox account expired, region restrictions), keep a small .storekit based suite for those edge cases. The bulk of your purchase path coverage moves to the Test Store and shrinks the size of the iOS only suite to a handful of platform specific tests.

A three layer testing strategy

Putting it all together, a Compose Multiplatform subscription app has three useful test layers, and each one answers a different question.

The first layer is commonTest unit tests against FakePaywallsRepository. This is where you cover your ViewModel state machine: initial loading, error paths, cancellation handling, derived UI states, and any business logic that lives above the SDK boundary. These tests are fast, deterministic, run on both targets from a single source set, and never touch the network. They are the layer you run on every PR, in pre push hooks, and on every CI build.

The second layer is instrumented tests against the Test Store. On Android this is androidTest with Espresso. On iOS this is XCUITest. Both drive the same RevenueCat purchase modal, both produce real CustomerInfo updates, and both verify the end to end flow from subscribe button to unlocked content. These tests are slower and a little flakier because they include real network calls, but they are the only layer where you can prove that the purchase path works for a real receipt. Run them on merges to main, on release branches, and as part of your release qualification.

The third layer is optional and platform specific. A StoreKit configuration file based suite for iOS edge cases that the Test Store does not model. A Google Play closed track for the rare bugs that only reproduce against the real billing client. Both are valuable, but neither is the workhorse. They exist to plug specific gaps, not to cover the core purchase flow.

The numbers shift the right way too. The unit tests are tens of milliseconds each and run on every commit. The instrumented Test Store tests are seconds each and run on merge. The native edge case suites are minutes each and run on release. Most of your purchase coverage ends up in the layer that runs most often, which is the opposite of what happens when you only have a closedTrack and a StoreKit configuration file.

CI considerations: one matrix, three jobs

The CI shape that falls out of this is straightforward. One job runs commonTest for both targets:

- name: Run unit tests (JVM + iOS)
  run: .\/gradlew allTests

allTests is the umbrella task that Kotlin Multiplatform creates when you have both Android and iOS targets configured. It dispatches to jvmTest, iosX64Test, iosSimulatorArm64Test, and any other target you have enabled. A failure in any one fails the job. Run this on every push, every pull request, and every nightly build.

The second job runs the Test Store instrumented tests on Android. The blog’s CI snippet works as written:

- uses: reactivecircus\/android-emulator-runner@v2
  with:
    api-level: 30
    target: google_apis
    arch: x86_64
    script: .\/gradlew :composeApp:connectedAndroidTest

Two practical notes. The Test Store key needs to be available to this job, but not to forks or to release builds. The cleanest way is a repository secret that the job writes to local.properties at the start of the run, so the same buildConfigField pattern picks it up. The job should also run on merges to main and on release branches, not on every PR, because it includes real network calls and consumes Test Store renewals.

The third job runs the iOS XCUITests. A standard xcodebuild test invocation against the same scheme that ships the app, with the Test Store key injected through the same mechanism your local builds use. Both Android and iOS integration jobs read from the same RevenueCat project, which means a single dashboard view shows test activity from both platforms.

The result is a CI surface that mirrors the test layers. Fast feedback from the unit suite on every commit. Slower but realistic feedback from the Test Store suite on merge. The expensive native suites only when you cut a release. None of these jobs require coordinating two sandboxes, and the same PaywallsRepository and ViewModel code is exercised end to end at every layer.

Conclusion

In this article, you’ve worked through a complete subscription testing setup for a Compose Multiplatform app. You configured the RevenueCat Test Store from local.properties and a single buildConfigField, drew the testability boundary at a PaywallsRepository interface so the SDK never leaks into your ViewModels or your tests, wrote commonTest unit tests against a FakePaywallsRepository using kotlin-test, kotlinx-coroutines-test, and Turbine, then layered instrumented tests on top with Espresso on Android and XCUITest on iOS that drive the same three button Test Store modal. The same shared code path is exercised from commonTest all the way through to the receipt validation backend, on both platforms, without two parallel test suites.

The thing worth internalizing is what changed at each layer. Subscription testing usually fragments because the sandboxes do. By moving the development sandbox up into RevenueCat itself, the Test Store turns the two platform problem back into one. By putting a small repository interface between Purchases.sharedInstance and the rest of your app, commonTest becomes a viable home for the bulk of your business logic tests. By using fakes instead of mocks at the unit layer, the same suite runs against both Kotlin targets without expect/actual or a JVM only mocking framework. Each of these choices is small. Together they collapse what used to be two test suites into one.

Whether you are porting an Android subscription app to iOS, starting a new CMP product from scratch, or trying to get purchase testing into CI for the first time, this layered setup gives you the smallest surface area you can ship a cross platform subscription app on with real confidence. The full source for every snippet in this article lives in cat-paywalls-kmp, and a free RevenueCat project with a Test Store key is the only thing you need to run all three layers locally.

But when those ads hit the Facebook and Instagram feeds, they often bomb.

I framed this pattern during a recent Sub Club Live as “revenge of the brand manager”. This happens when you optimize for aesthetics rather than addressing the messy, stressful reality your users actually inhabit.

Selling a vibe instead of a solution

Take a recent ad campaign from Granola, a popular AI note-taking app. Granola’s ads were undeniably gorgeous — exactly what a brand manager wants to see on a billboard.

The problem? The ads didn’t speak to the user.

When I look at creative like this, I see an ad made by somebody who hasn’t taken the time or trouble to really understand the world their users inhabit. While it checks a lot of boxes for traditional advertising best practices, in direct response advertising, it doesn’t really speak to what the users are going through.

When a user is scrolling through Instagram or TikTok, a conceptual slogan doesn’t stop them. They don’t care about your brand identity — they care about their own immediate problems. If your ad looks like it was made simply to be beautiful, it registers as an ad. An interruption rather than a solution. As we’ve seen with the shift toward value-first UGC ads, users have developed a profound blindness to anything that feels overly produced or disconnected from their reality.

Designing for the lived experience

If beautiful slogans don’t work, what does? The fix is to root your creative entirely in the user’s lived experience. You have to depict a specific scenario that the user recognizes immediately.

For a note-taking app like Granola, I would suggest focusing on a visceral moment of panic.

Take a specific instance from your user’s life, like a CEO asking what the client said. You freeze. But then you look at this app, and remember your notes. That kind of lived experience ad works much, much better versus a slogan where I don’t even know what the product does for anyone.

Watch on Wistia

This approach works because it leverages the emotion that comes with a solved problem. The user isn’t buying an AI note-taker; they’re buying an escape hatch for when their boss puts them on the spot. By visualizing the panic of the problem and the relief of the solution, the ad earns the click.

Why ‘ugly’ often wins

This reality is often frustrating for founders and designers. As David pointed out during our live session, it is easy to err on the side of polish because we all love the ideal of pristine brand advertising. But in direct response, the ‘ugly’ design — the one that clearly and bluntly states the problem — is frequently what wins the creative testing phase.

When you’re scaling paid user acquisition, you cannot afford to let aesthetic preferences dictate strategy. If you overanalyze your creative through the lens of brand purity, you miss the scrappy, relatable angles that actually drive downloads and trial starts.

So the next time you brief a designer or a creator, ban the conceptual slogans. Ask them to show you the moment your user sweats, and the moment your app makes them breathe a sigh of relief.

About the Author: Shamanth Rao is the founder and CEO of RocketShip HQ, a boutique growth marketing firm with over $100 million in managed spend. He hosts the Mobile User Acquisition Show, where he’s launched Intelligent Artifice, a deep dive on how AI is transforming performance marketing.

It was amazing — a fresh slate to use all our customer insights and improve performance! …But also slightly terrifying. Not because of the work itself, but because of the waiting.

That horrible in-between phase after you’ve shipped something, where you’re refreshing dashboards, overanalyzing early feedback, and catastrophizing every dip in the numbers.

What helped me wasn’t positive thinking. It was the opposite: leaning into pessimism.

Deliberately imagining everything that could go wrong before launch. Thinking through every possible scenario. Having the trickiest, most uncomfortable conversations with clients and teams to explore all the what-ifs.

It’s called a pre-mortem. (A bit morbid, but it works.)

Since then, I’ve used it for everything from website redesigns to subscription app launches; especially in products where feedback loops are fast and the stakes compound quickly.

And it’s become one of my favorite planning tools.

What is a pre-mortem?

A regular post-mortem happens after something fails, the classic sprint retrospective. You gather the team, ask not only ‘what went right’ but also ‘what went wrong’ or ‘what could have gone better’, and try to learn from it.

It often comes with a few cringe-inducing “we could have predicted that” moments, where Captain Hindsight suddenly looks like a genius.

The problem is, it’s reactive rather than proactive. You’re analyzing what went wrong after the fact, but it doesn’t change the outcome.

A pre-mortem flips that. The concept is simple: before you launch, imagine it’s three months later, and the launch has completely flopped. Really put yourselves in that moment: the disappointment, the stress, and the why-is-this-happening panic. Bring it to life.

Then ask the full team: why did it fail?

I called it pessimistic, but honestly, it’s not. It only becomes pessimistic if you assume failure is inevitable and stop there. The real goal is to surface risks while you can still do something about them.

If anything, it’s more realistic — and even optimistic — because it assumes you can fix and prevent those risks.

And the interesting part? The things that come up in a pre-mortem are rarely surprising. They’re usually the things everyone already half-knows but hasn’t said out loud.

Who came up with such a morbid concept?

The credit goes to Gary Klein and his often-cited Harvard Business Review article from 2007. But Gary (and yes, given how much I love this concept, we’re absolutely on a first-name basis) had been using the method for a good 30 years before that. He first developed it in the early 90s, so no one needs to do confusing maths back from 2007.

A psychologist by trade, he was fascinated by how people make decisions under pressure and uncertainty. He studied this in one of the most high-stakes environments imaginable: the US Air Force. Later, he developed the idea of pre-mortems further within his own research company, drawing not only on that work but also on medical post-mortems.

What Gary understood — and what more of us need to recognize — is the flawed reality of group decision-making. We’re wired for harmony. We want to get along. No one wants to be the negative Nancy, pointing out risks or poking holes in a plan.

I recently emailed a client outlining all the risks in their current target-setting model and ended with, “sorry, this is a bit negative…”.I felt bad raising those risks, but I also knew, from experience, what happens when you don’t. When you let people believe targets are promises rather than stretch goals. Still, it sucks to be the one to say it. That’s exactly the tension Gary Klein was trying to solve. A pre-mortem removes the pressure to keep up a ‘rah-rah, everything is great!’ mindset.

Instead, it creates a space where calling out risks isn’t awkward; it’s expected.

Since then, the concept has taken off. You’ll find pre-mortems everywhere now: in startups, corporate boardrooms, and even back in the military (a full-circle moment, really).

Daniel Kahneman — who many people know from his book Thinking, Fast and Slow — even called it his single most valuable decision-making technique. Not bad for something that started as an internal fix at a small research company.

Gary later expanded on the idea with what he calls the ‘double-barreled pre-mortem’. After imagining failure, you run a second round where you daydream about wild success — and what could go wrong there, too.

It sounds more optimistic, but the goal is the same: surface risks. Even success can break things. If only Ticketmaster had done that before the Taylor Swift Eras Tour ticket sales…

So that’s how, and why, pre-mortems started. But beyond making it easier to speak up, why else is this tactic so useful?

Why do pre-mortems actually help?

There are five reasons why pre-mortems are so powerful:

1. They make you a better fortune teller

Pre-mortems use a technique known as prospective hindsight (a fancy way of saying imagining the future), which Deborah Mitchell at Wharton found can increase your ability to correctly identify reasons for future outcomes by 30%. All that by pretending it has happened. You basically become a better fortune teller, pretty cool, right?

So it helps you surface real potential risks more effectively than just thinking about them without a specific prompt.

2. It creates psychological safety to talk about risks

We’ve talked a bit about this already. By making the goal ‘identify risks’, you make it safe to say them out loud. People are often all thinking “the founder keeps changing priorities” or “pretty sure this plan was ChatGPT and hasn’t been checked”, but they might be too scared to say it out loud.

As you see others be more open, you’ll also end up being more open.

I think this is especially valuable when you have a room full of young, smart people. I remember at my first job, I assumed whatever senior leadership said was the right call. It felt intimidating to challenge someone with 20 years more experience than me.

Now, as a leader, I know you can tell people to speak up — but the reality is, not everyone will. A pre-mortem helps level that playing field. It gives people permission, and a clear prompt, to question assumptions, raise concerns, and say the thing they might otherwise keep to themselves.

3. It makes the fear concrete

Vague anxiety is paralyzing; we’ve all catastrophized over endless, nameless what-ifs. Specific risks, though, are manageable.

Once you’ve written “what if no one buys it?” on paper and mapped out a plan for it, it stops being a powerful fear. It becomes just another scenario to handle.

Even better, involving the whole team in a pre-mortem helps counteract the planning fallacy — that tendency to be overly optimistic, assume everything will work out, and underestimate time, costs, and risks. By making the risks concrete, you can create a clear action plan.

Think of it as a bit of growth group therapy.

4. It removes panic from decision-making

Have you ever stood in line for coffee, and suddenly it’s your turn way faster than you expected? The barista asks, “What would you like?” and you stammer out, “Um… errr, a vanilla matcha latte, wait, an iced vanilla matcha latte!” Only to take a sip and think, “What was I thinking?”

Okay, that might have just been my own therapy moment the other day, but the point stands: under pressure, we’re terrible at making decisions on the spot.

The same goes for post-launch problems — you’re stressed, stakeholders are asking questions; you’re tempted to make snap, reactive decisions. You blurt out the first thing that comes to mind, and hope for the best.

A pre-mortem changes that. If you’ve already decided, ‘If X happens, we do Y’, then you don’t have to think under pressure. You execute the plan. You’ve already discussed the right course of action as a team, ahead of time. I do this for every experiment I run because it makes ‘failed’ experiments easier to handle: we know what failure looks like, we can learn from it, and we already have a sense of what to test next.

5. It gives you permission to take action imperfectly

I once worked with a Head of Product who was basically a pre-mortem specialist, though he probably didn’t realize it, since we’d never talked about pre-mortems. He had an uncanny ability to spot every possible risk, think it through, and tackle it. Sometimes, it felt frustrating, as it could slow projects down. Until I realized that if I named the risk and laid out a plan, he was more than happy to roll with imperfection.

The extreme opposite of optimism in project planning isn’t pessimism, it’s perfectionism. Try to control everything, and you’ll never go live.

A pre-mortem shows you that even if things go wrong, you have a path forward. That makes it easier to ship. The goal isn’t to prevent every risk, it’s to be conscious of which risks you’re willing to accept and which you aren’t.

By now, hopefully, you’re convinced and starting to wonder how to run your own pre-mortem.

How to run a pre-mortem

While the concept itself is simple, a few small tweaks in setup and approach can make your pre-mortem far more powerful.

Step 1: Gather the relevant individuals

While you can do a pre-mortem alone, I can’t recommend doing it with your team enough. Different people spot different risks based on their expertise, and hearing others’ perspectives can reveal risks you might never have considered.

Even better: bring in someone outside the project; someone who won’t have rose-tinted glasses. Ideally, a classic naysayer who can look critically at what’s being assessed (kind of like that Head of Product I once worked with).

Step 2: Set the scene

Next, set the scene.

Say something like: “It’s [date 2–3 months from now]. This launch has failed. Not a minor disappointment, but a proper flop. What happened?”

Pick a timeframe that feels realistic for the project. Then lean into the drama — think back to high school theater class and really bring it to life. The goal is to make it feel real, to transport yourself to that future moment, and look back with hindsight.

You can even get creative: have AI mock up a founder email, a critical internal memo, or an article in a relevant newspaper or magazine. The more tangible and vivid the scenario, the easier it is to uncover the real risks.

Step 3: List every reason it might have failed

Have everyone list reasons separately. Write down everything, even if they seem unlikely. For example:

• We couldn’t reach enough of our target audience
• The trial-to-paid conversion rate is too low
• We saw very high initial churn
• We struggled to get downloads
• The price felt wrong (too high, too low, confusing)
• A competitor launched something similar at the same time
• We got bad press or reviews early on
• The team burned out before we could iterate

The more specific, the better. We aren’t aiming for perfection here; quantity over quality is the key at this stage. The goal is to surface as many potential risks as possible.

Step 4: Go through the risks and group them by theme

There will inevitably be some overlap in the concerns people raise. That’s okay, this is a no-judgment moment. At this stage, you’re not prioritizing; you’re organizing.

Give everyone a chance to voice their concerns. Whatever you do, don’t try to diminish them or explain why something won’t happen, especially if you’re the leader or founder.

Instead, focus on grouping the concerns by theme. This helps you see more clearly:

• Which concerns are the most common
• Which areas seem to carry the most potential risks

Optional additional step: When pre-mortems require a culture change

In some companies, getting into the pre-mortem mindset can be tricky. When things are busy or deadlines are tight, it’s easy to skip it. Or sometimes, people just feel uncomfortable bringing up the uncomfortable.

Here, the framework Shreyas Doshi suggests can be really useful. He recommends categorizing risks into three types:

1. Tiger: a real threat — something that will hurt the company if left unaddressed.
2. Paper tiger: a perceived risk/threat that, on closer inspection, is unlikely to cause real problems. These are the things the team might be stressing over, but are actually minor and manageable.
3. Elephant: unsurprisingly, this is ‘the elephant in the room’ — a risk that is present but isn’t being talked about.

Using this playful, visual language helps build the psychological safety that’s so important for effective pre-mortems. It makes discussions lighter and more approachable, and it gives you a way to raise risks in other settings too. For example: “This might be a paper tiger, but have we considered…?”

Step 5: For each risk theme, ask two questions

Now that you’ve done some idea spring cleaning, it’s time to assess risk levels and impact:

1. Certainty assessment: how likely is it to happen?
2. Impact assessment: how bad is it if it happens?

This helps you map everything onto a simple 2×2 grid, so you don’t get stuck debating unlikely scenarios or low-impact risks. Instead, you can focus your energy on the ones that actually matter.

Depending on the size of the group and the scope of the project, this might even be a separate session. The goal here isn’t to solve everything yet; it’s to start identifying which risks deserve your attention first.

Step 6: Determine whether you need to plan or prevent those risks

Next, focus on those biggest risks and decide whether they’re preventable, plannable, or both:

1. Prevent: can we reduce the likelihood of this happening?
2. Plan: if it happens anyway, what will we do?

If you try to prevent every single risk, nothing will ever go live, so this is where you need to be critical. Ask yourself: Is this something we can realistically mitigate, or is it a risk we need to consciously accept?

The goal isn’t to eliminate all risk. It’s to understand it and feel prepared for what might happen.

Step 7: Work out potential solutions

Now, depending on the complexity of the risk, this might require an extra session — or a few — to properly think through. Don’t get caught trying to solve everything on the spot. Some risks need deeper brainstorming or input from others.

What does help is summarizing your plans into simple if/then statements. They’re clear, practical, and bring a sense of calm to the unknown.

For example:

• If activation is below 10%, we’ll simplify the first-time experience and retest
• If we attract the wrong customers, we’ll adjust our targeting and messaging before scaling spend
• If nobody hits the paywall, we’ll move it earlier and test different copy
• If day 1 churn is above X%, we’ll investigate whether the paywall is creating impulse conversions

Each of these should be tied to a specific metric you’re already tracking — trial conversion rate, activation rate, churn, and MRR. Set your trigger thresholds before launch, so you’re not debating what ‘bad’ looks like after the fact.

If you’re running paywall or pricing experiments, RevenueCat’s Experiments feature lets you set up A/B tests and define success metrics before you launch — so you’re not making decisions under pressure.

Step 8: Review and revisit

One last thing: don’t let your pre-mortem gather dust in a shared doc like so many other strategy decks. Depending on your timelines, set a few clear check-in points, for example, Day 7, Day 30, and Day 90 post-launch.

At each one, revisit your if/then statements and ask: are any of these scenarios actually playing out?

This is where the pre-mortem really earns its keep. The planning is valuable, but the follow-through is what helps you avoid those “we should have seen that coming” moments later on.

For longer projects, it can even be worth running a second pre-mortem closer to launch; a fresh look, with more context, often surfaces new risks you couldn’t see earlier.

Example: subscription app pre-mortem

Before launching a new subscription tier for a client last year, we ran a quick pre-mortem.

One of the risks we identified: ‘Existing customers might feel cheated if new customers get a better deal’.

We couldn’t fully prevent that. The new tier genuinely offered better value, and it needed to. It unlocked a segment of customers we were previously pricing out. But by naming the risk, we could prepare for it:

• We spent more time positioning the existing tier, not just promoting the new one
• We added a relevant feature to the higher tier to reduce cannibalization
• We communicated proactively with existing customers, explaining the new tier and who it was for
• We prepared responses for the support team

The result? Far fewer complaints than expected, and only a small increase in support tickets (mostly from customers who missed the updates).

More importantly, the new tier drove growth rather than cannibalizing the existing one, with overall MRR increasing significantly.

When to use pre-mortems

Pre-mortems work in a wide range of scenarios:

• Launching a new product or SKU
• Changes to subscription models
• Pricing adjustments
• Entering a new market or channel
• Rebrands or major website overhauls
• Paid campaign pushes

I even run them with new advisory clients to make sure I can support them effectively and drive real impact.

Basically, try a pre-mortem anytime failure would hurt, and you want to have thought it through in advance.

A pre-mortem won’t make launches less scary

You’ll probably still refresh dashboards too often and overanalyze early data — I certainly do.

But the quality of your anxiety changes. Instead of a vague dread that something might go wrong, you have a clear list of what could go wrong, and a plan for each scenario.

The best launches I’ve been part of weren’t the ones where nothing went wrong. They were the ones where we’d already talked through what we’d do if things did go wrong.

So before your next paywall test, pricing change, or new tier launch, take 30 minutes with your team. Imagine the worst, write it down, make a plan.

Then ship it anyway.

In this article, you’ll explore the v7 to v8 deprecation timeline and what each date actually means, the full list of removed APIs and their replacements, a step by step migration of the connection, query, and purchase flows, the new behaviors v8 adds that are worth adopting today, what v8.1 through v8.3 layer on top, and how to prepare for v9 before Google publishes a single line of its API surface.

The deprecation timeline that sets your deadline

Google has run a two year deprecation cycle for the Play Billing Library across several major versions. Every major version gets two years of support after release, then the Play Console stops accepting new builds compiled against it. The deprecation FAQ publishes the exact dates:

The phrasing in the FAQ is precise and worth reading carefully: “This deprecation prevents only new apps and updates from using older versions of the Play Billing Library. Existing apps that use a deprecated version of the library will continue to function as expected.”

That distinction matters. The deadline is a publishing gate, not a runtime kill switch. Already published v7 binaries keep transacting after August 31, 2026. What stops is your ability to ship a new release. If your app receives any updates at all, including security patches and bug fixes, you need to be on v8 before that gate closes. The extension request deadline of November 1, 2026 is for teams that need to file a formal request through the Play Console to keep shipping v7 builds for a brief additional window. It is not a free extension you receive automatically.

The Play Console signals this through a warning and an inbox message on the Policy status page once your app is on a deprecated version. If your AndroidManifest.xml does not contain the entry named com.google.android.play.billingclient.version, the Play Console cannot detect your library version, and the warning never reaches you. That entry is added automatically by the library, but manifest merging in multi module projects sometimes drops it. Verify it exists in your final merged manifest before you trust the absence of warnings.

What changed in v8: the removals at a glance

v8 removed several APIs that had been deprecated for one or two prior versions. If your code still uses any of these, the v8 upgrade will fail to compile until you replace them.

The signature of ProductDetailsResponseListener.onProductDetailsResponse() also changed. The callback now returns a QueryProductDetailsResult that splits the response into a fetched list and an unfetched list with per product status codes, replacing the older single list signature. Any class that implements this listener has to be updated, even if the rest of its logic is unchanged.

Two terminology changes accompany the API removals. “In app items” are now called “one time products” throughout the documentation and the API surface. The class names themselves did not change, the documentation simply uses the new term, but the rename carries a behavioral implication: one time products in v8 can have multiple purchase options and offers, the same way subscriptions did in v7.

Step 1: Bump the dependency and your minSdk

The first change is the Gradle coordinate. v8.0.0 was the first release in the v8 line, but most teams should target the latest patch in the v8 series instead of pinning to 8.0.0:

dependencies {
    val billingVersion = "8.3.0"
    implementation("com.android.billingclient:billing:$billingVersion")
    implementation("com.android.billingclient:billing-ktx:$billingVersion")
}

The library raised its minSdkVersion to 23 starting at v8.1.0. If your app still supports API 21 or 22, you have two choices: pin to 8.0.0, which keeps the original v7 minSdk of 21, or raise your own minSdk to 23 and adopt the latest v8 patch. The latter is the right call for almost every team, since API 23 was released in 2015 and the device tail below it has been negligible for years. v8.1 is also built against Kotlin 2.2.0, which can affect projects on older Kotlin versions if you consume the billing-ktx artifact, though this is a small jump for any project already on a recent Kotlin Compose stack.

Step 2: Migrate enablePendingPurchases

The no argument enablePendingPurchases() was deprecated in v7 and removed in v8. It used to be a single method that turned on pending purchase support for in app items implicitly. v8 replaces it with a builder that forces you to declare which product categories you want pending support for.

In v7, you had:

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases()
    .build()

In v8, the equivalent call is:

val pendingPurchasesParams = PendingPurchasesParams.newBuilder()
    .enableOneTimeProducts()
    .build()

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(pendingPurchasesParams)
    .build()

Notice that .enableOneTimeProducts() is not implicit. The deprecated zero argument version was, by Google’s own description, equivalent to a builder with .enableOneTimeProducts() set, so if you do not include this call you will silently lose pending purchase support for one time products. That regression is invisible in unit tests and in most countries with credit card based purchase flows. It surfaces as broken purchases in markets where users pay with cash at convenience stores or with bank transfers, primarily Japan, Germany, Brazil, Mexico, and Indonesia. Add .enableOneTimeProducts() even if you think you do not need it.

If you sell prepaid subscription top ups, also add .enablePrepaidPlans() to the builder. This was added in v7 specifically for prepaid plan pending transactions and carries over into v8 unchanged.

Step 3: Update queryProductDetailsAsync to the new callback shape

queryProductDetailsAsync itself is not removed, but its callback was. The pre v8 listener received a BillingResult and a List<ProductDetails>. The v8 listener receives a BillingResult and a QueryProductDetailsResult that splits products into two lists. Any product that failed to fetch shows up in the unfetched list with its own status code, instead of being silently dropped.

The pre v8 callback looked like this:

billingClient.queryProductDetailsAsync(params) { billingResult, productDetailsList ->
    if (billingResult.responseCode == BillingResponseCode.OK) {
        productDetailsList.forEach { details ->
            renderProduct(details)
        }
    }
}

The v8 version exposes both the successful fetches and the failures:

billingClient.queryProductDetailsAsync(params) { billingResult, queryProductDetailsResult ->
    if (billingResult.responseCode == BillingResponseCode.OK) {
        queryProductDetailsResult.productDetailsList.forEach { details ->
            renderProduct(details)
        }
        queryProductDetailsResult.unfetchedProductList.forEach { unfetched ->
            logUnfetched(unfetched.productId, unfetched.statusCode)
        }
    }
}

The reason this matters is that pre v8, if you queried five products and one of them was misconfigured in the Play Console, the whole call could return successfully with that product silently missing from the list. Your paywall would render four products and you would have no idea the fifth was even attempted. The new shape makes the partial failure explicit. Each unfetched entry carries a status code that tells you whether the product is unavailable in the user’s country, has not yet been published, or hit a transient error.

This is also the moment to rebuild any abstraction layer that wraps queryProductDetailsAsync in a coroutine or flow. The return type of your suspending wrapper has to change from List<ProductDetails> to a sealed class or pair that carries the unfetched information forward. If you have a typealias for the listener type itself, the typealias has to be updated, since the lambda signature is different.

Step 4: Replace the deprecated queryPurchasesAsync overload

v8 removed the overload of queryPurchasesAsync that took a raw SKU type string. The replacement uses a QueryPurchasesParams builder that wraps the same product type with the new typed enum.

Before:

billingClient.queryPurchasesAsync(BillingClient.SkuType.SUBS) { result, purchases ->
    handlePurchases(result, purchases)
}

After:

val params = QueryPurchasesParams.newBuilder()
    .setProductType(BillingClient.ProductType.SUBS)
    .build()

billingClient.queryPurchasesAsync(params) { result, purchases ->
    handlePurchases(result, purchases)
}

The behavior is identical when invoked correctly. The SkuType constants are gone, replaced by ProductType.SUBS and ProductType.INAPP. If you have a single shared method that accepts a string for the SKU type, refactor it to accept a String that matches the new enum values, or convert it to use BillingClient.ProductType directly.

Step 5: queryPurchaseHistoryAsync has no client side replacement

queryPurchaseHistoryAsync was deprecated in v7 and fully removed in v8. There is no equivalent client API. This is the only v8 removal that does not have a direct one to one replacement, and it tends to surprise teams the most.

Google’s reasoning is straightforward, even if undocumented in the migration page itself: purchase history is not authoritative source of truth on the client. Any history a client builds up can be incomplete, since the device may have been offline during a refund or revocation. The Play Developer API on your server has the authoritative record, and any analytics, audit, or reconciliation flow that depends on knowing past purchases should query it server side instead.

If you previously used queryPurchaseHistoryAsync for one of these reasons, you now have two paths. The first is to call the Play Developer API endpoint purchases.subscriptionsv2.get from your backend whenever you need to inspect a subscription’s full history, including its linkedPurchaseToken chain. The second is to lean on Real Time Developer Notifications and persist the events as they arrive, building your own purchase history table. Most teams already do the latter for analytics and revenue reporting, in which case the v8 removal is a no op.

If you used queryPurchaseHistoryAsync for entitlement restoration on a fresh install or after a reinstall, switch to queryPurchasesAsync with the new params builder. queryPurchasesAsync returns active purchases tied to the current Google account, which is what restoration actually needs. Active purchases is a smaller set than full history, but it is the correct set for entitlement granting. Note that v8 also stops returning consumed one time products and expired subscriptions from queryPurchasesAsync, so configure your one time products as non consumable in the Play Console if you need them to survive a reinstall.

Step 6: Move from alternative billing to user choice billing

v7 already deprecated the enableAlternativeBilling builder method, and v8 removed it entirely. The replacement is enableUserChoiceBilling, which takes a UserChoiceBillingListener instead of an AlternativeBillingListener and exposes a UserChoiceDetails payload instead of AlternativeChoiceDetails.

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enableUserChoiceBilling { userChoiceDetails ->
        recordExternalSelection(userChoiceDetails)
    }
    .enablePendingPurchases(pendingPurchasesParams)
    .build()

The functional contract is the same: when the user picks your billing system over Google Play’s at checkout, the listener fires with the purchase details so your backend can complete the transaction outside of Google Play’s payment flow. Only the type names changed. If you carry a per region build flavor where user choice billing is enabled in some regions and disabled in others, the build flavor logic does not need to change, only the type references.

One time products and the multi offer surface

v8 renamed in app items to one time products and gave them the same multi offer capability subscriptions had since v5. A single one time product can now carry multiple purchase options, each with its own price, regional availability, and offers attached. This is the change that motivates the bulk of v8’s surface, and it is also the reason the unfetched product list now exists. With multiple offers per product, the partial failure modes multiplied, and a flat list could no longer represent what happened.

The class names did not change. ProductDetails is still ProductDetails. What changed is the oneTimePurchaseOfferDetails accessor, which can now expose multiple offers and pre-order details starting at v8.1.0. If your paywall renders a single price for an in app item, you are still on the v7 mental model. v8 lets you expose a discounted offer or a regional offer on the same product without creating a duplicate SKU. This is opt in: existing one time products continue to surface a single offer until you configure additional options in the Play Console.

New behaviors worth adopting in v8

Two of v8’s additions are not strictly required but are worth turning on at migration time, since they reduce code you would otherwise carry yourself.

The first is enableAutoServiceReconnection(). The Play Billing service can disconnect for a number of reasons: the user installs an update to Google Play, the device wakes from a long sleep, the system reclaims the bound service. Pre v8, you had to implement onBillingServiceDisconnected() and call startConnection() again with appropriate backoff. v8 ships an opt in builder method that handles this for you:

val billingClient = BillingClient.newBuilder(context)
    .setListener(purchasesUpdatedListener)
    .enablePendingPurchases(pendingPurchasesParams)
    .enableAutoServiceReconnection()
    .build()

When auto reconnection is enabled, your onBillingServiceDisconnected() override can be a no op, and the library handles retry with backoff internally. Auto reconnection is opt in rather than the default. If you want to manage connection lifecycle yourself, leave it disabled and continue handling onBillingServiceDisconnected() directly.

The second addition is BillingResult.subResponseCode. Pre v8, the BillingResult returned for purchase failures grouped many cases under BILLING_UNAVAILABLE or ERROR. v8 adds a sub response code on BillingResult that distinguishes specific failure cases:

• PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS: the user’s payment method does not have sufficient funds.
• USER_INELIGIBLE: the user is not eligible for the offer they tried to redeem, typically because they have already used a one time intro offer.
• NO_APPLICABLE_SUB_RESPONSE_CODE: the failure does not map to a more specific sub code.

The ineligibility code is the one you almost certainly want to handle, because it lets you steer the user back to a fallback offer instead of leaving them at a failed purchase screen. The sub code arrives in the BillingResult delivered to your PurchasesUpdatedListener.onPurchasesUpdated callback:

override fun onPurchasesUpdated(result: BillingResult, purchases: List<Purchase>?) {
    if (result.responseCode == BillingResponseCode.ITEM_UNAVAILABLE) {
        when (result.subResponseCode) {
            SubResponseCode.USER_INELIGIBLE -> showFallbackOffer()
            SubResponseCode.PAYMENT_DECLINED_DUE_TO_INSUFFICIENT_FUNDS -> showFundsError()
            else -> showGenericError()
        }
    }
}

What v8.1, v8.2, and v8.3 add on top

v8 has been moving fast since GA. Three minor releases between November and December 2025 added significant capabilities that are easy to miss if you only read the v8.0 migration guide.

v8.1.0, released November 6, 2025, introduced suspended subscription handling. A subscription enters the suspended state when Google detects abuse or a payment dispute and pauses delivery of entitlements without canceling the subscription. Pre v8.1, suspended subscriptions were invisible to client side queries. v8.1 adds an isSuspended flag on Purchase and a parameter to queryPurchasesAsync to include suspended purchases in the result. The pattern is to filter purchases by isSuspended before granting entitlement, and route suspended ones into a separate UI branch that explains the hold to the user:

val params = QueryPurchasesParams.newBuilder()
    .setProductType(BillingClient.ProductType.SUBS)
    .build()

billingClient.queryPurchasesAsync(params) { result, purchases ->
    purchases.forEach { purchase ->
        if (purchase.isSuspended) {
            showSuspendedState()
        } else if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) {
            grantEntitlement(purchase)
        }
    }
}

v8.1 also reworks subscription replacement. The old SubscriptionUpdateParams.setSubscriptionReplacementMode() is now deprecated in favor of SubscriptionProductReplacementParams set on the per product builder. The new shape supports a KEEP_EXISTING replacement mode that lets you upsell a second subscription on the same account without canceling the existing one, which is useful for bundled offerings.

v8.2.0 and v8.2.1, released in December 2025, generalize what used to be the External Offers Program into a broader Billing Program surface. The old methods (enableExternalOffer, isExternalOfferAvailableAsync, createExternalOfferReportingDetailsAsync, showExternalOfferInformationDialog) are deprecated and replaced by enableBillingProgram(int), isBillingProgramAvailableAsync, createBillingProgramReportingDetailsAsync, and launchExternalLink. v8.3.0, shipped December 23, 2025, adds the developer provided billing flow on top, with BillingProgram.EXTERNAL_PAYMENTS, EnableBillingProgramParams, and DeveloperBillingOptionParams. This consolidation is Google’s response to the regulatory pressure that emerged from the Epic Games ruling and similar requirements in other jurisdictions, where Google is required to support developer provided billing and out of app payment links.

If your app uses the External Offers Program today, the deprecation is a clear signal to start migrating. The methods still work in v8.2 and v8.3, but they will likely be removed in v9. Migrating to the Billing Program surface now is a one time cost that buys you out of a forced migration later.

Preparing for v9 before its API surface exists

At the moment, the release notes top out at v8.3.0. The deprecation FAQ does not list a v9 row. There is no public alpha, beta, or release candidate. So how do you prepare?

By understanding the cadence and the direction of change. Google has shipped a new major version of the Play Billing Library roughly once a year, with v7 released in May 2024 and v8 reaching GA on June 30, 2025. On that pattern, v9 is expected to land in mid 2027, lining up with the v8 sunset deadline of August 31, 2027.

The direction of change is also predictable from the rapid v8.1 through v8.3 releases. Google is consolidating the external billing surface (External Offers Program, user choice billing, developer provided billing) into a unified Billing Programs API. v9 is likely to remove the deprecated External Offers methods, formalize the Billing Programs surface, and possibly extend it further to handle additional regulatory regimes.

Three things you can do today to be ready:

1. Opt in early: adopt every opt in API v8 ships, including enableAutoServiceReconnection() and the new SubscriptionProductReplacementParams. The opt in surface in one major version is the default surface in the next.
2. Migrate off External Offers: the Billing Programs surface in v8.2 and v8.3 is the forward path, and it gives you a non breaking migration window before v9 forces it.
3. Move history server side: v8 removed queryPurchaseHistoryAsync for a reason, and v9 will not reintroduce it. Build your purchase audit trail server side from RTDN events and the Play Developer API.

If you do these three things in your v8 migration, the v9 migration in mid 2027 becomes incremental rather than disruptive.

How RevenueCat absorbs the v7 to v8 transition

The recurring nature of Play Billing Library migrations is the kind of work that taxes a small team disproportionately. Every two years, someone has to read the migration guide, refactor the connection layer, retest pending purchases in cash payment markets, audit the queryPurchaseHistoryAsync removal, and verify that no listener signature change broke a downstream module. The work is rarely interesting, and it always lands on the team that least wants to do it.

RevenueCat absorbs this migration on your behalf. The RevenueCat Android SDK 9.x ships with Play Billing Library 8 already integrated, and the SDK API surface most apps interact with did not change between RC SDK 8.x and 9.x. The only meaningful changes for app code are a Kotlin minimum of 1.8.0 and the removal of data class modifiers from a handful of public types, which means copy() and component destructuring no longer work on those types. equals() and hashCode() are preserved. The migration path is documented in the RevenueCat 8.x to 9.x Android migration guide, and the rationale and feature set are walked through in the Play Billing Library 8 support in Purchases SDK v9.0.0 engineering post.

The practical implication is that the v7 to v8 migration steps in this article reduce to: bump your RevenueCat SDK from 8.x to 9.x, bump your Kotlin to 1.8 or later, replace any copy() or destructuring on the affected RC types with explicit constructors, and verify your one time products are configured as non consumables in the RevenueCat dashboard (since v8 cannot query consumed one time products). That is the entire migration. The v8 specific work, including the new PendingPurchasesParams builder, the queryProductDetailsAsync callback shape, the queryPurchasesAsync overload swap, the user choice billing rename, and the unfetched product handling, is already done inside the SDK.

The same property holds for v9. When v9 ships, RevenueCat will release a new SDK that integrates it, and your app code moves forward with the same pattern: bump the SDK, possibly bump your Kotlin or minSdk, and run your test suite. The recurring Play Billing Library migration stops being something your team has to schedule.

Conclusion

In this article, you’ve explored the full v7 to v8 migration: the deprecation timeline that sets your August 31, 2026 deadline, the removed APIs and their replacements, the six concrete migration steps from Gradle bump through user choice billing, the new behaviors v8 ships with enableAutoServiceReconnection and BillingResult.subResponseCode, the three minor releases that added suspended subscriptions and the unified Billing Programs surface, and a pattern based read on what v9 will likely require.

Understanding the structural reasons behind each removal helps you make better decisions during the migration itself. queryPurchaseHistoryAsync is gone because purchase history was never authoritative on the client. The new enablePendingPurchases builder is explicit because the implicit version silently regressed cash payment flows in some markets. The unfetched product list exists because partial failures had to become visible once one time products gained multiple offers. Each change reflects a problem the prior surface failed to handle, and the v9 changes will follow the same logic.

Whether you’re migrating to v8 this quarter, planning the v9 transition for 2027, or evaluating whether to outsource billing infrastructure to a platform like RevenueCat, this foundation lets you ship Android subscriptions without losing weeks every two years to a forced upgrade. For the official source material, refer to Google’s migrating to Play Billing Library 8 page, the deprecation FAQ, and the release notes.

Meet Rico, RevenueCat’s app growth advisor built directly into your RevenueCat dashboard and available in Slack. Ask why conversions dropped, which experiment to run, or how your churn rate compares to similar apps. Rico turns your RevenueCat data into your next move.

An advisor, not a search bar

Rico is an embedded domain expert with access to your RevenueCat data, the App Store and Google Play Billing Library documentation, and the industry-wide State of Subscription Apps (SOSA) benchmarks.

Not only can you ask Rico straightforward questions like “show me MRR by country” or “compare this month’s performance vs last month,” you can ask Rico real, business-outcome questions:

• “Where am I leaving money on the table in the trial-to-paid flow?”
• “Based on the A/B test, should we do a 0 vs 7-day trial next?”
• “What is the average conversion to paying for a fitness app?”

What Rico can do for you

Rico’s capabilities span across data analysis, technical debugging, and growth strategy. Here is what your new advisor can do:

Diagnose revenue and retention

“Why did MRR drop in Germany last week?”

Rico can pull your overview metrics, fetch chart data with complex filters, and compare periods to spot anomalies. If revenue drops, Rico can surface exactly which cohort, country, or product is driving the change.

Review product and entitlement setups

“Is my annual product configured correctly in the App Store?”

App Store and Google Play configurations are notoriously easy to get wrong. Rico can review your products, entitlements, offerings, and packages to verify that everything is attached correctly and properly configured in the stores.

Analyze experiments and strategy

“Based on the A/B test, should we do a 0 vs 7-day trial next?”

Rico lists your A/B test results and helps you interpret the winners and losers. It can provide paywall and pricing strategy recommendations, trial optimization advice, and retention analysis.

Benchmark against the industry

“How does my app’s trial conversion compare to similar apps in my category?”

Rico has a dedicated benchmarks tool that compares your project’s actual metrics against industry peers. Ask how your trial conversion, churn rate, or MRR growth stacks up against apps in your category. Rico surfaces where you’re ahead, where you’re behind, and what to test next, using data from the SOSA reports.

Deep-dive into customers

“Look up user abc123: they say they paid but don’t have access.”

When a user writes in with a billing issue, give Rico their app user ID. Rico pulls their full profile: active entitlements, subscription status, purchase history, and any custom attributes your app has set.

Then Rico tells you what it sees. Is the subscription in billing retry? Did they cancel but still have access? Have they been refunded before? Are they enrolled in an experiment that might explain unexpected behavior? For most support tickets, that’s enough to diagnose the issue and respond with confidence.

Research documentation and SDKs

“How do I implement a custom paywall in React Native?”

Rico has full access to the RevenueCat docs and all open-source SDK repositories across iOS, Android, Flutter, React Native, Unity, KMP, and JS. Ask about an implementation detail and Rico finds the exact code snippet or proven approach. Ask about a recent SDK release and Rico pulls the changelog. If something seems broken, Rico can check the live status of RevenueCat’s API.

Learn from the best in the industry

“What do high-retention apps do differently in their first 30 days?”

Rico can search the RevenueCat blog and pull insights from the SubClub podcast. Hundreds of conversations with the founders and operators who have built the most successful subscription apps. Ask Rico what high-retention apps do differently, how apps in your category structure their trial strategy, or what operators have figured out about reducing involuntary churn.

Project and team management

“Who changed the annual product entitlement yesterday?”

Rico can list your apps, API keys, and collaborators, and pull your project’s audit log. Every entry records who made a change, what they changed, and when. That covers everything from product and entitlement config to experiment activity, webhook updates, and collaborator role changes.

Feature adoption audit

“Which RevenueCat features am I not using that I should be?”

Ask Rico to run a feature adoption audit on your project. It checks every RevenueCat feature against your actual usage data and returns three things: what you’re actively using, what’s gone dormant, and what you’ve never tried.

Rico might flag that your Refund Handling integration stopped flowing data three months ago, meaning Apple has been approving refunds without your input. Or it might notice you’re running Customer Center but haven’t enabled the Retention Messaging API, which gives you a second chance to retain users when they try to cancel in the App Store.

App and competitor research

“What’s Duolingo’s monetization strategy?”

Give Rico any app’s bundle ID or package name and it will pull the App Store and Google Play metadata side by side. Ratings, pricing, category, IAP structure, localization breadth, release cadence, the full picture.

Ask Rico to look up a competitor and it will flag what their monetization strategy tells you: whether they’re running a trial-led conversion model, how their content scope affects willingness to pay, what their rating trajectory suggests about product-market fit.

Rico in Slack

Most revenue questions start in Slack. Someone posts a screenshot and asks, “Anyone know why this dropped?” Then everyone waits for the one person who knows how to pull the number.

With the Slack integration, you can now tag @Rico in any channel with a question. The answer lands in the thread: the data, the context, and what to do next. Visible to everyone in the conversation.

To connect Rico to your Slack workspace, go to Account Settings in the RevenueCat dashboard, open the Rico tab, and click Connect to authorize the integration.

Try Rico today

Rico is available in public beta.

Head to your RevenueCat dashboard and ask for a health check. Tell Rico to run a feature adoption audit, or ask: “What’s the biggest bottleneck to my revenue growth right now?”

Open the dashboard or add Rico to Slack. Ask your first question.

You can now make that record completely obsolete.

You know you need to test your paywalls. The difference between a mediocre paywall and a great one is often the difference between a struggling app and a thriving subscription business.

But for anyone who isn’t a speed-building champion, the reality is different. Creating a paywall that looks good, handles every edge case, and is ready to publish requires design skills and engineering time you don’t have. Iterating on it takes even longer.

The result is a “good enough” paywall that never gets tested.

RevenueCat’s Paywalls AI Editor changes this. It’s a conversational paywall agent that lets you generate a production-ready paywall from a text prompt in seconds.

From drag-and-drop to done-in-seconds

You can edit any aspect of your paywall using natural language. Type “make the annual plan more prominent” or “use a darker color palette.” Every change streams live in the preview.

RevenueCat Paywalls AI Editor handles the entire paywall creation process from end to end. Whether you’re starting from a blank canvas or adapting an existing template, the AI Editor gives you complete control over every layer of your paywall.

Copywriting and conversion

Great paywalls live and die on their copy. You can ask the builder to rewrite your headlines, subheads, and CTA text to match your brand voice. Personalize the copy using custom variables like {{ custom.first_name }} or rewrite pricing language with variables like {{ product.price }} and {{ product.relative_discount }}. Clean up awkward copy, fix mismatched monthly and yearly labels, and rebalance plan emphasis, for example, changing the default selected plan, updating badge wording, or anchoring users toward the annual option.

Visual design and layout

You control the entire visual mood through natural language. Ask the builder to restyle your colors, adjust spacing, update typography, or fix contrast issues. Add or refine your layout for light and dark modes separately, for example, a white background with dark text in light mode and a deep navy with a glowing CTA in dark mode. Generate and swap imagery for your hero sections and backgrounds to better match your brand on the fly.

Components and structure

Building a paywall means assembling the right pieces. The AI Editor drops in whatever you need on command. You can add headers, feature lists, testimonials, comparison tables, timelines, carousels, and package groups. Remove, duplicate, reorder, or move any existing section, for example, pulling a testimonial block above the pricing cards to build trust before the ask. Ensure compliance by adding sticky footers and updating your Terms and Privacy URLs.

Localization

Scaling your app means translating your paywall. The AI Editor adds localizations directly to your layout and updates translated copy across every component. Fine-tune individual localized strings, for example, shortening a German CTA that overflows its button and test how different languages affect your layout before you push the changes live.

Pre-launch auditing

Before you ship, the builder acts as a second set of eyes. Ask it to audit your paywall for common conversion killers. It flags issues like a low-contrast CTA button, a pricing card that clips on iPhone SE, a missing restore purchases link, or an annual plan that looks identical to the monthly one. Get a list of fixes you can apply instantly with a single follow-up prompt.

Try the AI Editor today

Log into your dashboard, click “Create paywall,” and select “Generate with AI”. Describe what you want to build. Try to beat 3 minutes and 16 seconds. We think you will.

The Hail Mary pitch

Bria Sullivan had already found success with her game Boba Story, but she wanted to experiment with monetizing a creator’s audience through an app. After a chance dinner meeting with YouTuber Hank Green, she secured a pitch meeting. The goal was to build something for one of his educational channels, Crash Course.

The meeting didn’t go well. The team wasn’t interested, and the answer was a polite “no.” But as the call was wrapping up, Bria threw out one last idea: “What about a Focus Timer, a Crash Course focus timer?”

That single question changed the trajectory of the project. While the Crash Course team still passed, Hank Green himself loved the concept. An hour later, he texted her to say he couldn’t stop thinking about it. They decided to partner up and build it specifically for his core audience—the “Nerdfighters.” It was a reminder that sometimes the best opportunities come from simply putting yourself in the room and refusing to let the meeting end on a rejection.

Live-streaming user research on TikTok

Rather than building in a vacuum, Bria used her existing TikTok audience to validate the app’s design in real time. During long live streams, she would draw different art styles, show color palettes, and ask her viewers directly what they preferred.

She presented six different variations of the app’s central character—a “bean”—and let the audience guide the direction. “When it comes to female audiences too and anything gamified, the look and feel matters so much for organic reach,” she explains. “It’s like what’s going to make someone convert, and the way something looks is a huge reason why people convert.”

This public validation ensured that by the time the app was ready, it already matched the exact aesthetic preferences of its target users. The original, lo-fi “Bee and Puppycat” style she initially favored was scrapped entirely based on this immediate, unfiltered feedback.

The backlash of monetizing a fanbase

Partnering with a massive creator solves the distribution problem, but it introduces a unique set of challenges. When Focus Friend quietly launched via a YouTube community post, the initial reaction wasn’t purely celebratory.

Despite getting 20,000 downloads in the first week, Bria was flooded with angry emails and negative reviews. Users were upset that the app used a subscription model instead of a lifetime unlock, and they were highly sensitive to standard app practices like ad tracking. Because the app was tied to Hank Green—a beloved public figure known for his philanthropy—users felt a personal betrayal that they wouldn’t feel toward a faceless corporation.

“I learned that,” Bria says. “Every app on your phone uses those things, but for some reason he’s not allowed to.” To protect Hank’s reputation and maintain trust, they made the difficult decision to strip out advertising tracking IDs entirely. It was a move that essentially killed their ability to do paid user acquisition, but it preserved the core relationship with the audience.

Why creators make terrible product managers

Bria’s experience with Focus Friend taught her a crucial lesson about creator partnerships: influencers rarely know what makes a good standalone app.

“I don’t think that influencers really know what a good idea is for them to do for their audience,” she observes. “They always, for some reason, they always want a social media or they want a feed of information. And I’m just like, no, I just don’t think that those are good ideas for apps personally.”

Her advice to developers looking to partner with creators is to act as the product manager. Creators understand their audience’s content preferences, but developers understand utility. The most successful collaborations happen when the developer steers the product toward a clear, functional use case—like a focus timer—rather than trying to build another content feed.

In the full episode, Bria also talks about her journey from learning Android development in 2010 to winning an App Store Award, the reality of being a solo developer while raising a newborn, and why she believes product instinct is far more valuable than pure engineering skill.

Guest links:

• Bria Sullivan on LinkedIn
• Focus Friend on the App Store
• Boba Story on the App Store

With the rise of AI, advertisers can now generate creator-style ads in a matter of hours using synthetic avatars, automated voiceovers, and video tools. What used to require weeks of coordination and creator involvement can now be executed in an afternoon.

This shift is not just technological, it reflects a deeper change in how advertising operates — the pace of modern platforms has outgrown traditional content production.

But this raises a fundamental question. If content no longer needs to be created by real people to perform, what actually drives trust, and where does artificial intelligence start to break it?

Based on what we’ve tested at Mojo, the answer is more nuanced than the current hype suggests. But there’s a few key learnings:

• Replication beats interpretation
• The cost of failure has collapsed
• AI knows what looks real, but humans know what feels real
• You are no longer building an ad; you are building a system

The real driver: ad fatigue

The rise of AI-generated ads is not driven by novelty alone. While it is undeniably fueled by the fact that technology has finally crossed a critical threshold of fidelity, the primary catalyst for its adoption is a structural constraint: ad fatigue

On platforms like TikTok and Meta, videos are consumed at a relentless pace. A highly-effective ad can lose its impact within days. For subscription-based products, this rapid decay directly increases the cost of acquiring a new customer.

Today, those stakes couldn’t be higher — with RevenueCat data showing the top 25% of subscription apps grew 80% year-over-year in 2026, while the bottom 25% shrank by 33%. In a winner-take-more market, efficient acquisition isn’t just about optimization, it’s about your app surviving at all.

The natural response is to produce more videos. But this is where the traditional system breaks:standard production is slow and requires a lot of resources. Even highly efficient teams operate on multi-week cycles. Meanwhile, the algorithms shift in real time.

This creates a fundamental mismatch: the algorithm evolves faster than your production process. AI removes that constraint. Instead of asking what the next ad should be, teams can now ask how many variations they can test today. The primary advantage of AI is not that it produces better ads. It’s that it allows you to discover better ads faster.

Case study: Scaling the Mojo ‘Auto Edit’ winner

At Mojo, one of our highest-performing ads was a simple 30-second split-screen video featuring a speaker explaining the product on top and a screen recording of the app on the bottom. This video converted trial users to paid at 23%.

The secret was the person. Our creator was our Product Manager. When he explained the product, he was walking through something he deeply understood. His conviction came from ownership. That kind of authenticity is extremely difficult to synthesize from scratch.

Watch on Wistia

Baseline: Our top-performing human UGC. Notice the genuine conviction of our PM talking about the feature he built.

Phase 1: why replication outperformed native creators

To scale this ad internationally, we initially recruited local creators in several countries to recreate the video. The result was disappointing — despite strong production quality, performance dropped across markets.

The issue came down to execution: each creator interpreted the script slightly differently. Pauses were shortened, pacing changed, and gestures were misaligned. Individually, these differences seemed minor, but collectively, they killed performance.

There was also a constraint regarding legal rights. We often did not have the rights to extend a creator’s content into other languages. This highlighted a critical point: the best-performing creator is the one you actually own.

So we changed strategy. Instead of adapting the ad, we replicated it: we used video translation tools like HeyGen to dub the original video, while strictly preserving the timing, the pauses, the gestures, and the exact energy. In Brazil, the dubbed version achieved a 40% lower acquisition cost compared to native creators.

The lesson here is that execution mechanics matter just as much as the message. AI does not reinterpret; it preserves.

Watch on Wistia

AI Dubbing: 95% perfect lip-sync preserving our PM’s original high energy.

Phase 2: AI avatars (the 80% failure rate)

Encouraged by these results, we moved to fully AI-generated avatars. We expected the speed of production to compensate for a slight dip in quality. Instead, the outcome was binary: most of the profiles we tested failed almost immediately.

The generic avatars we initially generated did not work, and the reasons went beyond mere technical fidelity.

First, we encountered a fundamental perspective and staging issue. As you can see in the variations above, the avatars were placed in hyper-polished environments — studio microphones, cinematic lighting, and stylized backgrounds. Some were even positioned at slight three-quarter angles rather than looking directly into the lens. This immediately broke the native, informal visual code of UGC. The user’s brain categorized the content as a commercial within the first second.

Second, there was a major casting issue. The avatars simply did not match our Product Manager’s original profile or conversational energy. We were trying to scale a specific type of raw, founder-led credibility, but we were using avatars that looked like generic stock models or polished influencers. The disconnect between the message and the messenger was jarring.

These flaws, combined with the expected rigid expressions, caused rapid drop-offs. One avatar had a mere 0.2-second lip-sync delay on a key word, which resulted in a 68% drop in click-through rate compared to the human baseline. Users couldn’t articulate why they did not trust it, but the data was brutal.

But one avatar worked.

Instead of using a generic, polished profile, we used HeyGen to create a custom digital twin based strictly on our original Product Manager. We stripped away the studio mics and cinematic lighting. We matched his raw facecam perspective, his specific look, and his exact baseline energy.

Because the source material already had natural presence and inherent credibility, the output felt believable. That version reached 87% of the original human conversion rate.

The economics changed dramatically:

• Traditional creator: $500
• Generating the custom AI avatar: $20

RESULT: 31% lower cost per acquisition.

Watch on Wistia

The $20 Winner: Natural head tilts and accurate micro-expressions driving a 31% lower CPA.

Phase 3: the double AI stack

Once we identified a winning creative, we introduced a two-step process: generating the base video using the custom avatar, then instantly translating it into multiple new languages using ElevenLabs for localized, natural-sounding voice cloning.

Watch on Wistia

The results (Brazil localized metrics):

• CPA: $8 (31% lower than the human control)
• CTR: 4.5%
• Conversion Rate: 3.1%
• ROAS: 2.1x

The cultural limit: This ‘double layer’ stack (a synthetic avatar that is then dubbed into another language) worked flawlessly in Brazil and Spanish-speaking markets, where users are highly receptive to direct-response UGC formats. However, when we pushed this exact same dubbed avatar to Europe (France, Germany), it failed. The European audience was far more sensitive to the uncanny valley, and the double layer of AI broke their trust.

This highlighted to us that sensitivity to artificial media is not just technical. It is geographic and culturally dependent. You can’t assume universal adoption.

Key takeaways: how AI-generated UGC impacts ad performance and trust

Ads are our business, so we had the luxury of being able to test AI-generated ads and finesse the output. Many apps won’t be able to take this same risk and time, so here’s my top learnings from our creative experiments with AI user-generated content.

Why natural execution beats polished authenticity

There is a common assumption that videos made by users perform well because they’re authentic. In practice, authenticity is only part of the story. These videos work because — even when users are following a script — they feel natural.

The best-performing ads rely on familiar patterns like direct-to-camera delivery, informal conversational tones, and simple visuals. AI is highly effective at replicating these patterns. By mimicking the structure of successful content, AI-generated ads can improve early metrics like views and watch time.

Balancing algorithmic attention vs. user trust

One of the most important insights from our experiments is that these ads operate across two distinct layers:

1. The algorithm rewards attention
2. The user decides based on trust

AI helps you win the first, but it doesn’t guarantee the second.

In our tests, fully synthetic avatars struggled in formats that rely on credibility, especially testimonials or personal stories. People are sensitive to anything that feels artificial in emotional contexts. We subconsciously scan for micro-expressions, subtle changes in eye contact, and the natural hesitation that signals genuine human experience. When an algorithm tries to simulate a heartfelt story, it misses these imperceptible cues. The result is a subconscious rejection by the viewer.

Conversely, AI thrives in structured, utility-driven formats. For product demonstrations, tutorials, and feature breakdowns, clarity and pacing matter far more than emotional authenticity. The rule is simple: use AI to explain, and use humans to convince. This principle was at the heart of our strategy when we decided to scale our own top-performing content at Mojo.

The economics of failing fast

The real advantage of AI was not just cost. It was speed.

With traditional methods, creative testing five human creators takes $2,500 and three weeks of production to find one potential winner. Testing five AI variations takes $100 and just two hours.

The downside of testing creatives has collapsed. You’re no longer optimizing for perfect execution upfront, you’re optimizing for iteration speed. You are no longer buying videos, you’re buying iterations — and iteration compounds.

From production to decision-making

Before, production was the bottleneck. Now, production is instant. But a new bottleneck emerges: decision-making.

When you only have five videos a month, you can rely on intuition. When you can generate 50 variations a day, intuition fails. Teams no longer need to figure out how to produce content. They need to figure out what to test and what to cut.

AI did not remove the need for creativity. It made taste and data analysis the new competitive advantages. Bad decisions now scale just as fast as good ones.

The hidden risks

Like any new approach to ad creatives, there are payoffs you have to consider:

Cookie-cutter ads

We’re already seeing a specific aesthetic emerge among AI-generated ads: perfect lighting, lack of breathing pauses, and synthetic enthusiasm. If every brand starts using similar avatars, these videos will become the new fatigued format. Ad fatigue won’t disappear; it just shifts from the individual video to the format itself.

Navigating the legal maze

There’s also a significant legal challenge. Building your acquisition engine on a digital copy of a real person is a liability maze. Who owns the likeness if that employee leaves the company?

With external creators, the problem is worse. If you don’t secure rights to use their digital likeness, you’re essentially renting your growth. Owned content scales, rented content does not. Brands need to rethink their talent contracts entirely. You need specific likeness agreements that outline exactly how, where, and for how long a synthetic avatar can be used, including clauses that allow the company to run the digital copy for six to twelve months after an employee departs.

Audience backlash and reputational risk

The risk of audience backlash is a reality that cannot be ignored. Audiences are becoming increasingly sophisticated at identifying synthetic media, and for subscription-based apps, the stakes are uniquely high. Because the business model relies on an ongoing relationship, being perceived as using deceptive or low-quality AI creative at volume can be devastating.

It creates what is essentially a ‘trust tax’, if a user feels tricked by an advertisement, they might install the app, but will inevitably churn. It doesn’t just hurt immediate acquisition; it erodes the fundamental trust that drives long-term retention. Every app audience is different, so it’s vital to consider your specific consumer group’s sentiment. The challenge for brands moving forward is finding the balance between being transparent, efficient, and maintaining a sincere human connection.

Best practices for scaling AI-generated ads

Before you generate new AI content, you need to answer a few fundamental questions:

• Do you own the source material and likeness rights?
• Is the format utility-driven rather than an emotional story?
• Can you kill the campaign in 24 hours if the data shows it is failing?
• Have you tested your specific market’s tolerance for synthetic media?

Most importantly, you have to break the perfection. Perfect delivery feels like a commercial. Here’s what we’ve found works:

• Lower the resolution slightly so it does not look like a studio shoot
• Let the audio retain a bit of background room tone.

Artificial intelligence naturally gravitates toward a flawless output, so you have to actively force it to be messy.

Checklist: when to use AI or real users for ads

If you’re deciding between a human creator and a synthetic avatar, use this quick reference guide based on our testing:

Opt for AI-generated ads when:

• The goal is utility: product walkthroughs, feature demos, or screen-recording tutorials
• You need scale: testing 10+ hook variations or localizing an ad into five different languages
• Speed is critical: you need to respond to a creative trend within 24 hours
• Cost is the bottleneck: you have a winning script but a limited budget for multiple creators

Opt for real humans when:

• The goal is trust: personal testimonials, ‘storytime’ formats, or founder-led brand intros
• Emotional nuance is key: content that requires subtle micro-expressions or genuine empathy
• High-value markets: targeting regions (like Europe) with high sensitivity to ‘uncanny valley’ media
• Originality: creating the source material that will eventually be replicated by AI

The new UGC

We’re entering an era of infinite content where the true bottleneck is no longer creation, but judgment. While the technological barrier to generating an ad has effectively dropped to zero, the psychological barrier to earning consumer trust has never been higher.

Algorithms are exceptionally good at replicating familiar patterns to buy attention, compress feedback loops, and scale distribution. What they cannot do, however, is synthesize genuine conviction. The top growth teams of the future won’t merely be those who test the fastest. Instead, they will be the ones who understand exactly when to automate a system for efficiency, and when to rely on a real human heartbeat for persuasion.Ultimately, AI didn’t make advertising smarter — it simply revealed the clear boundary between what machines can execute and what they cannot. Speed and automation will always buy you attention, but it takes a human to earn trust.

Listen on: YouTube · Spotify · Apple Podcasts

A staggering 55.4% of 3-day trials are cancelled on Day 0. Ouch.

That’s over half gone before they’ve even had a chance to use what they signed up for. Talk about not giving an app a fair shot. So what’s happening, and how can apps combat it?

Whilst the number does drop a bit with longer trials, even with a 30-day trial nearly a third of users cancel on the very first day. Combine Day 0 and Day 1, and you’re looking at 84% of 3-day trial cancellations happening in that first 24 hours. For 7-day trials, it’s still 64%.

Do you see why those numbers keep me up at night?

And it’s not just trials, even annual subscriptions see almost 35% of cancellations within the first month.

Why 55% of free trials cancel on day zero

This data from the State of Subscription Apps Report 2026 really surprised me. Users are churning fast, losing faith in the app from the outset, feeling disappointed. It’s like your date slipping out after the first drink. You’re left wondering… how did it go so wrong so fast?

The first place we tend to look is onboarding. While I’ve seen plenty of wins from improving onboarding and paywalls, it’s not enough. These early cancellations show a clear pattern: people want to try your product. They hand over their payment details, click subscribe… and then something goes wrong immediately after.

Most advice on reducing early cancellations focuses on the in-app experience, pre-trial onboarding or improving your lifecycle marketing. All this is important, but there’s one step almost nobody talks about: the post-subscription screen. The very thing your users see the moment after they convert.

Introducing app aftercare: aka, the post-purchase screen

I first realized this when I interviewed Rosie Hoggmascall, Head of Product & UX at Fyxer.ai, on her approach to paywalls. She emphasized thinking about what happens after purchase, and it stuck with me. I call it aftercare, because that’s exactly what most apps are missing: care.

Think about it like this: you walk into a shop, buy something, and the minute your transaction goes through, the salesperson turns away. No “Great choice!”, no bag, no receipt, no guidance on how it works. Just… nothing. You’d feel weirdly used. Embarrassed. Probably just awkwardly standing there wondering, “Now what?”.

That’s exactly what most apps do.

I walked through a ton of post-purchase screens to see how different apps handle this moment. (Confession: I didn’t spend hundreds of pounds on subscriptions. I have to be very strict on my app subscriptions, given how many I test. So I used Mobbin for examples, though I did peek at some in the wild too.) What I found was a spectrum: some apps completely miss the moment, and some absolutely nail it.

6 Levels of post-purchase screen optimization

Here’s how to level up your post-purchase screen, step by step. I see six levels of post-purchase screens:

1. The basic version: straight into the app
2. A clear confirmation screen
3. Celebrate the moment
4. Remind them what they are getting
5. Highlight what you’ll help them achieve
6. Give them one clear next step

Each is slightly better than the last, and more in tune with what the user needs.

Now, I will say that as much as I love a neat little framework, some apps I reviewed broke the mould, choosing to use the post-purchase moment to push users to sign up for an account or pursue an upsell. That also works in certain scenarios, so I’ll cover when to go with those approaches as well.

I’ve also made a Mobbin board with 13 examples of different app onboarding-to-post-purchase screen journeys. Check it out here.

Level 1: the default straight-into-app version

The most common approach is to rely on Apple’s default “You’re all set” confirmation, then dump users straight into the app. That’s it. No intermediate screen, no acknowledgement of what just happened, no guidance on what to do next.

Take Zero, a weightloss and metabolic health app. You subscribe, get the standard Apple pop-up, and then you’re deposited straight into the app. What next?

MasterClass, the online learning platform, does the same. You could argue it makes sense — MasterClass has a massive library, and users potentially already know what they want to watch or were attracted by a specific expert to subscribe. But even here, a little extra care would go a long way. If someone clicks through that confirmation screen too quickly (and they will), they might not even register what they just signed up for — or how much they’re paying.

It’s the same as the store example I shared earlier: no acknowledgement, no guidance, just an abrupt ending.

Level 2: a clear confirmation screen

Level two is a simple but meaningful upgrade — after the standard Apple confirmation, add your own screen that acknowledges what just happened.

Pillow Talk, an AI journaling app, does this really well. It welcomes you to Pillow Talk Plus, confirms that everything in the plan is now yours — the insights, the support, the space to process — and then guides you straight into the app.

It doesn’t list every feature exhaustively, but it gives a reassuring tick that you made the right choice. It also helps clarify that your subscription went through, in case you clicked past the Apple pop-up too quickly (as I tend to do).

Lifesum, a calorie-counter and meal-planning app, takes a similar approach: “Your journey has begun”. Simple, warm, and focused on the outcome rather than the features. That small moment matters more than you might think, especially for someone on a trial who could still talk themselves out of it.

That little moment of “You made the right choice, here’s what’s ahead” can do a lot of heavy lifting. It’s the same as a salesperson in a store saying, “All set — enjoy!”

You can take it even further by reminding users of their original reason for signing up (their Job to be Done) to reassure them and reinforce why they’re here. It’s such a simple screen, and not a huge effort to implement, which is why I think this should be the minimum standard for any app.

Level 3: celebrate the moment

Now we can do even better. Be the store employee who doesn’t just say, “You’re all set,” but adds a little enthusiasm: “I have that shirt too” or “Those shorts have been so popular, I love them”. The tiny extra phrase that makes you feel good about your purchase (and less guilty about spending money when you swore off clothes shopping for the month… ahem, not talking about me here).

In-app, you can take the same approach: make the post-purchase screen feel like a genuine celebration. Not cringe or over-the-top, but a moment that acknowledges they made a good decision, and this is something worth celebrating.

This is what Duolingo does. When I first explored this topic with Rosie, she mentioned their celebratory animation, which quickly makes you feel good about the decision you just made.

I mean, we rarely see that owl so happy — it’s nice to see.

Animations are a great way to spark that energy. Take Kitchen Stories, a recipe app: their fun confetti screen welcomes you with, “You can now start using Kitchen Stories Plus!” It could be a bit clearer about exactly what’s included in Plus, but the moment of celebration is there, and it works. (And there is confetti, who doesn’t love a bit of confetti.)

Level 4: remind them what they’re actually getting

Here’s something app teams do too quickly: assuming users remember what’s included in the plan they just upgraded to. Spoiler: they don’t. Especially on a trial, where part of the decision might have been, “Well, I can always cancel”.

It’s like making a big order at a restaurant; it’s nice when the waiter repeats it back to you, reassuring you they’ve captured your order. The same applies here. Especially if the upgrade came through a feature-specific paywall, users might not even know all the premium features they now have access to.

Use the post-purchase screen to remind the user of their purchase. It provides clarity, removes nerves, and also reminds them of all the great features now available.

AllTrails, the hike, bike, and run app, does this really well for their Peak subscription. First, there’s a simple animation welcoming you. Then, after suggesting push notifications, they clearly list everything included in the plan.

For users who were previously on Plus, they even reassure you that you’re still getting all the Plus features too.

That prompt to enable push notifications, with a clear explanation like “We’ll remind you before your trial ends”, is also a clever way to tackle Day 0 cancellations. It’s a double win: you get permission to send notifications, and the user feels less anxious about forgetting to cancel if they want to — preventing the pre-emptive trial cancellation.

This point about notifications is worth dwelling on. You can promise users reminders upfront, but if they haven’t enabled notifications yet, that promise doesn’t land. The post-purchase screen is the perfect moment to set this up, in context, when the reason is obvious, and the value is immediate.

Level 5: highlight what you’ll help them achieve

Beside, an AI receptionist app does this particularly well. It congratulates you on starting your trial, then immediately reminds you of the outcome you’re here for: your clients will get instant answers, and you’ll get time back.

It also backs that up with three concrete stats:

• 100% of business calls answered
• 80% of inquiries handled automatically
• 30% more bookings

You haven’t even opened the app properly yet, and you’re already thinking about results, instead of fighting buyer’s remorse and wondering whether to cancel.

Headway, the bitesized book summaries and personal growth app, is one of my favorites here. It combines the celebratory approach from earlier with a satisfying star animation: “Congrats! Now you are a member of Headway Premium, together with 1.7 million learners.”

That community framing is smart. It immediately signals that this isn’t some scrappy app you should second-guess. 1.7 million people made the same choice you just did.

We often assume that because someone signed up for a trial or subscribed, they already trust us. But really, they’ve only trusted us enough to make that first purchase (that’s free!). The post-purchase screen is your chance to keep building that trust, step by step.

Then it reframes the moment around the Job to Be Done: “It’s Day 1 of your self-growth journey”. That’s more than a confirmation, it’s a feeling of excited expectation. This is a new me. I’ll finally stop doomscrolling Instagram and start learning!

Headway reinforces this by focusing on outcomes — grow your productivity, get daily motivation, improve your soft skills — rather than just listing features. It’s about making the user feel the value they just unlocked.

Level 6: give them a clear next step

For some apps, the biggest barrier after subscribing isn’t doubt, it’s paralysis. Where do I start? What should I do first? If your app has a lot of content or options, that first decision can feel overwhelming enough to make someone close it entirely.

Now you don’t want to hit users with ten questions right after purchase — I don’t know about you, but when that happens, I just blank or pick the first thing that comes to mind.

The solution isn’t more information, it’s fewer choices. Greg, a plant care app, handles this brilliantly. The post-purchase screen gives you one job: start adding your plants. Take a photo or upload one. No menus to navigate, no features to explore, no extra decisions. Just one clear first step that gets you using the product immediately.

I had a similar experience with Picnic, a photo-organizing app. The moment I subscribed, it took me straight to a folder of my 2017 photos and had me swipe left or right to decide what to keep — Tinder-style.

As someone who hasn’t used a dating app in ten years, I got to enjoy the fun of swiping again. Once I finished that folder, the app celebrated how much space I’d freed up and let me delete the photos. Then I could move to the next folder at my own pace, making the process clear, fun, and completely manageable.

What that did (and I don’t think it was accidental) was make me feel immediate progress. I wasn’t thinking about whether the weekly subscription was worth it; I was busy clearing out my 2017 camera roll. By the time I came up for air, I was already invested, and honestly, it was kind of fun sifting through years of photos.

Another approach is to provide a brief instruction on what to do next. After the celebratory owl, this is exactly what Duolingo does: a simple, clear set of steps showing how the app works and what to do first:

While many apps include this guidance in their onboarding — and yes, most users will see it on Day 0 — for anyone signing up later, it’s a helpful reminder of what they’ll get and how it works.

Alternative post-purchase onboarding strategies

Now we’ve covered the six levels of app aftercare, let’s push it just a little further. Depending on your app, you can also use this moment to encourage users to create an account or present a subtle upsell, making the post-purchase screen do double duty.

1. Push for the account setup

If account creation is important to your app — for saving progress, personalizing the experience, or staying in touch — and you haven’t already collected it, the post-purchase screen is a good moment to ask for account creation. Not perfect, sure — ideally, you’d have it earlier, but better late than never.

The key is giving users a real reason to hand over their details right now. Not “create an account to continue” (that feels like a gate), but motivation to pass over that info. Back to our shop example: if setting up an account comes with a perk, like 10% off, we’re much more likely to go for it.

Alan Mind, a previous CBT-guided journaling app, does this well: “Save your progress and secure your journal”. That’s a reason that actually matters to the user, showing that their data and privacy are safe.

What would make this even better is offering frictionless sign-up options, like Apple or Google. It removes effort at exactly the moment users are least motivated to fill out forms.

As it stands, it’s not entirely clear what the password requirements are either, which can make this step feel unnecessarily clunky, and that’s the last thing you want right after someone has just subscribed.

Calm, the meditation app approaches this a bit better:

Post-purchase, you get a how did you hear about us survey, and are then encouraged to sign up for an account to track progress.

2. Go for the upsell

One final option — and one to use carefully — is leveraging the post-purchase high to push for a longer commitment or additional purchase. This tends to show up more in larger, well-known apps that are focused on increasing realized LTV per paying customer.

Flo, a cycle-tracking and women’s health app, does this with confidence. After congratulating you on starting Flo Premium, it presents a ‘gift’, which turns out to be a 44% lifetime discount on an annual subscription.

The framing is smart: it’s positioned as a gift, not a sales pitch. And by locking in annual subscribers at the moment of highest trust, they’re tackling both trial drop-off and long-term churn in one move.

Headway takes a slightly different approach. After the celebratory screen, they offer a one-time deal on a Self-Reflection Ebook at a discounted price.

This is a more classic upsell moment, the kind you’d usually see in e-commerce. You’re already in a ‘yes’ mindset, trust is high, and a complementary product can feel genuinely helpful rather than pushy.

That said, sequencing matters. Focus on getting the basics right first, making sure users feel good about what they’ve just committed to, and only then, ask for more.

How to build your first post-purchase screen

Getting started is easy. If you’re currently at Level 1, don’t try to jump straight to Level 5, as tempting as it is. Start with Level 2. It’s a single screen you can ship in a sprint: acknowledge what just happened, remind users why they signed up, and make them feel good about it. That alone puts you ahead of most apps.

Once that’s live, start layering in improvements. Add a celebratory moment or a clear first step, depending on what your app needs. If your product has a lot of content and users tend to feel overwhelmed, prioritize a clear next step or simple instructions (like Duolingo). If your product is simple but the commitment feels big (like Headway), lean into celebration and reassurance.

The main metrics to watch are your Day 0 and Day 1 cancellation rates. Track before and after launching the new screen to measure impact. If you offer a free trial, also monitor your trial-to-paid conversion rate, especially if you’ve added things like push notification opt-ins or feature reminders (like AllTrails has).

If you go down the upsell route, focus on realized LTV and retention, not just the conversion rate on that single offer. A pushy upsell that damages trust will cost you far more in churn than it generates in upgrades.

Because ultimately, the goal isn’t to optimize the post-purchase screen in isolation, it’s to get the moment after someone subscribes right, because that sets the tone for the entire relationship.

Don’t skip this onboarding moment

There are many ways to approach the post-purchase screen, and not every approach will fit every app. But the one thing I’d strongly push back on is doing nothing, dropping users straight into the app, and hoping they figure it out.

At a minimum, give users clarity on what they’ve just subscribed to. Add a moment of celebration, a clear next step, or a reminder of the outcome they’re working towards. These aren’t big product investments, but they can make a real difference to those Day 0 cancellation numbers.

You’ve already done the hard work of earning someone’s trust to the point that they’re willing to subscribe. Don’t stop guiding them the moment they do.

In this article, you’ll set up a Kotlin Multiplatform project with the RevenueCat KMP SDK, configure dashboard products and entitlements, initialize Purchases on Android and iOS, gate premium content from common code, run an in app purchase from commonMain, and drop in a server driven paywall built with the dashboard’s Paywall Editor. You’ll work directly with the same source layout used by cat-paywalls-kmp, the official KMP demo app.

What you’ll build

You’ll end up with a Compose Multiplatform app that lists premium articles, fades the body until the user is entitled, opens a server driven paywall, runs the purchase through the platform native dialog, and refreshes the entitlement state. The same screen runs on both iPhone and a Pixel without a single line of duplicated UI code.

The repository structure is a normal multi module KMP project: a composeApp module with commonMain, androidMain, and iosMain source sets, a few feature modules (home, article, paywalls, subscriptions), and core modules for data, network, and design system. Every line of subscription logic in this tutorial lives in commonMain.

Why single codebase changes the math

Building cross-platform subscriptions without a shared SDK means writing every subscription concept twice. You query Google Play with BillingClient and a purchase token, and you query StoreKit with Product.products(for:) and a signed JWS. You verify receipts with two completely separate server APIs, store them in two different shapes, and reconcile them with a backend mapping layer. None of this work is the part of your product that users care about.

The RevenueCat KMP SDK gives you four shared concepts that hide all of that:

• Offerings are the set of products you currently sell, configured in the dashboard rather than in your app.
• Packages are the buyable units inside an offering (monthly, annual, lifetime).
• Entitlements are the access levels your app cares about (premium, pro, family), independent of which store the user paid through.
• CustomerInfo is a single object that aggregates every active entitlement for the current user, regardless of platform.

Once you have these four objects, your app stops asking “did this user buy through Google Play or App Store?” and starts asking “is customerInfo.entitlements["premium"] active?” That single property check works the same on iOS and Android.

Prerequisites and dashboard setup

Before any code, you’ll set up four things in the RevenueCat dashboard:

1. A project with one Android app and one iOS app, each linked to its store credentials.
2. Products imported from Google Play Console and App Store Connect.
3. An entitlement named premium (or whatever identifier you prefer).
4. An offering with one or more packages attached, marked as the current offering.

Two codelabs walk through the dashboard side end to end. If you have not configured products yet, go through them first:

• RevenueCat Google Play Integration
• RevenueCat App Store Integration

The two important screens to land on are the entitlement and the offering. The entitlement is the unit your app code checks:

The offering is what your app fetches at runtime. It bundles the packages you want this version of the app to display, and you can change its contents without shipping a new build:

After both apps are set up, copy the public SDK API keys from Project Settings > API Keys. There is one key per platform, and you will use both of them in Step 2.

Step 1: Add the RevenueCat KMP SDK

The KMP SDK ships as two artifacts: purchases-kmp-core for the subscription logic and purchases-kmp-ui for the Compose Multiplatform paywall component. Both are published to Maven Central with a single version coordinate of the form <sdk>+<hybrid-common>. The number after the plus sign matters when you link the iOS pod, so do not strip it.

Start by adding the version and library entries to gradle/libs.versions.toml:

[versions]
purchases-kmp = "2.10.2+17.55.1"

[libraries]
purchases-kmp-core = { module = "com.revenuecat.purchases:purchases-kmp-core", version.ref = "purchases-kmp" }
purchases-kmp-ui   = { module = "com.revenuecat.purchases:purchases-kmp-ui",   version.ref = "purchases-kmp" }

Then declare the dependencies inside the commonMain source set of your app module’s build.gradle.kts. In the cat-paywalls-kmp demo this lives in composeApp/build.gradle.kts:

kotlin {
  sourceSets {
    commonMain.dependencies {
      \/\/ RevenueCat
      implementation(libs.purchases.kmp.core)
      \/\/ Compose Multiplatform paywall component
      implementation(libs.purchases.kmp.ui)
    }
  }
}

Notice that both Android and iOS pull the same commonMain dependency. There is no androidMain.dependencies { implementation("com.revenuecat...") } block. The KMP artifact carries platform specific bindings inside it.

Linking the iOS native framework

The KMP SDK depends on PurchasesHybridCommon, a native iOS framework that wraps StoreKit. The cleanest way to bring it in is through the Kotlin CocoaPods plugin. Apply the plugin to your composeApp module:

plugins {
  alias(libs.plugins.kotlin.multiplatform)
  alias(libs.plugins.compose.multiplatform)
  alias(libs.plugins.compose.compiler)
  kotlin("native.cocoapods")
}

Then declare both pods inside the kotlin { cocoapods { ... } } block. Pin the pod version to the same major as your purchases-kmp artifact so the Kotlin and Swift sides agree on protocol shapes:

kotlin {
  cocoapods {
    summary = "Cat Paywalls KMP App"
    homepage = "<https:\/\/github.com\/revenuecat\/cat-paywalls-kmp>"
    version = "1.0"
    ios.deploymentTarget = "15.0"
    podfile = project.file("..\/iosApp\/Podfile")

    framework {
      baseName = "ComposeApp"
      isStatic = true
    }

    pod("RevenueCat") {
      version = "~> 5.21"
      extraOpts += listOf("-compiler-option", "-fmodules")
    }
    pod("RevenueCatUI") {
      version = "~> 5.21"
      extraOpts += listOf("-compiler-option", "-fmodules")
    }
  }
}

Run ./gradlew podInstall once. Gradle generates a .podspec for your shared module and writes a Podfile.lock next to your iOS app. From now on, opening the iOS workspace in Xcode pulls everything down through CocoaPods.

The KMP SDK uses Kotlin/Native interop bindings that are still flagged as experimental, so opt in inside any iOS source set that touches them:

kotlin {
  sourceSets {
    all {
      languageSettings {
        if (name.startsWith("ios")) {
          optIn("kotlinx.cinterop.ExperimentalForeignApi")
        }
      }
    }
  }
}

That is the entire setup. No platform-specific source files yet. Everything else lives in commonMain.

Step 2: Initialize Purchases on each platform

Purchases is a singleton. You configure it once early in the app lifecycle, then every other call goes through Purchases.sharedInstance. Initialization is the only place where Android and iOS code differ, and only because each platform has its own application entry point.

On Android, initialize from your Application.onCreate. The cat-paywalls-kmp demo does this in CatArticlesApplication:

class CatArticlesApplication : Application() {

  override fun onCreate() {
    super.onCreate()

    Purchases.logLevel = LogLevel.DEBUG
    Purchases.configure(
      PurchasesConfiguration(apiKey = REVENUECAT_ANDROID_API_KEY) {
        appUserId = null \/\/ Anonymous user
      },
    )
  }

  companion object {
    private const val REVENUECAT_ANDROID_API_KEY = "your_android_api_key"
  }
}

The PurchasesConfiguration(apiKey) { ... } builder is a small DSL. Inside the trailing lambda you can set appUserId, purchasesAreCompletedBy, verificationMode, and other options. Passing appUserId = null tells the SDK to generate an anonymous identifier in the form $RCAnonymousID:<uuid>. When the user later signs in to your backend, you call Purchases.sharedInstance.logIn(userId) and RevenueCat transfers any purchases to that account.

Do not forget to register the Application class and the INTERNET permission in AndroidManifest.xml:

<application
    android:name=".CatArticlesApplication"
    android:label="@string\/app_name">
    <activity android:name=".MainActivity" android:exported="true">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" \/>
            <category android:name="android.intent.category.LAUNCHER" \/>
        <\/intent-filter>
    <\/activity>
<\/application>

<uses-permission android:name="android.permission.INTERNET" \/>

On iOS, initialize from your SwiftUI App struct. You import the native RevenueCat pod here, not the KMP wrapper, because configuration runs in Swift before the Kotlin runtime starts:

import SwiftUI
import RevenueCat

@main
struct iosAppApp: App {

    init() {
        Purchases.logLevel = .debug
        Purchases.configure(withAPIKey: "your_ios_api_key")
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

ContentView then hosts the shared Compose surface inside a UIViewControllerRepresentable:

struct ComposeView: UIViewControllerRepresentable {
    func makeUIViewController(context: Context) -> UIViewController {
        MainViewControllerKt.MainViewController()
    }

    func updateUIViewController(_ uiViewController: UIViewController, context: Context) {}
}

The Kotlin side of that bridge is a one liner in iosMain:

fun MainViewController(): UIViewController {
  val appGraph = createGraph<AppGraph>()
  return ComposeUIViewController {
    App(appGraph = appGraph)
  }
}

App is the same @Composable you call from MainActivity on Android. From this point on, every screen you build runs on both platforms.

The reason initialization is split is that Purchases.configure reaches into the platform billing client immediately. On Android it asks BillingClient to open a connection. On iOS it registers a StoreKit transaction listener. Both need to happen before any Compose composition starts, which is why you do not configure inside commonMain.

Step 3: Check entitlements from common code

Once Purchases is configured, you can ask “is the current user entitled to premium?” from anywhere in commonMain. The KMP SDK exposes coroutine friendly suspend variants of every callback API. The one you want here is awaitCustomerInfo():

suspend fun isPremium(): Boolean {
  val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()
  return customerInfo.entitlements["premium"]?.isActive == true
}

CustomerInfo.entitlements is a map keyed by the entitlement identifier you set up in the dashboard. The value is an EntitlementInfo with an isActive flag, an expirationDate, a willRenew boolean, and a store enum that tells you which platform the underlying purchase came from. For access decisions, only isActive matters. The entitlement is active whether the user subscribed through the App Store, Google Play, Stripe, or a promotional grant from your support team.

Most apps wrap this in a repository so the rest of the app can collect a Flow and forget about callbacks. The cat-paywalls-kmp demo defines PaywallsRepository in core/data:

interface PaywallsRepository {
  fun fetchOffering(): Flow<Result<Offering>>
  fun fetchCustomerInfo(): Flow<Result<CustomerInfo>>
  fun awaitPurchase(packageId: String): Flow<Result<StoreTransaction>>
}

The fetchCustomerInfo implementation is a thin Flow wrapper around the SDK call, with Dispatchers.IO to keep network work off the main thread:

override fun fetchCustomerInfo(): Flow<Result<CustomerInfo>> = flow {
  try {
    val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()
    emit(Result.success(customerInfo))
  } catch (e: Exception) {
    emit(Result.failure(e))
  }
}.flowOn(Dispatchers.IO)

A ViewModel collects this flow and exposes a StateFlow<CustomerInfo?>:

class CatArticlesDetailViewModel(
  articleId: Long,
  articlesRepository: ArticlesRepository,
  paywallsRepository: PaywallsRepository,
) : ViewModel() {

  val customerInfo: StateFlow<CustomerInfo?> =
    paywallsRepository.fetchCustomerInfo()
      .map { it.getOrNull() }
      .stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = null,
      )
}

The Compose Multiplatform UI then reads it like any other state and decides whether to render the article body or fade it behind a paywall prompt:

private const val ENTITLEMENT_PREMIUM = "premium"

@Composable
private fun CatArticlesDetailContent(
  article: Article,
  viewModel: CatArticlesDetailViewModel,
  navigateToPaywalls: () -> Unit,
) {
  val customerInfo by viewModel.customerInfo.collectAsState()
  val isEntitled = customerInfo?.entitlements?.get(ENTITLEMENT_PREMIUM)?.isActive == true

  DetailsContent(
    article = article,
    onJoinClicked = navigateToPaywalls,
    isEntitled = isEntitled,
  )
}

DetailsContent applies a fadingEdge modifier when isEntitled is false. Subscribed users see the article through to the end. Free users see the first few paragraphs fade into a “Join Now” CTA. The same composable runs on both iOS and Android.

Step 4: Run a purchase from commonMain

Triggering a purchase is two suspend calls: fetch the current offering, then call awaitPurchase with one of its packages. The SDK takes care of opening Google Play’s billing dialog or StoreKit’s purchase sheet, validating the receipt with the store, and posting it to RevenueCat for tracking.

The awaitPurchase helper from purchases-kmp-core accepts a Package:

suspend fun purchaseMonthly() {
  val offerings = Purchases.sharedInstance.awaitOfferings()
  val current = offerings.current ?: error("No current offering configured")

  val monthly = current.monthly
    ?: current.availablePackages.first()

  val transaction = Purchases.sharedInstance.awaitPurchase(monthly)

  \/\/ The SDK has already verified the receipt and updated CustomerInfo.
  \/\/ Your existing customerInfo flow will emit the new state on its own.
}

Offering exposes convenience accessors for common cadences (monthly, annual, lifetime) and a generic availablePackages: List<Package> if you want to build a custom plan picker. The cat-paywalls-kmp demo wraps this in PaywallsRepository.awaitPurchase(packageId):

override fun awaitPurchase(packageId: String): Flow<Result<StoreTransaction>> = flow {
  try {
    val offerings = Purchases.sharedInstance.awaitOfferings()
    val pkg = offerings.current?.availablePackages?.find { it.identifier == packageId }
      ?: error("Package not found: $packageId")

    val transaction = Purchases.sharedInstance.awaitPurchase(pkg)
    emit(Result.success(transaction))
  } catch (e: Exception) {
    emit(Result.failure(e))
  }
}.flowOn(Dispatchers.IO)

Two things to know about the return value. First, the StoreTransaction is informational only. The receipt has already been validated server side by the time awaitPurchase resumes, and the user’s CustomerInfo has been updated on RevenueCat’s backend. Second, the next call to awaitCustomerInfo() will reflect the new entitlement, which means any UI bound to your customerInfo flow recomposes automatically. You do not need to manually invalidate state.

If the user cancels the dialog, the SDK throws a PurchasesException whose code is PurchaseCancelled. Catch it and treat it as a no op rather than an error.

Step 5: Drop in a server driven paywall

You could build the package picker yourself, but RevenueCat’s Paywall Editor lets you design the entire screen in the dashboard and update it without shipping a new build. The purchases-kmp-ui artifact includes a Paywall composable that renders the configured paywall on both Android and iOS.

You design the paywall in the dashboard’s visual editor:

In your KMP code, the entire paywall screen is one Paywall call. The cat-paywalls-kmp demo lives in feature/paywalls/CatCustomPaywalls.kt:

@Composable
fun CatCustomPaywalls() {
  val composeNavigator = currentComposeNavigator

  Box(
    modifier = Modifier
      .fillMaxSize()
      .background(Color.White),
  ) {
    Paywall(
      options = PaywallOptions(
        dismissRequest = { composeNavigator.navigateUp() },
      ),
    )
  }
}

PaywallOptions is where you pass callbacks for dismissal, purchase completion, and restore. With no offering passed, the component renders the current offering assigned to the user in the dashboard. If you are running an A/B test, RevenueCat picks the variant for this user automatically and attributes any conversion to the right experiment arm.

This is the part that pays for itself. The entire visual design of the paywall, including which packages to show, how to highlight the recommended plan, what copy to use for the trial CTA, and which offering to display, is configurable from the dashboard. You can tweak headline copy or swap a one screen layout for a feature comparison layout in the morning, watch conversion metrics in the afternoon, and revert by clicking a button if the new variant underperforms. None of this requires a Play Store or App Store review cycle.

Putting it all together: the architecture

Here is how all the pieces line up in a finished KMP project. In code, the cat-paywalls-kmp demo organizes responsibilities by module:

• composeApp is the only module with platform specific code. Its androidMain configures Purchases from the Application, its iosMain exposes a MainViewController() to SwiftUI, and its commonMain holds App.kt plus a Navigation Compose NavHost.
• feature/* modules are screens (home, article, paywalls, account, subscriptions). They depend on core/* and contain Compose Multiplatform UI plus ViewModels.
• core/data owns PaywallsRepository, the only place that calls into Purchases.sharedInstance. Everything else reads Flow<Offering> and Flow<CustomerInfo> from this repository.
• core/model, core/network, core/designsystem, core/navigation hold the data classes, Ktor client, theme, and navigation graph respectively.

The final UX you ship looks like this. Subscribed users see the full article and a subscription management screen sourced from the same CustomerInfo object:

The same SubscriptionManagementScreen reads customerInfo.activeSubscriptions, customerInfo.entitlements["premium"]?.isActive, and customerInfo.originalAppUserId to render its content, and runs without modification on both platforms. There is no if (Build.VERSION...) and no #if os(iOS). The code lives once, in commonMain, and the SDK does the platform translation underneath.

If you want to inspect the full source as a reference, every file shown in this article is in cat-paywalls-kmp. The minimum surface to get a working integration is the four steps above plus the dashboard setup. Everything else is product specific UI.

Conclusion

In this article, you’ve configured the RevenueCat KMP SDK in a Compose Multiplatform project, initialized Purchases on Android and iOS, gated a premium screen with CustomerInfo.entitlements, run a real purchase through awaitPurchase, and rendered a server driven paywall with the Paywall composable from purchases-kmp-ui. Every piece of subscription logic except platform initialization lives in commonMain, which means your iOS and Android apps stay in lockstep without any code duplication.

The thing worth internalizing is what the SDK takes off your plate. You no longer think in terms of purchase tokens versus signed transactions, two notification pipelines, or two receipt verification servers. You think in terms of offerings, packages, entitlements, and CustomerInfo, and the SDK collapses both stores into those four concepts. That same abstraction is what makes the visual Paywall Editor possible, since it is far easier to ship one server driven UI when there is only one shared state model underneath.

Whether you are porting an existing Android subscription app to iOS, starting a new product on KMP from scratch, or experimenting with paywall variants without burning a release cycle, this setup gives you the smallest surface area you can ship a cross platform subscription app on. The remaining engineering time goes back into the parts of your app that actually differentiate your product.

As always, happy coding!

— Jaewoong (skydoves)

The data backs this up. According to our State of Subscription Apps report, hard paywalls convert downloads to paid at a median of 10.7% — five times better than the 2.1% median for freemium apps. The floor for hard paywalls (4.2%) is actually double the median for freemium.

“If you’re a bootstrapped startup or you’re operating with limited outside capital, it’s a much more reliable and low-risk way of growing your business,” explains growth advisor Phil Carter in a recent episode of the Sub Club podcast.

But what if you want to build a billion-dollar company?

“There are a lot of examples of apps like Spotify, Duolingo, Strava that have done that through freemium,” Phil says. “You’re just going to attract a much larger user base at the top of the funnel if you have a free version of your product.”

Watch on Wistia

The transition from a hard paywall to freemium is the highest-ceiling growth lever a mature app can pull. It’s also the most dangerous. To illustrate the stakes, Phil shared the story of his biggest win — and his biggest failure — from the past year. Both involved the exact same strategy.

The win: a 75% increase in LTV

Phil’s biggest win came from helping an established subscription app move away from a traditional hard paywall. But rather than simply opening up the app and hoping users would eventually subscribe, his team implemented a “multistep paywall.”

The strategy reframed the value proposition. Instead of saying, You have to pay for this product now, the new onboarding flow communicated a different message: This product is free and will always be free, but we want you to try the best version of it for seven days. After that, we’d love to have you continue paying to get maximum value.

The results were staggering.

“We saw a 75% increase in LTV per user through the implementation of this multistep paywall along with some other pricing and packaging optimizations,” Phil says.

By removing the hard gate, the app widened its top-of-funnel significantly. More users experienced the core product, organic acquisition accelerated, and the multistep paywall successfully captured the revenue upside.

“It pretty fundamentally altered the full potential size of this business,” Phil notes.

The fail: a 50% drop in conversion

The success of the multistep paywall might suggest that every scaling app should immediately drop its hard paywall. But Phil’s biggest failure of the year serves as a stark warning against treating freemium as a silver bullet.

With a different client, Phil’s team attempted a similar shift to freemium. The results were disastrous.

“The initial results didn’t work at all,” he admits. “We saw more than a 50% reduction in subscriber conversion. We very quickly pulled off of it after a couple of weeks.”

Why did the exact same strategic move produce such radically different outcomes?

It comes down to product-market fit and the inherent complexity of managing a freemium model. When an app relies on a hard paywall, it forces a binary decision before the user has fully experienced the product. The conversion is driven by the promise of value, the quality of the marketing, and the friction of the paywall itself.

When you remove that friction, you’re entirely reliant on the product’s ability to demonstrate ongoing, undeniable value. If the free experience is too generous, users have no incentive to upgrade. If it’s too restrictive, they churn before forming a habit.

According to State of Subscription Apps 2026, 55% of all 3-day trial cancellations happen on Day 0 — meaning the battle for the subscriber is won or lost in the first session.

As Phil puts it, moving from a hard paywall to freemium is “like moving from playing checkers to playing chess because it requires a lot more sophistication.”

When should you make the switch?

If you’re considering dropping your hard paywall, the data and Phil’s experience suggest a clear framework for the decision:

1. Stay with a hard paywall if:

• You’re bootstrapped or highly capital-constrained
• You need immediate cash flow to fund paid acquisition
• Your product solves an acute, immediate problem rather than building a long-term habit
• You don’t have the product analytics infrastructure to rigorously test feature gating

2. Consider testing freemium if:

• You’ve achieved strong product-market fit and high retention among your core users
• You’ve got the runway to absorb a temporary dip in conversion rates while you optimize the model
• Your product benefits from network effects or user-generated content (like Duolingo’s massive free experience)
• You’ve hit a growth ceiling with paid acquisition and need to unlock organic, word-of-mouth growth at scale

Watch on Wistia

Freemium isn’t a pricing strategy; it’s a product strategy. If you treat it simply as a different way to display your paywall, you risk halving your conversion rate. But if you treat it as a fundamental shift in how you deliver value, it might just be the move that turns your app into a billion-dollar business.

Why dropping conversion to 9% was the right move

When Opal, the popular screen time and focus app, hit $5 million in annual recurring revenue (ARR), they were scaling efficiently with a hard paywall. The business model was working, but user growth was plateauing.

To build a product capable of reaching a billion users, CEO Kenneth Schlenker made a terrifying decision: transition to a true freemium model. The immediate result was a massive drop in their download-to-paid conversion rate, plummeting from 20% down to 9%.

But that drop was exactly what the company needed. By giving away the core product for free, Opal unlocked entirely new segments—specifically high school and college students, who now make up two-thirds of their daily active users (DAUs). These free users became the app’s marketing engine. The initial hit to conversion was eclipsed by an explosion in organic growth, pushing Opal past 1 million DAUs and $10 million in ARR.

“We’ve seen a decrease in our conversion to paid, but we’ve also seen as a consequence of that an explosion of our DAUs and revenue with it,” Schlenker explains. “It’s a short-term, scary drop, but what happens in the long-term is that it pays back tenfold.”

The “would a free user recommend it?” test

The success of a freemium model hinges on a single question: would a non-paying user recommend the app to a friend? If the answer is no, the paywall is too restrictive.

Schlenker argues that many apps fail at freemium because their free tier feels like a crippled trial rather than a complete experience. If users hit aggressive limits before they can extract real value, they won’t stick around, and they certainly won’t tell their friends.

To find the right balance, Opal experimented heavily with their “blocks” feature. They tested giving free users just one block, then two, then more. They eventually landed on three free blocks per day. This proved to be the sweet spot—enough functionality for free users to get a great experience and build a habit, while still leaving power users hungry enough to upgrade.

You can’t “vibe code” a brand

With the rise of AI coding tools, the narrative of the “billion-dollar one-person company” has gained traction. The idea is that a single developer can spin up a functional app in a weekend and scale it to massive revenue. Schlenker calls this a lie.

While AI is incredibly efficient at generating functional tools, it cannot generate emotional resonance. A screen time app is technically simple to build—Schlenker notes that people frequently launch Opal clones—but building a category-defining company requires more than just code.

“Teams create product soul. You can’t vibe code a brand,” Schlenker says. “I think that a recipe for failure in my mind is just to create something that has a function, which AI does really, really well… but you need more than that to be able to be successful.”

That “soul” is evident in Opal’s design choices, like the highly engineered, tactile interaction of cracking open a digital gemstone when a user hits a focus milestone. It’s an expensive, difficult feature to build that doesn’t directly move a metric on a spreadsheet, but it’s the exact kind of magical moment that builds brand affinity and long-term retention.

Expanding beyond the App Store into schools

Opal’s organic growth among students led to an unexpected B2B opportunity. A high school in Los Angeles reached out to the company because their students—who were already using Opal independently—suggested the app as a solution to the state’s impending phone ban.

This organically birthed “Opal for Schools,” a specialized deployment that blocks distracting apps while students are on campus, but allows access to educational tools and emergency contacts. Crucially, it’s not just a “bell-to-bell” restriction. Students keep the app after school, using it to manage their own study time and sleep schedules.

By partnering with schools, Opal is essentially building the next generation of professional users while solving an immediate crisis for educators.

In the full episode, Kenneth also discusses why retention is the only real moat for consumer apps, how they turned a viral user video into their most successful ad, and why every AI feature should be evaluated by whether it makes the user win.

Guest links:

• Kenneth Schlenker on LinkedIn
• Kenneth Schlenker on X
• Opal