To commemorate the Digital Markets Act’s initial designation decisions, in September the European Commission issued its first two decisions opening specification proceedings on Apple’s technical implementation of Article 6(7) DMA (see case DMA.100203 and case DMA.100204). These are the first specification proceedings triggered by the European Commission as stemming from its capacity to do so under Article 8(2) DMA.
The European Commission, on its own initiative, opens these proceedings with a view to adopting an implementing act specifying the measures that the gatekeeper should apply to effectively comply with Article 6(7) DMA, i.e., the vertical interoperability mandate by which gatekeepers must enable access to the hardware and software features accessed or controlled via the operating system. This blog post explores the EC’s enforcement action considering the decisions it has issued fleshing out its expectations in terms of the application of the vertical interoperability obligation.
Apple’s compliance with Article 6(7) DMA: setting the scene
Once the DMA became applicable, Apple had to comply with Article 6(7) DMA. Even though the provision might seem straightforward, it hides three different prongs to its implementation.
First, the free-of-charge and effective interoperability of the hardware and software features accessed or controlled via the gatekeeper’s operating system to providers of services and providers of hardware. By March 2024, the European Commission had only designated Apple’s iOS as a CPS via a designation decision. Thus, all features controlled by iOS fell within the scope of this tenet of the provision. Second, the gatekeeper must allow the same type of interoperability to business users and alternative providers of services, regardless of whether those features are part of the operating system, as long as they are used by the gatekeeper to provide such services. Third, the EU legislature introduced an exception to the application of the provision in those cases where it can take “strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system”.
The examples that immediately come to mind are those included by the legislator under Recitals 55 to 57, such as the gatekeeper’s hindering of effective interoperability with respect to wearable devices. Such an allegation was already raised by the US Department of Justice when it sued Apple for monopolising smartphone markets early this year. iPhones do not interoperate well with wearables not manufactured by Apple (i.e., the Apple Watch) and the Justice Department alleged it was using the lack of interoperability to improve the chances that customers will buy its products. However, other hardware manufacturers would include those of headphones or virtual reality headsets. On the downstream end, Recital 56 of the DMA points to functionalities such as near-field-communication (NFC) technology, authentication mechanisms or secure elements and processors as examples of features which remain covered by Article 6(7) DMA.
Apple’s compliance report and solutions to the vertical interoperability mandate
On the compliance deadline, Apple answered in kind by introducing three main changes to its interoperability features. First, all iPhones running on iOS 17.4 or later in the EEA could initiate in-person payment transactions from a banking or wallet app compatible with NFC terminals or mobile devices accepting contactless payments. In short, Apple opened its NFC technology to support any type of contactless transaction to be performed on its devices. It previously did not allow for any. As it did with other compliance solutions it proposed in March 2024 (see comment here), Apple must authorise access to the functionality through its API via its HCE Entitlement. The technical implementation was nothing too surprising, insofar as Apple had proposed similar commitments in a separate sanctioning proceeding under Article 102 TFEU on the same topic, which the European Commission accepted by July 2024.
Second, Apple created a new dedicated process for developers to request additional effective interoperability with iPhone and iOS features. The process circled back, once again, to Apple’s evaluation of the developers’ requests on a case-by-case basis. According to the gatekeeper and the compliance report, Apple would consider the requests by applying a three-step process consisting of the request’s initial assessment, the drawing up of a tentative project plan and the subsequent development of the interoperability solution. At face value, Apple remained in sole control of deciding whether to develop those interoperability solutions. For instance, on its initial assessment, it could decide whether the request fell within the scope of application of Article 6(7) DMA. Additionally, in the tentative project plan stage the gatekeeper could also determine that the effective interoperability solution was not feasible and, therefore, could outright reject the request. On its decision triggering the first specification proceedings (case DMA.100203), the European Commission acknowledged that, as of 31 August 2024, Apple had received 88 requests for effective interoperability with iOS regarding a broad range of features and use cases. As far as has been reported, major interoperability features have not been rolled out on iOS. In fact, Spotify voiced its concern that Apple had discontinued technology allowing its users to control volume on their connected devices.
Third, Apple introduced a new effective interoperability solution for third-party browser engines. Prior to the DMA’s application, browser engines on iOS could not rely on the backend of their own browser engines. In other words, browsers like Chrome and Firefox operating on iOS had to rely on Apple’s proprietary browser engine (WebKit), which meant that many of its features and extensions did not work on Apple’s devices. The choice was not made by the likes of Chrome and Firefox by choice but by sheer necessity. Each of them holds their proprietary engines, Blink for Chrome and Gecko for Mozilla’s Firefox, but they could not run them on iOS until Article 6(7) DMA got some traction. By the compliance deadline, Apple introduced (yet another!) process for enabling alternative browser engines to run on iOS, namely the Web Browser Engine Entitlement for browser apps or the Embedded Browser Engine Entitlement for apps providing in-app browsing experiences. Developers have already complained that Apple’s proposed implementation hinders innovation by compelling them to perform their testing and development on devices physically located in the EU.
The European Commission’s reaction to Apple’s compliance (and Apple’s pending appeal before the General Court)
Up until the triggering of the specification proceedings, the European Commission did not directly contest any of Apple’s technical implementation relating to Article 6(7) DMA. However, it did make provision on its third non-compliance procedure against the gatekeeper that Apple’s Core Technology Fee (the fee it asks of alternative providers of apps and app stores operating on iOS different from its proprietary App Store) could undermine the provision. As the European Commission interprets it, the fee may well be interpreted as a condition for granting access to certain software features necessary to provide third-party apps and app stores on iOS. Therefore, within the third non-compliance procedure directed at Apple, the EC declared it was looking into whether such a commission interferes with the mandate under Article 6(7) DMA compelling to provide effective and free-of-charge interoperability with hardware and software features.
The needle that the EC will have to thread in this respect is to describe what a software feature means in the context of Article 6(7) DMA. Is an app or an app store a software feature of iOS? In my own view, the EC may not have much to argue in favour, insofar as the imposition of the Core Technology Fee is not a condition to Article 6(7), but to Article 6(4) DMA, and a suspensive condition at that. If the developer does not agree to pay the fee, then Apple gatekeeps the alternative distribution of apps and app stores from those developers. In turn, however, the European Commission could go into detailing the nuts and bolts of Apple’s entitlement system and there it would have a chance at demonstrating that the gatekeeper does, in fact, hinder interoperability with certain technical features that it provides itself for making alternative distribution possible. For instance, one could argue that the Core Technology Fee hinders the developer’s access to the software features necessary for an alternative developer to design its app on iOS. Those are software features which may be distinguished from the modalities of compliance proposed in Article 6(4) and, as such, it may constitute a separate infringement of Article 6(7) DMA.
Alternatively, Apple contested in part its designation decision before the General Court by touching upon the long tentacles of Article 6(7) DMA. Aside from arguing for the annulment of part of the decision based on the European Commission’s misinterpretation and misapplication of the DMA in general, it also brought a separate allegation before the General Court relating to vertical interoperability. The gatekeeper pleads the GC to make Article 6(7) inapplicable insofar as it touches upon its iOS and, it argues, breaches the requirements of the Charter of Fundamental Rights of the European Union and the principle of proportionality when it projects all its effects.
Some of the provisions of the DMA have been left unaddressed by the European Commission, and rightly so. That does not mean that the enforcer endorses those technical solutions. This is not the case for Article 6(7) DMA, albeit the EC has lightly touched upon it in connection with the interpretation of other mandates.
The specification proceedings triggered by the European Commission
The two main aspects the European Commission tackled within its two decisions (DMA.100203 and 100204) opening the specification proceedings relate to i) the new dedicated process for requesting vertical interoperability solutions proposed by Apple; and ii) the connectivity features and functionalities predominantly used for and by connected devices. Those decisions touch upon the following aspects as follows:
| Number of case | CPSs concerned | Subject matter |
| DMA.100203 | Apple’s iOS | iOS connectivity features and functionalities. |
| DMA.100204 | Apple’s iOS and iPadOS | New dedicated interoperability request. |
This is the first step in the European Commission’s progressive approximation to the non-punitive mechanisms embedded in the regulation, which the EU legislature specifically provided to navigate the complex dynamics of digital business models and transformations.
In principle, Article 8(2) DMA opens the door for the gatekeeper and the EC to hold a regulatory dialogue where they might exchange their views on the measures required to effectively comply with a provision. According to Recital 65 of the DMA, this type of proceeding is particularly relevant for those obligations susceptible to being further specified because they can be affected by the variations of services within a single category of core platform services. For instance, in Apple’s case, given the embeddedness of its designated CPSs (iOS as an operating system, the App Store as an online intermediation service and Safari as a web browser), the specification proceedings may well be particularly enlightening to flesh out whether Article 6(7) DMA comprises all the Apple ecosystem and what features must inevitably fall within its scope of application. In this respect, both decisions state that Article 6(7) is, as a standalone, an obligation that is susceptible to being further specified via these means.
Following the regulatory dialogue, the European Commission will adopt within six months an implementing act fleshing out those minimum requirements to meet the effective compliance threshold. Article 8(2) DMA must not be conflated, however, with the European Commission’s general assessment of the gatekeeper’s compliance. The former precedes the latter. Once the European Commission issues its implementing act, then the gatekeeper will reportedly issue compliance solutions anew so as to accommodate its compliance to the technical measures established in the implementing act. This is the reason behind the fact that the European Commission may open specification proceedings even before receiving the compliance report that a gatekeeper must submit pursuant to Article 11 DMA. For instance, the European Commission has opened the specification proceedings on the dedicated request process for vertical interoperability for both iOS and iPadOS, although the latter was only designated in April 2024 and has not yet submitted specific compliance solutions to the DMA’s mandates.
Specification proceedings on Apple’s connectivity features
On the decision (case DMA.10023), the European Commission shed some light on the contents of Apple’s compliance report (at least, the confidential version of it). On it, Apple that it had already put in place interoperability practices before the compliance date and explained that it already offers development tools to help developers write software and offer hardware that interoperates with iOS. Moreover, the gatekeeper also established it operates a ‘Made for iPhone’ licensing program enabling third parties to develop hardware accessories using Apple technologies. In a similar vein, Apple also defended its implementation of numerous industry standards, including functionality to connect the iPhone via Bluetooth or other short-range technology standards with third-party accessories (para 11 of the decision).
In light of Apple’s compliance solutions, the EC declares that Apple has not outlined measures in the compliance report to comply with Article 6(7) specifically referred to connected physical devices, although it has received several requests through its new process from manufacturers of this type of hardware. Those requests seek interoperability relating to features such as notifications, data connections to synchronise and transmit high data volumes or the pairing of the connected physical device with the iOS devices (para 12). From those requests directed at Apple, the gatekeeper informed the EC that it had moved most of them to the second stage of the interoperability process, whereas it still undertaking the preliminary assessment for the rest (para 15).
After a whole six months, since those requests were directed at Apple, the European Commission considers that the gatekeeper had ample time to attend to them adequately and decided not to. Thus, the EC exerts its power to trigger the specification proceedings to provide some guidance as to how the gatekeeper should achieve the provision’s goals, including aspects such as the exact interoperability solutions offered, their technical implementation and the modalities of access to be provided to third parties (para 17). In the EC’s own words, both contestability and fairness are at play when it comes to providing effective and free-of-charge interoperability to connected devices (para 18).
The EC, however, hints at the idea of vertical interoperability that it considers would comply with Article 6(7) DMA. In principle, the DMA does not necessarily point to how vertical interoperability will apply in practice. Bourreau already established that the guiding principle of equivalence of input (and not output) should guide the technical implementation of the provision. In other words, the business users requesting access should have access to the same functionalities and on the same terms as the gatekeeper, for their own complementary products and services relying on the essential features. Equivalence of input should apply when the principle of proportionality is respected, Bourreau defends. Notwithstanding, when such an integration is not proportionate, an equivalence of output should be alternatively imposed. Applying this principle, however, is a tough ask on the enforcer’s side. Experience in the telecoms sector demonstrates that monitoring its application is a time-consuming task requiring regular audits.
From the EC’s decision opening the specification proceeding, it seems as if the equivalence of input principle is the north star to the expected enforcement it wants to see for Article 6(7) DMA. When it comes to connected devices, the EC will, therefore, steer Apple’s compliance to providing access to the same iOS features as available to Apple allowing third-party providers to challenge Apple’s own connected physical and related services.
Specification proceeding on the dedicated interoperability request
As opposed to the previous decision, the EC expands the scope of the specification proceedings considering the new dedicated interoperability request process to both iOS and iPadOS, despite the substantive provisions of Articles 5, 6 and 7 will only become applicable to it at the end of October.
On the decision (case DMA.10024), the European Commission goes into much more detail than it did in the previous one, by setting out in so many words that Article 6(7) does not require the gatekeeper to introduce a request-based process, nor does it require the publication of a reference offer (para 18). In short, Apple introduced the new dedicated interoperability request process not by necessity but by choice, and that choice can be challenged on its own terms.
In fact, the European Commission heavily criticises the new request process by pointing out that it is not a ‘proactive approach’ to implementing interoperability by design, in line with the spirit of Recital 65. As such, it presents important limitations and difficulties for third parties, such as delays in the processing of requests and in the implementation of solutions leading to associated transaction costs (para 20). Mimicking the concern voiced out by stakeholders in previous contacts with the European Commission, the enforcer sheds some light on the complications that business users have been forced to face in their interoperability requests, namely the disclosure of confidential information to the gatekeeper and their identification of what features should be redressed via the gatekeeper.
And that’s only half of the story. The interoperability request process proposed by Apple on its compliance report only applies to pre-existing features for which interoperability was not foreseen. Therefore, not all existing features for which interoperability was not foreseen by design are included under the request process (para 22).
For the moment being, however, the European Commission aims at setting the ground rules for the already proposed process so that it renders rapid results abiding by the principles of transparency, predictability, objectivity, fairness and non-discrimination for all developers requesting access. All five principles embody what the European Commission understands by ‘effective’ interoperability. It goes far and beyond the general premises that the vertical interoperability mandate stands on by setting out a quasi-FRAND-like obligation upon the gatekeeper to process requests in a timely manner.
The effects of the resulting implementing acts
In six months’ time, the European Commission will issue two implementing acts detailing the specific measures the gatekeeper should implement to effectively comply with the relevant obligation. However, it is yet unclear what legal form the act will adopt. If anything, the EC’s expected enforcement action will be to issue an implementing act addressing the particulars of Apple’s compliance and some general (but concrete) measures it should bear in mind in its iterations with the European Commission as the sole enforcer of the DMA. But what about the rest of the gatekeepers’ compliance with the vertical interoperability mandate? Will those measures bear any weight when the EC observes their own technical implementations of the DMA?
Article 291 TFEU provides for the possibility of the European Commission being conferred powers to adopt implementing acts by the EU legislator. These implementing acts’ is to create uniform conditions for the implementation of a legislative act, if and when this is necessary. By their own nature, implementing acts are not necessarily of individual application. In fact, that is one of the main differences in implementing acts vis-à-vis delegated acts, which are only acts of general application.
We will just have to wait and see for the European Commission’s implementation measures to determine whether they hold the effects of general application. If one looks at the rest of the mechanisms the European Commission may exercise to issue guidance (and guidelines) to the gatekeepers, those implementing acts ought to be directed at bearing individual application. Article 47 DMA, for instance, establishes the EC may adopt guidelines on any of the aspects of the regulation to facilitate its effective implementation and enforcement. If the implementing acts were to bear general application, then what would be the point of triggering them with respect to one gatekeeper and one shade of compliance?
In turn, it seems nearly impossible to avoid thinking that the EC will be held accountable for the measures it specifies via Article 8(2) DMA in the informal contacts it holds with other gatekeepers with respect to the same provision. In fact, Recital 56 reads that the Commission “should provide the main reasons underlying its assessment, including any enforcement priorities”. Enforcement priorities are barely an individual endeavour, especially in light of the numerous combinations of compliance arising from the designation of the seven gatekeepers with respect to twenty-four core platform services combined with the twenty-three provisions applicable to them.
________________________
To make sure you do not miss out on regular updates from the Kluwer Competition Law Blog, please subscribe here.
