Open source

Patch edits your Xcode project and injects code into your @main App struct. You shouldn’t have to take that on trust, so the engine that does it and the runtime that ships inside your binary are both public.

One repository, two packages

Both live in patch-release/patch-swift. The SDK is the SwiftPM package at the repository root — which is why the package URL you add in Xcode is just the repository URL — and the engine is a second, independent SwiftPM package nested at cli/.

• Directorypatch-swift/

  • Package.swift the SDK — MIT, the package SwiftPM resolves
  • DirectorySources/ the SDK’s targets

    • …
  • Directorycli/ the engine — Apache-2.0, its own SwiftPM package

    • Package.swift
    • DirectorySources/ the engine’s targets

      • …

The SDK — repository rootMIT · Swift 6 · runs inside your app. WasmKit runtime, value marshalling, update lifecycle, host bridges, the SwiftUI renderer.

The engine — cli/ in the same repoApache-2.0 · Swift 6 · runs on your machine or in CI. Partitioning, Swift→WebAssembly compilation, SwiftUI/UIKit lowering, project integration.

Why two licences

The SDK executes a WebAssembly interpreter inside your users’ app, so it has to be maximally auditable and maximally permissive — MIT, no conditions worth arguing about.

The engine is Apache-2.0 rather than MIT for one reason: Apache-2.0 carries an express patent grant. Patch’s partitioning and lowering approach is novel enough that a licence which says nothing about patents is a worse answer for you, not just for us.

What is not open

The hosted control plane — rollouts, cohorts, device targeting, analytics, audit, team accounts — is a commercial service and its source is not published. The SDK will talk to any base URL, so you are not tied to our infrastructure. See Running it yourself.

What’s in the engine

• Directorycli/

  • DirectorySources/

    • DirectoryPartitioningEngine/ decides, per function, what can ship OTA

      • …
    • DirectoryCodeGenerator/ SwiftUI + UIKit lowering to the view IR

      • …
    • DirectoryCompiler/ Swift→WebAssembly pipeline, fingerprinting, upload

      • …
    • DirectoryViewNodeIR/ the wire format the SDK renders

      • …
    • DirectoryPatchCLI/ the patchcli command surface

      • …
  • DirectoryTests/ ~1,700 tests

    • …

The interesting part is PartitioningEngine + CodeGenerator. Everything else is plumbing. If you want to understand how a SwiftUI view body becomes WebAssembly, start at CodeGenerator/SwiftUIClassifier.swift and follow it into SwiftUIEmitter.swift.

What’s in the SDK

• Directory(repository root)

  • DirectorySources/

    • DirectoryPatchSDK/ runtime, loader, fallback chain, update checker, host bridges

      • …
    • DirectoryPatchSwiftUI/ the thunk entry point every generated view calls

      • …
    • DirectoryPatchRender/ reconstitutes the view IR into real SwiftUI

      • …
    • DirectoryPatchViewIR/ the SDK’s copy of the wire format

      • …
    • DirectoryPatchUIKit/ the UIKit equivalent

      • …
  • DirectoryTests/ ~1,000 tests

    • …

One invariant worth knowing

cli/Sources/ViewNodeIR and Sources/PatchViewIR are the same wire format, vendored into both packages. If you change one you must change the other, or a guest module will emit a tree the host cannot decode. The packages carry guard tests for this, and it has drifted before.

Building from source

1. Clone the repository and build the SDK. One clone gets you both packages. Nothing exotic — the SDK is a normal SwiftPM package at the root.

   git clone https://github.com/patch-release/patch-swift
   cd patch-swift
   swift build && swift test

2. Build the engine, the separate package in cli/.

   cd cli
   swift build -c release
   .build/release/patchcli --help

3. Add the WebAssembly toolchain — only needed to actually compile patches.

   patchcli setup

   This installs the pinned swift.org toolchain and the WebAssembly SDK. The Apple/Xcode toolchain cannot target WebAssembly, which is why a second toolchain is required at all.

4. Check the setup.

   patchcli doctor

PATH order matters

Building the CLI for your Mac uses the Apple toolchain; compiling patches uses the swift.org one. If swiftly is first on your PATH you’ll build the CLI with the wrong compiler. patchcli setup and doctor handle this for you — if you’re doing it by hand, put /usr/bin first for host builds and ~/.swiftly/bin first for WebAssembly builds.

Reproducing our coverage numbers

Every coverage figure on this site is generated from a committed measurement, not written by hand. You can re-run that measurement:

./corpus/fetch.sh                       # the corpus apps, at pinned commits
./tools/swiftui-corpus-coverage/run.sh  # the census

corpus/fetch.sh clones each app at the exact commit recorded in corpus/manifest.yml, so the corpus is reproducible rather than a snapshot we happen to have on a laptop. See what Patch can and can’t update for the current results.

Contributing

Issues and pull requests for both packages go to the same repository, patch-release/patch-swift. Two things that make a bug report actionable immediately:

patchcli doctor --json

That prints your setup as JSON — versions, toolchain, and whether the app’s fingerprint is registered. Attach it.

If you’re reporting that a view didn’t patch when you expected it to, the build output already names the blocking reads per view; paste that too.