Our policy has been we support the currently shipping iOS version, plus one back. This is because of device version testing complexities. It may work on older iOS versions if we code it with the right safeguards, but that is not guaranteed. When iOS 12 ships this fall, we would drop iOS 10 support (support as in testing for it, like I said it might still work).
We could do the custom scheme -- or just use the Oracle plugin since that bridges it to using NSURLConnection, which has no restrictions. This will work on any iOS version. I would opt for the easiest solution *for now* to get something out. Using cdvapp://index.html, will all future file:// references in that index.html file work, or still have the same restrictions? I'll have to do some tests (unless you know already?) Regarding the fallback, the point of this bridge plugin is that the switching is an active decision by the developer (a hard break) and is to aid in migrating completely to WKWebView. If we had an automatic fallback, it might be a crutch until its too late and UIWebView is gone and they are surprised since it was all working "behind the scenes". On Fri, Aug 3, 2018 at 1:22 AM Darryl Pogue <dvpdin...@gmail.com> wrote: > > On Sun, Jul 15, 2018 at 11:39 PM Shazron <shaz...@gmail.com> wrote: > > > > 4. XmlHttpRequests don't work, because of Cross-Origin Resource > > Sharing issue (CORS). There is a workaround plugin created by Oracle > > (UPL licensed, which is Apache-2.0 compatible). See > > https://issues.apache.org/jira/browse/CB-10143 > > This happens because we're using file:/// URLs, which are subject to > additional security restrictions in WKWebView. Every file is treated > as its own origin, so a page can't make an XHR request to something > like file:///etc/passwd, but that same feature also means it can't > make an XHR request to ./assets/whatever.js > > The encouraged solution to this is to implement a custom scheme using > WKURLSchemeHandler and handle serving the files from the filesystem > yourself. This means the entire app would be served from something > like cdvapp://index.html rather than a file:/// URL. > Unfortunately, that API was only added in iOS 11, and Cordova > currently supports as far back as iOS 9, and the next major will > probably still want to support iOS 10? > > If we have the ability to swap the webview at runtime, it might be > worth investigating whether it makes sense to add a custom scheme for > iOS 11+ and WKWebView, and provide a way to fallback to UIWebView for > iOS 10? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org