Compile xcframework as static library

[c128128]

Hey guys,

First, thank you.

Would it be possible to compile the xcframework using MACH_O_TYPE=staticlib?
Right now, it’s built as a shared library, which leads to some tricky situations during integration. Building it as a static library would help avoid those issues, and if needed, it can still be used as a dynamic library by wrapping it in a dummy framework.

[R4N]

Hi @c128128

Apologies for the delay in responding.

Just to clarify, are you asking to have the binaryTarget be an xcframework which wraps static libraries for each platform/architecture?

With the introduction of Apple Silicon Macs, all the iOS slices can't be combined into a single static library due to conflicting architecture types -- i.e. iOS device (arm64), iOS simulator targeting Mac Silicon (arm64) so wrapping it in a xcframework would be required.

Would you outline some details with an example or two of the tricky situations you're encountering when integrating?

[c128128]

Hi @R4N,

Right now it’s built as a dynamic library, which causes issues with SwiftPM.

In my setup:

• I have a local Swift package that depends on SQLCipher.swift
• That local package is included in a Shared.framework
• Shared.framework is a dependency for my main app

Normally, that should be enough if the binary was built as static. But in the current setup, I also need to add and link SQLCipher manually to the main app and any other targets that use it.

If I don’t, the app crashes at startup with:
dyld: Library not loaded: @rpath/SQLCipher.framework/Versions/A/SQLCipher

Also, having multiple dynamic libraries increases app startup time, so using static libraries would help there as well.

This could be avoided by building each framework slice with MACH_O_TYPE=staticlib during the xcodebuild archive step, and then packaging those outputs with xcodebuild -create-xcframework.

[R4N]

@c128128

Thanks for outlining the further details of your configuration, the integration issue you're running into, and some of the benefits to staticlib.

I re-created your setup in a local test project, but before it even got to any loading errors, the consuming application threw a build error that it's unable to find the SQLCipher module:

error: Unable to resolve module dependency: 'SQLCipher'

This occurs with all different combinations of SQLCipher.frameworks static/dynamic and the wrapper framework being static/dynamic.

I suspect you're internalizing the import of SQLCipher to within the framework itself? i.e. the class(es) you're importing SQLCipher into within the framework are the internal keyword for the import:

internal import SQLCipher

Which allows it your setup to work when using staticlib type for SQLCipher without adding the dependency to the top level application.

There are pros and cons to using dynamic vs static Frameworks. You've already outlined a couple of the benefits of static Frameworks, but dynamic frameworks also have some benefits -- reduced app size/efficient memory usage if the framework is reused shared by another executable in the same bundle (i.e. extensions), reduced compile times. In your setup, if your consuming application included another framework which also had dependency on SQLCipher, static linking would duplicate it whereas dynamic would just include the one copy in the top level app.

We've seen other Swift Packages (and Apple's documentation example code) include two targets, one static and one dynamic (for the actual library linking rather than the binaryTarget within like you're mentioning here). That is something we might consider for the future (two targets: one for a static Framework binaryTarget and one for a dynamic Framework binaryTarget), although it does slightly complicate the integration steps for consuming applications as they would need to select which target to use (and not both)

Mergable libraries were also introduced in WWDC23: https://developer.apple.com/documentation/xcode/configuring-your-project-to-use-mergeable-libraries but they are only available Xcode 15+ so that wouldn't work for consumers on older Xcode versions.

I'm going to keep this issue open for a few weeks in case you (or anyone else) has additional feedback.