I wrote the following document for work for Project Managers and Clients (well, and to remember, myself). But, since AIR iOS Packager in the AIR 2.6 SDK has much better performance, there are many more people entering the iOS development process for the first time I thought I would post it here as well. For easier reading and printing, you can grab the PDF here.

Thanks to everyone who took a look and helped review this document: David Ortinau (and his wife Angie), Ben Borowski, Jonathan Campos and Telford Burtts (who urged me to write this up and helped form the flowcharts).

Note: This does not cover Enterprise development. For that refer to the iOS Enterprise Development Guide.

Apple iOS Development Process Summary

Understanding Apple’s iOS development process can be difficult, especially for those coming to it for the first time. The process covered in this document is not the actual development process, like using XCode or another developer tool to create applications. Rather, this document will cover the process in which to create applications that will be installable on devices and posted for sale on Apple’s App Store.

In order to get your application onto a device and sell it in the App Store you will need to “sign” it. Digitally signing your applications confirms you as a valid developer or company. This also guarantees that the application has not been altered or corrupted since it was signed. Each application you create will need to be verified as a legitimate application created by a verified creator; you, the developer or company. There are a few steps you will need to take to sign your applications stating that you are the verified creator which will verify your application.

The iOS application development process as a whole has three Phases; Development, AdHoc and Distribution, each with its own specific role. Each Phase has up to three very important Parts (not all may be used in each Phase, though). These Parts, Application Source Files, Developer Certificates and Provisioning Profiles, are what you are going to use to create and sign your application in order to view it on your devices and sell your application on the App Store. Some of these Parts have specific Elements, Developer Names, Device IDs and AppIDs, inside of them that may be required depending on the Part.

In this document we will touch on the levels of Roles within Apple Developer Program Organizations, and what each has clearance to do. We will define and explain the Parts and necessary Elements within them, how to build with them, and what they purposes are. We will also walk through the development process by Phase; what each is for, and how the Parts are used within each Phase. What we will not be going through are the steps of creating each of the Parts mentioned, or how to develop and build (aka “compile”) applications. All of that information can be found on the Apple Developer Portal, in multiple books or on various blogs, training websites, or other destinations on the internet.

You can sign up for an Apple iOS Developer Account here.
Once signed up, you will find all of the information contained in this document in the Provisioning Portal located here.

Apple Developer Program Organization Structure

Before we continue, let’s take a look at the Roles within an Apple Developer Program Organization. This Organization will be called the “Team” from here on out.

The Agent
The Agent of the organization is the person with full control over the all aspects inside of the Developer Program Organization and profile. They can create all Parts necessary for development and distribution of your applications. They are the account master.

Admins
The Admins on the Team have limited access to much of the Team account. They can invite and allow new members, assign Teammates’ roles and create some of the Parts in the early stages of development. They cannot create some of the final, necessary Parts for publishing to the App Store.

Members
Members of the Team have very limited access. They can request Parts in the development process, but they can not create them for others.

All three of the above roles in the Team can be developers for applications. Their access and abilities within the Organization and Provisioning Portal are what separate them.

Elements and Parts

Now, Let’s define and explain each of the Elements and Parts that are used to create applications. The 3 Elements (Developers, UDIDs and AppIDs) explained below help to make up the Parts. The 3 main Parts (Application Source FIles, Signing Certificates and Provisioning Profiles) are what are used to build and sign your application. The second and third parts below have different types, which will be further explored in their explanation.

Element 1. Developers
Developers are the ones that will be creating the applications, and signing them. Any of the above Team Members have the ability to do this. The Company/Organization is also considered a developer for the sake of this document. The division of Developer and Publisher will not be explored.

Element 2. Device UDIDs
UDIDs are Unique Device IDentification numbers. They are a long string of alphanumeric characters unique to each device. Each account is limited to 100 (one hundred) device IDs per year. If you add a UDID to the account and delete it, you do not get that slot back until the year is up. UDIDs can be found by plugging in your device, looking at the Device Summary in iTunes, and clicking “Serial Number.” Only the devices you add to your account can be used to test your application.

UDIDs are added to the account profile in the iOS Provisioning Portal. (http://developer.apple.com/ios/manage/devices/index.action)

Element 3. App IDs
The App IDs you will need to create are specific to your application. These are for identification of your application to Apple. Apple will generate and prefix a random string of characters to your desired ID for purposes of uniqueness. During early phases of the development process, a generic ID, or “wildcard,” can be used to build multiple applications without having to cross IDs with different apps. When in later phases and to post to the App Store, AppIDs need to be explicit. It is best to use reverse DNS style application naming for these. For instance: com.yourcompany.yourproject.YourAppName. These IDs must be unique for every application intended for sale on the App Store.

For more information on this and to create App IDs refer to the App IDs section of your iOS Provisioning Portal. (http://developer.apple.com/ios/manage/bundles/index.action)

Part 1. Application Source Files
These files are what the developer and designer will actually be creating. They are all the code, images, etc that make up the application. There isn’t much to expand upon here without getting technical. Just know that this is the meat and potatoes of the application. These are not found in the Provisioning Portal, but are local to developers’ computers. The Source FIles will have reference the AppID and will be cross referenced with Part 3 (Provisioning Profiles).

Part 2. Developer Certificate
When each individual developer signs up to to be an Apple Developer, the first thing they should do is create a Developer Certificate. This certificate is also known simply as a “.p12”, “signing cert”, “cert” or other similar names. Developers will create their certificate on their own computer, which must be a Macintosh computer for building iOS applications. Once that certificate is created, though, it can then be shared between computers and even between Mac and PC.

Individuals can be listed as developers under multiple Teams. These Teams are companies or individuals that have paid Apple the cost for developing and publishing applications. For instance, I personally have not yet spent any amount of money to publish applications, but have signed up to be an Apple Developer and am listed on multiple Teams. Individual developers will need to request and create certificates for themselves for each Team they are on. It is not possible to use the same certificate for multiple Teams.

Types of Certificates
There are 2 different types of certificates that can be created. First are the Development Certificates. These are just what they sound like, certificates used in the development and testing phases. Development Certificates are created by and assigned to individual developers. Second are Distribution Certificates. These are created only by the Agent for distributing the application in the AdHoc Phase, mirroring the final build of the application. This certificate is also used for distribution to the App Store.

For information on how to request and create certificates, please refer to the How To tab in the Certificates section of the iOS Provisioning Portal. (http://developer.apple.com/ios/manage/certificates/ team/index.action)

Part 3: Provisioning Profiles
Provisioning Profiles are a very important part of the development process. These are what make your application legitimate and usable on iOS devices. Provisioning Profiles are, in essence, text documents that contain verification information. You can have an unlimited number of Provisioning Profiles on your account. After creating a Provisioning Profile, anyone who wishes to install the application on their device must first install it to iTunes. When syncing, iTunes will install the Profile to the device. Any time the Profile has changed (developers or devices have been added or removed, for instance), and the developer has created a new build with the new Profile, the same Profile must be replaced in iTunes. If it is not, an error will be given and the application will not be installed.

More information on creating Provisioning Profiles can be found in the Provisioning section of the iOS Provisioning Portal. (http://developer.apple.com/ios/manage/provisioningprofiles/index.action)

Types of Provioning Profiles
There are 3 types of Provisioning Profiles; Development, AdHoc and Distribution. All have a different combination of the above Elements and Parts.

Type 1 – Development
Development Provisioning Profiles are used while the developer is creating the application to test on devices. There are 3 Elements that are included in this profile:

1. Developer Names – These are the developers on your Team that have the ability to
create applications with this profile.
2. UDIDs – You can use up to all of your 100 devices on a single Profile. You can also
include only some the the devices to limit which to test per profile/app.
3. AppIDs – This is for the app verification purposes. You can also use a “wildcard” AppID.

When the developer goes to create the application, they will sign it using this Provisioning Profile and their developer certificate and will supply their password to verify themselves.

Only developers whose names appear on the profile can sign an application. This is verified by cross-referencing the certificate with the name of the developer at the time of compiling the app.
Only the devices that are listed on the profile will be able to install the application. When going to install the application on the device iTunes will check that any of the device IDs on the profile match the ID on the desired targeted device. If not, the application will not be installed.

Type 2 – AdHoc
These Provisioning Profiles are used when simulating App Store ready applications. These are a way to test your applications as if they were downloaded from the App Store. This Profile can only be set up by the Agent of the Team. There are, again, 3 Elements to this Profile.

1. Company Name – The company / organization name. This will be cross referenced with
the certificate at time of building the application.
2. UDIDs of the devices to test on.
3. AppID – this must now be explicit and unique.

Like the Development Profile, the AdHoc Profile contains the identifying information about the app and developer, this time being the company or organization who has created and will release it. This Profile must also be installed into iTunes synced with testing devices. The same verification of the Development Profile will be enacted here. You will use your Distribution Certificate when signing your application.

Type 3 – Distribution
Once AdHoc testing is complete, use the Distribution Provisioning Profile and Company Distribution  Certificate to sign and send the finished application to Apple for review and submission to the App Store. You will not be able to put the Distribution builds of the application on your devices, so there are only 2 Elements that make up this Profile.

1. Company Name – Same as the AdHoc Profile
2. AppID – double check that this is exactly what you want it to be as there
is no going back once the application is published.

This Profile is very important, so make sure to double or even triple check the information before posting the signed application to Apple for review. You will use the Distribution Certificate when signing your application for final approval by Apple.

What these Parts and Elements look like as a simple flowchart:

Phases of Development – Bringing It All Together.

There are three overall phases: Development, AdHoc, and Distribution. In each of these Phases you will use the 3 Main Parts (Source Files, Signing Certificates and Provisioning Profiles) made up of the 3 Elements (Developers, UDIDs and AppIDs) to create your application.

Phase 1: Development
The Development Phase is just what it sounds like: the period in which your application is going to be built and functionally tested. Often during this phase, the application will be compiled and loaded to devices multiple times to test and retest for functionality, design and bug testing. In order to build applications for the devices during this Phase, the developers will use the Application Source Files, Developer Certificate, and Provisioning Profiles.

The Development Provisioning Profile will have the AppID and Developers listed inside. The developers will take the Provisioning Profile, the Application Source Files and their Developer Certificate to compile the application.

Since the Profile and Source Files contain reference to the AppID, both must match. When using a wildcard ID the AppID listed in the Source Files only needs to match to the point where the wildcard begins. For instance, an AppID can be simply “ * “ meaning any name I given inside  the Source Files will work. But if there are any characters in the ID, the Source Files’ ID must match. For instance, an AppID “com.yourcompany.*” can look like “com.yourcompany.YourAppName” in the Source File reference.

Only developers listed on the Profile can compile applications with that Profile. When the developer compiles the application they will sign the application with their Certificate and password that they created when generating the Cert.

Once the Application is built, it is then possible to install it to iTunes, and sync to the device for testing. Here is what the Development Phase looks like as a flowchart:

Phase 2: AdHoc
This Phase is used for testing your application as if it was downloaded from the App Store. At this point your AppID must be explicit and unique and must match in the Source Files and Provisioning Profile. You will also be using your Organization’s Distribution Certificate and Distribution Provisioning Profile, which also must match. This is to ensure everything is ready for posting for Apple to review your application. If there are errors with the signing process, or with your application, Apple will reject your application from the admittance to the App Store.

Phase 3: Distribution
Once your application has been fully tested in the AdHoc Phase and is ready to be shipped to Apple for review, it will be built one more time. This time it will be prepared for sale and download in the App Store. Once the application has been built in this Phase it will be uploaded via the iTunes Connect Portal.

Conclusion

Now you have knowledge of how the iOS Development Process works. We have explained what each Part (Application Source Files, Signing Certificates and Provisioning Profiles) and Element (Developers, UDIDs and AppIDs) in the process is needed for. We have also taken a look at how the all tie together.

By combining each Part and their included Elements we have just explained what it means to create and sign a valid application in each Phase of the process.

While in the Development Phase your AppIDs could be a wildcard, or non-explicit, identification. When in the AdHoc and Distribution Phases your AppID must be explicit and unique to your application.

In the Development Phase we used the Developer’s Signing Certificate, the Application Source Files and Development Provisioning Profile. In the AdHoc Phase we used the Company/Organization’s Signing Certificate, Application Source Files and company AdHoc Provisioning Profile to simulate what the application would be like if downloaded from the App Store. In the Distribution Phase we signed the application using the Source Files, Company Provisioning Profile and Distribution Certificate.