O Safari obviously a very relevant browser on iOS, but even more relevant is its rendering engine o WebKit. The simple reason: Apple requires its use by all other browsers, that is, when you use Chrome, for example, you have access to the Google browser features, but the rendering of the page itself is entirely done by WebKit ( actually for one fork called Blink).
Obviously Apple has its reasons for doing everything this way: making life easier for developers (who only need to test their pages one time) and their users (who have a consistent experience, regardless of the browser).
But this also has a downside: if WebKit fails to implement something relevant to the evolution of the web, all browsers for iOS are stuck together in time.
Anyone who used the internet in the early 2000s should remember that Internet Explorer dominated the so-called “browser war” for many years, delaying it a lot! the news for the web. Between the releases of versions 6 and 7 of the browser, for example, there were more than five years of waiting! No wonder that many developers wanted the death of the sixth verse at any cost.
And what does this scenario of the past decade have to do with Safari / WebKit? Well, Apple was starting to gain a similar fame, since it neglected for some time some important web specifications (somewhat unfairly, I would say).
But, fortunately, we bring good news: one of the most important specifications that is not yet present in Safari, the Service Workers, had its implementation status on the official WebKit website changed. Before displayed as Under consideration (“Under consideration”), now presented as “In development” ("under development")! It is even possible to see that the first steps have already been taken.
What are Service Workers?
Without going into too much technical detail, this specification allows scripts of pages run on background (Background). It may not seem like a big deal, but!
Something that becomes possible with this, for example, are the pages that work offline (obviously you need to log in at least once on the site). Another cool thing that becomes possible is notifications push even without having the app installed however, it's too early to say whether Apple will go or not.
There are other advantages, such as performance improvements (see some analysis here) and also a management of cache more efficient.
A little about PWA (Progressive Web App)
Service Workers are extremely important for PWAs to be supported on iOS. In short, PWAs are web apps (applications that run on the browser) that, when the browser supports a certain functionality, take advantage of these; but when they do not support, they also work perfectly.
These features are generally related to those previously available only for native apps, such as full-screen display (without the browser address bar), access to the device's sensors (gyroscope, accelerometer, etc.), sending notifications push, offline operation, among other things.
Interestingly, the App Store did not exist on iOS iPhone OS 1.0 and third-party apps only ran on browsers, very similar to PWAs. As we well know, all that has changed: native apps are much more popular in today's mobile world, but for a number of reasons (which I will leave for a future article) we see the idea of ​​web apps coming back slowly.
The truth is that it is almost impossible to predict how applications will be developed in the future, but I particularly believe that both strategies (native apps and PWAs) will coexist for quite some time, given that each has its advantages.
Okay, it looks cool! When I arrive?
It is very unlikely (not to say impossible) that this will arrive in the first stable version of iOS 11, but very soon developers and users will see this news. Remembering that, when the day comes, any browser on iOS will automatically support this specification!
We can only hope that it doesn't take too long, after all, this is one of those changes where everyone wins! ()
