M1 "Command ValidateEmbeddedBinary failed with a nonzero exit code" Archiving Error in Xcode

Question

I upgraded from macOS Catalina (10.15.7) to Big Sur (11.5.1) going from an Intel i7 MacBook Pro to an M1 iMac subsequently upgrading to Xcode 12.5.1 from 12.4

The iOS app will compile and run on a device -- as well as a simulator. However if I try to Archive I get the titular error of this post. The error sort of references an Info.plist or the Watch app but is it cryptic and not that specific. I suspect it's something to do with my companion watch app.

ValidateEmbeddedBinary /Users/$USER/Library/Developer/Xcode/DerivedData/$PROJ-hkuuspnqxnzkxfdjlwwluxskiqbs/Build/Intermediates.noindex/ArchiveIntermediates/Watch/BuildProductsPath/Release-iphoneos/$PROJ.app/Watch/Watch.app (in target '$PROJ' from project '$PROJ')
cd /Users/$USER/Documents/$PROJ/$PROJ/Applications/Xcode.app/Contents/Developer/usr/bin/embeddedBinaryValidationUtility /Users/$USER/Library/Developer/Xcode/DerivedData/$PROJ-hkuuspnqxnzkxfdjlwwluxskiqbs/Build/Intermediates.noindex/ArchiveIntermediates/$PROJ/BuildProductsPath/Release-iphoneos/$PROJ.app/Watch/Watch.app -signing-cert 0B2269280E4CC1330AD714C0EC8A51DF24A35DB9 -info-plist-path /Users/$USER/Library/Developer/Xcode/DerivedData/$PROJ-hkuuspnqxnzkxfdjlwwluxskiqbs/Build/Intermediates.noindex/ArchiveIntermediates/$PROJ/InstallationBuildProductsLocation/Applications/$PROJ.app/Info.plist

I have managed to get it to Archive twice -- seemingly after making big changes at the project level. Once I embedded a framework and it archived -- then I added an entitlements file and added a line to point to it in the xcproject.pbxproj file. Producing a minimal working example of this will be tricky as I suspect it's a race condition in bigger projects.

Petromilli

Having same issue on AppCenter build system. – Flotsam

Answer 1

Reliable Workaround Found (Updated 29th of Dec 2021):

I have another work around (possible solution) that seems more reliable than my other answer as both my iOS app and watchOS app seem to be compiling without compile time errors (I now get run time errors!). This SO accepted answer was of some help: Remove & Re-add the WatchKit extension

I wasn't able to follow/understand the second instruction despite re-reading it several times. I re-added it manually by pressing the '+' and pressing 'New Copy Files Phase' and then manually entered the info that was there previously e.g. subpath field ($(CONTENTS_FOLDER_PATH)/Watch) and adding the Watch.app as a reference under 'Name'.

I also enabled 'Copy only when installing' and it seemed to compile reliably after that. It seemed to rename the phase from 'Embed Watch Content' to 'Copy Files' which is the only difference along with the checked box I can see.

I have no idea why this works or what was wrong previously. Just that these steps helped me.

Unreliable Workaround Found (Updated 29th of October 2021):

Leaving this here for posterity in case it might be useful to someone but this was the previous answer.

An unreliable work around I found was to archive the "Watch" App. Which will may or may not succeed but then trying to archive the normal iOS App will have a much better chance of succeeding in producing an archive. Again this reinforces that there maybe a deceptive race condition happening.

I'm also experiencing this in Xcode 13 but can get it to build by restarting the machine, cleaning & deleting derived data.

Another Workaround Found:

The Package Dependencies (SPM) didn't match the entries Frameworks, Libraries, and Embedded Content. I manually updated them and it seems to work now. I was missing SwiftHEXColors. However I still think there is a race condition as it's reproducible now.

Sorry I thought I fixed it but the issue returned!

Came across this bug that sounds a lot like my one:

If you use a Google Maps Swift dependency in an app with extensions, the build system incorrectly embeds the binary

dependencies alongside the extension in the PlugIns directory, causing validation of the archived app to fail. (69834549) (FB8761306)

Workaround: Add a scheme post-build action which removes the embedded binaries from the PlugIns directory after the build, e.g. rm

-rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app"/PlugIns/*.framework.

Petromilli

I've run into similar issues where changes I've made to a package weren't implicitly updated by Xcode as expected. It's unfortunate, but you start to recognize when this is a possibility, which gives you a place to focus your search. Glad you worked it out! – Beverage

Answer 2

Problems

• there is a problem with ValidateEmbeddedBinary command
• SwiftUI preview doesn't work on M1 (I know it's not related to this topic, but since the solution is suitable for this, it might be useful to someone)

Description

I had the same error on M1 because I was following other people's examples for Mac with Intel.

Environment

• Xcode 13.1
• MacOS 12.1
• MacBook pro 2020 M1

Solution

To fix this problem you need:

1. Uncheck "Open using roseta" from Xcode.app

2. Then go to "Build settings" and set the parameters for "Build Active Architecture only" and "Excluded Architectures" as in my screenshot for each target!

3. To fix the bug with not working preview, always use the emulator before clicking the "resume" button on the canvas
   
   

I hope this makes your life easier, good luck!

Roz

Answer 3

We have this issue on an 8GB M1 iMac running Xcode 15.3 & 15.4. We don't see it on a 16GB M1 MacBook Pro.

Our symptoms:

When building a project we get build/archive error: "Command ValidateEmbeddedBinary failed with a nonzero exit code"

Clicking on this error will show you the build log and the command that was being ran. You can copy and paste this into a terminal to recreate the error:

[user@host]$ cd /Volumes/Disk/Project
[user@host]$     /Applications/Xcode-15_4.app/Contents/Developer/usr/bin/embeddedBinaryValidationUtility /Volumes/Disk/Xcode_Directories/DerivedData/xxx-xxx/Build/Products/Debug-iphoneos/MyApp.app/PlugIns/MyAppIntent.appex -signing-cert xxx -info-plist-path /Volumes/Disk/Xcode_Directories/DerivedData/xxx-xxx/Build/Products/Debug-iphoneos/MyApp.app/Info.plist
warning: The CFBundleVersion of an app extension (123) must match that of its containing parent app (567).
Bus error: 10

If we repeatedly run that command it will fail with different errors including Bus error: 10 and Segmentation fault: 11. It will succeed a few times, but it mostly errors. In our experience we are seeing a warning (unrelated to the crash) before it crashes, suggesting the app is working to an extent before crashing.

Our workaround:

We noticed running the embeddedBinaryValidationUtility utility on it's own didn't crash, and then subsequent builds would work for a period, so we added a Run Script build phase that simply runs embeddedBinaryValidationUtility on it's own. Now builds work reliably.

To do this go to your project -> Build Phases -> Click + -> Add Run Script build phase and add this text to the text box under "Type a script or drag a script file from your workspace to insert its path.":

embeddedBinaryValidationUtility 2>/dev/null|| echo 1

This is obviously a workaround for a bug, likely memory management. Is this only happening on 8GB M1 iMacs?

Calctufa

I can confirm I had an 8GB M1. I don't have a 16GB to test it on. That's frustrating to hear as I advocated for a 16GB at the time -- we just dropped support for the Apple Watch as a result of this. – Petromilli

Answer 4

I had the same issue. And it was a project who someone created. I couldn't install an app on my iPhone. React-native: 0.64.2 Xcode: 14.1

Answer: In Xcode, I just changed the minimum deployments from 10.0 to 12.0. XCode is running on Rosetta you could check the answers above on how to turn it on

Here the minimum deployments

Obsequious