Native or cross-platform? Choose from product constraints

Start with the product’s hardest requirement

Teams often compare frameworks by counting screens. That misses the parts that create long-term cost: background work, media processing, Bluetooth, payments, accessibility, offline synchronisation, widgets, platform-specific navigation and release ownership.

List the capabilities that would make the product fail if they felt slow, unreliable or unfamiliar. Those capabilities deserve more weight than the percentage of interface code that might be shared.

When native is a strong default

Native development is attractive when the product depends deeply on one platform, uses new operating-system features early or demands precise control over performance and interaction. It also reduces the translation layer between platform documentation and implementation.

The trade-off is organisational. Two native applications usually mean two codebases, more duplicated product work and a need to coordinate release behaviour. Native is not automatically higher quality; it simply gives the team direct access to the platform and its conventions.

• The experience relies on advanced camera, media, Bluetooth or background capabilities.
• Platform-specific features are a product differentiator rather than an edge case.
• The organisation can sustainably staff and review both platform codebases.

When a shared codebase earns its place

A cross-platform approach can be effective for products whose core value is shared across platforms: forms, content, learning flows, commerce, scheduling or account-based utilities. A shared implementation can reduce duplicated feature work and make small teams faster.

That advantage is real only when the team treats iOS and Android as distinct environments. Permissions, back behaviour, text scaling, keyboard handling, in-app purchases and store policy still require platform-specific attention. Shared code does not remove platform work; it concentrates it at defined boundaries.

Use a weighted decision table

Score each option against the constraints that matter to this product: required device APIs, launch timing, team experience, accessibility, offline behaviour, expected lifetime, test automation and ownership after handover. Give the highest weight to product risk, not developer preference.

Build one technical spike for the riskiest integration before committing. A week spent proving background location, media export or a complex SDK is cheaper than discovering the limitation after the whole interface exists.

Decide how updates will be owned

Every mobile stack sits on moving foundations: operating systems, build tools, store requirements and third-party SDKs. Ask who will review those changes, how often dependencies are updated and what happens when a framework or plugin lags behind a platform release.

Document the decision and its assumptions. If the team size, product direction or platform requirements change, revisit the decision instead of defending it as permanent architecture.

Worked example: score the risky integration before the interface

Imagine two candidate products: an offline question bank and a camera tool that exports edited video while the user leaves the app. Both have lists, settings and purchase screens. Their hardest requirements are different, so the percentage of shared screens is a poor basis for choosing their architecture. These are illustrative product scenarios, not performance measurements.

For the question bank, first prove local content updates, saved progress, text scaling and purchases on both platforms. A shared interface may be useful if the team can maintain the store and storage boundaries. For the camera tool, first prove capture interruptions, export cancellation, background limits and recovery after the operating system reclaims resources. A working demo on one device does not settle those questions.

Make scoring explicit. For each candidate, give each criterion a score from zero to five and multiply by an agreed weight. Mark an untested requirement as unknown rather than assigning a reassuring midpoint. The arithmetic ranks documented assumptions; it does not make missing evidence disappear. Any mandatory requirement that fails should block that option even if its total score is higher.

Use the same input and acceptance conditions for each technical spike. For a video export, record the input format, output settings, device, operating-system version, elapsed time, memory observations, cancellation behavior and whether the output is usable after interruption. Do not compare a compressed sample in one framework with a full-resolution file in another.

The decision record should name the native code or plugins still required, their maintenance owner and an exit path if support stops. If the only engineer who can maintain a bridge will leave after launch, include that ownership gap in the decision. Revisit the result when a new product promise changes the risky integration.