I\'m trying to centralize my commonly used Swift code into a framework, and part of that code uses Google Analytics. I brought in Google Analytics as a Cocoapod, but I can\'t a
The bridging header file is a specific header file to use Objective-C file into a Swift framework.
You can find more about bridging in the Apple doc :
Xcode creates the header file along with the file you were creating, and names it by your product module name followed by adding "-Bridging-Header.h". (You’ll learn more about the product module name later, in Naming Your Product Module.)
So the only thing you have to make is create that file manually by choosing
File > New > File > (iOS, watchOS, tvOS, or OS X) > Source > Header File.
If the name of your framework is ABC,then the name of the header file should be :
ex : ABC-Bridging-Header.h
You can put it where you want in your framework project.
Hope this can help someone !
For those who have continued to ask if I had solved this problem, the following is how I accomplished this task importing the KochavaTracker SDK Cocoapod into a framework. That SDK is currently written in Objective-C. This answer is based on the answer provided by nuKs, with these specific steps.
1) Create a folder named KochavaTracker under your project folder, i.e. MyFramework/MyFramework/KochavaTracker.
2) Within that folder create a file named module.modulemap and insert the following content:
/*
This is the private module which is used to make private ObjC headers available to Swift code.
Note how all header files need to be specified with paths relative to this file.
This file lives inside a folder, and that folder is the actual module. In Xcode the SWIFT_INCLUDE_PATHS needs to include the parent directory to that folder.
*/
module KochavaTracker {
header "../../Pods/KochavaTrackeriOS/KochavaTrackeriOS/Classes/KochavaTracker.h"
export *
}
This effectively creates a module which is a wrapper for interface of the SDK, which Swift can later import like it does other Swift modules. Note that it relies on a relative path to the Pods folder.
3) As found in build settings, modify your SWIFT_INCLUDE_PATHS to include:
$(SRCROOT)/KochavaTracker
This makes it so that you will be able to import the module and it will locate it in/as the KochavaTracker folder which you created under it.
4) Add to your Swift code, where appropriate:
import KochavaTracker
From there you should be able to reference the classes in the KochavaTracker module.
The solution is not as straightforward as for an app. We have to create a modulemap.
Have a look at this example repo.
Inside Swift code we can only import so called modules. The trick is to define a module which in turn contains all the ObjC headers that we need the Swift code to access.
The module map section of this article may also help you.
As convenient as the bridging header is, it has one key limitation—you can’t use it inside a framework project. The alternative is to use a module.
To do this, create a directory in your project directory named after the library you want to use. I did this in the shell, outside Xcode’s auspices, naming it CommonCrypto. Inside the directory, create a module.map file that encapsulates library settings. For CommonCrypto, module.map looks like this:
module CommonCrypto [system] { header "/usr/include/CommonCrypto/CommonCrypto.h" export * }
Now add the new module to Import Paths under Swift Compiler – Search Paths in your project settings. Use ${SRCROOT} in the module path (e.g. ${SRCROOT}/CommonCrypto) to insure that the project works no matter where it’s checked out.
This makes it possible to just import CommonCrypto in your Swift files. Note that consumers of any frameworks you build using this technique are also going to have to add the module to their Swift search paths.
I followed the procedure in the article above and made it work for my need this way:
module Muse {
header "Muse.framework/Headers/Muse.h"
export *
}
I removed the [system]
lexon for safety (as it removes warning) and put the framework inside the same folder as the module.map file.
Also, don't forget to include libc++.tbd
and other required dependencies in your framework target (in the Linked Frameworks and Libraries
section of the General
tab) if you need them.