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.