PatchShort answer: CodePush is gone. Microsoft retired Visual Studio App Center — and the hosted CodePush service with it — on March 31, 2025, and archived the standalone code-push-server repository on May 20, 2025. React Native teams moved to Expo's EAS Update, Flutter teams use Shorebird, and native Swift apps, which CodePush never covered, use Patch.
Status, rechecked : the hosted CodePush service is still gone, microsoft/code-push-server is still archived and read-only, and Expo's EAS Update, Shorebird and Patch are all still shipping. Nothing on this map has changed since it was written.
On March 31, 2025, Microsoft retired Visual Studio App Center, and CodePush — the service that defined over-the-air updates for a decade — went with it. If your release process still has a code-push release-react step in it, that step has been pointing at a tombstone for over a year.
We build one of the tools on this map (Patch, the native-Swift one) — so read accordingly.
What did CodePush prove?
CodePush's decade established that OTA code updates are a legitimate, mainstream practice on iOS and Android. Ship the fix as an interpreted payload (JavaScript, in its case), let the app pick it up at next launch, keep the signed binary untouched. Apple's rules conditionally permit this pattern — the conditions bind you, the developer, not the vendor (the rules in detail) — and it was widely used in production React Native apps from 2015 until Microsoft retired it. The pattern outlived the product; every tool below is the same architecture with a different payload (how it works under the hood).
Which OTA update tool replaces CodePush for your stack?
React Native: from CodePush to EAS Update
Microsoft's own retirement notice pointed at exactly one path: the open-sourced standalone code-push-server for self-hosters — since archived upstream, with community forks carrying it on. Viable if you have the ops appetite, increasingly lonely if you don't. The ecosystem's consensus destination is EAS Update: Expo published its own migration guide, and in most ways it's an upgrade — channels, staged rollouts, code signing, an open protocol, first-class Expo integration.
Flutter: Shorebird
Founded by Flutter's creator, Eric Seidel, Shorebird brought code push to Dart's AOT world: unchanged code runs at full native speed, changed code runs in an interpreter, patches are diffs. It's the established answer in its ecosystem (how Shorebird compares to Patch).
Native Swift / SwiftUI: Patch
Native iOS briefly had OTA — JSPatch, Rollout.io — and Apple purged it in 2017, because those tools let downloaded code reach into the Objective-C runtime and redefine reviewed behavior. The gap since then was real: no JS bundle, no Dart VM, nothing to update. Patch closes it with the opposite architecture. You write ordinary Swift; the CLI compiles your changed code to WebAssembly; the on-device SDK (public source) runs it in WasmKit, a WASM interpreter written in Swift — and a patch can only call the host functions the shipped, reviewed binary exposes. There is no path to the ObjC runtime, or to APIs your binary didn't already use. Code that touches OS APIs stays native, detected automatically, with an automatic fallback chain to the code your binary shipped with; hash verification, staged rollouts, channels, and one-command rollback are built in. Pure-logic patches ship at kilobytes; patches that pull in heavier library surface ship larger. It's live today: brew install patch-release/tap/patchcli, a free tier (see pricing), iOS 16+, about ten minutes from install to first patch on a device.
What is the compliance fine print, whichever you pick?
OTA updates an interpreted layer, never the native shell — new native dependencies still mean a store release. And Apple's interpreted-code conditions bind you regardless of vendor; as 2017 proved, the line between permitted and purged is Apple's to draw. Any tool selling "Apple-approved" is overselling. What a good tool gives you is the mechanism plus the operational safety net — verification, rollout controls, rollback — to use it responsibly.
| Tool | Framework | Payload | Patches native Swift? | Hosted / self-host | Status (Aug 2026) |
|---|---|---|---|---|---|
| CodePush | React Native | JS bundle | No | was hosted (App Center) | hosted service retired March 31, 2025 |
code-push-server | React Native | JS bundle | No | self-host | archived May 20, 2025; community forks |
| EAS Update | React Native / Expo | JS bundle / Hermes bytecode | No | hosted (self-host possible via the open protocol) | mainstream default |
| Shorebird | Flutter | Dart patch | No | hosted / self-host | established |
| Patch | native Swift / SwiftUI | WebAssembly module | Yes | hosted / self-host | live |
| Server-driven UI | any | JSON layout | No — not code | your own backend | a different tool for a different job |
How do you choose, migrating or starting fresh?
The questions that actually matter, in order:
Inventory the dependency. How many releases shipped through OTA last year? What's your median time-to-fix without it? That tells you how much you depended on it — or what you've been missing if you're native and never had the lane.
Map your update boundary. What share of your bugs lives in the updatable layer — JS, Dart, or (for native apps) the logic/view-model/SwiftUI slice within the patchable boundary vs. raw OS-API code? The boundary, not the vendor, determines what OTA can ever do for you.
Demand the safety net. Staged rollout percentages, instant rollback, integrity verification, and a fallback path on-device. CodePush-era muscle memory sometimes skips these; none are optional.
Write the compliance paragraph once. One honest paragraph on what your mechanism does and how it meets the interpreted-code conditions — wherever you land, have it ready before App Review asks, not after.
CodePush's retirement didn't shrink the category; it reorganized it — and extended it to the one ecosystem that never had it. If you ship React Native, your path is well-paved. If you ship Flutter, likewise. And if you ship native Swift, you now have a lane on the map: see the CodePush alternative for native Swift iOS, or all five tools side by side in OTA update tools compared.
Frequently asked questions
When did CodePush shut down?
March 31, 2025. Microsoft's retirement notice states: “Visual Studio App Center is scheduled for retirement on March 31, 2025. After that date, it will not be possible to sign in with your user account nor make API calls.” The hosted CodePush service went with it. The client SDK and a standalone server were open-sourced first, and Microsoft archived the code-push-server repository on May 20, 2025.
What replaced CodePush?
For React Native, most teams moved to Expo's EAS Update, which offers channels, staged rollouts, code signing and an openly specified update protocol. Self-hosters run community forks of the open-sourced code-push-server. Flutter teams use Shorebird. Native Swift apps — which CodePush never covered, because it shipped JavaScript bundles — use Patch, which ships compiled Swift as WebAssembly.
Is CodePush still available?
Not as a hosted service. Microsoft's retirement page says of CodePush: “We have prepared a special version of CodePush that can be integrated into your app and run independently from App Center.” That standalone server is the microsoft/code-push-server repository, which carries the notice “This repository was archived by the owner on May 20, 2025. It is now read-only.” Community forks continue it.
Can CodePush update a native Swift app?
No. CodePush shipped JavaScript bundles to React Native apps, and a native Swift or SwiftUI app has no JavaScript bundle to replace. Updating native Swift over the air needs a different interpreted payload: Patch compiles the changed Swift to WebAssembly and runs it in WasmKit inside the signed app. Code that touches OS APIs stays native in either design.