I’ve encountered a lot of confusion about the different mechanisms available to get apps into the hands of your target users. This article explains the options and their respective limitations.
Note – some of the links below may require you to enter your Apple Developer credentials.
Type of Apple Developer Account
When you sign up as an iOS developer you have 3 choices:
- Developer – $99/yr USD. Must distribute through the App Store.
- Enterprise – $299/yr USD. Must distribute internally.
- University – free. Attached device install only (no distribution).
The Developer account is most common. It is appropriate for individuals or companies and the account can have many team members. After developing and testing your app, create a release build and submit to the App Store through a review process. Apps can be free or fee-based. Apple operates App Stores in a number of geographies if you wish to localize for languages and locales beyond your primary target audience. You’ll also need an iTunes Connect account to submit your app.
The Enterprise account is designed for companies to develop and distribute apps to their employees. The company must have a D-U-N-S number and Apps must be free. There is an approval process for the account, but not for the Enterprise apps themselves. The approval process will take a few days – and can take much longer if the CEO, CFO, and legal counsel are slow to respond to Apple queries. You must ensure that only “properly authorized users” are allowed to install Enterprise apps on devices. You should read the legal agreements and make your own determination, but companies I’ve worked with interpret ”properly authorized users” as direct employees only – not contractors, sales agents, resellers, or anyone else who isn’t a W-2 employee. If your Enterprise develops both internal and App Store apps you need to sign up for both account types.
Finally, the University account is designed for higher education institutions looking to introduce iOS development into their curriculum. Students can install apps on their devices – there is no distribution channel. For purposes of this discussion, I’m ignoring the University account.
Type of Distribution
AdHoc. Designed to support testing prior to broad distribution, both Developer and Enterprise account types allow AdHoc distribution to a maximum of 100 devices. Each device must be “registered” to your account’s iOS Provisioning Portal using the UDID (Universal Device ID). AdHoc builds will not install on unregistered devices.
While most commonly used for testing, it is permissible to distribute release/production apps using AdHoc distribution, subject to certain restrictions – most notably registered UDIDs and 100 devices. See the iOS Developer Program License Agreement for details.
Distribution. Developer accounts can only distribute through the App Store. The app is built for release in Xcode, then cryptographically signed, sealed, and delivered to Apple for their review process. As mentioned earlier, Apple operates App Stores in different geographies, and you submit your App to 1 or more of these stores.
Generally speaking, apps in any store are available everywhere and you cannot restrict anyone from buying your app. There is an exception for custom B2B apps you make available to your identified clients through Apple’s Volume Purchase Program (VPP). Your clients must register for the VPP, and you identify your clients using their registration ID.
Enterprise. As few developers have experience with the Enterprise developer program, there is a lot of confusion about Enterprise distribution. You DO NOT have to register device UDID’s for general distribution within your enterprise. You may choose to use AdHoc distribution during development of your app in order to strictly control who has access to it prior to full release. If you use AdHoc distribution during development it has exactly the same restrictions as mentioned above. But when your app is ready to be widely distributed to your employees, UDIDs do not matter, and there are no restrictions about the number of users or devices – provided you adhere to the “properly authorized user” clause.
Mechanics of Enterprise Distribution
Apple’s website describes Distributing Enterprise Apps for iOS Devices in detail, but here are some of the highlights:
There are four ways to deploy an app:
- Distribute the app for your users to install using iTunes.
- Have an IT administrator install the app on devices using iPhone Configuration Utility or Apple Configurator.
- Post the app on a secure web server; users access and perform the installation wirelessly (OTA).
- Use your Mobile Device Management (MDM) server to instruct managed devices to install an in-house or App Store app, if your MDM server supports it.
I get a lot of questions about OTA installation – it’s actually pretty easy. You’ll need:
- A secure web server that authenticated users can access
- An iOS app in .ipa format, built for release/production with an enterprise provisioning profile
- An XML manifest file in .plist format
- A network configuration that allows the devices to access an iTunes server at Apple
Xcode generates the .ipa and .plist files when you perform the release build and code-sign it with your Enterprise credentials. Upload those files to an area of your web server that your authenticated users can access.
Your website design can be as simple as a single page that links to the manifest (.plist) file. When a user taps a web link, the manifest file is downloaded, which triggers the downloading and installation of the apps it describes.
Here’s the code for the link itself – note the url points to the .plist, not the .ipa:
Don’t add a web link to the archived app (.ipa). The .ipa is downloaded by the device when the manifest file is loaded. Although the protocol portion of the URL is itms-services, the iTunes Store isn’t involved in this process.
Good luck, and good distributing!