Not All Browser APIs Are Created Equal

Before diving into any specific API, there is one mental model worth locking in: web capabilities have maturity levels, and knowing where an API sits on that scale determines how safely you can use it.

What Is a Web Capability, Exactly?

A web capability is the ability of a browser or web app to perform a specific task using a built-in API. Rendering HTML is technically a capability. CSS layout is a capability. But when most people talk about "web capabilities," they mean the APIs that go beyond the basics: sensors, hardware access, OS integration, speech, and so on.

Worth noting: not every capability is a JavaScript API. Some work through HTML elements directly. For example, if you want the user to take a selfie, you can use <input type="file" accept="image/*" capture="user"> and the browser will open the camera without a single line of JavaScript. But the vast majority of modern capabilities are API-based, so that is where the focus lands.

The Web Is Multi-Vendor by Design

The web platform is not owned by any one company. Google pushes Chrome. Apple pushes Safari. Mozilla builds Firefox. Samsung, Opera, Brave, and others all have a say too. Because of this, you end up with a landscape where different browser vendors agree on some things and disagree on others.

This is not new. Web developers who have been around since the early 2000s have dealt with compatibility issues forever. The shape of the problem has changed, but the core reality has not: an API working in one browser does not mean it works in all of them.

Green, Light-Green, and Everything Else

Think of APIs as being sorted into rough maturity tiers:

Green APIs are stable and available in every major browser on every major platform. iOS Safari, Android Chrome, Firefox on desktop, Samsung Internet -- all of them. These are safe to use in production today. The one caveat is "when technically possible," because sometimes the API exists but the underlying hardware does not, or the user has blocked the feature in settings.

Light-green APIs are mature enough to use, but not universally supported. In practice, these work well on Chromium-based browsers: Google Chrome, Microsoft Edge, Samsung Internet. They are typically not available in Firefox or Safari. Today, Chromium-based browsers hold roughly 80% of the market, so this is a meaningful chunk of your audience -- but not all of it. For anything touching iOS users, light-green means not available.

There are also experimental APIs behind flags, APIs in origin trials, and APIs that are outright unsupported. Those come with stronger warnings.

The iOS Problem Nobody Talks About Enough

Here is something that catches a lot of developers off guard: Chrome on iOS is not Chrome.

It looks like Chrome. It has the Chrome icon. It syncs with your Google account. But under the hood, it is running on Apple's WebKit engine, the same engine that powers Safari. This is not Google's choice -- Apple requires that every browser published on the App Store use the built-in WebKit rendering engine (called WKWebView internally). Firefox on iOS has the same restriction. Every browser on iOS does.

What this means practically: if an API is Chromium-only, it will not work in Chrome on iOS either, because Chrome on iOS is not Chromium. It is effectively Safari with a different skin.

You can verify this yourself by checking Chrome's user-agent string on an iPhone. It does not contain the word "Chrome" -- it uses CriOS (short for Chromium for iOS) precisely to signal to backend developers that this is not standard Chrome.

The same logic applies to Safari updates. Safari on iOS does not update independently through the App Store. It ships with the operating system. To get a newer Safari, you update iOS itself.

This restriction may change. The EU, UK, and Australia are all applying regulatory pressure on Apple to open up the App Store to alternative browser engines. Both Firefox and Chrome have already started testing their own engines on iOS in open-source repos, preparing for the possibility. But as of now, if your user is on iOS, they are on WebKit regardless of which browser they chose.

Progressive Enhancement Is the Right Default

The design pattern that makes sense for web capabilities is progressive enhancement: build an app that works for everyone first, then layer in capabilities based on what the current browser and device actually support.

If the browser supports the Gamepad API, add gamepad navigation. If it does not, the rest of the app still works. If the device has a Bluetooth chip and the browser exposes the Web Bluetooth API, great. If not, the core experience does not break.

This is not just a nice-to-have. For hardware APIs especially, capability detection at runtime is how you avoid crashing the experience for users on unsupported browsers. Always check before you call:

The check takes one line. Skipping it can mean a broken app for a large portion of your audience.