Ship Swift over‑the‑air
Skip Waiting for Review

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. 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 (74.6% of SwiftUI view bodies across a 24-app benchmark) — 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. 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 — ship in minutes, no App Store review, instant fleet-wide rollback — without adopting React Native or Flutter.

Yes — it's explicitly allowed by Apple's own rules. Apple's Developer Program License Agreement (§3.3.1(B)) 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.

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. There's zero impact on launch: the SDK activates the cached module instantly (even offline) and only checks for updates in the background. Anything genuinely performance-critical stays native, so your hot paths are always compiled machine code. Modules are tiny (tens of KB) and updates ship as compressed binary diffs.

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 — 74.6% of SwiftUI view bodies across a 24-app benchmark of real apps (16 open-source, 8 our own), with 82.5% measured per element. 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 15+ 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.