Frame 1 of 8: As EU app distribution expands, who still sets the terms?
Apple expanded distribution routes while retaining authorization, technical checks and operating obligations.
The question
Apple EU app distribution and payment options, with platform dependencies and current dated terms · January and March 2024 announcements; public policies observed October 3, 2026. Apple expanded distribution routes while retaining authorization, technical checks and operating obligations.
Mechanism 1 · Additional routes were introduced in separate steps
Apple faced an institutional choice about how third-party app distribution would operate inside its device platform. The European Commission describes rights to alternative distribution under the DMA; Apple’s announcements and developer terms specify how it opened routes while retaining technical and contractual conditions. The operating conflict is between access outside the App Store and responsibility for installation, security, payments and support. This case follows those documented choices, not a developer adoption story. The policy comparison is dated October 3, 2026. Earlier announcements establish when additional routes were introduced; the current pages describe the later conditions observed on that date. A developer’s applicable agreement and eligibility require their own dated assessment. Apple’s January 2024 announcement addressed alternative marketplaces and payment choices. Its March 12, 2024 developer announcement separately introduced planned Web Distribution for authorized developers to distribute apps from their own websites. The latter should not be attributed to the January announcement. [Apple’s January announcement](https://www.apple.com/sg/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/), [March developer announcement](https://developer.apple.com/news/?id=8c1m8hqt). The European Commission’s current app-distribution explanation describes the DMA’s requirement to allow third-party stores and web distribution, alongside rules about steering and payment choice. That is the regulator’s explanation of the framework. It is distinct from Apple’s description of implementation and contract terms. [European Commission, app-distribution Q&A](https://digital-markets-act.ec.europa.eu/businesses-portal/app-distribution_en). These sources establish a real change to the available route structure. They do not show how many developers adopted each route or how customers responded. The existence of an option is evidence about choice, not a measured reduction in a participant’s dependence or cost.
Mechanism 1 · Additional routes were introduced in separate steps
Apple’s current support page says the previous EU addenda were superseded by unified terms as of October 1, 2026. It describes agreement to the updated program license as necessary to access the options and become subject to those terms. The page also lists a 5% Core Technology Commission for specified digital transactions connected to alternative distribution. That rate is not a universal commission on every kind of app revenue. [Apple Developer, business terms and transition](https://developer.apple.com/support/apps-in-the-eu/). For web distribution, Apple’s separate page describes authorization, notarization, a registered website domain, customer-support and reporting responsibilities. [Apple Developer, Web Distribution in the EU](https://developer.apple.com/support/web-distribution-eu/). The factual lesson is that a route has more than a headline commission. A developer must determine the actual eligible transaction and the applicable terms, then evaluate the work that moves with the route. A fee category should never be placed beside another category as if both necessarily apply to the same transaction.
Mechanism 2 · Apple opened routes while retaining authorization
Apple’s implementation separated the distribution route from the device platform. It announced alternative marketplaces first and Web Distribution separately, while the observed web requirements still specified authorization, notarization and a registered domain. Opening another route therefore changed who could distribute the app without removing Apple’s role in authorizing that route. That distinction is visible in the policy structure; the sources do not measure whether these controls are proportionate or effective. The web-distribution requirements also place customer-support and reporting responsibilities on the authorized developer. The institutional decision redistributes operating work as well as storefront access. A customer still needs installation, updates and a response to a problem. Which party handles that work matters even when the customer-facing app is unchanged. A permitted route is therefore an implementation with continuing obligations, not merely a permission to upload a file. The rival explanations concern the purpose and effect of the same controls. Apple’s security account treats continued checks as part of operating the platform; the Commission’s account emphasizes contestable access and choice. The documents establish that both institutions make those arguments. They do not establish that the checks caused low uptake, prevented a particular security loss or generated net savings. No uptake estimate is supplied.
Mechanism 2 · Apple opened routes while retaining authorization
Apple describes security requirements and platform value. The Commission describes rights intended to contest gatekeeper control. Neither description, alone, measures the safety or profitability of a developer’s route. The tension between those perspectives should be made visible rather than settled by adopting either institution’s narrative as an outcome study. The available policy options became more varied over time: alternative marketplaces and payment choices appeared in the January 2024 announcement, planned Web Distribution in March, and unified EU terms in the policy observed on October 3, 2026. Those are actual institutional changes. Treating them as a single timeless opening would hide how the operating conditions changed. The relevant comparison is the applicable route and agreement at the date of use, not an invented developer’s preference. The proper comparison needs actual data under the agreement and date relevant to the developer. Conversion loss, total fees and net savings remain unmeasured here. Eligibility must be assessed for the developer’s circumstances.
Mechanism 3 · Preserve the date of the decision
Announcement, effective date and the date of a developer’s agreement answer different questions. A route introduced in an earlier announcement can operate under later terms. A useful comparison records the conditions applicable to the actual decision rather than combining dates into an apparently stable offer. The case establishes a changed route structure and continuing authorization, security and commercial conditions. It leaves developer adoption, customer installation friction, security outcomes and total savings unresolved. For a platform operator, the decision it illuminates is which responsibilities must accompany third-party access and who can be held to them. For the regulator, it is whether the implementation delivers the required opportunity. Neither institution’s stated objective answers the outcome question by itself.
Optional application · unscored
Hypothetical: A subscription app considers linking EU users to a website to avoid one storefront payment flow.
Reveal: Map the route’s eligibility, user steps, conversion drop-off, payment costs, taxes, reporting, support, safety obligations, and all applicable commissions. Compare net contribution under the effective terms for the date in question.
Teaching assumption: Fictional subscription app; no numerical conversion loss, cost or saving is assumed.
Teaching assumption: Determine applicable terms from the actual agreement and date; no eligibility judgment is supplied.
The answer
Apple expanded distribution routes while retaining authorization, technical checks and operating obligations. Availability of another route does not identify developer adoption, net savings or a complete exit from the platform. The case is bounded to Apple EU app distribution and payment options, with platform dependencies and current dated terms during January and March 2024 announcements; public policies observed October 3, 2026.
What’s new; Alternative distribution; Business terms; Transition to unified EU terms
Observed current unified terms, agreement requirement and qualifying 5% CTC scope.
Mutable October 3 page cannot certify exact September 27 wording or an individual developer’s agreement.
Opening; Eligibility and requirements; Transition to unified EU terms
Authorized direct distribution, notarization, registered domain and ongoing responsibilities.
Requirements and implementation vary; no security-effect or uptake measure.
March 12, 2024; Distributing directly from your website
Separately announced planned web distribution.
An announcement, not proof of immediate implementation or adoption.
January 25, 2024; app distribution and payment-processing changes
Initial alternative marketplace and payment announcement.
Does not support attributing the later web-distribution announcement to January.
What are the DMA rules for Apple’s and Google’s respective app stores?
Regulator’s explanation of store, web-distribution, steering and payment obligations.
Framework and regulator perspective, not measured developer savings or a specific eligibility judgment.
Original illustrative scenes are not documentary evidence.