UIWebView Strategy for Cordova iOS #110
Conversation
|
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. |
| * 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. |
There was a problem hiding this comment.
InAppBrowser has supported WKWebview for quite some time via usewkwebview.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
They can also use SafariViewController for inAppBrowser
There was a problem hiding this comment.
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...
| * 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. |
There was a problem hiding this comment.
Very much different use case and functionality, also not related to UIWebView<->WKWebView. This should not be part of this discussion.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
|
||
| The steps are roughly: | ||
|
|
||
| 1. Move the existing WKWebView plugin into cordova-ios. |
There was a problem hiding this comment.
Interesting to note: There are multiple, different WKWebView plugins out in the ecosystem. Just integrating the Cordova one would probably break all those.
|
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? |
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. |
|
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. |
|
Good point. @jcesarmobile is probably the right person to ask. |
|
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. 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: 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. |
I totally agree with you Jan! 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. |
|
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. |
|
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. |
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.
I feel pretty strongly that we should not be making any of these changes in a minor version bump.
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. |
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.
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.
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. |
|
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 Also I created a |
| 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. | ||
|
|
There was a problem hiding this comment.
I would add "Move UIWebView to plugin" as an option to this document, too. Here a first draft based on comments on this PR.
| ### 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. |
Adding a But yes, that's a good idea that you install a |
|
Any updates on this guys? |
|
I am personally for option one, sooner or later people will have to get rid of |
|
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 }}
|
|
@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
Apple has not provided any dates, so we don't know.
Due to the first question, again we don't know.
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. |
|
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!! |
|
How do you verify that you have eliminated all instances of UIWebView? My Ionic 4 project use the following plugins I have also added 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. |
|
Do note that the I'm unfamiliar with that fork but Apache's |
|
@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? |
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. |
|
The fork came from this thread |
|
Just a quick question. I use Ionic 4 which uses the cordova-plugin-ionic-webview by default. I performed the following steps:
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:
I am thinking I should not have any references at this point? |
|
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. |
|
Got it thank you. |
|
|
Hi, so I wonder what's the official Cordova solution to this? |
|
Solution to what? Did you read the thread? |
|
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? :-) |
The current solution, which is available in
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).
|
|
Many-many thanks!!!!! :-) |
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.? |
|
|
Sorry I misread your question. web storage issues happens when you change webviews, so going from So if you're already on 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 |
well, it really depends, if we implement the |
|
@jcesarmobile So what so you prefer? Wait for 6.0.0? When is it going to be released? |
|
There are already nightly builds of 6.0.0 :-) Are there any tutorials on migrating to WKWebView? |
|
Any updates for the 6.0.0 ? |
|
2 weeks left... I hope there will be an easy and quick solution to migrate existing apps to WKWebView 🤔 |
|
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. |
|
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. |
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.