Opinion
Is Drifty's Ionic Dead?
Dave Francis
December 18, 2020
Where, indeed, has Ionic gone ? Once popular as an app development framework, it seems to have disappeared. Pop over onto Drifty’s website and you’ll find the quote below….
“....the world’s most popular cross-platform mobile development technology stack, powering fast growing startups to some of the biggest companies in the world.
A look on Google Trends seems to suggest that Drifty wrote their copy some considerable time ago, though. Let’s compare Ionic, in blue, to Xamarin, in yellow, and finally, Google Flutter, in red, from December 2017 to the present day.
Whoops.
Drifty go on to say that Ionic is used in “five million apps” - which is probably true, over the product’s lifetime (and Ionic has been around since 2013) - whilst all of the above is, or rather, was, true, we think you’ll be hard pushed to find an Ionic developer today.
Here comes the science bit. (If you’re not interested in the science bit, scroll down to “Conclusions”.)
One thing we advise clients - and it’s probably the most important decision they get to make - is choose the development framework for their app wisely. Choosing the wrong development framework - for example, Xamarin or Ionic - will lead to serious problems later. You don’t want to choose a dead or moribund development framework.
According to AppBrain, Ionic held 3.2% of the app development market in July 2019. That number isn’t going up, according to the chart above. Quite the opposite, in fact.
So what went wrong?
As with Xamarin, Ionic has become the development framework of yesteryear. Let’s have a look why.
Released in 2013, Ionic is a complete SDK for hybrid mobile app development. The original release was built on AngularJS and Cordova: the latest versions were rebuilt as a set of Web Components, allowing the user to choose their framework: Angular, React or Vue.js. (That’s from Ionic 4 onwards, by the way.)
Ionic also allows the use of Ionic Components, which have no user interface framework. Ionic comes with tools and services to develop hybrid mobile, desktop and progressive web apps, using technologies such as CSS, HTML5 and Sass. All good so far.
Mobile apps built with these web technologies can be distributed via App stores by utilising Apache Cordova or (in later builds) Capacitor.
One point to note is the number of releases of Ionic.
As mentioned, Ionic changed direction with Ionic 4 to allow the user to choose their framework - in January 2019. Since then, there have been other releases and Ionic is now at Release 5.3.4 as of the end of September 2020.
These releases are - and this is one of the irritations of using Ionic - generally poorly documented. Looking on the developer forums, one of the major criticisms of Ionic is the vagueness of existing documentation, or the prevalence of outdated documentation, which give new learners a vague idea of what to do but then force them to trawl for answers on sites like Stackoverflow.
Essentially, learning Ionic entails leaning heavily on more experienced Ionic developers for answers - the more experienced Ionic developers seem to have concluded that a good solution is to use another framework. as you can see from the graph above.
A similar problem with documentation-bedevilled Xamarin. Documentation and support were basically either non existent or contradictory. Xamarin had all sorts of workarounds, bugs and glitches which made development a tedious and frustrating process as well.
With Ionic, the problem of lack of understandable documentation, or the prevalence of outdated documentation is compounded by the number of releases that Drifty release.
The development community seem a little tired of the number of Ionic builds being released, as Drifty seem to be attempting to reinvent what Ionic is and does. “What’s the point in developing in Ionic 3 when you know Ionic 4 is coming out soon?“ is one typical comment.
More modern frameworks (such as Google’s Flutter) have realised that the key to framework adoption is provide good documentation and examples, and this leads us into another problem with Ionic - its age.
Ionic - like the equally moribund Xamarin - date back from the early days of cross platform technology, which we have an article about here.
To reduce a complicated subject to a few simple lines: it used to be the case that mobile apps were developed in either Android or IoS - this required two codebases.
Two codebases means twice the expense in terms of development and maintenance, and also twice the amount of support and maintenance - with additional problems such as look and feel and ongoing support for third party plugins.
Natively developed apps were fast, but expensive. Essentially, you were faced with the choice of developing an app either for Android or IoS, but with Android and Apple phones cornering 50% of the market each, now, it’s become a business essential to develop apps which are “cross platform” in nature - one codebase producing both an Android and iOS app.
Back in the early days of cross platform development, solutions such as Silverlight, Xamarin and Ionic provided a solution for web and mobile development - this was all a long time ago, however, at least in software development terms. Silverlight was released in 2007, mainly as a web development system: Xamarin and Ionic followed five years later.
Whilst Silverlight was effectively killed off by the failure of the Windows Phone, Xamarin and Ionic have chugged on, but, ten years later, the cracks are beginning to show. There are still a lot of Xamarin / Ionic based apps out there, which are still keeping programmers in business, supporting legacy software, but effectively, both Ionic and Xamarin are facing massive issues in keeping development frameworks alive which rely on legacy ideas (and code, in the case of Xamarin.)
Simply put, much better frameworks have come along in a process of inevitable evolution, and older development frameworks are dying off. (It’s fairly safe to say that cross platform development is now a two-horse race between React Native and Google Flutter .)
Part of the problems that Ionic apps face is down to the internal architecture of the Ionic framework - basically, the way that Ionic code interacts with the phone’s native hardware.
Ionic apps are written in a mix of web and native code - they produce one codebase, so that’s simpler for maintenance. Theoretically, this is great - just use what ever native code your Android or IoS phone requires to access the camera, gyroscope or accelerometer. It should run at native speed, yes?
In fact, it doesn’t. The architecture of Ionic means that there has to be a Cordova / Capacitor - software - bridge between Ionic’s web functions and native applications. For example, in the case of a graphics heavy app, Ionic, which is controlling the web elements of the app, renders the graphic elements using a browser. Any native elements are called for via the Cordova bridge, which takes time. The more you attempt to do, the more Cordova calls are made, the slower the app becomes.
With other frameworks, such as Xamarin, and Flutter, a compiler is used to lump all these calls and code into a fast, low level language, which means much higher app performance. (Whether it’s all compiled or JIT - “Just In Time” compiled) is a different matter, but the end result is pretty much the same. )
One large bugbear with Ionic is the way it uses plugins. You’ll be hard pressed to find a modern app nowadays which doesn’t use plugins, and there are certainly lots out there. Ionic also has some of its own plugins, incidentally.
However. If you’re missing a plugin for some native functionality, you’ll simply have to write it yourself. Ionic is not capable of using Native plugins without transforming it in JavaScript. (With some newer cross platform tools, yes, again, you’ll have to write your own plugins, but in a seven year old environment, this is fairly inexcusable and hints at a lack of support from Drifty or a worrying lack of interest in Ionic in the development community.)
You can go fully web using Ionic, but if you have to rely on even a small amount of Native code, it’s not possible to implement it.
And this brings us back to the problem that using Ionic means that you may well have to have some recourse to Native code. Yes, you’re developing cross platform, from a single code base, but some elements of code have to be Native. What happens if the IoS code and Android code produce different results? Of course, Android is written in Kotlin / Java and IoS in Swift / Objective C - if one of the purposes of cross platform development is to remove the number of languages and specific expertise a developer has, any pitfalls which is caused by Ionic’s use of potentially different Native code elements removes that theoretical advantage.
In short, Ionic backs itself into a corner where “if it works, it works. If it doesn’t, potentially large headache to sort out.”
Whilst not exactly a show stopper, Ionic lacks a development feature which Flutter and React Native have - hot reload.
With hot reload, you can pause the execution of a test app, apply fixes and then run the app again. This means you can do “on the fly” debugging - so that means faster development. With Ionic, you’re back to the bad old days of reading error logs, debugging, recompiling and trying again.
It’s not exactly a show stopper, but it can lead to lengthy delays in development and a lot of frustration.
Again, not a show stopper, but apps tend to be quite large when written in Ionic. This is because they have to contain your plugins - Cordova, Capacitor and Native Ionic plugins, that is, your default libraries, your framework moderated dependencies (Angular, React or Vue) and CSS variables.
It’s not all bad news.
Carefully thought out, there’s a case for using Ionic over other cross platform frameworks. The operating phrase there is “carefully thought out”, however.
If your developers have strong experience in web apps and Angular, and are experienced with Angular and JavaScript libraries, Ionic can be a good choice for fast app production, if you’re planning to do a simple app or MVP. However, bear in mind the lack of hot reload which will impinge on development time.
Since you’re used to using web development tools, it can be pretty fast to develop an app using Ionic. However, as mentioned above, due to the Cordova / Capacitor bridge, developing anything which requires extensive use of phone hardware isn’t a good idea with Ionic. Mobile games are a definite no-no, or, indeed, anything which really hits the hardware.
The conclusion you may be coming to is that “Ionic is good for reactive web apps”. App and web developers are somewhat different in nature, and, of course, Ionic falls between these two stools.
Technology stack goes a long way in determining what framework to adopt. If a company has, as mentioned above, HTML / CSS experience, it makes some degree of sense to use Ionic. If you can find the developers, that is. If your devs have experience in .NET and C#, then you might think of developing an app in Xamarin - if, again, you can find the developers, as Xamarin has problems of it’s own (detailed here) - internal knowledge of React components? - that puts you on a React Native development route, and knowledge of Dart pushes you towards Google Flutter.
However, market dynamics mean you’re much more likely to find Flutter or React Native developers, they’re more modern frameworks…. you may want to go that way in the first place.
What really kills Ionic is that, without Native components, you’re very much constrained with what you do. If you do bring in Native development, you run the risk of eventually ending up with two codebases, which obviates the point of cross platform development in the first place and may have you scrabbling around for Java /Kotlin / Swift / Objective-C expertise at some stage.
Think long and hard before commissioning an Ionic based app.
Despite what Drifty claim on their webpage, Ionic has been on an increasing downward spiral for years, and now, with a tiny percent of the market, has reached a point where a major consideration is “will anyone support it?”
Developers aren’t looking for a job in Ionic, will third parties won’t develop plugins for it? Is this pretty much a death knell?
Designed in the early days of cross platform development, the whole developer landscape has changed faster than Ionic could adapt to it. Designed originally to produce one codebase and to obviate the need for external programming expertise in other languages, Ionic does neither.
Yes, there are use cases for Ionic, if what you’re looking for is a reactive web app - where your web code can be used to quickly produce a mobile version - but - going down that route, using a framework which has performance and availability issues hitting phone hardware means that you’re effectively ignoring a lot of features of mobile phone apps which the public now expect to find in a modern app.
By the same token, Ionic requires a developer who’s a cross between web app and mobile app - it’s somewhat of a conceptual leap to assume that developers will want to cross - skill like this when there are other, simpler and better documented toolsets out there on the market, all of which have a larger commercial market than Ionic.
Ionic has tried to reinvent itself a number of times to follow market trends and developments, but the cases where it’s wise to use Ionic are very limited, and, frankly, other more popular and better solutions out there do the same job better, with less potential headaches in terms of ongoing support, plugin availability and maintenance.
Looking for an app development agency? Check out our Manchester based Flutter app development services here.
