App archive fails validation due to invalid plist file on Xcode 15.3

[cameroncooke]

Report

SDK Version

6.13.0

What did you do?

Build for archive and validated on App Store Connect

What did you expect to happen?

Archive to pass validation

What happened instead?

Archive failed validation with the following errors:

Error
Invalid Bundle. The bundle MyApp.app/Frameworks/AppsFlyerLib.framework does not support the minimum OS Version specified in the Info.plist.

Please provide any other relevant information.

This started with the release of Xcode 15.3, this also happens for other 3rd party libraries for which I've already raised tickets and they already have fixes in the works:

https://github.com/google/GoogleAppMeasurement/issues/62 https://github.com/firebase/firebase-ios-sdk/issues/12441

This is currently blocking our ability to release on Xcode Cloud when using the "Latest version" Xcode stratergy.

[MilesV64]

We are also having this issue!

[williamkey123]

I'm having this issue as well; looks like it became an issue with Xcode 15.3. Until AppsFlyer fixes this, you can follow the instructions here to get Xcode cloud to use Xcode 15.2:

https://github.com/firebase/firebase-ios-sdk/issues/12441#issuecomment-1971577317

You can set the Xcode version for Xcode Cloud builds within App Store Connect -> Xcode Cloud -> Manage Workflows -> Workflow -> Xcode version. The default value is "Latest Release" which is currently Xcode 15.3 RC.

Once you do this, you should be able to re-run your workflow and build the app.

(Credit to @nsarno-lucid for this)

[zavsby]

Seems to be a blocker to use Xcode 15.3 for us also. @af-obodovskyi Could you take a look please?

[af-obodovskyi]

We will investigate this issue and come up with the solution, thank you!

[danniss10]

Also seeing this issue!

[vince1393]

Seeing this issue as well!

[slagunes]

Same issue too ☹️

[frangrolemund]

We will investigate this issue and come up with the solution, thank you!

According to the esteemed Eskimo, the minimum os version in the binary doesn't match the Info.plist. I used his instructions and found the following in the latest release of the framework (6.13.1):

• the AppsFlyerLib reports 16.0
• the Info.plist reports 9.0

...

Hope this helps.

[vince1393]

Any updates on this? Somewhat urgent as we have a release upcoming next week that relies on Xcode 15.3 APIs.

[abuljaleel]

Seeing this issue, Xcode 15.3

[alighani-zoral]

Hello, We are also facing this issue

Invalid Bundle. The bundle ******/Frameworks/AppsFlyerLib.framework does not support the minimum OS Version specified in the Info.plist.

We have a critical release pending to be released and we are using xcode 15.3 and unable to upload on Testflight.

Please suggest a fix for this

[zavsby]

Did anyone checked it with latest 6.13.1 version?

[jamesyorke]

Same here!

[vince1393]

Did anyone checked it with latest 6.13.1 version?

I tried 6.13.0 and had the same issue, haven't had a chance to check 6.13.1 yet

[jamesyorke]

Did anyone checked it with latest 6.13.1 version?

Can confirm 6.13.1 also still has the issue.

[vince1393]

Looks like the firebase SDKs have been fixed. Just waiting on this one. @af-obodovskyi do we have an ETA for this?

[guppy-jpf]

yet another me-too ...

[gooson]

+1

[sroyaura]

+1

[bcherry]

+1

[dmallory]

For anyone trying to work around this manually, I can confirm that changing the MinimumOSVersion to 16.0 in the framework's Info.plist resolves this and passes validation. The version in there is 9.0 as noted above, seems very stale.

[af-obodovskyi]

We are aiming to release a fix for this issue and searching for the best aproach. The planned release date for the SDK version v6.13.2 with fix is March 25th.

[frangrolemund]

We are aiming to release a fix for this issue and searching for the best aproach. The planned release date for the SDK version v6.13.2 with fix is March 25th.

Are you aware that this issue in your SDK also prevents uploading to TestFlight for general QA activities? This unfortunately leaves many of us with the choice between two weeks of stalled QA and hacking your code for you so that we can make progress with an unofficial binary we shouldn't ship anyway. If we can take @dmallory at his word, this is an about a 1 minute change to address right now. I'd argue that a component of the best approach is to get your consumers running again. Somehow Google had their entire SDK updated almost instantly.

[vince1393]

This is a serious issue for us, currently blocking important code from being merged that relies on the 15.3 compiler. March 25th is a very long wait time for something that appears to be a one-line fix.

[jamesyorke]

For anyone trying to work around this manually, I can confirm that changing the MinimumOSVersion to 16.0 in the framework's Info.plist resolves this and passes validation. The version in there is 9.0 as noted above, seems very stale.

Just to expand on this for people. I archived the build manually (ignoring my usual process), then after archiving, right click > show in finder. Right click > show package contents > Products > Applications > Right click your app > Show Package Contents > Frameworks > AppFlyer and here is where you do dmallory's MinimumOSVersion change in Info.plist. This should get you through whilst we wait until the 25th March

[dmallory]

For anyone trying to work around this manually, I can confirm that changing the MinimumOSVersion to 16.0 in the framework's Info.plist resolves this and passes validation. The version in there is 9.0 as noted above, seems very stale.

Just to expand on this for people. I archived the build manually (ignoring my usual process), then after archiving, right click > show in finder. Right click > show package contents > Products > Applications > Right click your app > Show Package Contents > Frameworks > AppFlyer and here is where you do dmallory's MinimumOSVersion change in Info.plist. This should get you through whilst we wait until the 25th March

Yes, any method of getting that final Info.plist edited should work. I switched it to a local SPM binary with my own Package.swift pointing to the edited framework since we validate builds frequently through CI, but editing manually or with a script before submit works, or you could probably fork this repo just to point to your own edited framework with it updated.

[cameroncooke]

Tbh while I appreciate all the workarounds provided these solutions are not appropriate where teams have deployment pipelines and I would prefer instead we could upgrade the urgency of the fix needed by the framework vendor. Any team that has any decent quality control will have automatic deployment pipelines and CI and it's not appropriate to have to build on someone's machine and edit app bundles manually.

[danniss10]

Agree with @cameroncooke here! March 25th is a really long timeline for this fix and manually editing bundles is not an appropriate solution. We are blocked from releasing the next version of our app until this fix is released. Is there anyway to increase the urgency on resolving this issue?

[guppy-jpf]

we had the same issue with another analytics framework, repro, (annoyingly, no issue tracker exposed on their github page) ... and were told by their support staff that their engineers consider this an apple issue and that:

• Xcode 15.3 performs a new check that validates that your project version is lesser or equal to "MinimumOSVersion" of all embedded dynamic frameworks. That is obviously wrong and it should be greater or equal.
• google/firebase uses a hack that just set the MinimumOSVersion to 100.0 to pass this new check.

[please disregard any "tone"-related reactions you might have to those responses; i think they are using machine translation to communicate in english]

they also state that:

AppsFlyerFramework like us, acknowledges that there is a problem, but they seem to be in the same position as us, not wanting to use that hack and waiting for Apples fix.

@af-obodovskyi -- from your comment above, it doesn't sound like appsflyer is "waiting for apple's fix" ... can you please comment on what form your fix is expected to take, and if you feel that this is actually working around an apple bug, or if it's just a necessary update to address a stricter (but not necessarily erroneous) set of checks in xcode 15.3?

thanks!

[4refael]

Unless you have to use 15.3, reverting back to Xcode 15.2 was the easiest solution for me.

[georgbachmann]

For anyone trying to work around this manually, I can confirm that changing the MinimumOSVersion to 16.0 in the framework's Info.plist resolves this and passes validation. The version in there is 9.0 as noted above, seems very stale.

Just to expand on this for people. I archived the build manually (ignoring my usual process), then after archiving, right click > show in finder. Right click > show package contents > Products > Applications > Right click your app > Show Package Contents > Frameworks > AppFlyer and here is where you do dmallory's MinimumOSVersion change in Info.plist. This should get you through whilst we wait until the 25th March

Thanks a lot for that tip. I am just wondering cause it's a compiled plist... how do you change the min-version? Do you convert the plist back and forth?

It's really shocking to me that a bug that is preventing users from uploading a build it not important enough to AppsFlyers for a quick fix update... @af-obodovskyi

[af-obodovskyi]

We have precisely investigated this issue with our latest build on Xcode 15.3 and played around with validating and publishing builds to AppStoreConnect with all different kinds of DM options, like embedding raw frameworks to the project, CocoaPods integration, Carthage integration and etc.

As a result of this investigation we have reproduced and confirmed, that the issue exists only on our SPM statically-linked projects (AppsFlyerFramework and AppsFlyerFramework-Strict).

There are multiple ways of solving this bug, which we consider actually, as an Apple bug, because no minimum deployment target restrictions have been specified in the release notes to the Xcode 15.3.

1. The most unwanted solution for us is using minimumOSTarget = 100 this approach may lead to some unpredictable behaviour in the future. We do not know how the system or AppStoreConnect validation service will handle it.
2. The second solution from our side might be updating the minimum deployment target. For this we have to make some analysis before the implementation to understand all the consequences of this decision. We still have a lot of customers who rely on older iOS versions, that is why it is not easy and fast for us to take such decisions.
3. Wait for possible Apple fix.

As a temporary workaround we suggest you to try using AppsFlyerFramework-Dynamic target. After multiple tests we can verify, that this should work and should be able to unblock our customers, so they can proceed with the deployment process. If you try this, please reach out to us and leave your feedback on this solution wether it was successful or not.

[via-guy]

I found other reports of issues with frameworks related to Xcode 15.3. It seems to be a common consensus that this is an Apple bug and it's recommended to downgrade back to Xcode 15.2 in order to fix uploading apps to the App Store.

[georgbachmann]

We have precisely investigated this issue with our latest build on Xcode 15.3 and played around with validating and publishing builds to AppStoreConnect with all different kinds of DM options, like embedding raw frameworks to the project, CocoaPods integration, Carthage integration and etc.

As a result of this investigation we have reproduced and confirmed, that the issue exists only on our SPM statically-linked projects (AppsFlyerFramework and AppsFlyerFramework-Strict).

There are multiple ways of solving this bug, which we consider actually, as an Apple bug, because no minimum deployment target restrictions have been specified in the release notes to the Xcode 15.3.

1. The most unwanted solution for us is using minimumOSTarget = 100 this approach may lead to some unpredictable behaviour in the future. We do not know how the system or AppStoreConnect validation service will handle it.
2. The second solution from our side might be updating the minimum deployment target. For this we have to make some analysis before the implementation to understand all the consequences of this decision. We still have a lot of customers who rely on older iOS versions, that is why it is not easy and fast for us to take such decisions.
3. Wait for possible Apple fix.

As a temporary workaround we suggest you to try using AppsFlyerFramework-Dynamic target. After multiple tests we can verify, that this should work and should be able to unblock our customers, so they can proceed with the deployment process. If you try this, please reach out to us and leave your feedback on this solution wether it was successful or not.

@af-obodovskyi Thanks a lot for your detailed reply! Will downgrade to Xcode 15.2 for the time being.

[frangrolemund]

As a temporary workaround we suggest you to try using AppsFlyerFramework-Dynamic target. After multiple tests we can verify, that this should work and should be able to unblock our customers, so they can proceed with the deployment process. If you try this, please reach out to us and leave your feedback on this solution wether it was successful or not.

Is this supposed to work with SPM in Xcode? It identified the package:

...but then failed to add to the project:

[af-obodovskyi]

@frangrolemund yes, it should, try to clear your SPM cache and try to pull the dependency one more time. Just delete the folder in this repository ~/Library/Caches/org.swift.swiftpm

[frangrolemund]

@frangrolemund yes, it should, try to clear your SPM cache and try to pull the dependency one more time. Just delete the folder in this repository ~/Library/Caches/org.swift.swiftpm

Looks like it was a latent failure in another third-party library and an unhelpful error when it got to yours. I can confirm that swapping to this framework was accepted by App Store Connect using Xcode 15.3. Thanks for the help.

[vince1393]

Have you guys reached out to Apple regarding this issue and filed a bug report through Feedback?

[cameroncooke]

It’s worth pointing out it’s an assumption that it’s an Apple bug. It seems to be App Store Connect rejecting the build not specifically Xcode. It’s not clear if it’s an issue of the build itself or that newer builds are validated to a stricter ruleset by App Store Connect.

It’s of course quite possible it’s a bug so should probably be raised as such. That all said we do need a reasonable solution regardless of fault.

Cameron.

On Thu, 14 Mar 2024 at 17:06, Vince Romani @.***> wrote:

Have you guys reached out to Apple regarding this issue and filed a bug report through Feedback?

— Reply to this email directly, view it on GitHub https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/263#issuecomment-1997934809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEZ6SPF3GNSIN6M7DJDFNLYYHKINAVCNFSM6AAAAABD6IAQ6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXHEZTIOBQHE . You are receiving this because you were mentioned.Message ID: @.***>

[guppy-jpf]

Have you guys reached out to Apple regarding this issue and filed a bug report through Feedback?

i know that google/firebase have filed a bug for a similar issue (FB13657402)

[clara-ia]

@af-obodovskyi Firebase appear to have tracked this down and already pushed a fix here - https://github.com/firebase/firebase-ios-sdk/pull/12414 - with details in this issue case - https://github.com/firebase/firebase-ios-sdk/issues/12441 - hopefully you can do something similar to resolve please AppsFlyer?

[leearmstrong]

AppsFlyer, any progress with your approach? You charge silly amounts for your service and can't get in gear for this!

[leearmstrong]

[vince1393]

We are aiming to release a fix for this issue and searching for the best aproach. The planned release date for the SDK version v6.13.2 with fix is March 25th.

@af-obodovskyi Any ETA? Initially we were told the fix would be in today and im not seeing a release anywhere

[af-obodovskyi]

The issue should be fixed in v6.13.2 for the SPM. Please, refer to this documentation when you update your Swift package. Thank you for your patience and pressious time.

A small update on the Apple issue: As previously mentioned, it is an Apple bug, but it is not related to the minimumOSVersion validation. After our further investigation, we have discovered a possible bug in Xcode 15.3 build system. When compiling a project with a statically linked framework, if we open the app bundle from the archive, we can see a Frameworks folder with a dummy AppsFlyerLib.framework, which is approximately 45 KB in size. For statically linked frameworks, such a folder should not exist. I suspect that when we push the build to the App Store Connect, it tries to validate the .plist of this dummy binary. We will prepare all corresponding information and will issue a ticket to Apple Support.

[leearmstrong]

Why do Firebase not have this issue? They are also a static closed source binary.

[clara-ia]

@leearmstrong they did but they already released a patch for it, see my comment above https://github.com/AppsFlyerSDK/AppsFlyerFramework/issues/263#issuecomment-2000134896

[leearmstrong]

@clara-ia Exactly my point, I think AppsFlyer are missing this!

I am recommending to our team we move away ASAP from AppsFlyer

[cameroncooke]

@clara-ia Exactly my point, I think AppsFlyer are missing this!

I am recommending to our team we move away ASAP from AppsFlyer

This is a powerful point, quite often as engineers we are reluctant to add 3rd libraries like this and have a lot of sway in the decision-making. The way AppsFlyer has dealt with this makes the argument against using the platform even stronger. Blaming Apple publicly and washing their hands of it isn't a good way to support their customers. They had the betas as long as everyone else did and did nothing and are only now talking about reporting it to Apple.

It's unacceptable that a 3rd party library blocks the release of consumer applications like this.

[georgbachmann]

The issue should be fixed in v6.13.2 for the SPM. Please, refer to this documentation when you update your Swift package. Thank you for your patience and pressious time.

Well... @af-obodovskyi this is a big SHOULD :) cause no it's NOT fixed?!? I am on 6.13.2 (AppsFlyerLib-Static). I am still getting the same error! Do we now have to wait an other two weeks so it fit's into your release cycle to really fix it? I really don't understand it... Why???? Would it have been so hard to test that yourself before releasing it?

Btw. I also just asked your marketing-guy to look for an alternative to AppsFlyer... it is really not acceptable that we cannot use the latest build tools as every single other package we use solved this issue within a day...