Disclosure: for 7 months covering Maria Luisa (Isa)
Stasi’s leave, I had the honour of working with Article 19 and contributed to a
civil society’s
joint submission for the public consultation on this very decision.
Once Isa returned (January 2025) I resumed my full-time research activities. That
said, mine will be a fresh look: no hard feelings towards the Commission for
having paid rather selective attention to the observations submitted.
There is much to unpack. Decision here.
The first thing to note is that the decision is limited to
specifying Apple’s implementation measures with respect to the process for requesting
interoperability concerning existing iOS/iPadOS features. This is a form
of guidance that Apple would, by all appearances, have gladly done without, but
which the EU co-legislators expressly provided for in Article 8(2) of the DMA. The DMA sets a strict deadline: the
implementing act specifying the measures must be adopted within six months of
the opening of proceedings. This timing is absolutely essential to prevent the
process from becoming a strategy for deferring compliance ad
Kalendas Graecas. Much like those in civil society, though without taking into account the stark inequality of resources, Apple was required to respond promptly, and to sacrifice part of its Christmas holidays to the case.
Now imagine, dear Wavesblog Reader, that you’re an app developer (yes, the one from the painting) who relies on iOS/iPadOS to access your users, reading and trying to make sense of the scope of Article 6(7) of the DMA, just as the Commission does, at some length, across 54 paragraphs (41 to 95). Each of the now numerous DMA commentaries will, in future, inevitably have to begin with this detailed analysis, on which judges, too, will soon be called to rule.
The unquestionable starting point is that Article 6(7) refers to the “same hardware and software features” as are available or used by the gatekeeper’s services or hardware. Thus, same feature (the what) and “equally effective interoperability” (the how) in terms of both the effectiveness of the interoperability solution and the conditions under which that solution is made available to you, "by
comparison to how the gatekeeper implements interoperability and access to
hardware and software features for its own services and hardware". Among the properties of the feature itself that you might care particularly about, the Commission lists by way of example the end user journey, ease of use, device and software set-up, data transmission speed, and energy consumption. According to the Commission, the EU legislator recognised that while the feature must be the same for both you and Apple (e.g., data transmission speed), the implementation of interoperability, though not necessarily identical, must be equally effective to that enjoyed by Apple. Clearly, an implementation of this obligation that grants you only a degraded feature (for instance, slower data transmission than that enjoyed by Apple), cannot be considered compliant with Article 6(7), whose purpose is to allow you to offer your services and hardware, and to innovate, “on an equal footing with the gatekeeper.” Contestability and fairness, those Castor and Pollux of the DMA temple, must be duly honoured.
Apple was required to comply with Article 6(7), as well as the others DMA obligations, as of 7 March 2024. This, evidently, has not occurred as envisaged, as you, dear app developer, may well have noticed. Nor has it escaped the Commission, which has been closely monitoring the situation, issuing a string of RFIs along the way. Perhaps you received one yourself, an RFI from the Commission asking, for instance, about your experience filing one of the interoperability requests with Apple after DMA compliance date , or about the difficulties you faced in trying to identify the features Apple uses for its own services and hardware.To deal with this situation, in addition to the possibility of finding a plain vanilla infringement, the EU legislator has introduced an entirely novel instrument: the specification proceeding. Article 8 of the DMA confers upon the Commission the power to unilaterally determine the specific measures required for compliance, distinguishing the specification process from a commitment procedure, which is centred on making the company’s own proposals binding.
This also means that, in empowering the Commission to specify the measures necessary to ensure effective compliance with the legislative provisions, the EU legislator made clear that the Commission is under no obligation to adhere to the gatekeeper’s own, inevitably self-serving, interpretation of its compliance duties. Apple’s first (2024) and the second (2025) compliance reports stated, in concrete terms, what it considered to be the most favourable interpretation of Article 6(7): an approach based on request-based interoperability. As regards solely the features existing on the date of adoption of its decision, the Commission considers that such an interoperability request-based process may be deemed compliant with the DMA, provided the conditions laid down in its Decision are fully met. As for new features released after the adoption of the Decision, Apple is expected to adopt by default a proactive approach to compliance and interoperability by design, as envisaged in Recital 65 of the DMA. The decision, in what is referred to as an Annex, sets out the specific measures Apple is required to implement, along with the corresponding timelines. Within two years, the Commission will assess the effectiveness and impact of these measures. Moreover, with regard to new features, excluded from the scope of the current specification, the Commission will take into account the compliance actions taken by Apple in determining whether its approach aligns with the proactive, interoperability-by-design standard foreseen in the DMA (see Article 1).
Much could be debated as to whether the request-based process specified and prescribed by the Commission might have been further improved, and here I note once again (see disclosure) that civil society, developers, and researchers had put forward constructive suggestions, only partially reflected in the final outcome. What now most draws my researcher's initial attention, and would warrant deeper reflection beyond this blog post, is the exchange, clearly emerging from the decision, between the Commission and Apple over the meaning and practical implications of the interoperability by design obligation. Compliance by design under the DMA had already caught my attention nearly two years ago, in what now feels like the prehistory of DMA enforcement.
In paragraph 104 of the Decision, the Commission recalls that gatekeepers should ensure compliance with Article 6(7) of Regulation (EU) 2022/1925 "by design and free of charge." This formulation encapsulates two core aspects of the provision. First, interoperability must not be treated as an afterthought or a concession granted upon pressing request, but built into the architecture of the regulated operating systems at the outset. Second, a system that imposes high transaction costs on developers to obtain interoperability can hardly be described as free of charge. In fact, this is not confined to the absence of explicit fees; it extends to ensuring that access is not undermined by burdensome procedures, opaque criteria, built-in friction, unjustified delays, etc. But then, quite justifiably, you may ask yourself, dear developer: how can the principle of interoperability by design possibly be reconciled with Apple's request-based process endorsed and further disciplined by the Commission? After all, if interoperability must be embedded by design, shouldn’t it be somewhat automatic, largely transparent, and proactively enabled, rather than contingent on your ability to navigate a request system, identify shadowy features, and patiently wait for the gatekeeper’s response?
You may find some reassurance in reading paragraph 105, which suggests that the Commission may, in fact, share many of your views and concerns. It is worth quoting in full:
"Unlike proactive approaches such as interoperability by design, a request-based
system presents important limitations and difficulties for third parties. In particular, it
causes delays due to the need to process requests and implement solutions, and it
leads to associated transaction costs. It requires third parties to (attempt to) recognise
the hardware and software features that may be available to or used by the
gatekeeper. It may also necessitate the disclosure of third parties’ confidential
information to the gatekeeper. Moreover, it risks enabling the gatekeeper to
maintain control over the request-based process and its outcome (i.e. whether, when
and how interoperability will be provided), in a context where the gatekeeper may
have incentives to refuse, delay, or restrict the provision of interoperability to
competitors or potential competitors. Overall, in a context characterised by
information asymmetry and imbalance in bargaining power, a request-based process
may allow the gatekeeper to undermine the effectiveness of Article 6(7) of
Regulation (EU) 2022/1925, and the ability of third parties to innovate."
Nonetheless, the request-based approach adopted by Apple is endorsed by the Commission, albeit subject to the (substantial) adjustments set out in Annex I. Why? Apple, the Commission notes in paragraph 107, had not envisaged third party interoperability in the original design of the operating system and/or of the features prior to the entry into force of Article 6(7). Faced with this legacy design, the Commission appears to have accepted that a request-based mechanism could serve as a somewhat transitional form of compliance, provided it fully complies with all the conditions set out in Annex I. Subject to the conditions it lays down, the Commission considers that it has addressed the risks previously identified in the rather long paragraph quoted above, and thereby ensured the “respect of third parties’ right to interoperability” (para. 107).
While the Commission confirms that, with regard to existing features, there is no obligation of interoperability by design, it nevertheless notes that the measures specified in the Decision make compliance with Article 6(7) “more automatic” and, in this sense, provide a “pathway” towards interoperability by design. Instead, when it comes to new features, the Commission makes clear that
interoperability by design should be persued by Apple (para. 110).
If, however, we turn to interoperability concerning specific features related to connected physical devices, the situation looks entirely different. For any feature covered by "the other" Article 6(7) specification decision, the request-based process is bypassed altogether: Apple is required to implement the prescribed substantive measures within the timeframes set out by the Commission. Some of these features, the Commission notes, could already be included in the forthcoming iOS 19, currently being unveiled by Apple as I write. Connected physical devices range from payment cards to cars, insofar as they either transmit or receive data. Interoperability with regard to connected physical devices is of substantial economic importance. As Apple itself acknowledges, "most iOS devices do—at some point—connect to a physical device within the EU." What the Commission does in this second Decision is provide Apple with detailed guidance, spelling out the exact interoperability solutions required for specific features, aspects of their technical implementation, and the modalities of access that must be made available to third parties.
At this point, the relationship between the two Decisions, and indeed the overall picture, becomes more intelligible: under the DMA, effective interoperability is understood as something that develops over time, evolving alongside, indeed, accompanying, technological change. To take this obligation seriously dans la longue durée, Apple must first establish a meaningful channel of communication and cooperation with developers requesting interoperability. The Commission considers that, if properly implemented with the safeguards it has specified, even a request-based system can serve this function. In such a framework, developers may articulate specific interoperability needs which Apple is then required to meet. Should Apple fail to do so in accordance with the DMA, the Commission may subsequently intervene, either through a further specification decision or, where appropriate, by initiating an infringement procedure. In this sense, the request-based system outlines a pathway toward interoperability by design, one in which, over time, it should make little sense for Apple to maintain separate interoperability solutions: one for its own products and services, and another for third parties.
In the case of the connectivity features covered by the second Decision, however, concerns about the lack of effective interoperability have already materialised. These are “borne out in requests made by third parties via Apple’s Interoperability Request Portal and submissions during the administrative proceedings and the public consultation,” as well as “by Apple’s submissions outlining possible interoperability solutions and its proposed implementation deadlines” (para. 18). The purpose of the second specification decision is therefore “to swiftly provide effective interoperability solutions to the market” (para. 19), and in the event of any conflict, it prevails over the process decision (para.20) (on this last point, a legal mind cannot help but glimpse vast and fertile fields for further musings).
These are merely initial reflections, but one must concede that the future of interoperability in the EU, as it is now taking shape, is both stimulating encouraging. You, dear Developer, in the EU and beyond, so long as you serve EU users, should be a little more hopeful than before. This is at any rate true for someone who has long followed the subject from a competition policy perspective, and who can only welcome the emergence of promising developments not only under the DMA, but even on the more traditional front governed by the stricter contours of Article 102.There will be ample opportunity to write more on this, and I very much look forward to discussing it further during an upcoming webinar, one that will also bring in perspectives and experiences from other jurisdictions.
