So, we are going to talk about the state of Webview with Niklas.
Thanks.
Can you hear me?
Yeah.
Sounds about right.
Okay.
So, I'm Niklas.
I'm a chair of the W3C Webview community group for two years now.
And I'm a maintainer of Apache Code Over.
And that's the way I got into Webviews.
So, because Apache Code Over uses Webviews for building cross platform apps.
And yeah, I had some trouble with Webviews in the past.
And so, I joined the community group to make a change.
First, raise your hand please.
If you have ever used Webview for some kind of application.
Oh, that's good.
More than I expected.
And if you haven't used it before, have you ever thought about Webview while developing for the web or whatever?
Oh, that's what I expected.
So, for the next few minutes, this is a little overview of what I want to talk about.
It's a bit of the diverse topic.
And yeah, Webviews are on a weird space.
We will see.
I'll catch you up on what Webviews are.
And yeah, what maybe the future for Webviews.
So, first, what is Webview?
The short answer is, we still don't know.
So, we're still figuring out what exactly is Webview.
We came up with different definitions.
Some of them are over here.
They are quite good, but we still get into arguments.
Have long discussions and never find found a good definition.
And yeah, essentially it means if you're embedding Web into an application, you're using a Webview.
But yeah, there are different kinds of Webviews.
This is something we could find quite good definition.
We have defined two types of Webviews.
A fully flat Webview, which can basically do anything you want.
Just like the browser and more.
And we have browser-like Webviews.
So, the criteria we defined.
Use experience flexibility.
The access to Web content.
And yeah, stage sharing.
I will get to that later.
This is defined in our usage and challenges report.
Part of the Webview community group.
So, as an example, I'll get you a screenshot of an application using Android Webview.
You can see in the top part is a native UI.
This is something very ugly.
I built myself.
And then in the bottom, there is the Webview component, which renders the Web page.
So, the app can mess and influence the content of the Webview in any way it wants.
Because it has APIs like JavaScript, Edgex's, X's to cookies, loading stuff, loading CSS into the page, whatever.
Yeah, other type of Webview is another example.
This is like a browser-like Webview experience.
It's Android custom tabs.
You might notice it from social media.
So, you click on the link and not your default browser opens, but it opens inside the app.
And yeah, custom tab is the API on Android for that.
It brings its own UI as you can see.
You see the domain we're going to.
And the title of the Web page.
And it can do things like stage sharing with the browser.
So, you might be locked in into your accounts.
And it's more reliable used for web browsing.
Because the app developer has less access and cannot, yeah, mess with you.
And extract content from the page.
What else is different?
Or what else differs?
Webviews from browsers?
So, Webviews are developed separately from browser development.
In some kind of fashion.
So, I'm not sure.
I don't work for browser developer, browser vendor.
But I've talked to some.
And yeah, Webviews sit somewhere between the native teams and the browser teams.
So, they have to consider both sides.
Because they have native APIs and browser.
Things they need to consider.
They're also more complex to build.
Because you have to take into consideration extra security and compatibility stuff.
And yeah, this makes them a lot more harder to develop.
And some browser vendors told me that it takes more time to build something for webviews than for browsers.
Webviews, as well, are part of the things.
Patrick talked about, like, interrupt, blah, really browser planning.
So, some features might come later or not get implemented into webviews.
Again, a little overview of why I care about webviews.
I started building apps.
Using webviews, then I got into maintaining a project.
I just use this webviews.
And yeah, use the feature of the capability of webview to build a cross-platform framework.
Patrick got over.
I got maintain on this project.
The community group was founded a few years ago.
And I joined because of my interest to improve the group.
And now I'm acting as a chair.
And trying to figure out how we can improve webviews.
Why you should care webviews.
You might want to consider webviews in some parts of the web development process.
Because there are critical component for many apps.
You might use them every day without noticing.
And yeah, they might expose you to security risk.
If the developer isn't using webviews properly,
they use for inner browsing.
So you might go to a page and it's broken.
Because the webview isn't up to date to the browser status.
And you might be using mini apps.
Mini apps are not that popular in Europe.
But in China they are big deal.
And basically everywhere.
And mini apps are using webviews to deliver experiences.
And many users in China or in Asia in general don't go to browsers.
That often, but everything happens inside super apps and mini apps.
And webviews are a big part of this.
And in my opinion, the web is the best cross-platform technology we have today.
It's good to build for the web.
So you can target basically any system.
So webviews are part of this.
The current state of webviews is pretty broad.
Pretty complicated.
We have mobile webviews.
We have desktop webviews.
We have platforms that are using webviews for different kinds of things.
Like Electron is using some kind of webview.
And it's everywhere basically.
And embedding is really important.
Some developers are building apps using webviews.
And they need webviews to keep up to date.
And it would be great to have the same content we have on the browser.
Inside the webview as well without any issues.
So fragmentation is a problem or could become bigger problem.
Most of the webviews we have today are provided by operating system.
So they are part of the platform, the authority.
And they are bundled with operating system.
So you don't need to care about updating the webview yourself as an app developer.
And this is what you have today.
But there are some pain points for webviews.
And there are some good reasons why we formed the community group.
So the biggest thing is the difference in behavior and support of web features.
So some web features come to webviews at the later stage or don't come to webviews at all.
And this creates some friction if you want to use the same content for webview and the browser.
Webviews have native APIs.
So basically every webview has its own native APIs.
They do similar things but do it in a different way and have different capabilities,
which creates some problems.
And sometimes it's hard to find out why something in a webview is broken,
why it's not supported or what's going on here.
The example I always bring is the topic of custom schemes,
origins, loading local files.
I won't bore you of the details but I spent many, many months,
figuring out problems here.
And yet this comes from the Apache Code Overcase where we have an app written in React,
Angular of UGS.
Bundle it together inside an app bundle, put it in the app.
And then the webview is loading local content from the file system,
so not from the internet.
And webviews have API for this.
Here's a little difference of the two APIs.
You have different names, different approach, but do the same thing in theory.
But because they're not doing exactly the same thing,
you have to figure out how you can make it work and this created some problems
for code over and similar approaches in the past.
So to tackle this, all of this in the webview community group
came up with the need we have to document issues like this somehow
and other data for the web.
We have web features today, as Patrick mentioned earlier today,
and it is great for getting an overview of everything,
and so we applied this to webviews.
And yet to make it work to experiment with the data we have,
we build a new site, canaveview.com,
to write down first behavioral documentations,
like the native APIs, and also work with web features,
and see the and everything we learned today.
So this is a screenshot of the site,
and basically the best example we have today.
We extended the tooling from web features a little bit,
so we have web views, and they're equivalent browsers,
so Android webview should be similar to Chrome on Android.
iOS webview should be similar to Safari on iOS.
So canaveview today shows you this table,
where things don't match.
We see some mixed support.
This is all coming from web features,
and canaveview is just the place to host it today,
and to visualize it.
But the data is together with all the other data for browsers.
So we don't create a new space,
we just do it today here,
and canaveview may be at some point,
it will be part of mdn, canaveviews, and all the other resources.
We started with bcd,
and then came to web features through our picture,
and thanks to the help from open web talks,
some people at Google,
we managed to get a good overview today,
and we're still discussing how to implement this,
into something like baseline, and all the other resources.
So the community group currently focuses on documentation,
so as you saw,
we have canaveview.com slash base,
and we can see an overview.
We also built and published some testing apps,
where you can load the site,
your site, your developing elsewhere,
your development for the browser,
into a web view,
and you test if something's going wrong,
and you're quickly to use bugs.
So these types are available,
these apps are available on the stores to download,
and you can have a look yourself,
and figure out web views without building native apps yourself.
So in the past, I always had to build my own native app
to test something in web views.
Another interesting approach,
I recently started working on a server.
We will hear about server later today,
and yes, server has this slogan on the main page today,
so they're focusing on embedding,
so this sounds like a perfect fit for web views,
and I took some time to look into this,
and server is a good fit for trying a new web view,
trying how we can do things differently,
and server is really gaining traction,
and I focus on this, so it's a good time now.
Naturally, because I'm coming from a patchy code over,
I got into figuring out how we can embed server into a patchy code over.
I built a plugin for this,
and it works on Android right now,
because server was pretty easy to get going on Android,
which was surprising to me,
but I'm happy to report that we can use it.
There's still a lot of details to figure out,
and you will notice pretty quickly that some things are broken,
and not working as expected,
but I'm gonna keep working on this,
and I'm looking forward for yeah,
collaborating with the server team there.
Thanks to some, thanks to the help and some funding
from NGI mobile free fund, which is run by an internet,
I got a little bit time to work on this as my free time project.
Currently, I'm working on getting the essential features,
done for a patchy code over, which is a black and bridge,
so in a patchy code over, you have the website with JavaScript,
HMS, CSS, and then you can call native functions
of the operating system,
like take a picture, get the location,
or active Bluetooth, wireless, whatever,
but would normally not be available in a browser,
can be available in your web field with a patchy code over,
and for this, we use a black and bridge,
and I'm getting to work this,
but the server lacks some APIs,
we have an Android web field for example,
so I have to work around this,
but maybe at some point,
if you will get those APIs in server,
and it would be great opportunity to make it work properly.
So what does the future bring for web views?
I'm not sure.
Web views definitely need a lot more considerations
for security privacy.
This is the number one priority,
because if you make changes to web view,
and we don't think about security and privacy,
things go down pretty quickly,
and we definitely don't want to do this,
and we think improving web views,
and improving the documentation around web views,
and reducing fragmentation around web views,
helps a lot of other areas, like mini apps,
and mini apps are very fragmented as well.
They have their own APIs, their own problems,
but we're looking forward to working together with them as well.
Also, AI is everywhere these days,
we are not sure if it stays, or how it will stay,
but maybe web views would play role there as well,
maybe web view, APIs, web views,
will be part of AI experiences.
So this is also a reason why we should focus on web views today.
The top title can be fixed things.
Short again, I'm not sure.
I'm just an independent developer.
Open source developer.
I don't have any stakes and browser development,
so it's hard to tell how we can change things.
If we can change things,
because vendors for good reasons move carefully,
and don't want to break their things.
The APIs for web views have grown over the years,
and there should be stable for good reasons,
and therefore there is not enough interest yet
to work on collaboration on standards,
and we are revising those APIs.
I think most of the group agrees that documentation
and tooling are the best way forward,
so we're going to continue with the work on documentation we did,
and this might show a path where we're going to improve web views.
I really like the position of being independent in this space here,
because here web views have a lot of different perspectives.
We have app developers, web developers,
you have browser developers, you have browser developers,
you have framework developers,
and my position is pretty unique,
because I'm independent in this space,
and it's interesting to talk of all of these,
and find out how web views are used.
So, come to the end,
I'd like to highlight that we need help here,
so if you have issues with web views,
please reach out and write about it on blog posts,
issues, we are still collecting,
we have a report that's called Document Usage and Challenges,
and we're looking forward to expanding this report,
find out how web views are used,
but could be improved, but typical what are issues,
and we need help there.
Also writing docs, so the behavior docs,
the different APIs are documented in many places,
but there's not a good overview of all these APIs,
and it's hard to find out what changes,
especially change logs are a thing when a new iOS comes out,
you have to figure out what change,
but it's anything broken, same for Android,
so this is really a thing.
It got a good idea today that we might do,
we could do based on web features,
a change log of all the web views,
like get an overview,
that's also a reason why we have kind of a view,
like a place for all web views on the same page.
So bringing new ideas, if you have anything,
you know about web views, anything in mind,
consider joining the community group at WFEC,
and we have regular meetings,
and it's a good place to get started.
And I also could need some support for server,
but I'm hopeful for this, so we need more APIs for server view,
so we can embed server properly,
do something like code over,
and figure out if a new engine,
like server, might be a good path,
so we're moving away from only the engines
the operating system provides.
The big omelette questions I want to close here,
and here, give to the room and start a Q&A,
is, do you have anything in mind?
You want to share?
You could do it now, or later with me?
Yeah.
Do we think server is a viable replacement web view?
We could use in the future,
instead of the already existing web views,
and the long distance goal is standardization.
So web view community group might evolve
into something that standardizes web views,
but we still need to figure out,
is there a business interest,
is there a good reason,
and yeah, who might be willing to work on standardization?
So this is the critical thing for me.
And I definitely need some of those stickers.
That's it for me,
and I'm hoping to, for suggestions, questions, ideas.
Thank you.
Thank you very much.
I have two questions, excuse my ignorance.
The users get to choose,
which web view they can use on their platform,
and do web views have developed tools.
The first one is,
I don't think users get to choose.
The developers get to choose in some way,
but the choices are pretty limited.
So I was used to have two web views,
and they made a new one,
and they've located the old ones.
So you had to choice for some time,
but right now,
basically, every operating system provides their own web views.
And you basically get to use that,
and otherwise you have to ship your own web view,
which is pretty complicated.
I'm going to explain to you,
but yeah, you blow up the app size.
This is also a thing.
You don't want to use downloading a whole browser engine,
just for your delivery app.
And on desktop,
it might be different,
because desktop has bigger APIs.
And developer tools,
basically, you use the same developer tools,
you use for browser development.
You can connect to your web view,
and use developer tools like Chrome,
for Android web views,
or for iOS web view.
And if you have a debug builder,
you can connect to this,
and it's the same experience, basically.
Hi, thank you for the talk.
If standardization does come to fruition,
would those kind of native APIs that are actually
called over provides,
come into standardization,
and be available in all platforms?
And would that make a patchy code over,
kind of,
not necessary,
if it comes to all web views,
by default,
like you can access the camera by,
from all web views.
I think this is a pretty interesting question,
so,
is using native APIs,
the web view is provide
to make the bridge between web view and native.
So if everything becomes part of the web,
the browser,
and then the web view,
in term,
code over will be irrelevant,
could be gone.
But this is the unofficial model of code over,
since forever.
So code over,
or we're said,
once the web caught up to the features we provide,
you can see it's to exist.
So this is basically our end goal,
but the standardization comes in a different way.
So the web views have different APIs of interacting with the web,
so you can have a value of JavaScript,
a typical API.
So if you start in a native line,
you start a web view,
you have a value of JavaScript API,
and then you can do something inside the web view.
And those APIs are different between different platforms,
and those could be standardized.
So this is my,
hopefully, in that this will be standardized at some point,
but yeah,
we're still figuring out if and how this could be possible.
Cool, hello.
So talking about web views,
and kind of like going a little bit into the alternative paths,
because I want to hear your opinion,
have your very research on validation of applications about,
for example, module validation,
also for use cases for mini apps,
and things like that.
So this is pretty new to me as well,
just a last topic,
the W3C conference.
There was an interesting practical session about module web engines,
that you could have web views that are tailored to a specific use case,
so they don't contain all the web features,
just the ones that are needed.
So there's an interesting use case.
There's a whole community group around this.
I'm looking forward for this,
but yeah,
there's also the concern that we don't want to fragment the web,
or a subset of web.
So this is something that's definitely in this question today.
Yeah, thank you.
I heard you talk mostly about real native web views,
but we have all these developments now,
with web views.
So we have Electron,
we have VBB,
we have Firefox,
and Google has isolated web apps with controlled frames.
And like in my idea version,
we would kind of get these web views into some standard,
and then the UI and the engine of browsers
would be pluggable together.
And the native parts would just be whatever native translation
of those web web standards exist,
what are your thoughts on that?
Yeah, it's an interesting thought,
and we should continue this discussion.
Yeah, isolated web apps and all the other topics
that are coming up right now are also interesting.
We don't want to get stuck in our web views,
and many apps, so they are basically silos right now.
They don't talk to each other,
and we're looking to change that pretty soon.
And yeah, this should be part of this as well.
Hey, so thanks for the talk,
and not really a question more of saying things
for creating documentation about web views,
because in practice, for instance,
browser vendors usually aim for investing a lot on performance,
but that comes for, on the price of sometimes security hosts
that are very hard to find actually,
and they're not easy systematic ways to find them.
So I hope that, for instance,
the commendation about the security implications of web views
could be also informative for people working on not only,
not only using the web views,
but also implementing what features that could
could open such security hosts.
And for instance, for me personally,
this mini-ups usage was completely new,
a part of not very popular in Europe.
So yeah, just to show up,
thanks for sharing this information that you've gathered
the hard way, currently.
Yeah, thank you.
It was great to get Android,
and I was into the web features,
PCD space, so we have the documentation everywhere.
You can see it, and can I use it right now.
And another big plan we have is security guide for app developers,
so you can use web views in a secure and responsible way.
This is also something we would like to write down,
but we haven't found the right person and resources yet.
So I'm wondering if you could talk more about the security implications
of these bridges to native.
It seems kind of scared to me that you have a web view
that can go to an arbitrary website,
but then the embedding app can look at the cookies,
and inject color scripts,
and whatever, I'm not sure how that corresponds
to the web's normal security model.
Could you say more about that?
Yeah, it's complicated.
I can say much in one minute,
but web views are pretty scary,
if you think about it, that way.
Frameworks like code over,
capacities of Italian, whatever day,
put extra security measures in place.
So those things are secure,
that context and that usage,
but if you use a web view,
just I open up a web view,
load any site in there.
It's not very secure.
You have to think about it.
That's why we need the security guide.
We need documentation and teach developers,
how to use it in a good way,
and you can use a good build.
You could publish an app on the store,
use a web view,
say hey, this is my browser XYC,
and then scrap all user information.
This could be possible in theory.
We don't have time for our questions.
Thank you very much.
Thank you.