Scipio turns your SwiftPM dependency list into XCFrameworks

The gap Scipio sits in between SwiftPM and Xcode

The README puts the problem plainly: SwiftPM is the best way to integrate dependencies into your app, but build artifacts built by Xcode are difficult to cache. On the other side of that, XCFramework is a good way to keep binaries portable. Scipio calls its own answer a hybrid way to manage dependencies, and the sequence is short. First SwiftPM resolves the dependencies and checks out the repositories. After that, Scipio converts each dependency into an XCFramework. The project says it is highly inspired by Carthage and by swift-create-xcframework, and the README section heading borrows the Latin phrase Carthago delenda est as a joke about the predecessor it is trying to displace. The practical consequence for a team is that the dependency graph stays expressed in a single Package manifest, while the artefact handed to consumers is a portable binary bundle rather than a source checkout.

Install and first run

The documented install path is nest, and the command is one line.

nest install giginet/Scipio

The first thing to do is describe the dependencies you want to build in one Package manifest. The README calls this the core concept of Scipio: all dependencies you want to use in your application should be defined in one Package manifest. The example manifest below sets the tools version, names the package MyAppDependencies, restricts the build to iOS 14, and lists APNGKit as an exact-version dependency.

// swift-tools-version: 6.0
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "MyAppDependencies",
    platforms: [
        // Specify platforms to build
        .iOS(.v14),
    ],
    products: [],
    dependencies: [
        // Add dependencies
        .package(url: "https://github.com/onevcat/APNGKit.git", exact: "2.2.1"),

The targets section then names a target MyAppDependency and lists the products to build inside it.

    ],
    targets: [
        .target(
            name: "MyAppDependency",
            dependencies: [
                // List all dependencies to build
                .product(name: "APNGKit", package: "APNGKit"),
            ]),
    ]
)

With the manifest in place you run the prepare command against the package directory.

$ scipio prepare path/to/MyAppDependencies

Scipio resolves the dependencies, cleans the package directory, builds each dependency for the declared platform, and combines the results into an XCFramework. The generated bundles are written to MyAppDependencies/XCFramework by default.

Prepare mode versus create mode

There are two entry points, and the difference is scope. The prepare command builds all dependencies listed in the manifest, which the README calls prepare mode, and the documentation points at a dedicated page for preparing all dependencies for an application. The second command handles a single Swift package, and the README says this feature is similar to swift-create-xcframework.

$ scipio create path/to/MyPackage

So the choose-one-package path is the direct replacement for the standalone tool Scipio was inspired by, while prepare mode is the part with no obvious equivalent elsewhere: one manifest, many dependencies, all of them turned into XCFrameworks in one pass. For a team that already maintains a dependency manifest for its app, that is the mode that removes work rather than the one that replaces a tool.

The cache system and why it changes the economics

By default Scipio checks whether rebuilding is required for XCFrameworks that already exist, and the cache policy is chosen with a flag.

$ swift run scipio prepare --cache-policy project path/to/MyAppDependencies

With that policy in place a cached framework that is still valid is reported as skipped rather than rebuilt. Scipio supports three cache backends, Project, Local Disk and Remote Disk, and the README explains the point of the third one directly: using a remote cache shares built XCFrameworks among developers. That is the feature that turns the tool from a convenience into infrastructure. Every developer, and every CI job, can pull the same prebuilt XCFramework instead of rebuilding the same dependency graph from source. The project cache lives with the project itself, the local disk cache is per machine, and the remote disk cache is the shared one.

Library Evolution is the flag that changes what you can ship

Library Evolution support is off by default, and the reason is spelled out in the README. With it disabled, built frameworks can be used only from products built with the same Swift version. The stated primary reason for the default is that some packages cannot be built with Library Evolution enabled, with links to an Apple developer forum thread and to issues in swift-collections and swift-nio as examples. The counterweight is distribution: if you intend to distribute the generated XCFrameworks, the README says it is recommended to enable Library Evolution, which is done with the --enable-library-evolution flag. The trade is explicit and it cuts both ways. Enabling it gives you binaries that survive a Swift version bump and can be handed to consumers who build with a different toolchain, at the cost of some dependencies failing to compile at all. This is the decision to make before you wire Scipio into a release pipeline rather than after.

Deliberately narrow dependencies, and only Apple official tools

The reliability section states that Scipio only builds with standard dependencies and Apple official tools. Dependency resolution is nothing more than swift package resolve. Parsing package manifests and generating the Xcode project is provided by the swift-package-manager package used as a library, and the README argues that this is a positive because the work will be maintained there rather than in Scipio. Building the frameworks and XCFrameworks themselves is done only with xcodebuild. There is also a notice section: Scipio copies several source files from Swift Package Manager, the copies live in Sources/ScipioKit/SwiftPM, and those copies are licensed under the Apache License. The repository layout is small and conventional, with Package.swift, Sources, Tests, Plugins, .swiftlint.yml, .spi.yml and a LICENSE.md, and the README badges advertise SwiftPM compatibility and support for iOS, macOS, watchOS, tvOS and visionOS.

Toolchain floor and where Scipio is the wrong tool

The supported toolchain is stated without ambiguity: Xcode 26 and later, with Swift 6.2 or later, and Xcode 16.4 is deprecated and no longer tested in CI. The versions exercised by CI are Xcode 26.0.1 with Swift 6.2, Xcode 26.4.1 with Swift 6.3, and Xcode 27.0 with Swift 6.4. The releases move at a steady clip, with 0.33.0 published on 2026-07-21, 0.32.1 on 2026-03-16 and 0.32.0 on 2025-12-24, and the last push to the repository was on 2026-10-19. The wrong-tool cases are just as clear. If your team resolves everything through SwiftPM binary targets and never hands compiled binaries to someone else, the XCFramework step buys you nothing and Scipio is extra machinery in the build. If you are still on Xcode 16.4, the tool does not support your toolchain. And if you distribute binaries to consumers on different Swift versions, the default configuration will not help you, so you need the Library Evolution flag and a dependency set that survives it. Against Carthage, Scipio keeps the dependency graph in a Package manifest rather than in per-project Cartfiles; against swift-create-xcframework, it handles a whole dependency set in one manifest rather than one package at a time, and adds the cache layer that neither of the two provides.

Editorial conclusion

Adopt Scipio if you ship binaries to teams that cannot resolve your dependency graph themselves, since it turns a SwiftPM manifest into portable XCFrameworks with a cache you can share. Skip it if your app already builds cleanly with SwiftPM binary targets, or if you need Xcode 16.4, which is deprecated and no longer tested in CI. Before you commit, try the prepare mode on one dependency, then decide whether to add the --enable-library-evolution flag, since enabling it can break packages that do not compile with Library Evolution.

Frequently asked questions

Official sources

1. giginet/Scipio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases