So you’re building an iOS app. Great! Let’s get to the brass tacks; how are you going to make money on it? Will there be some kind of purchasing ability within the app?
If your app is going to be anything like the majority of the 1.6 Million apps in the App Store, whose in-app purchases account for nearly $24 Billion annually - you need to know how purchasing works on iOS.
In-App Purchases vs. Apple Pay:
Apple has built two ways to pay for things directly into iOS: Apple Pay and In-App Purchase (IAP). Apple Pay is similar to a credit card transaction: it takes a small percentage of the transaction, plus a flat-fee. IAPs use the iTunes store purchasing system, and therefore take a 30% cut on all purchases, whether they’re one time uses or subscription based.
Based on the fee structure alone, it sounds like you’d be a fool to not go with Apple Pay. Well, the plain truth is you can’t use Apple Pay everywhere. In fact, unless you fall into a few specific use cases, you can’t use Apple Pay, or any other payment processor, at all.
Taking a Deeper Look at IAP - It’s important!
Regardless of whether you’re a CEO or a developer, do yourself a favor and read up on the purchasing guidelines for IAP and the ones for Apple Pay too. It’s important to understand the specific rules, so you don’t find yourself crashing into a brick wall later.
The gist is: any time you offer new/renewing content that users will pay for in-app (like news articles), they must be processed via IAP. Similarly, if you want to restrict some functionality, such as “Pro” features, that must be IAP. Finally, if you want to sell tokens/credits/gold coins/gems or whatever as consumables in a game or other service, they also must be through IAP.
One of the toughest decisions to make is whether or not to process subscription sign-ups through your app - or somewhere else like your website (more on that later). If you do decide to allow purchases within the app, then those must be through IAP too.
Given the fact that every In-App Purchase gives Apple a 30% cut, it can throw a really big wrench in your business plan if you aren’t expecting it.
What Doesn’t Fall in Apple’s In-App Purchase Policy:
Ok, when can you avoid using IAP? The simple answer is, when you’re selling physical goods and services.
My favorite example is Uber or Lyft. They can have their own credit card processing system (or Apple Pay) because the customer is paying for an actual ride from one place in the real world to another. When the customer purchases something from Amazon, they are buying a physical product, so Amazon can use their own payment system as well. However, you will notice that you cannot buy books in the Amazon Kindle app. You can download samples and add to a wish list, money does not change hands in the Kindle app.
Curiously, you can buy a Kindle book in the normal Amazon store app, using Amazon’s own payment processing. I don’t know if Amazon worked out a special deal with Apple, or they just snuck it in there. When you’re on Amazon’s size you can get just a small bit of leeway.
The trouble is 1) there aren’t a lot of businesses that offer these types of products or services that transact on mobile applications, and 2) it may not be immediately obvious that your pricing model falls under the IAP umbrella. If there is any doubt, submit your application for review as early as possible to validate this. It is far easier to adjust a business model months before launch than hours.
What about Software-as-a-Service businesses?
If you sell a SaaS subscription within an iOS app, it’s just another subscription in Apple’s eyes; you have to use an IAP subscription and give Apple 30%.
You can however, sell the subscription on your website and still have a companion iOS app. Take a look at the Basecamp iOS app:
This is the first screen you see when you launch the app. There are no IAPs for their subscription model. Instead, Basecamp has you sign up and pay for their subscription service on their website, not in their mobile app.
So you’re saying there is a loophole?
Yes. Well, maybe… You can certainly avoid paying the 30% fee for IAP, but there is a Shaq sized catch. You CANNOT advertise anywhere in an app that you are selling something outside of iOS.
This is a pretty tough decision to make, as it has implications not only for product development, but also user acquisition, engagement and retention.
Originally, Netflix did not allow you to sign up for their $10/month plan inside of their iOS app, instead forcing every user to activate their account online. They held steady on that for a long time, opting to avoid the IAP fees for a clunkier user experience. That was until they determined that the number of signups they received by the convenience of activating subscriptions right there in the app outweighed the 30% hit on revenue.
I cannot stress enough that you will be rejected if you link to a website that displays a payment form. Even if you link to your homepage, and that links to a payment page, you’ll be rejected. Notice that there is no link to basecamp.com in that screenshot above. (Bonus tip: if you have a link to an Android version on that homepage, you’ll also get rejected. Life is fun sometimes.)
What this means for your business. And your app.
All too often we have a tendency to rush into things. Apps, and software development, are notoriously hard to estimate regardless. There is always an unknown wrench that will be thrown into your plans, but your business model and how you scale revenue should always be in your hands.
Apple’s IAP policy might seem a little imperious, and it is. Apple has $528 billion reasons that allow them to get away with it though and they won’t be changing anytime soon. With a little bit of foreknowledge your business and your development plan can adapt.
Written by Tallwave