• Home
  • Blog
  • Native vs Flutter vs React-Native: Why do we go for native Swift and Kotlin apps?

Wondering what’s the difference between cross-platform and native Swift and Kotlin apps? Which one to choose if you are a startup or an existing business? We’ve got your questions covered in this article.

Native vs Flutter vs React-Native: Why do we go for native Swift and Kotlin apps?

Wondering what’s the difference between cross-platform and native Swift and Kotlin apps? Which one to choose if you are a startup or an existing business? We’ve got your questions covered in this article.

Kirill Stativko

CEO, Software Architect

share

table of contents

Expand
  • 1. Features
  • 2. Performance
  • 3. Ecosystem and community
  • 4. Team and skills
  • 5. Speed and development cost
  • 6. Publishing and review
  • 7. What to choose?

My answer stems from all the pitfalls collected during my journey in mobile application development since the beginning of iOS/iPhoneOS and Android platforms, which lasted for more than 14 years. It’s based on my experience in building native, hybrid, cross-platform mobile applications for early-stage startups and serious businesses.

Let's examine the differences in terms of:

Features

In my experience, cross-platform is great for apps that don’t use platform-related features a lot. E-commerce, news readers, and other screen-to-screen-like apps would be reasonable to build there. If your mobile app can be replaced with a Progressive Web App that runs in a mobile browser with no difference in user experience and functions, you can definitely think about cross-platform.

But think twice before choosing a cross-platform if you are planning to develop the app that:

  • has advanced multithreading or background data processing;

  • requires advanced performance optimizations and algorithms;

  • uses on-device machine learning algorithms;

  • works in the background and plays video and audio content;

  • stores massive on-device data and could work with no internet connection.

  • communicates with device sensors, Bluetooth devices, and NFC;

  • uses advanced camera features and image processing;

  • uses system app extensions (advanced push, keyboards, iMessage, etc.).

  • uses encryption a lot.

  • uses audio or video calls.

In all cases above you have to add iOS and Android engineers to your team. They are the ones who will help with native code bridges. But keep in mind that in most cases, developing code bridges takes more time than the same exact feature with regular native code.

Performance

Weirdly enough, performance is not an issue. Powerful modern devices can handle running cross-platform frameworks just fine. Where the problem could arise is the battery - usage, draining and heating can get you in more trouble than not-so-smooth animation. So, naturally, with Native code you have way more options and tools for optimization on any level, going far beyond framework limits.

Let’s dive briefly into the difference between Native, Flutter and React Native:

Flutter is like Unity for non-game mobile apps. It uses GPU-accelerated rendering with their own 2D UI library, and contains all the benefits of GL technology. The FPS in 3D games is impressive, but you can achieve even greater rendering speed for 2D UI. This is a great idea, and I really like this approach, but it wasn’t invented by Google. Long before the Flutter era, some trading apps were made with the help of gaming engines to be super responsive in UI and 2D data visualization.

React Native, on the other hand, has a different philosophy - it translates its core components into similar platform-related native ones (e.g. React View into Android View or iOS UIView). This allows you to get near-native performance - hence, the name React Native.

If you are curious about benchmarks, feel free to check this article

Ecosystem and community

Cross-platform will always lag behind native development, which is a problem with no solution. There are more and more new features and api appearing constantly in native SDKs, available for use the day after WWDC or GoogleIO conferences. At the same time, I don’t believe that Flutter will ever become an official programming language for Android. Even less I believe in Apple switching to Flutter any time soon. Apple and Google aren't going to stop supporting Swift and Kotlin, but there is no guarantee that Google’s support for Flutter is going to go on being as fierce as it is today, under the pressure of Kotlin Multiplatform Mobile (KMM).

Both Flutter and React Native have great communities with millions of developers, but keep in mind that Flutter is still young. It’s got more than 10k issues on Github in the official Flutter repository, many of which take quite a long time to get fixed. React Native is doing better here, with just 2k issues on its Github so far. Still, in my view, it drags behind Flutter when it comes to technology.

Can you name any well-known React Native / Flutter-built apps? First thing you might think of is Slack - which is cross platform on desktop, but the mobile versions are all native.

Microsoft Teams? It definitely is built with React Native, but I wouldn’t say the smoothness of it defies description on both mobile and desktop. Yet, if I was in their shoes, I would do the same and develop the “superapp” in hybrid mode - this way it encapsulates a lot of different tools inside.

Take a look at what other famous apps were built with Flutter and React Native:

The list is smaller than expected, isn’t it?

There is a logical explanation here: Big companies that know their business well choose cross-platform not in order to cut costs on development. In most cases, it’s to standardize their product and its codebase, which is very reasonable for companies with long history like Microsoft, Facebook or Shopify.

Team and skills

If you’re a big company, you probably know what you’re doing. Your choice of cross-platform is motivated by your product complexity, you’ve made R&D and PoC before you started re-writing/creating your product, and there is most likely already a bunch of good cross-platform engineers in your team. They know exactly where cross-platform gets you the most benefit.

In case you’re a software agency, the situation is a tiny bit more complicated. Still, most likely you have mobile developers under your wing, who can consult and help each other.

But watch out if you’re an early-stage startup. You’re lucky if your cross-platform developer is an ex- to Native and they know the pitfalls of mobile app development. In most cases, you don’t get that kind of luxury. Normally, there’s already a web developer in your team who tells you he can develop a mobile application all by himself. Then, at the first pitfall comes the understanding that mobile application is not the SPA wrapped into tiny-client and it’s time to consult with your iOS and Android teammates. Alternatively, they can always spend days in frustration browsing Github issues to find a solution or trying to fix the library.

Speed and development cost

Surprisingly, the use of cross-platforms doesn’t at all equal faster development, especially if your app is hybrid. I know a lot of examples where the management team decided to add some cross-platform features into an existing market-known product. As a result, it took ten times longer than it could have, had it been Native on both platforms. The reason is, your product already has CI/CD pipelines with auto tests that should be modified. But you will learn quickly that build process gets more complicated. Not all auto tests are going to work on cross-platform screens. Additionally, your Manual QA will lose a number of handy tools for testing, which he is accustomed to work with. So, you have to be ready for that.

You can read good articles explaining Airbnb experience with ReactNative

Publishing and review

So, you want to get published in app stores?

If you’re a big company, publishing time could be ignored. It’s a fraction of how long the whole development process takes. Most likely you have a marketing department that works simultaneously with the dev team.

In case you’re an early stage startup, the following info might be useful to read. In my experience, most cross-platform-web-developers skip sections of framework documentation, explaining the code signing and publishing process. They turn a blind eye to configurations that are mandatory for each platform - because they know better. Bundle id, code signing process, cross application data sharing, debug symbols, push notifications extensions, deep linking - they will learn it later. My guess is, they’ve never had a paid developer account in the App Store, nor have they seen App Store Connect and Google Play console. Keep in mind that the publishing process is not instantaneous as it is, and the absence of knowledge at developer’s hand makes it only more lengthy.

And don’t be surprised when you get your first rejection from the review team because your app doesn’t follow App Store and Human interface guidelines. Most of Native developers likely have such experience and know the pitfalls of the review process - that’s their job.

What to choose?

At the end of the day, your final choice isn’t going to be dictated by pros and cons of the framework, but rather a big picture of your project. Cross-platform is the kind of consensus between the resources you have, the aims you set and speed you’re striving for. In any case, you will have to choose based on what you have on hand rather than achieving the all-around picture-perfect product. As an existing business, the choice of cross-platform should be motivated by the aims you’re planning to achieve Vs. potential lock-ins you might get. But in case you’re a startup building your PoC, cross-platform might be a great first choice if you’re ready to start from scratch again later.

So, choose wisely

… or try out CodePlatform! That is why we’ve built it with Swift and Kotlin native code 🙂

    Features

  • What are the differences between native, hybrid, and cross-platform apps?

    We should differentiate fully native-coded and cross-compiled apps. Native-coded apps are written on platform-designed language (e.g., Swift/Objective-C or Kotlin/Java). They are built using platform SDKs only, whereas hybrid (partially cross-platform) and fully cross-platform apps utilize cross-platform frameworks (e.g., Flutter or React Native). A good example of a hybrid app would be a messenger super-app where chat and calls are native-coded, but the e-commerce part is built on cross-platform.

  • What kind of apps is reasonable to build with cross-platform?

    The apps that don't use platform-related features a lot. E-commerce, news readers, and other screen-to-screen-like apps. Talking about real examples: UberEATS-like (but not Uber and Uber Driver) apps, eBay-like ones, Expedia-like ones, and games.

  • What are the benefits of native application development?

    Complete control over your app behavior, as there are no lock-ins to cross-platform frameworks. Stability and performance, as well as the full power of native code - you can use new APIs and features the day after WWDC or GoogleIO conferences.

  • Why is there little info on Kotlin Multiplatform Mobile?

    Because it's not precisely the cross-platform framework that you expect. KMM provides a single codebase for the application logic, but you have to additionally implement native UIs and leverage other features specific to Android and iOS devices. It's mostly used by teams of professional developers in complex products.

  • What are the pros and cons of Flutter?

    It's fast, modern, and easy to use. It supports a wide range of devices. In theory, it allows you to create an app simultaneously for web, desktop, mobile and TV. But in practice, not everything is rainbows and unicorns - some parts have been released very recently or are still Beta. So, you may experience a couple of restrictions or a lack of necessary functionality out of the box.

  • What are the pros and cons of React Native?

    It's still React but in a different wrapper. It allows you to share the codebase with your web app if you're building it on React. It's JavaScript that we're all used to, only cross-compiling into native apps with good performance on the way out. There's a vast pool of existing developers, but ideally, they have to be ex-mobile developers. On the other hand, it can't be ruled out that Flutter may supersede React Native in the future. Additionally, React Native is designed for mobile apps, so you'll have to use community/partner editions for desktop ones or create a separate app with Electron.

table of contents:

  • 1. Features
  • 2. Performance
  • 3. Ecosystem and community
  • 4. Team and skills
  • 5. Speed and development cost
  • 6. Publishing and review
  • 7. What to choose?

Subscribe to new posts

Get updates on the newest features, tips and how-tos delivered to your inbox.

Get weekly updates on the newest design stories, case studies and tips right in your mailbox

What is CodePlatform?

What's next?

Start building great apps today

Talk to sales
Need a hand with development? Explore experts