What Patch can & can't update

These numbers are generated, not written

Everything below is imported from src/data/coverage.json, which is derived from a committed census artifact by npm run gen. No coverage figure on this site is typed by hand. Reproduce it yourself with ./corpus/fetch.sh and ./tools/swiftui-corpus-coverage/run.sh.

The honest, developer-facing map of what an OTA patch can reach in a SwiftUI app — and the small set of things it genuinely can’t. The short version: SwiftUI structure is never the wall. An OTA patch can author, restyle, reorder, rebind, and re-flow essentially your entire view hierarchy. The only true ceiling is the App Store’s own boundary — a native capability, framework symbol, or privacy entitlement that isn’t already compiled and signed into your shipped binary.

Measured coverage

Across 24 real apps — ours and well-known open-source ones — 74.6% of SwiftUI view bodies lower to WebAssembly and ship over the air.

74.6%view-level — 1,024 / 1,372

82.5%element-level — 21,034 / 25,503

98%best app — first-party-app-b

45%worst app — kiwix-apple

Per-app results vary widely, so the average matters less than the spread. The 16 named apps are public repositories measured at pinned commits, so you can verify those yourself; the 8 first-party-app-* rows are our own apps, included because dogfooding is the point but not named:

App	Views lowered	Coverage
tinode-ios	1 / 1	100%
first-party-app-b	41 / 42	98%
first-party-app-f	34 / 36	94%
first-party-app-g	22 / 24	92%
first-party-app-d	57 / 63	90%
first-party-app-h	24 / 27	89%
first-party-app-c	35 / 41	85%
firefox-ios	64 / 76	84%
GoCycling	31 / 38	82%
first-party-app-a	23 / 28	82%
wire-ios	137 / 172	80%
clean-architecture-swiftui	7 / 9	78%
isowords	49 / 63	78%
wikipedia-ios	114 / 149	77%
WWDC	22 / 29	76%
exyte-Chat	42 / 56	75%
first-party-app-e	18 / 24	75%
MovieSwiftUI	35 / 48	73%
Pulse	52 / 71	73%
ACHNBrowserUI	75 / 110	68%
IceCubesApp	91 / 160	57%
NetNewsWire	8 / 14	57%
Gifski	13 / 27	48%
kiwix-apple	29 / 64	45%

The remainder is mostly custom child views the engine cannot reconstruct, and unsupported modifiers. A view that cannot lower is never silently broken — it renders natively from your signed binary.

The headline

Nearly all of the SwiftUI surface that real iOS apps actually use is OTA-reachable. The measured share of view bodies Patch lowers to WebAssembly today is in the table above — and the views that stay native still render and move via OTA (only their internals are frozen). The gap between “reachable” and “lowered today” is engineering backlog, not a fundamental wall.

What you can update over the air

Within your app’s already-linked frameworks and declared entitlements, OTA patches reach virtually the entire SwiftUI surface:

Area	What an OTA patch can do
View structure	Add, remove, reorder, and restyle views; change the whole hierarchy. Structure is fully authorable over the air.
Text & images	Text (literals, interpolation, computed strings), Label, Image(systemName:) and bundle assets, AsyncImage.
Layout	Stacks, grids, List, Form, Section, ScrollView, Spacer/Divider, ViewThatFits, and the layout modifiers — frame, padding, offset, position, safe-area insets.
Styling, colors & fonts	Foreground/background/tint, borders, shadows, corner radius, fonts and weights, plus design-system tokens — a custom Theme.Colors.ink / Theme.Font.body(…) / Theme.Radius.lg in a modifier value position lowers and rides the patch (resolved natively, fed to the view).
Controls & state	Button, Toggle, Slider, Stepper, Picker, TextField/SecureField, Link/ShareLink, Gauge/ProgressView, bound to @State / @Binding / @AppStorage / @FocusState.
Navigation & presentation	NavigationStack / navigationDestination, sheets, full-screen covers, popovers, alerts, confirmation dialogs, toolbars, context menus, and searchable.
Modifiers & control flow	The vast majority of standard modifiers, plus if / if let / switch control flow inside a view body, gestures (onTapGesture & the gesture algebra), onAppear/onChange/task, and full async/await logic.

For the exhaustive symbol-by-symbol breakdown, see What’s updatable and the per-function coverage you get from patchcli build --verbose.

What you can’t update — the binary-symbol wall

There is essentially one true wall, with two faces. Both reduce to the same thing: an OTA patch can never introduce a native symbol, framework, or entitlement that isn’t already in your shipped, code-signed app, and can never rewrite the compiled machine code of native functions that aren’t a patchable View.body. This is not “hard, just not yet” — it’s a physical boundary, and it’s exactly the line the App Store draws.

1 · A native capability, framework, or entitlement that isn't in the signed binary

An OTA patch can’t introduce a privacy-gated capability your app never declared, or call into a framework the app never linked. The OS reads your signed Info.plist and entitlements at launch; WebAssembly can’t synthesize a permission key or link a new framework. Examples:

• Presenting a camera or photo-library picker in an app with no NSCameraUsageDescription / NSPhotoLibraryUsageDescription and no PhotosUI/AVFoundation linked.
• HealthKit, Contacts, Location, Microphone, Bluetooth, Apple Pay / Wallet presenters when the matching usage string or entitlement was never declared.
• A UIViewRepresentable wrapping MKMapView / WKWebView / MTKView / ARView in an app that never linked MapKit / WebKit / MetalKit / RealityKit.
• A custom Metal Shader (.colorEffect / .layerEffect) whose .metal function was never compiled into the app’s .metallib.

2 · The internals of non-View.body native code

Patch hot-swaps View.body getters (via dynamic replacement, like Xcode Previews) and data-drives the renderer. It has no mechanism to rewrite arbitrary compiled native functions. So an OTA patch can’t change the body of:

• A UIViewRepresentable’s makeUIView / updateUIView.
• A custom ButtonStyle / ViewModifier’s makeBody / body(content:).
• A @FetchRequest / @Query predicate or sort declaration (you can restyle, reorder, and relabel the resulting rows — you just can’t rewrite the predicate to reference an attribute the model lacks).
• A custom Shape.path(in:), custom Layout geometry, or any private native helper that isn’t a thunked View.body.

Important: "frozen internals" ≠ "can't touch it"

Be precise here, because it’s the most common misconception. An existing MKMapView, WKWebView, custom view, custom style, or Canvas in your app is fully reachable by an OTA patch — it still renders, gets placed, reordered, resized, shown, and hidden over the air. What’s frozen is only its native internals (the makeUIView body, the Metal kernel, the predicate). Likewise, a design-system color/font/number constant patches fine — unless it references a private or body-local member, in which case the view stays native (still rendered, never broken). And things people assume are off-limits — .drawingGroup() (SwiftUI’s own Metal), AsyncImage, ShareLink, haptics, built-in format styles, GeometryReader — are all patchable, because they live in the SwiftUI/Foundation runtime your app already links.

The one-line rule

If a change lives entirely inside your app’s existing linked frameworks, declared entitlements, and SwiftUI view bodies, an OTA patch can ship it. If it requires a new native symbol, framework, or privacy entitlement that isn’t in the signed binary — or it rewrites compiled native code that isn’t a View.body — it needs an App Store release. That second set is tiny, and it’s the same boundary Apple’s review process draws. When Patch isn’t sure a change is safe, it keeps the code native and renders the bundled fallback, so an update can never break your app.

New here? Start with the Quick Start or have an AI assistant set Patch up for you.