One codebase
The app lives in its screens and your server, plugins cover the hardware it uses, and your users' OS versions fit the framework. React Native or Flutter carries both apps.
Cross-platform app development or native
Choose cross-platform or native by what the app has to touch — not by the budget.
A budget says how many codebases you can pay for, not whether one can do the job. Your feature list answers that: hardware, work done off-screen, the platform's own controls, new operating system (OS) features and the oldest phones in use. We build both ways, in Swift and Kotlin or in React Native and Flutter.
- Swift, Kotlin, React Native and Flutter
- Reviewed against OWASP MASVS before release
- We reply within one working day.
- Apple App Store Review Guidelines, 2.5.1
- Android Developers: Access location in the background
- Flutter architectural overview
- React Native: Core Components and Native Components
In brief
- What it is
- Cross-platform app development builds your iPhone and Android apps from one shared codebase, in React Native or Flutter. Native means two separate apps, in Swift and Kotlin.
- Why it matters
- Sharing works best where the app keeps to its own screens. Where a feature reaches the phone around it, such as Bluetooth, a sensor or work with the app closed, one codebase has less to share.
- What you get
- Your feature list marked line by line, a clear choice between three ways to build, and the app itself, reviewed before release against OWASP MASVS, OWASP's mobile app security standard.
What gets built
Three ways to build, and the feature list picks one.
A marked feature list points to one of these builds, and we build all three.
One codebase with native parts
Nearly everything is screens, but one feature needs platform code that no plugin supplies. That feature gets its own Swift and Kotlin, and the rest stays shared.
Native on both platforms
The app exists for off-screen work, a hardware link, or a platform feature due on release day. Each platform gets its own app in its own language: Swift for iPhone, Kotlin for Android.
For the frameworks, see React Native development and Flutter development. For native builds, see iOS app development and Android app development. After launch, app maintenance and support covers bug fixes, security patches and OS compatibility updates under a written support agreement.
What the app touches
The feature list decides before the budget does.
Each feature either stays inside the app's screens or reaches the phone around it.
Cross-platform app development shares one codebase between iPhone and Android. Sharing works best where the app keeps to its own screens: forms, lists, accounts and calls to your server.
The picture changes where a feature reaches past them: to a radio, a sensor, a scheduler the operating system controls, or a control the platform draws itself.
How the two frameworks meet the phone
- React Native. Its guide to core components says it creates the matching Android and iOS views while the app runs. Our React Native development page follows that to the native side.
- Flutter. Its architectural overview says Flutter builds and paints its screens itself, instead of translating them into the operating system's own controls. Flutter development covers what that changes.
Neither fact picks a winner by itself. What settles the choice is how much of the app sits near those lines, and whether those features are why anyone installs it. A step counter is mostly sensor. A booking app is mostly screens.
Reading the list
Which way each kind of feature pulls.
Mark every feature against these rows before you compare frameworks. The features people install the app for count most.
| What the feature touches | What decides it | Pulls toward |
|---|---|---|
| Screens, forms, lists, your own API | Code that stays inside the app | One codebase |
| Camera, Bluetooth, NFC, sensors | Plugin coverage for the exact device | Native when the link is the product |
| Work while the screen is off | Each OS's own background rules | Native when it is the core job |
| The platform's own controls and gestures | How closely each OS release is matched | Native when that fidelity is the brief |
| A feature Apple or Google just released | Whether it must ship on release day | Native when the date is fixed |
| Older phones and a wide OS range | The framework release's minimum versions | Whichever floor covers your users |
The terms in this table, in plain words
- Codebase: the source code an app is built from. Cross-platform means one codebase for both stores; native means one per platform.
- Plugin: a ready-made package that lets shared code reach a phone feature, such as the camera or Bluetooth.
- API: the interface an app calls to use a feature. Your own API is the one your server offers the app.
- NFC: near-field communication, the short-range radio behind tap-to-pay and tap-to-pair.
- Minimum version: the oldest iOS or Android version an app can be installed on. A framework release sets its own.
How we decide it with you
From feature list to finished app, in five steps.
The way to build is agreed with you before the build starts, and it rests on what the app has to do.
Bring the feature list
You list every planned feature, including ones for a later version, since those can change the answer. The panel shows what else only you can supply.
Mark each feature
Together we place each feature in a row of the table above, from screens and hardware to off-screen work and the OS range.
Check plugins and OS versions
For hardware, we check plugin coverage for the exact device, not the category. For older phones, we compare the framework release's minimum iOS and Android versions with the versions your users run.
Agree the build
The marks point to one of the three builds above. You see the reasoning before any code is written.
Build, review and release
We build the app, review it against OWASP MASVS before release, and handle store submission to the App Store and Google Play.
Off-screen work
What the app does when nobody is looking at it.
Background work runs on each operating system's terms, whatever the app is written in.
An app that tracks a route, keeps a wearable connected or uploads photos works under each OS's own rules. Android Developers' guide to background location says an app targeting Android 10 (API level 29) or higher must also check for a separate background location permission. It adds that Google Play restricts background location to apps that need it for their core functionality.
Those rules bind a Flutter or React Native app exactly as they bind a Swift or Kotlin one. So off-screen work gets designed per platform, which leaves less for one codebase to share. When that work is why the app exists, a native build such as our iOS app development keeps it in each platform's own language.
Off-screen jobs to list before choosing
- Location. Recorded with the app closed.
- Wearables. A connection kept open to a wearable.
- Uploads. Photo uploads that outlast the screen.
- Sync. Scheduled sync with your server.
- Push. Push messages that update the screen.
A feature Apple or Google has just released
When it must ship on release day, native code can use it directly. A cross-platform app reaches it through its framework, a plugin, or native code written for that one feature. How a new iOS version affects the framework and its plugins is in the FAQ below.
What the choice does not change. Each operating system's rules on background work apply to every app, however it is built. So does guideline 2.5.1 of Apple's App Store Review Guidelines, which says apps must run on the currently shipping OS. Store approval stays Apple's and Google's decision, whichever route you choose.
FAQ
Cross-platform or native, asked and answered.
Bluetooth, OS versions, new iOS releases and switching later. For anything else, ask us directly.
Cross-platform app development builds an iPhone app and an Android app from one shared codebase rather than two separate native apps. React Native and Flutter are the frameworks SecWiz builds with. The shared code holds the screens and the app's logic, and what else the app reaches on the phone decides whether that is enough.
It depends on how much of the app is the Bluetooth link. If the app pairs with a supported device and shows its readings, one codebase with a maintained plugin can carry it. If the connection is the product, with a custom protocol and work while the app is closed, native code keeps that logic beside the APIs it calls.
Only the versions its framework release supports. Find the minimum iOS and Android versions for the release you would build on and compare them with the versions your users run. A native app sets its own minimum in its own project, so an audience on older phones can rule a framework release out.
Apple's App Store Review Guidelines, in guideline 2.5.1, say apps may use only public APIs and must run on the currently shipping OS. That rule covers every app. For a cross-platform app, running on a new release also rests on the framework and plugins inside it, so their update path belongs in the decision.
Yes, as a rewrite of the app rather than a conversion. A backend built as its own service, with auth, sync, offline handling and push, can stay in place while the screens and device code are rebuilt. Taking over an existing app starts with a short assessment of its codebase and dependencies.
Yes. SecWiz builds native iOS apps in Swift and SwiftUI, native Android apps in Kotlin and Jetpack Compose, and React Native or Flutter apps when one codebase across both stores fits. Every build covers store submission, push notifications, crash reporting and a release process more than one person can run, and is reviewed against OWASP MASVS before release.
Let's talk
Bring the feature list.
Tell us what the app has to do, and the choice starts there. Project work is delivered remotely from India during business hours. We reply within one working day.