DEV Community

Cover image for Building a better Web View for mobile apps
Max Lynch for Ionic

Posted on

Building a better Web View for mobile apps

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)

mzekrallah profile image
Mohammad G. Zekralla

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 ?

maxlynch profile image
Max Lynch

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!

fastcodesoluti1 profile image
Info Comment hidden by post author - thread only accessible via permalink


seanmclem profile image

Right, but isn't using a web view in a native app - what capacitor already is?

Thread Thread
natetronn profile image
Nathan Doyle

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.)

mzekrallah profile image
Mohammad G. Zekralla

Sounds great .. can’t wait to try these goodies .. good luck guys

fastcodesoluti1 profile image
Info Comment hidden by post author - thread only accessible via permalink


98sky profile image

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