AppLovinSDK 12.4.1 changed from a static to dynamic library

Unity Services
,
1

I have encountered the issue as described in the github thread below after updating Iron Source to v8.0.0 and the ISAppLovinAdapter to 12.4.1.

Contributors to the AppLovinSDK suggest that they have resolved this for those who use it directly and that a fix for those who use the IronSource/LevelPlay adapter would need to be made by the LevelPlay team.

Is this a known issue and if so, is there a current workaround or plan in place to release a new version of the ISAppLovinAdapter?

Version 12.4.1 of the AppLovinSDK contains privacy settings that will be required for iOS submissions starting on May 1st, making this an urgent issue.

2

Bumping this to say that I’m having the same issue. Would like to know if there’s a workaround and if this has been acknowledged as something that will be fixed. Removing AppLovin from the funnel is the only immediate solution on my end.

3

@bmorgan-ksg I will mention that you should be able to embed the AppLovinSDK.xcframework in your XCode project to get it to run without having the issue. That should be a valid solution for any dynamic framework you may have in your project as well, if you get errors for others (I had 3). If you’re fine with a hardcoded solution in the mid term, you could then have a postbuild script that embeds these frameworks for you.

But ideally a more flexible and permanent solution can be found for managing the mix of static and dynamic frameworks.

4

@conumental , thanks for the suggestion.

I went down this road and have found that our own build pipeline limits our options. We perform the Unity portion of iOS builds on a PC, transfer the resulting XCode project to a Mac and then run the pod install before opening and compiling the .xcodeworkspace. I believe that adding the AppLovinSDK.xcframework via a PostProcessBuild method ultimately requires the pod install to occur before Unity exits the build process (and therefore has to be run from a Mac).

For now, we will remove AppLovin as a mediation network while I evaluate CLI libraries that will allow us to modify the XCode project settings in between the pod install and .xcodeworkspace being opened.

5

We are also having this problem. We have a temporary workaround with a nasty hardcoded path to add the AppLovinSDK to the XCode project manually. This is our post process script that we have put in the Editor folder, in case it helps anyone.

    public class AddAppLovinPostBuild
    {
        [PostProcessBuild]
        public static void OnPostprocessBuild(BuildTarget target, string pathToBuiltProject)
        {
            if (target == BuildTarget.iOS)
            {
                string projPath = PBXProject.GetPBXProjectPath(pathToBuiltProject);
                PBXProject proj = new();
                proj.ReadFromFile(projPath);

                string mainTargetGuid = proj.GetUnityMainTargetGuid();

                string xcFrameworkPath = "Pods/AppLovinSDK/applovin-ios-sdk-12.4.2/AppLovinSDK.xcframework";
                string fileGuid = proj.AddFile(xcFrameworkPath, xcFrameworkPath);
                proj.AddFileToEmbedFrameworks(mainTargetGuid, fileGuid);

                proj.SetBuildProperty(mainTargetGuid, "LD_RUNPATH_SEARCH_PATHS", "$(inherited) @executable_path/Frameworks");

                proj.WriteToFile(projPath);
            }
        }
    }
5 Likes
6

As you may know, AppLovin released a non-static framework, SDK 12.4.1, to comply with Apple’s privacy manifest.
This may cause a run time crash with “Library not loaded: @rpath/AppLovinSDK.framework/AppLovinSDK” error if the you use:

  • LP Unity Plugin
  • External Dependency Manager for Unity v1.2.170 or later (NOT the “Mobile Dependency Resolver” LP installs)
  • AppLovin iOS SDK 12.4.1

Workaround:

  • Modify use_frameworks! :linkage => :static line in Podfile to just use_frameworks! or Uncheck “Link frameworks statically” in EDM setting,
  • Add AppLovinSDK.framework to “Build Phases” > “Embed Frameworks” (by drag&drop or pressing “+” button on the panel)
3 Likes
7

Thanks for sharing this saved some time.

For our project the “LD_RUNPATH_SEARCH_PATHS” line was not required.
I also wrote a quick search for the AppLovinSDK.xcframework directory so it’s not limited to just that version.

Shame that there still is no fix for this as initially we just removed the AppLovin mediation which of course works a treat :slight_smile:

1 Like
8

For anyone looking for a fix @yunanhou answer is still the best. We still have the same issue with Applovin SDK v13.0.1 …

1 Like