What is "Api Maturity Levels" about?

Not all browser APIs work everywhere. Green means all browsers, light-green means Chromium-only, Chrome on iOS is WebKit -- know this before shipping.

What topics does "Api Maturity Levels" cover?

This article covers: web API compatibility, browser API support, Chrome iOS WebKit, light-green APIs, progressive enhancement, feature detection.

Web API Maturity Levels: Green, Light-Green, Experimental

The first time I tested a capability "in Chrome" on my iPhone and it failed, I spent an hour debugging. The code was fine.

The problem was which Chrome I was testing in.

Not All APIs Are Created Equal

The web platform is built by multiple competing vendors. Google ships Chrome. Apple ships Safari. Mozilla ships Firefox. Each has its own priorities and its own pace for adopting new APIs.

The result is a spectrum of support. Some APIs work in every browser on every platform. Others work only in Chromium-based browsers. Others are still behind flags.

Knowing which tier an API belongs to is the first thing to check before shipping any capability.

Green: Safe to Ship Everywhere

Green APIs work in Chrome, Edge, Firefox, Safari, Samsung Internet -- every browser with a meaningful share of the market.

They have worked this way long enough that cross-browser behavior is reliable and consistent. You can ship a green API without conditional logic and trust it will work for the overwhelming majority of users.

The Geolocation API is green. Web Audio is green. The Media Capture API (camera and microphone access) is green. If the hardware supports the feature, a green API means the browser does too.

Light-Green: The Chromium Club

Light-green APIs work in Chromium-based browsers: Google Chrome, Microsoft Edge, Samsung Internet.

On desktop and Android, that covers roughly 75-80% of global browser usage. That sounds comfortable until you look at who it leaves out.

It excludes Firefox. It excludes Brave. It excludes Safari. Which means it excludes every iPhone and every iPad.

Web Bluetooth is light-green. Web NFC is light-green. Web Serial is light-green. WebHID is light-green. If a feature depends on any of these, every user on iOS or iPadOS -- and every Firefox or Brave user -- hits a broken path.

ExpandAPI Maturity Tiers

The iOS Browser Trap

Here is the insight that catches most developers once.

"Fine, Safari doesn't support it -- but my users have Chrome on their iPhones."

Chrome on iOS is not Chrome.

Every browser published in the App Store is required by Apple to use Apple's own rendering engine, called WebKit (technically WKWebView). Chrome, Firefox, Edge, Opera, Brave -- every one of them on iOS is running WebKit underneath. It is an App Store rule, not a product decision by those browser vendors.

The Chrome team specifically did not want backend and frontend developers to misidentify it. The user-agent string for Chrome on iOS does not say "Chrome." It says "CriOS" -- a deliberate signal that this is a WebKit-based shell, not Blink.

Testing a light-green API "in Chrome" on your iPhone is testing in Safari.

This restriction applies to iOS and iPadOS only. On Mac and Windows, Chrome is Chrome. On Android, Chrome is Chrome.

There is regulatory pressure from the EU, Australia, and the UK pushing Apple to open the platform. Some browser vendors are already preparing their own engines for that future.

But today, for any user on iPhone or iPad, Safari is the only real rendering engine running -- regardless of which browser icon they tapped.

Progressive Enhancement: The Right Response

The answer to uneven capability support is not to avoid light-green APIs. It is to build in layers.

Start with an experience that works for everyone. Then add capability-dependent features on top, gated by detection:

JavaScript

// Geolocation is green -- safe to rely on directly
if ('geolocation' in navigator) {
  navigator.geolocation.getCurrentPosition(updateMap);
}

// Web Bluetooth is light-green -- must degrade gracefully
if ('bluetooth' in navigator) {
  document.getElementById('bluetooth-section').hidden = false;
}

A user without Bluetooth support sees a clean page without a broken section. A user with it gets the enhanced experience. The capability is additive, not required.

This is not a workaround. It is the intended design pattern for the web's multi-vendor, multi-platform nature.

Before Shipping Any Capability

Run through three checks before reaching for any browser API:

What maturity tier is this? (See the web capabilities landscape for the full map.)
Does the experience degrade gracefully when the API is absent?
Have I tested on an actual iPhone, not just desktop Chrome?

The third check sounds obvious. It catches people constantly. The detection pattern itself -- how to check for any given API before using it -- is covered in the red APIs and feature detection post.

Next: there is a third tier beyond light-green -- APIs not yet available to regular users, but testable in production through a system called origin trials.

The Essentials

Green APIs work in every major browser. Light-green APIs work in Chromium-based browsers only -- not Firefox, not Brave, not Safari, and not any browser on iPhone or iPad.
Chrome on iOS is not Chrome. Apple requires all iOS browsers to use its WebKit engine, so Chrome, Firefox, and Edge on iPhone all run the same Safari internals. Testing on iOS Chrome is testing on Safari.
Progressive enhancement is the correct response: gate capability-dependent features behind existence checks so the experience degrades gracefully for unsupported browsers.

Api Maturity Levels