A regulatory dialogue entails at least two parties exchanging their views to reach a conclusion on a common topic. That’s what first comes to mind, at least. Well, the European Commission (EC)’s idea of such a dialogue differs greatly from that. Exhibit A: the EC’s publication of its preliminary findings on the two ongoing cases relating to the specification of Apple’s technical implementation of Article 6(7), i.e., the vertical interoperability obligation (see the previous post on the opening of the case, here).
The provision compels the gatekeepers controlling their operating systems (Windows PC OS, Alphabet’s Android and Apple’s iOS and iPadOS) to “allow providers of services and providers of hardware, free of charge, effective interoperability with, and access for the purposes of interoperability to, the same hardware and software features accessed or controlled via the operating system”. The mandate also provides a narrow scope to the gatekeeper to take “strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of (its) operating system (…), hardware or software features (…), provided that such measures are duly justified by the gatekeeper”. By building on this premise, the European Commission issued its preliminary findings on how Article 6(7) should look like for Apple’s operating system when confronted with requests from third parties to access those hardware and software features.
The preliminary findings are somewhat similar to a Statement of Objections (SO) when it comes to EU competition law: they demonstrate and set out in black and white what the EC takes issue with to pave the way for a final decision. In this case, however, that decision will not impose punitive sanctions (for now) but rather a whole array of implementation measures necessary to make Article 6(7) effective. Two sets of preliminary findings were issued. One for each specification case triggered by the EC on 19 September 2024: DMA.100203 (relating to Apple’s interoperability features with third-party physical connected devices) and DMA.100204 (with regards to its dedicated interoperability request). This post considers the bird’s eye view of those preliminary findings, bearing in mind the EC’s exhaustive findings, and building upon the detailed conclusions of my recent working paper on the topic.
The Before and After of Enforcement
As of March 2024 (aka the DMA’s compliance deadline), Apple presented how it intended to comply with Article 6(7): it would provide business users with the opportunity to send interoperability requests. Following such requests, Apple held a tight grip on the provision’s interpretation because it could deny those requests if it found they were too technically complex to accommodate to its operating system or if it simply determined that they fell out of the scope of the provision’s scope of application (e.g., because the obligation did not apply to a particular feature or because the interoperability mechanisms for the requested features were already readily available to them). Apple did not hold itself particularly responsible for the workings of the process, either, since it only compromised to update the business users every 90 days about the request’s status.
That IS the starting point of both these specification proceedings triggered in September 2024 by the European Commission. There is not much to work with but loads of scope for improvement. The EC already provided a few hints when it issued its initial decisions opening those cases that it would strive to transform Apple’s digital ecosystem to make it more welcoming to business users wishing to interoperate with the operating system. In fact, one of the most enlightening passages of those decisions highlighted that: “unlike proactive approaches such as interoperability by design, a request-based system may present important limitations and difficulties for third parties. (… and) it enables the gatekeeper to maintain control over (the) outcome (of the interoperability requests), i.e., whether, when and how interoperability will be provided” (para 20 of the decision in case DMA.100204).
In its preliminary findings, the EC went one step further. Apple’s vertical interoperability solution is not only below the threshold of interoperability by design, but it also creates “inherent limitations and risks” (para 2 of the case DMA.100204 preliminary findings). In that sense, the EC pre-empts Apple’s request-based process as an unfair and ineffective pathway to interoperability. The statement ignites quite a clear parallelism: market power debilitates competition structures, and the dominant player holds a special responsibility to not hinder nor harm competition further. The enforcer mirrors this building block from the application of Article 102 TFEU and sets out that implementation measures should follow from this general idea. In fact, the EC justifies that all the proposed implementation measures it includes in its preliminary findings flow freely (in line with the principles of necessity and proportionality) from this general presumption (paras 8 and 9).
In all fairness, the EC does not strike away any of Apple’s technical implementation of Article 6(7) but it fleshes out what effective interoperability should look like via the two preliminary findings. Case DMA.100203 is all about substantial changes and transformations that Apple must abide by with regards to functionalities enabling third-party physical connected devices to interoperate with iOS and case DMA.100204 revolves around the (messed-up) scheme of Apple’s initially proposed request-based process. As a matter of fact, the Commission relies on the request-based process to put forth its own idea of effective enforcement. However, the difference between the implementation measures and Apple’s prior compliance proposal is uncanny, as shown in Figures 1 and 2 below:
Figure 1 demonstrates Apple’s compliance solution as set forth in March 2024. Business users are basically relieved of playing any role in the whole process since they do not have any chance to provide feedback or comments to the gatekeeper on the new interoperability solution. Figure 2 below, however, shows the EC’s efforts in transforming Apple’s sub-par proposal -on effective interoperability- to, at least, accommodate the principles of transparency and fairness into the request-based process.
Figure 2 shows the many prongs and tenets the EC introduces to the mix via its preliminary findings, including a whole set of deadlines that the gatekeeper must abide by to comply with Article 6(7) DMA.
Additionally, the EC includes a pre-notification-like phase to the whole procedure, termed ‘Availability of Information’ in the graph. Prior to the EC’s preliminary findings, it was not entirely clear how developers could avoid their requests being rejected on the grounds of those interoperability solutions being readily available to them. To put it in other words, they really did not have any feasible way to learn from Apple such solutions already existed. That is precisely the reason why the EC now will require that Apple provide developers with information on reserved features and functionalities accessed or controlled by iOS and iPadOS so that they can understand their purpose. Such information will also explicitly describe whether particular features and functionalities are reserved to Apple or not and what terms, conditions, restrictions or entitlements apply to them (para 12). According to the Commission, access to such information is a prerequisite for the developer to adequately understand the extent of the reserved features and functionalities, i.e., those features which may require an interoperability solution (para 18).
As compared to Figure 1, developers now have several instances where they can provide their feedback directly to the gatekeeper throughout the process. Feedback is not necessarily reactive in nature, as it was in Apple’s compliance solution, meaning that the developer could only re-submit the request by changing certain aspects of it (in the hope that it would go through). The EC’s preliminary findings draw a clearer picture where the developers are continuously in contact with the gatekeeper, especially in the most critical phases of the process, e.g., the actual development of the interoperability solution.
Moreover, the EC introduces, in a similar fashion to the DSA-style out-of-court dispute settlements, a conciliation process by which gatekeepers and developers may address their disagreements and disputes with the assistance of a neutral third party (para 43). The EC introduces the conciliation process (not referenced in the DMA, but a welcome contribution to narrowing down the imbalances of rights and obligations between business users and gatekeepers) as a means to settle technical aspects of the request, such as those cases where Apple plans to implement an interoperability solution that the developer considers too restrictive or when the developers disagree with the level of complexity involving the interoperability solution (para 45).
Finally, transparency ignites most of the implementation measures proposed by the EC on its preliminary findings. The 90-day update initially set forth by Apple is wholly unsatisfactory for meeting the threshold of the DMA’s effective enforcement. The EC responds to that issue by introducing a whole array of different mechanisms to ensure that information flows rapidly and freely to developers. For instance, Apple ought to set up a designated contact point so that developers can engage and receive timely assistance on any issues that may arise during the assessment and implementation of their requests (para 28). Similarly, the gatekeeper will introduce an accessible tracker system that provides up-to-date and easily accessible information to developers via a dedicated section on Apple’s developer portal (para 69).
All these technical implementation measures relating to the request-based process nail down the how of interoperability. In parallel, however, the EC expands on the general thoughts presented by both Recitals 55 and 56 DMA. These interpretative provisions provide a guide of how the legislator intended enforcement to work out in practice in terms of the vertical interoperability obligation. Recital 55 highlights the example of wearable devices as a prominent area for improvement in terms of interoperability solutions. In a similar vein, Recital 56 pinpoints some of the functionalities required for the effective provision of a service catered together with a third-party device, notably near-field-communication technology or authentication mechanisms.
The EC makes good on such promises and directs all its attention to narrowing down the disparities between the functionality available to Apple’s connected devices vis-à-vis those of third parties. In its preliminary findings, the EC identified eleven features available on iPhones and iPads that deserve regulatory scrutiny through specification proceedings. Those include iOS notifications, automatic Bluetooth audio switching, AirDrop, AirPlay or their automatic Wi-Fi connection feature. The EC does not really justify its choice for those features (is the list exhaustive?), but it does provide a comprehensive account of how it intends them to work on third-party connected physical devices.
Instead of interpreting the principles of transparency and fairness, the enforcer draws into the meaning of the ‘equally effective’ threshold required by Article 6(7) DMA. The EC chooses to flesh out its implications relating to the features and functionalities that Apple must provide access to so that business users stand on an equal footing when competing with its connected devices, notably its smartwatch (Apple Watch) and its headsets (Apple Vision Pro and AirPods). The long list tailored by the EC is purely technical in nature, and for good reason, since this is the only by which innovation will reach end users. For instance, a whole range of features will enable third parties to develop compatible and interoperable wearable devices and connected physical devices (smart TVs, for example) with the iPhone and iPad. Users will, as a result, not be ‘stuck’ to using Apple’s digital ecosystem consistently, but they will, at least be provided the choice to pick competitor products, hypothetically bringing prices down for third-party connected physical devices.
Aside from the de facto extensive rules that the EC establishes per each of the 11 features to flesh out the meaning of effective interoperability, the enforcer sets out some ground rules applying transversally to all features. The EC starts out by setting out that for interoperability to be effective “it must be granted in a technically sound and workable manner for third parties, without any undue obstacles” (para 130). Following this same line of thought, the gatekeeper is bound to abide by a set of measures of general applicability to uphold the mandate of effective interoperability. They are both positive (prescriptive) and negative (proscriptive) in nature.
Relating to the former, the EC puts pen on paper to avoid recognising a general right to interoperability for all developers. Business users will be granted access to hardware and software features to the extent they indicate an interest in making use of those features for a particular purpose. Interoperability does not operate for its own sake. Rather, interoperability requests must be directed at a concrete and particular purpose(s), which the developer must set out beforehand. In line with the implementation measures on the request-based process, the gatekeeper must know what, how and why the business user needs interoperability to provide adequate access, in line with the principle of fairness.
In this same context, the EC translates the ‘effective interoperability’ threshold as a benchmark to ensure that the interoperability solutions for the features are equally effective and provided under equal conditions to those available to Apple’s own services and hardware. Despite that interoperability does not necessarily mean equality of results, the EC makes the statement true by placing a high threshold of compliance on the gatekeeper, by requiring it to ensure that equal effectiveness and conditions apply across all dimensions including to the end user journey and ease of use, device and software setup, data transmission speed and energy consumption. Building on its previous experience with Apple’s DMA compliance solutions incorporating friction into the end user journey, the enforcer requires the gatekeeper to make all interoperability solutions frictionless, away from security and safety prompts and complex defaults to access the rights available as per the regulation.
In terms of the proscriptive measures, the preliminary findings reiterate the obvious: the gatekeeper cannot introduce restrictions on the interoperability solutions catered to business users when those limitations stem from the type or use case of the app or the connected physical device. In this same sense, the enforcer enshrines the anti-circumvention clause embedded in Article 13 DMA into the implementation measures by declaring that the gatekeeper cannot undermine effective interoperability with the 11 features through its behaviour of a technical nature.
The whole array of implementation measures imposed on both cases will be complied with in practice, and not in the abstract, according to the preliminary findings. The instrument chosen by the EC is that of adding new reporting obligations, on top of the gatekeeper’s existing Article 11 and 15-related compliance and auditing mandates. With regards to third-party connected physical devices, the EC adds three additional compliance obligations relating to:
- The gatekeeper’s measures to comply with the specification decision, containing a detailed description of the interoperability solution and justification on how it establishes effective interoperability under equal conditions to that available to Apple’s own services and products; and
- The technical details and potential APIs made available to third parties as a consequence of the interoperability solution (a non-confidential version of the report will be publicly available); and
- Every measure the gatekeeper adopts (or plans to adopt) to ensure that iOS integrity is not compromised, explaining why such measures are strictly necessary and proportionate (a non-confidential version will also be available to the public) (para 131).
On the side of the measures related to the request-based process, the EC compels Apple to publish a public report on its website detailing certain key performance indicators (KPIs) on the status of all interoperability requests, notably the number of pending requests or the number of requests in each of the phases. An updated report will have to be issued by Apple every six months (para 79). Additionally, Apple will also have to report on all the measures it has taken to comply with the specification decision (para 85).
Gatekeeper reaction and the enforcer’s regulatory style
On 19 December, the EC released its preliminary findings on both specification proceedings. Apple published its note termed ‘It’s getting personal: How abuse of the DMA’s interoperability mandate could expose your private information’, a five-page manifesto directly criticising the EC’s stance on the effective vertical interoperability mandate and, especially, fellow gatekeeper Meta’s vested interests in promoting access to hardware and software features ‘for all’ (but really, for its own sake). See, for instance, below in Figure 3, a screenshot of some of the information included by Apple in the memo:
Meta’s Communications Director, Andy Stone, responded shortly after on X by arguing that Apple’s privacy concerns “have no basis in reality” and that “they don’t believe in interoperability”. The gatekeeper feud is just one of the many acts of the contemporary tragedy that Apple and Meta have put on stage around privacy for years now. And it shouldn’t necessarily be a bad reaction. If the EC’s preliminary findings were unambitious or left loads of discretion for Apple to decide on what features it should provide access to, then the reaction would have been less flamboyant.
However, this aspect does not make the EC’s style in issuing these preliminary findings impeccable, either. To start with, the hopes many of us held on to the DMA delivering a clear channel of communication between the regulator and the regulatory targets, have long been lost. The non-punitive-inspired mechanism of the specification does not set out an adequate path for holding a regulatory dialogue. Instead, it paves the way for the EC to simply state the implementation measures it wants the gatekeeper to comply with, and that’s that. It is true that the EC gave a period for public consultation (from 19 December until 9 January, happy ruined holidays, business users), but the process will not crystallise into anything similar to transparency. The EC will pass on the comments to Apple so that it can adjust its response to the preliminary findings in kind and it will also make adjustments to its final decision based on the feedback it has received. However, the feedback itself will not be available on its webpage for the public to learn about the influences it has received in drafting the final version of its decision nor to what extent the EC remains responsive to such feedback.
In my own mind, the specification proceedings could trigger a multi-lateral information exchange between the enforcer, business users, third parties and the gatekeepers. The DMA does not directly hinder that possibility (nor support it, to be true), as I set out on my paper exploring the topic. Notwithstanding, the EC has decided to transform those specification proceedings into a how-to guide that it passes on to the gatekeeper, at least from what’s directly obvious from the preliminary findings. Once more, the enforcer reinstates its role as the DMA’s sole enforcer by displaying great discretion not only in what the DMA should look like but how it will be most successful.
________________________
To make sure you do not miss out on regular updates from the Kluwer Competition Law Blog, please subscribe here.
