How to import prebuilt frameworks from local project in Swift package?

My org has very large app that currently has appx. internal 40 framework targets, some of which are nested within others, plus another 15 or so Carthage dependencies.

We'd like to transition to using Swift packages instead of frameworks, and using SPM instead of Carthage, but it's not feasible to transition everything at once. We need to migrate in phases.

We'd also like to start implementing any new modules from here on, using Swift packages, so we're not creating tech debt.

Normally in Xcode to link one module against some other module you drag the framework product into the "Frameworks & Libraries" list. Boom, done.

However with Swift packages, it seems the only way to define a dependency is if it's a Swift package AND you have all the source code.

There does not seem to be any way to link a build product (like a framework or library). Since most of our modules depend on prebuilt Firebase modules for analytics, that seems like a dealbreaker, unless I'm missing something.

As well, our CI pipeline currently uses fastlane to cache build artifacts so we don't have to compile everything from source with each run. How can we still take advantage of this if we migrate to using SPM instead of Carthage?

If we have multiple packages, say, that all depend some other package, does Xcode rebulid that dependency over and over when it builds each package?

I believe binary dependencies is coming in Swift 5.3: [Accepted with Modifications] SE-0272: Package Manager Binary Dependencies

I believe binary dependencies is coming in Swift 5.3: [Accepted with Modifications] SE-0272: Package Manager Binary Dependencies

I wonder when this will be available for use in Xcode iOS projects?

Given the usual cycle (perhaps with changes from the current situation), Xcode 12 will have it enabled in some fashion, with a preview in June and shipping in September. Hopefully adding support for this feature is among of multitude of changes to SPM's integration into Xcode by that time.

It depends:

  • generally speaking, packages behave similar to framework targets in that they get build once and not once for each client
  • contrary to framework targets, packages can build multiple times for different platform in the same build operation if needed (e.g. if the same package product is required by an iOS app and a watch extension). This won't have additional overhead, though, with framework targets you would need to create two distinct targets, one for iOS and one for watchOS.
  • in CI, you would build packages again every time, assuming you start off with a clean build. I am not familiar with how fastlane's caching works, but if it caches build products + intermediates, that would apply to packages as well.
Terms of Service

Privacy Policy

Cookie Policy