Apple had until 7 March 2024 to adopt the necessary measures to ensure that the terms and conditions it applies to app developers and app users within its mobile ecosystem comply with the app store-related provisions of the Digital Markets Act (“DMA”). These provisions essentially seek to stimulate competition in app distribution and content acquisition channels, as well as to introduce greater fairness in Apple’s terms and conditions to access the App Store.
Apple took everyone by surprise by announcing on 25 January 2024 how it intended to implement the app store-related provisions of the DMA in advance of the 7 March 2024 deadline. However, it became immediately clear to app developers that Apple’s implementation failed to comply with the DMA. This led Apple to make some limited changes to its terms in rapid succession to then bring more significant changes on 8 August 2024. The purpose of this blog post is to explain (in summary form, as many of these issues are complex and would deserve the sort of granular analysis that would not fit within a blog post) the reasons why Apple’s new terms still fail to comply with the DMA.
I should say at the outset that it is hard to understand Apple’s strategy when it comes to the DMA. Of course, Apple was probably shell shocked by the ineffectiveness of its lobbying against the DMA, which in its adopted version imposes a series of strict requirements that forces Apple to bring material changes to the way it runs the App Store and, more generally, its mobile ecosystem. From that point onwards, Apple seems to have decided to resist the implementation of the DMA as much as it could by using every possible trick. Apple and its advisors knew full well that the terms issued on 25 January 2024 did not comply with the DMA, and would thus likely trigger EC investigations, which is what happened (see below). Apple is now making these investigations difficult by modifying its terms on a regular basis, hence forcing the European Commission (“EC”) to investigate a moving target. Apple expects perhaps to wear out the EC (and app developers), which may finally accept terms that are short of full compliance with the DMA, but still “good enough” in that they represent progress. This would not be acceptable as the DMA is not a menu of options; it needs to be complied with in full.
Apple’s August 2024 terms still fail to comply with the DMA. As explained below, they represent minimal progress on all key issues. In some cases, they still violate the letter of some DMA provisions. In other instances, they make it very hard, and in some cases impossible for app developers and their users to take advantage of the benefits of the DMA through a combination of unattractive fees and friction, amounting to circumvention.
Let me now turn to the reasons why I consider that Apple’s most recent terms still fail to comply with the DMA.
Reason #1: Apple’s terms are often incomprehensible and therefore breach Article 8(1) of the DMA. The DMA aims to increase contestability and fairness in digital markets, by inter alia giving a number of rights to business users. Pursuant to Article 8(1) of the DMA: “The measures implemented by the gatekeeper to ensure compliance with those Articles shall be effective in achieving the objectives of this Regulation and of the relevant obligation.” In other words, the gatekeeper’s implementation measures must not frustrate the spirit of the DMA obligation concerned nor should they render it difficult for business users to exercise their rights under the DMA. Now, this is exactly what Apple is doing by issuing terms and technical documents that are extremely hard to understand for app developers.
Apple’s implementation (or lack of as we will see below) of Article 5(4) is a clear example. App developers who wish to take advantage of that provisions are facing two sets of terms whose exact scope are difficult to understand: (i) the “Alternative Terms Addendum for Apps in the EU” and (ii) the “StoreKit External Purchase Link Entitlement Addendum for EU Apps”.
- For an app developer to benefit from the Alternative Terms Addendum for Apps in the EU, they must be “established” in the European Union (EU) in accordance with Article 1(2) of Regulation (EU) 2022/1925 (see first paragraph of the Addendum).
- Pursuant to Section 2.1.A. of the StoreKit External Purchase Link Entitlement Addendum for EU Apps, an app developer is eligible to subscribe to its terms if the app is “distributed through the App Store on iOS, iPadOS, macOS, tvOS, visionOS, and/or watchOS in one or more storefronts available in any country or region located in the EU (“EU storefront”) of the App Store.”
The latter definition of eligible app developers is clearly broader than the former; contrary to the Alternative Terms Addendum for Apps in the EU, the StoreKit External Purchase Link Entitlement Addendum for EU Apps only requires that the app be made available in any country located in the EU (i.e., it does not require the app developer to be “established” in the EU). Why Apple applies such a distinction is unclear and nowhere explained. Moreover, this distinction will be lost to most app developers (who will not know the law of establishment in the EU, including the case law of the CJEU on this topic).
It is also unclear why, in determining which app developers may be eligible for the Alternative Terms Addendum for Apps in the EU, Apple refers to Article 1(2) of the DMA. This provision provides that the DMA applies to “core platform services provided or offered by gatekeepers to business users established in the Union or end users established or located in the Union, irrespective of the place of establishment or residence of the gatekeepers and irrespective of the law otherwise applicable to the provision of service.” (emphasis added). In other words, it is not clear why, in referring to Article 1(2), Apple restricts the applicability of the Alternative Terms Addendum for Apps in the EU to business users established in the EU (as Article 1(2) is broader), and why the distinction as to the scope of these two sets of terms is at all pertinent.
While these are the sort of questions that may fascinate EU lawyers, the vast majority of app developers will be left wondering which of these terms applies to them; an issue that matters since the fees that apply in each case are materially different. This one of many examples where Apple’s terms are so complex and obscure as to deprive app developers of their rights under the DMA.
[EU digital regulation experts will also recognize that Apple’s excessively complex and confusing terms might also breach the P2B Regulation, which establishes at Article 3(1) that providers of online intermediation services, including app stores, must ensure that their terms and conditions are drafted “in plain and intelligible language“. The rationale for that obligation is that business users, including app developers, must be in the position to determine the commercial conditions for the use of the app store concerned.]
Reason #2: Juxtaposition of existing and new terms. App developers can elect to stay under Apple’s existing (i.e., pre-DMA terms) or sign in to the new terms. It is hard to see how maintaining a set of terms (the “existing terms”) that is not compliant with the DMA complies with the DMA (especially if the new terms are not compliant either). Apple’s strategy seems designed to keep as many app developers under the existing terms because of the uncertainties created by some of the new terms and the unappealing aspects of others (e.g., as discussed below, the payment of the Core Technology Fee (“CTF”)). Thus, even app developers who would like to take advantage of the benefits of the DMA (and I know many) will be hesitant. There should only be one set of terms, which comply fully with the DMA.
Reason #3: Apple’s implementation of Article 5(4) in relation to steering is unclear and potentially non-compliant. Both the “Alternative Terms Addendum for Apps in the EU” and the the “StoreKit External Purchase Link Entitlement Addendum for EU Apps” define link out as “Link Out” or “Linking Out” as “communicating and promoting offers, in Your Application that is distributed through the App Store, to end users regarding digital goods or services that are available for purchase in a distribution channel of Your choice. The distribution channel can be a website, Alternative App Marketplace (EU), or another app, whether operated by You or someone else, and it can be accessed outside Your Application, or appear within Your Application as a web view.” Thus, it seems that these terms allow app developers to communicate and promote offers in their apps distributed through the App Store regarding other distribution channels without the need to use a link out (what I usually refer to as “pure steering”: e.g. a message in the app saying, for instance, go to www.widget.com to get 20% off) independently of the use of a “link out”.
What is confusing and potentially problematic, however, is that it remains open to question whether Apple intends to charge a fee when a user acquires digital content on the website of the developer either as a result of steering or because of an ad campaign. The answer should logically be no since there is no way to distinguish whether a user went to the website of a developer because they saw an ad in the subway or a message in the app. Now, the language contained in the two sets of terms issued by Apple is troubling on this point. Indeed, as per such terms, the initial acquisition fee and the store services fee are charged on transactions, which are the “sale of digital goods or services (including one-time purchases and autorenewing subscriptions) pursuant to Your Application’s use of Alternative Payment Processing or Linking Out under this Addendum” (emphasis added), and as seen above the definition of Linking Out includes pure steering.
Reason #4: Apple’s implementation of Article 5(4) in relation to link outs to purchase is non-compliant (and unclear). The “Alternative Terms Addendum for Apps in the EU” and the “StoreKit External Purchase Link Entitlement Addendum for EU Apps” seem to be diverging.
As to the terms contained in “Alternative Terms Addendum for Apps in the EU”, they require the payment of an (i) “acquisition fee” of 5% limited to a period of 12 months, but that is even if the transaction comes from the commercial efforts of the developer (as a result of which users look for their app in the App Store’s search engine by typing the name of the app, and are therefore brought to the App Store by the developer) or if the developer has bought search ads (in which case Apple has already been compensated for the acquisition); (ii) “store services fees” of 10% which apply for up to 24 months from the first install (but the services in question comes as a “bundle”, developers cannot pick and choose what they need); and (iii) the CTF, which is problematic for developers with a freemium model (and seem in addition to cover the same services as the store services fee).
As to the terms contained in the “StoreKit External Purchase Link Entitlement Addendum for EU Apps”, they require the payment of an (i) “acquisition fee” of 5% limited to a period of 12 months, but that is even if the transaction comes from the commercial efforts of the developer (as a result of which, once again, users look for their app in the App Store’s search engine and are therefore brought to the App Store by the developer) or if the developer has bought search ads (in which case Apple has already been compensated for the acquisition); (ii) “store services fees” of 20% (instead of 10%) which apply for up to 24 months from the first install (but, once again, the services in question comes as a “bundle”, developers cannot pick and choose what they need). By contrast, the CTF does not apply to app developers who elect to use this set of terms.
In my opinion, both sets of terms are problematic as they are truly discouraging developers to use link outs. They are also in tension with the “free of charge” reference in Article 5(4) as nothing is free in these terms. Moreover, they also leave app developers wondering why the fees in each case differ, and what is best for them (considering for instance that the impact of the CTF — which is based on the number of installs — may be hard to predict). Once again, there should be once set of terms that should comply with the DMA.
Reason #5: Apple makes the use of alternative payment service providers (PSPs) very unattractive in breach of Article 5(7). That is the case because (i) if an app developer wants to use an alternative PSP, it has to pay the 17/10% + the CTF (i.e., the same financial conditions as those applying if they used Apple’s own in-app payment solution, “IAP”, except the 3% payment processing fee), hence they have no financial incentive to use an alternative PSP; (ii) the process is subject to considerable friction because, here again, the app developer needs to show a disclosure sheet including language such as “[T]his app doesn’t support the App Store’s private and secure payment system”), which suggests that the alternative payment systems that will be used by the app developers may not be private and secure. This requirement is entirely unnecessary considering that app developers that do not sell digital content (e.g., Uber or Amazon) can use the PSP of their choice without showing such disclosure sheets. Moreover, Apple requires app developers to rely on PSPs that meet all necessary requirements, once again showing that this disclosure sheet is entirely futile; and (iii) app developers who decide to use an alternative PSP cannot use an IAP alongside (hence, depriving consumers of choice) and likely affecting user conversion. In these conditions, it would be very surprising that app developers decide to use alternative PSPs.
Reason #6: Apple makes alternative marketplaces unlikely to succeed in breach of Article 6(4). That is because: (i) Apple continues to impose onerous requirements on both app developers and app users, thereby creating friction. It is hard to see why these requirements are “duly justified” as per Article 6(4); (ii) developers of alternative marketplaces are subject to a €0.5 CTF from the first install (hence creating a potentially large liability for such developers before they even have material revenues, while app developers using alternative marketplaces will need to pay a €0.5 CTF after 1 million installs, which means that large app developers that are distributed freely on the App Store (Facebook, Uber, etc.) will not join alternative marketplaces; hence impeding their ability to gain scale. While some alternative marketplaces focusing on particular app genres may be able to succeed (though only time will tell), generalist app stores will fail.
Reason #7: Apple makes direct distribution challenging in breach of Article 6(4). Some of the requirements imposed on app developers who want to make their apps available for direct downloading are problematic: (i) it is not clear why direct downloading is only permitted from the app developer’s website and not, for instance, from a web app store as is the case in the PC space (web app stores may be an efficient means for app developers to distribute their apps and for users to find the apps that may cater to their needs.); (ii) in order for an app developer to be allowed to make its apps available for direct downloading, it has to be “a member in good standing of the Apple Developer Program for two (2) continuous years or more, and have an Application that had more than one (1) million First Annual Installs on iOS and/or iPadOS in the EU in the prior calendar year.” There is no justification for such onerous requirements, which will strictly limit the number of apps that may be eligible for direct downloading; and (iii) for the same reasons as those mentioned in the context of alternative marketplaces, the payment of the CTF to Apple is problematic.
Reason #8: Some of the terms and conditions imposed by Apple to app developers are not compatible with Article 6(7) of the DMA as (i) the €0,5 CTF per install that Apple imposes on alternative marketplace developers to effectively “interoperate” with Apple’s iOS software is incompatible with the “free of charge” requirement contained in Article 6(7). Contrary to the free of charge requirement contained in Article 6(7), the CTF imposes on marketplace providers competing with the App Store a large financial liability, which will in most instances amount to a constructive refusal to provide interoperability; and (ii) Apple’s onerous requirements imposed on developers seeking to introduce competition in app distribution and payment solutions introduces friction at the expense of “effective interoperability” in breach of Article 6(7).
Reason #9: Apple’s App Store terms are not FRAND. Although a lot could be written on this topic, I will focus on a couple of reasons why Apple’s terms breach the FRAND requirement contained in Article 6(12).
First, Apple’s terms and conditions are not “fair and reasonable” considering that they entirely discount the massive value brought by app developers to the App Store, as recognized by the EC in Apple App Store (Music Streaming) decision, see §651. Indeed, but for the presence of app developers in the App Store, Apple would not be able to sell its iPhone or tablets as users buy these devices to use a wide range of attractive apps. The only reason why Apple is able to charge hefty fees results from the “imbalance in bargaining power” (as referred to in Recital 62 of the DMA) resulting from Apple holding monopoly power in app distribution. In a scenario where app stores were able to fairly compete for app developers within Apple’s ecosystem, fees would inevitably decrease and even tend to zero (which explains why Apple is making the development of alternative marketplaces and distribution through direct downloading extremely difficult through a combination of fees and friction). Note that Apple already charges developer fees ($99 a year), and generates billions in revenue through search ads on the App Store (where developers compete with each for placement). Even with lower fees, the App Store would remain a largely profitable operation.
Second, Apple maintains a system whereby apps using the same app store services are subject to radically different terms and conditions (hence breaching the “ND” part of FRAND). The 17/10% commissions and the CTF only apply to apps selling digital goods and services (defined at Apple’s discretion), whereas all other apps are not subject to a commission. Since Apple no longer imposes app developers to use its in-app payment solution (which comes at an extra costs of 3%), both apps selling digital goods and services and apps not selling these goods and services are using the exact same app store services, and should therefore be subject to the same commissions (or lack of). Apple has never been able to provide an objective justification for this difference in treatment.
It is submitted that the EC should enforce Article 6(12) requirement by mandating Apple to ensure that the terms to access its App Store are FRAND. First, while competition in app distribution and between channels to acquire digital content may bring Apple in line with the FRAND requirement, it will take months or more likely years before this competition takes hold, leaving in the meantime app developers selling digital content subject to un-FRAND terms. Second, contrary to what is sometimes alleged, this does not require the EC to become a price regulator. It is for Apple to show that its terms are FRAND, not for the EC to determine what FRAND terms are. In any event, even if one may disagree over what “fair and reasonable” mean, Apple lack of compliance with the ND part of FRAND is manifest.
Reason #10: Besides breaching several specific provisions of the DMA, Apple’s terms also breach Article 13 as they amount to circumvention. That is the case because even when Apple’s terms seem to superficially comply with the DMA, they fail to effectively do so through a combination of unnecessary fees and friction that make it unappealing for developers to exercise their rights under these provisions.
The above is of course a summary of the reasons why Apple’s August 2024 terms are still in breach of the DMA. In fact, little progress has been made by Apple since the 7 March 2024 deadline. Unsurprisingly, this has triggered the EC to open two investigations, the first one on Apple’s lack of implementation of Article 5(4) and the second on Apple’s new business terms (although that investigation focused on Apple’s prior terms, not those issued in August 2024). In the first investigation, Apple already sent its preliminary findings on 24 June 2024. Needless to say, that Apple’s August 2024 terms will not help them with the pending EC investigations as they are still far off the mark.
While Apple’s strategy is hard to read, it has clearly tarnished the company’s reputation vis-à-vis the EC. In the end, the most likely plan is for Apple to reach a deal with the EC on the eve of the end of its 12-month investigation so as to escape an infringement decision and a fine. In my view, the EC should not accept any commitments that are short of full compliance with the DMA. If that is not possible, it should hit Apple with a big stick, so to maintain its credibility as the DMA enforcer. In the end, Apple needs to comply with EU law.
Disclosure: I advise a number of app developers on DMA matters. The views contained in this post are mine only.
