Manual signing fails for xcode test with embedded library. Can it be decomposed?

Question

I'm trying to run Facebook's WebDriverAgent, for testing on real devices: https://github.com/facebook/WebDriverAgent.

Our admin isn't a fan of Apple's automatic signing, so we're trying manual. When I put

 xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id='4xxx9' test DEVELOPMENT_TEAM=xxxx PROVISIONING_PROFILE=xxxxx

it says

Testing failed:
WebDriverAgentLib has conflicting provisioning settings. WebDriverAgentLib is automatically signed, but provisioning profile xxxx has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the project editor.

I set manual signing on everything (in xcode), and try again:

xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id='4xxx9' test DEVELOPMENT_TEAM=xxxx PROVISIONING_PROFILE=xxxxx

Testing failed:
WebDriverAgentLib does not support provisioning profiles. WebDriverAgentLib does not support provisioning profiles, but provisioning profile xxxx has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor.

It seems I need to decompose the 'test' action to build the library without the profile, but everything else with the profile, and then trigger testing.

Can this 'xcodebuild test' command be rewritten as several commands to effect such a build/test? I need a command-line solution because this is part of a continuous integration.

Thanks in advance!

Answer 1

This happened to me using manual signing and including Cocoapods dependencies. This is possibly a known issue with Cocoapods (https://github.com/CocoaPods/CocoaPods/pull/6964). Their workaround is to specify setting PROVISIONING_PROFILE_SPECIFIER to '' in the Podfile's post_install hook, but this didn't work for us because we commit our Pods, so the post_install hook doesn't run when we build.

However, in addition to passing the option PROVISIONING_PROFILE_SPECIFIER=xxxxx to xcodebuild, we were able to build by setting the following options in Pods.xcodeproj/project.pbxproj for each target/build configuration:

CODE_SIGNING_ALLOWED = NO;
CODE_SIGNING_REQUIRED = NO;
PROVISIONING_PROFILE = '';
PROVISIONING_PROFILE_SPECIFIER = '';

I am not primarily an iOS developer by trade, but from my understanding, PROVISIONING_PROFILE is deprecated and specifying both CODE_SIGNING_ALLOWED and CODE_SIGNING_REQUIRED may be redundant, but we do it anyway at the moment in our project.

Answer 2

Try using PROVISIONING_PROFILE_SPECIFIER=xxxxx instead of setting PROVISIONING_PROFILE, which is deprecated starting with Xcode8.

If the error then still occurs, try to set neither DEVELOPMENT_TEAM nor PROVISIONING_PROFILE_SPECIFIER, as these codesigning related buildsettings are only relevant, if you are actually building an app (but you are only executing an xcodebuild test on an already build app bundle).

If you want to build and test the app with one call of xcodebuild, you are encouraged to do a xcodebuild ... clean build test

EDIT

After taking a look at the WebDriverAgent project, the problem is related to the WebDriverAgentLib being a Dynamic Framework and a Target-Dependency of the WebDriverAgentRunner-Bundle. Dynamic Frameworks don't like codesigning during the build phase in Xcode8 at all (they now should be codesigned on the fly when being copied into the build product). With specifying code signing related build settings on the command line (DEVELOPMENT_TEAM etc.), Xcode8 will complain about this for Dynamic Framework targets and fail the build.

Solution 1: remove all codesigning related build settings from your xcodebuild call (PROVISIONING_PROFILE_SPECIFIER, PROVISIONING_PROFILE, DEVELOPMENT_TEAM, CODE_SIGN_IDENTITY) and just set these for the WebDriverAgentRunner-Target (either in the Xcode UI or via Command-Line with plistbuddy on the project.pbxproj).

Solution 2: don't test on a real device and instead just on the Simulator. As there is no need to codesign an Executable and/or Test-Bundle for Simulators, you can safely omit any codesigning related parameters from your xcodebuild call.

Solution 3: just stick with Automatic CodeSigning and assure that there a is valid login for the proper Developer Account in the build machine's Xcode.