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 selctive 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).
