Cocoapods: 'Failed to import bridging header' when executing test target

[azubala]

🌈

When swift project uses ObjC pods via the bridging header the main target can be compiled and run without any issues. When tests are executed on the same project it fails with an error:

[...]/Foo/Foo/Foo-Bridging-Header.h:9:9: error: 'AFNetworking/AFNetworking.h' file not found
#import <AFNetworking/AFNetworking.h>
        ^
[...]/Foo/FooTests/FooTests.swift:13:8: error: failed to import bridging header '[...]/Foo/Foo/Foo-Bridging-Header.h'
import Foo

Please find the demo project here.

Please also note that the project's module has to be imported in order to reference production classes from tests.

Contrary, when using bridging header for ObjC classes checked in the project, I can execute tests without any issues.

[neonichu]

This seems like expected behaviour to me, AFNetworking is only linked against your application target in your Podfile, so it is only available to it.

[azubala]

@neonichu thanks for your reply, although I think you're not right. When it comes to testing you don't need to link pods again the spec target, it's already referenced in the target dependencies:

I'm quite sure it's not the problem here. Please let me know if you require any more input.

[segiddins]

What's the Podfile?

[orta]

( as an aside, here's my Podfile which doesn't exhibit this behavior )

[azubala]

@segiddins here's the Podfile (the example project can be found here )

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

target 'Foo' do
pod 'AFNetworking', '~> 2.4'
end

target 'FooTests' do
end

@orta were you able to execute tests when your app uses bridging header?

[segiddins]

FooTests needs to be marked as exclusive.

-Samuel E. Giddins

On Oct 19, 2014, at 12:35 PM, Aleksander Zubala [email protected] wrote:

@segiddins here's the Podfile (the example project can be found here )

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

target 'Foo' do
pod 'AFNetworking', '~> 2.4'
end

target 'FooTests' do
end
@orta were you able to execute tests when your app uses bridging header?

—
Reply to this email directly or view it on GitHub.=

[azubala]

@segiddins adding target 'FooTests', :exclusive => true do didn't help.
@neonichu for now I'm going to go with your solution: to add pods for both targets, but I think in the long run it should be resolved other way.

[azubala]

By the way, the solution from @neonichu only works for a Podfile like so:

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

target 'Foo' do
pod 'AFNetworking', '~> 2.4'
end

target 'FooTests', :exclusive => true do
pod 'AFNetworking', '~> 2.4'
end

When I try to remove the redundancy with a Podfile like that:

source 'https://github.com/CocoaPods/Specs.git'
pod 'AFNetworking', '~> 2.4'

the problem remains.

Do you think guys you could investigate that or provide me some hints so I can debug it on my own?

Also, is this issue closed already? :smile:

[orta]

Yeah, tests run fine with my Podfile.

The linking happens because all the pods are in global scope then the testing pods are added exclusively to the testing target. You can check out the project and have a click around if you want to see how it works.

[azubala]

Thanks @orta I'm going to approach it the same way.

[azubala]

Hey I think we need to reopen the issue, I managed to came up with the steps to reproduce the issue.

My environment:

• Mac OSX Yosemite 10.10 (14A389)
• Xcode 6.0.1, build version 6A317
• Cocoapods 0.34.4

Steps to reproduce

• create empty swift project with tests
• create a empty bridging header for the project, e.g. Foo-Bridging-Header.h
• in build settings set the path to the header under _Objective-C Bridging Header_
• make sure the app compiles
• make sure the tests can be executed
• create a Podfile:

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

pod 'AFNetworking'

target 'FooTests', :exclusive => true do
end

• install pods
• open workspace, make sure the app compiles and tests can be executed
• add #import "AFNetworking.h" to the bridging header
• write a sample test where you create a class from your app, e.g. AppDelegate (to do that you need to import the module of the app in the spec)
• execute tests

Result:

• tests are failing due the the error error: failed to import bridging header

Expected behaviour:

• test should be executed when app uses bridging header

Sorry for the long comment but I think it's the real issue not just me and my setup.

Please let me know if you need help to track this down.

[segiddins]

@azubala are you sure you don't need to make a separate bridging header for your tests?

[azubala]

@segiddins I've already tried that and no luck.

[segiddins]

Could you please upload a sample project created with those above steps?

[azubala]

Sure, here's the example project.

[segiddins]

Can confirm the problem, and that it's resolved by including a pod in the test target. The issue was that Header Search Paths weren't set for the test target.

[azubala]

Thanks!

[broglep-work]

We are having the same issue.
But when including the pod in both the application target and the test target, the bridging header can be imported, but this causes duplicate symbols, because the test target is linked to the main target (manifest as failing isKindOfClass assertions) (the problem is described in https://github.com/CocoaPods/CocoaPods/issues/1729). So the workaround does not really work.

We did get it working by manually copying the header search path from the application target to the test target, but otherwise not including any pods in the test target. Then the bridging header can be correctly imported and we do not get duplicate symbols. (PODS_ROOT had to be hardcoded too, as the test target does not contain any pods and no target support files are generated)

Are there any ideas how this problem can be solved without manually messing with the header search path?

[jessecurry]

Turned out to be an easy fix for me, just had to choose the Pods.debug and Pods.release configurations for my tests target, it was set to None.

[kylef]

@segiddins the header search paths are not set because there are no pods in that target, thus it will not integrate it.

[leafpeak]

thanks @jessecurry this worked for me as well.

[gyemme]

thanks @jessecurry that solution works great! It took me sometime to find configurations. Click on yourproject.xcodeproj->info->Configurations.

[minikin]

thanks @jessecurry for the tip!

[xuqisheng]

thanks @jessecurry and @gyemme for tip!

[sxm12]

try this!!!!!
http://swiftalicio.us/2014/11/using-cocoapods-from-swift/

[ilandbt]

@jessecurry answer worked for me, Thanks

[dcgoss]

@jessecurry answer also worked for me. I also took his answer and wrote it up on Stack Overflow http://stackoverflow.com/questions/30836795/cant-import-main-swift-classes-into-test-target?noredirect=1#comment49718563_30836795 in case anyone else stumbles across this problem

[ralfebert]

The workaround proposed by @jessecurry works, but it leads to the class being present twice instead of the code in the test target using the class from the app target. (imho since Xcode 7) there is a warning for this:

objc[62874]: Class MBProgressHUD is implemented in both Foo.app/Foo and FooTests.xctest/FooTests. One of the two will be used. Which one is undefined.

This happens for a super-simple Podfile like this:

pod 'MBProgressHUD'

target 'Foo' do

end

target 'FooTests' do

end

target 'FooUITests' do

end

(moving the pod to the 'Foo' target doesn't fix this)

Without the workaround, the header files referenced in the bridging header cannot be found when compiling the test target, as described in the original problem.

I wondered if there is an elegant way to only get the main targets header search path for the test target as well and if this would suffice in these cases...

[segiddins]

This is no longer necessary due to @mrackwitz's work on target de-duplication and https://github.com/CocoaPods/CocoaPods/issues/4001.

[miktav]

@jessecurry answer worked for me. Thanks!

[jeyrschabu]

@jessecurry worked! Thanks

[tirupathi25]

I am using goole signIn pods ,wile i'm run my App getting below error, can anyone help me

/Users/tirupathi/Documents/AmzurConnect/AmzurConnect/AmzurConnect-Bridging-Header.h:5:9: error: 'Google/SignIn.h' file not found

import

    ^

:0: error: failed to import bridging header '/Users/tirupathi/Documents/AmzurConnect/AmzurConnect/AmzurConnect-Bridging-Header.h'

[Voley]

I still have the same issue. I'm using latest cocoapods and Xcode 7.1
Here is my podfile:

platform :ios, '8.0'

target 'myproject-iOS' do
pod 'AFNetworking'
pod 'Realm'
pod 'SDWebImage'
end

target 'myproject-iOSTests' do
pod 'AFNetworking'
pod 'Realm'
pod 'SDWebImage'
end

target 'myproject-iOSUITests' do
pod 'AFNetworking'
pod 'Realm'
pod 'SDWebImage'
end

When I try to run tests, it says "myproject-Swift.h" not found. Solution with targets did not help. What to do?

[RYANCOAL9999]

Please try to using this, https://github.com/RYANCOAL/swift-with-AFNetworking

[kylerobson]

I still had this issue where I put empty "target 'FooTests' do end" sections for UI/unit tests. I solved it by adding a pod to each of those targets. Not ideal, so I assume cocoapods needs some work to handle it. Once I added a pod, I had a different xcconfig for each target, and I think that's the crucial part to avoid duplicate symbols while also avoiding the "unable to import bridging header" error.

[RYANCOAL9999]

Have your try my method to do it ? You lose this code-@testable import Test.If you add this, it will have the error like your condition. My xcode version is 7.2, and the ios is 9.0, the AFNetworking's version is > 2.0 . I have try to add new swift file for test on my file. It doesn't have any error add the this code after. I think it should be version different to generate xcode project. So, You should try to use my method to reset up and rebuild the project.

[yzhong52]

I found a way to make it work and without linking the library twice (which gives a lot of annoying warnings in the console output window) is the through the following:

1. Make a copy of Pods.debug and Pods.release, I am calling them Pods-Test.Debug and Pods-Test.Release here but you can call them whatever you like.
2. Add them to the target settings as the following:

See this link how to change the configuration file.

1. Remove the the entire section of OTHER_LDFLAGS in both files Pods-Test.Debug and Pods-Test.Release

[RYANCOAL9999]

I have search it. It is on info pages, but my settings is different with you.
I have two xcode project, so I just open the Test.xcworkspace.

Configuration Settings,

[dcgoss]

All of you having issues with this may find this Stack Overflow question to be of help.

[fjcaetano]

I'm having the same exact issue, but my Podfile is a little different:

abstract_target 'CommonPods' do
  pod 'Google/Analytics'
  ...

  target 'winnin' do
      pod 'Crashlytics', :configurations => ['Release']
      pod 'Reveal-iOS-SDK', :configurations => ['Debug']
  end

  target 'winninTests' do
    inherit! :search_paths

    pod 'Quick', '~> 0.8.0'
    pod 'Nimble', '3.0.0'
  end
end

My Gemfile is pointing to the master branch as described in the Using a Gemfile documentation.

If instead of using the bridging header I try to import the module directly import Google, the test build errors with "No such module 'Google'"

One thing I found out: the Header Search Paths for my test target are empty. I've tried filling them with "Pods" and setting as recursive, but it didn't solve.

I think it may be related to #4944

[RYANCOAL9999]

follow this website, it is best solutions for the google api. https://developers.google.com/ios/guides/cocoapods#add_a_google_sdk_to_your_ios_app

[fjcaetano]

@RYANCOAL9999 that's exactly what I did, but I only installed Analytics as in the official docs.

If I import the GA in the bridging header as they say, I get the error described in this issue, but if instead I try to import the framework directly in the swift file, I get the "no module" error.

Just to be clear: the main target builds correctly both ways, only the test target throw these errors.

[RYANCOAL9999]

Are you sure that it is correctly with target builds ? if it is correctly, you can use google api on each swift file(include with new testing target)!!In my case, I can use AFNetworking api on main target or testing target without any import module.
Secondly, are you know how to use google api with iOS ??
https://github.com/google/google-api-objectivec-client/blob/master/Examples/BloggerSample/BloggerSampleWindowController.m
This website has example to show how to use google api in objective-c. Do you how to change to swift ?
I can give you one example, the code in objective-c like this,
In objective-C
GTMOAuth2Authentication *auth = [GTMOAuth2WindowController authForGoogleFromKeychainForName:kKeychainItemName
clientID:clientID
clientSecret:clientSecret];
In swift,
let auth = GTMOAuthWindowController(Name:kKeychainItemName,
clientID:clientID,
clientSecret:clientSecret);

[fjcaetano]

Yes, @RYANCOAL9999, it is working and I'm doing it correctly. We are able to receive events in GA as proof that we did it correctly. Actually, our app is already in the appstore, so that's not the issue. The problem is with the tests, not the main application.

[chrisortman]

@fjcaetano is this fixed for you? I have the same problem and using beta8 of cocoa pods still have errors.

When I added abstract_target and inherit search_paths I went from getting the bridging header error to duplicate module error.

[RuslanPatyk]

Guys, I am facing this issue with my tests after update to Xcode 7.3 and updating to Cocoa pods 1.0. Please, explain if there are problems in my Podfile. Thank you.
Podfile.txt

[amanssharma]

thanks @jessecurry , worked like a charm...

[RuslanPatyk]

With @jessecurry 's solution I am facing "Class GSDK_GTMABRecord is implemented in both... One of the two will be used. Which one is undefined". Does elegant solution for this problem exist?

[takecian]

+1

I found same issue with @RuslanPatyk , console says "Class XXX is implemented in both..One of the two will be used. Which one is undefined"

[RuslanPatyk]

takecian, I did figure out what yzhong52 means: there is a folder called "Pods" that contains your xcconfig files. You can copy files that you need and than edit them in the way yzhong52 suggests. His solution works in my case. Message "Class XXX is implemented in both... " has disappeared.

[takecian]

@RuslanPatyk , I did and it has disappeared! Thank you!

[fans3210]

@jessecurry , Thanks for your solutions. It works for me too! I think someone could write an article about this. Especially for now there are more developers started to use TDD

[mx4492]

Instead of manually modifying your project settings, you can ask CocoaPods to inherit the header search paths from the parent project.

target :MyApp do
  pod 'Foo'
  ...
  target :MyAppTests do
    inherit! :search_paths
  end
end

[DarkoDamjanovic]

@mx4492 Thanks, but then it fails to import the Obj-C BridgingHeader. (it's a Swift project)

[goktugyil]

@DarkoDamjanovic Any solutions to this?

[bejo]

@mx4492 Actually, just adding target :MyAppTests do <...> _within_ target :MyApp do <...> end solved the problem for me. I didn't even have to add inherit! :search_paths.

FYI:

$ pod --version
1.1.1

[Juice007]

you can try pod install again

[icanswiftabit]

Still having this issue at version 1.1.1

target :MyApp do
  pod 'Foo'
  ...
  target :MyAppTests do
    inherit! :search_paths
  end
end

Is not working

My Podfile is looking like this

platform :ios, '9.0'
inhibit_all_warnings!

abstract_target 'All' do
    use_frameworks!
    pod 'Moya', '~> 8.0.2'

    pod 'LayerKit', '~> 0.26.4'

    target 'A' do
    end

    target 'B' do
    end

    target 'C' do
    end

    target 'D' do
    end

    target 'E' do
    end

    target 'Tests' do
        inherit! :search_paths

        pod 'Quick', '~> 1.1.0'
        pod 'Nimble', '~> 7.0.1'
    end
end

plugin 'cocoapods-keys', {
  :project => 'MyProject',
  :target => 'All',
  :keys => [
    'FooKeys'
  ]
}

[DarkoDamjanovic]

I resolved this by adding the header search paths to the test target directly in the Xcode build settings.

[icanswiftabit]

True this does fix the issue but shouldn't cocoapods resolved it?

[DarkoDamjanovic]

@icanswiftabit Yes, this should be resolved by CocoaPods. But - it does not work for me, so this is a fallback solution. The downside - you need to manually keep track of changes on header search paths.

[Sunshine-Rain]

thanks @jessecurry ，it's work.