Cross-platform development with Flutter or React Native covers most business needs: one codebase runs on iOS and Android, and both the launch and the upkeep cost less. Native development is needed when an app pushes against the limits of the device: complex graphics, background sensor work, new system features on release day. The feature list and the maintenance budget decide, not framework fashion.
Key takeaways
A native app is written separately for each system, while a cross-platform app is built from one codebase for both. Native development means two apps, one in Kotlin for Android and one in Swift for iOS, and each calls system interfaces directly, with no layer in between.
Cross-platform development means one codebase plus a platform layer, from which the iOS and Android apps are built. Flutter apps are written in Dart, React Native apps in JavaScript or TypeScript, Kotlin Multiplatform apps in Kotlin.
Where the line between shared and platform code runs depends on the features: the more of them rely on a specific device, the more code has to be written separately for each system. The project itself goes through the same stages either way: analysis, design, app development for iOS and Android, testing and publishing.
There is no universal winner: cross-platform wins on time to market and maintenance cost, native wins on device access and on how quickly new system versions can be used. Compare the approaches on the parameters that end up in the quote and in the support plan.
| Criterion | Native development | Cross-platform development |
|---|---|---|
| Codebase | Two: Kotlin for Android, Swift for iOS | One shared codebase plus a platform layer |
| Reaching both platforms | Slower: every feature is built twice | Faster: one implementation for both platforms |
| Access to device features | Direct, to any system interface | Through ready-made plugins or your own native module |
| Interface | System components and the rules of each platform | Shared design, platform details tuned separately |
| Team | Android and iOS developers, two sets of tests | One main stack plus native skills for plugins |
| New iOS and Android capabilities | Available as soon as the developer tools ship | Once the framework supports them, or through your own native module |
| Maintenance after launch | Every fix is built and tested twice | One fix ships to both platforms |
| Main risk | Budget and timeline | Dependence on the framework and third-party plugins |
Native code pays off when the app spends most of its time working with the camera, sensors and wireless modules rather than with screens and data.
In such projects a cross-platform framework still has to be extended with native modules for both systems, and the savings disappear.
The cross-platform approach wins when the app is essentially an interface to your data and processes.
Device access in such apps usually comes down to the camera for QR codes, geolocation and push notifications. Flutter and React Native have ready-made plugins for these features, so little native code is left.
Pick the tool by what should become shared: in Flutter it is the interface and the logic, in React Native the JavaScript logic behind system components, in Kotlin Multiplatform the business logic, while the interface is up to you.
| Tool | Language | How the interface is built | When it fits |
|---|---|---|---|
| Flutter | Dart | Drawn by its own engine, identical on every device | A single branded interface and predictable animation matter |
| React Native | JavaScript or TypeScript | From iOS and Android system components | The company has a JavaScript web team and logic shared with the website |
| Kotlin Multiplatform | Kotlin | Native on each platform or shared with Compose Multiplatform | A native Android app already exists, or the interface must stay native to each platform |
Two well-known causes of stutter in cross-platform apps have been fixed in the frameworks themselves. Flutter draws the interface with the Impeller engine, which precompiles shaders instead of compiling them while the app runs: it is the default on iOS, and on Android since version 3.27 on devices with API 29 and above. In React Native 0.76 the New Architecture became the default: the asynchronous bridge between JavaScript and native code was replaced with direct calls through JSI.
Google officially supports Kotlin Multiplatform for sharing business logic between Android and iOS, and JetBrains’ Compose Multiplatform lets you share the interface as well. Adopting it does not require rewriting the whole app: shared code is added step by step.
Tip Choose a tool for which you can hire a replacement developer in your city: the app will outlive several specialists. Before deciding, look at recent job postings and CVs for each framework.
The promise of “one codebase for two platforms” holds for screens and business logic, but not for every system feature. If a capability is missing from ready-made plugins, a developer writes a platform module: Kotlin code for Android and Swift code for iOS. Flutter provides platform channels for this, React Native provides native modules.
So count not the share of shared code but the list of features that have no plugin. These are usually corporate device management systems, hardware such as scales, receipt printers and scanners, and partner SDKs released for one platform only.
Each such integration means two native implementations and a specialist who can write and update them. Check external integrations before the project is estimated:
Four local factors affect the choice: customers’ devices, payments, Telegram and the interface language. First, devices. According to StatCounter data for August 2026, Android accounted for about 83% of web page views from mobile phones in Uzbekistan and iOS for about 17%. This is a share of traffic, not a device count, but the skew is clear: many products can reasonably launch on Android first and add iOS as a second step.
Tip Before postponing iOS, check which devices your paying customers use: in website analytics, order data or ad reports. If the product is paid and aimed at a premium segment, the iOS share among buyers may turn out higher than the national average.
Second, payments. The Payme documentation still points to the official Android SDK, but its repository was archived on 2 August 2023, and there is no SDK for iOS. A card is linked in the app through the client-side methods of the Subscribe API, or the app opens the Payme checkout page with a return address after payment. Both options work from shared code without a native module, and your server receives payment confirmation directly from Payme.
Third, Telegram. Booking, orders and notifications can move into a customer account inside Telegram, with no store install and no yearly fees. This is how we built registration for UzFranchise Expo: guests registered in three languages and received QR tickets right in the bot chat. We build a bot for enquiries and bookings from $1,200, so compare this option with an app before you approve the budget.
Fourth, the interface language. An app for the local market usually needs Uzbek and Russian, often English too. In a shared codebase the strings are translated once; in a native project they are handled separately for Android and iOS, and mismatches between versions have to be caught by hand.
Development is only the first payment. After that the app lives by store rules: fees and update requirements are the same for either approach, while the cost of further changes is not.
Important Since 31 August 2026, Google Play has accepted new apps and updates only if they target Android 16 (API 36), and published apps must target at least API 35, otherwise new users on newer Android versions will not see them. The deadline can be extended on request until 1 November 2026. Apple has accepted only builds made with Xcode 26 and the iOS 26 SDK since 28 April 2026.
Start not with a framework but with a list of what the app has to do.
At Syntra Systems we go through these steps together with the client before estimating. If features touch the device rarely and both platforms are needed at once, we build a cross-platform app and keep native only the parts that cannot work otherwise. If the app mostly works with the camera, sensors and wireless modules, we build it natively and do not spend the budget on intermediate layers.
From there we run the project as one team: interface, backend, integrations with CRM and payment systems, publishing to both stores and support after launch.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
It's a common path: a product starts on Flutter or React Native, and a native version appears once load or new features call for it. You'd rewrite the interface and device-facing code, while the backend, the data and the store listings stay as they are.
In a typical business app built from lists, forms and notifications the difference is rarely noticed. It shows in complex animation, during long camera sessions and when the system gains a new feature that the framework does not support yet.
A hybrid app shows web pages inside an embedded browser (WebView). Flutter and React Native build a full app: Flutter draws the interface with its own engine, React Native renders system components. The hybrid approach lets you reuse a website but is more limited by what the browser can do.
The framework itself has no bearing on the review. Rejections come from the content: the app offers nothing beyond a website, breaks the payment rules, or doesn't explain why it needs the permissions it requests.
There's no ready-made Payme library for iOS, and the Android repository has been archived since August 2023. So the card is linked through Payme's own methods called directly from the app, or the app opens Payme's payment page and returns once it's done. Both approaches share the same code for iOS and Android, and payment confirmation reaches your server directly from Payme.
The catalogue, orders, profiles and notifications are stored on a server, and the app only displays that data. A server with a database and backups is needed under any approach and is paid for separately from the app stores. If the business already has a website or a CRM, the app connects to that rather than a second system being built from scratch.
An existing Android app can be kept as it is: Google officially supports Kotlin Multiplatform, a way to write shared logic — calculations and networking, for example — once for both Android and iOS. Shared code is added gradually, piece by piece, without rewriting the app as a whole.
Ask them to justify the choice with the feature list: which features touch the device, which ones have ready-made plugins and what has to be written natively. An answer like “we always use this framework” means the task was never analysed.
Sources
Cover photo: Arpit Brandings, Pexels
