Mobile | kaguc — Writing to understand systems.

The cross-platform boundary: share what must not diverge

Fri, 28 Aug 2026 00:00:00 +0000

Also in 中文. Part 4 of Trading app architecture.

The cross-platform debate is usually conducted as a framework comparison, which is why it never resolves. The prior question decides most of it: which parts of your app must be identical on iOS and Android, and which parts should not be?

Answer that and the framework choice narrows to a couple of reasonable options. Skip it and no amount of benchmarking will help, because you are arguing about tools while the requirement is undefined.

The test: is divergence a bug or a feature?

Take any layer of your app and ask what happens if the two platforms behave differently.

For an order validator, a fee calculation, an options pricing rule, a state machine, a protocol encoder: divergence is a defect. Two independent implementations of the same financial rule will drift — not maybe, will. They drift on the edge cases first, which in this domain are also the expensive cases. Nobody notices for months, and the bug report arrives as a customer whose numbers didn’t match.

For navigation transitions, gesture physics, date pickers, permission flows, accessibility, share sheets: divergence is correct. Users have platform expectations, and code that flattens them produces an app that feels subtly wrong on both. Effort spent unifying this layer buys negative value.

That’s the whole rule: share the layer where difference is a defect, keep native the layer where difference is the point.

Notice this is a correctness argument, not an efficiency one. DRY is usually justified as “write it once,” which invites the counterargument that duplication is sometimes cheaper. That counterargument is fine for UI and irrelevant for domain rules, because there the cost of duplication isn’t typing — it’s two divergent truths about money.

Sharing is not free, and the costs are structural rather than obvious:

A boundary appears. Shared code and platform code must talk. That interface needs types both sides understand, serialization, and error mapping. It is now a thing to design and version.

A runtime arrives. A second runtime means memory, startup cost, and a debugger that no longer sees the whole picture. When something breaks at the boundary, you are debugging two systems and the seam between them.

The team splits. Someone must be fluent in the shared layer and its toolchain. At small scale that is one person, which is a bus factor rather than a plan.

So the question isn’t “does sharing help” — it’s “does the divergence risk in this layer exceed the boundary cost.” For domain logic, usually yes. For a settings screen, usually no.

The three positions

Fully native, twice. Maximum platform fidelity, zero boundary cost, and every rule written twice. Reasonable when the shared logic is thin or the platform surface is most of the product.

Share the logic, keep native UI. The domain, models, and validation live in one codebase; each platform renders it. This targets exactly the layer where divergence is a defect and leaves the layer where it isn’t. The cost is that boundary and its toolchain.

Share the UI too. One codebase draws both platforms. Fastest to a feature-complete app with one team, and the reason most small teams should start here. The cost arrives later and from a predictable direction: platform capabilities. Every camera, biometric, background, or notification feature eventually needs a plugin, and a plugin is native code with extra steps. Budget for that from the start instead of being surprised by it.

The mixed model, and what it really costs

Large apps often end up mixed: a native shell with a cross-platform UI framework embedded for some screens. This is usually not indecision — it is the honest shape of a migration, and it’s the right pattern when you cannot stop shipping to rewrite (more on that next).

It has real costs worth naming before you choose it:

Runtime memory. Each embedded engine has a footprint. Multiple live engines multiply it, and the mitigation — caching and reusing engines — is itself a lifecycle problem you now own.
Two navigation stacks. The native stack and the framework’s router must be unified, or back-button behavior becomes a permanent source of bugs.
State on both sides. Session, theme, and locale now exist twice and must be kept in agreement. Every duplicated piece of state is a future desync.
Debugging across runtimes. A stack trace stops at the boundary. Crash and performance tooling must be configured to see both sides, or half your incidents become guesswork.

Make the boundary coarse

Whatever you share, the interface between the shared core and the platform should be coarse-grained.

The cost of crossing a boundary — serialization, marshalling, a runtime transition — is paid per call, not per byte. A chatty interface with dozens of small property reads can be dramatically slower than one call returning a complete object, even though it moves less data. This is the same lesson as batching updates at a native boundary in part one, and it generalizes: design boundaries as few, meaningful operations, not as remote field access.

There’s a design benefit too. A coarse interface expresses intent (“place this order,” “give me this screen’s data”), which stays stable while implementations change underneath. A fine-grained interface exposes structure, and structure changes constantly.

Choosing, honestly

Two variables decide it: how much of your product is domain logic that must not diverge, and how many people you have.

One small team, mostly UI over an API: share everything. One codebase, native modules where the platform demands it.
Small team, meaningful domain logic: share everything, but keep that logic in its own layer with no UI dependencies — so it can be extracted later without a rewrite.
Multiple platform teams, substantial domain logic: share the logic, keep UI native. This is where the boundary cost is clearly repaid.
Single platform: the question does not exist. Don’t pay for optionality you have no evidence you’ll use.

The mistake that costs the most is choosing a sharing strategy for a team size you don’t have yet. Architecture that anticipates an organization you might build is how small teams end up maintaining a large team’s overhead with a small team’s capacity.

References

J. Waldo, G. Wyant, A. Wollrath, S. Kendall, “A Note on Distributed Computing”, Sun Microsystems Laboratories TR-94-29, 1994 — a boundary between address spaces cannot be papered over; latency and partial failure are paid per call.
A. Hunt, D. Thomas, The Pragmatic Programmer, 1999 — DRY, stated as a rule about knowledge, not about typing.
M. E. Conway, “How Do Committees Invent?”, Datamation, 1968 — system structure mirrors the communication structure of the organization that built it.
Flutter docs, Add Flutter to an existing app and Multiple Flutter instances — engine warm-up, FlutterEngineGroup, and the cost of several live engines.

Previous: Local-first data · Next: Modularity and migration

Trading app architecture: six constraints and what they force

Fri, 28 Aug 2026 00:00:00 +0000

Also in 中文. A six-part series.

You cannot pick a trading client’s architecture by taste. Most of it is decided before you write a line — by how fast the data changes, what a wrong order costs, how big the catalog is, how many platforms and teams you have, and the fact that the app runs on a device you don’t control.

So the useful question is not “which stack.” It is: what does each of those constraints force, and what happens to the design when your version of that constraint is smaller?

That second half is the part worth caring about. Large financial apps converge on a recognizable shape, and the shape is often copied by teams who don’t share the constraints that produced it. What follows is the reasoning behind each element — informed by taking a large trading app apart and checking that the theory matched what a team at real scale actually built — and then the conditions under which each element is simply unnecessary.

The six constraints

1. Freshness. Market data is a high-rate, unbounded stream whose value decays in milliseconds. It cannot be polled, the consumer is permanently slower than the producer, and a silently dropped update is not missing data but wrong data. This forces a pushed, sequenced, back-pressured transport, and a decision about which streams may be conflated and which must be resynced. → Real-time data pipelines: push, backpressure, and conflation

2. Irreversibility. An order cannot be undone by the user, and exactly-once delivery does not exist. This forces an idempotency key minted and persisted before the first send, an explicit unknown state on timeout, reconciliation instead of blind retry, and a server that is the only source of truth. → Order reliability: idempotency, unknown states, and reconciliation

3. A large catalog. Hundreds of thousands of instruments, searchable instantly, including offline. This forces separating slow-changing reference data from fast-changing values, shipping a snapshot on the device, and syncing deltas against a monotonic version — while the ledger stays authoritative on the server. → Local-first data: snapshots, deltas, and the two kinds of state

4. Two platforms, one truth. iOS and Android must agree exactly on financial rules, and should not agree on interaction idioms. This forces sharing the layer where divergence is a defect and keeping native the layer where divergence is correct — and paying attention to the cost of the boundary between them. → The cross-platform boundary: share what must not diverge

5. Many teams, many years. The system must keep shipping while it changes shape. This forces module boundaries drawn around decisions likely to change, a core that receives its dependencies rather than reaching for them, and migration by growing the new inside the old instead of rewriting. → Modularity and migration: cutting boundaries that survive

6. An untrusted device. Every control you ship can be removed. This forces treating the client as an input and never an authority, keeping no secrets in the binary, auditing effective rather than declared policy, and treating every deep link and bridge call as hostile input. → The client security model: an input, never an authority

Flutter implementation notes

The six above are framework-neutral. This second group takes the same constraints down to a concrete Flutter build — with the patterns, the costs, and a reference design you could start from on Monday.

Flutter under a firehose — per-symbol notifiers, frame coalescing, and making rebuild scope match change scope
Channels, Pigeon, and FFI — the three ways out of Dart, memory ownership, and why EventChannel has no backpressure
Charts that hold 60fps — custom painting, static and live layers, and an honest shouldRepaint
Shipping a database with your app — bundled SQLite, data version vs schema version, FTS with pinyin search
Project structure and add-to-app — packages as enforced boundaries, routing as a registry, what embedding costs
A reference design: quotes MVP — a committed plan, what it deliberately doesn’t build, and the trigger for each upgrade

The decision rules

Every part above ends with “adopt it when a measurement demands it,” which is meaningless until someone names the measurement. One article supplies the numbers — frame budgets, message rates, catalog sizes, team sizes — the ladder of cheaper fixes to exhaust first, and the counter-signals that should stop you even past a threshold.

It also draws the distinction the rest of the series glosses over: correctness has no threshold. Idempotency keys, server-side authorization, sequence numbers, and decimal money are day-one work at any scale, because the cost of retrofitting them is unbounded. Only performance decisions wait for a number.

When to adopt the heavy machinery: thresholds, not opinions

Which of these are actually yours?

Each requirement came from a constraint, and constraints have magnitude. Shrink one and the requirement it produced collapses into something much smaller:

If your reality is…	The requirement…	becomes…
Data changes at human speed	pushed, sequenced, conflated pipeline	a WebSocket into UI state
Actions are reversible	idempotency key, unknown state, reconciliation	a request with a retry
Small or server-side catalog	on-device snapshot + delta sync	a search endpoint
One platform, or thin domain logic	shared cross-platform core	build it once, natively
One small team	module registry, ports and adapters	one codebase, no enforced boundaries
Low-value or public data	layered hardening	standard auth and TLS, done properly

Read the right column. For a small team building a quotes-and-watchlist MVP, this reasoning produces: one cross-platform codebase, REST plus a WebSocket, a search endpoint, no shared-core layer, no native performance work, no custom transport. That is not a simplified version of the large architecture. For those constraints it is the correct architecture, and the large one would be a mistake.

The large app is not more advanced. It is the same six constraints at full magnitude, plus years of accumulated migration state that no one would choose deliberately.

How to use this

Write down your own six magnitudes honestly. Work out what each one forces. Build only that.

Then adopt each heavy element on the day a measured constraint demands it — the queue actually grows, the profile actually points at the decode loop, the merge conflicts actually recur — and not one sprint earlier. Most of the cost of a large architecture is paid by teams who adopted it in anticipation of a scale they never reached.

What compounds is the map from constraints to structure. The structure itself is disposable, and someone else’s structure, copied, is a liability with good PR.

References

D. L. Parnas, “On the Criteria To Be Used in Decomposing Systems into Modules”, CACM 15(12), 1972 — a module should hide a decision that is likely to change.
M. E. Conway, “How Do Committees Invent?”, Datamation, 1968 — system structure mirrors the communication structure of the organization that built it.
J. H. Saltzer, D. P. Reed, D. D. Clark, “End-to-End Arguments in System Design”, ACM TOCS 2(4), 1984 — a guarantee is only real at the endpoint that can verify it.
M. Kleppmann, Designing Data-Intensive Applications, O’Reilly, 2017 — ch. 5 (replication) and ch. 11 (stream processing) are the background for the catalog and feed designs.
J. Bezos, Amazon 2015 Letter to Shareholders, 2016 — Type 1 (one-way door) vs Type 2 (two-way door) decisions.

The series is grounded in a static architectural analysis of a large trading app: what layers exist and how they communicate. No running app, no source recovery, no private protocols — and the detailed teardown notes stay out of the series deliberately, because the transferable part is the reasoning, not the artifact.

Mobile | kaguc — Writing to understand systems.

The cross-platform boundary: share what must not diverge

The test: is divergence a bug or a feature?

What sharing actually costs

The three positions

The mixed model, and what it really costs

Make the boundary coarse

Choosing, honestly

References

Trading app architecture: six constraints and what they force

The six constraints

Flutter implementation notes

The decision rules

Which of these are actually yours?

How to use this

References