Forum Xamarin.Forms

WebViewRenderer on iOS should to be upgraded to WKWebView from UIWebView as of iOS 8.0

Shane000Shane000 USMember ✭✭✭
edited February 2017 in Xamarin.Forms

WebViewRenderer on iOS should to be upgraded to WKWebView from UIWebView as of iOS 8.0

https://developer.apple.com/reference/webkit/wkwebview

Important
Starting in iOS 8.0 and OS X 10.10, use WKWebView to add web content to your app. Do not use UIWebView or WebView.
Tagged:

Open · Last Updated

Posts

  • Shane000Shane000 USMember ✭✭✭

    Specifically when changing from UIWebView to WKWebView you need to change the delegate handlers to map the new versions listed here:

    http://stackoverflow.com/a/26134994/548975

    Maybe I'll make a pull request when things settle down.

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    I am not sure if I am remembering correctly, but didn't Xamarin Forms also change its min support to iOS 8. Which if this is the case, I am all for moving to WKWebView. Some neat performance and support improvements in the newer version.

  • VelocityVelocity NZMember ✭✭✭

    @AdamP said:
    I am not sure if I am remembering correctly, but didn't Xamarin Forms also change its min support to iOS 8. Which if this is the case, I am all for moving to WKWebView. Some neat performance and support improvements in the newer version.

    Unless the documentation isn't up-to-date, Xamarin.Forms is still showing as compatible with iOS 6.1 and higher.

    You could target WKWebView from iOS8+ and keep UIWebView for iOS6/7 to maintain backward compatibility.

  • AdamPAdamP AUUniversity ✭✭✭✭✭

    @Velocity - it is at the moment. Where I actually saw it from was in the Feature Roadmap. 2.4.0 will deprecate iOS 6, however that still leaves iOS 7 :(

    Hence we would need to keep UIWebView for the moment for iOS7. Which isn't great because it has annoying bugs in it that are at the platform level, and I doubt that Apple will ever fix them, since its on the way out.

  • VictorHGarciaVictorHGarcia USUniversity ✭✭

    Why to continue supporting iOS 7? I think they need to drop that iOS version support since iPhone 4S last iOS 8.

  • rmarinhormarinho PTMember, Insider, Beta Xamurai

    We have discussed a little about this me and Jason, we need to keep the old renderer around, but we can create a new, if anyone wants to work in a new renderer based on WKWebView we can accept it.
    That said i don't know yet the best naming/way to go with this .

  • DavidDancyDavidDancy AUMember ✭✭✭✭

    @rmarinho Would this be a good opportunity to think about deprecating the attribute-based binding of renderers to Elements in favour of a DI container-based approach? The DI container could enable dynamic switching of renderers based on OS version, supported features, or anything else - and enable us to swap out "stock" renderers for our own implementations without having to subclass first. I personally see great benefits in having each Element's renderer just implement an interface that's specific to that renderer. My own implementation could extend the interface instead of inheriting from the original renderer. It could also vastly simplify the internal machinery that Forms uses to track which renderer is needed for which Element. Not to mention the potential startup time speedup that would result from filling the DI container from code instead of from a reflective scan of all the assemblies in the app. Forms could specify the DI container's features in terms of an interface as well, and thereby enable container independence.

  • eliseoazpeitiaeliseoazpeitia ARMember

    Hi, WKWebView support websql?

    Thanks

  • RyanDixonRyanDixon USMember ✭✭✭
    edited March 2017

    @eliseoazpeitia said:
    Hi, WKWebView support websql?

    Thanks

    Deprecated I believe! Many people are using IndexedDB instead but I'm not too sure how good Apples implementation of this is either :(

  • VelocityVelocity NZMember ✭✭✭

    @DavidDancy said:
    @rmarinho Would this be a good opportunity to think about deprecating the attribute-based binding of renderers to Elements in favour of a DI container-based approach? The DI container could enable dynamic switching of renderers based on OS version, supported features, or anything else - and enable us to swap out "stock" renderers for our own implementations without having to subclass first. I personally see great benefits in having each Element's renderer just implement an interface that's specific to that renderer. My own implementation could extend the interface instead of inheriting from the original renderer. It could also vastly simplify the internal machinery that Forms uses to track which renderer is needed for which Element. Not to mention the potential startup time speedup that would result from filling the DI container from code instead of from a reflective scan of all the assemblies in the app. Forms could specify the DI container's features in terms of an interface as well, and thereby enable container independence.

    Very interesting proposal David. Would you be interested to elaborate more in a seperate thread?

Sign In or Register to comment.