Ready Together
← All field notes
TECHNICAL OUTLINEPlanned

Why Ready Together uses Kotlin Multiplatform

The architecture is useful only if it helps two phones share the same product meaning without hiding platform-specific constraints.

By Oscar Emilio Pérez MartínezNot scheduledOutline
This is a planned story, not a published technical claim.

The final article must cite merged code, reproducible tests, and the outcome of the open physical-device gate.

Proposed story beat

Ready Together uses Kotlin Multiplatform to keep circle, event, check-in, drill, and report semantics consistent across Android and iPhone while leaving genuinely native capabilities at the platform boundary.

  1. Start with the product constraint.One shared drill must mean the same thing on two operating systems.
  2. Show what is shared.Domain models, repository contracts, presentation state, canonical timing, and degraded-mode rules.
  3. Show what remains native.Platform identity, lifecycle, maps, notifications, and store-specific release work.
  4. Explain the server boundary.The Ktor service can be authoritative without turning local UI success into deployment proof.
  5. End with evidence.Automated coverage is useful; the Android–iPhone physical Gate A must remain explicit until completed.

Evidence still required before final copy

  • Exact merged commits and test commands for the selected shared flow.
  • A public-safe architecture diagram derived from current repository structure.
  • Physical Android–iPhone observations, or an explicit statement that Gate A remains open.
  • Owner approval of every screenshot and any performance or parity claim.