UIWebView Strategy for Cordova iOS #110

dpogue · 2019-09-03T23:55:27Z

Background: As of August 2019, Apple is now showing a deprecation warning when uploading apps to the App Store that include UIWebView-related code. As a result, all Cordova apps built for iOS receive this deprecation warning on upload.

We need to determine how Cordova as a project wants to proceed to solve this problem. There are pull requests already being opened that I'm quite concerned with end up breaking all existing Cordova apps, and I think we want to be more careful about that.

I've put together this document outlining some options for discussion.

NiklasMerz · 2019-09-04T06:31:33Z

I personally would vote for option 2 in case of cordova-ios and inappbrowser. It looks like this is the best compromise and backwards compatible way. App developers should have moved to WKWebView with the plugin for some time and this way the upgrade should be the easiest way.

We are still relying on IAB for some legacy sites embedded in the "new" app in Cordova. There are plans to get rid of them in the future but that may take a long time and could cause compatibility issues with old versions of our product.

That IAB is a bad practice should be made clear with advice how to use it, but I would argue that this is not a strong enough reason to drop it completely. But I must admit that SafariViewControler looks like the way to go in the far future.

NiklasMerz

Add this file to README?

janpio · 2019-09-04T07:28:46Z

proposals/UIWebView-strategy.md

+* Moving all apps over to WKWebView will result in data being lost (localStorage, indexedDB, etc.)
+* WKWebView does not support all the same features as UIWebView and has stricter security requirements, and **many existing Cordova iOS apps will not work if run in WKWebView** without changes
+* The current WKWebView plugin needs updates to use Scheme Handlers to avoid issues that require a local web server.
+* The InAppBrowser plugin also uses UIWebView. Moving to WKWebView would potentially lose some functionality.


InAppBrowser has supported WKWebview for quite some time via usewkwebview.

IAB with WKWebView basically works fine now except this issue apache/cordova-plugin-inappbrowser#492

IAB also needs to hide UIWebView behind a build flag, like some other plugins.

What about LocalStorage from HTML5? That stuff is used all over the place at least by many apps I've made with Cordova. We can always make a backend system to send XMLHttpRequests to store data, but LocalStorage is just so much faster for small apps.

If I want to help make LocalStorage a possibility, would cordova-ios be the project to try to contribute to, or try to figure out solutions here?

I am not sure if LocalStorage should be part of this discussion. LocalStorage should work in WKWebView just fine. The only problem is that switching from UIWebView to WKWebView makes your apps data inaccessible with the new webview. There are some solutions out there to migrate. But this is not a new problem since WKWebView has been around some time.

I don't know if this migration should be part of cordova-ios.

They can also use SafariViewController for inAppBrowser

Just to play devil's advocate here, on the topic of local storage...

There are some plugins out there that migrate local storage such as this one, but most of them will only migrate if the WkWebView storage containers are empty (otherwise they run into a question of "should they overwrite?").

If one would update cordova-ios and thus migrate to the wkwebview without the use of this plugin, they may not realise that they lost data, and by that time it's too late to use a migration plugin. To save headaches for developers, maybe we should incorporate of these plugins directly into cordova-ios.

But on the other side, we could just simply tell users to consider using one of those plugins so that we don't have to maintain an one-time use code for an entire major version lifetime.

Personally I think I'm still on the "not cordova's problem" side...

janpio · 2019-09-04T07:30:29Z

proposals/UIWebView-strategy.md

+* WKWebView does not support all the same features as UIWebView and has stricter security requirements, and **many existing Cordova iOS apps will not work if run in WKWebView** without changes
+* The current WKWebView plugin needs updates to use Scheme Handlers to avoid issues that require a local web server.
+* The InAppBrowser plugin also uses UIWebView. Moving to WKWebView would potentially lose some functionality.
+    * Ideally, the InAppBrowser should be deprecated in favour of SFSafariViewController which severely restricts functionality in the name of security. Currently InAppBrowser use could largely be considered bad practice.


Very much different use case and functionality, also not related to UIWebView<->WKWebView. This should not be part of this discussion.

Very much different use case and functionality, also not related to UIWebView<->WKWebView. This should not be part of this discussion.

Agreed, but I also feel that deprecating IAB is in line with "the goal of [Cordova] is to cease to exist" now that there are platform-supported better options.
I'll drop this point from the discussion.

It's definitely a better option for what IAB was originally created, safe web browsing.
But as security is its strong suit, it's not as feature rich as IAB, all code/css injection, events, etc. that people relies on nowadays is not possible, so we can't deprecate it.

I agree. I have to maintain some pages which rely on that for some time. If you want your pages in IAB tightly integrated to your app you need this script injection stuff. Deprecating it should be the last resort, since it works fine now if you know what you are doing and use it in a responsible way. So security is not really a point.

the 'code/css injection' was always controversial, I was always against it as I wanted it to be a separate sandbox.
Pushing this off to wkwv is probably fine, and making a firm recommendation of SFSafariViewController when apps just need static pages, and/or oauth.

janpio · 2019-09-04T07:31:33Z

proposals/UIWebView-strategy.md

+
+The steps are roughly:
+
+1. Move the existing WKWebView plugin into cordova-ios.


Interesting to note: There are multiple, different WKWebView plugins out in the ecosystem. Just integrating the Cordova one would probably break all those.

janpio · 2019-09-04T07:36:36Z

I think https://github.com/ionic-team/cordova-plugin-ionic-webview is the elephant in the room - how does this very popular plugin fit in here?

https://npm-stat.com/charts.html?package=cordova-plugin-ionic-webview&package=cordova-plugin-wkwebview-engine&from=2018-09-03&to=2019-09-03

NiklasMerz · 2019-09-04T07:42:27Z

I think https://github.com/ionic-team/cordova-plugin-ionic-webview is the elephant in the room - how does this very popular plugin fit in here?

https://npm-stat.com/charts.html?package=cordova-plugin-ionic-webview&package=cordova-plugin-wkwebview-engine&from=2018-09-03&to=2019-09-03

Like said in the document the apache wkwebview engine needs to implement Scheme handlers. Scheme handlers in the ionic plugin make CORS and URL navigation easier, thats probably why it is the more popular choice apart being the default in new Ionic apps.

janpio · 2019-09-04T07:45:42Z

Possibly true, but not my point.

Should/Could this much more popular plugin be integrated? How can this plugin keep existing after Cordova iOS switched over to WKWebView (all those current users of it need a migration path)? What other side effects are there because of this situation of multiple plugins being there?

Ionic should be an active part of this discussion.

NiklasMerz · 2019-09-04T07:47:16Z

Good point. @jcesarmobile is probably the right person to ask.

jcesarmobile · 2019-09-04T10:07:24Z

Bringing a previous discussion link where we agreed to rename the cordova-plugin-wkwebview-engine classes on cordova-ios integration so it doesn't break existing WKWebView plugins that started as a fork (probably all of them), and keep the plugable webviews so people can still use different plugins from the default.
https://markmail.org/message/fxe6q6nnernvr6h6.

The problem with Scheme handlers is they are iOS 11+, so we should deprecate iOS 10. We can probably fallback to file urls on iOS 10, but I think having different behaviours is worse for the users.

We have 2 PRs at the moment:
first one add a preference that enables the compiler definition to disable UIWebView if desired. I think this is a third option, similar to the option 2, but as long as we don't disable it by default, we can release this as a minor release as it's a new feature and not a breaking change. With this in place it should be easier to transition to option 2 in a major version where we change the default from UIWebView to WKWebView. This also "unlock" people that are not using UIWebView but still get the warning.

The second PR claims that the previous one didn't work for him and still got the warning. This one is for 1, removing UIWebView entirely, but doesn't rename the classes, so other plugins will collide and fail to install. Also doesn't have url scheme handlers as it's a direct port of current plugin.

So I personally like more the first one, but we should check if we still get the warning and try to figure out why to properly fix it.

About integrating the Ionic one, it has a little Ionic Appflow code that I don't think fits into cordova-ios, so better keep them separate. But I can give a hand with the scheme handlers as I implemented it on the ionic one. But as I said, that would mean deprecating iOS 10.

timbru31 · 2019-09-04T10:32:06Z

I think ionic-team/cordova-plugin-ionic-webview is the elephant in the room - how does this very popular plugin fit in here?

Ionic should be an active part of this discussion.

I totally agree with you Jan!
How about the folks over at @ionic-team give something back to the Cordova community by contributing their cordova-plugin-ionic-webview fork back to the (orignal) cordova-plugin-wkwebview-engine since the fork already has been migrated to handle, e.g., the scheme handler for iOS 11+? IMHO this would help the Cordova project to tackle this big hurdle much faster.

Regarding the proposed options from Darryl, I would favor the "hard removal" options. We are very limited in regards of the development capacity and removing old, legacy, and deprecated code instead of maintaining both of them makes things easier.

NiklasMerz · 2019-09-04T10:34:44Z

Just another thought. I don't know if it makes sense or is technically possible.

Move UIWebView to a plugin as well and make cordova-ios use this or some of the WKWebView plugins. cordova-ios just contains the code to load a webview. By default the next version should load the Apache WKWebViewEngine (Plugin installed by default on new apps, Migration instruction for old apps). Users who need UIWebView, the Ionic one, a fork or others can specify their own one like it is now.

That way no UIWebView would be in cordova-ios and it would still be flexible enough like today.

jcesarmobile · 2019-09-04T10:58:33Z

That could work too, but it's a breaking change as they will need to install a webview plugin, and probably more work to move the UIWebView code into a separate plugin that will be short lived.

dpogue · 2019-09-04T14:48:34Z

The problem with Scheme handlers is they are iOS 11+, so we should deprecate iOS 10.

This seems fine to me, but should probably be brought to the list for discussion. iOS 13 is rolling out soon, and Apple traditionally only supports the two most recent iOS versions.

we can release this as a minor release as it's a new feature and not a breaking change.

I feel pretty strongly that we should not be making any of these changes in a minor version bump.

keep the plugable webviews so people can still use different plugins from the default.

We will definitely be keeping the pluggable webview support, so it should be possible for people to keep using other webview plugins.

we agreed to rename the cordova-plugin-wkwebview-engine classes on cordova-ios integration so it doesn't break existing WKWebView plugins that started as a fork

Thank you for reminding me of this. I'll update the document to make it clear that we need to rename classes when we integrate.

jcesarmobile · 2019-09-04T17:41:47Z

This seems fine to me, but should probably be brought to the list for discussion. iOS 13 is rolling out soon, and Apple traditionally only supports the two most recent iOS versions.

We unofficially also only support the last 2 versions, but we have been slow at removing them and if we do it fast people complain.

I feel pretty strongly that we should not be making any of these changes in a minor version bump.

If you see the first PR is pretty "simple". If you don't have the preference it will behave the same way it behaves at the moment, if you have the preference it will switch a few lines in compile time. I think that can safely go into a minor release and give us more time for a complete integration in next major release.

We will definitely be keeping the pluggable webview support, so it should be possible for people to keep using other webview plugins.
Thank you for reminding me of this. I'll update the document to make it clear that we need to rename classes when we integrate.

Related to the first point too. As we are integrating the WKWebView plugin renaming the classes, adding the scheme handlers and keeping the plugable webviews, in worst case, people can manually change deployment target to iOS 10 and still use the current cordova-plugin-wkwebview-engine that uses file instead of the scheme handlers.

bpresles · 2019-09-04T21:10:23Z

After reading this discussion, I found a good idea to rename classes of embedded WKWebView engine so that they don't conflict with existing engine plugins.

So the PR 663 (apache/cordova-ios#663) includes that change. I've tested it with stock v4.1.1 of cordova-plugin-ionic-webview and it's working just fine without any modification.

Also I created a UIWebView plugin based on current default UIWebView engine in cordova-ios (https://github.com/bpresles/cordova-plugin-uiwebview-engine) and published a first release : https://www.npmjs.com/package/cordova-plugin-uiwebview-engine
The funny thing is that this UIWebView engine can be used even on current and previous releases of cordova-ios (even though it's plain useless ;) ) as I took care to rename the classes ;)

bryyyanribo · 2019-09-05T06:30:03Z

@bpresles, What do you think is the best approach to this problem?

Should I Install this Cordova plugin for me to temporarily fix the issue regarding UIWebView?

NiklasMerz · 2019-09-05T06:38:10Z

proposals/UIWebView-strategy.md

+4. Add warnings to cordova-ios for apps that are using the UIWebView preference.
+5. Wrap all the UIWebView code behind a compiler definition that can be controlled by a preference, to allow disabling all the UIWebView code.
+6. [Next Major] Disable the UIWebView code by default, but allow it to be enabled by the preference for apps that require it.
+


I would add "Move UIWebView to plugin" as an option to this document, too. Here a first draft based on comments on this PR.

Suggested change

### 3 . Move UIWebView to a plugin and remove it from Cordova-ios

Move UIWebView to a plugin as well and make cordova-ios use this or some of the WKWebView plugins. cordova-ios just contains the code to load a webview. By default the next version of Cordova-ios should load the Apache WKWebViewEngine (Plugin installed by default on new apps, Migration instruction for old apps). Users who need UIWebView, the Ionic one, a fork or others can specify their own one like it is now.

There is already a proof-of-concept version of this done: https://github.com/bpresles/cordova-plugin-uiwebview-engine with https://github.com/apache/cordova-discuss/pull/110#issuecomment-528088573

This is a breaking change since existing apps need to install that plugin and creates work for a plugin that is probably short lived. InAppBrowser needs some work to get this working.

bpresles · 2019-09-06T13:18:27Z

@bpresles, What do you think is the best approach to this problem?

Should I Install this Cordova plugin for me to temporarily fix the issue regarding UIWebView?

Adding a WKWebView engine plugin won't remove the warning with current cordova-ios version as it still embed the UIWebView based engine even if you install a WKWebView engine plugin` that replaces it at execution time.

But yes, that's a good idea that you install a WKWebView engine plugin in your project to prepare it for the future, because you may (will?) have to adapt some part of your code to make it compatible with WKWebView, and so doing it the sooner possible makes sure that your app code is already prepared for when Apple will reject apps with UIWebView and so for future version of cordova-ios that will stop using UIWebView.

manish2535 · 2019-09-12T03:30:30Z

Any updates on this guys?

abdel-ships-it · 2019-09-12T14:42:43Z

I am personally for option one, sooner or later people will have to get rid of UIWebView We will be either not able to upload apps to the app store, or transition to WKWebView incase we want to upgrade cordova-ios. The latter seems more logical to me.

rajashekaranugu · 2019-09-12T20:38:01Z

Hi guys, I have also received same warning email from apple. currently am using ionic 4.5.0 and cordova 8.1.2 to build my iOS APP where we are using both inAppBrowser (3.1.0) and ionicWebView(4.1.1).

Really appreciate your time if some one can help me with below questions {{currently we are holding on a release }}

1. do we have any specific time that iOS will stop accepting the apps with UIWebView.?
1. instead of using in-app-browser can we use safari-view-controller ?
1. if I release my app with above specifications (with out any changes) how long my app will be supported ?
1. any solution for this so far?

breautek · 2019-09-12T20:54:36Z

@rajashekaranugu I'd prefer to keep comments on this ticket relating to discussing the solution of this issue instead of providing support but I'll quickly answer what I can below. If you have further questions, please read through apache/cordova-ios#661 and comment there, or create a new issue under cordova-ios repo.

do we have any specific time that iOS will stop accepting the apps with UIWebView.?

Apple has not provided any dates, so we don't know.

if I release my app with above specifications (with out any changes) how long my app will be supported ?

Due to the first question, again we don't know.

any solution for this so far?

There is no official solution. That is what this ticket is for, discussing how Cordova should proceed further. There are some PR proposals (apache/cordova-ios#663 & apache/cordova-ios#662) but they are likely introducing breaking changes and may not actually follow what Cordova thinks is the best way moving forward so no guarantee that they will be merged in or be a long term solution.

Again, if you have other questions, please use apache/cordova-ios#661 or create a new issue in the cordova-ios repo.

And of course, you are welcome to read through this discussion and provide your thoughts on how Cordova should move forward.

EdwinRozario · 2019-09-12T22:24:22Z

Ionic devs please also take a look at blog post. Ionic team might be able to provide some support while the cordova team is working on the fix.

derman10 · 2019-09-12T23:25:10Z

Ionic devs please also take a look at blog post. Ionic team might be able to provide some support while the cordova team is working on the fix.

thanks for sharing!!

ASHBAW · 2019-12-05T20:47:23Z

How do you verify that you have eliminated all instances of UIWebView?

My Ionic 4 project use the following plugins

 "cordova-ios": "^5.1.1",
 "cordova-plugin-ionic-webview": "^4.1.3",
 "cordova-plugin-inappbrowser": "git+https://github.com/kleeb/cordova-plugin-inappbrowser.git"

I have also added
<preference name="WKWebViewOnly" value="true" />
to my config.xml

I build from from the command line and then open of the project in Xcode. If I search for UIWebView I still see instances in a number of .m files.

If I unzip the generated .ipa file and grep through (grep -lr "UIWebView" *) the following is returned: MyApp.app/MyApp

So I am not quite sure what else I need to do?

Any insight would be greatly appreciated.

breautek · 2019-12-05T20:51:41Z

@ASHBAW

Do note that the WKWebViewOnly preference only applies to the cordova-ios package and does not apply to plugins. (Unless if they have been updated to read and respond to that preference of course)

I'm unfamiliar with that fork but Apache's inappbrowser is a plugin that still references UIWebView and does not respond to the WKWebViewOnly preference.

beevelop · 2019-12-05T21:01:11Z

@breautek Yep, we experienced the very same issue with the inappbrowser plugin. I tried tackling it with PR apache/cordova-plugin-inappbrowser#584 already.

The compile-flag solution might be quite useful for other plugin maintainers too. Is there a suitable place in the Cordova docs to note this down?

breautek · 2019-12-05T21:06:35Z

Is there a suitable place in the Cordova docs to note this down?

The flag should be added to https://github.com/apache/cordova-docs/blob/master/www/docs/en/dev/config_ref/index.md#preference imo. Not sure if there is an existing PR for this.

ASHBAW · 2019-12-05T21:07:19Z

The fork came from this thread
[apache/cordova-plugin-inappbrowser/issues/583]
where @kleeb removed UIWebView code for the inappbrowser plugin
Without it my build failed as described in 583

ASHBAW · 2019-12-06T15:56:42Z

Just a quick question. I use Ionic 4 which uses the cordova-plugin-ionic-webview by default.

I performed the following steps:

Created an empty started project
Installed cordova-ios@5.1.1
Add to my config.xml file.
Ran cordova prepare ios to apply the changes
Built a production version on the command line
Opened up project in Xcode

If I search the Xcode project I still see 117 references to UIWebView in 20 different files.

Should I still be seeing references to UIWebView at this point?

If I build and .ipa file and unzip it (i.e. change .ipa to .zip and unzip) followed by doing a grep through the Payload folder it returns that the app has references to UIWebView:

grep -lr "UIWebView" *
MyApp.app/MyApp

I am thinking I should not have any references at this point?

jcesarmobile · 2019-12-06T16:01:46Z

Yes, it won't remove the code, so you'll see the references if you search in Xcode. But as it's behind a build flag, Apple won't complain about it.

ASHBAW · 2019-12-06T16:03:56Z

Got it thank you.

l3ender · 2019-12-24T04:32:05Z

The App Store will no longer accept new apps using UIWebView as of April 2020 and app updates using UIWebView as of December 2020.

https://developer.apple.com/news/?id=12232019b

orbitaloop · 2020-01-10T08:25:44Z

Hi, so I wonder what's the official Cordova solution to this?
thanks

jcesarmobile · 2020-01-10T08:58:52Z

Solution to what? Did you read the thread?

ragcsalo · 2020-01-10T09:18:35Z

I also haven't seen the solution yet in the thread. Using Cordova with PhoneGap Build (and not ionic). Will there be a new Cordova version sometimes that would solve this, or do we have to use the WKWebView plugin and re-write our code completely to be compatible? If there is already a solution in this thread, would you please link it? :-)

breautek · 2020-01-10T13:32:11Z

also haven't seen the solution yet in the thread.

The current solution, which is available in cordova-ios@5.1.1 & if you're using the inappbrowser, cordova-plugin-inappbrowser@3.2.0 makes use of a flag to hide the UIWebView references behind a compile-time flag. This with a WkWebView plugin, either cordova official plugin, or ionic's webview plugin (ionic webview can be used without using the ionic framework), is a current day solution to Apple's deprecation notice.

cordova-ios@6 (which is a work in progress) will completely remove the UIWebView code and essentially make the WkWebView the default webview, eliminating the need to use a wkwebview plugin.

or do we have to use the WKWebView plugin and re-write our code completely to be compatible

Regardless due to the reasons above, you're going to have to move away from the UIWebView, and migrate to WkWebView eventually. No way around that. Even if you're writing a pure native ios app, depending on the features you use, this might be breaking changes for your app. To name a couple, if you use web storage, migrating webviews does not bring over web storage to the new webview. WkWebView enforces CORS, so that may require backend changes if you make any requests to a server to be CORS compatible. For the web storage issue, there are some plugins to help migrate web storage such as this one (not an endorsement, never actually used this plugin).

If there is already a solution in this thread, would you please link it? :-)

apache/cordova-ios#715

ragcsalo · 2020-01-10T13:34:35Z

Many-many thanks!!!!! :-)

HansKrywalsky · 2020-01-10T13:39:15Z

The current solution, which is available in cordova-ios@5.1.1 & if you're using the inappbrowser, cordova-plugin-inappbrowser@3.2.0 makes use of a flag to hide the UIWebView references behind a compile-time flag. This with a WkWebView plugin, either cordova official plugin, or ionic's webview plugin (ionic webview can be used without using the ionic framework), is a current day solution to Apple's deprecation notice.

cordova-ios@6 (which is a work in progress) will completely remove the UIWebView code and essentially make the WkWebView the default webview, eliminating the need to use a wkwebview plugin.

apache/cordova-ios#715

I'm going to develop a complete new App for IOS. Will i have any Problems migrating from cordova-ios@5.1.1 to 6.0.0? Regarding Storage lost, etc.?

breautek · 2020-01-10T13:50:36Z

I'm going to develop a complete new App for IOS. Will i have any Problems migrating from cordova-ios@5.1.1 to 6.0.0? Regarding Storage lost, etc.?

~~If you're developing a brand new app, you wouldn't have any data stored for your users in the first place.~~ But if you make ajax requests to remote server, CORS could still be an issue, that is an entirely a backend thing though. If you're unfamiliar with cors, I suggest you read more on it at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

breautek · 2020-01-10T13:59:05Z

Sorry I misread your question. web storage issues happens when you change webviews, so going from UIWebView to the WKWebview.

So if you're already on WKWebView using a plugin, on cordova-ios@5.1.1, upgrading to 6.0.0 ~~shouldn't cause any storage migration issues.~~ If WKUrlSchemeHandlers is implemented that can cause data lost.

If you're not using any wkwebview plugins, and you upgrade from 5.1.1 to 6.0, then you definitely will.

Web storage is definitely faster than using the filesystem, but I would consider using the cordova-plugin-file and store flatfiles instead. Using flatfiles will avoid headaches, should Apple ever decide to make and force another webview change in the future. And using the filesystem has virtually no limits in regards to space consumption, as long as the device has free disk space.

jcesarmobile · 2020-01-10T15:10:38Z

So if you're already on WKWebView using a plugin, on cordova-ios@5.1.1, upgrading to 6.0.0 shouldn't cause any storage migration issues.

well, it really depends, if we implement the WKUrlSchemeHandlers as proposed here, the app won't be served from file, but from a new custom scheme and data will be lost.

HansKrywalsky · 2020-01-10T19:45:01Z

@jcesarmobile So what so you prefer? Wait for 6.0.0? When is it going to be released?

ragcsalo · 2020-02-27T00:23:34Z

There are already nightly builds of 6.0.0 :-)
Also release 5.1.1 provides a preprocessor directive that allows apps to “compile out” UIWebView code.

Are there any tutorials on migrating to WKWebView?

thealiano · 2020-03-12T12:52:13Z

Any updates for the 6.0.0 ?

ragcsalo · 2020-03-16T23:21:39Z

2 weeks left... I hope there will be an easy and quick solution to migrate existing apps to WKWebView 🤔

NiklasMerz · 2020-03-18T09:35:53Z

We just published a blog post with steps to take now and a note about the future roadmap.

https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html

I am locking this now since the plan is clear and to avoid more questions on this thread. Other committers can still comment and open this again if needed.

erisu · 2020-07-03T08:16:25Z

As we have completed the removal of UIWebView from the iOS platform, I think we can either close or merge this PR.

I believe most proposals are usually merged before the task is started or completed.

Add proposal for UIWebView migration strategies

d29133b

NiklasMerz reviewed Sep 4, 2019

View reviewed changes

janpio reviewed Sep 4, 2019

View reviewed changes

bpresles mentioned this pull request Sep 4, 2019

Remove all UIWebView code? apache/cordova-ios#661

Closed

jcesarmobile mentioned this pull request Sep 4, 2019

ITMS-90809: Deprecated API Usage ionic-team/cordova-plugin-ionic-webview#431

Closed

NiklasMerz reviewed Sep 5, 2019

View reviewed changes

timbru31 mentioned this pull request Sep 9, 2019

Fix #661: Removed all UIWebView code. apache/cordova-ios#663

Closed

5 tasks

timbru31 mentioned this pull request Sep 16, 2019

Depreciated API error from Apple apache/cordova-plugin-inappbrowser#532

Closed

breautek mentioned this pull request Dec 2, 2019

cordova-plugin-inappbrowser does not work with latest cordova-ios 5.1.0. build fails with error "Unknown type name 'CDVUIWebViewDelegate'" apache/cordova-plugin-inappbrowser#587

Closed

ASHBAW mentioned this pull request Dec 10, 2019

iOS - build fails if using "WKWebViewOnly" preference apache/cordova-plugin-inappbrowser#583

Closed

3 tasks

jcesarmobile mentioned this pull request Feb 18, 2020

breaking: Use WKURLSchemeHandler for serving app content apache/cordova-ios#781

Merged

apache locked as resolved and limited conversation to collaborators Mar 18, 2020

purplecabbage merged commit 5318d97 into apache:master Jul 3, 2020

dpogue deleted the uiwebview-plan branch August 25, 2024 07:24


		The steps are roughly:

		1. Move the existing WKWebView plugin into cordova-ios.

+### 3 . Move UIWebView to a plugin and remove it from Cordova-ios
+Move UIWebView to a plugin as well and make cordova-ios use this or some of the WKWebView plugins. cordova-ios just contains the code to load a webview. By default the next version of Cordova-ios should load the Apache WKWebViewEngine (Plugin installed by default on new apps, Migration instruction for old apps). Users who need UIWebView, the Ionic one, a fork or others can specify their own one like it is now.
+There is already a proof-of-concept version of this done: https://github.com/bpresles/cordova-plugin-uiwebview-engine with https://github.com/apache/cordova-discuss/pull/110#issuecomment-528088573
+This is a breaking change since existing apps need to install that plugin and creates work for a plugin that is probably short lived. InAppBrowser needs some work to get this working.

UIWebView Strategy for Cordova iOS #110

UIWebView Strategy for Cordova iOS #110

Conversation

dpogue commented Sep 3, 2019

NiklasMerz commented Sep 4, 2019

NiklasMerz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janpio Sep 4, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janpio commented Sep 4, 2019

NiklasMerz commented Sep 4, 2019 • edited Loading

janpio commented Sep 4, 2019 • edited Loading

NiklasMerz commented Sep 4, 2019

jcesarmobile commented Sep 4, 2019

timbru31 commented Sep 4, 2019

NiklasMerz commented Sep 4, 2019 • edited Loading

jcesarmobile commented Sep 4, 2019

dpogue commented Sep 4, 2019

jcesarmobile commented Sep 4, 2019

bpresles commented Sep 4, 2019 • edited Loading

bryyyanribo commented Sep 5, 2019 • edited Loading

NiklasMerz Sep 5, 2019 • edited Loading

Choose a reason for hiding this comment

bpresles commented Sep 6, 2019 • edited Loading

manish2535 commented Sep 12, 2019

abdel-ships-it commented Sep 12, 2019

rajashekaranugu commented Sep 12, 2019 • edited Loading

breautek commented Sep 12, 2019

EdwinRozario commented Sep 12, 2019

derman10 commented Sep 12, 2019

ASHBAW commented Dec 5, 2019

breautek commented Dec 5, 2019 • edited Loading

beevelop commented Dec 5, 2019

breautek commented Dec 5, 2019

ASHBAW commented Dec 5, 2019

ASHBAW commented Dec 6, 2019

jcesarmobile commented Dec 6, 2019

ASHBAW commented Dec 6, 2019

l3ender commented Dec 24, 2019

orbitaloop commented Jan 10, 2020

jcesarmobile commented Jan 10, 2020

ragcsalo commented Jan 10, 2020 • edited Loading

breautek commented Jan 10, 2020

ragcsalo commented Jan 10, 2020

HansKrywalsky commented Jan 10, 2020

breautek commented Jan 10, 2020 • edited Loading

breautek commented Jan 10, 2020 • edited Loading

jcesarmobile commented Jan 10, 2020

HansKrywalsky commented Jan 10, 2020

ragcsalo commented Feb 27, 2020

thealiano commented Mar 12, 2020

ragcsalo commented Mar 16, 2020

NiklasMerz commented Mar 18, 2020

erisu commented Jul 3, 2020

janpio Sep 4, 2019 •

edited

Loading

NiklasMerz commented Sep 4, 2019 •

edited

Loading

janpio commented Sep 4, 2019 •

edited

Loading

NiklasMerz commented Sep 4, 2019 •

edited

Loading

bpresles commented Sep 4, 2019 •

edited

Loading

bryyyanribo commented Sep 5, 2019 •

edited

Loading

NiklasMerz Sep 5, 2019 •

edited

Loading

bpresles commented Sep 6, 2019 •

edited

Loading

rajashekaranugu commented Sep 12, 2019 •

edited

Loading

breautek commented Dec 5, 2019 •

edited

Loading

ragcsalo commented Jan 10, 2020 •

edited

Loading

breautek commented Jan 10, 2020 •

edited

Loading

breautek commented Jan 10, 2020 •

edited

Loading