Free Website Audit: Discover what's holding your digital presence back
What does this choice actually decide?
The choice decides how many codebases your team maintains. Native means one Swift app for iOS and one Kotlin app for Android. Cross-platform means one React Native or Flutter codebase that builds both. Everything else — cost, release speed, hiring, long-term risk — follows from that one fact.
The choice does not decide quality. A bad cross-platform app and a bad native app fail for the same reasons: unclear scope, no offline plan, slow screens, weak error handling. Framework choice cannot rescue a product that has no clear job.
Write down what the app must do on the device before you compare tools. List the hardware it touches: camera, GPS, Bluetooth, biometrics, health data, background location, push notifications, offline storage. List the integrations: payments, CRM, ERP, login provider, analytics. That list decides the answer faster than any framework benchmark.
How do native and cross-platform compare?
This is a decision frame, not a score. The result changes with your feature list and your team.
| Decision criterion | Native (Swift / Kotlin) | Cross-platform (React Native / Flutter) |
|---|---|---|
| Cost | Two codebases, two builds, two test cycles. Highest build and highest run cost. | One codebase for both stores. Lower build cost and much lower maintenance cost. |
| Time to launch | Slower to a first release on both platforms, because the work is done twice. | Faster to a first release on both platforms from one build. |
| Who can maintain it | Needs an iOS developer and an Android developer, or two teams. | One mobile team maintains both apps. Web developers can often contribute. |
| Scale limits | No framework ceiling. Limits come from your architecture and your backend. | Hits a ceiling on heavy graphics, real-time media and very complex gestures. |
| Lock-in | Locked to Apple and Google platform tooling, which you need anyway. | Adds a framework dependency on top. You follow its release cycle and its breaking changes. |
| When it is the wrong choice | The app is a standard business app. You pay twice for a difference users cannot see. | The app is the device. Heavy 3D, camera processing, or a day-one platform API. |
Cross-platform apps still need platform work. Store listings, signing, permissions, push setup, app review and release notes are separate for iOS and Android whichever framework you pick. Nobody escapes that part.
Choose cross-platform when
- The app is a business app: accounts, lists, forms, bookings, payments, notifications, content.
- You must launch on iOS and Android at the same time, with one budget.
- You have one small team and you need it to cover both platforms after launch.
- Your feature roadmap is driven by business rules, not by new device hardware.
- You want to reuse a design system and API layer that the website already uses.
- The app will change often, and two release cycles would slow every change.
Choose native when
- The app depends on heavy graphics, 3D, AR or real-time video processing.
- The app processes camera or sensor data continuously, in the background, or offline.
- You need a platform API on the day the platform ships it, not months later.
- One platform carries all the value, so a second codebase is not needed at all.
- Strict platform rules apply: regulated health data, payments hardware, device management.
- Battery use and sustained performance are product requirements, not nice to have.
If one platform carries all your users, the honest answer is often “build one native app”. That is cheaper than a cross-platform app you only ship to one store.
How do you test the decision before you commit?
Take the three hardest screens in the product, not the login screen. Build them as a throwaway prototype in the framework you favour. Run them on a real low-end Android device and a real iPhone. Measure start time, scroll behaviour and the one interaction users repeat most.
Then check the integration list. For each integration, find the official SDK and confirm it supports your framework today. An integration with no maintained SDK becomes custom native code inside a cross-platform app. That is normal in small doses and a warning sign in large ones.
Last, check who will maintain the app in two years. A framework your team cannot hire for is a long-term cost, whatever it saves this quarter. Konzept covers this work under mobile app development, and the surrounding backend under software development.
What does it cost, and what does Konzept publish?
The framework moves the cost less than the scope does. Integrations, offline behaviour, roles and permissions, payments, and the admin system behind the app move it far more. A two-screen app and a fifty-screen app in the same framework are not the same project.
Konzept publishes starting project prices on the pricing page. Growth starts from EUR 14,500, Scale from EUR 29,500 and Enterprise from EUR 44,000. Monthly partnership plans start at EUR 1,200 for Support, EUR 2,350 for Core and EUR 3,450 for Accelerate. These are published starting prices, not a quote and not a market average.
Budget for the work after launch too. App stores change rules, operating systems change every year, and an app that is not updated stops installing cleanly. Plan a maintenance budget from day one, whichever framework you choose.
What should you do next?
Write the feature list, the device features you need, the integrations, the launch date and the team who will own the app afterwards. That document answers the framework question in most cases without a debate.
If you want proof of the kind of work involved, read the work portfolio. If you are still deciding whether to use an agency or hire, read agency vs in-house. If the app sits beside a website project, website cost in Bosnia sets the budget context.
When the list is ready, get a quote. Send the feature list and the integrations, not the framework name. We will tell you which build fits, what it costs and where the risk sits.
