xcodebuild command line: passing DevelopmentTeam ID for code signing purpose

Question

My App is given one bundleID for App Store distribution. The App also has a small variant for enterprise distribution, thus with another bundleID. The automatic build uses the following command line to set bundleID and pick the right signing identify:

xcodebuild -project XYZ.xcodeproj -target XYZ -sdk "iphoneos" -configuration "Debug" BUNDLE_IDENTIFIER=<bundleID_1_or_2> CODE_SIGN_IDENTITY="<identify_1_or_2" build 

This automatic build has been working great, until recently I enabled iCloud capability. Now Xcode automatically adds the following to project.pbxproj:

TargetAttributes = {
  QWERTY1234567890123456 = {
  DevelopmentTeam = XYZ123456;
    SystemCapabilities = {
      com.apple.iCloud = {
        enabled = 1;
      };
    };
  };
};

Notice the addition of a hard-coded "DevelopmentTeam = XYZ123456"; for the two builds, the DevelopmentTeam ID is different. How to automate this? An easier solution is to have a script to modify project.pbxproj before invoking xcodebuild, but I am not a fan of that solution. The next best is to create a new "User Defined Setting" thus passing it via command line, but I could not figure out how to associate the User-Defined Setting with that DevelopmentTeam ID embedded there inside project.pbxproj.

Answer 1

In Xcode 8 this was added as DEVELOPMENT_TEAM build setting. You can pass as a command line argument just like other settings:

xcodebuild
    -sdk "iphoneos"
    -project Foo.xcodeproj
    -configuration "Debug"
...
DEVELOPMENT_TEAM=XYZ123456

See in more detail about Xcode 8 code signing changes: https://pewpewthespells.com/blog/migrating_code_signing.html

Answer 2

We were able to deal with multiple DevelopmentTeam IDs by using the sigh utility, which provides automation for provisioning profiles. We use it as part of the fastlane suite of tools.

sigh --team_id <DevelopmentTeamID>

Or as part of a fastlane automation ( Fastfile ):

sigh(team_id: "<DevelopmentTeamID>")

Answer 3

We ended up creating another debug-like build configuration. In our case it's called "Ad-hoc" for no particular reason. Our build server uses an enterprise certificate for test builds so we just changed that build configuration to have the correct certificate and team parameters, and the development "Debug" ones are no longer important. One thing that is challenging though is that some cocoapods (fbtweaks) don't realise you may be using a configuration that isn't called "Debug" to create debug builds, so there are some hoops that have to be jumped through to make that work correctly.