Push native iOS updates instantly.

Over-the-air (OTA) code updates for native Swift apps — no waiting for App Store review.

~/MyApp — patch
Trusted by Swift developers from

One command. We handle the rest.

A native-Swift alternative to Expo / CodePush — your React Native friends will be jealous.

01

Install the CLI

02

Run patchcli init in your app

03

Write Swift like always

MyApp.swift
import SwiftUI +import PatchSDK @main struct MyApp: App { + init() { + Patch.configure(.init(appKey: "pak_live_a3f8…")) + Task { await Patch.shared.start() } + } var body: some Scene { WindowGroup { ContentView() } } }

Mobile development at the speed of web. Finally.

Rollback with 1 click

Something off? Roll the whole fleet back to any prior version in one click — instant rollback with no App Store review. Your users will be none the wiser.

Releases · MyApp
v1.4.2 Fix EU tax rounding2 min ago · you live · 47%
v1.4.1 Promo-code stackingyesterday live
v1.4.0 Shipping thresholds3 days ago rolled back

Monitor hotfixes in real time

Adoption, errors, and load — device by device, as each hotfix lands.

Rollout · v1.4.2 · production rolling
0%
rolled out
Devices0 / 4.5M
Errors0.00%
Median load4 ms

Progressive rollouts

Staged rollouts over the air: ship to canary, then beta, then everyone — or A/B a variant to a slice and promote the winner.

Channels · v1.4.2 rolling
Canaryinternal · 1%
100%
Betaearly access
100%
Productionall users
47%

Run from your laptop or CI

Run it by hand for a hotfix — or let every merge to main ship a patch automatically.

From your terminal
~/MyApp — zsh
$ patchcli init # one-command setup $ patchcli release -m "fix EU tax" analyzing 47 files… 73.7% ship-safe compiling → wasm · fingerprint ✓ v1.4.2 live · 28s $ patchcli rollback # undo anytime, <60s
In your CI pipeline
.github/workflows/patch.yml
# release an OTA patch on every merge to main name: Patch OTA on: push: branches: [main] jobs: release: runs-on: macos-14 steps: - uses: actions/checkout@v4 - uses: patch-release/setup@v1 - name: Build & release OTA run: patchcli release --channel production env: PATCH_TOKEN: ${{ secrets.PATCH_TOKEN }}

Move fast and fix things

Start free. Pay as you grow.

Unlimited updates on every plan — hotfix as much as you want.

Hobby
Free
Up to 100 devices
  • Unlimited OTA updates
  • Instant rollback
  • CLI + CI/CD
  • Ship-safety checks
  • Individual workspace — one member
Start free
All features
Startup
$59/month
Up to 10,000 devices
  • Everything in Hobby
  • Phased rollouts
  • Channels — canary, beta, production
  • A/B testing
  • Invite your team — unlimited members
Sign up
Enterprise
Contact sales
Custom pricing · unlimited devices
  • Everything in Startup
  • SSO, priority support & SLA
  • Audit logs & activity feed
  • Dedicated onboarding
Contact sales

Questions, answered.

Yes. It's a common myth that native iOS code can't be updated over the air — that only a React Native (JavaScript) or Flutter (Dart) bundle can — and that's why most guides still say it's impossible. It was true before Patch. Patch makes genuinely native Swift updatable: its CLI compiles the Swift you changed to WebAssembly and ships it as a small patch, and the on-device SDK runs it in the WasmKit runtime. Covered Swift — business logic, async/await, and SwiftUI views (up to 98.5% of SwiftUI view elements) — updates with no App Store review and instant rollback. Code that touches raw OS APIs stays in your signed native binary automatically, and if a patch can't run the SDK falls back to the bundled version, so an update can't break the app. Your signed App Store binary is never modified — only the interpreted WebAssembly layer updates.

Yes — Patch. CodePush and Expo / EAS Update update the JavaScript bundle of a React Native app; Shorebird updates the Dart code of a Flutter app. None of them can touch a genuinely native Swift / SwiftUI app, because there's no JavaScript or Dart bundle to replace. Patch is the native-Swift equivalent: you write ordinary Swift, Patch compiles the changed code to WebAssembly and runs it on-device in WasmKit, so native iOS teams get the same over-the-air workflow — ship in minutes, no App Store review, instant fleet-wide rollback — without adopting React Native or Flutter.

Shorebird is the leading over-the-air update tool for Flutter — it ships new Dart code to a Flutter app through a modified Flutter engine, and it's a great fit if you build in Flutter. But it only updates the Dart layer; it does not update native Swift, Kotlin, or Objective-C. Patch is for teams who build genuinely native iOS apps in Swift and SwiftUI: it compiles your changed Swift to WebAssembly and runs it in WasmKit on-device, with no Flutter, no Dart, and no cross-platform framework. Same idea — interpreted code pushed over the air, no review queue, instant rollback — applied to native Swift instead of Flutter. More on Patch vs. Shorebird →

Yes — it's explicitly allowed by Apple's own rules. Apple's Developer Program License Agreement (section 3.3.2) expressly permits an app to download and run interpreted code, as long as it doesn't change the app's primary purpose, doesn't create a storefront for other code, and doesn't bypass the OS sandbox or code signing. Patch does none of those: your signed App Store binary never changes — only the interpreted WebAssembly layer updates. This is the exact same provision Expo / EAS Update and CodePush have relied on for nearly a decade, across tens of thousands of live App Store apps. Patch simply brings that proven, Apple-sanctioned model to native Swift. Keep your updates within the same purpose your app was approved for and you're squarely inside the rules.

No — the overhead is negligible. Your patched code runs in the WasmKit runtime at near-native speed, and for the kind of code Patch ships — business logic, validation, pricing, networking glue, view construction — the cost is measured in microseconds, far below anything a person could perceive. There's zero impact on launch: the SDK activates the cached module instantly (even offline) and only checks for updates in the background. And anything genuinely performance-critical — low-level rendering, heavy compute, tight loops — automatically stays native, so your hot paths are always compiled machine code. Modules are tiny (tens of KB) and updates ship as compressed binary diffs, so download and memory cost are trivial too.

Not at all. You keep writing native Swift exactly as you do today. Run patchcli init once — it registers your app, adds the Swift package, and inserts the two-line startup code for you — and that's the whole integration. No JS bridge, no React Native.

Far more than logic. Swift concurrency (async/await) runs in WASM, and Patch has coverage for SwiftUI views — up to 98.5% of SwiftUI view elements (structure, state, and interaction). Pricing logic, validation, business rules, networking glue, feature flags, routing, and your view code can ship over the air. The few things that touch raw OS APIs (HealthKit, cameras) stay in your App Store binary; Patch detects the split automatically and only ships what's safe.

Roll the whole fleet back to any previous version in under a minute — no resubmission. Patch also has a fallback chain: if a module is missing or corrupt, users automatically run the bundled version in the App Store binary.

Updates apply on next launch and are cached on-device, so the app works completely offline. Patch runs on iOS 16+ and falls back gracefully to the original bundled version if a module is missing.

By the number of distinct devices that receive patch updates across all of your apps. Every plan includes unlimited updates and rollbacks — you only move up a tier as your device fleet grows.

Push your first fix today.

Install the CLI and ship a patch this afternoon.

brew install patch-release/tap/patchcli · free to start · no card required