When the Digital Markets Act came into force, there was a grace period for Gatekeepers (such as Apple) to prepare their Core Platform Services (such as iOS) to be interoperable and to stop self-preferencing the Gatekeepers’ own products. Spoiler alert: many Gatekeepers haven’t yet done so.
In the browser world, the most egregious offenders are Microsoft and Apple. Microsoft is a Gatekeeper because of its Windows operating system, so it moved a lot of its sneaky tricks into Microsoft Edge which (bizarrely) is not designated as a Core Service. The Browser Choice Alliance was recently formed to persuade regulators to look at desktop browser competition.
Apple, meanwhile, have adopted a strategy of malicious compliance so brazen that they might as well be sticking a finger up at the EU, while shouting “Fine us then, you communists!”, then turning around and pulling a moonie.
So in September, the EU started two specification proceedings to “assist” Apple in complying with its interoperability obligations, and the preliminary findings were published yesterday for public consultation. I read the PDFs so you don’t have to, in case you’re imminently off to an Xmas party where glamorous and sophisticated people will ask you questions about this and you don’t want to appear an ill-informed chump.
The first focused on “on several iOS connectivity features and functionalities, predominantly used for and by connected devices”. While this isn’t in the world of browsers, “companies offering these products depend on effective interoperability with smartphones and their operating systems, such as iOS”, as do browsers, so it’s instructive to see the EU’s thinking on iOS interoperability.
The preliminary findings in case DMA.100203 – Article 6(7) – Apple – iOS – SP – Features for connected physical devices [PDF] is mostly technical, but concludes with some interesting measures for all features.
Paragraph 131 would ban the ludicrous contractual obligations that Apple would impose on third-party browser engines in its anti-competitive Web Browser Engine Entitlement Addendum for Apps in the EU [PDF]:
(c) Apple shall not undermine effective interoperability with the 11 features set out in this Document by behaviour of a technical nature. In particular, Apple shall actively take all the necessary actions to allow effective interoperability with these features.
(d) Apple shall not impose any contractual or commercial restrictions that would be opaque, unfair, unreasonable, or discriminatory towards third parties or otherwise defeat the purpose of enabling effective interoperability. In particular, Apple shall not restrict business users, directly or indirectly, to make use of any interoperability solution in their existing apps via an automatic update. In any event, any restrictions imposed by Apple shall not be more restrictive than those applied to Apple’s own services and hardware, i.e., Apple’s own services and hardware may not be subject to more favourable requirements and criteria.
It explicitly recognises that adding friction points can influence consumer behaviour, and thus forbids it:
(f) As regards the end user journey and the ease of use for end users, Apple shall not add friction that end users of Apple services and Apple connected physical devices are not subject to. In particular, Apple shall refrain from adding friction by:
(1) offering choices to the end user in a non-neutral manner, including in permission prompts for third-party connected physical devices,
(2) setting a system default to not grant a permission with respect to third party connected physical devices,
(3) requiring end users to process multiple successive permission prompts that could be presented in a single prompt,
(4) requiring switching between apps or apps and the iOS settings to configure a connected physical device,
(5) misrepresenting any risks of using the connected physical device towards the end user,
(6) using deceptive design pattern or dark patterns that steers users to not grant a permission.(g) Apple shall ensure that for the features listed in this Document and the respective interoperability solutions end users can grant any required user permissions in a frictionless way:
(1) From inside the application itself or with a simple system prompt; or
(2) Following a link to the relevant item in the system settings (so-called “deep-linking”). In this case, Apple shall ensure that the user does not need to continue onto additional screens to change the specific setting, that the relevant item can be clearly highlighted, and that the user can be visually guided to return to the application.
I hope that, if the EU starts specification proceedings on allowing third-party web browser engines because Apple still digs its heels in, a similar set of over-arching requirements will be specified.
The second preliminary findings published yesterday sets out proposed measures that Apple should implement to improve the request-based process for requesting interoperability with iOS [PDF] set up by Apple.
This was always a ridiculous process. The point of DMA is that Gatekeepers design and document APIs that allow interoperability, rather than grudgingly demand supplicants submit a form into a black hole. I’ve sent a couple of interoperability requests on behalf of Vivaldi (my employer), but only received an automated response with no idea of what the next step will be, when the initial assessment will take place, the criteria used for such as assessment, or how one appeals a rejection:
Hello,
Thank you for your submission. We’ll review your request soon. Your reference number is INTEROP-248.
If additional information is needed to complete the initial assessment, we’ll reach out. When responding to communications, please use the email address from which you submitted your interoperability request. The use of a different email address may result in a delay in handling your request.
For more information, please visit the FAQ.
Apple Developer Relations
Paragraph 23 of the preliminary findings addresses this lack of transparency:
To ensure sufficient transparency regarding the process, the gatekeeper should put in place a clearly structured, adequately documented process setting out how requests will be received, acknowledged, assessed and responded to.
(24) … . The webpage should include clear and detailed information on how to submit a request, what information the developer should insert in the request form, a description of the phases and their deadlines as well as a clear description of the criteria and considerations that Apple would apply or take into account in its assessment of the request at the various stages should also be included.
There should be a named contact, transparency of rejection reasons, and a conciliation process. There should be a tracker system so developers can see the progress of others’ interop requests (with the consent of the initial requester):
(69) Apple should organise the requests it received in an easily accessible tracker system giving developers relevant information on the status of each interoperability request, including for each request information on its current stage and expected timeline. The tracker must be up to date and be easily accessible to all interested developers via a dedicated section on the developer portal.
Perhaps most intriguingly, Apple should document its private APIs:
(11) To ensure sufficient transparency with respect to features and functionalities that are currently only available to or used by Apple, or not available in an effective manner to third-party developers (hereinafter “reserved feature and functionality”), the following measures should be implemented.
(12) Apple should provide developers with information on reserved features and functionalities, comprising
(i) descriptions of all features and functionalities accessed or controlled by iOS or iPadOS, so that developers adequately understand their purpose;
(ii) indications of whether the features and functionalities are reserved to Apple or also available to third parties, such that developers can easily distinguish features and functionalities that are not (yet) available to third-party developers;
(iii) any terms, conditions, restrictions, or entitlements that apply, such that developers understand why features and functionalities may or may not be available publicly as well as understand privileged access for Apple;
(iv) Apple’s services and hardware that use the feature or functionality, such that developers understand which services or hardware provided by Apple take advantage of the features and functionalities.
Of course, Apple is very sad about these suggestions. It swiftly published a lachrymose paper called It’s getting personal. How abuse of the DMA’s interoperability mandate could expose your private information [PDF] to lament that Meta had made 15 interoperability requests that “alter functionality in a way that raises concerns about the privacy and security of users”.
Apple further weeps,
These processes will hurt innovation— companies should be able to compete with one another to make their own products work together in new ways that benefit users without giving their ideas away to competitors. Apple is the only company being forced to share its innovations in this way with everyone else, including those who do not share its commitment to user privacy.
I’m no fan of Meta, but I agree with their unnamed spokesperson’s statement to Bloomberg:
What Apple is actually saying is they don’t believe in interoperability. Every time Apple is called out for its anticompetitive behavior, they defend themselves on privacy grounds that have no basis in reality.
Do you have an opinion? Tell the EU before 9 January!