appex contains disallowed file 'Frameworks' (cocoapods 0.39.0.beta.4)

[mikehouse]

The iTunes Connect gave this error message to me when I wanted to upload an ipa file to.
Several days I used to have a trouble with that. I found out that it was caused by cocoapods 0.39.0.beta.4. To be more accurate this problem appears when I'm adding some dependencies to a watch extension target. That is the empty folder 'Frameworks' is being created into the appex directory which causes the current issue. Downgrade to 0.38.2 have solved this problem though.

The same behavior is for such combinations
Xcode 6 + watch os 1
Xcode 7 + watch os 1
Xcode 7 + watch os 2

Thanks.

[bassrock]

Experiencing the same issue. Extension targets are containing the Frameworks folder when they should not.

[segiddins]

I believe we have other reports of this happening, I believe it's being caused by the embed frameworks script

[segiddins]

Can you see if #4261 fixes things for you?

[bassrock]

@segiddins just tried it same results.

[segiddins]

hm strange, that PR makes it so that the Frameworks directory should never be empty

[bassrock]

The .apex's (extensions) should not contain the Frameworks period as they use the frameworks from the main app. Thats the main issue.

[mikehouse]

Have just tried, the same(
This as I think causes the problem

local destination="${CONFIGURATION_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"

[bassrock]

A Today or a Watch Extension 1.0 should technically merge their frameworks to the main host app, but only link against the ones they require.

[segiddins]

In that case, it sounds like the framework folders path is actually what's wrong here?

[bassrock]

I think so, right now the following occurs when archiving:

.xcarchive/Products/Applications/Acme.app/PlugIns/TodayExtension.appex/Frameworks/ (all the used frameworks here)

but the /Frameworks/(frameworks here) should not exist in the .appex.

I think the scripts need to be different for extensions and instead copy into the .xcarchive/Products/Applications/Acme.app/Frameworks/ directory

[neonichu]

I don't think this can be solved inside the embed frameworks script, as the application extension is build separately first and then later copied into the application bundle by Xcode. We need to merge the dependencies of application extension targets into the ones of the host app at an earlier stage.

[rocxteady]

I got this error on 0.39

[mikehouse]

I think it could be fixed by bash script.
Try to create the script there 'watch extension target -> Build Phases' then click on '+' and select "New Run Script Phase", the run script should go after all others. Insert there

cd "${CONFIGURATION_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/"
if [[ -d "Frameworks" ]]; then 
    rm -fr Frameworks
fi

after clean a project and try to create an archive once again.

[romanr]

@mikehouse Thank you for the script! That's the only thing that worked for me out of many other solutions.
I wonder why this don't work in 0.39.0 even if it looks like it was referenced in some commit that went in 0.39.
Was this caused by use_frameworks! ? I had use_frameworks in my Podfile when I tried some pod and later removed use_frameworks. Perhaps it leaves Frameworks directory somewhere in the extension target.

[raylillywhite]

I was receiving the following error while trying to upload to the app store:
ERROR ITMS-90206: "Invalid Bundle. The bundle at 'Spruce.app/Frameworks/SpruceCore.framework' contains disallowed file 'Frameworks'."to address this issue."

The framework mentioned there is a dynamically linked framework that's shared between two apps. The framework and the two apps are all in the same workspace, each with separate Xcode projects, but sharing a Podfile. And the frameworks that were contained at Spruce.app/Frameworks/SpruceCore.framework/Frameworks/* were the standard Swift frameworks.

I fixed this by overriding the Embedded Content Contains Swift Code build setting on my framework target. It was previously being set to YES by Pods.*.xcconfig and I overrode it to set it to NO.

[brianmichel]

Hey @segiddins is there anywhere I can read about the nuance here that may be required? I'd be interested in working on this, but it seems like a hard and fast rule that we just shouldn't have the Frameworks directory inside of AppEx targets, right?

I'd love to take a crack at this, but it sounds like it's a bit more nuanced, can you help me understand?

[segiddins]

Nope, that's about it. The tough part is that, at appex build time, there doesn't appear to be any way to know where those frameworks actually should be copied, i.e. We don't have the containing apps frameworks directory available.

[csotiriou]

I have an iOS application, with a Today Extension + an shared embedded framework, for sharing code between the two. I have found that when archiving, the embedded framework contains a folder named "Frameworks" that includes many frameworks (including swift standard libraries!) and also the today extension does the same. These are the folders that mess with the App Store submission.

I have tried using mikehouse's approach by putting his script in both the extension's and the framework's build phases, but after archiving those two folders, the "Framework" folders are still there, so the problem persists. The interesting thing is that this happens only with Cocoapods 0.39. I solved it manually by deleting all "Frameworks" folders of any bundle, except the one of the root application.

@segiddins , why do you need the containing app's directory available during the appex build? Can't you just remove the "Frameworks" folder from each appex and embedded framework build before it gets contained to the final app? Or the "Frameworks" folders are being copied AFTER they are embedded into the main application?

In any case, is seems logical to make a post-install script that traverses the "Plugins" and "Frameworks" directory of the main app, and then delete any "Frameworks" directory contained in any bundle that exists in those folders. Could this be the solution?

[bassrock]

@csotiriou This is due to the fact that one could use a Watch Specific or Today Specific Framework in their Podfile for the Today View Target but not add it to the Main App Target. And extensions need to embed the frameworks into their main app targets. So while deleting the folders can work, the real solution is to embed the frameworks from the extension target into the main target while still linking the right frameworks at build.

[segiddins]

I made some progress on this in the seg-no-embed-in-extensions branch

[orta]

I just gave this a shot on emergence on this branch and got:

NoMethodError - undefined method `embedded_targets' for <Pod::AggregateTarget name=Pods >:Pod::AggregateTarget
/Users/orta/.rvm/gems/ruby-2.1.3/bundler/gems/CocoaPods-bd1b036e6cc6/lib/cocoapods/installer/analyzer.rb:684:in `block (2 levels) in verify_extension_bs'
/Users/orta/.rvm/gems/ruby-2.1.3/bundler/gems/CocoaPods-bd1b036e6cc6/lib/cocoapods/installer/analyzer.rb:674:in `each'
/Users/orta/.rvm/gems/ruby-2.1.3/bundler/gems/CocoaPods-bd1b036e6cc6/lib/cocoapods/installer/analyzer.rb:674:in `block in verify_extension_bs'
/Users/orta/.rvm/gems/ruby-2.1.3/bundler/gems/CocoaPods-bd1b036e6cc6/lib/cocoapods/installer/analyzer.rb:672:in `each'
/Users/orta/.rvm/gems/ruby-2.1.3/bundler/gems/CocoaPods-bd1b036e6cc6/lib/cocoapods/installer/analyzer.rb:672:in `verify_extension_bs'
/Users/orta/.rvm/gems/ruby-2.1.3/bundler/gems/CocoaPods-bd1b036e6cc6/lib/cocoapods/installer/analyzer.rb:74:in `analyze'

[segiddins]

@orta it's by no means runnable, I just said its progress

[enricenrich]

With the final release of 0.39.0 this error still happens. I fixed it with the suggestion by @mikehouse that I found here: http://stackoverflow.com/a/33092433

[Spacelapp]

Same problem for me with 0.39.0...

[segiddins]

Yes, we know it's an issue.

[seamane]

Thank you @mikehouse for the script! I have been working on this submitting issue for the past day, but nothing has worked until now. :) thanks again!

PS - I am using 0.39.0

[benasher44]

It looks like you're installing frameworks in both the watch app and watch extension targets. You only need to install them in the watch extension target. Try removing the "watch" target from your Podfile.

[antonioreyna]

OK let me try, I am doing a test right now, i read somewhere that i have to remove the embed swift code on the share extension and apparently its uploading now. If that works, why its on YES that option if its not needed? is that some xcode stuff or is part of the cocoapods configurations when it created the workspace?

[antonioreyna]

@benasher44 now that i removed the target 'watch' i keep getting this on archive:

diff: /../Podfile.lock: No such file or directory
diff: /Manifest.lock: No such file or directory
error: The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

and cant continue

[antonioreyna]

Looks like when i removed the target for the watch app the projects keept a phase for that target, to run the script Pods-watch/Pods-watch-resources.sh but i cant find that phase?

My apple watch app has no Build Phases tab

[benasher44]

@antonioreyna maybe try pod deintegrateing and then pod installing again. Without a sample project, it's hard to debug. If it's not much trouble, you might want to re-create your watch target.

[antonioreyna]

yeah maybe i will try to remove the target and then create it again, its empty by now :D, i already used the deintegrate and same result i ended up keeping the target on the pods but i will remove it to see the result @benasher44

[Urkman]

I'm currently on Xcode 8 Beta 6 and Cocoapos 1.1.0-beta1 and now I get this error :(
Nothing inside this thread helps :(

Any more ideas on this?

[marco318]

@Urkman I've been working on this error on last week, and it's so difficult to get out from this one.
Finally I made it after tons of trial, but it's not clear what was the key.
From my git log, I did these things below,

• update cocoapods to 1.1.0-beta1
• pod deintegrate & pod install
• Add run script by @benasher44 (remove 'Frameworks' from path)
• set 'Embedded Content Contains Swift' to No at Buid Settings of extension target, ($inherited) at others (I'm using Swift only, so I'm not sure with necessity of this one)
• remove run script named '[CP] Embed Pods Frameworks' at build phase
• Clear and re-Build

I'm not sure these will work, because I didn't do more test on last commit(with bug).
After having confidence, I will write about it again.

I agree with updating Cocoapods is not enough for fixing this error.
Is there anyone who fix this problem with only updating Cocoapods?

[Urkman]

@marco318: Thanks for that, but it does not help at all :(

[benasher44]

Upgrading CocoaPods worked for me. There are 2 root causes of this issue. Either you have an embed frameworks build phase in one of your extension targets, which will create the disallowed Frameworks folder when the script runs (not sure why App Store calls it a file), or your target is overriding a build setting that is causing Xcode to embed the Swift libraries/frameworks in your extension (similarly not allowed). You could also have both of these. CocoaPods in 1.1.0.beta.1 tries to fix both of these things, but there are ways that the project file can get into weird states and have duplicates of these build phases or other incorrect build settings, which makes it harder for CocoaPods to help you shake this issue in your project. If you provide a sample project, I'm happy to add more to CocoaPods to either have better warnings, errors, or otherwise attempt to fix this in ways that me and others have yet to report or provide reproducible examples for.

[benasher44]

You can also tell if this issue is going to happen to you before you submit to the App Store by inspecting the BUILT_PRODUCTS_DIR in your projects derived data folder after doing a build and checking your extension bundles for these framework folders. If you find them after a build, then your App will likely get rejected, and you should continue debugging.

[Urkman]

Strange thing...

Today I got a message from Xcode to "Update my project settings.".
After this Upload to App Store worked :)

[llater]

I am having continued issues. I receive warnings when I install and update my pods that the targets override the build settings defined in 'Pods/Target Support Files/Pods-xxx.release.xcconfig. Those .xcconfig files appear in the Pods folder of my app project (the project in the same .xcworkspace as the Pods project). After I set the build settings and build phases as prescribed with CocoaPods 1.1.0.beta.1, my Pods_xxx.framework still appears in red under the xxx(project)/Frameworks folder.

I believe the problem to be in the Pods-xxx.release.xcconfig file that appears in both projects; it specifies:

PODS_BUILD_DIR = $BUILD_DIR
PODS_CONFIGURATION_BUILD_DIR = $PODS_BUILD_DIR/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_ROOT = ${SRCROOT}/PODS

Does ${SRCROOT} refer to the Pods xcproject in the xcworkspace, even when the .xcconfig file is in my app's xcproject? Even though they share the xcworkspace, I fear that the build configuration (ie. setting the build settings and phases) refers to the wrong project (both have a folder named Pods), and thus I can't get my frameworks and libraries into my app's xcproject.

Any suggestions would be appreciated; thanks!

[benasher44]

@lelandlater which build settings is it complaining about specifically?

[llater]

@benasher44 The app target overrides 'EMBEDDED_CONTENT_CONTAINS_SWIFT' the build setting, while the appTests target overrides 'ALWAYS_EMBED_SWIFT_STANDARD_LIBRARY.' I have attempted to resolve these by adding $(inherited) in all relevant build settings, as well as removing the [CP] Embed Pods Frameworks in the Build Phases.

Xcode shows me a buildtime warning: "Validate Project Settings - Update to recommended settings (Pods.xcodeproj)." The changes it recommends are on target "Pods-xxx," and wants to "update embed Swift standard libraries setting" by setting "Always Embed Swift Standard Libraries" to "YES".

[benasher44]

If you want to stop seeing the pod install warnings, you should remove instances where you override those settings. If you upgrade to the latest 1.1.0 release, it uses flags updated for Xcode 8

[jshier]

@benasher44 Those are recommended settings from Xcode, so it seems like CocoaPods needs to be the ones to make changes here. Otherwise users will constantly see the "Upgrade to recommended settings" in Xcode.

[benasher44]

If you update to the latest CocoaPods 1.1.0 release, that issue is fixed

[jshier]

rc.2 still produces the warning about the setting if your project has it set and Xcode still complains if you don't. Seems like CocoaPods needs to defer to Xcode in this instance.

[benasher44]

CocoaPods produces the warning because it sets those flags because they're required due to your pods using Swift. If you override them, it warns you to let you know that build settings that CocoaPods believes to be required are being overridden.

For the Xcode warnings, this cycle sounds like something we should patch for better Xcode 8 support. I'd appreciate if you could open a new issue with more information and a sample project that reproduces the issue. Thanks!

[llater]

I have the latest version of CocoaPods installed, and have reset the build settings in which I overrode those set by the Pods-xxx.release.xcconfig file. Still, I receive the warnings when I pod install. Nevertheless, in the Frameworks folder of my xxx.xcodeproj (in the same .xcworkspace as Pods.xcodeproj), the Pods_xxx.framework is still red and cannot be used.

[pkrmf]

@benasher44 Do you know where I can find the documentation on how I should build my Podfile when I need to include iOS extension specific Pods and Parent app specific pods(Some of the pods are shared, some of them are app or extension specific)?. I am using the latest version of cocoapods.

I keep getting the error when building my parent app. When I build the iOS Extensions I get a similar issue, but instead of the parent app, it mentions the .appex:

Class SomeClass is implemented in both /Users/User/Library/Developer/CoreSimulator/Devices/3DCF00F1-F42C-4C55-B74B-ED1EDF2CF1D2/data/Containers/Bundle/Application/6135CDCF-8592-48C6-96CA-B529F512427E/SomeApp.app/Frameworks/SomeFramework.framework/SomeFramework (0x107fb5878) and /Users/Users/Library/Developer/CoreSimulator/Devices/3DCF00F1-F42C-4C55-B74B-ED1EDF2CF1D2/data/Containers/Bundle/Application/6135CDCF-8592-48C6-96CA-B529F512427E/SomeApp.app/SomeApp (0x1053d8598). One of the two will be used. Which one is undefined.

[benasher44]

@pkrmf that issue is known and has been reported here: #6065. In most cases, that log message can be ignored.