AppsFlyerSDK / AppsFlyerFramework

AppsFlyer Apple SDK
https://support.appsflyer.com/hc/en-us/articles/207032066-AppsFlyer-SDK-Integration-iOS
Other
166 stars 89 forks source link

[Xcode 12][SwiftPM] App fails to build when linking to AppsFlyer 6.1.0 or fails to Export for AppsFlyer 6.1.2 #143

Closed Panajev closed 3 years ago

Panajev commented 3 years ago

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?

alextudge commented 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.

akolov commented 3 years ago

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/
s-hintz commented 3 years ago

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.

Panajev commented 3 years ago

@s-hintz is it happening with the 6.1.1 release too? @andr-ggn @af-fess is this reproducible on your end too?

af-fess commented 3 years ago

hey @Panajev we are checking this. Thank you

Panajev commented 3 years ago

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.

s-hintz commented 3 years ago

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.

!/bin/sh

rm -r $TARGET_BUILD_DIR/$PLUGINS_FOLDER_PATH/AppsFlyerLib.framework

s-hintz commented 3 years ago

We are using several Swift Packages. AppsFlyer is the only one with problems.

s-hintz commented 3 years ago

We had to revert our changes and use the 6.1.0 with Carthage now.

akolov commented 3 years ago

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.

ivanlisovyi commented 3 years ago

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

akolov commented 3 years ago

@ivanlisovyi this doesn't solve the issue when AppsFlyer is embedded within another Framework. Code signing happens after post-action scripts are run.

ivanlisovyi commented 3 years ago

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

andr-ggn commented 3 years ago

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.

quentinfasquel commented 3 years ago

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

quentinfasquel commented 3 years ago

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

akolov commented 3 years ago

@quentinfasquel I believe the fix was not included in 6.1.1 yet, try switching SPM to use the master branch instead.

quentinfasquel commented 3 years ago

@akolov indeed ! You should tag that immediately ;)

quentinfasquel commented 3 years ago

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

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.

akolov commented 3 years ago

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.

akolov commented 3 years ago

@quentinfasquel yes, I'm using it via SPM.

quentinfasquel commented 3 years ago

@akolov are you using Xcode 12.2 ?

akolov commented 3 years ago

@quentinfasquel yes, Version 12.2 (12B45b).

quentinfasquel commented 3 years ago

@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

Screenshot 2020-11-25 at 17 55 08

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.

akolov commented 3 years ago

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

quentinfasquel commented 3 years ago

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

joshuapoq commented 3 years ago

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.

valerio-bettini commented 3 years ago

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 🤦🤦🤦

andr-ggn commented 3 years ago

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

Panajev commented 3 years ago

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 :/.

ilkerc commented 3 years ago

Same issue on v 6.1.2 using SPM

andr-ggn commented 3 years ago

@Panajev, @ilkerc This is another SPM issue. Did you try https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/142 ?

ilkerc commented 3 years ago

@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"
Panajev commented 3 years ago

Thanks @andr-ggn 6.1.2 and that approach sorted us out!

andr-ggn commented 3 years ago

@ilkerc You use not a 6.1.2 version

ilkerc commented 3 years ago

@andr-ggn I can verify that SPM fetches version 6.1.2.

Screen Shot 2020-12-08 at 15 24 44

I can build the project for iPhone devices and simulators but fails on mac target.

Image 2020-12-08 at 3 23 28 PM

I have created a sandbox project here: https://github.com/ilkerc/appsflyer-spm-sandbox

andr-ggn commented 3 years ago

@ilkerc I was able to compile for My Mac Steps:


Can you try these steps and back here?

ilkerc commented 3 years ago

@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

andr-ggn commented 3 years ago

@ilkerc

try to change Pre-Action few times..

Just tried on your project

ilkerc commented 3 years ago

@andr-ggn That didn't work on my case too, but discovered an interesting solution;

  1. Compile with AppsFlyerLib on frameworks.

    Screen Shot 2020-12-08 at 17 30 52
  2. Sign error

  3. Remove AppsflyerLib from frameworks

    Screen Shot 2020-12-08 at 17 23 20
  4. 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.

andr-ggn commented 3 years ago

If apple does not fix the static framework for .xcframework in the near future, we will have to switch to dynamic framework

alesp56 commented 3 years ago

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?

quentinfasquel commented 3 years ago

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.

SergeyPetrachkov commented 3 years ago

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)

quentinfasquel commented 3 years ago

@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")),

SergeyPetrachkov commented 3 years ago

@quentinfasquel I'll try in a few hours and will report back to you.

SergeyPetrachkov commented 3 years ago

@quentinfasquel nope, still fails to compile

SergeyPetrachkov commented 3 years ago
Screenshot 2020-12-17 at 13 14 38

this is what I get in derived data

valerio-bettini commented 3 years ago

Any update? It's appalling that we don't have a fix yet

SergeyPetrachkov commented 3 years ago

Ended up doing the following on my M1 Mac:

And only then it all works and I'm able to build the app for the AppStore.