One app for iPhone and Android.

Cross-platform app development builds one project that compiles to a real iOS app and a real Android app. Hybrid is the older approach and still the older word for it here: a web page running inside a native shell. Flutter and React Native produce native binaries and native views, so a shared screen behaves like the natively written one beside it. What separates cross-platform from native is not how a screen renders, it is how much of the app has to be written twice.

Three, consistently: the identity app-switch, the payment sheets, and anything the operating system owns, such as notification services and background limits. Signing in through the national identity app means leaving your app and returning, which iOS declares as a custom URI scheme inside the binary and Android declares as a queries entry in the manifest. Apple Pay and Google Pay are two sheets with two merchant set-ups rather than one payment integration. Everything above them, the cart, the order and the reconciliation, is shared.

Webzenia decides, in writing, once the integration list exists. Flutter draws its own widgets, which holds one visual result on both platforms and mirrors right to left when the directional widgets are used from the start. React Native renders the platform’s own components and shares logic, types and people with a React web product, which is the stronger answer when that team already exists. The call is recorded with the reasons and what reversing it would cost, because a framework is a multi-year commitment made in week two.

Yes, and the shared part is smaller than it looks. The authorisation flow and the session it returns are ordinary shared code. The app-switch is not: the app registers its own custom URI scheme, runs the flow in a web view, watches for the identity application’s scheme and hands over to it, in staging as well as production. Android adds a queries declaration, because the platform hides other installed applications unless an app asks to see them. The approval sits outside the build entirely, and the Dubai page sets out what it waits on.

The buttons and the flows do, the merchant set-up does not. Both wallets are reached through a single payment package on Flutter and on React Native, so the cart, the order and the reconciliation code stay shared. Each still needs its own merchant identity, its own certificates and its own settlement path. Card acquiring runs through a gateway you choose separately, which is a commercial decision rather than a framework one, and it is worth settling before the sheet is built rather than after.

Yes, if it is assumed from the first screen rather than added later. A layout written with start and end mirrors on its own; one written with left and right does not, and the correction is every screen a second time. Flutter needs its localisation delegates and directional insets, and Android needs the right-to-left flag in the manifest plus a mirrored resource set. Translation is the last step of that work rather than the first, and the typeface has to have a real Arabic companion, which is an identity decision made once.

Partly, and the part that survives is the part worth keeping. The API layer, the data model and the business rules move with you, because they are ordinary code that never depended on the framework. The screens do not: rewriting them in Swift and Kotlin is rewriting the interface. In practice the question is usually narrower than it sounds, meaning one feature that needs native, and that is a native module inside the same app rather than a new project.