An iPhone browser lets web pages talk to nearby Bluetooth devices and NFC tags
The early open-source app targets hardware web-app testing on physical phones, with a deliberately limited API bridge and short-lived permissions.
An iPhone web page can reach a Bluetooth gadget through Wand Browser. The open-source iOS app bridges a subset of Web Bluetooth and Web NFC into native hardware access, so a developer can try supported JavaScript against the device in front of them. The browser has picked up a wand, with an unusually specific spellbook.
The project’s README describes the working surface clearly. Bluetooth code can ask the user to select a device, connect to GATT services, read and write characteristics, and receive notifications through navigator.bluetooth. NFC code can read and write NDEF tags with NDEFReader. Those API names let a developer check a real application against the bridge before a promising demo turns into an afternoon of guessing.
The browser also supports permission-controlled camera video through getUserMedia, and keeps recent test pages in local history. The hardware features need a top-level HTTPS page with Wand in the foreground. A page buried in another document or an app sent into the background falls outside that stated operating condition.
The user picks which Bluetooth device a site can reach and approves NFC requests. The permission lifetime is short: loading another document, reloading, backgrounding Wand or revoking access in Site controls ends the hardware permission. A successful connection survives none of those events by implication. A developer who tests only the happy path could ship a very confident reconnect button.
The README calls this an “early version” and says it supports a subset of the APIs. It points developers to the bridge implementation for checking individual calls. NDEF support also has a defined scope: reading or writing an NDEF tag does not promise arbitrary NFC protocols, payment-card access or every operation a dedicated reader can perform.
The app requires iOS 18 or later. Its repository links an App Store listing and a TestFlight beta, plus a checked-in Xcode project for someone who wants to build it. The source is MIT-licensed. That makes inspection practical; it supplies no substitute for checking whether the specific hardware and calls you need are implemented.
The simulator limit is one of the most useful lines in the documentation: it can exercise browser flows and bridge logic, while the actual radios need a physical phone. A green interface test can establish that a permission screen appeared. It cannot establish that a sensor answered. The test needs the phone and the intended device close enough to connect, with a real response arriving through the bridge after permission is granted.
The maker documents a practical testing path: keep the supported page code, put the phone beside the real gadget, then see exactly where the permission and connection path stops. The remaining compatibility answer belongs to the device on your desk.
The simulator has no magic antenna.