Bug
audioplayers_darwin 6.4.0+ logs the following warning at first play() and never fires the player's onPlayerComplete event for short audio files (voice line MP3s, ~3 seconds):
SWIFT TASK CONTINUATION MISUSE: setUpPlayerItemStatusObservation(_:) leaked its continuation without resuming it. This may cause tasks waiting on it to remain suspended forever.
The leaked continuation appears to hang the play call. The audio either doesn't play or plays but never reports completion, which breaks any caller that awaits onPlayerComplete.
Repro
- Flutter app with
audioplayers: ^6.6.0 (resolves audioplayers_darwin: 6.4.0).
- iOS Simulator (tested: iPhone 17 Pro Max, iOS 26.4 — also reproduced on iPhone 15 sim per other reports).
- App preloads ~10 MP3 voice files (3-5 seconds each) at startup and plays them in sequence during user interactions.
- Run with Xcode console attached.
Observed
- Console shows
SWIFT TASK CONTINUATION MISUSE: setUpPlayerItemStatusObservation(_:) leaked its continuation without resuming it. on first play() after setSourceAsset.
- Voice lines either play silently or play but
onPlayerComplete never fires, so the application's voice-completion callback is never invoked.
- The first symptom downstream: every voice line in the session times out at the application's fallback timer (e.g., "voice_timeout file=voice_lets_fight.mp3 err=none" 11/11 voice plays during a single brushing session).
- Music (long-loop MP3 from assets) plays fine. Issue appears specific to short, frequently-restarted voice clips.
Versions
audioplayers: 6.6.0audioplayers_darwin: 6.4.0 (also reproducible on 6.5.0+ per the changelog's "async swift code" landing in 6.4.0)- Flutter 3.41.4 stable
- Xcode 26.4.1
- iOS 26.4 simulator
Workaround
Pinning audioplayers_darwin to 6.3.0 via dependency_overrides eliminates the warning and restores onPlayerComplete. 6.3.0 doesn't contain setUpPlayerItemStatusObservation (the new async-swift player setup); it uses the prior delegate-based observation path.
# pubspec.yaml
dependency_overrides:
audioplayers_darwin: 6.3.0
Likely cause
Looking at the 6.4.0 changelog ("FEAT: Async swift code, align release functionality, align Android initialization error" #1964), the new code uses withCheckedContinuation to wait for AVPlayerItem.status to transition to .readyToPlay. If the item's status observation fires after the continuation has been resumed (or if multiple observations fire), or if the player is replaced/disposed mid-setup, the continuation is leaked. The Swift runtime detects this and emits the misuse warning; subsequent play calls likely leak their continuations too, eventually exhausting an internal queue.
Happy to test fixes against this repro if you have a candidate patch.
Bug
audioplayers_darwin6.4.0+ logs the following warning at firstplay()and never fires the player'sonPlayerCompleteevent for short audio files (voice line MP3s, ~3 seconds):The leaked continuation appears to hang the play call. The audio either doesn't play or plays but never reports completion, which breaks any caller that awaits
onPlayerComplete.Repro
audioplayers: ^6.6.0(resolvesaudioplayers_darwin: 6.4.0).Observed
SWIFT TASK CONTINUATION MISUSE: setUpPlayerItemStatusObservation(_:) leaked its continuation without resuming it.on firstplay()aftersetSourceAsset.onPlayerCompletenever fires, so the application's voice-completion callback is never invoked.Versions
audioplayers: 6.6.0audioplayers_darwin: 6.4.0(also reproducible on6.5.0+ per the changelog's "async swift code" landing in 6.4.0)Workaround
Pinning
audioplayers_darwinto6.3.0viadependency_overrideseliminates the warning and restoresonPlayerComplete. 6.3.0 doesn't containsetUpPlayerItemStatusObservation(the new async-swift player setup); it uses the prior delegate-based observation path.Likely cause
Looking at the 6.4.0 changelog ("FEAT: Async swift code, align release functionality, align Android initialization error" #1964), the new code uses
withCheckedContinuationto wait forAVPlayerItem.statusto transition to.readyToPlay. If the item's status observation fires after the continuation has been resumed (or if multiple observations fire), or if the player is replaced/disposed mid-setup, the continuation is leaked. The Swift runtime detects this and emits the misuse warning; subsequent play calls likely leak their continuations too, eventually exhausting an internal queue.Happy to test fixes against this repro if you have a candidate patch.