Carthage: This application's bundle identifier does not match its code signing identifier

[JonasVautherin]

• carthage install method: [ ] .pkg, [x] homebrew, [ ] source
• which carthage: /usr/local/bin/carthage
• carthage version: HEAD, 2018-08-16
• xcodebuild -version: Xcode 9.4.1; Build version 9F2000
• Are you using --no-build? No
• Are you using --no-use-binaries? No
• Are you using --use-submodules? No
• Are you using --cache-builds? No
• Are you using --new-resolver? No

Cartfile

github "Dronecode/DronecodeSDK-Swift" "master"
binary "https://code.videolan.org/videolan/VLCKit/raw/master/Packaging/MobileVLCKit.json" == 3.1.1

Carthage Output

carthage update --platform ios
*** Downloading binary-only framework MobileVLCKit at "https://code.videolan.org/videolan/VLCKit/raw/master/Packaging/MobileVLCKit.json"
*** Fetching DronecodeSDK-Swift
*** Fetching RxSwift
*** Fetching grpc-swift
*** Downloading binary-only framework backend at "https://s3.eu-central-1.amazonaws.com/dronecode-sdk/backend.json"
*** Checking out grpc-swift at "5c11a4451e4f5f0c4bda26f939a7134f4609fad9"
*** Checking out DronecodeSDK-Swift at "8b7e0ff4c9bf46aa821035332c252898293c1502"
*** Checking out RxSwift at "4.0.0"
*** xcodebuild output can be found in /var/folders/cj/gmrrbftd6s96p4rhf1mgxqfm0000gn/T/carthage-xcodebuild.POI1KZ.log
*** Downloading binary-only framework backend at "https://s3.eu-central-1.amazonaws.com/dronecode-sdk/backend.json"
*** Downloading binary-only framework MobileVLCKit at "https://code.videolan.org/videolan/VLCKit/raw/master/Packaging/MobileVLCKit.json"
*** Downloading RxSwift.framework binary at "Mortred"
***  Skipped installing RxSwift.framework binary due to the error:
    "Incompatible Swift version - framework was built with 4.0.2 (swiftlang-900.0.69.2 clang-900.0.38) and the local version is 4.1.2 (swiftlang-902.0.54 clang-902.0.39.2)."

    Falling back to building from the source
*** Building scheme "SwiftGRPC-Carthage-Package" in SwiftGRPC-Carthage.xcodeproj
*** Building scheme "RxBlocking-iOS" in Rx.xcworkspace
*** Building scheme "RxCocoa-iOS" in Rx.xcworkspace
*** Building scheme "RxSwift-iOS" in Rx.xcworkspace
*** Building scheme "RxTests-iOS" in Rx.xcworkspace
*** Building scheme "Dronecode-SDK-Swift" in Dronecode-SDK-Swift.xcodeproj

Actual outcome
Exact same error as here: My app runs in the simulator, but when I try to run it on an iPad, I get an error like:

"App installation failed - This application's bundle identifier does not match its code signing identifier"

The Console shows the following message:

dispatch_source_read_socket_block_invoke:312: Failed to install application at file:///var/mobile/Media/PublicStaging/DronecodeSDKSwiftDemo.app/ : Error Domain=MIInstallerErrorDomain Code=77 "Code signing identifier (BoringSSL-55554944d9392e62a01539918cc12380119f014f) does not match bundle identifier (BoringSSL) for /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.4RVZ5j/extracted/DronecodeSDKSwiftDemo.app/Frameworks/BoringSSL.framework" UserInfo={LegacyErrorString=MismatchedBundleIDSigningIdentifier, FunctionName=-[MIExecutableBundle codeSigningInfoByValidatingResources:performingOnlineAuthorization:ignoringCachedSigningInfo:checkingTrustCacheIfApplicable:error:], SourceFileLine=759, NSLocalizedDescription=Code signing identifier (BoringSSL-55554944d9392e62a01539918cc12380119f014f) does not match bundle identifier (BoringSSL) for /private/var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.4RVZ5j/extracted/DronecodeSDKSwiftDemo.app/Frameworks/BoringSSL.framework}

If I build the project from Carthage/Checkouts/grpc-swift/SwiftGRPC-Carthage.xcodeproj with Xcode directly, then the resulting BoringSSL.framework seems just fine. But when building with Carthage, this BoringSSL-55554944d9392e62a01539918cc12380119f014f identifier somehow appears in BoringSSL.framework/BoringSSL (even though the bundle identifier is BoringSSL in Info.plist and in the Xcode settings).

Expected outcome
Carthage should succeed if Xcode succeeds.

[JonasVautherin]

Note that the xcodeproj used by Carthage is generated from SwiftPM (and seems to work on the iOS simulator, and also when building from Xcode instead of Carthage).

[ikesyo]

That is Apple's validation. Xcode projects generated by SwiftPM as is are not meant to be used to build iOS frameworks for submitting iOS apps. Please check and modify the Xcode project by hand.

[JonasVautherin]

Thanks for the quick answer! Let me try to be clearer:

1. I run carthage update --platform ios, and it builds all the frameworks, including BoringSSL.framework.
2. I open my project, and install it on the simulator. It works.
3. I try to install my project on the iPad, and I receive this bundle identifier error.
4. I git add the project generating BoringSSL.framework (Carthage/Checkouts/grpc-swift/SwiftGRPC-Carthage.xcodeproj) in order to track changes.
5. I open Carthage/Checkouts/grpc-swift/SwiftGRPC-Carthage.xcodeproj with Xcode, and build it for iOS.
6. I inspect BoringSSL.framework and realize that it is different from the one built by Carthage. More specifically, BoringSSL.framework/BoringSSLfrom Carthage contains this BoringSSL-55554944d9392e62a01539918cc12380119f014f, but the one from Xcode doesn't.
7. I check with git if Xcode has modified SwiftGRPC-Carthage.xcodeproj, but it hasn't.
8. I replace Carthage/Build/iOS/BoringSSL.framework with the new BoringSSL.framework coming from Xcode, and try to install the project on the iPad. __The error has disappeared.__

It seems that Xcode and Carthage don't get the same output, even though I run them on the same xcodeproj and it doesn't seem to be modified by Xcode.

I'm all for checking and modifying the Xcode project by hand, and I have been spending hours trying to understand why the build identifier coming from Carthage would have this BoringSSL-55554944d9392e62a01539918cc12380119f014f (it is just BoringSSL when I open the settings in Xcode or read the xcodeproj). The only place where this BoringSSL-55554944d9392e62a01539918cc12380119f014f appears is really in the binary BoringSSL.framework/BoringSSL. And same goes for all the other products of this xcodeproj, that was generated from SwiftPM.

Would you have any idea of what could be going wrong? Is there a requirement on the bundle identifier format (e.g. it must be ext.domain.name and cannot be name?). And do you know why the carthage build is different from the Xcode build?

[ikesyo]

the build identifier coming from Carthage would have this BoringSSL-55554944d9392e62a01539918cc12380119f014f (it is just BoringSSL when I open the settings in Xcode or read the xcodeproj)

The log says

Error Domain=MIInstallerErrorDomain Code=77 "Code signing identifier (BoringSSL-55554944d9392e62a01539918cc12380119f014f) does not match bundle identifier (BoringSSL)

so BoringSSL-55554944d9392e62a01539918cc12380119f014f is not a bundle identifier but it is a code signing identifier.

do you know why the carthage build is different from the Xcode build?

I'm not sure.

[JonasVautherin]

so BoringSSL-55554944d9392e62a01539918cc12380119f014f is not a bundle identifier but it is a code signing identifier.

Right, so that means that Carthage is signing the framework, and it should not. Correct?

I tried specifically setting CODE_SIGN_IDENTITY="" (and I can see it is in the xcodeproj in Carthage/Checkouts/grpc-swift), and that's the value for "Don't Code Sign". But still, I get this BoringSSL-55554944d9392e62a01539918cc12380119f014f in the resulting binary.

So somehow, Carthage seems to be wrongly signing the product. Does that make sense?

[JonasVautherin]

Also note that they had apparently the exact same problem here, and they solved it by changing the bundle identifier, somehow :thinking:...

[JonasVautherin]

Well, I'm giving up here.

Running "build" from Xcode and from carthage build --no-skip-current, on the very same xcodeproj, results in one framework being presumably signed (i.e. the Carthage one has BoringSSL-5555494... in Carthage/Build/iOS/BoringSSL.framework/BoringSSL) and the other one not being signed (i.e. BoringSSL- doesn't appear in BoringSSL.framework/BoringSSL).

[MrMage]

I think Xcode has an option to "Code Sign on Copy" in the "Copy Frameworks" step (or a similar one). Is that checked, and/or did you try that?

Also, could you check what RB App Checker outputs?

[JonasVautherin]

I think Xcode has an option to "Code Sign on Copy" in the "Copy Frameworks" step (or a similar one). Is that checked, and/or did you try that?

Hmm, I can see the signature in the binary before it gets copied into the app (so really just after it is built). So I don't think it is related to the copy (unless I should "unsign on copy", but I don't think that's possible :sweat_smile:).

Also, could you check what RB App Checker outputs?

Very nice! I was looking for a tool like this and did not find it!

Binary from Xcode:

Evaluating the unix executable ?BoringSSL?.

The unix executable is unsigned.
    Dynamic library code for arm64 has the UUID ?186DAD19-41A6-3D66-A5A6-DD7DA40C9CC6?

Binary from Carthage:

Evaluating the unix executable "BoringSSL".

The unix executable was signed by an unidentified entity (this is unusual).
    Neither timestamp nor signing-time were specified.
    The object code format is "Mach-O universal (i386 armv7 x86_64 arm64)".
    The signing identifier is "BoringSSL-555549448f6d6d4213a93ce88a9dde14127f00d9".
        Caution: this should contain a '.'!
    -> Requirements and resources didn't pass static validation.

The code signature has the UUID "D6713FE2-7852-2B53-3A41-C4E3CCD9C261".
    Dynamic library code for i386 has the UUID "F459D740-CEC9-33C4-A208-8B7ED9FC9096".
    Dynamic library code for x86_64 has the UUID "8F6D6D42-13A9-3CE8-8A9D-DE14127F00D9".
    Dynamic library code for armv7 has the UUID "1B076BE7-5190-3706-B104-4904590FB052?".
    Dynamic library code for arm64 has the UUID "CEB79AC3-A65D-3905-B698-7D70641979C9".

So that confirms that Carthage is somehow signing the binary, even though I can read in the xcodeproj:

CODE_SIGN_IDENTITY = "";
CODE_SIGN_STYLE = Manual; // Note: I tried Manual and also not defining it (which defaults to Auto, I believe)
...
PRODUCT_BUNDLE_IDENTIFIER = BoringSSL;
...
TARGET_NAME = BoringSSL;

And this CODE_SIGN_IDENTITY is described as "Don't Code Sign" in Xcode :thinking:...

[ikesyo]

That's weird that we explicitly disable code signing: https://github.com/Carthage/Carthage/blob/9503e2c07d9f839dfee3601be8ef0a9f471d2d5f/Source/XCDBLD/BuildArguments.swift#L136

[JonasVautherin]

Here is the output of the Carthage build.

And look at what I find at the end of the build of BoringSSL:

Signing Identity:     "-"

    /usr/bin/codesign --force --sign - --timestamp=none /Users/jones/Library/Developer/Xcode/DerivedData/SwiftGRPC-Carthage-bejmbxrxisaacbhaqhvmucittgyj/Build/Products/Release-iphonesimulator/BoringSSL.framework

[ikesyo]

If you build for iOS simulator sdk you'll see that the built product is signed (Xcode somehow does it). So that is the difference that you build for iOS device sdk but Carthage builds for both iOS simulator sdk and iOS device sdk and then combines them into a universal binary.

Please make it sure that you use carthage copy-frameworks when copying frameworks into you app bundle to correctly strip simulator architectures (as stated in the README).

[JonasVautherin]

That's it! You just made my day @ikesyo :-). Thanks a lot!

What's interesting is that not all the frameworks built by Carthage need copy-frameworks. I had to add the script for the 4 dependencies coming from grpc-swift, and it all works perfectly. Do you know why the other frameworks (e.g. I depend on RxSwift) don't end up having the same problem?

[nezhyborets]

My case is not Carthage, but Framework as Project in Workspace. Still want to share my solution, it's kinda crazy. Maybe it's due to Xcode 11 or Catalina, but anyway...

To fix this, I had to set framework's Product Bundle Identifier to anything with a dot. So before the fix Product Bundle Identifier was something like "FrameworkName", and Xcode would automatically append some autogenerated ID, and Signing Identifier would become "FrameworkName-5555494493d11a8e5f473d1cb2a5d781973d171e".

When I set Product Bundle Identifier to something with dot, like "com.organization.frameworkName", Xcode stopped to auto-append anything, and everything works because ids match.

[gbrooker]

@nezhyborets Thanks so much for posting this. I had exactly the same problem, and your fix worked perfectly. Prepending the string "com.github." to the bundle identifier of each of the 20 frameworks in my app allowed it to be uploaded to appstore connect. That's in Xcode 11.2. Never had this issue in Xcode 10.