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

[REQUIRED] Step 1: Describe your environment

Xcode version: Xcode 12 GM (12A7208)
Firebase SDK version: 6.32-spm-beta
Firebase Component: Analytics
Component version: 6.32
Installation method: Swift Package Manager

[REQUIRED] Step 2: Describe the problem
When trying to upload an archive to App Store connect Xcode 12 GM gives me the following error:
Found an unexpected Mach-O header code: 0x72613c21
If I change my build configuration to development the app builds and runs fine but if I switch to a release configuration and try to run the app on the latest iOS 14 iPhone 11 Pro simulator I get the following error:
Undefined symbol: _OBJC_CLASS_$_FIRAnalytics
and the following warnings:
missing required architecture arm64 in file /Users/neil/Library/Developer/Xcode/DerivedData/Kantinebaas-gnwjztsimxavkscwhhoheneylhus/Build/Products/Alpha-iphonesimulator/FirebaseAnalytics.framework/FirebaseAnalytics
missing required architecture arm64 in file /Users/neil/Library/Developer/Xcode/DerivedData/Kantinebaas-gnwjztsimxavkscwhhoheneylhus/Build/Products/Alpha-iphonesimulator/FIRAnalyticsConnector.framework/FIRAnalyticsConnector
missing required architecture arm64 in file /Users/neil/Library/Developer/Xcode/DerivedData/Kantinebaas-gnwjztsimxavkscwhhoheneylhus/Build/Products/Alpha-iphonesimulator/GoogleAppMeasurement.framework/GoogleAppMeasurement (2 slices)
Steps to reproduce:
Archive and try to submit project with a release build configuration using Xcode 12 GM with Firebase analytics added to the project using SPM.

Thanks for the report - I'll look into this right away. To confirm, did you add the -ObjC linker option for Analytics?

@ryanwilson yeah it was the first thing I checked! I went back to the Xcode 12 beta 6 and had no issues at all. Something that might be of note is apple released a new version of the Xcode 12 GM with build number of (12A7209). Im currently downloading it and I will try with that version also as it could of been a Xcode bug.

Yeah I'm downloading it as well, will report back when I can repro or not. Currently trying on 12A7208 but it's currently hanging when trying to check out grpc.. 😬

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.

Initial thought: if it's packaging for release, it may be trying to include all the architectures to run on device and it's not expecting to be run on the simulator? That's why it's searching for the arm64 architecture even though it's running on an x86 simulator. I tried running on device and get a different issue though, will try the new Xcode version.

Yeah I think its something to do with that also.

I can confirm I get the same issue with the new seed also.

Same re: running with Release. I am able to Archive though, selecting "Any iOS Device (arm64)" and hitting "Product -> Archive" in the menu.
Based on the original issue - you're unable to archive right?

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.

Yeah, so right now the firebase framework artifacts are being copied into the /Frameworks folder of the ipa and are embedded. The frameworks themselves are static frameworks....

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.

This is due to a static framework being embedded within the /Frameworks folder of the archive.

Thanks @ThePragmaticArt for finding that! I'm wondering if that's an Xcode bug or that's an artifact based on how we set up our Package.swift manifest. I'll see about reproducing with the upload case and filing some Feedback about it - especially since binary packages are new in SwiftPM.

.

Mach-O universal binary with 2 architectures: [i386:current ar archive random library] [x86_64:current ar archive random library]
FirebaseAnalytics (for architecture i386):	current ar archive random library
FirebaseAnalytics (for architecture x86_64):	current ar archive random library

It seems to have to do with the xcframework bundles included. Actual root cause, I'm not entirely sure. It does seem to be those 3 artifacts though.

Thanks @ThePragmaticArt for finding that! I'm wondering if that's an Xcode bug or that's an artifact based on how we set up our Package.swift manifest. I'll see about reproducing with the upload case and filing some Feedback about it - especially since binary packages are new in SwiftPM.

Mach-O universal binary with 2 architectures: [i386:current ar archive random library] [x86_64:current ar archive random library]
FirebaseAnalytics (for architecture i386):	current ar archive random library
FirebaseAnalytics (for architecture x86_64):	current ar archive random library

It seems to have to do with the xcframework bundles included. That's at least the only lead I can see. Actual root cause, I'm not entirely sure. It does seem to be those 3 artifacts though.

Those are in fact the only binary frameworks that we offer - all the rest are source based. It could be due to packaging of the XCFrameworks since they're manually generated from regular .frameworks (we hope to be changing over to build XCFrameworks directly very soon), or it could be an issue with binary frameworks in general on the Xcode side.

@ryanwilson I believe Realm has some embedded xcframework artifacts as well but do not have this issue:
https://github.com/realm/realm-cocoa.git

@ThePragmaticArt that must be outside of Swift Package Manager though - see here for where we define binaryTargets: https://github.com/firebase/firebase-ios-sdk/blob/cd844903abed3c4e73210af9b258808d21f455fe/Package.swift#L225-L239
This was introduced in swift-tools-version:5.3 and Realm is still on 5.0 and doesn't have any binaryTargets in their Package.swift file. We ship xcframeworks for our zip file and haven't had this issue, so I assume it's specific to SwiftPM's integration of binaries.

@ryanwilson interesting. I don't have anything separate I can test. I might be able to spin up something later today just to play around and see. Not sure if there are any quick samples that are already out there that could validate the behavior. It would be disappointing to hear there's a bug in the GM that requires a script to clean this up.

It looks like this is related to https://github.com/PSPDFKit-labs/radar.apple.com/commit/9b6c842d0d00465f20a82252df3735e4396beb06 (FB7785691). This was an issue opened stating that the archive should include those frameworks, but now we're running into an issue for Firebase.
@steipete - are you able to share how the XCFrameworks are generated and anything that may be going on here? Perhaps static vs dynamic frameworks?

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.

Thanks @steipete, helpful as always! :D That must be the issue, we package FrameworkAnalytics as a static framework. Will have to do some digging and chat offline with @paulb777 about how to proceed, but at least we have a workaround right now.

Keep in mind that there is another issue cropping up on Xcode 12 GM when deploying to device Code: -402620388 No code signature found:
https://forums.swift.org/t/swiftpm-binarytarget-dependency-and-code-signing/38953

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

@din that workaround did not work for me :(

It looks like a workaround is excluding arm64 in the Build Settings. See https://stackoverflow.com/a/63622570

@paulb777 that doesn't work either, can't build to device.

@kylebrowning Looks like I was conflating with another issue. Any change in behavior with @din's suggestion?

@paulb777 @din's workaround did not work out either.

@paulb777 @din's workaround did not work out either.
Just to be clear:

building for simulator works
installing on simulator works
building for device works
installing to device fails
archiving works
uploading archive fails.

Thanks @kylebrowning. I reproduced and reported the Xcode regression at https://feedbackassistant.apple.com/feedback/8705974 and will continue to investigate workarounds.

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 tested on Xcode 12.2 beta and got the same error Found an unexpected Mach-O header code: 0x72613c21

@paulb777 Thanks for that, im still getting the error, so maybe teach a friend to fish?
how did you determine which frameworks you should remove? I might have others being affected by this that are unrelated to Firebase so I wan't to either rule those out, or try the same work around.

I specifically identified the Firebase ones, since it would be problematic to remove dynamic frameworks.  You could remove all of them to start? Unfortunately, I wasn't able to find a way to log Scheme Post-Actions.  It wasn't working for me until I selected the "Provide build settings ...."

@paulb777 Okay that worked for me. However my other third party library(Kochava) fails for the same reasons, and following the same solution, I get a bigger error, probably because its dynamic and not static.
dyld: Library not loaded: @rpath/KochavaTracker.framework/KochavaTracker
  Referenced from: /private/var/containers/Bundle/Application/5A24965B-7D21-4065-8717-BB725CB4D2E8/theathletic-ios.app/theathletic-ios
  Reason: image not found
dyld: launch, loading dependent libraries
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
DYLD_PRINT_STATISTICS=1
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib:/Developer/usr/lib/libMainThreadChecker.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib
DYLD_PRINT_TO_STDERR=YES
(lldb)

@kylebrowning See the discussion at https://forums.swift.org/t/swiftpm-binarytarget-dependency-and-code-signing/38953 about dynamic frameworks. We probably can't help too much here on that part of it since Firebase only builds static binary frameworks.

Thanks @paulb777 I was already there for a bit. Haha. I'll jump back over there and post an update.

@paulb777 I had to slightly modify your workaround, but it appears to be working for me (i was able to archive/upload without any errors).
I use firebase in a framework so when I tried this script:
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/MyAppFramework.framework/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/MyAppFramework.framework/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/MyAppFramework.framework/Frameworks/FIRAnalyticsConnector.framework"

I got this error during archive validation
App Store Connect Operation Error
Invalid Bundle. The bundle at 'MyApp.app/Frameworks/MyAppFramework.framework' contains disallowed file 'Frameworks'.

I noticed that the Frameworks folder was empty, so I changed the script to this and it worked
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/MyAppFramework.framework/Frameworks"

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 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 just wanted to chime in and say that this workaround is unfortunately not working for me. I'm in the exact same boat that @kylebrowning was at a few days ago, with the following working/not working:

building for simulator works
installing on simulator works
building for device works
installing to device fails
archiving works
uploading archive fails.

As for my setup, I have a few static frameworks in a /Frameworks folder, and Firebase Analytics and Crashlytics imported via Swift Package Manager. I'll keep a steady eye on this issue while I try to solve it.

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

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?

@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

That did it! My target name was somewhat different from the final app name, and switching the target name to the actual app name solved it. Thank you so much!

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"

So I can build to my device now, but I still have the mach errors when archiving.

@kylebrowning same here, mate. Had to rollback to cocoapods for now :(

I'm also currently encountering this. Please ping me if I can help in debugging this in some way.
FWIW The issue is happening also with Xcode 12.2 beta (12B5018i).

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.

This is an opinionated statement that probably shouldn't be here.

This statement is only relevant to this particular thread and this particular sdk transition from cocoapods to spm.

This is an opinionated statement that probably shouldn't be here.

This statement is only relevant to this particular thread and this particular sdk transition from cocoapods to spm. And this happens to be related to https://github.com/firebase/firebase-ios-sdk/issues/6532

Ah, the verbiage made it sound like an attack on the core toolsets rather the handlings of the actual libraries. It's always helpful to reference or add clear and concise information as this is what can lead to an answer or conclusive response.

@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.

@paulb777 Do we have an update on how this issue can be resolved? The post action build scripts no longer work anymore so it's impossible to archive the project now. Any other possible work arounds?

@Neifau I haven't seen an example where the post-action workaround doesn't work once it is confirmed to remove all static frameworks from the app bundle.
Since this is an Xcode bug, I think the only other options are to go back to Xcode 12 beta 6 or wait for a fix in an upcoming Xcode release.

The post build script works for getting the build onto a device. It does seem to archive but when attempting to upload to Apple it's the issue marked at the top of this ticket.

The post script doesn't even work to run on my device anymore. I'm not aware of any other static frameworks being added to my project it seemed to stopped working after the latest Xcode update. What's the easiest way to find the static frameworks in the project?

"Pods have to download that insane Spec repo on top of everything else..."  Thank you 💯

"Pods have to download that insane Spec repo on top of everything else..."  For most automation setups involving proper configurations (VMs spun up for single one offs with no cache), this is a heavy hit on time and overall overhead on the HDD/SSD among other things. It's extraordinarily inefficient and slow. CDN doesn't change that....

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

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

You mean the Build Post-Action that @din suggested? Yep, that's working fine on Xcode 12.0.1 (12A7300) for me.

Ok thanks.. I will check the script is correct then because it keeps failing in another project I have setup.

@paulb777 the bug report link that you shared is not working for me - "Feedback Not Found"
https://feedbackassistant.apple.com/feedback/8705974
This is because the report is non-public, or its been closed by Apple? Do we have any indication from Apple if this will be patched for the next Xcode release? Could you kindly update us with any correspondence from Apple? Thanks.

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

I still get failed to build! please fix this issue!

As stated the workarounds mentioned here still produce the same error as detailed in #6676 @paulb777

also since CocoaPods no longer works on Mac please prioritize making this work with an officially maintained solution!

We still fully support CocoaPods on Mac.  If you have an issue with CocoaPods and Firebase, please open an issue describing how to reproduce.
The Firebase SwiftPM distribution is supported as documented at beta. This particular issue is an Xcode 12 issue acknowledged by Apple that we can't do a lot on the Firebase side besides discuss workarounds above like using one of the later Xcode 12 betas or removing static libraries from the built bundle.

Cocoapods will not install on the Mac beta I'm sick of wasting my time on something that wants me to downgrade software or OS to use @paulb777

the fact Firebase can't create a working product when Parse can means I'm dropping Firebase I'm tired of fighting with code and waisting my time when it's clear supporting standards isn't a priority

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!

No problem @morganchen12 thanks for the heads up and explanation

Probably worth extending @paulb777s answer to also remove these anomalies from the Plugins directory?

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.

Hey @moesalih, thank you for the help. Just to verify, the post-script runs on the Archive scheme (on Release), right? (If my need is to upload it to the store).

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"

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:

Combining @paulb777 and @ThePragmaticArt solutions works for me.

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

Yep, the Build Post-Action worked for me in Xcode Version 12.0.1 (12A7300), but using PRODUCT_NAME instead of TARGET_NAME as @alessionossa suggested

I cannot make it work on the latest Xcode 12.1. I've tried everything, still get the same error on upload 🤔

I cannot make it work on the latest Xcode 12.1. I've tried everything, still get the same error on upload 🤔

Do you get an error on upload or validation? Also, what is the error?

Before upload, so yeah on validation: Found an unexpected Mach-O header code: 0x72613c21

I've followed your instructions:

Maybe it's worth mentioning at this point that I also have OneSignal extension target in the project. But that's not related to Firebase 🤔

@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.

Before upload, so yeah on validation: Found an unexpected Mach-O header code: 0x72613c21

I've followed your instructions:

Maybe it's worth mentioning at this point that I also have OneSignal extension target in the project. But that's not related to Firebase 🤔

Log out the app path and read it in the console. Double check there's nothing unexpected configured in your build settings (like product/bundle/etc path or name). Small out of place configurations could lead to a needed tweak. The "APP_PATH" should lead you to were the copy framework phase would copy you frameworks too (how they ultimately end up in the bundle).

@callo90, @ThePragmaticArt I've double-checked the paths and they looked fine and the frameworks were actually deleted for regular app build. It got interesting for the archive step. The thing is that I have two schemes defined, like App Dev and App Prod. See space in the name. So I've modified the script a bit to escape space:
APP_PATH="${TARGET_BUILD_DIR// /\\ }/${PRODUCT_NAME}.app"
echo "App path ${APP_PATH}"
rm -rf "${APP_PATH}/Frameworks/FirebaseAnalytics.framework"
rm -rf "${APP_PATH}/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${APP_PATH}/Frameworks/FIRAnalyticsConnector.framework"

Now the path is properly escaped but for some reason, the path doesn't exist after I archive project:
/Users/borutt/Library/Developer/Xcode/DerivedData/App-dgdyqjgydzesslewypbrfsqeitxg/Build/Intermediates.noindex/ArchiveIntermediates/App\ Dev/InstallationBuildProductsLocation/Applications/App.app/Frameworks/FirebaseAnalytics.framework

Check the actual path on the system and it starts falling apart at after the scheme part. InstallationBuildProductsLocation doesn't exist, I can only see BuildProductsPath and IntermediateBuildFilesPath.
So the result of this is that the frameworks aren't deleted.

@ryanwilson @paulb777 Quick question for you guys, these beta branches have been evolving and updated fairly often and quickly (which is definitely good), but I don't believe any of this has made it beyond the beta branches into master branches or official releases. Is there a roadmap to when this may get out of beta and become part of the official release life cycle?

@ThePragmaticArt thanks for the question. The Package.swift manifest is definitely in master, let me share our current release strategy compared to CocoaPods and hopefully that clears things up a bit:

We create a release branch off master for our regular releases (to CocoaPods) (release-7.0 for example)
We create a new branch off the release branch with the same versioning as the 7.0-spm-beta for example, specifically for the purpose of having the spm and beta in the name.

We may add a few SwiftPM specific commits to this branch in case we find them for that release, like this one to speed up SwiftPM, but those are also cherry-picked into master afterwards

I'd like to differentiate the product offering of SwiftPM being beta quality and the "official release lifecycle". As of right now, SwiftPM support is part of the official release lifecycle and that will not change. The reasons that it's being called beta right now are for issues like this one (which is in Xcode so we can't provide a fix, but every Analytics user is going to run into it which is a bad experience in our opinion) along with the fact that not all SDKs are currently offered in the SwiftPM release.
The versions in the SwiftPM branch are directly related to the CocoaPods version (or the "official release"). We will likely switch to a proper semver strategy soon for ease of consumption, but the "Beta support" won't go away quite yet until we're confident users can have a great experience without having to struggle through things like this.
Thanks for helping us work through these issues! You can find other tasks that are being worked on in https://github.com/firebase/firebase-ios-sdk/projects/1, although not all are required for "Official" support as some are test related.

For case like mine, where the TARGET_NAME is different from the app name, the suggested hack will not work. A better way to do this is this:
rm -rf "${BUILT_PRODUCTS_DIR}/${FRAMEWORKS_FOLDER_PATH}/FirebaseAnalytics.framework"

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 😄

@marekpridal thank you for the updated script! I totally spaced frameworks being part of the plug ins.

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

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 confirm also with this modification I could compile and archive on Xcode Server CI
I'm wondering if we can add this on Xcode server's post trigger actions. I didn't try but maybe someone did?

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.

@ryanwilson Thank you for the info regarding the release process. I do have a side question and also understand this isn't necessarily your teams responsibility, but have you guys caught wind of any roadmap/path forward with SPM and GoogleTagManager + Firebase? I can't say their team is necessarily up to date with certain things, and they still only offer Cocoapods as an "official" supported package manager (which is quite disappointing). I'm not exactly fond of having to use a solution like Pods + Rome separately in order to have their binaries in our project.

Using the scheme's Post Build Action work-around did not work for me. Adding a run-script build phase to execute the rm command did.
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/"*.framework

Using the scheme's Post Build Action work-around did not work for me. Adding a run-script build phase to execute the rm command did.
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/"*.framework

I tried doing the same thing as trying to remove the frameworks as part of the post build phase leaves them in the archive. However, removing them from the archive causes a submission error:
ITMS-90562: Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.
Ultimately, a copy of each framework does need to be in the bundle, right? I'm kind of stuck -- removing the frameworks gets me past the "Mach-O header" error, but then it appears that since the frameworks are not in the archive, you get the dylib not present error.

@romayev Only static frameworks should be deleted. They're linked at build time and shouldn't be in the bundle. Dynamic frameworks should remain in the bundle. The file command can help you determine which is which.

@paulb777 Thanks, makes sense. The missing dlyb issue turned out be related to something else. So to summarize, the workaround worked for me, but not as a Post Build Action, but as a run-script build phase to be able to submit the archive to Apple.

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

I'm using the Xcode 12.2 still not working. :/

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 👍🏼

${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"

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.

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?

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

but then you can't submit a production build because you're using a beta Xcode version

@iosdec I believe that comment refers to a different issue than this one. That Forum thread includes multiple topics.

**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:

Produce an Archive the way you normally do. Once Organizer lists your Archive, right click on it and select Show in Finder
In Finder, right click on your Archive to select Show Package Contents
Navigate to Products > Applications and then right click on YourApp.app to Show Package Contents
Navigate to Frameworks
Take note of the Frameworks you'll have to remove. In my case it was only FirebaseAnalytics.framework and GoogleAppMeasurement.framework
Close Organizer, and go to Manage schemes > Edit scheme, then under Build, select Post-actions.
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.

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

@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?

We are also encountering the same issue with gym, while we have the 'rm -rf' workaround in a post build script in Xcode, gym fails at the end when archiving. Firebase with Swift Package Manager also.
** ARCHIVE FAILED **

The following build commands failed:
	CodeSign /Library/Developer/Xcode/DerivedData/teckro-ecyroeikhjpkxrbanultecxrweiv/Build/Intermediates.noindex/ArchiveIntermediates/teckroDev/InstallationBuildProductsLocation/Applications/Teckro.app/Frameworks/FIRAnalyticsConnector.framework
	CodeSign /Library/Developer/Xcode/DerivedData/teckro-ecyroeikhjpkxrbanultecxrweiv/Build/Intermediates.noindex/ArchiveIntermediates/teckroDev/InstallationBuildProductsLocation/Applications/Teckro.app/Frameworks/FirebaseAnalytics.framework
	CodeSign /Library/Developer/Xcode/DerivedData/teckro-ecyroeikhjpkxrbanultecxrweiv/Build/Intermediates.noindex/ArchiveIntermediates/teckroDev/InstallationBuildProductsLocation/Applications/Teckro.app/Frameworks/GoogleAppMeasurement.framework
(3 failures)
[09:47:38]: Exit status: 65

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"

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

So. I followed the steps everyone has mentioned above and I get past the Mach O error when uploading.
However upon install of said app to the device it crashes with a library not loaded error.
Did anyone get around that?

@kylebrowning same

@kylebrowning @georgmay do you get an error of which library is not loaded? I believe dynamic frameworks need to stay there but static frameworks (FirebaseAnalytics, GoogleAppMeasurement) do not.

@ryanwilson I'm not getting any errors of that nature on my side, I only encountered this issue when attempted to upload the binary into AppStore Connect (Mach-O).
Everything works after manually removing FirebaseAnalytics and GoogleAppMeasurement.

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"

Checked the actual path on the terminal and it starts falling apart at after the scheme part. InstallationBuildProductsLocation doesn't exist, I can only see BuildProductsPath and IntermediateBuildFilesPath.

@borut-t Any luck with the missing InstallationBuildProductsLocation? I'm having the same problem and I'm trying to figure out where and what environment variables I can use to remove the static firebase framework.

Why do you expect the application to work fine after removing these dependencies from bundle?

@nikolay-kapustin Static libraries are linked into the app at build time and redundant at runtime.

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?

@ZaniLuca try my solution above, i. e. run script after the archiving (you'll have to change paths)

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:

Produce an Archive the way you normally do. Once Organizer lists your Archive, right click on it and select Show in Finder
In Finder, right click on your Archive to select Show Package Contents
Navigate to Products > Applications and then right click on YourApp.app to Show Package Contents
Navigate to Frameworks
Take note of the Frameworks you'll have to remove. In my case it was only FirebaseAnalytics.framework and GoogleAppMeasurement.framework
Close Organizer, and go to Manage schemes > Edit scheme, then under Build, select Post-actions. Make sure to check Provide build settings from -> YourApp.
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.

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:

Produce an Archive the way you normally do. Once Organizer lists your Archive, right click on it and select Show in Finder
In Finder, right click on your Archive to select Show Package Contents
Navigate to Products > Applications and then right click on YourApp.app to Show Package Contents
Navigate to Frameworks
Take note of the Frameworks you'll have to remove. In my case it was only FirebaseAnalytics.framework and GoogleAppMeasurement.framework
Close Organizer, and go to Manage schemes > Edit scheme, then under Build, select Post-actions. Make sure to check Provide build settings from -> YourApp.
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.

post-actions of Archive scheme

Where I can find this window?

post-actions of Archive scheme

Where I can find this window?

post-actions of Archive scheme

Where I can find this window with post-actions?

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

post-actions of Archive scheme

Where I can find this window with post-actions?

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

Except for me it worked not on Build but on Archive scheme:
Product > Scheme > Edit Scheme > Click on Archive > Post Action

Except for me it worked not on Build but on Archive scheme:
Product > Scheme > Edit Scheme > Click on Archive > Post Action

I literally followed the exact same steps as above would have been clue less otherwise.

I literally followed the exact same steps as above would have been clue less otherwise.

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.

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.

Just got the same above error as well.

Just got the same above error as well.

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

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

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.

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.

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

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

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

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

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 static 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).

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 static 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).

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"

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"

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"

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?

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"

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?

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.

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.

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

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

Despite following all the previously recommended suggestions for removing frameworks in either Build or Archive steps, I couldn't get Firebase Analytics through Swift Package Manager to work. Ended up removing everything from Swift Package Manager and following manual integration steps. Do keep in mind all Firebase frameworks are static, so you'll have to avoid embedding them into your app. More info on that approach here:
https://firebase.google.com/download/ios#integrate-without-cocoapods
https://www.simpleswiftguide.com/how-to-add-xcframework-to-xcode-project/ (skip the embed+sign)
Explanation of static/dynamic and signing:
https://stackoverflow.com/questions/33076819/found-an-unexpected-mach-o-header-code-0x72613c21-in-xcode-7

Despite following all the previously recommended suggestions for removing frameworks in either Build or Archive steps, I couldn't get Firebase Analytics through Swift Package Manager to work. Ended up removing everything from Swift Package Manager and following manual integration steps. Do keep in mind all Firebase frameworks are static, so you'll have to avoid embedding them into your app. More info on that approach here:
https://firebase.google.com/download/ios#integrate-without-cocoapods
https://www.simpleswiftguide.com/how-to-add-xcframework-to-xcode-project/ (skip the embed+sign)
Explanation of static/dynamic and signing:
https://stackoverflow.com/questions/33076819/found-an-unexpected-mach-o-header-code-0x72613c21-in-xcode-7

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

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

Thanks for everyone's help. I did something similar, but attempted a more automated approach to look for static libraries.
In my scheme's Build Post-action I added a run script containing: $SRCROOT/buildScripts/fix_swift_pm_build_post_action.sh
remember to chmod it so it can execute. The shell script I used is:
`# Remove all static libraries to avoid unexpected "Mach-O header code: 0x72613c21" error
https://github.com/firebase/firebase-ios-sdk/issues/6472
path="${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app"
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}/Frameworks/$line"
rm -vrf "${path}/Plugins/$line"
rm -vrf "${path}/Watch/$line"
rm -vrf "${path}/AppClips/$line"
rm -vrf "${path}/AppClip.app/Frameworks/$line"
done
`

Thanks for everyone's help. I did something similar, but attempted a more automated approach to look for static libraries.
In my scheme's Build Post-action I added a run script containing: $SRCROOT/buildScripts/fix_swift_pm_build_post_action.sh
remember to chmod it so it can execute. The shell script I used is:
`# Remove all static libraries to avoid unexpected "Mach-O header code: 0x72613c21" error
https://github.com/firebase/firebase-ios-sdk/issues/6472
path="${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app"
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}/Frameworks/$line"
rm -vrf "${path}/Plugins/$line"
rm -vrf "${path}/Watch/$line"
rm -vrf "${path}/AppClips/$line"
rm -vrf "${path}/AppClip.app/Frameworks/$line"
done
`

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"

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"

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"

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"

The issue still exists in Xcode 12.4 (12D4e), but it looks like it's not necessarily an Xcode issue. fortrese's solution worked for me although have not tried the script yet (manual deletion of the two Firebase dependencies did the trick).  I had installed Analytics through cocoapods before but whatever I tried, I could not make it work any more on the simulator of my M1 Mac starting from v 7.3 (7.2-M1 worked though). No issues building on M1 iOS simulator once I installed all Firebase dependencies through SPM.

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"

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

The script posted by @surajbarkale seems like the most generic working one, especially if you have extensions or App Clips there are more places where the static framework needs to be removed from, i.e. the PlugIns and AppClips directory.

Thank you @surajbarkale! The script does the magic!

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.

Thanks for sharing the news @marius-serban! It would be great to hear if Xcode 12.5 addresses other variants of the issue as well. I'll keep this issue open until Xcode 12.5 exits beta.

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"

Thank you @surajbarkale! Script works great!

An important note!
If you have app extensions (ex: a notification service), then are .app will contain a PlugIns/ folder. If this is the case, then you will need rm -rf commands for Plugins/ in addition to Frameworks/.
For me, that meant the following
# works when you have an app extension
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FirebaseAnalytics.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/GoogleAppMeasurement.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/FIRAnalyticsConnector.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/PlugIns/FIRAnalyticsConnector.framework"

Instead of just...
# works when you don't have an app extension
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"

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 scripts covers all the cases in our app (with embedded watch and iMessage extensions).

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)

Hi guys.. i solved this problem changing the code signing identity. The target and project was different and i changed all for iOS Distribution according the provision profile file.

Honestly shocked Apple haven't hotfixed this in 12.4 Xcode at least as it looks like it's been an issue for a while... ugh

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.

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?

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.

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

Hi @testAVD and @batuhansk, sorry for the trouble you're facing.
Can you please try to reproduce this in a new project and let me know if you see the issue? If so, can you please confirm:

You're using Xcode 12.5 (and if you have multiple Xcode versions installed, it's activated with xcode-select)
Which Firebase products are you including?
Are you using any non-Firebase products that are binaries as well? Can you list which ones?

Thanks. If we can get a clean repro on Xcode 12.5 I'll re-open this issue.

Hi @testAVD and @batuhansk, sorry for the trouble you're facing.
Can you please try to reproduce this in a new project and let me know if you see the issue? If so, can you please confirm:

You're using Xcode 12.5 (and if you have multiple Xcode versions installed, it's activated with xcode-select)
Which Firebase products are you including?
Are you using any non-Firebase products that are binaries as well? Can you list which ones?

Thanks. If we can get a clean repro on Xcode 12.5 I'll re-open this issue.

Hi @ryanwilson,

No, I do not have multiple Xcode versions. Only Xcode 12.5 (12E262).
I use FirebaseAnalytics, FirebaseMessaging and FirebaseRemoteConfig products.
Yes I do. I use Realm as binary as well.

Thanks.

Thanks for the confirmations. If you create a brand new project and only include FirebaseAnalytics, FirebaseMessaging, and FirebaseRemoteConfig do you see the same issue?


Bug cvui:image() crash when size of image is larger from canvas

I found a bug, and it is occurring in different scenarios
first scenario - drawing image on a smaller canvas
cvui::image(frame, 0, 0, map);
calling cvui::image, when frame size is 1280x720 (width, height)
and the map image is larger, theRect is 1480x840
then the call to image() crashes on theImage.copyTo(theBlock.where(theRect));
int function render::image(theBlock, aRect, theImage);
the size of theRect is larger then theBlock!
need to resize, or not crash
when using movable EnhancedWindow  with an image inside of it , and it is dragged out of frame
in this case, theRect has for example x=-10,y=10 if I drag it to the left , so the program crashes on same issue
cvui::image() on theImage.copyTo(theBlock.where(theRect));
I tried adding if statement to resolve crashing,
void image(cvui_block_t& theBlock, cv::Rect& theRect, cv::Mat& theImage) {
		if (theRect.x < 0 || theRect.y <0 || theRect.y  + theRect.height > theBlock.where.rows)
			return;
		theImage.copyTo(theBlock.where(theRect));
	}

But this does not give good beheivior because for example trying to draw larger image , just does not draw anything. maybe larger image should be resized?
It fixed the issue of dragging the window with an image. but it did not cover all ways the window is dragged.
Hope there is a solution
Thanks in advance
M.

Thanks for the bug report. I think this problem you reported happens in different parts of cvui as well, when a frame to be rendered is larger than the available space, e.g. window area. I'll try to fix this problem by cropping the are that should not be displayed.

Hi
this is how I fixed this
void image(cvui_block_t& theBlock, cv::Rect& theRect, cv::Mat& theImage) {
		if (theRect.x < 0 || theRect.y <0 ||theRect.x + theRect.width > theBlock.where.cols || theRect.y  + theRect.height > theBlock.where.rows)
			return;
		theImage.copyTo(theBlock.where(theRect));
	}

added this If statement you can check if this is correct and covers all the issues.

Thanks, that's a great starting point for me.


Limited cancellation logic for asynchronous consumers

When we have an observable that we want to consume asynchronously (via, for example, FoldLeftAsyncConsumer), we're often interested in having a solid story for cancellation of the tasks that are being run in the background.
For example, imagine I have an observable of file watch events and I want to read the contents of a file every time there's such an event asynchronously. Whenever the observable is cancelled, I want all the running tasks that are reading contents from files to be correctly cancelled too.
By default, FoldLeftTaskConsumer does not do that https://github.com/monix/monix/blob/2e8a6a8790d1b971cf9ecb7ca45327636d532997/monix-reactive/shared/src/main/scala/monix/reactive/internal/consumers/FoldLeftTaskConsumer.scala#L75, it only returns a dummy assignable.
However, this is rarely what we want. We often want a consumer that will cancel all the running tasks, like I do in bloop via my own FoldLeftAsyncConsumer https://github.com/scalacenter/bloop/blob/825fb39bc94923a94ac7bcfbf4a484b6506ad8b2/frontend/src/main/scala/bloop/monix/FoldLeftAsyncConsumer.scala#L62-L67
However, changing the consumer is not enough to get the behavior I want. The definition of Consumer assumes that all consumers return an empty assignable cancelable and assigns the subscription cancelable to the consumer one https://github.com/monix/monix/blob/2e8a6a8790d1b971cf9ecb7ca45327636d532997/monix-reactive/shared/src/main/scala/monix/reactive/Consumer.scala#L67-L80
This is problematic because if the assignable is a multi cancellable, it will override the previous tasks. If it is single, it will ignore the cancelable given by the source subscription. In both cases, we lose cancellation capabilities.
Instead of the current logic, I propose to upstream my redefinition of the apply method in Consumer (which in 3.0.0-RC1 is final and cannot be overridden):
 Task.cancelable0 { (scheduler, cb) =>
   val (out, consumerSubscription) = createSubscriber(cb, scheduler)
   val sourceSubscription = source.subscribe(out)
   if (consumerSubscription.isInstanceOf[Cancelable.IsDummy])
     sourceSubscription
   else CompositeCancelable(sourceSubscription, consumerSubscription)
}

If I don't miss anything, I think this should fix the issue upstream. We've been using this technique in bloop for quite some time, so I think it should work.

What we need to do is to cancel running tasks in async consumers. There shouldn't be parallelism, so we should be able to just use MultiAssignCancelable for latest Task instead of ListBuffer in bloop version.

My implementation in bloop is lacking and very custom for my use case, I remember just putting some extra code together because MultiAssignCancelable wasn't working correctly. Let's ignore it, I'm not proud of it :smile:

it seems though that's not enough for you, since on cancellation of observable you complete the Task with results so far instead of making it non-terminating. That's an operator we don't have, but it could be implemented with Ref + ForeachAsyncConsumer

Do you mean that I complete the observable when one of its tasks has been cancelled?
If that's the case, I think that you usually want both: cancelling all existing tasks and completing the observable, and that's why I did that, though I could have probably implemented it as an extra doOnCancel on the part consuming the observable (I'm not sure about it though).


[Feature]: Free the 🐡 (Emoji in group/run names)

Description
Hello, I would like to bring to your attention a critical missing feature of the utmost importance. It is currently impossible to use emoji in group names (and probably in run names too). This is a mission critical feature for BagsOfMoneyHQ, which is currently an important free tier user.
Suggested Solution
Free the 🐡 (I would actually like this)
Alternatives
Let the 🐡 be sad :/
Additional Context
No response

I 🐡/🐡 second this thank you in advance for making ml fun

🐟
🐟🦈
🐟😮 🦈
Yumm 🦈
Feature documented

it's pronounced WAND - BEE


Inject mdx compiler for mdx1

fixes https://github.com/storybookjs/builder-vite/issues/557
I found that mdx was not working correctly here, and @valentinpalkovic realized my fallback in Storybook 7 wasn't either (https://github.com/storybookjs/storybook/pull/20823).  It was because we used to inject the mdx compiler into the source code that we get back from the @storybook/mdx1-csf compiler, but we lost that in https://github.com/storybookjs/builder-vite/pull/548/files#diff-f2dfc4dfa9074d77a728a88e6629a1d66be8a0765cab8562526cd00fbae910e5L6.  This re-introduces it, with a bit better of a guarantee that the correct version is going to be loaded, by starting from inside @storybook/mdx1-csf.

Hm, based on the CI failures we might need to also require react to be a peer dependency like we do in SB 7.  :-/

Looks good. :)

Turns out that rollup does not respect NODE_PATH, so we need to do a bit of resolution hackery to get it to resolve react relative to the example, and not from within builder-vite's node_modules.  Normal projects will not need to worry about this, it's just due to our non-standard multi-project example structure.

@joshwooding I'm having trouble with Windows here.  Any chance you can give this a shot?

Hi @IanVS
from issue 21023
CI passed when enabled previewMdx2 :

https://github.com/zhyd1997/builder-vite/pull/2/files/5e198d79e680ddc8047238a8e8e6f0ffe83c2ab6..824c0585f12824f6f08a18f2d526dcfe81673987
so this is mdx1-csf transform issue:
https://github.com/storybookjs/builder-vite/blob/4d49af67e795330248c6967741eafb6c5f0cc6cf/packages/builder-vite/plugins/mdx-plugin.ts#L20-L26

Yes, mdx1 requires us to inject an import into the code, and the yarn portal we are using for the examples doesn't seem to be working very well, because imports in builder-vite are not resolving back to the example's node_modules without some help.  It's working fine on posix systems, but not windows. I'm tempted to merge anyway and hope that Josh can get our CI green later. It's only an issue in our examples I believe.


Update Composer dependencies (2020-11-05-00-05)

Visual regression test passed!
View the visual regression test report


Non-ASCII characters are not handled correctly

I noticed that if a string value contains a character outside ASCII the POST fails with 403.
I tried copying the code to my own project, and found the cause. This line, specifically serializedJsonObject.Length, only works when the string only contains ASCII characters.
https://github.com/Zimmergren/LogAnalytics.Client/blob/51894390599bc69a543f8ed8c65000457af4b450/LogAnalytics.Client/LogAnalytics.Client/LogAnalyticsClient.cs#L127
If you replace it with Encoding.UTF8.GetBytes(serializedJsonObject).Length, or something similar, it should work for more strings.
Note, that this simple solution would not have the best performance, but that might be a lesser concern.

Hey @GunnarHakansson ,
Thank you for filing the issue, along with a fix.
I could integrate some tests into the full E2E tests for this.
Do you possibly have an example of a working vs. non-working object to pass into the code, then I could quickly integrate a few tests for that and get a new release done.

Sure. Here is a minimal program to reproduce it.
        static async Task Main(string[] args)
        {
            var client = new LogAnalyticsClient(args[0], args[1]);

            var working = new ToLog() {Message = "A"};

            var nonWorking = new ToLog() { Message = "Å" };

            await client.SendLogEntry(working, "TempTest");

            await client.SendLogEntry(nonWorking, "TempTest");
        }

        public class ToLog
        {
            public string Message { get; set; }
        }

By the way, there are some feature improvements I would like to make. Should I just send a Pull Request, or open a new issue for discussion first?

I can integrate the above examples into the E2E tests and verify that they work all the way, and that the fix works with the existing scenarios.
Meanwhile, do what you think make most sense - I'm open for both discussions and PRs. All help is appreciated.


Rustfmt

I removed everything from rustfmt.toml but the line disabling normalize_comments because that feature breaks glob.

Out of curiosity, how does it break? Would it be possible to unbreak with a local annotation?

It was turning:
None => { /* not a directory, nothing more to find */}

Into:
None => { // not a directory, nothing more to find }

Anyways, I fixed it with whitespace and got rid of the config.

I feel like this should be reported upstream, no? Seems like a bug.
On Tuesday, January 26, 2016, Steven Allen<EMAIL_ADDRESS>wrote:

It was turning:
None => { /* not a directory, nothing more to find */}
Into:
None => { // not a directory, nothing more to find }
Anyways, I fixed it with whitespace and got rid of the config.
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang-nursery/glob/pull/47#issuecomment-175226502
.

@blaenk Yes, I'm just lazy... https://github.com/rust-lang-nursery/rustfmt/issues/784

Thanks for the investigation!


Normalize input and intermediate data sources

In order to simplify the handling of data throughout the pipeline, it would be good to normalize the format of the data as much as possible, starting with the raw data sources.
Currently we have:
raw data

dataset
ext
format
rows
columns
row.id

rnaseq_expression
.csv
CSV
gene
cell line
GENE_ID

drug_response
.txt
Tab
drug_cell line
variable
UID

filtered data

dataset
ext
format
rows
columns
row.id

rnaseq_expression (normed)
.csv
CSV
gene
cell line
None

rnaseq_expression (z-scores)
.csv
CSV
gene
cell line
None

exome/genes_per_cell_line
.txt
Tab
gene
cell line
GENE_ID

exome/transcripts_per_cell_line
.txt
Tab
transcript
cell line
transcript_id

drug_response/_filtered
.csv
CSV
drug
cell line
None

combined data

dataset
ext
format
rows
columns
row.id

.csv
CSV
cell line
_
None

Further, it is less important, but the files also vary in their use of quoted fields or row identifiers.
Question
Should we reformulate the initial drug response data to split the combined drug cell line ids? We can either have two columns and use a numeric primary key for the file, or split the dataset into separate files by drug or cell line as was done in the filtered section?
Normalizing the other files
Possible approach for normalizing all other data:

CSV
Cell lines across columns
No quotes
Include row id: (gene_id, drug, etc)

The one exception I would suggest would be for annotation sources (GO, CPDB, MSigDB). Since these are typically handled differently, we can probably just leave them as-is. A middle-layer script can then be used to read in the files into a standard format. This way the raw versions will simply be those downloaded from the respective databases.

I'll take care of this

....including CNV
raw data:
cnv_log2_mean-value  .seg Tab [[columns are: ID(cellLine), chrom
(chromosome), loc.start (region start location), loc.end (region end
location), num.mark (quality value), seg.mean (log2 chromosomal segment
mean value)]]
filtered (processed) data:
cnv_log2_mean-value  .tab  Tab  cellLine  genes  GENE_ID (ENSEMBL)
[The 'filtered' table can transposed to have the GENE_ID outputted as rows]
On Thu, Aug 6, 2015 at 8:59 AM, Aleksandra Michalowski <
<EMAIL_ADDRESS>wrote:

I'll take care of this
—
Reply to this email directly or view it on GitHub
https://github.com/DCGenomics/Pharmacogenomics_Prediction_Pipeline_P3/issues/2#issuecomment-128354415
.

--

Sounds good! Just let me know if you need any help.
If you can, try and commit changes in small increments -- that way we will know which files you are working on and can try and avoid working on the same files.

Thanks!

As per our offline discussion, we're aiming for:

tab-delimited files
with header
no quotes
first (index) column should be along the lines of gene_id, pathway_id, transcript_id. Exception is the standard VCF output where the header starts with #CHROM.


Doctors page: List of doctors

In this pull request, I was able to:

create sidebar where you can navigate from one page to another.
integrate  sidebar component inside the doctorsPage component.
create doctoresPage component that lists all the available doctors you can book appointments with.
use react carousel to show the rest of the doctors on the page load.
ensure the code is free of linter errors.

Thanks for the warm feedback @usorfaitheloho


Consider shellcheck

I don't know if this is the best one, but shellcheck running on pull requests would be cool for enforcing simple code conventions, like number of spaces, and returning true/false when possible, etc.

Shellcheck does not support zsh https://github.com/koalaman/shellcheck/issues/809

It would be a great addition! Maybe we can push forward to have zsh included in shellcheck, or use ksh? Not sure how alike are those.

I don't think this is happening anytime soon 😞


All campaigns 404 from GB, CA

Most likely related to behaviors based on the language-map Strongarm settings.

Alright this is weird, unable to reproduce on my local?

Apparently I accidentally fixed this. WOO HOO


fixed Fusion_Viewport to allow displaySets to be changed

Context
This pull request addresses an issue where the fusion viewport does not refresh and match correctly when dragging and dropping CT and PT displaySets. The problem arises because the volumes added do not share the same FrameOfReferenceUID. Additionally, the displaySetMatchDetail of the fusion viewport  is not updated with the new displaySetInstanceUID, further exacerbating the issue.

Changes & Results

Modified the displaySetMatchDetail to update the displaySetInstanceUID with the appropriate value.

Testing

Checklist
PR

[] My Pull Request title is descriptive, accurate and follows the
semantic-release format and guidelines.

Code

[] My code has been well-documented (function documentation, inline comments,
etc.)

Public Documentation Updates

[] The documentation page has been updated as necessary for any public API
additions or removals.

Tested Environment

[] OS:
[] Node version:
[] Browser:

@wayfarer3130 he add the panel but the deploy preview is in a cancelled state, however it's workin locally


Switch from ActionBarSherlock to AppCompat

This should set the foundation to really allow developers to start digging in to implementing material design.

Removes ActionBarSherlock and the RoboSherlock library supporting it
Adds AppCompat and wrapper classes for ActionBarActivity that provide what RoboSherlock provided for ABS

This still uses RoboGuice 2.0. 3.0 would be nice, as it has 1st party support for these wrapper classes.
This also requires setting minSDK to 11, which in turn means we can really bump it up to 15. 15 still covers 90+% of all Android users, and almost certainly close to 100% of the tech savvy ones that use the Github app.

Set basic color palette (you guys can change this to whatever you like, I just went with a safe option of the grey primaryColor, darker version for primaryColorDark, and the blue for accentColor
Use AppCompat's new searchview UI (including using its new icon, which allows us to remove the old one)
Improved .gitignore (my IDE kept wanting to commit IntelliJ files...)
Removed unnecessary declarations from AndroidManifest

The actionbar cuts over the tab pager a little, but I don't think that's a new bug having seen it in the store version prior to this.
You guys should update your current actionbar items to fully-white versions of their new Material alternatives. They're available for free come google here, or I can add them in this pull request as well if you want.
This addresses #658
Screenshots album: http://imgur.com/a/x76xf
Couple screen records of the new UI:

https://www.dropbox.com/s/7yoh831834u7nlm/device-2015-01-04-180254.mp4?dl=0
https://www.dropbox.com/s/68oy4v2lo1dv29c/device-2015-01-04-180455.mp4?dl=0

@hzsweers good stuff.
"The actionbar cuts over the tab pager a little, but I don't think that's a new bug having seen it in the store version prior to this."
-- This is not happening in my device (Galaxy S3).
"You guys should update your current actionbar items to fully-white versions of their new Material alternatives. They're available for free come google here, or I can add them in this pull request as well if you want."
-- Please include it in this PR as well.

Will do. I'll investigate further with the actionbar overlap as well. If
you like the tabs UI issue I just opened though, perhaps I can skip trying
to fix the overlap and just implement that instead. What do you think?
On Sun, Jan 4, 2015 at 7:25 PM Fadil Sutomo<EMAIL_ADDRESS>wrote:

@hzsweers https://github.com/hzsweers good stuff.
"The actionbar cuts over the tab pager a little, but I don't think that's
a new bug having seen it in the store version prior to this."
-- This is not happening in my device (Galaxy S3).
"You guys should update your current actionbar items to fully-white
versions of their new Material alternatives. They're available for free
come google here, or I can add them in this pull request as well if you
want."
-- Please include it in this PR as well.
—
Reply to this email directly or view it on GitHub
https://github.com/github/android/pull/661#issuecomment-68664437.

Actually, if you go into 'filtering' branch, then you can see that material-y tabs are the way to go.
#109

Btw, shouldn't the expanded dropdown list be shown right on the bottom of the actionbar?
Because right now, it goes on top of the actionbar.
I'm just curious if you're doing this on purpose.

I'm not sure I understand what you mean about the filtering PR. Should I
contribute to that separately or do you mean it's already been given the
thumbs up?
In material design (and by extension, lollipop and appcompat), popup menus
appear on top of the root view that they originate from. The overflow does
the same thing. The idea iirc is that you don't need to see currently
selected item when you're picking a new one.
On Sun, Jan 4, 2015 at 7:37 PM Fadil Sutomo<EMAIL_ADDRESS>wrote:

Btw, shouldn't the expanded dropdown list be shown right on the bottom of
the actionbar?
Because right now, it goes on top of the actionbar.
I'm just curious if you're doing this on purpose.
—
Reply to this email directly or view it on GitHub
https://github.com/github/android/pull/661#issuecomment-68664980.

This is what the current play store version looks like for me by the way. Maybe it's a quirk of Moto X?

Ghhgvchhhihv

@fadils I've updated the PR with new icons from the material design icon repo
I couldn't find replacements for the following since they're Github-specific:

Dashboard
Gist
Issue close/open/reopen

I also think the app icon is due for a refresh. Just using the "Mark" from your logos with the octocat filled in as white would look great IMO.

Confirmed that the tabs overlap is specific to my moto x, works fine elsewhere. I think it's best to save tackling that and the tabs material refresh separately

The code looks good to me, but I haven't tested it extensively on a real device yet. I'll do it tonight if @fadils doesn't do it first ;-)

Sounds good!
--
Henri Sweers
Sent with Airmail
On January 5, 2015 at 8:57:08 AM, Jon Ander Peñalba<EMAIL_ADDRESS>wrote:
The code looks good to me, but I haven't tested it extensively on a real device yet. I'll do it tonight if @fadils doesn't do it first ;-)
—
Reply to this email directly or view it on GitHub.

Awesome work BTW :+1:

Happy to help! :smiley:

@hzsweers Quick suggestion - wouldn't it be nicer if the toolbar has colors similar to the top bar on the website?

@mustafa01ali I'd be fine with that, I was just trying to best match the existing app theme. Wouldn't be hard to change (though maybe a bit tedious to go change the icons again...). @jonanp @fadils what do you think?

@hzsweers That's not a problem, I can help with making the change. Doing so, IMHO will make it look consistent with the overall simple and clean Github UI that we all love.

Cool. Let's see what they think first before going through the trouble

@hzsweers Same with @jonanp, I think it's good.
Several things:

The menu is a bit tight so that the item's name is cut off.
Regarding the arrow, with your name (hzsweers) then the arrow right after the name. But if the username's is a bit shorter such as "fadils" or "github", then there is a big gap afterwards, and thus the arrow still be seen a bit after the menu is expanded.
These two things to maintain the consistencies between ABS and AppCompat.
And preferably solved in this PR, if that doesn't bother you too much @hzsweers =)
Other issues such as color, animation, etc.. then we can continue afterwards.

So I think you can only get one or the other here. Somehow we'll need to get access to the Spinner instance in the ActionBar and set its dropDownWidth field. IIRC we can set it to "wrap_content" and it will set the width to the largest measured width in the first 15 items. As a result though, I think the width for the arrow would then align to this new width regardless.
I'll tinker with it tomorrow, need to catch up on some sleep tonight. The easiest case might be to inflate a separate custom spinner and avoid the navigation list mode all together (which is preferable since it's deprecated). I'm not 100% sure about how the respective widths would align though, so I'll have to actually see it in action to know for sure.

Other issues such as color, animation, etc..

Do you mean with the changes in this PR or with just implementing Material Design in general?

Sure.
I just meant that apart from two things I mentioned above, then if we can complete it (color, animation, etc) within this PR, it would be great. If it's done in separate PRs, then it should be fine too.

So I'm having a lot of trouble trying to resolve this. I think it's an issue related the underlying adapter not setting correct layout params in getView() or reporting an inaccurate width, but nothing I do seems to change it. A regular spinner should set its width to whatever the widest measured item in the first 15 items is.
This form of navigation though is also deprecated now, so I was wondering if I could propose an alternative approach. In the spinner adapter, the top items are orgs and clicking them will cause a fragment switch. This is normal behavior with an actionbar list. However, the bottom three items (Gist, issues, and bookmarks) all start new activities. This is a little weird due to it behaving differently than the first three items. What would you think of dropping the actionbar list entirely and switching to an alternative type of navigation? Specifically I think this would be a great use-case for a navigation drawer. I've seen elsewhere in PRs/issues that you're planning to add more controls (account-specific info, settings, etc), and I think this would help facilitate that. What do you think?

I like the idea of a navigation drawer, i feel better to use.

+1 for navigation drawer, but I would do it in another PR so we can discuss it in more detail.
And I don't consider the spinner issue a stoper for merging al this, so if everything else is fine it can be merged.

Agree

Cool, I think that covers any blocker issues I can think of, so let me know if there's anything else that needs to be addressed!

+1 for nav drawer, 3+ orgs in a spinner are not very usable

Sounds awesome.
Will merge this.

@hzsweers #368 has nice wireframes regarding the nav drawer.

Cool, I'll make an issue and reference it.


removes use of multimethods

Yeah, IMO we should avoid encouraging the use of multi-methods
http://stackoverflow.com/questions/33299746/why-are-multi-methods-not-working-as-functions-for-reagent-re-frame/33487691#33487691

Thanks for the PR! :)