I decided to write this article in response to some common questions/statements/responses I’ve been seeing for quite a while. In discussions where the cross-platform capabilities of Ionic are being explained, it would be common for the Ionic team, or bloggers/educators like myself, to say that Ionic allows you to build the following applications from a single codebase:
- Web/PWA
- Native iOS
- Native Android
- etc.
It seems to be a point of contention to refer to an Ionic application as native even when the end result is a standard native .apk or .ipa file and it has the ability to use Native APIs, on the grounds that the user interface is displayed using an embedded web view and not Native UI controls.
Although I am of the opinion that it makes sense and avoids confusion among newer mobile developers to refer to Ionic applications as native when they are deployed to iOS/Android using an .ipa or .apk package (except in circumstances where the discussion is specifically about Web Views vs Native UI) - I am not here to convince you of that in this article, and I don’t think people who don’t share my view on this are wrong.
The point I do want to address is that inevitably when Ionic applications are referred to as native in any way, people will often make statements like (either out of genuine curiosity or feigned confusion for the point of snark):
“Oh, did Ionic finally get rid of web views?”
Whether the commenters are well-intentioned or not, there does seem to be a perception that web views are inherently a bad thing. The reliance on web views - an embedded browser to run/display web code - to display the user interface of an Ionic application in an iOS/Android environment is a limiting factor when compared to using Native UI. However, whilst there are disadvantages to using a web view, the usage of web views is fundamental to the underlying ideology of the Ionic framework and it provides some of Ionic’s biggest advantages.
If the Ionic framework were ever to “get rid of web views” then it would cease to be the framework we know and love that utilises the power of the web. In this article, I want to discuss some of the advantages that using web views provides.
A Disclaimer
I’m always cautious about writing these kinds of articles because I don’t want to contribute to the overall noise and unproductive arguments of framework wars.
It is my opinion that different tools are suited to different tasks, teams, and developers. I think people should use the tool or tools that work for them and try not to mix their identity and self-worth into the tools they are using. In most cases, I think there are far bigger concerns that determine the success of an application than whether you use Ionic, React Native, Flutter, Objective-C/Swift, Java/Kotlin, or something else to build the application.
I want to make it clear that the point of this article is not to make the point that:
“Web views are the best, and Native UI can go suck a lemon”
I am not making the point that the web view approach Ionic uses is better, just that it has worthwhile advantages and “uses web views” is not something you can just lump entirely in the “cons” column when weighing the pros/cons of what approach to use.
What is a web view?
Before discussing some of the advantages of web views, let’s quickly recap what exactly they are and what role it plays in an Ionic application. We will specifically consider the case of an iOS application, but the same concept applies to Android (and other platforms) as well.
If you were building a native iOS application in the “standard” way, you would be writing your application entirely in the code that is native to that specific platform. In the case of iOS, that means Objective-C or Swift. To build out the user interface for the application, you would be using the various native views and controls that are provided by iOS.
When an Ionic application is deployed to iOS natively, the underlying package does still use this same native code, but the bulk of the application itself is built with web code. In order to display a web-based user interface inside of a native iOS application, we make use of WKWebView. This is basically like launching a browser inside of the native application, and displaying our application inside of that. There is no browser interface visible, so there is no obvious difference between an application that is using Native UI controls for the user interface or a web view. The files displayed in the web view are accessed locally, so there is no need to have an Internet connection or to connect to a specific website/URL in order to display the content in the web view.
The biggest downside to using a web view to display the application is that the web view essentially becomes its own little world sandboxed away from the rest of the native application. Native APIs outside of the web view can still be accessed by the application inside of the web view, so this “sandboxing” isn’t much of an issue in that regard. The biggest point of difference is that unlike a “standard” native application, an application that uses a web view is primarily using this web view for computation and rendering the interface - the web view essentially becomes the “engine” for the application.
Fortunately, web browsers are quite powerful today, so as long as the application is designed well this limitation will often not matter. In some types of applications, this limitation can be a determining factor on whether or not a web-based approach is viable, but it isn’t for most. It does mean you have less leeway for mistakes though, so you do need to be careful you aren’t making costly performance mistakes. In the end, even with the full power of native code available a poorly designed application will still be slow.
With an understanding of what a web view is, and why that might be a limitation, let’s consider some of the positive aspects of using a web view.
Your applications will work wherever the web does
This is ultimately the primary benefit of using a web view to run an application, and most of the rest of the points I will be making are derived from this in some way.
By creating a web-based application, it’s just a standard web application that you can run wherever the web works. This gives you the ability to create cross-platform applications from a single codebase by default. There are no special compilers required to transform the code you wrote into code that works on a specific platform or special renderers that can display your application on each platform. It’s just standard web code that works on the web.
Using a web view allows you to ignore the specifics of the platform you want to run your application on. If the platform allows you to use a browser/web view then it can run your application. It doesn’t matter whether that is on a desktop browser, a mobile browser, a browser embedded in an iOS/Android application, a browser embedded in a native desktop application, a browser on a fridge or even on a Tesla.
A familiar development and debugging environment
A lot of the time, people who start developing mobile applications with Ionic (or any other web-based approach) are going to be those who have some experience with web development and want to utilise those skills for developing mobile applications.
Since we are able to use web views, which is essentially just a browser, the development experience is not really much different to just developing any kind of web-based application. Most of the development will be done directly through a desktop browser. Even when your application is deployed natively to iOS or Android or somewhere else, you can still test and debug using browser-based debugging tools that are exactly the same as those that you would use on a desktop browser.
Although some circumstances may require you to poke around the native codebase or logs using XCode or Android Studio (typically only in cases where you are integrating Native APIs), the vast majority of your development and debugging will happen in the browser.
Avoiding gatekeepers
I’ve had to edit this section down a few times and remove personal anecdotes since it was getting a bit too ranty and rambly. The short of it is that, personally, I despise that in the case of native iOS and Android applications a single external company (mostly Apple, the Google Play store seems to have fewer issues in this regard) essentially has full control over the distribution of your application and it can apply whatever arbitrary rules it likes. For example, you could spend months developing an application for iOS and ultimately Apple can just say “no” and refuse to put it on the store. There have even been many cases where applications that have previously been allowed on the app store have been disallowed by Apple and removed.
There have been many high profile cases of rejections and removals, but the more common case for smaller developers is running foul of the grey areas in Apple’s App Store Review Guidelines. Many of the guidelines are vague and open to interpretation, and ultimately it may depend on the particular reviewer you get for your application.
Many developers will find themselves falling victim to this particular requirement:
4.2 Minimum Functionality - Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value, or is just plain creepy, it may not be accepted.
Which basically means that if your app doesn’t seem “appy” or useful enough to the reviewer, they might just reject the application on the grounds that it would be better suited as a website. This may be true in many circumstances, a lot of apps would provide a better experience as a website/PWA, but if you’ve invested a lot of time into developing an iOS application specifically then this could sting. This particular requirement often leads to circumstances where a developer will submit an application and get rejected on this basis, and then sometimes even submit the exact same application later and have it accepted.
Of course, companies may operate their businesses as they please and if we want to get our applications into their platform we need to play by their rules and conform to their standards. I think that it is too risky to have your business model rely entirely upon remaining in the good graces of a company that can arbitrarily apply whatever rules they like.
Using a web-based solution like Ionic does not avoid this situation entirely. If you want to deploy an Ionic application natively to iOS then you face all the same rules everybody else does. What a web-based solution does give you is more options. Since your application is made from web code that runs in a browser, if you have developed it for one platform then you have (mostly) already developed it for other platforms too. If your application is rejected by Apple you can still deploy that same application to the Google Play store. Or, you could publish independently on the web (although you may need to make some concessions if your application relied on interacting with Native APIs) and your iOS users could still access your application this way.
Personally, I’m hoping for a future where the vast majority of applications are Progressive Web Applications distributed through the open web, and mostly only specialty apps are actually installed onto the device and distributed through other means - just like what has happened with Desktop applications. Many of the day-to-day applications that we use which once existed as native desktop applications we now use web apps for instead.
Independence
As well as being free from the whims of an external company that controls the distribution of your application, we should also consider our reliance upon the company that has created the tool that we are using to build the application. What if the tool or framework you are using to build your applications suddenly decides to go in a different direction, perhaps changing their licensing model or drastically increasing prices? What if the company goes completely bankrupt, will the tool/framework continue to be maintained? Will you still be able to use it? Are the skills you have developed specific to just that one tool, or could you use what you have learned from using that tool and more easily use a new tool or approach?
This probably isn’t too much of a concern if you are using the native language of the device to develop applications (i.e. Objective-C/Swift for iOS or Java/Kotlin for Android). It is something you should consider if you are relying on an external tool/framework to build your application like Ionic, React Native, Xamarin, Flutter, or anything else.
Frankly, I don’t know enough about all of these tools (nor do I have enough time) to cover the “disaster scenarios” for each one, but let’s consider a “disaster” case for Ionic.
The Ionic team today are certainly leading the charge for using the web platform to build mobile applications. I think that the efforts of the Ionic team have shown just how viable the web is for building modern mobile applications. As it stands today, the people developing and maintaining Ionic belong to a strong and well-funded company.
But, nothing is impervious to the various factors that influence life and business. Even the popular Parse platform which had the backing of Facebookshut down unexpectedly leaving thousands of developers in the lurch. I think this is much less likely to ever be the case for Ionic since Ionic is the company’s business, whereas Parse to Facebook is not its primary business interest. But it needs to be considered.
What if next week the Ionic team in its entirety were to be suddenly abducted by aliens or some kind of malevolent cosmic artificial intelligence. What would happen to those of us who rely upon Ionic to build our applications?
This is, again, a case where I think the web-based approach provides a strong benefit. If the entire Ionic team were to disappear, in the short term, it would have almost no impact (except for people who are relying on the Appflow services). All of Ionic’s components are MIT licensed, open source, web components. There is no services, or renderers, or compilers, or any other dependencies required to run Ionic applications that would disappear along with the Ionic team. We can just use these components in a web-based application in any way we like.
Having little to no short term impact is a huge benefit which means there isn’t going to be an “Oh frick, what do we do now?” moment. In the medium term, there is more to consider. Now that Ionic’s components are just generic web components, these should remain useable for quite a long time before requiring any maintenance. But there is also other parts of Ionic to consider like the Angular, React, and Vue specific packages. Or perhaps iOS releases a new version of their operating system with an additional “side notch”. Eventually, some maintenance will be required. Everything is entirely open source, though, so as long people are willing to organise and make contributions then these packages should remain in good standing for a long time (or you could also perform the maintenance yourself if you or your team had the capability to do so).
In the long term, there would need to be some driving force pushing the web forward for mobile applications. The Ionic team have done an incredible job in developing Ionic into what it is today, but without them, there would need to be some kind of driving force for vision and innovation pushing the web forward as the years go by. Personally, I think we are now well past the point where the viability of the web for mobile apps has been proven, and this would happen naturally due to market forces.
We’ve mostly just touched on the idea of Ionic as a company disappearing or failing here, but I think this open source web-based approach also succeeds in the other factors I mentioned at the beginning of this section. Since Ionic is free and open source I think it’s unlikely we need to worry about sudden pricing or license changes. If Ionic did decide to “go in a different direction” we would still be able to use the open source code that Ionic is comprised of. Finally, the skills you develop in learning to build Ionic applications are highly transferable as in the end, we are just learning to build for the web, not the language of a specific “tool”.
Always bet on the web
If there is one technology that has stood the test of time it is the web. Technologies come and go, but HTML/CSS/JavaScript and the World Wide Web are likely going to be around for a long time to come.
The portability and longevity of the web is the key advantage of using web views to build mobile applications.