Apple and Google Hand Developers the Exposure-Notification API

Today’s the day the Apple/Google contact-tracing partnership stopped being a slide deck and started being actual code you can build against. The first version of their exposure-notification API is now in the hands of public health authority developers, giving them a few weeks’ head start before the broader rollout expected in May.

If you missed the original announcement, the pitch is straightforward: use Bluetooth Low Energy to have phones log anonymous, rotating identifiers when they’re near each other for a meaningful stretch of time. If someone later tests positive and enters that into an approved app, everyone whose phone logged a matching identifier gets a notification. No GPS, no central location database — just a local log of “you were near someone” that never leaves your device unless you opt in to share a diagnosis.

What’s notable about today isn’t a new technical detail so much as the fact that it’s real now. Public health agencies (not random app shops) can start actually writing code, testing it, and finding the rough edges before this thing goes in front of a billion phones. That’s the right order of operations for something this sensitive — better to discover bugs and edge cases in a sandboxed developer release than after a national health service has already pushed an app to millions of people.

Why the staged rollout matters

Handing this to developers first, rather than shipping a consumer-facing app on day one, buys time to sort out questions that are still open: How do health authorities verify a positive test result without creating a new avenue for fraud? What’s the right proximity/duration threshold to flag as “exposure” without drowning people in false positives? How do you keep this genuinely opt-in and decentralized when multiple health authorities in different countries want to build on the same underlying primitive?

None of that gets answered by a press release. It gets answered by actual apps built by actual health departments hitting actual API limits and filing actual bug reports back to Cupertino and Mountain View. That’s presumably why we’re seeing an API drop for developers now instead of a finished app.

It’s also worth remembering this is opt-in at the OS level as designed — the API doesn’t turn on Bluetooth broadcasting by itself, and it’s supposed to only work through official public health apps rather than any app that wants to ask for it. Whether that restriction holds as pressure builds for wider access is one of the more interesting things to watch here.

The real test comes in May when this is supposed to open up more broadly and actual public-facing apps start appearing in various countries’ app stores. Adoption is going to be the whole ballgame — models of how effective contact tracing needs to be tend to assume a healthy fraction of a population is participating, and that’s a much harder problem than the Bluetooth handshake. But as a piece of engineering, getting two competing platform companies to agree on a common protocol in a matter of weeks and start shipping code to developers is not nothing. Worth watching closely over the next few weeks as the first real apps start testing against it.