Apple Changes In-App Purchase Policy? Not So Fast…

UPDATE: I guess I was wrong. Bad choice, Apple. Original post is as follows.

So, there has been a mild Internet Shit Storm (ISS) today over a story up in the New York Times that Apple has moved to change (and tighten) their policies regarding in-app purchases of content.

Apple is further tightening its control of the App Store.

Some application developers, including Sony, say Apple has told them they can no longer sell e-books within their apps unless the transactions go through Apple’s system. Apple rejected Sony’s iPhone application, which would have let people buy and read e-books from the Sony Reader Store.

Apple clarified on Tuesday that it was still allowing customers to read e-books they bought elsewhere within apps. (The New York Times reported earlier that Apple had told developers that content purchased outside of the App Store would no longer be viewable in apps.) For example, a Sony app could still access books the customer bought earlier from Sony’s store.

Horseshit. As reported by Harry McCracken over at Technologizer:

Er, hold on a moment, though–there’s no “from now on” happening here. The e-reading apps that are already in the App Store don’t permit in-app purchases of books, either. If Sony submitted a Reader app with in-app book buying and was refused admittance to the App Store, it’s only being required to play by the same rules as other e-book merchants.

There is nothing new here to see at all. This is the same exact policy that magazine publishers have been pissing and moaning about, and have been trying to end-run, since the iPad first came out and Apple first published the App Store guidelines.

Apple’s rule is clear: If you support in-app purchases for additional content, the only way to do it is to have the user buy them via the regular App Store mechanism (in other words, via their iTunes username/password). You are certainly free to also support purchases outside of the iTunes/App Store ecosystem by going out to a website, but you cannot do this from within the app itself. This has always been the case.

Amazon has, from day one, worked around this in their Kindle App for iOS. In the Kindle App, when you tap the Kindle Store button, the Kindle App itself closes and Mobile Safari opens and sends you to a (quite nice) mobile-formatted website where you can browse and make purchases. It looks and works basically like an app, but it is running inside Mobile Safari, and the user can tell (via the “app switching animation”) that they were switched into their web browser. When you make these purchases, they automatically show up in your Kindle App once you go back into the App, so the user-experience is still quite seamless. This method has always been, and still is, just fine with Apple.

Sony was almost certainly trying something similar, but different. In their app, when you hit the Sony eBook Store link, it would take you to their store within the application itself. This is different because then Sony can use the iOS SDK to make the store look and work like a native app, rather than a “mobile web page”. Apple says, and has always said, this is a no-no, and they’ve already rejected tons of Apps from magazine and newspaper publishers for exactly the same thing. Now, Sony says they were doing it from within a web page, but I’d lay odds that they were rendering that page inside the application by using an embedded Mobile Safari control. That too is, and always has been, verboten.

If you want to sell stuff right within your App, then the supported method is via the iTunes App Store. If you want to avoid the App Store mechanism, you have to close your application and switch the user to Apple’s Mobile Safari browser. Period.

Now, you can certainly do both. You are welcome to support in-app purchases via iTunes, and also allow the user can click a button which launches Mobile Safari and takes you to a web store. But no one wants to do that. The reason they want to end-run the App Store is so that the App Developer gets your user information directly from you (credit card numbers, email addresses, contact info, billing addresses, etc), and because they want to avoid giving Apple their 30% cut. But the developers all know that if you support both methods, everyone is just going to ignore the “switch to Safari” method and use the in-app method.

You can’t do it the way Sony wanted to do it, and they knew this well in advance. This is a transparent PR shot at Apple from a competitor.

The reasons for this policy may seem simple enough: Apple wants a cut of those sales. And that is certainly true, and is probably a huge motivating factor for this policy. But it is certainly not the only reason for this policy.

Apple sells the applications directly and they are expected, at least to some degree, to support them. Forcing all in-app purchases to go through the iTunes store gives Apple the power to control the user-experience over what the users buy. Just like Best Buy wouldn’t allow a vendor to come into their stores and set up a kiosk where they sell goods that Best Buy couldn’t control or even look at ahead of time, Apple won’t allow anyone to sell things “in their store” without letting Apple have the power to pull it. Without this policy, since Apple would have no control over the add-ons, they would be unable to ensure that the user is actually getting what they’re paying for. If you think that a huge proportion of Apple’s millions of customers wouldn’t call AppleCare to complain, rather than the app maker, when they have a problem, then you’re living in a dream world. If some App Developer was slinging porn, viruses, malware, or just plain junk via in-app purchases that Apple couldn’t “pull”, they would still get the support calls and the PR black eye. I can see the headlines now, “Apple allows App Dev to sell Porn to Children!” Not only that, but you could write the code in a completely insecure way. Sending credit card numbers across the internet completely in the clear, using crappy and easy-to-break encryption, and all sorts of other bad behavior. Because it wouldn’t be in a browser, where you (should) know how to look for the HTTPS and the other browser-based security features (which Apple controls because they make the only web browser engine for the device), the vendor can’t trick you into entering your credit card info into an insecure form. Or, at least, if they do try to trick you, they have to do it the same way you’d be tricked by any web site, and the browser wouldn’t be “in on it” with them (showing things like padlock icons on the screen even though the content is sent in the clear and sneaky things like that).

Secondly, without this policy, you could write an application that violates all the rules of the SDK and just have these features turned off until the user “buys” the add-on. It would be a way to end-run the “no emulation” rule of the SDK (because the add-ons could substantially change the “product” that Apple sold you in the store). Since Apple doesn’t have control over the in-app purchases, they couldn’t stop you from completely end-running the rules. Now, you may think the rules are junk and you want a completely free and clear “wild west” market. If so, fine. Jailbreak your phone or buy an Android phone. That isn’t what Apple is selling. They are selling a “safe” and at-least-somewhat curated ecosystem.

Third, and I think this is actually most important in Apple’s eyes: They want their users to always understand, without even thinking about it, which username and password to enter when the iPhone/iPod/iPad asks them if they want to buy something. It is absolutely essential to the user experience in Apple’s eyes that there is one place and one place only that you go to change your credit card number. There is one username and password that you use to buy things with your iOS device. And, when you buy something on the device, unless you do it in a web browser, you absolutely know where the billing is coming from, who to call if there is a dispute, how to change your address, where to look up your order history, and everything else related.

The rule is simple. From a user perspective, when you are inside an app other than Mobile Safari, the app cannot ever ask you for a credit card number, and it can’t ever sell you anything unless it is via the iTunes username/password mechanism. Period.

If you’re a developer and you want to get around this, do it on the web. You can do whatever you want on the web. In Apple’s eyes, anything that happens in Mobile Safari is “the web” and is “unmoderated” (the “wild west”). Anything that happens in a native app other than Mobile Safari is something else entirely. You may think this is a stupid distinction, and maybe it is, but that is and has been the rule all along.

There is nothing new to see here.

UPDATE: Perhaps I’m wrong, we will see. From Loop Insight:

“We have not changed our developer terms or guidelines,” Apple spokesperson, Trudy Muller, told The Loop. “We are now requiring that if an app offers customers the ability to purchase books outside of the app, that the same option is also available to customers from within the app with in-app purchase.”

If that quote is accurate and correct, then it could be that Apple is going to require Apps that use the “Kindle model” of content selling via Mobile Safari to also provide a way to actually use the in-app purchasing mechanism.

If this is true, that is not a good change Apple.