Apple’s new Unlisted App Distribution model

How developers can distribute and monetize applications has been evolving quickly over this last year.  Some of these changes have been in response to government or court mandates in various countries, but others appear to have been prompted by Apple itself. This week’s announcement of a new Unlisted App Distribution option is one that seems to be an evolution of Apple’s thinking in how the App Store should work.

Why is the Unlisted App Distribution model Important?

Since the introduction of the first iPhone, Apple has required developers to distribute apps through its own stores, and has always focused the most on promoting distribution of public apps to be downloaded by any user who could discover them on the Apple App Store. This makes sense, since the vast majority of iPhone/iPad users purchase devices for their own use, and more and more public apps has led to the sale of more and more consumer iOS devices.
While there are some lesser-known distribution channels that don’t use the App Store (I’ll cover them below), non-App Store channels can be cost-prohibitive and highly complex for developers and businesses to access.
Unlisted App Distribution appears to be a compromise targeted toward in-between use cases—making it much easier to target apps to non-public audiences while still leveraging the efficient and relatively friction-free public App Store distribution path most developers are already used to.

How can Apps be Distributed anyway?

To put this new distribution option in context, let’s quickly review the existing ways apps can be distributed to iOS devices, and then look at the cases where Unlisted will be most useful.
In the following diagram, app distribution is divided into options we can use during development/testing on the left, and options we have for distributing finished (production) applications on the right.

Ad-Hoc Distribution

Each development team is permitted to self-sign apps and distribute them however they wish to at most 100 iPhone and 100 iPad devices for internal testing purposes.  This distribution is intended for internal design and QA review only. External distribution to end-users is not intended nor allowed.

TestFlight (Internal)

While development teams may use Ad-Hoc to distribute internal review apps in any way they like (e-mail, file sharing, MDM systems), Test Flight provides a more structured and user-friendly way to distribute internal reviews. Only registered users of the developer’s team can use internal Test Flight, and is subject to similar (low) device counts.

TestFlight (External)

External Test Flight is a way for users outside the development organization to test new apps and provide feedback prior to a public launch. This distribution method requires developers to invite participants either by e-mail address or with a public web link.  Test Flight is limited to 10,000 public testers.
Until now, Test Flight (external), with it 10K user maximum, was the only method Apple provided to allow external users to download apps prior to general release.  Each app version distributed with Test Flight expires 90 days later, but uploading a new Test Flight version resets the 90 day clock.  Still, External Test Flight isn’t friction-less, and can be challenging for users who aren’t trained how to install and use Test Flight apps.

Releasing Production Apps

Over the years Apple has expanded how production iOS apps can be distributed to users.
Most people won’t remember that iPhone 1 had no way to install custom apps at all 😱.  This was actually quite controversial. At the time, its competitors—Windows Mobile, PalmOS, Blackberry and Symbian—all had the ability to install custom apps. Apple encouraged developers to create HTML/JavaScript apps—we all knew this was out of necessity rather than intent 😁. This limitation was soon overcome and the App Store as we know it was created.
Today we can release apps to production along a spectrum of options that support Business Apps with closely regulated user groups as well as consumer apps that have no restrictions at all. Yet it tends to serve the two ends of the spectrum well, while missing a step in the middle.  Unlisted appears to be a gesture intended to patch this missing middle.

Listed in App Store

On the far right is the distribution model most of us are most familiar with—an app is listed in Apple’s App Store, and can be downloaded by anyone (subject to regional availability).  These apps may be free, paid for up-front, or free to download but with in-app feature purchase or subscription. From a developer point of view, this is the distribution method that’s most familiar and—with automatic signing enabled—by far the easiest for most developers to use.

Enterprise Certificate

At the left side of the spectrum is the option for businesses that have custom apps restricted to its own employees. This option is most practical for large Enterprises with full-scale IT organizations. Customers can apply to Apple to purchase an Enterprise certificate to sign apps for this option. Self-signed apps can then be distributed to unlimited devices, subject to the “only your employees” restriction. This distribution method is very similar to the (pre-release) Ad-Hoc deployment above. The biggest difference is that there is not a 100 device limit, and Enterprise Certificate is intended for production releases.
However there are additional fees required from Apple, and distribution outside the developer’s company constitutes a contractural breach that can have significant consequences.

B2B and Education App Stores

I’ve grouped these two options because they’re very similar. In traditional software sales, a software company sells a number of “seat” licenses for a price “per seat” (i.e. per user or per device).  The buying company receives a license key to enable installation of the software on that number of devices.  This is essentially what these two stores are for—selling business (or education) software to businesses (or schools) at a “cost per device”.  This is most often used for enterprise software or for selling educational software. However both the seller and buyer of B2B/Education software need to setup specific accounts with Apple, and manage license keys and MDM software platforms to effectively use these programs. This is not a trivial investment on either side of the sale.

Unlisted App Distribution

The new kid on the block is Unlisted App Distribution—the subject of this article.  This is an established idea that Apple is adopting within its public App Store. Where has this idea been used effectively before?

• Public but unlisted content has been available in YouTube for years
• Vimeo uses unlisted public links in the same semi-shrouded content model as YouTube.
• I’ve previously used Microsoft’s Make this product available but not discoverable option to distribute Windows apps.

How does it work?

Basically the Unlisted in App Store option uses the same publishing path as Listed in App Store publishing option most of us are familiar with.  The difference is that Apple doesn’t add the app record to its directory or search engine (and presumably it will not appear in Google search engine results).
This has several benefits:

• Apple is promoting this option not only for Employee-specific apps, but also for apps that may be for an event (e.g. an app that has an exhibitor directory for a trade show).
• The App Store publishing workflow has been refined and simplified over the years to the point that most developers can publish apps to the App Store without knowledge of how the underlying code signing process works. This is a relatively accessible and easy to use publishing option.
• While Unlisted apps aren’t unavailable to unintended users, in practice this isn’t different than a publicly available B2B or B2C website that requires user login.
• These types of apps won’t place a public relations, support or reputation risk burden on developers, since it shouldn’t be necessary to prepare App Store screen shots, marketing copy or actively manage app review metrics & manage review feedback (though the last item is TBD, so we’ll see).

In short, I see this distribution option as very similar to Enterprise deployment, but without the additional fees and operational complexity.  Additionally, the Unlisted App option isn’t restricted to distribution within the developer’s own company, which greatly expands its use cases.

Disadvantages and unknowns

• While Test Flight can restrict who can download an app, Unlisted App Distribution cannot.  Apple suggests providing an in-app feature to authenticate users who download and attempt to use the app—much as restricted business web apps have login screens. I expect most unlisted apps will incorporate authentication into their design.
• At the time of this writing, Apple is requiring developers to request permission to use this feature.  Whether this request process is just an initial rollout restriction allowing the App Store team to monitor the use of a new feature or if Apple actually intends to be selective in granting permission to specific use cases is to be seen (hopefully the former).

Summary

Unlisted App Distribution option is a welcome option that will meet a lot of “in between” distribution use cases.  Often an app will be relevant to defined, non-employee user communities—a use cases that does’t fit Public App Store, Enterprise or B2B App Store intents. In those cases, we’ve usually used public App Store deployment while placing the app behind a login screen. Unlisted App Distribution should eliminate that ceremony and provide a more direct solution to the requirements at hand.