Establish the baseline and success evidence
A web-based approach to proximity experiences means visitors interact with beacons, NFC tags or QR codes through a browser rather than a dedicated native application. For QR codes, this is straightforward: the tag encodes a URL and the phone's camera or a QR reader opens it. For NFC, tapping a tag triggers the same URL redirect. For Bluetooth beacons, the path is less direct and depends on Web Bluetooth, which has significant constraints.
Progressive Web Apps add service workers, a manifest file and the ability for a visitor to "install" the site to their home screen. In a proximity context, a PWA can cache exhibit content, venue maps and wayfinding data so that a visitor who arrives with poor mobile signal can still access material triggered by NFC or QR. The PWA does not, by itself, solve the problem of detecting beacons in the background — that remains a native capability.
How each proximity technology reaches the browser
- QR codes: Encode a URL. The user scans with their camera or a reader app, and the browser loads the page. No special APIs are needed. This works on virtually every smartphone in use.
- NFC tags: Store a URL in an NDEF record. Tapping the tag with an NFC-capable phone opens the browser at that address. On Android this is reliable; on iOS, Apple requires the tag to conform to its Universal Links or App Clip framework, which adds a configuration step.
- Bluetooth beacons: The browser cannot passively scan for beacons. Web Bluetooth allows a page to connect to a specific beacon after the user explicitly taps a button and grants permission, but it cannot discover nearby beacons by itself. Background detection — the phone noticing a beacon and showing a notification — requires a native app or, on Android, a Physical Web approach that Google has effectively deprecated.
The practical implication is that a web or PWA strategy works well with QR and NFC but cannot replicate the passive, walk-up beacon experience that a native app provides. If your use case depends on a visitor receiving a notification simply by entering a zone, the web path alone will not achieve it.
Make decisions using comparable evidence
Museum and gallery exhibit information
NFC tags fixed to display cases or QR codes on labels can link directly to a mobile-optimised web page with text, images, audio descriptions and video. A PWA can pre-cache content for an entire gallery so that a visitor who taps an exhibit in a basement room with no signal still receives a full response. The service worker downloads updated content when connectivity is available, so curatorial changes propagate without the visitor needing to update anything.
For accessibility, the web page can offer adjustable text size, screen-reader-compatible markup and alternative text for images without requiring platform-specific accessibility frameworks. This is a genuine advantage over building separate native layouts for iOS and Android.
Retail product information and offers
A QR code on a shelf edge label or an NFC tag on a product fixture can open a page showing stock levels in nearby sizes, care instructions, compatibility information or a time-limited offer. Because the URL can be dynamic, the same physical tag can serve different content at different times — a morning coffee promotion versus an afternoon sandwich deal, for example — without anyone touching the hardware.
The limitation is that the retailer has no way to know a customer is near the fixture until they scan. There is no pre-emptive notification. For some retail environments that is acceptable; for others it defeats the purpose of proximity technology.
Event schedules and venue wayfinding
QR codes printed on lanyards, signage and table tents can link to a PWA that stores the event programme, floor plan and session times. Attendees install the PWA once and then have offline access for the duration of a multi-day conference. NFC checkpoints at room entrances can log attendance or pull up the current session details, though this requires the NFC tag to encode a URL with a session identifier rather than triggering a native app flow.
Service worker and caching strategy
For any PWA used in a venue with variable connectivity, the caching strategy matters. A cache-first approach for static assets (images, audio files, the floor plan SVG) ensures instant loading. A network-first approach for dynamic content (live session status, stock levels) ensures freshness when the network is available and falls back to cached data when it is not. The decision about which resources follow which strategy should be made during planning, not left as a default.
Acceptance, records and review triggers
Assuming Web Bluetooth replaces a native beacon SDK
Web Bluetooth requires the user to tap a button, select a specific device from a list and grant a permission prompt. It cannot scan silently in the background. On iOS, Web Bluetooth support remains limited compared with Android. If a supplier pitches a "no-app beacon solution" that relies on Web Bluetooth, ask specifically how the visitor discovers the beacon without already being on a web page that triggers the connection. If the answer involves the visitor typing a URL or scanning a QR code first, the beacon is not providing the initial discovery — the QR code is.
Neglecting iOS NFC behaviour
On Android, an NFC tap to a plain URL tag opens the browser directly. On iOS, Apple's NFC reader behaviour has changed over time and currently routes NFC taps through system-level handling that may prioritise Apple Pay, App Clips or system prompts over a simple browser open. Test every NFC tag type and URL pattern on both platforms before committing to a hardware order. If the tags do not behave consistently on iOS, the experience will fail for a large share of visitors.
Building a PWA without testing offline behaviour
A common fault is developing a PWA on a desk with strong Wi-Fi, deploying it, and only discovering at launch that the service worker did not cache critical assets because the cache-busting strategy invalidated them on every deploy. Before any go-live, put a phone in aeroplane mode, clear the site data, load the PWA once with connectivity, then enable aeroplane mode and tap an NFC tag or scan a QR code. If the page does not load, the caching is not working.
Overlooking the permission prompt fatigue
If a web page requests location access, notification permission and Bluetooth access in quick succession, visitors will dismiss the prompts. Map out every permission your PWA needs, decide which are genuinely required for the core experience, and delay non-essential requests until the visitor has received clear value. For a museum audio guide triggered by NFC, no permissions beyond the default browser behaviour may be needed at all.
Key checks before committing to a web or PWA build
- Does the use case require passive detection, or is an explicit scan or tap acceptable?
- Have NFC tags been tested on both iOS and Android with the exact tag type and URL format you intend to use?
- Does the PWA service worker correctly cache all content needed for an offline experience, verified by testing in aeroplane mode?
- Have permission prompts been sequenced so that visitors are not asked for multiple permissions before receiving any value?
- If beacons are part of the plan, is there a clear mechanism for the visitor to reach a web page that can then use Web Bluetooth, or is the discovery step unexplained?
- Is the dynamic URL backend (for QR and NFC) capable of handling peak concurrent requests at your busiest hour without degradation?
- Has the PWA been tested on the range of devices and browser versions your visitors actually use, rather than only on recent flagship phones?
Web and PWA approaches remove the barrier of asking visitors to download an app, which is a meaningful advantage for one-off visits, transient events and public institutions where install rates would be low. The trade-off is that certain proximity capabilities — particularly background beacon detection and rich push notifications — remain available only through native applications. Understanding that boundary clearly, rather than discovering it during deployment, is the central practical decision in this part of the technology choice.
