In their 12 years of existence, mobile applications have come a long way.
In 2008, there were a mere 500 of them. Today, there are more than five million. (1)
Whether Apple’s 2009 ”There’s an app for that” commercial was a marketing mantra or an actual prophecy, one thing is for sure — the way we communicate with and experience the world around us has completely changed in the past decade; a lifestyle shift in large attributed to the small squares neatly arranged on our screens.
So much so, in fact, that this app-driven life we have come to lead has us checking our phones 58 times a day, with 90% of this time spent on app usage. (2, 3)
Naturally, businesses both big and small have closely followed the mobile trend, understanding a proprietary app increases their visibility, cultivates customer loyalty, and improves their bottom line.
Worldwide, mobile app revenue (paid downloads, in-app purchases, and advertising) is projected to inch close to $600 billion, with figures expected to rise as having a business app is becoming a norm for any up and coming company. (4)
Apps, therefore, are not only in high demand, but they can be highly profitable. Yet when it comes to building one natively for both Android and iOS, high development costs and slow deployment times can place tremendous pressure on even the most ambitious of teams.
The good news is, there is a way around it.
One codebase to rule them all: cross-platform mobile development pros & cons
Those of you who have been keeping an eye on the app development scene will already have heard of them – Xamarin, React Native, Flutter, Cordova, and the like.
Over the years, these frameworks have satisfied the cravings of companies looking to reach smartphone users of both iOS and Android platforms (which comprise 98% of the mobile OS market), without actually developing two separate apps for each operating system. (5, 6)
By doing so, they’ve managed to benefit from:
- Same accessibility with half the effort. One of the biggest benefits cross-platform app development offers is the ease of code reusability. Instead of releasing multiple native apps for each platform, you can reuse a significant amount of code and have the same app deployed across multiple platforms.
- Reduced costs. Because the code is written once, the development team will have to put in half the effort which translates into reduced production, maintenance, and hiring costs. The need for learning a platform-specific language is also reduced as fluency in JavaScript, C++, C#, and HTML5 will in most cases suffice for cross-platform development.
- Shorter time to market. Less work also means quicker deployment times. Subsequently, less time spent in development means you can deliver value to your customers faster and tweak your applications according to their feedback sooner.
- Near-native feel. Despite the substantial UX and UI differences between iOS and Android, cross-platform apps can emulate the native feel by handling design and navigation mismatches by default.
These benefits seem almost too good to be true. Why would anyone go down the native route and build two separate apps for both platforms when you could gain the same accessibility by doing half the work?
Turns out there are quite a few reasons, including:
- Language barrier. One of the main challenges that come with cross-platform app development is the fact developers are writing an app in a non-native language. This means they won’t have the same access to the native components simply because the code is written in a higher-level language. To bridge the two, they need to rely on third-party libraries specific to each framework, and the younger the framework is, the scarcer the library.
- UX discrepancy. Because both Android and iOS have very specific graphical user interfaces (navigation, buttons, menus, etc.), more effort is required to achieve a native feel for each platform. Sometimes, the labor put into making this happen outweighs the above-listed benefits.
- Performance issues. Performance is another known dealbreaker, and even though the differences are for the most part minute, developing a mobile game with Flutter or React Native won’t match the native technology.
- Size. Depending on the framework, code linkage and third-party plugins can nearly double the file size of your cross-platform app. And as you can imagine, larger apps don’t get as much love as their lighter counterparts. Not only do they require more storage space on the user’s device, but they also take more time and data to download. In fact, Google Play Apps & Games published a report showing a 100MB app will receive ~30% fewer downloads than an app that weighs around 10MB.
- Your target audience. Finally, you may only need to serve Android or iOS users, in which case going native would make perfect sense. The programming language is now fully compatible with the platform and the device, meaning your developer won’t have to fish out that gyroscope plugin for Cordova.
You can see now how cross-platform development is not all roses. Plenty could go wrong and it’s up to you to decide whether this is a worthy approach for your project.
Still, for a vast majority of businesses (the likes of which include Facebook, Google, and eBay), the cross-platform development approach has proven to be a cost-effective, trustworthy method for building apps.
Let’s evaluate some of the leading frameworks in 2020 and see where they shine and where they fall short.
React Native: write once, deploy anywhere
Founded by Facebook in 2015, React Native has quickly cemented itself as one of the most popular cross-platform development frameworks among developers.
The main driver behind its large-scale usage is the framework’s programming language, JavaScript, which is used on 95% of the world’s 1.7 billion websites. (7, 8)
This means a developer who has already built a website using JavaScript won’t face a steep learning curve when working on a cross-platform app in React Native.
Another huge perk React Native brings to the table is its ability to successfully mimic a native feel of an application. While it doesn’t include many UI components out of the box, there is an abundance of third-party components that make for a smooth native experience.
The trouble is, when you rely too heavily on external libraries, you may be trading a native-like feel for slower performance. Because React Native requires a bridge for its native wrappers, you may end up with an app that has too many native calls, causing performance issues.
Cordova: is WebView worth it?
Much like React Native, Cordova is an alluring option for web developers who get sold on the idea of reusing their existing HTML, CSS, and JS skills to build an app for both Android and iOS.
On paper, Cordova looks like a dream. There are a bunch of tools and libraries that make your life easier — Ionic, for example, is great for handling UI and integrating additional services such as fingerprint biometrics and payment processing into your app.
But tread carefully before you jump on the Cordova wagon. If you’re unaware of the framework’s (and your own) boundaries, that dream can quickly turn into a nightmare.
First of all, it would be senseless to write a serious game or a heavy app with Cordova. Unlike React Native, which calls native functionalities through a bridge, Cordova renders the code in a WebView, and running an app this way can not only cause a significant loss in performance, it also makes the app prone to XSS attacks.
You’re also likely to spend some time on workarounds for platform-specific bugs. Sometimes, this process will involve a good deal of frustration, as native functionalities you’ve always taken for granted now need to be patched with plugins that require customizing or worse, developing from scratch.
For small, simple apps, Cordova is an option worth your while. Lifestyle, news, event, educational, and messenger apps, for instance, have been and can be easily built with Cordova, which at the time of writing takes up 7.88% of the app market share.
But if you’re developing an animation-heavy game, consider using the native approach. You’ll lose more time on figuring out the related workarounds than you have saved by writing a single codebase.
Xamarin: the cross-platform OG
Xamarin was among the very first open-source frameworks launched in an aim to bridge native platforms and make mobile development a less expensive affair.
And although Xamarin was released in 2011, it wasn’t until its acquisition by Microsoft in 2016 that the development community finally started lending it some credibility and traction.
Today, it’s one of the go-to cross-platform development frameworks, counting over 60,000 contributors from more than 3,700 companies. (9)
Based on C#, an object-oriented programming language, Xamarin is deemed by many to be more difficult to learn than React Native, though the code works seamlessly on a range of platforms, including Android, iOS, tvOS, watchOS, macOS and Windows.
Additionally, developers are equipped with all the tools they need to build their cross-platform app through .NET, including platform-specific APIs, packages, and XAML.
Now, there are two paths to choose from when building an app in Xamarin, both of which enable near-native performance levels.
- Xamarin Native offers a low-level approach to building separate applications for each platform with Xamarin.iOS and Xamarin.Android libraries. It’s a basis for exposing some native functionalities to Xamarin Forms by calling platform-specific APIs.
- Xamarin.Forms is a framework on top of Xamarin Native with all functionalities of Xamarin. It’s a better option for those just starting out with Xamarin as developers are able to reuse up to 96% of the code and product owners can scale and maintain their apps more easily.
Flutter: the new kid on the block
Unlike React Native and Xamarin, Flutter is a framework that’s only been around for a few years.
But despite being a novice on the market, Flutter has sent shockwaves through the community ever since its release by Google in 2018, proving to be a reliable, innovative contender.
Its programming language, Dart, may not be as popular as JavaScript, but it’s relatively easy to learn; for one, much of the syntax is similar to Swift, Kotlin and Java, meaning developers with C/C++ experience won’t have too much trouble switching to this object-oriented way of building apps.
And even if they hit a few roadblocks down the road, Flutter provides extensive documentation to support their transition.
Next comes Flutter’s architecture, which, compared to React Native, doesn’t rely on JavaScript Bridge to translate the calls into native API. Code written in Dart compiles into native machine code, resulting in smoother, improved app performance and better UX.
Yet Flutter’s way of communicating directly with the platform using its own library of built-in components is not ideal. Third-party plugins are hard to come by and hardware-specific APIs are not nearly as plentiful as with React Native, making Flutter an inferior choice for hardware-dependent apps.
Also worth mentioning is the fact C/C++ engine and Dart get quite bulky, and while apps made in Flutter may run better, they will take up a lot of space.
Still, the widgets you get out of the box are fully customizable and combined with the hot reloading feature make Flutter an ideal framework for developing an MVP app with a bespoke, pixel-perfect UI.
Which framework should you choose?
Well, the answer to that question will largely depend on the goals you’ve set to achieve with your app, as well as the time and budget you can allocate to its production and maintenance.
Whichever approach you opt for — native, cross-platform, or even a combination of the two — mobile isn’t going anywhere. On the contrary, we’re expected to spend an average of 3.7 hours on our smartphones per day this year, a 10% year-on-year increase and a 35% growth from 2017. (10)
Whichever way you decide to build your app, rest assured Microblink will be there to support you when you need a powerful, seamless scanning solution integrated within it.
