Understanding WebViews

They are similar. The rendering engine is primarily interested in painting pixels based on whatever HTML/CSS/JS it is dealing with. The WebView is the frame surrounding the rendering engine, and it comes with its own APIs to allow whatever app container it is in (could be Electron, WPF, etc. app) to communicate with the rendering engine and other related components.

Do you have or know of a comprehensive list of these?

I don’t, but I would venture every major app framework in existence today will provide support for a webview. Even if it didn’t, you can roll your own webview with only some effort :tractor:

Riiiight. I was just curious if you knew of something cool that I didn’t already. :wink:

Thanks for helping out on this.

Thanks for writing this article! In it, it seems like you use the term ‘WebViews’ very broadly, encompassing ‘traditional webviews’ and ‘integrated in-app browsers’. Would you be able to share some information about how you view the differences between these types of ‘webviews’? Are both types still available, or have IIAB types now the standard?

In-app browsers are just WebViews. Where a WebView contains no UI, the IIAB contains your typical address bar, buttons, and related UI that makes the WebView more usable as a browser. Does this help? :slight_smile:

Thanks for the reply… I thought the IIAB is preferred not only because of the built in browser UI but also because of security reasons. I don’t do any native mobile development, but when I was researching a little bit into this area I came across another article:
https://www.addthis.com/blog/2017/04/04/in-app-browsers-explained/ and the google android developer article:
The takeaway I got from those had to do with user data is kept secure with an IIAB vs a webview, but I haven’t found much other contemporary literature about the topic of webviews.

You can customize the behavior of a WebView to be more secure by enforcing HTTPS only navigation, blocking cookies, etc. Many in-app browsers prepackage some of these customizations “for free”.

There are many reasons why platforms encourage in-app browsers over WebViews. For navigating to various URLs, the convenience is a big factor. You don’t have to recreate any new UI. A more cynical reason has to do with ensuring some of the OS/platform’s more proprietary “extensions” are run as part of the browsing experience. These are extensions that you may not enable with a raw WebView for various reasons.

Sorry to bother, but what “101” means? I burn with curiosity.

It’s a way of signifying that Kirupa’s going to cover the basics of webviews in that paragraph.

1 Like

Nice article :partying_face::partying_face::partying_face:.
But I am kinda confused on how webViews are integrated into sections native mobile applications or desktop applications. I know about full screen hybrid apps. I have used electron for creating dektop application. But I don’t know how to embed into a section of the native application like an advertisement.

Hi @Japan1 - welcome to the forums :slight_smile:

Think of the WebView as an image element in your native UI. This image element is part of other things on the page like text elements, buttons, etc. The source of the image element would typically be an image file - which could be a part of the package or retrieved from a remote URL.

Now, replace the image element with a WebView. The source of the WebView could be some HTML content local in your package or some HTML content out in the larger internet.

Does this help clarify?


Very nicely explained Kirupa ! Awesome !

Thanks! Glad you liked it. It was one of my favorite articles to write :nerd_face:

Hey Kirupa,

Enjoyed the article! It covered a lot that most people don’t go into about why you would want to use a WebView.

One thing you didn’t mention is that hybrid apps aren’t supported on iOS. You can still write a hybrid app, but Apple won’t approve it on the App Store. They updated the Human Interface Guidelines a while back to prohibit apps that are simply repackaged web pages, saying that

“Apps that dynamically provide core features and functionality with web technology like HTML5 are best delivered through Safari, rather than through the curated App Store.”

It’s a bit disappointing, but it’s definitely something people should know before they start working on a hybrid-style iOS app.


@cadehunter - that’s good to know! I wonder what their bar is for repackaged apps, for that is a bit unclear. If I repackage a URL but have about 30 lines of extra JS that calls into system APIs, will that pass app store approval? :nerd_face:

1 Like

Hi there, I just watched your video on WebViews (very helpful. thanks, btw) and had a question about enabling WebViews on Wordpress.

So, basically I have a Wordpress site in which I host content (articles, videos). This site CMS’s is used to manage the content and then display it on my app (through AppMySite native app builder). That said, my question is, would it be possible to somehow enable WebViews on my Wordpress site (via plugin or back end work) so that when people click on a post link they are directed to the site hosting the content instead of an internal page? Similar to what social media sites are doing today and your examples from the video.

The blog or site will be public on mobile only so I’m only using Wordpress because I needed to build the UI in a particular way and use it as CMS.

I appreciate any help on this as I’m not a developer and am trying to figure out the best way to go about this. Thanks so much!

@dan27 - is this is a duplicate of a post you made yesterday? :slight_smile:

webViews are also great to build a UX heavy feature once and embed on all cross platform and for a company which has invested in native and web apps and expects the feature to be the same across all platform.

What are your views on local vs Remote webViews?
Since webViews are powerful and have access to native APIs there is a potential of RCE if we start trusting the remote code via the remote webView approach? is local a better option ?

What are your thoughts on smart vs dumb webViews?
I define smart as webView which does a ton of business logic and have less data bridging with the native vs dumb webView which basically focus on just UX and data is being sent to it from native.

For instance, If my native application has already setup a data channel open with the backend server receiving data notifications and now my webView needs data, so i don’t want to establish a separate websocket connection within a webView wasting client/server resources? is dumb webviews the right approach? What are your opinions around these.