Patreon / Apple IAP
Independent public proof of the structural method applied to a host-platform payment boundary conflict.
Produced independently from public evidence. Not commissioned by Patreon or Apple.
Proof of structural capability, not contracted outcomes.
Patreon / Apple IAP
Creator patronage platform · iOS monetisation boundary New proof set · April 2026Two mutually exclusive structural exits follow from the same diagnosis.
Path A — The Decoupler (continuity-preserving): Apple becomes the funding rail. Patreon remains the relationship authority. The Credit Event Log is the truth.
Path B — The Allocation Shift (category-transforming): Apple sees one platform subscription. Patreon governs allocation internally. The Patronage Allocation Ledger is the truth.
Both are structurally valid. They are not compatible. Leadership must choose one; attempting both recreates the collapse.
Path A and Path B cannot be combined. The decision is identity, not sequencing.
Produced independently from public evidence. Not commissioned by Patreon or Apple.
Plain-language entry point. Creates shared understanding of the Primitive Switch, the host-constrained mismatch, and the two redesign paths.
Entry point: No prior knowledge required. Designed to create a shared structural read across leadership, creator, product, and policy teams before the full diagnostic evidence is circulated.
Best for leadership, creators, fans, product teams, policy teams, and first-time readers.
Evidence-tiered diagnosis naming the Host-Constrained Primitive Mismatch.
Governing diagnosis: Patreon’s patronage primitive cannot be faithfully expressed inside Apple’s transaction-coded IAP grammar. At the iOS “Join” moment, a Primitive Switch occurs.
Primitive mismatch: stated relationship-coded creator patronage; actual transaction-coded subscription grammar imposed by the host platform at the payment boundary.
Best for evidence review, leadership alignment, platform strategy, policy framing, and understanding the governing diagnosis.
Board-level decision surface covering both structural exits.
Path A preserves Patreon’s existing creator-fan category through a translation layer. Path B transforms Patreon into a platform-level allocation system.
Best for executives, founders, board readers, product leaders, platform strategists, policy teams, and decision owners.
The Decoupler. Continuity-preserving replacement.
Complete builder specification for The Decoupler — the continuity-preserving exit that preserves bilateral creator-fan patronage behind an Apple-compatible payment rail.
Includes the Credit Event Log, Dual Ledger, Fan Agreement Object, Publication Event Handler, refusal gates, Translation Engine, Reconciliation Reserve, fan-facing credit balance, creator-facing per-creation earnings interface, transition sequence, admissibility conditions, recapture gates, drift immune system, and builder handoff.
Apple funds the relationship. Patreon defines it.
The public Redesign Executive Summary shows the replacement logic. The full Path A specification is restricted.
Access reviewed by context. Include organisation and request context. The full specification is not a public download.
The Allocation Shift. Category-transforming replacement.
Complete builder specification for The Allocation Shift — the category-transforming exit that replaces bilateral creator-fan payment with platform-level patronage allocation.
Includes the Platform Subscription Object, Fan Patronage Account, Allocation Rule Object, Patronage Allocation Ledger, Allocation Engine, Publication Event Listener, Creator Payout Engine, Reconciliation Reserve, fan allocation UI, creator payout interface, payor-of-record architecture, relational frame invariants, transition sequence, admissibility conditions, recapture gates, drift immune system, and builder handoff.
Apple sees one platform subscription. Patreon governs allocation internally.
The public Redesign Executive Summary shows the replacement logic. The full Path B specification is restricted.
Access reviewed by context. Include organisation and request context. The full specification is not a public download.
The Patreon / Apple IAP diagnosis produces a strategic fork, not one obvious redesign.
Path A preserves Patreon’s existing creator-fan category by installing a translation layer between Apple’s payment grammar and Patreon’s patronage relationship.
Path B transforms Patreon into a platform-level allocation system where Apple sees one subscription and creator-level economics are governed internally.
Both are structurally valid. They are not compatible. The decision is not which feature to build first. It is what Patreon is going to become.
A serious Full Redesign Artifact does not just say what to build. It also names which futures cannot be pursued together.