Safari - The Internet Explorer of the Mobile Web

It needs to be voiced.
iOS Safari has fallen from a spearhead of innovation in early 2010's to become the de facto limiting User Agent of the modern web.

I'll make my case in 5 parts:

• A bit of history
• Native & HTML5
• So how is iOS Safari limiting the modern web?
  • Viewport / fullscreen support
  • Web Notifications
  • Web App Manifest

or

Skip to the gist - tl;dr

---

Back in 2010

Back in 2010, Steve Jobs made a big case of why iOS would not support flash in his open letter Thoughts on Flash

Instead, Steve proposed a view of a mobile HTML5 era for the future:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too)

This was followed up with Apple's clear statement of supporting 2 development platforms at Apple - HTML5 and App Store Native

I want to make something really clear: We support two platforms at Apple. Two.

The first one is HTML5, a fully open uncontrolled platform (...) we fully support HTML5 and Apple's browsers are in the lead in terms of supporting the full HTML5 standard. We are behind this 100%.

The second one is the App Store. The App Store is a curated platform (...) with the most vibrant app community on the planet.

With it, Flash was effectively out, and the new technology war in the mobile era had become Native vs HTML5.

Native & HTML5

In the coming years the two platforms would evolve each in its own way:

• HTML5 continued in its quest to eliminate old proprietary technologies and standardise itself the open web - slow and steady but with guaranteed sandboxing and cross-device runtime
• Native Mobile progressed to reach much higher levels of integration and performance - with much less sandbox boundaries and much quicker iterations it evolved much faster

But the reality is that not all developers needed the tight coupling with the OS provided by Native. HTML5 had kept on improving, steadily and firmly and reaching ever nearer its Native counterpart.

However soon the App Store had created a bind - not really a platform bind, but a delivery and profitability bind.

So came Hybrid apps - web platform runtimes that could be easily wrapped in a Native runtime. And with good design and implementation, hybrid apps were now indistinguishable from Native.
Although there are no official numbers, it is widely known and accepted that a considerable amount of applications today use this Hybrid approach.

So I'll be calling all apps delivered through an App or Play Store "Native" throughout the rest of this post.

So how is iOS Safari limiting the modern web?

In the past years, web standards have brought the web platform really close to the perceived "Native" standards.
With APIs like WebGL, WebAudio, WebAssembly, Workers, Fullscreen API, Push API & Web Notifications, Accelerometer, Gyroscope, Orientation, Network Information and Web App Manifest, you can now install and run a web app and perform almost any task without a visible difference from a "Native" one.

However most of such Web APIs are still lacking in iOS Safari.
The decision of not implementing such APIs by Apple have avoided that a web app can be installed and run like a "Native" one through the web platform directly.

There are 3 APIs in particular that are key to the perceived "app" experience in the OS:

Viewport / fullscreen support

The Fullscreen API adds methods to present a specific Element (and its descendants) in full-screen mode, and to exit full-screen mode once it is no longer needed. This makes it possible to present desired content—such as an online game—using the user's entire screen, removing all browser user interface elements and other applications from the screen until full-screen mode is shut off.
Fullscreen API - Web APIs | MDN

The Fullscreen API has been available in Chrome and Safari since 2011. It has never been made available in iOS Safari - not by a technical constraint, but by a design decision.

For perspective, here is some of the commit history of pain I've been dragged through to workaround it:

(partial) commit history related w/ Android Chrome

• 2013‑12‑10 - Android Chrome - normalised viewport scaling
• 2013‑12‑10 - Fixed width/height viewport for Android stock browser <=534.3
• 2014-12-08 - Support for Fullscreen API for Android Chrome

(partial) commit history related w/ iOS Safari

• 2013‑09‑19 - generalised iOS7 viewport fix for all iPhones ( 4 / 4s / 5 )
• 2014‑03‑05 - viewport handling for iOS 7.0
• 2014‑09‑30 - hotfix for iPhone 6+ viewport
• 2014‑10‑01 - viewport fix for iOS 8.1+
• 2015‑09‑03 - viewport fix for iOS 9
• 2015‑11‑09 - Viewport is broken when the game is opened in portrait on iPhone 6s+
• 2015‑11‑11 - Swipe up hack is not working on iPhone 6s+ in portrait
• 2016‑11‑14 - fix(rendering): Fix iOS rendering when disabling swipe fix
• 2017‑10‑13 - fix(virtualEvents): Hack to disable iOS 10+ zoom
• 2018‑08‑16 - fix(iphoneX): iphoneX barheigth fix
• 2019‑08‑22 - fix(iphone): viewport fix for iOS 13

Web notifications

Notifications - Web APIs | MDN

Here is another 5+ years old API that never reached iOS Safari. It allows web apps to send users notifications, like "Native" apps.

The only alternative is to build your own "Native" app and deliver it through the App Store.

Add to home screen

Mobile browsers have for long allowed web apps to be added to homescreen as bookmarks with a chain of manual steps. But it is just such a buried option in the browser that no one actually used it.

Now it has become a standard option for web apps.

"Add to home screen" (or a2hs for short) is a feature implemented by mobile browsers that takes the information found in an app's web manifest and uses them to represent the app on the device's home screen with an icon and name.

This key element is part of a collection of web technologies called progressive web apps (PWAs), which are websites that can be installed to a device’s homescreen like a "Native" app, from a user's perspective. And this can now be done directly from the web.

Unlike regular web apps with simple homescreen links or bookmarks, PWAs can be downloaded in advance and can work offline, as well as use regular Web APIs.
Progressive Web Apps | MDN

This has not been added to iOS Safari up to now (iOS 13, 2019).

---

tl;dr

Web standards have bridged the gap with "Native" mobile apps enough that today, for most mobile apps, the only reason to prefer some form of "Native" entanglement is really due to the App and Play Stores channels for delivery and profitability. You just have to be in the app stores.

Much like Microsoft tried to lock their user base to Internet Explorer Web APIs in the past, Apple today seems to be forcefully ridging the perception of web platform vs app store apps in iOS. It is doing so by not implementing web platform enhancements that are key to bringing web apps to be enabled and used as first class citizens (like "Native" apps) by the user.

I'm not even original in this comparison, others have been noticing it too for a variety of reasons:

• safari-is-the-new-ie.com
  

  Safari is the New Internet Explorer

  Meghan Denny ・ Jan 14 '18 ・ 2 min read

  #javascript #safari #webdev #productivity

Rephrasing Steve Jobs on Thoughts on flash:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too).

Perhaps Apple should focus more on creating great HTML5 tools for the future, and less on blocking out the web platform from being a first class citizen on mobile.