Organizing a framework with multiple public modules

Using Swift
1

I have a library that has two modules, LibG and GComponent. I've compiled them into a framework with the following structure:

- LibG.framework/
  - LibG
  - Modules/
    - LibG.swiftmodule/
    - GComponent.swiftmodule/
    - LibG.modulemap
    - GComponent.modulemap
  - Headers/
    - LibG-Swift.h
    - GComponent-Swift.h

If LibG's swiftinterface contains import GComponent, I get the following error:

[...]/.build/x86_64-apple-macosx/debug/LibG.framework/Modules/LibG.swiftmodule/x86_64-apple-macos.private.swiftinterface:4:8: error: no such module 'GComponent'

If I only use @_implementationOnly import GComponent, the import doesn't appear in my swiftinterface and the code compiles, but I'd like to able to import the module in other code without resorting to Objective-C headers.

Is there something I'm missing in how to expose these modules to Swift?

2

(I'm going to assume that the first line is meant to be LibG.framework, not LibG.xcframework, since the file structure shown here is more analogous to the former.)

Due to the way module loading/searching is implemented w.r.t. frameworks on Apple platforms, a framework can only expose a single module and the framework's name must match the module's name. If you want to distribute LibG and GComponent in a way that clients can import either or both of them individually (if GComponent is not simply an implementation detail of LibG), then you must separate them into LibG.framework and GComponent.framework.

3

Thanks. That's a bit of a bummer. Do you know if there are workarounds either by fitting multiple frameworks in an xcframework or embedding GComponent as a full framework inside LibG.framework?

The thing I'm trying to avoid is having to distribute three zip files, LibG.xcframework.zip and GComponent.xcframework.zip for SPM and a combined zip for CocoaPods since it doesn't support multiple sources.

4

One thing to note, was curious to see if mergable libraries produced a novel solution here, but it doesn't. Merged frameworks don't contain modules for their dependencies, so you can't distribute a merged framework for development. Instead, the dependency graph in Xcode uses the modules from the mergable frameworks for compiling and the merged framework for distribution.

5

Why? In either case, the user just has to add 1 entry in their Package.swift/Podfile. You can also have 2 podspec files, so you only need 2, not 3, see example: GitHub - firebase/firebase-ios-sdk: Firebase SDK for Apple App Development

6

That is a wildly complicated example project, but you can see even there that they have this issue:

The podspec for GoogleAppMeasurement uses a single tarball with two frameworks, while the SPM package bundles them individually as GoogleAppMeasurementIdentitySupport.zip and GoogleAppMeasurement.zip.

It's a matter of tradeoffs where either you're hosting more zip files or distributing more packages. I was hoping that the distinction between products and targets in Swift would let me avoid that complexity, but it's sadly not the case.