App Store Desire Paths
A few years ago, the construction of a particular office tower in Calgary closed a sidewalk for several months. I promise this will be relevant. Signage directed pedestrians to use the sidewalk on the other side of the street. However, this construction site happened to be adjacent to a train platform in the downtown business district, and many people needed to get to offices that would be easier to access if the sidewalk were open. So, they walked in the road — a sort of desire path that has already been paved.
At some point, the police got involved. They hid behind the barricade of the construction site and ticketed passing pedestrians walking in the street. There was legal justification for this: the foot traffic often held up a lane of vehicles in a way that jeopardized the pedestrian’s safety, and caused increased risk of accidents due to cars, buses, and cyclists dodging them. But the number of people who risked their safety — and a ticket — indicated that there were fundamental problems with the way the construction site was built. The sidewalk should not have been entirely closed due to the heavy foot traffic, and pedestrians should have been accommodated in a way that would require minimal detouring.
I thought of this incident in light of recent App Store matters: first it was Hey, and then WordPress, Charlie Monroe’s mistaken account suspension, and — of course — Epic Games’ lawsuit joined the mix of confusing App Store policing. In the cases of WordPress and Monroe, Apple said that it had made mistakes in communication and that Monroe’s account should not have been suspended. Both Hey and WordPress had to make modifications to conform to unclear rules. Epic, meanwhile, is singlehandedly attempting to change the App Store business model.
It would be unwise to speak to the legal aspects of these cases, so let’s think about this more conceptually. Apple undoubtably has what it believes are many great reasons for cracking down on apps like Hey and WordPress, which it sees as attempting to work around its in-app purchase model by only allowing registrations outside of each app. Many other apps offer similar behaviour — Netflix, Bloomberg’s mobile terminal, and Amazon Drive, to name just a few, are useless without signing in, offer no way to create an account from within the app, and have no in-app purchases to subscribe or change tiers. I understand why developers dislike the in-app purchase requirement: a thirty percent haircut off every purchase adds up to a lot of money, and some developers have legitimate reasons for wanting to more directly manage customer relations.
A reasonable counterargument to what I see as benefits of the current model is that Apple should be more selective of the developers it allows into the store in the first place instead of their apps. But this potentially creates a system where it is difficult for new developers to become successful — even more so than it is today.
Then there’s the case of Epic, which wants iPhones and iPads to be smaller Macs with similar capabilities. According to the email its CEO sent to several members of Apple’s executive team, it feels as though it should have native access to app installation and management, and it should be able to run basically whatever code the user agrees to. Unsurprisingly, Apple’s legal team sent a six-page letter that can be summarized as uh, no. As a result, Epic is suing to permit its vision of the iPhone as a developer platform.
Alas, I am getting lost in the marsh and bogs of App Store policy. These individual cases are not as important as the overall picture they paint: Apple’s vision for the App Store is unclear, and developers often find themselves at odds with inconsistently-enforced policy.
I think the latter conundrum often and rightfully gets all of the attention, so I’d like to focus on the former: how do these policies create the ideal App Store as Apple sees it? Its talking points of quality, security, and privacy are pretty consistent, but its enforcement of these policies is unequal and clumsy, with account creation and in-app purchase requirements often becoming specific points of contention.
I do not think it would be helpful for me — some guy in Canada — to propose ideas for what Apple ought to do. That is a waste of everyone’s time. Purely as an observer and user, it seems that Apple’s current enforcement of App Store policies has made them the police officers hiding behind the construction site barricade ticketing pedestrians instead of trying to figure out why so many tickets are being written in the first place. Surely it more desirable to think less about what is legally possible and more about what is best.
This is not an argument for Apple to abandon all control over iOS and bend to the demands of every developer. It is only an observation that the attempts at policy circumvention and aggressive enforcement actions are not sustainable for a healthy developer ecosystem. It has been a long time since Apple was a company that prioritized developer needs, but there is a big difference between being standoffish and hostile — and the latter is increasingly an apt way to describe building apps for the iPhone and iPad.
One final thought: imagine for a second that iOS is a platform with a Mac-like policy of allowing apps to be downloaded and run from anywhere. Apps may use any in-app payment mechanism, too. What if the App Store and native in-app purchase API were actually preferred by most developers? That is, what if developers could use anything, but they usually chose Apple’s because it was the best option? The way these things are set up today seems to rely on developers having little other choice if they wish to have a native iOS app. What if they were, instead, a truly great choice — even if Apple still doesn’t allow any other choices?