Skip to content
Patch Docs

Set up with AI

An AI coding assistant can install Patch for you: hand it one of the prompts on this page and it runs the documented onboarding itself. The prompts drive the same Quick Start flow — install patchcli, run patchcli init (which registers the app, adds the PatchSDK package, injects Patch.configure(…), and makes your SwiftUI views patchable), then ship an update with patchcli release. There is nothing AI-specific to install; the assistant is only driving the CLI. Claude Code, Cursor, Windsurf and GitHub Copilot all work.

Prompt — assistant with terminal access

Section titled “Prompt — assistant with terminal access”

Use this if your assistant can run shell commands (Claude Code, Cursor agent mode, Windsurf Cascade, etc.). Copy it, paste it into the chat, and let it run the CLI.

paste into your AI assistant
Please set up Patch (OTA over-the-air code updates for native Swift iOS apps)
in this project. The official docs are at https://docs.patchrelease.com
(LLM-readable: https://docs.patchrelease.com/llms.txt and
https://docs.patchrelease.com/llms-full.txt). Follow the real onboarding flow:


1. Install the CLI with Homebrew:
       brew install patch-release/tap/patchcli
   Then install the Swift→WebAssembly toolchain it needs (one command,
   verifies checksums):
       patchcli setup


2. From this project's root directory, run:
       patchcli init
   This single command will: detect the Xcode project/target/bundle id;
   register the app via a browser link flow (it opens
   app.patchrelease.com/cli-connect — I'll sign in and click "Register app",
   and the CLI receives the app key automatically); add the PatchSDK Swift
   package (https://github.com/patch-release/patch-swift); propose a diff that
   inserts Patch.configure(appKey:appID:fingerprint:) plus
   Patch.shared.start() into my @main App struct (ask me before applying);
   and make my SwiftUI views patchable (route each view body through Patch +
   generate the route thunks). Note: this view-prep step ALSO runs
   automatically on every "patchcli release" / "push" / "build", so views I
   add later are picked up with no extra step — I never have to remember to
   run "patchcli prepare" manually.
   Useful flags: --yes (accept the code diff automatically), --no-open
   (don't auto-open the browser), --skip-package / --skip-code (skip a step),
   --manual (just print the manual steps). Do NOT pass --yes unless I ask.


3. Verify the setup:
   - The PatchSDK package is added to the Xcode project (and the project
     still resolves/builds).
   - "import PatchSDK" and a Patch.configure(...) + Patch.shared.start() call
     exist in my @main App struct's init().
   - my view bodies are routed (`__patchRoute { … }`) and the route thunks were
     generated. (This re-runs automatically on every "patchcli release" so views
     I add later are picked up; I can run "patchcli prepare --check" in CI to
     verify, or pass "--no-prepare" to opt out.)
   - .Patch.yml exists in the project root with app_key / publish_token / app_id.


4. After my next App Store build, I should run "patchcli fingerprint register"
   once to baseline the native shell (pushes are gated on this fingerprint).


Then explain, briefly, how I ship an update: I edit my Swift normally, then run
   patchcli release --rollout 10 --message "what changed"
which builds the WASM module, checks the fingerprint gate, uploads, and
activates it to 10% of devices — no App Store review. The on-device SDK fetches
and hot-swaps it on next launch. I widen the rollout with the dashboard or CLI,
and "patchcli rollback" reverts instantly.


If any step can't run (no Homebrew, no network, an unusual project layout, or a
UIKit AppDelegate app), tell me exactly which step failed and fall back to the
manual instructions at https://docs.patchrelease.com/quickstart/#manual-setup-the-fallback.
Don't invent
flags or steps — only use what's in the docs above.

Prompt — assistant without terminal access

Section titled “Prompt — assistant without terminal access”

Use this if your assistant edits files but can’t run a shell (e.g. an in-editor chat with no command execution). It will make the in-project code changes and hand you the two commands to run yourself.

paste into your AI assistant
Help me set up Patch (OTA over-the-air code updates for native Swift iOS apps)
in this project. You can't run shell commands, so do the file edits you can and
give me the exact commands to run myself. The docs are at
https://docs.patchrelease.com (LLM-readable:
https://docs.patchrelease.com/llms.txt). Follow the real flow:


1. Tell me to run these two commands in a terminal myself, in this order:
       brew install patch-release/tap/patchcli
       patchcli init
   Explain that "patchcli init" does most of the setup automatically:
   registers the app in the browser (app.patchrelease.com/cli-connect), adds the
   PatchSDK package, proposes the Patch.configure(...) code diff, and makes my
   SwiftUI views patchable. Tell me this view-prep step also runs automatically
   on every "patchcli release" (so views I add later need no extra step), that
   it's safe to re-run, and that it falls back to printing manual steps if
   anything can't be done automatically.


2. As a fallback (the manual path at
   https://docs.patchrelease.com/quickstart/#manual-setup-the-fallback),
   prepare these edits so I'm
   ready either way:
   - In Xcode I'll add the Swift package
     https://github.com/patch-release/patch-swift (product PatchSDK, from 1.8.0)
     via File → Add Package Dependencies… — or add it to my Package.swift if I
     have one; show me the Package.swift dependency + target lines.
   - In my @main App struct, add "import PatchSDK" and, in init(), call:
         Patch.configure(.init(
           appKey: "pak_…",        // from .Patch.yml after I run patchcli init
           appID: "…",             // baked in by patchcli init
           fingerprint: "…"))      // this build's native shell
         Task { await Patch.shared.start() }
     Show me the edit in context against my actual App struct.


3. Tell me that after running "patchcli init" I should confirm a .Patch.yml file
   appears in the project root with app_key / publish_token / app_id, and that my SwiftUI view
   bodies were routed through Patch. (This view-prep re-runs automatically on every
   "patchcli release", so I never have to remember it when I add new views.)


Then explain how I ship an update: edit Swift normally, then run
   patchcli release --rollout 10 --message "what changed"
which compiles the change to WebAssembly and ships it as an OTA patch (no App
Store review); the SDK hot-swaps it on next launch, and "patchcli rollback"
reverts instantly. Don't invent flags or steps — only use what's in the docs.
Section titled “Related”