Anmelden
Apple keeps challenging its interoperability obligations under the DMA
Apple keeps challenging its interoperability obligations under the DMA
A new FSFE report exposes how 56 interoperability requests under the Digital Markets Act have produced no concrete solutions by Apple, and how their declines contradict their own official documentation, leaving third-party developers locked out of iOS and iPadOS, despite European Commission’s latest specification decision.
Share your experience:
Start the survey
CC-BY-SA 4.0. by Rahak for FSFE.The Free Software Foundation Europe (FSFE)’s report “The challenges of regulating interoperability. Analysing Apple’s request-based approach under the Digital Markets Act” sheds lights on how Apple has been implementing the interoperability obligations under the Digital Markets Act (DMA). Under the European Commission (EC)'s latest rules, third-party developers can formally request access to Apple's platform. This report looks at how Apple has handled those requests in practice. The evidence of the report is based on public data from Apple’s public tracker, implemented as a requirement of the regulatory framework.
Despite the EC's clear requirements under the Digital Markets Act, the FSFE's report finds that, as of 22 March 2026, not one of 56 formal interoperability requests has resulted in a solution. Developers requesting access to Just-in-Time compilation, NFC protocols, and Bluetooth Low Energy Audio, for example, have seen their requests denied often because the features in question “fall outside of the scope of the law”. Despite the company's own technical documentation, which points in the opposite direction. The report elaborates on the shortcomings of Apple's request-based approach in relation to effective interoperability: Apple’s model requires developers to navigate account creation, fees, detailed requests, internal review, and potentially long implementation timelines, fearing sudden and unreasoned closure of their developer accounts during the whole process.
The report argues that while the regulatory framework issued by the EC on interoperability represents a progress, requiring transparency and due process obligations from Apple, governance issues, as pointed out, will arise in the future. Therefore, the report calls for open standards, transparent procedures, and stronger regulatory enforcement so that Free Software developers can participate on fairer terms within the mobile ecosystem.
“Despite being legally required by the European Commission, Apple continues to obstruct effective interoperability. Out of 56 requests, not a single one has resulted in a new interoperability solution. Developers are denied access to Just-In-Time-Compilation, NFC, or Bluetooth Low Energy Audio with arguments contradicting Apple’s own documentation. And there is the constant fear for developers to lose their developer accounts. The DMA must be implemented in a developer-friendly way, ensuring that legal obligations translate into fair and equal access to iOS and iPadOS features.”Matthias Kirschner, FSFE President “Interoperability only works when it is built into the platform from the start. The European Commission’s regulatory framework to facilitate interoperability between Apple and competitors is a good step forward. Or report sheds lights on the challenges faced by software developers under this new framework.”Lucas Lasota, FSFE Legal Programme ManagerYou can read the full report here. What follows is a summary of the main findings.
I want to donate for Device Neutrality!
Recap on DMA interoperability
Apple is one of the largest tech companies in the world. Due to its market power, it is designated in Europe as a gatekeeper under the DMA, a law designed to regulate digital competition and open closed platforms. Under this legislation, Apple must provide free-of-charge interoperability for the features and functionalities controlled by its mobile operating systems, iOS and iPadOS. This should allow users to install and remove apps freely, use alternative app stores, and enable developers to connect their apps to key software and hardware features without being blocked.
Making Article 6(7) of the DMA Free-Software-developer friendly is crucial for Device Neutrality: it obliges gatekeepers to provide effective and free of charge interoperability with, and access to, the software and hardware features of designated operating systems such as iOS and iPadOS. In practical terms, this means that developers must be able to access the same operating-system-controlled features that the gatekeeper’s own services use, instead of being kept on the outside looking in.
The DMA represents an opportunity for Free Software developers to compete on equal terms with gatekeeper services. Free Software developers deserve the right to build genuine alternatives to closed ecosystems like iOS and iPadOS, while users gain access to alternative app stores, payment systems, and unfettered software installation in mobile devices as well.
Apple DMA interoperability compliance in practice
When the DMA took effect, it expected gatekeepers like Apple to deliver interoperability by default: publishing APIs, clear documentation, and technical access matching that are equivalent to those used for their own services. Instead, Apple created a request-based system where each developer must seek permission for specific features, waiting for Apple to decide if they are ”in scope”. This led the European Commission to launch a specification case (DMA.100204), requiring a fairer process with timelines and a public tracker (for access to which an Apple account is required).
How a developer must request interoperability to Apple
Rather than opening its platform by publishing APIs and documentation from the outset, Apple built a request-based system in which every developer must apply for access to each feature they need.
The process starts with an Apple developer account, which costs at least 99 USD (in Spring 2026), then developers need to fill a detailed request describing the feature, the use case, the technical need, and possible alternatives to the feature or functionality they are asking access for. Apple then performs an initial eligibility check within 20 working days, after which it may proceed, reject the request, or say that an existing solution already covers it.
If Apple rejects the request, developers can seek internal review and, in some cases, conciliation. Even when a request is accepted, Apple can still take up to 24 months to implement the result, depending on its own assessment of technical complexity. That means the process can stretch across months or years before developers see any practical benefit, even though the underlying right to interoperability is already supposed to exist.
Timeline proposed by the European Commission to regulate Apple’s
interoperability requests. Source: European Commission.
The EC’s intervention gave the process a regulatory framework. As of March 22, 2026, Apple has received 56 interoperability requests under Article 6(7) of the DMA since May 2025, of which 43 have been closed, but 27 of those closures are fully confidential. Of the 16 publicly disclosed closures, none resulted in Apple developing a new interoperability solution: 10 were denied on “technical grounds”, 2 were dismissed by Apple citing “existing solutions”, and 3 were rejected as “out of scope or invalid”.
Interoperability requests received by Apple under Article 6(7) DMA until 22.03.2026
Status of the interoperability requests received by Apple under
Article 6(7) DMA until 22.03.2026What Apple tracker reveals: four examples of rejected requests
Several individual cases illustrate how the process works in practice. A Free Software terminal-like app requested access to Just-In-Time (JIT) compilation. JIT is already used by Apple’s Safari browser to run downloaded code securely in a sandbox. But Apple rejected the request from the developer and said JIT for non-browser apps was not a feature controlled by iOS.
Another developer sought access to FIDO tokens in wallet passes and the VAS NFC protocol used by Apple Wallet. Apple again denied that these were OS-controlled features, despite its own documentation requiring a special entitlement for NFC access.
A third case involved Bluetooth LE Audio for specialised research hardware. Apple said the feature was not available to or used by Apple’s own hardware or services, even though Bluetooth Low Energy is part of iOS and comparable functionality exists on competing platforms. Two further requests sought alternatives to Apple’s Push Notification Service, including decentralised or user-controlled notification servers. But both were rejected on the grounds that APNS is already open and persistent connections are simply an OS function.
These examples show the same pattern: Apple defines the scope narrowly enough to preserve its own product design choices, then treats those same choices as evidence that interoperability is unnecessary.
Why does this matter for Free Software developers?
The burden of requesting and eventually getting access to interoperability rights falls almost entirely on developers. Under Apple’s model, they must prove case by case that a feature is “used by Apple” before they can gain access, while Apple remains free to reject the request based on its own interpretation of the scope. The EC’s framework imposes on Apple transparency obligations. For Free Software projects, this means technical work becomes entangled with legal argument, procedural deadlines, and repeated submissions.
The mandatory developer fee adds to the problem. Article 6(7) requires interoperability to be free of charge, yet Apple still requires a paid developer account to submit a request, which creates a financial hurdle at the very point where the law is supposed to lower barriers. For volunteers, small teams, and independent projects, that is not a minor inconvenience; it is a structural filter on who can participate from the beginning.
What effective interoperability needs
In the short term, effective and free interoperability access is essential to a developer-friendly enforcement of the DMA. Equal and fair access for all developers cannot depend solely on discretionary control of gatekeepers.
Looking further ahead, shared governance is essential. Regulators alone cannot ensure that interoperability serves the public interest; developers, users, and civil society must have a genuine voice in how it is designed, monitored, and enforced. The Free Software tradition, built on open standards and community oversight, demonstrates that interoperability can be democratically governed as a digital common, rather than shaped by bilateral deals between gatekeepers and their largest competitors. That is the standard the DMA should be held to.
Call to action
The FSFE is still collecting first-hand accounts from developers who have engaged with Apple’s interoperability process under Article 6(7), or who were discouraged before they even began. Those experiences help document how the process works in practice and provide concrete evidence for regulators and enforcement actions.
If you are a developer who has requested access to software or hardware features under Article 6(7) of the DMA, or if you have considered doing so but were discouraged by the process, the FSFE wants to hear from you. Your experience can help document how interoperability works in practice and support better enforcement.
Share your experience:
Start the surveySupport our work
Monitoring gatekeepers, analysing regulatory processes, and defending software freedom takes independent resources. Your support helps the FSFE continue this work, bring evidence to regulators, and push for interoperability by design.
Please consider making a donation to support the FSFE’s work for Free Software, Device Neutrality, and user choice.
