Closed Panajev closed 3 years ago
When using 6.0.8 via SPM we got an error on run about a missing plist. Using 6.1.0 via SPM produces a compile time warning as above.
I did some poking around xcframework embedded into this package, and apparently codesign doesn't like when there's Versions dir in the framework bundle. Code signing works file if you move Headers and AppsFlyerLib into the bundle root and delete Versions dir:
➜ AppsFlyerLib.framework ls -1
AppsFlyerLib
Headers/
Info.plist
Modules/
AppsFlyerLib.framework is copied twice into our apps.
PlugIns/AppsFlyerLib.framework is incorrect Frameworks/AppsFlyerLib.framework is correct
So we get this error: PlugIns/AppsFlyerLib.framework: bundle format unrecognized, invalid, or unsuitable Command CodeSign failed with a nonzero exit code
This happens in our "Embed App Extensions" build phase.
@s-hintz is it happening with the 6.1.1 release too? @andr-ggn @af-fess is this reproducible on your end too?
hey @Panajev we are checking this. Thank you
Thank you :)
Sent from my iPhone
On 18 Nov 2020, at 18:19, Maxim Shoustin notifications@github.com wrote:
hey @Panajev we are checking this. Thank you
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
I checked 6.1.0 and 6.1.1 and I could not get it to work. I even tried to delete the plugin with a script, but since it I copied and code signed in the same build phase, I was not able to delete it in between.
rm -r $TARGET_BUILD_DIR/$PLUGINS_FOLDER_PATH/AppsFlyerLib.framework
We are using several Swift Packages. AppsFlyer is the only one with problems.
We had to revert our changes and use the 6.1.0 with Carthage now.
For those having issues with codesign when installing via SPM, I made a fork that makes it happy until upstream is fixed. Use the master branch, not versioned tags: https://github.com/akolov/AppsFlyerFramework.git Please note it doesn't fix extra Frameworks and Plugins embedding, just codesign fail.
@s-hintz Duplicated frameworks issue is not an AppsFlyer issue rather the SPM issue. The same issue happens with Firebase and other frameworks that use binaryTarget
in the SPM Package.swift
.
To make sure that your script works, you need to make sure to execute it as post-action in your scheme instead of build phase. (See linked Firebase issue for more info)
@ivanlisovyi this doesn't solve the issue when AppsFlyer is embedded within another Framework. Code signing happens after post-action scripts are run.
@akolov Yes, it doesn't. It only solves the framework duplication issue which AppsFlyers won't be able to solve anyways unlike the code signing.
Really appreciate to:
@akolov
@ivanlisovyi
We updated master branch to have flatten MacCatalyst framework. So it should solve code-signing issue
. Next version of SDK will contain flatten xcframework.
@andr-ggn I am still getting a signing issue with version 6.1.1. I am using Swift Package Manager and have a custom package, let say CusomTracker, that brings the AppsFlyer dependency, and my final app uses CustomTracker but fails at the last step when about to sign AppsFlyerLib.framework. This may be an important note : the app is iOS only, no iPad no Mac Catalyst.
I would surely appreciate a solution.
In fact @andr-ggn the issue is actually obvious. It seems you guys changed delivering a dynamic framework for a static framework. Maybe xcframework can carry a static framework. But it seems that Swift Package Manager expect a xcframework to carry either a static library or a dynamic framework. It is failing because it's trying to copy & sign a static framework, which doesn't make sense.
And the reason I am saying that you are delivering a static framework is only because of its structure : with "Versions", Current/A. I checked on previous versions and you used to have a dynamic framework for iOS
@quentinfasquel I believe the fix was not included in 6.1.1 yet, try switching SPM to use the master branch instead.
@akolov indeed ! You should tag that immediately ;)
@andr-ggn / @akolov it was too quick to be right, two major issues.
TLDR: 1- If you intend to distribue it as a framework, it's gonna have to be dynamic, if you just wanna ship a binary with SPM, it has to be through a xcframework, which can only support a static library or a dynamic framework. No damn f*ing static framework. 2- tag the fix quickly.
First, not having the tag and branching on master forces every intermediate swift package to be brought through branch instead of tag. (I had CustomTracker with tag x.x.x bringing AppsFlyer on branch master, then on revision... SPM cannot resolve a version if it depends on an unversioned dependency)
Second, and most critical. I just tried archiving, it works. But exporting the archive results in the following issue : Error Domain=DVTMachOErrorDomain Code=0 "Found an unexpected Mach-O header code: ...
The issue you guys previously fixed, I am guessing, was : "flatten the framework so that Xcode can sign it, or so that SPM stops complaining". The truth is, it should not have tried to sign it in the first place.
What's happening now is that Xcode/SPM is being tricked trying to copy a dynamic framework, but in the end it's a static framework. The concept of static framework doesn't really exist, especially not in the xcframework world. It used to be a hack until iOS apps could support actual dynamic frameworks. The issue appears now later on in the distribution flow, exportArchive
complains because it doesn't know what to do with an ar archive
(static).
Someone please tell me if I'm wrong in any of this, and please let me know if you've got a fix.
Found an unexpected Mach-O header code
is most likely because frameworks are copied into other embedded frameworks and plugins as per this issue: https://github.com/firebase/firebase-ios-sdk/issues/6472#issuecomment-694449182
I have AppsFlyer currently integrated in the production app in the AppStore via current master branch and it works fine.
@quentinfasquel yes, I'm using it via SPM.
@akolov are you using Xcode 12.2 ?
@quentinfasquel yes, Version 12.2 (12B45b).
@akolov I really don't get it then. Brand new project, add AppsFlyerLib as a SPM, branch master as you pointed out earlier in the day. Archive, distribute, export as Ad-Hoc... and Xcode shows this. In logs, it is just the Mach-O issue
and indeed... the .app contains the framework embedded, and the framework is a static archive. So I don't how you get that to work properly.
@quentinfasquel I'm linking all SPM packages into an extra framework that's shared among several targets in my project. Additionally, I have a cleanup build phase, that removes anything unexpected in embedded Frameworks and Plugins. This is not just AppsFlyer issue, but Firebase, Stripe and many others are affected as well.
@akolov got it, in the mean time I have a different solution that doesn't require any intermediate custom framework nor any cleanup. Just assuming that a static framework isn't something that exist.
Any update on getting master tagged? I've not actually tried it but I assume it resolved the codesigning issue with Xcode 12.2 - we can't use master as it goes against how SPM using versions as stable releases works.
Check the SPM proposal that states this:
While this feature [specifying branches] is useful during development, a package’s dependencies should be updated to point at versions instead of branches before that package is tagged for release. This is because a released package should provide a stable specification of its dependencies, and not break when a branch changes over time. To enforce this, it is an error if a package referenced by a version-based dependency specifies a branch in any of its dependencies.
We really need an update on this one. So unprofessional by AppsFlyer, it's the only remaining framework we have still to add using Pods 🤦🤦🤦
Unfortunately, we cannot just add/remove releases/tags. Each tag is a new release. There is a process in which not only development is involved.
6.1.2 with tag
Hello @andr-ggn I have set the version of the framework to 6.1.2 and I am still getting the Found an unexpected Mach-O header code: 0x72613c21 error :/.
Same issue on v 6.1.2 using SPM
@Panajev, @ilkerc This is another SPM issue. Did you try https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/142 ?
@andr-ggn Thanks for the suggestion, was a fix for iPhone target but not for catalyst. Build failed with the following error message;
/Users/ilker/Library/Developer/Xcode/DerivedData/hello-hgbirkcajlqormcajetinxjyhjnp/Build/Products/Debug - Staging-maccatalyst/Hello.app/Contents/PlugIns/AppsFlyerLib.framework/Versions/A: bundle format unrecognized, invalid, or unsuitable
Command CodeSign failed with a nonzero exit code
I have also added the Contents
folders, same error as above.
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Frameworks/AppsFlyerLib.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Plugins/AppsFlyerLib.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Contents/Frameworks/AppsFlyerLib.framework"
rm -rf "${TARGET_BUILD_DIR}/${TARGET_NAME}.app/Contents/Plugins/AppsFlyerLib.framework"
Thanks @andr-ggn 6.1.2 and that approach sorted us out!
@ilkerc You use not a 6.1.2 version
@andr-ggn I can verify that SPM fetches version 6.1.2.
I can build the project for iPhone devices and simulators but fails on mac target.
I have created a sandbox project here: https://github.com/ilkerc/appsflyer-spm-sandbox
@ilkerc
I was able to compile for My Mac
Steps:
echo "Apple"
Apple
to AAA AAA
Can you try these steps and back here?
@andr-ggn Interesting approach :) Didn't work on my case. Only difference is the Xcode version: 12.2 (12B45b)
Changes: https://github.com/ilkerc/appsflyer-spm-sandbox/commit/63bbf84a936bdbb471787d59b24213acc429281b
@ilkerc
@main
to @UIApplicationMain
echo "AAA AAA"
to echo "AAA AAA1"
try to change Pre-Action few times..
Just tried on your project
@andr-ggn That didn't work on my case too, but discovered an interesting solution;
Compile with AppsFlyerLib on frameworks.
Sign error
Remove AppsflyerLib from frameworks
Successful sign
As long as you don't clean build folder, signs successfully. I have purged all pre-post run scripts too. Also, I just tried pod 'AppsFlyerFramework-MacCatalyst'. This too fails with the same error, and I can also solve it with this weird solution.
Obviously this won't work if you try to archive for a release, I'll try to remove frameworks and continue signing manually on terminal.
If apple does not fix the static framework for .xcframework in the near future, we will have to switch to dynamic framework
We are still unsuccessful with the .ipa export (archiving works) when we use SPM (Xcode 12.3, export only for iPhone & iPad). We just replaced the previously linked static framework with the SPM, and now we are getting an IPA processing failed error. We tried to add that post-build action. Unsuccessfull. AppsFlyerLib.framework is present only on the root of the *.app package (not in Frameworks/Plugins folders). This should be ok, right?
AppsFlyerLib.framework is present only on the root of the *.app package (not in Frameworks/Plugins folders). This should be ok, right?
@alesp56 nope. It doesn't matter where AppsFlyerLib.framework is in the .app package, the app is already linked with it since its a static framework. It must be removed from the .app package. You should do so through a script build phase. This is an Xcode + SPM + static binaries issue... SPM thinks every xcframework contains a dynamic framework and copy it. I'll try and work a generic script that could be used to remove every static binary from .app package, if possible.
I do have a problem with 6.1.2 version:
Once I do import AppsFlyerLib
, the project fails to build with the following error:
ignoring file /Users/sergeypetrachkov/Library/Developer/Xcode/DerivedData/JuiceFit-etzvubmelzhgcpdhdlxyoibjzllu/Build/Products/Debug-iphonesimulator/AppsFlyerLib.framework/AppsFlyerLib, missing required architecture arm64 in file /Users/sergeypetrachkov/Library/Developer/Xcode/DerivedData/JuiceFit-etzvubmelzhgcpdhdlxyoibjzllu/Build/Products/Debug-iphonesimulator/AppsFlyerLib.framework/AppsFlyerLib (2 slices) Undefined symbols for architecture arm64: "_OBJCCLASS$_AppsFlyerLib", referenced from: objc-class-ref in AppDelegate.o ld: symbol(s) not found for architecture arm64
building on M1 and Xcode Version 12.3 (12C33)
@SergeyPetrachkov I was gonna say, you are on M1.
Not sure there was a tagged version available with SPM. But the MacCatalyst xcframework contains all necessary architectures. Try the same revision ?
.package(name: "AppsFlyerLib", url: "https://github.com/AppsFlyerSDK/AppsFlyerFramework.git", .revision("b233d5611aad73f014f07f0440300e7c4db1adb4")),
@quentinfasquel I'll try in a few hours and will report back to you.
@quentinfasquel nope, still fails to compile
this is what I get in derived data
Any update? It's appalling that we don't have a fix yet
Ended up doing the following on my M1 Mac:
#if !targetEnvironment(simulator) #endif
And only then it all works and I'm able to build the app for the AppStore.
Report
SDK Version
6.1.0 - 6.1.2 (former fails to codesign, latter fails to export)
What did you do?
Replaced the AppsFlyer CocoaPod pod with the SPM version
What did you expect to happen?
Application to compile successfully
What happened instead?
App fails to build when linking to AppsFlyer 6.1.0 code signing is invoked for it and fails
Please provide any other relevant information.
Hello, we understand the SPM version suggested for AppsFlyer is 6.0.8, but does it mean that it is SPM supported from that version onwards or just 6.0.8 and not 6.1.0? Can documentation be improved to reflect this?