[Accepted with Modifications] SE-0272: Package Manager Binary Dependencies

I agree with this. Tracking SPM properly is currently very difficult. It would be great to see the changes per version and better understand when things are released.

Please correct us if we’re missing something we should be seeing.

In terms of when things are officially released, I think proposals are updated to indicate when they are implemented and in which version they are available.

Thanks @hartbit.
That means that these evolution proposal:

Are not currently fully implemented ?

There are all implemented, but only SE-0226 is in an announced Swift version (5.2). I'll make sure that proposal is updated. The other proposals are implemented in master and will appear in the major Swift version after 5.2, although that version hasn't be announced yet.


will appear in the major Swift version after 5.2

Just to be sure: this means 6.0, and not 5.3, so it could be relatively far away. Correct?

As Ted has already commented on package resource support coming in 5.3 (SE-0271: Package Manager Resources - #74 by tkremenek) I'd guess that binary dependencies will also come in 5.3.


Correct. Package Manager Resources will come in 5.3


how about binary dependencies? i see no reason for shipping those in different releases as they are needed for SPM to take off

Binary dependencies will also come in 5.3



Great news all around! SPM will become the default dependency manager for Apple platforms with Swift 5.3. Monumental! Congratulations to @hartbit and the rest of the team for making it happen.


Binary dependencies is a fantastic feature!
Is there a way to specify system dependencies for static frameworks? I.e. I have a static framework(inside an xcframework) I want to make an SPM package and it has some dependencies like CoreLocation.framework and libsqlite3.dylib.

We didn't actually consider that use case, but I think there might a suitable workaround:

  • declare the binary target as you would for your static framework
  • create a regular target with a dummy source file that declares the additional build settings and depends on the binary target
  • create a product that vends the regular target
  • clients depend on that product and import the module of the binary target, they should get the additional linker flags from the regular target.

I haven't tested this myself, so please report back on your success with this!

1 Like

Thanks for the answer. Actually, I had tried this but with no success. It seems that linker settings only applied to that dummy sources. I've just tried to play with linker settings one more time and still no results. And also I don't see libraries and frameworks in Xcode's build log so maybe I do something wrong.
Another problem is that the framework I try to wrap in a package is ObjC one with some categories that don't work without -ObjC in linker flags. The only way I can set this flag is .unsafeFlags() but this option produce an error during import in Xcode project.

Binary dependencies is a great feature and will hopefully allow me to add SwiftPM packages for several SDKs. However, I have a couple challenges:

  • It isn't possible to reference an XCFramework other than at the root of a zip. This means we have to upload multiple zips for different variations of the SDK (static, dynamic)
  • There is no way to provide credentials for HTTP authentication. Cocapods uses .netrc.
1 Like

Is there any way for a binary target to declare dependencies so that any transitive dependencies needed by a downstream project are resolved?

If I understood correctly, binary only states the way the package is going to be deployed/consumed. So the transitive dependencies should be declared, normally, in your Package.swift. When you add the library dependency to your project, Xcode detects all transitive dependencies, download them and pack them. So just add to your package file your dependency, just like:

    dependencies: [
        // Dependencies declare other packages that this package depends on.
        .package(url: "https://github.com/DeclarativeHub/Bond.git", .upToNextMajor(from: "7.4.1"))

I have the same question here.

How do we authenticate ourselves when trying to consume a binary dependency stored in an artefact repository other than Github? Is authentication unsupported for "external" binaries?

I guess it depends what authentication we are talking about. I haven't tested it, but a basic auth embedded in the URL should work.

Thanks for the quick reply David. I my case (using Artifactory) I think URL based authentication is not supported on their side. I've noticed there is a PR opened to add netrc support to Swift tools, which would definitely solve my problem. I'll wait for that. For anyone interested: Add support for Netrc for Downloader by sstadelman · Pull Request #88 · apple/swift-tools-support-core · GitHub

1 Like