01 · Build decision
Should you build native or cross-platform?
Neither is the default answer. Choose native — Swift for iOS, Kotlin for Android — when the product depends on deep hardware access, top-tier graphics performance, or being first to a brand-new OS API. Choose cross-platform — React Native or Flutter — when one team shipping one codebase across iOS, Android and Huawei AppGallery matters more than squeezing out the last increment of platform-specific performance, which describes most business, e-commerce, content and marketplace apps.
This decision gets sold as a religious one — pick a side, defend it forever. In practice it's a project-by-project call, and we've shipped production apps both ways: native where the product needed it, cross-platform where it didn't.
The honest version of this comparison isn't "which is better" — it's which variables actually move the decision, so you can answer it for your own product rather than take someone's general-purpose opinion.
Side by side
| Dimension | Native | Cross-Platform App Development |
|---|---|---|
| Performance ceiling | Direct access to the platform's own graphics and processing APIs — the right choice for heavy 3D, AR/VR, or anything latency-sensitive. | Close to native for most business logic and UI; a real but usually small gap for the most demanding graphics work. |
| Reaching iOS, Android and Huawei | Three separate codebases, three release schedules, three sets of platform bugs. | One codebase targets all three — the reason most of our own apps are built this way. |
| Day-one access to new OS features | Available the moment Apple or Google ship it. | Usually available after the framework catches up — weeks, occasionally longer for deep API changes. |
| Deep hardware integration | The natural choice for custom camera pipelines, background processing, Bluetooth/hardware accessories, or OS-level widgets. | Possible via native modules/plugins, but adds a native-code dependency you're meant to be avoiding. |
| UI consistency across platforms | Matches each platform's own conventions exactly — sometimes the goal, sometimes extra work to keep two UIs aligned. | One design renders consistently everywhere — Flutter especially, since it draws its own UI rather than using platform widgets. |
| Team and hiring | Needs iOS and Android specialists, or two teams. | One team, fluent in JavaScript/TypeScript (React Native) or Dart (Flutter), covers every platform. |
| Huawei AppGallery distribution | Full native HMS Core integration — direct, but duplicated per platform. | Needs the React Native or Flutter HMS Core plugins layered in — AppGallery devices have no Google Mobile Services, so push, maps, in-app purchase and analytics all route through Huawei's stack instead of Google's, regardless of which approach you pick. |
- The product's core value is graphics or performance — games, AR/VR, real-time media processing.
- You need OS features on day one, not whenever a cross-platform framework catches up.
- The app leans hard on hardware — custom camera pipelines, background audio, Bluetooth accessories, complex widgets.
- You're building for one platform only, at least for now, and cross-platform's main advantage doesn't apply.
- You need iOS, Android and Huawei AppGallery from one team and one release cycle.
- The product is primarily business logic, content, forms and data — accounts, lists, marketplaces, bookings — which is most consumer apps, including all four of ours.
- Budget or timeline favours one codebase over three.
- You're validating an idea and want to reach every platform before committing to platform-specific investment.
Questions
About this decision.
Is cross-platform slower than native?
There's a real performance gap for the most demanding graphics and processing work — games, AR, heavy real-time media. For typical business, content and marketplace apps, the difference is rarely the thing a user notices.
Can a cross-platform app still use native device features?
Yes, through native modules and plugins — camera, biometrics, push notifications and most hardware access have mature cross-platform packages. It's custom, unusual hardware integration where native starts to matter more.
Does Huawei AppGallery force you into native development?
No. Both React Native and Flutter have HMS Core plugin support, so a cross-platform app can ship to AppGallery alongside the App Store and Google Play. It's an extra integration step either way, not a native-only requirement.
Can you switch from cross-platform to native later if the product needs it?
Often partially — some cross-platform apps migrate specific performance-critical screens to native modules while keeping the rest shared. A full rewrite is the expensive version of this and worth scoping honestly before it's needed.
Related service
Mobile App Development
Native and cross-platform mobile apps, web applications, APIs and the back-end that holds them up.
Want a second opinion on your specific case?
Send the details — this decision gets easier once there's a real product to weigh it against.