Best strategy for automating multiple builds from a single white-label xcode project?

Question

I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.

Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.

Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.

Issues that need to be respected or clarified;

• Manual build of a single brand via Idiot-Proof GUI (choose a git branch/tag, specify a certain brand, configure the app e.g. IAP-enabled, server-domainname, etc - will be written to the info.plist)
• In previous manual tests, setting the executable name in the plist didn't work? Sorry, have forgotten the exact problem.. perhaps was only an Xcode Debug buildconfig problem, not relevant to a distribution build?
• Code-Signing?!? Can the profile be specified on-the-fly? Some brands need to be built with the customer's own profile.

My personal feeling: Hudson or CruiseControl + Xcode plugin.

There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?

And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.

So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?

Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).

Americana

I'm also looking for something like this. Did you ever find a solution? – Lashing

Answer 1

IMHO you can resolve all issues using different targets of XCode.

Every target will share the code but it could:

• be signing with diferent profiles
• use diferent plist: this implies having different names..
• use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
• Build with one click in XCode.

I hope this helps

Jehiel

Answer 2

An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to: 1. Unzip it (change the .ipa file extension to .zip). 2. Change assets. Update the info.plist (using Plistbuddy command) Zip it again. Resign the code.

See this script as a starting point: https://gist.github.com/catmac/1682965

Gruchot

If you have only a few white label projects to do, you can take the approach mentioned elsewhere by creating a new target each time. However, this can get unwieldy with large numbers of targets. – Gruchot

Answer 3

Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.

Polysemy