React-native: 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.

[jordansexton]

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.

[jordansexton]

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
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!

[jordansexton]

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

[jordansexton]

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.

[jordansexton]

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?

[jordansexton]

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?

[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

[fungilation]

Good riddance. Get with the times and migrate to WKWebView.

[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: https://github.com/react-native-community/discussions-and-proposals/pull/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.