In an app target, a bridging header does the trick. Inside a framework target, things are trickier.
Out of the box, Swift code can access ObjC code defined in header files which have an #import
inside the frameworks umbrella header. These are also the public header files. If we want Swift to access private classes from within the same framework, we have to dance a small dance.
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 sample project contains an app MyApp which uses a framework called Foo.
The framework does its usual stuff, and in addition there's a directory called FooPrivate
-- this is actually a module. Inside it there's a module.modulemap
file which specifies the ObjC header files with relative paths. The framework target for Foo
has its SWIFT_INCLUDE_PATHS
set to $(SRCROOT)/Foo
which is the parent directory of the FooPrivate
directory.
With this, Swift code can import FooPrivate
and then use (private) ObjC classes.
When Swift code accesses the Foo module created by the framework, it needs to find the FooPrivate module, too.
We can work around this issue by adding
module FooPrivate {
export *
}
to the .modulemap
of the framework. In Xcode this can be done by simply setting MODULEMAP_PRIVATE_FILE
to point to a module map file with this content.
As annotated in the code once you add a private header via a private module import they become public knowledge in swift, not in objective-c do.