The App Business Blog

Since the beginning of the App Store there have been complaints about Apple’s 30% cut, it’s app review rules and the enforcement of them. It’s an impossible task to create rules that will please everyone, but is it possible to create ones that are more clear, leave fewer gray areas and can endure over time?

When In-App Purchases were launched in 2009 it was initially targeted at selling digital content like books and magazines; I worked on the Zinio magazine reader and the Iceberg book reader apps at the time. Steve Jobs made the argument that when Apple brought a paying customer to a publisher Apple deserved to be paid 30% for it, and when existing subscribers paid they could do so outside of the App Store and Apple would not receive any commission.

In order to preserve this division of who brought the customer, Apple decreed that you could not link to your website or encourage customers to leave the app and sign up to your service outside the app. We’ve probably all had app rejections where app review finds a link or a mention deep inside the app that could be followed back to your website. Never mind that it does not take a genius to type in “Netflix” or “Salesforce” into a search engine to figure out how to sign up for their service. (Ironically, “Hey” may be an exception to this.)

For Apple to make good on their claim to bring customers to apps they need to provide a great way to discover apps in the App Store. The recent addition of curated content on the Today tab of the App Store app is great and I happily give Apple a commission every time a new customer finds one of my apps this way. But only a very small fraction of apps can be surfaced by Apple’s editorial team. The other major mechanism to discover an app is through search, and we all know what a joke search is on the App Store.

I would argue that most people find new apps via friends, social media and other articles outside the App Store. They all refer you to the App Store with a link so that you can install the app. This may give the impression that Apple served up a new customer to you on a silver platter, but in reality Apple had very little to do with the discovery. Therefore Apple’s original argument rings very hollow today and it’s not a stretch to see it more as “rent-seeking”.

The above history lesson skips over episodes like where you could offer purchases on your website inside a web view, but only for a brief time before you had to launch Safari to the same URL, before all such links became forbidden. So it’s not exactly been well defined and stable rules in this, the most consequential part of our apps: how we get paid.

Let’s try to find a clear line that divides apps that must use Apple’s IAP from those that don’t.

One one extreme end of the spectrum would be that all apps have to use Apple’s IAP for unlocking any feature or functionality in the app, and no alternative mechanisms for payment would be allowed. That is essentially what Apple says in paragraph 3.1.1 of the App Store Review Guidelines. But then this is followed by with several exceptions to this rule. So even Apple realized that this was too restrictive and it would needlessly bar many types of apps from the App Store.

The most curious exceptions are listed in section 3.1.3(a) under the heading “Reader” Apps. They include (and are specifically limited to):

• magazines
• newspapers
• books
• audio
• music
• video
• access to professional databases
• VoIP
• cloud storage
• approved services such as classroom management apps

It has been pointed out by several people that this list has a lot of overlap with paid services offered by Apple. Since each addition to this list means fewer payments to Apple there must be very special reasons for adding to this list. One obvious reason is antitrust: it looks really bad if your direct competitors are forced to pay 30% of all their revenues to you just for the privilege to be on your platform. So adding more app categories to this list is a good thing for app developers, but it violates our goal of finding rules that do not morph over time. If Apple were to hypothetically launch a paid fitness app/service in the future, would that be added to the list of reader apps? Would existing apps of this type have this new rule applied retroactively, or the next time they submit an update?

SaaS services like Salesforce and Slack are not included in the list above. So why can they offer an app that has no functionality unless you already have an account with them? Do they fall under the category “approved services”? Is there a secret list of approved services?

I would argue that none of the above rules fit the criteria of being clear, encompassing and enduring. The further you move away from “all”, the more exceptions you have to make and the more gray areas you create. And that’s without examining all the one-off exceptions that Apple is known to have made with some notable companies.

Let’s approach the problem from the other extreme: all companies can do whatever they want to collect payments. Apple’s IAP system is just one payment system developers can choose from, and it has to compete for business on its own merits.

Apple’s core argument here is that a free-for-all system would more confusing and more risky for consumers. Some app developers are very crafty and it would not take long before devious scams would appear on the App Store, for example apps whose sole purpose is to collect credit card numbers. How would Apple avoid responsibility when an app defrauds customers and Apple approved the app for inclusion on the safe App Store?

A solution could be to have the payment systems be audited and approved by Apple or a third party organization. Then each developer would choose the payment system that best fits their business model. Apple would no longer have to categorize apps and decide which ones need to use which system. With competition between payment systems that should make antitrust regulators happy as well. Apple could probably justify taking a small fee from all transactions as payment for letting lots of electrons pass through the systems they maintain. It would of course not be anywhere near 30% though.

Will Apple make any changes to their rules without being forced to? In 2019 Apple paid out $39B to app developers. That means their 30% cut was likely more than $10B (accounting for some 15% deals and that some apps are paid up front). Most businesses would fight tooth and nail to keep that much annual revenue. Even if it means semi-regular firestorms in the press and antagonizing the developers who do most of the work to earn that revenue. For now it seems that Apple is content to be just like most businesses in this regard.

written by Nick

In 2013 the App Store top charts where dominated by free apps with in-app purchases. This was especially true in the games category. Recently I’ve seen indie developers experimenting with freemium and paymium models in non-game apps. This is good.

Sunlit

Sunlit by Manton Reece is a traditional free with in-app purchases style app. The idea of the app is to collect your best photos into stories along with geo check-ins. (Seems like several similar services just launched around the same time. Must be an idea who’s time has come.)

The App Store listing shows that there is a $4.99 in-app purchase available for “unlimited stories”. Thankfully the app doesn’t beat you over the head with messages to pay. An upgrade message is shown when you try to create your third story. This is unobtrusive and elegant. There is also a small link to upgrade when you create a new story. This is great for fans who may not run into the limits of the free app, but still want to give you money. Well done.

Photos+

Justin Williams released his Photos+ app in December and he explained his business model in a blog post where he likened it to the auto industry. The idea is to sell a base model of the app. In the case of Photos+ it’s priced at $2.99. Then you can purhcase add-ons, i.e. new features, with in-app purchases. I think this is a really interesting model to get around the fact that you can’t charge for app upgrades.

In the current version of the Photos+ app there is supposedly one in-app purchase to add more sharing capabilities. But I can’t actually find it… Maybe it was something that didn’t make the 1.0 cut but was still mentioned in the help screens. Anyway, I still like the idea of this business model.

Side note: The app name “Photos+” is impossible to search for in the App Store. Totally unrelated apps like “Yahoo Weather” and “Match the Dots” are listed way before Photos+. It’s just another reminder of how really bad search is in the App Store. But given that this is the reality, don’t name your apps after a generic category, and avoid giving it a name that is similar to hundreds of other apps.

Summary

I’m bullish on the idea of freemium and paymium for non-game apps. The two apps above are just two examples that recently came to my attention. What interesting app business models have you come across recently?

written by Nick

This post is a follow-up to my prior post about selling content on the App Store with new information from today’s press release from Apple and the updated App Store Review Guidelines.

First of all, kudos to Apple for updating the guidelines. The paragraphs you should look at for this discussion are 11.12 – 11.14. Based on my reading (and keep in mind that I’m an iOS developer, not a lawyer) these are your options:

1. Use IAP only for selling content

This is the most straightforward approach for most smaller developers. Just let Apple handle all the headaches of credit cards, payments, recurring billing, etc. For this convenience you pay 30% to Apple.

2. Use a combination of IAP and your own ecommerce

Most existing publishers who also want to sell content on iOS devices fall into this category. If you want to make content available on the iOS device that a customer has purchased on your ecommerce website, then you have some serious integration work to do, but that’s nothing new.

What’s new is that now you also have to offer the option of purchasing the same content using IAP. And the big, but not surprising, stipulation is that there has to be price parity between the two options. Your customer will pay the same amount in both cases, but you will have to pay 30% to Apple if the customer elects to purchase via IAP, compared to the 5-10% you typically pay to your ecommerce or credit card merchant. (11.13)

Furthermore, you cannot have a “buy” button in your app to direct a customer to your website. In order to purchase from your ecommerce website your customer will have to manually launch Safari, and type in the URL of your website, and complete the purchase there, before returning back to your app. Inconvenient, yes. But still a viable scenario for people who prefer to purchase things online from their desktop. (11.14)

3. Only rely on your ecommerce website

If you have a really well-known brand (Amazon comes to mind) you could remove all buy buttons, website links and purchase capabilities from your app. To buy content, your customers will have to know that they need to go to your website.

The advantage is that you don’t have to fork over 30% to Apple. The disadvantage is that you don’t get the convenience of IAP and you don’t get to ride on the coattails of Apple’s mighty iTunes machine.

Subscriptions

Subscriptions have their own paragraph (11.12) in the guidelines, which basically says: “Apps offering subscriptions must do so using IAP”. That clearly eliminates option 3 above. But is option 2 allowed? Steve Jobs quote in the press release seems to indicate that this option will be allowed: “Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing.” A big-name example that seems like a good test case is The Economist which provides print subscribers free access to all content in their iPad app.

If this is not complicated enough yet, what about publishers who sell both subscriptions and single issues? And combinations of print and electronic subscriptions?

What will publishers do?

I believe that most companies will complain and grumble about this for a while. But in the end they will come to the conclusion that 150 million iOS customers is just too big of a market to walk away from.

Some companies do not have the margins to pay Apple 30% for the content they sell. Just like some companies don’t have the margins for sales reps or TV advertising. They will have to look to other channels for selling their content.

What will consumers do?

First of all, Apple will continue to allow you access to content you have purchased elsewhere. So your Kindle books are safe.

People’s habits are difficult to change, and I don’t think these new rules will have a significant impact on how consumers will purchase their content. If you’re used to buying ebooks on Amazon, then you will probably continue to do so (even with a few extra clicks). If pushing the IAP button in apps is second nature to you, then that’s probably not going to change either.

written by Nick \\ tags: App Store

Apple’s rules and mechanisms for selling content in apps have been “evolving” since the App Store opened.

In app commerce variations

One of our very early projects for a client was a wallpaper app where you could download a number of wallpaper images paid for by the app purchase price. After that you could buy additional credits for more downloads. Initially Apple told us to use our own payment mechanism for this, as this was before In App Purchases were available. We implemented a solution using Bango, which Apple then promptly told us to remove or risk rejection. We now use IAP and all is well.

An ebook reader app that I worked on used the one app per book model, which does not scale very well. When IAP became available, this app was used as a showcase in the keynote at WWDC. The purchasing model is still ok, but it appears that the content may not be. More about that below.

For a magazine reader app, an existing ecommerce back-end was used for purchasing single issues as well as subscriptions. The best usability scenario would have been to seamlessly integrate the ecommerce website in a web view. But on the evening before the launch, Apple suddenly had a change of heart and requested (i.e. demanded) that we quit the app and launch Safari for all ecommerce processing.

Amazon does the same thing with their Kindle app, as does Barnes & Noble with their nook app. Interestingly Amazon’s Windowshop app does allow you to buy Kindle editions from within a web view, but not from the native UI. For mega retailers like Amazon, these restrictions and gray areas just become absurd.

What change?

Although not ideal, the launch Safari approach works, and is being used by many apps currently on the App Store for selling content. The fact that so many apps that use this mechanism have been approved, has led us to believe that this had Apple’s blessing. Until now.

The paragraph in question is 11.2 in the
App Store Review Guidelines. The wording here is very vague and depending on how you interpret that single sentence, you can argue that all of the above scenarios should be fine, or all should be rejected. If we accept the premise that Apple’s review and approval process is not random (and I know that to some, this may be a leap of faith), then the interpretation and enforcement of this paragraph must have changed over time.

SKU limit

If Apple required Amazon or B&N to use IAP for their ebooks, they would very quickly run into the max SKU limit of the IAP system. I have heard that the max number of In-App Purchase product items you can have is either 3,000 or 5,000. Although I suspect anyone trying to enter that many items using iTunes Connect would go mad long before approaching that number.

Several of our clients find that IAP is a non-starter because of this limit. Yes I know that you can use consumable IAP items to represent multiple real life SKUs, but that leads to other issues.

Subscriptions

Subscriptions have been part of IAP since the beginning, albeit the functionality was so crippled that I have not seen any project use it. In a nutshell each developer had to manage all aspects of subscriptions beyond processing the payment. And the big deal breaker was that subscriptions did not renew unless the customer opened the app regularly.

Today News Corp launched the much rumored The Daily news app. The news here for developers is that The Daily implements a new subscription system. Not much is known about the system, but the updated iTunes terms of service provides some clues:

(Oddly the printable version of the terms of service does not include this new paragraph.)

It seems clear that these “Paid Subscriptions” do automatically renew until you explicitly cancel. And Apple will provide a mechanism for opting in to sharing your personal information with the publisher, which has been another point of contention between the newspaper/magazine industry and Apple.

Apple’s Eddy Cue says that the new subscription system is “Available on the Daily today, and there’ll be an announcement for other publishers soon.”

Books should be sold in the iBookstore

Having developed many book related apps I was surprised to hear about this rejection of an ebook app. Apparently if your ebook app does not offer any features beyond what an ePub file in iBooks can do, then it will be rejected and you will be asked to submit your book to the iBookstore instead.

I can understand Apple’s position on this from both a usability perspective (the book category is already the largest in the App Store) and from a profit perspective. But I sure don’t want to be on the app review team trying to decide where the line of “enough interactivity” goes.

What now?

My main gripe as a developer is of course the lack of proactive communication from Apple on policy changes like this. When they finally published the App Store Review Guidelines it was clearly stated that it was a “living document”. Well, it’s been pretty dead and void of changes since the initial publication. And I think that most developers would agree that there have been some significant changes since then.

If you currently have an app on the App Store that does not comply with all the latest interpretation and enforcement changes, then it’s unlikely that your app will be pulled from the store immediately. But if you ever want to make an update to that app, you will have to comply with the latest policy/rule/interpretation/enforcement. Even if this means that you have to make fundamental changes to your business.

written by Nick \\ tags: In App Purchase

In a previous post I outlined some of the difficult choices developers face in deciding to embrace In App Purchase in free apps to allow users to upgrade to a full version.

The issues include:

• No upgrade path provided by Apple for current owners of a paid version.
• Difficulty in breaking into the free top lists on the App Store.
• In App Purchase requires OS 3.x and wireless access to the App Store.

Some of my clients have solved these issues by offering two versions of their apps on the App Store:

1. A free app with In App Purchase to upgrade to the full set of features.
2. A paid app with all content or functions already enabled.

If you have already been offering your app as a paid version and a free lite version, the only difference with this approach is the addition of In App Purchase to the lite version.

While this resolves most of the developers’ issues, it doesn’t help reduce the clutter on the App Store.

Update: I just noticed that Riptide Games have come to a similar conclusion after their experiments with In App Purchase. They also detail some of their statistics on sales and conversions. Recommended reading.

written by Nick \\ tags: App Store

In the last week a lot has been written about Apple’s change to allow In App Purchase in free apps. Here are some of the more informative articles I’ve found:

Thoughts on In-App-Purchasing For Free Apps
A thorough post by Jeff Scott at 148Apps describing the good news and the bad news for both developers and consumers.

In-App purchases could fundamentally change Apple’s App Store
Seth Weintraub at ComputerWorld postulates that everything will change. The (unanswered) question is how?

In-App Purchase now available for free apps
Marco Arment was one of the first iPhone developers to comment on the change.

Apple relents: in-app purchase for free apps allows demo-to-paid
Another good developer summary by Erica Sadun at TUAW.

Free In-App Purchases Will Change…. Little?
A somewhat pessimistic look at In App Purchase by Arnold Kim.

In App Purchase and the state of iPhone piracy
Much has been written about Apple’s statement that “Using In App Purchase in your app can also help combat some of the problems of software piracy by allowing you to verify In App Purchases”. Most of it has been ill-informed speculations by non-developers. In this post Dominique Bongard goes into great depth about the challenges of using In App Purchase to combat piracy. It’s not from a developers perspective, but from someone who has been involved in anti-piracy monitoring.

Do In App Purchases count towards the Top Grossing list?
This is one of the questions I asked in my original article. The answer seems to be yes. Freeverse analyzed the rankings of three of their games on the Top Paid list vs. the Top Grossing list. And Distmo discovered that several free apps have made it onto the Top Grossing list.

iTunes Connect Updated
On October 22 Apple made an update to iTunes Connect. After this update I was finally able to add In App Purchase to free apps, and it was also possible to change the price of an existing app with In App Purchase to free.

iPhone Developer Program License Agreement Updated
When you login to iPhone Dev Center you will be prompted to accept a new iPhone Developer Program License Agreement. I have not compared the entire document against the previous version, but one thing that I noticed had changed was specifically to allow for In App Purchase in free apps.

written by Nick \\ tags: App Store

I just wrote a blog post on our corporate blog about Apple’s announcement that In App Purchase is now allowed for free apps. This is a huge change and you should know how it impacts you as a developer.

written by Nick \\ tags: App Store