“What does an app cost?” closely followed by “Should we build a cross-platform app?” are the two most frequent questions I get confronted with as a developer. Neither of them have a straightforward answer, but for the latter I prepared a standard prelude:
You are asking a good question, but with the wrong intentions.
What follows usually depends on the asker’s background, but for this article I will try to keep it interesting for both people with and without a technical background.
Say you want to build a new application in a cost effective manner and heard that apps can be built just once and shipped to multiple platforms. Cross-platform development tools promise faster time to market at the same, or even or reduced, costs.
To some extent this is true. A first iteration, a Minimum Viable Product (MVP), something a bit more than a clickable prototype can usually be built very quickly. This is why we use cross-platform development at Conjure for proof of concept apps or internal tools.
People are usually impressed by the fast results and happy to ignore the fact that some functionality is missing and the UI is not yet perfect. This is absolutely fine if you don’t intend to actually ship it to end users.
However, if you do want to release this app, you will now be facing an unexpected long phase of feature completion and optimisation.
Up until this MVP, cross-platform environments will have you covered very well. Think of it as a showroom; every framework tries to deliver a smooth onboarding experience for developers and more often than not there will be some kind of template project or bootstrap command that allows you to start a basic app without writing a single line of code.
Integrating with native platform functionality like the camera, file-system, bluetooth services, etc, anything really that is more than just the UI will most likely require the use of third party libraries. This is not necessarily a bad thing and is common practice to use libraries — after all, you do not want to reinvent the wheel — however it adds yet another layer to your application, one that you can not control and might introduce bugs.
When building a native application you follow the platform’s standard and integrate directly with the OS or use other native libraries. A cross-platform application ends up with many more layers, and therefore more complexity.
This gets even more complicated when you can not use a cross-platform library for what you want to achieve. Maybe you want to integrate some proprietary libraries that are only available as native libraries, or you can’t find a cross platform library for your use case. In this case you will have to build a “bridge“ from your cross-platform code to your native code and you will end up with 3 programming languages instead of the one cross-platform code you were promised.
Big companies that use cross-platform tools tend to have teams that do nothing else than building those bridges. “React native enablement teams” is a name a company used that just stuck with me.
Don’t get me wrong! Cross-platform frameworks can be great!
There are many advantages in cross-platform development too, but depending on the framework you choose and the requirements of your application you will likely face some of the above challenges. At the end of the day, both approaches can get you great results, but both will require more or less the same effort.
Let me compare this with buying a car. Whether you choose an electric , petrol/diesel, or hybrid car, each has pros and cons and some might not work for your use-case at all. There is a price range from 10k to 200k and while the low budget car will get you from A to B, you will get an entirely different experience on the other end of the spectrum. The same applies here in app development.
Generally spoken: You get what you pay for.
So if it’s not cheaper and you don’t get the same performance, why do cross-platform frameworks exist?
Most of them were built to enable developers coming from other platforms to use their knowledge to build mobile applications. Each has a different background and was built with different intentions. Understanding these is key to deciding which cross platform framework to use.
RN is one of the most popular cross-platform frameworks. The slogan on the RN website states “Learn once, write anywhere”. The key here is that it is not “Write once, ship anywhere”. It’s not about building a single source web and mobile app, but allowing the use of the same programming language and concepts across platforms. It was developed by Facebook based on their JavaScript library, React, to allow their web developers to build mobile applications. Written in TypeScript and TSX, it renders native UI elements which usually results in a good performance and a native look and feel.
React Native is your choice if you have a large web development team familiar with React. Be aware, though, that you should hire native developers too to support them, particularly in the early stages.
Flutter is quite different from the other approaches in this list. It was built from scratch as a new framework to build cross platform applications and is the only one on this list not built with the intention of enabling developers to create mobile apps with their knowledge from other platforms. Their slogan is “Build apps for any screen”, and this already gives a hint on what Flutter is: a render engine. Of course it is more, but the key is that it does not try to use native UI components, but directly renders the UI using modern hardware accelerated graphic APIs.
Flutter might be a good choice if you start with a blank page. We frequently use Flutter at Conjure to develop internal tools and proof of concept apps.
Microsoft’s cross platform framework is the choice for .NET developers. As opposed to React Native, it’s write-once-run-anywhere and while the focus is on .NET and a single code base, it does allow to use native code as well. However it’s the only framework on this list that can not be used for web apps.
Want your team of .NET developers to build mobile Apps? Use .NET MAUI.
Ionic is “The mobile SDK for the Web”. As opposed to React Native, it does not render native UI elements but web content. If you already have a progressive web app (PWA), Ionic will help you bring it to the app stores in no time. The ionic team offers “Capacitor“ to access native functionality like camera, or the file system, but you might run into dead-ends if you require advanced control or specific native libraries.
A good choice if you want to bring your PWA on a phone.
At the time this article is written Kotlin MPM is still in beta. Kotlin is the programming language used to write Android applications. With Kotlin MPM it is now possible to share some of the code with iOS too. The benefit of doing so is more the consitsency in app behaviour, rather than in saving money. Kotlin MPM is the best option if you have a team of native Android and iOS developers that want to collaborate more closely and build apps on a single code base. Swift and Kotlin already have a lot in common so it won’t be difficult to pick it up for the iOS team. Make sure that everyone is on board and aware that it might not be 100% stable yet.
Kotlin MPM will enable your native Android and iOS teams to share business logic.
We have talked about when and why the team at Conjure uses cross-platform frameworks, explored challenges and limitations coming with it, and had a look at the backgrounds and intentions of some of the most common cross-platform tools.
Whether or not to build an app cross-platform should be a well informed decision made by business and developers together.
There is no cost saving — you get what you pay for.
