firebase-ios-sdk: Xcode 12 GM Archive Error SPM - unexpected Mach-O header code: 0x72613c21

As of Xcode version 12.4, I have verified following script eliminates this issue when added to “Post-actions” phase of “Archive”. It removes all static frameworks as some people are experiencing issues due to unrelated frameworks.

# https://github.com/firebase/firebase-ios-sdk/issues/6472
LOGFILE="${ARCHIVE_PATH}/static-frameworks.log"
echo "Removing static frameworks from ${WRAPPER_NAME} archive" > $LOGFILE
find "${ARCHIVE_PRODUCTS_PATH}/Applications/${WRAPPER_NAME}" -name '*.framework' -print0 | while IFS= read -r -d '' fm; do
    name=$(basename "${fm}" .framework)
    target="${fm}/${name}"
    echo "Checking: ${fm}" >> $LOGFILE
    if file "${target}" | grep -q "current ar archive"; then
        rm -rf "${fm}"
        echo "Removed static framework: ${fm}" >> $LOGFILE
    fi
done

I was able to get a variation of @din’s suggested workaround to work for me:

Add the following to the Scheme’s Build Post-Action:

rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"

Make sure to select Provide build settings from the app.

I can archive its when I try to upload to the App Store I get the Found an unexpected Mach-O header code: 0x72613c21 error. The other error was when I tried to run it on a simulator.

The mentioned above Build scheme post-actions didn’t help in my case, so I did a bit differently, maybe it will help someone as well:

I added the following script in the post-actions of Archive scheme:

#https://github.com/firebase/firebase-ios-sdk/issues/6472
full_frameworks_path="${ARCHIVE_PRODUCTS_PATH}/Applications/${FRAMEWORKS_FOLDER_PATH}"
rm -rf "${full_frameworks_path}/FirebaseAnalytics.framework"
rm -rf "${full_frameworks_path}/GoogleAppMeasurement.framework"

Unexpected Mach-O header code: 0x72613c21 is still an issue on Xcode 12.3 beta. In my case, the Post-Action workaround worked well.

Here are the steps to follow, in case someone is still having issues:

1. Produce an Archive the way you normally do. Once Organizer lists your Archive, right click on it and select Show in Finder
2. In Finder, right click on your Archive to select Show Package Contents
3. Navigate to Products > Applications and then right click on YourApp.app to Show Package Contents
4. Navigate to Frameworks
5. Take note of the Frameworks you’ll have to remove. In my case it was only FirebaseAnalytics.framework and GoogleAppMeasurement.framework
6. Close Organizer, and go to Manage schemes > Edit scheme, then under Build, select Post-actions. Make sure to check Provide build settings from -> YourApp.
7. Add a new run script Post-action with the following:

#https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-707793520
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"

Generate a new Archive. It should validate now.

p.s. In step 4, you can actually delete the frameworks manually from Finder, then go back to Organizer and click Validate. This is a quick way to test whether you’re deleting the right frameworks to bypass the Mach-O error.

Just to throw another option into the list 🤣 I modified the example from @surajbarkale to work as a script build-phase instead of a scheme post-build action so that it applies regardless of build scheme. The issue would apply to debug builds too it’s just Xcode doesn’t complain about it so seems valid to perform the stripping of the static frameworks for all builds.

I put this as my last build phase.

# Fixes binary framework bug, see:
# https://developer.apple.com/documentation/xcode-release-notes/xcode-12_4-release-notes#Swift-Packages
# https://github.com/firebase/firebase-ios-sdk/issues/6472
#

echo "Removing static frameworks from ${TARGET_NAME}.app"
find "${BUILT_PRODUCTS_DIR}/${TARGET_NAME}.app/" -name '*.framework' -print0 | while IFS= read -r -d '' fm; do
    name=$(basename "${fm}" .framework)
    target="${fm}/${name}"
    echo "Checking: ${fm}"
    if file "${target}" | grep -q "current ar archive"; then
        rm -rf "${fm}"
        echo "Removed static framework: ${fm}"
    fi
done

Also, I can confirm this workaround is fixed and no longer required in Xcode 12.5 (12E5220o) 🎉

Confirmed that this issue is fixed in the public version of Xcode 12.5. 🎉

Thank you everyone for your patience and helping out with workarounds! If you did add a workaround for your project, it’s probably best to remove it to ensure it doesn’t cause any issues in the future.

Unexpected Mach-O header code: 0x72613c21 is still an issue on Xcode 12.3 beta. In my case, the Post-Action workaround worked well.

Here are the steps to follow, in case someone is still having issues:

1. Produce an Archive the way you normally do. Once Organizer lists your Archive, right click on it and select Show in Finder
2. In Finder, right click on your Archive to select Show Package Contents
3. Navigate to Products > Applications and then right click on YourApp.app to Show Package Contents
4. Navigate to Frameworks
5. Take note of the Frameworks you’ll have to remove. In my case it was only FirebaseAnalytics.framework and GoogleAppMeasurement.framework
6. Close Organizer, and go to Manage schemes > Edit scheme, then under Build, select Post-actions. Make sure to check Provide build settings from -> YourApp.
7. Add a new run script Post-action with the following:

#https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-707793520
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"

Generate a new Archive. It should validate now.

p.s. In step 4, you can actually delete the frameworks manually from Finder, then go back to Organizer and click Validate. This is a quick way to test whether you’re deleting the right frameworks to bypass the Mach-O error.

great help this worked just right.

According to https://forums.swift.org/t/swiftpm-binarytarget-dependency-and-code-signing/38953/35, the issue is fixed with Xcode 12.2 beta 3

Unfortunately I just tried with Xcode 12.2 RC released yesterday and the .framework files are still embedded.

I tried with Xcode 12.3 beta 1 release today and the .framework files are still embedded. Hopefully this gets resolved in this cycle of betas.

The answer posted by @paulb777 initially worked for me. But after I added a widget extension to my app, I started getting the same error again when uploading to the app store.

After digging into the .xcarchive files of the successfully uploaded and the failed uploads, it seems that XCode adds a new PlugIns directory to the archive if you add a widget with the same Firebase frameworks in that directory, so I had to remove the Firebase frameworks from the PlugIns directory in addition to Frameworks.

There might be other reasons the PlugIns directory shows up in your archive.

So here’s my post-script:

rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FIRAnalyticsConnector.framework"

Now it uploads to the App Store! Hopefully this helps.

Tested on Xcode 12.5 beta (12E5220o) and this doesn’t seem to be an issue anymore. I’ve only tested with a basic iOS app with no extensions and got the archive successfully validated.

Issus still there with Xcode 12.3.

Xcode version: 12.3 (12C33) Firebase SDK version: 7.3.0 Firebase Components: Analytics, Crashlytics Component version: 7.3.0 Installation method: Swift Package Manager

If your project has Watch extension as well, you need to delete Firebase frameworks from Watch folder, too. Here is my script which works for this scenario.

rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Watch/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Watch/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Watch/GoogleAppMeasurement.framework"

Firebase using SwiftPM is definitely the hackiest approach you can take 😄

Here’s an yet unreleased blog post how we explain our SwiftPM integration: https://pspdfkit.com/blog/2020/binary-frameworks-as-swift-packages/ - will become a public URL in a few days but I’m ok with sharing it early here if it helps.

We use dynamic frameworks only, not statics, and the above radar has been fixed in the GM. Let me know if that helps, happy to share more to get Firebase across to SwiftPM! I also know the SwiftPM maintainer if we need further help.

Changing TARGET_NAME to PRODUCT_NAME worked splendidly for me. I guess it might not work for everyone depending on your project-settings, but if I’m not mistaking it is the Xcode default.

rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"

Unfortunately this issue still reproduces in the 12.3 RC released today.

Confirmed this is still fixed in the Xcode 12.5 RC released today - will leave it open until the fix is the publicly released version.

${PRODUCT_NAME} should be used instead of ${TARGET_NAME}, since the target name might differ from the product name (which is what we’re after). So:

rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Watch/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Watch/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Watch/GoogleAppMeasurement.framework"

For me, it worked by adding the post-actions for the build scheme.

rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"

Quick update to my previous comment:

Apparently, the problem was connected with App Store Connect issues. I tried again today, and it works as expected. The build was successfully deployed on TestFlight.

There is one more thing I would like to add. Perhaps it will be useful for someone struggling with the issue:

In my project (iOS app) I have multiple framework targets. One of them is a “shared” framework (named Common.framework) that I use as a dependency for all other targets. All libraries added via SPM (in Xcode) are added to this framework. For that reason, my app’s archive structure looked a bit different from what is described in this topic. I browsed my archive in Finder to locate where the Firebase frameworks are located exactly, and it looked like this:

├─ Products
│  └─ Applications
|     └─ MyApp.app
|        ├─ Frameworks
|        |  ├─ Common.framework
|        |  |  ├─ Frameworks
|        |  |  |  ├─ FirebaseAnalytics.framework
|        |  |  |  └─ GoogleAppMeasurement.framework

To make it work, I needed not only to remove FirebaseAnalytics.framework and GoogleAppMeasurement.framework but also the whole Frameworks directory containing the frameworks. Even if the Frameworks directory was empty, I couldn’t upload the archive to App Store Connect.

I adjusted the post-action script (added to Archive action) to remove the whole Frameworks directory:

rm -rf "${ARCHIVE_PRODUCTS_PATH}/Applications/MyApp.app/Frameworks/Common.framework/Frameworks"

In “Provide build settings from” I have my app target selected.

With the above, I can archive and upload my app with Firebase integrated via SPM to App Store Connect without an issue using Xcode 12.3 (12C33).

It’s probably better to use PRODUCT_NAME instead of TARGET_NAME because they can be different (like in my case) and the workaround wouldn’t work in this situation.

rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"

Hey @RealTechyGod,

We support both CocoaPods and Swift Package Manager on the most recent non-beta version of macOS. macOS 11 beta may have some compatibility issues, though from what I understand CocoaPods still works for most users and based on the issue you filed on the CocoaPods repository you may need to adjust your local Ruby environment in order to get it to work. You may be able to find some relevant materials for fixing your local Ruby environment on StackOverflow.

While we appreciate your classification of dead vs not-dead dependency managers, it’s not useful for us to collapse dependency manager usage into a binary state, since a dependency manager with a relatively small market share may still be used by enough developers to warrant support.

I’ll be hiding some of these comments since they’ve gone off-topic from the original issue, but their contents will still be accessible. Thanks for your feedback!

At this time SPM way seems to take much longer to fetch and resolve the dependencies graph. At least longer than with cocoapods. Even if we forget about the fact that it has some things to fix at this point, will it always take so long?

Thanks for everyone’s help. I did something similar, but attempted an automated approach to look for static frameworks.

In my scheme’s Build Post-action I added a run script which I call with: $SRCROOT/buildScripts/fix_swift_pm_build_post_action.sh

Remember to chmod it so it can execute. The shell script I used is:

path="${TARGET_BUILD_DIR}/${PRODUCT_NAME}"
cd "$SRCROOT"
find -E . -type f -iregex ".*\.framework\/[^./]*" -exec file {} \; | grep 'current ar archive' | sed 's/.*\/\(.*.framework\).*/\1/' | sort | uniq | while read -r line ; do
    rm -vrf "${path}"
    rm -vrf "${path}.app/Frameworks/$line"
    rm -vrf "${path}.app/Plugins/$line"
    rm -vrf "${path}.app/Watch/$line"
    rm -vrf "${path}.app/AppClips/$line"
    rm -vrf "${path}.app/AppClip.app/Frameworks/$line"
done

I encountered this issue too and had to modify the post-action script to remove additional frameworks. It looks like you also need to remove the frameworks for any other targets you might have, such as the Watch extension (as someone mentioned above) but also for the App Clips. Notice the the extra couple of frameworks in the AppClips folder.

rm -rf "${TARGET_BUILD_DIR}/MyApp.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/Frameworks/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/AppClips/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/AppClips/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/AppClips/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/AppClips/AppClip.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/AppClips/AppClip.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/MyApp.app/AppClips/AppClip.app/Frameworks/FIRAnalyticsConnector.framework"

According to https://forums.swift.org/t/swiftpm-binarytarget-dependency-and-code-signing/38953/35, the issue is fixed with Xcode 12.2 beta 3

Unfortunately I just tried with Xcode 12.2 RC released yesterday and the .framework files are still embedded.

@din that workaround did not work for me 😦

As a temporary workaround for building add Post Action to your Scheme with the following content:

rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/"*.framework
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Plugins/"*.framework

This is the only solution that worked for me. None of the above did the trick, because the path to the frameworks was never found. But I based on those solutions for writing this one. Using Xcode 12.4, just in case.

rm -rf “${ARCHIVE_PRODUCTS_PATH}/Applications/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework” rm -rf “${ARCHIVE_PRODUCTS_PATH}/Applications/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework”

This issue is acknowledged in the Xcode 12.4 release notes along with a variation of the workarounds discussed here.

For folks having issues today: this is an outage on Apple’s side and is not related to this issue. https://developer.apple.com/system-status/

cc @darrarski, @kylebrowning, @AndrewBennet

My company’s app uses FirebaseAnalytics via Swift Package Manager with this workaround and we successfully submitted a build to Apple as recently as last night with no issues.

post-actions of Archive scheme

Where I can find this window with post-actions?

Product > Scheme > Edit Scheme > Click on Build > Post Action

@0x6A75616E Thanks for the detailed walkthrough, worked for me. Had to choose my app in the ‘Provide build settings from’ dropdown in Post-action.

I’ve done the workaround and it’s working when i archive upload. But using fastlane gym i’m still getting the following errors.

xcodebuild: error: Could not resolve package dependencies:
  artifact of binary target 'FIRAnalyticsConnector' failed extraction: The operation couldn’t be completed. (TSCBasic.StringError error 1.)
  artifact of binary target 'FirebaseAnalytics' failed extraction: The operation couldn’t be completed. (TSCBasic.StringError error 1.)
  artifact of binary target 'GoogleAppMeasurement' failed extraction: The operation couldn’t be completed. (TSCBasic.StringError error 1.)```

Are any others having this same issue? 

Confirmed this is still fixed in the Xcode 12.5 RC released today - will leave it open until the fix is the publicly released version.

Now that Xcode 12.5 stable is release, this issue should be fixed, right?

We use both Google and Firebase Frameworks. If your using FirebaseAuth or Firebase and some other Google Product then you probably are too. Do an archive and look inside the frameworks, plugins and watch folders. If you have something googley or Firebase in those folders chances are it shouldn’t be there.

rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Frameworks/Google"*.framework
rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Plugins/Google"*.framework
rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Watch/Google"*.framework

rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Frameworks/Firebase"*.framework
rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Plugins/Firebase"*.framework
rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Watch/Firebase"*.framework

Possibly if you don’t have a watch app you might need to delete the entire folder ie

rm -rf "${full_frameworks_path}/${PRODUCT_NAME}.app/Watch"

We also had a few app extensions containing the frameworks, which we had to remove as well:

#https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-707793520
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Plugins/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Plugins/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Plugins/Coyote Add to Board Action Extension.appex/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Plugins/Coyote Add to Board Action Extension.appex/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/Coyote Share Extension.appex/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/Coyote Share Extension.appex/Frameworks/GoogleAppMeasurement.framework"

After checking the product after building, I noticed that the frameworks may be copied to several folders, so I used the following commands: rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Plugins/FirebaseAnalytics.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Plugins/GoogleAppMeasurement.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Plugins/FIRAnalyticsConnector.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Watch/FirebaseAnalytics.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Watch/GoogleAppMeasurement.framework” rm -rf “${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Watch/FIRAnalyticsConnector.framework”

I was able to successfully submit a build to the App Store 👍🏼

I am also experiencing this issue. I have tried the Post action on the build phase and a run script. Neither of them worked for me.

I will have to revert back to pods until this is fixed

Combining @paulb777 and @ThePragmaticArt solutions works for me.

@jamiehunt Only acknowledgement that it is an issue so far.

“Pods have to download that insane Spec repo on top of everything else…” stupid statement with cocoapods cdn

Not that this is an appropriate conversation in this context, but a CDN doesn’t change the fact that you’re downloading over a gig of data. For most automation setups involving proper configurations (VMs spun up for single one offs with no cache), this is a heavy hit on time setting up a fresh copy of the project and overall overhead on the HDD/SSD among other things and can take around 5-10 minutes per run. It’s extraordinarily inefficient and slow especially for variable environments and network speeds. CDN doesn’t change that…

“Pods have to download that insane Spec repo on top of everything else…” stupid statement with cocoapods cdn

At this time SPM way seems to take much longer to fetch and resolve the dependencies graph. At least longer than with cocoapods. Even if we forget about the fact that it has some things to fix at this point, will it always take so long?

This is an opinionated statement that probably shouldn’t be here. Without cache, SPM is drastically faster than Cocoapods and avoids many of the clashing cache issues and project config issues Pods have. Pods have to download that insane Spec repo on top of everything else…

This issue is still exist on Xcode 12.5 (12E262). I could not upload the binary to App Store without adding Post-actions script.

As of Xcode version 12.4, I have verified following script eliminates this issue when added to “Post-actions” phase of “Archive”. It removes all static frameworks as some people are experiencing issues due to unrelated frameworks.

This script by @surajbarkale covers all the cases in our app (with embedded watch and iMessage extensions).

For us, we had to use ${PRODUCT_NAME} instead of ${TARGET_NAME} in the directory path:

cd "$SRCROOT"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/GoogleAppMeasurement.framework"

I have a Share Extension that was causing this Match-O header issue and this is what worked for me as well as an Archive post action:

# There was a problem when archiving because of Firebase in the Share Extension. This script is a workaround. Inspired from: https://github.com/firebase/firebase-ios-sdk/issues/6472
rm -rf "${ARCHIVE_PRODUCTS_PATH}/Applications/MyAppName.app/PlugIns/ShareExtension.appex/Frameworks/FirebaseAnalytics.framework"
rm -rf "${ARCHIVE_PRODUCTS_PATH}/Applications/MyAppName.app/PlugIns/ShareExtension.appex/Frameworks/GoogleAppMeasurement.framework"

That workaround and that one worked well here. Thank you guys.

I Have added a widget in my application and now this solution, that was working fine for me doesn’t work anymore, anyone has an idea on how can I solve it?

Hi @ZaniLuca ! Try adding the similar scripts for all your targets. I suppose you’ll have to add something similar to your widget scheme. Try opening failed build products (your archive --> open package contents --> … --> open package contents --> Frameworks) and see if there are miscopied frameworks that need to be removed.

Applied @darrarski solutions above for GoogleMaps as well - didn’t realize that had the same issue as Firebase. Posting here because I originally thought it was a Firebase issue even after using the solution, so this should save some google maps people some time

rm -rf “${ARCHIVE_PRODUCTS_PATH}/Applications/outfield-swift.app/Frameworks/GoogleMapsUtils.framework” rm -rf “${ARCHIVE_PRODUCTS_PATH}/Applications/outfield-swift.app/PlugIns/GoogleMapsUtils.framework”

I’ve heard that this error is a current App Store Connect issue, rather than related to this workaround.

I followed the instructions provided by @0x6A75616E and @Fedos here:

• https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-740186615
• https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-747375434

After doing it, the app archives, passes validation, and successfully uploads to App Store Connect from Xcode 12.3 (12C33).

Unfortunately, it can’t be processed. It doesn’t appear on App Store Connect website at all. After a while, I received following email message from App Store Connect for the build I’ve uploaded:

Dear Developer,

We identified one or more issues with a recent delivery for your app, “NameOfMyApp” 1.2.3 (456). Please correct the following issues, then upload again.

ITMS-90000: This bundle is invalid - $message.

Best regards,

The App Store Team

It looks like the solution is not valid anymore.

rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FIRAnalyticsConnector.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/FirebaseAnalytics.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Frameworks/GoogleAppMeasurement.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/FIRAnalyticsConnector.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/FirebaseAnalytics.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/PlugIns/GoogleAppMeasurement.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Watch/FIRAnalyticsConnector.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Watch/FirebaseAnalytics.framework” rm -rf “${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Watch/GoogleAppMeasurement.framework”

The problem with this solution is that if you have a Run Script which is required for Crashlytics is going to fail because it can’t find the files

.../Build/Intermediates.noindex/ArchiveIntermediates/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run: No such file or directory

Is there a solution for this?

@marekpridal thank you for the updated script! I totally spaced frameworks being part of the plug ins. The only thing is that I had to change it to use PRODUCT_NAME instead of TARGET_NAME

@borut-t I have a framework that includes Firebase, so I had to modify those paths, open the organizer -> .xcarchive --> .ipa and look for the actual paths.

As a note to follow up on the original diagnosis, I do recommend adding the remove process as a build phase action (no different than stripping binaries) to prevent the need for duplicating across targets and decoupling it from the schemes as such:

Does anyone have the script working with Xcode Version 12.0.1 (12A7300)?

The workaround suggested by @paulb777 worked for me, using Xcode Version 12.0 (12A7208). Thank you 💯

@ThePragmaticArt Sorry mate. Didn’t mean to insult anyone here. I’m actually a huge fan of SPM and promote it in local dev communities here in Russia. So, no hard feelings.

installing to device fails (no code signature found)

@antonmartinsson check that your TARGET_NAME is the same as a product that you try to deploy to device. In my case, I had JuiceFit target but Juice.app and that fix would not work until I’ve fixed my naming

I had to adapt the workaround for my unique setup. I have a separate target that contains all of my dependencies, so I had to change the path to go into the nested Frameworks directory within that other target. Then on top of that, because the other target’s Frameworks was empty, I needed to change the script to delete the entire Frameworks directory instead of the individual frameworks within:

rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/OtherTarget.framework/Frameworks"

I reproduced the issue, still unzipping the new GM seed and will test it there but I’ll see if I can find a workaround for the first GM seed.