Implicit Import of Framework Bridging Header deprecation

Just updated to Xcode 8.3, Swift 3.1 today. I have a Swift framework I maintain and use— it's basically all Swift but I do need to use SQLite from within it. I accomplished this by adding a bridging header to the framework which contains only:


#ifndef MyFramework_Bridging_Header_h
#define MyFramework_Bridging_Header_h

#import <sqlite3.h>

#endif / MyFramework_Bridging_Header_h */


This seemed to work fine. Now however, I am getting the following compiler warning on one of my "import MyFramework" directives:


Implicit import of bridging header 'MyFramework-Bridging-Header.h' via module 'MyFramework' is deprecated and will be removed in a later version of Swift.

What is the proper way to get rid of this? Is there some way to explicitly import the bridging header?

Thanks!

Post not yet marked as solved Up vote post of Ironwolf Down vote post of Ironwolf
10k views
Posted by
Ironwolf
Reply
Add a Comment

Replies

I'm also confused by this.


I have a mix-and-match project, and have some Unit Tests written in Swift. They test classes in my app target, so I have marked the import statement as testable:


@testable import mymodule


That module has a bridging header... so I'm getting the same warning as you. I'm not sure of how to fix it. In the Xcode release notes it says:


Swift 3.1 includes a new warning of the form "implicit import of bridging header … via module … is deprecated and will be removed in a later version of Swift". This warning is no longer reported too frequently in contexts where it may not be easy to correct. (30202509)


And then I found this bug: https://bugs.swift.org/browse/SR-3801


Which references this: https://github.com/apple/swift/commit/08af6f0c0933dc70cb868633e2e017b63c12eba1


So from what I can tell in the comments from that second link is that they want to deprecate this implict importing... but I'm not sure of what that means for how I should get rid of this warning.

Posted by
bpapaattheskimm
Post not yet marked as solved Up vote reply of bpapaattheskimm Down vote reply of bpapaattheskimm
Add a Comment

Same issue here, what is confusing is that the @testable import flags an error in some test modules but not others.

Posted by
ckhpdx
Up vote reply of ckhpdx Down vote reply of ckhpdx
Add a Comment

I found a solution that works for us. Remove the @testable bit, however, you then have to include the main app's bridging header in the test target's bridging header.


So in MyAppTests-Bridging-Header.h


//

// Use this file to import your target's public headers that you would like to expose to Swift.

//

#import <UIKit/UIKit.h>

#import "KANoteTypeTableBase.h"

#import "MyApp-Swift-Bridging-Header.h"

Posted by
ckhpdx
Post not yet marked as solved Up vote reply of ckhpdx Down vote reply of ckhpdx
Add a Comment
@ironwolf, had you fixed it already?
Posted by
Johan.Bergman
Up vote reply of Johan.Bergman Down vote reply of Johan.Bergman
Add a Comment
I believe the error is stating that :

  1. The test module is implicitly importing your main module's bridging header. You don't need to import it. Everything is OK.

  2. Everything is OK now, but it won't be OK later because this "implicit" import will disappear soon (deprecated) and thus, it's not gonna be OK anymore.

  3. In order to stay OK, you should "explicitly" import your main module's bridging header in your test module's bridging header.

So, in your MyApp-Tests-BridgingHeader.h you should have :

Code Block 
//
// Use this file to import your target's public headers that you would like to expose to Swift.
//
#import "MyApp-Bridging-Header.h"
...

Then, Everything will be OK and will stay OK :)
Posted by
SalahArchipad
Post not yet marked as solved Up vote reply of SalahArchipad Down vote reply of SalahArchipad
Add a Comment