Tags: ios

I documented a weird bug with web audio on iOS a while back:

On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the video element). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!

It’s almost like playing a video or audio element “kicks” the browser into realising it should be playing the sound from the Web Audio API too.

This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.

I found a workaround but it was really hacky. By playing a one-second long silent mp3 file using audio, you could “kick” the sound into behaving. Then you can use the Web Audio API and it would play consistently.

Well, that’s all changed with the latest release of Mobile Safari. Now what happens is that the Web Audio stuff plays …for one second. And then stops.

I removed the hacky workaround and the Web Audio API started behaving itself again …but your device can’t be set to silent.

The good news is that the Web Audio behaviour seems to be consistent now. It only plays if the device isn’t muted. This restriction doesn’t apply to video and audio elements; they will still play even if your device is set to silent.

This descrepancy between the two different ways of playing audio is kind of odd, but at least now the Web Audio behaviour is predictable.

You can hear the Web Audio API in action by going to any tune on The Session and pressing the “play audio” button.

Push notifications are finally arriving on iOS—hallelujah! Like I said last year, this is my number one wish for the iPhone, though not because I personally ever plan to use the feature:

When I’m evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn’t support them—even though desktop Safari does—I’m somewhat stumped. There’s no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.

With push notifications in mobile Safari, the arguments for making proprietary apps get weaker. That’s good.

The announcement post is a bit weird though. It never uses the phrase “progressive web apps”, even though clearly the entire article is all about progressive web apps. I don’t know if this down to Not-Invented-Here syndrome by the Apple/Webkit team, or because of genuine legal concerns around using the phrase.

Instead, there are repeated references to “Home Screen apps”. This distinction makes some sense though. In order to use web push on iOS, your website needs to be added to the home screen.

I think that would be fair enough, if it weren’t for the fact that adding a website to the home screen remains such a hidden feature that even power users would be forgiven for not knowing about it. I described the steps here:

1. Tap the “share” icon. It’s not labelled “share.” It’s a square with an arrow coming out of the top of it.
2. A drawer pops up. The option to “add to home screen” is nowhere to be seen. You have to pull the drawer up further to see the hidden options.
3. Now you must find “add to home screen” in the list

• Copy
• Add to Reading List
• Add Bookmark
• Add to Favourites
• Find on Page
• Add to Home Screen
• Markup
• Print

As long as this remains the case, we can expect usage of web push on iOS to be vanishingly low. Hardly anyone is going to add a website to their home screen when their web browser makes it so hard.

If you’d like to people to install your progressive web app, you’ll almost certainly need to prompt people to do so. Here’s the page I made on thesession.org with instructions on how to add to home screen. I link to it from the home page of the site.

I wish that pages like that weren’t necessary. It’s not the best user experience. But as long as mobile Safari continues to bury the home screen option, we don’t have much choice but to tackle this ourselves.

I’ve mentioned before that I don’t enable notifications on my phone. Text messages are the only exception. I don’t want to get notified if a new email arrives (I avoid email on my phone completely) and I certainly don’t want some social media app telling me somebody liked or faved something.

But the number one feature I’d like to see in Safari on iOS is web notifications.

It’s not for me personally, see. It’s because it’s the number one reason why people are choosing not to go all in progressive web apps.

Safari on iOS is the last holdout. But that equates to enough marketshare that many companies feel they can’t treat notifications as a progressive enhancement. While I may not agree with that decision myself, I get it.

When I’m evangelising the benefits of building on the open web instead of making separate iOS and Android apps, I inevitably get asked about notifications. As long as mobile Safari doesn’t support them—even though desktop Safari does—I’m somewhat stumped. There’s no polyfill for this feature other than building an entire native app, which is a bit extreme as polyfills go.

And of course, unlike on your Mac, you don’t have the option of using a different browser on your iPhone. As long as mobile Safari doesn’t support web notifications, nothing on iOS can support web notifications.

I’ve got progressive web apps on the home screen of my phone that match their native equivalents feature-for-feature. Twitter. Instagram. They’re really good. In some ways they’re superior to the native apps; the Twitter website is much calmer, and the Instagram website has no advertising. But if I wanted to get notifications from any of those sites, I’d have to keep the native apps installed just for that one feature.

So in the spirit of complaining about web browsers in a productive way, I just want to throw this plea out there: Apple, please support web notifications in mobile Safari!

The good news is that web notifications on iOS might be on their way. Huzzah!

Alas, we’re reliant on Maximiliano’s detective work to even get a glimpse of a future feature like this. Apple has no public roadmap for Safari. There’s this status page on the Webkit blog but it’s incomplete—web notifications don’t appear at all. In any case, WebKit and Safari aren’t the same thing. The only way of knowing if a feature might be implemented in Safari is if it shows up in Safari Technology Preview, at which point it’s already pretty far along.

So while my number one feature request for mobile Safari is web notifications, a close second would be a public roadmap.

It only seems fair. If Apple devrels are asking us developers what features we’d like to see implemented—as they should!—then shouldn’t those same developers also be treated with enough respect to share a roadmap with them? There’s not much point in us asking for features if, unbeknownst to us, that feature is already being worked on.

But, like I said, my number one request remains: web notifications on iOS …please!

Dave recently wrote some good advice about what to do—and what not to do—when it comes to complaining about web browsers. I wrote something on this topic a little while back:

If there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it

To summarise Dave’s advice, avoid conspiracy theories and snark; stick to specifics instead.

It’s very good advice that I should heed (especially the bit about avoiding snark). In that spirit, I’d like to document what I think is a bug on iOS.

I don’t need to name the specific browser, because there is basically only one browser allowed on iOS. That’s not snark; that’s a statement of fact.

This bug involves navigating from a progressive web app that has been installed on your home screen to an external web view.

To illustrate the bug, I’ll use the example of The Session. If you want to recreate the bug, you’ll need to have an account on The Session. Let me know if you want to set up a temporary account—I can take care of deleting it afterwards.

Here are the steps:

1. Navigate to thesession.org in Safari on an iOS device.
2. Add the site to your home screen.
3. Open the installed site from your home screen—it will launch in standalone mode.
4. Log in with your username and password.
5. Using the site menu, navigate to the links section of the site.
6. Click on any external link.
7. After the external link opens in a web view, tap on “Done” to close the web view.

Expected behaviour: you are returned to the page you were on with no change of state.

Actual behaviour: you are returned to the page you were on but you are logged out.

So the act of visiting an external link in a web view while in a progressive web app in standalone mode seems to cause a loss of cookie-based authentication.

This isn’t permanent. Clicking on any internal link restores the logged-in state.

It is surprising though. My mental model for opening an external link in a web view is that it sits “above” the progressive web app, which remains in stasis “behind” it. But the page must actually be reloading, either when the web view is opened or when the web view is closed. And that reload is behaving like a fetch event without credentials.

Anyway, that’s my bug report. It may already be listed somewhere on the WebKit Bugzilla but I lack the deductive skills to find it. I’m not even sure if that’s the right place for this kind of bug. It might be specific to the operating system rather than the rendering engine.

This isn’t a high priority bug, but it is one of those cumulatively annoying software paper cuts.

Hope this helps!