CODEWITHSUNDEEP
xcodecontinuous-integrationautomated-deploy
Rich
Rich

Reputation: 531

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

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;

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).

Upvotes: 9

Views: 1127

Answers (3)

Larusso
Larusso

Reputation: 1151

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

Upvotes: 0

Ronan
Ronan

Reputation: 39

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

Upvotes: 0

Eva Madrazo
Eva Madrazo

Reputation: 4731

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

Upvotes: 1

Related Questions