Readability’s App Store Rejection Portends a Cloudy Future For Developers

A new App Store rejection sheds some light on the real implications behind Apple’s new in-app subscription policies, and the results aren’t pretty.

The iOS app for Arc90′s recently re-launched Readability service was rejected on Friday for “utilizing a system other than the In App Purchase (IAP) API to purchase content, functionality, or services.” This is significant because unlike companies like Rhapsody (who are already on the record as being firmly against the new policies), Readability is not a a traditional content provider.

As Readability creator and Arc90 founding partner Richard Ziade says in his “Open Letter to Apple” blog post, “Readability’s model is unique in that 70% of our service fees go directly to writers and publishers.” He continues, “if we implemented In App purchasing, your 30% cut drastically undermines a key premise of how Readability works.”

We spoke with Ziade after he posted his letter and he offered us this additional insight:

A big problem with this isn’t just the model (which is a big problem on its own). It’s the additional hoops we’d have to jump through just to make all this work. Imagine two payment distribution systems — one for iOS subscribers and another for web — that would have to exist. It’s just a big obstacle on our roadmap if we decided to do it. We’d rather put our energy towards making Readability better.

About Readability

Readability started as a bookmarklet that provided users with a better-formatted reading experience. Ideally suited for long-form content, Readability cuts out the clutter of modern web writing and presents text in a clean, focused way. The original proof of concept was so popular that Apple even based its Safari Reader feature on Readability.

Last month, Readability evolved into a total reading platform. While the basic bookmarklet remains free, users can subscribe to the Readability service (starting at $5 a month) and add articles, Instapaper-style, to a reading queue accessible from any web browser. What sets Readability apart is that publishers of the content that users choose to read get a percentage of the profits. In fact, 70% of a user’s subscription goes directly to the content writers.

The iOS app, which was developed by Instapaper’s Marco Arment, was supposed to be a special bonus for paid subscribers. It’s based on Instapaper and offers and optimized, offline reading and queuing experience.

Apple’s decision to reject the app doesn’t change the fact that the Readability is still usable within iOS. As a Readability subscriber, I’ve added “Read Now” and “Read Later” bookmarks to Mobile Safari on both my iPhone and iPad and am fully satisfied with the experience.

Instead, the decision very clearly sets the tone for what the rules for subscription-based service apps are going forward.

iOS Adverse Implications

The iOS platform is no stranger to criticism. Even before the official iPhone SDK made its debut in March 2008, developers were complaining about Apple’s policies in keeping the platform locked down, closed off and under a stringent set of guidelines. Through the years, some restrictions have lifted, rules have been better explained and more service offerings have opened up. Still, this is Apple’s show, and anyone who develops for the platform knows it.

For most developers, it’s worth the trouble. Despite Android’s tremendous gains in adoption, developers make more money on iOS and are more likely to cultivate repeat customers. New features tend to appear in the iPhone version of an app first; the iPhone and iPad get more exclusive titles; and the overall app experience tends to be more cohesive and complete.

Major brands and larger development houses target iOS and Android, but there are far more independent developers and smaller software shops that make their living entirely off of the iOS ecosystem than from Android. If Apple isn’t careful, it could start to push some of those indie developers away.

First launched with The Daily, Apple’s new subscription purchasing policy seems largely targeted at print publishers of magazines and newspapers. In that context, we have a hard time finding fault with Apple’s decision to take a 30% cut of all subscriptions obtained through the application download. Newspaper and magazine publishers might not be happy with the arrangement (though they can still offer subscribers the ability to subscribe outside the app), but in the grand scheme of things, 30% is likely on the low side of subscriber acquisition costs.

Even for streaming content services like Rdio, MOG or Rhapsody, we can understand Apple asking for a cut of a subscription rate — if only because those companies typically charge much higher rates for subscriptions that include mobile device support.

Plus, for consumers, the benefits of an in-app subscription system for magazines or music services is to their advangate. Not only is canceling a subscription faster (no having to wait on hold with an operator), but user privacy is better protected, too. Furthermore, at least in the case of published content, most content is going to be consumed on the device. If I subscribe to an iPad magazine, I am going to be consuming that content on the iPad.

This isn’t the case with web apps and cloud-based web services like Readability. Readability is an app built for the web browser. Having an iOS app is great — but fundamentally, the app and the service are designed to be platform agnostic and the desktop browser is definitely a major target.

How Far Does This Go?

The frustrating aspect of the Readability rejection is that this makes the road for apps that tie into cloud-based services in the future much less clear.

As Dan Benjamin and I discuss on a near-weekly basis, the line between web apps and native mobile apps is starting to become less and less distinguishable. A recent Appcelerator study showed that cloud connectivity is one of the top requirements for developers when building a mobile application.

Cloud connectivity can often mean plugging into subscription ecosystems. What worries us is what this means for native clients for web services.

Does 37signals now have to offer an in-app Campfire subscription in its Campfire for iPhone app? What about Evernote? Moreover, what about third-party apps that plug into the API for systems like Evernote or Campfire or Basecamp — are they also subject to this new subscription pricing policy? If so, how can that be enforced if the API doesn’t designate a payment or subscription option?

At the end of the day, we think Ziade summs it up best in his letter:

To be clear, we believe [Apple has] every right to push forward such a policy… 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.

More About: app store, apple, In-app subscriptions, Instapaper, iOS, readability

For more Dev & Design coverage: