Native dual-track versus cross-platform is a product decision: sensors, release cadence and who tests on devices — not a religion.
Custom camera, Bluetooth stacks, background location or OS-specific payments can justify two codebases. You pay twice for UI polish and you gain a cleaner native story in review.
If Android and iOS show the same lists and the same transaction, cross-platform cuts duplicate screen logic. Name the native islands in the proposal. "One codebase forever" is not a requirement; it is a hope.
App Store review, privacy manifests and payment rules are not the same as Play signing and device coverage. Cross-platform does not merge those queues.
Who owns devices, OS versions and a regression pass should be in the plan. Emulators hide the jobs that fail in a warehouse, a cabinet or a pocket with a dead radio.
Yes if the API is designed as the product. No if the first client embedded business rules that the second cannot share.
They are UI layers. Native modules and a boring API keep you movable. A business rule trapped in a widget is the real lock-in.
Start where the users already stand. Many China field teams are Android-first. Consumer brands often need both stores in v1.
Tell us which sensors and which store must be in v1. We will say native, shared UI or a sequenced release at /en/contact/.