Sure, shorter trials mean earlier payments, faster feedback for paid campaigns, and lower costs of providing free access. That last one matters most if you’re running an AI app, where every free session carries a real, variable cost behind it.

Yet our State of Subscription Apps 2026 report found a 42.5% median conversion rate for trials of 17+ days, versus 25.5% for trials of four days or less. That’s roughly 67% higher.

But do those subscribers keep paying? And does the pattern differ depending on subscription plans?

We analyzed 17,000+ apps to benchmark conversion and renewal across trial durations for weekly, monthly, and annual subscriptions. We also compared AI and non-AI apps and explored differences by category and subscriber region.

Which trial lengths do high-volume apps choose?

First things first: we looked at the 100 apps with the most trial starts in each category and plan duration, and checked what trial length each one runs.

Short trials tend to dominate. On weekly plans, 81–100 of those apps use trials of four days or less, depending on category.

Monthly and annual plans also lean toward trials of nine days or less, although the mix varies by category.

Education, Health & Fitness, and Travel favor 5–9-day trials, while Productivity and Photo & Video favor trials of four days or less. One possible explanation is how long users need to evaluate the app: some benefits take repeated use to assess, while others are apparent in a single session.

These are apps with the most trial starts, rather than the highest revenue or retention. Their choices show what’s common at scale. But this doesn’t establish which trial length performs best.

That leaves a useful question: how do conversion and renewal compare across those common short trials? And what changes in the less common, longer-trial groups?

How many trial users reach a second payment?

Our data actually shows that longer trials are often associated with higher renewal rates, though the pattern varies by subscription plan:

• Weekly subscriptions: The share of trial users who paid and renewed once is slightly higher after 5–9-day trials than after trials of four days or less: 14.4% vs. 11.8%. Evidence for longer trials remains limited.
• Monthly subscriptions: Longer trials are associated with more trial users paying and renewing: 30.6% after 10–16-day trials vs. 18.5% after trials of four days or less. The pattern then levels off in the 17–32-day trial group.
• Annual subscriptions: The share of trial users who paid and renewed increases with trial length across all four groups, from 3.5% after trials of four days or less to 18.5% after 17–32-day trials. Though trial duration alone may not explain higher retention.

One caveat before we go further: there is a correlational pattern, and a flattering one. Someone who’s still in your trial on day 25 of a 30-day window is simply more likely to pay than someone who bails on day two. Keep that in mind as the ceilings and floors get more specific below.

Do conversion and renewal favor the same trial length?

We also looked at conversion and first renewal separately to see whether longer trials coincide with more users paying, more paying subscribers renewing, or both.

For weekly subscriptions, the difference between the two common short-trial groups is larger at renewal. Trials of 5–9 days convert 24.3% of trial users, compared with 22.3% for trials of four days or less. Among paying subscribers, 65.9% renew after 5–9-day trials, versus 57.9% after shorter trials.

There are too few qualifying apps offering weekly plans with trials beyond nine days to extend that comparison reliably.

For monthly subscriptions, conversion is higher in the 5–9-day trial group than in the shortest-trial group: 45.9% versus 39.6%. The 10–16-day group has similar conversion, at 46.6%, but higher first renewal: 72.0% versus 62.8% of paying subscribers.

The 17–32-day group has the highest first renewal rate, at 77.5%, but lower conversion than either middle group, at 43.7%.

For annual subscriptions, both rates are higher across longer-trial groups. Comparing trials of four days or less with 17–32-day trials, conversion rise from 24% to 44.6%, and first renewal from 18.3% to 47.5%.

Of course, a trial rarely builds a year of loyalty on its own: a longer trial mostly gives annual buyers more time to be sure before a bigger, harder-to-reverse commitment. So the people who convert after that longer look might already be the ones less likely to cancel.

What if you remove the trial altogether?

Here’s another interesting finding: subscriptions purchased without a trial have lower first-renewal rates on weekly and monthly plans than those that begin with one.

The weekly gap is particularly large: 35.9% of paying subscribers renew without a trial, compared with 57.9% after trials of four days or less and 65.9% after 5–9-day trials.

Annual plans show a different pattern. No-trial renewal is higher than renewal after trials of up to nine days, but lower than after longer trials.

Note: this table measures first renewal among paying subscribers, not all trial users, so these numbers run higher. This comparison a;sp doesn’t tell us how many people purchase when shown a no-trial offer.

Lower renewal doesn’t automatically make a no-trial offer less profitable, though. David Vargas’s case study found that removing the trial, alongside changes to pricing and plans, helped one app earn enough per paying customer to support paid acquisition without it.

How does trial length relate to conversion and renewal in AI apps?

For AI apps with usage-based inference or generation costs, extra free access needs to justify its expense. Besides, higher churn with lower conversions means there's less room to get the length wrong.

The monthly results offer a useful comparison.

Trials of 5–9 days and 10–16 days show almost identical conversion, at 38.2% and 38.5%. First renewal is higher in the 10–16-day group, at 64.2% versus 57.4%.

But the 17–32-day group shows no further renewal gain: first renewal is 64.1%, while conversion falls to 31.8%. In this dataset, the longest monthly trials don’t provide a stronger conversion or renewal benchmark than 10–16-day trials.

For annual AI subscriptions, conversion is 33.8% after 10–16-day trials, compared with 23.3% after 5–9-day trials. First renewal is also higher, at 29.4% versus 19.6%. For weekly AI subscriptions, the difference is smaller. Conversion is 23.1% after 5–9-day trials versus 22.3% after trials of four days or less; first renewal is 62.5% versus 57.9%.

Without a trial, first renewal is lower on weekly and monthly AI plans. Annual no-trial renewal is 18.9%, compared with 15.1% after trials of four days or less and 19.6% after 5–9-day trials.

Does giving users more trial time improve conversion across regions?

On annual plans, North America and Western Europe have higher conversion across progressively longer-trial groups. Asia-Pacific follows that pattern up to 10–16 days, but has lower conversion in the 17–32-day group.

On monthly plans, conversion in Middle East and Africa, India and Southeast Asia, and Latin America is highest in the 5–9-day group and lower in the 17–32-day group. The largest gap among these regions is in Middle East and Africa: 38.3% versus 27.4%.

Do the same trial lengths outperform across app categories?

On monthly plans, longer-trial groups generally have higher renewal rates across app categories.

But they don’t always have higher conversion. In many categories, conversion is highest in the 10–16-day group and lower in the 17–32-day group.

When interpreting these differences, consider two timelines: how quickly users recognize the app’s value, and how often they have a reason to return. The data don’t measure habit formation, but those questions can help you decide what extra trial days should accomplish.

Three categories illustrate the differences:

• Media & Entertainment: The 10–16-day group leads on both conversion (58.9%) and first renewal (79.4%), with neither rate higher in the 17–32-day group. For streaming apps, the question to explore is whether extra trial days help users discover more content they want to keep watching.
• Utilities: Conversion is highest in the 10–16-day group, at 47.4%, compared with 44.0% in the 17–32-day group. First renewal is highest in the longest group, at 77.9%, versus 55% for trials of four days or less. A user might recognize a tool’s value after one task. The question for a longer trial is whether it gives them opportunities to use it again.
• Health & Fitness: Conversion is higher in the 5–9-day group than in the 10–16-day group: 46.8% versus 40.4%. First renewal is higher across longer-trial groups, from 51.5% for trials of four days or less to 77.1% for 17–32-day trials. If you’re considering more trial time, check whether users keep completing workouts or logging progress during those extra days. That would give you evidence of continued engagement, rather than assuming a longer trial builds a habit.

So, what's the right trial length for your app?

These findings make a case for challenging a short trial chosen by default. But they also show where longer trials have no clear advantage, helping you narrow down which alternatives deserve a test.

At the end of the day, the answer isn't "run longer (or shorter) trials," "cut trials entirely," or a number copied from the leader in your niche. It's whichever pattern matches your app:

• Time to value. How long a user needs to experience your app before they can fairly judge whether it's worth paying for.
• Habit versus motivation. Utilities' renewal kept climbing long after conversion had already peaked, because deciding fast and building a routine aren't the same thing. Health & Fitness runs the same tension the other way: a longer trial builds the habit, but it also gives motivation more time to fade first.
• Audience context. Price sensitivity and trust in recurring billing can change what a longer trial buys: more confidence to pay, or just more time to back out. So does whether users are weighing you against a free alternative, and how much they need to learn before they can fairly judge your app at all.
• Cost. Longer trial delays revenue and stretches out how long paid acquisition takes to pay for itself. If your app has a real per-user cost behind every session, that spend adds up whether or not the person converts.

The best next action? Use the benchmarks above as a starting point, then test trial length against your own subscription plans, your app's specifics, and what you know about your audience.

RevenueCat Experiments lets you get there faster. Set trial length as the variable, and let your own revenue numbers make the call.

How we analyzed the data

We compared trial conversion and paid renewal separately for weekly, monthly, and annual subscriptions on the App Store and Google Play, with breakdowns by platform, AI classification, category, and subscriber region. We also looked at the 100 apps with the most trial starts in each category.

• Period: August 2025–July 2026, based on trial starts for conversion and renewal dates for retention. The combined trial-to-first-renewal measure follows the same trials through both payments, including earlier annual cohorts.
• Measurement: Median app-level rates. Each renewal rate measures subscriptions that paid again, conditional on the previous payment.
• Sample requirements: More than 100 eligible trials or subscriptions reaching first renewal per qualifying app segment. Groups with fewer than 20 apps are directional.
• Trial coverage: No-trial subscriptions appear only in renewal comparisons. Trials longer than 32 days are excluded from conversion figures.

Watch on YouTube

The $150 Mac that couldn't build iOS apps

César had a computer science degree and a job writing C# for an ad agency when he walked past a shop window in Västerås and saw an iPhone in demo mode, scrolling through contacts. He'd been building for a Sony Ericsson Xperia X1 and hated everything about it. "I just saw it and I was like, 'Oh my God, this is amazing.'"

That night, a well-known Swedish comedian posted asking whether someone could make him an app. "And I have no idea how to build an app. I didn't have a Mac. I didn't know what Xcode was. I knew nothing," César says. Charlie's follow-up: "Well, you didn't even have an iPhone at this point, right? You just saw one?" He hadn't. He wrote back anyway, agreed a price, and went back to the store to ask what he'd need.

They sold him a returned PowerBook G4 for $150. He installed Xcode, opened the sample project, hit build, and discovered that iOS apps needed an Intel Mac to compile. "So I had to spend all the money I was getting paid to build the app to buy my first Mac. So that's how I got into app development."

The app itself was a blog reader: a WordPress plugin he wrote to expose posts as JSON, pulled into a list. "When there only was one screen size," as he puts it. The commitment came before the tooling, and the fee paid for the tooling. He's been employed as an iOS engineer since 2011.

A CloudKit experiment, forgotten, then handed to a beginner

Around the time CloudKit launched, César built a recipe app to see what the framework could do. Recipes were CloudKit records; you could see other people's. He named it Cooking, shipped it, and moved on. "I put it out there and I forgot about it."

It kept being used. One user had more than a hundred recipes in it, which mattered because of a detail Sofia raises: you couldn't reorder instructions or ingredients. Get a step wrong and you redid the recipe. Charlie: "This is the classic looking for some app as an excuse to try out a piece of technology."

Years later, Sofia wanted to learn to code. She'd started with Swift Playgrounds on an iPad, steering a character called Byte through a maze. César had an app lying around that he wanted rebuilt in SwiftUI. "Why don't you just rewrite all the views?" Charlie's verdict: "Easy first task."

"I started just building up the views and I guess I never stopped because I'm still building the views." Her biggest obstacle wasn't the logic. "I didn't have any terminology. So when I wanted to Google for something, I had to describe what I wanted." Even the word modifier wasn't hers yet. Cooking became Ambre, and Ambre started getting featured on the App Store.

Apple said the call was of utmost importance. It was a two-hour technical interview.

Sofia's plan was to get good enough to be hired as a developer somewhere. Then César saw a post from Apple's Mike Stern about Apple Entrepreneur Camp and told her to apply.

"I was terrified and César said, 'Oh, well, what's the worst thing that's going to happen?' They say no or they say yes. And I said, 'Yeah, that's the worst thing. They can say yes.'" Because then she'd have to do it.

The email that came back said it was imperative to get a call scheduled that week. She asked César what Apple could want. His guess: a five-minute welcome call, they just want to tell you you're in. "Oh, it turned out it was a technical interview for two hours."

She got in. The camp ran virtually during the pandemic, two weeks of DTS hours with Apple engineers, design sessions with Apple designers, and pitch training, on a nine-hour time difference. "We literally slept and ate and coded." What she took from it, she says, is going to sound cheesy: "my confidence, because going in, I felt like such an imposter. I was nervous at every meeting thinking, oh, they're going to call me out." The environment did the opposite. Her first client project followed, with César, across three time zones.

Everyone posted code. She posted about color.

Ambre's marketing, by their own account, has been light: an Instagram account that mostly works as a way for users to reach them. What grew was Sofia's own presence, after César and a contact at Apple all but pushed her into it.

She posted about app development with a tilt toward UI and design, and it found an audience. Her explanation: the community's feed was mostly code — someone found a new API or SDK and tried it out. "Whereas I would like, ooh, this color combination is super nice. And if you put it this way in the layout, it would read much better." Being one of the few people talking about design in a stream of code posts was the differentiation.

Charlie's own first memory of them is a marketing move too. On the roof of the Apple Park Visitor Center, Sofia handed him a card with a QR code. It opened Ambre as an App Clip, inside which another QR code led to a recipe: how to make Swedish fish. Then she pulled a bag of actual Swedish fish out and handed it over. "I watched you do this to other people after me, and we all had the same reaction." His conclusion at the time: these are very fun people.

Does the code really matter anymore?

The episode ends where the edit opens, on a question that a designer-and-engineer pair are unusually well placed to argue. César's position: "With AI today, we can build so much stuff. The thing that's going to put you apart or your product apart from the competition is the experience you offer." The feature set won't do it; design is about to matter more, not less.

He borrows an analogy from a Linux figure he'd seen quoted: complaining that you don't know what AI-generated code is doing is like complaining that you don't read the assembly. "What we own is the UX and quality of our app. Our customers are not going to read the code."

Sofia's version comes from the toolbox. "Procreate is a tool. An iPad is a tool. A pencil is a tool. When you buy watercolor, it's pigment and something that bind the pigment." AI is the next one, and it opens the door for designers who had the idea in their head but not the means to build it. This year that's been her: "I can talk directly with Claude and see my ideas come to life within minutes, hours, depending on the complexity."

Charlie pushes back a little — AI-built things feel similar unless someone is making all the small choices — and César closes with the question he wants developers to sit with: "If you make sure QA is awesome, the app looks amazing and it solves a real problem, does the code details really matter?"

Also in the full episode: what a textile engineer actually studies (geotextiles under airport runways, a thesis on getting a medical bandage to a CE standard), César's detours through blackjack dealing and Volvo factory software, the designers Sofia keeps a running iMessage thread with herself about, and the Ambre update landing with iOS 27.

Guest links

• Sofia Larsson on LinkedIn
• César Pinto Castillo on LinkedIn
• Ambre on the App Store
• Ambi Studio

We’ve been polishing the agenda for months, and it’s finally ready for your eyes: five keynotes and 36 workshops, split across exclusive virtual and in-person content. So whether you’re joining us in NYC or from the comfort of your home office, you’ll be leaving with fresh ideas and the momentum to ship them.

Keynotes

Here’s what’s heading up the main stage: five sessions from app leaders about what worked, what didn’t, and what they’d do differently — straight from the people building the apps.

All the keynotes will be available to watch on YouTube after the event. So even if October 21 is back-to-back meetings for you, there’s no need to miss anything. Register now to get sent the replays as soon as they drop.

Confidence engineering: why your app's activation flow is probably too short — Ravi Mehta, ex-CPO, Tinder

Every mobile growth team obsesses over friction — fewer screens, fewer fields, fewer taps between install and activation. It's conventional wisdom, and it's incomplete. One healthcare app replaced a three-step checkout with a twenty-five-step intake flow and conversion jumped 40%.

At Tinder, Ravi's team did the opposite — stripping onboarding to under two minutes to pull in millions who'd never have finished an eHarmony profile. In this session he'll share a framework for diagnosing your own flow: when to strip friction to the bone, when to add steps that earn trust, and how to spot the 'death zone' where teams split the difference and get the worst of both.

You'll leave with: a way to audit your own funnel, step-by-step, and a sharper question than "should this be shorter?"

Breaking the rules on purpose: the contrarian bets that built Babbel — Julie Hansen, CRO & US CEO, Babbel

Every subscription app has heard the same advice: never sell lifetime deals, don't bother with web checkout, go freemium to keep the funnel full, spend only on acquisition… Well, Babbel has ignored most of the advice — and is still here, 30 million subscriptions later.

As Babbel’s US CEO for nearly a decade, Julie had a hand in most of those bets. She’ll walk through why they made them against the advice of the day, which ones they’d make again, and what they cost Babbel.

You’ll leave with: the insight to discern which rules in your own playbook are real, and which are just habits the industry hasn’t questioned yet.

Built to burn: how to turn a high-churn product into good subscription economics — Greg Cohn, Co-founder & CEO, Burner (Ad Hoc Labs)

Burner is an app for disposable phone numbers, with a button that destroys the very thing you're paying for… yet it has been growing and profitable for almost a decade. In fact, half of Burner’s new subscription revenue on iOS is from users who previously churned.

Greg says they didn’t plan it that way. But along the ride, they learned not all churn is failure — some of it, in fact, is success. His session will tell the story of that success: from designing for profitable churn, to cohort math and monetization architecture.

You’ll leave with: analytical frameworks and mechanics you can steal — and a sneak preview of the new-to-the-market retention hack Burner’s testing next.

Speedrunning subscription monetization: what Tolan learned when the AI bill came due — Ajay Mehta, Founder, Tolan

For a decade, subscription apps ran on one assumption: the marginal cost of a subscriber is roughly zero. AI broke that. Now free users cost real money, and the heaviest users can cost more than they pay.

At Tolan, they learned this lesson in week one, when the OpenAI bill outgrew their userbase and a paywall became a survival mechanism. Since then, the team has run a decade’s worth of monetization plays in double-time. Ajay will recount each of these decisions; what they expected, what actually happened, and how they came to their ultimate monetization rule: would they be happy explaining it on a podcast?

You’ll leave with: a sense of what the end of zero marginal cost means for your own pricing, whether you're building an AI app today or adding AI to the one you have.

RevenueCat product update ahead of 2027 — Jacob Eiting, CEO & Co-founder, and Miguel Carranza, CTO & Co-founder, RevenueCat

We won’t spoil too much about our product keynote, but you can expect a retro on the last 12 months, roadmap reveals, and live product launches.

You’ll leave with: an insider's look at what's next for RevenueCat.

In-person workshops (block one)

One of App Growth Annual’s biggest opportunities is getting the right people in one room, asking the same questions you’ve been wondering about. Whatever your focus is right now, there’s a hands-on session to help, filled with genuinely useful conversations.

Apple Ads 2026, beyond the basics: what changed, what matters, and how to act on it — Thomas Petit, Growth Advisor

Apple Ads has changed more in the last two years than in the eight before it. This interactive session skips the 101 and tackles four core questions: Which numbers can you trust? Should you let Apple decide how you buy inventory? How do you test and iterate on creatives? And how much should you really buy?

Each question is unpacked with Thomas’s personal experience, how to use the functionality, and where the numbers can fool you. Expect questions, strong takes, and polite disagreement. Not recommended for ASA beginners.

You’ll leave with: a varied set of perspectives and focused examples to help inform complex ASA decisions.

Signal engineering: build your subscription app signal plan — Shumel Lais, Co-founder, Day30

Want to send better signals to Meta, Google, and TikTok, but your event tracking and measurement setup isn’t ready for it?

Shumel’s workshop will have attendees audit their own subscription funnel from install through renewal, scoring your existing events against speed, volume, intent, commercial value, and measurement reliability. Take part to identify which signals to test first and what you need to fix before you begin.

You’ll leave with: a signal readiness scorecard and prioritized action plan for your growth and data teams.

The executive roundtable: networking and problem-solving with fellow leaders at scaled apps — Ron Schneidermann, CEO, Acely

No agenda, no slides — just candid discussion and problem-solving with a small group of fellow app executives. Ron kicks the session off with lessons from scaling AllTrails to millions of subscribers, then opens the floor to questions and discussions on team building, product decisions, and growth challenges.

You’ll leave with: fresh perspectives from peers who’ve been there too.

The viral iteration loop: adapt trending content into high-converting creative — Diego Kafie, CEO & Co-founder, Noise

Viral content already exists in your niche — the opportunity is turning it into creative that drives installs for your app. In this workshop attendees will search live for what's working on TikTok and Instagram in your category, break down why it's performing, and adapt it into iterations you can test as paid or organic creative.

You’ll leave with: a shortlist of proven content angles tailored to your app, and a repeatable process for finding and adapting them.

How AI is changing subscription app monetization — Phil Carter, Founder and CEO, Elemental Growth

LLM-powered features carry non-trivial costs, but most subscription apps are still approaching monetization as though their gross margins haven't changed. Spend this session reviewing the strategies that the best AI apps are using to adapt: restricting freemium, shortening trials, adding higher-priced AI tiers. Wrap up by benchmarking your own metrics against peer apps and apply proven pricing tools (Van Westendorp, Gabor-Granger, MaxDiff, Conjoint) to your own packaging.

You’ll leave with: a benchmarking tool, a pricing study template, and playbooks for adapting your monetization to the AI era.

How to launch and grow your app in Japan and Korea — Hyerin Choe, Customer Success Lead, AB180

Japan and Korea are two of the highest-spending mobile markets in the world, but most Western apps stall at entry because the playbook that works in the US doesn't translate. Join Hyerin Choe from Korean app growth agency, AB180, to identify where your current growth strategy breaks down and build a localized go-to-market plan.

You’ll leave with: a market-entry framework covering channels, positioning, and the cultural signals that data alone won't reveal.

Build a user research system that runs itself — Ekaterina Gamsriegler, Growth Consultant & Director of Growth at DataCamp

Most apps run user research in bursts, then go dark for months. Ekaterina will walk through how to design an always-on feedback system for your app instead. From choosing the right research inputs (cancellation surveys, in-app prompts, price sensitivity polls), to writing the templates, mapping distribution channels, and building a cadence that feeds insights into your experimentation pipeline without becoming a full-time job.

You’ll leave with: a research system that’s ready to launch next week.

Beyond the first growth hire: building a remote growth and marketing team that scales from 0 to $50M — Olivier Lemarié, VP of Growth, Photoroom

Growth can't stay founder-led forever, but knowing when to specialize, who should own what, and which capability to build next is where scaling companies stall. Olivier’s workshop helps you map your current growth org against the capabilities needed to scale subscription revenue — paid, lifecycle, product growth, pricing, creative, data, international — and identify ownership gaps, missing roles, and your next hires.

You’ll leave with: a growth org map and prioritized hiring plan for your next stage.

Roast my ASO: your App Store listing, audited live — Steve P. Young, Founder, App Masters

Bring your App Store listing and get it torn apart live. Steve will audit real participants' metadata, screenshots, and keyword strategies against what's actually driving installs in their category — with pre-prepared case studies showing where AI-assisted ASO is outperforming manual approaches.

You’ll leave with: knowledge of exactly what’s costing you rankings and downloads — and what to fix first.

Find the moment your app earns the right to ask for money — Olha Yohansen, Independent Growth Consultant

Has your app earned the user’s trust by the time it asks for money? Olha’s workshop will get you mapping your own onboarding to pinpoint where users first feel “this app gets me” — and check whether that moment lands before or after you ask them to pay. If it's after, you're converting on template momentum, not trust.

You’ll leave with: a redesigned onboarding sequence that puts the aha! moment where it belongs.

In-person workshops (block two)

Our second round of workshops offer 10 hands-on sessions packed with in-the-trenches tactics to grow your app. We know it’s hard to choose, but whichever session you attend, you’re guaranteed to leave with new ideas and experiments to try right away.

Meta UA in 2026: what still works, what's changed, and how scale changes the game — Gessica Bicego, Fractional CMO, Independent Consultant

The right Meta campaign structure depends on your spend level, but most teams use the same setup whether they're spending $10K or $500K a month. Gessica’s workshop will group attendees by budget range where you’ll work through how campaign structure, optimisation approach, setup (CBO, Advantage+, W2A, signal engineering), and creative strategy should adapt for your scale.

You’ll leave with: understanding of which structure fits your current spend and what to change as you grow.

Google Ads for iOS: how to make it work — Ashley Black, Founder & CEO, Candid Consulting

Google has been overlooked as a serious iOS acquisition channel, but the platform has changed, and the opportunity is bigger than most teams realize. Join Ashley to evaluate your own app against Google's current campaign types, identify which formats match your funnel and audience, and stress-test whether the setup pain is worth the payoff for your specific scale and category.

You’ll leave with: a clear yes/no on Google Ads for your app, and a plan for what to test first.

How your ad creative shapes your LTV — Nataliia Drozd, Independent Growth Expert

The creative that lowers your CPA isn't always the creative that attracts subscribers who stay. Viral hooks and trending formats can flood your funnel with users whose expectations don't match your product — and you won't see the damage until retention data catches up. In Nataliia’s workshop, you’ll map the relationship between your creative narratives and the customer segments they attract, then test your assumptions in a simulation using real campaign data.

You’ll leave with: knowledge of which creative angles to scale, and which are quietly eroding your LTV…

Hybrid monetization: add new revenue without hurting your subscription — Cristian Rotari, Independent Consultant

Not every user will subscribe, but that doesn't mean they're worth zero. In this session you’ll map your user segments, identify which audiences are under-monetized, and evaluate which hybrid tactics fit your product: ads, IAPs, credits, affiliates, partnerships.

Finish by building a monetization ladder for your app and running a cannibalization check to confirm new revenue streams are truly incremental, not cannibalizing existing subscriptions.

You’ll leave with: one experiment that’s ready to test in the next 30 days.

Design habit mechanics that don't fade after week one — Yves Benchimol, CEO & Co-founder, WeWard

Gamification mechanics lose their impact the moment novelty wears off. Most teams respond by layering on more features, rather than questioning whether the mechanic should exist at all. Join Yves to apply a motivation-first framework to your own product and identify what's actually driving repeated use. You’ll then evaluate which mechanics are earning their place, and find where simplifying or removing features would improve retention more than adding new ones.

You’ll leave with: a clear map of which habit mechanics to keep, kill, or redesign.

Ship faster with AI without learning slower — Ethan Garr, Growth Advisor, Breakout Growth Labs

AI has collapsed the time between idea and shipped feature, but most teams haven't upgraded their learning loops to match. You're deploying faster, but are you discovering what users value faster, or just building confidently in the wrong direction?

Ethan will walk through how to map your current growth initiatives across a Velocity vs. Learning Matrix, to identify where AI is genuinely accelerating progress, and where speed is masking the absence of real customer signals.

You’ll leave with: a prioritized view of where to let AI run and where human judgment is key to helping more users reach experiences they can’t live without.

Diagnose your biggest revenue bottleneck — Alice Muir Kocourková, Independent Growth and Subscription Consultant

You've spent the last quarter optimizing something, but was it the right thing? Most teams pour effort into onboarding when the real opportunity is renewal, or obsess over trial conversion when Month 3 churn is quietly draining more revenue.

Join Alice to score each stage of your subscription lifecycle against industry benchmarks, identify where the gap between your app and the norm is largest, and prioritize fixes using an Impact vs. Effort framework.

You’ll leave with: your bottleneck diagnosed, and a 90-day plan to close it completely.

Segmentation as a growth engine: how to scale across segments without breaking efficiency — Bohdan Lopatiy, Product Director - Growth, Flo

Most teams know they should segment, then hit the cost of it: split your users enough ways and every test is underpowered, every cohort too small to read, and the efficiency you were chasing disappears into a hundred experiments nobody can act on.

For this workshop, you'll slice your user base several ways, work out which splits actually change what you'd build differently, and find the segment you're currently treating as an average when it isn't.

You’ll leave with: a segmentation model sized to your actual traffic.

From investment to exit: tactics for raising capital and selling your business — Eric Crowley, Managing Director, Houlihan Lokey

Whether you're preparing for a fundraise or positioning for acquisition, the gap between ‘growing nicely’ and ‘investor-ready’ is usually a handful of specific metrics and positioning decisions. Eric’s workshop will offer a chance to benchmark your business against what buyers and investors are actually looking for right now, identify gaps in your financial story, and pressure-test your positioning with the room.

You’ll leave with: readiness to navigate your next round or exit conversation with confidence.

Roast my web funnel — Nathan Hudson, Founder, Perceptycs / Swoopy

Your web funnel follows the playbook. But the playbook doesn't account for your category, your traffic, or the assumptions baked into every ‘best practice’ you copied.

Come along to Nathan’s web funnel roast and put your funnel on screen to get it torn apart from ad to checkout: what's cargo-culted, what's actually earning its place, and which experiments carry hidden risk.

You’ll leave with: prioritized test hypotheses and the context for why the obvious fix might not be yours.

In-person workshops (block three)

Wrapping up the day, our final block of workshops are definitely last but not least. Expect intimate conversations, practical takeaways, and new playbooks to take home.

Affiliate marketing: when it works and how to start — David Vargas, App Growth Consultant

Most apps treat affiliate marketing as an afterthought or assume it only works for e-commerce. But at scale, it can deliver high-intent users at a fraction of your Meta CPAs — if you pick the right partners and structure the right payouts.

David’s workshop will give you the chance to assess whether your app has the economics and category fit for affiliate marketing, map your ideal partner types, and design a commission structure that protects your margins.

You’ll leave with: a go/no-go decision and a 30-day launch plan.

Build an organic-to-paid acquisition engine — Shane Troy, Co-founder & Partner, Cousin Labs

Organic and paid teams rarely drive the same outcome, and the translation layer between them is where most growth teams leave the biggest gains on the table. In this session, you’ll map the exact loop that turns organic content into scalable paid creative: hypothesis design, creator selection and coaching, asset tagging, feedback loops, and the velocity payoff when winning formats feed directly into paid briefing.

You’ll leave with: a playbook to connect your organic and paid programs immediately.

Your creative pipeline is broken and more AI won't fix it — Elise Zareie, Head of Paid Social, Lingokids

AI handles analysis, iteration, and automation well, but when it's producing your actual ad creative, you often get volume without differentiation, or content that erodes trust with your audience. Join Elise’s session to audit your current pipeline and separate where AI earns its place, versus where it’s producing sameness. Finish by designing the right mix for your vertical: what stays AI, what needs human creators, and how to build that alternative without blowing your budget.

You’ll leave with: a creative production map tailored to your app and audience.

Ad monetization playbook for subscription apps — Felix Braberg, Ad Monetization, 2.5 Gamers

Your app is sitting on a monetization layer it's probably not using (or not using well). Ad revenue data reveals what each user segment is actually worth and whether they should be subscribing or staying on a free, ad-supported tier. This workshop covers how to read impression data as a willingness-to-pay signal, segment users accordingly, and set differentiated pricing.

You’ll leave with: a segmentation framework and a step-by-step tracking setup guide.

Make your app a habit: the lifecycle messaging that keeps people coming back — George Deglin, Founder & CEO, OneSignal

How do you make your app part of your customers' routine? Join this workshop to identify a behavior worth repeating, map where users drop off before they get there, and work out which of those moments can actually be fixed with messaging — and which are product problems a message won't solve. Wrap up by drafting a three-touchpoint journey with the audience, timing and rules behind it.

You’ll leave with: a brief you can hand to your team, from draft messages to behavioral rules and a measurement plan.

From 1 to 100 A/B tests per month: a practical framework for scaling experimentation — Olga Berezovsky, Head of Data & Analytics, Data Analysis Journal

Running more A/B tests doesn’t necessarily mean learning faster. As experimentation programs grow, tests often compete for the same traffic, run for months, and produce results that teams don’t trust. In this workshop, you’ll learn how to decide which ideas deserve a fully powered A/B test, which should be evaluated using faster methods, and which aren’t worth testing. You’ll then spend time scoring your current test portfolio by potential business value, identifying where rigor is slowing down learning, and redesigning your pipeline to complete more meaningful experiments.

You’ll leave with: a prioritized experimentation roadmap sized to your actual traffic and resources.

Your AI marketing team: what it can run, what it can't, and what to do about the rest — Jessica Gotti, Head of Performance Marketing, Bend

One marketer with AI can now do the work of a small team. This session breaks marketing into single functions and asks one question for each: can AI run it alone, does it just help, or is it still a person's job? Each answer comes from practice — real projects where AI took over, helped, or failed.

You’ll leave with: a map of the AI marketing team and real examples to make it work.

$1M to $10M ARR: the founder-to-CEO mistakes that stall your next stage — Josh Peleg, Vice President M&A and Business Development, BlueThrone

The skills that got you to $1M ARR won't get you to $10M, but they’ll get you to this workshop and that’s pretty close. Join M&A guru Josh to audit your own setup and mindset across four dimensions — growth, product, monetization, and team – and identify which founder habits are now bottlenecks. Bring your real growing pains; the room will workshop them together.

You’ll leave with: knowledge of the three changes needed to unlock your next stage.

Fix your activation before it kills your retention — Daphne Tideman, Growth Advisor & Consultant, Growth Waves

Your activation metric is probably measuring activity, not predicting revenue — which means every onboarding test you've shipped this year optimised for the wrong thing. Daphne’s session will help diagnose whether your drop-off is a trust, context, or value problem, before you’ll define the one user action that actually predicts LTV, and pressure-test it with the room.

You’ll leave with: a validated activation hypothesis and one test to ship next week.

Hyper-personalization in app onboarding and monetization — Thomas Cotter, Principal, Elemental Growth

Many apps invest heavily in personalizing onboarding and monetization without seeing meaningful ROI. In this workshop, you’ll learn how to make personalization actually work: what information to collect, how to identify and prioritize opportunities, where and how to experiment, and what to measure. Thomas will walk through real examples, then put attendee apps on screen for live personalization teardowns and test ideas.

You’ll leave with: a shortlist of personalization tests to run, prioritized by likely impact.

Virtual workshops

You didn’t think we’d neglect those watching from home? Our online attendees have six insightful sessions to choose from, but even better — unlike the in-person workshops, these will be recorded and shared to watch back after the day. So no need to panic if you can’t decide which one to tune in to!

Make AI-generated ads that actually convert — Julien Daver, Head of User Acquisition at SplitMetrics Growth Services

Generic AI creative tools promise to fix the production bottleneck of creative production every UA team is battling — but mostly, the output tanks your ROAS, or gets rejected by the network outright. For this session, Julien shares how his team actually integrates AI into their creative workflow, with real campaign data on what worked and what didn't.

You’ll leave with: a production framework built for mobile performance constraints, rather than a list of prompts.

From competitor ad to finished creative, in one hour — Sven Jürgens, Mobile App Growth Consultant, Sven Juergens Consulting

Your competitors have already paid to find out what works in your category, and the results are sitting in a public database anyone can open. What are you waiting for?

Sven will share the whole process live: pulling a competitor's longest-running ads from the Meta Ad Library, lining up the first three seconds of each one until the pattern is obvious, then writing the brief and building the creative that answers it. Copying their ad might get you a worse version of theirs; but answering the pattern gets you yours.

You’ll leave with: a one-page checklist of the nine steps to run this process on your own category the next day.

6+1 AI workflows to scale Meta from your phone — Marcus Burke, Meta Ads & App Growth Advisor, Ctrl Shift

With AI, small and midsized teams can get much of the operating leverage that used to require a fully staffed marketing and growth team. In Marcus’s workshop, he’ll walk through the workflows used across real clients, all drawing on a shared memory that compounds as it learns your account, and how each one makes Meta easier to operate and scale.

You’ll leave with: real workflows Marcus runs across client accounts.

Copy that converts: the language-market fit teardown — Lisa Kennelly, Growth and Product Marketing Strategist, Klarna

AI-written onboarding and paywall copy reads fine but converts flat — because nobody fed it real customer language. In Lisa’s session you’ll learn how to mine App Store reviews, support tickets, and cancellation reasons for the actual phrases, anxieties, and objections your users use, then watch a section of conversion copy rewritten live using what that turns up.

You’ll leave with: a repeatable method for mining customer language going forward.

Building apps people want: the playbook behind 23 million organic downloads — Bria Sullivan, CTO & Founder, Honey B Games

Most app developers build features nobody talks about. In this session, Bria will share the system she uses to decide what to build, and the process of making sure the ideas are compelling enough that users will tell their friends. From researching the market to running surveys, customer interviews, and testing visual directions on real people, this is Bria’s full workflow.

You’ll leave with: a repeatable process for designing features around what your target users actually want.

Yulia Lennox, Genesis Tech

Details on the final workshop are coming soon, so stay tuned.

Other highlights

But App Growth Annual isn’t just about keynotes and workshops. Also on the agenda:

Who wants to be a millionARR?

The live interactive game show where app growth knowledge meets dramatic tie-breaker questions, phone-a-friend lifelines, and (of course) real buzzers. If you want to take part you’ll have to make it through the audience qualifier round, before beating fellow contestants in different categories to make it to the top of the leaderboard.

With questions covering app trivia, industry knowledge and growth benchmarks, we’d suggest you start polishing up your knowledge now… (The State of Subscription Apps is good revision material!)

Exclusive virtual content

Online attendees get access to all the main stage content, streamed live from New York, but they also get to enjoy a whole hub of virtual-only material. Including: a networking breakout room, virtual Expo Hall to speak to RevenueCat and partners, and 1:1 speed dating-style networking.

Best of all, you can enter The Meowtrix, an interactive challenge for your App Growth Annual experience. Gather the most points among attendees by checking off specific side quests to climb the leaderboard and claim your prize.

The legendary afterparty

Last year saw Jason Paige (of Pokémon theme fame) bring the energy with a performance of RevenueCat’s official theme song. We then had DJ Jazzy Jeff soundtrack the evening while folks networked, got airbrush tattoos, custom caricatures, and enjoyed plenty of delicious street food.

Will Jason Paige be back this year? Who knows. Will we play the RevenueCat theme song regardless? Probably. Will there be tasty food and free drinks? Of course!

And that’s our full lineup for App Growth Annual. A jam-packed schedule filled with insights, inspiration, and new connections — maybe you’ll even meet your future co-founder.

We’ll see you on October 21!

None of them were canceled because they were bad or too expensive. They were canceled because, well… I wasn’t using them. Oops.

And it turns out I’m not alone.

According to the State of Subscription Apps 2025, ‘not enough usage’ is the number one reason people cancel subscription apps, accounting for 37% of cancellations — ahead of ‘price’ at 35%. The 2026 report showed we got a little more price-sensitive, but ‘not enough usage’ is still the second biggest driver of churn; ranging from 26%–40%, depending on the category.

When I covered ‘not enough usage’ in my top five cancellation reasons article, I gave it a short and sweet section. This has bothered me ever since. I haven’t seen a single article or podcast give this mega churn reason the attention it deserves. So here we go!

By the end of this read, you'll be able to tell the difference between a usage problem and a price problem. More importantly, you’ll know what to actually do about each issue.

How to diagnose price vs. usage churn

Here's the hard part: you often don’t know for sure why someone actually left. Even when you have a stated cancellation reason (Google Play surfaces these, while the App Store is a little trickier), cancellation surveys are not the reliable source of truth many teams treat them as.

A SaaS study on 723 participants by User Intuition found that stated exit reasons matched the actual churn driver only 27.4% of the time. Price was the reason 34.2% of churners gave, but it was the real driver in just 11.7% of those cases. Whilst the study wasn’t focused specifically on mobile apps, the lesson still holds: the reason someone gives when they cancel is often the surface explanation, not the underlying cause.

“Too expensive” might actually mean “I wasn’t getting enough value.”

“Not using it enough” might actually mean “I stopped believing this would work for me.”

So don't stop at the survey data. Use quantitative signals to understand whether you’re dealing with a price problem, a value perception problem, or a usage problem. Look at things like engagement patterns, feature adoption, time-to-value, and retention cohorts.

Then layer in qualitative research (user interviews, cancellation conversations, and feedback from churned users) to understand the story behind the numbers.

1. Define your version of ‘enough’ usage

Before you can solve for usage or even start a lovely little quantitative deep dive, you need to know what ‘enough’ actually looks like for your app. And sometimes ‘enough’ is much less frequent than you expect. Sometimes it varies wildly between user groups.

I worked with a meditation and workshop app where some users opened it once every month or two and still happily paid for an annual subscription. Because the value they got from that single session was high enough to justify the cost.

Meanwhile, other users who opened the same app a few times a week didn’t think it was worth paying for. Same app, but completely different definitions of ‘enough’.

As Dan Layfield of Subscription Index argued, usage cadence should match how long and how often the user actually experiences the problem you solve. A fitness app might need three sessions a week. A meditation app might need daily engagement. A personal finance tool might only need to be opened once or twice a month. Daily active users are often the wrong metric entirely.

This is exactly the point Asya Paloni of Welltory also makes: Duolingo's daily streak and light-guilt mechanics work because the behavior is tiny — opening the app for three to five minutes gives the user an immediate reward. That model does not translate neatly to a behavior-change app where the user has to do something difficult in the real world.

Asya suggests that reminders and human support improve engagement in those contexts, while gamification (especially shallow attempts like badges and streaks) often doesn’t improve retention. In some cases, forcing the Duolingo playbook onto a health or finance app can actually make things worse, creating pressure around the wrong behavior.

The classic activation thresholds are useful reference points:

• Slack found that around 2,000 messages correlated with teams that almost never churned
• Facebook identified reaching 7 friends within 10 days.
• Twitter/X focused on following 30 accounts.

All widely reported. All completely different. All built around the natural cadence of a specific use case. So the question is: what’s yours?

Then it’s time to start running the analyses that actually matter.

2. Look at pre-cancellation usage

Start with the 30 days leading up to cancellation for churned users. Were they still actively using the app? Or had usage already dropped to almost nothing?

If engagement had fallen off a cliff before they canceled, that’s a usage problem. The cancellation was just the final step.

If they were actively using the app right up until the moment they left, then price (or another factor) becomes a much more likely driver.

The key question: did they stop because they stopped seeing value, or did they stop because the price no longer felt justified? This guide on spotting churn before it happens covers the signals to look for in more detail.

3. Segment churners by usage frequency

Look at who is saying they left because the app was ‘too expensive’.

Are your heaviest users also citing price as a reason for leaving? If so, you may have a genuine pricing or value perception issue.

But if price complaints are concentrated among your lightest users, you might actually be looking at a usage problem wearing a price mask. They’re not thinking, “This costs too much”. They’re thinking, “I’m not getting enough out of this to keep paying”.

4. Compare cancellation reasons across price tiers (if applicable)

If you have multiple pricing tiers, compare churn reasons by plan. If your lowest-priced subscribers are still saying ‘not enough usage’ rather than ‘too expensive’ — especially if their actual usage data is low — the problem probably isn’t the price. The issue is that the product hasn’t become valuable enough in their routine.

Price is often the reason people say when the value equation stops making sense. The job is figuring out whether the problem is the number on the bill or the value on the other side of it.

Why the discount reflex is the wrong response to churn

What most teams do when they see ‘not enough usage’ in a cancellation survey is slap a discount on it. But think about it. If someone isn't using the app, why would they care what it costs? The issue usually isn’t that the app is too expensive. It’s that they’re not getting enough value. Lowering the price doesn’t fix that.

I saw this play out with a previous client. The cohort that signed up with a 50% discount had a £50 lower lifetime value (LTV) and higher churn than the full-price sign-ups. Cheaper didn't fix usage, it made things worse.

A discount doesn’t repair any of those four points where a habit can break; it won’t create a trigger that brings someone back, or refresh a reward that stopped feeling valuable. So don’t try to win back usage churners with a price cut. Find where the habit is breaking, and fix that instead.

‘Not enough usage’ is actually just a broken habit

The reason this category gets so little attention is that the label itself is a catch-all. What does ‘not enough usage’ actually mean? And is it just a softer version of ‘it’s too expensive’?

Does it mean that your subscriber:

• Forgot about your app? (How dare they!)
• Used it for a bit and stopped? (But why?)
• Lost interest in your app? (Ouch.)

I quit my Peloton subscription last year. I never received a cancellation survey, but if I had, I would have selected ‘not enough usage’. And that was true; I wasn't using it enough anymore. But the real reason was that I'd fallen out of the habit because it had started to feel repetitive, and I wasn't seeing any difference in my workouts. ‘Not enough usage’ was the symptom — the actual cause was my habit coming apart.

That word, ‘habit’, is the whole thing. Almost every version of ‘not enough usage’ comes down to:

• A habit never formed
• A habit failed to deliver enough value
• A habit quietly fell apart

If you want to fix usage, you first need to understand how a habit actually holds together.

Nir Eyal's Hook Model is one of the clearest ways to think about habit loops:

1. A trigger (a notification, a time of day, a feeling, or a problem they want to solve) brings someone back to your app
2. They take an action (use the app)
3. They receive a reward that feels worth the effort
4. They invest something (a preference, a history, a streak, personal data) that makes the next cycle easier and increases the cost of leaving.

Repeat that loop enough times, and a habit forms. But remove the value from step three, and the loop collapses. You could argue that the reward is the most important part, and technically it is. But I think it goes deeper than that. You can create a short-term dopamine hit; a temporary reward, or a moment of engagement — but if the user doesn’t believe the app is delivering real value, the habit won’t survive. A habit isn’t built on activity alone. It’s built on the belief that coming back is worth it.

Usage churn is this loop breaking. And in my experience, it tends to break at one of four predictable points.

The trigger never fired

Out of sight, out of mind. This happens right at the start, or with low-frequency apps, where people quietly drift back to whatever they used before because it's easier. This is the “I forgot about it” category.

You download a new recipe app, but you still end up opening Instagram or reaching for a dog-eared cookbook (guilty!). The novelty that made you download it faded before the app earned a place in your day, and once it's off the home screen, it's gone.

How to fix a trigger that never fired

Try a well-timed re-engagement sequence (not spray-and-pray notifications). Look at when usage typically drops during the billing cycle for your product, then meet users there with something genuinely useful.

I’ve seen this work directly: for users who had hit our definition of inactive (hadn’t completed a workout in five days), we sent a small number of targeted emails that acknowledged where they were and prompted them to re-engage. It drove a 100%+ lift in people completing a workout within three days, versus the control group who received no emails.

Focus on relevance and timing, not volume.

The action never stuck

Some people get going and still don't stick. The hardest part of a new habit is usually the beginning, when the effort is real, and the results are not visible yet. A five-minute journaling practice or a morning stretch feels like more work than payoff in week one. People start with good intentions, but then they slip once or twice, and never come back. This often starts with onboarding that's too short to reach the moment where the app clicks.

The other half of sticking is finding a slot in the day for it, making it a part of your routine. My Spanish used to be decent. Then I left Spain after living there for a few months, stopped practicing, and it faded. During a trip to Ecuador, embarrassed by my Spanish and keen to pick it up again, I started using a language app: a lesson in the morning, another while waiting for the boat. But when I got home, I had no natural moment to keep it up, and I drifted. My older sister is the opposite. She practices French every night right before bed. Same time, same trigger, sticks to it religiously.

That is the difference between an action that sticks and one that doesn't: a trigger that fires on its own, not because of some push notification or email. Without one, daily becomes ad hoc, ad hoc becomes occasional, occasional becomes embarrassingly-bad Spanish. The user wasn't unmotivated. The action just never anchored to an emotional trigger.

How to fix it an action that doesn’t stick

Try these two levers, depending on whether the user never activated or never anchored:

First: get them to the core action faster. The longer someone waits after paying before they experience real value, the less likely they are to ever form a habit around the product.

Second, borrow an existing trigger rather than trying to build one from scratch. The “Try it right after your morning coffee" prompt, or the "Try it before you sleep" nudge: that anchor matters as much as the product itself. My sister's French habit holds because it's welded to her bedtime. Give users a way to weld by notifying them at the time they are most likely to take action.

The reward went flat

This is the one that most usage analyses miss, and the one I'd argue is entirely missing from most articles. Some users get all the way here. They built the routine, came back for a while, but then stop because the app ran out of reasons to pull them back.

Remember my Peloton example? I had the routine, and I'd felt the value, at first. But the workouts stopped surprising me: same format, same structure, nothing new to come back for. A reward that's identical every time stops being a reward; we need variation and excitement (especially this ADHDer).

This tends to be further down the user journey. Variability in rewards is key here; fresh content and visible progress are really powerful — these motivations are the app's responsibility, not the users’.

How to fix it

This is where variable rewards and investment earn their keep. The same reward every time gets boring. (Peloton again: same workouts, same format, no surprise, no fresh reason to come back.)

Vary your rewards, show progress, unlock rewards based on that progress; give people something new to come back for. Finch is a great example: offering a rotating daily shop, and seasonal rewards linked to repeated usage and habit-building.

Also focus on building investment early: the more someone puts into an app — preferences, history, a profile — the more they lose by leaving. It’s the same sunk-cost fallacy that keeps us in relationships longer.

AI tools like Granola or Wispr Flow are good examples. The more content I build up in them, the more useful they become, and the harder it would be to switch. Building that investment before the first renewal changes the value calculation.

The value never landed, or never fit

This one usually surfaces later. The user genuinely tried, but it just didn't feel like it was working. They used a language app for weeks and felt like the main word they learned was ‘apple’ (manzana, in my experience with Duolingo). Value can take longer than people expect, or the outcome the app delivers may be different from what they wanted.

The pattern looks like this: you journal for a month and feel no different, so you stop. You might not cancel immediately because part of you thinks, “maybe I’ll get back into it.” Then renewal comes around and suddenly the decision feels obvious: “I’m not using it enough. Might as well cancel.”

Technically, that’s true. But ‘not enough usage’ was the symptom. The root cause was a value gap.

There's a quieter, less obvious reason worth separating out, because the fix is completely different: the app works; it just doesn't fit their situation. A meal-planning app that assumes you cook most nights might be genuinely excellent. But for someone who eats out five times a week, it feels useless or unnecessary.

The value isn’t slow to arrive; rather, the product simply doesn’t match the reality of the person using it. When this happens, no reminder, notification, or re-engagement campaign can fix that (no matter how good they are). And sometimes that’s okay. Some churn isn’t a failure to prevent; it’s the right decision for the user.

How to fix it

Surface outcomes and progress, not just features. Most apps show what they do. Few show what the user has actually achieved. A monthly progress summary, a milestone email, a reminder of how far someone has come. Those moments are what shift someone from “I’m not sure this is working” to “actually, look at that.” Take Loom’s monthly recap emails — they literally show you the value in one image:

For users who've already dropped the app, your typical reactivation playbook applies, though reactivation rates are low by default, which is exactly why catching the value gap earlier matters so much. And if it's a life-fit problem rather than a delivery problem, be honest with yourself: no email can surface value that was never going to exist for that user. Qualifying the right people beats winning back the wrong ones.

Each break sits at a different point on the loop, and each needs a different fix. Not one of them responds to a discount. But before you reach for a fix, you need to know which break you're actually looking at and make sure you aren’t dealing with a price problem.

How to know which part of the habit loop is broken

You've established the churn is coming from usage, not price. Now you need to figure out which of the four breaks you’re dealing with. Luckily, each one leaves a different fingerprint on the usage curve.

Pull your churned cohorts and find the moment users actually went inactive (not when they canceled, but when they genuinely stopped coming back). Then look at the shape of the drop-off:

The usage curve will tell you where to look, but don’t stop there — to understand why the curve looks the way it does, you need to talk to churned users. The data can show you when the habit broke, but conversations tell you why.

Talk to churned users (and what to do if you can't)

The most direct way to find out why a habit broke is to talk to the people who left. It’s the equivalent of asking for directions when you’re lost.

Ask users two things:

1. What did they expect from the app?
2. What did they actually experience?

That gap is almost always where usage broke, and it usually tells you which break it was. Then ask what was going on in their life around the time they drifted, especially if you can see usage drop before they canceled.

I know churned users are harder to reach. I know they don't always reply. But trust me, it's worth it.

If you genuinely can't get to your churned users, shorten the feedback loop instead. Matthieu Rouif of PhotoRoom deliberately launched with a monthly-only plan so users would churn faster and become interviewable sooner. If you're early-stage and your usage understanding is low, that trade-off is worth considering.

Other proxies when you can't reach users directly:

• Support tickets
• App store reviews
• More in-depth post-cancellation surveys

They might not tell you the exact cause 100% of the time, but they can help you narrow down where to look.

Fix the right problem

‘Not enough usage’ can sound vague, but once you dig into the quantitative and qualitative data, it usually isn’t. At its core, it comes down to a habit loop that never fully formed, due to one of four breaks: the trigger, the action, the reward, or the value.

And none of those problems are solved by the classic winback discount. They require a better diagnosis and a better strategy.

Start by understanding what ‘enough usage’ actually looks like for your product, then run the quantitative checks I outlined. From there, work backward: where are users dropping off, and why?

Fixing this mega churn reason is a journey, but it’s worth taking the time to get it right. When an app delivers real value, users become far less sensitive to both price and usage. The value they get in the moment is enough to justify coming back, and enough to justify staying.

Usage churn is harder to fix than a pricing problem, but it’s also the lever almost nobody pulls. And that’s exactly why the opportunity is so wide open.

To help you out, I went through the categories again, and collected seven that you should consider targeting during the remaining two weeks. All of these reward work that would make your app stronger anyway: finding a route to market, testing growth, launching to a new market, or getting clearer about your audience.

Some can fit an app you already have in progress, and there’s still time to pivot or even build a new app.

Launch a web-to-app funnel for the Funnel Vision Award

If your app is nearly done, the next question is awkward but important: how will anyone find it?

The Funnel Vision Award gives you a reason to answer that now (that plus the $15,000). To enter, launch a live web-to-app funnel with RevenueCat Funnels and use Stripe for checkout. Best thing: you most likely don’t need to release a new version of your app at all.

Keep the first version laser-focused. Pick one audience, one promise, and one offer. Send people to the funnel from a post or small ad campaign, then watch where they continue, pay, or drop off. The judges will look at payment volume, funnel design, and conversion. So don’t build a generic landing page that could belong to any app, but instead make the journey feel like the first useful part of your product.

Personally, I’d spent the least amount of time on the visuals and more time making the all the steps serve a purpose. The app that understands why someone clicked has a much better shot at converting them. If web acquisition is new to you, the Web-to-App Funnels Handbook covers pretty much everything.

Take an idea all the way to income with Replit

The Idea to Income Award offers $15,000 for first place. And it’s exactly what the name suggests: start with an idea, use Replit to build it, publish it, and prove that somebody will pay for it. You’ll need to build the mobile app with Replit, integrate RevenueCat using Replit Agent, and share at least three public posts from different points in the build.

To make the best use of your time, build for iOS, with that you have the biggest chance to get your app approved in time. The scope can be small (and should be). A specialist calculator, a training companion for one sport, or a practical tool for one profession can become a real product faster than an app trying to serve everyone.

Give your Android app a Galaxy-specific advantage

Already building for Android? Publishing on the Galaxy Store opens another route into Shipaton — and another market for customers to find you. Galaxy store optimization accounts for 20% of the score, and the store listing itself needs to be polished. A thing you can work on without having to release a new version of your app.

Should you target Samsung products by focusing on their unique selling points, that is also possible. Look at the hardware your app will run on. For example a foldable can turn a recipe app into ingredients on one side and instructions on the other. A planning app can keep the calendar and task details visible together. Small updates you can make to your app to make it more suited for Samsung devices.

You don’t need to use every Samsung-specific feature. Pick the one that makes sense for your app and make it feel intentional.

The prize is three weeks of featured placement across the Galaxy Store’s Apps and Discover tabs. There’s no cash prize here, but for an app that’s ready to convert and retain users, the distribution could bring even more money.

Run one honest growth experiment with Layers

You don’t need a huge audience to enter the Growth Loop Award. You need a clear idea of who the app is for, a reason they might care, and an experiment you can learn from. That makes this a good category for a newly launched app, and the winner takes $15,000.

Install the Layers SDK, choose one growth loop , and write down what you expect to happen. Then run it long enough to see a signal. If this sounds foreign to you, Layers has good resources on how to do this, and while going through those you also learn how to market your app, something you should do even if you didn’t target this prize category.

The result you get doesn’t have to be a hockey stick. The judges want to see that you treated growth as a loop: form a hypothesis, run the test, and then decide what comes next.

Make today’s movement decision easier for Simone Sharice’s audience

The Simone Sharice Influencer Award (with $20,000 for first place) asks for a personalized wellness companion covering movement, Pilates, recovery, and other day-to-day wellness needs. This does not mean that you need to build an endless workout library and ask users to figure it out. Better to build something personalized; a plan they can actually start.

To give you an example, on a low-energy day, that may be 10 minutes of recovery work. On another, it may be a focused Pilates session. The value is in making the choice feel manageable. So personalization matters, but so does restraint. The brief specifically rewards apps that avoid overload and make the next action obvious.

A strong first version could do three things well: understand today’s context, recommend a suitable session, and learn enough from the result to improve tomorrow’s recommendation.There are multiple Shipaton submissions targeting health and fitness, if yours is one, check if you could submit it for this award.

Build a nutrition app that doesn’t turn lunch into homework

Most nutrition apps start with numbers. Abbey’s Kitchen brief starts somewhere more human: help people make meals more satisfying without calorie counting or macro tracking.

Your app could let someone photograph lunch and ask what would make it more filling or enjoyable. It could let customers turn leftovers into a workable meal, or suggest useful additions based on what’s already in the kitchen. Something that is missing completely from current calorie and meal tracking apps.

You can build the core around one simple question: “What can I add?” Answer it well, in the moment when someone is hungry and short on ideas, and you’ve built something that is perfect for Abbey’s Kitchen’s massive audience.

Let new managers rehearse the conversation they’re avoiding

New managers are expected to give feedback, hold boundaries, and say no. These are often things you don’t get to practise beforehand. That’s the opening behind the Leadership Heather Influencer Award, which also offers $20,000 for first place.

What you could build is for example a rehearsal room, giving the user a realistic situation, letting them respond by voice or text, and then offer feedback they can use on the next attempt.

Start with a handful of conversations people genuinely dread:

• Giving direct feedback to a strong performer whose behaviour is negatively affecting the team
• Saying no to an unrealistic request from a stakeholder
• Setting a boundary with a direct report

Build it so that users of the app can get personalized feedback. Did the manager state the issue clearly? Did they bury the message? Did they set a boundary? Did they leave room for the other person to respond? All of these are very easy to codify in such a way that LLM’s can answer and give personalized feedback.

A quick note on the Influencer Awards

These categories give you an audience and a problem to solve. They don’t give you permission to use someone else’s identity. Name the Influencer Award in your submission and explain how the app serves that audience. But don’t use the influencer’s name, image, likeness, voice, branding, or logos in the product or marketing without written consent.

You can enter each project in only one Influencer Award. The same project can also compete in other non-Influencer categories when it meets their requirements.

Make things easy for the judges

Each award has its own requirements: a live funnel URL, Stripe Project ID, Replit preview URL, public build posts, Galaxy Store listing, verified Layers installation, or an explanation of how you served the chosen audience. It’s crucial that you don’t make judges hunt for that information in your submission.

The rest of your submission matters too. You’ll need a live store listing, a demo video under two minutes, an app icon, the required screenshot, and a free trial or promo code that unlocks paid features for judging. Our Shipaton submission guide walks through each of these requirements so take a look at it before you submit.

Shipaton closes on September 30, 2026 at 11:45pm PDT. Store review can take days, so ship the smallest valuable version now and improve it while the review is ongoing. For guidance on submitting your app for review, see our Late submitter’s guide.

Read the full rules and enter Shipaton 2026.

In this article, you'll explore building a custom paywall against the Android Purchases SDK, every option on PurchaseParams.Builder, the five replacement modes that govern plan changes, purchase results in callback and coroutine form, and the customization surfaces on RevenueCat's own paywall UI: PaywallOptions, PaywallListener, PaywallActivityLauncher, and PaywallPurchaseLogic.

Two decisions, not one

Before any code, separate two things that get conflated. Who owns the UI and who completes the transaction are independent choices, and the SDK lets you mix them.

• Your own UI, RevenueCat completing the purchase: PurchaseParams and Purchases.purchase.
• RevenueCat's paywall UI, RevenueCat completing the purchase: PaywallOptions and PaywallListener.
• RevenueCat's paywall UI, your own code completing the purchase: PaywallOptions and PaywallPurchaseLogic.
• Your own UI, your own code completing the purchase: your own BillingClient calls, followed by syncPurchases.

Most people asking how to customize the purchase flow want one of the first two. They both let RevenueCat complete the transaction and differ only on who draws the screen. This article covers those, plus the third, where your own code completes the Google Play transaction. The fourth is a migration topic rather than a customization one and is out of scope here.

You choose who completes the transaction at configuration time:

val configuration = PurchasesConfiguration.Builder(context, apiKey)
    .purchasesAreCompletedBy(PurchasesAreCompletedBy.REVENUECAT)
    .build()

Purchases.configure(configuration)

PurchasesAreCompletedBy.REVENUECAT is the default and means the SDK acknowledges verified purchases for you. PurchasesAreCompletedBy.MY_APP means it does not, and that obligation has a deadline covered in the last section. The older observerMode(true) setter still exists but is deprecated in favor of this one.

Reading an offering into your own UI

A custom paywall starts by fetching offerings and rendering whatever the dashboard returned. The callback form takes a lambda pair:

Purchases.sharedInstance.getOfferingsWith(
    onError = { error -> _uiState.value = PaywallUiState.Error(error.message) },
    onSuccess = { offerings ->
        val current = offerings.current
        if (current == null) {
            _uiState.value = PaywallUiState.Error("No current offering")
        } else {
            _uiState.value = PaywallUiState.Success(current)
        }
    },
)

offerings.current is nullable, and an app that assumes otherwise crashes the first time someone forgets to mark an offering as current in the dashboard. From there, offering.availablePackages is the list you render. Each Package carries an identifier, a packageType, and the product itself.

There is one nullable accessor per standard package type, offering.monthly, offering.annual, offering.weekly, offering.lifetime, and so on for each PackageType. Lookup by identifier behaves differently and catches people out:

val monthly: Package? = offering.monthly
val custom: Package = offering.getPackage("my_custom_package")

getPackage returns a non-null Package and throws NoSuchElementException when the identifier is absent, as does the offering["my_custom_package"] operator form. Wrap it or use the nullable accessors.

For the price label, read through to the product:

val Package.buttonText: String
    get() = with(product) {
        if (type == ProductType.SUBS) {
            "${price.formatted} for ${period?.value} ${period?.unit?.name?.lowercase()}"
        } else {
            "${price.formatted} one time"
        }
    }

price.formatted is the localized string Google Play returned, already carrying the right currency symbol and grouping for the user's storefront. price.amountMicros and price.currencyCode are there when you need to compute something. period is returned only for Google subscriptions, so it is null for one time products and for Amazon.

Why there is no eligibility check on Android

On iOS there is an eligibility check you call before showing a trial badge. On Android there is not, and looking for one is a common dead end. getEligibleWinBackOffers and checkTrialOrIntroDiscountEligibility do not exist in the Android SDK. Google Play bakes eligibility into what it returns: an offer the user is not eligible for is not in subscriptionOptions at all.

So you read the offers you were given. Two container types are involved and the naming is close enough to confuse. SubscriptionOptions is the collection of offers on a product, and each SubscriptionOption is one offer made of pricing phases. Accessors on the collection pick an offer, accessors on an option pick a phase:

val options = packageToPurchase.product.subscriptionOptions
val trialOption = options?.freeTrial
val introOption = options?.introOffer
val defaultOption = packageToPurchase.product.defaultOption

SubscriptionOptions implements List<SubscriptionOption>, so you can iterate it directly. On an individual option, the phase accessors are freePhase, introPhase, and fullPricePhase. There is no freeTrialPeriod on a Google product. That property exists only on AmazonStoreProduct. A single option can carry both a free phase and an intro phase.

To show what a multi-phase offer costs over time, join the phases:

val pricingText = option.pricingPhases.joinToString(separator = " then ") { phase ->
    "${phase.price.formatted} for ${phase.billingPeriod.iso8601}"
}

You might reach for phase.offerPaymentMode to label each phase instead of formatting the price. It is worth knowing its shape before you do. The type is OfferPaymentMode?, one of FREE_TRIAL, SINGLE_PAYMENT, or DISCOUNTED_RECURRING_PAYMENT, and it is null for any phase that is not FINITE_RECURRING. That includes the full price phase of every recurring subscription and every phase of a prepaid plan. So branch on it with a when that treats null as the ongoing price rather than as an error.

Making the purchase with PurchaseParams.Builder

Every purchase goes through PurchaseParams. Its builder has exactly three public constructors, and which one you pick decides how much control you have over the offer:

1. PurchaseParams.Builder(activity, packageToPurchase) takes a Package.
2. PurchaseParams.Builder(activity, storeProduct) takes a StoreProduct.
3. PurchaseParams.Builder(activity, subscriptionOption) takes a specific SubscriptionOption.

The first two do not purchase the base plan. They purchase the product's defaultOption, and the builder KDoc spells out how that is chosen: offers tagged rc-ignore-offer or rc-customer-center are filtered out, then the option with the longest free trial or the cheapest first phase wins, then it falls back to the base plan. That is usually what you want, and it is why most apps never touch SubscriptionOption at all.

Pass a SubscriptionOption when you need to override that choice, for example when your paywall shows two offers side by side and the user picked the one that is not the default:

val params = PurchaseParams.Builder(activity, selectedOption).build()

The simplest possible purchase is the package form with nothing else set:

Purchases.sharedInstance.purchaseWith(
    PurchaseParams.Builder(activity, packageToPurchase).build(),
    onError = { error, userCancelled ->
        if (!userCancelled) showError(error)
    },
    onSuccess = { _, customerInfo ->
        unlockContent(customerInfo)
    },
)

Two things about that snippet need stating outright. First, the onSuccess transaction parameter is typed StoreTransaction?, nullable, unlike the non-null StoreTransaction you get from the PurchaseCallback interface. Writing onSuccess = { transaction, _ -> log(transaction.orderId) } does not compile. Discard it with _ or use transaction?.orderId.

Second, userCancelled is not extra information. It is derived, in PurchasesOrchestrator, from a single comparison:

onError(
    error,
    error.code == PurchasesErrorCode.PurchaseCancelledError,
)

So checking the boolean and checking the code are equivalent. Either way, a user tapping outside the Google Play sheet is not an error you should surface. Showing a toast that says "Purchase failed" because someone changed their mind is a common defect in hand rolled paywalls.

The callback interface

purchaseWith is a Kotlin extension. The interface form takes a PurchaseCallback, which declares onCompleted and inherits onError(error, userCancelled) from PurchaseErrorCallback, so you implement two methods:

Purchases.sharedInstance.purchase(
    purchaseParams = params,
    callback = object : PurchaseCallback {
        override fun onCompleted(storeTransaction: StoreTransaction, customerInfo: CustomerInfo) {
            unlockContent(customerInfo)
        }

        override fun onError(error: PurchasesError, userCancelled: Boolean) {
            if (!userCancelled) showError(error)
        }
    },
)

Here onCompleted hands you a non-null StoreTransaction, which is the reason to prefer this form when you need the purchase token. Note that purchaseToken is non-null but orderId is still String? even here, because it is absent for pending and test purchases.

Coroutines

The suspend variants come in two flavors per operation, one that throws and one that returns Result:

viewModelScope.launch {
    try {
        val result = Purchases.sharedInstance.awaitPurchase(params)
        unlockContent(result.customerInfo)
    } catch (e: PurchasesTransactionException) {
        if (!e.userCancelled) {
            showError(e.error)
        }
    }
}

awaitPurchase returns a PurchaseResult holding storeTransaction and customerInfo. That type gets its equals, hashCode, and toString from the Poko compiler plugin rather than from data class, which means there is no generated copy() and no destructuring. Read the two properties directly.

PurchasesTransactionException is where userCancelled lives on the coroutine path, and it exposes error, code, and underlyingErrorMessage. That last one matters for support, because PurchasesError.message is not a server message. It is a computed property returning code.description, the same canned English sentence for every occurrence of a given code. underlyingErrorMessage carries what actually went wrong, so log both.

Reading the result

Entitlements

The CustomerInfo handed to your success callback is already up to date, so gate on it directly rather than issuing another fetch. Watch which collection you read from. entitlements.all contains every entitlement the user has ever had, including expired ones, while entitlements.active contains only the live ones. Reading all and forgetting to check isActive grants access to a lapsed subscriber.

val isPro = customerInfo.entitlements["pro"]?.isActive == true
val hasAnything = customerInfo.entitlements.active.isNotEmpty()

The indexing operator reads through all, which is why the isActive check is not optional there. entitlements.active is a Map<String, EntitlementInfo>, not a list, so active.keys gives you the identifiers.

Individual EntitlementInfo properties worth surfacing in a settings screen:

• willRenew: false once the user has turned off auto renew. Always true for lifetime access.
• expirationDate: null for lifetime access. For a trial, this is the trial expiration.
• periodType: one of NORMAL, INTRO, TRIAL, PREPAID.
• unsubscribeDetectedAt: when the user cancelled, if they did.
• billingIssueDetectedAt: when a payment problem started, if there is one.

The KDoc on the last two carries the important part. An entitlement can still be active while both are set, so branch on isActive for access control and treat the dates as context for messaging.

To react to changes that happen outside your purchase call, set the listener once and clear it:

Purchases.sharedInstance.updatedCustomerInfoListener = UpdatedCustomerInfoListener { info ->
    _customerInfo.value = info
}

This fires when the SDK updates its cache after an app launch, a purchase, a restore, or a fetch. It is not a server push, so it is not a substitute for calling getCustomerInfo when your UI needs current state.

Restore

Restore is a single call with the same two shapes, and it is not optional. Both stores require a way for a user on a new device to recover access:

Purchases.sharedInstance.restorePurchasesWith(
    onError = { error -> showError(error) },
    onSuccess = { customerInfo -> refreshUi(customerInfo) },
)

One naming inconsistency to watch for when you implement the interfaces instead: ReceiveCustomerInfoCallback uses onReceived, while SyncPurchasesCallback uses onSuccess.

Switching plans: Product changes and replacement modes

Everything above buys a new subscription. Moving an existing subscriber from one plan to another is a different operation, and it needs two more builder calls:

val params = PurchaseParams.Builder(activity, annualPackage)
    .oldProductId(currentSubscriptionId)
    .replacementMode(StoreReplacementMode.CHARGE_PRORATED_PRICE)
    .build()

Product changes work in the Play Store and the Galaxy Store. The Amazon Appstore ignores them.

Getting oldProductId right

The value is the subscription id, not the id plus base plan. This trips people up because the place you naturally read it from returns the combined form:

val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()
val oldProductId = customerInfo.activeSubscriptions
    .map { it.split(":").first() }
    .firstOrNull()

activeSubscriptions returns subscriptionId:basePlanId for Google subscriptions. The builder is forgiving here, its KDoc says anything after a : is ignored, but splitting yourself makes the intent visible.

The five replacement modes

StoreReplacementMode replaced GoogleReplacementMode in SDK 10.3.0. The old enum and the old .googleReplacementMode() setter both still exist and are both deprecated, so new code should use StoreReplacementMode and .replacementMode().

• WITHOUT_PRORATION: takes effect immediately. The user pays nothing today, then the full new price on the old plan's expiration date.
• WITH_TIME_PRORATION: takes effect immediately. The user pays nothing today, and the time remaining on the old plan becomes free time on the new one.
• CHARGE_PRORATED_PRICE: takes effect immediately. The user pays the price difference today and the billing date does not move.
• CHARGE_FULL_PRICE: takes effect immediately. The user pays the full new price today and the remaining time from the old plan is credited forward.
• DEFERRED: takes effect when the old plan expires. The user pays nothing today, then the new price on the old expiration date.

One structural note if you plan to branch on the mode you were given. StoreReplacementMode is not an enum, it is a class exposing five constants, so a when over it will not compile as exhaustive. Include an else branch.

The default is WITHOUT_PRORATION. It is set in the builder's internal state, not left null, so a product change with no replacementMode call is a real decision that was made for you. For a paid upgrade that is rarely the one you want, because the user gets the better plan immediately and pays nothing until their old period ends.

If you want to have a better undertsanding on the proration mode, check out Understanding Google Play subscription proration: a developer’s guide.

Choosing a mode

• Upgrade, charge now: CHARGE_PRORATED_PRICE. The user pays the difference and the renewal date does not move. This mode is only valid when the new plan's price per time unit is higher than the old one's, which Google Play checks and rejects otherwise, so it is an upgrade only mode rather than a general purpose one.
• Upgrade, generous: WITH_TIME_PRORATION. The user pays nothing today and their unused time becomes free days on the higher tier.
• Downgrade: DEFERRED. The user keeps what they paid for until it runs out, then drops to the cheaper plan. Charging someone immediately to receive less is a support ticket.
• Crossgrade at the same price: WITH_TIME_PRORATION or DEFERRED, depending on whether the switch should be felt now.

Two constraints come straight from the KDoc and are worth encoding as guards. WITH_TIME_PRORATION fails on the Play Store when both options belong to one StoreProduct, so use a different mode for base plan changes within a single product. CHARGE_FULL_PRICE is not supported by the Galaxy Store, and passing it there surfaces a PurchasesErrorCode.UnsupportedError in your error callback rather than starting a purchase.

DEFERRED reports back differently

The deferred mode is the one that makes purchase handling code look broken. Nothing changes today, so the CustomerInfo your success callback receives still describes the old plan. Code that reads the new product id out of the callback and writes it somewhere will write the old one.

Under DEFERRED the product id is also what matches the purchase callback to the transaction Google Play returns, which is another reason to pass the plain subscription id. Treat a deferred change as scheduled rather than done, and let the entitlement's expirationDate and your webhook pipeline tell you when it happened.

Other PurchaseParams options

isPersonalizedPrice

val params = PurchaseParams.Builder(activity, packageToPurchase)
    .isPersonalizedPrice(true)
    .build()

This is a compliance flag, not a pricing feature. It tells Google Play to disclose in the purchase sheet that the price shown was personalized for this user, which EU consumer law requires when that is true. The default is false, and the Amazon Appstore ignores it. Set it only when you are actually personalizing the price.

Add-ons

For Play Store subscriptions with add-ons, the builder takes extra items:

@OptIn(ExperimentalPreviewRevenueCatPurchasesAPI::class)
val params = PurchaseParams.Builder(activity, basePackage)
    .addOnPackages(listOf(addOnPackage))
    .build()

There are matching addOnStoreProducts and addOnSubscriptionOptions overloads. All three sit behind @ExperimentalPreviewRevenueCatPurchasesAPI, and the restrictions from the KDoc are strict: Play Store subscriptions only, every add-on's renewal period must match the base product's period, and at most 49 add-ons per purchase.

Keeping RevenueCat's paywall UI

Now the case where RevenueCat draws the paywall. If the paywall you designed in the dashboard is what you want to render but you need your own code in the flow, you do not have to give up the UI.

The composable takes a single options object, and dismissRequest is a constructor parameter of the builder rather than a setter:

Paywall(
    PaywallOptions.Builder(dismissRequest = { navController.popBackStack() })
        .setOffering(offering)
        .setListener(paywallListener)
        .setShouldDisplayDismissButton(true)
        .build(),
)

setOffering(null) falls back to the current offering. setShouldDisplayDismissButton defaults to false here, while PaywallDialogOptions and the activity launch options default it to true, so an embedded paywall with no close button is the expected behavior rather than a bug.

PaywallListener: Observing the flow

PaywallListener is an interface where every method has a default implementation, so you override only what you need:

private val paywallListener = object : PaywallListener {
    override fun onPurchaseCompleted(customerInfo: CustomerInfo, storeTransaction: StoreTransaction) {
        analytics.track("purchase_completed", storeTransaction.productIds)
        unlockContent(customerInfo)
    }

    override fun onPurchaseError(error: PurchasesError) {
        analytics.track("purchase_error", error.code.name)
    }

    override fun onPurchaseCancelled() {
        analytics.track("purchase_cancelled")
    }

    override fun onRestoreCompleted(customerInfo: CustomerInfo) {
        refreshUi(customerInfo)
    }
}

The full set is onPurchaseStarted, onPurchaseCompleted, onPurchaseError, onPurchaseCancelled, onRestoreStarted, onRestoreCompleted, onRestoreError, plus onUrlOpened for links inside the paywall and onWebCheckoutOpened for the case where the user left to pay on the web. That last one is distinct from cancellation and needs handling separately, because the user has not given up, they have gone elsewhere to finish. If you also plan to supply purchase logic, read the last section first: four of these callbacks go quiet in that mode.

Gating the flow before it starts

The two hooks people want when they ask about customizing the purchase flow are not in the list above. They are the initiated callbacks, and they hold the flow open until you answer.

Each one receives a Resumable, a fun interface with resume(shouldResume: Boolean) and an invoke operator defaulting to true. So resume() proceeds and resume(false) aborts. If you never call it, the purchase never starts. Watch the import: the one PaywallListener wants is com.revenuecat.purchases.ui.revenuecatui.utils.Resumable. There is an identical com.revenuecat.purchases.customercenter.Resumable for Customer Center, and picking it gives you a confusing message about overriding nothing.

Both hooks are members of the same listener shown above:

override fun onPurchasePackageInitiated(rcPackage: Package, resume: Resumable) {
    if (userIsSignedIn()) {
        resume()
    } else {
        showSignInSheet(
            onSuccess = { resume() },
            onDismiss = { resume(false) },
        )
    }
}

onRestoreInitiated(resume) gives you the same gate for restore. This is the place to require sign in, ask for a confirmation, or check an age gate, because it runs before Google Play's sheet appears rather than after the user has paid.

Getting a result from a full screen paywall

For a paywall presented as its own activity, results come back through PaywallResultHandler. Construct the launcher in onCreate. There is no remember based helper:

class MainActivity : ComponentActivity(), PaywallResultHandler {

    private lateinit var launcher: PaywallActivityLauncher

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        launcher = PaywallActivityLauncher(this, this)
    }

    override fun onActivityResult(result: PaywallResult) {
        when (result) {
            is PaywallResult.Purchased -> unlockContent(result.customerInfo)
            is PaywallResult.Restored -> refreshUi(result.customerInfo)
            is PaywallResult.Error -> showError(result.error)
            PaywallResult.Cancelled -> Unit
        }
    }
}

PaywallResult is a sealed class, so that when is exhaustive and a new case would break the build rather than fall through silently. A user cancellation arrives as Cancelled rather than as an Error carrying PurchaseCancelledError, because the activity maps that code before returning.

To launch it with a listener or custom purchase logic attached, use the options form:

@OptIn(ExperimentalPreviewRevenueCatUIPurchasesAPI::class)
fun showPaywall(offering: Offering?) {
    launcher.launchWithOptions(
        PaywallActivityLaunchOptions.Builder()
            .setOffering(offering)
            .setListener(paywallListener)
            .build(),
    )
}

The opt in is required only because of setListener and setPurchaseLogic on this particular builder. Paywall(), PaywallOptions, PaywallListener, and PaywallPurchaseLogic themselves need none. There is also launchIfNeededWithOptions, which takes a required entitlement identifier or a shouldDisplayBlock and skips presentation when the user already has access.

One caveat shows up only in the field. The SDK passes the listener and purchase logic to the activity through an in memory store rather than through the intent, because neither is serializable. If the process dies while the paywall is open, the SDK logs that they were lost, finishes the activity, and returns PaywallResult.Cancelled. Do not treat that result as a signal that the user declined. This applies only when you attached one of them. A paywall launched without either carries no in memory key and recreates normally.

Custom variables

A dashboard paywall can contain {{ custom.player_name }} placeholders, and you supply the values:

PaywallOptions.Builder(dismissRequest = { dismiss() })
    .setCustomVariables(
        mapOf(
            "player_name" to CustomVariableValue.String("John"),
            "level" to CustomVariableValue.Number(42),
            "is_premium" to CustomVariableValue.Boolean(true),
        ),
    )
    .build()

Both {{ custom.key }} and {{ $custom.key }} resolve. Resolution order is the value you passed, then the dashboard default, then an empty string with a warning logged. Keys must start with a letter and contain only letters, digits, and underscores, and the SDK drops invalid keys with a warning rather than surfacing an error, so check logcat if a placeholder renders empty. One exception: PaywallDialogOptions.Builder.setCustomVariables skips the validator, so a bad key there is never logged and simply resolves to empty.

Owning the transaction with PaywallPurchaseLogic

This is the case where your own code completes the Google Play transaction and RevenueCat supplies only the paywall and the backend. You configure PurchasesAreCompletedBy.MY_APP and hand the paywall your purchase code.

The interface has two suspend methods. The purchase side receives the activity and a params object:

class MyPurchaseLogic(
    private val billing: MyBillingClient,
) : PaywallPurchaseLogic {

    override suspend fun performPurchase(
        activity: Activity,
        params: PaywallPurchaseLogicParams,
    ): PurchaseLogicResult {
        return when (val outcome = billing.purchase(activity, params.rcPackage)) {
            is Outcome.Success -> PurchaseLogicResult.Success
            is Outcome.Cancelled -> PurchaseLogicResult.Cancellation
            is Outcome.Failed -> PurchaseLogicResult.Error(outcome.error)
        }
    }

Restore in this mode means telling RevenueCat what Google Play already knows, which syncPurchases does, so the implementation is usually thin:

    override suspend fun performRestore(customerInfo: CustomerInfo): PurchaseLogicResult {
        return try {
            Purchases.sharedInstance.awaitSyncPurchases()
            PurchaseLogicResult.Success
        } catch (e: PurchasesException) {
            PurchaseLogicResult.Error(e.error)
        }
    }
}

If your billing code is callback based, extend PaywallPurchaseLogicWithCallback and implement performPurchaseWithCompletion and performRestoreWithCompletion instead. The base class bridges them for you.

The result type has three cases and the exact names are easy to miss. It is PurchaseLogicResult.Cancellation, not Cancelled, and the error case carries a nullable errorDetails:

• Success triggers syncPurchases. From performPurchase it also dismisses the paywall. From performRestore it dismisses only if a shouldDisplayBlock was set and no longer matches.
• Cancellation tracks a cancel event and leaves the paywall open on the purchase path. On the restore path it is silently ignored.
• Error(errorDetails) shows an error dialog only if you provide the error. PurchaseLogicResult.Error() with no argument does nothing at all: no dialog, no tracking. Always pass the error.

params is a PaywallPurchaseLogicParams, which is what makes this interface usable for plan changes. It carries rcPackage, subscriptionOption, oldProductId, and replacementMode, so a product change configured on the dashboard paywall reaches your code with enough information to reproduce it. One type detail will bite you on the next line: replacementMode is typed ReplacementMode?, the interface that both StoreReplacementMode and the deprecated GoogleReplacementMode implement. There is no public converter, so narrow it yourself with params.replacementMode as? StoreReplacementMode before passing it to a PurchaseParams.Builder.

The older PurchaseLogic and PurchaseLogicWithCallback types are deprecated in favor of these, because their performPurchase took only a Package and had nowhere to put the product change details.

Three behaviors of this mode need internalizing before you ship it:

1. The SDK no longer acknowledges purchases, so your code must. The KDoc on PurchasesAreCompletedBy.MY_APP states the consequence: failing to acknowledge within 3 days leads Google Play to automatically refund the user.
2. MY_APP with a null purchase logic does not fall back to normal behavior. validateState puts the paywall into an error state that renders instead of your paywall.
3. Four listener callbacks stop firing. onPurchaseStarted, onPurchaseCompleted, onRestoreStarted, and onRestoreCompleted live only on the REVENUECAT branch. The initiated hooks still run because they execute before the branch, and onPurchaseError, onPurchaseCancelled, and onRestoreError can still fire because they come from a catch that wraps both branches. Anything you were doing in onPurchaseCompleted has to move into your performPurchase success path.

Choosing an approach

• Full design control, standard purchase handling: PurchaseParams with purchaseWith or awaitPurchase.
• Dashboard paywall embedded in your layout: Paywall with PaywallListener.
• Dashboard paywall as its own screen, returning a result: PaywallActivityLauncher with PaywallResult.
• Dashboard paywall, your own billing code: PurchasesAreCompletedBy.MY_APP with PaywallPurchaseLogic.

The naming differences between these surfaces are not consistent, and the compiler will not always help. PaywallOptions.Builder has setPurchaseLogic, while PaywallDialogOptions.Builder calls the same thing setCustomPurchaseLogic. PaywallResult uses Cancelled while PurchaseLogicResult uses Cancellation. When something does not resolve, check which options class you are holding.

Conclusion

The habit worth taking from all of this is to treat the silent defaults as decisions you are making. WITHOUT_PRORATION is what a product change does when you say nothing about proration, and it is the mode that charges an upgrading user nothing today. defaultOption is what gets purchased when you pass a Package, chosen by a documented rule you can predict. Both are reasonable, and both are wrong for some paywalls, so pick them on purpose and write the reason next to the builder call.

The other shift is to stop reading a declined purchase as a failed one. The SDK separates a failure from a decision at every layer, from the boolean on the error callback to the result types the paywall returns to the hooks that let you abort before Google Play ever appears. Your error handling should draw the same line, because the user who backed out of the sheet is still a prospect and does not need to be told that something went wrong.

Watch on YouTube

Both looked like wins. "Both of those look so promising on the trial numbers," says Anada Lakra, BoldVoice's co-founder and CEO. "And it makes sense, right? People have already put in all the time in the onboarding flow. They actually want to see what this app is all about." The team's instinct was to ship both to everyone.

Then the refunds arrived. "The refund spiked by way more than the gain in start trials," Anada says. People who feel forced into a trial ask for their money back the moment the charge hits their bank account — and they leave with a grudge. "Anything that kind of forces or tricks people into starting a trial, you'll pay it when it comes to refunds."

The fix was a different scoreboard. BoldVoice now judges paywall tests on net revenue after refunds, per exposed user, on a matured cohort — which means waiting at least an extra week for trials to convert and two more for refunds to settle before declaring anything. It's slower, and Anada admits the hardest part isn't discipline but patience: sitting on exciting data for a month or more. Asked at the end of the episode for her worst change of the past year, she doesn't hesitate: "The paywall stuff. Just stop over-optimizing every single word and every button and everything. Optimize them for a little bit and then move on to the actual product."

Every employee does two user interviews a week — including the engineers

BoldVoice's user research isn't a function. It's a calendar rule.

Automated invites go out to a deliberate mix of users — subscribers of two or three years, people who started a trial last week and converted, people who didn't — asking for a 15-minute call. The invite automatically books whichever team members have space in their calendars. "Every single person on the team — myself, my co-founder, our engineers, our growth people — everyone is in at least two user interviews a week," Anada says.

Two more layers sit on top. A super-user group meets roughly weekly, and engineers demo unshipped features to them, so heavy users shape the product before release. Users also come into the office so the team can watch what they tap and where they linger. "Being able to actually verbally talk to users and actually see them interact with the product, I think is an underrated skill."

Anada is candid about the bias in this setup. Happy users book the calls. "People who did not have a good experience are going to be less likely to jump on those calls." For them, BoldVoice uses a three-question survey answerable by replying to an email, and a short flow at cancellation asking what went wrong. Without that correction, she says, you end up making happy people happier and building a product that gets narrower and more technical instead of wider.

Why BoldVoice charged from day one — and won't copy Duolingo

BoldVoice launched in the first weeks of Y Combinator's summer 2021 batch and charged from the start: $10 a month, one-week free trial, no experimentation. That was the point. "Charging for the product is a way to already figure out who that ICP is," Anada says. Willingness to pay correlates with the problem resonating, and it kept the team from chasing feedback from people who would never be customers. The energy went into onboarding and the core product instead of the paywall.

Pricing has since matured — BoldVoice leads with an annual plan at around $150 a year, offers monthly as a fallback, and has a $200-a-year tier with extra features like chat — but the philosophy hasn't moved toward freemium, and Anada is precise about why. "The worst thing that someone can do is take some playbooks and some elements of a playbook from one app, combine it with a playbook of a different app, and create this mishmash strategy."

Duolingo's freemium base works because it teaches the basics of every language to a huge audience of hobby learners, and monetizing a fraction is enough. BoldVoice intentionally ignores that audience. Its users are intermediate-to-advanced professionals for whom the alternative is expensive one-on-one coaching with an accent coach: "totally different ICP, different value proposition, different willingness to pay." The same logic ruled out the cliché college-campus launch, which BoldVoice tried. Students had less money, less urgency, and hadn't yet sat in the meeting where a colleague got listened to instead of them.

What BoldVoice has instead is a narrow free taste: dismiss the paywall and you get the speech assessment, the first daily plan, and a coach video, then a seven-day trial to continue on day two. David Barnard calls it a reverse trial. Anada calls it a middle ground that doesn't cost you the onboarding paywall for the people who are already ready to pay.

One Threads post, 100,000 people in Korea

BoldVoice's in-house ML team, working with the Hollywood accent coaches who help label its training data, built a tool that guesses where you're from after about ten seconds of speech. They shipped it as an ungated web app — no download, no trial — called the Accent Oracle, and Anada mentioned it in her monthly investor update.

"One of them was an angel investor. It was Korean, and he was like, 'Oh, this is cool. I'll put it on Threads,'" she says. "And then I believe the next day we had 100,000 people in Korea try this thing."

The lesson she draws isn't "build a viral tool." It's that you can't engineer virality, but you can add levers to something that already has it: a city-level guess re-spiked the Oracle, and showing users a preview of the fuller results waiting in the app lifted the number who made the jump. A TikTok trend of users crying at low scores gave the brand another unpaid spike — hundreds of millions of views for one creator, by her estimate — with the caveat that humor brings reach, not intent.

$10M ARR, 10 people, one meeting a week

Anada’s explanation for roughly $1M of ARR per employee is unglamorous. Hire founder-type doers who don't need direction. Hold one company-wide meeting, on Mondays, and leave the rest of the week for building and talking to users. Default users to the annual plan so paid acquisition pays back within the trial window and every channel's return is legible the same week.

And let everyone ship. "Everyone in the company is using Claude. For the first time in my life, I'm actually shipping PRs myself, which is crazy. I'm not a technical person." The designer takes Figma work through to prototypes that are about 80% of the way to production before engineers touch them.

The part that keeps the small team defensible is the part that took longest to build. "Still to this day, you cannot talk to ChatGPT or Claude or whatever have you and get this kind of feedback that BoldVoice gives you," Anada says — a deliberate bet that non-native English pronunciation is too narrow a niche for general models to chase and far too large a market to ignore.

In the full episode, Anada also explains why BoldVoice is expanding from accent into the "penultimate mile" of spoken fluency, why she considers "accent" an almost anti-viral word, and what a self-imposed six-month term-sheet deadline did for her focus.

Guest links

• Anada Lakra on LinkedIn
• BoldVoice on LinkedIn
• BoldVoice

But I also don’t believe apps will disappear altogether. Ethan Garr, a growth advisor, shared on a Sub Club Live about building with AI that a friend had said apps would be gone within six months. Not what you want to hear when you work in the app space. Yet here we are more than six months later: apps are still around, and more are being launched than ever before (7x more since 2022, to be specific). So I don’t believe they’ll disappear. Yes, LLM chats are replacing certain apps. Yes, the space is changing faster than ever. But the data suggests there is still hope, and I’m willing to cling to that data.

Especially as I’ve found you can win the game if you focus on the areas where an LLM chat cannot beat your app.

"...since March we’ve seen a significant spike in student interest in ChatGPT. We now believe it’s having an impact on our new customer growth rate."

When CEO Dan Rosensweig of Chegg, a homework-help subscription service, said this during an earnings call in 2023, the impact hit hard:

• The company’s stock fell 50%
• By 2025, 45% of their workforce were made redundant
• By Q2 2026, the freefall continued and they attempted to pivot away from homework toward an employability platform

Every step of the way, the blame was the same: AI.

Now take Duolingo: ChatGPT, and most LLMs for that matter, can also tutor you, for free. Google has layered live translation into its products — only a few months ago, I did a full strategy session with a subscription app startup in Portuguese (even though I don’t speak a word of Portuguese). The experience was honestly mind-blowing. I’m curious what I’m like in Portuguese.

Yet Duolingo isn’t floundering:

• Q2 2026 revenue was up 18%
• DAU rose 23% to 58.7 million
• Paid subscribers increased 17% to 12.7 million

By contrast, Duolingo’s CEO Luis von Ahn seems largely unimpressed by AI competitors:

“Just having conversations in French on something like ChatGPT gets pretty boring after a while. It doesn’t keep you there. We keep you on task with all the gamification.”

So what explains the difference between the two? Why is one being, frankly, obliterated by AI, while the other’s owl is gleefully celebrating its success?

It’s about the app itself: while both companies create educational content, Chegg’s product is essentially a one-shot answer: a lookup experience without enough built around it in terms of data, habit, and workflow. Duolingo, meanwhile, has spent 14 years building gamification systems and habit-forming product design that are much harder to replicate.

People will pay for AI apps, they just won’t stay

One thing worth separating before we dive into the numbers is what we mean by an ‘AI app’, because we often talk about these all under AI:

• An LLM chat is ChatGPT, Claude, Gemini
• An AI app is a subscription app with AI as a central feature inside it, like Cal AI or Rosebud (and quite possibly yours)

The first is the free competitor keeping you up at night. The second might be your own app. The data below is about the second.

AI-powered apps are casually out-monetizing and outperforming non-AI apps, according to RevenueCat’s State of Subscription Apps 2026:

• 41% more revenue per payer
• 52% better trial conversion

But there is a flip side to this:

• 12 month retention of 21.1% vs. 30.7%
• Refunds are about 20% higher

So consumers are willing to pay for AI apps, but the harder challenge is getting them to keep paying.

FaceApp used AI to apply an age filter, allowing you to see an aged version of yourself (why anyone would want that is beyond me). It peaked with downloads growing by 2000%, only to see a 75% drop the next month because of privacy concerns and the novelty wearing off. From 2019 to 2020, growth stagnated, with ARR remaining around $25 million (not a bad number to be stuck at, but a change in growth pace for sure). FaceApp survived the challenges, but had to optimize the app to focus on a broader use case, from photorealistic beauty (e.g. applying makeup) to selfie retouching. Broadening their use case helped them better retain users — and in 2025 they hit $150 ARR.

So the question in this article’s title is secretly the wrong one: people will pay. They’re already paying more — and faster — for AI-powered apps than for almost anything else right now.

The real question is why will they still be paying in month six? That’s a product question, not a marketing one, and it’s the question the rest of this article sets out to answer. (It’s also a much nicer question to wake up to at 2 am.)

AI alone isn't enough to win customers permanently, and Sora proves it: when the company that builds the model can't keep people, the model was never what kept them. Which is also why I don't think the other AI apps or copycat AI apps in your category are your biggest competitors.

ChatGPT is the biggest ‘window’ ever built

A while ago, I was standing in the kitchen, checking several weather apps on my phone, trying to decide whether to walk the dog now. I turned around to find my father-in-law looking at me like I’d lost it: "Why are you doing that? Just look out the window."

Weather apps’ competitors aren’t other apps; they are looking out the window, asking around, or even just going to stand outside.

In the world of apps, your window is ChatGPT, Claude, or whatever other LLM chat of your choice. The free models, for now, can do a lot, and we see growing usage in categories of apps that support them, e.g, one in five US chatbot users ask for medical advice, and as many again about diet and fitness.

The second, more meta way it is your window competitor is the ability to help you and others build faster. App launches went from about 2,000 to 14,700+ per month in four years; the volume is huge.

But in that, we still see 69% of subscription revenue going to pre-2020 apps, versus just 3% to apps launched in 2025 and 2026. Eric Seufert argues that while the cost of building is lower, the cost of distribution has increased because apps are all chasing the same attention. Rik Haandrikman echoes this: distribution is a moat.

Those who are holding on to that 69% know what a weather app can do that a window can’t, what their app can do that an LLM can’t. Those who can’t explain the differentiator of their app are the ones slowly dying under the weight of AI's growth.

Anatomy of the apps AI has actually killed

This is not a random murder spree; AI’s victims share something in common (I clearly need to stop reading Swedish noir novels). The apps replaced by LLM chats have one or more of these four things in common:

1. No structure
2. No memory
3. No habit
4. No precision advantage

Most apps being replaced are a single question or task and an answer. That was Chegg’s real problem: strip away the branding, and the product was a prompt with a subscription attached. Stack Overflow, a question-and-answer platform for developers, is on the same path, with traffic falling around 6% every month since early 2022. Why? An LLM gives you the same answer instantly, in a conversation, without posting a question and hoping a stranger replies.

Dan Layfield, Founder of Subscription Index, made a point on Sub Club that explains the pattern: your retention is dictated by how long the user has the problem you solve. Phone plans are retained for decades because the problem never goes away. An answer-lookup problem dies the second the answer arrives — and now the answer arrives in three seconds, for free. Chegg's real problem was never ChatGPT; it was that the problem they solved only lasted one homework question at a time.

The uncomfortable truth: if your app’s value fits in one prompt and one reply, you are in the blast radius.

The Blank Box Test (and six things a blank box cannot do)

I have a challenge for you called the Blank Box Test. It’ll only take two minutes:

1. Open your LLM chat of choice
2. Write out your user’s problem in their words
3. Analyze the results vs. what your app offers

Hopefully, you’ll see one of six advantages appear that you can lean into further. If not, your app is replaceable. So consider each of these six areas and see which could help you effectively beat an LLM. With all of these, yes, there are ways an LLM could do these things, but a general chat doing all six — or even one of them — to a very high level for everyone’s daily needs? Unlikely.

And to be clear, this isn't AI apps vs. non-AI apps. Cal AI, Rosebud, and Tolan are all examples that lean heavily on AI. The difference is that AI isn't what they're selling you — rather, it’s part of their infrastructure that helps them lean into one of the six differentiators against LLMs. That’s why I’ve also intentionally shared several non-AI examples.

1. Structure

I use Deliciously Ella and Mob Kitchen for recipe inspiration. Until I had what I thought was a genius idea: why not use Claude to build a weekly meal plan based on what I already have in the fridge, my dietary requirements, the foods I love, and the kinds of food that work well for me as someone with ADHD and an intense sweet tooth? A perfect, personalized plan.

So I did exactly that. I used it for a few weeks, but eventually went back to my usual apps because I missed the beautiful visuals of seeing what I was going to cook. I missed feeling inspired and getting excited about new recipes. The checklists and text in Claude just weren’t doing that.

While I probably could have forced Claude to create images and build everything into a visual weekly dashboard, the structure of the apps is what gives them their value. I can browse them on the go, discover recipes as they catch my eye, and build my shopping list along the way. It’s not worth it to me to rebuild that, and I’d argue that for most average consumers it wouldn’t be.

I also think that’s why apps like Runna are still winning against LLMs. For some people, a quick plan generated by an LLM will be enough for their daily run. But Runna gives you the full calendar, guidance during your run, and the exact structure of every workout you can follow live. It turns a plan into an experience, and that’s where the added value lies.

2. Memory

Luckily, the days when our LLM chats acted like Dory from Finding Nemo are gone. Building structures like second brains (a persistent, semantically searchable digital knowledge with AI) can allow your LLM to have so much more memory than ever before. But you still have to get it to use that data in some cases to make your experience better, and not all data sources are easy for the average AI user to connect to an LLM.

Meanwhile, your app can use the accumulation of user data so that by month six it is so much better than it was in month one, in ways you may not have even thought of. Memory + judgment of the right prompts are powerful.

This is the investment part of the Nir Eyal Habit Loop: getting users to invest in your app. If you do so, ensure that the investment pays back, and you’ll be able to add value to their experience, like Rosebud, an AI journaling app that collects your data over time and uses it to better reflect and learn with you.

3. Habit

Habit comes down to accountability: being able to push someone to take action, whether that’s through streaks, reminders, or other forms of gamification.

Duolingo is a perfect example. You can ask an LLM to help you build a habit out of something, and it can tell you the theory behind habituation. Having it embedded in your app in a beautiful, intuitive way, with all those reminders and nudges already built out — it’s technically possible with AI, but not something the average user is willing to do themselves.

The numbers behind those nudges are not small either. When Duolingo introduced leaderboards, Jorge Mazal, their former CPO, shared that overall learning time went up 17% and the number of highly engaged learners tripled.

Once a streak passes 10 days, the odds of someone quitting drop sharply. An LLM can explain habit theory to you beautifully — but it won’t cause a terrifying owl to chase you at 9pm because your streak is about to die.

4. Precision

Cal AI launched in the middle of the rise of LLM chats in May 2024. Within a year, its teenage founders were claiming around $2 million in monthly revenue, and by the time MyFitnessPal acquired it, it had passed 15 million downloads. The acquisition also gave them MyFitnessPal's food database of 20 million foods and 68,500 brands, allowing them to redesign and improve the product.

You could argue that their product is just a simple question-and-answer tool, but the precision with which they can tell you what is in your food, thanks to all that data and insight, is much better than asking ChatGPT. Especially if you combine it with their structure for organizing and tracking your calories and intake. Gives us hope, right? If two teenagers can beat LLM chatbots, so can we.

Merlin, a bird-sound app, is another great example of this. They have a curated acoustic library built from decades of eBird and Macaulay Library data and have 10 million active users. That dataset and the precision to recognize bird sounds effectively are their strengths.

5. Connection

Trust, tone, and brand feel go a long way in building a connection. Look at Tolan, the AI companion. It builds a personality that stands out and gives a feeling of connection. Its founder argues that doing this well, with voice, memory, and character, is exactly what LLM Chats are not set up to focus on.

But connection goes further than an app that knows you. It’s about belonging: Duolingo’s leagues, Strava’s clubs, the run crew that only exists because the app brought them together. People don’t cancel things that feel like a part of them. Emotional connection is a strong driver of retention. I also find it telling that AI companion apps are on track to pull in $120 million even though chatting with an AI is free: people pay for a relationship, not a reply.

In a world flooded with vibe-coded apps, those that take the time to build connection and an experience stand out.

6. Digital and physical

I also believe there’s room for another advantage in subscription apps that combine physical and digital to deliver value. I use a subscription app called Willow to better understand what my plants need and know when to water them, when to move them to a sunnier or less sunny spot, and more.

They can do this better than an LLM chat by itself because they have sensors to feel and gather this data. While we can connect LLMs to other data sources, I believe there’s room for the physical advantage of naturally creating combined experiences with reality to add extra value.

The power of multiple moats

The combination of a few of these has allowed even ‘wrapper’ apps to survive and thrive. Take Co-Star, an astrology app: readings are written by a mix of AI and human writers, and Midjourney thought its packaging and ritual were worth acquiring in 2026. Yet users pay anyway: for the packaging, the birth-chart personalization, and the daily push ritual. That is a combination of structure and habit helping them win.

What this means for what you build, say, and charge

Firstly, you need to understand which of these six differentiators are available to your category and deliberately invest in them, figuring out what can truly make you different from an LLM chat or a quickly-created AI competitor. It will help you speak to your most loyal users and understand: if they are using LLMs, why are they still choosing you? If 95% of your audience still sees that value and understands it, and it’s not just down to brand loyalty, that helps you work out which of these matters most.

With distribution being the challenge now, your existing audience is a moat in itself. Investing in retaining users through the initial experience and onboarding, by building in guidance and value, is going to help you win.

From there, communication comes down to marketing and sharing outcomes that a blank box can’t promise. You want to sell the job you helped them achieve, not the engine. I’m not the only one who cringes at the label ‘AI-powered’ — Irrational Labs conducted a study of 767 software users in which AI-powered features actually lowered the perceived value and did nothing to justify the higher price. AI is a tool, not an outcome.

Finally, don’t risk getting into a race to the bottom. Yes, competition is fierce, but competing against the $0 competitor won’t help you win. Price isn't a long-term differentiator, and we see that in the State of Subscription Apps report too: high-priced cohorts hold at 6x the LTV of lower-priced cohorts, and premium positioning signals the differential you’ve built. You just need to make sure you deliver that value for that price. Your free tier is competing with that blank box too, since it is the more limited experience, so make sure your free experience shows off the same advantages.

The irony of it all

We’ve talked about LLMs like ChatGPT as competitors. We talked about them helping your competitors build, but there’s an additional challenge; they are also your distribution channel. You can’t completely ignore them or move away from them. They need to know your app in order to suggest it to users. And they are undeniably useful — Brian Balfour recommends integrating them early in your app and if you can, letting their ecosystem help you win while you strategically differentiate.

Your users will continue to pay for you if your app knows them (memory), structures them (opinionated workflow), holds them to it (habit), gets the details right (precision), feels like somewhere they belong (connection), and helps them get more value out of the world around them (physical and digital). Run the two-minute Blank Box Test this week if you haven’t, and start building the things a blank box cannot do.

That's it. That’s the update. Rico used to answer questions about your app business and suggest what to do next. Now, it can just go get the work done.

Watch on YouTube

Rico can change your setup for you

With your approval, Rico can create and manage products, Offerings, Packages, and Entitlements, and build or edit paywalls directly in RevenueCat.

That includes real store products, not just RevenueCat-side config. Rico can create and update the subscriptions that live in App Store Connect and Google Play. These features rolled out to everyone last week, so go check out your account right now.

Experiments are the part I'd try first

Every dev I talk to says the same thing about experiments: they’re easy to come up with, but a pain to set up. You have to duplicate the paywall, name everything, wire up new Offerings and Packages, keep track of which variant is which, and only then can you finally hit start.

Rico can do that whole chain now. Ask it to test a new price or a new paywall against your current one and it builds out everything the test needs. Rico can create, update, start, stop, pause, and resume experiments, so the follow-up work is also just asking.

You still approve everything

Every proposed change requires your approval before anything happens. Rico is limited by the access level of the collaborator using it, so it can't do anything you couldn't do yourself in the dashboard. Project admins can go further and limit what Rico is allowed to do across all collaborators from project settings.

You can limit Rico to three levels of access: Read & write with permission (to enable everything we’ve talked about here), Read only (to use Rico only for gaining insights to your data, but not for changing anything), and Disabled (will completely turn off all Rico integrations for this project).

It's on your phone

RevenueCat Mobile 2.0 brought Rico to iOS alongside the Paywalls AI Editor. Ask questions about your app business, attach a screenshot, approve Rico's actions, or generate a new paywall, all from your phone.

What’s more, Siri and App Shortcuts can now pull up MRR, revenue, active subscriptions, and trials without opening the app at all.

The Android release with Rico is in testing now.

Go ask Rico

The Rico docs have the full list of what Rico can and can't touch — or of course, you can just ask Rico. Have fun with it! Use Rico to learn more about what’s working or not in your app monetization scheme, then ask it to fix it. I’m looking forward to hearing about what you do with Rico.

According to the State of Subscription Apps 2026, 84% of 3-day trial cancellations and 64% of 7-day trial cancellations occur between Day 0 and Day 1. What’s more, nearly half of monthly subscribers, and the majority of yearly subscribers, do not renew even once.

By the end of this article, you'll have a clear picture of why that early churn happens — and a practical framework for preventing it. We'll cover the onboarding gap that quietly costs apps revenue every month, why new subscribers need to be treated like new users, and how to design a simple lifecycle journey that gets paying customers to their first 'premium win' — before buyer's remorse has a chance to set in.

Stop treating conversion as the finish line

Most subscription apps treat conversion as the finish line. But really it's the start of the retention journey. For many new subscribers, it's also where things start to go wrong.

Think about how much effort goes into getting a user to subscribe. Teams spend weeks, sometimes months, designing onboarding flows, refining paywall timing, testing trial journeys, tweaking upgrade messaging. Then the user finally converts… and the silence is deafening.

For new users, the app suddenly going quiet is a drastic 180. They were being nurtured towards the subscription they just paid for — and suddenly nothing. For app teams, that silence feels logical: the user paid, they're clearly engaged. Why interrupt them?

But subscribing doesn't mean the user actually understands what they've just unlocked. They might have converted based on a single feature they glimpsed during a trial, a discount that felt too good to pass up, or just a vague sense that this app might be useful. What they haven't done (yet) is experience the product as a paying customer. And without a little guidance, many of them will cancel before they ever do.

Why do users cancel early?

Early cancellations are rarely about product quality. They're almost always about the gap between what a user expected when they signed up, and what they actually experienced in those first few days. That gap is where buyer's remorse lives. And silence from the product team is what lets it take root.

There's another force making this worse: subscription fatigue. People are drowning in recurring charges — music, fitness, productivity, entertainment — and many have started turning off auto-renew the moment they subscribe to something new, just to feel in control.

It's a defensive habit born from too many forgotten subscriptions quietly draining bank accounts. Which means your new subscriber may have already mentally scheduled their exit before they've even opened the app a second time. The window to prove your product is worth keeping isn't weeks — it's days.

Re-onboard existing subscribers like they're new users

This is what's sometimes called the post-subscription gap: the window between a user converting and a user genuinely getting value from what they paid for.

It tends to show up in three connected ways:

1. Upgraders don’t find the premium features

This sounds almost too simple to be a real problem, but it is. And if you’re working with a freemium model, it’s quite possible the silence after conversion is what’s quietly pushing subscribers away.

Users who have already gone through free onboarding learn how to use the free version of your app. When they upgrade, nobody shows them what's changed. So they keep using the product the same way they always did — as if they're still on the free tier. The premium features exist, but the subscriber never finds them, and eventually cancels feeling like they never got much value when they started paying.

2. Most apps stop communicating once a user converts

After all that effort to nurture a potential subscriber, silence isn't a neutral choice — it's a missed opportunity. When lifecycle messaging disappears, users lack the product enablement to benefit from their upgrade, and often forget they even subscribed. They may question whether it was worth it, and cancel when renewal rolls around because they can't quite remember why they signed up.

3. “They’ve already been onboarded” is the wrong mental model

The mental model many teams use ("they've already been through onboarding, they don't need more") is a big mistake. It also misses the nuance between different types of subscriber: an experienced free user who upgrades doesn’t need the same input as instant or zero-touch buyers. But that doesn’t mean they don’t need any attention — they’ve just entered into a completely different relationship with your product. They deserve to be welcomed and shown around, just like new subscribers; simply in a different way.

What premium re-onboarding actually looks like

Re-onboarding for new subscribers isn't about repeating everything from free onboarding. It's about specifically welcoming people into the premium experience — making it immediately obvious what they've unlocked and how to start using it.

Slack does this well. When a user starts a Pro trial, they immediately receive an email that doesn't just say 'your trial has started' — it tells them exactly what's changed. The headline feature gets its own moment ('Message & file history unlocked'), followed by a clear list of everything else now available: Slack Connect channels, group huddles, unlimited canvases. There's no ambiguity about what the upgrade means. And crucially, the call to action isn't 'explore your account' — it's 'Explore in Slack', pointing users straight back into the product.

That's the whole job:

1. Confirm the decision
2. Show what's unlocked
3. Direct to first action

Monday.com does something similar. When a user starts a trial, they immediately receive a message encouraging them to dive back in and create their first workspace. They also point to next steps for further guidance, like tutorial videos, blog content and access to support.

The job of post-subscription messaging is to answer three questions for your new subscriber:

1. Where are the premium features? Show them, don't assume they'll find them.
2. How do I actually use them? A list of features is not the same as a guide to a first action.
3. Did I make the right call? This is the question every new subscriber is quietly asking. Your job is to reassure them the answer is yes (and quickly).

The goal is to move someone from "I paid for this" to "I just did something I couldn't do before" as fast as possible. That first premium success — sometimes called a ‘premium win’ — is the moment a subscription stops feeling like an expense, and starts feeling like a habit.

Define your premium win and build toward it

Every product has its own version of a premium win, and figuring out what yours is should be one of the first things your retention team works on.

• Strava’s premium win is seeing your performance data and training insights — the kind of analysis that makes a serious runner feel like they have a coach in their pocket
• Calm’s premium win is completing a sleep story or unlocking a full meditation course after a few free sessions have already built the habit
• Quizlet’s premium win is the moment a student gets access to Test Mode after experiencing the study tools for free

What all of these have in common is that they're concrete, experiential moments — not a feature list, not a marketing promise, but an actual thing the user did that they couldn't do before. They’re proof of the meaningful value your app promised.

A simple way to think about your post-subscription messaging is to design it like a seven-day journey, but for people who just converted:

• Day zero is a warm welcome that tells them exactly what to do first
• Day one or two is a nudge toward that specific premium win
• Day three is a check-in where you celebrate what they've done and point them to what's next
• By day five or six, you're spotlighting a feature based on what they've actually engaged with, not a generic list

Duolingo does a version of this brilliantly with their weekly progress reports, which don't just remind users to practice — they show users what they've already accomplished, making the subscription feel like proof of progress rather than just a recurring charge.

Four examples of lifecycle messaging to keep value visible long-term

The post-subscription gap is most dangerous in the first week or two. But the underlying problem — subscribers gradually forgetting why they're paying — doesn't go away after that. It just becomes more hidden.

This is where longer-term lifecycle messaging earns its keep.

Think of it as resurfacing value:

• Helping users connect to real outcomes rather than abstract features
• Reflecting their progress back to them
• Reminding them why they started

Lifesum: sharing feature updates

Lifesum sends messages to users when they improve a core feature — not just to announce the update, but to give subscribers a reason to re-engage with something they might have been using on autopilot.

Netflix: personalization and recommendation

Streaming apps like Netflix and HBO Max take a personalized approach, sending recommendations for what to watch next based on subscribers’ viewing history. It's a simple idea, but it solves the friction point of decision fatigue. When the next step is obvious and feels relevant, users take it. When they have to think about what to do, they often don't bother — and habit breaks are exactly where churn starts.

Dropbox: feature spotlight

Feature spotlights work particularly well for subscribers who haven't explored everything they've paid for. A targeted message that says "hey, you've never tried X, and based on how you use the app, it might be your new favorite thing" is infinitely more useful than a generic "here's everything we offer". It's also a retention intervention — that untouched feature might just be what would have justified the subscription when they hit renewal.

One example is Dropbox, who reach out to people using Dropbox to save and share images, inviting them to try their new image search feature. The email quickly conveys why it’s relevant for the user, what the benefits of the undiscovered feature are, and where to go next.

Strava: user identity reinforcement

Finally, don't underestimate the power of identity reinforcement. Strava tells users when they earn a ‘Local Legend’ badge by becoming the most frequent or fast rider/runner on a specific route. It highlights an achievement linked to the community, and gives them a reason to keep checking the app and building that habit. Strava even notifies users when they’re knocked off the top spot, creating an engagement loop between the entire user base competing with one another.

People stick with products that reflect who they want to be. Subscription products that make users feel like they belong to something tend to retain far better than those that treat subscribers purely as revenue lines.

If they’re engaged, just focus on the moments that matter

It would be wrong to end without saying this: more messaging isn’t the answer. While filling the silence is effective, it only works if there is still breathing space. The goal isn't to fill every day with a notification — it's to show up at the right moments with the right thing.

If your subscribers are actively engaged with your product, the best thing lifecycle messaging can do is get out of the way:

• Suppress messages when users are already in a healthy habit
• Avoid interruptions during focused sessions
• Step back when the product is working

These are all signs of a mature retention program, not a passive one.

The target is the moments when value is at risk of being forgotten: right after someone converts, when engagement starts to slip, when renewal is approaching. Those are the windows where a well-timed message can genuinely change the outcome.

Silence at the right time is fine. Silence right after someone hands over their credit card details is where early churn gets built.

Treat conversion as the beginning of the relationship

The shift in thinking here isn't complicated, even if building it out takes time. Treat conversion as the beginning of a new relationship, not the end of a funnel. Ask yourself: what does a new subscriber need to experience in their first week to feel confident they made the right call?

Start small. A warm premium welcome, a prompt toward the first premium win, and a week-one check-in is already meaningfully better than the silence most apps currently offer. Measure early cancellation rates in the first 30 days. Track whether new subscribers are actually reaching premium features in their first week. See what moves, and take it from there.

You can explain your app’s value, learn what each visitor wants, guide them toward a relevant offer, and let them purchase before opening the app.

For developers, the opportunity is straightforward: test whether a guided web journey can bring in more paying customers without adding a full web growth stack to your roadmap.

RevenueCat Funnels keeps that test focused. Build and host the journey in RevenueCat, connect it to the products and entitlements you already manage, and measure how campaign traffic moves from its first click toward purchase.

Several recent updates make it faster to get from an idea to a useful first test.

Get to a credible first design faster with AI

A blank screen creates work before it creates information. You need to choose a structure, write the copy, arrange the components, and make the result look like it belongs to your app.

RevenueCat’s AI Editor helps you get through that starting work faster. Describe the funnel screens you want in natural language, and the editor can create or modify it directly in the dashboard. You can also provide a screenshot or a design specification to steer the result.

The latest editor is better at:

• Creating polished starting points from open-ended prompts
• Handling complex layout and content changes
• Interpreting requests that don’t specify every design decision
• Rewriting copy and adjusting typography, spacing, colors, and imagery
• Adding, removing, and rearranging components

You still control the result in the visual editor. AI gets you to a credible draft faster; you decide what’s ready to test.

Learn more about building and editing Funnels >

Add familiar interactions without configuring them from scratch

A useful funnel often needs more than static text and a purchase button. It may need to compare plans, prepare a recommendation, or make a short processing step feel intentional.

RevenueCat Funnels now includes a dedicated bottom sheet component with a ready-to-customize ‘View all plans’ example. You can keep the main screen focused on a recommended offer while still letting visitors inspect the other available plans.

New loader components help you create processing and recommendation screens with:

• Circular or linear progress animations
• Live percentage indicators
• Changing status messages
• Multi-stage loading sequences
• Components that appear at a specified point

A timer-complete trigger can automatically move the visitor to the next step. Alternatively, you can reveal a button and let them continue when they’re ready.

These additions reduce the amount of layout and interaction work required to make a funnel feel complete.

See how loader components work >

Use your existing Firebase Authentication setup

If your app uses Firebase Authentication, new customers can now create an account without leaving the funnel or passing through a separate login page. This gives you an email for lifecycle messaging if they don’t purchase and ensures customers who do purchase can sign in to the same account when they open your app.

Add an authentication step, connect your Firebase project, and choose between:

• Google sign-in: visitors authenticate through a Google popup inside the funnel
• Email and password: visitors use a customizable login and sign-up screen, with optional email verification

Firebase connections are saved at the RevenueCat project level and can be reused across all funnels.

Visitors who already have an authenticated session automatically advance through the step. Everyone else can create an account or sign in, then continue through the journey and arrive at checkout with a consistent identity.

Configure Firebase Authentication in RevenueCat Funnels >

Create your own custom components

The standard components and AI editor will cover most first funnel experiments, but if you need to go further, the new custom component lets you (or your agent) build a component directly from web code.

You can package HTML, CSS, and JavaScript and place it inside a funnel screen. Custom components can support:

• Lottie or Rive animations
• Interactive comparison tables
• Accordions and custom layouts
• Calculators, charts, or counters
• Canvas and WebGL experiences
• Other app-specific visuals and interactions

Download the starter project, customize it yourself or give the folder to a coding agent, and upload the completed ZIP file. RevenueCat validates and hosts the bundle.

Packages, purchase buttons, and other purchase-critical elements remain native to RevenueCat. You use custom code for the part that differentiates the experience while keeping the surrounding journey inside the funnel editor.

Learn how custom components work >

Give campaign traffic a clearer path to purchase

Together, these updates make the time you spend in RevenueCat Funnels go further: AI gets you to a strong first draft, ready-made components cover common interactions, Firebase connects your existing authentication, and custom components let you extend the experience with your own HTML, CSS, and JavaScript.

If you’re already sending traffic from paid ads or creator partnerships, funnels give you a focused next step: turn those clicks into a guided journey from campaign promise to purchase.

Create your first funnel in RevenueCat >

Promise value → onboard users → prove value → present upgrade

You introduced users to your product, helped them experience an aha! moment, built trust, then asked them to pay. But today, many of the fastest-growing apps have flipped the last two steps of that model:

Promise value → onboard users → present upgrade → prove value

The change didn't happen overnight. As apps became better at contextual onboarding, personalization, and paywall optimization, they discovered users were often willing to purchase (or at least start a trial) before they had fully experienced the value being promised.

When Sean Ellis and I interviewed the co-founder of Noom on The Breakout Growth Podcast back in 2021, we were blown away by the app's 60-step onboarding flow. Today, 60 steps doesn't even sound that long.

And the data supports the shift: RevenueCat's State of Subscription Apps 2026 report found that hard paywalls outperform freemium by nearly 5x on conversion.

For developers, this creates incredible leverage. Faster payback periods mean better ROAS. Better ROAS means more dollars to reinvest in growth. Entire categories of apps are suddenly able to scale acquisition more aggressively.

But there’s a problem.

Hard paywalls and supersized expectations

When users pay before they experience meaningful value, the post-purchase user experience has to do much heavier lifting — and with a smaller margin for error to keep users from churning.

A simple switch in the acquisition flow means that early experience now has to:

• Validate the expectations created by your marketing
• Justify the purchase decision
• Create enough momentum for the user to return again

In other words, your app still has to build a habit and activate the user, but it needs to do this all while also proving it is worth their time at all.

AI is amplifying this challenge; they monetize incredibly well, but many AI-powered apps are struggling with long-term retention as their novelty fades. However, I don't think this is really an AI problem, I think it's a value problem. Building apps is getting easier, building durable growth is getting much harder.

When users buy before they've experienced meaningful value, identifying the experiences that will actually drive long-term retention becomes more challenging, just when it becomes more important. And, unfortunately, that's where many teams get stuck.

A few weeks ago, an app founder reached out to me after getting enough annual renewal data to realize his renewal numbers were way below expectation. They’ve cracked the code on acquisition — their onboarding is brilliant, with over a million downloads and ~30% month-over-month ARR growth — so they have a lot to celebrate. But not enough of the users they convert are sticking around. Solving this renewal curse is going to be crucial for their success.

This is where teams often struggle. On seeing those numbers, the immediate responses are often:

• Winback offers to salvage churned users
• Emails and notifications to engage users at funnel dropoff points
• New monetization tactics to get people paying longer

All good ideas, but none of them really address the underlying problem. And if these tactics quietly become the strategy, the team will never solve the value issues holding them back. The most successful growth teams I've worked with do something different. Before they jump into solutions, they work backwards, investing time into defining what success actually looks like.

Value isn't a moment, it's a journey

As humans, we are wired to solve problems at the point where they become visible. If retention is struggling, teams look at churn. If conversions are down, teams dive into paywall optimizations. If engagement is soft, we cue the comms team to add more emails and push notifications. The instinct makes sense; go where the pain is. But the cause of the pain isn’t always where you feel it.

Value isn't created in a single moment — it's built across the entire arc of the user experience. From the first ad someone sees, through onboarding and early use, to the first moment a user realizes this app meaningfully impacts their life. These steps are symbiotic..

Product-market fit is a try → use → love → keep using journey. Each step is deeply connected to the one before it, and a break anywhere in the chain can show up later as a retention problem.

Working backwards flips that. Instead of starting with the problem, you start with the desired outcome and ask: what journey creates that outcome?

Instead of asking "what does a successful user look like a year from now?" challenge your team to ask, "if a user loves this product a year from now, what happened along the way that made them love it?"

At each step:

• What did they discover?
• What did they feel?
• What did they start doing differently?
• What made them realize this app was actually going to meaningfully change or improve something for them?

Within the answers to those questions is your treasure map.

Why starting from the finish line works

A few years ago, I started running a workshop exercise called the ‘Perfect Customer Loop’ with growth teams. The goal was to make working backwards easier and more concrete.

It starts by picturing a must-have user of your app. Let's call her Maggie. She loves your product so much that when a friend mentions a problem your app solves, Maggie lights up and says "you have got to try this". That moment of advocacy is your destination, and from there, the team works backwards.

In the exercise, we go around the room and ask questions like:

• What happened an hour before the conversation that reminded Maggie how much value she gets from your product?
• What occurred a week ago that deepened her emotional connection to it?
• What surprised her a month ago?
• When was the first moment she knew this was going to work?

The team works all the way back to the same "you have got to try this" moment where Maggie was introduced to the app by another must-have user.

The moments the team surfaces are informed hypotheses, and that's fine. The exercise isn't about getting it perfect, it's about creating a shared map of the value experience. You can validate the moments later through user interviews and retention data.

I've run this workshop at RevenueCat's App Growth Annual conference and with teams across industries and categories. It consistently surfaces the gaps between the value teams think their app is delivering and the value users are likely to actually experience. More importantly, it unlocks how your most successful users came to love your product — what they knew, what they felt, and what they experienced along the way. That's the treasure map. Find the success story, and recreate it.

A company I worked with connects entrepreneurs with domain experts for paid advisory sessions. The team had built their entire growth narrative around this value of access to experts, faster decisions, and better outcomes.

But when we ran the Perfect Customer Loop exercise, what kept surfacing wasn't any of that, it was confidence. Customers weren't coming back because they got good advice, they were coming back because the conversations made them feel like they could trust their own judgment.

That's a completely different product story compared to the value the growth team were selling.It informs everything from what your onboarding needs to communicate, to what your activation experience should feel like, to what your retention messaging should say.

The takeaway is this: you can't design for an outcome you haven't clearly defined, and working backwards forces you to define it. When teams follow this path, the conversation almost always arrives at activation, where promise and value delivery converge.

Activation is a story, not just a moment in time

Ask any growth team what the most important retention driver is and they'll likely land on activation.

They're right, but it's worth being precise about what activation actually means. There are real moments that matter, like the first time a user experiences genuine value, and the point where that value turns into habit, but activation isn't just a completed checklist, a logged workout, or an uploaded file. Those can be critical actions and aha! moments, but to me, activation is a story that often starts even before a user gets to the app store.

In Daphne Tideman’s blog Why most activation metrics don’t predict who will stay (and what to use instead), she does a great job of explaining how easy it is to optimize for the wrong thing. We often conflate engagement for activation, rather than focusing on metrics that actually indicate users moving toward becoming a long-term subscriber — like ‘time to first value’ and ‘time to core value’..

By the time a user hits whatever you've designated as your activation event, they've already been shaped by the recommendation of a friend, an ad, your App Store listing, the onboarding experience, and even your pricing and paywall. If activation feels underwhelming, the problem is often upstream. A promise that was too big, targeting that brought in the wrong people, onboarding that set the wrong expectation.

When you have a hard paywall, this gets amplified. You've asked users to pay before they've experienced meaningful value, which means the first motion where you deliver value really needs to land.

If you want to design that entire activation experience well, start working backwards from what your best users already know, feel, and do.

Find your must-have users, then follow them

Working backwards isn't something you do once in a workshop and check off the list. It's a way of operating. Here's where to start.

The first step is identifying your ‘must-have’ users. Not necessarily your most active users or your highest LTV segment, but the users who love your product and would be very disappointed if they couldn’t use it anymore.

Sean Ellis built his product-market fit survey to surface those users: respondents who would be ‘very disappointed’ to lose your app are the must-have users you want to make more of. They've already made the journey you're trying to design for everyone else, and the rest of the survey tells you why they feel the way they do.

The second step is understanding what actually happens to them along the way. This is where the work pays off. Identify the must-have users and dig into the journey that creates them. Talk to them. Survey them. Find out what they knew, what they felt, and what they did in the early days that set them up for success.

The Perfect Customer Loop is designed to help you do this. Sean and I wrote a guide to using the PMF survey and the PCL together if you are looking for a deeper playbook.

The third step is the gap analysis. Not "where are users dropping off?" but "where does our current experience fall short of the journey that creates must-have users?" That question points you toward the moments that actually determine whether users succeed, long before a retention metric surfaces the problem.

Working backwards scales

Retention is the obvious place to apply this mindset, but the approach is transferable across your entire growth engine:

For onboarding: instead of asking "how do we reduce drop-off in step three?" ask "what does a new user need to know, feel, and believe by the end of onboarding to be set up for their first real value moment?" The answer often lives earlier in the journey than you'd expect.

On churn, instead of building winback campaigns that depend on discounts to claw back lost users, ask "what moment in the journey would have changed this outcome?" Churn analysis done this way becomes an onboarding and activation roadmap, not a rescue operation.

On features, before building anything, ask "does this move more users toward the must-have experience, or does it move us sideways?"

The teams that build long-term growth aren't better at reacting to problems. They're better at defining success before they start designing journeys to get there.

Building has never been faster or easier, but the foundation hasn't changed. Users have to try your product, use it, love it, and keep using it. Working backwards from that outcome and understanding deeply who your best users are, what made them that way, and how to design more of that journey is how you turn fast growth into sustainable growth.

In this article, you'll explore where the component vocabulary runs out, how the Rive and Lottie bundles are structured and the two decisions that make them work, what the upload step involves, what changes in your Android code, and the constraints worth knowing before you commit to one.

Where the component vocabulary stops

Every component in a Paywalls tree is something the SDK knows how to interpret. A stack arranges children, a text renders a localized string, an image draws a remote asset. Your paywall config is a composition of these known types, which is exactly why it can be served as JSON and rendered by a binary that has never seen that particular paywall.

The consequence is that you can compose the vocabulary, but you cannot extend it. An animation format is not expressible as a stack of text and images. Before custom components, you had three options:

• Export the animation as a video. The video component gives you motion with no bundle to build, and for a fixed clip it is still the right answer. It cannot react to state, and a video costs far more bytes than the vector data that produces the same motion.
• Ship a native Composable and gate it. You write the animation in your app, then guard it behind a flag or an offering identifier. This works, but it needs an app release for every change, which gives up the reason you moved to server driven paywalls.
• Fall back to a static image. Simple and immediate, and it throws away the motion entirely.

A custom component targets the case none of those cover: content that is interactive, vector based, and changeable from the dashboard. The RevenueCat docs name the use case directly, describing custom components as usable "for interactive elements such as Lottie or Rive animations and animated backgrounds."

What a custom component is

A custom component is a folder of web files with index.html at its root. You zip that folder and upload it to the component in the dashboard. RevenueCat validates the archive, unpacks it, and serves the files over HTTPS from a subdomain dedicated to that upload. In the tree, you place it and size it the way you place any other component.

Three properties shape how you build one:

• It is self contained. Everything the bundle needs travels inside the zip: scripts, styles, fonts, animation data, and the animation runtime itself. Once the bundle has loaded there is no further third party fetch, so the animation cannot fail because some CDN was slow.
• It runs under a strict Content Security Policy. This is the rule that shapes all the code below. The bundle cannot call fetch(), cannot use eval() or new Function, and cannot use inline <script> blocks. These are hard failures, not degradations.
• It is decorative. The docs are explicit that "paywall elements such as packages and purchase buttons must remain native." Selection and purchase stay on real components, where the SDK owns the purchase path.

Inside the box you are not bound by the component vocabulary. Any markup, any animation runtime, any layout technique the bundle rules allow. What you give up is the constraint being removed entirely: it is traded for a smaller set of rules, collected in the last section.

Two authoring requirements are easy to miss. The bundle must fill its frame, which means sizing to 100% width and height with margin: 0; padding: 0 and no hardcoded pixel dimensions. And index.html must contain a <head>, because RevenueCat injects its content SDK there at upload time. You do not add that script tag yourself.

One more thing about placement. A custom component's visibility can be varied by condition through the override system, but its size cannot. Since framing depends on the ratio of the box to the animation, pick a size that frames acceptably in every configuration you support.

The CSP rule is the one to internalize first, because nearly every Rive and Lottie tutorial loads its animation by URL or file path. A bundle cannot fetch anything at display time, so both examples below are built around handing the animation data to the runtime directly.

Rive: A state machine driven character

Rive is a runtime for interactive vector animation. What distinguishes it from most animation formats is the state machine: rather than playing a fixed timeline, a .riv file defines states and transitions, so a character can idle, react, and settle back. Files are compact, usually tens of kilobytes.

The bundle for the Marty example is six files:

rive-03-marty/
├── index.html
├── styles.css
├── app.js
├── config.js
├── rive.js
└── riv-data.js

rive.js is the Rive runtime and riv-data.js holds the .riv file as a base64 string. config.js carries the per animation settings, which lets one template serve several bundles. The snippets below inline those values instead, so each one reads on its own.

The interesting part of index.html is the script order:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="stylesheet" href="./styles.css">
</head>
<body>
  <div id="stage"><canvas id="canvas"></canvas></div>

  <script src="./rive.js"></script>
  <script src="./riv-data.js"></script>
  <script src="./app.js"></script>
</body>
</html>

Every script is a file reference, since inline blocks are rejected. The stylesheet is what gives the stage a height, and without it a canvas collapses to nothing:

html, body { margin: 0; padding: 0; width: 100%; height: 100%; }
#stage { width: 100%; height: 100%; }
#canvas { display: block; width: 100%; height: 100%; }

Two decisions are specific to shipping Rive this way. The first is which Rive build to use. The default @rive-app/canvas build fetches its WebAssembly from a CDN at startup, which the CSP blocks, so use @rive-app/canvas-single instead. That build inlines the WebAssembly into the JavaScript file, which is also why it is around 1.8 MB.

The second is how the animation reaches the runtime. Rive's src option takes a path, and loading it triggers a fetch. So riv-data.js carries the bytes as base64:

window.__RIV_B64 = "UklWRQ...";

You generate that from the .riv file with one command:

printf 'window.__RIV_B64 = "%s";\n' "$(base64 -i marty.riv)" > riv-data.js

In app.js, decoding base64 back to bytes uses atob, which returns a string of character codes that you copy into a typed array:

var bin = atob(window.__RIV_B64);
var bytes = new Uint8Array(bin.length);
for (var i = 0; i < bin.length; i++) {
  bytes[i] = bin.charCodeAt(i);
}

Those bytes go to the runtime through buffer rather than src. Fit and Alignment control framing, which the next section covers:

var r = new window.rive.Rive({
  buffer: bytes.buffer,
  canvas: document.getElementById('canvas'),
  autoplay: true,
  layout: new window.rive.Layout({
    fit: window.rive.Fit.Cover,
    alignment: window.rive.Alignment.TopCenter
  }),
  onLoad: function () { start(r); }
});

onLoad fires once the file is parsed, which is the first point where you can ask what the file actually contains. That matters because autoplay only covers files holding a single linear animation. When a file has a state machine, autoplay starts one of the linear clips instead of the intended behavior, so you stop that playback and start the machine:

function start(r) {
  r.resizeDrawingSurfaceToCanvas();
  var machine = (r.stateMachineNames || [])[0];
  if (machine) {
    r.stop();
    r.play(machine);
  }
}

resizeDrawingSurfaceToCanvas() matches the canvas backing store to its display size, so the result stays sharp on high density screens.

Fit and alignment: Matching the artboard to the box

Framing is the detail that needs attention. A Rive artboard, the fixed size canvas the animation was authored on, has its own aspect ratio, and the box the paywall gives you probably has a different one. With Fit.Contain the artboard is scaled to fit inside the box, which leaves transparent bars on two sides. If the artboard has its own background, those bars read as unwanted padding.

Which setting is right depends on the artboard:

• Transparent artboard: keep Contain. The bars are invisible against the paywall background, which is what you want for a mascot sitting on your own backdrop.
• Artboard with its own background: use Cover so the artboard fills the box, and set alignment to control what gets cropped.

That second point matters for characters. Cover crops to fill, and the default center alignment crops evenly from both edges, which in a wide box takes the top of the head. Marty uses Cover with TopCenter, so a wide box crops the legs and keeps the face.

Lottie: A vector animation from a JSON document

Lottie takes a different approach. A Lottie animation is a JSON document describing shape layers, transforms, and keyframes, and the runtime interprets it into vector output. There is no state machine, just a timeline you play, loop, or seek.

The Premium Crown bundle mirrors the Rive one:

lottie-02-premium-crown/
├── index.html
├── styles.css
├── app.js
├── config.js
├── lottie.min.js
└── animation.js

Here lottie.min.js is the Lottie runtime and animation.js holds the animation JSON. Two notes on those files. The runtime is the light build, which ships without the expression evaluator and therefore without the eval call the full build contains, making it the one to pick for a bundle. And the markup differs slightly from the Rive case, since the SVG renderer needs a plain container rather than a canvas:

<body>
  <div id="stage"><div id="host"></div></div>

  <script src="./lottie.min.js"></script>
  <script src="./animation.js"></script>
  <script src="./app.js"></script>
</body>

The self containment question has a simpler answer on this side. loadAnimation accepts either a path to fetch or an animationData object already in memory, so animation.js assigns the JSON to a global:

window.__ANIM = { "v": "5.12.2", "fr": 60, "w": 512, "h": 512, "layers": [] };

And app.js hands it straight over:

var anim = window.lottie.loadAnimation({
  container: document.getElementById('host'),
  renderer: 'svg',
  loop: true,
  autoplay: true,
  animationData: window.__ANIM,
  rendererSettings: {
    preserveAspectRatio: 'xMidYMid meet',
    progressiveLoad: false
  }
});

preserveAspectRatio is the Lottie equivalent of Rive's fit setting, and it takes standard SVG values. xMidYMid meet behaves like Contain and fits the whole animation inside the box. xMidYMid slice behaves like Cover and fills the box, cropping the overflow, which is what you want for a full bleed animated background.

One habit to adopt for either runtime: pause when the paywall is not visible, so a looping animation is not drawing frames the user cannot see. The event fires when the paywall is dismissed or the app goes to the background:

document.addEventListener('visibilitychange', function () {
  if (document.hidden) {
    anim.pause();
  } else {
    anim.play();
  }
});

For Rive the same handler calls r.pause() and r.play() on the instance from the constructor above.

he two bundles land in very different places on size. The crown zip is about 49 KB and the Marty zip about 660 KB. Both carry their own runtime, so the difference is the runtime itself: the Rive WebAssembly build is roughly ten times the size of Lottie's JavaScript renderer.

Uploading in the dashboard

Zip the contents of the folder, not the folder. index.html has to be at the root of the archive, and this is the most common thing to get wrong. On macOS, selecting the folder and choosing Compress produces the nested layout, so zip from inside the folder instead:

cd rive-03-marty && zip -r ../rive-03-marty.zip . -x ".*" -x "__MACOSX/*"

The exclusions matter because Finder and the shell both like to add .DS_Store and __MACOSX entries, which count against the file limit and put things in your bundle you did not intend. Verify the layout before uploading:

unzip -l rive-03-marty.zip

If the listing shows index.html rather than rive-03-marty/index.html, the archive is right. Upload validation also rejects nested archives, duplicate paths, absolute paths, and .. in entry paths.

Then add a custom component to your paywall, upload the zip, and position and size it in the tree.

To check your work before uploading, the starter template in the docs includes a preview script, bash scripts/preview.sh, which serves the folder locally and frames it at phone size. Opening index.html directly in a browser is quicker and will tell you whether the animation parses and plays, but it enforces none of the bundle rules, so a page using fetch() or an inline script will work locally and fail on the paywall.

What changes in your Android code

Almost nothing, and this is worth stating plainly because a new component type sounds like it needs new integration work. Move to purchases-android 10.16.0 or newer and the paywall you already present renders a custom component with no new code.

The Compose entry point is unchanged:

val options = PaywallOptions.Builder(dismissRequest = { finish() })
    .build()

Paywall(options)

The activity based path is unchanged too. The launcher takes a result handler, so the activity implements PaywallResultHandler, and it has to be created in onCreate:

class MainActivity : ComponentActivity(), PaywallResultHandler {

    private lateinit var launcher: PaywallActivityLauncher

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        launcher = PaywallActivityLauncher(this, this)
    }

    override fun onActivityResult(result: PaywallResult) {
        // handle purchased, cancelled, restored, error
    }
}

Then present it from wherever you gate your feature:

launcher.launch()

Because the definition lives on the server, adding an animation becomes a dashboard change rather than a release. You can put a Rive character in front of users, measure it, and take it back out without touching your app, once your install base is on a version that knows the type.

Availability and constraints

Custom components landed in purchases-android 10.16.0, released on July 31, 2026, and they require Paywalls. A V1 template based paywall has no component tree to place one in.

That version floor is the one operational detail to plan around. An older SDK does not recognize the component and renders the component's fallback instead, so configure a fallback before you enable the paywall change, and treat the rollout as gated on your install base rather than instant.

The upload limits are:

• Compressed zip: 5 MB
• Total uncompressed: 20 MB
• Single file: 10 MB
• Number of files: 200

Rive bundles are the ones to size check, though not for the reason you might expect. Marty's .riv is 30 KB, and base64 encoding inflates it to 40 KB, so almost all of the 660 KB zip is the runtime. Since the runtime is a fixed 1.8 MB uncompressed, the cap that binds first is the 20 MB uncompressed total, not the 5 MB zip.

The bundle rules follow from the Content Security Policy, and they rule out the shape most tutorials use:

• Reference scripts as files. Use <script src="./app.js">. Inline script blocks are rejected, even a single line of bootstrap.
• No eval() or new Function. Some library builds include an expression evaluator that uses them. Pick the build without it.
• No runtime fetching. No fetch(), no XMLHttpRequest, no importScripts(), and no http: resources. HTTPS images referenced from <img> or CSS do work, but bundling them removes the dependency.
• Relative paths only. Reference sibling files as ./file.js.
• Keep purchase UI native. Packages and purchase buttons stay on real paywall components.

Conclusion

Reach for a custom component when the content is the point and the vocabulary cannot express it: a branded character, a celebration on trial start, an animated backdrop. For a fixed clip, the video component is less work. For anything the tree already covers, use the tree, since it gets you native layout, localization, and the typed purchase path for free. When you do build a bundle, let the no fetching rule drive the design and most of the remaining decisions answer themselves.

What makes this worth the setup is not the animation but where the decision now lives. An animation used to be a code change, which meant a release, a review, and a staged rollout before you learned anything. Moving that box to the server turns it into something you can try on Monday and reverse on Tuesday, and that shortened loop tends to matter more than any single animation you put in the box.

When Captain of Shipaton, Charlie Chapman, announced the winner of Shipaton 2025’s #BuildInPublic award — a prize that included $15,000 and travel and lodging to New York — the winner was nowhere in sight. Camilo Peñalver, who had spent the previous months posting almost daily while building Gurwi, was at home watching the ceremony on his laptop.

The choice not to be there had not been his — there had been some obstacles; a common theme in the story of Gurwi.

This is the story of Gurwi and Camilo, a product and its builder that have become almost interchangeable. It follows his path from a YouTube course, to an ugly viral Figma prototype, to the Gurwi. Most importantly, it is about how he built all of this in public — leading strangers to give him cash, politicians to talk with him, and millions of views on TikTok that converted into loyal Gurwi customers.

Discovering Gurwi

Born in Santa Marta, Camilo spent his childhood moving across Colombia's Caribbean region before finishing high school in Riohacha, the capital of La Guajira — one of the country's poorest regions. The limited educational opportunities he encountered helped shape the problem he would later try to solve. He went on to study communication, journalism, and psychology while pursuing projects in video production, fiction, and entrepreneurship.

That mix of education, media, and entrepreneurship eventually led him to teach himself to code and imagine Gurwi as the “Duolingo for everything”. His first public version was a crude Figma prototype, shared in a TikTok video promising a mobile app that could make education more accessible in Colombia.

That video reached more than 250,000 views, 40,000 likes, and more than 500 comments, proving the idea already had an audience.

10 million from a stranger

The video even caught the attention of Colombia’s then Minister of ICT, Mauricio Lizcano, who congratulated Camilo publicly. Camilo used the opportunity to ask for help, but the exchange produced only a short call and no practical support.

Yet, Camilo kept building and posting, even though development, recording, and editing left little time for anything else. In 2023, he published a video about alleged irregularities in Fondo Emprender, a government seed-capital program. It reached one million views. The following year, he applied to the same program but was rejected and was unable to apply again because no further calls for pitches were announced. Later, a Colombian-born tech entrepreneur living abroad saw another video Camilo posted in 2024 and, after a 30-minute call, gave him 10 million Colombian pesos to continue building Gurwi.

The funding kept the project moving, but Gurwi still took almost a year to reach the app stores. The last part was a real sprint — but not because of funding, because of Shipaton.

Moving from one technology to another

Camilo had built the first version of Gurwi using FlutterFlow, a Flutter-based visual development platform. The stack worked great for building the MVP, but he felt that the platform was limiting some of the directions they wanted to take the app, mainly in supporting the rendering of the dynamic content that powers the Gurwi lessons.

Help arrived in the form of Jonnier Martínez, who joined to work on Gurwi in exchange for a small percentage of it. Since he had been programming longer than Camilo and had more experience in backend development, they decided to move from FlutterFlow to Flutter and build both iOS and Android versions of Gurwi using it, as well as a new backend and web version of Gurwi, for managing the content the app displays.

Discovering Shipaton

Camilo found Shipaton on X because he was already following RevenueCat and the wider Flutter ecosystem. Gurwi was still months from launch and the team had planned to wait until the following year, but the opportunity was too valuable to pass up.

The $15,000 prize could provide the starting capital Camilo had struggled to find through local programs. Winning could also help the team start a company in the United States, access Stripe, and pursue opportunities that were otherwise difficult to reach from Colombia.

Shipping before they were ready

Entering Shipaton meant bringing a launch planned for the following year forward by several months. Neither Camilo nor Jonnier had shipped a production app before, and the move from FlutterFlow to Flutter was still underway. They could reuse parts of the interface and the visual direction, but for example the web editor for creating lessons had to be built almost from scratch.

The work split along their strengths. Jonnier focused on development of the web editor, while Camilo moved between programming, strategy, marketing, recording, and editing of the mobile app. They submitted roughly three days before the deadline. The forms were familiar territory for Camilo; the harder part was presenting an app that was still new to both its users and its builders. They deliberately chose to wait until the last minute before posting the form, in order to attach the most up to date app metrics and marketing results.

Building in public, in two languages

Camilo had documented Gurwi in Spanish from the first rough Figma prototype. For Shipaton, he created a separate English-language account on X, where RevenueCat’s team and the judges were most active. As Jonnier and Camilo shipped features, Camilo also posted carefully edited progress videos, told the story behind the app, and tagged #Shipaton and #BuildInPublic so the work remained high on the feed.

The largest audience still came from Spanish-speaking social media. Camilo asked other creators to share Gurwi’s story, extending the campaign beyond what he could produce alone. Together with his own pitch, those videos generated more than four million views.

“The point is we ran. We gave it everything. My world became RevenueCat and Shipaton.”

The reach made Gurwi difficult to miss, but reach alone did not win the category. The judges chose Gurwi for the authenticity of its build-in-public story and the care visible in both the app and the videos around it.

The app made it to New York first

Charlie told Camilo about the win before the public announcement, since the prize included a trip to New York. Camilo already had a passport, but not a US visa, and appointments could take months or even years. After repeatedly checking for cancellations, he secured an appointment in Bogotá and the visa was approved.

Sadly, approval was not the same as having his passport back in hand. The Monday before the ceremony was a public holiday in Colombia, leaving too little time for the stamped passport to arrive before his flight. Camilo watched the ceremony from home while Gurwi appeared on a Times Square screen. The app had reached New York before its builder.

Beyond Shipaton

The $15,000 prize became the starting capital Camilo and Jonnier had spent years trying to secure. The Times Square appearance also gave Camilo a new story to share, and that story travelled through Colombian television, radio, and social media.

The attention converted into customers. Camilo’s later account puts Gurwi’s user payments during the year of the win at more than $19,000, before the app stores’ 15% commission. The team also founded Gurwi LLC, giving the team a chance to monetize with Stripe, something that was not possible in a Colombia-based company.

After Shipaton, Camilo and Jonnier have kept building Gurwi, growing the course catalogue, exploring B2B uses, and launching prompt-generated, hyperpersonalized classes. It’s safe to say that the journey of Gurwi is far from over.

Advice for Shipaton participants

For this year’s participants, Camilo’s first advice is to tell a story. A strong app is not enough on its own; builders should show why they’re making it — “try to make people connect with the project and the person itself.”

Nonetheless, visibility is not a substitute for purpose. Camilo rejects copying existing apps for quick money: build something original, or at least something rooted in a real motivation. Start with something you want to use and become your own user. This helps you understand which problems matter, and gives the product a reason to outlive Shipaton.

Finally, make the work visible. Throughout the campaign, Camilo documented the process, asked other creators for help, and of course: shipped. No amount of visibility can replace shipping the app, and continuing to ship features which people want.

Everything you need to get your app approved by App Store review and Play Store review before the Shipaton deadline

At the time of writing, there’s a little less than a month left before the Shipaton deadline. Following conversations in our Discord and on social media, we’ve noticed three groups of developers: some have been stuck in app review despite submitting early; some haven’t submitted yet and are worried they won’t make it; and some are only just starting to build and are considering giving up because they’ve heard reviews can take a long time.

So I decided to write this guide to help you get through app review as quickly as possible. Apple and Google can be unpredictable, but the process is mostly manageable if you do the right things. Even if there’s less than a month left when you read this, don’t give up: mobile apps can ship surprisingly fast. Your app must be publicly available — not just in TestFlight or a Google Play testing track — before submissions close, so review should be your priority. This guide will show you how to reduce your app to a review-ready release, navigate Google Play’s 14-day testing requirement, and avoid preventable delays. If you’re a student, you can skip the stores and enter the Next Gen category with a demo video and public open-source repository instead.

How much time do you actually have?

Shipaton’s submission requirements say that your app must be publicly available — not just in TestFlight or a Google Play testing track — in the US app stores by September 30th at 11:45 pm PDT. Apple also says that it can take up to 24 hours for the app to appear in the App Store, so to be on the safe side, your app should be in stores, with RevenueCat powering an in-app purchase or serving ads through RevenueCat Ads, at least a day or two before the submission period ends.

How does the app review process work?

The next sections will assume some familiarity with the app review process both Apple and Google have for their respective stores. Fear not, we’ll go through the fundamentals here.

To publish your app, you need a developer account. Apple charges $99 per year, while Google Play charges a one-time $25 registration fee. You can enroll as an individual or an organization.

Organization accounts require additional verification, which may include a D-U-N-S number. New personal Google Play accounts also have a testing requirement, which we’ll cover below.

Once you have your account, you need to create your app, provide all the required assets, and bundle your app. After that, you can submit it to different “release tracks”. In Apple’s case, these release tracks are TestFlight and App Store. The first one is meant for testing your app either in private or public beta, and the latter is the actual store release, which allows everyone to download your app (and pay actual money for it).

Google Play offers internal, closed, open, and production tracks. You don’t have to use every testing track. However, some new personal accounts must complete a closed test before applying for production access. More on this below.

When we talk about submitting your app for review, we usually mean the store release tracks. Neither Apple nor Google allow apps into their store before someone from their team has reviewed the app and made sure it's not misleading, buggy, or unsafe for users. This is the part where first-time developers often get stuck. However, by doing the right things, which we go through next, you can make this process more likely to go through without problems.

I have not yet submitted my app for review

Ok take a deep breath, if you’re at this stage with your app, we will need to sprint a little, because our first priority will be to get our app into the review pipeline as soon as possible. To do this we need to strip our app to its core features. I’ve written about how to build a minimum lovable product in an earlier post, but to summarize:

build something that your core users would love, and drop everything else.

Should you ship your first version without in-app purchases?

Comment out the draft features, remove unfinished authentication if the core experience doesn’t need it, and postpone subscriber-only extras. You can also consider submitting a complete free version first and adding monetization in a second submission once the first is approved. This is optional, and it only makes sense if you have enough time for two reviews.

Purchases and subscriptions give reviewers more to check, and missing metadata, unclear instructions, or misconfigured products can cause a rejection. But for the main Shipaton competition, your qualifying version must still be live before the deadline with RevenueCat powering an in-app or web purchase, or serving ads through RevenueCat Ads. If the deadline is close, including monetization in the first submission may be safer than betting on a second review. Whichever route you choose, test your purchases in the platform sandboxes before submitting the monetized version.

Ace Google’s 14-day testing requirement

This requirement applies to personal Play Console accounts created after Nov 13, 2023. Before you can apply for production access, you must run a closed test with at least 12 testers opted in continuously for 14 days.

Start with the earliest functional version of your app. You can keep building while the closed test runs.

Once the 14 days are complete, apply for production access. Google may require additional testing if participation or engagement is insufficient, so encourage testers to use the app and share feedback.

To recruit testers, reach out to your friends and family. If you’re a billionaire in Gotham City, or just someone who doesn’t have family or friends, head to our Shipaton Discord to make use of the #looking-for-google-play-tester channel to recruit people to give your app a try.

My colleague Jaewoong wrote a deeper guide to Google Play’s 14-day testing requirement if you want the full walkthrough.

Make use of TestFlight and testing tracks

Talking of testing, it is good to test your app with a closed or open group of people before submitting the app to stores. This is a great way to gather feedback on your product, but it can also help you catch what an app review might flag: bugs, performance issues, bad copy, and incomplete features. You save the reviewer’s time and have a better feedback loop in your development process.

Get all your assets ready

Apple and Google both have extensive guidance on how your store submission should look, what assets and things you need (e.g., privacy policy and terms of service documents), and what not to say, for example (mention the word beta, or call your unreleased app the number 1 app for doing anything). Read these carefully, and ingest the information yourself, so that when you start editing your screenshots and app descriptions, you know exactly what is allowed and what is not.

For more detail, read Apple’s common app review issues and our guide to common App Store rejection reasons.

I’m ready to submit / I’ve already submitted my app

This section applies whether you're preparing to submit or your app is already waiting for review.

Before withdrawing a submission, understand what happens. Apple removes it from the review queue, and resubmitting starts the review process over. Apple does not promise to review submissions in the order received.

Google is more explicit: review time is counted from your latest submitted change. Sending additional changes while an app is under review may push it to the back of the review queue.

Don't restart review for a minor improvement. First, check what you can edit without withdrawing the build or whether you can provide the missing information through the store's review communication tools.

If you discover something likely to block access or cause a rejection, restarting may still be the faster choice. The following sections will help you identify those issues and give reviewers the information they need.

Go through your submission

If your submission is currently in review, it’s worth going through the submission fields again, seeing if you’ve missed something. Common things to check are, for example, if you placed placeholder links for a privacy policy, or if you forgot to put the actual content in that URL. In that case, you can just go and add the missing privacy policy. The same goes for your paywall and the links on it. Both Google and Apple require apps to have a privacy policy, and it needs to match what you submitted in the privacy declaration.

For apps with subscriptions, Apple and Google require appropriate Terms of Use links. Apple provides their own that you can link to in your App Store description by adding it at the end:

Terms of Use (EULA): https://www.apple.com/legal/internet-services/itunes/dev/stdeula/ Privacy Policy: https://your-apps-privacy-policy.com

A common thing with both the Terms of Service and privacy policy is that you can get by with very simple versions if you don’t add analytics or in-app purchases to your app. To get approved faster, consider dropping them as we mentioned earlier and adding them back later on.

Figure out your auth

If your app has authentication, check that you’ve created a test account and provided the username and password in the fields prepared for those. Reviewers won’t create accounts, but instead expect to use an account that has already been set up. Make sure that your test account does not have two-factor authentication on, as that will block the reviewer. In case your test account can’t be used without 2FA, then consider building a demo mode that shows all parts of your app, and documenting that in the review notes.

If your app uses Google or other third-party authentication, make sure you’ve also included Sign in with Apple, as that is a requirement. If your app uses third-party authentication to access data that is only possible with that account, for example, you built an email client for Gmail, then document that in the review notes as well.

If your app has subscriptions, make sure that your test account does not have an active entitlement; otherwise, the test account might not see your paywall, which in turn blocks the reviewer from reviewing your paywall and in-app purchases.

Record a video of your app in use

There’s been an uptick in Apple asking people to record a video of their app in use, showcasing, for example, the in-app purchases and authentication parts. This can be a simple screen recording, under a minute in length, that just showcases how your app functions and what happens, for example, after purchasing a subscription. Don’t overthink it, and consider adding it before reviewers even ask for it.

Use the expedited review process (for bugs)

This final point is something we advise against. Apple allows you to request an expedited review if you face “extenuating circumstances.” In practice, this means fixing a critical bug that severely affects the app experience or coordinating a release with an event you’re directly associated with.

You might think that releasing your app for Shipaton is one of these events where you can use the expedited review process to get your app approved in time, especially since Shipaton is a time-sensitive event and you are directly associated with the event as a registered participant.

However, Apple does not explicitly say that hackathon or competition timelines qualify. Apple also decides each request individually. RevenueCat’s official guidance is not to use expedited review for this. Instead, focus on submitting your app early enough and following the tips above.

What your next 30 days should look like

The points we’ve gone through in this article are not a magic bullet for acing app store reviews, but following them multiplies your chances for having a compliant app, the necessary requirement for passing the store review.

In terms of timeline, you should focus on getting your app in review in the next two weeks, and preferably in the next week. Stop developing new features. Instead, focus on fixing launch-blocking bugs and getting your app to an MVP stage you can submit for review. Once the app is approved by Apple or Google, the review process tends to go faster, so you will have a higher chance of getting, for example a version with in-app purchases approved.

As he put it:

“The only way of discovering the limits of the possible is to venture a little way past them into the impossible.”

Even flexible visual builders have limits. You can arrange the available components in countless ways, but some ideas, such as a branded animation or expandable FAQs, don’t fit neatly within a predefined set of building blocks.

We want to give developers more freedom to push what their purchase experiences can do and bring their most creative ideas to life. That’s why we introduced custom components for RevenueCat Paywalls and web-to-app Funnels.

With custom components, you can bring self-contained HTML, CSS, and JavaScript into a paywall or funnel to create animated backgrounds and icons, accordions and expandable content, and experiences tailored to your app.

Purchase-critical elements still rely on RevenueCat’s native components and checkout flows. But the canvas around them just became much bigger.

Here are two ways to put custom components to work.

Bring your purchase experience to life with animation

Motion can add personality, reinforce your brand, and guide attention toward the most important parts of a paywall or web-to-app funnel.

Custom components let you create animated backgrounds, icons, illustrations, and other visual treatments that go beyond static media. You can build animations directly with CSS or JavaScript, or use libraries such as Lottie and Rive by including them in your component bundle.

For example, you could:

• Add a subtle animated background behind your value proposition
• Bring benefit icons to life as customers explore an offer
• Use a looping illustration to demonstrate your app’s premium experience
• Add branded motion to connect the different steps of a web-to-app funnel

Animation doesn’t need to dominate the experience. Even small moments of movement can make a paywall or funnel feel more polished and connected to the rest of your brand.

Let customers expand the details they care about

Customers often have questions before subscribing, but putting every answer on the screen at once can make a purchase experience difficult to scan.

With HTML and JavaScript, you can create accordions and expandable sections that keep the initial experience focused while giving customers access to additional context.

You might use expandable content for:

• Frequently asked questions
• More information about individual benefits
• Explanations of how a feature works
• Details about what’s included with an upgrade
• Supporting information within a web-to-app onboarding journey

This creates a more layered experience. Customers can quickly understand the primary value proposition, then dig deeper when they need reassurance or clarification.

In a paywall, expandable content can keep the offer focused without hiding useful details. In a funnel, it can add depth to an onboarding screen without turning every step into a wall of text.

Build it with an agent or write it yourself

To get started, add a custom component in the RevenueCat Paywall or Funnel Editor and download the starter bundle. It includes an index.html entry point, a local preview, packaging tools, a getting-started guide, and instructions that coding agents can follow.

You can give the folder to your coding agent of choice and describe the experience you want.

Your coding agent can use the included instructions to build the component within RevenueCat’s requirements. If you prefer to work directly with the code, you can edit the HTML, CSS, and JavaScript yourself.

When the component is ready, preview it, package the files, and upload the resulting ZIP file. You can then place the custom component where you want it in your paywall or funnel.

Creativity, with guardrails

Custom components are self-contained and run inside the area they occupy in your paywall or funnel. They’re intended for decorative and supplementary experiences.

They shouldn’t contain interface elements required to complete a purchase. In Paywalls, packages and purchase buttons must remain native. In Funnels, custom components should complement RevenueCat’s native purchase controls and checkout flow.

Uploaded bundles must also follow RevenueCat’s security, file structure, and size requirements. For in-app paywalls, your app needs a supported RevenueCat SDK version to display custom components. Review the custom component requirements and minimum SDK versions before publishing.

Custom components open up a much broader creative canvas across RevenueCat Paywalls and web-to-app Funnels, from a single animated icon to an expandable experience that helps customers understand why they should upgrade.

Open the RevenueCat Dashboard and start building.

We can’t wait to see what you create.

Watch on YouTube

"About 90% of our traffic is actually going to our website, and we have a really long personalized quiz that we send all leads to," says Ethan Ethier, the company's Head of Growth and Operations. The quiz isn't a lead-capture gimmick — it does three jobs before a user ever sees a price. "It educates the user on the actual product, it overcomes objections, and it increases the perceived value of the product," Ethier explains. And the answers do real product work: they build the user's personalized training plan inside the app, so the funnel doubles as onboarding.

They didn't take the web-first approach on faith, either. The team ran traffic head-to-head, App Store versus quiz, and the quiz won on conversion — decisively enough that direct-to-store now only makes sense for the highest-intent users who already know what they want. One wrinkle worth noting: when they rebuilt the same quiz on Android, it converted on par with the web. It was only App Store traffic that lagged.

The influencer app that waited a year to run ads

There's a persistent myth that if you have millions of subscribers, your app markets itself. Built With Science was founded with YouTuber Jeremy Ethier — Ethan's brother — whose channel has over 7 million subscribers. The app still had to be grown the hard way.

The app launched in early January 2025. The first Meta ad didn't run until a full year later. "We wanted to double down on improving the product," Ethier says. "As long as we're constantly improving our trial-to-paid and retention, that lifts the floor for everything else." The logic: organic traffic converts at your ceiling, paid traffic converts below it, so buying traffic before the floor is fixed just buys expensive proof of the same problem. Once trial-to-paid, retention, and churn looked healthy, they scaled — and today organic converts at 35–40% trial-to-paid, with colder Meta traffic around 25%, at a premium $189/year price point.

Just as counterintuitive: Jeremy barely appears in the ads. "We're not relying on Jeremy at all for ads," Ethan says. The team wanted to solve what he calls the bus problem — everything depending on one person's YouTube channel — so the Meta program runs on B-roll, testimonials, and static creative. A channel that scales without the founder's face is a channel that actually scales.

The pricing page change that moved annual from 60% to 80%

The team's biggest win of the year didn't touch the price. Built With Science charges $189 a year or $30 a month, and the old pricing page showed both plans side by side. Roughly 60% of subscribers picked annual.

The winning variant showed only the annual plan upfront, paired with a day-by-day timeline of the free trial: day 1, you get your personalized plan; day 12, a reminder that your trial is about to end and you can cancel anytime. Monthly still exists behind a view-all-plans option. "We didn't change the price, we didn't change the positioning. It was simply a UI shift which had a massive impact for us," says Ethan. Annual take jumped to 75–80% — at nearly $190 a year, a substantial LTV shift from a layout change that mostly worked by shrinking the perceived risk of starting the trial.

The same page also produced their biggest fail: an experiment that added more context to clarify the value proposition actually hurt conversion. Their read — at the moment a user is motivated enough to be looking at prices, more information is friction, not reassurance.

A gym buddy plan that 15% of trial starts take

One of the more unusual pricing mechanics in the app came straight from user requests for a family plan. During the web quiz, users can add a "gym buddy" — a partner who joins at 15% off for both people.

Around 15% of everyone who starts a trial adds one. That lifts average order value on its own, but the quieter win is retention: gym-buddy subscribers stay on the app longer, the same dynamic family-plan apps see with their highest-retaining cohorts. And because the question lives in the quiz, the pricing page stays clean for solo users — no paywall clutter for an option most people won't take.

70% of their experiments fail. That's the system working.

"Probably 70% of the experiments that we run fail in the first go," Ethan says. "And that doesn't mean it's a failure... often we're iterating on these failures to uncover a winner."

The process behind that: be obsessed with the problem, not the solution. The team starts with funnel data in Amplitude, finds the biggest drop-off, lists every plausible problem with that step before discussing a single fix, locks in the most likely problem as a team, and only then brainstorms solutions. Everything gets documented — which is what turns failures into iterations. A no-trial toggle test (pay upfront, get 20% off) initially lost; the written record pointed to copy that framed the free trial as the losing option. A rerun that made both choices feel good is now showing a strong lift.

In the full episode, Ethan and David also get into Jeremy AI — the in-house chat coach one engineer built in a weekend that became a customer-favorite feature — quiet feature launches that keep engagement metrics honest, and how running their own in-app training studies feeds both the science and the marketing.

Guest links:

• Ethan Ethier on LinkedIn
• Built With Science
• Built with Science Careers

Week 1: The lecture hall was full. 400 eager students, all willing to give the subject (and the lecturer) a chance.

Then Week 2 arrived. The good intentions faded, and attendance dropped to maybe 300–350. Over the course of the term, that number would slowly whittle down to 200–250, depending on the lecturer and the topic. (Statistical modeling had a particularly brutal drop-off.)

But never did I turn up to Week 2 and find only 140 students left. A 65% drop-off in a single week.

Yet that's exactly what happens with weekly subscribers. By the first renewal, only 35–58% remain. That lecturer (your app) has to work far harder than any of mine ever did to get people back in the room. The first renewal isn't a billing event. It's the ultimate test of survival.

The first renewal drop-off in numbers

I’d love to say that monthly and annual subscriptions are less dramatic than weekly subscriptions, but they really aren't. Here’s the drop-off for first renewal by plan, from the State of Subscription Apps report 2026:

• Weekly subscriptions: 42–65%
• Monthly subscriptions: 39–58%
• Annual subscriptions: 60–77%

Ouch. Triple Ouch.

The durations differ, but the pattern is the same: the first renewal is where you lose the most subscribers.

The good news? Once someone gets past that point, the drop-off slows dramatically.

For weekly subscribers who make it to their second renewal, 74–91% will still be paying by their third. The same pattern applies to annual plans: get someone to year two, and they’re far more likely to stay for year three, and probably year four too.

So, how do you survive the survival test? And why is this one moment such a big deal? Here’s my theory.

You only have the activation window to convince subscribers to renew

Why didn't a user renew? Was your onboarding funnel not good enough? Urgh, it was that bug the app had last week, wasn't it?

Maybe, but those are often just symptoms. The real reason is usually that time-to-value wasn't reached within the activation window. Your app never truly became part of their life before the renewal moment.

Just like with trial lengths, different subscription durations give you different activation windows to prove your value. And no, the window isn't equal to your subscription length. I believe the most important activation periods are actually:

• Weekly: first five days
• Monthly: first two weeks
• Annual: first month

For weekly and monthly subscribers, the window closes when they start worrying about the next charge.

Annual subscriptions are different. With a whole year of runway, it feels like you have plenty of time… but you don’t. If someone hasn’t activated and experienced the value of your product by Month 3, once the embedding window closes, the odds of keeping them around drop significantly.

We see this when people actually cancel annual subscriptions:

23–50% of annual subscribers who cancel do so in the first month, with another 8–10% dropping off in Month 2. Some of those are the “I’m scared I’ll forget to cancel” group (I’ve definitely done that). But a lot of them are simply people who were never convinced. They never reached the point where the value of the app outweighed the cost.

This matters because winning that first renewal looks completely different, depending on which subscription duration the user signed up for. Let’s run through how to beat the first renewal curse for each plan length.

The weekly subscriber: fast-tracking a habit

Let’s cut to it: 42–65% of weekly subscribers are gone after one billing cycle. (Again, ouch.)

As mentioned, those first five days are what matter. Time to love bomb (you have my permission). This is the moment to go all in, no playing hard to get.

Day 0: love bombing and driving action

It starts on Day 0 with a strong onboarding experience. You want users to get some kind of win, progress, or sense of achievement in that first session. Don’t make them wait to feel valued.

The first renewal isn’t won at renewal. It’s won before they even convert, on that Day 0. We see this with 3-Day trials (often the trial length for weekly subscriptions, when there is one) where 84% of cancellations happen between Day 0 and Day 1.

Which means what you show someone immediately after they pay matters a lot. The moment they become a paying customer? Hit them with a strong post-purchase screen that reinforces the decision they just made, reminds them why they signed up, and gets them moving toward the next value moment.

For short subscriptions, I usually recommend focusing this moment on action: what is the one small, simple thing they can do right now? The goal isn’t to explain every feature. It’s to get them moving toward the value they signed up for.

Greg, a plant care app, does this well by inviting the user to log their plants:

Day 1–3: deepen the value

From there, Days 1–3 are about deepening the value. The user should experience the app’s core action, see a result, and start building a reason to come back.

And because the window is so short, you can (and should) be more aggressive with communication than you would be for monthly or annual subscriptions.

Day 4–7: fast-track the habit

Now you're trying to fast-track a habit. The data is pretty clear that real habits take longer than 7 days to form. But that's okay. You don't need a fully-formed habit yet. You just need the first signs of one: a return visit and the core action repeated enough times for the user to feel the value.

If you aren't sure what level of usage is ‘enough’, reverse engineer it from the subscribers who stay. What do they do in their first week? As you identify the behaviors that matter, segment users based on those actions and analyze both the frequency of the behavior and the percentage of users who complete it: that's how you find the leading indicators of renewal.

Throughout all of this, notifications and emails are your friend. The window is short, so don't be afraid to communicate more frequently. Just skip the generic reminder-style notifications. "Don't forget today's session" is really just another way of saying, "Please use my app." Make your messages value-oriented instead:

• Celebrate what they've done
• Show what they could achieve next
• Introduce features that will help them get there

Timing matters just as much as the message itself.

Duolingo tested sending re-engagement emails at different intervals and found that 23.5 hours after a user’s last lesson worked best: just before the same time the next day, when the habit would naturally repeat. And because Duolingo has streaks, they get to say, "Remember, you're on a 24-Day streak," instead of "Please come back."

For one client I worked with, we knew that completing a particular assessment (which includes human feedback — I know, revolutionary in this AI era) has a huge impact on both renewals and long-term retention. So our emails, push notifications, and even in-app messages all focus on getting new subscribers to complete that assessment as quickly as possible.

Once you know which behavior predicts retention, your job becomes much simpler: get more people to do that thing.

The monthly subscriber: 30 days to routine

The numbers are gentler for monthly subscribers, but you're still losing 39–58% at that first renewal.

The good news is that you have longer than a week this time. You don't need to force-feed a habit in seven days. But 30 days go by faster than you think, which means each stage of the month needs a job. Week 1 is about activation. The following weeks are about building familiarity, reinforcing value, and creating reasons to come back.

Alice Muir shared on the Sub Club podcast that lifecycle messaging in this period has the highest ROI. So if you run monthly subscriptions, this is where you can focus your efforts: building out the communication and the relationship with the user.

Days 1–7: get them to a meaningful outcome

Not a completed tutorial, not onboarding finished, not even a streak starter. What you're looking for is a clear value moment. Someone probably won't feel fitter after a single workout or dramatically calmer after a single meditation session. But if they've achieved something, you've celebrated that progress with them, and it felt easy enough to do again? That's the beginning of a habit.

Days 8–21: habit reinforcement

This is where most apps go silent. I use the phrase ‘love bombing’ far too often in my work with subscription apps, but it fits. Most apps love bomb users for the first seven days and then completely forget about them. Take a look at your CRM flows. How often are you actually communicating with users in Weeks 2 and 3? The frequency can taper, but it shouldn't fall off a cliff.

At this stage, the goal is simple: figure out where the user is in their journey and help them take the next step.

Let's go back to the workout app example:

1. The first flow gets them to Workout 1
2. The next flow gets them to Workout 2
3. After that, it's about building consistency

If someone hasn't opened the app in five days, that's a churn signal — so it’s time to follow up gently from different angles. They may not have found the right program, or there may be hesitations you can remove (equipment, time, or feedback they want to give).

A lot of this stage is about removing hesitations, concerns, and struggles.

Days 22–30: pre-renewal reinforcement

If they haven't canceled yet, this is when to reinforce the decision. Don't be the dark-UX company that hides the upcoming charge. Nothing churns someone harder than suddenly realizing they've been paying for something they forgot about. Your metrics might look better for a month, but in the long term, that's not growth.

Instead, think: positive reinforcement, progress reports, value summaries, and achievement highlights.

Loom does this well, showing how many meetings you've skipped and hours you've saved — things you could work out yourself, but probably never would.

I love it when a workout app tells me how many minutes I've trained or that I'm in the top 10% this month. Arbitrary numbers? Completely, but they make me feel like I've dedicated myself to something.

This means when the "Should I renew?" thought arrives, there’s already a positive feeling attached to the decision. Even better: once they've cleared that first renewal, that's your opening to suggest a longer plan, so they don't have to face this decision every single month.

Overall, monthly subscriptions need more touchpoints than weekly subscriptions, weighted toward the start, dwindling over time, but never stopping completely. Adjust to the user: if they're highly active, acknowledge it rather than pushing them to do more. If they're not, help them take action and figure out what's holding them back.

The annual subscriber: 90 days to embed

A startup recently reached out to me: great product usage, but a far bigger drop at the annual renewal than they expected. It wasn't the first time I'd heard this, and it won't be the last.

Annual renewals are deceptive. Cancellations spike a little in Month 1, taper off, and you start thinking: "All is well with the world, they love us, they're staying". Then the first wave of renewals arrives, and it's a nasty shock.

Here's the thing: starting to prevent that churn at Month 11 is way too late. In my experience, most renewal decisions are made in the first 90 days, with data suggesting that around 30% of annual subscribers cancel in the first month.

Annual subscribers paid a large sum upfront. That makes them more motivated than weekly or monthly subscribers, which is great, but it also means they have more to lose. The gap between expectation and reality is much bigger if your product disappoints. I always say this to people who want to charge more: that's fine, but be conscious that expectations rise with the price. The data backs this up: low-priced annual plans see first renewal rates around 36%, while high-priced ones manage just 23%.

A disappointed $10 subscriber shrugs, cancels, and moves on. A disappointed annual subscriber feels burned: they request refunds, they leave negative reviews. The stakes feel much higher because they made a bigger commitment upfront.

So focus on the first 90 days. That's where the biggest drop-off happens; where your biggest opportunity is. If an annual subscriber is still active after around 90 days, the chance they renew is dramatically higher.

One thing to keep in mind: if an annual subscriber cancels, reactivation rates are extremely low, averaging around 5%.

Month 1: activation is key

This looks similar to what we covered in the monthly renewal section:

• First value
• Core value
• Reinforce value

Months 2–3: keep showing up

This is where apps ghost their customers. They have flows and fancy setups for the first seven days, maybe 30, then it’s radio silence.

Instead, keep integrating into the user's life until using your app feels so natural they can’t imagine being without it: a workflow, a daily habit, a routine. Embedding is the goal. Airship found that apps sending relevant pushes in the first 90 days see retention around 3x higher than apps sending none.

Months 3–12: don't let it go stale

The first 90 days matter most, but there’s a later risk: the product starts feeling same-y. Maybe they've achieved their main job-to-be-done and want to be challenged differently.

I had this with Peloton: loved it for the first few months, and if you'd looked at my first 90 days, you'd have bet on me retaining it. But after a while, it felt like they weren't hearing me anymore, and I stopped making progress.

So keep check-ins going throughout the year: lower frequency, higher quality. Annual subscribers chose commitment; you don't need to convince them as heavily as monthly users. But you do need to show that the product is improving and its use case is still supported.

Personalized milestones are powerful here. I loved Ladder's recent summer update: extra flex workouts for while you're traveling, plus new programs I could switch to if I got bored with mine. It made me feel like they understood where I was as a customer and what I needed.

How to find your first renewal predictor

There is often a single early behavior (or a small set of behaviors), measurable in the first billing cycle, that predicts whether a subscriber makes it to renewal. This is your First Renewal Predictor (FRP).

Here's how to find it:

1. Map your renewal curve and find where it stabilizes: where does churn drop off dramatically? For most apps, that's around Renewal 2/3, which is what the benchmarks show across subscription types.
2. Compare early behaviors of survivors vs. churners: depending on plan type, look at Day 7, 14, or 30 behavior for subscribers who reached that stability point versus those who didn't.
3. Identify the actions that most differentiate them: that's your FRP.

For Duolingo, the 7-Day streak is a predictor: one week of consistent engagement means the chance of long-term retention jumps. A streak doesn't just mean 20 minutes a day for seven days, it means they engaged in some meaningful way each day.

What first renewal predictors are not

What FRPs are typically not: session counts, onboarding completion, and trial starts. Those are volume signals, and volume doesn't prove usefulness. I've had days when I opened and closed a recipe app five times just trying to figure out what to cook this week, without selecting a recipe in the end. One open with a recipe chosen would be a far better signal of success than five opens with no action

FRPs are quality signals:

• A specific core action completed X times (sometimes within a date range)
• Engagement with a feature that only high-LTV users touch
• A returning pattern (back on Day 3 and Day 7, not just a single visit)

When analyzing this I also look at the cohort size. It's great if someone meditates 20 times in Week 1, but if only a tiny percentage of users do that, it's not a realistic target. Depending on the engagement level overall, I look for what the top 10% are doing. Then break the core action down by frequency to find the level that balances predictive power with a cohort big enough to matter.

Finally, it’s worth noting your FRP may vary per subscription duration, and can be very similar (or the same) as your activation metric.

If you get activation right, the first renewal takes care of itself.

If first renewal predictors sound suspiciously like activation signals, you're not wrong. Most FRPs are activation metrics, measured from a different angle. With a weekly or monthly plan, you don't have time to build a full habit and relationship before the first renewal. The real work is activating the user and helping them experience the product's value. (Annual — and maybe quarterly — plans are the exception: there you have to go beyond activation and focus on embedding.)

So if you have a first renewal problem, don't go shopping for a retention solution. Review your activation window and fix the product experience within the first seven, 30, or 90 days, depending on your plan type. The renewal will follow.

This is also why win-back campaigns aimed at re-engaging first-renewal churned users convert so badly: those users never activated, so there's nothing to win them back to.

I really like how Alice Muir explains it in the State of Subscription Apps Report 2026:

"In a market where year-one retention is declining across all durations, the winning strategy is not gating harder or charging differently. It’s accelerating time-to-value before the first renewal decision."

Remember Greg, the plant care app? Their monthly retention sits at 21% after 12 months, well above the median. But the more interesting part is what happens next: churn nearly stops. They lose just 3% more subscribers over the following nine months. Survive the early renewals, and your subscribers don't just stay. They settle in.

The first renewal isn't actually where you win or lose, it's where you find out whether you already lost.

How to find your first renewal rate in RevenueCat

Get started reducing churn by checking your first renewal rate by plan type in your RevenueCat charts: if it's below your category's median, the gap is almost certainly in your activation window, not your paywall, pricing, or marketing.

Here’s a quick step-by-step to check your first renewal rate in RevenueCat. You can also ask Rico to pull the numbers directly for you.

1. Open Charts in the RevenueCat dashboard (left nav) and select the Subscription Retention chart
2. Set your date range with the range selector: this chart cohorts subscribers by their first purchase date, so pick a window old enough that the cohorts have had a chance to hit their first renewal (e.g. for monthly plans, cohorts at least ~1 month old; for annual, at least ~1 year old)
3. Segment by plan type: use the segment/breakdown control and choose Product (or Product duration) so each plan gets its own retention line
4. Read the Period 1 column/point: that's the share of each cohort that made their first renewal (aka, paid a second time). Period 2, 3, 4 etc. show subsequent renewals

Two things to watch:

• When you segment by a dimension other than the subscription start cohort, subscribers in a segment can have different start dates — and therefore different renewal opportunities. The chart only measures the portion of the cohort that has actually had the chance to renew in that period, so don't compare a period's rate against the full cohort size.
• Duration = period length: Period 1 means one billing cycle later (one month for monthly plans, one year for annual plans etc.). That's why segmenting by plan type is the right move — it keeps the comparison apples-to-apples.

For some stores, that's no longer the case.

Under changes required by the Epic v. Google ruling, approved third-party stores in the US can be installed from inside Google Play and can offer apps from Play’s own catalog. Aptoide Games is already enrolled, and more will likely follow.

In this guide, we'll cover what third-party Android stores are, how the program works, which stores to consider, and how to make that opt-out call on purpose.

What are third-party Android app stores?

Third-party Android app stores are app marketplaces that operate outside Google Play. Each one has its own catalog, its own search, and its own update mechanism.

The main ones operating in the US include:

• Amazon Appstore: Amazon's store for Fire tablets and Fire TV devices, with its own billing system.
• Samsung Galaxy Store: Preinstalled on every Samsung phone, with its own billing and subscription system.
• Epic Games Store: Epic's own storefront, and the company whose lawsuit against Google set this year's changes in motion.
• Aptoide: Portugal-based, with around 25 million monthly users, and the first store to appear inside Google Play in the US under this program.
• F-Droid: A catalog of open-source apps only, with no billing system at all.
• Outside the US: The list gets much longer, with ONE Store in South Korea, Xiaomi's GetApps, and dozens more.

The difference has always been in distribution. Google Play ships on nearly every Android device. Galaxy Store comes preinstalled on Samsung phones, and Amazon Appstore on Fire devices. Most other independent stores, however, faced the same two hurdles: users had to sideload them, and their catalogs had to be built from scratch.

The Play Catalog Access Program tackles these limitations.

The Play Catalog Access Program

The Play Catalog Access Program lets approved third-party stores in the US access Google Play's app catalog and offer those apps to users. Downloads still complete through Google Play, and Google's fee still applies.

This solves both problems we covered above: enrolled stores can be installed from inside Google Play, and they can offer apps from Play's catalog instead of building their own from scratch.

A few things to know about how it works:

• It comes from a court order. Google created the program to satisfy the permanent injunction in Epic v. Google. The injunction was entered in October 2024 and became effective on November 1, 2024, and the catalog-access provisions took effect on July 22, 2026.
• It won't last forever, at least not automatically. The court order's remedies run for three years from the November 1, 2024 effective date, which puts the end around November 1, 2027. Even though some pieces, like catalog access, only arrived in mid-2026.
• Enrollment is gated for app stores. They have to meet Google's security and policy requirements and pay $5,000 upfront, plus $5,000 a year.
• Google Play's full content policies don't apply. Stores set their own rules, subject to Google’s eligibility and safety requirements.

Installing a third-party store: before vs. now

Until July, getting an independent store onto a user's phone was a small act of determination.

The user went to a website, downloaded an APK, and Android did everything short of begging them to stop: a settings toggle, a warning screen, a blocked install.

The new system is supposed to make it as simple as installing any other app:

In practice, the first weeks were rockier. Rival stores were hard to find in Google Play's search, and installing one took extra steps. At an August 13 hearing, Judge James Donato ordered Google to fix this within a week, and Google agreed to make the changes by August 20.

What this means for developers

The Play Catalog Access Program doesn't require any code tweaks or affect what you pay Google. What matters is one page in Play Console, called Catalog Settings: since July 22, it's been sharing your listing with enrolled third-party stores by default.

In Play Console, go to Settings, then Catalog Settings. You'll see three options:

• Share all listings with all enrolled stores
• Manage per store
• Opt out

The first option is preselected, so unless someone on your team has changed it, sharing is already on. It doesn't add extra cost and increases visibility. The catch is that every enrolled store sets its own content policies. Google doesn't control what else gets listed there or how your app is displayed.

Whether that matters depends on your app.

If you have compliance obligations or an audience that needs extra protection (e.g., healthcare, finance, apps for kids), switch to the per-store option and vet each store before allowing it. Read its trust and safety policies, browse its catalog, and see how it presents apps like yours. Then, allow the ones that pass, skip the ones that don't, or opt out of the program entirely.

Where to go from here

The Catalog Access Program adds enrolled stores like Aptoide Games to that list, making reaching new users much more accessible.

A few other things to keep in mind:

• Aptoide Games is the only enrolled store visible so far, so revisit your choice as more stores join.
• Your fees and billing stay the same no matter what you pick. Google's other programs, like alternative billing (letting users pay through a non-Google payment system) and external offers (linking users out to buy on your website), are a separate decision.
• Existing Amazon Appstore integrations on Fire devices and Galaxy Store integrations aren't affected, so there’s nothing to change there. If you distribute through Amazon Appstore or Galaxy Store, and don't want to manage each store's billing yourself, RevenueCat's SDK supports both.

For those who weren’t online yet: in 2020, Quibi bet that people would watch premium stories made for their phones, delivered in episodes of ten minutes or less. It raised an eye-watering $1.75 billion and was shuttered less than a year after going live. And with that, short-form video for mobile died and was never seen or heard from again. Or did it?

Today’s short-drama apps were built for how people actually use phones: upright, in short bursts, and often one cliffhanger away from paying. They combine serialized stories, aggressive paid acquisition, and monetization that begins almost immediately. This time, the numbers look a little different

China got there first

Quibi approached mobile video from the top down. It brought Hollywood budgets, stars, production practices, and a conventional streaming subscription to a smaller screen. The episodes were shorter, but much of the machinery still came from television

Short drama as we see it in the app stores today developed in China. Its immediate roots lie in the serialized shorts that spread across platforms such as Douyin and Kuaishou in the late 2010s. Chinese regulators formally recognized micro-short drama as a distinct format in 2020, and the market accelerated during the pandemic. It originates in an ecosystem where vertical video, web fiction, mobile payments, performance marketing, and fast, inexpensive production were already the norm

The stories were built differently too. Chinese web fiction had spent years refining plots around base human desires and conflicts: romance, revenge, sudden wealth, family betrayal, hidden identities, and dramatic reversals. Short drama translated that rhythm into video. Every episode had a job: establish the stakes quickly, resolve just enough, and create the next reason to keep watching

The business model developed alongside the format. Viewers could sample a story for free, pay to unlock the next episodes, watch ads to earn access, or subscribe. Distribution often started with a dramatic clip on a social platform and ended inside a mini-program or dedicated app. The same story attracted the viewer, kept them watching, and eventually asked them to pay

By June 2024, China had 576 million micro-drama viewers (more than half of the country’s internet users!) according to the China Internet Network Information Center. China’s domestic micro-drama market reached roughly RMB 50 billion that year, overtaking the country’s cinema box office for the first time

This was already a mass-market business before most Western entertainment executives had heard of ReelShort or DramaBox. Omdia estimates that microdramas generated roughly $11 billion worldwide in 2025, with China accounting for about 83% of the total

What travelled overseas was more than the shows themselves. Apps such as ReelShort began producing local stories with English-speaking actors and familiar settings while keeping the rapid pacing, performance marketing, and payment mechanics that had already been tested in China

ReelShort founder Joey Jia told TIME that the company can take a story from idea to live in front of an audience in roughly three months, see exactly where viewers stop watching, and rebuild a failed concept with different characters. That feedback loop is hard to reproduce when a traditional production takes years and most of its budget is committed before the audience sees a frame

This is no longer contained to China

Based on Appfigures data, we analyzed over 5,000 of the highest grossing non-game Entertainment apps, and found roughly 360 short-drama apps in the listing (around 6.5% of all apps in the category). Together, they generated about 145 million estimated downloads and $230 million in estimated store revenue in the latest 30 days

When we look at download numbers, it becomes clear that something’s happening. At just 6.5% of the Entertainment listings, short-dramas generated 38% of downloads and 13% of store revenue. Its share of downloads was nearly six times larger than its share of apps

Like most categories, short-drama is top-heavy. The ten largest apps generated roughly 78% of the group’s estimated store revenue. At the other end, the long tail represented about 70% of apps, attracted 23% of downloads, but only 1.5% of revenue

Small apps can still attract installs. Turning those installs into substantial store revenue is much harder

The two app stores also play very different roles. Android produced 76% of estimated downloads, while iOS produced 58% of store revenue. Android is where these apps find much of their reach; iOS is where much of the direct revenue is generated, though this explicitly ignores ad revenue. A relevant distinction to make, because over ⅔ of short-drama apps include ad monetization, compared to 37% of the overall Entertainment category

What happens after the download

The download is just the start. What matters next is whether that new user pays

We compared the short-drama apps in RevenueCat’s data with the broader Entertainment category. The short version: short drama gets people to pay much (much) faster than traditional Entertainment apps do

For the median short-drama app, 5.5% of installs became paying customers within 35 days. The median for other Entertainment apps was 1.6%

The same advantage appears in early revenue. Short-drama apps generated a median of $0.83 per install in the first 14 days, compared with $0.15 for other Entertainment apps. First-month realized revenue per paying customer was $23.85, versus $13.09

That’s not (just) a matter of a better paywall. Short-drama apps design the ad, episode, price, and payment moment together to form a cohesive, compelling journey

A typical ad does not introduce the brand and ask viewers to remember it. It drops them into a betrayal, a wedding, an inheritance, or a billionaire-shaped problem. The viewer watches long enough to need the resolution, installs the app, gets several episodes free, and reaches a highly personalized paywall at the moment of maximum curiosity

At MIP London, executives told the Associated Press that some of the largest microdrama platforms spend as much as 90% of their budgets on marketing. That sounds extreme through a television lens. It makes more sense in the world of mobile attribution where each piece of creative can be tied to an install, an episode, a payment, and eventually a renewal

This looks more like a mobile game than Netflix

Short-drama apps do not rely on a single monthly subscription. They borrow freely from mobile games: virtual coins, consumable purchases, rewarded ads, limited-time offers, and short subscription periods all sit next to one another

That mixed model is visible in the Appfigures data. Store metadata showed in-app purchases on 93% of short-drama listings, subscriptions on 86%, and advertising on 67%. More than half showed all three, and those apps generated roughly 93% of the short-drama store revenue in our sample

It’s a great example of how apps use mixed monetization to ‘drop the floor’ (make it possible for the masses to generate a little revenue) and ‘raise the ceiling’ (allow highly engaged users to pay again and again)

Our own data shows just how strongly the subscription side is built around urgency. For the median short-drama app, weekly plans accounted for 88.5% of recurring revenue, compared with 14.3% for other Entertainment apps. The most common weekly price was $9.99 - about twice the $4.99 that the rest of Entertainment usually charges

In this case, weekly pricing fits. A viewer can discover a series, binge dozens of minute-long episodes, and make a relatively expensive purchase in a single session while also actually experiencing the full value in that same session. The app does not need to convince that person it deserves a permanent place alongside Netflix. It needs to make the next episode feel worth paying for now

Then comes renewal

The first payment comes quickly. The second is harder

The median first-renewal rate for short-drama apps was 31.1%, compared with 44.3% for other Entertainment apps. In the smaller group for which we could measure six-month retention, the gap was wider: 1.8% for short drama versus 8% for the rest of Entertainment

The model works brilliantly in the moment. In our data, it is much less effective once that moment has passed. These numbers do not tell us whether that comes from story completion, weekly pricing, acquisition mix, or something else - but they make the trade-off difficult to ignore

The opportunity is fairly obvious: bring short drama’s mobile speed together with the libraries, franchises, and subscriber relationships traditional media already knows how to build

The rest of streaming is paying attention

Traditional media has moved from watching this category to investing in it

In the US, Omdia found that ReelShort users spent an average of 35.7 minutes per day in the app in late 2025, compared with 24.8 minutes for Netflix on mobile. ReelShort’s audience was much smaller, but those viewers spent considerably longer in the app each day

The industry moves are becoming concrete. Disney selected DramaBox for its 2025 Accelerator program. Fox took an equity stake in Holywater, the company behind My Drama, and committed to producing more than 200 vertical titles over two years. Peacock has launched a dedicated microdrama hub, TelevisaUnivision is producing vertical series for ViX, while TikTok is now testing a standalone app called LimeShorts, designed specifically for short vertical series

Not everyone needs to copy these billion dollar investments, or start cropping every show into portrait mode. The lessons that are up for grabs for anyone are on how tightly short-drama companies connect marketing, viewing, payment, and production. They can see which ad brought someone in, where that viewer stopped, what persuaded them to pay, and whether they returned

The weak point is retention. Established media companies already have the libraries, franchises, and programming experience that could help solve it

Quibi may have been early, but timing was not the only difference. The companies that followed rebuilt the idea around the phone - and found a business model that worked

Let us help!

Building a vertical-video product or rethinking mobile growth? Come talk to RevenueCat at IBC 2026 in Amsterdam this September!

A detailed walkthrough of the five Devpost steps, what to prepare, and how to make sure your app gets judged

Your app is built, RevenueCat is integrated, and the store review is behind you.

There’s one job left: submitting it to Shipaton. Or maybe you’re not yet there, since there are still days left to submit. No matter what the case, you should start looking at how to submit your app to Shipaton at this point.

Shipaton submissions are sent through Devpost. The submission form has five sections: Manage team, Project overview, Project details, Additional info, and Submit. Here’s how to get through each step without a headache.

The submission deadline is Sep 30, 2026 at 11:45 pm PDT. You can save a draft and edit a submitted project until the deadline, but don’t leave the final click until the final minute.

First, make sure your app is eligible

For the main Shipaton competition (all other categories than Next Gen), your app must:

• Be an iOS, iPadOS, macOS, or Android app; web apps are not eligible.
• Use the RevenueCat SDK to power at least one in-app or web purchase, or serve ads through RevenueCat Ads.
• Be a new app whose first public version was released during the Shipaton submission window.
• Be fully published on the Apple App Store, Google Play Store, Mac App Store, or Samsung Galaxy Store.
• Work as shown in your submission video and description.
• Be available to download in the United States.

Apps released before Shipaton don’t qualify, and moving an existing app to another store doesn’t make it new. An existing web app can qualify if your Shipaton submission is an iOS, iPadOS, macOS, or Android version of that app that users can download from the mentioned App Stores.

TestFlight or testing-track builds don’t count. Shipaton needs a live store listing, and app review can take days, so don’t leave it until deadline week.

Students entering the Next Gen Award get an exception: they can submit a demo video and public open-source repository instead of a store listing. You can enter both the Next Gen Award and any of the other categories by providing a public open-source repository, demo video, and an app store link.

Prepare these materials for your submission

Get these assets ready for your submission. All of them are required, and missing any of them will make your app not eligible for judging:

• Your project name and a short tagline.
• A description of the app and its main features.
• A public App Store, Google Play, Mac App Store, or Galaxy Store URL.
• A public YouTube or Vimeo demo video.
• A 1024 × 1024 app icon.
• RevenueCat project ID
• At least one 1179 × 2556 app screenshot without a device frame.
• A free trial or promo code that lets judges test all premium features.
• Any category-specific links, IDs, metrics, or explanations.

Some sponsor categories might have extra requirements; see official rules for requirements on those. Everything you submit needs to be in English.

Filling the Devpost submission

Register for Shipaton, start a project, and save it as a draft. Devpost splits the submission into five steps.

Step 1: Manage your team

Start by adding everyone who worked on the app.

Solo project? You’re done here. For a team project, invite people with the email tied to their Devpost account or send them Devpost’s private invitation link. Add everyone before the deadline.

Step 2: Complete the project overview

The project overview is the card people will see in the Devpost gallery. It asks for:

• Project name: Use the same recognizable name as your store listing.
• Tagline: Explain what the app does in one short sentence.
• Thumbnail: Upload a clean image that remains readable at a small size. Devpost recommends a 3:2 image in JPG, PNG, or GIF format.

Here's my tip on how to do this well: skip taglines like “An AI-powered productivity platform.” Say what the product actually does: “Practice difficult conversations before having them with your team.”

Step 3: Tell your project’s story

Project details are the core of the submission: what you built, why it matters, and a working demo. Devpost’s submission guide divides this into the project story, technology tags, links, images, and demo video. Let’s go through each part in detail:

Write a description judges can scan

Answer the basics first:

1. What problem does it solve?
2. Who is it for?
3. What does it let them do?
4. How does it make money?
5. What makes it interesting or different?
6. Which award categories are you targeting?

Add the build story: what was hard, what you learned, and what comes next. Break it up with headings and short paragraphs. You can use AI to correct spelling and formatting, but don’t let AI write your whole description. No one will like reading that.

Include the proof each category asks for. Make the job for judges easier by explaining why your app qualifies for selected categories, and what makes it stand out.

Add your technology tags

Tag RevenueCat and the main tools you used. Devpost allows up to 25 tags. If you’re entering a sponsor category, tag that product too: Kotlin Multiplatform, Replit, OneSignal, Layers, Stripe, or whichever one applies.

These are mainly used for explaining your project; they don’t affect judging.

Add the public app link

For a standard entry, link to the fully published app on:

• Apple’s App Store or Mac App Store.
• Google Play.
• Samsung Galaxy Store.

Test the store link in a private browser window. The app needs to be downloadable in the US.

The store-link exception applies only to Next Gen. In any other case, you need to have a store link in your submission to be considered eligible.

Upload your images

For Shipaton, that means:

• A 1024 × 1024 app icon.
• At least one screenshot at 1179 × 2556.
• Screenshots without device frames.

Pick screenshots that tell the story. Five near-identical screens won’t help; a good set should show the core experience, the monetization, and the product’s strongest visual details. If you end up winning we will use the app icon and one of the screenshots in the marketing materials.

Add your demo video

Upload the video to YouTube or Vimeo. Unlisted YouTube videos are fine; private ones won’t be viewable by the judges, so don’t do that.

Keep the essential demo under two minutes, as judges aren’t required to watch beyond the 2 minutes. Show the app running on the device it was built for, and highlight the most important features and aspects of your app.

In the first two minutes, cover:

• Your app’s elevator pitch.
• The app’s core experience in use.
• Its purchase, subscription, web-payment, or advertising experience.
• The prize categories you are targeting and why the app fits them.

Don’t spend the week making a trailer for your app or game. A clear screen recording with concise narration beats a long intro or elaborate title sequence.

As explained in How we judge Shipaton, judges make most of their decisions from the description, video, and screenshots. Lead with the stuff that makes your app stand out, and mention which categories you are targeting.

If you haven’t made one before, keep it simple: record the screen, add a clear voice-over, and tell one coherent story. Our guide to storytelling can help you structure the pitch. Avoid copyrighted music, third-party trademarks, and other protected material unless you have permission to use them. For the influencer categories, do not use the likeness or brand of the influencers.

Step 4: Choose your categories and complete the additional information

Additional info holds the Shipaton-specific fields: media, store links, your RevenueCat project ID, and any promo code judges need for premium features.

You can enter several compatible categories, but don’t tick boxes for the sake of it. Each one may need its own explanation, link, account ID, or proof.

The official Shipaton rules contain the complete category requirements and judging criteria.

RevenueCat awards

• Grand Prize: Share what happened after launch, using the numbers that best make your case: downloads, revenue, active users, paid customers, conversion, retention, or something else.
• HAMM Award: Explain the business model, pricing, paywall, conversion, and revenue, including what you changed or learned.
• Catvertising Award: Show where RevenueCat Ads appear, why those placements fit the experience, and how ads work alongside other revenue.
• RevenueCat Design Award: For exceptional craft, interaction design and animation. Point judges to the details worth noticing.
• RevenueCat Peace Prize: For apps with a positive impact on people, communities or society. Be specific about who benefits and what changes for them.
• Best Game Award: For the strongest mobile game. Cover the gameplay loop, progression or replayability, art direction and why the monetization belongs.
• #BuildInPublic Award: For the best public build story. Link to your posts and show how feedback, accountability or the community changed the app.
• Next Gen Award: For qualifying student projects. Use an academic email and submit a demo plus a public repository with code, setup instructions and a visible open-source license.
• Conflict of Interest Award: Only for eligible RevenueCat and sponsor employees.

All eligible projects can be considered for the Grand Prize, but you still need to show what happened after launch. Revenue made by the app is used for the shortlist, but it does not decide the winner. Making the most money will not automatically make you the winner of the Grand Prize award.

Influencer Awards

The five briefs are:

• Productivity — Christopher Lawley: A focused tool for Apple power users to save and retrieve reusable text, documents, files, and images.
• Nutrition and Healthy Eating — Abbey’s Kitchen: A flexible nutrition app inspired by the Hunger Crushing Combo framework, without calorie counting or restrictive meal plans.
• Yoga and Fitness — Simone Sharice: A personalized companion that turns movement, Pilates, recovery, and wellness needs into a clear daily plan.
• Career Coaching — Leadership Heather: A practice environment for new managers preparing for difficult workplace conversations.
• Gaming — Mr Lewis Blogs Gaming: A gaming bucket-list app for saving, organizing, completing, rating, and sharing games.

You can enter one Influencer Award per project and still enter other eligible categories. State which brief you chose and how the app fits that audience in the Devpost submission.

Building for an influencer’s audience doesn’t give you permission to use their name, image, voice, logo or likeness. Get express written consent before using any of it in the product, store listing or marketing.

Sponsor awards

• Ship Kotlin Everywhere — JetBrains: Publish for both iOS and Android using Kotlin Multiplatform, Compose Multiplatform, or both. Include both store links and explain the implementation.
• Most Viral App — Noise: Use Noise to promote the live app during Shipaton. Include the app URL and the email associated with your Noise account.
• Best App for Galaxy — Samsung: Publish on the Galaxy Store and explain Galaxy-specific work such as foldable support, Samsung features, or device optimization.
• Idea to Income — Replit: Build and publish using Replit and RevenueCat through Replit Agent. Include at least three public build posts, the Replit preview URL, username, and an explanation of Replit’s role.
• Keep Them Coming Back — OneSignal: Integrate OneSignal and deploy at least one campaign. Include the OneSignal App ID and describe the messaging experience.
• The Growth Loop Award — Layers: Install the Layers SDK and describe the audience, hypothesis, experiment, observed signal, lessons, and next step.
• Funnel Vision Award — Stripe: Launch a live web-to-app funnel using RevenueCat Funnels with Stripe. Include the funnel URL and Stripe Project ID.

Only enter a sponsor category once the integration works, and you have every requested detail. A technology tag on its own won’t qualify.

Step 5: Review and submit

The last screen is a short rules-and-terms confirmation.

Before you press Submit project, check:

• Is the store link live and available in the US?
• Does the app install and behave like the version in your video?
• Is the video public, and is the essential footage under two minutes?
• Have you uploaded the correctly sized icon and screenshot?
• Can judges access premium functionality through a free trial or promo code?
• Have you answered the additional questions for every selected category?
• Are your teammate details correct?
• Are your written materials and testing instructions in English, or accompanied by an English translation?

After submitting, click View and inspect the public entry. Check the formatting, embedded video, gallery, links, and category answers.

You’re only done when Devpost shows Submitted and 5/5 steps done. A saved draft doesn’t count.

You can still edit after submitting

Submitting early doesn’t lock the entry. You can make changes until the deadline. After that, edits to your Devpost portfolio won’t change the version entered into Shipaton.

That extra time is useful for:

• Catch private or broken video links.
• Fix missing fields.
• Improve your description.
• Replace weak screenshots.
• Add post-launch growth results.
• Confirm that the store listing and promo code work.

You can submit more than one app, but each entry must be unique and substantially different. When yours is ready, submit it and click View for one last look at the public entry.

Frequently asked questions

Still unsure whether your app qualifies? Here are the answers to some of the most common submission questions. See also our frequently asked questions section on shipaton.com if your questions are not answered here.

Can I submit more than one app?

Yes. Each app must be a separate, eligible project whose first store release happens during the Shipaton window, from August 1 to September 30, 2026.

Does releasing an existing app on a second store count as a new launch?

No. If the app was already available in one app store before August 1, releasing it in another store during Shipaton does not make it a new app.

There is an exception for web apps. A project that previously existed only on the web can qualify if its first native app-store release happens during the Shipaton window.

What if my app is still waiting for store review at the deadline?

It will not qualify. Judges need to be able to download the published app from a supported store.

Store review can take several business days—and longer if the build is rejected—so RevenueCat recommends submitting it for review at least one week before the Shipaton deadline.

Can I participate without an Apple or Google developer account?

Possibly, through the Next Gen Award. Eligible students can submit a demo and public open-source repository instead of publishing the app to a store.

You will need a verifiable academic email address from a school, university, bootcamp, or another academic program. Standard Shipaton categories still require a published app and working RevenueCat integration.

Can I enter the Next Gen Award and another category?

Yes, provided you meet both sets of requirements. That means submitting the code required for Next Gen and publishing the app to a supported store for the other category.

The store release is not considered when judging the Next Gen Award itself.

Does every submission need to use RevenueCat?

Yes. Standard entries must use the RevenueCat SDK for purchases, subscriptions, or RevenueCat Ads.

Is there a limit to the number of teammates?

No. Your team can have any number of members. However, if an eligible prize includes travel to New York, RevenueCat will fly one team member.

In this article, you'll dive deep into how the RevenueCat Android SDK renders server driven paywalls as native Compose UI, comparing to the WebView screen and what it defers, the two level offerings cache and asset pre-download, the three stage pipeline from wire format to render model, how unknown input and misconfiguration get absorbed by different mechanisms, the facts only the device can resolve, and the cost of holding every platform to the same JSON.

The fundamental problem: The server can send what your binary does not know

There are broadly two ways to render a screen defined somewhere else. You can ship a runtime that resolves an open-ended instruction set at display time, or you can ship a renderer that understands a closed set of types fixed at compile time. A third option exists, shipping executable code from the server and running it against native widgets, but it trades the schema problem for a second runtime inside your APK and a longer conversation with store policy, so set it aside.

The first option has a ready-made implementation on every Android device. HTML is the instruction set, the browser engine resolves it, and WebView is the host. A paywall becomes a URL. When the design team invents a new layout, they write new markup, the server serves it, and an app that shipped two years ago renders it without ever having been taught what a carousel is.

The second option is what you get when you want native views. You define a schema, you write a renderer for each shape in it, and both live inside your binary. Consider the smallest possible version of that schema:

sealed interface PaywallComponent {
    data class Text(val text: String) : PaywallComponent
    data class Image(val url: String) : PaywallComponent
    data class Stack(val children: List<PaywallComponent>) : PaywallComponent
}

Three shapes, a recursive tree, and a renderer that walks it. This works, and it keeps working right up until the dashboard learns to emit a fourth shape. Now the server sends this to a binary compiled against the three shape schema:

{
  "type": "carousel",
  "pages": [ { "type": "text", "text": "Unlimited access" } ]
}

Your deserializer has three options if it has to decide alone, and all of them are bad. It can throw, which fails the whole paywall and shows the user nothing on the screen your revenue depends on. It can skip the unknown node, which leaves a hole in the middle of a layout that was designed around it, so the user sees a headline, empty space, and a purchase button with no explanation of what they are buying. Or it can guess, which is worse than either.

Notice what makes this asymmetric. The problem is not rendering. Drawing a carousel in Compose is a solved problem. The problem is that a native renderer knows a closed set of types while the server can emit an open one, and the gap between the two widens every time you ship a dashboard feature, because users update their apps on their own schedule and some of them never will.

This is the actual decision behind native versus WebView paywalls, and it is not settled by a benchmark or a visual audit. Both of those follow from a prior question: where do you put the uncertainty about what the server might send? Inside a runtime you did not write and do not version, or inside a schema boundary you design deliberately?

The shortcut and what it defers: Hosting a page versus owning a tree

Before looking at how RevenueCat's SDK answers that question, it is worth accounting for what the WebView approach actually costs, because it genuinely does solve forward compatibility.

A WebView hosted paywall makes the SDK's job small. Its responsibilities reduce to roughly this shape:

webView.loadUrl(paywallUrl)
webView.addJavascriptInterface(bridge, "native")

The page owns layout, typography, animation, and state. The bridge carries a handful of messages in both directions: the page tells native that the user tapped a product, native tells the page that the purchase succeeded. Everything visual is HTML and CSS, so the design team iterates without touching Kotlin and without a schema negotiation.

What that architecture defers, rather than solves, is everything that depends on the paywall being present, fast, and native.

The paywall becomes a network resource. Before a single pixel can paint, the page has to be fetched. You can pre-warm a WebView to hide this, and well built implementations do, but pre-warming a WebView means keeping a renderer process alive on the speculative chance that the user will see a paywall. You are pre-warming a process. Pre-warming bytes on disk is a different proposition, and the next section is about what that difference buys.

Caching the page yourself is possible, and more possible than it first looks. shouldInterceptRequest lets you serve every request from storage you control, and a service worker gives you explicit eviction and validation. What you cannot do is skip the work. You now maintain a second asset pipeline, its correctness, and its invalidation logic, in a language and a runtime separate from the app hosting it.

The layout engine is not yours to pin. Android System WebView updates independently of your app, through the Play Store, on a schedule set by the user's device, and devices without Play Services, with updates disabled, or on older Chromium builds form a version matrix nobody controls. A CSS rule that lays out correctly during QA can lay out differently on a device that updated its WebView provider last week. Compose does not remove platform variation, since text shaping still comes from StaticLayout and HarfBuzz, but the measure and layout code ships inside your APK, so the box model does not move under you. That is a much narrower moving target than an entire layout engine.

The page's content also sits outside Compose's reasoning. Compose can skip the AndroidView wrapper when its parameters are stable, and the hosted view does report a measured size, but Compose cannot reason about anything inside the document. The page's content height is only known after the document lays out, which happens after Compose has already measured. So a WebView inside a Compose column either gets a height you hardcode or a height that arrives over the bridge one frame late, and nested scrolling between the page's scroll container and a Compose parent becomes a coordination problem rather than a feature.

Finally, the seam between the page and the purchase is untyped. A tap crosses a postMessage boundary as a string, and nothing checks that identifier against your real product catalog until the user presses the button. As you'll see later, the native path checks the same mapping, just before the paywall renders rather than on the tap.

None of this makes the WebView approach a mistake. It makes it a set of deferred payments. The rest of this article walks through what paying them up front looks like in code.

Nothing to fetch when the paywall opens: Two-level caching and asset predownload

Start with the property that is easiest to verify and hardest to retrofit. After the first successful offerings fetch, presenting the current offering's paywall no longer depends on the network. The component tree, the fonts, and the images are already on the device.

Offerings, which carry the paywall definitions, are cached at two levels. If you examine OfferingsCache:

internal class OfferingsCache(
    private val deviceCache: DeviceCache,
    private val dateProvider: DateProvider = DefaultDateProvider(),
    private val offeringsCachedObject: InMemoryCachedObject<Offerings> = InMemoryCachedObject(
        dateProvider = dateProvider,
    ),
    private val localeProvider: LocaleProvider,
)

There is an in-memory layer, offeringsCachedObject, for the warm path within a process, and a disk layer behind deviceCache that survives process death. Writing goes to both:

@Synchronized
fun cacheOfferings(offerings: Offerings, offeringsResponse: JSONObject) {
    offeringsCachedObject.cacheInstance(offerings)
    deviceCache.cacheOfferingsResponse(offeringsResponse)
    offeringsCachedObject.updateCacheTimestamp(dateProvider.now)
    cachedLanguageTags = String(localeProvider.currentLocalesLanguageTags.toCharArray())
}

The raw response JSON is persisted, not just the parsed object graph, which means the disk copy can go back through the same parsing path as a fresh network body rather than needing its own deserialization format.

Look at the last line. The cache records which language tags were active when it was populated, and staleness checks both time and locale:

@Synchronized
fun isOfferingsCacheStale(appInBackground: Boolean): Boolean =
    offeringsCachedObject.lastUpdatedAt.isCacheStale(appInBackground, dateProvider) ||
        cachedLanguageTags != localeProvider.currentLocalesLanguageTags

A user who changes their system language gets a refetch even if the cache is chronologically fresh. This is the kind of invalidation rule you only write when the cached payload is locale dependent, and it is the first hint of a theme that runs through the whole architecture: the device is a participant in rendering, not just a display surface.

The disk copy is a failure path rather than a startup path. On a cold start the in memory cache is empty, so the SDK does attempt a network fetch, and what matters is what happens when that fetch fails:

GetOfferingsErrorHandlingBehavior.SHOULD_FALLBACK_TO_CACHED_OFFERINGS -> {
    val cachedOfferingsResponse = offeringsCache.cachedOfferingsResponse
    if (cachedOfferingsResponse == null) {
        handleErrorFetchingOfferings(backendError, onError)
    } else {
        warnLog { OfferingStrings.ERROR_FETCHING_OFFERINGS_USING_DISK_CACHE }
        createAndCacheOfferings(
            offeringsJSON = cachedOfferingsResponse,
            loadedFromDiskCache = true,
            ...
        )
    }
}

Because the disk entry is a complete offerings response, it flows through exactly the same createAndCacheOfferings path as a network body, with loadedFromDiskCache as the only difference the rest of the pipeline sees. A user who opens the app on a plane gets last week's paywall instead of an error screen, so after the first successful fetch no connectivity failure leaves them with no paywall.

Caching the tree is only half of it. A component tree full of remote font and image URLs still paints late if those URLs are fetched when the paywall opens. So the SDK fetches them when offerings are fetched, which is typically during SDK configuration at app launch. Looking at where OfferingsManager handles a successful offerings response:

onSuccess = { offeringsResultData ->
    offeringsResultData.offerings.current?.let {
        offeringImagePreDownloader.preDownloadOfferingImages(it)
    }
    offeringFontPreDownloader.preDownloadOfferingFontsIfNeeded(offeringsResultData.offerings)
    offeringsCache.cacheOfferings(offeringsResultData.offerings, offeringsJSON)
    ...
}

Images and fonts start downloading before the offerings are handed back to the caller. Two limits are visible in those four lines and worth stating rather than glossing: images are predownloaded for offerings.current only, so a paywall on a non-current offering does not get them, and fonts are read from the first offering that has paywall components on the assumption that all offerings share a font set. Both downloads are also asynchronous, so a user who reaches a paywall within the first second of a fresh install can still outrun them.

Fonts are where the distance between native and web is greatest. On the web, a custom font is a single @font-face declaration and the browser handles fetching, caching, validation, and fallback. Android does have downloadable fonts through FontsContractCompat, but that resolves a font name against a provider's catalog. An arbitrary file that a customer uploaded to their own bucket has no platform support at all, and FontLoader is 235 lines of the work the browser was doing for free.

Those 235 lines buy something the section title has been promising: the font file is on disk before the paywall opens, so the first frame draws in the right typeface. Font resolution happens once, before composition, which means no font swap and no flash of invisible text. It also means the guarantee is one directional. A font that is not in the index when the paywall state is built resolves to the system font for the entire life of that presentation, so a missed predownload is not a late swap, it is a paywall rendered in the wrong typeface until the user closes it and opens it again.

The predownloader starts by filtering out fonts it does not need to fetch at all:

private fun isBundled(info: FontInfo.Name): Boolean {
    if (info.value.isEmpty()) return false
    return when (info.value) {
        in genericFonts -> true
        else -> context.getResourceIdentifier(info.value, "font") != 0 ||
            context.getAssetFontPath(info.value) != null
    }
}

The dashboard can reference a font by name, and the device checks whether that name resolves to a font already bundled in the app's resources or assets before downloading anything. A server could only know this if every app reported its bundled font names on every build.

For fonts that do need downloading, the loader keys its cache by a hash of the URL, so a file referenced by more than one font alias is fetched once and later requests attach themselves to the in flight download as listeners. The download itself verifies integrity and commits atomically:

val tempFile = File.createTempFile("rc_paywall_font_download_", ".$extension", cacheDir)
urlConnectionFactory.downloadToFile(url, tempFile, description = "paywall font")

val actualMd5 = md5Hex(tempFile.readBytes())
if (!actualMd5.equals(expectedMd5, ignoreCase = true)) {
    tempFile.delete()
    return Result.failure(IOException("Downloaded font file is corrupt for $url"))
}

if (!tempFile.renameTo(cachedFile)) {
    tempFile.copyTo(cachedFile, overwrite = true)
    tempFile.delete()
}

The file downloads to a temporary name, gets checked against an expected MD5 the server supplied alongside the URL, and only then moves into place. A truncated download never becomes a cache entry, so a partially written font file cannot poison the cache and produce garbled text on every subsequent launch.

There is one more recovery path that only shows up in production. Android can reclaim cacheDir at any time, so a cache entry can point at a file that no longer exists:

if (cachedFontFamily != null) {
    if (cachedFontFamily.fonts.all { it.file.exists() }) {
        return cachedFontFamily
    }
    warnLog { "Cached font files missing for ${cachedFontFamily.family}, re-downloading" }
    ...
}

The in-memory index is checked against the filesystem before being trusted, and a family whose files have been evicted is dropped and refetched rather than handed to Compose as a set of dangling File references.

The three-stage pipeline: Tolerant, then validated, then rendered

With assets local, the remaining question is how the JSON becomes Compose UI. The SDK does this in three distinct stages, and the separation is what makes everything after it possible.

The first stage is deserialization into a data model that mirrors the wire format closely and validates almost nothing. PaywallComponentsData is the root:

public class PaywallComponentsData(
    @SerialName("template_name") public val templateName: String,
    @SerialName("asset_base_url") public val assetBaseURL: URL,
    @SerialName("components_config") public val componentsConfig: ComponentsConfig,
    @SerialName("components_localizations")
    public val componentsLocalizations: Map<LocaleId, Map<LocalizationKey, LocalizationData>>,
    @SerialName("default_locale") public val defaultLocaleIdentifier: LocaleId,
    public val revision: Int = 0,
    @SerialName("zero_decimal_place_countries")
    public val zeroDecimalPlaceCountries: List<String> = emptyList(),
    ...
)

Two things in that declaration shape everything downstream. Localizations arrive as a map keyed by every locale the paywall supports, not as a single pre-resolved language, which makes locale selection the device's job. And revision is carried explicitly, so a client can tell one published version of a paywall from another, which is what makes experiment attribution possible later.

Inside componentsConfig is the tree, built from PaywallComponent, a sealed interface with a hand written serializer:

@Serializable(with = PaywallComponentSerializer::class)
public sealed interface PaywallComponent

The second stage compiles that data model into a render model. StyleFactory performs the transformation, and its constructor shows what compiling means here:

internal class StyleFactory(
    private val localizations: NonEmptyMap<LocaleId, LocalizationDictionary>,
    private val colorAliases: Map<ColorAlias, ColorScheme>,
    private val fontAliases: Map<FontAlias, FontSpec>,
    private val variableLocalizations: NonEmptyMap<LocaleId, NonEmptyMap<VariableLocalizationKey, String>>,
    private val offering: Offering,
    private val stripRules: Boolean = false,
)

Every reference in the wire format gets resolved here. A component whose background is ColorAlias("primary") gets an actual ColorScheme. A text component whose font is FontAlias("brand") gets a FontSpec. A package component naming a package identifier gets a real Package from the Offering, or an error if no such package exists. String keys become resolved strings for every supported locale. The stripRules flag is the second stage's one concession to unknown input, and the next section is about what sets it.

The output type is deliberately minimal:

@Immutable
internal sealed interface ComponentStyle {
    val visible: Boolean
    val size: Size
}

By the time a ComponentStyle exists there is nothing left to look up. No alias to resolve, no locale to pick, no package to find. That is what makes it safe to declare @Immutable, and it is why nothing inside composition can fail. The annotation is a promise to the Compose compiler that an instance's properties never change after construction, which lets Compose skip re-executing a composable whose inputs are equal to last time and leave what it emitted in place. Strong skipping means Compose would already skip on instance equality for many of these, but the annotation documents the guarantee and lets the compiler treat the type as stable everywhere it appears rather than only where the same instance happens to be reused.

Validation in this stage accumulates rather than fails fast, and the reason is practical. When a dashboard user publishes a paywall referencing three colors that were deleted, a fail fast validator reports one, the user fixes it, republishes, and discovers the second. Accumulating means one report lists all three. The SDK uses its own Result type:

internal sealed class Result<out A, out B> {
    class Success<A>(val value: A) : Result<A, Nothing>()
    class Error<B>(val value: B) : Result<Nothing, B>()
}

paired with combinators that gather every error instead of stopping at the first:

internal inline fun <A, B, G, H> zipOrAccumulate(
    first: Result<A, NonEmptyList<H>>,
    second: Result<B, NonEmptyList<H>>,
    transform: (A, B) -> G,
): Result<G, NonEmptyList<H>>

zipOrAccumulate takes two results and a function. If both succeeded it applies the function. If either failed it returns every error from both, concatenated. The error type is NonEmptyList<PaywallValidationError>, and the choice of NonEmptyList is what keeps the failure case from lying: a list type that guarantees at least one element makes "failed with zero errors" unrepresentable. PaywallValidationError has twenty one cases, including MissingColorAlias, MissingFontAlias, MissingPackage, MissingStringLocalization, and TabControlNotInTab.

The third stage is rendering, and it is almost boring by comparison. ComponentView dispatches a ComponentStyle to a composable:

@Composable
internal fun ComponentView(
    style: ComponentStyle,
    state: PaywallState.Loaded.Components,
    onClick: suspend (PaywallAction) -> Unit,
    modifier: Modifier = Modifier,
    componentInteractionTracker: PaywallComponentInteractionTracker = PaywallComponentInteractionTracker { _ -> },
) = when (style) {
    is StackComponentStyle -> StackComponentView(...)
    is TextComponentStyle -> TextComponentView(...)
    is ImageComponentStyle -> ImageComponentView(...)
    ...
}

The remaining branches follow the same shape, and the function ends there. There is no else, and there cannot be a missing case either: a when used as an expression over a sealed type will not compile unless every subtype is covered. Adding a style without a corresponding view is a compile error rather than a runtime hole.

That is the payoff of the three-stage split, and the precise version of the claim is narrower than the grand one. Every question of what type of thing the server sent is answered before stage two ends. What is not settled at that boundary is data. A variable name, an image URL, a window width, and a selected package are all resolved during composition, which is why the misconfiguration path below exists: the types are pinned down at the boundary, the values are not.

Absorbing bad input: Forward compatibility and misconfiguration are different problems

That boundary has to actually hold, which brings us back to the carousel arriving at a binary that predates carousels. The SDK has two forward compatibility mechanisms for genuinely unknown input, and then a third, separate path for input that is well formed but misconfigured. Keeping those two problems apart matters, because they fail for different reasons and deserve different answers.

Tier one: A fallback subtree supplied by the server

The component deserializer is written by hand rather than generated, and the last branch is where forward compatibility lives:

override fun deserialize(decoder: Decoder): PaywallComponent {
    val jsonDecoder = decoder as? JsonDecoder
        ?: throw SerializationException("Can only deserialize PaywallComponent from JSON, got: ${decoder::class}")
    val json = jsonDecoder.decodeJsonElement().jsonObject
    return when (val type = json["type"]?.jsonPrimitive?.content) {
        "button" -> jsonDecoder.json.decodeFromJsonElement<ButtonComponent>(json)
        "image" -> jsonDecoder.json.decodeFromJsonElement<ImageComponent>(json)
        ...

Fifteen branches later comes the part that matters:

"fallback_header" -> FallbackHeaderComponent
        else -> json["fallback"]
            ?.let { it as? JsonObject }
            ?.let { jsonDecoder.json.decodeFromJsonElement<PaywallComponent>(it) }
            ?: throw SerializationException("No fallback provided for unknown type: $type")
    }
}

When the type is unrecognized, the deserializer looks for a fallback key on the same object and decodes that value as a PaywallComponent, recursively. So the server does not send a carousel and hope. It sends a carousel with instructions for what to render instead:

{
  "type": "carousel",
  "pages": [ "..." ],
  "fallback": {
    "type": "stack",
    "components": [ { "type": "text", "text_lid": "carousel_summary" } ]
  }
}

A binary that knows carousels renders the carousel and ignores fallback. A binary that does not renders the stack. The recursion means a fallback can itself contain a fallback, so a component added in the newest SDK can degrade through intermediate representations down to something a much older binary understands.

The design decision here is that the server owns the degradation choice rather than the client. A client cannot reasonably invent a substitute for a component type it has never seen, but the person who designed the component can specify one, and the dashboard can emit it automatically.

This does not hand an old binary a capability it was never built to render. What it guarantees is that the old binary shows a coherent, purchasable screen instead of a hole, and that a designer chose what that screen is. The hosted approach has a floor of its own here: its instruction set is only as new as the oldest WebView in your install base.

Notice also that every branch decodes from json, the already parsed JsonElement, rather than from text. A comment in the source explains why:

Decode the JsonElement directly; re-stringifying (decodeFromString(json.toString())) is ~quadratic in tree depth, as every nested PaywallComponent would re-stringify its whole subtree.

The obvious implementation of a discriminated union deserializer reads the type field, then hands the JSON text to the right serializer. In a recursive tree, every node on the path from the root down to a leaf re-serializes that leaf, so total work becomes the node count multiplied by the tree's depth instead of just the node count. Ten levels of nesting means the deepest text gets written out and parsed again ten times. Decoding from the parsed element does each node once.

Tier two: Unknown conditions collapse the override cascade

The second class of unknown is not a component but a condition. Components carry overrides that apply only in certain situations, which is how one definition covers phone and tablet, light and dark, selected and unselected. Think of a stack of CSS rules applied in source order: each override that matches overwrites the properties it names and leaves everything else alone. ComponentOverride pairs the conditions with the properties:

public class ComponentOverride<T : PartialComponent>(
    public val conditions: List<Condition>,
    public val properties: T,
)

Condition is nested inside ComponentOverride and has grown over time, from simple markers to parameterized rules:

@Serializable(with = ConditionSerializer::class)
public sealed interface Condition {
    public val isRule: Boolean get() = false

    @Serializable public object Compact : Condition
    @Serializable public object Medium : Condition
    @Serializable public object Expanded : Condition
    @Serializable public object IntroOffer : Condition
    @Serializable public object Selected : Condition

The newer ones carry operators and operands, and mark themselves with isRule:

@Serializable
    public data class SelectedPackage(
        public val operator: ArrayOperator,
        public val packages: List<String>,
    ) : Condition { override val isRule: Boolean get() = true }

    @Serializable
    public data class Variable(
        public val operator: EqualityOperator,
        public val variable: String,
        public val value: JsonPrimitive,
    ) : Condition { override val isRule: Boolean get() = true }

    @Serializable public object Unsupported : Condition
}

That isRule flag separates the original fixed set of conditions, which every SDK version has always understood, from the ones added later. The distinction is what the fallback strategy keys on.

Unknown condition types deserialize to Unsupported rather than throwing, through a reusable helper:

internal object ConditionSerializer : SealedDeserializerWithDefault<Condition>(
    serialName = "Condition",
    serializerByType = mapOf(
        "compact" to { Condition.Compact.serializer() },
        "selected_package_condition" to { Condition.SelectedPackage.serializer() },
        "variable_condition" to { Condition.Variable.serializer() },
        ...
    ),
    defaultValue = { Condition.Unsupported },
)

SealedDeserializerWithDefault is used at seven boundaries, six of them in the component schema, and it falls back in two situations rather than one:

val serializer = type?.let { serializerByType[it] }
    ?: return defaultValue(type ?: "null")
return try {
    jsonDecoder.json.decodeFromJsonElement(serializer(), jsonObject)
} catch (_: Exception) {
    defaultValue(type)
}

An unrecognized discriminator falls back. So does a type the client recognizes whose payload fails to parse, which means a future server version can add a required field to an existing condition without breaking older clients. The unknown value half of this pattern also appears on enums through EnumDeserializerWithDefault, and on nested sealed types like PurchaseButtonComponent.Method, which carries an explicit Unknown case alongside InAppCheckout and the web checkout variants. It is not applied to every sealed type in the schema, though: PaywallComponent itself throws when no fallback is present, and types like Dimension and ColorInfo are plain polymorphic with no default.

Now, what should a client do when it finds an Unsupported condition? Rendering the override anyway is wrong, because the condition it depended on was never evaluated. Ignoring only that override is also wrong, and the reason takes a moment to see. Say one override paints a dark background on compact screens, and a second one, carrying a rule, switches the text to light when the annual package is selected. Drop the second and the text keeps its base dark colour on the dark background the first one painted, which nobody ever previewed. Overrides are written as a stack, and half a stack is not a smaller design, it is a different one.

So the effect escalates from the override to the whole tree. Any Unsupported condition anywhere sets a single flag, and that flag discards every override carrying a rule across the entire paywall:

internal fun <T : PartialComponent, P : PresentedPartial<P>> List<ComponentOverride<T>>.toPresentedOverrides(
    stripRules: Boolean = false,
    transform: (T) -> Result<P, NonEmptyList<PaywallValidationError>>,
): Result<List<PresentedOverride<P>>, PaywallValidationError> {
    val overridesToProcess = if (stripRules) {
        this.filter { override ->
            override.conditions.none { it.isRule || it is ComponentOverride.Condition.Unsupported }
        }
    } else {
        this
    }
    ...

What survives is the base set of conditions, so the paywall renders as the design without conditional refinements. The trade off is explicit: a coarser but coherent paywall instead of a precisely targeted but internally inconsistent one. The cost is a real deployment coupling. The flag is computed per component tree, so on the day the dashboard starts emitting a new condition type, every client that has not yet updated loses conditional refinement across the whole of any paywall that uses it, not just the component that carried the new condition.

Once conditions are resolvable, the cascade itself is a fold:

internal fun <T : PresentedPartial<T>> List<PresentedOverride<T>>.buildPresentedPartial(
    windowSize: ScreenCondition,
    offerEligibility: OfferEligibility,
    state: ComponentViewState,
    conditionContext: ConditionContext = ConditionContext(null, emptyMap()),
): T? {
    var partial: T? = null
    for (override in this) {
        if (override.shouldApply(windowSize, offerEligibility, state, conditionContext)) {
            partial = partial.combineOrReplace(override.properties)
        }
    }
    return partial
}

Overrides apply in declaration order, and combineOrReplace merges each matching one over the accumulated result, replacing outright only when there is nothing accumulated yet. Precedence is an explicit list order rather than a scoring algorithm, which makes it deterministic and testable.

The separate path: Misconfiguration exits the components pipeline

The two mechanisms above handle input the client does not recognize. A different failure is input that is perfectly well formed and simply wrong: a color alias that references a deleted color, a package identifier that is not in the offering, a tabs component with no tabs. That is not a forward compatibility problem, it is a misconfiguration problem, and it gets a different answer.

validatedPaywall is where all of it converges:

internal fun Offering.validatedPaywall(
    currentColorScheme: ColorScheme,
    resourceProvider: ResourceProvider,
): PaywallValidationResult =
    validatePaywallComponentsDataOrNull(resourceProvider)?.let { result ->
        when (result) {
            is RcResult.Success -> result.value
            is RcResult.Error -> fallbackPaywall(currentColorScheme, resourceProvider, errors = result.value)
        }
    } ?: paywall?.validate(currentColorScheme, resourceProvider)
        ?: fallbackPaywall(currentColorScheme, resourceProvider, error = PaywallValidationError.MissingPaywall)

Four outcomes in one expression. A component tree that validates is used. A component tree that fails validation goes to fallbackPaywall. An offering with no component tree falls through to the older PaywallData paywall it may have configured. An offering with neither also goes to fallbackPaywall.

The result type is what makes the exit clean:

internal sealed interface PaywallValidationResult {
    val errors: NonEmptyList<PaywallValidationError>?

    data class Legacy(
        val displayablePaywall: PaywallData,
        val template: PaywallTemplate,
        override val errors: NonEmptyList<PaywallValidationError>? = null,
    ) : PaywallValidationResult


and on the components branch, a comment stating the policy directly:

data class Components(...) : PaywallValidationResult {
        // If a Components Paywall has an error, it will be reflected as a Legacy type so we can use the Legacy
        // fallback.
        override val errors: NonEmptyList<PaywallValidationError>? = null
    }

Components structurally cannot carry errors. A components paywall either compiled cleanly or it is no longer a components paywall, and there is no third state for the renderer to interpret.

The name fallbackPaywall suggests something more configured than it is. It builds PaywallData.createDefault(availablePackages, ...) against PaywallData.defaultTemplate, and because that result carries errors, what actually draws is DefaultPaywallView, which reads only the package list off it. The generated screen is nicer than it sounds: it pulls the app's name and icon from the platform and derives two prominent colors from the icon, so it lands approximately on brand with no configuration at all. It lists real products at real prices with a working purchase button, and the diagnostic explaining what went wrong is a debug build only overlay, so a production user sees a plain paywall rather than an error message aimed at a developer.

The shape across all three mechanisms comes down to this. Tiers one and two are forward compatibility, absorbing input from a newer server than the binary expects, and both stay inside the components renderer. The misconfiguration path is robustness against a badly configured dashboard, and it leaves the components renderer entirely. What they share is that none of them reaches ComponentView as an unknown type, which is why stage three needs no else and no defensive branch.

What the node tree gives you: Semantics and a typed purchase path

Everything so far has been about surviving the schema boundary. Two things that become possible on the other side of it are hard to get any other way.

The first is accessibility. Because components render as Compose nodes, they emit semantics that TalkBack consumes directly, and the SDK can shape that tree deliberately. StackComponentView splits a clickable stack into three parts. A wrapper Box carries the caller's modifier and owns both the click gesture and the semantics. Inside it, the stack draws its content without a shape clip so that children which intentionally overflow, like offset badges, stay visible, and a sibling supplies the shape clipped ripple. Putting the click and the semantics together on the wrapper merges them into a single node alongside whatever testTag or Role the caller supplied, rather than scattering them into separate nodes a screen reader has to announce one at a time.

A WebView is not inaccessible, and pretending otherwise would be easy to refute. ARIA gives explicit control over roles, labels, and grouping. What it gives you is a second accessibility contract to get right, one that does not compose with the native tree around it: focus order across the AndroidView boundary, mergeDescendants on a Compose parent, and tag based UI tests all stop at the edge of the document. The native tree also means the paywall is testable with SemanticsNodeInteraction, the same tooling as the rest of the app, instead of needing a browser automation layer.

The second is the purchase path. The purchase button is not a generic button posting a string across a bridge, it is a typed component with a typed action:

@SerialName("purchase_button")
public class PurchaseButtonComponent(
    public val stack: StackComponent,
    public val action: Action? = null,
    public val method: Method? = null,
    public val name: String? = null,
) : PaywallComponent {
    public enum class Action {
        IN_APP_CHECKOUT,
        WEB_CHECKOUT,
        WEB_PRODUCT_SELECTION,
    }

By the time this reaches the renderer it has been compiled into a style holding a resolved Package, which came from the Offering, which came from Google Play. A dashboard that references a package not in the offering produces MissingPackage in stage two and exits to the fallback path before a user can tap anything. This is not compile time safety on the product identifier, since the identifier is data. It is the same check a bridge would eventually do, moved from the button press to before the paywall renders.

What only the device can know: Where the division of labor falls

There is a common misreading of server driven UI, which is that the server draws the screen and the client displays it. That is not what is happening here, and the difference is why the on device work is not incidental.

The dashboard owns design intent. The device owns facts nobody can know at publish time. The schema is the contract between them, and conditions are how intent gets expressed in terms of facts the server does not have.

Start with theme, because it shows the pattern in four lines. Colors arrive from the server as a pair rather than a value:

public class ColorScheme(
    public val light: ColorInfo,
    public val dark: ColorInfo? = null,
)

and resolution happens inside composition:

internal val ColorStyles.forCurrentTheme: ColorStyle
    @Composable
    get() = if (isSystemInDarkTheme()) dark ?: light else light

Reading isSystemInDarkTheme() inside a composable registers a recomposition dependency on the configuration, so a theme change updates the paywall in place, provided the host activity declares android:configChanges="uiMode" and is not recreated outright. Locale works the same way and is held as Compose state:

private var localeId by mutableStateOf(initialLocaleList.toLocaleId())

val locale by derivedStateOf { localeId.toComposeLocale() }

Every text component reading locale recomposes with strings from a different entry in the localizations map that was already downloaded, because the wire format shipped all of them.

Screen size comes from the standard adaptive API rather than a guess about device class:

internal enum class ScreenCondition {
    COMPACT, MEDIUM, EXPANDED;

    companion object {
        fun from(sizeClass: WindowWidthSizeClass) =
            when (sizeClass) {
                WindowWidthSizeClass.COMPACT -> COMPACT
                WindowWidthSizeClass.MEDIUM -> MEDIUM
                WindowWidthSizeClass.EXPANDED -> EXPANDED
                else -> {
                    Logger.d("Unexpected WindowWidthSizeClass: '$sizeClass'. Falling back to COMPACT.")
                    COMPACT
                }
            }
    }
}

That else is instructive after a section about exhaustive when expressions. WindowWidthSizeClass is a plain class with a private constructor and companion object constants rather than a sealed type or an enum, so there is no exhaustiveness to lean on and the branch is mandatory. Note where it falls back to, and note that it logs. Because the value comes from the current window rather than the physical display, a foldable that unfolds or an app entering split screen moves between conditions live.

The case that no server can resolve at all is offer eligibility. A dashboard author wants a headline reading "Start your free trial" for users who qualify and "Subscribe" for users who already used theirs. Eligibility is a property of this user's purchase history on this store, so the device resolves it by reading the shape of what Google Play returned:

internal val Package.introOfferEligibility: OfferEligibility
    get() {
        val phaseCount = (product.defaultOption?.pricingPhases?.size ?: 0) - 1

        return when (phaseCount) {
            1 -> OfferEligibility.IntroOfferSingle
            2 -> OfferEligibility.IntroOfferMultiple
            else -> OfferEligibility.Ineligible
        }
    }

The number of pricing phases beyond the base phase tells you how many discounted phases this user can actually receive, because Google Play only includes phases they are eligible for. The else treats an offer with three or more discounted phases as ineligible rather than inventing a category for it, which is a real limit in an otherwise total function. Promotional offers layer on top with the same logic and fall back to intro eligibility when no promo applies, and the result becomes the offerEligibility argument to buildPresentedPartial, which is what makes an IntroOffer condition evaluable at all.

Currency formatting is the subtlest of these, and a good illustration of why the device has to decide. A user's language and their storefront country are independent, so a Korean speaker can have a US storefront. Format a derived per month price in the wrong locale and the separator or symbol placement disagrees with the price string the store returned, which users notice immediately. The lookup tries three things in order: a locale that already pairs the device's language with the storefront's country, then any locale for that storefront, then one built by stapling the storefront's region onto the device's language.

val currencyLocale by derivedStateOf {
    if (storefrontCountryCode.isNullOrBlank()) {
        locale
    } else {
        val deviceLanguageCode = locale.language.lowercase()

        val javaLocale = availableStorefrontCountryLocalesByLanguage[deviceLanguageCode]
            ?: availableStorefrontCountryLocalesByLanguage.values.firstOrNull()
            ?: Locale.Builder()
                .setLocale(locale.toJavaLocale())
                .setRegion(storefrontCountryCode.uppercase())
                .build()

        javaLocale.toComposeLocale()
    }
}

availableStorefrontCountryLocalesByLanguage is built once by scanning Locale.getAvailableLocales() for every locale whose country matches the storefront. Text renders in the device language, prices format according to the storefront country, and zeroDecimalPlaceCountries from the wire format suppresses decimals in currencies that do not use them.

Localization covers more than text. The payload is a three case hierarchy:

public sealed interface LocalizationData {
    public value class Text(public val value: String) : LocalizationData
    public value class Image(public val value: ThemeImageUrls) : LocalizationData
    public value class Video(public val value: ThemeVideoUrls) : LocalizationData
}

A localization key can resolve to a string or to a set of image URLs, which means a Korean user and a US user can see entirely different hero imagery from one paywall definition, chosen on the device with the assets already predownloaded. The Video case is declared and read by the renderer, but the deserializer only attempts Text then Image, so it is not currently reachable from the wire. That is what a schema running slightly ahead of its parser looks like from the inside, and it is the same coordination problem the platform section returns to.

Finally, UiConfig adds a token layer above individual paywalls:

public class UiConfig(
    public val app: AppConfig = AppConfig(),
    public val localizations: Map<LocaleId, Map<VariableLocalizationKey, String>> = emptyMap(),
    @SerialName("variable_config") public val variableConfig: VariableConfig = VariableConfig(),
    @SerialName("custom_variables") public val customVariables: Map<String, CustomVariableDefinition> = emptyMap(),
) {
    public class AppConfig(
        public val colors: Map<ColorAlias, ColorScheme> = emptyMap(),
        public val fonts: Map<FontAlias, FontsConfig> = emptyMap(),
    )

Components reference ColorAlias and FontAlias rather than literal values, so changing a brand color once updates every paywall referencing it without touching a component. FontsConfig, whose declaration is not in that excerpt, holds a single field named android. The name is the interesting part: a schema serving only Android would not need to key the field by platform at all. The wire format carries a font entry per platform and each SDK reads its own key, which is the first place in the schema where cross-platform parity shows up as a design constraint rather than an implementation detail.

The localizations map on UiConfig is separate from a paywall's own copy and holds translations for variable rendering. When a component writes {{ product.period }}, the word "month" has to appear in the reader's language even though the dashboard author only wrote English. Those translations ship with the config and get applied on the device.

So the division of labor is specific. The dashboard decides what the paywall means. The device decides what is true right now. Three of those facts a hosted page can also read for itself: navigator.language, prefers-color-scheme, and a media query cover locale, theme, and width without any bridge. Theme comes with a wrinkle, since what a WebView reports to prefers-color-scheme follows the host theme's android:isLightTheme rather than the system setting directly. The other three are the ones a browser cannot see on its own. What this user's purchase history makes them eligible for, which currency conventions this storefront uses, and which fonts already shipped inside this binary all have to arrive as bridge messages the page then re-renders against, and until they arrive the page is displaying a guess.

The platform behind the JSON: What the SDK does not show you

Reading through the SDK, it is easy to conclude the hard part is the renderer. It is not. The renderer is the visible half of a system whose expensive half never ships to a device.

Start with the editor. A dashboard where a product manager rearranges a paywall has to emit a component tree valid against the schema, with live preview, which means a browser side implementation of the same layout semantics the native renderers implement. Visual editors for general purpose layout are a solved product category. An editor for a schema you invented is not one of them. It is a third renderer, and it has to stay in parity with the other two.

Then the schema. PaywallComponentsData carries a revision, and a good number of its sealed types have default cases, because the schema is a contract between one server and every SDK version ever installed. SealedDeserializerWithDefault covers seven of them, and others like ButtonComponent.Action and ButtonComponent.Destination reach the same result through hand written serializers that map an unrecognized value to Unknown.

Adding a component type is not a code change, it is a protocol change. The type has to be designed, added to the schema, implemented in each platform renderer, given a sensible fallback representation for older clients, taught to the editor, and covered by fixtures. The fallback mechanism from tier one only works because someone designs the fallback at the same time as the component.

Then parity, where the cost is highest and least visible, because it is not a feature you finish. The same JSON has to produce the same paywall on Android, on iOS, and through every hybrid framework in between, across codebases with different layout systems. Compose and SwiftUI do not agree by default about how a stack distributes remaining space, how a shadow interacts with a clipped shape, or what a percentage size resolves to inside a scroll container. Getting them to agree is deliberate work, and keeping them agreeing is permanent work.

Those resources feed the debug source set, where TemplatePreviews renders them through a preview parameter provider so a change to the renderer can be reviewed against the same definitions every platform consumes. Separately, ui/revenuecatui-testing publishes PaywallFixtures, PaywallFixtureView, PaywallFixtureViewOptions, and PaywallFixturesTestRule, which let an app developer snapshot test their own dashboard configured paywalls against recorded fixtures. Parity is not maintained by discipline alone; there is a shared corpus and there is tooling that renders it.

On top of rendering, an experimentation platform needs to know what happened. The SDK carries PaywallEvent, PaywallStoredEvent, PaywallPresentedCache, PaywallPostReceiptData, and PaywallComponentInteractionTracker, which threads through most component views. Attribution is the reason: to know whether variant B beat variant A, a purchase has to be tied back to the exact paywall revision on screen when it happened, surviving process death, backgrounding, and a store callback that arrives later.

Add it up and the shape is clear. The JSON is the easy part. A visual editor, a versioned schema with a designed degradation story, a delivery and caching tier, a renderer per platform held to parity by a shared corpus, and an experiment assignment and attribution pipeline are the actual system. Parity is also not a cost you pay once: every component type you add adds work on every platform you support, indefinitely.

This is the honest argument for not building it yourself. Not that the rendering is hard, though the degradation design took real thought, but that the rendering is the part you would actually finish. RevenueCat provides the dashboard, the schema, the delivery, the renderers, the experiment engine, and the attribution, which is why a product manager can reorder packages, change which one is preselected, swap a hero image for one locale, or restyle a paywall and have it take effect on installed apps without a release. That capability is not a feature of the SDK. It is a property of the whole platform, and the SDK is the part that happens to run on the device.

The bill, honestly: Release gates, schema ceilings, and parity

Native server-driven UI is the more expensive architecture, and there are four places the cost lands.

The first is that new capabilities are gated on releases. When a component type is added, apps cannot render it until they ship an SDK version that knows it, and the fallback mechanism exists precisely because that transition takes months across a real install base. A hosted paywall has no such gate. That is a genuine advantage, and the fallback subtree does not erase it, it only guarantees the old binary shows something coherent in the meantime. The gap is not a fee that purchases anything either. It is the same architectural decision seen from the other side: a render model living inside your binary is what makes the offline path, the theme and locale response, and the pre-render validation possible, and it is what makes new components wait for a release.

The second is a ceiling on expression, and it is the one a competitor leads with. A designer can only produce effects the schema models. If the schema has no notion of a particular animation curve or a blend mode, no amount of dashboard work produces it, and the request becomes a protocol change with a multiplatform release behind it. A hosted page has no such ceiling, because its instruction set is the whole of CSS.

The third is the deployment coupling described in tier two. One unknown condition type strips every override that carries a rule across the whole of the affected paywall, which means the day a new condition ships, clients that have not updated lose conditional refinement throughout that paywall rather than only where the new condition appeared.

Conclusion

The next time you evaluate a server driven UI system, the question to ask is not how it renders. It is where the system puts the uncertainty about what the server might send, and who pays when that uncertainty resolves badly. A hosted document pushes it into a runtime you do not version, and the bill arrives as a blank screen on a bad network, a layout that shifted when the WebView provider updated, or a product identifier that did not match anything until a user pressed the button. A typed component tree pushes it into a schema boundary you design, and the bill arrives as release coordination, a ceiling on expression, and renderer parity, paid by the team rather than the user.

What makes the second approach hold up is that the boundary is a single, narrow place, and that every way past it has a named floor. Past that boundary, ComponentView is a when with no else, and the compiler will not let the renderer be incomplete. Every architecture has a point where it stops guessing. It is worth choosing where yours is.

Then he got tired of opening Sketch just to write a movie review.

Watch on YouTube

That inconvenience eventually became Quick Reviews, the first app Matt considers a serious release. It also started a run of small utilities built from the same question: if a piece of software keeps annoying you, why not fix it yourself?

A Sketch artboard had to become an app

Before Quick Reviews was an iOS app, it was a manual design chore. Matt wanted to post visually appealing reviews of movies and games to his social accounts, so he built a Sketch document. Every time he wanted to post a review, he had to sit at his Mac, duplicate the artboard, swap the poster image, and retype the text.

When people started asking what app he was using, he built a simple, one-page jQuery website to automate the process. It still required users to screenshot the final result, and it had no account system or review history. He wanted the tool on his phone, which meant he finally had to figure out native iOS development.

Bad AI made him learn the code

Matt knew CSS and HTML, but his previous attempt at building an iOS app felt like "laying out your HTML in tables." SwiftUI's declarative syntax felt familiar to someone who already knew the web. At the same time, early AI coding tools like Cursor were becoming available.

He spent about a month and a half working through the app, but the AI tools available at the time were frustratingly rudimentary.

“It was so hard. You had to tell it to do one small thing. It would screw it up. You'd have to do it again... The entire app would be in one Swift file, and you'd have to remind it, ‘you might want to do a second file.’” — Matt Birchler

But that friction was exactly what he needed. Because the AI couldn't build the app perfectly on the first try, Matt was forced to read the output, understand the data structures, and learn how the views interacted. That structural knowledge paid off. Today, when he uses much better AI tools, he actually knows what to ask for and how to verify that the generated code is correct.

The $10 subscription was downside protection

Quick Reviews is a free app, but it includes a $10 annual subscription from day one. That decision wasn't driven by aggressive growth targets; it was driven by API exposure.

The app pulls metadata, posters, and cast information from The Movie Database and uses an RSS feed to import a user's recent Letterboxd reviews. Relying on third-party services meant Matt couldn't assume every dependency would remain free forever.

“I wanted to make sure all of these projects do not lose me money.” — Matt Birchler

By putting the automated metadata and Letterboxd sync behind a paywall immediately, he gave the app a way to cover future service costs. Separately, the wider app catalog has become Matt's largest side-income stream, bringing in more revenue than either his blog or his YouTube channel by a significant margin.

99 folders of experiments

Once Matt realized he could fix his own software annoyances, the development bug bit hard. He built Quick Subtitles and Chapterize to remove friction from his own podcast workflow, using them multiple times a week. When he set a goal to run 365 miles in a year and couldn't find a workout app that simply graphed his progress toward that specific target, his immediate response was, "I could make that." So he built Yearly Run Goals.

He names his apps clearly—using words like "Quick"—to signal that they are focused utilities, not massive platforms that require endless support. But he doesn't release everything he builds.

In his Mac's home directory, Matt has a folder simply named "Apps." It contains 99 folders—not all of them projects he built himself, but many of them tiny tools, abandoned visualizers, and experiments that never went anywhere. He sees a friction point and wants to know whether he can fix it. Sometimes the answer is yes, and a new app ships. Sometimes the answer is no, and the experiment stays in the folder.

Where to go next

In the full episode, Matt also discusses why actually selling software on the App Store changed his view of Apple's 30% commission, why YouTube sponsorships often create more administrative work than they are worth, and how co-hosting the Comfort Zone podcast gives him a collaborative creative outlet.

Guest links

• Birchtree
• Quick Reviews on the App Store
• A Better Computer on YouTube
• Comfort Zone Podcast

Timing makes this worth the effort: according to our State of Subscription Apps 2026 report, 55% of 3-day trial cancellations happen on Day 0. The battle for a subscriber is won or lost in the first session, so if your paywall only gets one shot, it should speak to the person looking at it.

The example app

Chorus, the bird song identifier and walk tracker I'm building for Shipaton 2026, spends its onboarding learning why someone is using the app and what would get them to walk more. It asks about their dream bird, who they go on walks with, when they go on walks, and what would actually get them out the door more.

This post is about what happens next: using Apple's on-device Foundation Models framework to hand their own ’why’ back to them at the moment of the ask, on a RevenueCat remote paywall. The best part? It's free.

Here's the basic paywall with no personalization:

It does the job. It's okay, but it's not really speaking to the user. Let's change that.

Custom variables on the paywall

Using RevenueCat remote paywalls, you can start personalizing them using custom variables, but what if you could push that further? What if you could use everything your app already knows about your customer to really get personal?

Open your RevenueCat paywall editor. Click ‘Paywall Logic’ in the left-hand menu and select Variables. Then click ‘Create Variable’ and you'll see the following entry form:

I'll start by creating the userName variable (possibly the easiest bit of personalization), with the default value ‘Birder’. Chorus asks for the birder's name in onboarding, saves it, and passes it into the remote paywall in Swift like so:

struct ChorusPlusPaywall: View {
    let userName: String?   // asked for in onboarding; nil if they skipped it

    var body: some View {
        PaywallView(displayCloseButton: true)
            // If there's no name, send nothing; the dashboard
            // default ("Birder") fills the gap.
            .customPaywallVariables(userName.map { ["userName": .string($0)] } ?? [:])
    }
}

That'll produce a paywall like this:

Better. But we can make it even better with Foundation Models.

Apple's Foundation Models

Foundation Models is Apple's on-device large language model (LLM) framework, introduced in iOS 26. It generates text locally, with no server round trip and no per-token cost. Apple says "On-device models excel at a diverse range of text generation tasks, like summarization, entity extraction, text and image understanding, refinement, dialog for games, generating creative content, and more". Perfect for our use case. On-device models are much smaller than cloud-based models, so there are limitations, which I'll go through later.

As I mentioned, Chorus gets to know the customer during onboarding — this is where the magic happens.

Create a class that handles all interaction with Foundation Models. I've called mine ‘PaywallCopyGenerator’. In Chorus, each onboarding screen is aware of this class, and its functions get called at different points in the flow.

Right at the start, the welcome screen calls prewarm(), which checks SystemLanguageModel.default.availability and warms a session. Devices without Apple Intelligence bail out here: they ship the hand-written fallback line and never touch the model.

func prewarm() {
  guard warmSession == nil else { return }
  guard case .available = SystemLanguageModel.default.availability else { return }

  warmSession = LanguageModelSession(instructions: instructions)

  warmSession?.prewarm()
}

Prewarming the session reduces the time it takes for the user to see generated output. Do it as early as possible.

One gotcha: the first time a user's device meets the requirements, SystemLanguageModel can register as unavailable while the OS downloads the model in the background. Don't panic, it resolves itself. In Chorus I don't need to guard with an iOS 26 availability check because the app targets iOS 26; if you support older versions, you will.

Instructions and prompts

You'll notice you pass system instructions into the session. Apple has great guidance on getting the best out of the model by giving the model a role, persona, and tone. Here are Chorus's system instructions:

You are a warm British field naturalist writing paywall copy for Chorus, a
bird-walking app. You are given notes about a walker from the app's
onboarding: their dream bird, what would get them out walking more, and how
they walk. Write two short sentences spoken to them as "you".
1. Conjure their next walk as one small imagined moment, built only from
the notes: who is with them, when or where they walk, their dream bird
singing somewhere in it.
2. Say what Chorus can help them do about it.
Never invent people, places, times or history that are not in the notes.
Mention Chorus exactly once, in the help sentence; never name features or
prices. Never the walker's name. No questions, no exclamation marks, no em
dashes. Thirty words at most.

Write like a person talking, not an advert: plain, everyday words, said
simply, nothing you would not say to a friend on a walk. The examples
below are style only; never reuse their scenes, company or times of day
for a different walker. When the notes say who walks with them, hand it
back as theirs: "your partner", "your dog", "your kids", not "a partner"
or "the kids".

Example 1.
Notes: Their dream bird: the goldfinch; they have never heard one; that is
the dream. What would get them out more: knowing new birds were waiting.
They walk at dawn, with their kids. They get out less than they'd like.
Line: Imagine a dawn walk with your kids when a goldfinch strikes up, your
first ever. Chorus can help you catch it the moment it sings.

Example 2.
Notes: Their dream bird: the wren; they hear them all the time and love
them. What would get them out more: keeping the birds they've found close.
They notice birds by ear first.
Line: Picture the next wren that sings before you spot it, one more song
worth keeping. Chorus can help you hold on to every one.

Example 3.
Notes: Their dream bird: the blackbird; they hear them all the time and
love them. What would get them out more: calmer, quieter time outside.
They walk at dusk, as the day's song winds down.
Line: Imagine a quiet walk at dusk, just you and the blackbird seeing the
day out. Chorus can help you make more of those.

The instructions lean on five concepts from Apple's documentation:

1. The persona: Chorus follows Apple's role-playing blueprint. Casting the model as a "warm British field naturalist" with the words "you are" merges character and voice in a single line. The instructions are also written in the exact register they expect back, right down to banning em dashes and obeying that ban themselves.
2. Step-by-step logic: dense task descriptions are broken into a two-step plan. For smaller models, this reduces the cognitive load and keeps sequencing on track.
3. Size constraints: the prompt stays lean. Two paragraphs of imperatives and one clear objective fit Apple's recommended length budget.
4. Few-shot safety: three curated examples establish the style. An "examples are style only" guard prevents exemplar bleed. Without it, the model happily hallucinates dawn walks for night owls.
5. Strategic repetition: high-stakes rules like "never invent" and "exactly once" are reinforced, and the runtime prompt repeats the most important rule last.

The runtime prompt works differently. Onboarding captures information about the user, then a few screens before the paywall we ask the model to generate the personalized line. That head start matters: on-device models are still fairly slow, so generating early means the line is ready by the time the paywall appears. (You can add a loading state at the end of onboarding if you prefer, but it's best not to block the paywall.)

Apple suggests sending the model hard facts, so a fairly long Swift function builds the runtime prompt with no conditional language (no ‘if’s for the model to reason about). Deterministic code decides which facts apply; the model only translates them into prose:

// Chorus — the walker's brief. Apple's "turn conditional prompting into programming
// logic", shipped: deterministic Swift turns onboarding answers into prose notes, so
// the on-device model only ever sees the conditions that apply. The model's whole job
// is translating these notes into one warm line. From `PaywallCopyGenerator.swift`.

/// The walker's why, in prose: dream bird + history, what would get them out more,
/// how they notice birds, and every context line that exists. Empty when everything
/// was skipped — there is nothing to reflect, and the fallback line ships instead.
func brief(signals: OnboardingSignals) -> String {
    var lines: [String] = []
    if let bird = signals.dreamBird {
        let heard: String = switch signals.dreamBirdHistory {
        case .often: "they hear them all the time and love them"
        case .yearsAgo: "they heard one once, years ago"
        case .unsure: "they aren't sure they've ever heard one"
        default: "they have never heard one; that is the dream"
        }
        let seen: String? = switch signals.dreamBirdSeen {
        case .often: "they see them all the time"
        case .yearsAgo: "they saw one once, years ago"
        case .unsure: "they couldn't say if they've seen one"
        case .never: "they have never seen one"
        case nil: nil
        }
        // Short name — briefing "the Common Nightingale" teaches stilted formal names.
        lines.append("Their dream bird: the \(bird.shortName); \(heard)"
                     + (seen.map { ", and \($0)" } ?? "") + ".")
    }
    switch signals.desiredPerk {
    case .whereNext: lines.append("What would get them out more: knowing new birds were waiting.")
    case .cameraScan: lines.append("What would get them out more: being able to name what they see.")
    case .wearBird: lines.append("What would get them out more: keeping the birds they've found close.")
    case .knowNow: lines.append("What would get them out more: knowing what's singing around them, right there and then.")
    case .everyDay: lines.append("What would get them out more: a reason to get out every day.")
    case .calm: lines.append("What would get them out more: calmer, quieter time outside.")
    case .learnSongs: lines.append("What would get them out more: learning to know the songs themselves.")
    case nil: break
    }
    switch signals.spotting {
    case .ear: lines.append("They notice birds by ear first.")
    case .eye: lines.append("They see birds but often can't name them.")
    default: break
    }
    switch signals.knowTheBirds {
    case .everyOne: lines.append("They want to know every bird they've heard.")
    case .special: lines.append("They'd like to know the special ones at least.")
    case .justListening: lines.append("They're happy just listening.")
    case nil: break
    }
    if let habitat = signals.habitat {
        switch habitat {
        case .gardenAndStreet: lines.append("They walk gardens and streets close to home.")
        case .park: lines.append("Their walks loop the local park.")
        case .woodland: lines.append("Their walks run under trees more often than not.")
        case .water: lines.append("Their walks keep close to water.")
        case .openCountry: lines.append("They walk open country where song carries far.")
        case .allOver: break
        }
    }
    switch signals.walkTime {
    case .dawn: lines.append("They walk at dawn, when the chorus is loudest.")
    case .dusk: lines.append("They walk at dusk, as the day's song winds down.")
    default: break
    }
    switch signals.companion {
    case .alone: lines.append("They walk alone.")
    case .partner: lines.append("They walk with their partner.")
    case .dog: lines.append("They walk with their dog.")
    case .kids: lines.append("They walk with their kids.")
    default: break
    }
    switch signals.walkFrequency {
    case .mostDays: lines.append("They walk most days.")
    case .fewTimesAWeek: lines.append("They walk a few times a week.")
    case .nowAndThen: lines.append("They get out now and then.")
    case .lessThanLike: lines.append("They get out less than they'd like.")
    case nil: break
    }
    return lines.joined(separator: " ")
}

OnboardingSignals is a struct that gets populated as the customer moves through onboarding.

The final piece of the puzzle is asking the model to generate output:

func generate(signals: OnboardingSignals) {
    guard task == nil else { return }

    let brief = self.brief(signals: signals)
    guard !brief.isEmpty else { return }   // everything skipped → fallback line

    working = true
    task = Task { [weak self] in
        defer { self?.working = false }
        guard let self else { return }
        self.generatedLine = await self.requestLine(
            prompt: "Notes: \(brief)\nUse only these notes. Write the line.")
    }
}

private func requestLine(prompt: String) async -> String? {
    guard let session = warmSession else { return nil }   // no model → fallback
    let response = try? await session.respond(
        to: prompt,
        generating: GeneratedLine.self,
        options: GenerationOptions(temperature: 0.85, maximumResponseTokens: 110))
    return response?.content.line
}

The runtime prompt is simple compared to the system instructions. We ask the model to fill a @Generable type:

@Generable
private struct GeneratedLine {
    @Guide(description: "Both sentences: the reflection, then the Chorus help line. Nothing else")
    var line: String
}

You can do interesting things here too, like checking the output for banned words and regenerating when one appears. You may also want to trim whitespace. The model occasionally leaks JSON artifacts into the string, so I trim it like this:

let line = raw.trimmingCharacters(in: .whitespacesAndNewlines)
    .trimmingCharacters(in: CharacterSet(charactersIn: "{}\"\u{201C}\u{201D}"))
    .trimmingCharacters(in: .whitespacesAndNewlines)

Pass the generated line into the paywall like before and you should see the foundation models generate something like the text surrounded by the red rectangle:

Pretty cool, right?

Limitations of Apple’s Foundation Model for personalized paywall copy

Foundation models are small. I like to compare them to the early days of GPT-3: about three billion parameters against the trillions in server-side models. Output isn't always great, and they can hallucinate. That's why the safety checks matter. Out of the box, Apple protects against harmful output (racism, violence, profanity), but Apple also states that you're responsible for the content the model generates.

A note on prompt safety: Chorus never sends freeform user text to the model. The brief is built entirely from fixed onboarding answers, so there's nothing a user can type that ends up in the prompt. If you do include free text, treat it as untrusted: interpolate it into a rigid prompt structure, and never let it stand alone as instructions.

I also found the model isn't yet smart enough for more ambitious moves, like picking the most relevant feature for a customer and spotlighting it. But it's early days: the models improved massively from iOS 26 to iOS 27, and I expect that trend to continue.

One more reason to ground the model in the user's own answers: our SOSA 2026 data shows AI-powered apps earn 41% more per payer but churn 30% faster. AI features only pay off when they create real, lasting value. Personalization built from what users actually told you is exactly that.

Going even further with AI-personalized paywalls

From iOS 27 you can swap the on-device model for a cloud-based one through the Foundation Models framework. Anthropic's Claude already conforms, and the other big providers may follow suit.

There's also Apple's Private Cloud Compute, which runs much larger server-side models. You can use it for free if you have fewer than two million lifetime first-time downloads and are enrolled in the App Store Small Business Program.

With those larger models, the more ambitious personalization opens up, like picking the most relevant feature for each customer and spotlighting it. Teams like Tinder invest heavily in exactly this kind of paywall relevance work; with these APIs, you don't need a dedicated team to try it.

Whether you want ultra-personalized paywall copy that calls out a birder’s favorite feathered friend, or are looking to demo the exact feature that solves your user’s job-to-be-done, on-device AI is unlocking a new way to tailor paywalls to every individual — just in time to ask them to subscribe.

To keep going on paywalls, start with our paywalls study guide or check out the paywalls documentation.

But the interesting part isn't the game. It's how it makes money. There's no paywall, no subscription, no in-app purchase (IAP). There's one button that says 'Watch Ad to Play', and behind that button is RevenueCat Ads.

Keep in mind that although I used this to make a game, RevenueCat Ads can also work for an app you’re building, such as a Photo Editing app that lets you watch an ad to unlock a premium filter, or a Messaging app that unlocks premium sticker packs with ads.

Watch on YouTube

RevenueCat Ads does two things right now

Ad revenue tracking ties ad money to the same user as your purchases

The obvious pitch is that you stop bouncing between AdMob and RevenueCat to figure out what your app actually made. True, and nice. But the better pitch is underneath that: your ad revenue gets tied to the same user as your subscription and IAP data.

That means ad revenue folds into your revenue chart and into realized LTV. You get blended revenue per user instead of two disconnected numbers you're eyeballing across two tabs. There's also a dedicated ads section in RevenueCat Charts and an ads tab on individual customer profiles, so "is this free user actually worth anything?" becomes a question you can just look up.

Francie wrote the full breakdown of the tracking side when it went into public beta: every metric, what shows up where, and how the SDK integration works. If you're on AdMob, it's mostly swapping your ad loading calls for RevenueCat's loadAndTrack methods. Make sure to turn on ‘Impression-Level Ad Revenue’ for it to track correctly.

Start there if tracking is what you came for. The rest of this post is the other half.

Ad rewards grant virtual currency or a timed Entitlement (this is new)

A user finishes a rewarded ad, AdMob fires a server-side verification (SSV) callback to RevenueCat, and RevenueCat verifies it and grants the reward. You don't build the verification layer. You don't build the granting layer. You just configure it in the dashboard.

Two kinds of rewards:

• Virtual currency: coins, credits, gems, tokens, whatever your economy uses
• Entitlements: actual RevenueCat Entitlements, granted for a duration

That second one is the interesting part. An Entitlement is just a level of access. Normally you get one by paying, but now, you can earn one by watching an ad. Same Entitlement check in your code either way.

Before you start: what you need in place

Three prerequisites:

1. An AdMob account with a rewarded ad unit, connected to your RevenueCat project so your ad units sync to the dashboard.
2. Server-side verification enabled on that ad unit in the AdMob console, pointing at RevenueCat's SSV callback URL. It's one shared endpoint for every ad unit, and RevenueCat works out which unit and which user from what the SDK attaches at show time.
3. The RevenueCat SDK (purchases-ios 5.80.3 or later (iOS 15+), or purchases-android 10.12.0 or later).

The AdMob adapter that makes this a two-line change is iOS and Android only. On Flutter, React Native, Unity, or Kotlin Multiplatform, you take the manual path: generate a verification token, attach it to your ad's SSV options, then poll for the result. That needs purchases_flutter 10.6.0+, react-native-purchases 10.5.0+, purchases-unity 9.8.0+, or purchases-kmp 3.5.0+.

Ad revenue also doesn't count toward Monthly Tracked Revenue right now, which means the feature is free to use.

The ad monetization docs walk through every step. Point your agent at them: it can read the docs, do the implementation, and debug it when something's off (that’s what I did!).

How to set up RevenueCat Ads Entitlements in your dashboard

1. Create the Entitlement: Product catalog → Entitlements → new Entitlement. I called mine play_game, because that's what it does.

One thing worth knowing: you do not need to attach a product to that Entitlement for ad rewards to work. But you also don't have to choose between ads and purchases for the same Entitlement — you can attach both. A user gets access either by subscribing or by watching an ad, and your code only ever checks one thing: is play_game active.

Say you're running a Pro tier that gates your whole app behind a subscription. Attach an ad reward to that same pro Entitlement, and now a non-payer can earn Pro access for 30 minutes by watching an ad, on the exact same Entitlement your subscribers already have.

For an ads-only Entitlement with no purchase path at all, you can skip the product entirely.

2. Create the reward: Ads → Rewards → 'Add entitlement reward'. Pick your synced rewarded ad unit, pick the Entitlement, set a duration.

I went with 30 minutes, which is the lowest amount of time allowed. Watch one ad, play for the next half hour.

3. Wire up verification, then check the Entitlement: On the ad itself you call enableRewardVerification() after it loads, then present it with a rewardVerificationCompleted callback. That callback is where you react to the verified reward. The rewards docs have the full Swift and Kotlin versions.

Gating the game is the same check you'd write for a subscription:

let customerInfo = try await Purchases.shared.customerInfo()

let canPlay = customerInfo.entitlements["play_game"]?.isActive == true

You don't have to refresh anything yourself. Before it hands you the result, the SDK already refreshes customer info for an Entitlement reward and invalidates the virtual currencies cache for a currency reward. We’ll just want to make sure we check this value each time before we allow the user into the game.

That's it! Watch ad → Entitlement active → button goes live → 30 minutes of aggressive parking decisions.

Or, grant virtual currency instead of a timed Entitlement

Duration-based isn't always the right shape. If 30 minutes of access doesn't map to how your app works, use virtual currency instead: 10 coins per ad, 10 coins per game. Users can stack up a balance, spend it how they want, and you're not fighting a timer to model something that isn't time-based.

An ad unit can have one virtual currency reward and multiple Entitlement rewards at the same time, and completing the ad grants all of them together. So you can hand out coins and open up access from a single view if that's your design.

When rewarded ads are the wrong call

A rewarded ad only helps you if it's not replacing a sale you'd have made anyway. If someone would have subscribed or paid specifically for the perk behind the ad, don't let them earn that same perk for free by watching thirty seconds of video. However, a subscriber who watches an ad for something extra — bonus currency, a one-time boost, a perk they wouldn't otherwise pay for, is pure upside. More engagement, more ad revenue, nothing cannibalized.

RevenueCat's State of Subscription Apps 2026 found only about 10% of apps run a true hybrid monetization model that mixes IAP, ads, and subscriptions, and it's concentrated in gaming at roughly 4x the average. That's where adoption is today, not where it has to stay. The rewarded ad pattern maps cleanly into non-gaming apps too, and most haven't tried yet. This gap is an opportunity.

Execution is what decides whether it pays off. The reward has to be valuable: earn something people actually want. It has to be discoverable: if it's buried two menus deep nobody finds it. And it has to be repeatable: a reward users come back for compounds, which is where you find the incremental dollars.

Quick tangent… enter Shipaton to win the Catvertising Award!

There's a Shipaton category for exactly this. It's called the Catvertising Award, and it goes to the most creative and effective use of RevenueCat Ads as a monetization method. Judges are looking for clever placements, smart integration with the rest of your revenue stack, and an experience users don't hate.

First place is $20,000, second is $10,000, third is $5,000. The winner also gets a Shippy trophy, an invitation to RevenueCat's App Growth Annual conference in New York City, coverage on 9to5Mac and 9to5Google, and their app on a giant billboard in Times Square.

Two rules worth knowing before you start: the app has to be released for the first time between August 1 and September 30, 2026, and it has to use the RevenueCat SDK for a purchase or for ads. Submissions close September 30 at 11.45pm PDT.

If you've got a game, or any app where watching an ad to keep going makes sense, this is a low-effort category to enter and there's a lot on the table.

See the Catvertising Award category →

Go build something

The thing I keep coming back to: ads and subscriptions were never really an either/or. Now both paths run through the same Entitlement, show up in the same revenue chart, and roll into the same LTV number.

Set it up, then go make something great!

Further Reading

• Track in-app ad revenue alongside purchases
• Blended ARPU Framework: How to Measure Hybrid Monetization
• How subscription apps can use hybrid monetization to capture more revenue

Learn more in the Docs

• Ad monetization overview
• Granting ad rewards: SSV setup, dashboard config, Swift and Kotlin samples
• AdMob ad tracking
• Manual ad tracking: AppLovin MAX, ironSource, Unity Ads, and other ILRD platforms
• Google AdMob integration: connecting your AdMob account
• Virtual currency
• Entitlements
• Ad charts

"We've never sent a lifecycle email. We haven't done any experimentation on our web funnel," says co-founder Luke Martin-Fuller. "We haven't tested any paywalls. We haven't expanded in our geographies. We've not added AdWords or TikTok or SEO or AEO."

Watch on YouTube

One paid channel — Meta, running user-generated creative — carries the entire acquisition motion. Roughly half of new customers still arrive through word of mouth. Visible sells in two markets, the US and the UK. There has been no price testing.

The reasoning is sequencing, not contrarianism. "The thinking really was that unless you've got something of value that is going to be retaining people and helping them, then there's no point investing in all of that experimentation," Martin-Fuller says.

David Barnard, who has lived with a chronic illness for over 15 years and came to the product as a skeptic, puts the failure mode in blunter terms. "A colleague of mine calls them paywall wrappers. If the product isn't real, you just got 60 pages of onboarding that hype somebody up, they subscribe, and then they get zero value and don't retain."

Visible built the free app first and ran it for over a year before charging anyone. It reached roughly 50,000 users on word of mouth alone, with no wearable attached. Every one of those untouched levers is still sitting there, which is a strange position for a $10M business to be in — and an unusually good one for whoever takes the growth role Visible is currently hiring for.

The web quiz is partly there to talk people out of buying

All of Visible's traffic lands on a landing page, then into a quiz that went live in October 2023 and hasn't changed since. Martin-Fuller is the first to say it's under-optimized. But it does one job deliberately.

"The truth is that our product isn't for everyone," he says. "And it would be inconsistent with what we're trying to do in the world to just make people buy it."

The quiz screens for whether pacing — the energy-management strategy the product is built around — is actually the right approach for that person. Some of them get told no.

Barnard's argument for why this isn't self-sabotage is the sharpest passage in the episode: customers who pay but never get value leave worse reviews, kill retention, and feed you misleading product signals about what to build next. "Yes, you may be able to juice conversion, but you're going to kill retention."

The supporting number: median time from first landing on the site to purchase is 10 days. People go away and research. Some of them, Martin-Fuller notes, now send an agent to do it for them. For a considered purchase, a long deliberation window isn't a leak in the funnel. It's the qualifying mechanism working.

Members submit an audition tape, then get paid cash for the ads that ship

Visible runs two creative programs with a team of two people.

The first, Creator Collaborative, works with established creators already in the chronic illness space — compensated on reach or impressions depending on their following. The second, Community Voices, recruits from Visible's own customers. A line in the monthly member digest invites people to join a Slack group. They submit an audition tape. From then on they get a creative brief every week and can send in a video.

The compensation detail is the one worth stealing. "If we use it, then they'll get paid some money," Martin-Fuller says. "And that's cold, hard cash. That's not credits or a discount on a future purchase." It's a flat fee, identical whether the video becomes the top performer or gets $10 of spend and never runs again.

Everything gets tested on small budgets first. Only one or two videos a week ever receive scaled spend.

The program also produced a hire. Visible's social media manager, Gemma, first came into contact with the company when they asked her to make a video. She lives with chronic illness herself and was already an influencer in the space. They enjoyed working with her enough to offer her a job.

Martin-Fuller thinks they're leaving something on the table by keeping all of it inside paid. The approach he wants to test is letting members post the same videos organically on TikTok, unapproved and unbriefed, on the theory that one in a hundred goes somewhere.

The band costs $80 because Visible makes nothing on it

Visible sells a Polar-manufactured armband at roughly $80, bought wholesale, at cost. The subscription is $20 a month, or $14.99 annually.

"We don't make any money on the hardware that we sell," Martin-Fuller says. "The way we deliver value is by building an amazing app experience."

Barnard's reaction on first seeing the price was suspicion — $80 reads as a cheap knockoff until you learn there's no markup on it at all. Which is a real positioning risk, and Martin-Fuller concedes it's worth revisiting.

He lays out three models the team looked at. Charge a lot upfront for the device and keep the recurring fee low — the Oura approach, which works partly because a ring functions as jewelry, and where a premium ceramic variant makes the standard one feel affordable by comparison. Price everything into a single rolling membership and never mention hardware cost, which is Whoop's model, though you're still committing to 12 or 24 months upfront. Or take the third path, closer to what dog-tracker company Tractive does: drop the entry barrier as far as it goes and make the money on the ongoing service.

Selling hardware also removed the free trial entirely. You can't give away a physical device, so trial length, trial opt-in placement, and the rest of that playbook are simply unavailable. Visible's substitute is the original free app — still live, genuinely useful, and deliberately barely promoted. One small mention on the website, fed by word of mouth, and it accounts for a large share of acquisition.

The research papers are the part nobody clones

From the earliest version of the free app, Visible let users opt in to sharing anonymized data with researchers. Doing it properly meant informed-consent flows, ethics committee sign-off via an academic partner, and pipelines that strip identifying data while preserving what makes it useful. None of that moved a revenue number.

What it produced was papers in journals including Nature, on using heart-rate data to predict future symptom events, and work with Mount Sinai and Imperial College London on the interaction between symptoms and the menstrual cycle.

For a community that has spent years being disbelieved, and a category crowded with people selling supplements and courses, that record is the trust argument. Visible is careful about what it claims: "It's not a treatment, it's not a cure. It helps you implement a management strategy."

It's also the thing a competitor can't reproduce quickly. Asked about clones, Martin-Fuller is relaxed. "Honestly hope they don't try because they won't get that far."

In the full episode, Luke and David also get into why Visible chose not to announce its Series A, the natural-language AI feature that early access users rejected outright, and how a startup ended up giving product feedback to a company that has been building heart rate monitors since 1977.

Guest links

• Luke Martin-Fuller on LinkedIn
• Visible
• Visible careers

The honeymoon doesn't last, though. AI apps churn at 30% higher rates than traditional subscription apps. The novelty that converts so well wears off just as fast.

Or is there more to it?

The category average doesn't tell us the whole story. Plenty of AI apps are actually retaining at the level of non-AI subscription businesses.

So we went looking for what separates that group from the rest.

The gap between the retention groups

We analyzed 3,519 AI-powered apps using RevenueCat's subscription data and ranked them by how well they retain paying subscribers a year in. We then grouped them into three retention categories: high-, mid-, and low-retention.

→ Here's how we identified and grouped the apps.

High-retention AI apps keep 13.9% of paid subscriptions active after a year, at the median. Mid-retention apps keep 5.3%. Low-retention apps keep 1.4%, a tenth of the top group.

The same ranking holds across all plan lengths:

• On monthly plans, the high group retains 10.9%, compared with an AI-app average of 6.1% and a non-AI average of 9.5%.
• On annual plans, it retains 30.7%, exactly matching the non-AI benchmark and far above the 21.1% AI average.

So, where in the year does that gap build up? Mostly at the first renewal.

On monthly plans, 57.9% of subscribers at high-retention apps renew the first time; at low-retention apps, it's only 30.2%. Later renewals narrow the gap — 79.5% versus 68.5% by the third month.

What separates high- and low-retention AI apps

Here's every trait we measured, ranked by how much more common it is in the high-retention group than the low-retention group:

• Monetization structure: Subscription-only apps are 16.4 percentage points more common among high retainers, while hybrid monetization is 16.3 points more common among low retainers. But a quarter of the best-retaining AI apps still sell consumables alongside a subscription.
• Trials: A 7-day trial runs 12.7 points more common among high retainers; no trial at all runs 23.7 points more common among low retainers. But the value of a trial depends on plan length: it favors trials strongly for weekly plans, mildly for monthly, and much less so for annual.
• Access model: Freemium runs 11.4 points more common among high retainers (66.8% versus 55.4%). That said, hard paywalls are rare among all AI apps, at under 2% of apps.
• Launch year: Apps launched between 2020 and 2023 are 10.6 percentage points more prevalent in the high-retention group. By contrast, apps launched in 2024 or later are 20.2 points more prevalent among low retainers. This could partly be due to the recent AI boom and the influx of new apps that came with it.
• Price: Cheaper subscriptions are 7.3 points more common among high retainers. AI apps in the lowest price band make up 15.6% of the high-retention group but only 8.3% of the low-retention group. One possible interpretation is that proving the value of AI features becomes harder as prices increase.
• Size: Small apps (under 500 paid subscriptions in the cohort) are 6.4 points more common in the low-retention group. But it isn't decisive: 44% of high-retention apps had fewer than 500 paid subscriptions in the retention cohort, and small apps are actually most common in the mid-retention group.
• Category: Utilities and Education lean toward high retention; Photo & Video and Media & Entertainment lean toward low. The likely reason is deeper than the category itself: how naturally the use case turns into a habit.

These are patterns, not proof of causation. Some may simply be consequences of stronger retention: an app that retains well, for example, may have more room to offer lower prices or generous trials.

But the low-retention profile is still striking: newer apps, no trials, weekly plans, and higher prices. It looks a lot like the playbook for turning a spike in attention into revenue quickly, without necessarily giving users a reason to stick around.

"Teams building AI-first apps often focus on improving conversion in onboarding and finding the perfect price, rather than on retention. Many of these apps are barely used long-term, because users came from a trending video showing one specific feature."

How to think about retention for your AI app

These findings don't provide a single formula for retention. Instead, they show what better-retaining AI apps have in common and where product and monetization choices may make a difference.

Three areas are worth focusing on: getting subscribers to a useful result fast, matching your trial to how quickly your product delivers value, and choosing a monetization model that fits your costs.

1. Make value land before the first renewal

AI apps often have a one-and-done problem. Many subscribers come for one impressive result — a selfie turned into a professional headshot, a room redesigned in one tap — get it, share it, and have no reason to come back.

The challenge is turning that first result into recurring value. Start with two questions:

• How quickly subscribers reach a meaningful result
• What gives them a reason to return before renewal

On the first, AI apps have an unusual advantage: they can generate a personalized result from the subscriber’s own photos, voice, or data within minutes. Design onboarding to get users to that first useful output as quickly as possible.

The second is harder: an impressive first result isn't always enough to bring users back. So you need to build reasons to return to the product:

• Outputs that improve as the model learns the subscriber
• Work that accumulates over time (projects, history, a library)
• External triggers like widgets or reminders

"The AI apps that retain do a lot of lifecycle marketing: email, push, special offers for existing users. And above all, organic content — users who enter through that channel arrive warm and already connected to the brand."

→ Your next step: Learn how subscription apps can become painkillers and how emotional value can strengthen retention.

2. Align your trial with your product's value cycle

Our data show that 7-day trials are more common among high-retention AI apps, whereas no trial is more common among low-retention apps.

But it also varies by subscription duration: offering trials is associated with better retention on weekly and monthly plans, while annual plans show the opposite pattern.

To find the right solution for your app, look at how your product delivers value:

• How quickly can someone reach a useful outcome?
• How many sessions does it take?
• Does the value improve through personalization, repeated input, or habit formation?
• What needs to happen before paying feels reasonable?

AI apps have another constraint: every generation costs money. If a longer trial gets expensive, limiting the number of generations can control costs while still giving users enough time to experience the product and come back.

→ Your next step: Read The 7-day trial, and other free trial myths to understand how to define a trial length around your product’s value cycle. Then, calculate the true cost of your AI features.

3. Optimize your monetization model

Subscription-only apps are more common among high retainers in our dataset, but that doesn't mean every AI app should rely on subscriptions alone. A quarter of the strongest-retaining AI apps also sell consumables.

For AI apps, the right model depends partly on how usage drives costs. A hybrid model can balance this by combining a subscription with extra charges for additional generations, credits, or premium features.

It also depends on the product itself and how users experience its core value.

“Fitness and education apps can often justify free trials because they’re closely tied to activation and long-term retention. Many AI apps have a different dynamic: inference costs make trials more expensive, while the core value is often much faster to experience. Generating a video or an image typically requires less commitment than completing a workout or a lesson, so the optimization focus shifts toward maximizing upper-funnel conversion and monetizing access to core actions, for example, charging for additional generations or premium capabilities.”

Whatever model you choose, evaluate its impact over multiple renewal cycles. A monetization change can increase short-term revenue while weakening long-term retention.

→ Your next step: Learn why hybrid monetization is becoming the default model for AI subscription apps and see how AI apps are adapting their pricing models.

What’s next

This research shows that AI apps can both convert better than traditional subscription apps and achieve comparable long-term retention.

But we also want to dig even deeper into how they do it.

As our next step, we’ll talk to the teams behind some of the highest-retaining AI apps to understand what they're doing differently. We'll share what we learn along the way.

How we grouped and analyzed the AI apps

Because an annual subscriber renews once a year while a weekly subscriber renews 52 times, retention was compared within plan length: an app's weekly subscriptions were measured against other apps' weekly subscriptions, monthly against monthly, and annual against annual. Apps selling several plan lengths get one combined score across their qualifying durations.

We then split them into three groups:

• Low-retention group: The bottom 30% of the retention score (1,056 apps)
• Mid-retention group: The middle 40% (1,407 apps)
• High-retention group: The top 30% (1,056 apps)

Retention is based on paid subscriptions started between July 2024 and June 2025, tracked for a full year. That includes both direct purchases and converted trials.

• A subscription counts as retained if it completed every renewal in that year: one for annual plans, 12 for monthly, 52 for weekly.
• We measure at the subscription level, so a subscriber who switches to a different plan counts as a churned subscription.

We also verified that the trait patterns (trials, monetization, price, launch year) hold when comparing high- vs. low-retention apps within the six biggest categories. Health & Fitness is the one exception: there, trials and monetization barely separate high from low retainers. One plausible reason is that the habit is built into the use case itself.

Scope of the data:

• 3,519 AI app configurations (2,633 iOS, 886 Android)
• 'AI-powered' is a classification, and it spans very different products, from fitness coaches to video editors. Ranking apps only against the same plan length and checking the findings within categories addresses part of that mix, and the groups stay deliberately broad
• Paid subscriptions started between July 2024 and June 2025, including both direct purchases and converted trials
• Over 50 million paid subscriptions in the retention cohort
• 11 app categories, from Productivity to Photo & Video, across 7 global regions
• Every app has at least 100 eligible subscriptions, so no group is built on tiny samples

Watch on YouTube

When he started building Sequel — an app to track movies, TV shows, games, and books in one place — he knew he didn't want to spend his days hustling on social media or managing ad campaigns. In fact, he spent a total of $100 on Apple Search Ads before deciding it wasn't for him. Instead, he engineered the app to market itself.

The media detail screen in Sequel isn't just optimized for the person using the app. It's optimized for the moment that person pulls out their phone to recommend a movie to a friend. By prioritizing large, beautiful artwork over dense text, the screen acts as a billboard. "If it looks sleek and polished, I wanted the other person to go like, 'Wow, what is this?'" Romain says.

That single design decision turned his existing users into his most effective acquisition channel.

The $1,000 reality check

The indie developer journey is rarely an overnight success, and Romain's path was no exception. After volunteering for redundancy at his startup job to go full-time on Sequel, the initial financial reality was grim. In the first eight months after launch, the app made just $1,000.

Instead of endlessly grinding without a safety net, he set a hard deadline. He decided that if the upcoming version 2.0 update didn't generate £1,000 in its first month, he would stop and look for a job. Setting that milestone removed the emotional weight of slow growth. It turned a vague period of uncertainty into a clear, binary decision point.

The MacStories effect

The turning point for Sequel didn't come from an App Store feature. It came from the Apple enthusiast community.

Romain had quietly reached out to a few Mac and app-focused websites, resulting in a small newsletter mention that brought in his first wave of real user feedback. But it was the launch of version 2.0 that changed everything. The team at MacStories wrote a full, deep-dive review of the update.

"They wrote about my product better than I could have ever done myself," Romain recalls. They highlighted the exact design details and interactions he was most proud of. That review put Sequel in front of the tastemakers. Shortly after, YouTuber Quinn Nelson (Snazzy Labs) and The Verge's David Pierce both independently noted that Sequel was the most recommended app in their audience replies. The word-of-mouth engine Romain had designed was finally running at scale.

Why a capped free tier is really a trial

One of the hardest decisions in building a freemium app is figuring out what goes behind the paywall. Romain's initial strategy for Sequel was to limit free users to tracking 25 items total. He quickly realized this was a mistake.

As host Charlie Chapman points out in the episode, an app enthusiast who knows they will eventually hit a hard limit stops treating the app as free software. They mentally convert it into a trial. From the first open, they are hunting for the paywall to decide if the eventual cost is worth their time.

Romain eventually pivoted to an unlimited free tier, moving specific features like release notifications behind the paywall instead. The lesson? It's much easier to turn a paid feature into a free one than to take a free feature away from your users.

In the full episode, Romain also talks about how he accidentally became a designer after being hired as an engineer, the existential risk of relying on free third-party APIs, and why writing down your design principles makes it much easier to say no to feature bloat.

Guest links

• Romain Lefebvre on Threads
• Romain Lefebvre on Mastodon
• Sequel on the App Store

We've partnered with AB180 to give South Korean developers hands-on local support and help getting the most out of RevenueCat's tools, backed by a team that already works with some of South Korea's biggest apps and games like NAVER WEBTOON, MUSINSA, Amorepacific, and Nexon.

AB180 is a South Korea-based marketing technology company with over 10 years’ experience in MarTech and AdTech, and the team behind the Airbridge attribution platform. The partnership makes it easier for South Korean app developers to get local support, expert guidance, and access to world-class tools for managing and optimizing in-app subscriptions.

Local expertise, backed by a global platform

AB180 will support all RevenueCat customers in South Korea, from first integration through to scaling monetization, at no extra cost. It's included for every RevenueCat customer in the region.

If you're building in South Korea, here's what AB180 can help with:

• Setting up and integrating RevenueCat across iOS, Android, and the Web
• Moving over from another provider or your own in-house system
• Digging into your performance data to understand what's working and where you stand against benchmarks
• Rolling out RevenueCat's growth tools: paywall builder, web-to-app funnels, and experiments
• Joining a growing network of local developers building and scaling subscription apps

With this step, RevenueCat is continuing to expand its global partner network and empowering developers everywhere to monetize smarter, scale faster, and focus on building apps users love.

Ready to grow?

Our partnership with AB180 is one more step in our mission to help app developers worldwide make more money. If you're a South Korea-based app builder, get in touch with AB180 through our form here to see how they can support your growth journey.

You can also check out our Docs for detailed information on getting started and growing with RevenueCat.

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!