Xcode 12 GM Archive Error SPM - unexpected Mach-O header code: 0x72613c21
Neilfau opened this issue · 160 comments
[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.
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
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.. 😬 EDIT: it resolved, just took a while.
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.... If you delete them from the xcarchive manually, everything works as expected. I'm not sure what's running behind the scenes to trigger this embedding phase though, but it needs to be removed.
I can archive its when I try to upload to the App Store I get the
Found an unexpected Mach-O header code: 0x72613c21error. 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.
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.swiftmanifest. 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
https://github.com/realm/realm-cocoa/tree/master/core
Not sure if that helps as a reference point for something that might be similar.
@ThePragmaticArt that must be outside of Swift Package Manager though - see here for where we define binaryTargets:
firebase-ios-sdk/Package.swift
Lines 225 to 239 in cd84490
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 PSPDFKit-labs/radar.apple.com@9b6c842 (FB7785691). This was an issue opened stating that the archive should include those frameworks, fixed in the GM, and 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? (Also, thanks for having that repo and the context - we would have been blind to it otherwise).
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.
Workaround:
Yeah, so right now the firebase framework artifacts are being copied into the
/Frameworksfolder of the ipa and are embedded. The frameworks themselves are static frameworks.... If you delete them from the xcarchive manually, everything works as expected.
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.
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.
Things I've tried for each new process.
- Delete Derived data
- Delete app from Phone
- Restart Phone
- Restart Xcode
- Din's suggestion for post action build script on the build section in my scheme
- Din's suggestion for post action build script on the run section in my scheme
- Excluding arm64
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.
@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. I know not something you're required to fix, but Im going to link them to this issue for posterity.
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.
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 (no code signature found)
- archiving works
- uploading archive fails (found an unexpected Mach-O header)
As for my setup, I have a few static (non-Firebase) 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
@SergeyPetrachkov That did it! My target name was somewhat different from the 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 and need to rollback to Cocoapods for the time being. 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. Pods have to download that insane Spec repo on top of everything else...
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 #6532
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 #6532
Ah, the verbiage made it sound like an attack on the core toolsets (SPM & Cocoapods) rather the handlings of the actual libraries (Firebase + Dependencies). 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..." stupid statement with cocoapods cdn
The workaround suggested by @paulb777 worked for me, using Xcode Version 12.0 (12A7208). Thank you 💯
"Pods have to download that insane Spec repo on top of everything else..." stupid statement with cocoapods cdn
Not that this is an appropriate conversation in this context, but a CDN doesn't change the fact that you're downloading over a gig of data. For most automation setups involving proper configurations (VMs spun up for single one offs with no cache), this is a heavy hit on time setting up a fresh copy of the project and overall overhead on the HDD/SSD among other things and can take around 5-10 minutes per run. It's extraordinarily inefficient and slow especially for variable environments and network speeds. CDN doesn't change that....
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 @paulb777 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.
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 best option is dropping support for Cocoapods as it's an unofficial backend thats dying (dead) or developing a separate fully functional version for Swift packages
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?
Also, did you apply the following fix:
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: 0x72613c21I'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). The error itself just means the path is likely wrong for your config and the frameworks are still being copied into 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
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.
So the result of this is that the frameworks aren't deleted.
Do you have any suggestion about what could be wrong here?
@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? Currently, I believe we're up to the 7.0-spm-beta branch and I believe they started around 6.1.
@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
masterfor our regular releases (to CocoaPods) (release-7.0for example) - We create a new branch off the release branch with the same versioning as the
7.0-spm-betafor example, specifically for the purpose of having thespmandbetain 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
masterafterwards
- 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
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. The only thing is that I had to change it to use PRODUCT_NAME instead of TARGET_NAME
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
.frameworkfiles 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"