Web 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.
Top comments (8)
This sounds awesome and i read the article and watched the demo but isn’t portals the same as “capacitor” but in a paid model ? I mean can you please make it clear how come portals is different from capacitor ?
Portals uses Capacitor but it's built to be dropped into an existing native app (Capacitor doesn't support that today). It also has additional features for remote updates of multiple Portals in a single app, as well as some future tooling to make it easier to work with in large native app projects. As we build it out a bit more hopefully the differences will become more apparent. Thanks!
testts
Right, but isn't using a web view in a native app - what capacitor already is?
I realize this is an old post and comment but, for others who may have had a similar question like yours, as was the case for me, I think this page in the docs explains what Portals is and isn't (and when to use it vs using "traditional" Capacitor instead etc.)
ionic.io/docs/portals/what-is-a-po...
Sounds great .. can’t wait to try these goodies .. good luck guys
jh
Hey everyone, I need your help in android native webview using java I want to open camera from javascript side . I faild to do so, anyone have idea
Some comments have been hidden by the post's author - find out more