This is less of a solution blog post and more of a rant against the fucken stupidness of Apple and how they are driving me absolutely crazy. The problem is, developers put up with their shit because let’s face it, their app store is incredible, they give reasonably good shares of proffits and people think their devices are sexy. But for a developer working outside the Apple Ecosystem, I.E. outside the app store, Apple is a thunderous pain in the ass. Excluse my colourful language but this is the second time in six months that Apple’s deliberate curtailment of web applications running in IOS browsers has caused me serious problems and massive time investments.

The first problem was a few months ago. I found that the .play Javascript event wouldn’t trigger when the screen was locked. This problem isn’t in Android. But on IOS, when a screen is locked, Javascript no longer runs. It’s a simple solution to a complex problem with the aim of improving battery life. It’s not so bad. I’ve been able to get around it.

The second problem though is more complicated.
Here’s the main problem. I’m creating a complex application where thousands of valuable audio tracks will be available for people to listen to using a web interface. Without decent security, it would be possible for someone with some basic scripting skills to download every single track. So therefore several layers of authentication are required. Here’s what happens in summary. I’m leaving a lot of information out because of course, I don’t want to give away my secrets and I also don’t want to tell would-be thieves how to get around what I’ve done.

• A user clicks play or play all.
• The browser asks the server for permission and sends on a password that’s unique to that session along with some other identifiable information.
• The server responds with the required authentication that will enable that track to be streamed.
• the browser then uses that information to request the track.
• The server receives a correct request with all of the security information so it sends the track to the browser for streaming.
• The browser streams the track.

The problem is, technically, the user hasn’t directly made the request to listen to that track by clicking or tapping something. Technically for IOS, the user made the request to validate the security information. But as there’s a conversation going on in the background between the server and the browser, the browser made that request without the intervention of the user. Therefore, the browser stupidly considers the audio streaming step as an automated action so doesn’t actually play the audio.

How am I going to get around this?

I’m not completely sure. I have ideas. Some involve reducing the security which isn’t an acceptable course of action. But instead of authenticating eaach streaming request, I could authenticate the page then use that authentication for the streaming requests on that page. It’s not as nice or as solid as the other method but for damned IOS, it will likely have to do.

I use IOS every day. The iPhone is my primary mobile device. I like the interface and the Voiceover screen reader is just brilliant. But from the perspective of a developer, I have developed deap and justifiable frustration toward Apple. They are trying to fource me into developing a native app for Ceol FM. It’s definitly in the plans to do this but there’s only so much time I can spend on this.

There have been others who have had this problem. Here are a few related forum and blog posts:

• Safari 11: audio.play causes “Unhandled Promise Rejection: NotAllowedError (DOM Exception 35)” even with user interaction
• HTMLMediaElement.play() – Web APIs
• Safari 11 has a major change to Web Audio API: requires each Audio() object to be triggered manually
• Safari audio.play() – NotAllowedError (DOM Exception 35)
• Safari audio.play() – NotAllowedError (DOM Exception 35)
• Audio output is blocked on iOS (and probably elsewhere) #14
• detect Unhandled Promise Rejection: NotAllowedError when calling .play() #178