Max LynchWeb Views are among the most widely used components in mobile apps for good reason: most apps need to incorporate some internal or external web experience at some point.
Because of this, Apple and Google provide basic Web View controls out of the box: iOS with WKWebView, and Android with WebView (there are other options on Android but this is the primary one most apps use).
Unfortunately, using these Web Views is anything but simple, and native developers are stuck reinventing the wheel every time they need to use one of these Web Views in their app. Luckily, that pain is coming to an end. Read on to learn about our take on a better drop-in Web View for iOS and Android native app developers.
The Use case for Web Views
Web Views feature prominently in many apps. Some apps are built entirely around a single primary Web View instance, and other traditional native apps selectively display and embed Web Views to bring in web experiences.
For apps where most of the functionality and content is built in the Web View, the use case for Web Views is obvious. I don’t want to spend more time talking about that use case here but tools like Capacitor and Ionic Framework excel at this and are widely used.
For traditional native apps, the use cases for embedding web experiences might vary from from embedding an existing web experience such as a mortgage application or a survey, to displaying web-based authentication forms, to hosting prototype web experiences before porting to native.
Generally, the more established the company, the larger their web development teams, and the more prominent that company is on the web, the more likely they will need to bring in web experiences into their mobile app at some point in time.
The Problem with Web Views Today
Generally, Web Views provided by Apple and Google are spartan and bare bones. Nearly every native developer that we’ve talked to has expressed annoyance at extending the stock Web View controls and then maintaining a fairly complex set of code to host web experiences in the app. Thus, the problem with the stock Web Views is that they just don't do enough and don't cover the surface area of what native developers typically need them to do.
I have first-hand experience with this as the creator of Capacitor, which is essentially a supercharged Web View for hosting web apps that need to interface with existing native code. Capacitor is many tens of thousands of lines of code that wrap the core Web Views available on each platform and add a number of features, like:
- An API for adding new native “plugins” that expose new Web APIs to web developers based on custom native code, and do so in a controlled fashion and with a web-developer approved API (promises, typescript, etc)
- A high performance bridge for communicating between web and native and keeping track of invocations and returning results back to the caller
- Handling references to assets to host web content offline and correctly stream data for Web HTML controls like video and audio (surprisingly tricky).
- Marshalling data between the native and web layer
- Managing native elements such as alert dialogs, keyboard, status bar, scroll regions...all while correctly handling orientation changes
- Handling delegate methods for navigation, load, errors, permission requests, and other general housekeeping.
- Updating embedded web experiences dynamically and out of band with the slower native release cycle
And then doing this on both iOS and Android (on which even more code and complexity is required). And this list is not nearly exhaustive!
It seems like every meaningfully large native app ends up implementing a subset of the features above, which is no small task!
Building a better Web View
It took many months to build the first version of Capacitor due to the complexity required in building a robust Web View wrapper with the above features, and I never want another developer to have to go through that again.
Sadly, almost every native app developer does have to go through this today, and then has a bunch of complex, custom code to maintain. All that when they could have just imported a stable, well maintained, feature-rich Web View control and got back to the fun part of building their app.
When we realized that what we had with Capacitor could be pulled out to help native app developers everywhere, we knew we were on to something: a much better Web View for native apps.
Announcing Ionic Portals
We’ve been working on bringing the Web View technology behind Capacitor to native apps and native developers everywhere, and we are taking the wraps off the first iteration of that product today: Ionic Portals.
Ionic Portals is a drop-in Web View component for native apps that handles all the messy, annoying parts of using a Web View in a native app. Developers can host multiple different web experiences through different “portals”, and isolate them, selectively exposing custom native functionality that each one needs. Teams can remotely update and deploy new web experiences dynamically to deploy new features and tests in realtime and without disrupting the native app release process.
Ionic Portals uses the same technology currently deployed in major consumer apps like Burger King, Paylocity, H&R Block, Aflac and more, but distributed as a drop-in control for existing native apps.
And on top of all this, Ionic Portals is maintained and supported by us, so you have one less component to have to maintain in your app.
We’re currently working with a few teams who are desperate for a better Web View control in their native apps. If you’re interested in trying it out and sharing your feedback as we built out the product, we’d love for you to get in touch. Visit the Ionic Portals page to see a demo and learn more about our take on a dramatically improved Web View for native apps.
