Based on development hours, the Ionic framework (developed and supported by Drifty) was the fourth most used cross-platform, or hybrid, mobile app development framework in the world in 2021. While Flutter and React Native are by some distance currently the most popular frameworks used in hybrid app development, Ionic’s 16% market share places it on a similar level of popularity to Cordova and slightly ahead of Xamarin and Unity.
Ionic claims that 15% of the apps in Apple’s App Store are built using the framework as well as tens of thousands of apps developed by businesses and organisations for internal use.
Can We Help You With Your Next App Development Project?
Flexible models to fit your needs! Get a quote in 24 hours
In this blog, we’ll introduce you to the Ionic framework’s use cases, strengths and weaknesses. And when and why it might be preferred to cross-platform alternatives like Flutter and React Native or a fully native approach.
If you still haven’t reached a strategic conclusion on if your next app should be cross-platform or native, we go into far more detail on the pros and cons of the two approaches here – Web apps vs native apps: a comparison.
But very briefly, native apps built specifically to run on either the Android or iOS mobile operating systems offer more flawless integration with device hardware such as cameras, microphones and GPS. Native is usually the choice for apps whose functionalities are tied closely to leveraging device hardware and which prioritise glitchless reaction time.
WebView apps are relatively cheap and easy to build but limited in their access to device hardware, which is possible only via plugins. However, they can still be a good choice to offer a custom mobile version of simple, content-serving web apps.
Progressive web apps (PWAs) occupy the middle ground between WebView and native apps. They are essentially small websites running in a browser shell within an app that provides access to the native platform layer. The evolution of cross-platform frameworks such as Ionic, Flutter, React Native, Cordova and Xamarin mean that PWAs can now get pretty close to the feel and performance of native equivalents.
Only one core codebase is developed for both Android and iOS, making cross-platform apps more cost and time-efficient than native. The frameworks are generally considered easier to learn and faster to create applications with than those used for native apps. And for many cross-platform apps, when done well, there can be almost no noticeable performance and reliability trade-off.
While still (to varying degrees depending on app functionalities) a compromise on native app performance, modern PWAs can be close enough to represent a genuine strategic choice. And for some kinds of app, the better choice.
Just a few examples of high profile cross-platform PWAs that show just how effective the technology can be:
A few examples of significant apps built with the Ionic framework include:
Ionic now describes itself as no longer a framework for Cordova and Angular but a framework for Capacitor, “with official support for Angular, React and Vue, and unofficial support to be used in pretty much any JS stack out there.”
Dedicated teams and team augmentation with Ionic, Flutter, React Native and other major cross-platform and Native technologies
Not sure which tech stack is the best choice for your next app project? Get in touch, we'd love to offer our experience!
Ionic’s claim for Capacitor is that its interface for accessing native SDKs, native UI controls and native APIs on each platform means that apps built on the runtime can be described as genuinely native as well as cross-platform.
Ionic.io offers the following explanation of what Capacitor brings to the table:
“It might be helpful to think of Capacitor as a powerful new browser for modern Web Apps that unlocks the full native functionality of each platform through consistent cross-platform APIs. Using Capacitor, developers can build one app and target one set of APIs regardless of the platform the app is running on, as opposed to managing multiple APIs for each target platform.”
“This means that, for example, accessing the Camera uses the same code on iOS/Android as it does on Electron and on the web. This makes it easy to build one web app that runs natively on mobile, desktop, and the web as a Progressive Web App!”
The advantage of Capacitor with Ionic, compared to Cordova, is that the latter works through an abstraction layer rather than plugging directly into native SDKs, APIs and UI controls.
Capacitor (Capacitor 3 was released in early 2021) was installed around 1.5 million times last year and, in combination with the Ionic framework, has been used by enterprises including Burger King and the airline Southwest to build internal and consumer-facing apps.
Anyone interested in a deeper dive into exactly how Capacitor works should read this blog by Ionic’s Max Lynch. It outlines how the runtime works at a low level and explains its Native API and stripped back WebView layer.
Ionic’s historic weaknesses were that its use of WebView meant that it was often considered less than optimal for large apps, especially those with heavy reliance on device hardware. Pre-Capacitor, Ionic also lacked native plugins support resulting in a lack of stability and potential conflicts between plugins. There was also sometimes no native plugin access, forcing developers to build solutions from scratch.
Using the latest version of Ionic (6 at the time of writing) with Capacitor goes some way to minimising the framework’s traditional weaknesses in accessing device hardware efficiently, as well as the previously sub-optimal speed and size of apps.
All of these downsides stemmed from the fact apps built with Ionic are WebView-based. Capacitor is still a WebView but a stripped down version with unnecessary iOS and Android WebView features removed.
Capacitor also lets an app work with the native functionality of Android Manifest/Info.plist/etc., while Cordova tried to do everything itself; an approach that wasn’t always successful. Capacitor also gives the development team full control of the development environment.
While Ionic is betting on Capacitor as the foundation the framework’s future will be built on, it will continue to support Cordova for at least another few years. And the Cordova Ionic plugin ecosystem is rich and mature. Updating pre-Capacitor Ionic apps built with Cordova to its latest versions will continue to be a viable option for the foreseeable future.
But for organisations who do want to future-proof Ionic apps by migrating them to Capacitor, doing so is a relatively painless process. Capacitor was specifically designed for backwards compatibility with Cordova in mind, precisely so legacy apps could be easily migrated.
A small app could potentially be migrated from Cordova to Capacitor in just hours. There’s a migration guide inside the Capacitor documentation and it’s relatively lean and straightforward.
There have been inaccurate reports that Apple has recently been rejecting or ejecting cross-platform apps, including those built with the Ionic framework, from the App Store. This is not strictly true. Apple has stopped accepting submissions of apps that use the deprecated UIWebView APIs in favour of the new platform-native WKWebView.
Both the latest versions of Capacitor and Cordova can meet that requirement for apps developed with Ionic.
Some of Ionic’s most notable pluses from a tech perspective are:
Ionic’s Adaptive Styling that adapts components to the style of the platform the app is running on may not always be an exact match, which is a sometimes criticism. But if it is more important to an app project that design must stick to a particular system or look consistent, Ionic can take a lot less time to standardise across platforms.
While the freedom React Native and Flutter give to customising component styling means they can be matched exactly to native styling, doing so for multiple platforms can be an unexpectedly time-consuming and resource-hungry process.
It is often claimed that the process of bridging native code into React Native is smoother than doing the same into Ionic. However, the introduction of Capacitor, which adds native projects as source artifacts, means it is now essentially done in the same way.
Pre-Capacitor, Ionic apps built with Cordova could only install native code via plugins. Development teams would often have to build new Cordova plugins alongside the app being developed when something suitable didn’t already exist. This could mean long stretches passing before plugins were developed and custom native code tested for interaction with the actual app.
The introduction of Capacitor now means, as is the case with React Native, platform projects can be utilised as source artifects. This simplifies the process of bridging native code into an app and means custom native code can be tested in the same project as the app.
Some of Ionic’s weaknesses are:
As a web-based framework, Ionic apps do have to rely on plugins to access Native APIs. The more complex an app, the more plugins are required. And plugins that did work can have reliability issues and suddenly return errors if packages aren’t well managed.
For example, libraries used for navigation with React Native can be slower than Angular’s router, used with Ionic. However, React Native and Flutter do have some advantages when it comes to accessing device hardware.
The Ionic framework comes with Adaptive Styling, which is supposed to adjust the look of components to the style of the platform the app is running on. Not every element, however, exactly matches the native counterparts of all platforms, which can give a slightly less than native feel to the design of Ionic apps.
It would be disingenuous to take the approach of trying to qualify one of the popular cross-platform mobile frameworks as ‘the best’. The reality is they all have different technological qualities and characteristics that mean the question would be better framed differently.
All the major contemporary cross-platform app development frameworks are “good”. If they weren’t, they wouldn’t exist in a hugely competitive market software development market. Which is “the best” for your needs at a particular time will depend on a number of factors.
Rather than asking which of the frameworks is “better”, the question should instead be “which is right for this particular project?” That is a much more nuanced, and valid, question.
The answer will depend on a combination of the app’s requirements, resources and strategy at an organisational level (ie., if the organisation has existing in-house software development resources and/or policies around preferred tech stack), and the preferences and experience of those tasked to build it.
If you are interested in exploring React Native and Flutter as technology choices for hybrid apps, you can refer to our comparative analysis Flutter vs React Native – Which to Choose, When?
The Ionic framework is one to consider for your app if:
Ionic can be used to build apps that mostly use the same codebase across these different platforms. For example, it would be a budget efficient choice for a start-up that needs to create an application for the web as well as available as Android and iOS apps. Everything can be inside one repository, one framework, one language and can be deployed everywhere.
Or if you want to build an MVP to test the waters of a particular market or business capability to see if users will see the app’s value, Ionic’s prefabricated design lends itself to a fast time-to-market.
If you only need to develop native applications and you don’t need or want a website then another choice like Flutter (although web and desktop support has now been introduced for Flutter, contributing to its increasing popularity) or React Native might make more sense for you. Or a completely native approach like Kotlin or Java for Android or Swift or Objective-C for iOS.
If you are building a large, complex app that will place heavy demands on device hardware and memory usage, Ionic may well not be the optimal choice for technical performance across platforms.
If your app experience will rely on augmenting the design of native features, for example how an app like Snapchat is overlaid on a device’s camera, Ionic probably isn’t your best option.
And if you have the budget to develop and maintain the individual codebases of fully native applications across multiple platforms, as well as strategic reasons why doing so will be advantageous or crucial to your app’s success, Ionic also probably won’t be your framework of choice.
Ultimately the choice of framework for an app project should come down to client requirements, project complexity, and organisational needs balanced with tech requirements and preferences. It’s not always strategically crucial to hit the optimum speed for frames-per-second. But optimal time-to-market and a unified codebase that can be built and maintained by a software development team featuring mainly web technology stacks might be.