Skip to main content

Interface: IosMediaSessionConfig

Defined in: packages/media-session/src/specs/media-session.nitro.ts:548

iOS half of MediaSessionConfig. Ignored on Android.

There is deliberately no playbackResumption here​

Not an oversight and not a TODO. iOS has no mechanism that can restart a terminated app to play audio: force-quit (and an OS termination) is treated as the user's intent that the app stop, and nothing — no media button, no Control Center, no route change — may bring it back. What iOS does share with Android is the layer underneath: withPersistence saves the session on both platforms identically, and on iOS the next manual launch calls restorePersisted and comes back paused, on the same track, at the same position.

If Apple ever ships a resumption mechanism, this is where the flag belongs — ios.playbackResumption, mirroring AndroidMediaSessionConfig.playbackResumption. Stated here so the asymmetry reads as a platform fact rather than as something to "fix" by hoisting the flag out of its platform namespace.

Properties​

artworkCacheSize?​

optional artworkCacheSize?: number;

Defined in: packages/media-session/src/specs/media-session.nitro.ts:556

Maximum number of decoded artwork images kept in memory, keyed by URI. Artwork decoding is off the main thread; the cache is what keeps a queue of repeated covers from re-decoding on every setMediaItem.

Default​

8

supportedPlaybackRates?​

optional supportedPlaybackRates?: number[];

Defined in: packages/media-session/src/specs/media-session.nitro.ts:581

Playback rates offered to the lock screen's rate control, ascending.

MPChangePlaybackRateCommand.supportedPlaybackRates is a fixed list: iOS shows the control only when there is something to show, and it snaps the user's choice to a member of this array. An audiobook app that offers 1.0/1.25/1.5/1.75/2.0/3.0 has no way to say so without this.

Default​

[0.5, 0.75, 1, 1.25, 1.5, 2]

Why there is no Android twin (checked, not assumed)​

Nothing on the Android side takes a list. media3's speed lever is Player.COMMAND_SET_SPEED_AND_PITCH → setPlaybackParameters(...), which accepts an arbitrary float; there is no "supported rates" concept anywhere in Player, MediaSession or PlaybackStateCompat (javap over the shipped media3-common/media3-session 1.11.0 AARs finds no such API), and media3's notification draws no rate control at all — a controller that wants one builds its own UI and picks its own numbers. So this is a genuine platform asymmetry rather than a missing mapping, and it is namespaced under ios for the same reason playbackResumption is namespaced under android: the shape of the config should say which platform can honour it.

Setting it on Android is harmless and does nothing.