You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 11, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 11, 2026. It is now read-only.
UIWebView is formally deprecated in the upcoming iOS 12 #765
Facebook is talking about ripping out it's webview support entirely in favor of existing community implementations so that they can focus on react native's core and also because Facebook doesn't use webview internally. If you look at their issues, a large portion of them are about webview because they are basically just ignoring it
Long story short, I think that reactxp will need to make some decisions on what to do here. Here are a few possibilities I can think of (I like idea #1 the most).
Reactxp could ship a new implementation of webview that uses "react-native-wkwebview-reborn" for iOS and "react-native-webview-android" for Android under the hood. These seem to be the currently accepted community implementations that meet the basic requirements that react-native's current webview do not meet. I think this could be a good opportunity for reactxp to solve a common problem for its user base. Otherwise, xp apps that need webview will need to individually do this work manually (see idea Update tag in link.md #3).
Similar to the previous idea, but reactxp could write native webviews from scratch on each platform. This would avoid the external dependency on 3rd party OSS, but is re-inventing the wheel. One upside of this is that it would be easier to write a shared + consistent interface between the platform specific webviews, which were not written to be used together easily.
Reactxp could deprecate the webview, and point to existing platform-specific community solutions.
One of the principles we've followed in ReactXP is that any components provided in the "core" of ReactXP must be supported within React Native and not require any add-ons. If an RN extension is required, we've opted to make a ReactXP extension so it's optional.
We've also tried hard to retain backward compatibility in ReactXP. This situation creates a conflict between these two principles.
The best answer is that Facebook retains support for RN.WebView by changing the underlying implementation to WKWebView. If FB isn't willing to do this work, perhaps someone else is willing to submit a PR to RN.
As a fallback, I think we'd either:
Reimplement RX.WebView as you suggest above, leveraging OSS components on each platform and abstracting away any differences.
Remove RX.WebView from ReactXP core and implement a new extension called reactxp-webview, in the same manner as option 1.
If FB isn't willing to do this work, perhaps someone else is willing to submit a PR to RN.
Unfortunately, that's not the root problem right now. At first, Facebook basically said "we don't need this, if the community wants it the community is gonna have to build it". So people have started opening PRs, but now Facebook is blocking them by either not reviewing or not merging them after review (here is one example from November 2017 - this issue was raised at least back in 2015). In addition, hramos is telling people not to open PRs because Facebook is thinking about removing WebView from their core.
I should clarify though - Facebook is talking about ripping WebView out of their core code base and possibly putting it in the semi-official react-native-community repo.. It's super unclear how this will shake out and could impact what the best course of action will be.
I think both of these fallbacks you suggested are good ideas. I'm personally a fan of fallback #2. Mainly because AFAIK there is no precedent in ReactXP for shipping a component that isn't backed directly by react-native under the hood.
I've been chatting with one of the members of the Facebook RN team. He has some ideas for how to move RN.WebView out of the RN "core" into an extension but maintain compatibility through the use of an npm post-install script that links the native extension into your iOS and Android projects. This doesn't solve every edge case, but it would ease the pain.
That would certainly be a step up from completely jettisoning the component to third parties. I wonder if their stance will change after extracting it from core. It seems like they are not open to community contributions at the moment for WebView, in particular.
The best answer is that Facebook retains support for RN.WebView by changing the underlying implementation to WKWebView. If FB isn't willing to do this work, perhaps someone else is willing to submit a PR to RN.
Nice. It looks like we'll need to opt into the new implementation using useWebKit={true}. I assume that prop will have no effect on versions older than 0.57, so it's safe to add. The only other compatibility issues revolve around scalesPageToFit, which we can document as not supported on iOS with RN >= 0.57.
Activity
erictraut commentedon Jul 31, 2018
Thanks for bringing this to our attention.
One of the principles we've followed in ReactXP is that any components provided in the "core" of ReactXP must be supported within React Native and not require any add-ons. If an RN extension is required, we've opted to make a ReactXP extension so it's optional.
We've also tried hard to retain backward compatibility in ReactXP. This situation creates a conflict between these two principles.
The best answer is that Facebook retains support for RN.WebView by changing the underlying implementation to WKWebView. If FB isn't willing to do this work, perhaps someone else is willing to submit a PR to RN.
As a fallback, I think we'd either:
luisnaranjo733 commentedon Aug 1, 2018
Unfortunately, that's not the root problem right now. At first, Facebook basically said "we don't need this, if the community wants it the community is gonna have to build it". So people have started opening PRs, but now Facebook is blocking them by either not reviewing or not merging them after review (here is one example from November 2017 - this issue was raised at least back in 2015). In addition, hramos is telling people not to open PRs because Facebook is thinking about removing WebView from their core.
I should clarify though - Facebook is talking about ripping WebView out of their core code base and possibly putting it in the semi-official react-native-community repo.. It's super unclear how this will shake out and could impact what the best course of action will be.
I think both of these fallbacks you suggested are good ideas. I'm personally a fan of fallback #2. Mainly because AFAIK there is no precedent in ReactXP for shipping a component that isn't backed directly by react-native under the hood.
erictraut commentedon Aug 1, 2018
I've been chatting with one of the members of the Facebook RN team. He has some ideas for how to move RN.WebView out of the RN "core" into an extension but maintain compatibility through the use of an npm post-install script that links the native extension into your iOS and Android projects. This doesn't solve every edge case, but it would ease the pain.
luisnaranjo733 commentedon Aug 3, 2018
That would certainly be a step up from completely jettisoning the component to third parties. I wonder if their stance will change after extracting it from core. It seems like they are not open to community contributions at the moment for WebView, in particular.
DoctaCloak commentedon Aug 8, 2018
Are there any issues that newcomers to ReactXP can help out with? Eric Traut (@erictraut)
luisnaranjo733 commentedon Sep 7, 2018
Eric Traut (@erictraut) Looks like FB figured it out and this is coming in RN 0.57 :)
Once XP supports 0.57, this issue can be closed.
erictraut commentedon Sep 8, 2018
Nice. It looks like we'll need to opt into the new implementation using
useWebKit={true}. I assume that prop will have no effect on versions older than 0.57, so it's safe to add. The only other compatibility issues revolve aroundscalesPageToFit, which we can document as not supported on iOS with RN >= 0.57.erictraut commentedon Sep 8, 2018
Here's the fix for useWebKit: eb05735