iOS error "Embedded binary is not signed with the same certificate as the parent app"

Question

Those are my first steps in IOS applications development and I'm facing some problem that I can't figure out.

error: Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target's code sign settings match the parent app's.

    Embedded Binary Signing Certificate:    Not Code Signed
    Parent App Signing Certificate:         iPhone Developer: Emil Adz (9QNEF95395)

I can't understand, what is a Embedded Binary Signing Certificate?

I went over the questions with the same error here, but none of them were related to the problem presented here (Not Code Signed).

I tried to revoke my certificate from the Apple Developer Member Center and request another certificate, but the issue persists.

Does some know how it could be fixed?

Hamper

In this qusetion, the signature are different. But if you see both are same then you can refer my answer from this question. https://mcmap.net/q/218323/-embedded-binary/… I believe same answer cannot be copied in multiple questions – Oubre

It can be a bitcode issue forums.developer.apple.com/thread/14998. It was in my case – Bearable

delete derived data might help – Theall

Answer 1

The embedded binary is referring to a widget that you are deploying alongside with your app.

In your case, you are not signing your widget with any Signing Identity (since your error says "Not Code Signed").

To resolve this, go to your Project file, find your widget's target, and under the Build Setting tab, find the Code Signing Identity value. Choose the same code signing identity that you are using for your main app's target.

You will also need to create and configure a provisioning profile specifically for your widget when you want to release it.

Lactone

My code signing identities were configured correctly but for some reason xcode didn't see this that way. Setting them to the same configuration as there were configured made xcode to resolve the problem. Thanks for you help. – Hamper

I ended up doing the same for OneSignal library. – Convenience

Answer 2

Swift 5 . Simple way in my case check this screen shot i am done

Unwilled

@ShakeelAhmed Do you think its right place to sale yourself? Lol – Jubal

its for opportunity :-) i am surprised why people are hiding there apps name etc lol – Unwilled

This helped me for the new iOS 14 App Clip. Thanks – Lumisterol

I had this error with an app with an embedded extension in Ventura b4/Xcode b4, and there were two steps to this solution working for me. First I had to check "copy only when installing" as recommended above, which allowed a build but didn't allow the extension to be copied after a first installation, then I had to uncheck it again, after which both building and working with the extension worked again. That's right, I had to try turning it off and turning it on again. – Attenweiler

this error showed up in apple's sample-food-truck app and I had to tick the Copy checkbox on Xcode 14.2. Thanks for the solution! – Careycarfare

Checking this caused my widget to disappear from the add widget interface, or appear blank if it was already added. – Como

Answer 3

Sometimes none of the solution on Stackoverflow works. In that case,

Solution

1. Make sure that there is no red mark/issue in any of the sections of Signing(Debug), Signing(Release) and Enabled capabilities in both of MainApp and EmbeddedApp
2. Make sure that both certificates and provisioning profiles are installed under login/system keychain.

3. Make sure that your certificate is never ever set as Always Trust. Access must be kept as Use System Default

Greenhead

Oh my god! THank you! – Unicameral

~~~~~~~~~~THIS! – Bloodmobile

What's the reason it fixes? – Playgoer

I was looking for the reason for 13 hours. You made my day! Thanks a lot! – Trixi

Wow man thanks a lot! actually worked for me after so many other answers here.. Should be marked as the most helpfull answer.. – Gammon

Use system Defaults exactly kept by default on your system – Siqueiros

Do not do this, this will now throw "Invalid trust settings. Restore system default trust settings for certificate" CodeSign errors. – Winthrop

Answer 4

Assumptions

• the app I am working is called TestApp (for the sake of privacy)
• the steps below are tested in Xcode 11.1
• the scheme I was using to compile is AdHoc
• the app has the Push Notification capability

Issue

In my case the issue was caused by a discrepancy between the signing of two targets. The issue was between:

• the TestApp target (i.e. what in the error is referred to as Parent App Signing Certificate)
• the notificationServiceExtension target (i.e. what in the error is referred to as Embedded Binary Signing Certificate).

Resolution

In my AdHoc scheme, under the TestApp target, I disabled the automatic signing because I wanted to specify the provisioning profile and the certificate.

The steps I followed were:

1. from Signing & Capabilities -> AdHoc -> Signing (section)
   1. removed the tick from Automatically manage signing under selected
   2. selected the provisioning profile I wanted to use

2. from Build Settings -> Signing (section)
   1. under Code Signing Identity, choose for both AdHoc and Any SDK the certificate I wanted to use
   2. under Code Signing Style -> AdHoc, chose Manual
   3. under Provisioning Profile -> AdHoc, chose the provisioning profile I wanted to use (i.e. the same as step 1.2)

The error was thrown because I didn't apply the same settings to the notificationServiceExtension target (which was still using the automatic signing and therefore another certificate). As soon as I have repeated the steps above also for this target, the error was gone.

I hope it can helps someone, because this error drove me crazy!

Beverage

Answer 5

This error is also shown when deployment target of your Today extension is newer than the parent app. They must be the same.

I have iOS app set to 10.0 and added Today extension which was automatically set to 11.4 as the latest. This caused the error to appear. Simply changing the Deployment target of the extension target to 10.0 resolved the issue.

Deleterious

Answer 6

Oddly enough, I had to remove the products folder from my project in order to fix this error. Xcode crashed then, after reopening, worked like a charm!

Defray

The only one answer that works for me ! thx but i have an hard time to understand why this is happening randomly – Hirschfeld

worked for me :) but removing this folder can affect my app In any way or it will work fine? – Auspicate

As for me, relaunching Xcode helped: then it again asked the permissions to keychain access and signed app correctly – Passive

Answer 7

It seems this issues appears in xcode 10 and the resolution is different from the aforementioned.

I was able to fix (or rather bypass) the error by setting the Build System to Legacy (via File > Workspace Settings)

Another interesting thing to note is that the signing error would not occurr if I was building to an actual device (i.e. before changing the Build System to Legacy). It would only occurr when building using the simulator and only on Xcode 10 beta 3, 4 and 5.

Link to the original thread: https://forums.developer.apple.com/thread/105537

Schlessinger

I had the issue on the production version of XCode - Version 10.1 (10B61). It not only worked when I switched off the new system but also started to work (compile) when I switched it back on (after a day of developing under the switched off new build system) – Ruminant

Answer 8

I was having this issue when I migrated to Xcode 10 and managed to fix it by updating the architectures in "Build Settings"> "Valid Architectures" for the Watch target to

$(ARCHS_STANDARD)

This thread helped me out a lot: https://forums.developer.apple.com/thread/107563

Outage

This did it for me. Even if $(ARCHS_STANDARD) results in the exact same architectures being populated in this record, using (ARCHS_STANDARD) instead of manually specifying, say arm64_32 armv7k, fixed my issues. – Surah

That worked for me too! – Unscramble

Answer 9

I had the issue when following the SwiftUI documentation about integrating an iOS app with watchOS.

The issue is that the extension is not under the same development team, so it will fail when we try to compile it.

Nothing about architecture and nothing about trust.

SOLUTION: ScreenShot for xcode

1. Go to the project general file
2. Check on the extension folder on the sidebar (check the screenshot number 2)
3. Switch to the Signing & Capabilities tab
4. Choose your team (need to match the master project's development team)

Integumentary

Answer 10

check your Excluded Architectures

Pantelleria

I had set arm64 in excluded architectures, and fixed by clearing the setting on both main and extension targets. :+1: – Coma

Answer 11

I got this error when the App Groups weren't set up correctly on all my App IDs in the Developer Portal. Therefor the App Groups in the app didn't work correctly and the Binary for the extension or the Watchkit app couldn't be signed.

Carrnan

Answer 12

I got this error while having another compile time error in my code.

My new target has never been built before.

So I thought I'll fix this error first. But it turned out, that fixing the other error enabled Xcode to build the target and fix the other error itself.

Kneedeep

Answer 13

I got this error after adding a Copy Files Build Phase to the main app Target.

Copy Files
Destination: Absolute Path
Path: /Applications
File: MyApp.app

This worked the first time I ran the app.

On subsequent runs, Xcode began complaining about the certificate mismatch.

Removing the Copy Files build phase fixes the certificate mismatch. I'm still searching for a way to Copy Files without the error.

Same issue links:

• https://mcmap.net/q/218325/-embedded-binary-is-not-signed-with-the-same-certificate-as-the-parent-app-yet-they-are-identical
• https://forums.developer.apple.com/thread/102707
• https://github.com/Bouke/SwiftInitializerGenerator/issues/6

Isidor

I'm having the same issues with xcode 12.4.. Did you find any fix or workaround? – Johniejohnna

Answer 14

I had this problem with a Photo Editing Extension. I eventually discovered that it was due to my unusual project structure.

• My project includes a local Swift package containing all the source code and resources for the appex (app extension).
• The appex links the library created by the Swift package.
• The appex has no source files of its own. The “Compile Sources” build phase has no files, and it has no “Copy Bundle Resources” build phase.

On a clean build, Xcode builds the appex and embeds it in the app successfully.

On an incremental build, even with no changes to any file, Xcode fails during the “Validate MyEx.appex” step.

The problem, it turns out, is that Xcode re-links the appex executable every time it builds, even if nothing has changed. And Xcode does not then sign the new appex executable, except during a clean build.

This means that the appex executable is always unsigned after an incremental build, so it is never signed with the same certificate as the parent app (because the appex isn't signed at all).

My solution was to add an empty file, dummy.swift, to the appex target. That is sufficient to make Xcode only re-link the appex when needed, and to always sign the appex after linking during an incremental build.

Athos

Thanks. I have a similar project structure, but with a Safari web extension, and JS files for the extension in the Copy Bundle Resources phase. There were no source files in the extension target and adding an empty Swift file fixed it. – Velda

Answer 15

Check if you have more targets like oneSignal or other else and check if you have the same team of the main target.

Silvia

Answer 16

I was getting this error trying to build a WatchOS app in Xcode 11 - I tried all the various suggestions in this and other SO posts but the thing that finally worked was switching Xcode to use the legacy build system.

Go to: File | Project (or Workspace) Settings | Build System

And select Legacy Build System

Saving

Answer 17

Check your keychain access expire certificate not deleted that's why its showing a error.

Debutante

Answer 18

XCode 12.5

In my case, I followed Shakeel Ahmed's answer. But I also needed to do this change on the Pod file.

You can find more here https://github.com/facebook/react-native/issues/31480#issue-876308920

Rhenium

always try to provide code rather posting images. This will help community to answer your question. – Mannerheim

Answer 19

I have experienced this same issue in a Unity.iPhone project. We embed a target for a Stickers extension that we ship with the app.

The Stickers extension target is the one complaining about the code sign settings not matching the parent apps.

error: Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target's code sign settings match the parent app's.

        Embedded Binary Signing Certificate:    Software Signing
        Parent App Signing Certificate:     Apple Distribution

This occurred when the Stickers Extension target build settings were set to ARCHS_STANDARD (arm7, arm64), while the parent app was set to arm64.

I fixed this by setting the Extension's ARCHS build property to arm64.

Go figure, I suspect this output catches a bunch of different issues and just doesn't specify any details in the log message.

Fatherless

Answer 20

I had same error when updated latest version of xcode (15.0.1).

I solved it removing all "arm64" from "Excluded Architectures" located "Build Settings" tab.

Execution

Answer 21

I was using OneSignal and it was disabled from the user-defined settings.

Go to Extension target -> Build Settings -> User-Defined -> Change these two values to YES

Uninhibited