Lately, I released my first visionOS app. Actually, my personal deadline was the US release date (2nd of February 2024) and gladly everything worked out. You can read a little bit about it in my other article: https://mic.st/blog/develop-and-release-a-visionos-app-without-vision-pro/. One thing I struggled a little bit the last few days before submitting it for app review was the question: How do paywalls actually look like on visionOS or VisionPro?
Do they have to be somehow different to the commonly known paywall (e.g. see the great collection at https://www.paywallscreens.com/ as a reference) ?
What am I doing with all the space available?
Do we have to somehow make them “spatial” (whatever that means), i.e. see https://superwall.com/blog/a-new-frontier-of-app-monetization-spatial-paywalls ?
I will somehow try to give a few of my thoughts on this but also a little bit of monetization and pricing in general in this article.
Why monetize at all (as an indie developer)?
A lot was written about that already, e.g. see https://www.swiftjectivec.com/pricing-indie-ios-apps-according-to-perks-of-a-wallflower/. Basically to me it all comes down to: Do not undersell yourself, your work or the result of your work which is your app.
I am barely listening to any podcasts, maybe one or two times a year but what actually made it click for me was a “SubClub” episode with Jake Mor (founder of Superwall, see https://superwall.com/).
You can find the episode I am talking about here: https://www.everand.com/listen/podcast/614439392.
Unfortunately, the sound quality is not so great but I do really recommend listening through all of it if you just started with thinking about monetizing your app. Most important for me was him talking about a lot of apps / developers just miss to show the paywall to 100% of the people opening the app. Which you can easily fix by just showing it right after startup or onboarding.
My ten points when it comes to monetizing your app
Here is some advise I learned from reading and testing stuff regarding paywalls or monetizing:
- You are spending time on developing and it’s totally fine to charge for it.
- People are probably willing to pay more than you initially think (see also chapter “Pricing” in this article)
- Aim for subscription strategies with trials and annual subscriptions when it comes to monetizing.
- Do show your paywall as early as possible. If before or after the onboarding (if you have this) works better should be tested. I currently do show it after the onboarding for my apps but I’m planning to test this as well in the future.
- Annual subscriptions should always have a discount when compared to monthly subscription.
- When using multiple plans, consider anchoring, i.e. “Save 42% with the yearly plan”.
- Do show the calculated monthly price for the yearly plan so that people can compare more easily.
- Set up at least monthly, six month and annual plans. Having all of the setup early, makes testing different paywall offerings easier later on.
- Present more than one option on your paywall. But also test this.
- Finally, of course do not violate App Store review guidelines, do not use dark patterns. Everything you need to know is presented with nice graphics in Apple’s Human Interface Guidelines (HIG), see https://developer.apple.com/design/human-interface-guidelines/in-app-purchase. If you do miss the absolute minimum which basically is the link to terms and conditions and restore purchases, they will tell you during review anyway.
Pricing
The psychology when it comes to pricing is a huge topic on its own. Essentially, when you do price too cheap, your app’s quality might also be expected to be cheap. Here is also a short take on this by Jordan Morgan: https://www.swiftjectivec.com/pricing-indie-ios-apps-according-to-perks-of-a-wallflower/
If you want to deep dive on pricing, there is also this book:
Monetizing Innovation: How Smart Companies Design the Product Around the Price
by Madhavan Ramanujam and Georg Tacke, see https://www.goodreads.com/en/book/show/30121516
If you do not know where to start with your price, look for competitors and consider charging a little more. Charging less than a competitor might work in the supermarket but it’s not the deciding factor for most customers when it comes to subscribing to an app’s plan. As mentioned earlier, lower price might just be expected to be lower quality. Besides that there is the simple math of ten customers paying 10 € per month is better for your revenue than ten customers paying 5€.
When it comes to discounts of annual plans and you do not have a clue about where to start: A lot of pricing / subscription service companies do publish articles about their customers’ mean data, e.g. see https://www.paddle.com/blog/annual-vs-monthly-billing or https://recurly.com/blog/monthly-vs-yearly-pricing-an-analysis/ both of these articles do mention something between 10 – 30 %. To get the most out of your discount strategy, test it.
Testing
A couple of times I wrote about testing your monetizing strategy. So, what does that mean? As an indie developer you probably do not have the budget to start with huge pricing research (what is recommended to a degree in the book mentioned above).
What you can do is ask potential users, e.g. on reddit or on X what they would be willing to pay. That might work in theory but in the end these are by far real users of your app. Personally, I never did that and I guess you are quicker if you just start with any pricing mentioned in the articles above and test on production.
RevenueCat
Essentially, you want to be able to do some kind of A/B testing on production users. If you do not want to setup your own infrastructure for doing that, you can do that easily with RevenueCat (see https://www.revenuecat.com/). What they and similar companies offer is a so called remote paywall, i.e. a paywall that can be configured remotely without having to go through App Store review for every change.
In general it is a great service for managing payment flows. Their feature “Experiments” is part of their premium plan where you can test different “offerings” against each other. An offering is basically a set of products that can appear on your paywall. This offering can be directly rendered on a remote paywall delivered by RevenueCat’s SDK or you can define your own JSON sent out via their servers.
Luckily, their premium plan does not cost you anything up to 2,500 € monthly recurring revenue. Everything is really easy to setup and their docs are really great. So, 100% recommended.
Testing ideas
So, what to test? Here are some testing ideas:
- Location of your paywall, e.g. showing it before of after the onboarding
- Layout of your paywall, e.g. Blinkist style (“This is how your trial works”) vs. Bumble etc. (offering multiple products), see https://www.paywallscreens.com/ as an inspiration for different layouts and contents of paywalls.
- Hard vs. soft paywall, i.e. are users able to use your app at all without choosing any plan
Some more finer grained tests:
- Number of products on your paywall
- Different lengths of trials (requires setup in App Store connect)
- Different prices (requires setup in App Store connect)
- Videos on your paywall (e.g. Jake Mor really recommended doing that together with a hard paywall)
- Wordings, Colors (e.g. the continue button’s color) order of elements
Regarding Remote Paywalls
One last thing: Remote paywalls might be considered as kind of a gray area.
Of course you need to update your paywalls screenshot whenever you change it after testing it. You should definitely not use remote paywalls for circumventing app store review. This means if you are introducing dark patterns later on remotely and they find out, your app might be kicked out of the store (for good reasons).
Worst case your whole developer account might get blocked for violating the rules.
Differences for paywalls on visionOS or Vision Pro
Given you have done your homework in general you should now have an idea of the concept of pricing, monetizing and mobile paywalls. The important thing here is mobile paywall, i.e. the question is: Is there a difference on visionOS and if so what is it? As of now most of paywall adivce was written before the release of Vision Pro and its operating system visionOS. This means we have to look around somewhere else.
Some first thoughts by Jordan Morgan on paywalls on visionOS or Vision Pro you can find also here: https://superwall.com/blog/a-new-frontier-of-app-monetization-spatial-paywalls.
Initially, I thought as I have a lot of space I will just show a lot of stuff I would also shown on an iOS paywall. This means, basically use the same layout you would use for any iOS paywall and maybe increase some font sizes.
This will give you a working paywall and if you use some of the native visionOS features it might even look nice (see my other article for things like glass backgrounds or adding depths: https://mic.st/blog/develop-and-release-a-visionos-app-without-vision-pro/).
Apple itself does not have any special platform considerations yet for visionOS. The HIG just say: “No additional considerations for iOS, iPadOS, macOS, tvOS, or visionOS.” (source: https://developer.apple.com/design/human-interface-guidelines/in-app-purchase, visited on 2024-02-13). I will guarantee though, that they will update this in the future. As this platform and its own forest of paywalls still needs to evolve throughout the years.
However, what Apple already offers is a brand new HIG entry of “Eyes” as means of input, see: https://developer.apple.com/design/human-interface-guidelines/eyes. This is a great starting point for any of their textual and WWCG video content when it comes to what they do call “spatial design” or “spatial layout”.
In production example of BeatFabrik’s paywall
BeatFabrik is my first visionOS app for Vision Pro and it has a paywall. I released it right on the release date of the Vision Pro so I already have some paying subscribers. A little bit more on the app itself you can read here: https://mic.st/blog/develop-and-release-a-visionos-app-without-vision-pro/ or of course you can download it in the App Store as well https://apps.apple.com/us/app/make-music-with-beatfabrik/id6475737516?mt=8
Now, let me share a screenshot of BeatFabrik’s current paywall with you and my thought’s behind it.
What do we have here?
Most basic requirements
It has the most basic requirements according to their guidelines and derived from their HIG regarding in app purchases.
- I.e. prices are shown as charged later
- Trial lengths (the text above the button changes depending on the selection)
- Buttons for seeing terms and conditions and restoring purchases are there
Hard Paywall
It is a hard paywall, i.e. you either have to choose any (trial based) plan or you cannot use the app itself (besides onboarding)
I actually thought about starting with a soft paywall and hiding some features. However, the main thing for not going that route: I did not had much time before the release and also I never tried a hard paywall before. So why not? However, I might experiment with a soft paywall later on though.
Right after the onboarding
It is shown right after the onboarding
The onboarding itself quickly teaches the user the navigation of the app. It is basically how to scroll around the piano roll, add, move, delete notes and change lengths of notes.
My thought was to offer at least “some” interaction within the onboarding that might feel nice and lead to conversions of people wanting to try more with a trial.
Content placed around the center
The most paywall’s important content is placed around the center.
- My preferred subscription plan is the annual one (as described earlier)
- The continue button is placed slightly off-centered but has more color contrast for better visibility
- Free trial and possibility to cancel anytime is mentioned right above the button and also more towards the center
Keeping distractions low
I tried to keep distractions low. There are now animations, jumping texts or videos. I did not go crazy with the colors. The only colored thing is the gradient in the title so that the whole screen is not too boring. The other thing is the blue button.
However, I want to test a walkthrough video at some point.
Simple interactions
Everything on visionOS is rather new so I tried keeping the interactions really basic.
There is no scrolling content, just look and tap. I thought this would be the easiest and least straining gestures.
Also I did not cram a lot of text onto the paywall as I thought scrolling and reading might not be the most enjoyable thing on the Vision Pro.
Huge radii
First of all you should not have anything without a radius anywhere on an interactive element on visionOS. Round elements are just more comfortable to look at. Also HIG tell you very explicitly:
“In general, give an interactive item a rounded shape. People’s eyes tend to be drawn toward the corners in a shape”
I started with way smaller radii for everything on the paywall (and also the whole app). It just starts to fell better (at least in the simulator) as soon as you do increase radii. Maybe a circled “Continue” button could also be the way to go. Note to myself: Let’s test this!
Borderless vs prominent buttons
Bordered or prominent buttons are used for the most important things
When looking around the UI, border-less buttons are still visible via a subtle hover effect that appears whenever looking at them (see my other article for an example video: https://mic.st/blog/develop-and-release-a-visionos-app-without-vision-pro/)
Therefore, I went with border-less buttons for the big squares representing each plan and also the mandatory terms and conditions and restore purchases buttons at the bottom. By that I could use bordered or prominent buttons for the most important things (i.e. the continue button).
Final thoughts
That is all from my side so far, I hope you learned something!
Right now it seems like a lot of experimenting, in near future there will be more articles appearing about paywalls on visionOS or Vision Pro. When I have some more insights after experimenting / testing in my own off course I will happily update the article.
Happy coding!
