Cocoapods: [1.5.0, static libs] Mixed Objective-C/Swift pod fails to import Swift from Objective-C

Created on 6 Apr 2018  ·  26Comments  ·  Source: CocoaPods/CocoaPods


🌈

First, a lot of thanks for this feature ❤️

Report

What did you do?

  • Update to CocoaPods 1.5.0
  • Remove use_frameworks! from Podfile

Pod setup: one Pod TestLib with mixed Swift/Objective-C code. Objective-C files import Swift code with #import <TestLib/TestLib-Swift.h>.

What did you expect to happen?

The project would build.

What happened instead?

The project failed to build with error 'TestLib/TestLib-Swift.h' file not found.

CocoaPods Environment

Stack

   CocoaPods : 1.5.0
        Ruby : ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-darwin14]
    RubyGems : 2.4.6
        Host : Mac OS X 10.13.4 (17E199)
       Xcode : 9.3 (9E145)
         Git : git version 2.15.1 (Apple Git-101)
Ruby lib dir : /Users/maximelemoine/.rvm/rubies/ruby-2.2.1/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 4ddb0bcf3b52ed9ff3e40a475fb06d9dc264bcfe

Installation Source

Executable Path: /Users/maximelemoine/.rvm/gems/ruby-2.2.1/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-packager    : 1.5.0
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0

Podfile

# Uncomment the next line to define a global platform for your project
platform :osx, '10.10'

#use_frameworks!

target 'TestSwiftImport' do

  pod 'TestLib', :path => '.'

end

Project that demonstrates the issue

https://github.com/MaximeLM/TestSwiftImport

hard confirmed

Most helpful comment

I disagree, this issue should remain open. The __has_include workaround is helpful, but forcing pod authors to deviate from Apple docs doesn’t seem great if it’s possible for CocoaPods to configure build settings appropriately. The ideal fix is to have libraries build as-is.

If that’s not possible then some documentation is probably warranted.

But I didn’t open the issue so I can’t exactly go making demands everywhere :)

All 26 comments

This is a known issue you can workaround it via #import "TestLib-Swift.h" instead.

... or just use cocoapods 1.4

sure, you do you @Zmeu213

@dnkoutso (:

@dnkoutso ok, I'll use the workaround

@dnkoutso you say this is a "known issue", is there an issue open already?

@MaximeLM apologies meant meant internally and we should keep this open.

Same Issue +1

@MaximeLM
@dnkoutso

Did you realize that the more serious problem is: As a pod author, you can not limit user how to use!

use_frameworks!
//to be
#import <TestLib/TestLib-Swift.h>
//remove use_frameworks!
//to be
#import "TestLib-Swift.h"

So The temporary solution is:

#ifdef  AMacro
#import "TestLib-Swift.h"
#else  
#import <TestLib/TestLib-Swift.h>
#endif

//And find ways to inject 'AMacro' into your application

Another serious problem is:
@dnkoutso
When using swift, the lint function Cocoapods provide is compiled to dynamic framework?Why not lint by static library? Although using macros can solve this problem. When lint is a dynamic library, use <>. In the other case, "" is used.

At work , when we want to gradually migrate to use swift, we have to rely on libraries that were previously written with objc. It is OK! But we should try to avoid this situation: objc and swift are mixed and objc still needs to call swift.
Unfortunately, I am the one. @MaximeLM too.

I'd recommend using #if __has_include to differentiate between them

@orta
You got wright way!!!
Thank you,I learned.

I think this issue could be close.

I disagree, this issue should remain open. The __has_include workaround is helpful, but forcing pod authors to deviate from Apple docs doesn’t seem great if it’s possible for CocoaPods to configure build settings appropriately. The ideal fix is to have libraries build as-is.

If that’s not possible then some documentation is probably warranted.

But I didn’t open the issue so I can’t exactly go making demands everywhere :)

Will keep it open.

@nolanw
I think it is so hard ... But I agree you said!
I hate protobuf by using use_framework!. I use swift so I have to use_framework until the release of [email protected].

I can finally avoid using the disgusting macro (GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS) to use both swift and objc-protobuf. There are some issues so I can not use swift-protobuf.

So the protobuf author must be very happy to hear: cocoapods can make libraries build as-is!

@orta thanks! What I end up using in our private pod is:

#if __has_include("TestLib-Swift.h")
    #import "TestLib-Swift.h"
#else
    #import <TestLib/TestLib-Swift.h>
#endif

Of course, this workaround is only possible for pod authors.

Is there a final say on this issue yet?

I'm not a fan of adding the hack, since I've already in this life experienced situations where such hacks break in edge cases, and considering this world of mixed package managers, unexpected things happen.

But, if that's the only way this is going to work, I'll do it.

We haven't found a better way yet

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

@dnkoutso I am trying to include socket.io swift client using cocoapods in my existing project which has already Objective C pods and my project is in Objective C. When I do so I get the error "module map file '/Users/.../Library/Developer/Xcode/DerivedData/BCFramework-aecawjeshbaibfeekdiasoxrrcjz/Build/Products/Debug-iphoneos/Socket.IO-Client-Swift/SocketIO.modulemap' not found"

One thing to note here is that I am creating a custom framework instead of an application. Please suggest how should I proceed.

@ChiragBhutani1988 what you're describing sounds like a different issue - could you open another issue with a sample project + steps to repro? thanks

@amorde It appears this is broken in cocoapods 1.5.3. I was having trouble getting it to work in the attached project with the proposed workaround, and so i tried to revert to 1.5.0 via gemfile. After a clean and rebuild it worked. Going back to 1.5.3, clean, build, doesn't work again.

@fer662 what exactly is broken? there are a few things discussed in this issue.

@amorde sorry for being unspecific. The import for for "LibName-Swift.h" works on 1.5.0, but results in a file not found in 1.5.3, where LibName is a swift pod integrated as a static library.

Noticing the same problem with 1.6.1. Create an empty ObjC project, then add a Swift pod and do not set use_frameworks!. Now try to #import "LibName-Swift.h" and you get not found. I tried with a couple of different Pods including AlamoFire. Interestingly enough I do see the "LibName-Swift.h" file in the build folder, but for some reason it isn't found by Xcode. So the solution I assume is to get this file generated/moved to the correct folder to be found, OR make a change to the project so it can find it.

Tried #import "PromiseKit-Swift.h", doesn't work. Any other workarounds?

I'm also seeing that the Library-Swift.h file still isn't being generated for static libs on CP v1.8.4. Without it, I'm unable to use the pod as a static lib. Any idea why the workaround from 1.5.0 isn't working anymore?

@dnkoutso I am trying to include socket.io swift client using cocoapods in my existing project which has already Objective C pods and my project is in Objective C. When I do so I get the error "module map file '/Users/.../Library/Developer/Xcode/DerivedData/BCFramework-aecawjeshbaibfeekdiasoxrrcjz/Build/Products/Debug-iphoneos/Socket.IO-Client-Swift/SocketIO.modulemap' not found"

One thing to note here is that I am creating a custom framework instead of an application. Please suggest how should I proceed.

I have the same issue but can't find if @ChiragBhutani1988 has create a separate issue or not...

Was this page helpful?
0 / 5 - 0 ratings