Apple PlatformIssue Guide
#017 AVPlayer Open

iOS 27 beta pauses playback when Notification Center fully opens

GitHub source

Evidence not classified. This page is generated from GitHub Issue #17; GitHub remains the canonical authoring and discussion source.

Source#

Apple Developer Forums: https://developer.apple.com/forums/thread/838683

Problem#

A video-streaming app reports an iOS 27 beta behavior change: fully opening Notification Center pauses an AVQueuePlayer; audio continues for roughly five seconds, the app is then suspended, and closing Notification Center leaves playback paused. The same build reportedly continues playing on iOS 26.

Setup reported by the developer:

AVQueuePlayer
video + audio, not muted
audiovisualBackgroundPlaybackPolicy = .automatic
AVAudioSession category = .playback
UIBackgroundModes includes audio
AVPictureInPictureController attached
canStartPictureInPictureAutomaticallyFromInline = true

Feedback: FB23893965.

Evidence level#

Observed Apple Developer Forums report; platform regression remains unconfirmed.

Apple documents that AVPlayer.audiovisualBackgroundPlaybackPolicy controls audiovisual playback as an app transitions to the background. For .automatic, the system decides whether playback continues. .continuesIfPossible explicitly requests continuation; .pauses explicitly requests pause. Therefore the first task is to determine whether Notification Center causes a background/scene transition, a playback-policy transition, a PiP transition, or an independent transport pause.

Why this is a useful debugging case#

Do not collapse these states:

Notification Center becomes visible
        ≠
scene becomes inactive
        ≠
app enters background
        ≠
PiP starts
        ≠
AVPlayer transport pauses
        ≠
process is suspended

The approximately five-second gap between video pause and process suspension is especially useful: it suggests at least two observable transitions that should be timestamped separately rather than treated as one event.

Investigation#

Build a timestamped state timeline around Notification Center presentation.

Capture:

UIApplication / UIScene lifecycle state
AVPlayer.rate
AVPlayer.timeControlStatus
AVPlayer.rateDidChangeNotification + reason when available
AVPlayerItem.status
AVAudioSession interruption/route notifications
PiP possible / active / suspended state
AVPlayer audiovisualBackgroundPlaybackPolicy
currentTime progression
process suspension boundary from system logs

Instrument at minimum:

T0  before Notification Center pull-down
T1  Notification Center partially visible
T2  Notification Center fully presented
T3  video stops advancing
T4  audio stops
T5  scene/app lifecycle transition
T6  process suspension
T7  Notification Center dismissed

The key question is not simply “why did AVPlayer pause?” but:

Which state transition occurs immediately before rate / timeControlStatus changes, and which component owns that transition?

Controlled matrix#

Use the same asset and build while changing one variable at a time:

A. iOS 26 + .automatic
B. iOS 27 beta + .automatic
C. iOS 27 beta + .continuesIfPossible
D. iOS 27 beta + .pauses (control)
E. iOS 27 beta without AVPictureInPictureController
F. iOS 27 beta with PiP controller, automatic-from-inline disabled
G. audio-only AVPlayer
H. video + muted audio
I. local MP4
J. HLS

Interpretation examples:

B fails, C works
→ automatic background-policy decision is a strong boundary

B and C both fail
→ investigate lifecycle / suspension / transport policy below the public policy preference

B fails only with PiP controller attached
→ PiP eligibility/state coordination becomes primary

local + HLS both fail identically
→ HLS/network path is unlikely to be causal

audio-only continues while audiovisual pauses
→ audiovisual visibility/background policy is implicated

Public API contract to preserve#

AVPlayerAudiovisualBackgroundPlaybackPolicy is a policy input, not proof of the actual lifecycle event that triggered the player state change.

In particular:

.automatic
→ system chooses

.continuesIfPossible
→ explicit continuation preference

.pauses
→ explicit pause preference

Do not label .continuesIfPossible a production fix until it is tested against expected lifecycle, PiP, audio-session, and App Store behavior. Use it first as an A/B discriminator.

Reusable engineering rule#

For system-UI playback regressions, correlate player transport state with app/scene lifecycle and PiP state before blaming the media pipeline.

Use this boundary model:

system UI event
→ scene/application policy transition
→ audiovisual background policy
→ PiP coordination
→ AVPlayer transport decision
→ timebase progression
→ process suspension

The first transition that differs between the working OS and failing OS is the useful root-cause boundary.

References#