Inside the Apple-Google Contact-Tracing API, Ahead of Its Launch
A look at the Exposure Notification API before Apple and Google hand it to public-health agencies this week.
The Exposure Notification API that Apple and Google announced back in April is apparently just about ready to go live. Public-health agencies are expected to get access within days, which means the first wave of official COVID-19 exposure-notification apps built on top of it could show up not long after that.
Worth pausing on how unusual this collaboration is. Apple and Google are direct competitors in mobile OS and services, and they don’t typically build shared infrastructure, let alone ship it simultaneously across iOS and Android. But a pandemic-response tool only works if it works across both platforms, so here we are.
How it’s supposed to work
The core idea is decentralized proximity matching over Bluetooth. Phones running an app built on the API broadcast rotating, anonymous identifiers to nearby devices. If you later test positive and choose to report it through a participating health app, the identifiers your phone broadcast during the infectious window get uploaded. Other phones periodically check the list of reported identifiers against what they’ve locally recorded from devices they’ve been near, and if there’s a match, the user gets an exposure alert.
The notable design choice is what’s explicitly excluded: no GPS or location data, and no central server holding a map of who’s been near whom. Matching happens on-device. The identifiers are rotating and anonymous rather than tied to a persistent user ID. Apple and Google have been pretty insistent that this is opt-in and meant to support health-authority apps, not to be a surveillance tool or a standalone consumer app from either company.
Why this matters beyond the tech
A lot of early standalone contact-tracing apps from various countries and companies struggled specifically because of how iOS handles background Bluetooth — apps couldn’t reliably scan for nearby devices when not in the foreground, which cripples a system that depends on continuous background broadcasting. By baking this into an OS-level API instead of a third-party app, Apple and Google sidestep that limitation. That’s arguably the whole point of doing it this way rather than leaving it to individual health apps to solve on their own.
The catch is adoption. This only works if a meaningful share of the population installs a participating app and opts in, and only if health agencies actually build compatible apps rather than sticking with centralized designs they may already have in progress. There’s also an open question about how many separate regional apps will exist versus some kind of shared framework, and whether public trust in “no location data collected” claims will hold up once people start actually using this.
Still, having this ready to hand off to health agencies this week is a real milestone. The bigger test starts once actual apps built on it are in people’s pockets.