Apple’s Brazil App Store Changes: A 105‑Day Plan

On December 23, 2025, Brazil’s competition authority approved a settlement that requires Apple to allow alternative app stores and expanded payment options on iOS in Brazil. The headline for product and engineering leaders: Apple Brazil App Store changes are now on a 105‑day implementation clock once the terms formally take effect. Whether you sell subscriptions, one‑offs, or run a marketplace, you need a readiness plan that addresses distribution, payments, security, support, and analytics—fast.

What exactly is changing—and how fast?

Here’s the distilled version of what Brazil’s settlement sets in motion for iOS:

• Apple will allow third‑party app stores in Brazil.
• Developers will be permitted to use external payment methods in‑app and to link out to the web for purchases of digital goods/services.
• Apple may present informational warnings, but they must be neutral and not add friction compared to Apple’s own flows.
• There’s a 105‑day implementation window once the terms are binding for developers, and the agreement lasts three years. A substantial non‑compliance fine is attached.

On fees, press reports summarizing the terms indicate a familiar pattern: standard App Store transactions remain subject to either a 25% or 10% commission (depending on eligibility), an additional ~5% if you still use Apple’s payment rails, ~15% if you include actionable external purchase links, and a ~5% Core Technology Commission applicable to alternative app stores. Expect Apple’s official documentation to finalize the exact numbers and reporting format; plan your models now, but verify against Apple’s published terms when they drop.

Apple Brazil App Store changes: why this matters to your roadmap

If you operate in Brazil, you’re making near‑term calls about distribution and monetization. If you don’t yet operate there, this is still important because Brazil is a top‑10 app economy by downloads and revenue potential, and regional precedents often echo elsewhere. What you choose—stay on Apple’s terms, add external links, adopt third‑party payments, launch on an alternative store, or all of the above—reshapes your funnel, risk profile, engineering backlog, and support model.

Here’s the thing: this isn’t a binary “App Store vs. not.” You’ll likely run a hybrid approach. For many consumer apps, Apple’s native purchase flow still converts well; for price‑sensitive segments or high‑ARPU subscriptions, external links or third‑party payments can expand margin—so long as you keep churn risk, trust signals, and support costs in check.

Data check: the timeline and reported fee structure

• Settlement approval date: December 23, 2025.
• Implementation window: 105 days after terms become binding for developers (the binding start date will be clarified in the final docs).
• Agreement duration: three years.
• Reported fee signals: 25% or 10% on App Store transactions; +5% if Apple processes payment; 15% for external link purchases (when you include a tappable link); ~5% Core Technology Commission for alternative stores.

If the binding date landed on, say, January 20, the 105‑day target would fall around early May. Don’t wait for the calendar math—begin procurement, legal, and engineering spikes now. If the specifics shift slightly, your plan should adapt with toggles rather than be blocked.

Let’s get practical: your 105‑day readiness plan

Week 1–2: Decide your distribution and payments posture

Hold a 90‑minute cross‑functional with product, engineering, legal, finance, fraud, and support. Pick one of three starting positions for Brazil:

• App Store‑only (status quo).
• App Store + external links or third‑party payments (hybrid).
• App Store + alternative store presence (dual distribution).

Define your gating criteria: target margin, acceptable conversion hit from warnings, customer trust requirements, and operational complexity. For reference on policy shifts and tradeoffs, read our practical take in App Store Policy Changes: What Devs Must Do Now.

Week 3–6: Payment architecture and SKU strategy

• Separate SKUs and price books by channel. Don’t let external‑link SKUs bleed into App Store receipts and vice versa.
• Choose a PSP for Brazil with proven antifraud, boleto/pix support where relevant for your use case, and robust chargeback handling. Map your dispute‑resolution flows and SLAs.
• Implement a “unified entitlement service” that normalizes receipts from Apple, alternative payment providers, and alternative stores into a single customer record. This will save you months of reconciliation pain later.

Week 5–8: UX for warnings and trust

• Draft neutral, plain‑language purchase screens for external links. Assume Apple’s rules will require clear and objective messaging; avoid salesy phrasing that could be flagged as non‑neutral.
• Add pre‑purchase trust elements: payment badges (provider‑neutral), refund policy summaries, and clear customer‑support entry points.
• Build graceful fallback for web‑to‑app deep links. If a user hits your website link and bounces, give them an in‑app recovery path.

Week 6–9: Alternative marketplace evaluation

• Identify which alternative stores are credible for your audience and category. Validate submission APIs, review standards, malware scanning posture, and security disclosure programs.
• Ask how they surface ratings/reviews, offer editorial featuring, and run user support. Build a lightweight marketplace scorecard and pilot with one store before you scale.

Week 8–11: Compliance, reporting, and finance

• Engineer the reporting pipeline Apple will require for external transactions (expect server‑side reporting with receipt attestation and periodic reconciliation). Design it as a provider‑agnostic module.
• Update privacy notices and consent flows to reflect new payment channels. If you use ad attribution, revisit your ATT prompts and measurement strategy; our briefing on the policy headwinds in ATT Under Fire: What Mobile Teams Should Do Now covers practical mitigations.
• Coordinate finance cutover dates, update revenue recognition policies, and test end‑to‑end invoicing for Brazil.

Week 10–13: QA, fraud drills, and go‑live rehearsals

• Pen test your web checkout and in‑app link flows. Threat‑model link hijacking, overlay phishing, and payment form skimming.
• Run simulated refund/chargeback scenarios across channels.
• Stage rollout by segment or geography within Brazil to watch fraud and support volumes before a full release.

How the fees may hit your unit economics

Let’s walk through a simple example for a BRL 50 monthly subscription:

• App Store default: Assume 10% commission (post‑year‑one subscription rate) + optional 3–5% payment processing if you stick with Apple’s rails. Net take ≈ BRL 42.5–45 after taxes and PSP costs, depending on your specifics.
• External link flow: If actionable links trigger a ~15% fee, your net may be similar to, or slightly better/worse than, Apple’s native path once you account for PSP fees and potential conversion loss from a warning screen.
• Alternative store: Add the ~5% Core Technology Commission, then the store’s own commercial terms (varies). Your net improves only if that store’s audience converts better or your marketing economics make up the difference.

Two takeaways. First, channel‑specific pricing will be normal. Second, the “best” option isn’t universally cheaper—it’s a mix of fees, conversion, fraud, chargebacks, and support costs. Model it honestly with real‑world data, not hope.

Security and compliance: where the real risks live

Apple will display warnings for alternative flows, but the text must be neutral and not punitive. That swings the spotlight back to your own security design. The biggest risks we see:

• Link tampering: Attackers inject or intercept external purchase links. Mitigate with signed, single‑use tokens tied to device and session, short TTLs, and strict referer checks.
• Payment page phishing: Brand‑neutral designs can look generic; invest in recognizable but policy‑compliant trust signals and HSTS + certificate pinning where appropriate.
• Refund abuse and entitlement drift: Without ironclad receipt normalization, users can end up with overlapping, stale, or missing entitlements. Centralize entitlement state and run nightly reconciliation jobs.

Document your control set and keep it auditable. If you’re distributing on an alternative store, ask for their malware scanning pipeline, signature policy, and incident‑response commitments in writing.

Engineering notes: implementation gotchas you’ll want to avoid

• Deep link parity: If you link out from iOS to web, ensure one‑tap return into the exact post‑purchase state in the app. Nothing torpedoes trust like making users sign in again.
• Caching warnings: If iOS displays a system warning before external purchase, your UI should not pile on with a second modal. Respect the platform sequence.
• Receipt normalization: Represent all purchases—App Store, external PSP, alternative store—using a single canonical schema with fields for source, transaction ID, user, product, period, currency, taxes, and signature. Add a reconciler that flags mismatched states daily.
• A/B responsibly: If you test external links vs. native purchases, be sure your experiments don’t unintentionally steer users into non‑compliant flows.

Will alternative app stores actually matter in Brazil?

Short term, most mainstream developers will likely lead with hybrid: keep the App Store presence and test external links for specific offers. Alternative stores will be compelling for categories where audience clustering, editorial featuring, or pricing flexibility offsets the extra integration work. Keep your initial marketplace rollout small, measure conversion and support load, then decide to expand or not.

People also ask: Do I need a marketplace app of my own?

Only if you plan to aggregate multiple apps (yours or partners’) and can deliver real consumer value—curation, bundles, exclusive content, or community. A thin wrapper won’t cut it. If you go this route, you’ll need installation APIs, signed catalogs, update management, fraud monitoring, and a clear plan for harmful‑app takedowns.

People also ask: What about ATT, attribution, and ads?

ATT prompts still exist. External purchase links don’t change your need to respect user tracking choices. For performance teams, expect attribution to get messier with more off‑store web checkouts. Update your analytics contracts, move to server‑side conversion APIs where available, and invest in incrementality testing. If you need a quick refresher on privacy headwinds and practical workarounds, our field guide for mobile teams navigating ATT is a good starting point.

A lightweight framework to decide your Brazil strategy

Run this four‑question test with your leadership team. If you answer “yes” to at least three, launch external links or a marketplace pilot:

1) Will an extra 3–6 percentage points of margin meaningfully improve unit economics at your current ARPU and CAC?
2) Can you maintain a same‑or‑better checkout conversion with a neutral warning in the path?
3) Do you have the engineering bandwidth to implement entitlement normalization and reporting in the next eight weeks?
4) Is your fraud team prepared for new dispute paths and refund policies?

If you’re below that bar, stay App Store‑first for now, clean up your entitlement layer and analytics, and revisit in Q2 once Apple’s documentation stabilizes.

Execution checklist you can start today

• Draft channel‑specific T&Cs and privacy notices for Brazil.
• Choose and onboard a PSP with Brazil‑native fraud tools.
• Build your entitlement normalization service and reconciliation jobs.
• Prototype external purchase screens with neutral copy and strong trust cues.
• Map alternative store candidates and request technical docs.
• Implement external transaction reporting stubs (even before Apple’s final spec).
• Stand up dashboards that compare conversion, refund rate, chargeback rate, and LTV by channel.

Zooming out: why this isn’t just a Brazil story

Regulatory pressure tends to rhyme across regions. Europe’s DMA created technical precedents (alternative distribution UIs, external link entitlements, reporting APIs) that Apple then refined. Brazil’s move extends that pattern to a major non‑EU market. Even if you don’t operate in Brazil, building a channel‑agnostic entitlement and reporting layer now is a smart hedge for future policy shifts.

What to do next (developers and founders)

• Developers: Spike a proof‑of‑concept for external links with a real PSP sandbox this week. Wire the entitlement normalizer and a webhook to flip access instantly on payment success. Add automated tests for race conditions (payment success vs. app restore).
• Product leads: Choose two offers to A/B across native vs. external flows and define success thresholds (conversion delta, net margin, refund rate).
• Founders/CFOs: Refresh your Brazil P&L scenarios with three fee models and realistic conversion penalties. Green‑light or kill alternative store pilots based on expected net, not vanity reach.
• Security/Legal: Draft your warning/consent copy and threat‑model the external flow. Pre‑write your incident response steps for payment‑related phishing.

If you want experienced help scoping and shipping this change, our team has shipped cross‑channel monetization stacks and gnarly compliance integrations for years. See how we build and run mobile platforms on our client portfolio, explore our services, or just start a conversation via our contact form. We also publish hands‑on guidance in the Bybowu blog when policies like this flip the table—bookmark it and check back as Apple’s docs ship.

Final thought: optionality is the new default

Policy changes like this don’t force you to abandon the App Store—they force you to get smarter about optionality. Build an architecture that treats distribution and payments as configurable channels, not monolith choices. If you do, you’ll be ready for Brazil’s deadline and whatever comes next—without rewriting your app every time a regulator blinks.