Mobile web app explained: what runs in the browser, and what does not
A mobile web app is an application that runs inside a phone's browser and is reached through a URL rather than installed from an app store, using the same web technologies as a website but built around the interaction patterns and screen size of a phone.
The practical difference from a native app is the first thirty seconds. A link opens, nothing downloads, nothing asks for an account, and the person is already in the thing you sent them to.
What does mobile web app mean in practice?
- No install. Distribution is a link, so it travels over SMS, WhatsApp, email or a QR code, and it works for someone who will use it once and never again.
- No app store. No review queue, no version fragmentation, no users sitting on a build from eight months ago. You deploy, and the next person to open the link gets the new version.
- One codebase. The same app serves an iPhone, an Android handset, and the tablet on the workshop desk.
The trade for all three is that you are inside the browser's sandbox. That is where the honest evaluation starts.
How does a mobile web app use the phone's camera?
There are two routes and they behave differently.
The simple one is a file input carrying a capture hint. The page asks for a photo, the operating system's own camera opens, the person shoots, and the file comes back. MDN's reference for that attribute is explicit that it is a hint rather than a guarantee: if the requested facing mode is not available, the browser may fall back to whatever it prefers.
The second route is getUserMedia, which hands the page a live camera stream it can display, overlay with on screen guidance, and grab frames from. It requires HTTPS and an explicit permission prompt from the person holding the phone. This is how in browser guided capture is normally built.
What a mobile web app cannot do with the camera
Fine grained camera control, meaning full sensor resolution stills, torch, and focus distance, lives in the ImageCapture API. According to the compatibility data published on caniuse.com, ImageCapture is supported in Chrome from version 59 and is not supported in any version of Safari, on macOS or on iOS.
So the same web app can switch the torch on for an Android user and cannot for an iPhone user. Anyone writing "the flow must turn the flashlight on for the underbody shot" into a specification needs that fact before they write it, not after.
Beyond the camera controls: a mobile web app cannot record in the background or with the screen off, cannot reach depth sensors or LiDAR, cannot get raw sensor data, and generally loses its camera permission and its in progress state if the tab sits in the background long enough. None of that is a bug waiting for a workaround. It is the sandbox doing its job.
Mobile web app vs native app: how to choose
The question that settles it is how often the same person will use the thing.
- Choose the mobile web app when the user is external, not known in advance, and will use it once or twice. An install requirement standing in front of a one time task is where most of the audience is lost, and it is lost silently.
- Choose native when the user is a trained employee opening it daily, or when you genuinely need background work, hardware control, offline by default, or an on device model.
- Watch the middle. Contractors and repeat customers sit awkwardly between the two, and a progressive web app is the usual compromise. Read what it does and does not fix before assuming it closes the gap.
Mobile web app example: a one time capture link
An insurer sends a claimant a link by SMS. It opens in Safari, asks for camera permission once, walks through eight steps with an instruction on each, and uploads. The claimant never creates an account and never opens it again.
A native app would have given the insurer better camera control and worse completion, because a proportion of claimants would have stopped at the app store. For a once in three years interaction, that is not a close call.
Where this matters in visual capture
This is the whole reason a capture link opens in a browser instead of asking a customer to install something. Venta Capture, a product of VentaVid, runs its guided capture in the mobile browser with no app and no account, because the person on site is usually doing it once. The trade is the one described above: the browser's camera, with the browser's limits, in exchange for far more people actually starting. What the organisation controls instead is the capture flow, which is where most of the quality difference lives anyway.