On this page · 12 sections
- What actually changed on iOS, and when
- The four money paths, priced
- The iOS engineering work, concretely
- Reporting, invoicing and the audit clause
- Alternative marketplaces: what you are actually signing up for
- The child-safety rules that will break your paywall
- Android: the 30 September registration cutoff
- What to do in the next six weeks
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. Two unrelated regulatory changes now land on the same Brazilian release train. Apple's settlement with CADE, Brazil's competition regulator, took effect with iOS 26.5 on 18 June 2026: App Store commission in Brazil is now 21% for most digital goods sales or 10% for Small Business Program members and for auto-renewable subscriptions after their first year, plus a separate 5% Apple payment processing fee when you use Apple In-App Purchase. Apps distributed outside the App Store pay a 5% Core Technology Commission instead. Every Apple Developer Program member had to accept the revised licence agreement by 6 July 2026. Separately, Google requires apps to be registered by a verified developer from 30 September 2026 before they can be installed on certified Android devices in Brazil, Indonesia, Singapore and Thailand, across seven stores including Google Play, Samsung Galaxy Store and Xiaomi GetApps. Brazil generated $1.7 billion in app revenue in 2024 across roughly 9.6 billion downloads, on a base of more than 150 million smartphone users, so this is not a market most product teams can quietly skip.
The two changes pull in opposite directions. Apple's opens distribution; Google's closes it. If you ship to Brazil on both platforms, you have one team absorbing new commercial optionality on iOS and another racing a hard installation cutoff on Android, in the same eight-week window.
What actually changed on iOS, and when
Apple announced the changes on 18 June 2026 and shipped the developer-facing capabilities with iOS 26.5 the same day. The settlement with the Conselho Administrativo de Defesa Econômica gives developers three things they did not have on the Brazil storefront before:
- Distribution of notarized iOS apps through alternative app marketplaces.
- The right to operate an alternative app marketplace, subject to Apple authorization and ongoing requirements.
- Alternative payment processing inside App Store apps, and out-of-app offers that send a user to a web browser to complete a purchase.
None of this is automatic. The entitlement profile Apple issues for alternative payments is scoped to a single ISO 3166-1 alpha-2 country code, br, and only works on iPhone running iOS 26.5 or later on the Brazil storefront. An app that ships the same binary worldwide has to gate the whole flow at runtime.
Apple's own framing of the trade-off is blunt. Its 18 June 2026 newsroom post says Notarization "is less comprehensive than the App Review process that applies to all apps on the App Store", and sets out the security and privacy exposure the new options create. That matters commercially: if you route payments away from Apple, Apple will not issue refunds, and purchase history, Family Sharing and Report a Problem will not reflect those transactions.
The four money paths, priced
There are now four distinct ways to take money from a Brazilian iOS user, and they have different rates, different engineering costs and different support obligations. The rates below are Apple's published Brazil business terms as of August 2026.
| Path | What Apple charges | What you take on |
|---|---|---|
| App Store with Apple In-App Purchase | 21% commission (10% for Small Business Program, Mini Apps, Video and News Partner Program members, and for auto-renewable subscriptions after year one) plus a 5% payment processing fee | Nothing new. No code changes required |
| App Store with an alternative payment processor in-app | 21% commission (10% for the same programs and post-year-one subscriptions); no Apple payment processing fee | Entitlement, StoreKit External Purchase APIs, disclosure sheet, PSP contract, tax collection, refunds, monthly reporting |
| App Store with an out-of-app offer linking to your website | 15% store services commission, or 10% for program members and post-year-one subscriptions, on sales within 7 days of the link tap | Entitlement, actionable-link handling, disclosure sheet, web checkout, attribution within the 7-day window, monthly reporting |
| Alternative app marketplace | 5% Core Technology Commission on paid apps and digital goods | Notarization, marketplace token integration, App Store Connect API work, loss of Apple In-App Purchase, your own update pipeline |
Two details in that table cost teams real money if they are missed. First, the store services commission only applies to sales made within seven days of the link tap, which means your web checkout needs attribution good enough to defend that boundary in an audit. Second, the alternative marketplace path removes Apple In-App Purchase entirely from that build. You do not get a hybrid: an app distributed through a marketplace cannot fall back to StoreKit purchases.
A worked example on R$100 of digital goods
Applying Apple's published Brazil rates to a round R$100 purchase, before any taxes, and before the cost of whichever payment processor you contract:
| Path | Apple's cut on R$100 | Left before PSP and tax |
|---|---|---|
| Apple In-App Purchase, standard rate | R$26.00 (21% + 5%) | R$74.00 |
| Apple In-App Purchase, Small Business Program | R$15.00 (10% + 5%) | R$85.00 |
| Alternative in-app processor, standard rate | R$21.00 | R$79.00 |
| Out-of-app offer, standard rate | R$15.00 | R$85.00 |
| Alternative app marketplace | R$5.00 | R$95.00 |
The spread between the cheapest and the most expensive path is 21 percentage points. That looks decisive until you price the other side. A Brazilian payment service provider that meets Apple's stated bar (Level 1 Payment Card Industry compliance for card data, plus a customer service process covering disputed transactions, subscription management and refunds) is not free, and neither is the chargeback exposure you inherit. Apple also requires that you present Apple In-App Purchase at least as prominently as any alternative on every screen where you merchandise a digital good, so the cheaper path does not get a cheaper conversion funnel.
The real cost is usually the back office, not the checkout.
The iOS engineering work, concretely
If you decide to offer alternative payments on the Brazil storefront, the implementation is well specified and narrow. It is also easy to get subtly wrong.
Start with the entitlement. In Certificates, Identifiers and Profiles, enable the StoreKit External Purchases or Offers Entitlement on your App ID, then declare it in your entitlements property list:
<key>com.apple.developer.storekit.custom-purchase-link.allowed-regions</key>
<array>
<string>br</string>
</array>
Xcode will notice that the entitlements file and the cached provisioning profile no longer match on the next build or distribution request, and will pull a fresh profile. Teams running unattended CI signing should expect that first build to fail until the new profile is fetched.
The runtime sequence has two mandatory checks, both before you show anything to the user:
import StoreKit
func canOfferExternalPurchase() async -> Bool {
// Must be checked before showing the disclosure sheet
guard await ExternalPurchaseCustomLink.isEligible else { return false }
// Must be checked before every purchase or payment-entry flow
guard AppStore.canMakePayments else { return false }
return true
}
ExternalPurchaseCustomLink.isEligible tells you whether external purchase is available at all for this user and storefront. AppStore.canMakePayments tells you whether this user is permitted to make payments, which is how the parental-controls requirement is enforced today. Apple's guidance is explicit that the eligibility check comes before the disclosure sheet, not after.
The disclosure sheet itself is a modal you build in iOS 26.5, using Apple-supplied design specifications and downloadable resources, telling the user they will be transacting with the developer and not Apple. Apple has said a system-provided disclosure sheet backed by a new StoreKit API arrives in a later iOS release, and that users who dismissed a developer-built sheet with "Show this next time" turned off will see the system sheet once more after you migrate. Build the sheet behind a feature flag. You will be replacing it.
Two design constraints that break existing paywalls:
- Apple In-App Purchase must appear on every screen where you merchandise a digital good and offer a payment option, at least as prominently as the alternative. Prominence is judged on layout, language, font, colour and size together.
- Apple In-App Purchase buttons must use Apple-provided artwork on a black or white background. Custom colours are not allowed, and custom button designs are only permitted when Apple In-App Purchase is the sole option.
Your App Store product page also may not mention purchasing on your website or through alternative processing. The messaging has to live entirely inside the app.
Reporting, invoicing and the audit clause
This is the part that turns a payments experiment into a finance project. For any App Store transaction in Brazil that does not use Apple In-App Purchase, you must:
- Track every alternative payment transaction and report it to Apple using the External Purchase Server API.
- Send that report monthly, within 15 days of the end of each calendar month.
- Collect and remit any applicable taxes yourself for sales processed by an alternative provider.
- Pay Apple's invoice within 30 days of receiving it. Apple aggregates transactions and calculates commission by the 15th of the following month.
Apple retains audit rights under the Developer Program License Agreement to check the accuracy of those records. The stated consequences of underpaying are not gentle: offset against proceeds owed to you in other markets, removal of the app from the App Store, or removal from the Apple Developer Program.
If you distribute through an alternative marketplace, the reporting duty splits. The developer reports transactions of digital goods inside their own app and from link-outs; the marketplace operator reports its own sales, paid downloads of apps on the marketplace, paid downloads of the marketplace app itself, and subscriptions for its catalogue.
Any team that has already shipped external purchase links under the EU rules will recognise the shape of this. The Brazil entitlement is a separate one, scoped to br, and the rates are different, so an EU implementation is a starting point rather than a drop-in.
Alternative marketplaces: what you are actually signing up for
An alternative app marketplace, in Apple's definition, is an app whose primary purpose is discovery and distribution of notarized iOS apps. Operating one requires authorization from Apple against specific criteria and ongoing requirements.
Distributing through one is lighter but still a distinct release pipeline. In App Store Connect and the App Store Connect API you register the marketplace, supply your Developer ID, add the marketplace token the marketplace gives you, mark which of your apps are eligible for alternative distribution, and notify the marketplace when an update is available. That last step is the one that surprises release engineers: on the App Store, Apple pushes updates. Here, you tell the marketplace, and the marketplace tells the user.
Notarization applies to every iOS app regardless of channel. It is a baseline review combining automated checks and human review, covering accuracy of developer and cost representation, functionality and crash-freedom, safety, security and privacy. Apple encrypts and signs apps intended for alternative distribution, runs integrity checks at install time, and can revoke installations and block launches if it later determines an app is unsafe.
Read that as an operational risk, not a formality. A build that ships only through a marketplace has a review path, a signing path and a revocation path you do not control and cannot appeal through the usual App Review channel.
| Dimension | App Store | Alternative app marketplace |
|---|---|---|
| Review | Full App Review, including Notarization plus content and commerce policy enforcement | Notarization only: accuracy, functionality, safety, security, privacy |
| Apple commerce | Apple In-App Purchase available | Not available |
| Apple's cut on digital goods | 21% or 10%, plus 5% if using Apple In-App Purchase | 5% Core Technology Commission |
| Update delivery | Apple distributes updates | You notify the marketplace, which distributes |
| Reporting duty | Only for non-Apple In-App Purchase transactions | Developer and marketplace operator both report |
| Age ratings | Required | Required |
The child-safety rules that will break your paywall
If you offer alternative payment options in Brazil, Apple imposes rules that cut across the standard subscription funnel.
Apps in the Kids category must put a parental gate in front of any in-app purchase flow that uses an alternative payment processor, and cannot offer an out-of-app website purchase at all.
Every other app must support parental purchasing controls and require parental consent when offering alternative payment options. For users under 18, an in-app alternative purchase flow is allowed only behind a parental gate, and an out-of-app offer linking to a website is not allowed at all.
There is no dedicated API for this yet. Apple's stated guidance is to use AppStore.canMakePayments at runtime to determine whether a person can authorize payments, and says new APIs to better support these requirements will arrive in a future software update. In practice that means an age-conditional paywall today and a rework when the API lands.
Teams already working through App Store age rating and social media declarations will find the same question repeating: what does the app actually know about the user's age, and how defensible is that signal? The Brazil payment rules make that question a revenue question rather than a compliance one.
Android: the 30 September registration cutoff
Google's change is simpler to describe and harder to negotiate. From 30 September 2026, apps must be registered by a verified developer to be installed and updated on certified Android devices in Brazil, Indonesia, Singapore and Thailand.
The initial phase covers seven stores: Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Palm Store from Transsion, vivo V-Appstore and Xiaomi GetApps. Google has said the protections expand globally for all apps on certified Android devices in 2027.
Matthew Forsythe, Director Product Management, Android App Safety at Google, wrote in the 18 June 2026 announcement: "This rollout is an industry-wide effort to create a safer ecosystem."
The numbers say most teams are already fine. Google states that over 99% of apps on Play have been registered automatically. The exposure sits in the remainder: apps under old or dormant developer accounts, white-label builds under a client's account, internal-tools APKs distributed outside Play, and anything published by an agency that has since been offboarded.
| Date | What happens | What to do now |
|---|---|---|
| June 2026 | A new system service rolls out to most Android devices, used later to verify developer registration | Nothing; note it in device-compatibility testing |
| July 2026 | Android Developer ID Status API launches globally; early access for the Android Developer Console API and limited distribution accounts | Request early access if you register apps in bulk |
| August 2026 | Limited distribution accounts and the Android Developer Console API launch globally; advanced sideload flow for unverified developers ships | Wire the status API into CI to detect unregistered package names |
| 30 September 2026 | Registration required for the seven participating stores in Brazil, Indonesia, Singapore and Thailand | Every package name you ship to those markets must be registered |
| 2027 | Requirement expands globally to all apps on certified Android devices | Treat registration as a standing release-checklist item |
Two escape hatches survive the cutoff, and neither is a distribution strategy: unregistered apps can still be installed with Android Debug Bridge, and through the advanced flow Google shipped in August 2026 for power users, which adds security checkpoints to that install path.
The automation matters here. The Android Developer ID Status API lets you check whether a package name is already registered, and the Android Developer Console API lets you register and manage package names from your own environment. Both support OAuth delegation, so a third-party platform or store can perform those operations on your behalf. If you manage more than a handful of package names, put the status check in the same pipeline stage that already runs your Android target API level migration checks.
Limited distribution accounts are worth knowing about even if you are an enterprise. They let students, hobbyists and learners share apps to up to 20 devices without a government-issued ID or a fee, which is a reasonable answer for internal demo builds that do not justify a full account.
What to do in the next six weeks
A practical sequence for a team that ships to Brazil on both platforms:
- Confirm the licence agreement was accepted. The 6 July 2026 deadline for the updated Apple Developer Program License Agreement has passed. Only the Account Holder can accept it. If it was missed, alternative distribution tools and the Brazil entitlement are not available to your account.
- Enumerate every Android package name you ship into Brazil, including builds distributed outside Play, and check each against the Android Developer ID Status API. Register anything unregistered well before 30 September 2026.
- Decide whether alternative payments are worth it for your actual mix. If most of your Brazil revenue is auto-renewable subscriptions past their first year, you are already at 10% plus 5% processing, and the alternative path saves five points before PSP costs. The engineering and finance overhead rarely pays for itself at that spread.
- If you proceed, scope the finance work first. Monthly reporting within 15 days, invoice payment within 30 days, tax collection and remittance, and an audit-defensible transaction record. This is a bigger change than the StoreKit work.
- Model the marketplace path only if you have distribution. A 5% Core Technology Commission is attractive on paper and worthless without a marketplace that reaches your users. Losing Apple In-App Purchase in that build is not reversible per-user.
- Re-test your paywall for under-18 users. Parental gates,
AppStore.canMakePayments, and the ban on out-of-app offers for minors change the funnel, not just a screen.
Teams building this into a wider release process usually fold it into their enterprise mobile app development governance rather than treating it as a one-off market launch, because the same pattern (a regional entitlement, a regional fee schedule and a regional compliance gate) is now recurring across the EU, Brazil and Southeast Asia.
India-specific considerations
For Indian product companies and services firms, Brazil is mostly an export-market question, and it lands on the same teams already handling Indian compliance work.
Three points are worth separating out. First, an Indian company distributing on the Brazil storefront with alternative payments becomes a merchant of record for those transactions and takes on Brazilian tax collection and remittance, which is a finance and legal decision before it is an engineering one. Second, the personal data flowing through an alternative checkout is still covered by India's Digital Personal Data Protection Act 2023 when the processing happens in India, so the payment-data path needs the same treatment as any other cross-border flow in your consent and retention design. Third, Indian services firms building for overseas clients frequently hold the Play Console or Apple Developer account on the client's behalf; those are exactly the accounts most at risk of an unregistered package name on 30 September 2026.
Indian teams pricing this work should also note that the Android side is largely a process change and the iOS side is a product change. The cost comparison in our analysis of India versus US app development cost holds here: the expensive part is the recurring monthly reporting obligation, not the initial build.
Firms that already run Android developer verification remediation for Southeast Asia can reuse that inventory directly. Brazil is in the same enforcement wave, with the same date and the same seven stores.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based product engineering organisation with senior-led iOS, Android and release-engineering teams that ship into multiple app store jurisdictions. We can inventory every package name and bundle identifier you distribute into Brazil, wire the Android Developer ID Status API into your existing pipeline before the 30 September 2026 cutoff, and model whether alternative payments on the Brazil storefront actually clear the finance overhead for your revenue mix. Where the answer is yes, we build the entitlement, StoreKit External Purchase integration, disclosure sheet and monthly reporting path end to end. Talk to us at /contact-us/.
References
- Apple announces changes to iOS in Brazil — Apple Newsroom, 18 June 2026.
- Changes to iOS in Brazil — Apple Developer Support.
- Payment options on the App Store in Brazil — Apple Developer Support.
- Operating an alternative app marketplace in Brazil — Apple Developer Support.
- Manage distribution on an alternative app marketplace — App Store Connect Help.
- ExternalPurchaseCustomLink.isEligible — StoreKit documentation.
- AppStore.canMakePayments — StoreKit documentation.
- External Purchase Server API — Apple Developer documentation.
- Android developer verification: building a safer ecosystem together — Android Developers Blog, 18 June 2026.
- Understanding Android developer verification — Android Developer Console Help.
- Register your apps in Play Console — Play Console Help.
- Android developer verification — Android Developers.
- Brazil app market statistics — Business of Apps, updated 7 January 2026.
Last updated: 7 August 2026.
