On CMA’s proposed NFC access conduct requirement for Apple’s iOS

If the title of this post didn’t get your pulse quickening, you’re probably in a coma. Sorry if it’s a bit clickbaity.

On Tuesday, the daring, dauntless and doughty defenders of digital diversity at the UK’s competition regulator published their Proposed NFC access conduct requirement for Apple’s mobile platform.

You might be wondering why contactless tap-to-pay is interesting for anyone outside Fintech, but actually NFC is a browser-adjacent technology, or should be: WebNFC was specified by some nice folks in Intel and is shipping today (or imminently) in Chromium browsers on Android. Not WebKit on iOS, of course.

But also, it’s interesting to see what sort of Conduct Requirements we can expect from CMA after it previously accepted Apple’s pinky promises not to be anti-competitive. So naturally, I devoured the 147 page document like a TERF with a new Harry Potter book. It immediately gave me a pervasive feeling of deja vue:

In October 2024 Apple made its ‘NFC & SE Platform’ available in the UK and other jurisdictions. …
However, two years after the platform became available there is still no evidence of NFC apps launching in the UK using the platform. Stakeholders have raised concerns that current access may not be commercially viable, that fees and non-pricing terms may be onerous, that divergent technical approaches across jurisdictions and platforms can make it harder to scale, and that limits on default status information may weaken developers’ ability to compete effectively.

if that sounds familiar, it’s because that’s very similar to the situation with non-WebKit browser engines in the EU and Japan. Browser vendors who want to ship a different engine in those countries are required to sign a Web Browser Engine Entitlement ^[PDF] (WBEE) that gives Apple draconian and arbitrary power. The APIs that the browsers depend on can be removed on a whim:

WBEE 5.1: Apple may at any time, and from time to time, with or without prior notice to You, modify, remove, or reissue … the Alternative Web Browser Engine APIs, or any part thereof

and Apple may kill any competitor non-WebKit browser “for any reason” and “in its sole discretion”:

WBEE 4.2: You acknowledge and agree that Apple may, in its sole discretion, reject, or cease distributing Your Alternative Web Browser Engine App (EU) for any reason

CMA’s proposed conduct requirements of Apple, if applied to browser engines, would blow such anti-competitive tomfoolery out of the water:

Apple must ensure that the NFC Access provided to an Authorised Developer is
and remains effective … not impose an unjustified restriction of any nature which may undermine the effectiveness of the NFC Access, whether directly or indirectly, or through an act or omission.

This includes, for example, technical or procedural barriers by way of contractual terms, technical design requirements, app review processes and enforcement practices. Subject to the exception set out in this paragraph, Apple must provide NFC Access to an Authorised Developer on a continuous basis, without restriction, suspension or other interruption.

Developer testing and accessibility

In the EU and Japan, Apple is obliged to allow non-WebKit browser engines, but not outside. This creates a major headache for web developers: those outside those countries will not be able to test how their sites behave on a non-WebKit iOS browser unless they jump on a plane. Apple told us that web developers should hire an in-region testing consultancy, and that “Apple does this all the time”, perhaps forgetting that Apple is a $5 Trillion dollar company.

The European Accessibility Act requires covered services to “mak[e] websites, including the related online applications, and mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust”. Japan has an Act for Eliminating Discrimination against Persons with Disabilities.

Cloud-based testing services do not provide equivalent access to testing screen readers, haptic feedback or tools such as the Rotor. The Japanese Digital Agency’s 2025 accessibility testing methodology explicitly included Apple’s VoiceOver screen reader. Not every web developer can afford an external consultancy; Japan’s Act for Eliminating Discrimination against Persons with Disabilities applies to shops, sole traders and even volunteer groups.

Apple has, in my personal opinion, a deservedly excellent reputation for the accessibility of its products (shout out to James Craig and team!). It is therefore especially disappointing that it will not allow developers outside the EU and Japan to test that their products marketed to EU or Japanese consumers do not exclude disabled people.

Conversely, and happily, CMA’s NFC conduct requirement explicitly requires Apple to allow access to NFC “for testing and development purposes” and

4.6: Apple’s obligations would apply in relation to developers of apps (irrespective of the location of those developers) to the extent these apps enable, or intend to enable, UK consumers to make NFC transactions that rely on NFC access. [emphasis added]

This would be great if included in conduct requirements for web browsers on iOS, or a specification decision in the EU.

Travel

ON the subject of jurisdiction, the NFC CR is explicit that people who are ordinarily resident in UK can carry their rights with them while temporarily travelling. This too should be spelled out for web browsers, when the time comes:

A UK End-User is a person ordinarily based in the United Kingdom, with an
Apple ID registered in the United Kingdom. For the avoidance of doubt, this requires Apple to ensure that a Developer can facilitate NFC Transactions for a resident of the United Kingdom who is using iOS within the United Kingdom, or while travelling temporarily, without change of residence, outside the United Kingdom. [emphasis added]

Default API

Apple must ensure that a UK End-User is able to set an NFC App as the Default NFC App…

To work effectively, developers of NFC apps should be able to detect whether they are the user’s default:

Apple must introduce and maintain an API which must be made available to all Authorised Developers, and through which an Authorised Developer can confirm whether its NFC App is a UK End-User’s Default NFC App

Currently, Apple allows browser vendors to check if they are default up to 4 times a year (they raised this from once a year after consultation). The NFC CR is explicit that Apple cannot limit this default check:

Apple must not limit the number of times an Authorised Developer is able to call the Default Status API…

Apple must not limit the number of times, or the frequency at which, an Authorised Developer is able to issue prompts to a UK End-User to switch the Default NFC App.

Apple believes that only it knows how to do user experience properly (see iTunes, Liquid Glass, etc) so they worried that “allowing developers to check default status information is ‘unnecessarily intrusive’ and could encourage developers to excessively prompt users”. The NFC CR rejects this:

4.251: Multiple stakeholders told us that a rate limit of four times a year would be ineffective as it would not allow them to obtain default status information on a regular basis, which is an important factor in providing users with effective and targeted prompts…

5.76-77: Stakeholders said that they have strong incentives to avoid over-prompting given the risks of irritating users.

The CMA’s mobile browsers and cloud gaming market investigation found that developers understand that the overuse of prompts can be intrusive, and that most browser vendors aim to target users who have not yet set their mobile browser as default, therefore avoid unnecessary prompting. We expect that NFC developers would behave in a similar manner and ‘would be reluctant to repeatedly prompt users given the risk of creating a poor user experience.

Fair fees

CMA proposes that Apple can charge a fee for NFC access. I think there should not be a fee for at least ten years, to compensate for the the enormous monopoly profits Apple has accumulated over the last 17 years.

Nevertheless, the fee can’t be a number plucked out of the air by a Cupertino beancounter:

Apple may require a Developer to pay an NFC Access Fee. In relation to a fee so offered, payable or proposed, Apple must secure, and must be able to demonstrate to the CMA’s satisfaction, that each NFC Access Fee is fair, reasonable and non-discriminatory [Emphasis added]

CMA wants to see Apple’s working out, and has already done some benchmarking:

4.144: To test the evidence on Apple’s current fees further, we have conducted our ‘own break-even analysis for a direct competitor (ie a ‘copycat’ entrant).

and

5.314: We considered figures available from Google as a comparator, and this was for the number of staff working on developing and maintaining HCE and SE based NFC technology on Android on a global basis… We consider that Apple would likely require significantly less FTE resource to implement HCE in the UK than Google requires to develop and maintain SE and HCE on a global basis…

Therefore, on the basis of the available evidence, we consider that itis reasonable and appropriate to assume that Apple is likely to incur low implementation costs.

Apple would not be allowed to pass on the costs of dismantling its monopoly:

5.46: the costs for putting in place, fair, reasonable, transparent and non-discriminatory prices, non-pricing terms, and conditions of access should not be treated as costs of our intervention as a whole.

Compliance monitoring

The CMA expects Apple to support its chosen application of each of the principles with objective and verifiable evidence.

The CR makes sure that there are checks and balances in place so Apple can’t just revert back to its haughty autocratic ways. There must be a complaints handling process that is “clear, transparent and accessible”. Records of complaints, decisions, outcomes and reasons must be retained for six years.

In paragraph 4.259, the CMA proposes to require Apple to submit compliance reports every three months. These would cover whether Apple is complying with the final CR and whether the CR is effective in achieving its intended aims. The CR is intended to give developers “an effective route to challenge decisions and raise concerns” (para 4.244). And, if the CMA believes Apple is not playing fairly, it can investigate:

4.243(b): the CMA is required to keep CRs under review, and must have the ability to open a conduct investigation where it has reasonable grounds to suspect a breach of a CR

Now do browser engines

CMA has committed to investigating competition between browser engines on iOS this year. I hope we’ll see similarly precise conduct requirements to ensure that UK users can benefit from faster and more powerful engines than WebKit, and Web Apps can challenge the hegemony of single-platform proprietary technology Apps on mobile.

Note to CMA

Howdy CMA chums. The CR PDF seems to contain both a full-page image and a separate text layer, but the text layer is fragmented into separately positioned characters. The PDF’s embedded fonts include numerous fonts named CALS_InvisibleTTFont, which means -at least on using Mac’s Preview function- I couldn’t search, or copy text from it. Sometimes this happens with the PDFs you publish, sometimes not.