We're not planning to update the AudioSource.isPlaying boolean in this case. There are other cases where isPlaying goes to false, like when headphones are plugged in (and the default device changes). In that case, the AudioSource is actually stopped and the whole engine is stopped and restarted. It's a normal thing to check for this, and call AudioSource.Play in response (for example, if a background music track stops playing). However, in the case of iOS interrupting our audio session, the AudioSource is still set up to play, so we don't want the user to see isPlaying false and call Play again. isPlaying would then continue to return false and this would be weird/confusing.

If a user accepts a phone call while Unity is in the foreground, we'll end up losing audio session focus and Unity will be running and audio will not be updating. In this case, I think we just have to recommend that you write some Objective-C code to subscribe to those AVAudioSession callbacks, if you need to learn about this. Alternatively, you could also check one of your playing AudioSources and if AudioSource.time does not get updated in X frames, then you'll know audio is not updating and has lost focus (probably 2 frames would be enough for a 30fps game). In future versions of Unity, we’ll look into making it easier to discover when this happens, perhaps via a C# callback.