FR: Add support for dynamically linked libraries with Swift Package Manager

[Brian-Co]

trafficstars

Feature proposal

• Firebase Component: All

As of today, Firebase integration through Swift Package Manager provides statically linked libraries only. See: https://firebase.google.com/docs/ios/link-firebase-static-dynamic?hl=en

Dynamic linkage has been available through Cocoapods since Firebase version 7.0.0.

Is dynamically linked libraries support for Swift Package Manager planned to be added? And if yes, when could we see that being shipped?

Thanks a lot!

[paulb777]

Just like CocoaPods, there are no plans to support dynamic libraries for the binary part of the distribution (Firebase Analytics). For the rest, it should be feasible, especially if there's a way for the library to control the linking like CocoaPods allows from the Podfile.

With a bit of searching, it's not clear to me if and how it's possible in Swift PM - but definitely open to suggestions and PRs.

[mortenbekditlevsen]

In Package.swift you can add type: .dynamic to a library to have it link dynamically. Some packages supply the same targets as both dynamic and static by giving one of the libraries a different name.

[mortenbekditlevsen]

Not certain how the internal dependencies are handled - of course it's no good if two dynamic libraries statically link to shared functionality...

[paulb777]

Thanks @mortenbekditlevsen. I'm not enthusiastic about doubling the number of Firebase SPM products, but can consider if there's enough interest.

I'd much prefer a solution that lets the library consumer decide like CocoaPods's use_frameworks! and use_frameworks! :linkage => :static alternatives.

[mortenbekditlevsen]

Right - I don't know why control is placed at the point of the author rather than the consumer, but I guess there must be some reason for it to be like that.

[paulb777]

Given Apple's announcements around mergeable libraries at WWDC 23 and associated runtime speedups for dynamic libraries, let's consider switching our binary distribution builds to dynamic libraries in Firebase 11.

[jeffremer]

I'm curious if this would include the transitive Google dependencies or other Google frameworks - currently GoogleAppMeasurement is a transitive dependency for FirebaseAnalytics and GoogleMobileAds, so we're getting duplicate symbol warnings when trying to use FirebaseAnalytics from one target (the main app) and with GoogleMobileAds used by another target (our own Advertising wrapper).

[paulb777]

Yes, GoogleAppMeasurement and other Firebase dependencies will be included.

[ncooke3]

Hi everyone, the upcoming Firebase 11 release will make the transition from using static XCFrameworks to using dynamic XCFrameworks. I'm marking this as closed ahead of Firebase 11.

[mesqueeb]

@ncooke3 @paulb777 If we use the new dynamically linked Firestore SDK for a visionOS app, will we still need to execute open --env FIREBASE_SOURCE_FIRESTORE path/to/monorepo.xcworkspace to open our project? Or will this no longer be required?

[paulb777]

@mesqueeb We still won't have binary distribution support for visionOS - so the open ... command will still be needed.

[mesqueeb]

@ncooke3 @paulb777 thanks for taking time in your schedule, just 3 short questions

1. will dynamically linked swift Firestore module be available with Swift Package Manager?
2. will visionOS be supported for the dynamically linked Firestore module?
3. will a dynamically linked Firestore module increase build times via Xcode? (currently by adding just Firestore module it often takes 30min build time on my macbook air)
4. What's the estimated time of arrival of v11?

[ncooke3]

Hi everyone, I'm reopening this issue as dynamic library support was pulled from Firebase 11. Swift Package Manager's support of binary targets is limited and ultimately does not allow a binary target (vending a dynamic XCFramework) to depend on source targets. There is some related discussion with respect to dylibs and SPM in this thread: https://forums.swift.org/t/swiftpm-binary-target-with-sub-dependencies/40197/28

I'll be working on filing a Feedback with Apple to hopefully see broader support for our use case. For those using other distribution channels like Carthage or the Firebase zip (which are more flexible than SPM), I recommend filing an issue and upvoting accordingly.

[mesqueeb]

@ncooke3 Thanks for the update. Did you see the post where Jeremy David Giesbrecht mentions that SwiftPM issues should rather be reported at the official Swift Github? → https://github.com/swiftlang/swift/issues

No. SwiftPM is part of the open‐source Swift project, so bug reports for it belong at bugs.swift.org.

Please reference this thread when making a new issue on the swiftlang/swift repo! That way we can follow it over there as well : )