For Firebase to support Swift Package Manager, there will need to be several changes to both Swift Package Manager and Firebase. See https://github.com/firebase/firebase-ios-sdk/commits/spm-master for the prototype implementation which successfully built a few of the Firebase libraries with SwiftPM. Below is a summary of some of the key requirements:

Binary library support
Some of the Firebase libraries may not open source. Thus for Firebase to completely move to SwiftPM, binary library support must be added, including support for depending on a source-based Package from a binary package. See the Swift forum discussion. The pitch to support framework search paths could provide a workaround.

Resource support
Firebase ML, Firebase In App Messaging and Firebase Firestore require resource support. There may be a workaround for Firestore, but not for the others. See Swift bug.

Separately versioned libraries per repo
Firebase currently separately versions its libraries from a single mono-repo. This could be accomplished with SwiftPM by adding multiple package support to a repo or by adding the ability to version libraries within a package. Xcode would also need to be similarly updated.

Firebase could consider abandoning separately versioning its libraries like it already does for binary and Carthage distributions. This would be especially unfortunate for managing new libraries with zero major versions of semantic versioning.

Build Settings
Some Firebase libraries rely upon being able to build some of their sources with and without Automatic Reference Counting (ARC). There does not seem to be a way to do this. See Forum discussion and Swift build setting proposal.

Module Map Generation
Objective-C modules aren't generated for Objective-C targets. This causes us to rely on changing our import statements to use local header paths instead of framework paths. See https://bugs.swift.org/browse/SR-10707

Testing - OCMock
Most of Firebase unit testing relies upon OCMock which does not yet have Swift Package Manager support.

Subspec support
Firebase relies upon subspecs so that different library combinations can choose different subsets of the GoogleUtilities support library. Now that static libraries/frameworks are better supported, it is probably feasible to split each GoogleUtilities subspec into a separate library.

Private Headers
Firebase uses the CocoaPods/Xcode private headers feature to share non-public APIs across libraries. It might be feasible for Firebase to abandon the use of this feature in favor of repo-relative import paths.

FR: Support for Swift Package Manager #3136

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions