Looking to distribute an app? Planning to use the app store? That’s one way to get apps in people’s hands. But we also put apps in peoples hands for development, testing, or possibly enterprise distribution. I’ve been doing a lot of this lately so I thought I’d write it up while it’s all fresh.
Let’s take it step by step. When you first write an application you’re working as a developer with a phone (or iDevices) setup for development. You write and test with an iPhone (or device) in development mode. But then you want to see if your work meets user’s standards. So you recruit some test users and put your app on their phones using ad-hoc distribution. Once they’re happy, you can submit to the app store, to the VPP app store, or do your own distribution in-house in a company or organization with enterprise distribution. The process looks like this:
Each box in the chart is a type of distribution mode and has its own requirements and limits. (Note that Apple refers to distribution as anything but development.) This post describes those requirements and limits and what you can do with each mode. This post is long enough so I’m generally leaving the procedures of how to do each one to future posts.
I use the Xcode organizer to read and upload information with a phone. There are other ways to do some of this with IPCU (iPhone Configuration Utility), but here I’ll be focusing on Xcode and its Organizer window with the device tab active. Also, I’m talking about Xcode 4.5 and 4.6 only. If you have an older Xcode you should probably upgrade. (Use the Mac App store.) In any case if you want to submit to the app store or VPP app store, you’ll have to use the latest production Xcode (4.5 at this writing, probably 4.6 within a few months).
Devices used for development need to be set up for development. This lets you debug with them and gives you access to your application files on those devices.
To put a device into development mode you need to click the “Use for Development” button in Xcode’s Organizer when the device is plugged into your Mac. (This only shows up when the device is not being used for development.) You also need to list its UDID in your Devices list in the iOS Provisioning Portal. Xcode automates part of that process. But if you’re using a custom development provision profile you need to add that device to that profile. Your development profile lists the device UDIDs that it can be used on.
With that done, you can now run in the debugger on that device. In addition the crash logs and console, you can access your application’s files. This includes custom log files your app has written out to the devices disk, cache files, SQL files, etc. If you design your app with this in mind it can be a valuable debugging tool!
To access those application files:
- Connect your development phone to your Mac and open Organizer in Xcode with the “Devices” tab active. Wait until your phone shows a green dot next to it.
- Click your “Applications” item under your phone, then on the right, click your application under development.
- After a moment (as the files are downloaded), your applications files will show up in the bottom pane of the Organizer window.
- You can use the “Download” button at the bottom to download your files from your iPhone to your Mac. They’ll show up with a name like “com.YourCompany.YourApp 2012-12-30 18.104.22.168.xcappdata”.
- To open this right click the file (control click or two-finder tap) and select “Show Package Contents” from the contextual menu. This allows you to see your app’s saved files.
Ad-hoc distribution is not development; it’s a distribution to a strictly limited set of devices for testing purposes only. Ad-hoc uses the same 100-device list as developer mode does.
Ad-hoc distribution lets you install your app without going through the app store, but you’ll need to create an ad-hoc distribution profile for your app. This profile must be installed on your device for the iPhone or device to accept that app. Also, the device will have to be added to your device list just like with development mode above. When you make your ad-hoc distribution profile, you’ll have to list the devices it will work with as you listed the development devices on your development profile. The devices this profile will work on are listed in the profile, like the development profile.
Ad-hoc is designed for doing beta testing with only a small numbers of users. Presumably these are users you’re working with and who will give you reports to you about the app and any shortcomings. These are also users that will send you their UDID numbers. You’ll need that to add them to the device list. There are some free apps like “Ad-hoc helper“, ”UDID“, and “UDID Sender“ that your testers can download and use to send you their UDID information. Your users can also get that UDID from iTunes, but the apps are easiest and less error-prone. Alternately if your beta testers are local, you can plug in their phones to your Mac and get their UDID yourself from Xcode’s Organizer like you did with your development devices.
Some good practices during ad-hoc (and development too) are to:
- Install BugSense or Google Analytics for iOS (or some other crash logging system) in your app for crash logging. (The first is better for crashes but doesn’t do analytics, the second is better for all-around analytics usage data but can get some crash data too.)
- Sit down with (or Facetime or Skype) your beta testers and walk through the app. Watch them, but don’t coach them. See where they have problems. Redesign and rewrite your app accordingly.
At this point, your ad-hoc users think your app is the greatest thing ever. It’s time to distribute to the world!
The Development/Ad-Hoc Device List
First, an aside: The device list for your developer account has a few key points that are worth noting. It’s limited, it’s updated yearly, and your developer ID has only one list. Manage them well as it can be a scarce resource.
You can get another list of the same 100 size by setting up another developer ID for yourself, but it’s awkward and difficult to shift between the two developer IDs. That works best for multiple development teams where each team primarily uses their own team ID. Although if you’re doing contracting work it would be a good idea have your customer set up their own developer team ID which you would use for their work. If you set up too many under your own name (aka email address) Apple could think you’re trying to work outside the system and possibly even revoke your developer IDs. (They’ll contact you first.) Key points:
- List size is 100 devices per developer ID (or developer team Apple ID).
- This list is used for Ad-Hoc and Developer ONLY. It does not apply to other distribution modes.
- You can add and delete any time but deletions only become effective once per year on the anniversary of your developer ID creation.
- If you max out, you’re out of luck.
So What Release Distribution Should I Use?
There are three ways to get your app into user’s hands. The well-known way is the app store. But if you are in a narrow market and perhaps you’ve customized your app for one or a few customers, you can use VPP, the Volume Purchase Program. (From the developer side it’s also called “B2B” for Business to Business.) VPP is a specialized form of app store distribution. This lets you allow only a set of customers you’ve selected to see your app. You’ll need a different application ID for VPP than for any app store work, but you can do this on your current Apple ID (developer ID).
There’s also the Enterprise Distribution for in-house distribution at a company or organization. This does not go through the app store process at all and you handle all details of distribution. You have to get a special Apple ID (developer ID) for this in addition to a new application ID.
App Store Distribution
This is what most developers use since most of us want to reach a large audience. To do this, you’ll need to go to “Provisioning” in the iOS Provisioning Portal and select the distribution tab. There you’ll create a distribution certificate and profile and download and add them to Xcode. (The certificate gets added to Keychain Access.)
In Xcode, you’ll make your app with the “Archive” command and sign it as an ad-hoc. This sets the stage for submitting it to the app store. Next you’ll use iTunes Connect (from iOS Developer Center) to setup your new app data. You’ll need the app title, version, description, copyright, app store categories, your website address, any review instructions, screenshots and your app icon in 1024×1025 size. Walk through that process until you get to “Ready for Upload” status.
At that point you can go back to Xcode and select your app in the Archive, and click the distribution button. Xcode will re-sign your app with your app store profile and upload it to the app store for review.
After an initial routine and automatic validation step, your app will be in the queue for review. Lately I’ve seen a 5-8 day review cycle for my apps for both app store and VPP submissions.
VPP apps are submitted in a very similar way as above and also go through a review process. Apple has asked me during review what customizations I’ve done for the app. This is an incorrect question as customizations aren’t required; you can nicely point that out to Apple and they’ll approve your VPP anyway. (At least they did with us.)
The only difference between an app store and a VPP app store submission is that during the iTunes Connect setup for submittal, you tell iTunes Connect you’re submitting a B2B app. You do this on the same page where you set your pricing and availability for your app by clicking the “Custom B2B App” checkbox. Then, enter the Apple IDs of the customers you want to be able to see this product or release.
You use VPP when you have a customized app for a customer or set of customers, or when you have a limited set of known customers. Note that you’ll need your customer’s Apple IDs that they wish to buy your app with. If they have several Apple IDs then make sure they get you the right one! Believe me, this solves problems later.
This is different since you’re not going through the app store at all! There’s no review process. And you can’t do this with your regular developer team ID that you use with the app store. You’ll need to make a new developer ID specifically for enterprise distribution (and a new application ID too). Apple may call and talk to you. They’re nice; they just want to make sure that you know this isn’t for distributing the same app you may already have in the app store.
With enterprise there’s no help in distributing to your users and installing on their iDevices either. Users can’t go to the app store to get these! You have to distribute yourself. This is designed for using in-house in a corporation, or perhaps a large organization of some sort. There’s no limit on the number distributed to, but it is up to you to control access and to limit distribution to your employees and subcontractors. To do otherwise is to risk Apple revoking your developer ID and that’s a lousy way to shut down your development!
The reason this works for unlimited numbers is that each enterprise app is signed by you instead of by Apple. You control which iDevices it’s distributed to, how it gets to them, and who gets to install it. The enterprise profile does not list the devices it may be installed on and you are not limited by the 100 device limit as in ad-hoc and development. (This is a source of confusion for many developers.)
When you do enterprise distribution, you distribute by choosing the “Save for Enterprise or Ad-Hoc Distribution” radio button in the distribute panel in Xcode Archive. Then click the “Save for Enterprise Distribution” checkbox in the save file panel. That opens up some fields which sets up an XML file you can use for OTA (Over-The-Air) distribution. I’ll do another post about that later.
Or instead of OTA distribution, you can simply load the ipa file directly onto people’s phones with IPCU or Xcode.
Below is a quick reference to some of the features of the various distribution modes. I hope this clarifies some of the confusion about ad-hoc, enterprise, and other ways of putting your app on iDevices. I welcome your comments or questions.