AVAudioPlayer throws breakpoint in debug mode
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
When AVAudioPlayer triggers a breakpoint in Xcode debug mode, it is almost always caused by an "All Exceptions" breakpoint catching internal Objective-C exceptions that AVFoundation throws and handles internally. These exceptions are not bugs — AVFoundation uses exception-based control flow internally, and they are caught before reaching your code. The fix is to modify your exception breakpoint to only break on your own exceptions, or to add an action that continues automatically after hitting the breakpoint.
The Problem
Xcode pauses execution at the play() call (or during AVAudioPlayer initialization) even though no error occurs in your code. The audio plays successfully after you continue.
Fix 1: Modify the Exception Breakpoint
In Xcode's Breakpoint Navigator:
- Find your "All Exceptions" breakpoint
- Right-click > Edit Breakpoint
- Change "Exception" from "All" to "Objective-C" (or "C++")
- Or better, add a condition or action:
Option A: Change to break only on Swift errors:
- Exception: Swift Error
Option B: Add an auto-continue action:
- Click "Add Action" > "Debugger Command"
- Enter:
po $arg1(to log the exception) - Check "Automatically continue after evaluating actions"
Fix 2: Remove the All Exceptions Breakpoint
If you do not need to catch all Objective-C exceptions:
- Open the Breakpoint Navigator (Cmd+8)
- Find "All Exceptions" breakpoint
- Right-click > Delete
You can still catch Swift errors with a "Swift Error Breakpoint" which does not trigger on AVFoundation's internal exceptions.
Fix 3: Audio Session Configuration
Sometimes the breakpoint triggers because the audio session is not configured properly:
Configuring the audio session before creating the player can prevent some of the internal exceptions that AVFoundation throws when it probes available audio routes.
Proper AVAudioPlayer Setup
Debugging Real AVAudioPlayer Errors
Common Pitfalls
- Keeping "All Exceptions" breakpoint and blaming AVAudioPlayer: The internal exceptions are normal AVFoundation behavior, not bugs. They are caught internally and never propagate to your code. Modify the breakpoint to "Swift Error" only, or add auto-continue to avoid false stops.
- Not retaining the AVAudioPlayer instance:
AVAudioPlayermust be stored in a property. If it is a local variable, ARC deallocates it immediately after the function returns, stopping playback mid-stream. Always assign to a stored property:self.player = try AVAudioPlayer(...). - Forgetting to call
prepareToPlay(): WithoutprepareToPlay(), the firstplay()call buffers audio data synchronously, causing a perceptible delay. Pre-buffer by callingprepareToPlay()during initialization, especially for short sound effects where latency matters. - Not configuring the audio session: Without setting the audio session category, playback may be silent when the device is in silent mode, or may interrupt other audio unexpectedly. Set
.playbackto play through silent mode, or.ambientto respect it. Set.mixWithOthersto avoid stopping background music. - Playing sounds on a background thread without audio session activation: AVAudioPlayer should be used on the main thread for UI-related sounds. If you call
play()from a background thread, ensure the audio session is active. Some operations (like route changes) must happen on the main thread. UseDispatchQueue.main.async { player.play() }if unsure.
Summary
- The breakpoint during
AVAudioPlayerusage is caused by Xcode's "All Exceptions" breakpoint catching AVFoundation's internal exceptions - Change the exception breakpoint to "Swift Error" only, or add auto-continue to stop false positives
- Always configure
AVAudioSessionbefore creating anAVAudioPlayer - Retain the player in a stored property — local variables are deallocated by ARC
- Call
prepareToPlay()to pre-buffer audio and reduce playback latency

