I have a react application hosted on heroku, which relies heavily on playing audio with an audio tag. There are two different "pages" (I'm using conditional rendering rather than react router, so everything is all one page), that essentially do the same thing:
To ensure fair use (this is a hobby project), copyrighted audios have been trimmed to 25 seconds before hosting. These are pulled into the "music player" section of the app (accessible through the nav bar), one at a time as needed. I have other audio files of my own recordings that are not trimmed and run at about 3.5-5mins long, which appear in the "covers" section of the app.
All of the album links update the audio src and play correctly on Android and desktop devices. On iOS, regardless of browser, the "covers" audios will not play, but the "music player" audios will. I have spent hours trying to find a workaround for this, because it doesn't seem to have to do with browser auto-play policies as much as with some policy on iOS itself? The site is rendered in such a way that the user must interact with it before playing audio, so it satisfies autoPlay policies. Has anyone run across a similar issue?
You can find the site here: thekillersmusic.herokuapp.com
This issue has been resolved. The problem for me was that the audio files were converted from wav to mp3 by changing the extension on my local device before hosting. This caused range headers to be included on the http requests made for the resources, and partial content responses to be sent back. For whatever reason, iOS devices had issues resolving the partial content responses. However, android and desktop systems did not. After redownloading the files as mp3, rather than wav, and then hosting the new files, the requests were handled with 200 status codes rather than 206 status codes, and the audio worked across all platforms.