The bundle at … contains disallowed file 'Frameworks'

Question

I'm trying to deploy a .dylib library wrapped in a framework, and I'm experiencing the following issue: 'ERROR ITMS-90206: "Invalid Bundle. The bundle at X.app/Frameworks/PoemsRecommender.framework' contains disallowed file 'Frameworks'."

It looks like there's a framework nested in a framework:

Things I tried:

• Remove "Frameworks" folder in the "Run Script" phase (it actually helps with submission but the app crashes because it can't find the dylib which is in the Frameworks folder)
• Change "Frameworks" to "Shared Frameworks" in "Embed Frameworks"
• Disable "Always Embed Swift.."

Answer 1

Reason

The error message indicates that you are trying to package a framework that has its own frameworks embedded inside.

This is not currently supported through traditional framework embedding

The fix is, unfortunately, to link all frameworks separately in your main target.

How do I know?

When you see this error X.app/Frameworks/PoemsRecommender.framework contains disallowed file 'Frameworks'."

Apple is explicitly saying that a framework that embeds a "Frameworks" folder is disallowed. There is a great discussion here that goes into a lot more detail.

Recommended Solution

Package your frameworks separately and link them all manually. Apple has good guidelines here

Not Recommended but will achieve your goal

If you must use a single framework, there is quite a bit of work involved. Effectively you want to create an Umbrella framework that will mask all underlying frameworks. This can get messy if you ever decide to link those sub-frameworks in other parts of your application. Since your question is vague on the details I cannot ascertain if this will affect you.

There are a number of resources that can guide you through the laborious process.

Effectively the steps involve creating an aggregate target that can use a build script to bind all your frameworks at runtime.

I have done this in the past and we ran into lots of issues on the way and I would not recommend this approach. In the past we had a white-labelled SDK that consisted of a number of internal frameworks that were binded by an aggregate target. More often than not it was difficult to maintain and difficult to understand by new team members. Eventually we just migrated to multiple frameworks.

I think Apple has their own tooling to support how they do it but, sadly, it is not available to us peasants.