Will Apple’s in-app purchase terms hurt the iOS platform?

The folks who created Readability have published an open letter to Apple after their app was rejected because it violates the new license terms that require that all purchases made from within applications use Apple’s In App Purchase functionality. Here’s their response:

Before we cool down and come to our senses, we might as well share how we’re feeling right now: we believe that your new policy smacks of greed. Subscription apps like ours represent a tiny sliver of app sales that represent a tiny sliver of your revenue. You’ve achieved much of your success in hardware sales by cultivating an incredibly impressive app ecosystem. Every iPad or iPhone TV ad puts the apps developed by companies like ours front and center. It was a healthy and mutually beneficial dynamic: apps like ours get exposure and you get to show the world how these apps make your hardware shine. That’s why we’re a bit baffled here.

To be clear, we believe you have every right to push forward such a policy. In our view, it’s your hardware and your channel and you can put forth any policy you like. But to impose this course on any web service or web application that delivers any value outside of iOS will only discourage smaller ventures like ours to invest in iOS apps for our services. As far as Readability is concerned, our response is fairly straight-forward: go the other way… towards the web.

I have read plenty of arguments both ways about this new policy, but I’m pretty convinced at this point that aside from whether or not it’s evil and greedy, it’s almost certainly bad business for Apple.

Apple does many things incredibly well, which is why I love their products. The problem is that their confidence leads them to want to force their developers to do things the “Apple way” rather than letting come up with their own ways to do them. The fact that they can also dictate terms that require developers to pay a very large portion of their fees to Apple doesn’t discourage them either.

I suppose it’s possible that the new In App Purchasing framework Apple is mandating is so awesome that it’s worth the 30% you have to pay. In that case, while Apple is losing developers now, they’ll all come running back to take advantage of the new opportunity. It strikes me as more likely, though, that this mandate will be a disaster for Apple, because it snares too many producers who already have existing business models and can’t afford to suddenly start giving 30% of their subscription revenue to Apple.

Update: John Gruber rebuts:

Maybe I’m missing something, but these guys claiming to be surprised and disappointed by Apple’s insistence on a 30 percent cut when their own business model is to take a 30 percent cut strikes me as rich. And how can they claim that Readability isn’t “serving up content”? That’s exactly what Readability does. What they’re pissed about is that Apple has the stronger hand. Readability needs Apple to publish an app in the App Store. Apple doesn’t need Readability.

This gets at the tension. Readability doesn’t need Apple if they can sell their web-based service without them. Apple doesn’t need Readability if they’re one of a relatively small number of defectors from the iOS platform. I honestly have no idea which way this one’s going to go.

Update: Marco Arment explains why the new requirements are burdensome to developers aside from the 30% cut Apple will take. Adapting applications to fit into Apple’s payment framework will be impossible for some applications and require substantial reworking for many applications. That seems like too large a price to pay on top of the large revenue share that Apple will take.

Arment does a good job of listing some corner cases that put developers in a very tough position with regard to Apple’s requirements. I don’t expect Apple to have come up with all of these cases and accounted for them. What they illustrate is that Apple isn’t clever enough to come up with a system that will work for everyone and thus shouldn’t try to force everyone into one system.