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.
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 Manager
You 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.2026
What 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.
Support FSFE
Anmelden
Anders als die Versionsnummer erwarten lässt, bringt der neue Major-Release nichts umwälzend Neues, aber vor allem eine nützliche Klärung. (
Mozilla wagt einen neuen Schritt und präsentiert mit Thunderbolt ein Werkzeug für Firmen, die ihre Daten nicht aus der Hand geben wollen. Hinter dem Projekt steht die MZLA Technologies Corporation, die bereits Thunderbird betreut. Thunderbolt setzt auf offene Technik und lässt sich komplett im eigenen Rechenzentrum betreiben. Damit richtet sich das System klar an Organisationen, […]
Keycloak vereint Identity- & Access-Management in einer zentralen IAM-Schicht. SSO und MFA erfordern saubere Protokoll- und Systemintegration. Ein Online-Workshop zeigt die Umsetzung. (
Debian hat eine neue Projektleiterin und ihr Name steht für gewisse Veränderungen. Sruthi Chandran tritt die Nachfolge von Andreas Tille an, der nach Ablauf seiner Amtszeit nicht erneut kandidierte. Die Wahl verlief unspektakulär, denn Chandran war die einzige Bewerberin und wurde nach den üblichen Abstimmungsformalitäten bestätigt. Chandran beschreibt sich als frühere Bibliothekarin und bringt viel […]
