Cocoapods: EMBEDDED_CONTENT_CONTAINS_SWIFT = YES causes app being rejected

[marcvanolmen]

I spend an hour trying to create an simple app to locate the bug but I failed, so sorry I have to do it with just a description:

We have project that contains 4 targets (1 iOS app, 1 iOS framework, 1 tvOS app, 1 tvOSframework).

• The tvOS app contains Swift code.
• The tvOSframework doesn't contain Swift code but one of the frameworks it uses contains Swift code.

When we run pod install the tvosframework gets the flag added

EMBEDDED_CONTENT_CONTAINS_SWIFT = YES

When Xcode builds this framework it creates inside the Framework another folder called Framework. (which is empty) When we submit the app, iTunes Connect refuses the app with the error that this Framework folder is not allowed.

When we manually override EMBEDDED_CONTENT_CONTAINS_SWIFT = NO, rebuild our app everything is ok.

EMBEDDED_CONTENT_CONTAINS_SWIFT = YES
FRAMEWORK_SEARCH_PATHS = $(inherited) "$PODS_FRAMEWORK_BUILD_PATH"
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
LD_RUNPATH_SEARCH_PATHS = $(inherited) '@executable_path/Frameworks' '@loader_path/Frameworks'
OTHER_CFLAGS = $(inherited) -iquote "$PODS_FRAMEWORK_BUILD_PATH/Aspects.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/FXKeychain.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/JLRoutes.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/MKTools.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/Mantle.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/Objection.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/RMStore.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/RNCryptor.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/RTVVideoEffects.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/SDWebImage.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/TRToolkit.framework/Headers" -iquote "$PODS_FRAMEWORK_BUILD_PATH/TRVideoKit.framework/Headers"
OTHER_LDFLAGS = $(inherited) -ObjC -all_load -framework "Aspects" -framework "FXKeychain" -framework "JLRoutes" -framework "MKTools" -framework "Mantle" -framework "Objection" -framework "RMStore" -framework "RNCryptor" -framework "RTVVideoEffects" -framework "SDWebImage" -framework "TRToolkit" -framework "TRVideoKit"
OTHER_SWIFT_FLAGS = $(inherited) "-D" "COCOAPODS"
PODS_FRAMEWORK_BUILD_PATH = $(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/Pods-ReutersTVCore_tvOS
PODS_ROOT = ${SRCROOT}/Pods

[segiddins]

Are you using cocoapods to integrate into a framework?

[marcvanolmen]

No we use Xcode to add this framework. The framework itself uses several cocoapods so the above is the config of one of the cocoapods generated files for this frameowork.

[segiddins]

Can you share a project that reproduces the issue? Since setting that build setting definitely should _not_ cause a rejection.

[marcvanolmen]

I haven't been able to replicate it in non - private project I will try more over the next week.

[segiddins]

Awesome, thanks for following up!

[andriyslyusar]

Hi, I have a similar issue. Swift project 'A' with dynamic Swift framework 'B'. B has cocoapods dependencies:

target 'B', :exclusive => true do
  pod 'Typhoon', '~> 3.3'
  pod 'R.swift'
  pod 'SwiftColors'
  pod 'Alamofire', '~> 3.0'
end

Created workspace will have EMBEDDED_CONTENT_CONTAINS_SWIFT = YES both for A and B, but without changing EMBEDDED_CONTENT_CONTAINS_SWIFT to NO for B will lead to reject iTC, similar case https://github.com/CocoaPods/CocoaPods/issues/4419.

[!] The `Project [Debug]` target overrides the `EMBEDDED_CONTENT_CONTAINS_SWIFT` build setting defined in `Pods/Target Support Files/Pods-Project/Pods-Project.debug.xcconfig'. This can lead to problems with the CocoaPods installation
    - Use the `$(inherited)` flag, or
    - Remove the build settings from the target.

[segiddins]

@andreyslyusar as requested above, please share a project we can use to reproduce the issue.

[jigneshsheth]

I am having the same issue when start using the Alamofire by cocoapods.

[neonichu]

Closing, since we never got a project to reproduce — we can reopen if someone can provide one.

[marcvanolmen]

Because I'm in NY, I will bring our project on Dec 5th to the http://www.meetup.com/CocoaPods-NYC/ to see this helps.

[itsthejb]

Hi all,

This sounds a bit like an issue we're having: we have a (non-Pod) internal Swift dynamic framework at the moment. If we have EMBEDDED_CONTENT_CONTAINS_SWIFT = YES then Xcode include the root dylibs inside that framework's Frameworks folder in the bundle:

ie. you have App.bundle/Frameworks/AwesomeInternalFramework.framework/Frameworks. This appears to be incorrect and ITC will complain.

However, if we override EMBEDDED_CONTENT_CONTAINS_SWIFT = NO for the framework target, Cocoapods compains with:

target overrides the EMBEDDED_CONTENT_CONTAINS_SWIFT build setting defined in...

Therefore I think the Cocoapods warning is incorrect, and should not insist on this for framework targets (and possibly others).

Shouldn't be too hard to create a test project if necessary. Just let me know :+1:

[andriyslyusar]

@neonichu do you still need an example project? Does @marcvanolmen managed to project example on NY meetup?

[marcvanolmen]

I wasn't able to find the time to go to the meetup, so if you have a sample project please provide it.

[andriyslyusar]

@neonichu here is an example of project: https://github.com/andreyslyusar/CocoaPods-Issue-4515

Example of error while upload iTC:

EMBEDDED_CONTENT_CONTAINS_SWIFT should be EMBEDDED_CONTENT_CONTAINS_SWIFT = NO for EmbeddedFramework:

[itsthejb]

Can confirm that @andreyslyusar's demo project exactly recreates what we're seeing as well. Thanks for that!

[neonichu]

Thanks for the example project!

[jegv91]

Any updates on this issue? Thanks in advance :)

[segiddins]

@jegv91 not yet, but a PR with a fix would be much appreciated!

[Ben-G]

@jegv91 I'm currently using a post install hook as a workaround:

post_install do |installer|
    system "sed -i '' -E 's/EMBEDDED_CONTENT_CONTAINS_SWIFT[[:space:]]=[[:space:]]YES/EMBEDDED_CONTENT_CONTAINS_SWIFT = NO/g' Pods/Target\\ Support\\ Files/Pods-LibraryTargetName/*.xcconfig"
end

Not elegant, but does the job for now.

[kvreem]

@Ben-G where do u put this install hook ?

[ArtSabintsev]

@Kkhattab you put it in the podfile (example: https://guides.cocoapods.org/syntax/podfile.html)

[kvreem]

@ArtSabintsev I know you didn't suggest doing it but when i did it still didnt work, this is what I am experiencing.

@Ben-G was this what you were trying to solve as well?

[ArtSabintsev]

Can you drop a copy of your podfile in here?

[kvreem]

Im am also on version 0.39.0

platform :ios, ‘8.0’
use_frameworks!

target 'Rydite' do
pod 'LayerKit'
pod 'Atlas'
pod 'NYTPhotoViewer'
pod 'MBProgressHUD', '~> 0.9.1'
pod 'SBPickerSelector'
pod 'SWRevealViewController', :git => 'https://github.com/John-Lluch/SWRevealViewController.git'
pod 'SwiftHEXColors'
pod 'CWStatusBarNotification', '~> 2.3.3'
pod 'Parse'
pod 'IQKeyboardManagerSwift'
pod 'PageMenu'
pod 'GoogleMaps', '1.10.5'
pod 'SPGooglePlacesAutocomplete', '~> 1.0'
pod 'FPPopover', :git => 'https://github.com/alvises/FPPopover.git'
end

[ArtSabintsev]

can you add the post-install script in there as well?

[kvreem]

platform :ios, ‘8.0’
use_frameworks!

target 'Rydite' do
pod 'LayerKit'
pod 'Atlas'
pod 'NYTPhotoViewer'
pod 'MBProgressHUD', '~> 0.9.1'
pod 'SBPickerSelector'
pod 'SWRevealViewController', :git => 'https://github.com/John-Lluch/SWRevealViewController.git'
pod 'SwiftHEXColors'
pod 'CWStatusBarNotification', '~> 2.3.3'
pod 'Parse'
pod 'IQKeyboardManagerSwift'
pod 'PageMenu'
pod 'GoogleMaps', '1.10.5'
pod 'SPGooglePlacesAutocomplete', '~> 1.0'
pod 'FPPopover', :git => 'https://github.com/alvises/FPPopover.git'
end

post_install do |installer|
system "sed -i '' -E 's/EMBEDDED_CONTENT_CONTAINS_SWIFT[[:space:]]=[[:space:]]YES/EMBEDDED_CONTENT_CONTAINS_SWIFT = NO/g' Pods/Target\\ Support\\ Files/Pods-LibraryTargetName/*.xcconfig"
end

It still get the same results as i posted above. It happens whenever I try to do a pod install so I end up have to take out the framework I want to add, and then doing a git reset --hard to go back to my working cocoapods.

[ArtSabintsev]

ok, will take a look in a sample project later

platform :ios, ‘8.0’
use_frameworks!

target 'Rydite' do
pod 'LayerKit'
pod 'Atlas'
pod 'NYTPhotoViewer'
pod 'MBProgressHUD', '~> 0.9.1'
pod 'SBPickerSelector'
pod 'SWRevealViewController', :git => 'https://github.com/John-Lluch/SWRevealViewController.git'
pod 'SwiftHEXColors'
pod 'CWStatusBarNotification', '~> 2.3.3'
pod 'Parse'
pod 'IQKeyboardManagerSwift'
pod 'PageMenu'
pod 'GoogleMaps', '1.10.5'
pod 'SPGooglePlacesAutocomplete', '~> 1.0'
pod 'FPPopover', :git => 'https://github.com/alvises/FPPopover.git'
end

post_install do |installer|
system "sed -i '' -E 's/EMBEDDED_CONTENT_CONTAINS_SWIFT[[:space:]]=[[:space:]]YES/EMBEDDED_CONTENT_CONTAINS_SWIFT = NO/g' Pods/Target\\ Support\\ Files/Pods-LibraryTargetName/*.xcconfig"
end

Thanks.

[Ben-G]

Sorry if this was unclear, but you need to rename Pods-LibraryTargetName
in the script to the name of the Pods project specific to the target for
which you want to set the flag. E.g. Pods-MyAwesomeFramework.

[kvreem]

@Ben-G ok i will try it would it essentially be Pods-MyAppNameHere ?

[Ben-G]

@Kkhattab it would Pods-MyFrameworkNameHere. For the main app you should leave the EMBEDDED_CONTENT_CONTAINS_SWIFT setting untouched. You should only use this override for any frameworks that you are providing, in addition to the app. In our case we were importing an internal framework into our app. We needed to disable the flag for that internal framework.

[kvreem]

@Ben-G yeah this doesn't seem to mitigate the issue for me. What's odd is I am not even adding a internal framework, I just wanted to add frameworks from cocoapods and then I started running into this issue.

[obitow]

Hi, I have the same problem in my project. Setting this flag to No solves it, but the warning every time I run update or install annoys me a little. Can CocoaPods check if the target is a Framework, so the .xconfig file doesn't set EMBEDDED_CONTENT_CONTAINS_SWIFT to Yes?

[kvreem]

@obitow i believe the fix is to make sure you do not have any frameworks used in other frameworks in your cocoapods, so basically do not nest your frameworks.

[paulz]

As a workaround, we simply ignore EMBEDDED_CONTENT_CONTAINS_SWIFT set by cocoapods:
https://gist.github.com/paulz/e1fb44c96fdfbcbbb29086adb7100d3f

post_install do |installer|
    ignore_overriding_contains_swift(installer, 'MyFramework')
end

def ignore_overriding_contains_swift(installer, framework_target)
    target = installer.aggregate_targets.find{|t| t.name == "Pods-#{framework_target}"}
    raise "failed to find #{framework_target} among: #{installer.aggregate_targets}" unless target
    target.xcconfigs.each_value do |config|
        config.attributes.delete('EMBEDDED_CONTENT_CONTAINS_SWIFT')
    end
end

[benasher44]

This is fixed in CocoaPods 1.1.0. It properly sets this setting based on the product type. Can people try testing with that version?

[hfossli]

@benasher44 Maybe I'm missing something, but it isn't working as I would expect on my side

1) Create an xcode project for Swift only

2) Create Podfile.

hfossli in ~/Downloads/ASDASD(ruby-2.3.0) λ cat Podfile
platform :ios, '8.0'

use_frameworks!

target 'ASDASD' do
  pod 'KeychainSwift', '~> 6.0.2'
end

3) Verify pod version

hfossli in ~/Downloads/ASDASD(ruby-2.3.0) λ pod --version
1.1.0

4) Install

hfossli in ~/Downloads/ASDASD(ruby-2.3.0) λ pod install
Analyzing dependencies
Downloading dependencies
Installing KeychainSwift (6.0.2)
Generating Pods project
Integrating client project

[!] Please close any current Xcode sessions and use `ASDASD.xcworkspace` for this project from now on.
Sending stats
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.

5) Log to console the xcconfig

hfossli in ~/Downloads/ASDASD(ruby-2.3.0) λ cat Pods/Target\ Support\ Files/Pods-ASDASD/Pods-ASDASD.release.xcconfig 
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES
EMBEDDED_CONTENT_CONTAINS_SWIFT = YES
FRAMEWORK_SEARCH_PATHS = $(inherited) "$PODS_CONFIGURATION_BUILD_DIR/KeychainSwift"
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
LD_RUNPATH_SEARCH_PATHS = $(inherited) '@executable_path/Frameworks' '@loader_path/Frameworks'
OTHER_CFLAGS = $(inherited) -iquote "$PODS_CONFIGURATION_BUILD_DIR/KeychainSwift/KeychainSwift.framework/Headers"
OTHER_LDFLAGS = $(inherited) -framework "KeychainSwift"
OTHER_SWIFT_FLAGS = $(inherited) "-D" "COCOAPODS"
PODS_BUILD_DIR = $BUILD_DIR
PODS_CONFIGURATION_BUILD_DIR = $PODS_BUILD_DIR/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
PODS_ROOT = ${SRCROOT}/Pods

Here's the result Example project.zip.

---

I would expect ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to be omitted or be set to NO. My expectation may very well be wrong.

Also when I export the app to archive using under Product > Archive in Xcode I get a pretty big archive with what I would say is a minimum amount of code for any viable app.

[benasher44]

I'm assuming KeychainSwift uses Swift. In that case, it'll be set to yes for the target you're integrating that pod into. Since KeychainSwift is a Swift pod, your target requires Swift and its libraries by proxy.

[benasher44]

One of the downsides of using Swift pods is that your target that uses them will then have to be distributed with the Swift libraries, which causes the bloat you're seeing.

[benasher44]

Going to close this, since CocoaPods now properly sets EMBEDDED_CONTENT_CONTAINS_SWIFT to YES or leaves it untouched based on the target's product type. It even handles it properly for extensions as well.

[chrisballinger]

@benasher44 I still see this problem with CocoaPods 1.2.0.beta.1 for this project / Podfile: https://github.com/ChatSecure/ChatSecure-iOS/tree/omemo

We have an abstract target and three concrete sub targets. One is an app, one is a framework, and one is tests. We have to manually disable ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES or the App Store upload fails.

edit: also the manual overrides via post_install tricks no longer work.

[benasher44]

Hi @chrisballinger! Thanks for letting us know! Would you mind opening up a new ticket with the issue template filled out? It'd go a long way helping us help you. Thanks!