Browser Permissions & WebRTC Diagnostics
How to Test Camera on Safari iOS When WebRTC Fails to Request Permission
When iOS Safari never shows a camera prompt at all, it's almost always one of three specific causes: the site lacking HTTPS, a previously saved "Don't Allow" decision for that site, or an active Screen Time restriction. All three are checkable and fixable directly from the iPhone or iPad's own Settings app.
Diagnosing iOS Safari WebRTC Failures
iOS Safari follows the same fundamental permission rules as its desktop counterpart, just accessed through a different interface. A prompt failing to appear at all — rather than appearing and then failing — is the key symptom this guide addresses, and it points at one of a small number of specific causes rather than a broad, unexplained malfunction.
HTTPS is required exactly as it is on desktop; a plain HTTP site will never trigger a camera prompt on iOS Safari regardless of anything else being configured correctly. A previously dismissed "Don't Allow" choice is remembered indefinitely per site, the same as desktop Safari, and won't prompt again until manually cleared. Screen Time content restrictions, if active on the device, can block camera access at a level above any individual site permission, silently preventing the prompt from ever appearing.
Step-by-Step Fixes for iPhone / iPad Camera Access
Step 1: Confirm the site uses HTTPS
— look for the padlock icon in Safari's address bar.
Step 2: Tap the "aA" icon at the left of the address bar
While on the specific site, then "Website Settings," and check whether Camera is set to "Deny."
Step 3: Change it to "Ask" and reload the page.
Step 4: Check the global default
At Settings app → Safari → Camera, and set it to "Ask" if it's currently "Deny."
Step 5: Check Screen Time restrictions
At Settings → Screen Time → Content & Privacy Restrictions, and confirm Camera access isn't specifically restricted there. ↑ Test with the widget above.
iPadOS Follows the Same Rules
Everything covered here applies identically to iPadOS as it does to iOS, since both share the same underlying Safari engine and the same Settings app structure for camera permissions — if you manage both an iPhone and an iPad, expect to work through this same checklist independently on each device, since permission decisions don't automatically carry over between them even when signed into the same Apple ID.
If you've verified all three causes above and the prompt still never appears, a full restart of the device itself is worth trying before assuming something more serious — iOS, like any operating system, can occasionally get a background permission-handling process into a stuck state that a simple app restart doesn't clear, but a full device restart reliably does.
Keeping iOS itself updated matters here too — Apple periodically refines exactly how Safari handles permission prompts and secure-context requirements across point releases, and a device running an older iOS version may be missing a relevant fix that a current, fully up-to-date release already includes. Checking Settings → General → Software Update takes only a moment and rules this out cleanly.
A Few More Things to Check on Mac
What are VDCAssistant and AppleCameraAssistant, and why do they matter for camera problems?
These are macOS’s own background processes for managing camera access — VDCAssistant coordinates the camera hardware itself, and AppleCameraAssistant works alongside it. If either one gets stuck, commonly after an app crashes without properly releasing the camera, every app can show the camera as unavailable until both are reset. Opening Terminal and running sudo killall VDCAssistant AppleCameraAssistant forces a clean restart of both, which resolves a large share of stuck-camera and black-screen issues that a simple app restart doesn’t fix.
What is UVCAssistant, and is it different from VDCAssistant?
On some macOS versions, Apple introduced UVCAssistant as an additional process specifically for USB Video Class (UVC) compliant external webcams — the standard most third-party USB cameras follow. If you’re using an external webcam rather than the built-in camera, and killing VDCAssistant alone doesn’t resolve a stuck camera, check Activity Monitor (View → All Processes) for UVCAssistant specifically and force-quit it the same way.
Does Apple Silicon (M1/M2/M3/M4) handle the camera differently than Intel Macs did?
Yes — Apple Silicon Macs route camera video through the chip’s own dedicated image signal processor rather than the path Intel Macs used, and the exact background processes involved can differ across specific Apple Silicon generations. If a fix written for an Intel Mac, or for a different chip generation, doesn’t fully apply on your machine, checking Activity Monitor’s actual running process list — rather than assuming a name from an older guide — is the most reliable way to identify what’s genuinely holding your camera.
Once this is fixed, testing your webcam online is a quick way to confirm the camera is fully working again, not just detected.