EU Digital Markets Act (DMA): Developer Rights, Gatekeeper Obligations, and API Access Guide

The EU Digital Markets Act — Regulation (EU) 2022/1925 — entered into force on 1 November 2022 and became applicable on 2 May 2023. The European Commission designated six gatekeepers in September 2023, with obligations taking effect in March 2024. If you distribute software through app stores, build messaging integrations, depend on search engine placement, or run workloads on gatekeeper cloud infrastructure, the DMA eu digital markets act developer guide is directly relevant to your compliance and commercial strategy.

DMA is not a data protection regulation. It is a market structure regulation targeting the largest digital platforms — "gatekeepers" — that act as unavoidable intermediaries between business users (developers, merchants, publishers) and end users (consumers). The DMA imposes binding obligations on these gatekeepers: what they can and cannot require of business users, what APIs they must expose, and what data they must share.

For developers, the DMA creates three categories of rights:

1. Distribution rights — you can cross-list apps at different prices, distribute iOS apps outside the App Store in the EU (eu dma apple sideloading), and install third-party app stores
2. Data access rights — business users can request portability of data generated through their interactions with gatekeeper platforms
3. Interoperability rights — third-party developers can request API access to gatekeeper messaging services (WhatsApp, Messenger, iMessage)

This guide covers the obligations, timelines, enforcement mechanisms, and practical developer checklist for operating under DMA as of 2026.

Who Is a Gatekeeper? (Art. 3 Quantitative Thresholds)

Not all large platforms are gatekeepers. Article 3 of the eu dma gatekeeper designation process sets two alternative quantitative thresholds:

Threshold A (Financial): The platform provider has an annual EEA (European Economic Area) turnover of at least €7.5 billion, OR a market capitalization or equivalent fair market value of at least €75 billion.

Threshold B (User Scale): The core platform service has at least 45 million monthly active end users established or located in the EU, AND at least 10,000 annual business users established in the EU.

A company must meet Threshold A plus Threshold B to be presumed a gatekeeper. Meeting only one threshold is not sufficient for the presumption to apply, though the Commission can designate on a case-by-case basis below these thresholds.

Core Platform Services (CPS)

The DMA applies per core platform service, not per company. The same company can be designated as a gatekeeper for multiple CPS. Article 2(2) defines ten categories of core platform services:

Designated Gatekeepers and Their Services (March 2024)

Six companies received gatekeeper designation. Each is designated for specific CPS, not for all their services:

Note: Apple's iMessage and Google's Google Assistant were designated later in separate decisions. Amazon's Alexa and Microsoft's Azure remain under Commission review as of 2026. eu dma cloud provider obligations for AWS and Azure are not yet confirmed under the designation framework, though cloud computing is a listed CPS category.

Art. 5: Absolute "Black List" Obligations

Article 5 contains the per se prohibited behaviors — the black list. These obligations apply immediately from the compliance deadline (March 2024) with no room for justification or behavioral modification. Gatekeepers cannot argue that a black-list practice is pro-competitive or efficiency-justified.

Art. 5(1): No Cross-Service Data Combination for Targeting Without Consent

Gatekeepers cannot combine personal data obtained from their CPS with data from other services (including third-party services) for the purpose of online advertising targeting, unless the end user has given explicit consent (GDPR Article 7 standard). This was one of the first enforcement targets: Meta's "pay or consent" model — which conditioned free access to Facebook on consent to data combination — was investigated as a non-compliance with Art. 5(1) and GDPR simultaneously.

Art. 5(2): No Most-Favored-Nation (MFN) Clauses

Gatekeepers cannot contractually or technically prevent business users from offering their products or services at different prices or conditions on other channels. The dma art 5 2 mfn clause prohibition means:

• Apple cannot require that an app's in-app price be the lowest price available across all platforms
• Amazon cannot require sellers to match Amazon's listed price
• Google Play cannot impose pricing parity requirements

This directly affects developers who want to offer promotional pricing through their own websites or on competitor platforms without the gatekeeper extracting the benefit.

Art. 5(4): Anti-Steering Prohibition

Gatekeepers cannot prevent business users from directing end users to their own services or to alternative channels. Specifically:

• App developers can include links to external purchase flows (e.g., "Buy on our website" inside an iOS app)
• App developers can communicate with users about pricing available elsewhere
• Gatekeepers cannot charge fees for the act of communication or linking itself

Apple's implementation of anti-steering for iOS in the EU has been contentious. The Commission opened proceedings in March 2024 specifically over Apple's conditions on linking out from App Store apps.

Art. 5(5): No Mandatory Gatekeeper Identity Service

Gatekeepers cannot require business users to use the gatekeeper's own identity or authentication service as a condition of using the CPS. Developers are not required to implement "Sign in with Google," "Sign in with Apple," or "Login with Facebook" exclusively. You can use your own auth, Auth0, Supabase Auth, or any other provider without the gatekeeper blocking your distribution.

Art. 5(7): No Retaliation for Regulatory Complaints

Gatekeepers cannot prevent, restrict, or penalize business users or end users for raising DMA compliance concerns with the European Commission or national authorities. No NDA clause, no contractual waiver, no technical consequence for filing a complaint.

Art. 6: Behavioral "Grey List" Obligations (Most Impactful for Developers)

Article 6 contains obligations that are presumptively required but where the gatekeeper may engage with the Commission in a "regulatory dialogue" to specify the precise technical implementation. These are not absolute prohibitions — they are structured obligations that must be implemented unless the gatekeeper can demonstrate that a specific implementation would threaten the integrity of the platform.

Art. 6 obligations are where most of the developer-facing impact lives: dma art 6 data portability business user, sideloading, ranking transparency, and interoperability.

Art. 6(3): Third-Party Software on Gatekeeper OS

Gatekeepers operating an operating system must allow third-party software to function on that OS, including on a technical level. Gatekeepers cannot use OS-level technical restrictions to prevent third-party apps from functioning, accessing device hardware, or communicating over the network in ways that the gatekeeper's own apps can.

Practically: Apple cannot use iOS API restrictions to prevent third-party browsers from using their own rendering engines (not WebKit), and cannot restrict access to NFC hardware in ways that advantage Apple Pay over competitors.

Art. 6(4): Sideloading — Third-Party App Stores and Alternative Distribution

dma art 6 4 sideloading is the provision that allows installation of third-party applications and app stores from sources other than the gatekeeper's official store. For iOS in the EU, this became effective in March 2024 when Apple introduced "alternative distribution."

What Art. 6(4) requires:

• Allow users to install apps from sources outside the gatekeeper's app store
• Allow third-party app marketplace operators to operate on the gatekeeper's OS
• Not technically foreclose alternative distribution paths
• Not apply disproportionate security review burdens to alternative-source apps compared to store apps

What Art. 6(4) does not require:

• Zero-friction installation (reasonable security warnings are permitted)
• No entitlement process (Apple still requires developers to obtain a "marketplace entitlement")
• Immediate approval without any review (a business-justification review is permitted)

Art. 6(5): No Pre-Installation Advantages and Fair Default Selection

Gatekeepers cannot impose pre-installation of their own services as an irremovable default, and must allow users to set third-party alternatives as defaults with the same prominence. Browser choice screens and default app selection prompts must not be designed to steer users toward the gatekeeper's own services through dark patterns or asymmetric presentation.

Art. 6(6): Business User Access to Their Own Interaction Data

Gatekeepers must provide business users with continuous and real-time access to data generated by the business user's own interactions with end users via the gatekeeper's CPS. This is the dma art 6 data portability business user right.

For a developer running an app on the Google Play Store: you have a right to access data about how your app users interact with your app listing (impressions, click-through rates, conversion data) that Google collects but has historically withheld from full disclosure. The data must be provided in structured, machine-readable format.

Art. 6(7): No Blockage of Business Users' Own Data Access

Distinct from Art. 6(6), Article 6(7) prevents gatekeepers from using technical or contractual means to restrict business users from accessing data that those business users generate through their own end-user interactions — even when that data flows through gatekeeper infrastructure. If your users interact with your service via a gatekeeper platform (e.g., a bot on WhatsApp), you have the right to access the data generated by those interactions.

Art. 6(9): Real-Time Ad Data Access (Ad Tech Transparency)

Gatekeepers providing online advertising services must give eu dma data access right to advertisers and publishers for real-time performance data, including: bidding data, pricing data, and effectiveness data. Article 6(9) targets opacity in programmatic advertising — specifically the practice of gatekeepers withholding auction-level data that would allow advertisers to verify whether they are being charged fairly.

# Art.6(9) — Structure of DMA-compliant ad performance data export
# Gatekeepers must provide this data in machine-readable format, real-time

from dataclasses import dataclass, field
from datetime import datetime
from decimal import Decimal

@dataclass
class DMAAdBidRecord:
    """
    DMA Art.6(9) compliant auction-level ad data structure.
    Gatekeepers must expose this data to advertisers and publishers
    for real-time verification and performance auditing.
    """
    auction_id: str
    timestamp: datetime
    placement_id: str
    advertiser_id: str                    # Your business user ID
    publisher_id: str                     # Where ad was shown

    # Bidding transparency (Art.6(9)(a))
    bid_submitted: Decimal                # Your bid in EUR
    clearing_price: Decimal               # What you actually paid
    second_price_if_applicable: Decimal | None  # Reveals auction mechanics

    # Impression and outcome data
    impression_served: bool
    click_recorded: bool
    conversion_recorded: bool
    attributed_revenue: Decimal | None

    # Gatekeeper attribution vs. advertiser's own measurement
    gatekeeper_attributed_conversions: int
    advertiser_measurement_conversions: int | None  # From advertiser's own tracking

    def price_discrepancy_pct(self) -> Decimal | None:
        """
        Detect if clearing price exceeds second price by more than
        margin — indicator of auction manipulation.
        """
        if self.second_price_if_applicable is None:
            return None
        if self.second_price_if_applicable == Decimal("0"):
            return None
        delta = self.clearing_price - self.second_price_if_applicable
        return (delta / self.second_price_if_applicable * 100).quantize(Decimal("0.01"))


@dataclass
class DMAAdDataExportRequest:
    """Request structure for Art.6(9) data access — send to gatekeeper API."""
    business_user_id: str
    regulation_basis: str = "DMA Art.6(9) Regulation (EU) 2022/1925"
    date_from: str = ""
    date_to: str = ""
    granularity: str = "auction_level"    # auction_level | daily | campaign
    format: str = "jsonl"                 # jsonl | parquet | csv

Art. 6(10): End-User Data Portability — Continuous and Real-Time

Article 6(10) gives end users the right to continuous, real-time data portability — including through third-party applications. This extends GDPR Article 20 portability rights by adding the "continuous and real-time" requirement (GDPR portability is a one-time export right on request).

For developers building services that compete with gatekeeper platforms: you can build applications that access a user's data from Facebook, YouTube, or Google Search history in real time — with the user's authorization — under Art. 6(10). The gatekeeper must expose an API for this purpose.

Art. 6(11): Ranking Transparency — No Self-Preferencing, Access to Ranking Data

eu dma rank transparency developer: Gatekeepers providing ranking services (search results, app store search, product listings) must:

1. Not self-preference their own services in rankings using criteria not available to third parties
2. Not use third-party data obtained through the CPS to inform the ranking algorithm in ways that disadvantage the third party
3. Provide access to ranking criteria — upon request from business users, disclose the main parameters affecting ranking

If you are an app developer on the Play Store or App Store, you now have a right to request information about what factors affect your app's ranking in search results. If Google is ranking its own apps (YouTube Music, Google Maps) above competitors using signals from the search engine that are not available to the competitors, that is an Art. 6(11) violation subject to enforcement.

Art. 7: Messaging Interoperability — Opening WhatsApp, Messenger, and iMessage

Article 7 is the most technically ambitious provision of the DMA. It requires gatekeepers operating number-independent interpersonal communication services — messaging apps — to provide interoperability to third-party providers who request it.

eu dma messaging interoperability obligations apply to: WhatsApp, Facebook Messenger, Apple iMessage, and Microsoft Teams (as designated CPS).

Interoperability Timeline

The DMA sets a phased timeline tied to compliance deadline (March 2024):

Technical API Access Process

Article 7(3) establishes the access process for third-party providers:

1. Request submission — a third-party provider submits a written request to the gatekeeper specifying the interoperability functionality requested
2. Gatekeeper specification publication — the gatekeeper must publish technical specifications at least 6 months before implementation
3. Negotiation period — gatekeeper and requesting provider negotiate implementation details; disputes escalated to the Commission
4. Implementation deadline — gatekeeper must implement within the Art. 7 timeline once request is agreed

The gatekeeper can impose security conditions on interoperability — end-to-end encryption must be preserved, and the gatekeeper can require that the third-party provider demonstrate it will not degrade the security model. However, the gatekeeper cannot use security as a blanket refusal if a technically sound implementation is possible.

Signal and Matrix Protocol Implications

The DMA does not mandate a specific protocol, but the practical reality is that end-to-end encrypted interoperability at the messaging layer requires a common protocol. The Matrix protocol (Element, Beeper) and Signal Protocol are both technically capable of federated messaging. The DMA creates the legal mandate; protocol standardization will follow through negotiation.

Developers building on open messaging protocols now have a legal right in the EU to request federation with WhatsApp and Messenger. The dma art 7 whatsapp obligation means Meta cannot indefinitely refuse interoperability — they must provide technical specifications and implement within the statutory timeline.

# Art.7 Interoperability — Request structure and status tracking

from dataclasses import dataclass
from datetime import date
from enum import Enum

class InteropRequestStatus(Enum):
    SUBMITTED = "submitted"
    SPECIFICATIONS_PUBLISHED = "specifications_published"
    UNDER_NEGOTIATION = "under_negotiation"
    IMPLEMENTATION_AGREED = "implementation_agreed"
    LIVE = "live"
    COMMISSION_REFERRAL = "commission_referral"  # Dispute escalation

@dataclass
class DMAInteroperabilityRequest:
    """
    DMA Art.7(3) — Structure for third-party interoperability access requests.
    Third-party messaging providers submit this to the gatekeeper.
    """
    requesting_provider: str
    gatekeeper: str                          # "Meta/WhatsApp", "Meta/Messenger", "Apple/iMessage", "Microsoft/Teams"
    target_cps: str                          # The specific designated CPS
    requested_capabilities: list[str]        # ["1to1_messaging", "file_sharing", "group_chat", "voice_calls"]
    submission_date: date
    status: InteropRequestStatus

    # Compliance deadline mapping (from March 2024 designation date)
    capability_deadlines: dict[str, date] = None  # {"1to1_messaging": date(2027,3,7), ...}

    # Technical specifications
    proposed_protocol: str = ""              # e.g., "Matrix", "Signal Protocol", "XMPP"
    e2e_encryption_preserved: bool = True   # Required — gatekeeper can mandate this
    security_audit_completed: bool = False

    # Commission escalation
    days_without_response: int = 0
    commission_referral_date: date | None = None

    def is_overdue(self, reference_date: date) -> bool:
        """
        Gatekeepers must respond within a reasonable period.
        Commission can be escalated if no response within 3 months.
        """
        from datetime import timedelta
        deadline = date(
            self.submission_date.year,
            self.submission_date.month + 3 if self.submission_date.month <= 9
            else ((self.submission_date.month + 3) % 12),
            self.submission_date.day
        )
        return reference_date > deadline and self.status == InteropRequestStatus.SUBMITTED

App Store Sideloading Deep Dive (Art. 6(4) in Practice)

The eu dma apple sideloading implementation is the highest-profile and most contested Art. 6(4) case. In March 2024, Apple introduced its "alternative distribution" framework for iOS in the EU. The implementation has been criticized by the Commission as potentially non-compliant.

What Apple Actually Did

Apple's EU alternative distribution framework consists of:

1. Alternative Marketplace Kit — a new SDK and entitlement that allows third-party companies to operate as "alternative marketplace operators" on iOS in the EU
2. Notarization requirement — apps distributed outside the App Store must still be notarized by Apple (a process requiring a business entity, developer account, and passing automated malware checks)
3. Core Technology Fee (CTF) — Apple imposed a fee of €0.50 per install for apps that exceed 1 million free installs per year, applicable to all distribution channels including the App Store

The eu dma core technology fee is the focus of the Commission's non-compliance proceedings, opened March 2024. The Commission's position: a fee on the act of alternative distribution chills the Art. 6(4) right, because it makes large-scale EU-only distribution economically punitive for high-volume free apps.

What Developers Can Do Now

Despite the CTF controversy, the framework is live. For EU iOS distribution:

The break-even calculation for the CTF: if your app is free and targets EU users, the CTF activates only above 1 million EU installs per year. Below that threshold, alternative distribution in the EU is effectively fee-free. Above it, the €0.50/install fee must be weighed against the 27–30% commission savings from avoiding in-app purchase commission.

# Art.6(4) EU Distribution Fee Calculator
# Determines whether alternative distribution or App Store is more economical

from decimal import Decimal

def eu_distribution_comparison(
    annual_eu_installs: int,
    annual_iap_revenue_eur: Decimal,
    is_small_developer: bool = False,  # <€1M revenue = small developer rate
    alt_marketplace_commission_pct: Decimal = Decimal("0"),  # Your marketplace fee
) -> dict:
    """
    Compare Apple App Store vs. Alternative Marketplace costs under DMA Art.6(4).
    CTF = €0.50 per install above 1,000,000 free installs/year.
    """
    CTF_PER_INSTALL = Decimal("0.50")
    CTF_FREE_THRESHOLD = 1_000_000

    # App Store commission (post-DMA EU rates)
    app_store_rate = Decimal("0.15") if is_small_developer else Decimal("0.27")
    app_store_commission = annual_iap_revenue_eur * app_store_rate

    # Alternative distribution CTF
    taxable_installs = max(0, annual_eu_installs - CTF_FREE_THRESHOLD)
    ctf_total = Decimal(taxable_installs) * CTF_PER_INSTALL

    # Alternative marketplace commission on revenue
    alt_commission = annual_iap_revenue_eur * (alt_marketplace_commission_pct / 100)

    alt_total_cost = ctf_total + alt_commission

    return {
        "app_store_annual_cost_eur": float(app_store_commission),
        "alternative_distribution_annual_cost_eur": float(alt_total_cost),
        "ctf_component_eur": float(ctf_total),
        "alt_commission_component_eur": float(alt_commission),
        "net_saving_eur": float(app_store_commission - alt_total_cost),
        "alternative_cheaper": app_store_commission > alt_total_cost,
        "ctf_activates_at_installs": CTF_FREE_THRESHOLD,
        "taxable_installs": taxable_installs,
    }


# Example: 2M EU installs/year, €500K IAP revenue, small developer
result = eu_distribution_comparison(
    annual_eu_installs=2_000_000,
    annual_iap_revenue_eur=Decimal("500000"),
    is_small_developer=True,
    alt_marketplace_commission_pct=Decimal("0"),  # Own marketplace, no 3rd-party cut
)
# CTF cost: 1M taxable installs × €0.50 = €500K
# App Store commission: €500K × 15% = €75K
# Alternative is MORE expensive at this volume because CTF dominates IAP savings

At high install volume with low IAP revenue, the CTF can make alternative distribution more expensive than the App Store — which is precisely the Commission's concern about its chilling effect.

DMA × AI Act Intersection

Two major EU technology regulations — the DMA and the EU AI Act — overlap in several practical scenarios relevant to developers.

Gatekeeper AI Assistants: Dual Obligations

AI systems deployed as core platform services — Gemini (Google), Copilot (Microsoft), Siri (Apple), Alexa (Amazon) — face both DMA and AI Act obligations simultaneously. The gatekeeper's AI assistant is:

• A CPS under DMA (virtual assistant category) → must comply with Art. 5 and Art. 6 behavioral obligations
• A high-risk or GPAI system under the EU AI Act → must comply with transparency, documentation, and conformity assessment requirements

For developers interacting with gatekeeper AI assistants via APIs:

• You have Art. 6(3) rights: the OS must allow your third-party AI application to function equally to the gatekeeper's own assistant
• You can request ranking data under Art. 6(11) if the assistant is used for recommendation or content ranking

Art. 6(11) Ranking Algorithms and AI Act Transparency

If a gatekeeper uses an AI model for app store or search ranking, dma art 6 11 requires access to ranking criteria. The EU AI Act Article 13 requires transparency for certain AI systems, and Article 50 requires disclosure when AI is used to generate or rank content. The two obligations stack:

• DMA Art. 6(11): gatekeeper must disclose the "main parameters" of the ranking algorithm to business users on request
• AI Act Art. 13: if the ranking system is a high-risk AI (Annex III, item 5: AI systems used in employment/workers management, or item 7 for credit/insurance) or GPAI-based, additional transparency documentation applies
• AI Act Art. 50: if the ranking affects what content users see, gatekeeper may have disclosure obligations to end users

AI Training Data on Gatekeeper Platforms: DMA Data Access + GDPR

DMA Art. 6(6) gives business users the right to access data generated through their interactions on gatekeeper CPS. If you use this data for AI model training, the eu dma ai act intersection creates a governance regime:

The practical implication: DMA Art. 6 opens access to data; it does not automatically provide the GDPR lawful basis to use that data for any purpose including AI training. Your GDPR assessment and AI Act Art. 10 training data documentation must account for the DMA data's provenance.

Business Users Building AI on Gatekeeper Cloud (AWS, Azure, Google Cloud)

DMA does not currently regulate cloud computing services as a gatekeeper CPS for Alphabet, Microsoft, or Amazon — the Commission has not yet designated AWS, Azure, or Google Cloud as designated CPS in the cloud computing category. If and when cloud computing CPS designations are confirmed, additional obligations (data portability, switching rights under DMA Art. 6(6)) would layer on top of the EU Data Act Chapter VI cloud switching rights already in force.

For now: developers building AI systems on gatekeeper cloud infrastructure face eu dma aws azure exposure only to the extent their application layer uses designated CPS (Google Search API, Amazon Marketplace, etc.). The cloud hosting layer is currently outside DMA scope.

DMA Enforcement

Fines (Art. 26)

The DMA's eu dma enforcement 2024 framework is among the most severe in EU digital regulation:

eu dma art 26 fines at 10% of worldwide turnover for major gatekeepers represents enormous potential liability:

• Alphabet (2022 revenue ~$283B): 10% = ~$28.3B
• Apple (2022 revenue ~$394B): 10% = ~$39.4B
• Meta (2022 revenue ~$116B): 10% = ~$11.6B

Systemic Non-Compliance (Art. 35)

dma art 35 systemic noncompliance applies when a gatekeeper has committed at least three DMA violations within an 8-year period. In addition to the 20% fine, the Commission can impose:

• Behavioral remedies: mandatory interoperability requirements, ban on acquisitions of companies active in the relevant sector
• Structural remedies: as a last resort, forced divestiture of parts of the business
• Acquisition bans: prohibition on acquiring any company active in the digital sector for a defined period

This is a provision modeled on US antitrust law concepts, but with a lower burden of proof — three EU Commission findings of DMA non-compliance (which require only a balance-of-probabilities standard) over 8 years triggers structural remedy eligibility.

Enforcement Authority

The European Commission (Directorate-General for Competition) has exclusive jurisdiction for DMA enforcement. National competition authorities can assist but cannot independently enforce the DMA. This is distinct from GDPR (which is enforced by national DPAs) and the EU AI Act (national market surveillance authorities with Commission oversight).

Active Investigations (2024–2026)

Developer Practical Checklist

1. Map Your Gatekeeper Dependencies

Identify which designated CPS your business depends on for distribution, discovery, or revenue:

Distribution:  App Store (Apple) / Google Play (Alphabet) / Amazon Marketplace
Discovery:     Google Search / Bing / App Store search / YouTube
Monetization:  Apple IAP / Google Play Billing / Amazon Payments
Communication: WhatsApp Business API / Facebook Messenger / LinkedIn
Advertising:   Google Ads / Meta Ads / Amazon Advertising
Infrastructure: (Watch for cloud CPS designations — AWS/Azure/GCP under review)

For each dependency: identify which DMA articles grant you rights, and what data or API access you should be requesting.

2. Assert Your Art. 5/6 Rights

eu dma business user rights you can exercise immediately:

• Cross-platform pricing (Art.5(2)): Set different prices on your own website vs. in the App Store. Remove any contractual language that previously prevented this.
• Anti-steering links (Art.5(4)): Add "Buy on our website" links inside your EU iOS app. Apple must permit these in the EU.
• Data portability requests (Art.6(6)/(7)): Submit formal written requests to each gatekeeper for data about your users' interactions with your app/listing. Document the request date — gatekeepers must respond.
• Ranking transparency (Art.6(11)): Request the main parameters affecting your app or content ranking. This is particularly relevant if you suspect self-preferencing.

3. EU iOS Distribution Strategy

Evaluate the CTF break-even for your specific app profile:

• Low install volume (<1M/year) + high IAP revenue: Alternative distribution saves 15–27% commission with zero CTF. Strong case for own marketplace.
• High install volume (>1M/year) + low IAP revenue: CTF likely exceeds commission savings. App Store may remain cheaper.
• Enterprise apps (B2B, internal tools): Zero IAP revenue means zero commission savings from alternative distribution; CTF is still a cost. Consider web app delivery instead.

4. Monitor Messaging Interoperability API Publications

Under Art. 7, Meta (WhatsApp, Messenger), Apple (iMessage), and Microsoft (Teams) must publish technical specifications at least 6 months before the implementation deadline. Subscribe to or monitor:

• Meta's developer blog and DMA compliance documentation page
• Apple's DMA compliance documentation (developer.apple.com/dma)
• Microsoft's DMA response documentation
• European Commission DMA portal for decisions and gatekeeper compliance reports

If you are building messaging infrastructure or a communications platform, submit Art. 7 interoperability requests as early as possible — the 6-month specification publication window starts from when you submit a formal request.

5. AI Systems and Gatekeeper Platform Data

If your AI system uses data obtained through DMA Art. 6 rights:

1. Document the DMA legal basis for each dataset (Art.6(6) business user data, Art.6(10) end-user portability, etc.)
2. Separately document GDPR lawful basis for personal elements of the dataset
3. Verify that your FRAND-terms agreements (if applicable) explicitly permit training use
4. Add DMA data provenance fields to your EU AI Act Art. 10 training data documentation

Infrastructure Jurisdiction and the DMA

The CLOUD Act Problem for DMA-Obtained Data

When the DMA grants you access to business data — customer interaction records from your gatekeeper app listing, pricing data, ad performance records — that data has real commercial value. Where you store and process it matters.

The eu dma cloud act interaction: if you process DMA-obtained business data on AWS, Azure, or Google Cloud, those cloud providers are US companies subject to the CLOUD Act (18 U.S.C. §2523). The CLOUD Act authorizes US government to compel cloud providers to disclose data stored on their servers regardless of where the data physically resides, without requiring a mutual legal assistance treaty with the EU.

This means:

• Data you receive under DMA Art. 6(6) (your business performance data from gatekeeper CPS) stored on AWS is potentially accessible to US government agencies via CLOUD Act warrant
• Trade secrets disclosed in DMA data access responses lose EU trade secret protection if stored on US cloud infrastructure
• The DMA's purpose — reducing platform concentration and restoring competitive balance — is partially undermined if the data you receive flows into another US platform's infrastructure

EU-Native PaaS as DMA-Aligned Deployment

eu native paas dma alignment: deploying on EU-native infrastructure where the operating company, legal entity, and data storage are all under EU jurisdiction eliminates the CLOUD Act overlap. The US government cannot compel a cloud provider with no US legal nexus to disclose EU customer data.

For developers asserting DMA Art. 6 data access rights, receiving data from gatekeeper platforms under EU regulation, and building services that compete with gatekeeper offerings:

• Single regulatory regime — GDPR + DMA + EU AI Act govern your data processing, without US CLOUD Act as a parallel access regime
• Reduced concentration risk — operating on digital markets act eu cloud-independent infrastructure aligns with the DMA's structural objective of reducing platform dependency
• DMA Art. 6(6) data integrity — business-sensitive data received through DMA portability mechanisms stays within EU jurisdiction

The eu dma aws azure question will sharpen if and when the Commission formally designates AWS, Azure, and Google Cloud as gatekeeper CPS in the cloud computing category. At that point, the cloud providers themselves would be subject to DMA switching obligations and interoperability requirements — creating a further incentive for EU-native alternatives.

sota.io is an EU-native PaaS — German legal entity, EU data centers, no US corporate parent — purpose-built for developers building within the EU regulatory framework. For teams processing DMA-obtained data, GDPR-sensitive workloads, or EU AI Act-governed AI systems, single-jurisdiction infrastructure eliminates the CLOUD Act layering problem without requiring complex data residency configurations on US cloud platforms.

See Also

• EU Data Act (2023/2854): B2B Data Sharing, Smart Contracts, and AI Training Data
• EU AI Act Regulatory Sandbox (Art.57-63): How to Build and Test High-Risk AI in the EU
• EU Cyber Resilience Act: SBOM Requirements and Vulnerability Handling for Developers
• EU NIS2 + AI Act: The Double Compliance Burden for Critical Infrastructure Developers
• EU Digital Services Act 2024: What Hosting Providers, Platforms, and Developers Need to Know