Swift 5.3 lets packages own their runtime resources

A library that needs a data file has not been fully integrated when only its code links successfully. The file must arrive with the application, and the library must be able to find it without knowing how that application was packaged. Swift 5.3, released on September 16, addresses this through SwiftPM resource support. The design makes resources part of a target and gives that target a generated way to locate its resource bundle.

The same release permits binary targets distributed as XCFrameworks on Apple platforms. These changes broaden the kinds of dependencies a package can describe. They also make distribution contracts more explicit. Source code, runtime data and prebuilt machine code place different requirements on a build system, even when an application consumes all of them through one package manifest.

I find Swift more useful when a library's implementation details stay local to the library. Resource lookup previously required assumptions about the consuming application's layout. Giving a target responsibility for its resources makes that boundary easier to maintain, particularly when the same library can be linked in different ways.

Resources belong to the target using them

SE-0271 explains the central difficulty. A package can become a dynamic framework in one application and statically linked code in another. It cannot safely assume that the bundle containing its code also contains its resources. The build system needs freedom to choose a suitable layout for the final product.

The proposal associates resources with ordinary targets and test targets. A test fixture can therefore belong to the tests that use it, without becoming a resource shipped with every consumer of the library. Resources used by the library belong alongside the source target needing them at runtime.

This avoids requiring separate code and resource targets for a library with one data file. It also accommodates resource processing that generates source code. The relationship remains attached to the target whose compilation and runtime behavior depend on that material.

Resource paths are relative to the target directory. The manifest adds a resources parameter accepting resource rules. An illustrative target declaration can copy a directory whose internal structure must remain intact:

// swift-tools-version:5.3
import PackageDescription

let package = Package(
    name: "Templates",
    products: [
        .library(name: "Templates", targets: ["Templates"])
    ],
    targets: [
        .target(
            name: "Templates",
            resources: [.copy("Assets")]
        )
    ]
)

Here, the conventional target directory is Sources/Templates, so the copied directory is Sources/Templates/Assets. The example assumes that directory exists. Declaring a resource gives it a role in the package build, rather than making an arbitrary path elsewhere on the development machine available at runtime.

Copying and processing express different intent

The copy rule preserves the selected file or directory as-is. When the path names a directory, its structure remains intact in the resource bundle. That suits content whose directory organization is meaningful to the code loading it.

The process rule lets the build system apply platform-specific handling. A directory selected for processing is traversed recursively and its files receive the appropriate rules. Without specialized processing, a file is copied by default. A package author can consequently allow optimization where the platform supports it without embedding those tool invocations in library source.

The distinction matters when a resource is more than an opaque byte sequence. A platform-specific asset can need compilation before an application uses it. Swift 5.3 supports generic resources across platforms, while resource types specific to Apple platforms require Xcode processing. A manifest declaration does not make an Apple resource compiler available on every host.

The proposal also explains why the package manager should not blindly ship every unrecognized file under a target. An image may be an application resource or an illustration accompanying internal design notes. File extension alone cannot determine the author's intent. Explicit resource and exclusion decisions reduce the risk of including unintended files in a distributed product.

This is a useful tradeoff for reusable packages. Some manifest maintenance becomes necessary, but the package describes what it means to distribute. A directory of source material can contain documentation that has no runtime role. Including that documentation should be a deliberate choice rather than a consequence of broad copying.

Bundle lookup is generated inside the module

SwiftPM generates an internal static module property on Foundation's Bundle for a module containing resources. Its implementation knows the selected product layout and instantiates the appropriate bundle. Package code can use the familiar Foundation lookup operations through that property.

For example, code inside a resource-owning target can locate a settings file with the generated accessor. The optional result still needs handling by the caller:

import Foundation

let settingsPath = Bundle.module.path(
    forResource: "DefaultSettings",
    ofType: "plist"
)

The package does not hardcode the generated bundle's name or assume its position relative to the executable. That abstraction is the main portability benefit. A build system can alter the physical arrangement while preserving the lookup API available to the target.

The accessor is internal. Each module receives its own implementation, so identically named accessors in separate packages do not conflict. A package wishing to expose resources directly to clients can publish its own API returning the bundle or a particular resource. It has to make that distribution decision explicitly.

A module without resources does not receive this generated property. That makes Bundle.module part of the package build's generated context, rather than a universal Foundation property available in any Swift source file. Moving code between modules also requires moving or reassigning the resources it expects.

I like the scope of this initial design. It solves location without claiming that string-based resource names become statically checked. The proposal describes typed resource access as possible future work. In this release, a misspelled file name can still produce a failed runtime lookup, even though finding the correct bundle no longer depends on application layout assumptions.

Binary targets solve a different distribution problem

SE-0272 focuses on libraries that cannot be distributed as source. A package can declare a binary target through a local path or a remote URL. The initial artifact format is XCFramework, and the implementation is restricted to Apple platforms.

A remote artifact declaration includes a checksum. That ties the expected bytes to the package manifest, so downloading a different archive from the same location does not silently become an accepted update. The package manager provides swift package compute-checksum to calculate the value for an artifact file.

The checksum answers whether the downloaded archive matches the declared archive. It does not establish that the binary is correct or appropriate for the application. A consumer still relies on the library vendor for the implementation. The proposal's scope is consumption of vendored binaries, including a package that combines a binary C library with Swift source bindings.

It deliberately separates that use from a general cache of compiled source packages. Replacing a source build with a cached result raises further questions about matching the source and build configuration. A binary target is a package's explicit distribution choice, not a claim that SwiftPM can substitute any prebuilt artifact for any source dependency.

Remote artifacts use a zip archive with the XCFramework at its root. The module name must match the target name declared in the manifest. Local artifacts can use either an archive or a raw XCFramework. These requirements make the manifest and artifact contents parts of one distribution contract, even though they may be hosted separately.

The proposal does not provide a build process for creating the binary itself. A vendor remains responsible for assembling a valid artifact. Package consumption consequently begins after that build and packaging work, with SwiftPM retrieving the declared object and incorporating it into the dependency graph. The checksum ties that retrieval to the expected bytes.

This boundary also affects version management. Changing an archive in place changes the object the manifest describes, even if its URL stays the same. A versioned distribution needs an artifact whose content and declared checksum agree, so consumers can identify what their dependency graph actually contains.

Platform support has precise boundaries

The release announcement distinguishes available language and package features from forthcoming toolchain distribution. Swift 5.3 ships with Xcode 12 and downloadable Linux toolchains. The official Windows toolchain is described as arriving in the coming weeks. The release broadens platform work without making every artifact available on announcement day.

Resource portability and binary portability also have different limits. Generic resource handling can work across supported platforms because the package uses a generated lookup contract. An XCFramework remains an Apple-platform binary distribution format in this implementation. A library author choosing between source and binary targets therefore makes a portability decision that consumers inherit through the package graph.