August 19, 2021
14 min read
80% of purchases are made via the first paywall, that’s why A/B testing for paywalls is crucial for finding a working business model for a subscription-based app as fast as possible. However, paywalls are deeply regulated by Apple, and often intuitively right versions don’t make it past the moderation process.
In this article, we’ll take a closer look at the Apple guidelines for mobile paywall design and cover the rules you should follow to pass the app review. We’ll also show you a few examples of well-done paywalls with the ideas you can borrow, as well as the paywalls that use tricks you’d better avoid.
The paywall roughly can be divided into seven elements:
It can be a picture (inside text or background), or it can be a video. Some applications avoid paywall media altogether, including business media, whose audiences expect specific informational and educational benefits. Here are a few examples:
You can always find more examples in our paywall library.
In other words, do you or do you not give partial access to the functions of your app before the first payment. Whether to use a hard or soft one is more of a business decision rather than an App Store guideline, but it’s a nice element to run A/B tests with. Also, some developers immediately offer a second paywall screen right after the user closes the standard one, with more favorable conditions or an extended trial period.
Hard paywall improves conversion to purchases, but doesn’t allow the user to use the application for free. So there is a risk of a high churn rate. Soft paywall is more difficult to monetize, but users don’t fall off immediately at the start, so you can try to sell your subscription once again later.
Text is very important for the paywall, as it should explain to the user why they ever must make a purchase. Make sure to provide a catchy and easy-to-understand title to hook your potential subscriber. The description should give as much useful information as possible, so use it wisely:
You don’t have to use all of these together in one paywall, just think of what could work best in your case and experiment further by substituting one element with another if something doesn’t work.
You must indicate the duration and full price of the subscription. Depicting the price for a time unit remains up to you, but then the full price must be underlined more vividly in case you opt for this option. Auto-renewal cannot occur more often than once a week and less often than once a year. The currency must be localized. If an introductory price offer or a trial is used, then you also need to specify the standard price applied after the end of the offer. All subscription options must be available on one screen. You can change the layout, order, shape of badges, make the switch between options using swipe, etc.
You can experiment with price and subscription periods. Apple allows you to use a week, a month, two months, three months, six months, and a year.
Our case studies show real life examples of how running A/B tests with subscriptions affects monetization.
Prosto noticed that it was uncomfortable for the users to subscribe for a year at once, so they added a 6-month subscription which led to the + 30% revenue increase.
OctaZone increased the price of their annual subscription and added a three-month subscription. As a result, they got + 30% to LTV.
There is relative freedom: the design of badges is not regulated in any way. You can also use words like Best Value, Most Popular, etc., which actually affects conversions.
“Continue” button. Also known as “Subscribe” or CTA-button, it provides a lot of flexibility: color, wording (Subscribe Now / Subscribe for $9.99 / Start with 3-day trial), shape, and so on. The subscription can be activated either by clicking on this button or by clicking on the offer itself.
In addition to the usual paywall, you can also test non-standard options. You can experiment with the same elements in introductory offers, promotional offers, and upsell paywalls, which offer the user a more premium plan.
The free trial enables your users to use your app for free for a certain period of time with access to all or a limited number of features, which gives a lot of room for experimentation:
Subscribe to our Paywall Newsletter to get fresh ideas for your paywalls every month.
Apple is pretty serious about its guidelines, so it’s not something you should take lightly. We’ve prepared a few pieces of advice to help you easier pass the reviewing process.
As we already mentioned, the paywall is the place where the user makes their mind to purchase the subscription or leave the app and look for some alternative. So make sure to provide them with as much useful information as possible. They want to know what they are paying for, so mention all the benefits of your app or show which “problems” they can solve with it.
This is something the App Store looks closely at when reviewing apps, and also something your potential users may get angry about if you decide to get tricky. You can always mention discounts and cross out old prices, but the final price you mention on the paywall must strictly coincide with the price of the purchasable product.
Another trick that some like to use is to get unclear about the billing period of the subscription. For example, they mention the price in the form of “$X.XX/month” on the paywall while actually selling the annual subscription which the user gets billed for immediately after the purchase. However, if you have both annual and monthly subscriptions, you may put the price description for the annual product in the way “$X.XX/year which is $Z.ZZ/month”, to show how this price is more beneficial than the monthly one, and you may get past the review. But to avoid misunderstandings, reviewing issues, and anger from your potential users, we recommend to state clearly the billing period of the subscription products you offer.
If you decide to add a free trial as an introductory offer to your subscription, make sure to mention the period it will be active for and what price the user is expected to pay after it ends.
Through the years, the strictness towards the text on the CTA button has been getting softer. A few years ago your app could get rejected for the button saying “Start your free trial”, provided that you offer a subscription with a free trial, but now it’s a way to go, along with more usual Continue, Activate, or Buy. But we advise you to stick to these standard variants, if you don’t want to get rejection troubles.
Not long ago, the App Store demanded additional information on the paywall screen: among others, an indication that the subscription is automatically renewed if auto-renewal is not disabled within 24 hours before the end of the period, or that the subscription can be canceled in the account settings. Now, this isn’t necessary, but many developers have kept these small-sized paragraphs “just in case”.
To have a better understanding of what a proper paywall should look like, we’ve prepared a few examples that perfectly illustrate transparent benefits, clear pricing, descriptive work of trial period, and more.
It’s a good example of a well-optimized paywall. It clearly states that the user gets a trial with any option they may choose and shows the discount for the yearly plan (both in percent and in the strikethrough text).
This paywall features all the necessary information, even beyond requirements. It provides a prolific explanation of the trial work, specifies the amount of money the user will have to pay after the end of it, and shows 3 clear plans to choose from.
Another great example of a user-friendly paywall: transparent display of benefits, clear explanation of the trial and the overall cost, plus a trial end reminder, which is a rarity.
Apart from seeing what a proper paywall looks like, it’s also worth checking real-life examples of the paywalls you shouldn’t look up to. They somehow managed to get through the review but it’s more of an exception. Even if your app manages to get past the reviewer and get published while having pretty evident issues on its paywall, it still can get temporarily withdrawn from the market or even banned later. This can happen if the users of your app find your paywall inappropriate or even fraudulent and start leaving comments in the App Store lowering its rating – that’s when Apple is sure to take another closer look at your app. So by no means we recommend trying to be tricky with the moderation like the following apps did.
This app seems to be pretty tricky, as it shows absolutely no information about the prices and billing periods on the paywall until you click the large “Enter” button. Shall we mention that it’s far from being user-friendly?
This paywall looks decent at first glance, but if you seriously decide to purchase its subscription, you’ll probably get confused about the real price you’ll have to pay. You might want to use that special deal that offers 6 months for $39.99 which looks pretty beneficial in comparison with the 3-month subscription that goes by $29.99. But it’s hard to notice the subtext for the special deal mentioning that 6 months after you’ll be paying $39.99 for the same 3 months. It’s a clear dark pattern case that you’d better stay away from if you want to pass that review.
Another example of using dark patterns combined with a rather weakly executed paywall. For some reason they couldn’t fit all the essential paywall elements on one screen and added more confusion with the “Start Free Trial” button, which doesn’t start anything but takes you to another page instead. But the most important issue here is the “2 months free” offer for the annual subscription, which simply doesn’t exist. It’s just the way they decided to tell the user of the overall advantage of purchasing the annual subscription – you’ll have to pay $19.99 instead of $23.88 if you chose the monthly one and used the app for a year. But there’s nothing like a 2-month free trial, only the standard 2-week one. So you should be more clear in the way you express this or that idea on your paywall, especially concerning pricing, if you don’t want to get a storm of hate towards your app.
If a mistake was found during the review process, your app just wouldn’t make it to the App Store.
If you have adjusted your paywall remotely and broken the rules bypassing the moderation process, the ramifications could be the following:
How can the changes be noticed after the review? Users can tell Apple themselves, or a random inspection could occur.
Anyway, adjusting paywalls is OK. Just don’t break the rules.
On average, Apple’s guidelines receive major updates every six months. You can follow them on the Apple Developer site under Human Interface Guidelines (interface requirements), and the Subscriptions page (general guidelines for subscription mechanics). However, App Store guides are not always relevant, and it’s more reliable to track more actively updated documents, such as the Paid Application Agreement, available in the developer’s iTunes Connect, and the App Store Review Guidelines.
The App Store focused on the subscription model back in 2017. Since then, the review policy has changed dramatically, hitting hard on the number of transactions that the user makes by accident, but this achievement has a downside, including the highly regulated mechanics of offering subscriptions. Nevertheless, in the current state, Apple leaves a lot of flexibility for applying engaging solutions, leaving developers the opportunity to stand out, including the paywall screen – and such opportunity, of course, should be utilized properly.
A/B testing is essential in pursuit of the best possible paywall. With Adapty, you can configure different prices, trial periods, promo offers without app releases. With a 7-day free trial, it’s worth checking out.
Apple says that 90% of submissions are reviewed in less than 24 hours, however reviewing the very first version of an app can take up to 1 month in some cases. If your app has already gone through the initial review, you don’t have to send the whole app to be reviewed once again, just check the elements you changed (e.g., subscription options or the paywall itself) when initiating the reviewing process.
There are many reasons for this, from technical issues to violating Apple guidelines. The reviewer usually mentions the general reason for rejection, but doesn’t always specify what exactly needs to be changed. If the reason lies in violating human interface guidelines regarding in-app purchases, here’s what you may have done wrong:
In brief – yes, you do. Stick to the rule to not hide anything from the reviewer.
There are several variants you may try:
August 19, 2021
14 min read
May 5, 2022
5 min read
July 22, 2020
38 min read