Feature requests for SFSafariViewController from Twitter, Inc

Originator:nobrien
Number:rdar://21349835 Date Originated:11-Jun-2015 04:42 PM
Status:Open Resolved:
Product:iOS SDK Product Version:9.0
Classification:Feature (New) Reproducible:Always
 
The trajectory of SFSafariViewController is really top notch and we have a strong desire at Twitter to move our Web View code from a custom controller wrapping WKWebView.   The web view is one of the most heavily traffic’d components in our application and if we get the requirements we need from a SFSafariViewController, there would be nothing stopping us from converting over (with the exception of still supporting iOS 7 and 8 of course).

Our team has enumerated all the code we have in our WebViewController and effectively 90% of the work we do is to reach parity with Safari, and is immediately taken care of by SFSafariViewController.  For that remaining 10%, we do have other work we do today that we would like to have built into SFSafariViewController.

Critical:
  - Observable loading behavior
     - Did the user wait for the complete load, did they navigate as things were loading, did they close as things were loading?
  - Observable requests and their timings
     - Optimally, a data structure with the W3C NavigationTiming would be the best
     - https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
     - Spoke with Engineer on CFNetwork team about this being exposed with NSURLSession as well and he was in favor

High Priority:
  - Ability to warm the SFSafariViewController before actually presenting it with a URL, URL request, HTML data or file on disk
    - Currently, are investing heavily into warming the shared URL cache for high priority Tweets so that if the user hits that Tweet we will open UIWebView (sadly not WKWebView) with that pre-cached web page.  If we could just warm an SFSafariViewController with the desired link, this would eliminate an enormous amount of effort on our end.

Lower Priority:
   - Observable data usage broken down by the navigation timing
     - Knowing our users’ data costs are critical because in many countries as bytes directly translate into monetary cost

The last place where we do a lot of work is w.r.t. handling specific URLs and URL schemes that should all (I would assume) work with the new seamless link support added to iOS 9.

Thanks for everything!
Nolan O’Brien,
Tech Lead - Twitter Dynamic App


[[[[[[[[[[[[[[[[[UPDATE 06/29/2015]]]]]]]]]]]]]]]]]]]]]

Clarification of what we would like to observe regarding SFSafariViewController. It appears that I may have been overly simplistic in my description which leaves room to misinterpret the intent of what we want to observe in the web page loading. I'll try to clarify that here:

- We really just care about the initial page load: subsequent navigations don't really matter. We really want to measure how often users are getting to the destination they are wanting to go to and measure what the bottlenecks are so that we can work to improve the experience.
- When getting the "completion status", we are looking to measure whether the user got to their destination or if they abandoned the attempt and to collect information as to why that would have failed. We'll use this metric to gauge which links/sites are performing poorly for users (but not tied to any specific user).
    - Complete: full page loaded (Green)
    - Navigate: page didn't fully load, but the user did choose to interact with the page (Yellow)
    - Cancel: user gave up waiting for the page to load (Red)
- When getting the request timing info, we only care about requests related to the initial load of the page.
    - The timing of each resource request including redirects, latencies and data used
    - The ordering of each resource request
    - Potentially the latency for loading the javascript for execution on the page (often a culprit of slowdown)
    - Data consumed by each resource request
    - We really don't care about the specific URLs loaded, mostly the types of resources
        - Was it the core HTML? Was it a redirect? Was it javascript? Was it CSS? Was it a large PNG or a small JPG?
        - If the URLs are provided, we would just categorize. If the URLs are not provided, but just the category of the resource, great!

The W3C NavigationTiming I brought up is just a well know standard that would provide this info usefully, it's not necessary though.

By having this kind of info, we will have greater insight into where we are failing users. We can determine how links load and what the issues that need to be resolved are.

With WKWebView/UIWebView we've been able to observe the HTTP redirects (and to an extent Meta-Data refreshes and javascript redirects) to observe that some of the slowest loading web pages have upwards of 12 redirects before finally loading the true URL (this takes multiple dozens of seconds in developing countries). We are already measuring the other timings for resource loads to in order to see if what we can do to improve user perceived latencies. Maintaining these measurements (or even improving them) will provide us the means to positively impact the user experience.

In no way do we track user behavior/navigation or even tie the link loaded by the WebView to any user...it's completely anonymized. So anything that would appear to risk user privacy should be considered off the table and a safe/anonymous alternative would be preferred.

Comments

+1 for pre-warming the SFSafariViewController with an URL and access to load events at-least.

By manish.deora at March 9, 2016, 10:40 a.m. (reply...)

Track page-loading

I am using SFSafariViewController first time, I am unable to track url of current page. Suggest me to way to use delegat by which I can track the URL.

By kunaldutta999 at Oct. 27, 2015, 8:57 a.m. (reply...)

Another request: Customize the Done button text

Can we have the "Done" button say "Cancel" instead?

By elliot.lee at June 12, 2015, 6:44 p.m. (reply...)

+1 to being able to customize the Done button. Adding an option for a back arrow would be nice as well, and having it shrink instead of disappearing when scrolling.

Re: Customize the Done button text

Probably being able to customise the Done button in general is pretty good. In many cases, instead of done you would need "Finish".

By Schemetrical at June 13, 2015, 7 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!