Thank you for this interesting article !
I consider hybrid applications with webviews as one of the most important applications on desktops too!
I use WebView from the JavaFX package unfortunately this has an old WebKit version as a base. It lacks a Chromium based WebView on the Desktop (Windows and Linux), so I would have to work with heavyweight Chromium Embedded Frameworks.
It would have a current WebViewer (by WebKit) for embedding in Deskstop applications are provided … someone knows a solution for this?
Friedhold
Would using Electron be an option? There isn’t a whole lot of investment to provide non-CEF solutions for cross-platform WebViews. This isn’t ideal for your case where you are using JavaFX as your app layer.
Nice article.
Still newbie to web technologies, as I m coming from traditional c++, java background.
I am still confused on the basic difference between webview and rendering engines like webkit or blink. Feel like their purpose is one and same. Can you shed some light on that?
Thanks in advance.
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 
Riiiight. I was just curious if you knew of something cool that I didn’t already. 
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? 
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:
https://developer.chrome.com/multidevice/android/customtabs
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 
.
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
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 
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.
Thanks!
@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?
1 Like