CLCTN · ARCHITECTURE · OTA PATCH LAYER · 19 SEP 2026
The right tool. Possibly for the wrong half of the problem.
Patch compiles the Swift you changed to WebAssembly and runs it on-device in WasmKit, leaving the signed binary untouched. It slots into the layering from
Android via Swift without disturbing it —
as long as one rule holds: clctn-shared must never learn that Patch exists.But the dev-loop case you're describing deserves a harder look than the tool does. Section 02 is the one that decides this, and it turns on a single question about how you actually work.
00 · THE VERDICT, BEFORE THE DETAIL
{{ v.tag }}
{{ v.t }}
{{ v.b }}
01 · WHAT IT ACTUALLY IS
{{ f.k }}
{{ f.v }}
{{ f.b }}
02 · THE GATE — WHAT IS ACTUALLY SLOW IN YOUR LOOP
Do you write code away from your Mac? Everything on this page is a footnote to that question.
You framed this as "the delay of App Store Connect", but App Store Connect is not in a solo developer's inner loop and never has to be. Xcode installs to a paired iPhone over Wi-Fi in seconds, free, with a debugger attached. Internal TestFlight needs no review at all. Neither of those is the 48-hour wait Patch was built to eliminate.
Where Patch genuinely wins is the case your message actually hints at: an LLM session running somewhere that isn't your laptop, and a phone in your hand that isn't near it. If that's the working pattern, nothing else closes that gap. If your Mac is with you, most of this is solved already and Patch's dev value drops sharply.
ROUTE ONTO THE PHONE
LATENCY
WHAT IT NEEDS
WHERE IT FAILS YOU
{{ r.name }}
{{ r.latency }}
{{ r.needs }}
{{ r.fails }}
One detail that matters for expectations: a patch applies on next launch, not live. The loop is push, quit the app, reopen — fast, but it is not hot reload, and there is no debugger attached to interpreted code. Print-and-look, not breakpoints.
03 · WHERE IT SITS — AND THE ONE RULE THAT PROTECTS ANDROID
Your instinct to have clctn-shared be the thing that updates is right, and the good news is that it costs nothing structurally: the SDK never goes in the shared package. Integration is two lines in the app's entry point; the build engine reaches the rest from outside. So the shared core keeps building for Android with no Apple and no Patch symbol anywhere in its graph.
THE LAYERING · WHO KNOWS ABOUT PATCH
{{ layering }}
{{ l.k }}
{{ l.t }}
{{ l.b }}
04 · THE FINGERPRINT CONTRACT — THE PART THAT WILL BITE AN LLM WORKFLOW
Every patch is built against a hash of your native shell. Change native code and the hash moves; a moved hash means no patch until you ship a new binary. The docs are blunt that this is the one problem everyone hits — and an agent-driven session is a machine for producing exactly the changes that move it.
For a TCA codebase the line falls somewhere unusually legible, which is the best thing on this page: State and Action behave like a schema, and everything downstream of them is fluid.
FLUID · ships over the air
FINGERPRINT-STABLE — PATCH AND KEEP MOVING
FROZEN · needs a real build
MOVES THE FINGERPRINT — RE-REGISTER AND REINSTALL
THE SIDE EFFECT WORTH MORE THAN THE TOOL
This contract is good discipline whether or not you ever adopt Patch. "Settle the state shape, then churn the logic and the views" is how a TCA app should be built anyway, and it is precisely the habit an LLM session tends to break — agents love adding a stored property to solve a view problem. Patch turns that tendency into an immediate, visible cost, which is a strange but genuine argument in its favour.
05 · WHAT IN CLCTN SPECIFICALLY WON'T PATCH
Measured coverage across 24 real apps is 74.6% of SwiftUI view bodies, but the spread runs 45% to 98% and the losers are all the same shape: apps heavy in native-wrapped views. Worth predicting where CLCTN lands before adopting, because our most distinctive screens are exactly the expensive kind.
Important nuance from the docs, and the most-misunderstood point: a view that can't lower is never broken — it renders natively from the bundled binary, and it can still be moved, resized, shown and hidden over the air. Only its internals are frozen. So the camera and the 3D box don't block anything; they just don't change from a patch.
06 · DEV-ONLY, OR ALL THE WAY — FOUR POSTURES
Your plan is posture A, and it has one property worth naming out loud: it pays the whole cost and collects the smaller half of the benefit. The fingerprint discipline, the hybrid execution model and the setup are all paid in dev; the thing Patch is actually famous for — fixing a crash for everyone in two minutes instead of two days — is deliberately left on the table.
{{ p.k }}
{{ p.name }}
{{ p.cost }}
WHAT IT MEANS
{{ p.what }}
WHAT YOU GIVE UP
{{ p.give }}
{{ p.foot }}
RECOMMENDATION
{{ postureLine }}
07 · WHAT THIS DOES TO THE ANDROID PLAN
Nothing, if the rule in section 03 holds. And Android doesn't want it anyway.
Patch exists to route around App Store review. Play has no equivalent bottleneck for a developer testing their own work — internal distribution lands in minutes, and a direct install lands in seconds. The Android dev loop is already the fast one.
So this is not a layer you'd ever mirror in Kotlin. It is an iOS-side compensation for an iOS-side problem, sitting above the shared core rather than inside it — which is the same position SwiftUI, StoreKit and Vision already occupy in the split.
The one thing to watch: if patchcli ever asks you to annotate, restructure or add an import inside clctn-shared to improve coverage, decline. Coverage in the shared core is worth less than the shared core staying portable.
{{ a.k }}
{{ a.t }}
{{ a.b }}
08 · THE ACTUAL CHANGE TO MAKE
One block in the Technical Blueprint, in the same shape as the resizability and portability constraints already there. It costs nothing now and keeps both the adopt and the drop decisions one config change away.
BLUEPRINT · OTA PATCH LAYER · PROPOSED WORDING
{{ constraint }}
09 · VERIFY BEFORE COMMITTING — THINGS THIS PAGE ASSUMES
Sources:
Patch documentation — coverage census, the compatibility fingerprint, and the Apple-compliance note citing DPLA §3.3.1(B) — plus
patchrelease.com for pricing and the CI example. Coverage figures are the vendor's own published census at pinned commits; treat them as a good-faith measurement, not an independent one. Related:
Android via Swift for the package split this page sits on, and
Technical Blueprint for the target list.