[BUG] MediaElement steals audio session on iOS when configured to play silently

[Joeb454]

Is there an existing issue for this?

• I have searched the existing issues

Did you read the "Reporting a bug" section on Contributing file?

• I have read the "Reporting a bug" section on Contributing file: https://github.com/CommunityToolkit/Maui/blob/main/CONTRIBUTING.md#reporting-a-bug

Current Behavior

When a MediaElement is configured to silently autoplay video (ShouldAutoPlay="True", ShouldMute="True"), the underlying iOS AVPlayer still activates the shared AVAudioSession with CategoryPlayback. This causes the iOS audio session to be stolen, even though the MediaElement produces no audible output.

The effect is that any audio playing from another source (e.g. Spotify, Apple Music, a podcast app) is interrupted or paused whenever the muted MediaElement begins playback.

This is a platform-level side effect of how AVAudioSession works on iOS. Setting the category to Playback and activating the session is a way to indicate that my app intends to be the primary audio source.

Expected Behavior

When a MediaElement is configured to play silently (muted or zero volume), it should not interrupt or claim exclusive ownership of the iOS audio session. Ideally, the MediaElement (or its platform view) should either:

1. Use AVAudioSessionCategory.Ambient (or Playback with the .MixWithOthers option) when the media is muted, so that other audio sources are not interrupted.
2. Expose a configurable property (e.g. AudioSessionCategory or AudioMixBehavior) that allows the developer to control the AVAudioSession category used by each MediaElement instance.
3. Provide a way to pass audio session configuration through ToPlatformView or via the MauiMediaElement constructor on iOS/macOS, so that developers can influence the AVAudioSession setup at the platform level.

Option 3 would be the most flexible, as it would allow developers to handle their own use-case-specific audio session management without the toolkit needing to anticipate every scenario.

Steps To Reproduce

1. Create a .NET MAUI application targeting iOS.
2. Add a single MediaElement to a page, configured to autoplay muted:

<toolkit:MediaElement
    Source="https://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4"
    ShouldAutoPlay="True"
    ShouldMute="True"
    ShouldShowPlaybackControls="False"
    Aspect="AspectFill"
    HeightRequest="300" />

3. Before opening the app, start playing audio from another app (e.g. Spotify or Apple Music).
4. Launch the MAUI app on an iOS device or simulator.
5. Observe that the background audio is interrupted/paused as the muted MediaElement begins autoplay.

There's a reproduction project repo linked below too.

Link to public reproduction project repository

https://github.com/Joeb454/maui-media-element-repro

Environment

- **CommunityToolkit.Maui.MediaElement**: 8.0.0
- **OS**: iOS 18.x (also reproducible on earlier iOS versions)
- **.NET MAUI**: 10.x

Anything else?

The root of the issue appears to be in MediaManager.macios.cs, where the AVAudioSession is configured during player setup. Currently there is no mechanism to influence the audio session category from the MediaElement API or to pass configuration through to the platform view.

[ne0rrmatrix]

Good catch. I implemented the feature that added this when I added Rich Media Notifications. Can you create a discussion with your recommended choice so we can move forward with adding it. Once we get around 10 people up-voting this we can start the ball rolling.

I like the idea of adding support for developers being able to configure this. If you have a suggested API or are interested in adding the feature I would be happy to help you if you have any questions. Details about adding new features: https://github.com/CommunityToolkit/Maui/wiki/Submitting-a-New-Feature

[Joeb454]

@ne0rrmatrix I've done a commit on my forked repo that handles this based off the ShouldMute property, which might give a more expected behaviour at least, so could potentially open that as a PR if people think that's a sensible default behaviour; this would work for the app I'm working with at least, but conscious that this needs to be a sensible default for all apps.

I'll take a look at the new feature doc now and have a think about a suggested API for this where developers can configure it more appropriately.

[Joeb454]

@ne0rrmatrix I've created #3129 as a new feature suggestion now; happy to work through this as much (or as little) as you need/want to get a solid proposal in place.