One Xcode 4 Project, Four Target "Variations" ... With A Twist
I have a sneaking suspicion that what I'm looking to do can be done more elegantly within Xcode 4 ... but then I've been wrong before. Here's the scoop:
I have an iOS app with the usual debug/release builds and regular, unit-test, and ui-test targets. Nothing unusual there. The app also calls out to a server. Nothing special there either. Except ...
Now I want to be able 开发者_如何学编程to build the app for four different server environments: Development, QA, UAT/Beta, and Production. In addition, each build must be able to co-exist on the same device, for developer builds or ad hoc distribution.
So let's see ... how might this pan out? Each app will need its own target identifier for starters. Perhaps detecting the kind of build could help target which server to use:
Debug builds target Development. (Ad Hoc Distribution) Release builds target QA (... or UAT/Beta?). (App Store Distribution) Release builds target Production.
As for those Target Identifiers (com.companyname.appname), I suppose I could use different Info.plist files for each build ... but that smells unwieldy (duplicate info). Perhaps it's the only way?
Bottom line: I'm uncertain of a) how to resolve the Ad Hoc vs. App Store Distribution cases, as well as b) the QA/UAT cases, as well as c) how to do this without messing up the (at least to me) more elegant setup Xcode 4 offers with those simple "Press Play" Debug/Release build ops.
Maybe I have to add new Schemes? Perhaps it's simply a matter of adding more Info.plist files ... or builds ... or configurations ... or targets ... or some mixture. Again, I'm trying to keep from duplicating a lot of info (only to change one or two settings) if I can help it. Debug/Release seems very clean as it is, and I want to make sure I change things along the proper axis. Measure twice, cut once, as they say.
Clues welcome/appreciated!
Here's what I ended up doing. Hopefully this is the most sensible way to go about it:
- For now, I combined QA and UAT. (This may be split later on.)
- I made three Info plists, one for Development (Debug), Beta/QA/UAT (Release), and Production (Release). Each of these has slightly different bundle display names, bundle identifiers, and bundle names, but is otherwise identical. (THIS is where the lion's share of duplicate info will be. Have to change things in all three - for instance, if I add a new font or URL type.)
- I created a new configuration, Beta (based on the original Release/Production config), so now there's Dev, Beta, and Production configs as well.
- In the Provisioning Portal, I set up App IDs using the previously declared bundle IDs, and generated new certs for Beta, Dev, and Production. (The existing app ID ends up being used for App Store releases.)
- In the Build Settings, I used Conditional Settings to specify the appropriate Info plists and code signing identities.
I think this will do the trick! If there's a cleaner way, however, please weigh in. Thanks!
精彩评论