Use WKWebView instead of UIWebView

[ckknight]

It would be nice if there were a way to use WKWebView instead of UIWebView when using the <WebView> component, as WKWebView has substantial performance benefits.

[drkibitz]

It also comes with problems. Would like to differentiate between the 2 as separate components.

[LinusU]

@drkibitz What kinds of problem? The only thing I can think of is that it requires iOS 8. Maybe we can choose UIWebView when on iOS 7 and lower, otherwise use WKWebKit.

[gabro]

WKWebView is known to be "broken" or at least unfinished. Here's a relevant thread about why (for instance) Google Chrome for iOS still uses UIWebView: https://code.google.com/p/chromium/issues/detail?id=423444

A relevant fragment of the discussion:

A partial list of regressions relative to UIWebView that we’re currently aware of:

• There is no cookie management API, which means there is no obvious way to clear/manage cookies
• Protocol handlers no longer work, which breaks several very important features
• POST bodies are missing from delegate callbacks, which breaks certain aspects of form handling

[vjeux]

We should have WebViewIOS and WKWebViewIOS instead of a generic WebView component. Anyone up for the renaming and providing both implementations?

[chandlervdw]

While still buggy, it looks like Telerik has implemented a WKWebView plugin for Cordova that gracefully degrades to UIWebView in <= iOS 7. I agree with @vjeux that we could go ahead and split the components, setting the stage for a working WKWebView.

[jaygarcia]

+1 on @vjeux's suggestion.

[sophiebits]

Why do we need both?

[vjeux]

@spicyj we should be able to expose all the platform features and let the developer pick the one that makes sense for their use case.

[sophiebits]

I agree in principle but my understanding is that UIWebView is preferable only if you need a synchronous API (or need to do low-level configuration), neither of which are super compelling reasons from the JS side. I'm okay either way I guess but the UIWebView/WKWebView vs WebViewIOS/WKWebViewIOS suggested naming is odd to me.

[joewood]

Isn't there still an issue with WKWebView in that it cannot load from a local resource, it has to load over http? Telerik included a mini-http server in the Cordova plugin to workaround this issue, as far as I remember. Just mentioning, as it may not be as simple as a drop-in replacement.

[mydearxym]

+1 I use Semantic-ui to build my mobile app on iOS , and it kind of slow , maybe the WKWebView will speed it up

[koenbok]

Does anyone happen to know if the JIT is enabled in JSContext on desktop?

[brentvatne]

^ cc @ide

[brentvatne]

Labeled as good first task as per @vjeux's comment:

We should have WebViewIOS and WKWebViewIOS instead of a generic WebView component. Anyone up for the renaming and providing both implementations?

[oveddan]

I second @joewood concern about the WKWebView being buggy. You can't load html from a local resource, nor does it support the html5 app cache, so pages cannot work offline. This is not an issue with standard WebView.

[brentvatne]

I'm going to close this because it doesn't seem to be going anywhere - I think there would be some value in having a WKWebViewIOS component so it's available as an option at least - if anyone has any use for this and wants to implement it, please do so and open a PR 😄

[oveddan]

Agreed @brentvatne it would be nice as a separate component. Also, FYI in IOS9 there will be a SFSafariViewController

[brentvatne]

@oveddan - ooh, looks cool! shares cookies with Safari

[oveddan]

@brentvatne I'll work on creating WKWebView component - I think it could be useful with something like what @joewood mentioned Telerik did, with some sort of min-http server, that serves a local file over an http server. If the packager can serve html, then someone can build something similar for these static files. That mini-file-server would probably be a separate project.

[bnolan]

@oveddan Any progress on this? I'd like to use WKWebView for SceneVR because the javascript performance is much higher than UIWebView.

[oveddan]

@bnolan Sorry, no I haven't had a chance to work on this, nor do I have time in the near future to.

[jordaaash]

I am actively working on this, and have a nearly complete implementation of the API currently supported by React Native for UIWebView. I should be ready to open source the project next week, and then I'll open a PR for it here.

This is my first attempt to contribute to React Native, so I would definitely expect the PR to go through no small amount of scrutiny by the core team as I revise it, but I plan to release it as a standalone first.

There is also qrush/react-native-wkwebview which is barebones but works if you need something right away. I used it for a little while myself before deciding to fully implement it.

The main differences between Nick Quaranto's project and what I'm working on are:

• Taking into account iOS API differences between UIWebView and WKWebview, support for as much of React Native's current API from WebView.ios.js as possible: bounces, html, injectedJavaScript, onNavigationStateChange, and all other events
• AQWebView.m has built-in spinners for loading and pull to refresh behaviors. I've removed these and exposed the events, so you can implement your own state transitions using onNavigationStateChange and renderLoading, as with React Native's WebView.
• Improved internal handling of local paths and file:https:// URLs. WKWebView has various issues with this, depending on the version.

It's based on React Native master but I'm backporting it to v0.14.x as well.

[fungilation]

Just want to chime in that WKWebView support (in addition) would be most welcomed, for performance reason. For http webviews, WKWebView in iOS 9 is pretty much superior now with no downside.

And for reference, in iOS 9 there's also Safari View Controller which chiefly gives users webviews that shares same login cookies as from Safari itself, but at cost of no ability to inject JS or control what goes on inside that Safari View. There's support for RN at https://github.com/naoufal/react-native-safari-view

[eljefedelrodeodeljefe]

@jordansexton do you have progress on this? Would be an enabler for me. I am a backend dev, learning react.js seems a bit steep to me. So I am looking to have vue.js in a (decent) webview and use react-native as a backend and for heavy lifting. Sorry all.

[jordaaash]

I completed this but never open sourced it as I no longer use it. I use the
stock React Native webview based on UIWebView. I may be able to release it
if you're interested, but I recommend against using it unless you really
know you need WKWebView. The limitations of it are extreme and even that is
understating things. No cache control or support for NSUrlProtocol inside
of your app is a dealbreaker.

Jordan
On Apr 7, 2016 7:49 PM, "Robert Jefe Lindstädt" [email protected]
wrote:

@jordansexton https://github.com/jordansexton do you have progress on
this? Would be an enabler for me. I am a backend dev, learning react.js
seems a bit steep to me. So I am looking to have vue.js in a (decent)
webview and use react-native as a backend and for heavy lifting. Sorry all.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#321 (comment)

[arbesfeld]

@jordansexton I'd love to see what you worked on!

[dvicory]

@jordansexton Would also like to see it!

[hramos]

@bowerman0 I echo @ide's comment and it's something I've commented on other WebView issues. We are reluctant to import PRs that touch WebView, and would rather have the community work on third party modules to fit their needs.

On our side, we do need to agree on what the future of the build-in WebView module should be in order to avoid any further confusion here when people try to use this module as opposed to a better supported third party module.

[hramos]

@fungilation how do you think react-native-wkwebview might benefit from being merged into the core React Native repo (aside from an increase in visibility)?

[fungilation]

That and de-fragmentation. If react-native-wkwebview is more actively developed and better (in multiple ways IMO) than RN's (stagnant) WebView, doesn't the community benefit from a better out-of-box iOS WebView that's built-in and will be more used/supported?

[brunolemos]

While WebView be the "official way to do it", that's what 99% of developers will use. IMO it doesn't necessarily need to be merged, a note in the docs like it was made with react-navigation could be enough. But merged in the core passes more confidence that it will be maintained.

[insraq]

Maintainer of react-native-wkwebview here. I agree that there are limited benefits for this repo to be merged into core, one of them being Expo support (Expo still uses UIWebView). But I think this is more of an issue for Expo, rather than React Native.

IMO, React Native should focus on the "core" bridges and this component should happily live as a 3rd party component. This makes it easier for people to actually contribute to this project. Also, it means flexible release schedule (as opposed to the monthly release schedule of React Native)

And I agree with @brunolemos that improving React Native docs is a better way to make people more aware of the decision regarding UIWebView and WKWebView and point them to the solution.

[fungilation]

Could react-native-wkwebview be "linked" in RN proper (in documentation if not in code, though being built-in without install would be nicer), as a new WebViewiOS in RN? Then there's no downside even for "touching" existing WebView.

More people see and choose to adopt WebViewiOS, less issues against existing WebView over time until if or when it gets deprecated.

EDIT: as @bowerman0 says below, visibility is a big issue. WebViewiOS in docs allows visibility without breaking existing WebView, and WebViewiOS should state benefits and the fact it uses WKWebView. (for better or worse, largely better)

[bowerman0]

@hramos The WebView should either be updated to WKWebView or move out of the react-native package. (Both are equally ok with me, personally.) The UIWebView-based WebView can cause unexpected problems for developers that use it. Because the official docs use WebView, most developers probably do not look for alternatives until they encounter problems.

[iainbeeston]

UIWebView is officially deprecated in iOS 12 (I don't think it was in iOS 11, but forgive me if I'm wrong about that) https://developer.apple.com/documentation/uikit/uiwebview

[amloelxer]

@hramos any word on if there are going to be instructions on building on iOS from source anytime soon? I would love to poke around on this and other issues, but as I believe we discussed before, the only instructions to build from source are for Android and they are here https://facebook.github.io/react-native/docs/building-from-source.html. Am I missing something? Are there any guides for building from source for iOS?

[amloelxer]

Also/ or if someone could explain it to me, I would be happy to make a PR to the docs

[ckknight]

I opened this issue over 3 years ago. The lack of action on it has once again blocked a major feature.

[smathson]

@ckknight If lack of action is blocking a major feature for you, consider using https://github.com/CRAlpha/react-native-wkwebview. We are using it in production with no problems.

[kelset]

👋 related to this whole WebView topic, just wanted to let you know that "something is moving": within the core we decided to try an planning an "extraction" of this component into its own separate repo for easier maintenance.

You can follow along and give feedback here: react-native-community/discussions-and-proposals#3

[jamonholmgren]

Because https://github.com/react-native-community/react-native-webview uses WKWebView by default, I'm not planning to migrate this issue over there. This issue can probably be closed.

[kelset]

Sounds good to me - closing

[luisnaranjo733]

Should we consider WebView to be officially deprecated from RN and migrated to react-native-community?

[kelset]

Basically, yes. It will be properly announced when 0.57.0 is released but yeah, that's what will happen.