CLCTN · PLATFORM STRATEGY · ANDROID VIA SHARED SWIFT · 19 SEP 2026

Android later. The line you draw now.

Polymarket shipped an Android app in July 2026 with roughly 170,000 lines of production Swift inside it — models, networking, business logic, and over 120 ViewModels, all shared with the iOS app. Native Compose UI on top. That is the path, and it is proven at a scale far beyond anything CLCTN will reach.

The corner to avoid is not "we didn't build Android." It is arriving at the Android decision with a codebase where the domain logic and the iOS framework code are the same code. Polymarket's own account is explicit that the head start came from having already split the app into Swift packages before the question was asked — the rest was moving files across a line that already existed.

00 · THE VERDICT, BEFORE THE DETAIL

01 · WHY THIS IS NOW CREDIBLE AND WASN'T TWO YEARS AGO

Four things landed independently and happen to compose. Any one of them missing and this page would say "use Kotlin."

{{ p.t }}

02 · THE LINE — WHAT SHIPS TO BOTH, WHAT STAYS ON IOS

Polymarket's rule was one sentence: share everything we can. Anything touching UIKit, SwiftUI, MapKit, PassKit or a platform SDK stays on the iOS side; everything else is a candidate for the shared layer. The boundary is made real by hiding platform code behind protocols and injecting the implementation at startup — which in our case is swift-dependencies, already in the blueprint for every effectful boundary.

Applied to CLCTN's existing target list, the split is unusually clean — because the blueprint already put one SPM target per domain rather than one app target with folders.

clctn-shared

FOUNDATION + OBSERVATION + PORTABLE PACKAGES ONLY

{{ s.t }}

clctn-ios

PLATFORM CODE — MIRRORED IN KOTLIN ON ANDROID

{{ s.t }}

THE PATTERN · A SWIFT PROTOCOL, A KOTLIN CONFORMANCE

ALREADY OUR DEPENDENCY STYLE

{{ sketch }}

This is the part of the Polymarket write-up worth internalising: the Android implementation is plain Kotlin using the native SDK, conforming to a Swift protocol. No reducer knows which platform it is on. We already write dependencies this way — the blueprint mandates it — so the work is choosing the right protocols, not inventing a technique.

03 · TCA 2 IS THE REASON THIS IS EASIER FOR US THAN FOR THEM

They had to invent a shareable ViewModel. We inherit one.

Polymarket's hardest migration was moving 120+ ViewModels off ObservableObject, @Published and Combine onto @Observable, because the bridge generates Kotlin from Swift Concurrency, not from Combine publishers. Every publisher needed a hand-written async surface.

A TCA reducer is already the thing they spent a year building toward: a value type, an action enum, effects expressed in structured concurrency, state observed through Observation. No Combine, no UI framework, nothing to migrate. The unit of sharing is the reducer, and it is portable by construction.

TCA 2 sharpens this further — Point-Free describe it as the next generation of the library, embracing Swift's modern concurrency tools. The 1.x line already builds for Android, Linux and Wasm on the package index, and Point-Free maintain a whole cross-platform Swift track. The company that makes our architecture is actively taking it off Apple's platforms.

Caveat worth carrying: TCA 2 was in beta preview at last public note. Fine for a project that hasn't shipped v1 — you would adopt it during the build, not migrate to it after. Confirm its release status before committing the blueprint to 2.x.

04 · WHAT BIT THEM — READ BEFORE BELIEVING THE PITCH

The write-up is unusually honest about cost, which is the main reason to trust it. Four of these are real and one of them is genuinely nasty.

WHAT HAPPENED TO THEM

WHAT IT MEANS FOR CLCTN

05 · THE HONEST CASE AGAINST

The forum thread contains a well-argued dissent, and it is worth keeping on the page rather than filtering out. Two of the three objections do not apply to a one-person company; one of them applies harder.

06 · THE ACTUAL CHANGE TO MAKE NOW

Nothing that costs a day. Zero Skip, zero Gradle, zero Kotlin, zero Android tooling installed. Two paragraphs in the Technical Blueprint and one habit — the same shape as the resizability rule on the iPhone Duo page: a constraint that is free while the codebase is small and expensive once it isn't.

And like that rule, it pays off without Android ever happening: a platform-neutral core is also what makes the logic testable without a simulator, and what would let a web or server surface exist later.

BLUEPRINT · PORTABILITY CONSTRAINT · PROPOSED WORDING

{{ constraint }}

07 · OPEN QUESTIONS, TO ANSWER BEFORE ANY OF THIS IS LOAD-BEARING

Sources: Our Android App Is Written in Swift (Swift Forums, August 2026) and its reply thread, including the dissent in section 05; Point-Free's notes on ComposableArchitecture 2.0 and their cross-platform Swift work; Swift Package Index build results for swift-composable-architecture. Related: iPhone Duo for the sibling resizability constraint, and Technical Blueprint for the target list this page splits.