The Device Decides The Form Factor

Mostafa Dhouib·9 min read

The Device Decides The Form Factor

The short answer. On one of the two major mobile platforms, no browser exposes the web interface needed to talk to a Bluetooth Low Energy peripheral. Not the default browser, and not the alternatives, because the platform requires them all to use the same underlying engine, so an alternative browser inherits the same gap. The consequence is blunt. If a connected device is anywhere on your roadmap, a browser-only product cannot reach it, and no amount of engineering effort on your side changes that. This is a platform decision, not a preference. Establish constraints of this kind before design starts, because they decide the form factor, the team you need and the release plan.

A team came to me with a web application and a device on the roadmap for the following year. The plan was to add device support later, which sounded reasonable until you look at what "later" required, which was a second product in a different technology on a different release process.

The mechanism

Reaching a Bluetooth Low Energy peripheral from a web page requires a browser interface for discovering devices, connecting, and reading and writing the characteristics defined by the peripheral's GATT profile. The standard for that exists. It is implemented in some browser engines and not in others.

On one major mobile platform the relevant interface is not available. That is the first fact and it is not the interesting one. The interesting one is why installing a different browser does not help.

That platform requires every browser to use the platform's own web engine. A browser shipped by a different vendor is, for rendering and web platform features, the same engine with a different interface around it. So whatever web capabilities the platform engine lacks, every browser on that platform lacks.

This is why the usual workarounds do not apply. You cannot tell the user to install a different browser, because there is no different browser in the sense that matters. You cannot polyfill it, because a polyfill is JavaScript and the capability it needs does not exist in the runtime. You cannot proxy it through a server, because the radio is on the handset and the server cannot reach it. You cannot use a different transport over the same radio, because the platform does not expose raw radio access to web content either.

The only route from web content to that radio is a native application that holds the Bluetooth connection and passes data to whatever interface you present. Which means that if a peripheral is in scope, a native component is in scope, and that is settled by the platform rather than by your architecture discussion.

Flags and experimental settings have existed at various times, as have third-party browsers that add the capability outside the standard web engine by other means. None of these are a basis for a product that patients or clinicians are expected to use, and the current state of all of it must be re-verified against current platform documentation and release notes at the time you build, not inherited from an article. The structural fact, that all browsers on that platform share the platform engine, is the part that has been stable.

What follows from it for planning

Once you accept the constraint, a set of decisions that looked independent turn out to be one decision.

Form factor. Either a native or hybrid application on both platforms, or a web application plus a separate native companion that owns the device link. There is no browser-only option that includes the peripheral.

Team. A native component needs people who can build, sign, submit and maintain mobile applications, which is a different skill set and a different release cadence from web deployment. In a regulated product it is also a different verification burden, because the device link is usually where the safety-relevant behaviour lives.

Release process. Store review sits between your build and your users. That changes how you ship fixes, which matters most for the one thing you most want to be able to fix quickly, which is the device communication layer.

Scope sequencing. Doing the web product first and the device later is not adding a feature. It is starting a second product, with its own release pipeline and its own verification evidence. If the device is certain, the honest plan builds the native shell early even if its first version only wraps the web interface, because that way the device work is an addition to something that exists.

The data question comes with it. A device link produces telemetry that nothing else holds, which makes your product the system of record for it whether you planned that or not. That is the per-datum decision described in the most important screen is a database decision, and it arrives attached to the form factor choice.

How to establish constraints like this before design

The Bluetooth case is just the clearest example of a class. The class is: a single external fact, outside your control, that makes a plan impossible. The useful habit is a short, deliberate search for those facts at the start of a project.

Write down every external capability the product depends on. Not features. Capabilities that something other than you must provide. Radio access, background execution, notifications with a given reliability, camera at a given frame rate, local storage of a given size that survives eviction, file system access, precise location while backgrounded, secure element access, printing, offline operation.

For each one, name the specific platform or vendor interface that provides it. This is the step that converts a vague assumption into something checkable. "We will connect to the device" is not checkable. "We will use this interface, on these platform versions" is.

Check it against primary sources, in the version you will ship on. Platform documentation, release notes and support tables, not blog posts and not the memory of someone who did it on the other platform. Capability support is version-specific and platform-specific, and the answer you want is specific to both.

Test the capability on real hardware before design, not after. A one-week spike that connects to the actual peripheral from the actual platform is the cheapest money in the project. Documentation tells you a capability exists. It does not tell you it works reliably under backgrounding, after a reconnect, with your specific peripheral's profile, on an older operating system version your users still run.

Record the finding with a date and a source, and plan to re-check. Platform capabilities change in both directions. A finding without a date is unusable in a year.

Then ask the single question that makes this worth doing. What one external fact, if true, makes this plan impossible? Ask it of the platform, of the data access you are assuming, of the third-party interface you have not read the terms for, and of the regulatory classification you are assuming. The answer is usually either "nothing we can find" or something that changes the project completely, and the cost of asking is a few days against the cost of finding out in month eight. This is the same discipline as proving data access before you build, applied to device capability.

The honest limit

Platform capability is a moving target, and this is the article most likely to go out of date. The structural reason behind the constraint, that one platform requires all browsers to use its own engine, has held for a long time, and it is what makes the gap unworkaroundable rather than merely inconvenient. If that changes, the specific conclusion changes with it. Verify current support before you make a decision, and treat anything in experimental or flagged status as unavailable for a product people depend on.

The constraint also only binds if the peripheral connection must happen on the handset. Some products legitimately avoid it. A device with its own network connection can send data directly to your backend, with the application never touching the radio. A device that syncs through a vendor's own application and exposes data through an interface moves the problem to that vendor's terms and reliability, which is a different risk rather than no risk. A clinical workflow where a bridge device sits in a clinic is another route. Each of these is a real option and each trades the capability constraint for a dependency.

And the general habit has a failure mode. Looking for the one fact that kills a plan can turn into looking for reasons not to start. The discipline is to timebox it, write down what you found with sources and dates, and then build. A few days of capability verification is cheap. A quarter of feasibility analysis is a different and worse problem.

FAQ

Can a web page connect to a Bluetooth device on mobile? On one of the two major platforms, no. The web interface for discovering and connecting to a Bluetooth Low Energy peripheral and reading its GATT characteristics is not available in any browser there, because the platform requires all browsers to use its own web engine. On the other platform it is generally available, which makes the gap easy to miss in development.

Why does installing a different browser not fix it? Because on that platform a browser from another vendor is the platform's own web engine with a different interface around it. For web platform capabilities it is the same runtime, so it has the same gaps. There is no alternative engine to install, which is why this is a structural constraint rather than a browser choice.

Is there a workaround on the server side? No. The radio is on the handset, so a server cannot reach the peripheral regardless of what you build. Polyfills do not help either, because a polyfill is JavaScript and the underlying capability is absent from the runtime. The only route is a native component on the handset that holds the connection and passes data to your interface.

What does this mean for a product that plans to add a device later? That the later work is a second product rather than a feature. It needs native build, signing and store submission, people with those skills, a release cadence gated by store review, and its own verification evidence for the safety-relevant communication layer. If the device is certain, build the native shell early even if its first version only wraps the web interface.

How do I find constraints like this before design? List every capability something outside your team must provide, name the specific platform interface that provides each one, check it against primary platform documentation for the versions you will ship on, and run a short spike against real hardware. Record each finding with its source and date, because capability support changes in both directions.

Are there product designs that avoid the constraint entirely? Yes, and they trade it for something else. A device with its own network connection can send data straight to your backend and never involve the handset radio. A device that syncs through a vendor's application moves the dependency to that vendor's interface and terms. A clinic-side bridge device is another route. None of them removes the dependency, they relocate it.