It started with a few whispers, then a handful of tweets. Now, it’s a full-blown trend we can’t ignore. Over the past few weeks, we’ve had several industry figures reach out to us, all asking some version of the same question: “Is Apple killing the toggle paywall?”
Short answer: yes. It sure looks like it
Developer after developer is getting the same rejection notice from App Review, and it’s always about the same thing: a paywall design that includes a toggle to turn a free trial on or off. If you’re using this pattern on iOS, you need to pay attention. This isn’t a drill
What is the toggle paywall?
For the uninitiated: the “toggle paywall” is a paywall design where users are presented with a subscription offer and a toggle switch that lets them add or remove a free trial. In most implementations, the toggle defaults to off – meaning the user sees a plan without a trial. If they flip the switch, they get a different plan (usually weekly instead of annual) that includes a trial period
The mechanic was popularized by Adam Lyttle in mid-2024, when he documented how implementing this exact design doubled his weekly app revenue from ~$2,500 to over $5,300. The numbers were staggering. His introductory offer conversion rate hit 63%, and subscription retention sat at 68%
It was a masterclass in behavioral psychology. The toggle defaulted to “off,” with the cheaper-looking annual plan pre-selected. Users who wanted the free trial had to actively flip the switch, which then moved them to the more expensive weekly plan. Many users, seeing the lower annual price, would just hit “continue” without toggling, skipping the trial entirely and paying upfront. The result? A massive boost in immediate revenue and a higher average revenue per user (ARPU)
It was so effective that it spread like wildfire. Within months, you could see variations of the toggle paywall in apps across the App Store. It became the go-to strategy for developers looking to juice their monetization. We even featured it in our own paywall redesign case studies, where one app saw a 17% boost in ARPU and another saw a 64% uplift in revenue after implementing it
But here’s the thing about patterns that feel a little too effective: eventually, the platforms catch on
The rejection wave
Starting in mid-January 2026, the rejections started rolling in. Axel Le Pennec was one of the first to post about it publicly, sharing a screenshot of Apple’s rejection notice along with a resigned “My app got rejected for that”. Adam Lyttle himself – the man who popularized the pattern – quote-tweeted it the very next day with a simple, three-word eulogy: “RIP paywall toggle”
Since then, the reports have kept coming. Aivars Meijers, Sergey, Ingo, and others have all shared their rejection stories. A Reddit thread about it has dozens of developers confirming the same experience. It’s not an isolated incident – it’s a pattern
The rejection notice from Apple is brutally clear:
Guideline 3.1.2 – Business – Payments – Subscriptions
The purchase screen includes a toggle to add or remove a free trial from the subscription purchase. This design is confusing and may prevent users from understanding that they are committing to an auto-renewing subscription that will begin charging them after the free trial period.
Next Steps: Remove the toggle for adding or removing a free trial from the subscription purchase screen. Users should be presented with a clear subscription offer that explicitly states whether a free trial is included.
No ambiguity there
Why now?
So why is Apple cracking down on this now, after the pattern has been in wide use for over a year?
The honest answer is: we’re not 100% sure. Apple hasn’t published an explicit policy update or blog post about it. But we can connect a few dots
First, Apple has been on a broader mission to clean up subscription practices for a while. Their guidelines on subscriptions (3.1.2) have always emphasized transparency, and their scam-prevention rules (3.1.2(a)) specifically call out apps that “trick users into purchasing a subscription under false pretenses” [10]. The toggle, with its default-off state, arguably falls into that bucket. A free trial that you have to opt into via a hidden toggle is, from Apple’s perspective, a trial that most users will never see – which defeats the purpose of offering one
Second, the pattern became too popular. When a handful of indie apps use a clever design, it flies under the radar. When thousands of apps across the store are using the same mechanic- and when YouTube videos about it are racking up tens of thousands of views – it gets noticed. Apple’s App Review team is clearly aware of the trend, and they’ve decided it crosses the line
Third, and perhaps most importantly: users were getting confused. The whole point of the toggle was that many users wouldn’t toggle it. That’s not transparency – that’s obfuscation. And Apple, whatever you think of their policies, has a legitimate interest in making sure users understand what they’re signing up for
The plot twist: It’s only dead on iOS
Okay, so the toggle paywall is dead. Pour one out. We hardly knew ye
But wait – it’s dead on iOS. And that’s an important distinction
As of today, there is no indication that Google has any issue with this design. The same goes for web-based paywalls. If you’re running a multi-platform app, the toggle might still be a viable, high-performing strategy on Android and the web
This is where having a flexible, remotely configurable paywall setup becomes essential. With a tool like RevenueCat, you can use Targeting to display one paywall on iOS (compliant, toggle-free) and another on Google Play or the web (the classic, high-ARPU toggle design). Don’t throw the baby out with the bathwater – just make sure you’re showing the right paywall on the right platform
What to test instead
So, what’s an iOS developer to do? Get back to the drawing board. The good news is that there are plenty of high-converting, fully compliant paywall designs to test. And some of them might actually convert better than the toggle ever did
Here are the patterns we’d recommend testing first:
1. The “honest” timeline paywall
This design, popularized by Blinkist, shows a clear, step-by-step timeline of what happens after the user taps “Start Free Trial.” Something like: Today: Full Access → Day 5: Reminder → Day 7: You’re Charged. Blinkist reported a 23% increase in conversion rate and a 55% drop in complaints after implementing this pattern. It builds immense trust, and in many cases, trust converts better than tricks
2. The multi-package selector
Instead of toggling a trial on and off, present multiple subscription packages side by side – say, weekly, monthly, and annual. Badge the one that includes a trial. Users select the package they want; no toggle needed. The trial is inherent to the package, not a separate mechanic. This uses classic price anchoring to make the annual plan (with the trial) the obvious choice
3. The value-first paywall
This approach front-loads the value proposition. Strong visuals, benefit-oriented copy, social proof, App Store ratings – all before the user ever sees a price. When users are genuinely convinced of the value, the friction of payment decreases significantly. Shift the conversation from “how much does it cost?” to “what am I getting?”
4. Personalized paywalls with conditional visibility
This is the more sophisticated play. Use conditional logic to show different paywall content based on user attributes – like whether they’re eligible for an introductory offer. If they are, show trial messaging prominently. If they’re not, show a direct purchase flow. No toggle required, and the experience is tailored to each user. RevenueCat supports this through Targeting and conditional visibility in our paywall builder
5. The exit offer
What if you could get a second chance to convert a user who’s about to leave? That’s the idea behind an exit offer. When a user dismisses your paywall, instead of just closing the screen, you can present them with a different, often better, offer. Think a lower price, a longer trial, or a monthly plan after they’ve rejected an annual one
We just shipped this feature in our Paywall Builder. It’s all configured remotely, no code changes needed. It’s a great way to capture intent that would otherwise be lost. But be careful: Apple is also getting stricter on instant paywall abandonment offers, so test this one carefully and make sure it doesn’t feel like you’re trapping the user
6. The web purchase button
Here’s a curveball: route your US-based iOS users to a web checkout entirely. You avoid Apple’s 30% commission, you have full control over the purchase flow, and you can design whatever paywall you want – toggle included – because Apple’s App Store guidelines don’t apply to web purchases. Note that you still have to include in-app purchases in your in-app screen, but you can offer a discount on web (or increase your prices in-app) to nudge people towards the web option. We’ve shipped a Web Checkout Button component that makes this easy to test. The results have been… interesting.
| Alternative | Key benefit | Compliance risk |
|---|---|---|
| Timeline / “Honest” Paywall | Builds trust, reduces refunds, proven conversion lift | None |
| Multi-Package Selector | Clear, uses price anchoring, no toggle needed | None |
| Value-First Paywall | Shifts focus from price to value | None |
| Personalized / Conditional Paywalls | Tailored experience per user segment | None |
| Exit Offer | Second chance to convert abandoning users | Low (if not overly aggressive) |
| Web Purchase Button | Full design freedom, avoids 30% commission | None (web rules apply) |
The key is to start experimenting now. Don’t wait for your next app update to get rejected. Proactively test these alternatives and find a new champion for your iOS paywall
One more thing
Here’s an interesting data point that might ease the pain. Ludwig Henne, founder of Fits, ran an A/B test comparing a Adam Lyttle-style toggle paywall against a Blinkist-style honest paywall. The toggle paywall won on ARPU (+19%), but when he isolated the toggle mechanic specifically, he found that the toggle itself wasn’t the main driver. The real conversion lift came from the visual hierarchy: normalized yearly pricing, a “Most Popular” badge, and a larger UI for the annual plan
In other words, you might be able to remove the toggle and keep most of the revenue gains – as long as you maintain the other design elements that made the paywall effective. The toggle was the headline act, but the supporting cast was doing most of the heavy lifting
The end of an era
The death of the toggle paywall on iOS marks the end of an era. It was a wild ride, and it made a lot of developers a lot of money. But the App Store is Apple’s house, and they make the rules
Ultimately, this is probably a good thing for users. And what’s good for users is, in the long run, good for the ecosystem. It forces all of us to be more creative, more transparent, and more focused on communicating the genuine value of our products. The best paywalls have always been the ones that make users want to subscribe, not the ones that trick them into it
So pour one out for the toggle paywall. And then get back to testing