Research Supporting WKWebView on iOS11

[Sdaswani]

We would still support UIWebview on iOS10.

Research should include:

• What's required on the engineering side?
• What do we gain?
• How can we compare performance?

[boek]

Add support for WKWebView

Summary

Currently Focus uses UIWebView to display web pages. With iOS 11 Apple gives us the ability to use WKWebView with our content blocker.

Pros

Performance

WKWebView is reported to be 3-4x faster. This will make Focus noticeably faster on nearly every device running iOS 11.

iOS Integration

The APIs available for WKWebView are significantly better. Like supporting 3D Touch, Drag and drop, etc...

More code re-use

Firefox on iOS uses WKWebView. Which means we can start sharing more code between the two applications.

Architecture improvements

As we add more tent pole type features some areas of our codebase are starting to bloat. Improving this will increase our engineering / debugging throughput as well as having a more approachable code base for open source contributions.

Cons

Supporting multiple Web Views

We will have to build an architecture to support multiple WebViews that can allow us to share as much code between the two as possible. Even with this architecture there will be features like Save images inside web pages that will need a little customization for both implementations. This will add to the development time for these.

QA

Just as engineering will have an overhead of supporting multiple WebViews. This will probably impact QA as well.

Effort

Everything together would be an XL . Though I don’t recommend we bite it all off at once.

We can incrementally get there by improving the architecture of our current implementation over time.

Conclusion

With how fast iOS 10 was adopted we can probably assume iOS 11 will follow a similar trajectory. This change will probably have the biggest impact to our users as they upgrade to iOS 11 in terms of performance.

[Sdaswani]

Thanks for this @boek - very helpful. I think moving to WKWebView is something we should do, but in the following fashion:

• Plan to release it early next year (earlier if we see iOS11 tending towards 50% iOS market share).
• At release, iOS10 uses UIWebView, and iOS11 uses WKWebView.
• At release, we build feature parity between UIWebView and WKWebView.
• After release, all new features are on WKWebView.

cc @antlam

@boek thoughts?

@bbinto your thoughts / decision?

[bbinto]

Thanks @boek & @Sdaswani. We all agree that we should move to WKWebview.

The only questions are when, and what happens to existing UIWebView users with <iOS 11.

When:

Plan to release it early next year (earlier if we see iOS11 tending towards 50% iOS market share). Agreed, with all existing and new features on WKWebView only.

Support:

After release, all new features are on WKWebView.

• I'm not the eng manager, but if I understand this correctly we would we still have to "maintain" the UIWebView code case and its features. If so, I'd like you all to have as little legacy code as possible to maintain, so I'm wondering, once we know there is only a small amount of users left on < iOS 11 for Focus, discontinue support for iOS 10 and only push out Focus with WKWebview (feature parity to UIWebView version).

The difficult thing is to set a date to start working towards feature parity for UIWebview & WKWebview while not feature freezing for too long. If we knew e.g. it would take us 1 month to get the app to use WKWebview (only), we'd try to not include any new big features during that time. Maybe have 1 month intensive UX research on specific topics.

The later we start the transition, the more work it will become.

Makes sense?

[Sdaswani]

Sorry @bbinto I may have confused matters a bit when I said 'new features on WKWebView only'. That doesn't mean all new features, necessary - only the ones where we have to interact with the WebView. For example, Save/Copy Image interacts with the WebView, but Onboarding or Tracking Protection may not. So we would maybe spend 1 month build out WKWebView support, and any new feature would hopefully not utilize the WebView, so there is no divide between UIWebView and WKWebView.

Also @boek one big thing to think about - can we do the 'Trackers Blocked' functionality with WKWebView? Meaning if we just hand of control to Apple via their Content Blocking API, can we still say '10 trackers blocked'? I will check with the Firefox team.

[Sdaswani]

Number of trackers blocked not possible with WKWebView!

[boek]

It looks like WKWebView supports https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API

We could potentially use this to get the URLs and the time the browser spent downloading them to get the same information as the URLProtocol method used with UIWebView

Here is a little example of measuring the difference between content blocking enabled / disabled.

[Sdaswani]

@boek but does this we have to do both loads - with content blocking on and off - to get a comparison?

[boek]

@Sdaswani no, those APIs give us quite a bit. I think I can get all the requests where the duration was 0 and then match the URLs against the content blocker lists to get a breakdown of what was blocked.

[Sdaswani]

OK, spend some time researching this, but maybe after Ebony, as we have a long list of items to work on for the Ebony release.