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 :smile:

[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:// 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" notifications@github.com 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 https://github.com/facebook/react-native/issues/321#issuecomment-207150673

[arbesfeld]

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

[dvicory]

@jordansexton Would also like to see it!

[jordaaash]

Sure thing, I'll check it into a public repo today (Tuesday) if I have time, and tomorrow if not.

[jordaaash]

This is alpha software. WKWebView itself was unable to meet my needs, and I don't use it any more.

Since that's out of the way: npm install react-native-wkwebview

https://github.com/jordansexton/react-native-wkwebview

I believe it was based on RN 0.20 (as seen in the dev dependencies of package.json). I can't make any guarantees, but I'll see what I can do to update it for more recent RN versions, and also to turn it into an iOS lib for easy integration. You should be able to (ab)use it right away by just dragging files into your Xcode project.

[jordaaash]

The original code was very closely based on React Native's WebView for iOS at the time it was written (for React Native 0.14, I believe), and then updated a bit for 0.20, but not since. This was internal to another project so you won't find any helpful git history, and you will find wacky artifacts in this library against numerous versions of RN. These are what I'll be trying to smooth out, but it's definitely usable if you're willing to hack around. I suspect it's currently compatible with RN 0.19+ but I can't say for sure.

[dvicory]

Thanks @jordansexton, I will be looking more into your library over the next few weeks. A quick glance through it does look similar to what RN has internally. We will potentially be using this for a project at the company I work at and if you're unwilling to maintain it we may be able to take over maintenance. Though would appreciate any work in getting it working with latest RN releases.

What sort of wacky artifacts are we talking about?

[jordaaash]

Haha similar indeed. I basically just copied the RN code as of 0.14 originally and changed things as needed, or eliminated things where unsupported in WKWebView or required for my use at the time. There is also a small addition that was made to handle target="_blank", and mailto: or other non-http/s links.

I updated the code for 0.20 essentially using the same hacky process. It's hard to say what kind of wacky artifacts you may encounter (too wacky to think about!) but it really just comes down to API changes in RN that may not be reflected in the code or my knowledge of RN (limited) or iOS (more limited).

I say all this mostly as a big disclaimer so that when somebody says "it doesn't work", I can just point to this and be like "yah, I told you", and then try to fix the issue once I'm aware of it. One thing that comes to mind is the unusual synchronous shouldStartLoadWithRequest handling, which was added after this was made.

[insraq]

We have recently open sourced our implementation of WKWebView on React Native. The implementation derives from React Native's WebView. We fork from @jordansexton 's git repo when extracting the source from our codebase. We try to maintain maximum compatibility with WebView. We've also implemented onShouldStartLoadWithRequest, which uses WKNavigationDelegate internally.

We use this component in our app and will try to make sure it works with latest React Native. (our App usually upgrades to latest RN asap). For anyone interested, here is the repo: https://github.com/CRAlpha/react-native-wkwebview (currently not on NPM).

Update:

It's on NPM taking the name react-native-wkwebview-reborn We've also added postMessage support and lots of other features. PRs are welcome.

[brunolemos]

I really believe we should reopen this issue. (or #10456)

1. WebView was deprecated by Apple, WKWebView is strongly recommended:

2. Fix performance issues (it uses the Nitro Javascript engine)

3. New iOS features, like 3D Touch support

4. Support for swipe back gesture

5. Probably a lot more that I didn't face yet

In my view, it's time for it to be the new default. What you people think?

[farazs]

@brunolemos agreed. the current webview implementation has issues with the javascript bridge as well https://github.com/facebook/react-native/issues/11594

the only fix I see is something like this http://www.joshuakehn.com/2014/10/29/using-javascript-with-wkwebview-in-ios-8.html

[fungilation]

Is there any kind of discussion with the RN core team about this? Coming deprecation of UIWebView, likely in iOS 11, ought to be addressed.

[farazs]

Just use https://github.com/CRAlpha/react-native-wkwebview it already exists and is up to date.

[fungilation]

I remember trying this package, but it either didn't build or run. That was a few months ago though.

If WKWebView works with minimal downside (in this package), there's no reason for RN to not adopt it officially. Performance matters, besides compatibility.

[shergin]

It's a time! We definitely have to replace UIWebView with WKWebView. We can do this in two simple steps:

• Create a new fully compatible component WKWebView; live with it and test it carefully;
• Replace old one with it! (Previous implementation can live as a separate package.)

Honestly, we, at Facebook, do not use this component so much, so it is unlikely that I or one of my colleagues will have time to dive into this, so... PRs is welcome!

[raphaeleidus]

I made an attempt in #16535 Unfortunately I am a JS Dev, maybe someone could look this PR over and help improve it?

[fossecode]

@shergin any news here? @bowerman0 submitted a PR a couple of months ago in https://github.com/facebook/react-native/pull/16792, but it has not been reviewed yet. Been waiting for this for a long time, it would be so nice to get it.

[fungilation]

Agreed. I'm developing an app that relies on WebViews heavily, and I run into situations where really long websites (ex. hackernews with long comment threads) would crash the app on reloading the webpage. WKWebView may crash too but at least I'd know that's the latest and updated by Apple, while UIWebView has long been deprecated now.

[yilunzhang]

+1. Existing WKWebView packages (e.g. https://github.com/CRAlpha/react-native-wkwebview) does not work with expo.

[fungilation]

I'm wrestling with some malformed website (not sure how) that crashes my app, on loading them in UIWebView (https://github.com/fungilation/react-native-webview-bridge/ to be precise). https://canscribe.com/ for one repeatedly crashes my app on loading it in webview. The website loads fine, either as an in-app browser (SafariView) or Safari itself.

UIWebView is ancient, not fixed or updated and needs to be deprecated.

[hramos]

As @shergin mentioned earlier in the thread, we don't use WebView much here at Facebook. You can tell by the vast quantity of issues that are opened against WebView here on the repo.

One of my responsibilities is to ensure the open source community's needs are met. Be assured I'm aware of the need for a better solution here. As it happens, we don't have plans to make changes here so I am updating the issue to make it clear the contribution has to come from the community for the time being.

[bowerman0]

@hramos are you interested in this PR: https://github.com/facebook/react-native/pull/16792? I can rebase to latest and merge some other bugfix commits if there is interest in taking the changes.

@grabbou mentioned on that PR that it was unlikely to get merged, so I was going to make a standalone project when I got the time.

[fungilation]

How about merging https://github.com/CRAlpha/react-native-wkwebview into RN proper? It's still iOS only, but since we are talking about WKWebView that's the half that matters. It's a very active repo (illustrating exactly the demand for a better WebView), and have a better (working) 2 way messaging between React Native and WkWebView than RN's own, IMHO.

@bowerman0 if you are thinking of starting your own, you should look at react-native-wkwebview first.

I'm using https://github.com/alinz/react-native-webview-bridge in my app WonderSwipe, and I'd migrate to react-native-wkwebview when I have time. react-native-webview-bridge is still UIWebView, poorly maintained and it's... quirky. I had to use react-native-webview-bridge because RN's own WebView was and is lacking still on 2 way communication between React Native and the WebView's internal JS, which I need.

[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?