FR: Support for Swift Package Manager

[WarSunsOfPeace]

With iOS support for Swift Package Manager in Xcode 11 can we please get that added to this project.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[ryanwilson]

Hey @w0mba7 - thanks for the report 😄

We're excited and looking into the best way we can support this as soon as we can, but there are a few dependencies and file structure changes we may need to do. We started experimenting with support on a branch at https://github.com/firebase/firebase-ios-sdk/tree/spm-master a few weeks ago and have a better idea of the approach we need.

We also started a discussion on binary framework distribution on the Swift forums but it looks like we may get some more information from a WWDC session this week titled Binary Frameworks in Swift
.

This won't be something we can do overnight but want to support it as soon as we can, there are a few bugs to work out as well (like SR-10707 that I discovered while working on adding support).

[possen]

#2135 linking issues.

[possen]

My experiment was to take the Carthage Binaries and add this to the Targets section but complains that the module map is in the wrong place:

error: package has unsupported layout;modulemap '/Users/user/Projects/RideCore/Carthage/Build/iOS/nanopb.framework/Modules/module.modulemap' should be inside the 'include' directory

moving things around in the folders and renaming did not seem to help.

     targets: [
        .target(
            name: "Core",
            dependencies: ["stuff"],
            path: "Carthage/Build/iOS",
            linkerSettings: [
                LinkerSetting.linkedFramework("FirebaseAnalytics"),
                LinkerSetting.linkedFramework("FirebaseCore"),
                LinkerSetting.linkedFramework("FirebaseDatabase"),
                LinkerSetting.linkedFramework("FirebaseMessaging"),
                LinkerSetting.linkedFramework("GoogleUtilities"),
                LinkerSetting.linkedFramework("leveldb-library"),
                LinkerSetting.linkedFramework("GoogleAppMeasurement"),
                LinkerSetting.linkedFramework("GTMSessionFetcher"),
                LinkerSetting.linkedFramework("nanopb"),
                LinkerSetting.linkedFramework("Protobuf")
            ]

[morganchen12]

Related to #2135

[paulb777]

Follow the progress at https://github.com/firebase/firebase-ios-sdk/commits/spm-master. Suggestions and PRs welcome!

[paulb777]

Much of Firebase Unit Testing relies on OCMock which does not yet support Swift PM. That could be a great place for someone in the community to contribute to accelerate the migration.

[paulb777]

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.