The Distro Scheme

If you came to Xcode4 from Xcode3, you noticed a distinctly different methodology to the way in which apps are built, namely Schemes. Schemes introduce more organization and flexibility to how you build targets in Xcode and to what is actually produced. But with flexibility comes some complexity that can be frustrating at times. Once you get used to schemes, however, they are not so bad. This article is not a complete treatise on schemes. Rather, it highlights one workflow trick I devised using schemes.

A scheme is a collection of build actions (Build, Run, Test, Profile, Analyze, and Archive). For each build action, you can define a handful of characteristics. Among these is which kind of build to build? That is to say, is it a debug build, a release build, or what?

Let’s focus on the type of build any particular action gets. Specifically, for the Archive action. This build action is interesting because you must use it to create an archive to submit to Apple, and you use it to create Ad Hoc builds to send to colleagues or beta testers. Alas, the Archive build action in a scheme can have only one build type at a time, and the Product -> Archive menu option just builds according to the scheme settings. As is, you have to remember to edit (or at least check) your scheme settings before you build an archive, if you build more than one type in your development process! What a hassle!

Detour: Build Configurations

As an aside, it is worth noting that the type of build performed for any action (Debug, Release, etc) is actually one of the defined build configurations in the project. Build configurations are defined in your project’s settings, under the Info pane:

By default, a new project has Debug and Release configurations. I always duplicate the Release configuration and rename it Distribution. In some projects, I also duplicate Release and rename it Ad Hoc, if I need that. And for the purpose of this article, let’s assume we do! (Release and Distribution really are the same; you could rename Release to Distribution rather than duplicating and renaming. The significance of the name Distribution is that it helps Xcode match suitable provisioning profiles. I use keywords like “Debug”, “Ad Hoc”, and “Distribution” in my provisioning profile names for this purpose. For example, “Hawk iMedia Distribution Profile”. When selecting code signing profiles, this helps Xcode select the right one or highlight appropriate profiles for you to choose one.)

Back to Schemes

My “aha!” moment with schemes came when I realized (finally!) what use there might be for duplicating a scheme. For projects that will have the need for both an Ad Hoc build as well (of course!) as a Distribution build, I configure the Archive action in my project’s default scheme to use my Ad Hoc build configuration. When I am working on anything except a final build for submission, I make sure to choose the default scheme for the project. This has the added benefit that my entire development work flow before I am anywhere ready to build a Distribution build uses the same scheme, unedited.

For Distribution builds, however, here’s the trick. Duplicate your app’s scheme, calling it something like “Distro: My App”, and change the build configuration for the Archive action to Distribution (or whatever your submission build type is called).

Now, when you want to build an archive to submit to Apple, you simply have to select your Distro scheme, and select the Product -> Archive menu item, which is much simpler than editing and checking scheme settings all the time.

Got some other scheme tricks? What are they?

Posted in: iDevBlogADay

3 comments

  1. Yes, this is exactly what I discovered a few months ago and it’s made life a little easier indeed.

  2. Jim Dabell says:

    There’s a better way of doing things that I’ve been trying to find the time to write up properly. This is an abbreviated version.

    Ditch configurations. Instead of debug and release configurations, have development, ad hoc and App Store targets. This isn’t any more complex, and it is more flexible in several ways. One of these is relevant here.

    Go to the Build section of the scheme editor, and you will find you can add additional targets here. If you add your ad hoc and App Store targets, you can make sure that they are ticked only for archiving. Now, when you archive, both ad hoc and App Store builds will be created, and you don’t have to remember to manually switch schemes – one scheme is enough.

  3. Very nice! Thanks for sharing this. What I like about the multiple-scheme approach, as I described, is that you do have to specifically choose it, which means that as you’re doing it you can mentally recognize “Oh, this is something different that I don’t do often.” It has the additional advantage that you build just what you want, when you want it. But I think you’re approach may use schemes more in line with how Apple intended them to be used, so I am going to keep it in mind for future projects.

Leave a Reply

Your email address will not be published. Required fields are marked *

Prove you are human: *

Read previous post:
The Veiled UI

Despite what Apple's Human Interface Guidelines may say, sometimes you want to prevent your user from doing anything until some...

Close