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 🙂
