The Digital Markets Act Explained: Why the EU Is Imposing New Rules on Apple, Google, and Others

My last post on Sunday focused on the new features of the iOS 27 update and the related issues stemming from the EU’s Digital Markets Act (DMA). I tried to briefly outline both sides of the issue. From our perspective as tech professionals, it seems that the EU is restricting us in this area. In fact, that’s just one side of the story.

The Digital Markets Act is one of the most important European laws governing digital platforms. It influences how Apple is allowed to operate the App Store, what opportunities developers have on the iPhone, and to what extent Apple and Google are allowed to favor their own services over competing offerings.

But what’s actually behind the DMA? Why was it introduced? Who does it apply to? And why can this regulation—which is actually intended to foster more competition—lead to problems with features like Apple Intelligence and Siri?

What Is the Digital Markets Act?

The Digital Markets Act, or DMA for short, is an EU regulation designed to regulate particularly large digital platforms.

The goal is not to restrict Apple, Google, or other large companies in general. Rather, it focuses on a specific market position. The EU assumes that, due to their size and central position, large platforms can act as so-called gatekeepers. A gatekeeper controls key access to digital markets. In the case of smartphones, this access could be the operating system or the app store, for example. Anyone developing an iPhone app can hardly avoid the Apple ecosystem. Anyone developing an Android app is heavily dependent on Google’s platform.

It is precisely this dependence that forms the basis of the DMA. The EU aims to make digital markets fairer and more contestable and prevent gatekeepers from using their dominant position to systematically disadvantage competing offerings.

When was the DMA enacted?

The DMA was adopted on September 14, 2022.

On September 6, 2023, the first group of “gatekeepers” was identified. This group consisted of Alphabet, Amazon, Apple, ByteDance, Meta, and Microsoft. A total of 22 key platform services were classified as “core platform services.”

The DMA is therefore not a new response to current AI developments. It was already in the works before generative AI became a central component of the major platforms. This is precisely what makes the current development interesting, because the focus is no longer just on app stores and search engines. It is increasingly about who gains access to an operating system’s AI capabilities.

Who does the DMA apply to?

The DMA does not apply to every technology company.

It focuses on companies that meet specific quantitative and qualitative criteria and are therefore classified as gatekeepers.

So-called Core Platform Services are affected.

These include, among others:

• Online search engines
• App stores
• Operating systems
• Social platforms
• Messaging apps
• Online advertising services
• Video-sharing platforms
• Browsers
• Certain cloud and other digital platform services

For Apple, iOS/iPadOS and the App Store are particularly relevant. For Google, the DMA applies to, among other things, Android and Google Play. This does not automatically regulate the entire company, but rather the specific platform service that has been classified as a “gatekeeper” service.

What Does the DMA Require?

The DMA consists of a series of requirements. Most are barely noticeable to ordinary users. Others directly change how smartphones are used.

Alternative App Stores

The best-known regulation concerns app distribution. Apple must allow alternative methods of app distribution in the EU. Under certain conditions, apps can be offered through alternative app stores or via web distribution. Developers are also permitted to inform users about alternative purchasing options and direct them to offers outside the App Store. This is a significant departure from Apple’s existing model. As a result, the App Store is no longer necessarily the only way software can be installed on an iPhone in the EU.

Alternative Payment Systems

The rules regarding payments have also been changed. Under the relevant DMA rules, Apple and Google may not simply force developers to use only their own in-app payment systems. Developers must also be given the opportunity to inform users about alternative offerings outside the respective app store. For us developers, this means more choices.

No Preferential Treatment for Own Offerings

Another important point concerns so-called “self-preferencing.” A gatekeeper may not simply give preferential treatment to its own products and services over comparable offerings from competitors. This can apply, for example, to the display of search results or the positioning of the gatekeeper’s own services in search results.

Interoperability

If Apple or Google uses a specific feature of its operating system for its own apps, the gatekeeper must also make that feature available to third parties.

Article 6(7) of the DMA therefore requires gatekeepers, under certain conditions, to enable third-party providers to achieve effective interoperability with the operating system’s hardware and software features.

This also applies to AI features, and this is precisely where the connection to Apple Intelligence begins.

Why is this difficult for Apple and Google?

At first glance, the call for interoperability sounds relatively simple: If Apple has a feature, others should be able to use it too. Technically, however, this is much more complicated, since an operating system consists of a large number of interconnected software components.

Some of these components have deep integration with the system and have access to:

• personal data
• notifications
• contacts
• files
• location information
• microphone and camera
• other apps
• hardware functions
• security features

Greater interoperability often means a larger potential attack surface. This is because many of the items listed above are critical from an IT security perspective.

Apple must therefore ensure two things simultaneously: third-party providers should be given comparable capabilities, and users should be protected as effectively as possible.

The EU has certainly taken this conflict into account. The interoperability measures established by the Commission explicitly ensure that interoperability remains compatible with data protection, security, and the integrity of the operating system.

The problem becomes even greater with AI

With traditional operating system functions, it’s possible to define relatively precisely which APIs a developer is allowed to use. With artificial intelligence, this is more difficult.

Take Siri, for example: Siri can link information about the user, analyze the current screen, and perform actions within other apps.

If Apple makes these capabilities available to its own AI, an obvious question arises: Should another AI be granted the same capabilities? How far must this equal treatment extend? Should another AI also be allowed to access the screen content? Should it be allowed to control other apps? How can we prevent third-party AI from receiving more data than the user has actually authorized?

This is precisely why interoperability for AI is becoming a significantly more complicated issue than, for example, supporting a smartwatch. The EU has now explicitly addressed this development. As part of the 2026 DMA review, AI and equal access to operating system functions were identified as important future issues.

An Example: Siri and Noxidox

This also explains why the situation surrounding Siri AI in the EU is of interest to Noxidox.

Let’s imagine that Noxidox offered an app intent: “Search my documents for information about my project.” Technically, Siri could trigger this intent. The actual processing could then take place entirely within Noxidox:

Siri → App Intent → Noxidox → local RAG search → local foundation model

This is relatively easy to delineate. It gets more complicated when Siri itself is supposed to delve deeply into the documents or the results. Then the question arises as to what data Apple Intelligence is allowed to see, what processing takes place locally, and when Private Cloud Compute might be used.

Apple Can’t Simply Say, “This Feature Is Proprietary”

A fundamental principle of the DMA regulation is that the gatekeeper must not use its dominant position to exclude innovative competition. So, basically, this is very positive for an app developer like me. The point is to make certain functionalities accessible if they fall under the relevant DMA obligations. To this end, the European Commission has set guidelines for Apple on how third parties should be able to access certain iOS features.

These include, for example, notifications, certain Wi-Fi features, NFC, pairing, and other functions.

So this is the DMA approach: The EU does not dictate which specific technical solution Apple must implement. However, it can stipulate that a certain form of interoperability must be effectively possible.

What solutions are available?

There is therefore no single solution for meeting the DMA requirements. Instead, there are various technical and regulatory models.

1. Public APIs

The traditional approach is a public API. Apple provides an interface through which third-party providers can access a specific feature. This is also the simplest option for us developers because the interface is clearly defined. At the same time, Apple can control permissions and security mechanisms.

2. Permission Models

Finely granular permissions are becoming increasingly important, especially for AI features. For example, an app could be granted access to specific information without automatically having access to all personal data. This also aligns with the principle Apple already uses for many other system features.

3. Request-Based Interoperability

For features that are not already available via a public API, a developer can officially request interoperability. To this end, Apple was required to establish a more transparent process in accordance with EU regulations. Developers should be able to understand how requests are processed and what technical options are available.

4. Equivalent, but Not Necessarily Identical, Solutions

The DMA does not necessarily require Apple to disclose its entire internal technology to third parties. What matters is effective interoperability.

Apple can therefore, in principle, develop a technical solution that takes security and data protection requirements into account, as long as this does not effectively place third-party providers at a disadvantage. The European Commission has explicitly taken this into account in its decisions to date.

Do these solutions already exist?

Yes, because the DMA is by no means a purely theoretical regulation anymore. Apple, Google, and others have already implemented numerous changes. A recent example is data transfer between iPhones and Android devices.

Apple and Google are working on solutions that will allow users to transfer significantly more personal data between devices when switching between ecosystems. This includes, for example, contacts, calendars, messages, photos, documents, and other data.

The iOS operating system now also offers concrete interoperability solutions, such as improvements to notifications, Wi-Fi, NFC, pairing, and other features for third-party devices.

The DMA is thus already bringing about concrete changes to the technical architecture of the major platforms.

And what about Google?

The fundamental problem at Google is similar, even if the technical starting point is different. The Android operating system has traditionally been more open than iOS. Nevertheless, with Android, Google Play, and its own services, Google wields enormous control over the ecosystem.

Here, too, the question arises: Which features is Google allowed to use exclusively for its own services, and which must be made available to competing services?

Once again, the topic of AI is particularly interesting here.

In 2026, the EU examined specific measures regarding the interoperability of third-party AI on Android. The areas examined include, among others, voice activation, context-based information, and the ability of AI services to interact with other apps.

What does this mean for developers?

For us software developers, the DMA is a double-edged sword, as the case of Siri AI shows. On the one hand, it opens up new possibilities. For our apps, we may gain new opportunities to integrate our ideas deeply into the system. Or, as is currently the case, we may be excluded from innovations. Then we have to deal with different rules for different regions, which complicates implementation and testing. My App Intent, for example, might be processed very differently on an iPhone outside the EU than on my test device.

And what does this mean for Noxidox?

For Noxidox, the DMA regulation is therefore not just a regulatory issue. In the long term, it could have a direct impact on the app’s architecture.

The key question for me will be which new interfaces Apple actually makes available to third-party developers through the DMA—and what conditions are attached to them.

For a privacy-first app, not every form of interoperability is automatically desirable. Noxidox shouldn’t simply be integrated as deeply as possible into the operating system. The integration must continue to align with the app’s fundamental privacy concept. However, I’d also like to take users’ wishes into account, and integration with iOS can lead to many workflow optimizations.

One final point

The DMA is neither an “anti-Apple law” nor a law that fundamentally prevents Apple or Google from developing their own technologies.

It pursues a different goal: A company should not be able to use its gatekeeper position to permanently control access to a digital market.

However, it has not yet been definitively clarified how far these rules should extend when it comes to AI.

This discussion will need to take place in the coming months.