Permissions and network conditions are the main failure points

What it is

The TV and the phone are on, Bluetooth is on, and the AirPlay list is still empty—because Local Network permission was never granted, or the two are not on the same Wi-Fi, or one of them is on a guest net. Permissions and network conditions are the main failure points. Cross-device discovery looks like a radio problem and is actually blocked by an OS grant and layer-2 topology. People reboot the television; they do not go hunting for a permission dialog that appeared once. Discovery can show progress; if the reason says “no devices found” rather than “no Local Network permission” or “not on the same network,” clearer progress still repairs the wrong thing.

Why it happens

The usual discovery channels—local-network multicast, Bluetooth, peer-to-peer Wi-Fi—each sit behind a system gate and behind network isolation. Mobile OSes make “look for nearby devices” a runtime permission; one deny becomes a long silent failure, and further scans stay empty. A router parks the phone on a guest VLAN and the TV on the main LAN; broadcasts die at the gateway, both “on Wi-Fi” and invisible to each other. Enterprise nets that disable multicast or turn on client isolation break meeting-room cast while every piece of hardware is fine. These conditions live outside the UI and present exactly like “nothing nearby.” The mental model people hold is device power, not a permission database and a subnet, so they toggle Bluetooth and pull the TV’s plug, spending the repair on the wrong path. Naming the actual gate aims the repair: grant that permission, join the same net, or drop guest isolation.

Where it stops holding

Pure Bluetooth accessories (headphones, a stylus) never use the LAN; failure lives in Bluetooth permission and the system Bluetooth switch, not Wi-Fi. Devices that already see each other through a cloud account (a signed-in computer and phone) can skip LAN discovery, so isolation is not this path’s failure. An explicit deny is a legitimate choice: stop scanning and say “without Local Network permission this phone cannot find the TV,” rather than a more aggressive sheet to harvest a yes. When cellular is up and Wi-Fi is not, some discovery must fail and some can take a vendor relay; do not write both failures as one sentence.

Applying it

• On an empty discovery list, check and show local gates first: Bluetooth off, Local Network denied, not on any Wi-Fi, VPN or guest net. Each item gets a deep link, not only “not found.”
• When the permission dialog appears, one sentence tied to the current task (“used to find TVs on this network”); after a deny, keep a repair entry on the discovery page.
• When both devices can show a network name, print it (“phone on Guest, TV on Home”). When names are unavailable, say that the same Wi-Fi is required and that guest nets usually will not work.
• Verify by denying Local Network, putting the phone on guest and the TV on the main LAN, and turning on client isolation. The three failures must produce three different reasons, each naming the gate that actually closed; they must not all read “no devices nearby.” Then grant the permission and join the same net: the target should appear, confirming the reason was not a guess.

Related

• Within the group: K8.05.1 Pairing is the highest barrier in a cross-device experience · K8.05.2 Discovery needs visible progress and failure reasons
• Adjacent: K1.12 Platform differences in permission models · K1.09 Power, data, and weak networks
• Search terms: Local Network permission · client isolation · AirPlay same network