Why Apple should relax its App Store rules

Developers for Apple’s platforms have long had to walk a knife’s edge, balancing their desire to implement powerful features with their need to ensure that those ideas fall within Apple’s prescribed bounds.

Unfortunately, those bounds often seem to be moving targets. To take one example, Smile Software recently announced that Apple had deemed features of Smile’s popular TextExpander beyond the pale and that, as a result, Smile would have to revise the app.

Apple’s role as gatekeeper has drawn ardent praise and provoked sharp criticism. Though iOS had become an incredibly successful platform, where hundred of millions of users gobble up app after app at a pace unmatched by the OS’s rivals, problems have arisen along the way.

And as iOS continues to mature, Apple’s tight grip onto its mobile ecosystem is beginning to make evolution and growth hard for developers who have contributed significantly to the platform’s success.

Curated garden or manicured prison?

For developers, living in Apple’s gilded cage means having to contend with a long list of rules. Initially, as the folks from Cupertino found their footing, the restrictions were largely unwritten, but they have since been codified and made available to registered members of Apple’s Developer Connection. The company has even set up an “appeals board” to hear special cases brought to it by developers whose apps fell into the rules’ inevitable cracks.

For the most part, the rules have worked well. Apple wants iOS to be a well-curated garden on the outskirts of the Internet’s Wild West, and that has meant excluding some software along the way. For some kinds of apps, the decision is relatively painless: Obviously, nobody wants the App Store to host malicious software that takes advantage of users.

For other apps, though—software that most users would want to have on their phones and tablets—running afoul of Apple’s rules can be a serious problem. In the past, the company occasionally altered its rulebook to accommodate unexpected needs, but that process has slowed down considerably in the last couple years. At the same time, iOS has shifted from being a platform designed for use in conjunction with desktops and laptops to being one that often stands on its own.

When rules go bad

Take the aforementioned case of Smile Software’s TextExpander—an app that can seem inconsequential until you start using it and realize that how much unproductive time it can remove from your daily routine. TextExpander lets you define and quickly recall arbitrary chunks of text, regardless of their complexity.

On OS X, TextExpander can interact with just about any app. On iOS, Apple’s sandboxing makes this much harder, but in the past Smile’s developers have circumvented the problem by implementing a software development kit that other programmers can easily and quickly integrate into their own software.

Unfortunately, this leaves one problem unsolved: Third-party apps still need to synchronize their text-snippet database against the main TextExpander app, which is difficult to accomplish in an environment where programs are largely prevented from talking to one another—or even being aware of one another’s presence on the device.

Thus, Smile had to find another workaround, which involved relying on iOS’s built-in Reminders as an ersatz synchronization mechanism. After initially permitting that usage, Apple eventually rejected it as an improper application of a technology whose primary goal is, after all, to help you compile grocery lists.

Workarounds are not solutions

In fairness, Smile could adopt alternatives to the way it did things. One option would be to develop a Web-based system that allowed synchronization across the Internet, thereby avoiding strange workarounds that require putting its software at the mercy of Apple’s approval process.

On the other hand, such a revision is far from trivial, even for a well-established company like Smile: Web synchronization is notoriously hard to implement, leads to all sorts of privacy complications, and (of course) only works if you’re connected to the Internet.

Ultimately, the biggest problem with Aple rules like the one that went against TextExpander is that they hurt customers. Smile isn’t some rogue company trying to sneak malicious software into the App Store; it’s legitimately trying to make users more productive by giving them a product that they are happy to use and pay for.

More generally, the inability of iOS apps to work in concert is becoming increasingly problematic. Apple’s store policies favor inexpensive, highly specialized apps; if you’ve ever spent time working with a Unix shell, you know that this model can work very well—if the apps can easily pipe content through each other. Absent this ability, though, you’re left with situations like the ones affecting iWork, where Apple’s fixation on simplifying everything leaves users scratching their heads.

In-app purchase woes

This issue is just the tip of the iceberg. In many other areas Apple’s grip on its ecosystem risks harming its users much more than it ensures protecting their interests. Take in-app purchases (IAPs), for example, where Apple wants to be the payment processor of choice in the App Store, except not really.

IAPs have become a snake pit of rules and exceptions. Developers can use them to charge customers, but only for virtual items; organizations can’t use IAPs to collect donations; and—as Instapaper creator Marco Arment discovered last year—companies can’t use them to manage recurring subscriptions unless the company actually publishes the magazine or newsletter in question. On top of this, Apple won’t let developers use their own payment systems except in connection with physical products.

This approach may be no more than a nuisance when it’s part of Cupertino’s ongoing fight with other tech giants like Amazon and Google. But it becomes a big problem when it limits what users can do with their devices, as in the case of a time-sensitive notification system that stops working because the users forgot to renew their subscriptions manually.

Time for some change

I’m not suggesting that Apple do away with its App Store rules and welcome apps willy-nilly into the iOS ecosystem. Besides being a very unlikely proposition, it doesn’t seem desirable. I like the App Store, and I like the fact that there is a barrier to entry to it.

On the other hand, I think that it’s time for Apple to figure out how to relieve some of the most pressing pain points that developers keep encountering. As a user, I’m much happier if developers can focus on building better features instead of having to reinvent the wheel for features like synchronization and inter-app communication. And as a developer, I’d much rather not waste my time on things like building my own user management or payment system, or be forced to offer an inferior experience to my users because of the fickle policies that Apple decides to enforce.

This problem is becoming more significant because iOS is becoming more important to its users—and they, in turn, are developing more-sophisticated needs and demands. Apple’s decision to publish its rulebook was a great step toward increased transparency; it’s now time to take additional steps to benefit users who want to depend on iOS as a primary working environment.