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

Closed
mikehouse opened this Issue Sep 17, 2015 · 128 comments

Projects

None yet
@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
Member

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

@segiddins
Member

Can you see if #4261 fixes things for you?

@bassrock

@segiddins just tried it same results.

@segiddins
Member

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
Member

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
Member

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.

@neonichu neonichu added this to the 0.39 milestone Sep 25, 2015
@segiddins segiddins added the d3:hard label Sep 27, 2015
@segiddins segiddins removed this from the 0.39 milestone Oct 5, 2015
@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
romanr commented Oct 13, 2015

@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
Member

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
Member

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

@orta
Member
orta commented Oct 14, 2015

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
Member

@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
Member

Yes, we know it's an issue.

@seamane
seamane commented Oct 23, 2015

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

@mikeh mikeh added a commit to mikeh/alfresco-ios-app that referenced this issue Nov 10, 2015
@mikeh mikeh Add workaround for CocoaPods #4203 CocoaPods/CocoaPods#4203 "appex co…
…ntains disallowed file 'Frameworks'"
5503264
@siuying
Contributor
siuying commented Nov 12, 2015

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
Contributor
siuying commented Nov 12, 2015

@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
pilot34 commented Nov 21, 2015

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
Member

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

@mtucker
mtucker commented Dec 10, 2015

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
Contributor
siuying commented Dec 11, 2015

@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
mtucker commented Dec 11, 2015

@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
Contributor
siuying commented Dec 12, 2015

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

@mtucker
mtucker commented Dec 13, 2015

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

@siuying
Contributor
siuying commented Dec 13, 2015

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

@paulz
paulz commented Dec 20, 2015

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.

@eflyjason

so we cannot use_framworks! for app extension?

@siuying
Contributor
siuying commented Dec 21, 2015

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

@eflyjason

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
Contributor
siuying commented Dec 21, 2015

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

@eflyjason

@siuying how do you do exactly?

@siuying
Contributor
siuying commented Dec 21, 2015

@eflyjason what's your setup? Your podfile?

@eflyjason

@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
Contributor
siuying commented Dec 21, 2015

@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
Member

@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
Member

@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
Member

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
Member

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
Member

Even better! Any chance this can be part of CocoaPods 1.0 πŸ˜ƒ?

@benasher44
Member

@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
Member

@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
Member

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

@astralbodies astralbodies referenced this issue in wordpress-mobile/WordPress-iOS Apr 4, 2016
Closed

Resolve binary submission issues for 6.1 #5081

@benasher44
Member

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
Member

@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
Member

@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
Member

@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
pilot34 commented Apr 13, 2016

@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
Member

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
jonasman commented May 31, 2016 edited

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?
screen shot 2016-05-31 at 22 28 01

Inside the main app i have the Stocks.framework with this folder structure in the archive package:
screen shot 2016-05-31 at 22 29 47

@benasher44
Member
benasher44 commented May 31, 2016 edited

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
nixzhu commented Jun 2, 2016

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

@benasher44
Member

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
Member

@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
Member
benasher44 commented Jun 3, 2016 edited

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 @ 03ab3a3. 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
acegreen commented Jun 4, 2016 edited

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
Member

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

@acegreen
acegreen commented Jun 4, 2016

Thanks mate

@9SL9
9SL9 commented Jun 13, 2016

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
jonasman commented Jun 13, 2016 edited

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

@benasher44
Member

@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 πŸ’―

@cyanisaac

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
Member

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.

@cyanisaac
cyanisaac commented Jun 27, 2016 edited

@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 #5542 which says "preprocess options" doesn't exist, and that I might have meant "preprocess_request"

Am I doing something wrong here?

@PSchu
PSchu commented Jun 28, 2016

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
Member

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

@benasher44
Member

@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
PSchu commented Jul 1, 2016

@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
Member

@Pschu awesome thanks for following up!

@segiddins segiddins closed this in #5502 Jul 5, 2016
@huyouare
huyouare commented Aug 10, 2016 edited

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
Member

@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
Member

@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
Member

@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
mlchild commented Aug 16, 2016

@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
Member

@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
Member

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
Member

@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
Urkman commented Sep 1, 2016 edited

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
marco318 commented Sep 1, 2016

@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
Urkman commented Sep 1, 2016

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

@benasher44
Member

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
Member

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
Urkman commented Sep 2, 2016

Strange thing...

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

@lelandlater

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
Member

@lelandlater which build settings is it complaining about specifically?

@lelandlater

@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
Member

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
jshier commented Sep 20, 2016

@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
Member

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

@jshier
jshier commented Sep 20, 2016

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
Member

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!

@lelandlater
lelandlater commented Sep 20, 2016 edited

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
pkrmf commented Jan 26, 2017

@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
Member

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

@cpboyd cpboyd referenced this issue in SVGKit/SVGKit Feb 17, 2017
Merged

Change CocoaLumberjack to 3.x #511

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment