Imagine this: you’re in the zone, writing code, totally focused, working on that feature you finally managed to wrap your head around. All of a sudden, you feel a tap on your shoulder. It’s your boss.

“Hey! I’m meeting with a client in 10 minutes and I want to show him the app you’re working on. Can you install it on my phone?”

Everybody works differently but chances are that you’re used to this demand because it happens everyday. It may not be your boss though. Sometimes it’s a Quality Assurance Engineer who needs to see if a bug has been fixed. Sometimes it’s your Project Manager. At every company there is always one person in charge of those demands. Don’t be that person. Today I’m going to show you a way of making a build automatically available for your boss to install.

Prerequisites

Before we start digging into Xcode and the application, we need to have a place to store the application. This place needs to be available the member of your team. I’ve decided to keep things simple and use Amazon S3 in my examples, but feel free to use any tool capable of hosting and distributing static files.

Setting up Amazon S3

I’ve decided to go with Amazon S3 because it’s simple. In that sense, being able to drop the files we need in Amazon’s console will do just fine. If you need help creating a bucket (you can see a bucket as a folder), the documentation is quite straightforward.

In this bucket, we’ll upload a small website. The last thing we want would be people asking you what to do on this page and how to download the application. Remember that the whole point of this is people letting you work on the application while being able to play with the latest version. With that in mind, we’ll just put a big title and a just-as-big install now button.

The website used as an example is available in this Github repository. We’ll see how to customize it in the rest of this article.

The application

Recently I’ve been trying to force myself into developing a writing habit and after each session I started wondering how many words I’d written. With that in mind I created an application that counts the number of words in posts on my blog. The application is available on github so feel free to refer to it.

https://twitter.com/Palleas/status/826944054323769347

Archiving the app with Xcode

When people start looking for tools to improve the way they work, they can quickly get overwhelmed. Which tool should they use? Should they pay for a service or build it from the ground up? If this is your case you will be happy to know that we’ll only need Xcode to export the application.

First, make sure you’ve selected “Generic iOS Device” in the list of devices and that you’ve checked the “Automatically manage signing”. Once again, we only want to focus on making your app available.

Then, select “Product > Archive”. It will generate an archive of your application and should automatically open Xcode’s “organizer” panel (see figure 2). If it doesn’t, this panel is available at all times in the “Window” menu.

Exporting the application

This panel shows a bunch of information about your archive: the bundle identifier, the version… if you’ve already submitted an application to the app store, chances are you’ve already seen this panel and clicked on the “Upload to App Store” button. But in this case, we don’t care about this button; we want our build to be available outside the App Store. That’s why we’ll use the “Export” button. In the panel that will open, we’ll select “Save for Ad Hoc Deployment” and click next.

Ad-Hoc distributon is a feature Apple introduced a couple of years ago with iOS 4. Before that, you had two ways of installing an application on your device: using Xcode or using the App-Store. Ad-Hoc involves a specific provisioning profile listing all the allowed iOS devices. You don’t need to care much about that since we are letting Xcode manage the code signing for us. Just know that this is what it’ll use internally.

If you’re authenticated in multiple Apple developer teams, Xcode will ask you to select the one you want to use to release the application. In the next figure, I’m using my own. That’s one of the many great things with this feature: you don’t need to have a super-expensive entreprise account.

Xcode will then ask you to select the devices to which the application will be exported. Select “all compatible devices”, as shown in figure 5. Exporting the application for specific models of iPhone or iPad involves knowledge about device architectures and that’s a complex topic we won’t cover today.

The manifest checkbox is important, although we could easily skip it in the future. Distributing an iOS application on a device is a little different than downloading an application on your Mac (or your Android device). The big install button we put on the website won’t be a direct link to the built package. You will actually ask the phone to fetch a manifest containing a bunch of information about your application, including the link to the installation binary. The figure 7 shows the panel we’re talking about.

That’s when it gets a little bit confusing. The window shown in figure 7 asks you a couple of questions about the manifest. Specifically, it will ask you for:

• The name of your application
• The URL to the binary we’ve just built
• The URL to the icon of your application in 2 sizes: 57px for the thumbnail, and 512 for the large one.

It is confusing because as this is the first time we are building the application, we don’t know the exact URL at which the application binary will be accessed. Worse, the panel won’t let you leave this field empty, nor let you use anything but https. At this point we are clearly in a chicken or egg situation, so I would strongly suggest for you to chose the easiest route and use a dummy value that we will update later. Click export and finish the process.

Navigate to the folder in which you’ve chosen to store the exported app, you’ll see 2 things: the IPA and the manifest file. The manifest is a property-list containing informations about your software: the bundle id, the version, the url of the software, etc.

Uploading the app to S3

Now that we have a packaged version of our application, we’ll need to upload it someplace accessible to anyone with the manifest. In our case, that’s an Amazon S3 bucket. Grab the URL to your IPA and put it in the manifest, in the software-package section, then upload the manifest as well.

Finally, open the webpage we’ve created and update the url in the download link to itms-services://?action=download-manifest&url=manifest-url, where manifest-url is the url to the manfest file you just uploaded.

Making sure everything works

To make sure everything works, visit the website we’ve setup on your mobile and tap the install button. If everything worked according to the plan, you should be prompted with a confirmation popup, asking you if you really want to install the application (see figure 11). If it does, congrats! If it doesn’t, make sure you’ve done everything properly: are you using Xcode’s automatic code signing? Do you have and old version of the app already installed that could create a conflict?

Where do we go from here?

The great thing with this process is that it is straighforward: we clicked a bunch of buttons and let the tools do the rest. Of course, since you’ll probably want to push an updated version of your application, you’ll have to re-export the application and upload it to S3.

Continuous Integration and Deployment may seem overwhelming at time, but it doesn’t have to be. The goal of this post was to show you that you already have all the tools needed to make a build available to your team, your boss or your client.

Of course, there are many aspects that we didn’t cover: proper code signing, versioning, installing multiple versions of an application on your device and, of course, how to automate the entire process.