Cocoapods: 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 https://github.com/CocoaPods/CocoaPods/pull/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

[siuying]

I think I have another use case for this issue. My app have three targets:

• App Target
• AppExtension Target
• AppShared Dynamic Framework

The dynamic framework supposedly is shared by both extension and app. When submitted, ITC complains:

• The bundle at 'App.app/Frameworks/AppShared.framework' contains disallowed file 'Frameworks'
• The bundle at 'App.app/Plugins/AppExtension.appex' contains disallowed file 'Frameworks'

Remove "Embed Pods Framework" or the script by @mikehouse will not fix the validation error.

[mikehouse]

@siuying Did you add the script to 'AppExtension Target'? If so, check pls that it goes after cocoapods' scripts.

[siuying]

@mikehouse Yep. I found the cause is the extension target has "Embedded Content Contains Swift Code" set to YES, which it should be NO.

[bassrock]

@siuying yea by setting "Embedded Content Contains Swift Code" to Yes I have found that it creates the Framework folder in the target with the swift lib files.

[pilot34]

I made script to remove 'Embed Pods Frameworks' phase from Extension target, but don't know how to integrate it to Podfile http://stackoverflow.com/questions/33846361/hook-in-podfile-to-edit-my-project-file

[segiddins]

As I've said, that branch isn't meant to work yet, hence why there's no pull request for it.

[mtucker]

Am I correct in saying that, as a result of this bug, it is currently impossible to use Swift libraries in App Extensions via CocoaPods?

[siuying]

@mtucker no. If you seeing this error, just follow the workaround above:

• remove embed pod framework
• add a user script to clean framework
• make sure framework and app extension are not build with "embedded content contains swift code", and
• do a clean rebuild

I have apps with extension shipped without issue.

[mtucker]

@siuying I seems like that workaround assumes that I am not using Swift frameworks in my extension. In my case, I would like to be able to do that.

For example:

platform :ios, '8.0'

use_frameworks!

target :MyShareExtension do
  pod 'Parse'
  pod 'Kanna', '~> 1.0.0'
end

target :MyApp do
  pod 'Parse'
end

In this case, Kanna is a Swift library. After following the workaround, Kanna does not get bundled with ShareExtension and generates an error at runtime when I try to use the library:

dyld: Library not loaded: @rpath/Kanna.framework/Kanna

For this reason, it seems like using Swift libraries in app extensions is not possible. Is that accurate?

[siuying]

@mtucker Have you tried to bundle it to you app too?

[mtucker]

@siuying Yes, that seems to work. Obviously not ideal but seems like the only option for now.

[siuying]

@mtucker yep, not ideal, but its how it works. The framework is not actually bundled to the extension, but the main app.

[paulz]

manually removing Embed Pods Frameworks from Build Phases for app extension targets let my app pass the validation while uploading to the AppStore. But few minutes after the upload, I got email from Apple:

Dear developer,

We have discovered one or more issues with your recent delivery for "My App Name". To process your delivery, the following issues must be corrected:

Invalid Bundle - One or more dynamic libraries that are referenced by your app are not present in the dylib search path.

Once these issues have been corrected, you can then redeliver the corrected binary.

Regards,

The App Store team

Adding post build script to remove Frameworks folder from app extensions targets did not help, got another automatic email as well.

After removing use_framworks! from app extensions targets the app passed post upload validation.

[hesyifei]

so we cannot use_framworks! for app extension?

[siuying]

@eflyjason you can, and you have to use use_framework! for pod include swift code.

[hesyifei]

but apple give me ERROR ITMS-90205 and ERROR ITMS-90206 when uploading as @paulz just mentioned if I use swift frameworks in extension :(

[siuying]

@eflyjason I have successfully submitted by following the thread's workaround.

[hesyifei]

@siuying how do you do exactly?

[siuying]

@eflyjason what's your setup? Your podfile?

[hesyifei]

@siuying

# Uncomment this line to define a global platform for your project
platform :ios, '8.0'
use_frameworks!

target 'AppName' do
    pod "AsyncSwift"
    pod 'MBProgressHUD', '~> 0.9.1'
    pod 'EAIntroView', '~> 2.8.0'
end

target 'AppNameActionExtension' do
    pod "AsyncSwift"
    pod 'MBProgressHUD', '~> 0.9.1'
end

So as you see AsyncSwift is a Swift pod and MBProgressHUD is a Objective-C pods. If I use use_frameworks!, everyone works find. But when I submit the build to Apple, it give me the following error: :(

ERROR ITMS-90205: "Invalid Bundle. The bundle at 'xxx Extension.appex' contains disallowed nested bundles."

ERROR ITMS-90206: "Invalid Bundle. The bundle at 'xxx Extension.appex' contains disallowed file 'Frameworks'."

But if I do not use use_frameworks!, I cannot use AsyncSwift pod.

So how can I fix it? Thanks! :)

[siuying]

@eflyjason check @mikehouse workaround

[mikeperri]

I tried the @mikehouse workaround (adding a shell script to the application extension's Build Phases), and that worked for me. It felt a little redundant to add a script to to delete a folder that's being generated in the build, so I just deleted the "Embed Pod Frameworks" build phase. That also worked.

So, to be really specific...

1. Open the (Your App).xcodeproj file (this is the first file on the project navigator pane).
2. Switch to the target for your app extension (on the top left of the middle pane).
3. Go to the Build Phases tab
4. Click the X after "Embed Pod Frameworks"

[kylebrowning]

@mikeperri's Solution worked for me.

[efremidze]

I'm still running into this issue on a keyboard extension. I'm getting the same email as @paulz from Apple using @mikeperri's workaround.

[efremidze]

@mikeperri's Solution worked after reinstalling cocoapods.

[skywinder]

+1. Got error with Embedded Content Contains Swift Code defined to No by pods configs for my embedded framework.

[dfujiwara]

@mikeperri's solution gets reverted once i run pod install again after making that change, so in a CI environment, @mikehouse's solution is what I found that worked reliably.

[benasher44]

@neonichu so we've recently run into this issue again (pinging you, since you initially labeled this issue), and we've done a lot more debugging. From what we've found, it seems that there should be no embed frameworks script at all for the extensions. Below, I've recapped the general issues we've run into, and how we came to this conclusion (CocoaPods 1.0.0.beta.6). Some of this may be recapping issues already raised, but I think it paints a pretty complete picture:

Background

1. We were using static libs, and very recently we switched to use_frameworks!.
2. We were using the hack of just removing the Frameworks directory from the watch extension in a later build phase to allow App Store submission (mentioned once or twice in this thread already).
3. Our watch app is a watchos 1.0 app and will continue to be one for the near future.

When switching to frameworks, it seems at first that we can't do 2 anymore, since the watch extension needs those frameworks. What we've found:

• CocoaPods as is without the hack in 2 works just fine in the simulator and even building to a real watch device
• Despite that, we cannot submit to the app store after use_frameworks without some modification to our build phase, and the App Store cites the following reasons:

• Invalid Bundle. The bundle at 'Yelp.app/PlugIns/Yelp Watchkit Extension.appex' contains disallowed nested bundles.
• Invalid Bundle. The bundle at 'Yelp.app/PlugIns/Yelp Watchkit Extension.appex' contains disallowed file Frameworks.

This "disallowed file Frameworks" reason is what anyone submitting with CocoaPods might see regardless of whether or not they have frameworks enabled, since it appears that CocoaPods adds the embed frameworks build phase that creates the Frameworks directory regardless of whether or not your project actually calls use_frameworks!. If you don't have use_frameworks! enabled, this folder will just be empty, but the App Store will complain regardless.

The "contains disallowed nested bundles" reason is what you get if you actually call use_frameworks!, remove the hack from 2 from when you were submitting builds that used static libs, and then submit to the App Store. I assume those nested bundles it's referring to are the frameworks that were embedded (why they don't just say frameworks instead of bundles, I don't know).

Given what we've learned about the App Store, we went back and looked at fresh project. Watch extensions (in a fresh project) get @executable_path/../../Frameworks as one of its Runpath Search Paths by default. This suggests that watch extensions (and this may be different for watchos 2, but we won't be able to verify this until if/when we upgrade) aren't meant to have Frameworks folders in them, and they just look up into the app's frameworks folder to access the frameworks they need. It looks like this has been previously mentioned in this thread, but I thought it deserved another mention.

Workaround

This fixed the issue for us. We left the hack in from 2 above that deletes the Frameworks folder, and then we just made sure the watch extension had @executable_path/../../Frameworks in its Runpath Search Paths to point to the existing, installed frameworks.

Solution

CocoaPods shouldn't included an embed frameworks build phase for extensions. Instead, it should just ensure that the Runpath Search Paths for each extension (and app target) is accurate.

If you think about frameworks being a tool to share code between your app and all of your extensions, it actually makes sense that you wouldn't embed frameworks in multiple places, since then you're back at the same package bloat issue you had with static libs (i.e. each target gets a copy of all of the dependencies it needs). Therefore, it makes sense that all of the frameworks be embedded in one place, so that you only ever have one copy of the shared frameworks, to which all of your extensions need access. Then your extensions just have search paths that point at those frameworks. If you think about it this way, you really shouldn't need an embed frameworks script at all for any target other than the app target, unless there is a case where your app and extensions are using frameworks that are entirely different. Even still, it really doesn't matter if the frameworks are all in the same place.

[neonichu]

@benasher44 Thanks for the detailed info on this!

The main issue right now is that CP does not know much about relationships between targets right now, especially not about which target is embedded into which other target. Regarding watchOS 2, it is indeed a different situation, those extensions need to have their own frameworks embedded separately because they're built for a different platform, this further complicates the situation a bit.

[benasher44]

Would it make sense to add new target syntax for this and maybe call it embedded_target? It'd be just like a regular target, but it would take a 2nd argument that says in which target it's embeded: embedded_target 'Yelp WatchKit Extension', 'Yelp'.

Could this fix the embedding frameworks separately issue as well? If you knew that a target was embedded but had a different architecture, then you would know that only that target required its own embed frameworks build phase. Does this seem right?

[neonichu]

I think it would be nicer if CP could infer this, as the information is already present in the Xcode project, including whether or not two targets build for the same or different platforms.

[benasher44]

Even better! Any chance this can be part of CocoaPods 1.0 😃?

[benasher44]

@neonichu maybe you could lay out some steps required to make this happen? I'd be willing to help make progress here, with some guidance on which projects and where things need to be updated/changed.

[segiddins]

@benasher44 Xcodeproj's PBXNativeTarget could be update with helper methods to get the array of targets a given target embeds and is embedded in, and CocoaPods could know that targets that are embedded do not get the Embed Frameworks script, and instead the containing target's embed frameworks script would include the frameworks intended for the child target

[benasher44]

@segiddins awesome thanks! I'll try to dive in this week.

[benasher44]

Just a note to keep documentation complete: @astralbodies ran into an issue that needs to be considered with this solution as well: your extension relies on a framework that your app target does not rely on. If CocoaPods expects this other framework to only be copied in the embed script for the extension, then this framework needs to be instead copied in with the rest of the other main target frameworks, in the case that the extension is the same architecture as the main target

[benasher44]

@segiddins I've started this here (just getting started). I'm feeling good about using bundle ids and product bundle ids to identify "embeddedness." What I have so far is untested and is mostly just a start at an approach.

I'm out of time this week, but I'll try to keep on it maybe some this weekend, but definitely more early next week. You're welcome to dm me somehow (twitter?) if you wanna take this branch and run with it.

[segiddins]

@benasher44 send me an email and we can get you into the slack, you've been doing great work!

[brianmichel]

I understand that the 'correct' fix will ultimately be hard to deliver since it's very hard for CocoaPods to determine the relationships between targets in a project I am trying to explore a solution for my project where I have a bit of insider information.

Basically I'm attempting to write a function in my Podfile that runs during the post install hook to remove these additional build phases. I have something like this:

def remove_copy_frameworks_phase_for_extensions(installer)
  installer.aggregate_targets.each do |aggregate|
    case aggregate.name
    when 'Pods-share_extension', 'Pods-today_widget'
      if aggregate.user_targets.count == 1
        puts 'Removing "Embed Pods Frameworks" build phase from extension target'
        pod_target = aggregate.user_targets.first
        phase = pod_target.shell_script_build_phases.select { |p| p.name == 'Embed Pods Frameworks' }.first
        phase.remove_from_project
        pod_target.project.save
      end
    end
  end
end

I can obviously make some assumptions around my project structure to attempt to accomplish my goal, however I've realized that while this code does work and do the desired thing, the post install hook is executed _before_ client integration happens. This is important to know since at that time, the build phases are modified, which means that all of this modification was for not.

Currently it seems like the _easiest_ way to solve this problem is to build a purpose-driven and dangerous CocoaPods plugin that opens up, and patches Pod::Installer#perform_post_install_actions. I'd like to avoid this if possible, the goal of this is to ensure that no matter how many pod install commands are issued, the resulting project structure can be more easily submitted to the app store.

I'd love to hear thoughts from the CocoaPods maintainers about such a solution.

[segiddins]

@brianmichel you're free to write a plugin, the whole point of plugins is that they can do stuff that we don't want to support in perpetuity ;)

[pilot34]

@brianmichel asked exactly that on stackoverflow with no luck :( Please, notify if you will solve that.

[brianmichel]

@brianmichel you're free to write a plugin, the whole point of plugins is that they can do stuff that we don't want to support in perpetuity ;)

Thanks @segiddins I figured this would be the answer, but just wanted to find out what some maintainers felt.

[benasher44]

I have a branch here that's working (with tests :) ) that can determine which targets in an xcode project are app extensions as well as the host targets for those extensions. I'm pretty new to the CocoaPods project, so it's a bit slow going for me getting a branch together in the main project that integrates this branch to better support frameworks in extensions.

Based on time that I have, I don't expect to have a PR up for at least another week or so, but the Xcodeproj branch can give you some hints about how to more generically identify extension targets.

[jonasman]

Cocoapods 1.0 here
@mikehouse's script didn't work for me.
Also removing the embedded pods build phase in both today extension and framework. Did not solve the problem.

I still get the error "frameworks ." file is present after uploading the app to itunesconnect.

Any help?

Inside the main app i have the Stocks.framework with this folder structure in the archive package:

[benasher44]

Recently the App Store added more blocking verification to submission. You'll additionally need to add a script to your extension host target (target hosting your app extensions, and one script phase per extension) build phase like this:

EMBEDDED_EXTENSION_PLUGIN_PATH="$TARGET_BUILD_DIR/$PLUGINS_FOLDER_PATH/<HARD_CODE_EXTENSION.appex_HERE>/Frameworks"
if [[ -d "$EMBEDDED_EXTENSION_PLUGIN_PATH" ]]; then
    rm -fr "$EMBEDDED_EXTENSION_PLUGIN_PATH"
fi

[jonasman]

@benasher44 your script worked fine!
I had to add your script twice.
One for the today appex extension and another one for the common code framework (StocksKit.framework).
After adding the scripts and archiving again I check that both appex and my framework folders didn't contain any folder inside named "Farmeworks" and tried again a submission. It worked just fine.
I think that the script from @mikehouse does nothing actually. And removing the embedded pods, in the extension and framework, build phase also helps.

[nixzhu]

@benasher44 Could you show a real example of your script? Do I need replace HARD_CODE_EXTENSION or others?

[benasher44]

Actually, it turns out that you don't need the above script. This thread is likely renewed from upgrading to CocoaPods 1.0, which IIRC re-integrates your Xcode project. This will move your build phases around, such that a previous build phase you might have added is now in the wrong place and no longer works. The final fix was to just take our script like this:

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

and ensure that it was the final build phase for each extension target that CocoaPods integrated.

[MarkMolina]

@benasher44 It seems to work for me whereas the archive was successfully uploaded to iTC. However I fail to miss the actual problem and why we need to remove this folder generated by CP.

[benasher44]

@MarkMolina currently CP doesn't recognize app extension targets as being different than non-app extension targets when it comes to integrating frameworks. App extensions can't have frameworks embedded in them, and instead they should be embedded in their host target.

[benasher44]

Hi folks! I was able to successfully submit a build to the App Store using a modified CocoaPods branch that I've been working on. The first part is a PR here: CocoaPods/Xcodeproj#382. I'm going to open a 2nd PR for the CocoaPods part after I get some tests written and resolve the related issue #5458. Until then, it'd be great if some of you who have been experiencing this issue could try doing an App Store submission with my branch! Early feedback would be really great, especially because this issue isn't all that noticeable until you go submit to the App Store.

It's currently based off of CocoaPods master @ 03ab3a34822a2548faf6281fee5b550395d2c5f0. To try this out in your project, setup your Gemfile like so (and please read the disclaimer at the bottom):

gem 'cocoapods', :git => 'https://github.com/benasher44/CocoaPods', :ref => 'bbdffa5ee720f8f4696b87120e573cd61aec8cac'
gem 'xcodeproj', :git => 'https://github.com/benasher44/Xcodeproj', :ref => '42df5c0932e11228f9ad9e901b7cae6205d80fe4'

Thanks!

Disclaimer about this Gemfile setup

These shas point at in-flight branches that are not committed to a master branch. This means that I could rebase to update my branches with master, and then these particular commit hashes could change! If you'd like to use these CocoaPods branches longer term, please fork my CocoaPods fork and point your Gemfile at your own fork.

Update: updated shas after rebase
Update: updated shas after rebase
Update: updated shas from recent PR update
Update: updated shas after rebase

[acegreen]

I'm getting a storm of warnings after submission, the IPA is accepted and uploaded.

Non-PIE Binary - The executable 'Payload/StockSwipe.app/Frameworks/AMPopTip.framework' is not a Position Independent Executable. Please ensure that your build settings are configured to create PIE executables. For more information, refer to Technical Q&A QA1788 - Building a Position Independent Executable

Repeats for all frameworks installed through CocoaPods

[benasher44]

@acegreen see #5453 for that one. It's an ITC bug. Thanks for testing out my branch though!

[acegreen]

Thanks mate

[9SL9]

Any update on this issue? I'm having this for a today widget extension. Funnily though when I validate my IPA all is ok, only when I try and upload do I get the error

[jonasman]

Just go to your archives and delete the frameworks folders from appex and your common framework and send it to itunes

[benasher44]

@9SL9 I have a PR up to fix this. You can try it out by modifying your Gemfile like above.

[alexito4]

If someone still has this issue and until the fix is merged, in my case removing the Frameworks folder form the .appex of the extension was the only thing that worked 👍
thanks all 💯

[wtpisaac]

Hello there.

I am looking to modify my Gemfile like above. Where is that gemfile located?

Thank you.

[alexito4]

@cyanisaac usually there is no Gemfile in your project, unless you want to use specific versions like betas. You can take a look at Using a Gemfile official guide to know more about it ;)

[benasher44]

Hi @cyanisaac! If your project doesn't currently use a Gemfile, you can checkout http://bundler.io for more info on how to get your project setup to use a Gemfile to manage your project's gems, in addition to the link provided by @alexito4.

[wtpisaac]

@alexito4 @benasher44 Thank you for pointing me in the right direction there. I will test the Gemfile config above out.

EDIT: Okay, I attempted using the Gemfile above, using "bundle exec pod install" once running bundle install, but ran into a similar issue to here https://github.com/CocoaPods/CocoaPods/issues/5542 which says "preprocess options" doesn't exist, and that I might have meant "preprocess_request"

Am I doing something wrong here?

[PSchu]

Hi @benasher44, does your branch also copy the Framework of an WatchExtension into the MainBundle? (i got 3 pods which only exist in the extension and are built with platform :watchos, '2.0')
I tried your branch and got a linker error for my WatchKit Extension. I'm not a 100% sure its the branch's problem at the moment need to look into it another time.

[benasher44]

@cyanisaac I don't think so. I think that issue sums it up, since my PR uses bleeding-edge CocoaPods.

[benasher44]

@PSchu This should have no impact on WatchOS 2 extensions, since those should be working with the currently released version of CocoaPods. When you have some time, I'd appreciate a Podfile or more information about your setup, so that I can try to reproduce your issue.

[PSchu]

@benasher44 i finally got time to look at it a little closer and the problems were all on my end. Your Branch works perfectly for us. Can't wait for it to be in a release

[benasher44]

@Pschu awesome thanks for following up!

[huyouare]

I've been experiencing this issue in Xcode 8 Beta 4 while developing a Messages Extension. The Run Script from @mikehouse fixed the error the first time, but when it occurred again, it seemed that setting the ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES Build Setting to No in my app extension fixed the issue (EMBEDDED_CONTENT_CONTAINS_SWIFT is deprecated in Xcode 8). I'm not quite sure why it was a fix, but I used this and this as resources.

[benasher44]

@huyouare can you try submitting to the App Store using my PR? You can do so by updating your Gemfile like this:

gem 'cocoapods', :git => 'https://github.com/benasher44/CocoaPods', :ref => 'c7def7aa85d58429bd53c6779c5d01c31eca5093'

You may also need to update your Gemfile to use the master branch of CocoaPods dependencies like CocoaPods/Xcodeproj, etc.

[huyouare]

@benasher44 Thanks for the quick fix! I tried using your PR which worked, but only after removing the Build Setting manually from both targets. Otherwise I get the error [!] The 'EncryptText [Debug]' target overrides the 'ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES' build setting defined in... This can lead to problems with the CocoaPods installation

[benasher44]

@huyouare okay great! That's expected, since my update adds a setting, which you are overriding. When you override a setting set by CocoaPods, it warns you that you might be undoing some of its magic. Thanks!

[jonasman]

@benasher44 is your PR merged into 1.0.1 or the new beta versions of CP?

[jonasman]

also the script works fine in extensions but doesnt clean the frameworks folder from my own shared framework.

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

[benasher44]

@jonasman, if you're not using Xcode 8 yet, then the PR merged into 1.1.0.beta.1 should work. Otherwise, the PR for Xcode 8 is on master and not in a release yet

[mlchild]

@huyouare Were you able to run the iMessage extension from Testflight on your phone successfully? I was able to upload it to the app store, but it just hangs after I install it on my iOS 10 beta phone.

[antonioreyna]

Hello, I have this problem what should i do? I added this to my build phases at the end:

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

But no luck, I am using xcode 7.3.1

[benasher44]

@antonioreyna you can remove that build phase if you upgrade to 1.1.0.beta.1

[antonioreyna]

I have that version installed @benasher44 should i add something on my podfile?

[antonioreyna]

this is my podfile, am i doing somehting wrong @benasher44

source 'https://github.com/CocoaPods/Specs.git'

# Uncomment this line to define a global platform for your project
platform :ios, '9.0'
# Uncomment this line if you're using Swift
use_frameworks!


def shared_pods

pod 'Alamofire', '~> 3.4'
pod 'AlamofireObjectMapper', '~> 3.0'

end

target 'MyApp' do

shared_pods
pod 'BWWalkthrough', '~> 1.1'
pod 'SideMenuController', '~> 0.1'
pod 'WWCalendarTimeSelector', '~> 1.2'
#pod 'Alamofire', '~> 3.4'
pod 'AlamofireNetworkActivityIndicator', '~> 1.0'
#pod 'AlamofireObjectMapper', '~> 3.0'
pod 'RoundedViews', '~> 1.0'
pod 'SwiftLocation', '~> 0.9'
pod 'PopupController', '~> 0.1'
pod 'PMAlertController', '~> 1.0'
pod 'SwiftDate', '~> 3.0'
pod 'SwiftString', '~> 0.5'
pod 'TextFieldEffects', '~> 1.2'
pod 'JWTDecode', '~> 1.0'
pod 'FluentConstraints', '~> 1.0'
pod 'QRCode', '~> 0.5'
pod 'SwiftyTimer', '~> 1.4'
pod 'PayPal-iOS-SDK'
pod 'SwiftValidator', '~> 3.0'
pod 'KeychainSwift', git: "https://github.com/marketplacer/keychain-swift.git", branch: "swift_2_3"
pod 'RSBarcodes_Swift', '~> 0.1'
pod 'Google/Analytics'
pod 'GoogleIDFASupport'

end

target 'shareContent' do

shared_pods

end

target 'watch' do

platform :watchos, '2.0'

end

target 'watch Extension' do

platform :watchos, '2.0'

shared_pods

end

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