One of the tasks we are beginning to explore at AIS is developing and distributing mobile applications for our corporate clients. One common scenario will be for these apps to be available only for their employees, or a select group of their clients. So distribution through Apple’s App Store, for example, may not be an acceptable solution.
There are several options for distributing enterprise iOS applications, if we can’t (or don’t want to) go through the App Store:
1. Ad Hoc distribution. This involves building the distribution files, distributing them to the clients (via email or posting them to a server), and having them drag the files to iTunes and then synchronizing their devices. That’s a little messy. And it requires repeating the process every time there is an update to the app.
Again, this is a messy process, and will have to be repeated for each update and new app.
3. Mobile Device Management. The SysAdmin can install apps through MDM (Mobile Device Management, requires sign-in). Again, device management is required, but MDM allows for remote management once the device has been initially configured. When a new or updated app is available, the administrator creates a new payload, sends a push notification (through Apple’s Push Notification Service) to the appropriate client devices, and the devices execute the command (in this case pulling down and installing the app in the payload). If MDM is already a feature in the organization’s administration processes, this is a viable option.
4. Distribute apps wirelessly, using the Over the Air (OTA) process. This is the route I’ll discuss in detail, as it seems to be the most straightforward and easiest to implement of the available options, especially if MDM is not applicable. There are some wrinkles, too, which can automate the process of updating/upgrading the apps transparent to the users.
App Development and OTA Distribution Process Overview
There are several steps involved in app development and the OTA distribution process. From a high level, they include:
1. Develop the iOS app. Obviously, the app needs to be developed! The standard process is using Xcode, Apple’s IDE. You can also use MonoTouch, a cross-platform IDE and SDK that allows you to use C# and .Net to create natively compiled iOS apps.
2. In order to be able to distribute the app, you need to purchase an Enterprise Development License through Apple.
3. Once the license has been approved, and the app has been developed, a provisioning profile needs to be created through the iOS Provisioning Portal (you can only see this if you are logged in as a developer).
4. Once the provisioning profile is installed, build and archive the app.
5. Before you create the distribution objects, make sure you have the web server set up and properly configured.
6. Create the Distribution and save.
7. Push the IPA and Manifest files to the web server.
8. Create a link on a web page that will be available to the appropriate users.
9. Send the link out to users.
10. When a user clicks on link, a dialog will come up asking if they want to install the app.
11. When installed and tapped, another link will appear, confirming startup. Upon acceptance, the app will run.
We’ll now discuss #4 – 11 in detail.
Build and Archive the App
Assuming your app compiles and runs according to specifications, you should “Build and Archive” the application for distribution (Product -> Archive).
Upon successful completion of the archive process, Xcode’s Organizer will come up, listing all of the archives created for your apps. This is where you will actually create the distribution objects. But before you take that step…
Set Up and Configure the Web Server
Make sure you have a web server online and configured properly. The most important aspect of this is to make sure that the proper mime types have been added to the Mime Type Settings:
For Mac OS X Server:
You will also need to determine exactly where on the server the ipa and manifest files will be stored. For this example, we put MobileCaseWorker.ipa and MobileCaseWorker.plist in /apps/MCW/1.0/ (making the fully qualified path for our test app distribution server http://10.2.2.58/apps/MCW/1.0/). Knowing this path is important for the next step.
Create the Distribution Files
Now that you have the web server set up and the path established, go back to Organizer:
Click on the “Distribute…” button.
Select the appropriate archive, then click “Distribute…”
Select “Save for Enterprise or Ad-Hoc Deployment” and click “Next”.
Choose an identity, and click “Next”.
Give your distribution package a name, and make sure you select “Save for Enterprise Distribution”. The fields for Enterprise Distribution will appear. Fill out Application URL with the exact path (including the domain name and the ipa file name, including extension), as determined in the previous step. Thus, for this example, the path would be http://10.2.2.58/apps/MCW/1.0/MobileCaseWorker.ipa.
Select where you want to save the distribution files and click “Save”.
Push Files to Web Server & Create Link on Page
Two files have now been created:
Both of these files need to be placed in the appropriate directory on your web server. Once that is done, create or modify, a web page to which the users will go to download the app. The page will have a link to the manifest file, but the structure is specific:
So, for our example, it looks like this:
<a href="itms-services://?action=download-manifest&url=http://10.2.2.58/apps/MCW1.0/MobileCaseWorker.plist">Mobile Case Worker 1.0</a>
Once you have everything in place, you can send a link to this page to your users. They can then load the page into mobile Safari and tap the link:
When they tap the link and select Install, the download and installation process starts:
Once the app is installed, the user will be prompted one more time to allow the app to run on their device. Once they accept, they’re good to go!
There are some nuances and potential gotchas involved in this process:
1) The web server should be secure, especially if the applications being made available are sensitive.
2) With that in mind, you can embed a direct link in an email to the users.
3) If you want to get fancy, you an set up a version management system on the back-end, with appropriate code in the app itself. Every time you push up a new version of an app, the user will be restricted from using the app until the new version is installed. One way of doing this is to have the app poll the server every time the app starts up or is awakened. It can get the latest version number from the server and compare it to the currently running version. If a newer version is available, it will then post a modal dialog, with a link to the latest download. Once the app is updated, all should proceed normally.
4) The name you give the app in Xcode (Target Name), and the App ID you give it in the Provisioning Portal have to match exactly. Usually, the App ID will follow this format:
In Xcode, select the Target, click on the Summary tab, and fill out the Bundle Identifier appropriately:
If there is a name mismatch, build errors will occur until this is corrected.
5) There is apparently a bug in Apple’s implementation of the “itms-services” protocol. No spaces, even if they are escaped or URL Encoded, are allowed in the file name or web folder structure.
6) If you forget to add the mime types identified above, a rather generic “Cannot connect to 10.2.2.58” message. We figured this one out the hard way….
In addition to the links provided throughout, we also got a big helping hand from this blog post at Syndicated Methods. That kept us from turning issue #6 into a half-day marathon of troubleshooting.
There are no “ideal” solutions to Enterprise iOS Application deployment. But with a little work, and enough foresight, the pain can be minimized and the process can be relatively transparent to your (or your clients’) users.