How Apple’s In-App Purchase Guidelines Stifle Mobile SaaS Innovation
Since the advent of the App Store in 2008, mobile developers have been griping about the iron fist with which Apple rules it’s distribution platform. Though Apple’s “Walled Garden” approach to app distribution has resulted in a great, consistent, high-quality experience for end-consumers (the same cannot be said of it’s Google counterpart), their strict mandate on how payments conducted inside applications is now stifling the development of mobile-first software-as-a-service (SaaS) platforms.
Apple’s In-App Purchase Guidelines
Apple’s guidelines state that if your app charges a subscription fee where users pay on regular (or even irregular intervals) for the use of software (i.e., the app), then these subscription payments must run through the App Store’s In-App Payments (https://developer.apple.com/in-app-purchase/In-App-Purchase-Guidelines.pdf).
This is particularly relevant to SaaS companies since these companies’ business models, for the most part, are built upon the concept of monthly or annually recurring revenue collected through subscription payments. Since users of SaaS software are paying for the software (and not some physical good purchased on the app), SaaS software falls squarely into the category of applications that have to run payments through In-App Purchases.
Heres the catch: Apple takes a 30% cut of all payments made via In-App Payments
Right off the bat, SaaS mobile apps on the App Store that require subscription payments must fork over 30% of their topline revenue to Apple. In a world where a fraction of a percent can make or break a company (e.g., companies will fight for 0.1% decreases on payment processing fees), giving away 30% of revenue is not financially prudent for most large companies.
SaaS companies are hit particularly hard with this because the requirement to use In-App Payments only applies to companies where users are paying for the software itself. For example, an app like HotelTonight (where one can book hotel rooms), isn’t required to use the In-App Payments system because users pay for the hotel room, not for the software itself.
Necessary workarounds are stifling real progress with mobile-first or mobile-centric SaaS platforms
For most established SaaS companies, the 30% fee is a nonstarter (and let’s not even talk about the hassle of having to develop a platform-specific payments system). As a result, most SaaS companies have to intricately work around this by:
- Offering a web-based core product on which users sign up for and pay for their subscription using their own payments system (as soon as you introduce subscription signup without In-App Payments into an iOS app, you will get rejected by Apple’s review committee)
- Ensuring that the mobile product is an “add-on” to the web product so that when users pay the subscription through the web, they paying for the web functionality specifically and not the mobile “add-on”.
Take a look at any big subscription-based SaaS company’s mobile app and you’ll notice that:
- They don’t actually let you sign up for the service from the app (in fact, they’re not even able to link you to a website in order to subscribe and pay because Apple will reject apps that do that as well)
- The feature set on the mobile app is significantly less robust than that of its web counterpart — i.e., it is an “add-on” and not a full application.
The Shopify iOS app is a great example of this — users must sign up and go through onboarding/setup process via the website. When comparing the web application vs. the mobile application on a feature-by-feature basis, the mobile application is clearly lacking the robust feature set that its web counterpart offers.
Apple’s In-App Payment Guidelines are a major obstacle to truly entering an age of mobile SaaS technology
I firmly believe that in order for us to see real strides in innovation with mobile SaaS products, the following changes need to occur (assuming the App Store remains as one of the de-facto methods of mobile app distribution):
- Apple needs to lower its fees for In-App Payments for SaaS software subscription apps.
With 30% lower revenue on any mobile-first SaaS product, companies are highly incentivized to focus on building a core web product instead. Sure, the argument can be made that good mobile SaaS solutions might warrant a higher price tag, which allows companies to maintain their profit margins. There will be companies that can prove this premium value to their customers — however, most will not be able to stomach the 30% hit.
Even for these mobile-first companies that do manage to charge a premium to offset their payouts to Apple, going cross-platform is an issue. The moment you introduce a web app into the fray along with a mobile app, you MUST charge the same price for the mobile subscriptions as the web subscriptions; meaning any subscription that comes through the mobile app is worth 30% less than the web. This incentivizes companies heavily to drive all of their traffic to their web application.
Lowering the fees is not an outrageous proposition. In fact, in 2011, when the 30% fee was introduced, Steve Jobs stated that “We created subscriptions for publishing apps, not SaaS apps.” The vague nature of this statement led to a lot of questions (see http://techcrunch.com/2011/02/22/jobs-subscriptions-publishing-apps/) and it now seems that most SaaS companies are required to pay the 30%.
- Apple needs to provide developers a better way to get feedback on a proposed feature set or application architecture.
When looking to get clarity from the Apple developer support team around the feasibility of innovative payments & subscriptions solutions for SaaS products, Apple’s firm response is always:
We are not able to preapprove proposed app ideas or concepts without reviewing the app itself. Therefore, we recommend that you submit your app for review.
Essentially, they want you to build an application first, submit it for review, and then cross your fingers and hope that your application is deemed fit and compliant for the App Store. They will not comment or give guidance on any proposed set of features or application architecture in advance of having the code uploaded to them.
No wise developer or company will spend months building an entire mobile application just to test if Apple will approve the product. Instead, one is always incentivized to focus on building a core web product first and then building a mobile product as an “add-on”, almost as an afterthought.