How to Choose the Right Mobile App Development Approach

Working on a project that involves building a new mobile app? Do you have an existing web application that you’d like to deploy to mobile? Are you new to mobile application development?

If any of these are true, then you might find this guide valuable for choosing the right mobile application development solution for you. The last part of that sentence (“for you”) is important, because one app development approach might be great for someone else’s project, but not the best fit for you or the project you’re working on.  Before you pick a solution, it’s best to think through your options carefully, instead of going with the first recommendation you get or the most popular solution at the time.

I’ll try to keep this guide brief and focus on the key distinctions between each mobile app development approach. There’s a lot to talk about on this topic, but there are actually a small number of key factors that you need to consider. Let’s jump in.

Native or Cross-Platform

Your first decision is whether to build with the native SDKs provided by Apple and Google. 

To answer that, think about what sort of languages, tools, frameworks, and libraries you’re already familiar with. Odds are, if you’re reading this you probably don’t have much experience with Swift or Kotlin, the languages used to build native iOS and Android apps, respectively. Don’t feel too bad though, because according to the latest StackOverflow survey, only about 6-8% of all professional developers have a proficiency or experience with these languages. The vast majority of developers (around 70% or more) are more proficient with JavaScript, HTML, and CSS, the languages of the web.

So, if you have experience building native apps, then that might be a viable option. If not, you might find a cross-platform solution like React Native or Ionic more appealing. These solutions not only help you save time by sharing code across platforms. They also allow you to build native mobile apps using languages that you probably know already. Flutter is one exception here because it uses Dart, a relatively nascent language. But still, all of the major cross-platform solutions - React Native, Xamarin, Flutter and Ionic - are designed to appeal to web developers that are new to mobile and don’t have much experience with the native SDKs.

Only about 6-8% of all professional developers have a proficiency with the languages used to build native mobile apps (Swift, Kotlin). In contrast, the vast majority of developers - more than 70% - are familiar with the languages of the web (HTML, CSS, JavaScript).

Choosing a Cross-Platform Solution

The next decision, if you choose not to build with the native SDKs, is which cross-platform solution is right for you.

A lot of that hinges on one important question: are you building a brand new mobile app, or do you have an existing web application that you’d like to bring to mobile? 

Bringing Your Web App to Mobile

If you’re trying to bring an existing web application to mobile, there really are only two viable options: Capacitor and Cordova. 

Capacitor

Capacitor is a cross-platform native runtime that you can add to any existing web app, and then deploy that app to native iOS, native Android, on the web as a Progressive Web App (a web application that provides access to native mobile devices for certain supported features), and even on desktop using Electron. Capacitor was introduced a few years ago by the Ionic team. It powers most Ionic apps today and is 100% free and MIT open source. The Capacitor community has grown significantly over the last year or so, and was recently rated highest in developer satisfaction for mobile tools in the recent State of JS survey.

The great thing about Capacitor is that it allows you to use whatever web stack you want. If you’re building with Tailwind, Bootstrap, Svelte, Angular, React, Vue, it’s all supported on Capacitor. 

Cordova

Cordova is similar to Capacitor, in that it allows you to deploy an existing web application to mobile, or build a new mobile app using your web stack of choice. Cordova also has a large install base and a thriving plugin ecosystem. The big difference between Cordova and Capacitor is that Cordova is older. When it was created, a lot of the modern Web APIs that power Capacitor weren’t in existence. Cordova also adds a lot of abstraction when it turns your web project into a native mobile app. This is nice if you’re new to mobile, but it can be painful if you ever want to customize or troubleshoot the native packages. Also, Cordova hasn’t kept pace with Capacitor in terms of new features and the overall pace of development on the project.

So, if your goal is to bring an existing web app to mobile, or to build a pure web application using your UI library or web stack of choice, then Capacitor and Cordova are great options.

If you’re trying to bring an existing web application to mobile, there really are only two viable options: Capacitor and Cordova. 

Building a Brand New App

If, on the other hand, you are building a brand new mobile app, then you might consider React Native, Xamarin, Flutter, or Ionic. There are other options of course, but these four represent the most popular on the market today. 

The key to choosing between them is actually quite simple. The truth is, any of these solutions will give you a great app (assuming you program it well), with full access to the native device (using a library of native API “plugins”) and they all have large, vibrant communities. 

While most comparison posts you read will focus on external factors like performance and design, the real difference that you need to consider is how you build an app in each platform.

React Native

Let’s start with React Native. React Native has a few distinct characteristics. First, the UI of a React Native app is rendered using native UI components. This is why they like to say your app is “truly native”. It’s because they’re using the native iOS date picker, list view, tabs menu, etc. Although you program your React Native apps in JavaScript, using a mobile app development approach that is based on React, that JavaScript is interpreted at runtime and orchestrates, or calls up, the native UI components when the app runs.

This sounds good, and in most cases it does produce a really good user experience, but there are some downsides to it. For one thing, you will not be able to use any existing web-based UI components in your React Native application — at least not without some serious acrobatics. If you have a library of React components that you’ve customized and want to use in your mobile app, you’re out of luck. Or if you want to use Tailwind, Material, Bootstrap or some other UI library, no can do. Even if you’re comfortable with native UI components, there’s a limit to what you can customize. If Apple and Android don’t support the specific style, theme, or interaction you’re going for, then you probably won’t be able to pull it off. Contrast that with the almost unlimited permutations that are available to web developers customizing a UI using CSS.

Finally, because React Native is not really web-based, you won’t be able to use any of the popular web libraries that you might be familiar with as a web developer, such as D3, Tailwind,  or any other library that makes use of the DOM. On top of that, React Native doesn't have access to the highest performance JavaScript runtime on iOS since that is limited to apps using WKWebView (like Capacitor). Instead, React Native apps are limited to the use of JavaScriptCore, which doesn’t deliver the same performance benefits of JIT compiling.

To summarize, React Native apps are written in JavaScript and provide a developer experience that would be familiar to most React developers. It uses the native UI components to render the user interface of your application, which provides a very native-like feel to users. The downside is that you can’t easily leverage any existing web UI components, CSS customizations, or web-based libraries.

Xamarin

Xamarin is very similar to React Native, except that Xamarin apps are written in C# as opposed to JavaScript. And much like React Native, Xamarin orchestrates native UI controls on each platform. A majority of the business logic is shared across platforms, with some platform-specific code written specifically for iOS and Android. Thus, the value proposition for Xamarin is essentially the same as React Native: write native mobile apps using a familiar language (C#), with a significant amount of code shared across platforms.

Xamarin is popular among Microsoft developers. Marquee customers include UPS, Alaska Airlines, and Allscripts.

The downsides are also similar. You’re limited to the native UI libraries. You won’t have access to any web libraries or any other library that makes use of the DOM. And it’s mobile specific (although they do have a version that runs on MacOS). Also, Xamarin’s ecosystem is much smaller than that of React or any other web framework community. There are far fewer C# developers, and the number of Xamarin libraries is a fraction of what you would find in many other cross-platform communities, including Ionic and Capacitor.

Flutter

And then there’s Flutter. Flutter is a relatively new cross-platform solution from Google. Flutter’s main value proposition is that you can deploy your apps across mobile, desktop, and web, all from the same codebase. They also tout the impressive visuals stylings of their UI toolkit, including fancy gestures and animations.

What’s the catch? The catch is that - to pull all that off - Flutter had to lean on some serious customizations that are not at all portable outside of the Flutter ecosystem. Meaning, when you build a Flutter app, you’re all in on Flutter. Heaven help you if Google drops the project (they would never do that, right?), because everything about Flutter is custom. 

To start off, Flutter uses a little known language called Dart. According to the same StackOverflow survey cited above, less than 4% of professional developers reported some familiarity with Dart. So, not only will you have to learn a new language, the value of that knowledge is almost exclusively tied to Flutter’s success in the market. 

Secondly, Flutter uses a custom rendering engine to generate all those fancy UI components, gestures, and animations. That means you’re not using any web standards or web libraries; hence why your code will not port well if Google ever abandons the project. In fact, their web support doesn’t even support basic web features like CSS. It’s like Flash all over again.

For web developers, this poses many of the same problems as React Native. All of the CSS customizations, custom UI components, and familiar web libraries that you might be used to building with will not be available on Flutter. It’s effectively a closed ecosystem, albeit open source. And don't be fooled. When Flutter brags about how many packages it has, keep in mind that it has to have every library created completely from scratch to work with it. Capacitor has access to orders of magnitude more packages because it works with all web and JavaScript libraries.

If you’re considering Flutter, especially for any sort of mission-critical project, it really comes down to how comfortable you are with putting all your chips down on Google’s ongoing support for the project, and the prospect of broader adoption of Dart. If you’re kicking around on a side project, that’s not too risky. But if you’re building an app for a customer or for an important project at work, consider yourself warned.

When you build a Flutter app, you’re all in on Flutter. Heaven help you if Google drops the project, because everything about Flutter is custom. 

Ionic

That brings us to the last option: Ionic. Of course, as an Ionic team member I’m biased here. I’ll try to give you a fair analysis of when and why to choose Ionic, and what the tradeoffs might be compared to the other solutions we’ve outlined.

Similar to Flutter, Ionic is truly cross-platform, meaning with one codebase you can deploy your Ionic app virtually anywhere the web runs: mobile, tablets, web, desktop. That said, today Ionic is primarily focused on mobile experiences. 

Unlike React Native, Xamarin, and Flutter, Ionic is the only option that takes a web-first app development approach. 

For example, the UI of an Ionic app runs in a browser - called a WebView - that is invisible to the user. By default, Ionic apps run on Capacitor, the cross-platform native runtime that we mentioned above. But unlike using Capacitor out-of-the-box, Ionic provides a highly opinionated way to build mobile apps with the web. Our open source UI library features over 100 pre-built UI components, animations, and gestures that are optimized for mobile and look and feel just like the native UI components. This effectively allows you to build native-like mobile experiences with the web. Check out the live demos of some of our popular components to get a feel for what we mean.

These UI components are all built with the web, but they look just like the native UI components for iOS and Android. In fact, with a feature called Adaptive Styling, they automatically conform to whatever platform they’re running on, such that they use the Cupertino design system when running on iOS, and Material Design when running on Android, without you having to do anything.

What’s the advantage of building with web components? Why not use the native components like React Native? It comes back to developer experience and the power of the web when it comes to customizing your mobile experience. Recall that, with the native UI components, you can’t use CSS theming or add your own custom web components to your UI. With an Ionic app, you can do anything that you would be able to in any other web application. 

Also, because Ionic is web-based, you can import any of your favorite web libraries, debug using Chrome Dev Tools, and basically do anything that you would do when building a traditional web app.

On top of that, Ionic provides tremendous flexibility when it comes to which JavaScript framework you use. Ionic offers three flavors of its open source UI toolkit that cover each of the main JavaScript frameworks: Angular, React, and Vue. Alternatively, you can use vanilla JS if that’s your jam. And remember, if you really want to go all out and use your own custom web stack, Capacitor is always a good option. The benefit of using Ionic Framework - our mobile UI library - over pure Capacitor, is that you’ll get all the UI components out-of-the-box, plus powerful tooling to help you as you develop your app.

Summary

To summarize, the key distinction between Ionic and React Native and Flutter is that Ionic is purely web-based. Or as we like to say: Truly Native. Truly Web. Truly Native because you have full access to the native SDKs just like any other native mobile app (thanks to Capacitor), and Truly Web because you’re using pure web standards just like any other web app. As a web developer, you’ll be right at home building a mobile app with Ionic, using all the familiar tools, languages, libraries, and frameworks you’re accustomed to. And because it’s all based on open web standards, you don’t have any of the lock-in concerns that you will with Flutter.

There’s one more thing. React Native, Xamarin, and Flutter are open source projects backed by giant tech companies. Facebook, Microsoft, and Google are in it mostly to advance their agenda and increase their influence over the broader developer community. They’re not sponsoring these projects out of the kindness of their hearts. 

Ionic is a commercial business that is dedicated to helping our community and our customers be successful. This is especially valuable for professional developers and teams building in the enterprise. While our core technology is 100% free and MIT open source, we offer a full suite of premium solutions and expert services to help our customers reach their goals. You can learn more about our enterprise offerings here. And if you’re an indie dev, be sure to check out Appflow, a suite of cloud-based mobile CI/CD services to help you build, publish, and update your Ionic and Capacitor apps over time.

Ionic is solely dedicated to helping our community and our customers be successful with app development. This is especially valuable for professional developers and teams building in the enterprise.

Key Questions

Well, there you have it. If you’re embarking on a new mobile project, you can use this helpful rubric to decide which mobile app development approach is right for you. To summarize, here are the key questions you should consider:

• Are you comfortable with the languages used to build native mobile apps (Swift and Kotlin), or would you prefer to use JavaScript or a similar language that might be more familiar to web developers?
• Do you want to build a brand new mobile app from scratch, or are you looking to convert an existing web app to mobile (or repurpose a good deal of your existing code)?
• Do you have a preference for any particular JavaScript framework? 
• Are there any web libraries, CSS stylings, or custom UI components that you want to add to your app?
• Will the stock iOS and Android UI components be good enough, or do you have certain customizations you’d like to apply?
• How important is it to be able to port your mobile project to another platform or reuse part of your project in a web application?
• Are you building a mission-critical application for a client or for your business, where ongoing support and access to add-on software and services would be valuable?

Of course, perhaps the best way to find out is to build a quick sample app and see for yourself. If you want to get started building with Ionic, check out our Getting Started guide. Or visit Capacitor if that seems like a better fit. Enjoy!

Comparison Chart

P.S. Here’s a comparison chart to help you decide: