Native or cross-platform? Start with the awkward requirements

The login screen won't settle this

A login screen and a scrolling list make a reassuring prototype. They may tell you almost nothing about the requirement that will determine your mobile architecture.

Consider a hypothetical warehouse app. Its ordinary screens are simple, but it must work with a particular scanner, keep useful state when a connection drops, and recover from interrupted synchronization. Those are better starting points for a technical evaluation.

For this discussion, native means building in each platform's own application stack; cross-platform means sharing substantial application code across platforms. Neither label answers the warehouse team's questions. Start with the behavior that could force an expensive change of direction, not the screen that's easiest to demonstrate.

Give the prototype a narrow job

Before asking for a framework recommendation, write a short risk brief. It should name the device or integration involved, the exact behavior required, and the conditions under which that behavior must hold.

• Which scanner model and connection method are required?
• What can the user do without a connection?
• What happens if the app closes before data is sent?
• How should duplicate scans or conflicting updates be handled?

Build a focused technical test against those questions. Keep its interface plain. The goal is evidence about feasibility and implementation effort; attractive screens would only make an unresolved technical problem harder to notice.

Use requirements to direct the comparison

This table is an evaluation plan, not a universal framework ranking. Apply it to the actual app and its intended devices.

Give a failed test a documented consequence: another approach, a changed requirement, or a deliberate limitation.

Inspect the code after the demo works

A successful prototype is the start of the comparison. Now ask what it took to make it work.

Was the implementation straightforward, or does it depend on a fragile workaround? Who maintains the library involved? How will the team diagnose a failure on one operating system? If a shared implementation needs specialized code, record that boundary and the expertise required to maintain it.

Evaluate native options with the same discipline. Separate platform builds need an explicit plan for keeping product behavior aligned. Don't treat familiarity as proof that ongoing work will be small. Ask both proposals to explain their exceptions, upgrade path, and testing responsibilities.

Flutter documents both shared multi-platform development and cases requiring platform-specific code or plugins. That is why the integration test matters; see Flutter’s platform-integration documentation.

Price the team you will need later

A build estimate without an ownership model leaves half the decision unfinished. Compare who will update dependencies, investigate device-specific issues, and carry changes through release.

Ask the proposed team to describe a plausible future change, such as adding another scanner or revising a permission flow. Which code changes? Which tests run? Where would they need specialist help? Their answer is more useful than a promised percentage of code reuse.

Also establish the test matrix. Shared implementation should never be used as a reason to skip checking the target platforms. The buyer needs confidence in the delivered behavior, not a smaller number of source files.

Make the choice explainable

Record the decision in a short architecture note: the tested requirements, evidence, remaining limitations, and reasons for choosing the approach. Include what would make you revisit it.

A sensible decision may favor native development because a demanding integration dominates the app. Another may favor a shared implementation because the important flows remain common and the exceptions are manageable. Both need evidence from the specific product.

Before approving the larger build, ask for one demonstration: the awkward requirement working on an intended device, with an explanation of the code and maintenance behind it. That's a stronger basis for commitment than a framework debate.