Hello I’m here to let you know about one of the issues I’ve found.
Bug 1: Background audio in Brave prevents screen from sleeping after alerts.
Device: iPhone 13, iOS 26.6.2, Brave (latest version from App Store)
Steps to reproduce:
1. Open YouTube video (music) in Brave browser.
2. Minimize browser / lock phone so audio plays in background.
3. Wait for any alert to arrive (message, app reminder, timer, etc.).
4. Observe that the screen turns on with the alert notification.
Expected: Screen should turn off after the alert is dismissed, returning to sleep state while audio continues in background.
Actual: Screen stays on indefinitely after any alert, even after dismissing it. This results in the phone screen staying on all night, draining battery significantly (e.g., 1% remaining after 8 hours of sleep).
Thank you for your feedback. For further investigation of this issue you described, you need to prove some settings:
In the display settings, if “Auto-Lock” is activated, Settings => Display & Brightness => Auto-Lock
Maybe the the Auto-Lock is only activated for specific apps like Brave Browser via Guided Access. Then you can adjust that under Settings => Accessibility => Guided Access and triple press the side button to lock the screen state within that app until manual intervention.
I hope this helps for the first steps. I do not have an iPhone, so bear with me if I’m wrong with the setting names.
If you don’t understand something or if the issue persists, give feedback or ask for further help via reply here.
Settings => Display & Brightness => Auto-Lock => Never
Settings => Accessibility => Guided Access => Off
I always have auto-lock disabled. I manually shut my screen off, every time, and know it will stay that way—which is part of the reason I noticed this bug happening!
And as for guided access, I’ve never used this feature before, so it makes sense why it is off.
Again, thank you for getting back to me. What do you recommend?
I’m honestly confused. Why set a timer for three minutes?
I don’t want the screen to come on. The problem is that it does, when an alert goes off, instead of normally timing out when the screen is off and locked.
My only work around so far, is to engage Do Not Disturb mode for 8+ hours.
This can do it, but during the day, I cannot have DND on, and my battery still drains.
Otherwise, the reason for using Brave in the first place, for music with an off screen, is basically moot?
You need to do this to have a work around so the display goes after 3 min. You can of course also set a lower value like 15 sec, mine was jsut an example; maybe a bad one.
The problem of battery draining comes from two things: One is the display which we can conquer with the said setting and the second is the streaming. Concurrent streaming uses also much battery if using 4G or 5G. Over W-LAN would be a bit better.
You can try it out and test how much battery it will use when going over W-LAN.
Another way would be something like focus mode (Settings => Focus). You can set there like notification mute for a time period like “Do not Disturb” mode, though I do not have any experiences with because I use Android.
I hope I could help nonetheless the unhappy situation of yours. I would recommend to set a Auto-Lock value like 15 sec. I would not see any other possibility, though I could be also wrong of course.
Thank you for your questions I’ll respond as best I can.
In a locked screen, with no player? Not at all.
My personal setting for the phone display, while unlocked, is always-on. I manually close it, every time. This is on purpose.
The display auto-closes after notifications like usual, if I’ve locked my phone.
IF I am currently using Brave to play audio—right when another notification arrives, the screen awakes to trigger the peek. But it stays on, and doesn’t auto-close.
This is a Brave-only occurrence.
No. Brave is my only audio player, on my device.
I am using it for the sole purpose to cue up the 8+ hour nature background tracks on YouTube’s site, while having my screen off.
If the screen persists on, this benefit of “closing” my phone cancels out.
Prior, I was using YouTube premium, and the screen always behaved. Once I locked it, notifications peeked as usual. Screen stayed off.
When I canceled my membership, I needed an alternative that let me lock my screen—and found Brave.
Safari also behaves, while playing podcasts with the screen locked.
Both the YouTube app, and safari— I have accessed from the lock screen, and know the audio player works as it should.
Yes. I use the default YouTube site, and have tried both mobile and desktop version requests, to see if it will make a difference. It does not.
I have not tried “music.youtube,” therefore I cannot say.
(Side note, logging into my YouTube account through Brave—it will only let me see the notifications icon, while in landscape mode?? But that is a discussion for another time. )
Hi, just chiming in with a couple of observations that might help narrow this down.
Since Safari (podcasts) and the native YouTube app both behave correctly with the exact same lock-screen/notification pattern, this does look Brave-specific rather than an iOS-wide quirk. One possible mechanism (not confirmed, just a hypothesis) is that Brave may not be properly releasing a “keep screen awake” state after a notification interrupts background playback — but I don’t have any way to verify that without access to the app internals.
One more data point that might help isolate it: does the same thing happen if you play audio from a different site (not YouTube) while Brave is in the background? That would help tell whether this is specific to YouTube’s web player or affects background audio in Brave generally.
Worth flagging separately: I noticed you also posted “Bug Number 2” about audio ducking/silencing during background play without pausing. These look like two distinct symptoms to me (screen re-waking vs. audio silently dropping) — probably worth keeping them as separate reports rather than assuming one explains the other, so neither gets lost if only one turns out to be reproducible/fixable.
Also worth noting for anyone wanting to file this formally: brave-ios on GitHub was archived in May 2024 — the iOS codebase moved to brave-core, so that’s where a bug report would need to go for actual engineering triage, since this forum thread doesn’t seem to have any Brave staff involvement yet.
Thanks mel4 — that’s a useful data point about Safari behaving the same way with podcasts + locked screen.
I don’t have an iOS device myself, so I can’t run that test. If you have an iPhone/iOS device, you could try the podcast test yourself and see what happens — that would work too, not just Unicornfrog.
One thing worth trying in the meantime: Settings > Notifications > Show Previews > Never. Some iOS users report this stops notifications from waking the lock screen at all — I haven’t verified whether it also fixes the “screen stays on” part of this specific issue, but it’s a quick, reversible setting to test.
Agreed on the title edit — that’s for Unicornfrog to update since they opened the thread.
I just gave this a test! I opened my podcast site inside Brave, started the player, set a 1 minute phone timer (shoutout to LxWulf, to be fair!) and locked my screen.
What happened, surprisingly, was that the problem mirrored the other bug I reported. The player stopped playing, would not respond to the play button, and the screen stayed on and didn’t sleep. But this time, the audio player ghosted to blank, and didn’t list the name or author like usual.
Done!
If the previews are disabled, I’d have to unlock my phone voluntarily, several times a day, to manually check for my notifications, by their badge. This is even more effort, than using Brave to be the “hands off” benefit it’s promising, and I might as well not! I believe though, that Brave intends to be fully integrated and seamless, and hence why am here, to give feedback.
I can try it, yes? But I feel I’ve already gotten that benefit by engaging DND for nighttime use. I need something that works with my day use, that doesn’t need me to constantly intervene. Thank you for the suggestion, though.
Uhoh. I used the “Report a bug” from Brave settings, and it led me directly here? Which made me believe, this is the place they want errors to be shared? I sure hope they remember they did that, and check!! As for GitHub, I’ve never used it, and would have to find out.
That’s a really useful (if frustrating) test, Unicornfrog — confirms this isn’t YouTube-specific.
For what it’s worth: there’s a known (community-documented, not officially confirmed by Apple) WKWebView issue where the Web Audio API’s AudioContext gets suspended after the screen locks and doesn’t recover on its own unless the page explicitly handles it (closing/recreating the audio context, or suspend+resume on visibility change). That could explain both the unresponsive player and the blank “now playing” info — if the underlying audio context is dead, whatever JS updates that display probably isn’t running either. I can’t confirm that’s actually what’s happening in Brave’s case, just flagging it as a plausible mechanism worth someone checking against brave-core’s source.
OP provided in the comments, in case you don’t want to read the whole post:
Summary
Description of the issue:
Background audio in Brave prevents screen from sleeping after alerts.
Device:
iPhone 13, iOS 26.6.2, Brave (latest version from App Store).
Steps to reproduce:
Open YouTube video (music) in Brave browser.
I use the default YouTube site, and have tried both mobile and desktop version requests, to see if it will make a difference. It does not.
I opened my podcast site inside Brave, started the player, set a 1 minute phone timer and locked my screen.
Minimize browser / lock phone so audio plays in background.
Wait for any alert to arrive (message, app reminder, timer, etc.).
Observe that the screen turns on with the alert notification.
Expected result:
Screen should turn off after the alert is dismissed, returning to sleep state while audio continues in background.
Actual result:
Screen stays on indefinitely after any alert, even after dismissing it. This results in the phone screen staying on all night, draining battery significantly (e.g., 1% remaining after 8 hours of sleep).
In a locked screen, with no player: The display auto-closes after notifications like usual, if I’ve locked my phone.
Safari also behaves, while playing podcasts with the screen locked.
IF I am currently using Brave to play audio — right when another notification arrives, the screen awakes to trigger the peek. But it stays on, and doesn’t auto-close.
This is a Brave-only occurrence.
I opened my podcast site inside Brave, started the player, set a 1 minute phone timer and locked my screen.
What happened was that the problem mirrored the other bug I reported. The player stopped playing, would not respond to the play button, and the screen stayed on and didn’t sleep.
But this time, the audio player ghosted to blank, and didn’t list the name or author like usual. The other bug:
Workaround:
only work around so far, is to engage Do Not Disturb mode for 8+ hours.
For what it’s worth: there’s a known (community-documented, not officially confirmed by Apple) WKWebView issue where the Web Audio API’s AudioContext gets suspended after the screen locks and doesn’t recover on its own unless the page explicitly handles it (closing/recreating the audio context, or suspend+resume on visibility change). That could explain both the unresponsive player and the blank “now playing” info — if the underlying audio context is dead, whatever JS updates that display probably isn’t running either. I can’t confirm that’s actually what’s happening in Brave’s case, just flagging it as a plausible mechanism worth someone checking against brave-core’s source.
@Evan123 Please have a look at this issue. None of us here know what to do anymore and no one else helps.
Initial report & some
additional details
OP provided in the comments, in case you don’t want to read the whole post:
Summary
Description of the issue:
Background audio in Brave prevents screen from sleeping after alerts.
Device:
iPhone 13, iOS 26.6.2, Brave (latest version from App Store).
Steps to reproduce:
Open YouTube video (music) in Brave browser.
I use the default YouTube site, and have tried both mobile and desktop version requests, to see if it will make a difference. It does not.
I opened my podcast site inside Brave, started the player, set a 1 minute phone timer and locked my screen.
Minimize browser / lock phone so audio plays in background.
Wait for any alert to arrive (message, app reminder, timer, etc.).
Observe that the screen turns on with the alert notification.
Expected result:
Screen should turn off after the alert is dismissed, returning to sleep state while audio continues in background.
Actual result:
Screen stays on indefinitely after any alert, even after dismissing it. This results in the phone screen staying on all night, draining battery significantly (e.g., 1% remaining after 8 hours of sleep).
In a locked screen, with no player: The display auto-closes after notifications like usual, if I’ve locked my phone.
Safari also behaves, while playing podcasts with the screen locked.
IF I am currently using Brave to play audio — right when another notification arrives, the screen awakes to trigger the peek. But it stays on, and doesn’t auto-close.
This is a Brave-only occurrence.
I opened my podcast site inside Brave, started the player, set a 1 minute phone timer and locked my screen.
What happened was that the problem mirrored the other bug I reported. The player stopped playing, would not respond to the play button, and the screen stayed on and didn’t sleep.
But this time, the audio player ghosted to blank, and didn’t list the name or author like usual. The other bug:
Workaround:
only work around so far, is to engage Do Not Disturb mode for 8+ hours.
I’m here to let you know about one of the issues I’ve found.
,
I manually shut my screen off, every time, and know it will stay that way—which is part of the reason I noticed this bug happening! 
I used the “Report a bug” from Brave settings, and it led me directly here? Which made me believe, this is the place they want errors to be shared? I sure hope they remember they did that, and check!! As for GitHub, I’ve never used it, and would have to find out.