All I Want For Christmas: A Beta App Store

Notice: You must submit your basically untested app now or your holidays will surely be ruined. If you don’t, you’ll miss out on all those downloads that your app probably isn’t ready for anyway. Your call. Merry Christmas.

Okay, Apple doesn’t actually issue such an alert, but they might as well.

The App Store is about to shutdown for holiday break this Saturday. And so I felt it was a good time to reflect on where we are with regard to the marketplace heading into 2014. The answer, as best I can tell from talking with innumerable developers over the past year, is still very good — but it’s not exactly great. And it should be great.

More specifically, the state of testing and releasing an app has gone from more-or-less untenable to the nightmare we all knew it would become. The time is now: Apple needs to come up with a real solution to allow developers to distribute and test their apps before they launch on the App Store.

These launches have never been more critical. And they’ve never been such a crapshoot. Apple needs to address this and fix the current solutions that just aren’t working.

Currently, if you wish to test your app before launch, you have two solutions: TestFlight or HockeyApp. TestFlight has long been the favored approach, leading up to their sale a year and a half ago to Burstly. HockeyApp has come on strong as of late, likely due to TestFlight’s large number of bugs alongside recent iOS updates.

(Note that I’m not mentioning Apple’s own 100 test device allotment for regular iOS developers because such a number for any sort of actual testing is absurdly low. And worse, those 100 devices are set in stone for a year — even if you delete them from your account.)

TestFlight and HockeyApp are far from ideal from the perspective of both the developer and the end user. The process to install and use both services is at best arduous and at worst, sheer insanity (how many times can your provisioning file just. not. install?).

And let’s be clear: both are hacks. Both require a user to install a provisioning profile on a device which Apple undoubtedly would prefer everyone not do, but turns the other way. These installations, which require a full security bypass, are the antithesis of what Apple preaches with the App Store. And yet, they’ve been the go-to way to handle third-party remote app installs.

Well, almost.

This past year, I’ve noticed a distinct rise in the use of Apple’s own enterprise distribution system to push pre-release apps to testers. This method has existed for a while, but few have dared use it (without explicit permission) in the past. Now it seems that almost everyone is using it. And for good reason: it’s so much better for the remote installation of non-App Store apps.

Send a link to the file, one click install, done. No provisioning file. No mess.

This, of course, isn’t what Apple intended this system for. Such easy installs were meant for companies using private, internal apps. Apple charges $299 a year for this privilege. But Apple also can’t be completely clueless. I’ve heard from a number of developers that Apple is well aware of some developers doing this — they do screen each company that applies for an enterprise license — and chooses to turn the other way (except when they’re forced to take action).

Why? Again, because there simply is no better way. With TestFlight fleeting and HockeyApp still just a hack that can work only when situations are perfectly ideal, there is nowhere else to turn.

So here’s what I propose — it’s a solution that undoubtedly is not unique, but I feel like it is the right time: a Beta App Store.

Throughout its history, Apple has seemed to be a company adverse to the notion of “beta” products. But the more recent launches of Siri, iWork, and of course, Maps, suggest that they may be coming around. Now it’s time to go a step further: to offer a full marketplace (still somewhat curated — more below) devoted to not-quite-ready-for-primetime applications.

With a Beta App Store, Apple could provide developers a way to test apps with certain users — or even certain demographics, or regions. Developers do this now simply by releasing their apps — fully live — only in the stores of selected smaller regions (Canada and Australia being popular choices since both are English-speaking). This is more or less a “soft launch” but it’s also very much a launch. Again, the app is live. Anyone connected to the correct App Store could download it.

With an official Beta App Store, a developer could potentially set more granular parameters. Demographics. More specific regions. Unique device restrictions. You could imagine a way to make certain downloads invite-only while others are opened up much more broadly.

How could Apple do this? Fairly easily, it seems.

They would create a new Beta App Store app that is separate from the real App Store. This app would not be installed by default on devices, but would instead be a separate download (just like many of the current Apple-built apps). And, of course, it would feature a bunch of big, wordy opt-in dialogues.

But rather than allow anyone to submit apps to this new trial store, Apple should take a page from their OS X playbook. Starting with Mountain Lion, Apple began giving users the option to download an app from anywhere over the web or just the official Mac App Store. But there was also a third option: to allow downloads outside of the Mac App Store from “trusted” developers.

A Beta App Store for iOS should work similarly. A user would opt-in to it (preferably via the download of the new Beta App Store app and with all the subsequent pop-ups) but a developer would also only be approved to push apps to the Beta App Store if they were approved in the same way that Apple currently certifies approved Mac app developers. In other words, a white list of app developers.

This way, Apple could ensure that those pushing apps to this new Beta App Store aren’t trying to do so for malicious purposes. You could imagine a one-time review process for this Beta App Store — or a way to show that you’re already a developer in good standing. And, of course, a one-strike-and-you’re-out policy.

What I’m proposing is a far less restrictive App Store where trusted developers are just that, trusted. They can upload builds at will and Apple would be okay with that knowing they aren’t trying to harm users. At the same time, users are opting-in to testing these apps which still may be buggy, but again, aren’t going to be harmful. It’s a more formalized, safe, and secure system than everyone is currently using. Win-win.

So why not do this? It’s obvious, right? I imagine Apple is afraid that such a system would add both a layer of confusion and complexitity to the current App Store system. But again, I don’t think so given what I see developers already doing. What’s better: letting trusted developers push beta apps to willing testers through a lightly regulated store you can track, or letting them push beta apps to anyone via ad-hoc links?

It’s time for this, Apple. The App Store has flourished thanks to a robust ecosystem that has allowed many companies, developers, and users to thrive. But no system is so perfect that it doesn’t warrant changes and evolution over time. Now is that time.

[image: DeviantArt/TheArcSage]