DMA Compliance Workshop – Apple

By Jasper van den Boom & Sarah Hinck

This brief summary of the Apple workshops sheds light on its most important changes, some of the most relevant questions and answers in the Q&A, and shares some general observations. These reports are intended to represent facts and convey information on what was discussed during the workshops. They are not intended to provide normative considerations on whether the undertaking complies.

Opening remarks

Apple’s workshop opened with a general explanation as to how they have implemented the changes required under the DMA. Broadly, their changes include allowing for alternative payment options, introducing a browser choice screen, the introduction of new business terms for developers that want to use third-party app stores (including a common technology fee, or CTF), the provision of a Marketplace kit that helps with the development of third-party marketplaces, introducing alternative agreements for app distribution, allowing for side-loading, and providing additional documentation and help for developers. There will be more changes in late 2024 to 2025, such as allowing for the uninstallation of Safari and additional tools. This delayed roll-out may raise eyebrows with observers, as the 7th of March was the date by which compliance was meant to be effective, and not the starting date to start working on these changes.

Apple has remarked that there is no one route to compliance with the obligations under the DMA, and that it has invested tens of thousands of engineering hours and financial resources, that it has developed 600 new APIs and a wide range of tools to ensure compliance. However, it also clarifies that it is still not sure how their efforts will develop in the future, and that they will engage in further debate with stakeholders and the Commission to develop new efforts. After setting out these general changes, it elaborated on which changes it has made with respect to which obligations.

Apple iOS: choice screens and default settings – Article 6(3)

In the first session, Apple discussed the introduction of their web browser choice screen. Here, Apple also took the opportunity to discuss the use of default settings and how users can activate defaults. Apple has explained that if users open Safari for the first time they will be prompted with a browser choice screen. It explains that it sees this as a requirement under the DMA; the choice screen should be presented upon opening the web browser, not when setting up a new iPhone. To make it on the list of available choices, the web browser must meet certain conditions. It must be installed by at least 5000 users in the previous year on the App Store or iOS, and only the most popular browsers will be eligible to be presented. Apple has explained that there is differentiation per Member State, so only the most popular browsers downloaded by users in a specific Member State will be presented in that territory. For the presented choices, Apple argues that it provides information to users, that the choices are presented neutrally, and that the order in which the choices are presented is fully randomized. Apple has also introduced more default choices beyond the scope of their obligations under the DMA, including for navigation software, contactless payments, and later this year will introduce a default for third-party marketplaces.

Following the presentation, stakeholders asked a wide range of questions on topics varying from technical choices, to risks, to effectiveness. While not all questions will be discussed, we will discuss the answers which are most relevant to the discussion on these changes. Firstly, stakeholders asked about the possibility to uninstall certain services. Apple has clarified that their App Store can be removed from the home screen, but not uninstalled. One of the observers warned that since third-party marketplaces are dependent on an integrated stack, there is the risk that if Apple starts allowing the uninstallation of their App Store, this will break the third-part app stores as well. Apple did not have an answer ready for this specific issue. On risks, users asked whether there would be measures in place to prevent the emergence of copycat apps on third-party marketplaces, on which Apple referred to its Notarization process. It also reassured one observer that the warning screen prompted when users set a new default marketplace would only be launched once, after which it would be considered trusted. Finally, Apple has commented that it will share data on the effectiveness of its choices, but did not provide clear metrics for determining the effectiveness of their choices. Instead, they relayed that they put the consumer experience first in determining if changes are effective, something that is not required or supported in the DMA. There were also some questions related to the choice screen, specifically the customization per Member State, as it is still unclear who will make it on the list and whether all options are presented. The choice to include options based on downloads within a Member State allows for more local search engines to make it to the choice screen, but again adds opaqueness to the decision-making process.

Apple App Store and app distribution on iOS – Articles 5(4), 6(4) and 6(12)

The second presentation revolved around three key topics: alternative app distribution, the requirements for operating a third-party marketplace, and alternative payment options. Apple also discussed its controversial Notarization process, to which app developers are subjected if they do not distribute their apps through the App store. The presentations related to the conditions set by Apple, warning screens, and how they support these developments.

The Notarization process – Apple views the Notarization process as its baseline defence for quality degradation. Through notarization, Apple checks if apps fit with their product description, if prices are irrationally high, and content issues such as IP or cracked apps.

Alternative app distribution – for 15 years, Apple has relied on a centralized ecosystem, where the use of Apple services such as Software Development Kits (SDKs) was mandatory. Now, to comply with the law, Apple must open up its ecosystem as to allow developers to use alternative distribution channels. In first instance, this will be limited to providing apps through third-party app marketplaces, as Apple is firmly opposed to side-loading through direct links. However, to ensure compliance Apple will allow web-based sideloading from next spring.

Third-party marketplaces -In order to provide a third-party marketplace, third parties must demonstrate minimum safety requirements, anti-fraud measures and the ability to resolve payment disputes and after cares. Third-party marketplace providers must also show a €1.000.000 line of credit. Moreover, providers of third-party marketplaces must submit to the Notarization process, where Apple determines if apps meet their standards in terms of quality and other areas. Apple has committed to ensure that apps such as Screentime and safety features continue to work for apps that are downloaded through third-party marketplaces.

Alternative payment options – Apple will allow developers to use third party payment services within their apps. Apple will also allow developers to place direct links to their promotions or discounts, something they were not previously able to do. Apple offers non-mandatory design templates for these activities. Developers will have to pay Apple a reduced transaction fee if they make in-app transactions, but will not pay a payment processing fee to Apple. For developers who direct users to their websites, Apple will charge a fee for purchases in the first seven days after the initial purchase, as a general finder’s fee. Apple will not provide any support or aftercare such as returns or dispute resolution for purchases made with third-party payment services. These terms will also only apply to digital goods, and not the sale of physical goods.

Business terms – Apple now offers two choices for software developers, their new business terms or their classic business terms. Under the latter, developers will have to rely on Apple’s services fully, as they have had to in the past. If developers choose the new terms, they can use alternative distribution channels. With the new terms, Apple will charge developer a number of different fees. First, a reduced commission on sales made through app stores. Here, Apple will charge 10% (instead of 15% under their classic terms) or 17% (instead of 30%) for the sale of software goods. For developers that want to use the Apple payment system they charge an additional 3% fee. Finally, a Common Technology Fee (CTF) of €0.50 is charged for every download after the first million downloads. For developers that make use of the new business terms, they will have one opportunity to switch back to the classic terms before committing fully.

Apple’s conditions raised many questions, in particular on whether these charges are FRAND and if they allow for durable use of third-party services by software developers. Observers raised questions about the impact of these costs on apps provided by non-profit or open source developers, the €1.000.000 requirement to start a marketplace, as well as the focus on software services while excluding physical goods. Apple defended its choices in a similar manner most of the times, referring to the value that it provides through its platforms and ecosystem. Overall, observers echoed the sentiment that Apple kept introducing self-imposed additional control measures. As a result, users have a choice, but Apple still has the ability to steer users’ choice.

Apple iOS; interoperability and tying –  Articles 6(7), 5(7)

On interoperability, Apple discussed developers ability to use their Webkit and to use the NFC chip for physical payments. Apple warned that making these changes take time, and that it has set up its interoperability request centre to allow software developers to engage with Apple to make their services interoperable. When Apple receives such a request, they will first consider whether the request falls in the scope of the DMA and if effective interoperability already exists. If there is no interoperability, they will develop and offer a project plan as to offer a solution. If Apple determines that it is not appropriate or feasible to offer a solution they will inform the software developer, if it is possible they will develop a solution based on an appropriate timeline. As a general principle, access should be available for EU users.

There are several areas where developers can be active. First, developers can now offer alternative browser engines to enable web services in app. For this, Apple will open a number of APIs so that developers can interoperate, at least if they meet the safety and security requirements. Secondly, third parties can start to make use of the NFC chip. Banking app developers are responsible for the implementation, and will again have to meet Apple’s minimum standards. Third parties will not be allowed to place their alternative web-engines on the home screen, as this would lead to  safety risks and technical issues according to Apple.

Apple’s design choices attracted critical responses from the audience. The use of the CTF would effectively exclude third-party developers from introducing alternative web-engines, Apple was accused of monopolizing middleware with its mandatory use of APIs and its fees, and it was noted that the technical limitations used by Apple excluded a host of parties and functionalities. Apple defended itself by relying on technical limitations, or the fact that it is not mandatory to offer access to its ecosystem freely.  

Data-related provisions – Articles 5(2), 6(9) and 6(10)

For the discussion on the data-related provisions, Apple reiterated that it has always praised itself for being the most privacy conscious smartphone provider. Apple protects users’ privacy through their App Tracking Transparency Program and has never used third party data for the provision of advertisements. Users already have data rights including the ability to download their data, and will extend data sharing options following the implementation of the DMA. For art. 5(2) DMA, Apple argues that it was already mostly compliant as it is rare that data is cross-used or combined within its services. Moreover, it already maintains a data minimization principle.

Apple also already provides data to its business users and provides insights through the App Store Connect API. With the implementation of the DMA, they provide their business users with new reports and information related to their performance and other metrics. It is also possible for developers to share this information with third parties from now on. Apple applies security measures so that users cannot be identified, for instance by adding noise to the data, which allows for de-identification. Apple engages in ongoing developments in the area of data sharing and availability, for instance by allowing developers to launch requests for new types of information and by setting up its help centre.

Apple received a number of questions on whether they believe these solutions are compliant. For instance, the addition of noise may be at odds with the requirement to provide accurate data to business users. The type of data that can be shared is also limited to App Store data. Here, Apple will make further changes over time.


Apple will have its work cut out for it in terms of defending its new business terms for third-party participation, its compliance with anti-steering provisions, and allowing for the uninstallation of their applications. Apple has referenced its dedication to safety, security and the user experience multiple times. However, it is not clear to which extent Apple believes it actually complies with the DMA obligations effectively, it is also not yet clear which metrics it will use to determine whether they are actually compliant or not.

Begin typing your search term above and press enter to search. Press ESC to cancel.

Back To Top