How Mobile Browsers Work: Camera, Permissions, Quirks

Engines behind phone browsers, CPU and memory limits, the changing viewport and keyboard, frozen tabs, camera access, permission prompts and cross-browser…

Mobile browsers: common questions

Does Chrome on iPhone use the Chrome engine?

No. On iPhone and iPad, Chrome, Firefox and Edge use Apple’s WebKit engine, the same as Safari (the EU has allowed other engines since iOS 17.4, but WebKit is still what most users get).

Why does the camera prompt not appear?

Common causes: the page is not on HTTPS, the phone’s settings block the browser app from the camera, the site was blocked earlier, or an in-app browser does not allow camera access.

Can a website ask for a permission again after the user blocked it?

No. Once blocked, the browser stops showing the prompt. The user has to change it in the site settings, so ask only at the moment of need and offer a fallback.

Related chapters

Keep learning

Overview

Chapter 74 · mobile browsers On a phone, your page is a guest on someone else’s device A small, hot, battery-powered computer with a slow CPU, little memory, a keyboard that covers half the screen, and an operating system that can freeze your tab at any moment. Add camera prompts and two very different browser engines. This chapter walks through all of it, without a line of code. Samsung Internet not on iPhone In-app browsers (Instagram, Facebook, TikTok, LinkedIn…) Android System WebView (Blink) WKWebView (WebKit)

1. Who is really drawing your page

A browser is two things: the app (address bar, tabs, menus) and the engine that turns HTML and CSS into pixels and runs JavaScript. On a phone, the name on the icon often hides which engine you get. Browser app Engine on Android Engine on iPhone / iPad What the engine rule means in practice “It works in Chrome” does not mean it works in Chrome on iPhone: that Chrome uses Safari’s engine, with Safari’s bugs and features. On iPhone, testing Safari covers almost every browser your users have, because Apple’s rules made all of them use WebKit. In-app browsers are a third world: the app decides what is allowed (camera, downloads, pop-ups, sign-in) and shares no cookies with the real browser. Since iOS 17.4, the EU allows browsers with their own engines on iPhone. Outside the EU, and for most users even inside it, WebKit is still what runs your page on Apple devices.

2. The phone’s budget is not your laptop’s

CPU: the same JavaScript, several times slower The same script on a developer laptop finishes quickly. On a mid-range Android phone it runs several times longer and blocks taps. mid phone same script · taps wait Phone chips are designed to save battery, and most of the world uses mid-range or older Android phones. A bundle that feels instant on your laptop can freeze the screen on theirs. Budget for the slow phone, not the developer’s. Memory: the OS will take it back Many tabs and apps compete for memory. The operating system freezes, then discards background tabs. Coming back reloads the page. tab in background memory pressure tab discarded user returns → reload Phones have a few gigabytes for everything: other apps, the camera, the OS. When memory runs short, background tabs are frozen and then thrown away. Big images, huge lists and memory leaks make your page the first one to go. Heat and battery Performance starts high and drops after the phone heats up, as the chip slows itself down. first minute full speed after 10 min A phone has no fan. After a few minutes of heavy work (video, animation, the camera) it slows itself down to cool off. Low-power mode slows things further. Long-running work must stay light. Network: fast, then gone The same user over a day: Wi-Fi, 4G, a lift, then 5G. home Wi-Fi 4G on the move in a lift Mobile networks switch between towers and lose signal in lifts and trains. Latency, not bandwidth, is usually the problem: each round trip can cost hundreds of milliseconds. Fewer requests and graceful offline states matter more than raw speed.

3. The screen keeps changing size

On a laptop the window has one size. On a phone, the address bar slides away as you scroll, the keyboard covers half the screen when you type, and the notch and home bar eat into the corners. Play with the phone and watch what a “full height” layout and a button pinned to the bottom do. Browser toolbars shown (top of page) hidden (scrolled) open (typing) Safe area (home bar, notch) of the screen is really visible “full height” box under home bar bottom “Pay now” button With the toolbars shown, a box sized to the full screen height runs under the bottom toolbar. CSS now has small, large and dynamic viewport units, so a layout can choose which height it means. With the toolbars hidden, the button sits on the home bar, where a swipe means “go home”. Respecting the safe area keeps tap targets clear of it. Everything fits in this state. Change the toolbars or open the keyboard: one design must survive every state. Viewport rules of thumb Assuming the screen height is fixed: the visible area changes on every scroll and every keyboard open. Decide which height a section means (smallest, largest or current), and keep key buttons in the normal page flow where the keyboard cannot bury them. Keep tappable things out of the notch and the home bar (the “safe area”), especially in landscape.

4. Fingers, not a mouse

There is no hover Hover menus versus tap Menu opens on hover: on a phone the first tap “hovers”, the second tap clicks, or it never opens. Menu opens on tap, and closes on a second tap or outside tap. A phone can ask “does this device have a fine pointer and hover?” and the answer is no. Anything only reachable by hovering (tooltips, menus, previews) is invisible to touch users. Big enough to hit Tap target size easy to hit A fingertip covers about 1 cm. Apple suggests 44 points and Google 48 density-independent pixels for tap targets, with space between them. Small, crowded links cause wrong taps and rage taps. Typing on glass Tell the browser what the field is for, and it shows the right keyboard and autofill. number pad autofill / SMS code Fields can say what they hold (email, phone, one-time code, address). The phone then shows the right keyboard and offers autofill, including SMS codes. On iPhone, text smaller than 16 px in a field makes Safari zoom in when it gets focus. No more 300 ms delay, if you say so Old behaviour: a tap waited about 300 milliseconds to see if a double-tap zoom followed. With a mobile viewport set, taps fire right away. no viewport mobile viewport Phones used to wait about 300 ms after a tap in case it became a double-tap zoom. A page that declares itself mobile-friendly (width equals the device width) gets instant taps in every current browser.

5. Your page can be frozen or killed at any time

Page lifecycle on a phone: active, then hidden when the user switches app, then frozen with timers stopped, then possibly discarded. Returning either resumes or reloads. Hidden: the user switched app or locked the phone. This is the last moment you can rely on. Save drafts and send analytics now. Frozen: timers stop, network requests pause. Nothing runs. Video and audio may be stopped. Discarded: to save memory the OS throws the tab away. When the user comes back, the page reloads from scratch, so unsaved form input is gone unless you stored it. Back and forward: browsers keep recent pages in a “back-forward cache” and restore them instantly. Some patterns (for example, listening for the page being closed) block that cache and make “back” slow. Lifecycle rules Waiting for “the page is being closed” to save: on phones that moment often never comes, because the tab is simply frozen or killed. Save on “the page became hidden”, keep forms restorable, and expect to be resumed or reloaded. Safari on iPhone Chrome on Android a home-screen web app on iPhone No camera: the page is not secure camera feature missing Camera, microphone and most powerful features only exist on secure pages (HTTPS). On plain HTTP the browser does not even offer them, so no prompt ever appears. No camera: the phone has blocked the whole app site asks OS: app has no camera access No camera: this site was blocked earlier blocked before no prompt Once a user blocks a site, the browser will not show the prompt again. Asking again just fails silently. On iPhone the user changes it from the page settings menu next to the address, or in Settings for the browser. On Android the user changes it from the lock icon next to the address, under site settings. Design for this: explain how to re-enable, and offer a fallback such as uploading a photo. user taps “Scan” page loads Maybe: it depends on the app app decides camera, if the app allows prompt, if the app allows In-app browsers are web views controlled by Instagram, Facebook, TikTok and others. The app needs its own camera permission AND must allow web pages to use it. Some do, some do not, and it changes between versions. Detect failure and offer “Open in your browser”, plus a photo-upload fallback. Camera on already allowed camera on · indicator lit Chrome remembers the decision for this site (unless the user chose “only this time”). On iPhone the site setting is often “Ask”, so Safari may ask again on a later visit even after an allow. Do not assume a grant lasts forever. Prompt in context, likely allowed Prompt out of nowhere, often denied browser prompt user allows user confused camera on Many browsers now offer “only this time” or ask again on later visits. Ask each time you need it, not once at start-up. A camera prompt on page load, before the user did anything, feels suspicious. Many people tap “Don’t allow”, and then the site is blocked for good. Some browsers also quiet or hide prompts that users keep rejecting. Ask only when the user taps something that clearly needs the camera.

6. Asking for the camera

A camera on the web goes through two locks: the phone must allow the browser app, and the browser must allow your site. Set up a situation and see what the user experiences. Safari · iPhone Chrome · Android In-app browser Home-screen app · iPhone Page served over plain HTTP Phone lets the app use the camera This site’s permission not decided Camera requested after a tap on “Scan” on page load

7. Camera decisions in production

Do you need a live camera at all? Photo picker versus live camera Need one photo (profile picture, receipt): a file picker that opens the phone’s own camera app. No permission prompt, full-quality photo, works in most in-app browsers. Need a live picture (QR scan, video call, AR, ID check): a live camera stream inside the page, with the prompt. The simplest camera is the phone’s own camera app, offered through a normal file upload button. It avoids prompts, odd preview sizes and most cross-browser issues. Reach for a live stream only when the product needs live video. Front or back, and how sharp The page asks for the back camera at a preferred size. The browser picks the closest camera and size the device really has. ask: back camera, ~1080p device has: 720p you get: 720p You can ask for the user-facing (selfie) or environment-facing (back) camera and a preferred size and frame rate. These are wishes, not orders: phones with several lenses, older phones and laptops pick what they can. Always read back what you actually got. The preview on iPhone Camera preview on iPhone Preview not told to play inline: iPhone jumps into a full-screen video player. Preview set to play inline and muted: it stays inside your layout and starts without a tap. Safari on iPhone treats the camera preview like any video: it must be allowed to play inline, and muted video starts on its own. Get that wrong and the preview opens full screen or stays black. Release it Camera light stays on until the page stops the stream, not when the scan screen closes. scan screen camera, forgotten still on · battery + light camera, released Only one user of the camera A video call app holds the camera. The web page asks and gets a camera-busy error. call app holds camera page asks “camera busy” If another app or tab is using the camera, the request fails with a “could not start” or “busy” error, not a permission error. Tell the user what to close instead of saying “permission denied”. Inside an iframe Camera inside embedded frames camera works iframe, no allowance iframe, camera allowed by parent An embedded frame (a payment or ID-check widget) cannot use the camera unless the parent page explicitly allows that feature for it. The same applies to microphone, location and more. Third-party widgets fail silently without it. Privacy by design Frames are processed on the phone. Only the result, such as the scanned code, goes to the server. camera frames decode on device send only the result Decide what leaves the device. For a QR or barcode scan, process frames on the phone and send just the code. Say clearly on screen why you need the camera before the prompt appears.

8. Permissions in general

Every permission passes two locks: the phone's settings for the browser app, then the browser's setting for your site. your site lock 1: browser’s site setting lock 2: phone allows the browser camera / location / mic Each permission is in one of three states for your site: not decided yet, allowed, or blocked. Only “not decided” shows a prompt. A block is sticky, so the cost of a badly timed prompt is permanent. What each platform offers to web pages Safari · iPhone Chrome · Android camera & microphone yes, prompt push notifications motion sensors needs a prompt no prompt install prompt manual: Share → Add browser offers it Bluetooth, USB, NFC

Asking well

Explain first, then ask A screen in your own design explains the benefit. Only if the user agrees does the browser prompt appear. your screen: “Scan to pay” user taps Continue browser prompt The browser prompt is short and scary. Show your own screen first that says what you need and why. If the user says no to YOUR screen, nothing is blocked and you can ask again later. Plan for “no” Handling a denied permission Dead end: “Camera required” and nothing else. A way forward: upload a photo, type the code, or see how to re-enable. Every permission feature needs a fallback. Location can fall back to typing a city, the camera to uploading a photo, notifications to email. Ask less, ask later Prompts asked on first load are denied far more often than prompts asked at the moment of need. on first load no / ignored at the moment of need Never ask for several permissions at start-up. Browsers watch how often users reject a site’s prompts and may show them quietly or not at all. One permission, at the moment of need. Grants do not last forever A grant can become “only this time”, expire, or be reset by the user. only this time / expires asks again Many browsers offer “only this time”, reset permissions for sites you have not used in a while, or default to asking each visit. Check the current state every time instead of trusting what was true yesterday.

9. Cross-browser issues you will meet

Test the feature, not the browser name Detecting support Reading the browser’s name and version: in-app browsers and iPhone Chrome lie, and the list goes stale. Checking whether the feature exists right now, and offering a fallback when it does not. Browser names are a poor guide: Chrome on iPhone is really WebKit, and in-app browsers invent their own names. Check for the feature itself and design a simpler path when it is…

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
System Design — Core concepts first (SQL vs NoSQL, CAP, indexing, replication, sharding), then designs grouped by what carries them: the database, Redis, Kafka, or many services.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.