A Worse User Experience

In compliance with Apple’s rules for the iOS App Store, Amazon recently updated their iOS Kindle app to remove the “Kindle Store” button. Previously, tapping that button in the app launched MobileSafari and loaded a mobile-optimized version of the Kindle Store web site. Books could (and still can) be purchased through that site and then accessed from within the Kindle app.

Dan Frommer argues that Apple’s ban on in-app links to web sites that sell content is bad for users:

Now, Apple device owners will have to figure out on their own that they need to go to Amazon’s website in their Safari browser to buy stuff to read with their Kindle app.

This is a worse customer experience. Apple’s devices are now slightly harder and clumsier to use. And it’s Apple’s fault.

From now on, if developers want to sell virtual goods and subscriptions that don’t go through Apple’s in-app iTunes payment system — which forks over a 30% cut to Apple and puts developers at risk of patent lawsuits — they aren’t allowed to link to those other e-commerce stores in their apps anymore.

He’s right: it’s a much poorer user experience. But even worse, companies link Amazon couldn’t sell their content through Apple’s in-app purchase system, even if they wanted to. According to Apple’s iTunes Connect Developer Guide (PDF), developers can only create “up to 3000 separate product IDs assigned to your In-App Purchases per app.” Amazon’s Kindle Store claims to contain “more than 950,000 Books, Kindle Singles, Newspapers, Magazines, Blogs, Audiobooks, and Games & Active Content.”

Even if books represented only a tiny fraction of the 950,000 items in the Kindle Store catalog, there would be far more than Apple’s 3,000-per-app limit. And even if Amazon were willing and able to pay Apple’s 30% cut on Kindle sales and use the official iOS in-app purchase system, technical limitations set by Apple prevent them from doing so.

The end result, then, is a crappy deal for users. Forget whether Amazon can make money while paying a 30% cut. Forget the risk of patent liability and the investment of time and money required to start using Apple’s in-app purchase system. The fact of the matter is, Apple has made getting books onto iOS devices harder. Users must magically know how to switch to MobileSafari and navigate to the Kindle Store, instead of tapping on an easy-to-use “buy” or “store” button. That doesn’t sound like the kind of experience Apple wants to create. It sounds more like Android.

What if there were no Coke at Disney World? Or, Problems with Apple’s in-app purchase rules

Apple made a lot of waves last week with it’s announcement regarding In-App Purchases (IAP). They introduced two major changes. First, developers can now sell auto-renewing subscriptions on a weekly, monthly, or yearly basis. Second, Apple has revised the App Store Review Guidelines to require the use of in-app purchase in a number of situations.
I’m going to leave subscriptions aside for now and concentrate on the new App Store rules governing the use of in-app purchases. Subscriptions are important, but I think they’re just a part of the larger problem developing around IAP. Apple’s new requirements are as follows. Apps that allow you to use content purchased elsewhere, such as through a web store, must allow you to purchase the same content using IAP. Moreover, apps must offer that content via IAP at an equal or lesser price, even though Apple takes a 30% cut of all in-app purchases. Finally, apps may not include links to web sites or other “external mechanisms” though which the content can be bought without giving Apple it’s 30% commission. The relevant sections of the App Store Review Guidelines are below:

11.13 Apps can read or play approved content (magazines, newspapers, books, audio, music, video) that is sold outside of the app, for which Apple will not receive any portion of the revenues, provided that the same content is also offered in the app using IAP at the same price or less than it is offered outside the app. This applies to both purchased content and subscriptions.

11.14 Apps that link to external mechanisms for purchasing content to be used in the app, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected.

Leaving aside any possible anti-competitive behaviors going, the biggest problem with Apple’s new rules is that they’re bad for customers, and thus they’re bad for Apple. Why? It’s all about customer choice.

Amazon’s Kindle app is a fantastic example. Until now, it hasn’t been possible to buy books through the Kindle app. Instead, the app includes a “Kindle Store” button that launches Mobile Safari with an iPhone-optimized version of the Amazon.com Kindle website. Users can then search and browse for books. Upon purchasing a book, a button can direct the user back to the Kindle app, where the book will be downloaded and made available for reading.

Now, imagine the same app under Apple’s new rules. The Kindle Store link will be gone. Without it, most users will have no idea they can buy Kindle books through the Amazon website. Instead, the app will have a searchable list of books that can be purchased directly within the app. From a user experience point of view, it’s great.

So what’s the problem? It’s hard to imagine Amazon making any money this way. I’m no book publisher, but I’ve read that margins in the industry are quite low. Remember, Amazon must pay a substantial portion of the sale price to the book’s publisher. What’s left after the publisher’s cut and Apple’s 30% cut? Very little – perhaps not enough to make the Kindle app worth Amazon’s while. Ordinarily, we might expect the added costs from Apple’s 30% commission to get passed on to consumers via higher prices for books purchased within the app. But Apple has specifically banned that practice.

Instead, Amazon might choose to pull the Kindle app from the iPhone and iPad. That’s neither good for consumers nor good for Apple. Sure, consumers could still buy books through Apple’s own iBooks store, but generally speaking, the selection is worse and the prices are higher. Furthermore, you can’t read iBooks on anything but iOS devices. There’s no reader for Mac, Windows, web, anything. (I expect an iBooks reader for Mac one of these days, but that’s another matter.)

John Gruber tweeted this analogy:

App Store : Apple :: Disney World : Disney They make money on everything you buy in the park.

It might be a fair analogy, but it doesn’t mean it’s good for customers. Suppose that Disney charged a fee on every Coke sold at Disney World, but also required that the price of a Coke in the park be the same as the price of a Coke at your local gas station. If the fee were high enough that Coke couldn’t make money, they’d just stop selling soda at Disney World. Coke and Disney don’t care; they’re raking in so much money elsewhere that they probably wouldn’t even notice the lost sales. It’s the visitors to Disney World who suffer – they can’t buy a Coke when they want one.

Likewise, these new IAP rules are bad for Apple. Neither Apple nor companies like Amazon will notice much in the way of lost sales. The people who get screwed are the customers, who suddenly aren’t able to buy the products they want. Sure, they get a better user experience from those developers willing to play Apple’s game, but they’ll be missing out on critical content. If I can’t buy the book I want on my iPad, what good does it do me that the user experience would be better, if only they carried my book?

Certainly nobody, not even Amazon, is going to abandon iOS overnight. But clearly, Apple is in the iOS business for the long haul, and it’s still early enough that they could falter with serious consequences. Thankfully, there’s an easy fix – charge less. Apple’s original justification for the 30% commission for apps is that it pays for the (substantial) overhead involved in payment processing, storage, and bandwidth to send apps to customers. For in-app purchases, however, only payment processing is relevant. (For example, Amazon’s library of Kindle titles isn’t stored on Apple’s servers or downloaded through their network.) To solve the problem, Apple needs only to reduce their commission on in-app purchases to something more in line with a credit card processor — maybe 5%.

Apple’s policies for the App Store have a way of starting out sounding draconian and relaxing over time. Hopefully we’re in the first stage of that process, and Apple will come to their senses sooner rather than later.

Web apps vs. iOS apps

Craig Hockenberry, in a post on A List Apart, on web apps vs. iOS apps:

iTunes offers you a simple way to charge users for content. It can be a one-time payment via app purchase, or a recurring payment (such as a subscription) with in-app purchases. In either case, a customer only has to tap on a buy button and enter their password. Apple handles all the payment processing and accounting. You just wait for bank deposits from around the world at the end of each month.

My guess is this has a lot to do with it. As Hockenberry also points out, it’s easy to pay for things on the App Store. There’s no typing of credit card numbers and billing zip codes. Just enter your iTunes password, and you’re done. Easy as pie.

A Missed Opportunity in VolumeSnap

A number of sources are reporting that the fantastic Camera+ app has been pulled from the App Store:

tap tap tap posted (and later deleted) instructions on Twitter that allowed users to enable the “volume button as shutter” functionality via a back door workaround. This is most likely what got Camera+ kicked off the App Store; other apps with “hidden features” or “easter eggs” like this have been banished from the App Store before, like a flashlight app that allowed users to stealthily enable internet tethering.

The feature in question could be activated only by opening Safari on the iPhone and entering a custom URL, which then communicated with the Camera+ app. (In case you’re curious the URL is: camplus://enablevolumesnap).

Apple is certainly well within the terms of the developer agreement to remove Camera+ for sneaking the feature past its reviewers, and you might say that enforcing that policy helps keep all sorts of insidious apps out of the App Store. However, I think Apple missed an opportunity here. As was well documented on their blog, the developers of Camera+ tried to include “VolumeSnap” as a documented feature of the app. Apple rejected it, citing possible user confusion about the function of the iPhone’s volume buttons. That’s not unreasonable – I wasn’t confused, but I can imagine some iPhone users who might be. You could even argue that making VolumeSnap an option, available through the app’s settings, could be confusing.

But what if Apple had chosen a third path, somewhere between rejection and allowing the app with full VolumeSnap functionality. Simply put, what if Apple had allowed the URL-based VolumeSnap activation to remain in the app as a documented, tested feature? Most users wouldn’t be confused at all, because the VolumeSnap feature is disabled by default, nor is there any visible way of activating it. The only people affected would be those who are savvy enough to find the activation URL and enter it into Safari. Presumably, these are pretty sophisticated users who would be unlikely to get confused by the VolumeSnap feature. Moreover, if they’re sophisticated enough to turn the feature on, it’s a good bet they could figure out how to turn it off as well.