PWAs on iOS 12.2: No Motion and No Orientation (or…? ) — UPDATED (beta 6)
As it stands Apple will introduce an option in iOS 12.2 called “Motion & Orientation Access” which is turned off by default. iOS 12.2 is still in its beta period and is close to release. Once released, all websites and PWAs using these APIs will be effectively broken in Safari.
And that’s bad.
People called it a “cliff-edge scenario”, said it “threatens web-based VR and AR” and would “wipe out a complete genre of online games”. Scary words but in my opinion, they aren’t overstating it too much.
Time is ticking
This week, March 9, beta 5 was released to the public. Not knowing if there were changes since the previous betas (there was talk about an alternative implementation), I downloaded beta 5 and tried it myself.
Unfortunately, there is no change:
Time is running out. The release for iOS is not announced officially, but it will probably follow shortly after Apple’s March 25 event, according to MacRumors. One other beta might follow, but it seems there is very little time for more.
I’ll update this when there is news.
Update March 14: Good news, an update to the spec is here!
And the corresponding bug in Webkit: https://bugs.webkit.org/show_bug.cgi?id=195329
Not sure if it will make it on time though. Will update this when that is clear.
Update 2, March 19: no change in beta 6.
Meanwhile, the proposed change to the device orientation spec has been merged.
At this point, you might ask: why do you think this is so important? Motion & orientation are just a couple out of many web features, you might argue.
True, and moreover they come in after core PWA features (manifest, service worker) and other, more widely used, features like camera access, location services, and notifications.
Personally, I became more involved with PWAs recently, finally seeing a realistic path to a web ecosystem that can compete with native apps. Things are coming together and browser support is growing. You get that sense of momentum.
And then, coincidentally at the same time when I was working on a sensor demo with a colleague, the news arrived that Apple would “pull the plug” on it. It is not only frustrating, but it’s also a step back when you are finally moving forward. If the web is to become a full-featured application ecosystem, it needs the complete package, including the (arguably) less important ones.
Apple is concerned that unrestricted access will hurt users privacy. And rightly so. It can be misused for fingerprinting or be used to determine if you are sitting up, lying down etc. All without asking the user’s permission. Clearly, there is a good argument to be made for asking the user’s permission before enabling access to these sensors.
But wait… why like this?
The key question is why Apple decided to add an option under “Settings” to accomplish privacy protection. There is an alternative that is accepted, that protects the user’s privacy and that doesn’t hurt existing applications that hard: simply prompt the user and ask permission when the feature is triggered.
While there is talk (as mentioned above) of such an alternative, the question remains why this path wasn’t chosen initially.
This discussion on Github, to figure out a compromise that Apple could adopt before the 12.2 release, was locked by w3c for becoming “too heated”, which does give a feel for the impact the sudden introduction created.
It’s not all bad!
Let me finish up by saying that there also is a lot of good news. PWAs will remain awesome and their momentum will not be killed.
Safari is no front-runner but has been introducing PWA features and adopting APIs at a steady pace the past year. iOS 12.2 itself also introduces improvements. Maximiliano Firtman published an excellent article on it “PWAs on iOS 12.2 beta: the good, the bad, and the “not sure yet if good””.
Still, (virtually) disabling these APIs would be a small blow for PWAs and it raises questions about Apple’s future commitment to the web as it seems they seem to have no real trouble delivering it.
Let’s just hope things will turn around (just) in time.