In the process of evaluating the suitability of SFSafariViewController
(SFSVC) for use within the Twitter iOS client, I encountered a number of bugs
with differing severities, all of which I filed as Radars in Apple's bug
reporting tool. Here is my attempt to holistically document their impact on our
ability to adopt SFSafariViewController as a replacement for our existing
WebViews.
The fundamental blocker is Radar #23706636, wherein a crash in the remote SFSVC process will cause the host app (i.e., Twitter) to crash without any notification. This is a gap in the sandbox provided by SFSVC, and makes the host app susceptible to Denial of Service (DOS) attacks wherein attackers can force crashes by posting links to pages that exploit known browser bugs.
Radar #23706923 is a concrete manifestation of this problem, wherein a memory leak during resizing of animated GIFs will ultimately exhaust the memory available to the SFSVC process and result in a crash of the host app.
Realistically, DOS attacks are not likely; however, the largest concern is that
we have zero insight into crashes within SFSVC (and limited protection from
them). The existing WKWebView implementation will render a blank screen if
the remote process crashes, allowing the user to continue using the host app;
thus, SFSVC would be a regression.
SFSVC has issues with contentInsets when the keyboard is visible (Radar
#23706138) and when presented in
landscape mode (Radar #23706265).
Incorrect contentInsets makes it impossible to reach content near the bottom
of the webpage.
Normally, I would classify these bugs as low severity, since they appear to be
mainly an inconvenience. However, we experienced a similar contentInset bug
with the Twitter implementation of WKWebView and I found over five JIRA
tickets filed throughout the company which attempted to understand and work
around the bug. (In one particular case, it was impacting the revenue of an
advertiser because the button to submit a form was unreachable at the bottom of
the webpage.)
There are a number of oft-reported inconveniences affecting the SFSVC user experience. Radar #23705421 states that a Back to [Host App] link fails to appear in the iOS status bar when navigation occurs from SFSVC to another app. (This may negatively impact time-in-app due to the inconvenience of returning.) Furthermore, SFSVC doesn't activate Universal Links by default (Radar #23612919), which means that custom schemes remain the only reliable way of deeplinking between the web and native apps. Though I've listed these as low severity, improving the deeplinking and multitasking experiences have been recent priorities at Twitter, and probably matter more to us than other app developers.
Radar #23557272 states that SFSVC may render as a blank canvas for a split-second upon initial use, and Radar #23557171 states that SFSVC will render incorrectly when a in-call status bar appears (i.e., the large green or blue bar indicating an active call or tethering session). These bugs show a distinct lack of polish, which will be attributed by consumers to Twitter.
Finally, SFSVC does not provide a means to exclude the system Twitter activity from its share sheet (Radar #23503333), meaning that the Twitter app is unable to provide a first-party/in-app experience for tweeting links from SFSVC without being redundant.
It's difficult to asses the severity of accessibility bugs, so I've separated them out. Fundamentally, Radar #22492329 (which was filed externally) is a blocker for use with VoiceOver, since it claims that VoiceOver will cease to function on certain pages. I wasn't able to reproduce this problem, but I did reproduce the strange console logging that they described (Radar #23705345), which leads me to think that the original bug is still present and that SFSVC is unstable with VoiceOver active.
Furthermore, SFSVC does not respect the universal dismiss gesture (a two-finger 'Z' shape) as filed in Radar #23420704.
My colleague, Nolan O'Brien, filed a series of feature requests (Radar
#21349835) in June 2015, which
predominantly concerned insight into the timing and success of the initial page
load. (This is important to advertisers for conversion tracking, as well as
helpful for understanding user behavior around organic content.) Apple added a
callback to the SFSafariViewControllerDelegate to indicate the completion of
the initial page load, but this is still exceedingly coarse feedback, because
it fires upon the first window.load event, which can fire significantly after
a page has become interactive. It also provides no insight into the various
timing components of the load, or the redirects encountered along the way,
which have been important for Twitter as we've sought to reduce the number of
end-user redirects.
I built a simple HTTP service and iOS app to test and reproduce these issues. Many of the Radars refer to this app in the repro steps.
Did some of those bugs get fixed?