· Added

FSFE says Apple is still blocking DMA interoperability in practice (56 requests, no solutions yet)

A credited summary of FSFE’s April 2026 report arguing Apple’s request-based DMA interoperability process is producing lots of paperwork and very little actual access. The practical takeaway for app teams: expect platform capability access to remain uneven, and plan for compliance and distribution strategy to vary by region.


Original report (source): Free Software Foundation Europe (FSFE) - “Apple keeps challenging its interoperability obligations under the DMA” (Apr 20, 2026)


Summary

FSFE published a report arguing that Apple’s DMA interoperability compliance is still not translating into real-world access for third-party developers.

Their headline claim (based on Apple’s public DMA request tracker) is stark: as of Mar 22, 2026, 56 formal interoperability requests had been filed and none had resulted in a concrete solution.

FSFE’s framing is that a “request-based” model creates a long, fragile path for developers (accounts, fees, detailed requests, review cycles, long timelines), plus the operational fear of account closure while you are in the middle of it.

1) “Interoperability” is turning into process, not capability

Even if you disagree with FSFE’s policy stance, the operational signal is useful:

  • the DMA does not automatically mean “you can now use the same OS-level features Apple apps use”
  • instead, it can mean “you can now file a request and see what happens”

For app teams, that is a planning difference. It affects what you commit to, what you promise partners, and what you tell your customers.

2) Region-by-region reality is the new default

The practical marketing and product implication is not just “EU vs rest of world”. It is that capabilities, distribution options, and allowed flows can diverge by region and then lag for months.

If you run growth experiments, you should assume:

  • your payment and linking UX may need EU-only variants
  • support scripts and refund expectations may need per-region differences
  • measurement plans may need “channel truth” labels, not one global bucket

3) The boring part: write down your dependency map

This kind of regulatory change is where teams get burned by vague assumptions.

Tiny win: make a one-page dependency map for the next quarter:

  • what OS/store capabilities you rely on (payments, NFC, background modes, device APIs)
  • what you would do if access becomes region-gated or delayed
  • who owns the user-facing copy (support, legal, product, marketing)

That doc is not exciting, but it prevents “wait, we can’t do that in EU?” surprises.


Read the source: https://fsfe.org/news/2026/news-20260420-01.html

Editor: App Store Marketing Editorial Team

Insights informed by practitioner experience and data from ConsultMyApp and APPlyzer.

Want help with ASO?

If you want this implemented for your app, check out our services - or run your workflow in APPlyzer.