Looking back: Hancock's Half Hour and the COVID app fiasco
Five years on from the UK government's spectacular mishandling of its COVID-19 contact-tracing app, the episode stands as one of the most instructive — and avoidable — technology policy failures in recent British history. What was already apparent in real time has since been confirmed in exhaustive detail: the government wasted months, burned through public money, and repeatedly blamed Apple and Google rather than confront its own strategic errors.
TL:DR – The short version? Never pick a public fight with Apple. It never goes well. These are Apple-manufactured devices, it is Apple's App Store, and if Apple decides you are not in compliance, they will show you the door — politely, but firmly, and with the receipts.
Contents
- Looking back: Hancock's Half Hour and the COVID app fiasco
- What actually happened in 2020
- The full picture, confirmed by history
- Apple's App Review: the rules apply to everyone
- What the HEY Calendar rejection tells us about Apple's consistency
- How App Review actually works — and how to navigate it
- The enterprise certificate lesson — still relevant
- 2026 update: what has changed, and what hasn't
What actually happened in 2020
The UK government, led at the time by Health Secretary Matt Hancock, chose to build a centralised contact-tracing app rather than use the privacy-preserving, decentralised framework that Apple and Google had jointly developed and made available to public health authorities worldwide. The government's preferred approach required continuous Bluetooth scanning in the background — something Apple's iOS explicitly prevented for privacy and battery-life reasons, and which the Apple–Google Exposure Notification API was specifically designed to work around.
Rather than engage with Apple and Google early, the government pressed ahead, ran a trial on the Isle of Wight, and then — when the app failed to function reliably on iPhones — pointed the finger at Apple.
It is difficult to understand what these claims are as they haven't spoken to us.
When Hancock announced a pivot — claiming the UK would build a "hybrid model" combining the best of both approaches — Apple's response was equally blunt.
We don't know what they mean by this hybrid model. They haven't spoken to us about it.
The "hybrid model" was effectively dead on arrival. Any app that attempted to use background Bluetooth scanning outside the Apple–Google framework would not pass App Review, would not be eligible for the Exposure Notification API, and would not be published on the App Store. It took the government another three months — and a full abandonment of the centralised approach — to arrive at the same conclusion.
The full picture, confirmed by history
MIT Technology Review's subsequent investigation laid out the timeline in damning detail. The NHS app built on the centralised model detected only around 4 percent of contacts on iPhones during the Isle of Wight trial — a direct consequence of Apple's background Bluetooth restrictions. Engineers working on the project were aware of this limitation from the outset. The decision to press ahead regardless was political, not technical.
The app could not do what the government said it could do. The operating system restrictions were not a surprise — they were documented, publicly available, and had been flagged internally. The decision to continue was made at a political level.
The eventual NHS COVID-19 app — rebuilt on the Apple–Google Exposure Notification framework and launched in September 2020 — worked. It was downloaded tens of millions of times and functioned as intended. The months lost to the centralised approach, however, cannot be recovered.
Apple's App Review: the rules apply to everyone
One of the most persistent misconceptions in this episode — and in technology policy more broadly — is that Apple's App Review guidelines are negotiable for sufficiently important or sufficiently large organisations. They are not.
Apple's App Store Review Guidelines cover Safety, Performance, Business, Design, and Legal requirements in detail. They apply to every developer, from a solo indie building a niche utility to a national government deploying a public health tool. The guidelines are not suggestions. They are conditions of access to a platform used by hundreds of millions of people.
The COVID-19 Exposure Notification API came with additional requirements, documented publicly from the moment Apple and Google announced their partnership. Point 10 of Apple and Google's joint FAQ stated clearly:
Apps will receive approval based on a specific set of criteria designed to ensure they are only administered in conjunction with public health authorities, meet our privacy requirements, and protect user data.
This was public information, available for months before the government's public blame game began. The legal role holder within the primary organisation — in this case, a government department — was required to formally agree to these terms. The obvious questions at the time were: who held that role, and had those agreements been signed? The answers would have told us immediately whether this was Apple's failure or the government's.
What the HEY Calendar rejection tells us about Apple's consistency
The COVID app saga is not unique in illustrating Apple's willingness to reject high-profile submissions. In more recent years, Basecamp's DHH has continued his long-running and very public dispute with Apple's App Store policies. The HEY Calendar app was rejected from the App Store, with DHH documenting the experience in detail on his blog.
Apple rejected the HEY Calendar from their App Store. Same bullshit, different app. They want their 30% or they want you gone.
Whatever one's view of the underlying commercial dispute, the pattern is consistent: Apple applies its guidelines, and non-compliance — whether from a small startup or a well-funded government programme — results in rejection. The HEY Calendar rejection, like the original HEY email app rejection before it, demonstrates that neither public profile nor political pressure changes the outcome.
How App Review actually works — and how to navigate it
Mobile development teams who work regularly with the App Store understand the review process well. For those who do not, here is the practical reality.
Every release of every app goes through App Review. A human reviewer, supported by automated tooling, examines the app's functionality and content against the published guidelines. Rejection notices specify the guideline breached and the steps required for resubmission. The process is thorough — Apple's reviewers will test every corner of an app, and they will find issues that developers have missed or chosen to overlook.
Common causes of rejection include:
- Missing or incomplete metadata in the App Store submission
- Failure to support current iOS versions or current device sizes
- In-app purchase implementations that do not comply with Guidelines 3.1.1 or 3.1.3
- Privacy declarations that do not accurately reflect the app's actual data collection
- Failure to provide App Review with working test credentials
If an app fails review a second time, the developer can appeal to the App Review Board — a significant internal escalation. In my experience, this process is more straightforward than it sounds, provided the developer approaches it professionally, explains their position clearly, and does not attempt to pressure Apple into changing its rules on the basis of business urgency or political importance. Those arguments carry no weight.
Existing published apps are generally left in place during a dispute, but the inability to push updates is a slow death sentence: apps that cannot be updated will eventually break on new devices and new OS versions.
The enterprise certificate lesson — still relevant
The Facebook enterprise certificate revocation of 2019 remains one of the clearest examples of Apple enforcing its developer programme terms against a major corporation without hesitation. Facebook had distributed apps to the general public using an enterprise certificate — a certificate intended solely for internal, employee-facing tools. Apple revoked it. Facebook's internal apps stopped working immediately.
The lesson is the same one the UK government learned the hard way: the rules exist, they are enforced, and the size or importance of the organisation in breach does not change the outcome.
2026 update: what has changed, and what hasn't
Since 2020, the regulatory environment around Apple's App Store has shifted considerably. The EU's Digital Markets Act has forced Apple to permit alternative app distribution and alternative payment systems within the European Union, and Apple has faced significant regulatory scrutiny in the UK, the US, and elsewhere. The App Store's commercial terms — particularly the commission structure — have been modified in response to legal and regulatory pressure.
What has not changed is Apple's approach to the technical and privacy guidelines that govern what an app is permitted to do on iOS. Background Bluetooth access, location data handling, privacy nutrition labels, and the requirements around sensitive APIs remain tightly controlled. A government or enterprise developer approaching Apple in 2026 with the same attitude that characterised the UK's COVID app programme — assuming that political urgency or national importance creates exceptions to published rules — would find the outcome identical.
The COVID-19 contact-tracing episode is now a case study in how not to engage with a major platform. The technology Apple and Google built was sound, was available, was documented, and was free to use. The failure was entirely one of political decision-making and institutional reluctance to engage with the platform on its own terms.
If there is a single lesson worth carrying forward into 2026 and beyond, it is this: Apple's guidelines are not an obstacle to be negotiated around or blamed when things go wrong. They are the conditions of access to one of the world's largest software distribution platforms. Engage with them early, engage with them honestly, and — if you find yourself in dispute — do it privately, professionally, and without a press conference.
