Thoughts on Mobile Native and Cross-Platform Frameworks (2026 onwards)

I've been in Mobile Development since 2018 or 2019 when I was still a student and for some reason among the available options that time besides Native (Ionic, Xamarin, and React Native) it was React Native that peeked my interest that time. I heard of Flutter only around 2021 (pandemic era) and joined a bootcamp.

I think I favored React Native because JSX was cool, it looked like HTML and they said that React Native was considered a true native mobile application because it uses Native UI elements unlike Ionic although they both use Javascript (I also didn't like Angular) and Xamarin was too bothersome to learn because of the Microsoft Visual Studio thing, VS Code wasn't really that popular yet in my circles as I can remember.

Native was the obvious choice, in my case Java because it was the language we learned for Object Oriented Programming and it was the logical choice but I heard that competition in the Java space was hard and with Javascript, it looked like I had more options at that time, I decided to be more practical.

It's been a long time though and I've seen and experienced the worst of React and React Native as a library and as a framework respectively but for some reason I still spent 5 years professionally in React Native and eventually along with Express, React and Next.js as a Full Stack Developer.

In 2025, I made a bold decision and decided to try Native Mobile Development as a career. Thankfully, a company took a chance but eventually we transitioned to Flutter because of the company's needs.

With that, I want to share my personal thoughts, opinions, and experiences about Native and Cross-Platform Mobile Frameworks. My goal in this article is not to be too technical or too accurate but to offer a perspective based on experiences instead so take it with a grain of salt.

Since majority of my experience was in React Native, that's where I feel I should start and long story short, it's a great framework for people who are already experienced in Javascript especially now with Expo's tremendous growth and advances in truly making the ecosystem of React Native easier to get into.

It was such a nightmare before to setup the Bare React Native Workflow, I'd cry a lot just to get my first build to work on a new machine, I hope that someone reading could relate 🤣 especially with Gradle, Ruby, Cocoapods those were the absolute worst. You get used to it though, just pick a React Native version that was slightly older and more stable (though how would you know as a beginner haha I could only laugh about it now).

But the joy of watching one codebase build and hot refresh on two devices belonging to two different platforms was exciting, especially since I only had a Mac device and learned to use a Mac device on my first industry job in 2020 as a React Native Developer on a Macbook Pro with 256GB of RAM uhhh! another point in time I wanted to cry but right now I'm just laughing.

I think that's one of the most amazing things that keeps people in Cross-Platform is that a single line of code actually runs on Android and iOS and doing a bit of native development for some time, I admit Hot Reload / Hot Refresh was something I really missed.

Another amazing technology I got to use with React Native in 2021 was Over-The-Air (OTA) Update with Microsoft Codepush when it was still alive.

It truly saved us from a lot of resubmissions to the Appstore and Playstore because the app just listens for new Codepush updates and downloads the JS Bundle, perfect for quick updates like seasonal UI updates that honestly doesn't need to go through an app review. Though I later learned that if the changes became to too large, it takes some time for the bundle to be downloaded onto the device so you needed some kind of loading time. It was best to just stick with minor changes then submit a next major app release with those included. It was best to not rely on it to be the alternative for a official Appstore or PlayStore app submission.

I've learned some techniques as a workaround since then like storing data that influences the UI on the backend or remote config. Using backend feature flags to toggle specific features or behaviors you want. It was cool to look back on those learning experiences, continuously assessing and thinking of ways to make things better even till now.

And of course, you can't talk about React Native without JavaScript, the language that could do everything. I got into React Native when Typescript wasn't a thing yet, we just had JavaScript and it was a total nightmare and as an absolute noob in React, I didn't know about PropTypes at that time.

You could do a lot of cool shorthand syntax with JavaScript compared to Objective-C and Java at that time but times have changed and I have to be honest, Kotlin the appointed successor to Java for Mobile App Development in Android is a more pleasant language for me to write in than JavaScript/Typescript because you feel safer and it's just as much fun to write functionally in Kotlin with Jetpack Compose. Reading through Swift and Swift UI, they look kind of similar but I haven't tried it yet.

There was a lot of room for introducing magical errors with JavaScript but Typescript alleviated many of that (assuming you were using it right) and I think more than JavaScript was really the joy of Declarative UI through JSX and Functional Components that React and React Native provided at that time. Being able to think of UI in terms of both it's internal state and actual appearance in a single file is amazing whereas before you would have the layout file, the program file that creates a binding to that UI element and add logic and event listeners.

Unfortunately, a declarative UI (state-based UI) framework isn't a novel idea anymore in the mobile space. Flutter introduced Widgets a similar idea but executed without a HTML like syntax. Native Swift had adopted a similar paradigm through Swift UI, and Kotlin now has Jetpack Compose which I think is based on Flutter (Google's Product btw). I personally think that it's becoming all too similar which is actually a good thing in the end, because it means it's becoming a standard.

In terms of performance, React Native had a bad reputation before but managed to implement a new architecture overhaul to improve performance but I already stopped using React Native in 2025 and haven't gotten to compare how it practically feels in a large production project. But the move to JSI, Turbo Modules, Fabric and so on should have made it on par if not the same as Flutter?

The new architecture overhaul meant that the old React Native Bridge is already gone from newer versions and replaced with a more straightforward technology called JSI or JavaScript Interface, a lightweight C++ layer that provides direct referencing of native code and functions.

Right now in 2026, the reasons I think that people would go for React Native are:

1. They already know Javascript and don't want to learn a new language like Dart, Kotlin, or Swift to build a mobile app.

2. They're already working with a React project and want a mobile app that isn't just a mobile responsive website or PWA.

Maybe native SDK integrations like FaceID and Biometrics is necessary in their product but it looks like that barrier is growing thinner and thinner as time goes on with regards to authentication through WebAuthn https://webauthn.io/.

3. The most convenient for Over-The-Air (OTA) updates is important when you don't want to be bogged down by Apple Store reviews because they have a lot of questions about your app (idk), on PlayStore I've never encountered a review that got blocked though.

It's more convenient in JavaScript-based Frameworks because they just replace the JS Bundle. The main limitation of OTA on React Native, is you cannot push native code updates so a new native package will still require an app submission. But this technology is also available on Flutter through Shorebird but the process is different.

When I was assigned to work on the Android Kotlin project and worked on it a couple of months, I really loved it.

Everything just worked right of the gate, no weird errors due to JavaScript or Gradle or Cocoapods.

It's fast and the language Kotlin is an amazing language. It's a joy to work on.

I wasn't even using Compose on the production because it was already written using XML view-binding approach and I was liking it. With Compose, I feel like it was React but more elegant (except the Modifier though that's where I liked React Native Stylesheet object better). But in reality, Compose is more like Flutter and its Widgets.

Android Studio although heavier in consuming resources than VS code provides tooling that you wouldn't get in React Native without additional setup and configuration. Things like a Debugger, Accurate Logger, Device Explorer, Layout Inspector, and Layout Editor at the minimum. Setting up a Flipper vs React Native Debugger vs Reactotron is a rabbit hole I don't want to be part of again.

Packages are also a breeze, I didn't encounter any issues at least for the dependencies I needed.

I did have to learn the Android App Lifecycle more thoroughly than before though there's that as well as intricacies of Android with regards to services and intents. In React Native, there's usually a package that abstracts that.

There's not a lot to say though, it's great, performative, and works as it should which turned out better than I expected.

I spent months reviewing Kotlin and Android with Kotlin (previously Java) for this role and when you're working constantly in a specific field like Mobile, you start to see more common denominators and adjusting to another becomes easier although it isn't always 1:1 on every aspect.

Right now, I am happy with my decision.

If a company’s product was only exclusive on a single ecosystem like iOS, then go with Swift and Swift UI call it a day and vice versa for Android and Kotlin. But the market is mostly a duopoly so to reach out to the entire market, you’d need both so you’d end up developing twice on the two vastly different ecosystems.

There would be no problem at all if the teams were huge but even then just making sure that both apps looked the same and behave the same is one of the main challenge with this approach which I know is called feature parity.

It is (or was?) expensive to maintain two huge codebases because Android is usually a separate team and iOS is a separate team. Realistically you need dedicated developers that are experts in the ecosystem to be able to maintain that native codebase. An iOS and Android app may look the same but they are definitely very different under the hood.

The next hurdle is time. Since iOS and Android are different apps although they can look and feel the same, development time can look different for each one. Swift architecture and coding is different, the project maybe setup differently and same goes for Android because the 2 ecosystems have different ways of doing things and follow different principles and guidelines. Android development can be faster on a particular feature than iOS and vice versa. It isn't consistent and if you only have a small team, that time problem becomes more apparent if a developer(s) have to switch context from Android to iOS and vice versa just to get the same feature to work as expected and consistent on the two platforms.

Besides development time, debugging can also be a problem maintaining which leads to additional time consumption because the same business logic and implementation is written twice and separately based on the specific style of the ecosystem and developer. A bug on one of the common feature that is discovered on Android needs the Android developer to take a look into it and a bug on the same common feature that is also discovered on iOS needs the iOS developer to take a look. This is very frustrating, especially when the bug is business logic related. Kotlin Multiplatform or KMP is one of the solutions the Android team is introducing to address this issue natively but it's still young https://kotlinlang.org/multiplatform/ and adoption is not noticeable with all the AI hype currently going on in the developer space.

These are some of the reasons why switching to a Cross-Platform Mobile Framework like React Native or Flutter makes sense and highly convincing.

But as Shopify has shown us here https://shopify.engineering/shop-app-migration Shopify migrated from React Native to Native whereas previously in 2020 they moved from Native to React Native. So the above arguments are still true if it wasn’t for AI being capable enough to interpret a unified specification and generate code for both platforms which can then be verified and checked by the respective native developer teams that they have, making the work smoother.

So what’s the lesson? if you have a large budget for AI it’s better to go with Native and good specifications and prompts for platform specific needs? It still depends.

Their new workflow works but I can only imagine that the token costs would be astronomical and isn't worth it for a company smaller than Shopify and indie devs.

So I'll be moving on to my new favorite.

It took some time but we’ve arrived at Flutter. Here are the main things I really appreciate about using Flutter professionally compared to when I was using React Native in 2019-2025:

1. Setup was seamless, back in 2021 when I took that Flutter bootcamp and still now in 2026. Everything installed just worked out of the gate. Better than what I’ve experienced with the Bare React Native Workflow.

To be fair, setup is also seamless for Expo but the problem was in and before 2025 at least, not a lot of companies with existing React Native (RN) projects was migrating to Expo because they already had the bare workflow in a stable state. No cocoapods or gradle error.

2. The Dart language is type-safe at the core of its language. I just feel a lot safer that type-safety is built-in to the language of Flutter which prevents a lot of potential errors. Sometimes in RN, even if you were using Typescript, if the old package or library was Javascript, there was still potential for something to break unexplainably and you’d need to dig deep into the library source code to find out why which is a headache.

3. Flutter is performant. The iOS jank issue which was previously one of the deal breakers before is now non-existent in my experience with the new Impeller Rendering Engine (previously Flutter was using Skia) and the project I’m working on is a large app.

4. The UI appears consistent on both platforms right out of the box. On React Native, one of the selling points before was that the iOS app uses the native UI Cupertino themed components and the Android app uses the native UI Material themed components. But for Flutter, if your company has a specific UI branding, Flutter makes it easy to make it look the same and consistent on whatever platform you use. In RN, you’d have to use something like NativeWind which needs you to learn Tailwind or Tamagui.

5. Packages aren’t a headache. There were so many packages in React Native that gave me and my teammates a hard time. There were instances that a new iOS or Android version would break a package and we had to create patch in that specific package for it to work or upgrade or downgrade to a specific React Native version.

In Flutter, every dependency that I used and needed in our project just worked without any issues except for older packages that still needed Cocoapods instead of supporting the new Swift Package Manager (SPM) but from what I searched, React Native is also moving in the same direction.

6. Long lists run well out of the box on Flutter. Flatlist the default and built-in list component for React Native made life very hard for us in implementing certain feature requirements and had to try out other problematic solutions like recyclerlistview, react-native-big-list, react-native-largelist. Thankfully sometime later in 2024 I think or 2025, Flashlist appeared from Shopify which helped a lot.

7. Flutter’s built-in solutions and widgets are enough to get real work done. State Management, Networking, Navigation, Animations, Gestures, Keyboard, Safe Area, MediaQuery, Layout, Lists and Grids, other UI widgets, and Local Storage (RN AsyncStorage ehem and I’m aware that something better was made like react native mmkv).

8. The Flutter team actually prescribes an official architectural pattern (MVVM) that a complex project can learn to follow before trying to invent their own https://docs.flutter.dev/app-architecture/guide.

React Native has the same freeform philosophy like React since it started out as a library while Flutter I think based this on Android’s proven architecture guide https://developer.android.com/topic/architecture. A developer can immediately learn a proven and tested design pattern within the frameworks own documentation.

Honestly, it was just a breeze working on a Flutter project than I ever did on a React Native project especially now with AI but at the end of the day, they solve the same problems through different philosophies and methodologies.

Personally, I enjoyed coding on Kotlin more than on Dart but way better than on Typescript and so much better than Javascript. I think if I actually worked on a Swift and SwiftUI package, my opinion would be the same as Kotlin but I think the new Jetpack Compose is just more verbose and descriptive similar to Flutter (which is probably the main inspiration).

My conclusion in all of this is that with Flutter and Native you won’t go wrong but there’s a reason React Native is still loved to this day whether it’s Typescript or Over-The-Air (OTA) updates or Hot Reload/Refresh (which Flutter also has) and it can still compete well based on the needs of the specific developers.

It’s still best to try out each one and stick with which one helps you understand the process better then start from there. If you prefer to declare UI like HTML, you’ll most likely lean towards React Native, if a tree-like or parent and child like pattern then Flutter or Jetpack Compose or Compose Multiplatform (which I didn’t talk about because it’s still new). I think Swift UI is more similar to Jetpack Compose.

I hope that my story helped you make a decision on which technology to use for your mobile app project.

Have fun!