App Store Policy Changes You Must Act On Now

App store policy changes aren’t a headline; they’re a backlog. December 2025 brought real, dated shifts: Apple’s concessions in Japan, a settlement timeline in Brazil, a new Google Play policy note in the U.S., and a federal court move in Texas. If you own a P&L or a release train, this isn’t optional reading. It’s the work.

Let’s get concrete about what changed, what it means for product, billing, and consent flows, and how to ship the right fixes in the next 60–90 days. We’ll use “app store policy changes” as our anchor because that’s exactly what’s driving the tactical decisions you need to make this quarter.

What actually changed in late December 2025

Apple announced iOS changes in Japan on December 17, 2025 to comply with the Mobile Software Competition Act (MSCA). The headline: developers can distribute iOS apps via authorized alternative marketplaces and process payments outside IAP in Japan, with a new baseline notarization step for apps distributed outside the App Store. Apple frames this as enabling choice while trying to mitigate malware, fraud, and privacy risk. (apple.com)

On December 23, 2025, Reuters reported Apple settled a Brazilian antitrust case, agreeing to allow third‑party app stores and alternative payment processing in Brazil within 105 days. The settlement runs three years and includes significant potential fines for non‑compliance. (reuters.com)

Google Play posted a December 9, 2025 policy announcement expanding alternative billing programs for eligible developers serving U.S. users and launching an external content links program. There’s a compliance date: January 28, 2026 if you want to keep linking users externally or offering alternative billing. (support.google.com)

Also on December 23, a U.S. federal judge blocked enforcement of Texas’s new App Store Accountability Act (a state‑level law that would have mandated broad age verification and consent). It’s a preliminary injunction, so litigation continues, but the ruling pauses immediate compliance burdens in that state. (reuters.com)

Zooming out, regulators continue to scrutinize Apple’s ATT. Italy’s competition authority fined Apple roughly €98 million (about $116 million), finding the implementation burdensome for third‑party developers compared with Apple’s own apps; Apple is appealing. Whether you agree or not, the signal is clear: consent UX and tracking parity are under the microscope. (theverge.com)

Immediate implications for product and revenue

Here’s the thing: the changes aren’t “global policy” toggles. They’re market‑specific allowances with added review and security steps. Treat them as new distribution and billing lanes that exist only in certain countries and only for certain developer profiles.

For Japan: you may choose to distribute via alternative marketplaces and bypass Apple IAP for digital goods, but your app must pass Apple’s new notarization review when sideloaded via those marketplaces. That process is not full App Review, but it isn’t a rubber stamp either; budget time for failed checks and resubmissions. (apple.com)

For Brazil: start your 105‑day timer from December 23, 2025. That puts your operational deadline in early April 2026. Legal will want the settlement text; product needs to plan marketplace onboarding, billing SDK swaps, and anti‑fraud monitoring. (reuters.com)

For U.S. Android: the Play policy update means you can apply for alternative billing or link externally, but only if you meet program rules and hit the January 28, 2026 deadline. That affects your paywall UX, price disclosures, refund flows, and customer support macros. (support.google.com)

FAQ: Do we need separate builds for Japan and Brazil?

Not necessarily. A single codebase can handle region‑specific marketplace and payments logic if you architect flags well. Use a capability matrix keyed by country, store, and user segment (e.g., enterprise distribution vs. consumer). Keep binaries identical when possible and inject marketplace configuration server‑side to avoid a version skew that turns hotfixes into a whack‑a‑mole.

Policy changes meet engineering reality: a practical framework

When policy shifts land mid‑quarter, teams thrash. Here’s a framework we’ve used with clients to make it survivable:

1) The 3x3 Policy Matrix

Create a living grid with rows for Distribution, Billing, and Consent; columns for Japan (MSCA), Brazil (CADE settlement), and U.S. Android (Google Play programs). For each cell, record: what’s allowed, what’s required, review steps, developer enrollment links, and your owner/ETA. This keeps legal, product, growth, and engineering aligned on the same truth table. (apple.com)

2) Feature Flags by Market

Implement a tri‑layer flag approach: hard flags (kill‑switches, set server‑side), soft flags (A/B or staged rollouts), and guard rails (client‑side eligibility checks). For example, a billing_provider flag that returns apple_iap, external_link, or alt_billing by country/store combo lets you ship one app that behaves correctly per policy.

3) Review‑Aware Release Trains

Plan notarization or special review windows into your release train. If an alternative marketplace in Japan or Brazil adds days of review latency, treat that like an external dependency—because it is. Protect critical bugfix lanes by reserving an emergency track for security and compliance hotfixes only.

Where consent UX and AI models collide

Adding AI features? Apple updated App Review Guidelines in November to call out data sharing with third‑party AI explicitly. If you stream user data to an external model, you must disclose and obtain explicit permission. That language may sound like prior privacy rules, but the explicit reference to “third‑party AI” removes ambiguity. Build granular toggles and a clear “data goes here” explanation in plain English. (techcrunch.com)

Practical pattern: a two‑step consent where step one explains local processing vs. optional cloud enrichment, and step two requests permission that’s scoped to specific AI vendors or endpoints. If you can’t be that specific, you’re risking rejections and user distrust.

People also ask: Can I link out to my website to sell subs on Android in the U.S.?

Yes—if you enroll in the program and implement the disclosures and handling described in Google Play’s policy announcement. And you must be compliant by January 28, 2026 to keep using those options. Map your flows for price transparency, refunds, and support; your CS team will need updated macros. (support.google.com)

People also ask: Will Texas’s paused law affect my roadmap?

The preliminary injunction blocked enforcement for now. That eases immediate age‑verification build pressure in that state, but it’s not a final decision. Keep a “lightweight age gate” in your backlog so you’re not starting from zero if the legal posture shifts. (reuters.com)

Designing the new paywall

Multiple payment lanes means multiple UX branches. A robust paywall now needs:

• Market‑aware copy and disclosure: Users in Japan and Brazil may see different legal language, fees, or payment options compared with the U.S.

• A reconciliation plan: Refunds and chargebacks look different across Apple IAP, external links on Play, and alternative billing providers. Your finance team needs daily exports keyed by provider and country.

• Observability: Instrument separate events for each lane—paywall_view_alt, external_link_click, iap_success, alt_billing_success. That lets you monitor drop‑offs and deliver data to support audits.

Security, notarization, and the real-world risks

Alternative marketplaces and external billing expand your attack surface. Apple will run baseline notarization checks for apps distributed outside the App Store in Japan, but that’s not the same depth as full App Review. Treat notarization as necessary, not sufficient. Add your own supply‑chain scans, dynamic analysis, and post‑install telemetry for fraud and abuse. (apple.com)

If your mobile security backlog has been on pause, restart it. We’ve written at length about rapid patch‑and‑verify rhythms for mobile teams under pressure; the same discipline applies here when policies push you to ship new integrations quickly. Our guidance on rapid response for mobile teams under scrutiny is a good refresher. See our briefing on ATT pressure and mobile risk management and our security playbooks in the blog.

The compliance checklist for Q1 2026

Use this as your working doc in Jira or Linear. Assign owners.

Japan (MSCA)

• Decide: App Store only vs. alternative marketplaces.
• If alternative marketplaces: enroll, implement notarization packaging, and test submission failure paths.
• Payments: map IAP vs. alternative payments; localize fee and refund terms.
• Consent: verify AI data‑sharing disclosures if using third‑party AI APIs. (apple.com)

Brazil (CADE settlement)

• Timeline: target early April 2026 as a practical deadline (105 days from Dec 23, 2025).
• Marketplace: identify partners, review their review processes, SLAs, and anti‑fraud controls.
• Billing: contract with providers; implement webhooks for receipts, refunds, and fraud signals.
• Support: translate FAQs; confirm local tax handling. (reuters.com)

U.S. Android (Google Play)

• Enrollment: apply for alternative billing/external links program(s).
• Deadline: ship compliant flows by January 28, 2026.
• UX: add price transparency, dispute paths, and support contact.
• Analytics: segment events by billing lane for audits. (support.google.com)

Global

• Feature flags: implement server‑driven market flags for distribution and payments.
• Monitoring: separate graphs for conversion by lane and market.
• Legal: maintain a single source of truth for allowed options per market; review quarterly.
• Security: expand CI to include dependency checks and binary integrity validation on marketplace builds.

Engineering patterns that scale across markets

• Abstract the paywall. Build a provider‑agnostic interface with adapters for Apple IAP, Google Play Billing, and external providers. Keep all price and tax logic server‑side.

• Centralize eligibility. One eligibility endpoint returns which marketplaces and billing options a user can access, based on region, device, app store source, and entitlement state.

• Idempotency everywhere. Purchases and refunds execute once even if a user retries or the app drops offline. Use idempotency keys and durable queues per provider.

• Receipts as the source of truth. Treat every provider’s receipt as an auditable record; store normalized receipts and the raw provider payloads for disputes.

• Compliance mode. Add a silent “compliance logging” layer for flows touched by new policies. If a regulator asks “what did the user see, and when?” you have the evidence.

People also ask: Will ATT change again?

Expect scrutiny of tracking and consent to continue. The Italy fine shows regulators are looking at how consent mechanics play out in practice, not just in policy text. Keep your consent UX honest, specific, and symmetric across first‑party features and third‑party SDKs. (theverge.com)

Risk and tradeoffs, candidly

Alternative marketplaces promise lower fees or better reach, but they also add another review queue, a new fraud vector, and a dependency you don’t control. External links on Android can improve ARPU but complicate refunds and support. AI‑assisted features can boost engagement yet trigger stricter consent and data‑handling obligations. None of these are free wins; they’re tradeoffs. Decide intentionally.

What to do next (this week)

• Appoint a single DRI for marketplace and billing strategy; give them decision‑making authority.
• Stand up the 3x3 Policy Matrix and circulate it.
• Audit your paywall and consent flows against Japan, Brazil, and U.S. Android requirements.
• Implement server‑side feature flags for distribution and billing lanes.
• Book time with legal and finance to define refunds, taxes, and dispute paths per provider.
• If you need help, our team runs focused compliance sprints. See mobile product and compliance services and how we work in what we do. Or just contact us to sanity‑check your plan.

If you’re starting late, here’s a 30/60/90 plan

Days 1–30: Prove compatibility

• Build the eligibility endpoint and provider‑agnostic paywall adapter.
• Implement consent UX with explicit AI data‑sharing disclosures if applicable.
• Enroll in Google Play programs and read notarization docs for Japan. (support.google.com)

Days 31–60: Ship and measure

• Roll out flags by market; soft‑launch alternative lanes to 5–10% of eligible users.
• Add observability dashboards by lane and country.
• Train support on refunds and disputes per provider.

Days 61–90: Harden

• Expand to full rollout; run a forced‑update if needed.
• Pen‑test purchase flows and marketplace builds.
• Conduct a documentation pass so audits aren’t a fire drill.

Will these changes stick?

Some will, some won’t. The Texas injunction could flip on appeal. Japan’s MSCA path will evolve as Apple and marketplace operators iterate on safeguards. Brazil’s settlement runs for three years, and you should expect periodic adjustments. Google’s programs are live now with a date certain for compliance. That mix—policy plus program plus court order—is the new normal. (reuters.com)

If you need a deeper explainer on previous shifts and how we recommend teams execute under time pressure, read our earlier piece on what devs must do when app store policies move. Then apply the playbook above to the concrete changes dated in December 2025.

Bottom line

App store policy changes just created new lanes for distribution and billing in Japan, Brazil, and U.S. Android—with real deadlines and meaningful review steps. Treat them as product features with owners, flags, SLAs, and metrics. If you execute with a single codebase, a provider‑agnostic paywall, and strong consent UX, you’ll capture upside without letting compliance eat your roadmap.