CMA App Store Commitments: What Devs Must Do Now

On February 10, 2026, Apple and Google agreed to a package of CMA app store commitments in the UK, with a public consultation through March 3 and regulator monitoring slated to start on April 1. The headline promises: fair, objective, and transparent app reviews and rankings; no unfair use of competitor app data; and—on Apple’s side—clearer, easier pathways to request access to iOS system features like Wallet/NFC and other interoperability hooks. Here’s the thing: even if you’re not UK‑only, platform‑level shifts like these tend to ripple outward. Let’s make them work for you.

What exactly changed—and when?

Two dates matter. February 10, 2026: the CMA published proposed commitments and opened consultation. April 1, 2026: subject to feedback, the regulator begins monitoring whether Apple and Google deliver what they promised. In practice, that means your UK‑distributed apps should expect more transparent review communications, documented criteria, and the ability to query or appeal decisions with better data trails. Ranking systems—the opaque heart of discovery—must be fair and non‑discriminatory, especially where your app competes with a first‑party offering.

On iOS specifically, Apple committed to a more structured process for developers to request access to certain device capabilities. Think NFC for payments and passes, Wallet integrations, and similar surface areas where Apple historically controlled entitlements tightly. We don’t suddenly get a magic entitlement switch; we do get a published process, clearer criteria, and timelines to evaluate requests.

Does this only affect the UK?

Formally, yes—the legal hook is the UK’s digital markets regime. Functionally, probably not. Apple and Google don’t love maintaining divergent processes by region for long. Expect documentation, tooling, and policy text that starts UK‑first and then bleeds into global developer communications. If you’re shipping in the EU, cross‑reference with DMA‑driven changes you’ve already navigated. If you’re US‑only today, don’t assume stasis: discovery and review systems are hard to fork cleanly, and improved transparency in one market often becomes the default FAQ everywhere.

Prepare for the CMA app store commitments by April 1

Here’s a pragmatic, team‑ready plan. Assign an owner for each track and set weekly standups until mid‑April.

1) Prove you’re treated fairly in reviews

Stand up a lightweight “review dossier” per release: the exact binary, changelog, the date/time of submission, the review feedback, and the decision latency. Track deltas between your app’s average review time and public first‑party benchmarks where available. If a competitor ships similar functionality faster, document it. Your goal isn’t to litigate every rejection; it’s to build a time‑series that makes patterns obvious—and defensible—if you need to escalate.

Implementation tips: instrument CI/CD to post submission metadata to a shared dashboard (e.g., a Notion or Airtable table coupled with a Looker Studio chart). Keep the feedback thread text, including timestamps and any requested clarifications. Normalize identifiers (bundle ID, version, build number) across Apple and Google so you can compare cycles without mental math.

2) Audit ranking neutrality like you mean it

ASO teams: a weekly top‑30 snapshot for your core keywords in the UK storefront is now table stakes. Record your rank, total first‑party apps in the viewport, and any recurring modules (editorials, featured blocks) that affect tap‑through. Track “competitor proximity”—how close a first‑party app sits to your term cluster—and the volatility of those placements around your major releases. Expect more documentation from Apple/Google on ranking principles; your job is to validate with real data.

Pro tip: build a small crawler using official web previews where allowed and human spot‑checks to avoid triggering anti‑scraping blocks. Pair this with Store Analytics to correlate impression share and product page views. When a rank dips without a traffic dip, it’s often a module change, not a core rank change. Knowing the difference prevents bad roadmap calls.

3) Lock down developer data boundaries

The commitments highlight the handling of developer data—what you submit during review and how it’s used. On your side, draw a bright line between “review‑only” artifacts (e.g., demo accounts, test credentials, exposed staging endpoints) and production operations. Rotate review creds every cycle. If you share metrics or feature flags for test access, scope and expire them by default. Document exactly what reviewer access you provide and for how long; your security team will thank you after your next audit.

4) Use the new iOS interoperability request path

If your roadmap includes Wallet passes, NFC‑based experiences, or similar entitlements, designate a PM/Eng pair to own the request pipeline. Pre‑work: lay out the user value, security model, abuse mitigations, and competitive rationale. Build a demo that showcases the guarded flows (e.g., on‑device cryptography, rate limiting, fallback UX for unsupported devices). The best time to prepare a request was yesterday; the second‑best is before April 1 so you can learn how the new process behaves under load.

Architecture note: for Wallet/NFC, isolate the capability behind a feature service with server‑side gating. That way you can gracefully ship to regions where the entitlement is granted while degrading UX elsewhere without binary forks.

People also ask

Will app store fees drop because of this?

No immediate fee changes are in scope. The commitments focus on process fairness, ranking transparency, and access pathways. Fees are part of separate—and ongoing—policy battles. Plan for today’s economics; treat any fee movement as upside, not a dependency.

Do I need a UK legal entity to benefit?

No. If your app is available in the UK storefronts, you’re in the blast radius. What you’ll want is a UK market testing cohort so you can verify how review communications and ranking visibility behave there versus your other target regions.

Will Apple actually open up NFC payments?

What’s on the table is process clarity and a structured way to request access—not blanket enablement. Expect more transparent criteria, example use cases, and timelines. If your UX relies on tap‑to‑pay or secure pass provisioning, design an off‑ramp and a long‑tail fallback (QR, barcode, link‑based handoffs) so you can ship value even while entitlements are pending.

Metrics and dates you can bank on in Q1 2026

• February 10, 2026: CMA published proposed commitments from Apple and Google and opened a consultation window.

• March 3, 2026: Consultation closes. Expect minor clarifications but not a wholesale rewrite.

• April 1, 2026: Monitoring begins. Assume KPIs around review latency, reversal rates on appeal, ranking stability for competing apps, and responsiveness to interoperability requests.

Use those dates to frame your own internal SLAs: a 24‑hour turnaround on review clarifications, weekly ranking audits, and a two‑week window to assemble any escalation dossiers.

Fast‑track checklist: your 30‑60‑90 day plan

The goal isn’t perfection; it’s momentum with evidence.

• Day 0–30: Spin up the review dossier, ranking snapshots, and a security playbook for reviewer access. Identify one entitlement request you could credibly file on iOS—Wallet pass, NFC use case, or similar.
• Day 31–60: File the entitlement request with polished documentation and a working demo. Add anomaly detection to your ASO dashboard (e.g., notify if rank shifts >5 positions within 24 hours for top keywords).
• Day 61–90: Run a retrospective on review outcomes and rank movement since April 1. If patterns look off, escalate using your data assets. Fold learnings into your release checklist.

Designing for Wallet/NFC access without painting yourself into a corner

Here’s a field‑tested pattern. Gate device capability behind a server‑driven feature flag with three states: Denied, Pending, Granted. In Denied, surface an alternate path (barcode or deep link to a web flow). In Pending, let users pre‑enroll and cache provisioning data to shrink time‑to‑value when approval lands. In Granted, enable native flows with on‑device encryption and rate‑limited APIs. Make sure analytics are partitioned by state so you can demonstrate user benefit when you escalate entitlement requests.

Security edge cases: never hardcode entitlement assumptions in the client; always revalidate on app launch and sensitive actions. Log entitlement errors separately from general network failures so you don’t lose the signal in a sea of 500s.

Measuring ranking neutrality without violating platform rules

Don’t brute‑force scrape. Combine allowed web previews, human panel checks, and your own impression share analytics. Focus on consistency: same device model, same UK locale, same time of day, and clean sessions. Build a “competitor adjacency” metric—how often and how closely first‑party apps appear near your core terms—and watch its trend line. That’s the simplest way to tell whether transparency gains translate into meaningful discovery stability.

Risks, realities, and how to de‑risk them

• The commitments improve process visibility; they don’t guarantee specific outcomes. You still need production‑grade release hygiene: reproducible builds, privacy manifests that match behavior, and app review notes that pre‑empt obvious questions.

• Interoperability requests create product debt if you pin your core UX to an entitlement. Always ship a viable non‑entitled path that doesn’t feel like punishment. Your conversion will thank you.

• Ranking transparency won’t remove marketplace noise. Seasonal spikes, editorial modules, and competitor bursts still move the board. Measure longer windows and tie rank to business outcomes, not vanity snapshots.

Where this intersects other 2026 compliance work

If you’re already modernizing policies and user flows, bundle this effort with adjacent work:

• App metadata and rating governance: reuse the enforcement mindset you applied in our analysis of App Store Age Ratings: The Enforcement Phase to keep submissions clean and defensible.
• Roadmap operations in App Store Connect: align with the platform tweaks covered in February 2026 App Store Connect Update: Ship Smarter so your teams exploit new fields and workflows instead of fighting them.
• Policy posture across ecosystems: if Google Play policy changes touch your category this year, our Play Age Signals API: 2026 Compliance Playbook outlines the instrumentation mindset you’ll want everywhere.
• Regulatory resilience: leadership teams should revisit the risk register using our EU AI Act 2026: The Last‑Mile Compliance Playbook as a template—different law, same need for traceability and proactive documentation.

A simple framework for escalations that work

When you need to push back on a rejection or questionable ranking behavior, use SPARQ: Summary (one paragraph in plain English), Proof (logs, screenshots, timestamps), Alignment (cite the stated review or ranking principles), Risk (user harm or competitive disadvantage), Quiet ask (the narrow, reasonable remedy you want). Keep it short. Make it easy for the reviewer to say yes without rewriting policy.

What to do next

• Stand up a shared dashboard for submissions, review outcomes, and ranking snapshots in the UK storefronts by the end of this week.
• Nominate a PM/Eng pair to file one iOS interoperability request you can stand behind with a demo and security doc.
• Rotate and scope all reviewer credentials; expire them automatically post‑review.
• Instrument a competitor adjacency metric and set weekly alerts for outliers.
• Schedule a leadership readout for the week of April 7 to decide whether to escalate any patterns you’ve observed since monitoring began.

Zooming out: the spirit of these changes is straightforward—less gatekeeping theater, more documented process, and a genuine path to request access to system capabilities. Teams that treat this as a compliance chore will burn time chasing edge cases; teams that operationalize the transparency will move faster, ship cleaner, and make a stronger case when they need exceptions. Your roadmap doesn’t have to wait. Ship, measure, document—and be ready on April 1.