Thanks folks for putting this pitch together! We (the Firebase team) are excited as this would unblock us from fully supporting SwiftPM for all our SDKs. When it comes time for implementation, we'll ensure this works as expected for Firebase SDKs. A few thoughts and comments as it relates to supporting Firebase's use case:
API for Package.swift
No large concerns here. Having
allowsBinary is fine, although I imagine most folks will copy paste from a getting started guide without much thought so I'm not sure how effective it will be for the goal of being more secure.
I believe the API would also allow for our existing scenario of a binary target depending on a source based target (i.e. FirebaseAnalytics depending on FirebaseCore) so that's great!
Format of the artifact/artifact manifest:
We'll likely have to ship XCFrameworks anyways (and potentially shift to only XCFrameworks when Xcode 11 is a requirement to submit to the App Store in order to simplify our packaging), so this isn't a concern for us.
(EDIT: Not Needed) Multiple XCFrameworks per binaryTarget
One thing that could be helpful though is providing a zip file with 1 or multiple XCFrameworks instead of limiting to just one. This would match our existing strategy with CocoaPods (example in the FirebaseAnalytics podspec).
Our current approach on CocoaPods allows us to modularize our builds and SDKs without having to publish multiple podspecs for a single product SDK. It's not a dealbreaker but would prevent us from having individual
XCFrameworks that wouldn't make sense to expose to developers on their own.
Edit: As pointed out by @NeoNacho, targets aren't visible to end users and we can package multiple
.binaryTargets in a product to achieve this. A single
xcframework works for us.
Re: @NeoNacho's idea:
A simple way of doing it could be an URL prefix match, one could opt-in to a specific release by specifying the whole URL, a specific project (in the GitHub sense) by something like "https://github.com/firebase/firebase-ios-sdk/" and into a whole org by "https://github.com/firebase/". This might address @Jon_Shier's concern a little bit as well, as someone using Firebase could opt-in to allowing any binaries from the Firebase org.
This is interesting and could work well for us (although our main binary distribution mechanism isn't via GitHub but our own servers,
https://dl.google.com/firebase/sdk/ios). This could easily be documented in our getting started guide but I could see it being missed as some of our other instructions are missed regularly.
One issue I foresee is communication when a new dependency is added: if FirebaseAnalytics or another SDK has a new binary dependency on another Google package that lives outside of the Firebase URL scheme, the error messages would be important and include as much detail as possible to help the developer. On the Firebase side we're extremely careful about adding dependencies but we have on occasion restructured our frameworks to be easier to build, modularize, etc and this could be a support burden when doing this internal work.
Overall we'd be fine without any additional security added since that's the current state of other package managers but would support something like URL prefix matching.
No comments here, not enough context and it doesn't currently apply to Firebase, if ever.