Federal Court of Australia

Epic Games, Inc v Apple Inc [2025] FCA 900

ORDERS

THE COURT ORDERS THAT:

1.    The further hearing of the proceeding be stood over to a date to be fixed.

2.    Save for the oral summary of these reasons given by Beach J at the time of delivery of this judgment and any republication in any form of that summary, pursuant to s 37AF(1) of the Federal Court of Australia Act 1976 (Cth) and on the ground set out in s 37AG(1)(a), subject to further order, disclosure and publication of these written reasons and the content thereof shall only be made to the parties’ external legal advisors in this proceeding and in proceedings NSD 190 of 2021, VID 341 of 2022 and VID 342 of 2022, and to no other person.

3.    Liberty to apply.

4.    Costs reserved.

Note:    Entry of orders is dealt with in Rule 39.32 of the Federal Court Rules 2011.

REASONS FOR JUDGMENT

BEACH J:

1    There are four proceedings before me, the joint trial of which took place over a period of four months on questions of liability.

2    In the first proceeding, which these present reasons deal with, the Epic parties have made claims against the Apple parties principally concerning alleged contraventions of s 46 and other provisions of the Competition and Consumer Act 2010 (Cth) (CCA). The relief that they seek is directed at breaching Apple’s walled garden that protects its digital ecosystem.

3    The Epic parties are involved in developing entertainment software for personal computers, smart mobile devices and gaming consoles, with their most popular game being Fortnite. They allege that the Apple parties’ contravening conduct has forced app developers including Epic to only use Apple’s App Store to distribute their software applications (apps) to the broad base of iOS device users, and to only use Apple’s payment system for processing the purchases of their in-app digital content by iOS device users. I will explain the detail of this in a moment. Apple removed Fortnite from the App Store on 13 August 2020. That step has provoked the present litigation against the Apple parties.

4    In the second proceeding, the Epic parties have made claims against the Google parties principally also concerning analogous alleged contraventions of s 46 and other provisions of the CCA. They allege that the Google parties’ contravening conduct has hindered the ability of app developers including Epic to distribute apps to Android devices in a realistic and practical way other than through Google’s Play Store. It is said that Google has achieved this by imposing various contractual and technical restrictions, which stifle or block Android device users’ ability to download app stores and apps directly from developers’ websites and prevent or hinder competition in the distribution of apps to Android devices. It is also said that Google has inappropriately imposed on app developers Google’s payment system for processing the purchases of in-app digital content by Android device users. Google removed Fortnite from the Play Store on 13 August 2020. That step has also provoked the present litigation against the Google parties.

5    I have delivered a separate set of reasons dealing with the second proceeding (Epic Games, Inc v Google LLC [2025] FCA 901).

6    The third and fourth proceedings are representative proceedings commenced by the representative applicants under Part IVA of the Federal Court of Australia Act 1976 (Cth) where similar allegations have been made by them on behalf of group members against the Apple parties and the Google parties concerning the same contraventions of s 46 of the CCA as alleged in the first proceeding and the second proceeding. One of the class actions is against the Apple parties concerning the overcharging of commissions on the App Store. The other class action is against the Google parties concerning the overcharging of commissions on the Play Store. In each case it is said that the contraventions caused app developers to pay materially higher commissions on paid app downloads and in-app purchases of digital content than they would otherwise have had to pay had the contravening conduct not occurred.

7    I have delivered a separate set of reasons dealing with both the third and fourth proceedings (Anthony v Apple Inc; McDonald v Google LLC ([2025] FCA 902).

8    I will say something more about the joint trial and how these reasons should be read a little later. But for the moment let me introduce the case against the Apple parties in some more detail.

9    Apple Inc designs, manufactures and sells smartphones, tablets and personal computers, which are known as iPhones, iPads and Macs respectively, along with various other devices and accessories. Let me say something more about devices before proceeding further.

10    Internet-connected computing devices include smartphones, tablets, PCs such as Windows and macOS, and gaming consoles such as the Microsoft Xbox, Nintendo Switch and Sony PlayStation. Types of computing devices differ in various physical and functional respects depending on their particular use cases and the consumer needs that they are designed to meet. Conveniently one can identify five general characteristics of relevance to the present case.

11    First, one has size and portability. Smartphones are smaller and more portable than consoles. Second, one has methods of power connection. Desktop PCs for example require fixed power connections. Third, one has performance and memory capacity. Smartphones have typically been less powerful than PCs. Fourth, one has input methods. Typically, smartphones have touch screens, consoles require controllers and desktop PCs and some laptops require keyboards and mice or trackpads. And fifth, one has the range of apps that they support. Let me say something by way of introduction about operating systems and apps at this point.

12    For a smartphone, tablet or personal computer to operate, it requires an operating system. Now an operating system, which I have simply referred to as an OS, is a form of software that provides the basic functionality for a device. It facilitates the operation of the device’s hardware and software, manages how apps will run on the device, and manages access to and use of its resources. Both smartphones and tablets as well as PCs require an OS to operate.

13    The two largest operating systems for mobile devices are Apple’s iOS on which iPhones run and with a similar operating system for iPads, and Google’s Android OS on which Android devices run.

14    On each of these devices, users can use applications known as apps for any number of purposes, including news, travel bookings, maps, entertainment and games. Apps developed for a particular OS are referred to as native apps. Apps may also be developed to run through a web browser on any device irrespective of the OS. These are referred to as web apps and can be accessed by users via a web browser.

15    Now apps enhance and optimise the functionality of a device. Generally speaking, three kinds of apps can be run on a modern device being native apps, web apps and streaming apps.

16    As I have indicated, a native app is an OS-specific app that is programmed to run on a particular OS and cannot run on a different OS. To create a native app, a developer will use software development tools that are created for the particular characteristics of an OS. Consequently, it is difficult to port apps between different operating systems.

17    There are now more than 1.8 million native apps available on the App Store for download to iOS devices. Only a small number of these were developed by Apple. The vast majority of iOS apps available in Australia are developed by third-party developers.

18    In contrast to a native app, a web app is designed to run inside a webpage accessed through a web browser and is platform agnostic. Web apps use web technologies rather than platform specific software and suffer limitations in functionality compared with native apps. These differences are the result of inherent technical limitations that web apps face, as well as browser and operating system level policy decisions made by platforms to extend less functionality to web apps.

19    Any web app can be accessed on an iOS device through a web browser and are not subject to the same guidelines or restrictions that Apple imposes on native apps available through the App Store.

20    A streaming app is run on a remote server but can be viewed and controlled on a user’s device via an associated portal app being either a web app or a native app. Streaming apps respond to user inputs relayed by the portal app and transmit back to the user’s device a live audio-visual feed of the remote streaming app’s output. Generally speaking, for this all to work well, streaming apps require high bandwidth, low latency and reliable network connections which are not always available to mobile users.

21    Now native apps are typically distributed for installation on a device in one of three ways. First, through an app store. Second, by directly downloading the app from a website. Third, by pre-installation on the device.

22    Software developers develop apps and make them available to consumers for use on their devices. Apps are most commonly downloaded onto mobile devices via an app store, itself a type of app that allows users to browse or search a catalogue of apps.

23    Now developers can monetise apps developed for smart mobile devices in three principal ways. First, they can monetise their apps by providing users with the app for free, and monetising the app through other means such as advertisements shown in the app. Second, they can monetise their apps by charging users a fee to download the app. Third, they can monetise their apps by supplying users with apps in which the user can make “in-app” purchases for which the developers can charge.

24    Now in-app purchases are, as the name suggests, purchases that occur within an app, such as purchases of digital content such as subscriptions or in-app currency, and of physical goods and services supplied outside the app such as food deliveries or transportation. Contrastingly, out-of-app purchases require the customer to leave the app and undertake the purchase elsewhere, such as on a website or another device.

25    Now to offer in-app purchases, app developers require in-app payment solutions. In-app payment solutions are systems by which funds are transferred between a buyer and seller without the user leaving the app.

26    App developers can develop their own in-app payment solution or obtain an in-app payment solution from a third-party. Various third-parties supply in-app payment solutions, including Stripe, Square, PayPal and Adyen.

27    Now Apple’s App Store is the exclusive platform by which iOS native apps are distributed. By reason of Apple’s policies and contractual restrictions, as well as technical restrictions encoded in iOS, only native apps from the App Store may be installed on an iOS device apart from certain trivial exceptions.

28    Further, under the terms and conditions of the developer program licence agreement (DPLA) that Apple requires all developers to enter into, Apple does not permit any third-party app store to be distributed on iOS devices in Australia, whether through the App Store or otherwise. Apple also prohibits and makes it technically impossible to directly download apps onto iOS devices. As to pre-installation, Apple pre-installs the App Store and a few native Apple-developed iOS apps on iOS devices supplied by it in Australia, but it does not pre-install any additional third-party apps on iOS devices.

29    Contrastingly, users of Android devices can use more than one app store. They can also download native apps directly from websites, which is referred to as direct downloading or sideloading.

30    But users of apps for iPhone and iPad have no choice. The only means by which iPhone and iPad users can gain access to native apps, and developers can supply them to such users, is via Apple’s App Store, which is pre-installed on all iPhones and iPads.

31    Further, app developers that make apps available for download on the App Store are contractually required to use Apple’s in-app payment solution (IAP) exclusively to take payment in respect of iOS apps, whether for the initial download of an app or for an in-app purchase of digital content. Contrastingly, when users make an in-app purchase of physical goods or services, developers can choose the payment solution that they wish to use.

32    Apple does not require the use of IAP for in-app purchases of physical goods and services, such as food or transportation. Indeed, Apple specifically prevents IAP from being used for the payment of such goods and services.

33    Apple charges a commission on paid apps downloaded from the App Store and any in-app purchases of digital content within an app that is downloaded from the App Store, and which purchase is facilitated by the only available payment solution, IAP.

34    Apple achieves all of this by means of restrictive contractual provisions to which developers are required to agree if they wish to distribute iOS apps. Those contractual provisions are supported by technical restrictions at the OS level relating to which apps the OS will permit to run.

35    If a developer wishes to distribute iOS apps, it must enter into two essentially non-negotiable agreements with Apple Inc, being the developer agreement and the DPLA. And subject to some limited exceptions, thereafter the developer is only permitted to distribute apps via the App Store. Further, with limited exceptions and as I have already indicated, iOS will only permit apps to run if they were acquired from the App Store, and will not permit apps other than the App Store to install other apps.

36    Developers are not permitted to submit any alternative app store for listing on the App Store. Further, developers are not permitted to distribute an app by any means other than the App Store including via direct downloading. Further, developers are not, save for limited exceptions, permitted to steer users to payment mechanisms other than the IAP.

37    The entry into and enforcement of these non-negotiable contractual provisions is the Apple conduct which these proceedings concern.

38    Now according to Epic, Apple’s conduct should be assessed in two relevant markets.

39    The first market is said to be an iOS app distribution market, in which Apple provides services related to the distribution of iOS apps. This encompasses the services Apple provides to users in making a large range of apps available for download, and to developers in facilitating the provision of developers’ apps to users. It is said that no services are readily substitutable on either the user side or developer side such that the market should be widened. As posited by Epic, Apple is a monopolist in that market, a position which it brought about through various contractual provisions and technical restrictions.

40    The second market is said to be an iOS in-app payment solutions market, in which Apple provides services to developers including accepting, processing, collecting and remitting payments for digital content within iOS apps. It is said that there are no readily substitutable services for developers which might point towards a wider market. Again, as posited by Epic, Apple is a monopolist in that market.

41    Contrastingly, Apple contends for a market which it describes as a market for app transactions. Further, it denies the existence of any separate iOS in-app payment solutions market.

42    Now as to market power, and as I have indicated, Epic says that Apple is a monopolist in both relevant markets, which manifests itself in the complete foreclosure of any competition in relation to the distribution of iOS apps and also for iOS in-app payment solutions services.

43    Further, according to Epic, in both the iOS app distribution services market and the iOS in-app payment solutions market, Apple has acted to ensure that it remains the only supplier and that this was Apple’s purpose in both markets in engaging in the impugned conduct the subject of this proceeding.

44    As to competitive effect, Epic says that Apple is currently a monopoly supplier in both of Epic’s posited markets. Epic says that if Apple’s contractual restrictions were removed, competitors in both markets would be given the chance to compete. It is said that in both markets there are various examples of app developers who have sought to enter the distribution market or use alternatives to Apple’s IAP, but have been blocked by Apple’s contractual restrictions. More directly, Epic says that it would seek to compete in the iOS app distribution market almost immediately. Epic says that entry into both markets would necessarily lead to greater competition than the current state where there is an absence of competition.

45    Now Apple has resorted to matters of security to justify its contractual provisions and restrictions. But Epic’s case is that the issue of security is not relevant to the question of whether Apple’s conduct has the purpose of or brought about a substantial lessening of competition. Epic says that there is no scope to permit a substantial lessening of competition just because it is balanced by claimed pro-competitive effects elsewhere. Epic says that it is impermissible to assess the relevant question by seeking to weigh up Apple’s asserted advantage arising from the restrictive conduct, being increased security, against the harm arising from the restrictive conduct, being a reduction in competition. Further and in any event, Epic says that in respect of distribution, the effective aspects of Apple’s security measures being OS-level protections and other protections can apply to all apps regardless of their source.

46    Further, Epic says that in respect of payment solutions, there is no good reason why allowing entry of other payment solutions providers would have any effect on security. It is said that Apple presently allows alternative payment solutions providers to operate in respect of payments for physical goods and services ordered through an iOS app using a payment system that is integrated into the app.

47    In summary, Epic says that Apple by engaging in the impugned conduct has breached ss 46 and 47, alternatively s 45, of the CCA from 6 November 2017 (the relevant period). I note that it is not a coincidence that 6 November 2017 is also the commencement date for the present version of s 46.

48    Epic says that Apple has breached s 46 because it has substantial market power in both of Epic’s pleaded markets and has imposed the restrictive contractual conditions. Epic says that the restrictive contractual conditions had the purpose, effect or likely effect of substantially lessening competition in one or both of the distribution and payments markets. Further, Epic says that Apple has breached s 47 because it supplies distribution services to iOS app developers on the condition that they not obtain in-app payment solutions for digital content from any other person. And in the alternative to the s 47 case, Epic says that Apple has breached s 45 because it imposes the restrictive contractual conditions.

49    Further, Epic also says that Apple has engaged in unconscionable conduct contrary to s 21 of the Australian Consumer Law (ACL), being schedule 2 to the CCA, by reason of what are said to be the unbalanced contractual terms and technical restrictions which it has imposed on app developers.

Summary of findings

50    In summary, I have made the following key findings.

51    First, I have found in favour of Epic concerning its two posited markets being, first, the iOS app distribution market and, second, the iOS in app payment solutions market. Now I should note that the fact that I have found that various other products and services are not close constraints and therefore are not part of the relevant product dimension of market definition does not entail that the availability of such products and services do not provide some form of competitive constraint. In my view they do provide a competitive constraint to some extent although not such as to deny the market definition that I have found or Apple’s substantial market power in such a market.

52    Second, I have found in favour of Epic to the effect that at all relevant times Apple has and had a substantial degree of power in each market.

53    Third, I have found that Apple has, contrary to s 46 of the CCA, engaged in conduct in either or both markets that had the purpose or had or is likely to have or had the effect of substantially lessening competition in such markets being, specifically, conduct that prevents or prohibits the direct downloading or sideloading of native apps and prevents or prohibits developers and users from using alternative payment methods to IAP for purchasing digital in app content; as to the latter, I have only found in favour of Epic on its effects case.

54    Let me elaborate further on some of my key findings.

55    In my view Apple’s restrictions on direct downloading or sideloading of native iOS apps had the purpose and effect or likely effect of substantially lessening competition in the iOS app distribution services market. Further, in my view such conduct had such a purpose and effect or likely effect in the broader app distribution market, if I am wrong in my primary finding of an iOS app distribution services market.

56    Further, in my view Apple’s conduct in imposing IAP on app developers in the circumstances indicated had the effect or likely effect of substantially lessening competition in the payment solutions market.

57    Now I would note in relation to these findings that Apple may in part in imposing these restrictions have sought to address security concerns and risks. But nevertheless, none of that negates my key conclusions. Apple may have had a security purpose in preventing direct downloading or sideloading, but that does not deny other substantial purposes. Moreover, the existence of a security purpose says little about the effect or likely effect of Apple’s restrictive conduct in terms of competition questions.

58    Now before proceeding further I should say something about Apple’s centralised app distribution system. After all, the various contractual constraints and technical restrictions were designed to keep in place and to fortify such a centralised app distribution system.

59    First, it may be accepted that a centralised system has some benefits over a decentralised system in terms of security concerns.

60    Second, I also accept that the quality of Apple’s offerings including its distribution services is in part a function of the premium style security that Apple offers and enshrines in its centralised app distribution system. So, it is a relevant non-price factor. And so, for example, in dealing with any counterfactual commission charges absent the relevant impugned conduct, quality differentials such as concerns security differences need to be considered in terms of Apple’s offerings as compared with other entities’ offerings.

61    Third, the fact that Apple has imposed a centralised app distribution system for the purpose of protecting security does not entail that there is not also a substantial anti-competitive purpose involved.

62    Fourth, in terms of anti-competitive effects, any security beneficial effects in maintaining a centralised distribution system do not necessarily outweigh any anti-competitive effects flowing from Apple’s conduct.

63    Let me say something concerning Apple’s ban on rival app stores within the App Store. As I have indicated, Apple does not permit the direct downloading or sideloading of rival iOS app stores. Contrastingly, Google permits this concerning rival Android app stores.

64    Now I am not persuaded that the restriction precluding rival app stores within the App Store had an anti-competitive purpose relevant to the iOS app distribution services market. Such a ban is targeted if at all against competitors rather than competition. Further, Apple seems to have had various purposes for such a ban. One purpose was to address security risk as Apple saw it. Another purpose was to prevent free riders. And an associated purpose was to protect the asset that it had invested in and built up.

65    But does this restriction have an effect or likely effect of substantially lessening competition in the iOS app distribution services market?

66    Now given that direct downloading or sideloading of rival iOS app stores was not permitted, it would seem that the combination of such a restriction together with the ban on rival app stores within the App Store had such a likely effect.

67    But of course if I permit the direct downloading or sideloading of rival iOS app stores, then the competition question concerning the ban on rival app stores within the App Store itself is substantially ameliorated. There would then be no effect or likely effect of substantially lessening competition. A rival app store could enter the market and compete through the direct downloading or sideloading of an iOS app store, albeit that there are imperfections and disadvantages in such a pathway as distinct from being permitted to do this through the App Store. But that less desirable pathway would not give rise to substantial competition consequences.

68    Now there is another way to consider the matter. If I allowed an app store within an app store, that would diminish the quality of Apple’s App Store offering. That would not be a pro-competitive step. Further, to the extent that new security risks were injected by permitting such access, that would also not be a pro-competitive step. These last two concerns may have an anti-competitive effect. For reasons I will later address, in my view Apple’s ban on rival app stores within the App Store itself does not contravene the CCA.

69    In all other respects I have not accepted Epic’s case against Apple concerning the other alleged contraventions of Part IV of the CCA or its unconscionable conduct case under s 21 of the ACL.

The joint trial and these reasons – structural aspects

70    Now as I have said, the joint trial before me concerned the concurrent hearing of four proceedings being Epic’s proceeding against Apple, Epic’s proceeding against Google and two class actions.

71    Epic’s two proceedings have been issued out of the NSW Registry of this Court. The two class actions were subsequently issued out of the Victoria Registry of this Court. The two class actions in terms of competition law liability questions were derivative of or sought to leverage off Epic’s cases and evidence on liability against Apple and Google, save for the question of the overcharging of commissions relating to paid app downloads or in-app digital purchases on the App Store or Google’s Play Store.

72    Now in terms of the concurrent hearing of all four matters, I made orders that the evidence in one case should be treated as evidence in all other cases unless I indicated to the contrary, say, in respect of an admission made by one party that was not cross-admissible against other parties.

73    As I have said earlier, I have produced three sets of reasons being the present reasons, another set of reasons in the Epic v Google proceeding and a third set of reasons dealing with and combining my analysis and findings in the two class actions. Now a number of points.

74    First, the sequence in which the reasons should be read for ease of comprehension are in the order that I have just indicated.

75    Second and relatedly, it should also be understood that findings of fact or law in my present reasons form part of the foundation for my reasons in the Epic v Google proceeding and then my reasons in the class actions, unless I indicate to the contrary. Indeed, all sets of reasons should be read as a composite whole. So, although I have indicated the sequence in which the reasons should be read, which in one sense can be seen as an incremental vertical structure, I also intend for my findings in the Epic v Google proceeding to be treated as findings in this proceeding as well as findings in the class actions, and for the findings in the class actions to the extent relevant to be findings in both this proceeding and the Epic v Google proceeding.

76    Third, occasionally, my reasons in Epic v Apple and Epic v Google may overlap in relation to a particular topic. This is partly a function of how the cases have been presented. Nevertheless, my conclusions on such a topic in each proceeding have considered and been based upon all the evidence in all proceedings.

77    Fourth, some aspects of my discussion in the reasons in the class actions concerning the relevant counterfactual analysis should be taken as being incorporated by reference in these reasons. But I do accept that to some extent the dimensions to such an analysis are different.

78    In terms of assessing whether the relevant contraventions occurred, one is looking at and comparing the future from the time of the contravention with the relevant impugned conduct against the future from the time of the contravention without such conduct. But of course in looking at the future with and without the relevant conduct you do not just simplistically hold all else equal. But in terms of the class actions where one is considering causation questions involving what would have occurred if the relevant impugned conduct had not been engaged in, a different calculus and standard of proof is required as I have explained in my reasons in the class actions. A different retrospective hypothetical scenario is involved. Nevertheless the two types of analysis overlap and accordingly my reasons here also include aspects of my reasons in the class actions.

79    Fifth, I should also note here that the economic concepts including the hypothetical monopolist test that I have discussed in my reasons in Epic v Google apply to my discussion in these reasons, although of course more quantitative analysis was involved in the evidence in that proceeding by virtue of Professor Asker’s detailed analysis.

80    Sixth, annexed to my present reasons and the reasons in the Epic v Google proceeding is both a schedule of abbreviations and acronyms and also a dramatis personae which also includes the detail of lay and expert witnesses in terms of their positions at the start of the trial.

81    Now in terms of the venue for the joint trial, on 24 August 2023 being about 7 months before the trial commenced, I informed the parties that the trial would be in Melbourne so that they could organise their affairs including their selection of counsel. I should say that at this time much of the lay written evidence and expert written evidence had been filed save for the important economic expert evidence which was in the early phases of preparation, which for Apple did not need to be filed until 1 December 2023 and which for Google did not need to be filed until 7 February 2024. But undoubtedly some counsel had already been engaged in the matter for some time, including on various questions that had been resolved by the time that I took control.

82    It is convenient to note here a number of points concerning the venue for the joint trial and how it was run.

83    First, the subject matter of the litigation had nothing to do with particular State geography or location. It concerned Australia wide (at least) digital commerce and markets, rather than say a gas plant explosion where the place of trial usually selects itself.

84    Second, 95% of the management lay witnesses of Epic, Google and Apple were located overseas. Whether they flew into Melbourne or Sydney was a neutral question for both them and the parties whether from the perspective of convenience or expense.

85    Third, 95% of the expert witnesses called by all parties were also overseas witnesses. A similar point can be made.

86    Fourth, the trial was run so that the vast majority of Fridays were non-sitting days so that any Sydney counsel could return to Sydney if they so wished. Order 3 of my orders of 27 September 2023 specifically provided for this. This of course entailed that extended sitting hours applied on all other days. I have annexed to these reasons my chambers’ communication to the parties on 24 August 2023, my orders of 27 September 2023 and part of the transcript of the case management hearing held on 19 September 2023 which sets out the discussion on these matters.

87    Fifth, any Sydney counsel had the option of appearing on a video-link at any time if they so wished. Order 6 of my orders of 27 September 2023 specifically provided for this optionality for Sydney counsel on an unqualified basis.

88    Sixth and importantly, for Apple witnesses and issues, Sydney senior counsel for Google did not need to be physically present. Likewise for Google witnesses and issues, Sydney senior counsel for Apple did not need to be physically present. Indeed, that was my observation. Sydney senior counsel came and went depending upon the particular phase of the trial then being run and what their dance cards looked like.

89    Seventh and in any event, each team had multiple senior counsel involved. So, on many occasions where an Apple issue was being run, not all Apple senior counsel needed to be present. Indeed they were not present. The same position applied for Google issues. As for Epic, it had three senior counsel, being Mr Neil Young KC and two others who operated on a FIFO basis as suited the occasion, namely, Mr Garry Rich SC and Dr Ruth Higgins SC.

90    Eighth, the trial required the use under my control of the largest electronically fitted out trial court room of its type in Australia, with the necessary technical and other assistance from numerous court staff, all of whom were ultimately answerable to my requirements. What was also necessary was to provide the parties with workspaces, conference rooms and storage facilities on the same level as the court room. All of this was arranged and provided months in advance of the trial starting. If I may say so I am most grateful to the administrative and court staff for making this all possible. I should also express my appreciation to the in-court electronic operator for her first-class work.

91    Finally in terms of the running of the trial, let me express my appreciation for the considerable effort put in by Mr Young KC and his team for Epic, Mr Matthew Darke SC and his team for Apple, Mr Cameron Moore SC and his team for Google and the cameo performance of Mr Anthony Bannon SC and his team for the class applicants. The timeliness and quality of the work of counsel and their instructing solicitors was excellent, and the skill of counsel in their notably efficient presentations including the handling of witnesses resulted in this complex and lengthy trial finishing precisely on time.

92    Let me now proceed to the heart of the matter. For convenience, I have divided my reasons into the following sections:

(a)    Epic parties and background facts – [94] to [216].

(b)    Apple parties and background facts – [217] to [281].

(c)    Apple’s relationship with app developers and IAP – [282] to [372].

(d)    Google entities and background facts – [373] to [394].

(e)    Epic’s pleading – Apple’s conduct and the pleaded markets – [395] to [483].

(f)    Lay evidence in the Apple proceeding – [484] to [528].

(g)    Apple’s decision-making processes and decision makers – [529] to [583].

(h)    Apple’s contractual framework with developers – [584] to [734].

(i)    Apple’s intellectual property – access and use by developers – [735] to [861].

(j)    Operating systems and security, Apple’s devices and app distribution – [862] to [1297].

(k)    Some legal and economic principles – market definition and other matters – [1298] to [1659].

(l)    Market definition – the parties’ cases – [1660] to [1800].

(m)    Market definition – what is the relevant product? – [1801] to [2032].

(n)    Application of the hypothetical monopolist test – [2033] to [2317].

(o)    Substitution – behaviour of users, relevant metrics, competitive constraints, out of app payments, iOS v Android, perceived competition between Google and Android, Professor Dhar’s surveys, web apps and streaming, conduct of platforms and developer side responses – [2318] to [3688].

(p)    Section 46 – some legal principles – [3689] to [3840].

(q)    Apple’s power in the iOS app distribution market – [3841] to [4174].

(r)    The App Store’s profitability – evidence of market power – [4175] to [4485].

(s)    Core security and threat model – Apple’s justifications – [4486] to [4789].

(t)    The purpose of Apple’s conduct in the iOS app distribution market – [4790] to [5063].

(u)    The effect of Apple’s conduct in the iOS app distribution market – [5064] to [5442].

(v)    In app payments – processing solutions – [5443] to [5623].

(w)    The iOS in app payment solutions market and market power – [5624] to [6005].

(x)    iOS in app payment solutions – purpose and effect of Apple’s conduct – [6006] to [6113].

(y)    The position of Apple Pty Ltd – [6114] to [6137].

(z)    Other alleged statutory contraventions – [6138] to [6324].

(aa)    The question of relief and conclusion – [6325] to [6347].

(ab)    Schedule of abbreviations and acronyms, dramatis personae of witnesses and other individuals, and other annexures.

93    Let me now proceed to deal with some background matters.

Epic parties and background facts

94    Let me now say something about the Epic parties. The following matters are not controversial unless I state otherwise.

95    The first applicant, Epic Games Inc, is a technology company headquartered in Cary, North Carolina, USA. Epic was founded by Mr Timothy Sweeney in 1991. He remains its CEO, controlling shareholder and is the chairman of its board. Other current shareholders of Epic include a subsidiary of Tencent Holdings Ltd, Sony Corporation, KIRKBI A/S (the parent of the Lego Group) and the Walt Disney Company.

96    Epic’s business is multifaceted and includes the following aspects.

97    First, its business includes the development of apps for consumers, including both gaming and non-gaming apps.

98    Second, its business includes the development of software tools that provide other developers with digital content and other resources, and which can be used in a range of commercial settings, including game development, film and television production, architecture, and automotive design. These software tools include Epic’s licensable “game engine”, known as Unreal Engine, the most recent version of which was released in April 2022.

99    Third, its business includes the provision of Epic online services which is a modular set of online services made available for free to other developers for use in multiplayer games. Epic online services enables developers to provide a wide range of functionalities, including those that facilitate “friend” connections and voice communication between users, and the analysis of user activity.

100    Fourth, its business includes distributing and publishing PC apps developed by Epic and third-party developers, which has been facilitated via the Epic Games Store since December 2018.

101    Fifth, its business includes providing an optional payment solution known as Epic Direct Payment (EDP) to process in-app purchases of digital items for developers whose apps are distributed through the Epic Games Store. Epic charges developers that use EDP a 12% commission on in-app purchases, but does not charge any commission for in-app purchases where the developer uses an alternative payment solution.

102    Epic is now a significantly sized company. Its most popular app is Fortnite. In January 2023, there were approximately 1.4 million monthly active users of Fortnite, and approximately 12,000 monthly active users of Unreal Engine, in Australia. A monthly active user is a consumer who ran the app or completed a purchase within the app at least once during a given month.

103    The second applicant, Epic International, is a subsidiary of Epic that is registered in Luxembourg. The third applicant, Epic Entertainment, is a subsidiary of Epic that is registered in Switzerland.

104    Until 2023, Epic International was responsible for certain parts of Epic’s business operations outside the USA. In particular, until 31 December 2022, Epic licensed Epic International to distribute, publish, market and operate games developed by Epic, as well as Unreal Engine, outside the USA. Since 1 January 2023, Epic Entertainment has replaced Epic International in this function.

105    Users in Australia who download and use Epic’s apps on a smart mobile device enter into an end user licence agreement with Epic International from August 2018 to 31 December 2022, or Epic Entertainment since 1 January 2023.

106    At its inception, Epic’s business focused on the development of computer games for PCs, and, from 1998, the provision of Unreal Engine, which Epic licensed and continues to license to other developers. In addition to being a developer in its own right, Epic has consistently sought to foster a competitive environment for third-party developers. Initially, this was for the collective benefit of the gaming industry. More recently its focus has expanded to the app industry as a whole.

107    It has done so in a number of evolving ways. From the outset, Epic sought to support third-party developers by creating innovative product features and software tools that were made available to all developers. So, Epic’s first PC game enabled users to edit and create new versions of gameplay within the game. The Unreal game, which precipitated Unreal Engine, took this concept further and provided users with access to the game’s complete editing interface and scripting language, thereby enabling them to program and then share their own game modifications with other users. The subsequent development of Unreal Engine conferred even more wide-reaching benefits on third-party developers: the engine was designed to enable developers to generate their own components for their own games. This resource provided developers with the necessary capabilities to overcome the significant technical barriers to developing high quality 3D games. More recently, in 2020, Epic launched Epic online services which provides further tools and services to developers to assist them to enhance their games. Epic online services is available for free and is compatible with a variety of game engines beyond Unreal Engine.

108    Upon the launch of the App Store in 2008 and the emergence of native iOS app development, it was anticipated that mobile games would be the next frontier for Epic and should be a central focus of its business strategy. Epic began directing its attention to iOS app development. At the time, most iOS game apps were rendered with simple 2D graphics and yet were popular with users. If Epic could make Unreal Engine compatible with iOS, it could bring more complex and immersive 3D games to iPhone users, and later to Android users, and become the leading game engine for high-quality 3D games on smartphones.

109    In 2010, Epic updated Unreal Engine 3 to include support for iOS and Android apps. In later editions of Unreal Engine, Epic progressively widened its functions and availability and reduced its cost, and it is now used in many business contexts, including film, television, automotive design and the training of surgeons.

110    In or around September 2010, Epic and Apple entered into an Apple developer agreement, which governed how Epic could use information and software provided by Apple, as well as a DPLA, including schedule 2 to that agreement. Together, these set out the terms on which Epic could develop and distribute iOS apps on the App Store.

111    At the same time, Epic opened an Apple developer program account, being the Team ID ’84 account, which was subsequently used for the distribution of Fortnite, among other Epic apps.

112    In 2011, Epic began exploring ways to reposition itself to become a leading developer of “play for free” or “freemium” online games using a “games-as-a-service” model. This involved distributing games directly to users online and continuously updating those games with new content, for example, new maps and characters, without the need to develop sequels. Play for free games can be downloaded and played without charge, but typically offer optional in-app purchases for players to enhance their experience.

113    In about September 2003, Valve Corporation, a game developer, launched an online PC app distribution service called “Steam”, which could be accessed from a web browser or downloaded as a desktop app by PC users. Initially, Steam only distributed PC games developed by Valve itself.

114    In about October 2005, Valve started distributing third-party PC games through Steam, charging a commission of 30% of the gross revenue from the sale of each game downloaded. Within about three years, almost all third-party PC game sales were occurring through Steam. It remained the dominant distributor of PC games for at least another 10 years.

115    In 2013, Epic began negotiating with Valve for the distribution of Fortnite to PC users. Epic had previously distributed PC games in the Unreal series through Steam, paying Valve 30% of its gross revenue from those titles. But there were perceived drawbacks in Valve’s terms. Epic decided that it would not distribute Fortnite through Steam and instead took steps to develop its own PC distribution capability. Epic’s ultimate objective was to develop a multi-platform store for both Epic and third-party titles, with a commission structure that was more favourable to developers than that of Steam. This decision was informed by the fact that Epic was already a relatively successful company which could expect to reach a substantial user base.

116    The first step toward this objective was the launch, in 2014, of the Epic Games Launcher. PC users could download this app free of charge from Epic’s website. It enabled them to access and download to their PC all of Epic’s games and other apps, including Unreal Engine. By June 2015, the Epic Games Launcher had achieved one million unique users and hosted various Epic products.

117    Epic began working on Fortnite in late 2011. The app underwent testing with limited numbers of users in late 2014 and through 2015, and was publicly released on 25 July 2017 as a paid game on PCs such as Windows and macOS, Xbox One, and PlayStation 4. At the time, PCs and consoles were the only devices capable of supporting “AAA” games, being games that, like Fortnite, require high-level graphics, high screen resolutions, and sophisticated input devices or controllers.

118    The original version of Fortnite released on 25 July 2017 was a “player versus environment” (PvE) game, now known as Fortnite: Save the World. PvE games involve a single user playing against a computer-controlled environment or characters. Save the World quickly became popular and, by mid-August 2017, over one million people had played it.

119    In September 2017, Epic launched a new free to play, multiplayer game mode within Fortnite called Fortnite Battle Royale. Within about three weeks of its release, over 12 million people had played Battle Royale. By the middle of January 2018, that number exceeded 40 million. Within a year of the release of Battle Royale, there were approximately 175 million registered Fortnite users. It has since become one of the world’s most popular games. As of February 2023, the number of users who registered a Fortnite account exceeded 500 million, and there were about 62 million monthly active users, being users who log into their Fortnite account at least once per month.

120    In late 2017, Epic introduced various features which allowed real world friends to connect with each other within Fortnite and allowed users to make new connections with other Fortnite users. The ability for users to build strong social connections within the game, and to play with people whom they knew in the real world was an important part of Epic’s strategy to grow the Fortnite user base and maintain user enjoyment over time.

121    By August 2018, Fortnite was available on Windows, macOS, Xbox, PlayStation, Nintendo Switch, iOS and Android and, in September 2018, it became the first AAA gaming app to achieve full cross-play functionality between all of those devices. Cross-play enabled a user playing Fortnite on any one of those devices to play in the same game session as a user of any of those other devices, provided each had installed the latest update to Fortnite.

122    Achieving cross-play functionality was and remains innovative, and required Epic to overcome differences between each platform. It required negotiations with Microsoft and Sony, both of whose standard platform rules had prohibited cross-play functionality. Epic considers cross-play to be an essential part of the Fortnite experience. Without it, users would not be able to play with their friends unless their friends owned the same device hardware, and Fortnite’s user base would be fragmented. For users, cross-play between platforms is one of Fortnite’s popular features.

123    At the same time, Epic introduced cross-progression within Fortnite across PCs, consoles, and mobile devices, which enabled users to access the digital items they had purchased and the rewards they had earned on any platform by logging into their Fortnite account, regardless of the platform on which the items had been purchased or the rewards earned.

124    Epic then progressively introduced cross-wallet within Fortnite, which provided the ability to purchase V-Bucks, being an in-app currency, on one platform and to then use those same V-Bucks on another platform. But Nintendo has never allowed this functionality.

125    Both cross-progression and cross-wallet were innovative technical achievements, and both features remain uncommon among mobile games.

126    In December 2018, Epic launched another mode within Fortnite known as Fortnite Creative. Creative enables users, on their own or with up to 16 friends, to customise and publish their own Fortnite “islands”; that is, virtual worlds, in which users can play Battle Royale-style games, enjoy musical shows and concerts, attend social or educational experiences or artistic installations, or visit virtual tourism destinations. Once these islands are created, other Fortnite users can access and experience them.

127    Creative has been popular with Fortnite users. Between October 2020 and December 2021, Fortnite users spent 30 to 40% of their time in Creative, and 75% of monthly active users played Creative. As at February 2023, over one million creators had published over one million islands.

128    In April 2020, Epic released Fortnite Party Royale, as part of Fortnite’s evolution from a pure gameplay experience to an app with a substantial social and entertainment dimension. Party Royale was a mode in which users could take part in events with other users without participating in gameplay such as music concerts, movie screenings, collaborations with TV shows, fashion brands and athletes, social justice discussions, and film festivals.

129    The result of these iterative developments is that Fortnite has evolved from being a game to being an app that offers each of its many users an immersive social, entertainment, and creative experience.

130    Epic incurs significant costs to maintain and continually improve Fortnite. Battle Royale is regularly updated, with new chapters and seasons, storylines, maps, items, weapons, and challenges. Epic employs approximately 500 to 700 engineers, including teams of platform experts who specialise in platforms such as Xbox, Linux, Mac, Windows, PlayStation, Android and iOS. Of those, some 150 engineers are responsible for the continued development of Fortnite.

131    Now Epic has monetised its apps both through subscriptions and, more extensively, in-app purchases of digital content. Fortnite generates revenue primarily through the sale to users of the in-app currency V-Bucks. V-Bucks can be purchased with real money within the Fortnite app, and they can be purchased outside the app, from the Epic Games Store on PCs, from console stores, physical retailers and online resellers.

132    Once purchased, V-Bucks are stored in a digital wallet linked to a user’s account in the Fortnite app. They are used to buy digital items from a store within the app, which items can then be used in the game. Once purchased, digital items are stored in a user’s “locker”, from which users can select the items with which they want to equip their character at any given time.

133    In addition to V-Bucks, users can purchase a “pack” of digital items for use in Fortnite, whether from other digital storefronts or physical retailers. The digital items contained in a pack can be redeemed from the item shop, within the Fortnite app or through the Epic Games website.

134    In December 2020, Epic introduced the “Fortnite Crew” subscription service which provides users with a “crew pack”, which includes a collection of digital items and 1,000 V-Bucks, each month, in exchange for a monthly fee.

135    Let me turn to the development of Fortnite for mobile devices. In about January 2018, Epic decided to launch Fortnite on Android and iOS mobile devices.

136    To continue to expand the Fortnite user base, Epic considered that it was necessary to make Fortnite accessible to users across as many device types as possible. Making Fortnite available on mobile devices was seen as a means to attract a new class of users who did not own a PC or console, or did not often play games on those devices. Given that most people own a mobile device, but a far smaller proportion of people own a gaming console, Epic considered that the potential audience for Fortnite on mobile was much larger than on consoles. Epic also considered that launching Fortnite on mobile would attract a different audience, including casual gamers, mobile gamers and women, who were less likely to purchase consoles than mobile devices and more likely to play games on mobile devices than on consoles or PCs. In addition, expanding to mobile would allow Epic to engage existing Fortnite users at different times and in different situations, given the portability of mobile devices relative to PCs and consoles.

137    Now building a mobile version of Fortnite took considerable technical work by a team of engineers, to accommodate the differences between mobile devices, consoles and PCs, including the smaller and lower quality displays, and the role of touch screen controls.

138    Epic sought to launch Fortnite on iOS and Android mobile devices at around the same time, because both operating systems had very large user bases and Epic believed users tended not to switch between them. The development process took longer for Android than iOS, including because of the need to ensure compatibility with many different Android devices which are manufactured by a variety of original equipment manufacturers (OEMs) with different characteristics.

139    To launch Fortnite on mobile, Epic created Fortnite native apps for iOS and Android and, for Android only, the Fortnite installer.

140    Although Fortnite can be accessed and streamed on certain devices, including iOS and Android, Epic perceived that running Fortnite as a native app as opposed to a web app or streaming app on mobile was the only viable option to reach a broad new user base and the only way to provide an acceptable experience to all users. Epic considered that offering Fortnite to mobile users via a web app was not viable because web apps suffer from limitations as to speed, performance, functionality, memory and security, which would compromise the user experience.

141    Epic released a beta version of Fortnite as a native app for iOS devices on 14 March 2018. The full release occurred in April 2018.

142    The contractual terms previously agreed between Epic and Apple, as well as technical restrictions which Apple imposed on iOS devices, precluded Epic from ever distributing Fortnite as a native app to iOS device users otherwise than via the App Store. In short, an app cannot be distributed to iOS devices without a certificate from Apple. Further, under the DPLA, Apple prohibits all forms of app distribution outside of the App Store, custom app distribution, ad hoc distribution and beta testing through TestFlight.

143    During the period in which Fortnite was available on iOS, it was consistently one of the most popular apps on the App Store. Throughout 2018 and 2019, Fortnite maintained a top 10 position on the App Store in the “free games” category and was one of the top grossing iOS apps overall. From March 2018 to July 2020, Fortnite’s average monthly active users on iOS devices ranged between 8.3 million and 13.6 million.

144    Let me say something now about the Epic Games Store.

145    For several years prior to 2018, Epic had a goal of developing a store for its own PC games and third-party PC games. This would enable it to distribute its apps without paying commission to a distributor. It would offer app developers a commission structure more favourable to them than Steam’s 30% commission. It would later expand into mobile platforms to create a multi-platform store. And it would expand Epic’s ecosystem by attracting more consumers and developers to Epic’s products.

146    Epic began implementing this strategy in 2018. The Epic Games Store was launched on 6 December 2018. The Epic Games Store is an app store for PCs running Windows and macOS, comprising the Epic Games Store website and the Epic Games Launcher app.

147    Since at least 2020, the Epic Games Store has included non-gaming apps, such as the music streaming app Spotify, the voice-chat and social app Discord, the podcast and radio streaming app iHeart, an app created by Buendea in partnership with NASA to assist NASA research being NASA XOSS MarsXR Editor, and the music streaming app Tidal.

148    Users can browse and purchase gaming and non-gaming apps on the Epic Games Store website, but must download and install the Epic Games Launcher in order to download and install Epic Games Store titles on their PC. The Epic Games Launcher ensures that all apps downloaded from the Epic Games Store can be updated automatically and are stored in the same location on the user’s device. Once installed on a PC, the user can browse and purchase Epic Games Store titles from within the launcher app, without having to navigate to the Epic Games Store website via a web browser.

149    The games and other apps available on the Epic Games Store include first-party titles that Epic developed or owns, second-party titles developed by third-parties with funding from Epic Games Publishing, and third-party titles developed and funded by third-party developers including Spotify.

150    By about January 2024, the Epic Games Store had three first-party titles, six second-party titles, and approximately 2,976 third-party titles. By that time, 262 million total users had interacted with the Epic Games Store at least once and it had reached a peak in December 2023 of 75 million monthly active users.

151    Now in launching the Epic Games Store, Epic sought to disrupt Steam’s dominance in PC app distribution by offering developers a more favourable revenue share model, more closely reflecting the actual costs of app distribution.

152    The revenue share model Epic decided to implement for the Epic Games Store was an 88:12 percentage split, whereby third-party app developers retained 88% of gross revenues generated from the sale of apps and from in-app purchases made within apps downloaded from the Epic Games Store. Epic considered that a 12% commission would cover its costs of distributing third-party apps on the Epic Games Store and earn Epic a profit of about 5% of gross revenues.

153    Now in order to attract developers to distribute their apps via the Epic Games Store and compete with Steam, Epic considered that it would need to offer an attractive revenue share to developers and grow the Epic Games Store user base into a large and engaged audience.

154    Epic’s strategy was to rapidly grow the Epic Games Store user base by leveraging the popularity of Fortnite, and by offering apps that were for a period exclusive to the Epic Games Store on PC. To persuade developers to offer exclusive PC content on the Epic Games Store and forgo Steam’s much larger user base, Epic offered developers minimum guarantees, that is, it promised to pay certain developers a minimum amount regardless of revenue earned in exchange for exclusive Epic Games Store distribution on PC for 12 months. To attract users, Epic also offered games that, for a limited period, could be installed for free and which, once installed, could be retained indefinitely.

155    Now in the months leading up to the launch of the Epic Games Store, Epic met and communicated with about 80 to 90 different app developers and informed them of its intention to launch a rival PC app store with an 88:12 percentage revenue share. About two weeks before launching the Epic Games Store, Epic informed Steam’s owners that Epic was about to announce an 88:12 percentage revenue split.

156    On 1 December 2018, five days prior to the launch of the Epic Games Store, Steam announced the first change to its 70:30 percentage revenue share model in about 13 years, in the form of a tiered commission structure at the following rates: 30% of the first USD 10 million in revenue; 25% of revenue between USD 10 million and USD 50 million; and 20% of revenue over USD 50 million.

157    Other Epic Games Store competitors shortly followed. About eight days after the Epic Games Store launch, Discord, a social and voice-chat company which had launched its own PC app store in August 2018, announced that it would reduce its revenue share from 70:30 to 90:10. In March 2019, about four months after the Epic Games Store launch, Microsoft lowered its commission rate for all non-gaming apps distributed on PC through the Microsoft Store from 30 to 15%. In about May 2019, Microsoft announced a new version of its game subscription service, Xbox Game Pass for Windows PCs, which enabled Microsoft to differentiate the Microsoft Store from the Epic Games Store and Steam.

158    In April 2021, Microsoft announced that it was lowering its commission rate for PC gaming apps to 12%, matching the Epic Games Store’s revenue share.

159    In June 2021, Microsoft announced that, with effect from 28 July 2021, app developers were no longer required to use Microsoft’s payment solution for in-app payments within non-gaming PC apps, and instead could use their own or a third-party commerce platform in their apps, in which case no commission would be payable to Microsoft. This latter announcement also mirrored the approach taken by the Epic Games Store.

160    Now when the Epic Games Store first launched, EDP was used to facilitate purchases of paid apps on the Epic Games Store as well as for in-app purchases of digital goods and services within apps downloaded from the store.

161    EDP was created by Epic, initially for the purpose of facilitating in-app purchases within its own apps. Currently, it is incorporated within most PC apps downloaded from the Epic Games Store and within Epic’s apps on Android devices, save for those downloaded from the Samsung Galaxy Store, both to facilitate the purchase of paid apps and to facilitate in-app purchases of digital goods and services.

162    In around mid-2019, Epic agreed to permit the developer Ubisoft to distribute via the Epic Games Store but with its own payment solution, owing to technical features associated with Ubisoft’s games.

163    In December 2019, Epic decided to allow all third-party developers distributing through the Epic Games Store to choose their own payment solution for in-app purchases within their apps.

164    Third-party developers can build their own payment solution to facilitate in-app purchases, use a payment solution developed by a third-party payment solutions provider such as Paddle, Stripe, Square or PayPal, or use EDP.

165    Where the developer chooses not to use EDP in a given app, Epic does not earn any commission on in-app purchases occurring within that app save where Epic has paid the developer a minimum guarantee or other amount yet to be recouped.

166    EDP allows users to purchase goods and services without leaving the app. EDP accepts payments using about 76 payment methods in 43 different currencies. It connects to payment gateways provided by eight third-party payment processors.

167    EDP is compliant with the Payment Card Industry Data Security Standard, as are the third-party payment processors that Epic uses for EDP, and has anti-fraud and transaction data encryption measures in place. Additional anti-fraud checks are run by both the third-party processor and the financial institution. If a user makes a purchase within an app that uses EDP, and that user has not previously provided their payment details, the user will be asked to enter those details and they will be securely stored by the third-party payment processor, not by EDP.

168    Where a third-party developer chooses to use EDP, Epic or Epic International, depending on where the customer is domiciled, generally acts as “merchant of record”. Epic sells the digital goods on behalf of the app developer, takes responsibility for associated licensing and reporting obligations including paying relevant taxes and handles refund requests and other customer complaints.

169    Let me now say something about Epic’s agreements with app developers relating to the Epic Games Store.

170    Since at least 23 August 2023, all developers distributing apps via the Epic Games Store do so under the terms of the current Epic Games Store distribution agreement with Epic. Previously, developers who chose not to use EDP for in-app purchases could enter into an in-game transaction rider, which could sometimes be negotiated. The Epic Games Store distribution agreements do not prohibit the distribution of other app stores on the Epic Games Store and, indeed, two alternative PC app stores are currently distributed through the Epic Games Store.

171    For app developers, the Epic Games Store provides various features and functions, including the following.

172    First, there is a distribution service, whereby Epic hosts developers’ apps on Epic’s servers, displays those apps on the store, and distributes the apps to those users who choose to purchase or download them through the store.

173    Second, there is access to a developer portal, where developers can publish their apps and updates, upload code, access marketing tools and sales and financial data, as well as obtain app development tools such as the Epic online services (EOS) software development kit (SDK). EOS is a modular set of online services which make it easier for developers to successfully launch, operate, and scale high-quality games.

174    Third, subject to user consent, Epic provides developers with their users’ email addresses, which enables developers to share information with users about updates, new features, and titles.

175    Fourth, the developers have the option of promoting their titles to users on the Epic Games Store homepage from time-to-time as part of Epic’s editorial support. Epic does not offer paid or search advertising on the Epic Games Store but provides developers with access to its social media channels and merchandising services.

176    Fifth, there is cross-store PC play support, whereby Epic requires developers to integrate cross-store PC play functionality within their titles, that is, the ability for users to play games with each other regardless of the store from which they downloaded the app, and sometimes provides financial support to developers to cover the engineering work to meet this requirement. Epic has developed and made available an SDK to support cross-store PC play, which it makes available to developers for free.

177    For app users, the Epic Games Store offers a digital store with a simple user interface through which users can download paid and free PC apps and utilise enhanced search functionality such as searching by search terms, category, or additional filters like price range, genre, type of app, type of game, and supported controller types. Refunds are paid in accordance with Epic’s refund policy where EDP is used, and the Epic Games Store also supplies bandwidth management tools, weekly free games, user and critic ratings and reviews for certain titles, as well as user rewards and parental control settings.

178    Prior to being added to the Epic Games Store library, all apps submitted for distribution on the Epic Games Store are assessed by Epic using virus and malicious software scan technology, PhotoDNA to detect inappropriate image material, and every title is run to ensure it meets Epic's functionality and feature requirements, and the text, images, videos and product display pages of titles are reviewed to ensure titles meet Epic’s content guidelines.

179    In respect of security, Epic protects users’ accounts on the Epic Games Store, including by using email verification to validate new users’ email addresses, employing password criteria and Captcha technology, offering two-factor authentication, and monitoring for unusual transaction activity.

180    Now since its launch in December 2018, the Epic Games Store has grown rapidly.

181    As of January 2024, it was the second largest PC app store, with approximately 262 million total users and over 1,151 developer accounts which distributed apps through the store, and it had increased its gross revenue from USD 570.9 million in 2019 its first full year to [REDACTED] [REDCATED] in 2023. By this time, the Epic Games Store had also increased its average monthly active users, that is, persons who have opened the Epic Games Launcher rather than visited the website, from 32.2 million in 2018 to 63.7 million in 2023 and its average retained active users, that is, persons who have transacted with the Epic Games Store and continue to use the Epic Games Store in consecutive months, from 9.7 million or 64.8% in 2019 to 25.9 million or 68.7% in 2023.

182    As a result of the accelerated growth strategy deployed by Epic, and particularly due to large minimum guarantees paid to secure exclusive titles in the first four years, the Epic Games Store has not yet generated profits from the distribution of second-party and third-party apps. Although Epic derives revenue from its first-party apps such as Fortnite that are distributed on the Epic Games Store, Epic does not attribute this revenue to the Epic Games Store for its internal accounting purposes. Rather, first-party app revenue is attributed to the particular app in question.

183    Epic has now significantly reduced the value of minimum guarantees paid to developers, and expects the Epic Games Store’s third-party and Epic Games publishing businesses to be profitable by around 2027, using its existing revenue share model. It also had approximately seven second-party titles in development which are planned for exclusive release through the Epic Games Store.

184    It has introduced self-service publishing tools which make the process for distributing third-party apps through the Epic Games Store more efficient, by relying less on Epic’s own technical support and release management teams.

185    In the period between 10 March 2023 and 31 December 2023, approximately 1,118 third-party titles were released through the Epic Games Store’s self-service publishing tools. Epic expects its self-service publishing tool to continue to dramatically increase the number of third-party apps on the Epic Games Store and that its annual revenue from third-party titles will exceed [REDACTED].

186    Let me now say something about the events leading to and concerning the removal of Fortnite from the App Store.

187    Now Fortnite was available on the App Store from 26 February 2018 to 13 August 2020 for downloading on iOS mobile devices. At all relevant times it was a party to a DPLA with Apple Inc and also a developer agreement.

188    During that period, Fortnite was downloaded for free from the App Store’s Australian storefront around 2.85 million times. Within those downloaded apps, approximately 2 million paid transactions were made.

189    Despite the large number of iOS users, as a proportion of the total paid transactions in Fortnite during this period the value of the transactions that took place on iOS was around 9%.

190    On 30 June 2020, Epic renewed its DPLA with Apple. Also on 30 June 2020, Mr Sweeney sent to Mr Phillip Schiller and other executives at Apple a request for a special side deal amending the DPLA so as to permit Epic to include competing payment processing options in Fortnite and other Epic software distributed on the App Store and to make the Epic Games Store app available on the App Store and by sideloading. Mr Sweeney acknowledged at the time that this was prohibited under the terms of Epic’s contracts with Apple; see his email of 30 June 2020 to Mr Cook and others.

191    On 10 July 2020, Apple responded to Mr Sweeney’s email. In its response, Apple explained that to accede to Epic’s demands would require Apple to behave in a manner contrary to rules and guidelines vital to the health of the Apple platform and which provide enormous benefits for both app users and developers.

192    On 3 August 2020, Epic submitted Fortnite version 13.40 to Apple and to Google. That version contained code that would allow Epic to offer EDP as an alternative payment option in Fortnite on iOS devices when what has been described as a hotfix was activated. A hotfix is a method of making real-time changes to apps available to users without adding new code and without requiring them to download a new update from an app store. Epic did not disclose to Apple that this version of Fortnite contained the hotfix code, because it believed that Apple would not have approved the version 13.40 update.

193    The description of the update submitted to Apple did not mention Epic’s direct payment option, even though a description of the changes contained in the update is required. Epic’s servers and in-app payment screen in the submitted Fortnite app reflected that IAP was the only available payment option within Fortnite for iOS.

194    Apple approved Fortnite version 13.40 and it was made available in the App Store. The hotfix was installed when existing app users downloaded the update, or new app users downloaded the app.

195    Epic deceived Apple because Mr Sweeney and unnamed others at Epic believed that Apple would not have approved the new version of Fortnite had it known what the software contained. Epic planned the hotfix with the goal that the code would not be discovered through the app review process. That was the point of the hotfix. Mr Sweeney understood at the time that what Epic was planning to do would breach various provisions of the DPLA.

196    On 13 August 2020, Epic activated the hotfix and thereby made EDP available within Fortnite on iOS. As a result, iOS users were presented with a choice when purchasing V-Bucks within Fortnite. They could make their purchases using Apple’s IAP or by using EDP.

197    At the same time, Epic introduced what has been described as the Fortnite mega drop. This was a permanent price reduction of up to 20% for Fortnite in-app purchases on iOS, the Play Store, Windows and macOS, when EDP was used, and on Xbox, PlayStation and Nintendo Switch regardless of payment method. The mega drop was designed to encourage iOS and Android users to make in-app purchases using EDP rather than Apple’s or Google’s payment solutions.

198    Just after 2am on 13 August 2020, Mr Sweeney emailed Mr Schiller and other Apple executives, informing them that “Epic will no longer adhere to Apple’s payment processing restrictions”.

199    He threatened that if Apple chose to block user access to Fortnite or its updates on Apple’s iOS platform, then Epic would be in conflict with Apple on a multitude of fronts.

200    Epic then activated the functionality for Epic direct payments on Fortnite, circumventing the IAP function on iOS devices.

201    Later on 13 August 2020, Apple removed Fortnite from the App Store due to the presence of the EDP functionality. Later Epic commenced proceedings against Apple in the United States District Court for the Northern District of California alleging, among other things, violations of the Sherman Act and California’s unfair competition laws.

202    On 14 August 2020, Apple suspended Epic’s membership of the developer program, and advised that its developer account would be terminated within 14 days unless Epic cured its breaches of the DPLA.

203    On 28 August 2020, Apple terminated Epic’s developer account, DPLA and its developer agreement and informed Epic that it could not reapply to the Apple developer program for at least one year. As a result, Epic could no longer submit apps or updates to the App Store and, in addition to Fortnite, other Epic apps associated with the Team ID ’84 Account were removed from the App Store, including in Australia. Further, the equivalent Epic macOS apps were no longer available for download by macOS users from the App Store and could not be updated.

204    Epic’s response was to inform app users that they could continue to play Fortnite on other devices.

205    The removal from the App Store of Fortnite and Epic’s other apps had the effect that new iOS device users could not download those apps from the App Store, and existing iOS users of those apps could no longer update their iOS versions of those apps. Given the frequency of software updates, Fortnite users were quickly unable to use the app on iOS to play with users on other platforms who were using an updated version.

206    In August and September 2021, more than one year after the termination, Epic made several requests for reinstatement of its Team ID ’84 Account. To date, Apple has not reinstated Epic’s account.

207    Now during the period in which Fortnite was available on iOS, it was consistently one of the most popular apps on the App Store and by July 2020, Fortnite’s average monthly active users on iOS devices had reached 13.1 million. By December 2020, fewer than four months after Fortnite’s removal from the App Store, only 1.9 million average monthly active users remained on iOS.

208    The effect of Fortnite’s removal from the App Store has been significant declines in Fortnite’s revenue. In addition to the lost revenue caused by Apple’s removal of Fortnite from the App Store, Epic continues to be denied the opportunity to launch the Epic Games Store on iOS devices in Australia, among many other places, and thereby to grow its own user base.

209    Now Epic has said, which I accept, that if Apple and Google lifted its restrictions in Australia and globally, Epic would launch the Epic Games Store on iOS and Android within months. In doing so, Epic would ensure that users of the Epic Games Store on PC, iOS or Android could buy an app from the Epic Games Store on any of those platforms and access it on the others without having to repurchase the app. And Epic has said that it would offer app developers a lower commission rate than they are currently charged by Apple and Google.

210    Now as to the Fortnite hotfix, Mr Sweeney accepted that both the immediate effect and the long term goal was to avoid Apple’s 30% commission. Epic’s best estimate was that between 30% and 70% of transactions would transfer to other platforms. The base case was a transfer of 50% of transactions.

211    After the release of the hotfix Epic released marketing materials that sought to encourage users to continue playing and making Fortnite purchases on other platforms. Epic’s aim was to do the most it could to encourage users to play and spend on other platforms.

212    Now in terms of the developments to the time of trial, the following should be noted.

213    As I have indicated, if Epic could distribute the Epic Games Store as a native app on iOS and Android through the App Store and the Play Store being Google’s app store respectively, it would do so, and Epic says that it would offer mobile app developers the same 88:12 revenue share, plus the option to use their own payment solution and pay no commission on in-app purchases.

214    But at present and due to Apple’s restrictions, Epic is not permitted to distribute the Epic Games Store on iOS devices, either via the App Store or by direct download from Epic’s website outside of the European Union.

215    On 26 January 2024, Epic announced via social media platforms its intention to launch an Epic Games Store mobile store on iOS devices in the EU as a result of it being made possible by the Digital Markets Act (EU). In furtherance of this objective, on 17 February 2024 Epic announced that it had had its developer account reinstated which would enable it to commence developing the Epic Games Store on iOS.

216    Now before proceeding further I should make one other comment concerning Epic. For some years now it has been pursuing corporate and litigation strategies here and in foreign locations under what it has described as Project Liberty, which has been designed to challenge Apple’s and Google’s policies in relation to the distribution of apps through the App Store and Play Store respectively. Where relevant, in both these reasons and in my reasons in Epic v Google I have made reference to specific events, actions and internal considerations that concern the causes of action pleaded and this stage of the trial that could be said to fall under that strategy.

Apple parties and background facts

217    I have said a little about Apple at the outset of these reasons, but let me now elaborate. Unless I state otherwise, the following matters are not controversial.

218    The first respondent, Apple Inc, is a technology company and has a substantial market capitalisation. It is incorporated and based in California, USA.

219    Apple Pty Ltd, a subsidiary of Apple Inc and incorporated in Australia, supplies Apple hardware and services to app users and developers in Australia. Apple Pty Ltd is not involved in relation to requiring developers to enter into or comply with contractual agreements between them and Apple. The staff of Apple Pty Ltd provide support to Australian app developers and choose the apps that will be highlighted in the country-specific version of the App Store that is accessible to Australian app users. This is what I have referred to as the Australian storefront.

220    As I have said, Apple Inc and its subsidiaries design, manufacture, and market iPhones, iPads, and Macs, as well as various other devices and accessories. As of 30 December 2023, there were over 2.2 billion active Apple devices worldwide. As at Q1 FY2022, excluding China, there were over 1.4 billion active Apple devices worldwide.

221    Apple also supplies various services, including the App Store, which distributes iOS apps, Apple Music being music subscriptions, Apple Arcade being game subscriptions, Apple TV+ being subscription and on demand video services, and payment services including Apple Pay. The combination of Apple’s hardware, software and services was described by the parties before me as the Apple ecosystem.

222    As at 31 March 2023, more than 1.5 million iOS apps were available for download on the Australian storefront, of which only 86 were developed by Apple. The remainder were independently developed by third-party developers.

223    Now as I have already said, the OS used by the iPhone is known as iOS. It was developed by Apple and first released with the iPhone in 2007, as I will discuss shortly.

224    When the iPad was first released in 2010, its OS was an adapted version of iOS. Since about June 2019, the iPad has used an OS known as iPadOS, which was developed specifically for the iPad using iOS as the foundation. Save where necessary to distinguish between them, I will refer to the operating systems for both the iPhone and the iPad as iOS.

225    Both iPhones and iPads, being iOS devices, are sold to consumers with iOS pre-installed. Apple does not licence iOS to other OEMs.

226    The OS used by Apple’s line of general-purpose PCs is known as macOS, which predates iOS. These devices include iMac, Mac Pro, Mac Mini and the MacBook range of laptops, being macOS devices. macOS and iOS are based on the same core technologies and code but are modified to suit the device on which they operate.

227    The iPhone is a handheld portable electronic device which is capable of cellular communication via cellular mobile networks, telephony, and multipurpose computing functions. It comprises integrated hardware and software components that provide internet connectivity and the ability to access apps offering a variety of functions.

228    Like the iPhone, the iPad is an integrated hardware and software device operated via touchscreen, which provides internet connectivity and the ability to access apps offering a variety of functions. The iPad is capable of cellular communications and is portable, although it is larger than an iPhone.

229    In 2021, around 3.5 million of the smartphones sold in Australia were iPhones, which amounted to a 48% share of all smartphones sold in Australia, and over 1.2 million of the tablets sold in Australia were iPads, which amounted to a 64% share of all tablets sold in Australia.

230    Let me now go back into the history in a little more detail.

231    In 2007, Apple released the iPhone. It comprised three products in a single device, being a widescreen music player, a smart phone with touch controls, rather than a keyboard, and an internet communications device capable of various functions including email and web browsing. iPhone, and its continued success to date, are the product of historical and ongoing investment in research and development by Apple.

232    In 2008, Apple launched the App Store. The App Store is a two-sided transaction platform. It exists to facilitate transactions between developers of apps and app users. The App Store is also the product of significant past and continuing investment by Apple in research and development.

233    To provide developers with the ability to build apps for the App Store, Apple developed a suite of technology and tools, including software development kits (SDKs) that allow third-parties to develop software capable of functioning on iOS. Apple regularly updates its technology and tools, including to enable developers to use the newest features of its iOS devices.

234    Now smartphones hold sensitive information of their users. They may hold, for example, digital drivers’ licenses, health information, real time location data, personal contact details, personal photos, mobile keys for a place of business and authentication tokens.

235    The App Store has protections so that app users and developers can transact in that environment with confidence that the App Store and the apps available through it are compatible with high standards of security and privacy.

236    Apple allocates significant resources to the security and privacy of iOS. It has pioneered improved security measures including biometric security. It has differentiated itself from competitors based on security and privacy.

237    I should say that all of the experts who participated in the security and technology conclave agree that there are wide and varied threats to mobile systems.

238    There are over 1 billion active iOS users who are almost constantly connected to the internet, who frequently download apps and engage in transactions involving financial or personal health data. Further, they frequently utilise their iOS device’s camera, microphone and GPS hardware.

239    For Apple, security means protecting app users’ data, protecting their control over their devices, and making sure that what happens on the device is what the user intended and is not the result of manipulation by a bad actor. Security encompasses ensuring the safety, integrity and reliability of Apple’s products, detecting and preventing malware and social engineering schemes, incorporating safeguards to ensure the user knows what is happening on their device and to protect the user’s data even in the event that a bad actor tries to target them.

240    To protect iOS device users’ security and privacy, Apple adopts an approach referred to as defence in depth. This is an approach to security and privacy which is designed and implemented as multi-layered security architecture, to ensure that even if one layer is temporarily circumvented, there are multiple other layers of security to protect the user against malicious threats. The sophistication of the defences is a response to the sophistication of the threats. Defence in depth substantially increases the chance that an attack would be economically unviable for attackers because the work required to defeat each layer of Apple’s security increases the cost and effort to mount and maintain a successful attack. It was not in dispute that security on mobile devices should be guided by the principle of defence in depth.

241    iOS device security integrates hardware protections including biometric protections. It integrates software and operating systems security including the “sandboxing” of apps such that their operating systems access is limited to that which is appropriate and necessary for the intended performance of the app. And it includes app review with both automated and human stages.

242    The purpose of app review is to hold apps to clear, published and high standards for privacy, security, reliability and safety. App Store review guidelines require that apps not be offensive, unsafe or risk physical harm, that they not contain hidden, dormant or undocumented features or request too much information or information irrelevant to their core functionality. The App Store review guidelines provide additional protections in apps designed for children, require information transparency and the handling of personal data in a way that complies with applicable privacy laws and privacy policies and prohibit apps from manipulating, tricking or forcing people to consent to unnecessary data access. App review is a continuing process. It applies both before and after app distribution through the App Store in an effort to determine that apps available through the App Store are safe and trustworthy.

243    According to Apple, centralised app distribution through the App Store ensures that a user obtains native apps from a trusted source and are subject to automated and human review, and facilitates the swift and comprehensive removal of malicious apps. Apps found to be malicious or unreliable are removed from the App Store.

244    In 2021, Apple terminated over 802,000 developer accounts over fraud concerns, prevented more than 3.3 million stolen credit and debit cards from being using to purchase goods and services and protected app users from more than $1.5 billion in potentially fraudulent transactions. Apple was in a position to do so because it monitors all transactions across the App Store using sophisticated proprietary computer technology and human review.

245    Further, Apple has always conspicuously sought to differentiate itself in the markets in which it competes by its ability to provide app users with a product which is safe and secure. Apple's privacy and security features are in fact a key aspect of inter-brand competition with other platforms like Windows PCs and Android devices. Apple’s focus is upon providing app users with a device which they can trust as a repository of highly sensitive personal information, and which will perform in the way users expect.

246    Apple says that the features of iOS are features by which Apple differentiates its products and competes with other smartphone suppliers and transaction platforms.

247    Now Apple accepts that alternative models or rules are possible for security. But it says that they are inconsistent with Apple’s consumer offering and its foundational principles of security and privacy for app users.

248    Now in the EU, Apple has been compelled under the Digital Markets Act to facilitate the downloading onto iOS devices of third-party app stores. It will also be compelled to allow third-party developers the option of using alternative payment processing systems for such transactions. Apple says that, despite the additional efforts it will go to in order to protect the privacy and security of European iOS device users, these changes will place European iOS users in a heightened risk environment. They will also enjoy diminished services. I will deal with these assertions later. Let me return to some general matters.

249    Apple has also differentiated itself from other products based on a superior user experience. One aspect of the superior user experience is that app users and developers can transact securely and conveniently using Apple’s IAP. IAP provides app users with a range of benefits including a centralised, convenient way for them to transact with any developer on the App Store whilst only providing their billing details to Apple once. IAP also provides verification that digital in-app purchases are delivered, fraud detection tools, parental controls and payment support and refund services. Developers gain flexibility, through IAP, to monetise their apps in a range of ways. They avoid the administrative burden of receiving payments from customers and converting currency for the 175 countries in which the App Store operates. And they obtain both routine and customised business analytics.

250    Apple’s IAP includes a range of features and services beyond payment processing to deliver an enhanced experience and suite of services to both app users and developers. This includes a centralised and convenient payment system, Apple security features, currency conversion, management of customer support and refunds, a record of transactions, and services to develop, test, market, distribute and monetise developers’ apps and to maximise consumer engagement.

251    Let me say something about the history of the App Store itself. Since its introduction, 37.6 million developers have registered with Apple. Around 657 million people visit the App Store each week worldwide. The number of apps on the App Store has increased from 500 in 2008 to over 1.8 million apps. These are global figures. In Australia, more than 99.99% of apps on the Australian storefront are developed by third-party developers. The number of app downloads has increased from 145 million in 2008 to 32 billion in 2014 globally.

252    As I have discussed earlier, apps can be designed to run on a specific OS, being native apps, or inside a webpage, accessed through a browser, such that they are platform agnostic, being web apps.

253    When the iPhone was first launched in 2007, it was sold with several native apps pre-installed, all of which were developed by Apple. At that time, native apps developed by third-parties were not permitted to be downloaded to the iPhone, but third-party web apps could be accessed. In March 2008, Apple removed its prohibition of third-party native apps, and launched the first SDK which made it possible for third-parties to develop native apps for iOS. On 10 July 2008, Apple launched the App Store, which it continues to operate.

254    App stores have certain typical features. They are themselves apps which connect to the internet and facilitate the installation of additional apps onto a device. They contain a catalogue of apps that can be searched using keywords or other criteria, and can also be browsed, often via lists sorted by name, developer, category, or other characteristics. They allow users to review and rate apps for the benefit of other users. Once a user selects an app and authorises its installation, which may require payment, the selected app is transferred to the user’s device, verified, and then installed. And they facilitate the maintenance and updating of installed apps.

255    The App Store is a native app that is pre-installed on all iOS devices. The App Store distributes iOS apps, being native apps written for iOS, to iOS device users. From its inception, the App Store has been and remains the exclusive platform by which iOS apps are distributed. Apple does not permit any other app stores to be distributed on iOS devices.

256    The App Store has country-specific storefronts where prices are shown in the local currency and users find apps of relevance to that country. More than 1.5 million different iOS apps are available for download from the App Store’s Australian storefront. The App Store has a search function that enables users to search for and download apps, and developers are able to pay for an advertisement to be displayed above particular search results.

257    In connection with the App Store, Apple has developed and operates App Store Connect, which is a portal through which third-party app developers upload, submit, and manage their apps for distribution on the App Store.

258    Apple makes an app store available on macOS devices, being the macOS App Store. But in contrast to iOS devices, the macOS App Store is not the only way to distribute apps on macOS devices. MacOS users can also download software onto their devices from external sources, such as from websites, or by developing and running their own software directly within macOS. Given the open nature of app distribution on macOS devices, Apple deploys a number of security protections. These include a technology known as Gatekeeper which, among other things, checks all downloaded software for malware, and a built-in antivirus technology known as XProtect, which automatically detects and blocks known malware. Both Gatekeeper and XProtect apply to all apps on the macOS platform, whether they come from the macOS App Store or not. Since around 2019, Apple has also required that all apps distributed to macOS devices outside the macOS App Store be signed by the developer using an Apple-issued developer ID certificate and notarised by Apple. Notarization is a process whereby third-party apps are submitting to Apple for various automated scans, including for malware.

259    Now when the App Store was first launched, apps were either free, or could be downloaded for a one-off initial fee, but it was not possible to purchase digital content or services within an app after it had been downloaded from the App Store.

260    In March 2009, Apple introduced IAP to the App Store. IAP facilitates in-app purchases of digital goods or services, including subscriptions. It provides for the acceptance and collection of payments from users via a range of payment methods, the payment of refunds to users and the payment of commissions to Apple with the remaining balance to app developers. Further, through IAP, users can view their purchase histories, cancel subscriptions, and use parental controls.

261    Generally speaking, IAP includes one-click purchasing, a payment gateway, fraud mitigation systems, payment processing services and technical integrations.

262    Apple requires third-party app developers to use IAP for in-app purchases of digital goods and services subject to limited exceptions. But no such requirement applies to apps that provide for the purchase of non-digital goods and services. Developers of those apps are free to choose their own payment solutions.

263    Let me now turn to another topic concerning some aspects of technology and intellectual property. Of course I will discuss this in more detail later in my reasons.

264    Apple Inc has a large intellectual property portfolio and a loyal customer base. Between FY 2005 and FY 2022, Apple spent more than USD 149 billion on research and development, with the annual figure growing from approximately USD 0.5 billion in FY 2005 to almost USD 26.3 billion in FY 2022. This has resulted in the development of a substantial intellectual property portfolio and a large customer base.

265    For example, as at March 2023, Apple was listed as the registered owner of more than 24,000 US utility patents and a further 4,000 US utility patent applications, 3,500 US design patents, 5,000 US copyright registrations, 1,500 Australian patents and a further 700 Australian patent applications, and 700 Australian registered designs.

266    Apple’s brand is consistently recognised as one of the more valuable brands in the world.

267    As I have already said, when the iPhone launched in 2007, it was sold with several native apps installed on the device, all of which were developed by Apple. Third-party developers could not build or distribute native iPhone apps, which are downloaded to the device. They could make web apps, which operate via an internet browser, for iPhones and they can still do so today. More than 97% of iPhone users access web apps.

268    In October 2007, Apple announced it would develop an SDK to make it possible for third-party developers to develop apps for the iPhone.

269    Apple’s software engineering teams spent the next five months creating and documenting application programming interfaces (APIs) and other components of the SDK and ensuring that the SDK would work on a new platform that Apple built for developers.

270    An API is a software intermediary that enables developers to make use of the iPhone’s many features.

271    These were made available with other software tools, including the Xcode integrated development environment, to help developers build, debug and test their apps.

272    In addition to this technical challenge, the associated defence in depth protective measures involving app review of every app and app update to guard against a unique threat model were developed and implemented to ensure that App Store was a safe platform that developers and app users alike would trust. I will discuss Apple’s defence in depth approach later.

273    As iOS and iOS devices became more sophisticated, so did the technology and tools that Apple licenses to developers to allow them to make iOS apps. The development of apps expanded to other Apple devices, including the iPad and Apple Watch.

274    There are 37.6 million developers registered with Apple. To register, developers must execute the Apple developer agreement. There is no fee for doing so. Registering allows developers to access Apple’s online developer portal and registered developers may receive benefits such as invitations to conferences and other events, access to pre-release hardware or software to develop interoperable products, and access to certain types of technical support.

275    In order to access Apple’s SDKs and other software development tools, and to submit apps for review and potential distribution through the App Store, developers must execute the DPLA and pay an annual program fee of USD 99.

276    Under the terms of the developer agreement, the DPLA and the related App Store review guidelines, and the technical and contractual enforcement by Apple of those terms, Apple chooses to license its software and thereby facilitate exploitation of its intellectual property, via third-party apps developed for distribution on the App Store. Those are the terms which millions of developers have chosen to accept, to the profit of many developers.

277    Now Apple says that in circumstances where Apple enjoys exclusive intellectual property rights, the allegation that certain terms are anti-competitive must be seen in the context of the licensing arrangement as a whole and its many pro-competitive benefits.

278    Finally, let me make another point here concerning whether the relevant provisions of the CCA apply to Apple Inc.

279    Now although this was initially the subject of contest, by the end of the trial Apple accepted that the relevant provisions of the CCA apply to Apple Inc. This was an appropriate concession to make given that Apple Inc carries on business within Australia for the purposes of s 5(1)(g) of the CCA. Apple Inc has entered into a direct contractual relationship with some [REDACTED] or more Australian consumers, as well as a direct contractual relationship with over 30,000 Australia-based app developers. Apple also operates the App Store in Australia through its Australian subsidiary, Apple Pty Ltd. The relevant provisions therefore apply to its conduct outside Australia.

280    Further, having regard to the nature of the allegations made, the markets at issue and the parties with whom Apple Inc contracts, the impugned conduct was engaged in by Apple Inc within Australia.

281    Further, by operation of s 5(2) of the CCA, s 47 applies to any of the impugned conduct engaged in by Apple Inc outside Australia in relation to its supply to app developers within Australia of services for the distribution of iOS apps. I might add here that this statutory extension is of little moment in the present context given my ultimate findings concerning s 47 that I have discussed towards the end of these reasons.

Apple’s relationship with app developers and IAP

282    Let me say something about the relationship between Apple Inc and App Store app developers and in that context make some brief observations concerning the developer agreement, the DPLA and the App Store review guidelines. I have a more developed discussion of the contractual matrix in a separate section of my reasons.

283    The developer agreement governs foundational elements of the relationship between Apple and developers. For example, it contains terms regarding confidentiality and trade mark use. It also provides that Apple may terminate a developer’s registration, and refuse a re-application, in its sole discretion.

284    The DPLA licenses the Apple software for the sole purpose of developing and testing apps and certain other types of software; see clause 2.1(a) and clause 1.2, definition of “Covered Products”; certain related acts are also licensed in clause 1.2, such as distribution of technical documentation. The Apple software includes the following items.

285    First, the software includes iOS, which I have already described.

286    Second, the software encompasses more than 250,000 APIs and includes 150,000 APIs for iOS and other APIs to support developers building apps for iOS, macOS and other Apple OS. Many SDKs or APIs are for particular features of iPhone, iOS or other aspects of the Apple ecosystem such as the MapKit API for Apple Maps, SiriKit for the iOS voice-activated assistant “Siri”, and the CloudKit APIs for iCloud data storage. SDKs and APIs particularly relevant to game developers include Metal, a powerful computer graphics API, and GameKit, which provides integration with Apple’s Game Centre social-network gaming features.

287    Third, the software includes the Xcode IDE, which is a software development tool that reduces the time and resources needed to develop an App.

288    Fourth, the software includes TestFlight, which is software that allows developers to conduct beta testing of their apps, by making them available to up to 10,000 external testers, prior to launch.

289    It was not in dispute that in developing Fortnite, Epic used the Xcode IDE, TestFlight, Metal, GameKit, numerous other SDKs and a significant number of Apple APIs, although the existence and extent of any copyright protection in Apple’s favour was contentious. I will address this later to the extent necessary. It should also be noted that even absent any copyright, some of this software and related material likely contained Apple’s confidential information and may have been protected under contractual or equitable duties of confidence enforceable against Epic.

290    Now developers have a choice as to the payment model they adopt to monetise their apps.

291    If the app is to be made available for free and without any in-app purchases, the developer is bound by schedule 1 of the DPLA. If the app is monetised via other means, such as advertising or the sale of physical goods or services, schedule 1 still applies and Apple’s commission from those sales is zero.

292    If a developer chooses to require a payment to download the app or for in-app purchases of digital goods and services including subscriptions, then schedule 2 of the DPLA applies. The developer elects which country-specific App Store storefronts will be used for distribution.

293    Under both schedules 1 and 2, the developer appoints Apple Inc and another Apple entity, in this case Apple Pty Ltd, collectively as the developer’s agent for the marketing and delivery of their apps in each of their selected App Store storefronts. I should note here that Apple Pty Ltd is not formally a contracting party to the DPLA notwithstanding any schedule 2 references to it.

294    These agreements are standard for all developers. Apple seeks to justify this at least as a matter of practicality. There are presently more than a million developers that are entitled to submit apps for review and potential inclusion on the App Store, including more than 120,000 that are monetising their apps via paid digital transactions.

295    Further, Apple says that where one party contracts with multiple counter-parties, including by way of an agency agreement, there is nothing unconscionable about the use of a standard form, take-it-or-leave-it agreement. It has prayed in aid what I said in AHG WA (2015) Pty Ltd v Mercedes-Benz Australia/Pacific Pty Ltd [2023] FCA 1022; (2023) 303 FCR 479; (2023) 170 ACSR 1 at [230] to [259]; see also the appeal from my decision which was dismissed by Moshinsky, Bromwich and Anderson JJ in AHG WA (2015) Pty Ltd v Mercedes-Benz Australia/Pacific Pty Ltd [2025] FCAFC 86, particularly at [101] to [144]. I would also note that nothing in Productivity Partners Pty Ltd v Australian Competition and Consumer Commission (2024) 419 ALR 30 casts doubt on that proposition.

296    Now schedule 2 provides for Apple to be paid a headline 30% commission for all sales of apps and any digital content, functionality or service offered in the app. But all but 19 of Australia’s 30,000 registered developers are entitled to a discounted commission rate of 15%. This commission rate applies only to sales for real world currency.

297    For example, transactions within the Fortnite app involving the exchange of V-Bucks for digital content did not attract any commission for Apple. Such transactions occur entirely within Epic’s systems.

298    Apple says that its commission is the mechanism by which developers compensate Apple for the value provided including, so Apple says, their use of Apple’s tools, software and proprietary technology, and for the range of ongoing services Apple provides to developers to help them develop, test, market, distribute and monetise their apps via the App Store using Apple’s proprietary technology. Apple says that the commission also allows it to realise a return on its investment in the App Store and to fund further innovation across the Apple ecosystem.

299    Now Epic says that the commission payable under the DPLA is not a fee to use or license Apple’s intellectual property, including because schedule 2 states that the commission is payable in consideration of services provided by Apple or its subsidiaries as agents or commissaires. In the case of Australia, the agent is Apple Pty Ltd.

300    But contrastingly, Apple says that it licenses the use of the Apple software on the whole of the terms of the DPLA, including the developer’s agreement that, if their app is accepted for distribution via the App Store and they intend to charge a fee for the app, or for in-app content, schedule 2 will apply and Apple will receive the relevant commission.

301    The question of characterisation of the commission payable and whether it should be seen in whole or in part as a licence fee for the use of intellectual property rights is a contentious issue between the parties. I will return to this question later in my reasons.

302    The DPLA provides that an application may not create a store for other apps, and subject to limited exceptions prohibits the installation of software by a user onto a device directly from external third-party sources other than the App Store, that is, it prevents sideloading. This requirement is reinforced by the App Store review guidelines.

303    Apple says that it goes to extensive lengths to preserve the security and privacy of the App Store and to ensure that apps available in the App Store are functional, perform as claimed, are safe and otherwise appropriate for app users. It says that if an app can itself operate as an app store, those efforts can be circumvented. So, too, can developers easily bypass their payment obligations under the DPLA. Similar requirements are imposed by other platform operators, such as game console manufacturers.

304    Let me now say something about the App Store review guidelines.

305    The DPLA provides that, by submitting an application for consideration for distribution via the App Store, the developer warrants that the application complies with all requirements specified by Apple and any additional guidelines that Apple may post to the developer portal or App Store Connect, which is a platform used by developers to submit their apps for review. Apple may remove apps from the App Store at any time where the developer has breached the App Store review guidelines.

306    The App Store review guidelines address issues such as objectionable content, child protection, privacy, regulatory compliance and app functionality.

307    Now the App Store review guidelines require most types of apps that offer in-app purchases of digital content to use Apple’s IAP system. But they also allow developers to request app users’ email addresses and to send communications outside the app to their user base about purchasing methods other than IAP.

308    IAP is an integral part of the App Store's “commerce engine”. It is a secure and centralised system for simultaneous transactions in which digital content is delivered, payment is transferred, sales are recorded and commission is collected in respect of apps that developers monetise through downloads or in-app purchases. IAP enables Apple to readily collect commissions which developers are independently contractually obliged to pay, in return for the significant Apple value that Apple provides to developers. By contrast, and as Apple would see it, external payment mechanisms enable developers to circumvent payment of commissions, while having already enjoyed the benefits provided to them by Apple.

309    IAP did not exist prior to the App Store. As I have said, it was introduced in March 2009 in response to feedback from developers wishing to monetise the in-app delivery of content after the downloading of the app from the App Store.

310    IAP provides many benefits to app users and developers. It records sales, manages payments, provides routine and customised business analytics, handles conversions to 44 currencies using nearly 200 different payment methods, ensures compliance with local tax laws, provides customer support for in-app transaction issues, provides fraud protection measures, protects user information, allows app users to view their purchase histories, manage their purchases and subscriptions in one place, cancel subscriptions, seek refunds and use parental controls to prevent children from making unauthorised transactions, amongst other benefits.

311    IAP also provides extensive security benefits to protect app users.

312    Apple’s app review team investigates the app’s IAP offering to determine whether the transactions will actually result in the delivery of the expected content, whether the purchased content is consistent with the overall app, and whether the transaction may have other characteristics that could mark it as a scam or mislead users.

313    IAP allows app users to transact using the payment details linked to their Apple ID account. There is no need for the user to provide payment details directly to each developer. Payments using the user’s chosen payment method are processed using Apple’s biometric security mechanisms and two-factor authentication. This arrangement provides a mechanism that allows Apple to confirm that users who purchase digital goods or services in an app receive what they paid for, at the actual terms that they agreed to pay, and in a secure manner that protects against fraud and theft of their personal information.

314    Apple uses machine learning models to predict trends in transactions and relies on information collected by IAP to identify potentially fraudulent transactions. Anti-fraud technology detects and protects against use of stolen cards in IAP purchases. IAP protections prevent exploitations of app users, such as apps that attempt to defraud or maliciously change pricing information in apps. App users’ payment methods and payment details are stored in a tamper resistant hardware security module on a service to which even Apple employees do not have access.

315    IAP is not a mere payment processing service. Further, Apple does not itself process payments, rather it contracts with third-party payment processors to facilitate customer payments through IAP. The App Store commission includes the cost to Apple for third-party payment processing services.

316    IAP allows developers to make four types of transactions available within their apps.

317    First, there are transactions to acquire consumable content, being content that depletes as it is consumed by the user such as purchases of the Fortnite currency V-Bucks.

318    Second, there are transactions to acquire non-consumable content, such as premium app features that do not expire.

319    Third, there are transactions for auto-renewing subscriptions, being subscription content that app users are charged for on a recurring basis until they elect to cancel.

320    Fourth, there are transactions for non-renewing subscriptions, which provide for a user to access content for a limited time.

Epic’s allegations concerning Apple’s so-called restrictive terms

321    Now as I will set out in more detail later, Epic’s key complaints are the following. First, Apple does not allow an app distributed via the App Store to itself function as an app store. Second, Apple does not allow native apps to be downloaded to iOS devices, other than via the App Store. So, it prevents sideloading. Third, Apple requires native apps to use IAP for in-app purchases of digital content. Fourth, paid apps and in-app purchases, including subscriptions, may be subject to commission being either 15% or 30%.

322    Now Apple says that these rules only apply to developers who wish to use the Apple software to develop and the App Store to distribute to iOS devices a particular type of app, namely a native app.

323    Developers who do not wish to use the Apple software to develop and the App Store to distribute their apps can still develop and distribute apps for iOS devices as web apps, without entering into the agreements referred to above. Web apps can be accessed in the same way as native apps, that is, by tapping on an icon on the iOS device’s home screen.

324    Further, the rules concerning commissions and the use of IAP only become relevant where a developer chooses to monetise a native iOS app in a particular way, by selling the app or digital in-app content.

325    Freely distributed apps with no in-app purchases of digital content operate without commission and without use of IAP. Such apps can be monetised through in-app advertising or the sale of physical goods or services, in respect of which no commission is payable.

326    Now Epic says that the so-called restrictive terms are imposed jointly by Apple Inc and Apple Pty Ltd. But I agree with Apple that the DPLA is an agreement between Apple Inc and the developer. The DPLA requires the developer to adhere to the App Store review guidelines and schedule 2 to the DPLA. Plainly, the so-called restrictive terms are terms imposed by Apple Inc and not by Apple Pty Ltd.

How does Apple monetise the App Store? How do developers monetise their apps?

327    Developers choose whether and how to monetise their apps in the App Store. They are not obliged to do so. Only developers who choose to charge for app downloads or in-app purchases of digital content for apps in the App Store are liable to pay a commission to Apple.

328    Commission is not payable for free or ad-funded apps, sales of physical goods and services, or digital content purchased outside of the App Store but accessed in the app downloaded from the App Store pursuant to the reader rule or multi-platform rule.

329    In 2020 alone, for example, developers generated USD 46 billion from in-app advertising in the App Store, and USD 511 billion from sale of physical goods and services via iOS apps.

330    In 2021, more than 85% of apps on the Australian storefront were free to download and did not have any in-app purchases. In 2022, the equivalent figure was 78%.

331    So, no commission was payable by developers on those apps. The only fee they paid was the annual program fee of USD 99.

332    Developers who charge for app downloads or in-app purchases choose from a broad range of price points in the price matrix made available by Apple. As at 7 December 2022, developers could choose from 900 price points between $0.39 and $17,999.99. They could also change their price point at any time, at their discretion, in accordance with the price matrix; see schedule 2, clause 3.1 of the DPLA.

333    Payments for purchases made on the Australian storefront are processed through Apple’s IAP and paid to Apple Pty Ltd, which retains a commission and remits the remainder to the developer.

334    When the App Store was launched in 2008, Apple charged 30% for paid apps. That rate was consistent with the headline commission charged by other digital game app transaction platforms, including Steam. Handango, an online store for apps which could be downloaded for devices such as Blackberry, Palm Pilot, also charged 30% commission. And the App Store’s 30% commission was less than the prevailing charge for software on physical media which ran as high as 70%. Since 2008, the commission rate for paid apps and in-app purchases on the App Store has not increased, but has instead decreased markedly as explained below.

335    In 2011, Apple introduced the reader rule which removed developers’ obligations to pay any commission for app users to access digital content viewed on iOS devices but purchased elsewhere, for example, for magazines, newspapers, books, audio, music and video.

336    Since 2016, for apps that offer auto-renewing in app-purchase subscriptions, commissions on renewals after the first year have been reduced from 30% to 15%. Subscriptions in existence for more than a year were automatically transferred to the lower 15% rate.

337    In 2016, Apple also reduced the commission for video apps as part of its video partner program. Apps that deliver premium subscription video entertainment services which integrate with certain Apple technologies, which has the benefit of ensuring a seamless experience for customers, pay a 15% commission for in app-purchases of subscriptions.

338    In 2018, Apple introduced the multi-platform rule. That is a rule which benefits developers who operate across multiple platforms. App users may, on iOS devices, access content, subscriptions and features they have acquired on other platforms or from developers’ websites without the developer paying any commission to Apple, provided that those items able to be acquired elsewhere are also available as in-app purchases within the app on the App Store. Apple does not receive any commission on such content purchased on a non-iOS platform. Nor does Apple require price parity between platforms. Epic, in particular, benefited from the multi-platform rule, since it enables cross-wallet play in Fortnite.

339    Since 1 January 2021, under the small business program, developers whose aggregate revenue from paid apps and in-app purchases does not exceed USD 1 million per annum have been eligible to enrol and thereby pay a 15% commission rate.

340    Later in 2021, Apple introduced the news partner program under which it decreased commission rates to 15% for subscription news publications that provide their content to Apple News in Apple News format.

What benefits does Apple provide to app developers?

341    Apple has provided the following description of the benefits that it provides to app developers, which I generally accept subject to excising laudatory intensifiers.

342    The App Store provides developers the option of a secure, trusted and accessible marketplace for immediate global exposure of their apps to over one billion iOS users in 175 countries and in over 40 languages. Approximately 657 million people visit the App Store each week.

343    Running the App Store is a substantial undertaking. Apple spends billions of dollars to develop and maintain the App Store, including hundreds of millions of dollars employing engineers.

344    First, developers may access Apple software, including SDKs and others tools, which are regularly updated with improved features, to build, debug and optimise native apps.

345    Second, Apple provides services to developers including management of customer enquiries, support for billing issues, troubleshooting and refund requests. Apple has around 5,000 employees in its AppleCare support team to respond to refund enquiries.

346    Third, Apple continuously improves the storefront interface and capabilities of the App Store.

347    Fourth, developers can provide app updates, for example, to add new functions or fix technical issues, to app users for free, and app uses are automatically notified when the updates are available.

348    Fifth, the App Store has a global marketing team to drive discovery and engagement, and Apple provides marketing, editorial and promotional support to attract new app users.

349    Sixth, Apple advises app developers on how to improve their products and grow their business.

350    Seventh, Apple provides assistance to developers to navigate foreign tax systems, calculate tax liabilities, collect and remit sales taxes to relevant tax authorities on their behalf.

351    Eighth, Apple provides tools and training provided by Apple to aspiring entrepreneurs, developers and designers though its Apple developer academy programs.

352    Ninth, Apple hosts events such as worldwide developer conferences at which developers have access to information about app development and assistance from Apple.

353    Apple Pty Ltd regularly assists Australian developers.

354    Now Apple allows developers to choose their preferred method, at any given time, for monetising or not monetising the apps they develop for distribution through the App Store. There are five business models by which developers may distribute their apps on the App Store. These business models are described on Apple's developer portal and are free, freemium, subscription, paid and paymium.

355    The subscription model is a monetising strategy of increasing prominence. The flexibility afforded to developers in relation to subscription services serves in turn to improve the functionality of apps, which helps developers attract and retain users. The broader network effects serve to advance the interests of developers, users and Apple.

356    Developers have considerable flexibility in determining the terms on which subscriptions are offered, by taking advantage of functionality facilitated by Apple’s software.

357    Apple enables developers to offer multiple subscriptions with different access levels to content, different prices and different durations so that users can select between them.

358    Developers have the option of presenting the benefits of subscription during the onboarding process, that is, when users first launch the app. This serves to highlight the value of the subscription and attract subscribers. As I have indicated, developers may offer an app experience, which allows the user to use the app at no cost, with the option to subscribe if they want to enhance their experience or engage more deeply.

359    Developers may choose to offer either or both auto-renewable and non-renewing subscriptions. Where auto-renewal is not operating, developers are able to display a promotional offer for one month free subscription in order to help them retain subscribers.

360    Apple enables developers to give users a free or discounted price for a specific duration for auto-renewable subscriptions.

361    Developers may provide introductory and promotional subscription offers, and also offer codes which operate as a form of discount coupon for subscriptions.

362    Apple makes available a range of tools to help developers manage existing subscriptions, gain new subscribers and retain existing subscribers. These include the following.

363    Developers may send push notifications to app users to market content.

364    Apple provides tools to manage relationships with subscribers which can lead to improved engagement, higher retention and better ratings and reviews. These include enabling subscribers to manage their subscriptions in-app, extend a subscription’s renewal date, determine a subscriber status which can be used to inform the developer’s retention strategy and provide subscribers with relevant information within the app.

365    Developers can determine if a subscriber has turned off auto-renew for a particular subscription and take action, for example, present a promotional offer or suggest an alternative offering that better fits the subscriber’s needs.

366    Apple offers tools to prompt subscribers to update their payment details if a subscription lapses or a subscription does not successfully renew and it offers tools to track whether subscribers have consented to an increase in price and messaging subscribers in the event that they do not.

367    Further, users are able to switch between or renew their subscriptions in-app.

368    Users who subscribe to app content are also able to share access to their subscriptions with up to five family members across their Apple devices.

369    In the event of a failed subscription renewal, Apple attempts to recover the failure for 60 days. Developers may effectively extend subscription periods by enabling grace periods of 3, 16 or 28 days so subscribers can retain access to subscription content or pause the subscription while the renewal is outstanding.

370    Developers may manage prices for their subscriptions by increasing or decreasing them in some circumstances. Apple permits developers to schedule price changes for their apps, for example, setting a promotional price for a month before returning to the regular price, change prices for a pre-set period, or using promotional offers and offer codes.

371    Apple provides all developers with a range of data about their subscriptions to allow developers to manage and refine their subscription strategy. This includes anonymised individual subscription data in subscription reports.

372    It is now appropriate to say something briefly about Google, although I will have a little more to say in my reasons in Epic v Google as well as later in these reasons.

Google entities and background facts

373    Google LLC is incorporated in Delaware, USA and its ultimate holding company is Alphabet Inc, which is also incorporated in Delaware. Google LLC is headquartered in California, USA.

374    For public financial reporting purposes, Google LLC is divided into two segments being Google Services and Google Cloud. The core products and platforms which comprise Google Services include ads, Android, Chrome, Hardware, Gmail, Google Drive, Google Maps, Google Photos, the Play Store, Search, and YouTube.

375    In the year ending 31 December 2021, Google Services’ revenues exceeded USD 237.5 billion and Google Services’ operating income exceeded USD 91.8 billion.

376    In terms of Google’s contractual relationship with app developers the following may be noted.

377    The developer distribution agreement (DDA) provides that it is an agreement between the app developer and the applicable Google entity based on where the developer has selected to distribute its apps.

378    In the present context the applicable Google entity is Google Asia Pacific Pte Ltd in relation to apps distributed through the Play Store in Australia. Consequently, a developer that distributes apps through the Play Store in Australia and in the USA enters into the DDA with both Google Asia Pacific Pte Ltd and Google LLC. Google Asia Pacific Pte Ltd is incorporated in Singapore and its ultimate holding company is also Alphabet Inc.

379    Further, Google Asia Pacific Pte Ltd is a party to a payment processing service agreement with Google Payment Australia Pty Ltd. The latter is incorporated in Australia and is a subsidiary of Google LLC; its ultimate holding company is also Alphabet Inc. Google Payment Australia Pty Ltd is also the holder of an Australian financial services licence.

380    By the payment processing services agreement, Google Payment Australia Pty Ltd has undertaken to perform payment processing functions and services, as directed by Google Asia Pacific Pte Ltd. In addition, Google Payment Australia Pty Ltd enters into arrangements with users of the Google Payments Service who register for that service online. The terms of those arrangements are set out in a product disclosure statement issued by Google Payment Australia Pty Ltd.

381    Let me say something about Google Mobile Services (GMS), which in one sense runs on top of open source Android and is necessary for a number of key operating system features not available in open source Android alone.

382    GMS includes key modules, which are APIs and SDKs collectively known as Google Play Services, which enable core functionality for the device and for many apps and services. Android devices which do not also have GMS installed cannot access Google Play Services and are significantly functionally limited as a result. One limitation is that, if app developers build apps using Google Play Services APIs or SDKs, those apps become dependent on GMS and will only run as intended on devices that have GMS installed.

383    So, by using Google Play Services, app developers can design their app to make use of Google Maps functionality, such as features that respond contextually to a user’s location, via specific Google Play Services APIs. But if such an app is installed on a device that lacks GMS, the app will not have that functionality. Many popular apps, such as Facebook, YouTube, WhatsApp, Gmail, Twitter, Netflix, Uber, Pokemon Go, Slack, and CommBank cannot be run on an Android device that does not have GMS installed.

384    GMS also includes apps developed by Google. Among them are the core applications, being the Play Store, Search, Chrome, Google Maps, Gmail and YouTube. The remaining five core applications were among the top six apps by usage in the Play Store, as of April 2023. GMS also includes “Flexible Applications”. These differ between territories and, in Australia, consist of Drive, YouTube Music, Play Movies, Duo and Photos.

385    Google’s GMS apps are pre-installed, under the terms of the mobile application distribution agreements (MADAs), on virtually all Android smart mobile devices sold outside of China. Both in Australia and globally excluding China, over 99.9% of smart mobile devices which utilise a licensed OS are GMS Android devices. From 2018 to 2021, approximately 4 million smartphones were sold in Australia each year with GMS and of course the Android OS pre-installed. Globally excluding China, approximately 800 million smartphones were sold each year with GMS and the Android OS pre-installed.

386    Google LLC licenses OEMs to distribute GMS on their Android devices in accordance with the terms of the relevant MADA. In doing so, more users are introduced to the GMS apps, which include Google Search and the Play Store, and therefore more advertising revenues are derived by Google. The greater the number of OEMs distributing GMS devices, the greater the number of users of those devices, and the larger the audience for Google’s services. The calculation that Android would drive users toward Google’s proprietary products has proven correct. Google makes most of its money selling advertising on Google Search and a considerable amount from the Play Store.

387    The Play Store is an app store. It is owned and was developed by Google LLC. It was originally known as Android Market, which launched in 2008 in the United States and in 2009 in Australia, before being rebadged as the Play Store in 2012.

388    The Play Store distributes Android native apps to Android devices. Through the Play Store, users can search or browse for apps developed by Google or third-parties, and then download and install such apps onto their devices. There are approximately 3 million apps available to users in Australia for download on the Play Store. Users can discover apps within the Play Store using the search function, and recommended apps are presented to users based on their search and download history. The Play Store also facilitates app updates.

389    The Play Store remains the principal distribution point for Android apps.

390    Now if an app developer wishes to distribute its app via the Play Store, the developer must enter into a DDA as I have referred to earlier.

391    With limited exceptions, app developers who wish to distribute their apps via the Play Store are required to use solely Google Play Billing to facilitate in-app purchases of digital content. Among other things, Google Play Billing enables the facilitation of payments from users in many countries, via a range of payment methods. Google charges developers a fee of up to 30% of the price of in-app purchases made through Google Play Billing.

392    Google Play Billing can only be used on native Android apps that are downloaded from the Play Store and installed on Android devices. Google Play Billing cannot be used on non-native Android apps, apps on other operating systems, or in-store or online. Google Play Billing operates on one-platform through one-channel. Despite that, as at July 2020 Google’s own documents indicated that approximately 200,000 apps were being monetised through the use of Google Play Billing, and that those apps had been installed nearly 36 billion times.

393    As of October 2022, there were more than 400,000 apps on the Play Store, covering more than 170,000 developers, which had been monetised by the use of Google Play Billing.

394    I have said something more about the Google entities and their conduct in my reasons in the Epic v Google proceeding.

Epic’s pleading — Apple’s conduct and the pleaded markets

395    Let me now say something more about Epic’s case concerning Apple’s impugned conduct and how it puts its case in this respect, although I have briefly canvassed this earlier. It is important to be clear about this before addressing the pleaded markets.

Apple’s alleged conduct in respect of iOS app distribution

396    Now Epic has made the following allegations concerning Apple’s conduct in respect of iOS app distribution, aspects of which I have briefly canvassed earlier.

397    Apple Inc and Apple Pty Ltd have each engaged, and continue to engage, in the following conduct in trade or commerce.

398    Apple requires app developers who wish to distribute iOS apps to the broad base of iOS device users to do so only through the App Store, with the effect that Apple is the only distributor of iOS apps in the Australian iOS app distribution markets and with the exception of those iOS apps that are pre-installed on iOS devices, iOS device users can only obtain iOS apps through the App Store.

399    Apple pre-installs the App Store on the home screen of all iOS devices and prohibits iOS device users from removing the App Store from their iOS devices. Further, Apple pre-installs many Apple iOS apps on the home screen of all iOS devices. Further, Apple prohibits the pre-installation of third-party apps, including app stores, on iOS devices. Further, Apple prohibits the distribution or offering of alternative app stores on the App Store and on iOS devices. Further, Apple prevents iOS device users from directly downloading, installing or updating iOS apps from websites.

400    Generally, Apple prohibits the distribution of iOS apps to iOS devices other than through the App Store, save for trivial exceptions.

401    Apple requires app developers to enter into the developer agreement and DPLA, including the App Store review guidelines, if they want to distribute iOS apps to iOS device users.

402    Apple does not permit app developers to negotiate any of the terms of the developer agreement, DPLA, or the App Store review guidelines.

403    Apple imposes some or all of the restrictive terms upon app developers seeking to distribute iOS apps or offer in-app purchases to iOS device users, including restrictions which prohibit app developers from using and offering alternative payment solutions for accepting and processing payments for in-app purchases within an iOS app and by charging supra­competitive prices to app developers and/or deriving supra-competitive profits, unconstrained by competition, in connection with the distribution of iOS apps and/or for IAP.

404    Apple prohibits app developers from steering iOS device users from within iOS apps to alternative payment methods to IAP for purchasing digital in-app content outside the app, save for, since 30 March 2022, “reader” apps which are permitted to apply for the “External Link Account Entitlement”. This allows them to provide an informational link in their app to a website the developer owns or maintains responsibility for in order to create or manage an account.

405    Apple enforces the restrictive terms, including by enforcing some or all of the restrictive terms against Epic by removing Fortnite from the App Store and terminating Epic’s Team ID ‘84 developer account. Apple refuses to reinstate the Team ID ‘84 account.

406    Apple refused to permit the Epic Games Store to be included on the App Store and to be distributed to iOS device users on iOS devices.

407    Apple requires its appointment under the DPLA as the agent for app developers for the marketing and downloading of apps on the Australian App Store.

408    Through its imposition and enforcement of the restrictive terms, Apple has ensured that the App Store is the sole means by which app developers may make their iOS apps available to iOS device users and the App Store is the sole means by which iOS device users may obtain iOS apps.

409    By reason of these matters, Apple has foreclosed any and all alternative iOS app distribution methods.

410    By reason of the matters, Apple has prevented or hindered competition in the iOS app distribution market. The competition that is hindered is in respect of the means by which iOS device users may obtain iOS apps.

411    But for the conduct described above, Apple Inc and/or Apple Pty Ltd would or would likely face the threat of entry by competitors and vigorous and effective competition in the iOS app distribution markets, or in one or more of those markets, from alternative methods of iOS app distribution, such as competing app stores, direct downloading options and/or from app developers using or offering alternative payments solutions for accepting and processing in-app purchases to other developers.

412    I will refer to the conduct I have just described as the iOS app distribution conduct.

The alleged restrictive terms — Epic’s pleading

413    Epic has alleged the following concerning the restrictive terms, aspects of which I have briefly canvassed earlier.

414    It says that Apple required, and continues to require, that any app developer who wishes to distribute its apps through the App Store including the Australian App Store must set up a developer program account with Apple requiring the payment of an annual fee, and enter into the Apple developer agreement and the DPLA with Apple Inc. And it says that Apple required that any app developer entering into the DPLA adhere to, relevantly, the App Store review guidelines. I might add that none of this is contentious.

415    Epic says that Apple, by enforcing the DPLA and App Store review guidelines, has prevented app developers from distributing or offering alternative app stores on iOS devices and from using and offering alternative payment solutions for accepting and processing-payments for in-app purchases within an iOS app. Again, this is not contentious.

416    Epic says that to distribute a free iOS app, an app developer must additionally enter into a schedule 1 agreement with Apple. Alternatively, to distribute a paid iOS app or offer in-app purchases, an app developer must additionally enter into a schedule 2 agreement with Apple. Again, this is not contentious.

417    Now pursuant to the terms of schedule 2 to the DPLA, in Australia, Epic says that both Apple Inc and Apple Pty Ltd have the following positions and functions.

418    First, such entities are required to be appointed by the app developer as the app developer’s agent for the marketing and delivery of the licensed applications to end-users; “Licensed Application” is defined in schedule 2 at clause 1.1(c) to include “any content, functionality, extensions, stickers, or services offered in the software application”; “End-User” is defined in schedule 2 at clause 1.1(b) to include “individual purchasers as well as eligible users associated with their account via Family Sharing”. Second, such entities are to market and make the licensed applications available for download by end-users through the App Store, for and on behalf of the app developer. Third, such entities are to market, solicit and obtain orders on the app developer’s behalf for licensed applications from end-users. Fourth, such entities are to provide hosting services of licensed applications. Fifth, such entities are to make copies of, format, and otherwise prepare licensed applications. Sixth, such entities are to issue invoices for the purchase price payable by end-users for the licensed applications. Seventh, such entities are to allow the download of licensed applications by end-users. Eighth, such entities are responsible for the collection of all prices payable by end-users for licensed applications acquired by those end-users under schedule 2. Ninth, such entities are to remit to app developers amounts held in trust. None of this is contentious putting to one side for the moment the precise entity in question. Let me say something about commissions.

419    The relevant Apple entity is entitled to a commission “for its services as ... agent and/or commissionaire under this Schedule 2” of 30% of all prices payable by each end-user for licensed applications or, for an auto-renewing subscription purchase in its second or subsequent year, 15% of all prices payable by each end-user. Where the app developer qualifies and has been approved for the App Store small business program, the commission is reduced to 15% of all prices payable by each end-user for licensed applications.

420    Further, upon collection of any amounts from any end-user as the price for any licensed application delivered to that end-user, Apple deducts the full amount of the commission with respect to that licensed application and any taxes collected by Apple, and remits the remainder to the app developer.

421    And pursuant to the DPLA, Apple imposes the following terms on app developers, none of which are contentious in the sense simply that they are imposed.

422    First, iOS apps may be distributed via the App Store only if selected by Apple in its sole discretion.

423    Second, iOS apps may only use application programming interfaces (APIs) documented by Apple in published documentation and which are contained in software provided to developers by Apple in the manner prescribed by Apple and must not use or call any private APIs.

424    Third, iOS apps may not download or run code that, inter-alia, creates a store or storefront for other apps or code. Colloquially, this is the store within a store prohibition.

425    Fourth, iOS apps may not provide, unlock or enable additional features or functionality through distribution mechanisms other than those permitted under the DPLA without Apple’s prior written approval or as permitted in relation to the use of IAP.

426    Fifth, iOS apps may only read data from or write data to a designated container area on the iOS device, except as otherwise specified by Apple.

427    Sixth, iOS app developers must not distribute iOS apps to third parties via distribution methods other than the App Store save for certain trivial exceptions expressly permitted by the DPLA.

428    Seventh, iOS app developers are prohibited from issuing any refunds of in-app purchases made using IAP to users of their iOS apps.

429    Eighth, iOS app developers must submit to the exclusive jurisdiction of the courts of the Northern District of California with respect to litigation arising out or relating to the DPLA, and agree that the DPLA will be governed by the laws of the United States and California.

430    Ninth, app developers must comply with the App Store review guidelines. Let me go to these now before coming back to schedule 2 of the DPLA.

431    The App Store review guidelines, which take effect as a term of the DPLA and the schedule 2 agreement, are non-negotiable and Apple reserves the right to update them from time to time. They require the following.

432    First, subject to certain exceptions in the guidelines, iOS app developers must use IAP for in-app purchases of digital content. But they are precluded from using IAP in respect of non-digital goods.

433    Second, except in relation to “reader” apps where a user has previously purchased magazine, newspaper, book, audio, music and video content, iOS app developers must not do anything that directs, encourages or steers users to purchasing mechanisms other than IAP. I will refer to this as the anti-steering restriction.

434    Third, with the exception of “reader” apps, iOS app developers must not allow users to access content, subscriptions or features purchased through avenues other than the iOS app unless those items are also available for purchase within the iOS app via IAP.

435    Fourth, developers must not submit an iOS app which creates an interface for displaying third-party apps similar to the App Store.

436    Fifth, an app may only contain or run code not embedded in the binary code of the app, such as HTML5-based games, if code distribution is not the main purpose of the app and the code is not offered in a store or store-like interface.

437    Sixth, it is “unacceptable” for an app developer to submit an iOS app which creates an interface for displaying third-party apps “similar to the App Store or as a general­interest collection”.

438    Seventh, app developers may not include an alternative payment solution within the app.

439    Eighth, app developers are not permitted to steer iOS device users from within an iOS app to alternative payment methods outside the iOS app, save for, since 30 March 2022, “reader” apps, which are permitted to apply for the “External Link Account Entitlement” to provide an informational link in their app to a website the developer owns or maintains responsibility for in order to create or manage an account.

440    Ninth, app developers must not allow users to access content, subscriptions or features they purchased through another app distribution channel, such as the app developer’s own website, without also making it available as an in-app purchase within their iOS apps distributed via the App Store.

441    Tenth, browsers on iOS devices must use only Apple’s own WebKit browser engine.

442    If an app developer does not comply with the terms of the DPLA and these provisions, the iOS app will not be approved by Apple for distribution via the App Store, or if the app is already on the App Store, it can be removed from the App Store and/or the app developer’s developer program account may be suspended or terminated.

443    Pursuant to schedule 2 to the DPLA, Apple imposes the following terms on app developers.

444    First, app developers must allow Apple to collect a 30% commission on the sale of paid apps, except for in limited circumstances where the commission is reduced to 15%.

445    Second, app developers must allow Apple to collect a 30% commission on digital in-app purchases, except for in limited circumstances where the commission is 15%.

446    Third, app developers seeking to distribute iOS apps must appoint Apple Inc and Apple Pty Ltd as their agent for the purposes of Apple conducting all dealings with iOS device users.

447    Fourth, where Apple determines to refund a customer, it requires reimbursement for the full amount of the price paid by the “End-User” for that “Licensed Application”.

448    Fifth, Apple may withhold payments due to the app developer if Apple determines, or even suspects, that the relevant app developer or any affiliate of the app developer has engaged in, encouraged or participated with other app developers to engage in any suspicious, misleading, fraudulent, improper, unlawful or dishonest act or omission.

449    Sixth, Apple may delist app developers’ apps from the App Store at any time.

450    Seventh, Apple also requires app developers to price their iOS app within global pricing tiers set by Apple.

451    Eighth, the iOS app developer must relevantly appoint Apple Inc and Apple Pty Ltd jointly as the developer’s agent for the marketing and delivery of the developer’s app (“Licensed Application”) through the Australian App Store to end-users located in Australia.

452    Ninth, in consideration for its services as agent, iOS developers must allow Apple Inc and relevantly Apple Pty Ltd to collect a 30% commission on the sale of paid apps and in-app content, except in relation to certain subscriptions which involve a 15% commission and for developers who have enrolled in the small business program.

453    Tenth, Apple Inc and relevantly Apple Pty Ltd may refund a payment to the iOS end-user, in which case the app developer must reimburse that amount to Apple.

454    Eleventh, Apple Inc and relevantly Apple Pty Ltd may delist iOS app developers from the App Store at any time and for any reason.

455    The matters referred to above are collectively referred to as the restrictive terms.

456    Now the developer agreement, the DPLA and schedule 2 to the DPLA are each standard form contracts. And Epic’s case is that Apple does not permit app developers to negotiate any terms of each of the developer agreement, the DPLA, the App Store review guidelines and/or schedule 2 to the DPLA. Further, Apple may amend the terms of each of the standard form developer agreement, DPLA and schedule 2 to the DPLA at any time. None of this is in dispute.

457    Now Epic’s case is that Apple Pty Ltd imposes the restrictive terms above jointly with Apple Inc. In the alternative, Epic says that Apple Pty Ltd has given effect in Australia to the restrictive terms. In the further alternative, Epic says that Apple Pty Ltd is involved in the imposition of the restrictive terms by Apple Inc and/or the giving of effect to the restrictive terms by Apple Inc, within the meaning of s 75B of the CCA.

458    In my view, the effect of the contractual framework is that the iOS restrictive terms are imposed by Apple Inc on iOS app developers supplying apps to iOS users in Australia, and are given effect to by Apple Pty Ltd.

459    In practice, the collection of payment, the immediate extraction of Apple’s commission, and the delayed remittance of the balance to the developer is undertaken, or primarily undertaken, by Apple Pty Ltd, whilst the practical enforcement of the DPLA and App Store review guidelines falls to Apple Inc on behalf of all of its subsidiaries.

460    In summary, Epic says that Apple Inc has since 6 November 2017 being the beginning of the relevant period, entered into contracts containing provisions which have the following purpose and effect. They require developers to appoint Apple Inc and Apple Pty Ltd as the developer’s agent for the marketing and downloading of apps on the Australian App Store. They prohibit the distribution of iOS apps to iOS devices other than through the App Store, save for trivial exceptions. They prohibit the offering of app stores that are an alternative to the App Store on iOS devices. They prohibit iOS device users from directly downloading, installing, or updating iOS apps from websites. They require developers to use IAP for iOS in-app purchases of digital content. Subject to limited exceptions, they prevent developers from using any payment solution other than IAP for facilitating payments for iOS in-app purchases of digital content. Subject to limited exceptions, they prevent developers from offering users access to digital content, subscriptions or features purchased through another channel unless those items are also available for purchase within the iOS app via IAP. And subject to limited exceptions, they prohibit developers from steering iOS users from within an iOS app to an alternative payment solution for purchasing in-app digital content.

461    In addition to imposing these iOS restrictive terms, Apple has, throughout the relevant period, enforced those terms, both on its behalf and on behalf of its subsidiaries.

462    First, Apple has enforced the store within a store prohibition against entities including Facebook (now Meta), Amazon, Microsoft, Tribe, and NVDIA GeForce NOW.

463    Second, Apple has forced app developers including Instagram and Pebble to remove functionalities from within their iOS apps which Apple considers violate the App Store review guidelines, even where Apple’s apps offer the same or similar functionalities.

464    Third, Apple has enforced its App Store review guidelines against many entities, including Microsoft.

465    Fourth, Apple has enforced its restrictive terms against Epic, by removing Fortnite from the App Store and terminating the Team ID ’84 account. Apple refuses to reinstate the Team ID ’84 account, and to permit the Epic Games Store to be distributed to iOS device users.

466    So too, Apple has been rigorous in enforcing the iOS restrictive terms concerning payment solutions. It has rejected thousands of apps for distribution on iOS for violating the App Store review guidelines, which set out the requirement to use IAP and the anti-steering rule, and it has terminated numerous developers’ accounts for incorporating a third-party payment mechanism into their app.

467    In addition to making and enforcing the iOS restrictive terms, Apple also prohibits the pre-installation of any third-party apps including app stores on iOS devices.

468    Finally, Apple reinforces its contractual restrictions with technical restrictions that are encoded in iOS. Those technical restrictions prevent the installation and running of apps on iOS devices unless the app has been downloaded from the App Store, apart from certain trivial exceptions.

469    Now this conduct is all said to occur in the following market.

470    Epic says that there is a market or markets for the supply of services for the distribution of iOS apps to iOS device users, which is said to exist now and at all relevant times. I will refer to this as the iOS app distribution market.

471    Epic says that the services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide iOS device users with iOS apps and associated updates or the provision of services to iOS device users enabling or facilitating iOS device users to be presented with or find, obtain and utilise iOS apps and associated updates.

472    In the alternative, Epic says that there is a market or markets for the supply of services for the distribution of iOS apps and native apps written for Android OS, which I will refer to as Android apps, to, respectively, iOS device users and users of Android smartphones or Android tablets, which I will refer to as Android device users. I will refer to this as the app distribution market, which is said to exist now and at all relevant times.

473    The services consist of the provision of services to app developers enabling or facilitating app developers to reach, offer and provide iOS device users or Android device users with mobile apps and associated updates or the provision of services to iOS device users or Android device users enabling or facilitating iOS device users or Android device users to be presented with or find, obtain and utilise mobile apps and associated updates.

474    Epic says that each of the iOS app distribution market and the app distribution market is a market in Australia for the purposes of s 4E of the CCA in that its geographic dimension is limited to Australia, alternatively, the market in Australia forms part of a global market excluding China.

Apple’s conduct in respect of iOS in-app payment solutions

475    Further, as I have briefly canvassed earlier, Epic says that Apple has engaged and continues to engage in the following conduct in trade or commerce in the Australian iOS in-app payment solutions markets, or in one or more of those markets.

476    Apple requires app developers to use Apple’s IAP if they want to offer in-app purchases to iOS device users.

477    Apple restrains app developers from using any other payment solution for accepting and processing payments for in-app purchases within an iOS app.

478    Apple prohibits app developers from steering iOS device users from within iOS apps to alternative payment methods to IAP for purchasing digital in-app content outside the app, save for, since 30 March 2022, “reader” apps, which are permitted to apply for the “External Link Account Entitlement” to provide an informational link in their app to a website the developer owns or maintains responsibility for in order to create or manage an account.

479    I will refer to the conduct that I have just described as the iOS payment solutions conduct.

480    Now this conduct is all said to occur in the following market.

481    Epic says that there is a market for the supply of services to app developers for accepting and processing payments for in-app purchases within an iOS app. I will refer to this as the iOS in-app payment solutions market, which is said to exist now and at all relevant times.

482    The services consist of the provision of services to app developers, including the provision of a payment solution enabling and/or facilitating app developers to accept and process payments for in-app purchases within an iOS app.

483    The iOS in-app payment solutions market is a market in Australia for the purposes of s 4E of the CCA in that its geographic dimension is limited to Australia, alternatively, the market in Australia forms part of a global market excluding China.

Lay evidence in the Apple proceeding

484    It is convenient at this point to say something about the lay evidence specifically called or tendered in the Apple proceeding. Of course, given my trial orders and the nature of the concurrent hearing, other evidence called or tendered in the other proceedings is also relevant and admissible in this proceeding.

Epic’s lay evidence

485    Mr Sweeney gave written evidence in chief in both the Apple and Google proceedings and was cross-examined by Mr Matthew Darke SC for Apple and Mr Cameron Moore SC for Google.

486    Mr Sweeney gave on the whole reliable evidence, although there were several occasions where he appeared to be a little evasive. But generally his evidence was frank and to the point. Moreover, to his credit he freely agreed to the cross-examiner’s characterisation of Epic’s strategy as it concerned Apple and Google, Project Liberty and the hotfix.

487    Mr Steve Allison, the vice-president and general manager of the Epic Games Store, gave written evidence in chief in both the Apple and Google proceedings. He was cross-examined by Mr Stephen Free SC for Apple and Mr Moore SC for Google. He gave honest and helpful evidence, and made appropriate concessions where necessary.

488    Mr Andrew Grant, Epic’s senior director of engineering, gave written evidence in chief in both the Apple and Google proceedings. He was cross-examined by Mr Darke SC and Mr Moore SC.

489    He was a reliable witness and technically very good. But there were aspects of some of his affidavit evidence that were incorrect.

490    Mr Matthew Weissinger, the former vice-president of marketing at Epic, gave written evidence in chief in both the Apple and Google proceedings. He was cross-examined by Mr Free SC for Apple and Mr Yezerski SC for Google.

491    I had no difficulty with the reliability of his evidence generally.

492    Mr Michael Seavers, the former vice-president of development at Epic, gave written evidence in chief in both the Apple and Google proceedings. He was briefly cross-examined by Mr Free SC for Apple.

493    Mr Seavers was technically very good and gave straight-forward answers. There was no difficulty with the reliability of his evidence.

494    Mr Christian Owens, the founder and the initial CEO of Paddle Payments Limited (Paddle.com Market Limited) and later the executive chairman, gave written evidence in chief in the Apple and Google proceedings. He was cross-examined by Mr Darke SC for Apple and Mr Robert Yezerski SC for Google. Generally he gave reliable evidence, although perhaps at times he bordered on being slightly evasive.

495    Mr Christopher Prestwich, Epic’s solicitor and partner at Allens, gave written evidence in chief in the Google proceeding concerning the installation of various apps. He was very briefly cross-examined by Mr Moore SC concerning the steps that he had taken. I do not need to linger on the detail.

496    It is convenient to also note here that other employee solicitors of Allens, namely, Mr Isaac Johanson-Blok and Mr Oliver Sweetapple-Gagiero, gave written evidence which was not cross-examined on. This evidence was also accompanied by a statement of agreed facts pursuant to s 191 of the Evidence Act 1995 (Cth).

Apple’s lay evidence

497    Mr Schiller, who I have mentioned earlier and who is an Apple Fellow and employee of Apple, gave written evidence in chief. He was cross-examined by Mr Young KC for Epic and Mr Tony Bannon SC for the class applicants.

498    As an Apple Fellow, and previously as the senior vice president of worldwide product marketing at Apple, he is and was responsible for the App Store.

499    On the whole his evidence was honest and on many aspects reliable. But having said that, the detail in his affidavit and the precision in some of his answers was surprising given the time period that had elapsed concerning some of the relevant events and the absence of contemporaneous documents that could otherwise have been used to refresh his memory.

500    In my view there was from time to time a significant amount of reconstruction in some of his evidence that diminished its weight. I will discuss particular subject matter in more detail later.

501    I also found his evidence concerning the production and use of financial records concerning the App Store to be problematic.

502    Further, I had difficulty with some of his evidence relevant to the question of Apple’s purpose which I will discuss later.

503    Mr Craig Federighi, senior vice president of software engineering at Apple, gave written evidence in chief. He was cross-examined extensively by Dr Ruth Higgins SC for Epic.

504    Mr Federighi was technically very proficient and a very reliable and helpful witness. He also made appropriate concessions where necessary.

505    He has a BSc in electrical engineering and computer science obtained in 1991 from the University of California, Berkeley, and an MSc in computer science, also obtained from that institution in 1993.

506    After graduating from Berkeley with his MSc, he began working at NeXT Computer in 1994, a technology company that specialised in computer workstations for use by businesses and higher education, including the development of applications for use on the NeXT Computer operating system. He joined NeXT Computer as a software engineer on the Enterprise Objects Framework team, which was responsible for building the Enterprise Objects Framework, NeXT Computer’s software development platform. He later managed the Enterprise Objects Framework team, and then the WebObjects team, a related team that was responsible for developing NeXT Computer’s WebObjects application development platform.

507    In early 1997, NeXT Computer was acquired by Apple, where he continued to lead the WebObjects department as a director of engineering following the acquisition.

508    In 1999, he joined Ariba (now SAP Ariba), an internet e-commerce company, as vice president of internet services, and was then promoted to chief technology officer. At Ariba, he was responsible for platform architecture, app design and product strategy, as well as demonstrating their products.

509    In 2009, Mr Federighi returned to Apple as vice president of macOS engineering, where he led a team that focused primarily on the features and user environment of the operating system for Mac devices. In this role, he was responsible for all operating system software for Mac devices, as well as any software that was common to the Mac devices and iOS devices at the time. This included leading the macOS engineering team in the development and launch of the Mac App Store.

510    In 2012, he was promoted to senior vice president of macOS engineering at Apple, reporting to the CEO.

511    In late 2012, he was appointed to his position at the time of trial as senior vice president of software engineering. In this role, he led Apple’s software engineering organisation, which is responsible for building the operating systems that power Apple's products such as the iOS operating system running on iPhone and the macOS operating system running on Mac devices.

512    Now there were some aspects of his evidence that caused difficulties. One criticism that I had of his evidence concerned the speech that he gave in re-examination to a question asked of him. Its length was excessive and some of its content was new. I will return to the subject matter later. Another criticism is that he had not properly looked at the 2021 Nokia Threat Intelligence Report although he cited some of its statistics in his affidavit. But the detail in that report put some of the data in a different light.

513    Ms Stella Wong, business lead for the App Store, Australia and New Zealand at Apple Pty Ltd, gave written evidence in chief. She was cross-examined by Mr Neil Young KC for Epic and Mr Nick De Young KC for the class applicants.

514    On the whole she was an engaging witness and gave reliable and honest evidence. I had no difficulty with her evidence generally speaking.

515    Ms Saori Casey, vice president of corporate financial planning at Apple, gave written evidence in chief concerning Apple’s financial records. She was cross-examined by Mr Thomas Prince for Epic. I will discuss her evidence later which involved some problematic aspects, although most of it was reliable.

516    Ms Jacqueline Harlow, principal counsel and senior manager of IP transactions at Apple, gave written evidence in chief concerning Apple’s IP portfolio and Apple’s proprietary developer technologies and underlying IP rights. She also gave evidence as to the core Apple technologies used by Epic to produce Fortnite. She was not cross-examined.

517    There is one other individual that Apple sought to call on IP questions, albeit as an expert, which I did not permit.

518    Apple sought to tender a report of Mr James Malackowski concerning Apple’s intellectual property and also certain accounting questions.

519    I refused the tender for various reasons and gave an ex tempore ruling accordingly for which a transcript is available (T 4247 to 4249). It would be a waste of time to produce a further formalisation of my views.

520    Briefly, his expertise and specialised knowledge was questionable in terms of the questions posed. Further, he did not properly answer the questions posed, and indeed strayed beyond the questions posed. Moreover, there were serious difficulties with the form of his report which blended base fact with his subjective non-expert interpretations and beliefs. Perhaps there was some trace gold to be found, that is, true expert views in proper form, but it was not worth the effort in sifting or extracting it. Further, aspects were duplicative of other evidence.

521    In my view the report was not receivable as expert opinion evidence under s 79 of the Evidence Act 1995 (Cth), and even if it had been I would have excluded it under s 135.

522    Let me deal with one final aspect under this topic.

523    Now a criticism made by Epic is that Apple did not call sufficiently senior executives to give evidence. In essence a Jones v Dunkel point was made. But I have not accepted this.

524    Apple adduced evidence from two of its most senior executives, being Mr Schiller and Mr Federighi. Those are the executives responsible for the business decisions the subject of this litigation, to give evidence in this case. Each of those witnesses has an intimate knowledge of the matters the subject of this litigation.

525    Mr Schiller explained his role in connection with the history of Apple, iOS device and the App Store as follows:

I was a member of the leadership team at every stage of development of the iPhone, from its concept, through its development and its production, and so I had a role in all elements of the creation of the iPhone – the hardware and the software – and had an input to many of the decisions of features implementation, and then that carried through to launching the iPhone. I was responsible for the event that we had where we launched the iPhone and introduced it to the world, and then all the marketing activities that followed to bring the iPhone to market.

526    Mr Schiller has over 30 years’ experience working at Apple, culminating in his appointment, after decades of service on Apple’s most senior executive team, as an Apple Fellow. He was intimately involved in the creation and launch of the iPhone and App Store, working closely with Mr Jobs on those projects. He remains the executive responsible for the App Store.

527    Mr Federighi leads a software engineering team that is responsible for the highly sophisticated operating system that is run on over a billion devices worldwide. He commenced the process of assuming responsibility for that role in 2009. He is a very qualified witness to speak about the measures that Apple takes and has taken in the past to safeguard the security and privacy of the iOS ecosystem, at least where he has personal knowledge.

528    Let me say something more about Apple’s decision making processes and decision makers.

Apple’s decision-making processes and decision-makers

529    There is much to be said for Epic’s assertion that the evidence of Apple’s executives reveals peculiarities at the core of Apple’s internal decision-making and governance. And I do agree that Apple’s lack of formal governance structure, its verbal culture and absence of any written records to support key decisions are at odds with the scale of Apple’s business and its accountability to public investors.

530    But I am not convinced that they are only consistent with and explicable by the reality that Apple does not face competition in respect of iOS app distribution or payment solutions for in-app purchases of digital goods. Perhaps they are explicable by some management style peculiar to Californian corporate culture in general or tech companies in particular. Who knows? Anyway there are various unusual features which it is necessary to set out.

Apple’s decision-making structure

531    A decision-making body within Apple is the executive team. The executive team comprises the heads of each functional organisation within Apple, including the CEO, CFO, head of services, head of manufacturing and operations, head of sales, chief legal counsel, head of software engineering, head of hardware engineering and, at times, head of support.

532    According to Mr Schiller, the executive team generally meets each Monday for three hours to discuss the strategy and direction of the company, as well as ongoing programs that Apple is running.

533    Mr Schiller gave evidence that from around 2007, he has reported directly to the CEO, who in turn reports to Apple’s board of directors. It is the CEO’s responsibility to work with the board on their agenda, and the board’s discussions, in Mr Schiller’s experience, were not at the level of individual features.

534    The executive team is unaware of matters raised with the Apple board and, as a collective, do not report to, or refer matters to, the board. Mr Schiller was unaware of whether key decisions regarding the App Store, such as the decision by Apple to permit third-party native apps on the iPhone in 2007, were communicated to the board.

535    Indeed, there is no evidence that Apple’s board had involvement in any of the decisions the subject of these proceedings.

536    Now I accept that a number of the decisions which Epic now seeks to interrogate were made at a time when Apple was a far smaller business than it is today and the potential impact of the iPhone could not yet be known. Further, the process followed by the executive team in making foundational decisions about what form the then new invention should take in an operational setting were not a product of market power that was yet to exist. It is likely that this was the work of an effective executive team. So, it may be that the executive team later applied the same approach that had proved to be successful.

537    Now Epic is dismissive of the evidence given by Mr Schiller to the effect that Mr Jobs had impressed on executives that they should be able to listen, absorb and retain information without depending upon handwritten notes. But this does contextualise Apple’s approach to decision-making, which was dynamic and highly effective.

538    Mr Schiller explained that the CEO works with the board to determine the agenda of issues that the board is to consider. He said that generally the board was told about particular features of a product that the executive team were working on, but it was not an area of great attention for the board.

539    Now Mr Schiller explained that at the time the decision was made to permit third-party app developers to develop apps for iOS, the decision was considered important but not a strategic decision for the company.

540    The decision-making process in respect of some of Apple’s most formative and significant App Store and IAP decisions were informal in character. Such decisions were often made by a subset of the executive team, and in some instances, were not made or discussed at an executive team meeting. Instead, decisions were often made by a small group of the Apple executives who were responsible for the relevant area.

541    Decisions about the App Store were typically made by a subset of the following Apple executives: Mr Schiller, Mr Jobs, the CEO until 2011, Mr Cue, senior vice president, services, Mr Forstall, senior vice president, iOS software until 2012, and, more recently, Mr Cook, (CEO), Mr Maestri (CFO) and Ms Adams (general counsel).

542    The relevant decision makers concerning various decisions were apparently the following.

543    First, the decision to permit third-party native apps on the iPhone was made by Mr Jobs, Mr Schiller and Mr Forstall.

544    Second, the decision that the App Store would be Apple’s centralised app distribution model was made by Mr Jobs, Mr Schiller, Mr Cue and Mr Forstall.

545    Third, the decisions to set the IAP 30% commission rate and introduce the reader rule were made by Mr Jobs, Mr Schiller and Mr Cue.

546    Fourth, the decision to reduce the commission for subscriptions was made by Mr Schiller, Mr Cue and others whom Mr Schiller could not recall.

547    Fifth, the decision to introduce the multi-platform rule was made by Mr Cook, Mr Schiller and Mr Cue.

548    Sixth, the decisions to set the 26% commission rate in South Korea and the 27% commission rate in the Netherlands when a developer elects to use an alternative payment solution were made by Mr Cook, Mr Schiller, Mr Cue, Mr Maestri and Ms Adams.

A lack of decision-making records – the Californian excuse

549    Now the executive team, despite being an important decision-making organ, does not appear to have created minutes of its meetings or records of its decisions, and has not done so since at least 2007, which was apparently a consequence of a mandate by Mr Jobs.

550    Mr Schiller gave the following evidence:

When Mr Jobs came back in 1997 … in one of the earliest meetings, someone was taking notes, writing down what he was saying about what we were doing, and he stopped and said, “Why are you writing this down? You should be smart enough to remember this. If you’re not smart enough to remember this, you shouldn’t be in this meeting”. And we all stopped taking notes, and learnt to just listen, and be part of the conversation, and remember what we’re supposed to do, and that became how we worked.

551    Similarly, when Mr Federighi explained the absence of documents recording the “threat model” for iOS, he described Apple as a Californian company that has “a very verbal culture.”

552    Mr Federighi’s evidence about the way in which Apple operated included the following:

Apple has a culture of employees that often stay a very long time – you know, 15, 20, 30 years. We have a very verbal culture. We have a lot of shared understanding. We rely on teams to embody sets of expertise, and we transmit that expertise through the work and verbally. That is how I’ve gained my expertise in these matters at Apple. I know it may sound strange for a company as large as Apple that there aren’t the kinds of formalisms that one might think of when you think of, like, a military contractor or a space agency or something like that. I can only tell you that it isn’t the way we work.

553    So it would seem that Apple has maintained a practice of making significant decisions about the App Store and IAP without creating any written records, although it would seem that executive team meetings were usually accompanied by an agenda, a position that I am willing to accept.

554    But notwithstanding the absence of contemporaneous decision-making records, Mr Schiller purported to describe his recollections of the events regarding the various decisions referred to in his affidavit that I am concerned with, and the rationale for those decisions, in detail. And in many instances those decisions were made by Apple more than a decade ago.

555    First, regarding the initial decision by Apple not to allow third-party native apps on the iPhone, Mr Schiller said he did not need a document to remember these discussions and accepted that his affidavit evidence regarding this decision was made without looking at contemporaneous documents, and was based on his memory.

556    But as Epic pointed out, Mr Schiller’s assertion that he had a clear memory of those discussions in 2007 can be contrasted with his inability to recall more recent events, including his own emails and meetings discussing the small business program in 2020, and arrangements connected to the video partner program from 2018 to 2020.

557    Second, for Apple’s decision in or around October 2007 to allow third-party native apps on the iPhone, Mr Schiller said that whilst he did not recall whether there were records of this decision, he could remember the actual words that were said when the decision was made.

558    Third, in respect of Apple’s decision in 2008 to adopt a centralised app distribution model for the App Store, Mr Schiller said that he remembered the reasons for Apple’s decision but could not identify a document recording those reasons.

559    Fourth, Mr Schiller recalled developing the goals for the App Store, but did not know if those goals were recorded in a document. Mr Schiller gave evidence that the “two goals” referred to in his affidavit were goals that he “wrote … back when we were creating the App Store” and that he “probably wrote them down on a whiteboard in a meeting and repeated them many times to the team”. Mr Schiller purported to have a clear recollection of these goals, which are presented in his affidavit as being guiding principles to fundamental decisions made in respect of the App Store, in circumstances where there are no contemporaneous written records. As Epic says, a written reference to those goals first appeared in Apple’s internal documents in 2016, almost a decade after the App Store was launched. I will return to this question later.

560    Fifth, regarding Apple’s decision in or around 2009 to set the 30% commission rate, Mr Schiller said was that he could remember the meetings but did not recall if there were written records of that decision.

561    Sixth, Mr Schiller said that the introduction of the reader rule in 2011 was not documented in a written record with any reasons for the decision being made.

562    Seventh, Mr Schiller could not recall any written record of the decision or reasons for Apple’s decision to reduce the commission for subscriptions in 2016.

563    Eighth, Mr Schiller could not recall seeing a written record of the decision to launch the video partner program.

564    Ninth, Mr Schiller could not recall any written record of Apple’s decision to introduce the multi-platform rule in 2018 or of the reasons for that decision.

565    Tenth, Mr Schiller did not believe the decision or reasons for the decision to introduce the small business program in 2021 were documented.

566    Eleventh, Mr Schiller referred to the existence of specific documents being “slides” in the form of a presentation that outlined analysis and recommendations for the changes to Apple’s commission rates in South Korea and the Netherlands to meet regulatory requirements prescribed in those jurisdictions. But Mr Schiller’s recollection of the existence of those documents was inaccurate.

567    As Epic correctly points out, there is no documentary evidence that Apple has drawn to my attention, contemporaneous or otherwise, that records an analysis or examination of the costs that were considered or the calculations that led to the revised commission rates in South Korea and the Netherlands. There is also no analysis or explanation as to why the 26% commission rate imposed by Apple when an alternative payment solution is used in South Korea is different from the 27% commission rate imposed in the Netherlands.

568    Let me turn to Mr Federighi. Mr Federighi gave evidence about central issues such as the asserted threat model for iOS that preceded his return to Apple, without annexing or referring to any documents at all. Indeed, no documented threat model exists.

569    His evidence was accordingly based neither on documents, nor direct recollection but instead involved only what he learnt after joining Apple. As Epic correctly points out, his understanding was all retrospective and based on discussions with people who were there at the time.

570    Mr Federighi confirmed that he did not speak to Mr Forstall, Mr Dallas DeAtley or Mr Darin Adler, who were individuals working on a team focused on iOS security. But he never identified the “people who were there at the time were” with whom he did speak.

571    I must say that all of these circumstances lead me to treat much of their evidence sceptically concerning the basis of various decisions made by Apple which I have identified.

Was there any documented analysis of decisions?

572    Now as Epic points out, in addition to avoiding the creation of written records to support its decision-making, there is an absence of any business case preparation or other analyses undertaken by Apple to support or inform significant decisions in respect of the App Store and IAP. It pointed to the following aspects which I accept.

573    Mr Schiller could not recall any business cases or other analyses being prepared in respect of the following.

574    Apple’s initial decision not to allow third-party native apps on the iPhone was not made by reference to any analysis by the development team or any analysis of the security and privacy risks associated with allowing third-party native apps on the iPhone.

575    Apple’s subsequent decision to allow third-party native apps on the iPhone was not made by reference to a business case or documents examining the benefits, risks, costs, profit impact, any analysis of financial implications, any written analysis of risks and benefits or a security assessment in documentary form.

576    Apple’s decision to set the IAP 30% commission was not made by reference to any cost analysis, capital investment analysis and other financial measures, including forecast cashflows, net present value, return on investment, forecast profitability or the costs of acquiring third-party payment processing services, or any investigation of what stream of revenue would be produced for Apple.

577    As Epic points out, when taken to the transcript of the iPhone SDK launch from 6 March 2008, Mr Schiller stated that Apple did not know how much money it would make from the App Store or how much it would cost, but that Apple hoped it would break even.

578    As to Apple’s decision to launch the small business program, although Mr Schiller said that the small business program was launched in January 2021 after an extended period of consideration by Apple, there are few documents recording such considerations or analysis.

579    I agree with Epic that it is unusual that Apple did not create papers, recommendations, business cases, forecasts, analyses or presentations to inform the discussions of the executive team in respect of the App Store.

580    Now Mr Schiller sought to downplay the significance of a number of these decisions during cross-examination. Whilst he agreed that each of these decisions was important at the time they were made, he did not think most of them were major strategic decisions, including the decision to allow third-party developers to create native applications for the iPhone.

581    Now as Epic points out, Apple did recognise the utility of having a business case prepared for some occasions. Mr Schiller was questioned as to the absence of a business case analysis concerning the decision to permit third-party apps on the iPhone. He explained that at the time Apple did not develop a documented business case for a decision that it did not consider to be a major business decision. Mr Schiller explained the type of issue that Apple was developing business case analyses for at the time. He said that the type of business case would vary depending on the situation, the product and the time. He recalled a number of models that they were working on with the iPhone for the business case, but at the time the business case they were working on was less about “here’s how many we will sell and here’s how much revenue it will generate”. He said that it was more about how it would be sold with or involving phone carriers and their subsidy model in the United States, and how one would price it.

582    Mr Schiller provided an answer as to why the App Store concept was not the subject of standalone business case analyses at the time that Apple made decisions. He explained that Apple thought of the App Store as part of the iPhone functionality.

583    Of course whatever be Apple’s perspective or position concerning the App Store at the time of its development and inception, I am considering a competition case with the relevant period commencing in November 2017. I have discussed evidence going to this question elsewhere in my reasons.

Apple’s contractual framework with developers

584    As I have already indicated, Epic’s case is that Apple has engaged, and continues to engage, in anti-competitive conduct by deliberately precluding developers from distributing native iOS apps through any alternative channels, and requiring that IAP be the sole payment solution for payments for purchases of digital in-app content in native iOS apps. As should be apparent from what I have already said, Epic’s key complaints are the following.

585    First, Apple does not allow an app distributed via the App Store to itself function as an app store.

586    Second, Apple does not allow native apps to be downloaded to iOS devices, other than via the App Store; the parties have referred to this as sideloading.

587    Third, Apple requires native apps to use IAP for in-app purchases of digital content.

588    Fourth, paid apps and in-app purchases including subscriptions may be subject to commission being either 15% or 30%.

589    Fifth, the anti-steering rule is imposed by Apple.

590    Now these rules only apply to developers who wish to use the Apple software to develop and the App Store to distribute to iOS devices a particular type of app, namely a native app. Developers, including game developers, who do not wish to use the Apple software and associated tools and services and the App Store to develop and distribute their apps can still develop and distribute web apps for iOS. This can be done without entering into the relevant agreements that I have previously referred to.

591    Further, the rules concerning commissions and the use of IAP only become relevant where a developer chooses to monetise a native iOS app in a particular way, by charging users to download the app or charging users for digital in-app content. Freely distributed apps with no in-app purchases of digital content operate without commission and without use of IAP. Such apps can be monetised through in-app advertising or the sale of physical goods or services, in respect of which no commission is payable.

592    Further, the DPLA is an agreement between Apple Inc and the developer. The DPLA requires the developer to adhere to the App Store review guidelines and schedule 2.

593    Now as I have already indicated, Apple Inc. requires all iOS app developers to enter into two standard form contracts being the developer agreement and the DPLA. The agreements are standard for all developers.

594    Now I have touched on these agreements earlier, but let me say something more about each class of agreement in turn, beginning with the developer agreement.

Developer agreement

595    Now the developer agreement governs foundational elements of the relationship between Apple and developers. It does not confer licences necessary to develop and distribute apps through the App Store, or grant access to the various tools designed to facilitate such development and distribution. Those matters are dealt with instead by the DPLA.

596    Under clause 2, registering with Apple to become an “Apple Developer” gives a person the opportunity to attend certain Apple developer conferences, technical talks and other Apple events. Apple may also offer to provide the developer with certain services for the developer’s own use in connection with their participation as an Apple developer. Apple reserves the right to change, suspend or discontinue providing such services and providing the contents of the Apple developer web pages.

597    Under clause 3 of the developer agreement developers acknowledge that copyright and other intellectual property laws protect the Apple developer web pages and content contained therein and otherwise offered at Apple events, that Apple retains ownership of all rights in the “Site, Content, Apple Events and Services” and that, except as expressly provided in the developer agreement, no other rights or licences are granted or to be implied under Apple intellectual property protected tools, technologies, and services.

598    Clause 3 also provides that unless expressly permitted under the developer agreement or a separate agreement with Apple, the developer may not do various things in relation to content and services provided and made available by Apple, including reproduce, create derivative works or in any way use such material.

599    Clauses 4 and 5 impose obligations of confidentiality in respect of pre-release software, services and hardware provided to registered developers.

600    Under clause 10, Apple may terminate or suspend a developer’s registration at any time in Apple’s sole discretion. And if that occurs, Apple reserves the right to deny the developer’s re-application at any time in Apple’s sole discretion.

Developer Program License Agreement (DPLA)

601    The DPLA confers a licence on the app developer to use, inter-alia, iOS and various software tools that Apple makes available for the development and testing of iOS apps. But developers are not granted any right to distribute iOS apps under the DPLA. Rather, apps developed using the “Apple Software” may be distributed only if selected by Apple in its sole discretion for distribution via the App Store.

602    Now in order to access Apple’s SDKs and other software development tools, and to submit apps for review and potential distribution through the App Store, a developer must execute a DPLA and pay an annual program fee of USD 99.

603    As far as the licence to develop apps for distribution is concerned, there is a single commercial bargain between Apple and the developer, which includes the terms of the schedules, and the payment of commissions pursuant to schedule 2 for paid downloads and paid in-app transactions. But contrary to what Apple asserts, that does not entail that the commissions payable are directly attributable to a licence fee for any intellectual property rights.

604    Now it is a condition of the DPLA, and of the licence to use iOS, that any app submitted to the App Store must comply with the documentation and program requirements as defined by Apple. The documentation and program requirements may change from time to time, but at all relevant times have included the App Store review guidelines. So, as a term of the DPLA, all developers who choose to make apps available through the App Store must comply with those guidelines.

605    For free apps to be distributed by the App Store, including those that “use the In-App Purchase API for the delivery of free content”, distribution will be subject to the distribution terms contained in schedule 1 to the DPLA.

606    Where the developer wishes to distribute an app and intends to charge end-users a fee for the app or within the app through the use of the In-App Purchase API for the delivery of fee-based content, the developer must enter into an agreement in the terms of schedule 2. Where that occurs, the terms of that schedule “will be deemed incorporated into this Agreement by this reference” (clause 7.2). I will return to the In-App Purchase API later.

607    Now the “Purpose” of the DPLA is set out in the first paragraph. It is the agreement to be used where a developer wishes to use the “Apple Software” to develop one or more “Applications” for Apple-branded products.

608    The same paragraph records that Apple is willing to grant a limited licence to use the Apple software and services under the “Program” to develop and test the developer’s applications on the terms and conditions set out in the agreement. The “Program” is defined in clause 1.2 to mean the “overall Apple development, testing, digital signing, and distribution program contemplated in this Agreement”.

609    The next paragraph explains that applications developed under the DPLA for iOS products can be distributed in four ways including, relevantly, through the App Store. Separate options apply to applications developed for macOS.

610    “Apple Software” is defined in clause 1.2 to include, relevantly, Apple SDKs, iOS, the Provisioning Profiles and “any other software that Apple provides to You under the Program, including any Updates thereto (if any) that may be provided to You by Apple under the Program”. This now involves more than 250,000 APIs. Many SDKs and APIs are for particular features of iPhone, iOS or other aspects of the Apple ecosystem. SDKs and APIs of particular relevance to game developers include Metal, a powerful computer graphics API, and GameKit, which provides integration with Apple’s Game Centre social-network gaming features.

611    “Apple Services” or “Services” means the developer services that Apple may provide or make available through the Apple software or as part of the program for use with “Your Covered Products” or development, including any updates that may be provided to the developer by Apple under the program.

612    A developer’s “Covered Products” are its applications, libraries, passes, Safari extensions, Safari push notifications and/or FPS implementations developed under the agreement.

613    “Documentation” is defined in clause 1.2 to mean any technical or other specifications that Apple may provide to the developer for use in connection with the Apple software, Apple services, Apple certificates or otherwise as part of the program.

614    “Program Requirements” is defined in clause 1.2 to mean the “technical, human interface, design, product category, security, performance and other criteria and requirements specified by Apple,” which includes but is not limited to “the current set of requirements set forth in Section 3.3, as they may be modified by time to time by Apple” in accordance with the DPLA.

615    Applications that meet Apple’s “Documentation” and “Program Requirements” may be submitted for consideration by Apple for distribution via the App Store. If so submitted and selected by Apple, the applications will be digitally signed and distributed.

616    Clause 1.1 of the DPLA states that “[i]n order to use the Apple Software and Services”, a developer “must first accept this Agreement”.

617    Now through clause 2.1, Apple grants the developer a limited licence to use the Apple software (as defined) in the specific ways and for the specific purposes described in clause 2. The licence is granted subject to the terms and conditions of the agreement as the introductory words to clause 2.1 indicate.

618    There is a limited licence to use Apple’s IP protected assets to test and develop apps for distribution, if selected, on the App Store on all the terms set out in the DPLA and the applicable schedule.

619    Now I accept, as Apple has put, that it is not correct to say that there is a licence of intellectual property protected tools, technologies, and services, on the one hand, and a separate agreement for the distribution of apps, on the other. There is a single commercial bargain between Apple and the developer, which includes the terms of the schedules.

620    And I agree with Apple that, generally speaking, there is a licence to use Apple’s underlying IP to test and develop apps for distribution, if selected, on the App Store on all the terms set out in the DPLA and the applicable schedule. But again, that does not make the schedule 2 commissions directly characterisable as a licence fee for intellectual property rights

621    But generally speaking I accept that in commercial terms one part of that arrangement cannot be seen without the other.

622    Now clause 2 of the DPLA needs to be read with clause 7, which deals with the distribution of apps and libraries. The chapeau to clause 7 is in permissive terms, and relevantly provides that apps developed under the DPLA for iOS may be distributed through the App Store, if selected by Apple.

623    Clauses 7.1 and 7.2 of the DPLA require iOS app developers to enter into one or more additional agreements with Apple Inc. and certain of its subsidiaries, including Apple Pty Ltd.

624    Most relevantly, for present purposes, clause 7.2 provides that, if the app developer intends to charge end-users a fee of any kind for digital goods and services, the app developer must “enter into a separate agreement (schedule 2) with Apple and/or an Apple Subsidiary”.

625    If a developer wishes to make its app and content available for free, then clause 7.1 of the DPLA requires it to appoint Apple Inc. and certain of its subsidiaries, including Apple Pty Ltd, as its agent and/or commissionaire pursuant to the terms of schedule 1 to the DPLA.

626    Relevantly, clause 7.2 provides that where the developer intends to charge end-users a fee for the app or within the app through the use of the In-App API, the developer must enter into a separate agreement with Apple before any such commercial distribution of the app or the additional content, functionality or services for which the developer will charge a fee. The last sentence of the first paragraph of clause 7.2 provides that to the extent that a developer enters into, relevantly for the context before me, schedule 2, the terms of that schedule “will be deemed incorporated into this Agreement by this reference”.

627    So, clearly the licence in clause 2 of the DPLA needs to be read with clause 7.

628    The licence in clause 2.1(a) is to install copies of the Apple software to be used internally for the sole purpose of developing or testing covered products, “except as otherwise expressly permitted in this Agreement”.

629    There is no general licence to use the Apple software for the purposes of distribution, and such permissions may not come into existence if, for example, the app is not selected by Apple for distribution through the App Store. But if such distribution is approved then the use right extends, so far as necessary, to use of the Apple software for that purpose too. The same extension is relevant to remove the limitation that would otherwise arise from the terms of clause 2.6.

630    Clause 3.2 in part relevantly provides that apps for iOS products developed using the Apple software may be distributed only if selected by Apple in its sole discretion for distribution via the App Store or other distribution channel. The nature of the use right extending to development for the purposes of distribution, and distribution itself, is reflected in the nature of the “Program” and the “Program Requirements”.

631    Clause 3.3 relevantly provides that any application that will be submitted to the App Store must be developed in compliance with the documentation and the program requirements. As I have already said, the “Program” is the overall Apple development, testing, digital signing and distribution program contemplated in the DPLA. Relevant program requirements include the following.

632    First, applications must only use documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

633    Second, except for the limited purpose specified, an application may not download or install executable code. Interpreted code may be downloaded to an application but not to create a store or storefront for other code or applications.

634    Third, without Apple’s prior written approach or as permitted where dealing with the In-App Purchase API, an application may not provide, unlock or enable additional features or distribution mechanisms other than relevantly the App Store.

635    Fourth, the developer and its apps must not collect user or device data without prior user consent, whether such data is obtained directly from the user or through the use of the Apple software, Apple services or Apple SDKs, and then only to provide a service or function that is directly relevant to the use of the application or to serve advertising.

636    Fifth, apps that offer location-based services or functionality, or that otherwise obtain a user’s location through the use of the Apple software or Apple services, must notify and obtain consent from a user before a user’s location data is collected, transmitted or otherwise used by the app and then such data must be used only as consented to by the user and as permitted under the DPLA.

637    Sixth, apps may be rejected if they contain content or materials of any kind such as text, graphics, images, photographs or sounds that in Apple’s reasonable judgment may be found objectionable or inappropriate, for example, materials that may be considered obscene, pornographic or defamatory.

638    Seventh, apps must not contain any malware, malicious or harmful code, program or other internal component such as computer viruses, trojan horses or backdoors which could damage, destroy, or adversely affect the Apple software, services, Apple-branded products or other software, firmware, hardware, data, systems, services or networks.

639    Let me turn to another matter which I have already touched on being the In-App Purchase API.

640    Now all use of the In-App Purchase API and related services must be in accordance with the terms of the DPLA, the program requirements and attachment 2.

641    The “In-App Purchase API” is the documented API that enables additional content, functionality or services to be delivered or made available for use within an application with or without an additional fee. Further, attachment 2 sets out the additional terms for use of that API.

642    First, a developer may use the In-App Purchase API only to enable end-users to access or receive content, functionality or services that the developer makes available for use within the app, for example, digital books, additional game levels or access to a turn-by-turn map service. The developer may not use the In-App Purchase API to offer goods or services to users outside the application.

643    Second, the developer must submit to Apple for review and approval all content, functionality or services that the developer plans to provide through the use of the API. Such submissions are treated in accordance with the application submission and selection process in section 6 of the DPLA.

644    Third, where the developer seeks to provide additional content, functionality or services, it must submit a new or updated “Submission Description” for review and approval by Apple prior to making such items available through the use of the In-App Purchase API. Apple reserves the right to withdraw approval of any content, functionality or services and the developer agrees to stop making such content, functionality or services available for use within the application.

645    Fourth, all content, functionality and services offered through the In-App Purchase API are subject to the program requirements for applications.

646    Fifth, an in-app purchase item must either already exist in the application waiting to be unlocked, be streamed to the application after the In-App Purchase API transaction has been completed or be downloaded to the application solely as data after such a transaction has been completed.

647    Sixth, for each successfully completed transaction made using the In-App Purchase API, Apple will provide the developer with a transaction receipt. It is the responsibility of the developer to verify the validity of such receipt prior to the delivery of any content, functionality or services to an end-user.

648    Seventh, Apple may provide hosting services for non-consumables that the developer would like to provide to end-users through the use of the In-App Purchase API. In such circumstances the developer is responsible for providing items ordered through the In-App Purchase API in a timely manner.

649    Contrastingly, the developer may use the Apple Pay API solely for the purpose of facilitating payment transactions made by or through the application, and only for the purchase of goods and services that are to be used outside of any iOS product or Apple Watch unless otherwise permitted by Apple in writing. The Apple Pay API is a limited form of functionality that allows the payment method associated with the user’s Apple ID to be employed for the purposes of the transaction.

650    The developer also acknowledges and agrees that Apple is not a party to any payment transactions facilitated through the use of the Apple Pay APIs and is not responsible for any such transactions, including but not limited to the unavailability of any end-user payment cards or payment fraud. This clause reflects the fundamentally different relationship that exists for the purpose of transactions for non-digital content through apps.

651    Let me now say something in more detail concerning schedule 2. I will return to some other provisions of the DPLA itself later.

The schedule 2 agreement

652    The schedule 2 agreement requires the developer to appoint Apple Inc. and Apple Pty Ltd jointly as the developer’s agent for the marketing and delivery of the developer’s app through the Australian App Store to users located in Australia.

653    Apple Inc. and Apple Pty Ltd are instructed to provide marketing, hosting, downloading and invoicing services to the developer in order to allow user access to the developer’s app. While Apple, as agent, hosts and allows the download of iOS apps by users on behalf of developers, the developer is responsible for hosting and delivering content sold using IAP.

654    The provision of services by Apple Pty Ltd under the schedule 2 agreement incorporates a requirement that the developer must comply with the terms of the DPLA if the developer wishes that Apple Pty Ltd continue providing those services.

655    A substantially identical agency arrangement exists under the schedule 1 agreement in relation to free apps distributed on the App Store, even though no commissions are payable to Apple.

656    These arrangements give rise to a relationship of forced agency as Epic has correctly said. The developer has no option but to appoint Apple Inc. and Apple Pty Ltd as its agent for the marketing and delivery of its iOS app. Apple Inc. reserves to itself the right to select, in its sole discretion, which iOS apps will be distributed on the App Store and, thereby, which apps will be available to iOS device users. It also reserves to itself the right to cease offering an iOS app for download at any time without cause. Further, under the forced agency, Apple assumes for itself the right to collect the prices paid by iOS device users for apps or digital in-app content. Apple will only remit the amount received from iOS device users, after deducting its commission, within 45 days after the end of the monthly period in which the payment was received.

657    Other rights that Apple enjoys under the DPLA are inconsistent with a true agency relationship, in which Apple would be required to act in the best interests of the developer as principal.

658    Apple reserves to itself the right to use information it receives from developers on an unrestricted basis without notifying or compensating developers for such use, and is entitled under the DPLA to compete with developers in connection with the developer’s apps.

659    Contrastingly, developers are prevented from gathering data from the use of Apple services, which are defined to include Apple’s distribution services, and Apple does not provide developers with user and device data that relates to a developer’s own app.

660    When a user seeks a refund from the developer, Apple reserves to itself the exclusive right unilaterally to decide whether to grant a refund, and the developer is liable to reimburse Apple if any refunds are granted. Apple may issue a refund in respect of any payment made by a user within the first 90 days after download of an app, or where a user complains that an app fails to conform to the app’s specifications, warranty or any applicable law.

661    Contrastingly, developers are prohibited from issuing refunds to users, and therefore have no avenue of recourse if a refund is issued by Apple on questionable grounds.

662    Let me go into a little more detail at this point.

663    The formal parties to the schedule 2 agreement are the app developer and Apple Inc. Now Apple Pty Ltd is referred to with respect to activities in Australia (clauses 1.1 and 1.3 of schedule 2). But in my view that does not make it a contractual party as such. The prefatory words to schedule 2 make it clear that it is an addendum to the DPLA with no addition of Apple Pty Ltd as a contracting party as such.

664    The app developer must appoint Apple Inc. and Apple Pty Ltd jointly as the developer’s agent for the marketing and delivery of the developer’s app (“Licensed Application”) through the Australian App Store to end-users located in Australia (clauses 1.1 and 1.3 of schedule 2 agreement; and see exhibit A).

665    Apple Inc. and Apple Pty Ltd are instructed to provide marketing, hosting, downloading and invoicing services to the developer subject to the terms of the DPLA in order to allow end-user access to the developer’s app (clause 1.2 of schedule 2).

666    Accordingly, the provision of services by Apple Pty Ltd under the schedule 2 agreement incorporates a requirement that the app developer comply with the terms of the DPLA if the developer wishes that Apple Pty Ltd continue providing those services. A substantially identical arrangement exists under the schedule 1 agreement in relation to apps distributed by Apple Inc. and Apple Pty Ltd on the App Store free-of-charge.

667    It is a condition of the DPLA, and of the licence to use iOS, that any application submitted to the App Store must comply with the “documentation” and “program requirements” as defined (clauses 3.2(c), 3.3 and 6.9). The documentation and program requirements may change from time to time, but at all relevant times have included the App Store review guidelines. So, as a term of the DPLA, all developers who choose to make apps available through the App Store must comply with those guidelines.

668    As I have indicated, a consequence of the requirement that a developer enter into at least one of the schedule 1 and the schedule 2 agreements, is a relationship of forced agency. The developer must appoint Apple Inc. and Apple Pty Ltd as its agent for the marketing and delivery of its iOS app.

669    Apple Inc. reserves to itself the right to select, in its sole discretion, which iOS apps will be distributed on the App Store (clause 3.2(g)) and, thus, which apps will be available to iOS device users. It also reserves to itself the right to cease offering an iOS app for download at any time without cause (clause 7.3 of schedule 2).

670    Further, under the forced agency, Apple assumes for itself the right to collect the prices paid by iOS device users for apps or digital in-app content (clause 3.1 of schedule 2).

671    Apple will only remit the amount received from iOS device users, after deducting its commissions, within 45 days after the end of the monthly period in which the payment was received (clause 3.5 of schedule 2). It also assumes the exclusive ability to offer refunds to iOS device users (clause 3.4 of attachment 2 to the DPLA).

672    Under the schedule 2 agreement, Apple Inc. and Apple Pty Ltd are entitled to specified commissions for their services as the developer’s agent under the schedule 2 agreement (see clauses 3.4 to 3.6 of schedule 2).

Other matters and relevant clauses

673    Apple Inc. does not permit app developers to negotiate any of the terms of the developer agreement, DPLA, the schedule 1 agreement, the schedule 2 agreement or the App Store review guidelines.

674    Further, Apple Inc. reserves to itself the ability to amend the terms of the Apple agreements and the App Store review guidelines at any time (clause 9 of the developer agreement; clause 4 of the DPLA; and see the introduction of the App Store review guidelines (“This is a living document; new apps presenting new questions may result in new rules at any time”).

675    Under clause 7.6 of the DPLA, a developer is required to agree to distribute its iOS apps only in accordance with the terms of the DPLA. As such, a developer wishing to distribute its iOS app may only do so by appointing Apple as its agent, on whose discretion the developer relies to select its app for distribution, to do so through the App Store.

676    The building and testing of apps is facilitated by certain software tools that Apple provides to approved developers under the developer agreement and the DPLA. The DPLA contains distinct provisions that govern the rights and licences conferred on developers in relation to the use of these tools and the development and testing of iOS compatible apps. There is an annual program fee that is payable by developers participating in the developer program as consideration for the rights and licences granted to them under the DPLA (clause 8 of the DPLA).

677    Apple requires developers to use IAP for in-app purchases of digital content within iOS apps. That obligation does not arise under the licence conferred by the DPLA, but is instead specified by Apple under the App Store review guidelines which I will discuss in a moment.

678    Developers are prohibited from using IAP for in-app purchases in respect of physical goods and services and must use an alternative payment solution in those circumstances.

679    The developer must not issue any refunds to end-users and agrees that Apple may issue refunds to end-users in accordance with the terms of schedule 2 (clause 3.4 of attachment 2).

680    Further, if a developer chooses to require a payment to download the app or for in-app purchases of digital goods and services including subscriptions, then schedule 2 of the DPLA applies (clause 7.2). The developer elects which country-specific App Store storefronts will be used for distribution.

681    Further, under both schedules 1 and 2, the developer appoints an Apple entity as the developer’s agent for the marketing and delivery of their apps in each of their selected App Store storefronts (clause 1.1 of schedule 1 and exhibit A; clause 1.1 of schedule 2 and exhibit A).

682    The particular Apple entity appointed depends upon the region in question. A developer whose app is distributed through the Australian and US storefronts of the App Store appoints Apple Pty Limited as agent for the purposes of Australia and Apple Inc as agent in the US.

683    Schedule 2 provides for Apple to be paid a headline 30% commission for all sales of apps and any digital content, functionality or service offered in the app. That is subject to various exceptions, including the small business program.

684    This is in addition to the annual “Program Fee” which a developer agrees to pay under clause 8 of the DPLA. The program fee is the fee set forth on the Apple developer program website (see clause 8). It is currently USD 99 per year. For developers who are also subject to schedule 2, because they charge for download of their app and/or for in-app content, the commissions on such transactions are payable in addition to the program fee.

685    Under clause 3.5 of schedule 2 to the DPLA Apple has up to 45 days from the close of each month to remit funds to developers.

686    Now I agree with Apple that this is not an unreasonable arrangement and Apple has a legitimate business interest in giving itself the flexibility that is afforded by these arrangements. Apple is dealing with a vast number of developers and apps, and revenue from a vast array of sources. It assumes obligations on behalf of developers to deal with collecting and paying sales tax, and it also assumes responsibility for dealing with refund requests from users.

687    Apple’s right, under clause 6.3 of schedule 2 to the DPLA, to make refunds to users, and where necessary to require the developer to reimburse or grant Apple a credit for the amount refunded, is reasonable and appropriate.

688    Centralised handling of refunds is an important feature of a platform when it comes to offering users a seamless and trustworthy experience. Epic’s own distribution agreement with developers who use the Epic Games Store also gives Epic the discretion to issue refunds, rebates and credits to customers and provides that they will deducted from the developer’s revenue.

689    Under clause 7.3 of schedule 2 to the DPLA, Apple may cease marketing and cease distribution of apps at any time, with or without cause, by providing notice of termination.

690    Given the responsibility that Apple assumes for the safety and integrity of the platform and apps distributed through the App Store, this is an appropriate power to be held by Apple.

691    Clause 4 of the DPLA provides that Apple may change at any time the program requirements or the terms of the DPLA.

692    Now I agree with Apple that given the context in which the DPLA operates, there is nothing inherently unfair about the flexibility that is conferred on Apple by this clause. Through the terms of the program requirements and the DPLA, Apple maintains technical and content standards across the Apple ecosystem, including to deal with dynamic software security, performance and integrity issues. Moreover, as the clause provides, new or modified program requirements will not apply to apps already in distribution via the App Store, although Apple reserves the right to remove apps from the App Store for non-compliance with new or modified program requirements.

693    Clause 9 of the DPLA provides protection to Apple against potentially time consuming and vexatious disputes about the confidentiality of information that has been submitted by developers. Apple by that clause expressly disclaims any confidentiality obligations or use restrictions with respect to any information provided by a developer, including in respect of its apps. Clause 9.3 states that this disclaimer is “[t]o avoid potential misunderstandings”.

694    Despite acting as the developers’ agent, Apple reserves to itself under clause 9.3 of the DPLA the right to use information it receives from developers without notifying or compensating developers for such use. But presumably this right could only be exercised for the proper purposes of the DPLA and the transactions contemplated rather than any extraneous purpose.

695    Contrastingly, and as I have already mentioned, app developers are prevented from gathering data from the use of Apple services, which are defined to include Apple’s distribution services, and Apple does not provide developers with user and device data that relates to a developer’s own app (clause 2.6 of the DPLA, clause 2 of exhibit D of schedule 1; clause 2 of exhibit E of schedule 2).

696    Clause 14.4 of the DPLA provides that nothing in the DPLA will impair Apple’s right to “develop, acquire, license, market, promote, or distribute products or technologies that perform the same or similar functions as, or otherwise compete with, Licensed Applications, Covered Products, Corresponding Products or any other products or technologies that You may develop, produce, market, or distribute”. I agree with Apple that that is a prudent and reasonable protection in the context of the arrangements regulated by the DPLA. Apple has, from the invention of the iPhone, developed and distributed its own apps. It has never sacrificed its right to continue doing so, notwithstanding that it has assumed the role of curating the App Store and accepting responsibility for reviewing the content, performance and integrity of third party apps. As Apple correctly points out, clause 14.4 avoids any implications arising that might cut across those accepted arrangements.

697    Clause 14.10 of the DPLA is an exclusive jurisdiction clause. I agree with Apple that this is an unremarkable clause in an international agreement of this kind for a company headquartered in California that is dealing with numerous developers from jurisdictions around the world. In my view it is not unreasonable for developers to abide by such an arrangement in circumstances where they are wishing to take advantage of Apple’s services.

The App Store review guidelines

698    The DPLA provides that, by submitting an app for consideration for distribution via the App Store, the developer warrants that the app complies with all requirements specified by Apple and any additional guidelines that Apple may post to the developer portal or App Store Connect which is a platform used by developers to submit their apps for review.

699    The App Store review guidelines are the primary source of requirements to be complied with. Schedules 1 and 2 of the DPLA confirm that Apple may remove apps from the App Store at any time, including where the developer has breached the guidelines.

700    Section 1 of the guidelines deals with safety. The content of that part of the guidelines indicates the breadth of that concept from Apple’s perspective.

701    Section 1.1 of the guidelines sets out various examples of objectionable content that should not be included within apps. The general description of objectionable content is that which is “offensive, insensitive, upsetting, intended to disgust, in exceptionally poor taste, or just plain creepy”. Specific examples include defamatory content, discriminatory content or racially targeted commentary, depictions that encourage illegal or reckless use of weapons and dangerous objects, overtly sexual or pornographic material, false information and features, including inaccurate device data, and harmful concepts which capitalise or seek to profit on recent or current events, such as violent conflicts, terrorist attacks and epidemics.

702    Section 1.2 provides that apps with user-generated content or social network services must include certain filters and mechanisms to filter and deal with offensive content and abusive users.

703    Section 1.3 deals with a specific category of apps called the “Kids Category” which is described as a way for people to easily find apps that are designed for children. Such apps must not include links out of the app, purchasing opportunities, or other distractions to children unless reserved for a designated area behind a parental gate.

704    Section 1.4 provides that Apple may reject an app if it behaves in a way that risks physical harm. Examples include medical apps that could provide inaccurate data or information, apps that encourage consumption of tobacco and vape products, illegal drugs, or excessive amounts of alcohol, and apps that urge customers to participate in activities or use their devices in a way that risks physical harm to themselves or others.

705    Section 1.6 requires that apps should implement appropriate security measures to ensure proper handling of user information collected pursuant to the DPLA and the guidelines and prevent its unauthorised use, disclosure or access by third parties.

706    Section 2 of the guidelines deals with “Performance” of apps. That includes requirements as to the presentation of apps on the App Store.

707    Section 2.3 provides that customers should know what they are getting when they download or buy an app, so the developer should ensure that all app metadata, including privacy information, app description, screenshots, and previews accurately reflect the app’s core experience and are kept up to date with new versions.

708    Section 2.3.1 provides that an app should not include any hidden, dormant or undocumented features. So, the functionality has to be clear to end users and the app review process. Section 2.3.1 also provides that marketing an app in a misleading way is grounds for removal of the app from the App Store and termination of the developer’s account. Examples given include promoting content or services that the app does not actually offer, or promoting a false price whether within or outside of the app.

709    Section 2.3.2 provides that if an app includes in-app purchases the developer should ensure that the app description, screenshots and previews clearly indicate whether any featured items, levels, subscriptions etc require additional purchases. Developers promoting in-app purchases on the App Store have to follow the guidance in the separate publication “Promoting Your In-App Purchases” and must ensure that the app properly handles the “SKPaymentTransactionObserver method” so that customers can “seamlessly complete the purchase when your app launches”.

710    Section 2.5 contains various software requirements, including the following.

711    First, apps may only use public APIs and must run on the currently shipping operating system.

712    Second, apps should be self-contained in their bundles and may not read or write data outside the designated container area, nor may they download, install or execute code which introduces or changes features or functionality of the app, including other apps.

713    Third, apps that transmit viruses, files, computer code, or programs that may harm or disrupt the normal operation of the operating system and/or hardware features will be rejected.

714    Fourth, apps that alter or disable the functions of standard switches, such as volume switches or other native user interface elements or behaviours, will be rejected.

715    Fifth, apps must request explicit user consent and provide a clear visual and/or audible indication when recording, logging, or otherwise making a record of user activity. This includes any use of the device camera, microphone, screen recordings or other user inputs.

716    Section 3 of the guidelines relates to business activities of apps. The introductory section explains that while pricing is up to the developer, Apple will not distribute apps and in-app purchase items that are clear rip-offs. This includes rejecting apps that try to cheat users with irrationally high prices. Further, if Apple finds that a developer has attempted to manipulate reviews, inflate its chart rankings with paid, incentivised, filtered or fake feedback or used third party services to do so, Apple will take steps to preserve the integrity of the App Store, which may include expelling the developer from the Apple developer program.

717    Under section 3.1.1, if the developer wants to unlock features or functionality within the app such as subscriptions, in-game currencies, game levels, access to premium content or unlocking a full version it must use in-app purchase. Any credits or in-game currencies purchased via in-app purchase may not expire, and the developer has to ensure that there is a restore mechanism for any restorable in-app purchases.

718    Further, apps offering “loot boxes” or other mechanism that provide randomised virtual items for purchase must disclose the odds of receiving each type of item to customers prior to purchase.

719    In relation to auto-renewing subscriptions, section 3.1.2 provides that the developer must provide ongoing value to the customer, and the subscription period must last at least seven days and be available across all of the user’s devices. Other specific conditions for such offerings include the following. Subscriptions must work on all of the user’s devices where the app is available. Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content or use of the app. Further, a user should be able to get what they have paid for without performing additional tasks, such as posting on social media, uploading contacts or checking in to the app a certain number of times. Further, apps that attempt to scam users will be removed from the App Store. This includes apps that attempt to trick users into purchasing a subscription under false pretences or engage in bait-and-switch and scam practices.

720    Section 3.1.3 contains a series of exceptional categories where apps may use purchase methods other than in-app purchase. In these cases, users cannot be encouraged within the app to use a purchasing method other than in-app purchase except as permitted.

721    But developers are expressly permitted to send communications outside of the app to their user base about purchasing methods other than in-app purchase. The exceptional categories include reader apps, multiplatform services, enterprise services, person-to-person services, and goods and services outside of the app.

722    For physical goods and services that an app enables to be purchased, to be consumed outside of the app, a developer must use purchase methods other than in-app purchase to collect payments, such as Apple Pay or traditional credit card entry.

723    Section 3.2.2. sets out certain business models for apps that are unacceptable. One is creating an interface for displaying third-party apps, extensions, or plug-ins similar to the App Store or as a general-interest collection. Another is monetising built-in capabilities provided by the hardware or operating system, such as the camera.

724    Section 3.2.2(vi) provides that apps should allow a user to get what they have paid for without performing additional tasks, such as posting on social media. Apps should not require users to rate the app, review the app, enable tracking or take other similar actions in order to access functionality, content, use the app or receive monetary or other compensation.

725    Section 3.2.2(ix) provides that apps offering personal loans must clearly and conspicuously disclose all loan terms and cannot charge an annual percentage rate of higher than 36%.

726    Section 5 deals with legal issues and also contains a series of rules relating to privacy.

727    All apps must include a link to their privacy policy, including within the app in an easily accessible manner. The privacy policy must clearly and explicitly deal with certain matters, including identify what data, if any, the app/service collects, how it collects that data and all uses of that data. It must also explain the data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data.

728    Apps that collect user or usage data must secure user consent for the collection, even if such data is considered to be anonymous at the time of or immediately following collection. Apps must also provide the customer with an easily accessible and understandable way to withdraw consent.

729    Further, there is imposed a data minimisation principle. Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task.

730    Further, apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access.

731    Further, unless otherwise permitted by law a developer may not use, transmit, or share someone’s personal data without first obtaining their permission.

732    Further, there is a requirement that apps only include content that the developer has created or has a licence to use. Developers are also encouraged to notify Apple if they believe their intellectual property has been infringed by another developer.

733    Further, there is set out a general developer code of conduct in section 5.6, one aspect of which is that apps should never prey on users or attempt to rip off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app. Non-compliance with the developer code of conduct may lead to termination of a developer’s account in the Apple developer program.

734    Now Epic complains that Apple has enforced the guidelines inflexibly and refuses to accommodate the needs of even the largest developers. In my view, as a general proposition that is largely true. I do not need to go into any detail on this aspect for the moment.

Apple’s intellectual property — access and use by developers

735    As Apple has pointed out, it has spent USD 101 billion on research and development between 2005 and 2020. It has pointed to the following matters which I agree with unless I state otherwise.

736    That investment has resulted in the development of an extensive portfolio of technology, intellectual property and other intangible assets, including Apple’s brand.

737    Apple’s brand value represents the accumulated value of Apple’s marketing investments over many years and the goodwill that arises from its reputation for high quality products and emphasis on ease of use, privacy and security.

738    The App Store can operate because Apple permits third parties to use certain of Apple’s tools, technologies and supporting intellectual property. Apple is the registered owner of a large portfolio of patents and copyright works.

739    In order to distribute native apps and digital in-app content on iOS devices, third parties require permission to access and use a suite of tools and technology offered by Apple, supported by Apple’s intellectual property.

740    This is the essence of the legal and commercial relationship embodied in the DPLA. The DPLA offers developers a variety of tools, services and rights to use Apple’s associated intellectual property.

741    By giving developers access, on the terms of the DPLA, to Apple’s tools, technology and supporting intellectual property, developers can make such use of Apple’s property, services and support to develop and distribute native apps through the App Store.

742    I agree with Apple that the use of its property is essential. It is not practical for a developer to develop native apps for iOS without using at least some of Apple’s SDKs and the more than 250,000 APIs that are available to developers.

743    Ultimately the commercial essence of the relationship is the flexibility of the general access that is granted to developers through Apple’s developer program and the legal rights conferred by the DPLA.

744    Except where legally compelled to do so by certain local laws, as is now the case in the EU, Apple has never permitted third parties to use Apple’s technologies, tools, services, and intellectual property rights, or granted licences, to enable the distribution of third-party app stores on iOS, direct downloading of iOS apps from websites or the conduct of in-app transactions for digital content outside of Apple’s commerce engine.

745    These points assume significance for each of the forms of access that have been envisaged in the present matter as a means of decentralised distribution of apps, namely, the downloading of a third-party app store app through the App Store itself, the downloading of a third-party app store app from the website of the alternative store provider and the downloading of a third-party app directly from a developer’s website.

746    In each case the process cannot occur without access to Apple property.

747    Now Apple is the registered owner of a very large portfolio of patents and copyright works. This includes more than 24,000 US patents, 1,500 Australian patents and 5,000 US registered copyright works.

748    Apple’s patents protect inventions relating to the App Store and app distribution and development, including development tools and features accessible to developers through APIs.

749    Apple’s Xcode integrated development environment (Xcode IDE) provides developers with software features that are necessary to design, develop and debug software for use on iOS. Copyright notices for Xcode are in evidence.

750    An SDK is a collection of software development tools in one package which facilitates the creation of applications. The SDKs include necessary tools, such as the code compiler and linkers. It is not practical for a developer to develop native apps for iOS without using Apple’s SDKs.

751    Apple has more than 250,000 APIs that are available to developers. It is virtually impossible to develop a native app for iOS without using at least some of these APIs.

752    The SDKs and APIs that were originally created to facilitate third-party native apps being developed and distributed on iOS were the product of work by Apple’s software engineering teams.

753    Ms Jacqueline Harlow, principal counsel and senior manager, IP transactions at Apple gave the following evidence.

754    As at the date of her written evidence, Apple was listed as the registered owner of the following: 5,000 registered US copyrights; 24,000 US utility patents and 3,500 US design patents; 4,000 US utility patent applications; 1,500 Australian patents and 700 Australian design registrations; 200 Australian patent applications and hundreds of unpublished US and Australian design applications.

755    Now through Apple’s developer program, Apple provides developers limited licences to a broad array of proprietary Apple technologies and services, underlying which are various Apple IP rights.

756    For example, Apple registers the copyrights in its key software products including iOS, iPadOS, watchOS, and macOS. Copyright also protects Apple’s unregistered works, including SDKs, APIs, and other software products and tools. Apple registers copyrights as the first step to enforce Apple’s rights against copyright infringers.

757    Additionally, Apple files patent applications and obtains patents to protect inventions relating to iOS, iPadOS, watchOS, macOS, App Store, and app distribution and development, including development tools and features accessible by developers through APIs. These inventions allow developers to quickly build apps with advanced user interactions and features and to easily distribute and maintain those apps on customer devices.

758    In order to access Apple’s proprietary technologies or services a developer must first enter into certain agreements with Apple, including a developer agreement and the DPLA.

759    These agreements, together with software specific agreements that govern the download or use of particular Apple technologies, tools, and services, and Apple’s published guidelines for using Apple trademarks and copyrights, define how developers may access or use Apple’s proprietary technologies.

760    Now as I have already indicated, in order to access or use Apple’s proprietary technologies and services for advanced application development and distribution, a developer must enter into Apple’s DPLA in addition to the developer agreement.

761    Further, under the Digital Markets Act Apple is obliged in the EU to facilitate novel forms of third-party access. This has required Apple to develop more intellectual property-protected technologies, tools and services. So, to comply with the legal requirements of the Digital Markets Act Apple has created a new API called “MarketplaceKit” that allows alternative app marketplaces to operate on iOS and facilitates the secure installation of apps distributed from such an alternative app marketplace, by enabling the marketplace’s web server to directly interface with iOS.

762    Let me deal with another topic concerning Epic’s use of Apple’s intellectual property and/or Apple’s confidential information.

763    In evidence is a copy of Epic’s responses and objections to Apple’s first set of interrogatories dated 11 December 2020 filed in case No. 4:20-cv-05640-YGR-TSH brought by Epic against Apple in the US District Court for the Northern District of California.

764    These responses have been tendered and received by me as admissions made by Epic.

765    Epic stated in response to interrogatory number 6 the following matters.

766    First, Apple has over 250,000 APIs that are available to developers and it is virtually impossible to develop an app for, or a toolset for development on, iOS or macOS without them. Epic has used thousands of Apple’s APIs for the development of the Fortnite apps for iOS or macOS. Epic has incorporated APIs that are related to a relatively constant set of frameworks in the iOS and macOS versions of Fortnite.

767    Second, in the iOS version of Fortnite, Epic has used APIs from the following frameworks in the game’s executable code: AdSupport, AudioToolbox, AVFoundation, Cloudkit, CoreAudio, CoreGraphics, CoreMedia, CoreMotion, Core Video, DeviceCheck, Foundation, GameControfler, GameKit, iAD, MediaToolbox, Metal, MultipeerConnectivity, QuartzCore, SafariServices, Security, StoreKit, SystemConfiguration, UIKit, UserNotifications, WebKit and Video Toolbox.

768    Third, in the macOS version of Fortnite, Epic has used APIs from the following frameworks in the game’s executable code: AppKit, AudioToolbox, AudioUnit, AVFoundation, Carbon, CFNetwork, Cocoa, CoreAudio, CoreFoundation, CoreGraphics, CoreMedia, CoreMIDI, CoreServices, CoreVideo, Foundation, IOKit, MediaToolbox, Metal, OpenGL, QuartzCore, Security and VideoToolbox.

769    Fourth, in addition, due to dependency on the third-party Chromium Embedded Framework and Vivox libraries, Epic has indirectly used APIs from the following frameworks: Accelerate, AddressBook, Applicationservices, CoreText, Core WLAN, DiskArbitration, GameController; IOBluetooth, IOSurface, lmageCaptureCore, lmageIO, Quartz, Security Interface, and SystemConfiguration.

770    Fifth, Epic has used Apple’s ARkit framework for internal experimentation and demonstrations, but has not used it for the development of either the iOS or macOS versions of Fortnite.

771    Sixth, like most platform providers, Apple makes certain software development tools widely available to developers like Epic that make apps intended to run on iOS and macOS devices. These tools come in the form of device-specific SDKs. Epic has used the iPhone, iPad and Mac SDKs to develop the iOS and macOS versions of Fortnite. Just like with Apple’s APIs, it is not practicable for a developer to develop iOS or macOS compatible apps without using Apple-issued SDKs.

772    Seventh, Apple’s core tool is the Xcode IDE, which provides developers the software features that are necessary to design, develop, and debug software for use on iOS and macOS. Epic has used the Xcode IDE for writing and debugging code when working on the iOS and macOS versions of Fortnite. Epic also has used other tools included with the Xcode IDE to measure the performance of Fortnite, install builds of Fortnite on development devices, and upload builds of Fortnite to Apple’s Appstore Connect for distribution.

773    Eighth, Apple’s SDKs also include other tools that are necessary to develop apps for iOS and macOS devices, including the compiler and linkers. Epic has used these tools to develop the iOS and macOS versions of Fortnite.

774    Ninth, a few people at Epic have also had access to Apple’s internal bug reporting system, Radar. Apple has the ability to use Radar to report to Epic bugs in Fortnite and also to request that Epic add features to the iOS and macOS versions of Fortnite. Epic has used Radar to report to Apple bugs in iOS and macOS, such as certain problems Epic identified with the Metal drivers, and to request that Apple add features to its operating systems.

775    Tenth, due to the technical restrictions that Apple has placed on the distribution of iOS apps, Epic has used Apple’s TestFlight to perform pre-release testing of the iOS version of Fortnite.

776    Eleventh, in order for an app to run on an iOS device, it must be signed with a certificate issued by Apple. The type of certificate depends on how the developer intends to distribute its app. For the purposes of developing and testing iOS apps prior to wider distribution, Apple makes available several types of certificates to developers. Development or ad hoc certificates allow a developer to distribute an iOS app to a limited number of pre-approved devices.

777    Twelfth, if a developer wishes to beta test its app with a larger user base (up to 10,000 test devices), then it must use Apple’s TestFlight service. Epic has uploaded pre-release builds of the iOS version of Fortnite to TestFlight to perform broader pre-release testing among its employees and contract staff.

778    Thirteenth, Epic regularly discussed with Apple engineering issues related to Fortnite, including in connection with Apple’s Consultation Labs program. Epic and Apple held weekly conference calls to discuss existing engineering issues as well as anticipated issues with Apple’s pre-release software such as beta OS and/or Xcode that was made available to Epic through Apple’s developer program. These calls covered the following Fortnite-related topics: discovery and resolution of graphics driver bugs in iOS and macOS; memory usage and bugs affecting Epic’s ability to implement and support iOS and macOS features; investigation into rendering issues in Fortnite caused by Apple’s Metal software; and Epic’s testing and providing feedback on Apple developer tools.

779    Fourteenth, Epic staff would sometimes physically visit Apple to investigate issues and to test and troubleshoot Fortnite on Apple’s pre-release software. Epic’s on-site visits focused on improving the Apple toolchains and leveraging Apple’s internal tools on current hardware to debug performance and/or stability issues with Fortnite, which were frequently caused by issues with Apple’s software. Epic staff also visited Apple for support with debugging crashes in Fortnite nested within Apple’s Metal rendering code.

780    Fifteenth, in connection with migrating Fortnite to Xcode 11 and the corresponding reduction in available memory resources for the game, Epic and Apple worked closely together through on-site visits to Apple, weekly conference calls and email communications.

781    Sixteenth, Epic’s visits to Apple were dedicated to measuring rendering memory allocation with Apple’s tools, discovering and reporting bugs with Apple’s tools, and optimising Fortnite’s rendering memory footprint without degrading the graphical quality of the game.

782    Seventeenth, the weekly conference calls and emails focused on providing progress updates and investigating, reporting, and troubleshooting bugs that the Epic and Apple teams encountered.

783    Clearly and in summary, Epic has used the SDKs, APIs and development tools licensed by Apple to Epic under the DPLA for the purpose of developing iOS apps. Epic used the Xcode IDE for writing and debugging code when working on the iOS version of Fortnite. Epic also used other tools included with the Xcode IDE to measure the performance of Fortnite, install builds of Fortnite on development devices and upload builds of Fortnite for distribution. Epic used Apple’s iPhone and iPad SDKs to develop the iOS version of Fortnite, including the code compiler and the linkers that are included in the SDKs. Epic used thousands of Apple’s APIs in the development of the Fortnite apps for iOS and macOS. In the iOS version of Fortnite, Epic used Apple APIs from 26 frameworks in the game’s executable code.

784    That means that the use of Apple’s software is not confined to the development phase of Fortnite. Code written and owned by Apple is downloaded when a customer downloads Fortnite and used when the customer plays Fortnite.

785    The following frameworks that are specific to iOS were used by Epic in the development of Fortnite for iOS: the AdSupport framework; the Cloudkit framework, being the collection of APIs that allow an application to store files in a user’s Apple cloud storage; the CoreMotion framework, being a collection of APIs that pertain to the iOS device’s gyroscope and orientation; the DeviceCheck framework, being an API that allows developers to offer a one-time free trial to users; the GameKit framework, being a collection of APIs that provide social matchmaking for games and for users; the iAD API framework, being APIs typically used in advertising, including to uniquely identify users; the MultipeerConnectivity framework, being a collection of APIs that allow an app to detect when there is an iOS user with the same app nearby; and the SafariServices framework, which allows a user to log into the app.

786    Each of those frameworks contains multiple APIs.

787    Epic has used Apple’s TestFlight software to perform pre-release testing of the iOS version of Fortnite. Copyright notices for TestFlight are in evidence.

Epic’s arguments

788    Let me set out Epic’s arguments.

789    Epic says that Apple has not identified, whether in its pleading or otherwise, the nature and scope of any intellectual property rights which it says are the subject of a licence granted under the DPLA, nor how developers exploit any such rights in relation to the relevant aspects of the App Store’s operation, being app distribution and payment services.

790    Further, to the extent that it might be inferred that Apple has some particular but not precisely identified intellectual property rights in SDKs or other software, Epic says that it has been placed at a disadvantage in meeting and testing Apple’s contention that it has exclusive control over the markets for which Epic contends by virtue of Apple’s intellectual property rights.

791    Now the only direct witness evidence of Apple’s intellectual property rights comes from Ms Harlow and Mr Schiller. But Epic says that this was all very vague.

792    Now Epic accepts that the DPLA confers a licence on a developer to use, inter-alia, iOS and various software tools that Apple makes available for the development and testing of iOS apps.

793    But Epic says that Apple has adduced no evidence identifying the specific subset of intellectual property rights within its intellectual property portfolio which it says are the subject of this licence.

794    Epic says that whilst Ms Harlow said that Apple files patent applications and obtains patents to protect inventions relating to iOS, iPadOS, watchOS, macOS, App Store and app distribution and development, including development tools and features accessible by developers through APIs, she did not identify those patents and patent applications or any specific rights that they confer.

795    Further, Epic says that Apple has not adduced any evidence of the specific works in which copyright is claimed to subsist.

796    Epic says that although Ms Harlow asserted that copyright also protects Apple’s unregistered works, including SDKs, APIs and other software products and tools, and she exhibited copyright notices for Xcode and Testflight, she did not provide evidence of any copyrighted works.

797    Similarly, Epic says that Mr Schiller mentioned the brand names of certain tools which Apple has developed for, and provided to, app developers, such as Xcode, SpriteKit, Metal, ARKit and Core ML. Epic says that the mere identification of software by its brand name or the production of a copyright notice is thin evidence of the “literary work” in which copyright is alleged to subsist. It says that to enable me to determine the existence and scope of any exclusive rights conferred on Apple as copyright owner so that I might properly evaluate Apple’s submission as to the artificiality of the markets for which Epic contends, it was necessary for Apple to identify and prove both the works in which copyright is relevantly alleged to subsist with greater specificity, and the precise ways in which Apple alleges that developers have substantially reproduced those works.

798    Moreover, as to Apple’s APIs, Epic says that it is an open question under Australian law whether APIs are capable of being protected by copyright. Further, the position in the United States is also not settled. In the US Supreme Court decision in Google LLC v Oracle America., Inc. 593 U.S. 1 (2021), the Court did not decide whether APIs for the computer language Java were capable of attracting copyright protection.

799    In that case, Oracle claimed that Google had infringed its copyright by use of 37 API packages used in Google’s Android platform for its smartphones. Google had copied around 11,500 lines of Java code used in those APIs. The Java code that Google took was declaring code, which is the part of an API that organises and declares or identifies pre-written functions and tasks so that the API can communicate with other software. Other code in an API called implementing code performs the tasks. At first instance, the District Court for the Northern District of California found that the declaring code was not copyrightable as a matter of law. But on appeal, the United States Court of Appeals for the Federal Circuit (Oracle America, Inc v Google Inc 750 F.3d 1339 (2014)) found that APIs can be protected by copyright.

800    The Supreme Court overturned that decision on the basis that Google was entitled to take declaring code under the principles of fair use. But the majority did not rule on the Court of Appeals’ finding as to whether copyright subsists in APIs, and did not address the question of whether this type of code is copyrightable.

801    Now Epic says that although Australian law might recognise that copyright can subsist in relation to a subset of specific statements or instructions within a larger body of software, without any evidence from Apple about the works in which copyright is alleged to subsist, I cannot be satisfied that Apple’s APIs meet the definition of “computer program” in s 10(1) of the Copyright Act 1968 (Cth) (the Act) or the threshold of originality.

802    Now as to how developers might relevantly be said to be exploiting Apple’s intellectual property rights, Epic says that the evidence adduced by Apple does not illuminate that question in relation to the relevant aspects of the App Store’s operation, namely, app distribution and payment services. Epic says that Apple could have, but did not, adduce adequate, or in some cases any, probative evidence on this point.

803    Now as I have indicated earlier, Apple relies on Epic’s response to interrogatory number 6, in which Epic acknowledged various matters which I have set out. Apple says that the effect of this response is that Epic has incorporated computer code that is written and owned by Apple into the executable code that runs when the Fortnite app is used and that this is a continuing use of Apple’s intellectual property that occurs after the app is distributed every time the app is used. But Epic says that I should not accept that assertion.

804    Epic says that its response was given to an interrogatory that asked Epic to describe in detail Epic’s use of any services or tools provided by Apple to create, develop, maintain or update Fortnite. But Epic says that Apple cannot use that evidence to prove that Apple has intellectual property rights in any such computer code.

805    Further, Epic points out that Mr Grant, who verified Epic’s response to this interrogatory, was the only witness to give detailed evidence of Epic’s use of Apple’s Xcode IDE and Apple’s SDKs and APIs. Mr Grant’s evidence, which was not challenged in cross-examination, was relevantly as follows.

806    First, he said that to create the iOS-compatible Fortnite app, the Fortnite team at Epic used Xcode IDE, which offers a suite of Apple-specific SDKs and APIs for the development of apps on iOS and macOS. Xcode is the primary application for developers to author, test and run source code written for iOS and macOS apps on their devices. Apple makes it compulsory to use certain APIs in order to build certain functionality into an app. So, in order to support in-app purchasing on iOS, it was necessary for the Fortnite team to use the StoreKit API.

807    Second, he said that Xcode offers a set of tools and Apple-specific SDKs, containing APIs, for the development of apps on Apple platforms, including iOS and macOS.

808    Third, he said that developers can download Apple’s Xcode application to use the SDK for iOS app development and the SDK for macOS app development, and access Apple’s APIs through those SDKs.

809    Fourth, he said that an SDK generally provides access to the APIs necessary for writing an app for the relevant OS. APIs are sets of definitions and protocols that allow third-party app developers to program their apps to access and make use of OS-provided functionality. Effectively, APIs allow programs to interact with the OS.

810    Fifth, he said that for apps on any platform, including iOS and macOS, nearly all code that is contained within the app itself is provided by the developer.

811    Sixth, he said that during the development process of Fortnite’s native iOS app, under his supervision, Epic engineers used Apple’s SDK, APIs and development tools to create functionality specific to Fortnite running on iOS.

812    Seventh, he said that the vast majority of code within Fortnite’s iOS native app was previously written by Epic’s software engineers.

813    Eighth, he said that in order for Fortnite’s iOS native app to request services from iOS and/or functionality provided by an Apple library (through an API), the code that Epic’s engineers wrote referenced particular “headers” from Apple’s SDKs. In limited instances where a header itself contains code and specifies it to be an option, the compiler may opt to “inline” (that is, duplicate) that code within the app to improve performance. So, to enable users to play audio on iOS devices, Fortnite on iOS needed to reference headers that list the iOS APIs relevant to performing audio operations. The headers are often identical to the headers required to enable equivalent functionality via the same APIs available on macOS.

814    Ninth, he said that in developing Fortnite for iOS, under his supervision, Epic’s engineers needed to undertake further steps to implement certain APIs on Apple platforms. For example, Epic was required to write additional code to call the functions associated with Apple’s graphics API Metal, as the Metal API was provided for the programming language Objective-C, while the Fortnite code was written in C++.

815    Tenth, he said that when Epic released Fortnite on the App Store in 2018, Fortnite did not execute any code that referenced Apple’s APIs when it was being displayed within the iOS App Store, downloaded by a user from the iOS App Store or subsequently updated.

816    Eleventh, he said that in August 2020, Epic offered EDP as an alternative payment solution to Apple IAP for iOS users making in-app purchases within Fortnite. Apple’s iOS SDK and APIs were not used to implement that alternative payment solution.

817    Twelfth, he said that in addition to Xcode, there are a number of integrated development environments or platforms that can be used to develop apps for iOS and/or macOS, namely Microsoft Visual Studio and B4i. While an iOS app can be developed without using Xcode, in order to make an app available through the iOS App Store or macOS App Store, Apple requires developers to use the tools distributed with Xcode so that it is in a form that can be uploaded to Apple’s developer portal. He also said that distributing a macOS app through a third party app store (like the Epic Games Store) and/or through direct downloading only requires the use of Xcode for the notarisation process.

818    Now I accept that Mr Grant gave such evidence. Epic says that five points relevantly follow from that evidence.

819    First, Epic says that despite the fact that a developer of an iOS app has a theoretical choice as to whether to use the Xcode IDE in developing the app, in practice, if the developer wishes to distribute that app on the App Store, the developer has no real choice at all. If developers were able to distribute iOS apps using an alternative distribution channel, they would be able to use alternative development platforms, such as Microsoft Visual Studio.

820    Second, Epic says that the use of certain APIs by developers is mandated by Apple, such as in the case of the in-app purchase API, the requirement of which is a reflex of the impugned requirement that developers use IAP for in-app purchases of digital content. Those APIs, which are included in Apple’s SDKs, can only be accessed by developers by downloading Xcode.

821    Third, Epic says that even if APIs are capable of being protected by copyright, one could not be satisfied that the reference to or use of the API in creating the executable code of an iOS app would involve the incorporation of a substantial part of any Apple copyrighted work, such that the reproduction of that code, absent any licence from Apple, would be an infringement of any exclusive rights held by Apple.

822    Fourth, Epic says that there is no evidence that any code provided by Apple to developers is executed by an iOS app when the app is being displayed within the iOS App Store, downloaded by a user from the iOS App Store or subsequently updated. To the contrary, Epic says that Mr Grant’s evidence was that when it was available on the iOS App Store, Fortnite did not execute any code that referenced Apple’s APIs when it was being displayed within the iOS App Store, downloaded by a user from the iOS App Store or subsequently updated.

823    Accordingly, Epic says that there is no evidence that any code in which Apple intellectual property rights might subsist is relevantly used or exploited by developers in the course of iOS app distribution.

824    Fifth, Epic says that not only is there no evidence as to what Apple intellectual property rights subsist in or protect Apple’s IAP, there is no evidence that, absent the requirement in the DPLA that developers use IAP for in-app purchases of digital content within iOS apps, Apple’s iOS SDK and APIs would be used or exploited by a developer implementing an alternative payment solution for their iOS app.

Analysis

825    Now I must say that I do not accept many of Epic’s arguments.

826    Apple pointed out, correctly, that the licence in clause 2.1(a) of the DPLA is a licence to “install” copies of the “Apple Software” on Apple-branded products “to be used” for the purpose of developing or testing covered products including apps.

827    And as Apple points out, the installation of software on a computer including on an iPhone, iPad or Mac necessarily involves making a copy of the whole of the computer code that comprises the software. So, each time software is installed, there is a reproduction in material form of the whole of the code, within the meaning of s 31(1)(a)(i) of the Act.

828    Now clause 2.1(a) of the DPLA licenses installation of the “Apple Software” that is provided to the developer under the “Program”. “Program” is defined as “the overall Apple development, testing, digital signing, and distribution program contemplated by this Agreement.” So, the licence covers all software that Apple provides to developers under the program, even if it comes into existence after the developer executes the DPLA.

829    Let me move to another point.

830    Epic says that Apple has not led evidence to substantiate the existence of any intellectual property rights relevant to app distribution. But I agree with Apple that there is ample evidence identifying examples of copyright works that are “Apple Software”.

831    “Apple Software” is defined in the DPLA as:

Apple SDKs, iOS, watchOS, tvOS, iPadOS, visionOS, and/or macOS, the Provisioning Profiles, FPS SDK, FPS Development Package, and any other software Apple provides to You under the Program, including Updates thereto (if any) that may be provided to You by Apple under the Program.

832    Several of those terms are defined further in clause 1.2.

833    First, “Apple SDKs” is defined as:

Apple-proprietary Software Development Kits (SDKs) provided hereunder, including but not limited to header files, APIs, libraries, simulators, and software (source code and object code) labeled as part of iOS, watchOS, tvOS, iPadOS, or Mac SDK and included in the Xcode Developer Tools package for the purposes of targeting Apple-branded products running on iOS, watchOS, tvOS, iPadOS, and/or macOS, respectively.

834    Second, “iOS” is defined as “the iOS operating system software provided by Apple for use by You only in connection with Your Application development and testing, including any successor versions thereof.”

835    Third, “iPad OS” is defined as “the iPadOS operating system software provided by Apple for use by You only in connection with Your Application development and testing, including any successor versions thereof.”

836    In s 10(1) of the Act, “literary work” is defined to include a “computer program or compilation of computer programs” and “computer program” is defined as “a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result”.

837    I agree with Apple that numerous computer programs that fall within the definition of “Apple Software” are identified in the evidence.

838    First, as I have explained elsewhere, iOS is the iPhone operating system and the licence of iOS and iPadOS to users is in evidence. Moreover, as Apple says, this is not a copyright infringement case and there is no issue about the iOS code between the parties. I agree with Apple that it did not need to tender a copy of the iOS code to establish that there is a computer program called iOS, which is owned by Apple.

839    Second, the “Apple Software” is defined to include the “Xcode Developer Tools package”. A copyright notice for Xcode is in evidence, as are the terms and conditions that must be accepted before downloading Xcode, being the “Xcode and Apple SDKs Agreement”. In a copyright infringement action, a copyright notice is taken to prove ownership of copyright, unless the contrary is established (s 126B(2) of the Act). Xcode provides developers with software features that are necessary to design, develop and debug software for use on iOS.

840    The DPLA licences a computer program called Xcode, and Epic has used Xcode for writing and debugging code when working on the iOS version of Fortnite. Epic has also used tools included with Xcode to measure the performance of Fortnite, install builds of Fortnite on development devices and upload builds of Fortnite for distribution.

841    Third, the DPLA defines “TestFlight Application” as “Apple’s application that enables the distribution of pre-release versions of Your Applications to a limited number of Your Authorised Developers and to a limited number of Best Testers, as specified on the TestFlight developer website, through TestFlight”. “TestFlight” is defined as “Apple’s beta testing service for pre-release Applications made available through Apple’s TestFlight Application.”. A copyright notice for TestFlight is in evidence.

842    Epic has used Apple’s TestFlight software to perform pre-release testing of the iOS version of Fortnite. And a computer program called TestFlight is licensed by the DPLA.

843    Fourth, an SDK is a collection of software development tools in one package which facilitates the creation of applications. There is a definition of “Apple SDKs” in the DPLA as I have just set out.

844    The iOS and iPadOS SDKs are provided as part of the Xcode developer tools; see the definition of Apple SDKs in the DPLA and in the Xcode and Apple SDKs agreement. Accordingly, the copyright notice for Xcode applies to the iOS and iPadOS SDKs.

845    As Apple says, clearly there are computer programs or compilations of computer programs called the iOS SDK and the iPadOS SDK, as well as other SDKs, including ReplayKit, GameKit and StoreKit.

846    Epic has used Apple’s SDKs and APIs licensed under the DPLA for developing iOS apps. More specifically, Epic used Apple’s iPhone and iPad SDKs to develop the iOS version of Fortnite. Epic has also used other tools from Apple SDKs, including the compiler and linkers.

847    Fifth, an API is a software intermediary that allows applications to communicate with one another. As I have said, Apple has more than 250,000 APIs that are available to developers. And as Apple said, one cannot realistically develop a native app for iOS without using at least some of those APIs. Epic has used thousands of Apple’s APIs in the development of the Fortnite apps for iOS and macOS. One way in which an API can work is by the developer incorporating code from the API into the app’s code. Epic has used APIs from 26 frameworks in Fortnite’s executable code.

848    Mr Grant gave evidence about the function of the APIs in seven of those frameworks. As I have set out earlier, one has the Cloudkit framework, which is a collection of APIs that allow an application to store files in a user’s Apple cloud storage. One has the CoreMotion framework, which is a collection of APIs that pertain to the iOS device’s gyroscope and orientation. One has the DeviceCheck framework, which is an API that allows developers to offer a one-time free trial to users. One has the GameKit framework, which is a collection of APIs that provide social matchmaking for games and for users. One has the iAD API framework, which includes APIs typically used in advertising, including to uniquely identify users. One has the MultipeerConnectivity framework, which is a collection of APIs that allow an app to detect when there is an iOS user with the same app nearby. And one has the SafariServices framework, which allows a user to log into the app.

849    Another API discussed in the evidence is Metal, a powerful computer graphics API. Metal is one of the APIs that Epic has used in executable code of Fortnite for iOS. Apparently, Metal is superior to Google’s OpenGL API.

850    So, Apple makes hundreds of thousands of APIs available to developers. And I have no doubt that Epic has used thousands of them, including by incorporating code from certain specified APIs into Fortnite’s executable code.

851    Now Epic says that there is doubt that APIs are capable of being protected by copyright under Australian law. But in Australia, it is well established that a relatively short or simple piece of code can satisfy the definition of computer program in s 10(1) of the Act. Further, a command which, when executed, causes a sequence of other functions to be executed, can be a computer program for the purpose of the Act. Further, a software intermediary that facilitates communication between two applications can be seen as a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. Metal, being a computer graphics API, is capable of satisfying that description.

852    Further, in relation to Epic’s reproduction of code from certain Apple APIs in Fortnite’s executable code, it is self-evident that it satisfies the substantiality question.

853    In Hytera Communications Corporation Ltd v Motorola Solutions Inc (2024) 308 FCR 68; [2024] FCAFC 168, I together with O’Bryan and Rofe JJ said at [737] to [748]:

The question of substantiality is one of mixed law and fact in the sense that it requires the judge to apply a legal standard to the facts as found: Designers Guild Ltd v Russell Williams (Textiles) Ltd [2000] 1 WLR 2416 at 2423 (Lord Hoffman). To the same effect is the following statement of Wilson J in SW Hart v Edwards Hot Water Systems (1985) 159 CLR 466 at 482:

... the question whether there has been a reproduction is a question of fact and degree depending on the circumstances of each case. The emphasis upon quality rather than quantity directs attention to the significance of what is taken.

In Ladbroke, Lord Pearce stated the well-known test concerning “substantial part” as follows (at 293):

… Whether a part is substantial must be decided by its quality rather than its quantity. The reproduction of a part which by itself has no originality will not normally be a substantial part of the copyright and therefore will not be protected. For that which would not attract copyright except by reason of its collocation will, when robbed of that collocation, not be a substantial part of the copyright and therefore the courts will not hold its reproduction to be an infringement. It is this, I think, which is meant by one or two judicial observations that “there is no copyright” in some unoriginal part of a whole that is copyright. They afford no justification, in my view, for holding that one starts the inquiry as to whether copyright exists by dissecting the compilation into component parts instead of starting it by regarding the compilation as a whole and seeing whether the whole has copyright. It is when one is debating whether the part reproduced is substantial that one considers the pirated portion on its own.

…

In Data Access, the High Court considered the applicable principles in the context of computer programs. The plurality (at [83]) endorsed the approach taken by Mason CJ in dissent in Autodesk Inc v Dyason (No 2) (1993) 176 CLR 300 (Autodesk (No 2)) at 305. After quoting the above passage of Lord Pearce from Ladbroke, Mason CJ said (citations omitted):

… in the context of copyright law, where emphasis is to be placed upon the ‘originality’ of the work’s expression, the essential or material features of a work should be ascertained by considering the originality of the part allegedly taken. This is particularly important in the case of functional works, such as a computer program, or any works which do not attract protection as ends in themselves (eg, novels, films, dramatic works) but as means to an end (eg, compilations, tables, logos and devices).

The plurality in Data Access continued (at [84]-[86], citations omitted):

There is great force in the criticism that the “but for” essentiality test which is effectively invoked by the majority in Autodesk (No 2) is not practicable as a test for determining whether something which appears in a computer program is a substantial part of it. For that reason, we prefer Mason CJ’s opinion that, in determining whether something is a reproduction of a substantial part of a computer program, the “essential or material features [of the computer program] should be ascertained by considering the originality of the part allegedly taken”.

In order for an item in a particular language to be a computer program, it must intend to express, either directly or indirectly, an algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the “device having digital information processing capabilities”. It follows that the originality of what was allegedly taken from a computer program must be assessed with respect to the originality with which it expresses that algorithmic or logical relationship or part thereof. The structure of what was allegedly taken, its choice of commands, and its combination and sequencing of commands, when compared, at the same level of abstraction, with the original, would all be relevant to this inquiry.

That being so, a person who does no more than reproduce those parts of a program which are “data” or “related information” and which are irrelevant to its structure, choice of commands and combination and sequencing of commands will be unlikely to have reproduced a substantial part of the computer program. We say “unlikely” and not “impossible” because it is conceivable that the data, considered alone, could be sufficiently original to be a substantial part of the computer program.

The High Court affirmed those principles in IceTV which, like Ladbroke, was a case concerning a literary work that was a compilation of information. … On appeal, one of the questions for determination was whether the time and title information which was reproduced in the IceGuide constituted a “substantial part” of the weekly schedules so as to constitute infringement. In two separate judgments, the High Court unanimously answered that question in the negative.

In their joint judgment in IceTV, French CJ, Crennan and Kiefel JJ emphasised the relationship between the features and characteristics of the work that lead to the conclusion that the work was original for the purposes of subsistence of copyright, and the question of infringement.

…

Their Honours confirmed that, in order to assess whether material copied is a “substantial part” of an original literary work, it is necessary to consider not only the extent of what is copied, but also the quality of what is copied (at [30]) and that a factor critical to the assessment of the quality of what is copied is the “originality” of the part which is copied (at [32]). With reference to the facts and reasoning in Ladbroke, their Honours stated (at [37]) that “where the part reproduced did not originate with the author, so that the author would not have copyright in the part standing alone, the part reproduced will not be a substantial part”. Their Honours added, however, that the fact that a part reproduced originates from the author does not, of itself, mean that it is necessarily a substantial part of the whole work; originality in the context of infringement has a broader aspect (at [38]).

…

The principles elucidated in Ladbroke, Data Access and IceTV recognise that, within a work in which copyright subsists, different parts of the work may have different degrees of originality. The assessment of whether a part of the work that is copied is a substantial part for the purposes of the Copyright Act will be affected by the degree of originality in that part. At one end of the spectrum are copyright works that consist of a compilation of information, in respect of which (typically) there is no originality (and indeed no copyright) in the information that is compiled, and where the originality only resides in the form of compilation. In such a case, the copying of the information, but not the form of compilation, will not infringe copyright. At the other end of the spectrum are works that might be described as wholly original (whilst recognising that the vast majority of works have elements that are derivative of other work). When assessing, in such cases, whether a part of the work that is copied is a substantial part, it remains relevant to consider the degree of originality in that part; however, as explained in Data Access, originality of the part copied is assessed by reference to the essential or material features of the copyright work.

854    We also went on to say at [790] to [794]:

The plurality judgment in Data Access provides the most extensive guidance to the assessment of substantiality in the context of computer code. Relevant passages from Data Access have been reproduced earlier in these reasons. …

In Data Access, the plurality stated their agreement with the following observations of Mason CJ in Autodesk (No 2) (at 305, citations omitted) …

The above passage makes three points in the context of computer code. First, the phrase “substantial part” refers to the quality of what is copied rather than the quantity. Second, in determining whether the quality of what is copied makes it a substantial part of the copyright work, it is important to inquire into the importance which the copied portion bears in relation to the work as a whole: is it an “essential” or “material” part of the work? Third, in this context “essential” does not mean essential to the operation of the computer code. Rather, in the context of copyright law, where emphasis is to be placed upon the originality of the work’s expression, the essential or material features of a work should be ascertained by considering the originality of the part allegedly taken.

…

It follows that the assessment of whether copied computer code constitutes a substantial part of a relevant computer program (work) is concerned with the quality of what is taken rather than the quantity. The quality of the copied code is to be assessed by reference to the importance which the code bears in relation to the work as a whole, which can also be described as the materiality of the code. But importance and materiality do not refer to the function of the code in the sense of whether the code is important or material to the operation of the computer or device in which the code is installed. Rather, importance and materiality refer to the originality with which the code expresses the functions sought to be performed by the computer or device, which includes such matters as the structure of the code and the choice and sequencing of commands.

855    But in any event, it is not essential for me to find that any particular Apple API constitutes a copyright work, or that Epic has reproduced a substantial part of any API. I am not here required to address a copyright infringement suit.

856    On any view I am satisfied that Apple’s APIs are a valuable resource and are code that Apple makes available to developers pursuant to the terms of the DPLA.

857    Now Epic says that there is no evidence that any code provided by Apple is executed by an iOS app when the app is being displayed within the iOS App Store, downloaded by a user from the iOS App Store, or subsequently updated.

858    But I agree with Apple that when a user downloads an app, the whole of the app’s code is copied to the user’s device and so any Apple code that has been incorporated into the app’s code is copied to the users’ device and so reproduced in material form (s 31(1)(a)(i)). The code is executed when the user uses the app, that is, when the device runs or executes the code.

859    Plainly, that is not occurring when the app is “displayed in” the App Store, or during the process of downloading or updating the code, but I agree with Apple that that is irrelevant.

860    Finally, and as Apple has said, to say that no relevant copyright work has been identified in the evidence makes no more sense than saying that an agreement licenses the printing of books, including the Harry Potter novels, but it is not clear whether it licenses any copyright works. It is not necessary to read Harry Potter novels to know that that they are literary works protected by copyright.

861    But in any event, even if there was a serious doubt as to the extent of any copyright protection, in my view some of the software and related material that Epic used likely contained Apple’s confidential information and is likely to have been protected under enforceable contractual or equitable duties of confidence.

Operating systems and security – general

862    By way of a pre-amble, it is convenient to note here that Professor Somayaji, a professor of computer science at Carleton University, Ottawa, Canada, gave expert evidence for Epic in both the Apple proceeding and the Google proceeding. He dealt with topics relevant to security and technology in each case.

863    In the Apple proceeding, Professor Somayaji also addressed responding evidence of Professor Aviel Rubin for Apple and also Apple’s changes to iOS in order to comply with the Digital Markets Act (EU).

864    In the Google proceeding, Professor Somayaji also addressed responding evidence of Professor Traynor and also to some extent some evidence of Mr Pascal Burg. He also gave a late report concerning real time scanning and installation aspects.

865    Professor Somayaji was cross-examined by Mr Moore SC for Google concerning his evidence in the Google proceeding. He was cross-examined by Mr Free SC for Apple in the Apple proceeding.

866    Clearly Professor Somayaji was technically very proficient. I have no difficulty with his expertise or reliability. In terms of the subject matter of his opinions and what I have ultimately accepted, I have addressed such questions below and elsewhere.

867    I should also note that Professor Somayaji, Professor Rubin and Professor Traynor participated in an expert conclave and produced a joint expert report. Professor Somayaji also participated in a joint expert report with Mr Burg.

868    Now before proceeding further it is convenient to say something more about the evidence of Professor Rubin, Apple’s expert.

869    Professor Rubin, a professor of computer science at John Hopkins University until early 2023 but still holding the emeritus title, and now chief scientist at Harbor Labs, gave expert evidence dealing with topics relevant to security and technology. He was cross-examined by Dr Higgins SC for Epic.

870    Clearly he had the relevant technical expertise to express the relevant opinions, but there were some difficulties with his evidence.

871    First, given both his contacts with Apple and Harbor Labs’ contacts and connection with Apple, there were difficulties in seeing him as being truly independent.

872    Second, some of his report blended fact, assumption and opinion. Further, he seemed to rely upon Mr Federighi’s assertions and views from time to time. Professor Rubin’s evidence concerning threat models was also problematic.

873    Third, his report or parts thereof seem to have been sourced to anecdotal and undisclosed communications with Apple employees who did not give evidence. This contamination to his evidence also occurred in analogous US proceedings.

874    Professor Rubin gave the following video deposition evidence in 2021 for Apple in analogous US proceedings brought by Epic:

Q.    Okay. I'm sorry to push you back and forth, but if you could open up your rebuttal report for me right now and turn to page fifteen and, in particular, paragraph forty-six.

…

Q.    Okay. I'm looking at the sentence that says:

“It is industry best practice for device manufacturers to perform a formal security analysis, including a threat model, of a product before bringing it to market.?

Do you see that?

A.    Yes.

Q.    Do you have any evidence that Apple, in fact, performed a formal security analysis, including a threat model of a product before bringing it to market, specifically that -- referring to the iPhone?

A.    Based -- based on my conversations with the Apple engineers, it is clear to me that they had large teams looking at this various issue.

Q.    Okay. And who -- who, in particular, are you relying on for that?

A.    The combination of discussions that I had gave me the impression that they had put a lot of energy into studying the security and modeling -- and threat modeling of the product.

Q.    And, in particular, did they indicate to you that they had performed a formal security analysis, including a threat model, before the iPhone was brought to market?

A.    I -- I don't believe we discussed that one way or the other.

Q.    Okay. Have you seen any contemporaneous documentation of Apple having performed a security analysis, including a threat model, before bringing the iPhone to market?

MR. LO:    Vague.

THE WITNESS:    I -- I'm sure that I have, but I can't think of any specific document right now.

875    This contamination in effect carried over to his evidence in the report tendered before me.

876    Generally, Professor Rubin did not disclose in his reports multiple direct discussions with Apple employees and engineers which informed his evidence in the US proceedings and thereby informed his evidence in this proceeding.

877    Further, Professor Rubin on various occasions uncritically adopted the evidence given by the Apple lay witnesses, especially Mr Federighi, as his own expert opinion.

878    Generally, I prefer the evidence of Professor Somayaji who was more independent and who I found more reliable on most topics. Let me turn then to some general topics the subject of evidence from Professor Somayaji from which I have considerably drawn. Where I refer to any figure or table, I have preserved the lettering or numbering of the expert unless I indicate otherwise; I make that observation generally in relation to these reasons, and my reasons in Epic v Google and in the two class actions.

879    Let me begin by dealing with a number of introductory matters concerning operating systems. I will then get into the detail in terms of their design, function and security mechanisms. I will also say something about apps and how operating systems deal with relevant threats. But it should be noted that the next major section of my reasons covers app distribution and threats posed in much greater detail including how they can be dealt with beyond the architecture of the operating system.

880    Now what follows contains modified extracts or paraphrased aspects of Professor Somayaji’s evidence which I have accepted subject to any qualification that I have noted.

Computers and operating systems – introduction

881    The cases before me are concerned with the security and operation of internet-connected computers. Today these computers take many forms such as desktop computers, laptops, tablets, smartphones, smartwatches, cloud-based servers, set-top boxes and internet-of-things (IoT) devices such as smart thermostats, appliances or light switches. These devices vary widely in their appearance, computational power, internet connectivity, specialisation, and general capabilities. But from a security perspective they are almost identical because they all face the same threats on the internet, and they all use the same technologies to address those threats.

882    When one refers to computers or devices one is referring to internet-connected computers, because those are the systems for which the challenges of computer security are most relevant. The analysis is not dependent on the technological means by which these computers are connected to the internet, whether it be using home or office-based wireless networking (Wi-Fi), cellular networks (LTE, 5G), wired internet (Ethernet), home internet (DSL, cable, fibre-to-the-home) or other means. The security issues are the same no matter how you are connected to the internet.

883    A key difference between any computer is the software that it can run, and what software a device can or cannot run is determined by its operating system. An operating system is the set of code that allows applications, that is, programs to use the capabilities of a given computer, for example, the processor and system memory, without requiring specific knowledge of that computer’s hardware. Computer hardware varies widely, even between computers that are sold under the same name. So, laptops are frequently sold with the same name but different chips, processors and device drivers can be equipped with significantly different central processing units (CPUs). An operating system allows developers to create programs without having to worry about such details. Operating systems also provide a common set of capabilities that developers can rely on, reducing the amount of code that they must write.

884    Now it is necessary to distinguish between security mechanisms and security policy. Security mechanisms are collectively the technologies to prevent, detect, and mitigate attacks; security policy describes what activities the system owner decides should and should not be allowed in order to achieve stated security goals. A given set of security mechanisms can be configured in different ways to implement different security policies. By way of analogy, a door lock is a security mechanism, whilst the rules for determining who is given a key to that lock and the associated rationale is a security policy. Security policies are always constrained by the larger goals of a system, and as such security policies must conform to the more general policies of an organisation. So, a convenience store would experience fewer thefts if it always kept its doors locked, but such a restriction would interfere with it serving its intended customers. A central idea is that computer security mechanisms are largely a commodity, and that differences in security outcomes between classes of systems are mostly due to differences in security policy.

885    Let me focus on various characteristics of products produced by Apple being its devices running the following operating systems: macOS, iOS, and iPadOS.

886    At a technical level, these operating systems are all based on the same core technologies and code, with modifications being made to suit each type of device. But these operating systems run on devices that are used for distinct purposes. macOS, the oldest of the three, runs on Apple’s Macintosh line of computers such as MacBook Air and Mac Mini that are designed as general-purpose personal computers. Personal computers are equipped normally with a keyboard and an on-screen pointing device such as a mouse or touchpad that together allow for virtually any content creation or content consumption task, ranging from document creation to software development to playing games. iOS runs on iPhones, Apple’s smartphones, which are handheld devices used for personal communication, information retrieval, and entertainment. Smartphones, by design, trade customisability for reliability and ease of use. iPadOS runs on iPads, Apple’s tablets, which are similar to iPhones but with larger screens. The larger screen of tablets make them better suited for marking up documents, viewing video content, and multitasking in general; with an attached keyboard, they can be used for general text and code editing, much like a laptop but with a more constrained environment.

887    Since iOS and iPadOS use essentially the same restrictive security policies, iOS can be taken to refer to both iOS and iPadOS. Similarly, iOS devices can be taken to refer to devices that run iOS being iPhones and devices that run iPadOS being iPads. macOS devices refer to devices that run macOS, such as the MacBook Air and Mac Mini.

888    An application, that is, an app, is a computer program that provides functionality beyond that supplied by the operating system. Indeed, the purpose of an operating system is to provide the infrastructure needed to run apps. Apps can have a very narrow purpose like a calculator or can be very general. Apps also can be specific to a particular operating system, that is, a native app or they can be platform agnostic.

889    An app store is an app that connects to an internet service in order to facilitate the installation of additional apps onto a device. An app store has a curated set of apps that can be searched using keywords or other criteria; apps can also be browsed, typically via lists sorted by name, developer, category, or other characteristics. Once an app is selected and authorised for installation, the app is transferred to the system or device, verified and then installed. App stores normally facilitate the maintenance and updating of installed apps.

890    App stores are available on a variety of platforms. Cloud-based services, network-attached storage servers, game consoles, and other systems all have app stores.

891    Now to understand how computer devices including smartphones are secured, it is necessary to understand the threats computers must be secured against. Computers are used to access many sensitive resources, including finances and communications, and they can be used to control physical systems including building security systems and cars. Given the variety of uses of computers, the security threats they must address are varied and complex.

892    Threats to computer devices can be classified into three categories: physical threats, online threats, and intermediary threats.

893    Physical threats can be as simple as someone stealing a device and trying to guess its PIN, or they can be as complex as opening a device, extracting its chips for analysis, and installing those chips into a different device for data extraction.

894    Online threats attack a device over the network, with specially crafted messages bypassing a device’s security protections. In the worst case, these exploits can allow an attacker to take complete control of a device, giving them access to all of a user’s data and allowing them to spy on and interfere with their online activities. Online threats can require the user’s active involvement, for example, visiting a website, or they can be passive, happening without the user taking any action at all. Intermediary threats, on the other hand, do not target the device and instead use the device to attack its user or other networked systems. So, a website that is trying to steal a user’s credentials is not attacking the user’s computer; the computer is just a means by which the user is subject to attempted credential theft.

895    In the context of malicious apps, attacks can be online threats, intermediary threats, or combinations of both. Malicious apps can be distributed through many different attack mediums, often by tricking a user into thinking its purpose is not malicious, but once installed they perform malicious actions.

896    Spyware refers to apps that surreptitiously conduct a surveillance of a target. As modern devices have the ability to record audio, video, location, and any on-device activity, spyware integrates these capabilities into its own malicious app and deploys them on behalf of an attacker rather than the user.

897    Data miners steal confidential data that is stored on the device or on remote servers. They use normal access an app would have, but for malicious purposes.

898    Phishing apps and websites impersonate legitimate ones in order to steal credentials. A phishing app displays information, requests input, and then sends that input to a remote party. The danger with this attack is that this is the same basic functionality of almost any modern website.

899    Adware changes apps on the system to display unauthorised advertisements, often hiding the ads of others. Whilst displaying ads is legitimate behaviour, a malicious adware app displays ads where they should not be and from unauthorised parties.

900    Ransomware replaces a user’s files with encrypted copies for which only the attacker has the key. To get this key, the user must pay the ransom. Whilst legitimate apps need to be able to read and change files on behalf of the user, ransomware turns this capability against the user.

901    Cryptominers are integrated into seemingly legitimate apps and websites and mine cryptocurrencies in secret. Cryptocurrency mining takes a lot of computational resources, and so any system running a cryptominer will draw more power, will get hotter, and will cause legitimate apps to be slower. The operations a cryptominer performs, however, are very similar to those needed for legitimate encryption tasks, such as for protecting the confidentiality of network communication. So, a malicious cryptominer steals computing resources and electricity that should have been available to the user.

902    To stop these and other kinds of attacks, malicious computational activity must be stopped. Whilst there are multiple ways to stop malicious apps from harming users’ devices, the underlying security technology available to companies is largely commoditised. So, cryptographic methods are standard technologies for protecting the confidentiality, integrity, and authenticity of information, and techniques for limiting the resources that apps can access have been part of operating systems for decades.

903    In this section of my reasons I will deal with security in the context of operating systems, again relying upon extracts from or paraphrased aspects of Professor Somayaji’s evidence.

Operating systems – the detail

904    Let me say something more concerning modern computer systems before turning to the detail of security questions.

905    Computer devices can be used to address a wide variety of use cases, such as drafting documents, communicating with friends, receiving and viewing news updates, and even programming apps to run on other computers. At the core of modern computing is the hardware on which software runs. In computing, hardware refers to the physical components that make up the computer. Contrastingly, software is the instructions written in code to specify how apps should run on the hardware. The hardware provides the necessary components both to run the software and to support user interaction with the software.

906    Today, a wide range of variations in computer hardware exists. Fundamentally, different categories of hardware address different consumer needs. So, desktop and laptop computers typically offer significant amounts of computing power, large displays, and support use cases where users spend an extended block of time using an app while in one place. Contrastingly, mobile phones have evolved to support use cases where users need rapid access to data and contacts while on the go and feature responsive, network-connected hardware packed into a small and portable form.

907    Two major categories of internet-connected mobile devices are feature phones and smart devices. Feature phones are simple mobile phones that primarily focus on basic functions like voice calls and text messaging. They usually come with limited internet connectivity, a numeric keypad, and a basic operating system that allows for limited third-party apps, which are apps developed by entities other than the one that made the operating system, for example, Google apps on iOS. First-party apps refer to apps developed by the same entity that made the operating system, for example, Apple apps on iOS.

908    Contrastingly, smart devices, such as smartphones and tablets, are advanced internet-connected computers that come with a wide range of features, powerful hardware, and versatile operating systems like Android and iOS.

909    Within the category of smart devices, smartphones and tablets present different form factors and drive different use cases. Tablets are portable electronic devices with touchscreen displays that are larger than a smartphone but smaller than a laptop. Tablets offer a blend of features from both smartphones and computers, enabling users to browse the internet, watch videos, play games, and use apps. Tablets are designed for convenience and ease of use, with a simple interface controlled by tapping or swiping the screen with fingers. Tablets are ideal for media consumption, web browsing, and light productivity tasks, thanks to their larger screens. Smartphones are smaller, pocket-sized electronic devices that combine the functionality of a feature phone and a full computer. Smartphones have touchscreen interfaces and provide cellular features such as calling and texting in addition to computing features such as internet browsing, first- and third-party apps, and taking photos and videos with built-in cameras. Smartphones are designed for portability and on-the-go use, offering quick access to communication and essential daily tasks.

910    Android is an example of a smart device operating system. The Android ecosystem is quite diverse, with many manufacturers producing a wide range of devices that cater to different budgets and preferences. Android phones and tablets are available in various shapes, sizes, and hardware configurations. This is in contrast to Apple devices, such as iPhones and iPads, which are only available in a relatively small number of configurations.

911    Gaming consoles are computers built to provide optimal gaming experiences and typically feature strong graphics processors and game controllers designed specifically for gaming use cases. Gaming consoles typically do not connect to mobile cellular networks, and most are not portable, with a few notable exceptions. Whilst all these device variations represent computers, they are highly differentiated in form and function based on how users interact with them. There is no one-size-fits-all hardware; these differences in device hardware types correspond to different use cases.

912    On a software level, however, the technical mechanisms that make up operating systems and apps are fairly common across different device hardware types.

913    At a high level, an operating system is the set of software that manages a computer’s software resources and processes, enables access to the computer’s hardware components, and provides services enabling the computer’s apps to run, and in this way provides the basic functionality for the device. Computer hardware can be highly variable and complex, to the point that apps cannot be reasonably developed to run directly on a computer’s hardware. Instead, the operating system acts as an abstraction layer between apps and the computer hardware in which the operating system simplifies the details required to run apps on specific computer hardware. An abstraction layer provides both an interface and an implementation. The interface is how a resource is accessed while the implementation is how a resource actually carries out its task. So, files are accessed using a standard interface, but files are implemented using filesystem code and device drivers that control where and how a file’s data is stored. Abstractions provided by the operating system help apps to run across different sets of hardware.

914    So, Android apps written to run on a Google Pixel 6 phone do not have to be rewritten to run on Samsung Galaxy S23, despite there being significant hardware differences between them. Of course, operating system abstractions do not necessarily allow apps written for one operating system to be trivially run on a different platform. Apps coded for Android devices will be unable to run on iOS devices without being reprogrammed in code recognised by iOS.

915    The most important abstraction that operating systems provide for modern computers is that of a process. A process is, to a first approximation, an executing or running program. Programs are files on computers that contain code, whether encoded directly for the processor or in another form, for the computer to execute. A program on its own does nothing, like a recipe in a cookbook. Programs must be run before they do anything, like a chef carrying out the steps of a cookbook. Even in portable devices, computer hardware can provide enough resources to run hundreds or thousands of programs at the same time. A key challenge in operating system design is how to allow many programs to run on a single computer with shared resources without those programs coming into conflict.

916    In provisioning and managing the many programs to run on a single computer, operating systems play three key roles.

917    First, as a gatekeeper, the operating system is responsible for managing apps’ access to data, hardware sensors, for example, the camera or the microphone, as well as apps’ ability to display content to the user of the device.

918    Second, as a coordinator, the operating system has to manage system resources to allow apps to work both synchronously and cooperatively where necessary.

919    Third, as a provider of virtualisation, the operating system partitions and abstracts the computer’s resources, giving each app the illusion of it having its own memory, processor, and persistent storage, when in fact all apps are sharing the same set of physical computing resources. Virtualisation helps to keep apps separate and is a key technology for sandboxing apps. But on its own it is not enough to fully confine apps.

920    By way of the analogy used by Professor Somayaji, imagine a large restaurant with many chefs, servers, customers, and ingredients. In this restaurant, the chefs cook food at their own stations, and then deliver the plates of food to customers. In this analogy, chefs are the apps, plates of food are services, and customers are users. That is, apps deliver services to users. The operating system, then, is the kitchen management, which supplies ingredients, stovetops, and kitchenware to the chefs as needed. The ingredients provided to the chefs will also be served in usable forms ready to be cooked, for example, wheat flour instead of stalks of wheat.

921    In much the same way, the operating system provides apps with access to processing resources, storage, and input from hardware sensors such as touchscreens. But rather than requiring apps to interface directly with hardware components, operating systems translate their language into something more usable by apps. So, when an app wants to write data to a flash memory drive it can simply ask the operating system to write the specified data to storage rather than it having to figure out how to communicate with the drive.

922    In other words, the role of the kitchen management as the operating system is to manage the resources supplied to the chefs, ensuring all chefs have only what they need, coordinate across chefs to manage shared resources, and ensure that chefs do not conflict with each other, for example ensuring that apps do not write over each other’s data.

923    Let me say something more about the gatekeeper role.

924    Operating systems serve as gatekeepers to the resources of the computer, just as the kitchen management might restrict and allow chefs access to certain ingredients and kitchenware. It is the operating system’s job to allow apps access to computer resources selectively to support necessary uses. By the same token, the operating system makes sure that apps do not have access to sensitive resources, like private files or a device’s camera, unless explicitly authorised.

925    Let me say something more about the co-ordinator role.

926    To continue Professor Somayaji’s analogy, it takes a lot of coordination to make sure that multiple dishes can be prepared at the same time. Kitchen management has to make sure ingredients are ready when they should be, ovens and stoves must be allocated between different tasks, and a customer’s order cannot get delayed for too long. Similarly, the operating system coordinates access to system resources so as to allow different running programs to get what they need and when they need it. The task for the operating system is harder, however, because it cannot trust programs to behave properly. Imagine a large kitchen, but one with a mix of experienced, inexperienced, and even malicious cooks working together. You would need to take special steps to minimise the occurrence of mistakes that could harm customers or even sabotage the whole kitchen.

927    To minimise damage in a kitchen, one would have supervisors and other quality control measures to detect problems and take appropriate measures for any problematic chefs. While one can do the same with computers, it is not as reliable because one cannot discipline or fire misbehaving “chefs”, one must work around their bad behaviours. Instead, operating systems rely heavily on other techniques such as virtualisation.

928    Let me say something more about virtualisation.

929    Virtualisation is a way that operating systems help ensure that apps remain separated. With virtualisation, every running program executes in its own virtual computer which is known as a process. From the running program’s perspective, it can seem quite real and not virtual at all. Each app has its own computing resources that, from its perspective, appear to be exclusive.

930    In the kitchen analogy, rather than one large kitchen, there is now one kitchen, that is, station, per chef, complete with all the requisite kitchen resources. By default, chefs do not have access to each other, other stations, or ingredients and supplies outside of what has been specifically provided for them at their station. Interference between chefs is minimised because the chefs do not interact with or even see each other while they work; the only resources and activity they see are their own.

931    This image of each chef, that is, the app, seeing a siloed view of a larger, more complex system is an important one to keep in mind. One critical challenge of computer security is how to keep code, data, and resources separated between apps to limit the damage that a malicious app can do. But if one app needs access to certain resources belonging to another app, how can these resources be kept separate? In practice, a key job of the operating system is to permit legitimate sharing while minimising the risk that such sharing compromises security.

Basic computer architecture

932    Let me elaborate on the basic architecture of the modern computer.

933    At its most basic level, a computer stores and processes information as specified by sets of program instructions. Whilst there are many models of computation, modern computers share a few basic components.

934    Drives are a type of computer memory for storing information for long periods of time. While drives originally referred to ferromagnetic spinning platters being hard drives or floppy disk drives, today “drives” can also refer to devices with flash memory chips, so-called solid-state drives. Drives provide persistent storage, meaning that the information stays there until it is explicitly erased, or the storage system breaks. Drives are normally used to store files including program files and user data files.

935    Random access memory (RAM) is a type of computer memory storing program code and data that is optimised for rapid access and modification. The contents of RAM are volatile, meaning that the information in there is deleted when the device’s power is turned off. RAM is the working memory of the computer. When a program is run or a file is accessed, its contents must be first loaded from a drive into RAM.

936    A CPU or processor is the computer component that executes computer programs. Program code and data is stored in RAM, with the CPU reading them from and saving them to RAM as needed. When the necessary code or data is not in RAM, it will be transferred from files stored on drives into RAM where it will then be loaded into the CPU as needed. CPUs have very small amounts of extremely fast storage called registers where the actual work of computation takes place. Just as a recipe can say to use eggs if they are available or tomato sauce if they are not, putting to one side for the moment any culinary cognitive or sensual dissonance, similarly the CPU can make decisions based on the program it is running and the data it is given.

937    Devices allow the CPU to connect with external systems. Information can be sent to a device and can be received from a device. A device could be a keyboard, mouse, video display, a network interface, or a drive. Except for RAM, everything connected to a CPU is a device.

938    Smartphones, tablets, smartwatches, laptops, servers, and more all represent computers, but they vary in terms of the number of CPUs, the amount and kinds of RAM, and the variety of devices connected to them. Whilst different hardware configurations lend themselves to a variety of different use cases, from a technical perspective, computer operating systems perform the same core functions and leverage the same fundamental capabilities regardless of whether they are run on desktops personal computers, smartphones, or any other hardware configuration. A core insight of theoretical computer science is that all computers are equivalent, in that any computer can emulate, that is, pretend to be another computer, provided it has enough resources, RAM primarily, to do so. The emulated system can be faster or slower than the original, but with the right implementation it can behave as similar as one would like, in that it will produce the same output from the same input.

939    This ability of one computer to emulate another is why computers can vary dramatically in the instructions their CPUs execute, the structure of their RAM, and the devices that are attached, and yet they can still run the same software. So, whilst the appearance and technology of computers is extremely diverse, from a computer science perspective, their basic functional capabilities are very similar. This is not just a theoretical result. Android devices are made by many manufacturers in a variety of form factors and with widely differing hardware components. Nevertheless, they can mostly run the same Android applications.

Networking

940    Let me elaborate on aspects dealing with networking.

941    Smartphones constantly communicate, exchanging data with local cell towers, home routers, platform vendors, social media services, and many, many other systems. Collectively, such computer-to-computer communication is known as networking, and the requirements of networking shape many aspects of operating system design.

942    Whilst computers use many technologies to communicate, for example, Ethernet, 5G, Bluetooth and WiFi, that communication is unified using the Internet Protocol (IP) being the language of the internet. The key insight of IP is that so long as a message can be encoded in a common format, it can be transmitted over essentially any communication channel. IP packets, that is, messages, can be compared to postcards, in that they are a fixed size, have a sender (source), a receiver (destination), and their contents can be read by anyone handling them.

943    Just as a postcard could travel via trucks, airplanes, and even ships on the way to its destination, IP packets can pass over many kinds of networks controlled by different organisations while travelling from their source to their destination. Unlike with postcards, a given exchange between two computers can involve millions of packets, and there is a high likelihood that a significant fraction of those packets will be corrupted or lost in transit. Various communication protocols are used to address the limitations of exchanging raw IP packets. For example, the Transmission Control Protocol (TCP) turns collections of IP packets into a reliable, continuous bidirectional stream of data, and Transport Layer Security (TLS) adds privacy and security to TCP-based communications. Internet-based applications, whether they be web browsers, email apps, or messaging apps, are defined by the specialised protocols they can use to communicate. Further, higher level protocols depend and are based on other lower-level protocols, with each packet encapsulating the information for higher-level protocols inside that of lower-level protocols. For example, actual website data, when sent over the network, is encapsulated within TLS data that enforces the security of the communication. The TLS data is encapsulated by TCP data, which includes instructions on how to transmit the communication. The TCP data, in turn, is further encapsulated by IP data, which includes instructions on how to route the communication. In this way, higher-level information such as website data is encapsulated inside lower-level communications such as routing directions, as shown in Professor Somayaji’s figure 1 below.

944    Individual computers on the internet each have their own IP address. This address is the source address for sent packets and the destination address for received ones. Any computer can be running many separate apps, and each of these can be performing its own communication. To distinguish which program should receive a given packet, low-level protocols such as TCP specify source and destination ports. A port is a number that can be associated with a program. Just as a building can have apartments or units, a host has ports that can individually send and receive information. By default, ports are assigned arbitrarily to programs. But some ports are considered well-known in the sense that the program listening for communication on that port is expected to communicate using a specific, well-known, protocol. So, port 25 is the well-known port for the simple mail transport protocol, the protocol for exchanging email, and port 80 is the standard port for the hypertext transport protocol, the standard protocol for the World Wide Web.

945    A key requirement for any modern computer is that it be able to connect to the internet. In more precise terms, it must be able to run multiple programs where each can continuously send and receive IP packets and the necessary protocols layered on top. As essentially any computer on the internet can exchange packets with any other computer, including those belonging to attackers, each computer must also have protections against malicious communications.

Operating system design

946    Let me provide a conceptual overview to the design and key components of operating systems as explained by Professor Somayaji.

947    First, it is necessary to say something about foundational architecture.

948    The operating systems of internet-connected computers, from smartphones to televisions to cloud-based servers, all share the same basic architecture, as shown in Professor Somayaji’s figure 2. Operating systems share fundamental components, described in the following subsections, including hardware, kernel, processes, services, libraries, and application programming interfaces (APIs).

949    Let me say something about the kernel, which is the program at the core of the operating system that has full control of the computer hardware and system resources.

950    Whilst all programs are executed by the CPU, they are not all treated the same. The kernel is the first program that is run when the operating system starts, and as such the CPU allows it to run in a mode that allows the kernel control over everything, often referred to as supervisor mode. The kernel is responsible for running other programs; before doing so, it puts the CPU into a lower privilege mode (user mode) where programs only have access to the resources that have been specified by the kernel. If a program wants more resources, it must request them from the kernel, which may or may not grant the request.

951    A key responsibility of the kernel is managing the numerous types of devices that the system interacts with, such as storage devices, graphical displays, and networking interfaces. To use any device, the kernel needs to know the specific means by which it may be controlled. As a result of the number and variability of devices, however, kernels do not have direct knowledge of how each device is controlled. Instead, this knowledge is abstracted into code modules known as device drivers. A device driver translates requests and responses between a more generic form that is understood by the rest of the kernel to the specific form needed by the device. Whilst device driver code is logically separate from the kernel, typically it is loaded directly into the kernel. Programming mistakes in device drivers, much as in any part of the kernel, can crash the entire system. In contrast, other non-kernel programs can crash without affecting the rest of the system.

952    Code that is running in the kernel can be logically divided into many components. Code running in the kernel, in supervisor mode on the CPU, can be referred to as running in kernel space. Other code on the system, running on the CPU in user mode, can be referred to as running in user space.

953    Let me say something about processes. Save and except for the kernel, every program executes as a process, which is the running instance of a program that actively issues commands to the operating system.

954    Apps are made up of one or more processes. Web browsers, word processors, and games are all apps that run as one or more processes running programs that cooperate in order to implement their functionality. Inside of a process, a program sees essentially an entire computer system: it has a CPU, memory, and mechanisms for receiving input and sending output. But a process is a virtual construct created through a combination of hardware and software that is orchestrated by the kernel. A process allocated CPU appears to be exclusive, but instead is shared with other processes and the kernel, with it only getting periodic opportunities to use the CPU. A process also sees exclusive access to RAM, but that RAM is partitioned and shared with many processes. This technique of running processes within their own simulated environments is virtualisation, one of the key roles of an operating system. All of these interactions are mediated by the kernel. A process uses system calls, which are requests to the kernel that may be accepted or rejected, to request changes in CPU or RAM allocations, read and write data on drives, and access other devices. This allows the kernel to act as gatekeeper, controlling which resources are accessible to a given process.

955    Whilst processes have much less control over their execution environment than a program running with full control of the hardware, they enable simplicity for software developers. When developing programs, software developers do not have to worry about sharing computer resources with other running programs or processes, as that is all taken care of by the kernel. Software developers also do not have to worry about the complexity and variability of hardware, as that is all handled by the kernel and made available to processes in a standardised fashion. Further, programming errors in processes are limited to that process. When one process crashes, the rest of the system will continue running as if nothing has happened.

956    Let me say something about services. Whilst many processes are part of the user interface of the app, other processes never directly interact with a user. Some run in the background executing maintenance tasks while others await network requests. Such background processes are known as services. Services are present on essentially all computers, as many tasks are best handled in the background. So, a request to print a document is often made to a print service, which then communicates with a printer. In fulfilling its duties, a service can handle a request itself or forward the request onto a separate service running on another computer. A computer that primarily runs services is known as a server.

957    Let me say something about libraries.

958    Modern apps are built with large amounts of code necessary to implement easy-to-use graphical interfaces and to interact with network services. Whilst much of this code may be specifically written for the app at hand, apps also typically rely on external code. This external code has been prewritten by other software developers and is normally included in the form of code libraries. A library can contain simple utility functions, such as for sorting lists of items, or can also provide much more complex functionality such as routines for rendering complex graphics. The library acts as part of the program within the app, with the only difference as compared to the rest of the app’s code being that the app developer did not write it. In addition to third-party libraries, operating systems also provide libraries to facilitate access to background services and other functionality provided by the kernel. For example, C programs are made up of functions that can only call other C functions. Kernel system calls, however, cannot be called as C functions from user space, they have their own interface. To bridge this gap, the standard C library contains C functions that “wrap” system calls by incorporating the necessary machine code to make them.

959    Let me now say something about APIs which are a standardised means by which apps can access the functionality provided by code written by others, whether it is running on a local system or on a remote system.

960    So, APIs are methods of interaction that are documented and standardised so that they may be used by other developers. As an example, operating systems use memory management APIs to mediate access to system memory. When an app wants access to additional memory, it will send a request to the memory management API to be allocated more memory. The API request will in turn trigger relevant operating system code to find additional memory for the app to use. In this way, the app can make use of the operating system’s memory management functionality without incorporating the code into the app’s codebase or understanding the details of how the operating system manages memory.

961    At the base level, most APIs are implemented using libraries, either included in the operating system or provided through third-party software development kits (SDKs). Using an API is often similar to using code in any software module, except that the interface is opaque, as the developer knows the functionality being provided but does not know how it is being provided. Behind the scenes, APIs are implemented using a mix of system calls, calls to other libraries, and requests to local and remote services. For example, when an app opens a file, requests a web page, or makes a payment request, the app is using APIs.

962    Apps can be added to a computer via installation and can be removed from a computer via uninstallation. Computers can typically support multiple apps running concurrently. In terms of the concepts discussed above, apps can be thought of as a combination of custom code and libraries that communicate with an operating system through platform-specific APIs. In this way, native apps are required to be developed using the platform specific APIs which vary between operating systems. The same app running the same logic under the hood requires different development routes when developed for different operating systems, due to differences between operating system APIs.

963    Let me say something about hardware support.

964    The operating system kernel serves as the bridge between applications and hardware resources. For the kernel to access those hardware resources, it needs to know their capabilities and how to control them. To receive touchscreen, keyboard, and mouse events, to control graphics hardware and displays, to store data on drives, and to communicate via network interfaces, dedicated code in the kernel is required.

965    Whilst applications can depend on standard APIs provided by the operating system kernel and libraries, the kernel has no equivalent guarantees from hardware. Although there is standardisation for some devices, such as USB flash drives, in general hardware with roughly equivalent functionality will provide very different interfaces. To deal with the variety of hardware, then, operating systems have architectures and device drivers. An architecture refers to the CPU, memory, and supporting hardware necessary to start up the system and interface with other devices. A device driver is code that allows an operating system to interact with devices, which is basically any hardware that is not the CPU and memory. Traditionally drivers were required for additional hardware added to a computer, either as plug-in circuit boards or via data cables, but today device drivers are also used to access components integrated into the system-on-a-chip that powers most mobile devices. Whilst some device drivers can run in user space, architecture support code and most device driver code are loaded into the kernel and are an integrated part of the kernel as it runs.

966    Kernels divide drivers into categories, with each category of device expected to provide specific programming interfaces appropriate for that category. Storage devices provide a storage device interface while a network device provides a networking interface. Whilst there exist ways to provide access to unique functionality, for the most part device drivers abstract away differences, so they provide generic functionality to the kernel without the rest of the kernel needing to know about the variations of each piece of hardware.

967    When an operating system, such as iOS, is developed by the same organisation that develops the hardware, their operating systems will have excellent support for their own architectures and devices, because they all are developed within the same organisation. Contrastingly, when the operating system and hardware developers are generally different parties, as is the case with Windows and Android, porting to new architectures and supporting new devices requires collaboration that can be facilitated or hindered by operating system design choices.

968    Let me say something about portability. Code is said to be portable when it can run in different environments with minimal changes. Portable applications can run on different operating systems, and portable operating systems can run on different kinds of hardware.

969    Portability is an important property as it allows code to be used more widely, making its functionality available to a greater number of systems and users. But portability almost always comes at some cost in complexity, performance, and/or functionality.

970    For applications, portability issues arise from architectural differences and available API differences. A computer architecture is the machine language that is understood by the CPU and its associated implementations. While new generations of CPU often introduce changes in the machine language instructions it understands, they are generally broadly compatible with their predecessors. Today there are two dominant architectures: x86-64 and ARM. x86-64 is the primary architecture of computers running Windows, while ARM is the architecture of most mobile devices. Apple’s Macintosh line of computers have undergone multiple architecture shifts, from Motorola 68000 to PowerPC to x86-64 and, in 2020, to ARM implemented through Apple Silicon.

971    Whilst programs written for one architecture cannot run on a CPU of a different architecture directly, they can run using a language runtime that translates from one machine language to another. Apple has extensively used such translation layers to allow applications created for old architectures to run on newer ones, and Microsoft has similar technology to allow their ARM architecture surface PCs to execute standard Windows applications created for x86-64 systems. But porting applications between architectures is often not a significant problem, as most programs are written in higher-level languages that can be compiled into machine code for virtually any architecture, or they are written in languages that directly execute portable higher-level source code such as JavaScript or Python or that are compiled to portable bytecode languages such as Java, C# or WebAssembly. Complex applications with significant performance requirements, however, can be hard to port between architectures because parts of them will be written in hand-crafted machine code.

972    Operating systems are much more difficult to port between architectures than applications because they inherently depend on and make use of the specific features of the CPU and associated supporting hardware. Low-level tasks such as how the CPU is initialised, how memory is managed, and how devices are accessed are all extremely architecture specific. While the Linux kernel was originally created for the x86 architecture, which is the predecessor to the x86-64 architecture, today it is portable to more than twenty architectures. But this portability is only possible because extensive work has been done to make most of its code not architecture specific. Even so, each supported architecture requires a great deal of specialised code, and this code must be maintained separately.

973    Whilst architecture-level portability can be a challenge in some contexts, API portability is in general a much bigger challenge. Despite their differences, CPUs mostly offer roughly the same functionality, so architecture portability is mostly about translating between different implementations of the same concepts. But APIs can give access to arbitrary functionality of unbounded complexity. So, the Google Maps API gives access to vast amounts of geographic data that Google has gathered and curated for many years that is accessed using highly optimised programs. For this API to be duplicated, you would either need to get a copy of Google’s code and data, which they do not make available, or you would have to replicate it.

974    Whilst generally not at this level, applications today rely on very complex APIs. Graphical interfaces require code for displaying text, images, and user interface elements such as menus, buttons, text entry boxes. Touchscreens require complex routines for recognising gestures. Video and audio processing requires the use of complex algorithms. Some of these APIs are provided by operating systems directly, while others are provided by libraries and SDKs that, in turn, make use of operating system APIs. To port an application between operating systems, the application has to be changed to use the new operating system’s APIs or it must make use of APIs that are available on multiple operating systems. But these complex APIs are often built on conceptual models that are not directly comparable, so using a new API may require significant reworking of code. Even when the conceptual models are relatively close, a new programming language may need to be used because some operating systems only provide API access in certain language, and those languages can be largely operating system specific. So, iOS APIs assume code is written in Objective-C or Swift, while Android APIs assume code is written in Java or Kotlin.

975    Application portability between operating systems is important in practice because end users want to run apps to accomplish specific tasks. The operating system exists simply to support the running of apps. In specialised applications, operating systems and apps are co-developed. But in the consumer space, operating systems run first-party and third-party apps, and those apps determine what a device can and cannot be used for. Because it is often difficult to port apps between operating systems, devices, data, and services can end up being bound to one operating system or another because the code supporting them has not been ported, inhibiting interoperability.

976    A key contributor to the popularity of the web is that it enables portable applications with almost no operating system or architecture dependencies. But web apps come with various technical and user experience limitations compared to native apps.

977    Let me say something about proprietary software and how it compares to open source software.

978    All software is subject to copyright protection. The legal distribution of software, then, requires the explicit approval of its authors. Normally this approval takes the form of a software license. Software licenses, including those of operating systems, can be divided into two broad categories: proprietary and open source. While in the past most systems ran software with proprietary licenses, open source licenses have become increasingly popular for software libraries, development tools, applications, and operating systems. In most contexts it is difficult to sell open source software directly, since it is hard to sell something that is otherwise available for free; nevertheless, open source has significant commercial value and today most open source software is created by developers working for companies.

979    One significant advantage of open source software is that it enables collaborative software development, even between organisations that are otherwise rivals. One of the biggest such successes is the Linux kernel, which is the kernel used by Android and is developed collaboratively by hundreds of companies and thousands of developers. Because development is shared, no single organisation has to bear the cost of maintaining Linux. But because it is open source, every contributing organisation and anyone else in the world can take Linux and use it as they see fit.

980    It is important to note that such use includes modifying it to suit their own requirements. If Windows does not have an operating system feature that one needs, that person can request Microsoft add that feature in their next release and maybe Microsoft will decide to implement it. If Microsoft does not, one has no other options. But with Linux one can just go ahead and add the feature or pay a skilled developer to do so on one’s behalf. If that feature is of interest to others, it can be “upstreamed” and integrated into the next Linux release; but even if nobody else adopts it, one can continue to use one’s own private version that has the added functionality.

981    Having covered the fundamental components of operating system design, let me now describe the elements and methods used to enforce operating system security as explained by Professor Somayaji.

982    Operating system security is needed because when one connects computers to networks, attackers are also able to connect to those networks in order to attempt to monitor, manipulate, and inject their own communications. To understand how such threats are managed, one needs to appreciate several high-level security concepts.

Security policy

983    In computer security, a system is said to be secure if its behaviour conforms to its designated security policies. A security policy is a set of rules regarding what behaviour is and is not allowed on a platform, for example, an operating system.

984    The concept of secure only makes sense once one has security policies. Unlike with laws, though, security policies are about enforcement of allowed behaviours. A secure system allows activities that conform to its security policies and disallows activities that do not. For instance, a system may enforce rules restricting apps from modifying kernel code, accessing the device camera without the user’s consent, or connecting to forbidden servers. A system becomes insecure once an attacker can carry out an action that is forbidden by the system’s security policies.

Reference monitor

985    A reference monitor is the part of a system that is responsible for enforcing security policies. By design, the reference monitor is the only part of the system that has to remain secure in order for the security properties of the system to be maintained. If a reference monitor is kept small, its code can be subject to extra scrutiny and even mathematical verification, thus providing strong system level security guarantees.

986    Essentially no commonly used system today is implemented with a small reference monitor. Instead, the reference monitor comprises most of the operating system, including the kernel and key system services, because a coding mistake in any of these components could allow security policies to be bypassed. To improve system security, then, operating systems incorporate multiple mechanisms to secure the entire system.

Authentication and access control

987    Key to securing computer systems are the methods by which the operating system authenticates users and provides them with access to resources. The moment computers were used by multiple people with potentially conflicting requirements, computer systems were built to distinguish between users and give different users different privileges. Users first need to be identified and then authorised for the various resources they are entitled to access. The identification process is referred to as authentication, and the mapping of the user to the various resources they may or may not access is known as access control.

988    Authentication requires that the user identify themselves and then present credentials to verify that identity. Entering a username into a login screen identifies you, while typing in your password verifies your identity. Whether authentication happens using biometrics, for example, facial or fingerprint recognition, secure physical tokens, or passwords, most of the system does not know or care about the method of authentication, as the system just needs some way to know who the user is.

989    Once the user is identified, the system needs to know what resources that user may access. This problem can be represented using an access control matrix, where the rows list the users, and the columns list the resources the user may or may not have access to. A full access control matrix is generally too verbose for normal use, as there are too many users and resources to list explicitly. Instead, there are mechanisms such as permissions, capabilities, and access control lists that group together users, resources, or both that record access in a more concise and usable way.

990    Whilst authentication and access control were originally centred around users which were, in fact, humans, today authentication and access control mechanisms are often used for other entities, including apps, computers, and entire organisations. Whilst the authentication mechanisms will be different for non-human entities, the access control mechanisms remain the same.

991    For an access control mechanism to be secure, it must be implemented in a way that it cannot be bypassed. Conceptually, access control mechanisms are enforced using reference monitors based on information from secure authentication mechanisms. A key concept behind secure authentication is the idea of trusted paths.

Trusted path

992    In order for the operating system or any app to authenticate a user, it must have a trusted communication path to that user, known as a trusted path. When the user types in a password, shows their fingerprint, or has their face scanned, the security of the process is only assured if the system can be sure that legitimate data is being input. If malicious code can fake a fingerprint scan or a password entry, the security of the entire system can be compromised.

993    To secure the authentication process, the operating system must ensure the integrity and authenticity of all hardware and software components involved in authentication. The kernel, device drivers, authentication services, and authentication-critical apps must all be protected from compromise, because any of them could undermine the security of the authentication process.

994    Manufacturers of some smartphones place restrictions on modifications to their devices. Part of the motivation for such restrictions is to maintain trusted path security. So, a compromised replacement fingerprint reader could allow malicious parties to bypass it. But the same mechanisms used to guarantee trusted paths for authentication can also make it difficult for third parties to do legitimate repairs.

Cryptographic security

995    A key technology at the core of verifying software components, securing communications, and implementing other security mechanisms is cryptography. Traditionally, cryptography is the study of codes and ciphers used to protect secrets. But modern cryptography uses mathematical constructs in order to provide a variety of security guarantees. Today the word “crypto” often refers to cryptocurrencies, which use the same basic building blocks as other cryptographic technologies.

Digital signatures

996    One of the most useful cryptographic constructs is that of a digital signature. Based on public key cryptography, a digital signature is a short message that attests to the integrity and authenticity of a digital document.

997    From a technical perspective, a digital signature is a mathematical object that can only be created using a private key, which belongs to the signatory.

998    A corresponding public key, which the signatory makes public, can be used to verify that the signature was in fact produced by the signatory’s private key. Much as a bank account’s signing card is used to verify the signature on checks and other documents, the public key allows a digital signature to be verified.

999    The advantage to this system of cryptography is that the authenticity of the entire document, not just the signature, is demonstrated by the signature being verifiable using the signatory’s public key. If even one bit of the document is changed after being signed using the signatory’s private key, the signature of the document is invalidated. Any entity can verify whether the document has been tampered with simply by checking the signature against the signatory’s public key.

1000    Digital signatures are only valid if three assumptions are valid being, first, the digital signature method is secure, second, the private signing key has been kept confidential and, third, the public key does in fact belong to the correct entity.

1001    As to the first assumption, whilst digital signature algorithms and implementations can have flaws, in most circumstances one can be relatively confident that well-known cryptographic methods are highly secure.

1002    The second assumption may be invalid as private keys can be compromised, but that is an operational fact of life that is addressed through mechanisms to revoke keys and through key expirations and updates.

1003    But the third assumption is one that requires significant care to meet in practice. Public keys can be built into hardware, for example, so a device can verify that a new operating system version was authorised by the hardware manufacturer. But one cannot rely exclusively upon only built-in keys if one wants to verify apps, media, and other kinds of digital content, as there are too many sources that need to be verified. The solution to this third assumption is certificate chains.

1004    A certificate in this context is a digital document containing a public key and associated metadata. A certificate will normally encode the entity associated with the public key, the date of issuance, date of expiration, and the algorithms used to generate the public key and associated private key. The private key is not part of the certificate. Certificates are also typically signed by one or more public keys to ensure the authenticity and integrity of the certificate.

1005    As certificates can be signed and can be used to sign other documents, there can be chains of certificates where each attests to the integrity and authenticity of the next in the chain. To maximise security, certificate chains should be rooted in a highly trusted certificate and public key, such as one that is built into the hardware and was installed when the device was manufactured.

End-to-end secure communication

1006    As information sent via IP has no inherent confidentiality, integrity, or authenticity guarantees, protocols must be layered on top to provide such guarantees. When communication is protected against surveillance and spoofing, that is, faking, by any parties except the two that are communicating, it is said to be end-to-end secure. So, web and other network traffic that is sent via TCP/IP today is protected using TLS, a successor protocol to Secure Sockets Layer (SSL), and is end-to-end secure.

1007    Under the hood, TLS uses public key certificates to ensure communication is occurring with the desired entity, and these certificates are verified using certificate chains. When web browsers report that a connection to a website is “secure” with a lock icon or other designation, what they are actually reporting is that the connection is being protected using TLS and the certificate of the remote site has been signed by a trusted entity. Web browsers have built-in hundreds of certificate authority certificates. Websites are considered to be authentic if the domain name of the website is the same as in the site’s certificate, and the certificate is part of a valid chain that has its root in the trusted certificate authority’s certificate.

1008    Whilst end-to-end secure communication is important, attackers can easily purchase plausible domains that they then provision with valid certificates, making communication with those sites appear secure. Other mechanisms are needed to defend against these and other attacks.

Mitigating attacks

1009    No matter the set of security mechanisms, attackers always have a way of getting past them. In part this is due to technological limitations, but these limitations stem from a fundamental truth: one cannot state a perfect security policy, let alone enforce it. An ideal security policy would disallow all ways an attacker could do harm to a system and its users, but because one cannot even list all possible harms, one cannot defend against them perfectly. Nevertheless, one must try, as attackers are constantly innovating.

1010    There are classes of ad-hoc defenses that are in common use based on the kinds of threats they are designed to stop. One can divide these defenses into six groups: security audits, sandboxing, anti-malware, code hardening, software updates, and behaviour limiters.

1011    First, let me say something about security audits, which as the name suggests is a review of a system where the goal is to find potential security issues. A security audit is analogous to a financial audit, except that a system’s code and behaviour is reviewed instead of financial records. Security audits can be a part of a more general app audit that can look for issues beyond security. A security audit looks for vulnerable code, configurations, or designs that could be exploited by an attacker. Manual security audits can be expensive to conduct in depth, and like any audit, if problems are not found that does not mean that there are no problems. Indeed, the quality of any audit depends on the skill and resources given to the auditors, things that are almost always in short supply. But whilst security audits are a foundational aspect of creating secure systems, they are not enough on their own.

1012    Second, let me say something about sandboxing.

1013    Modern systems constantly have to run code from potentially untrustworthy sources. For example, contemporary web pages can execute code when opened despite the fact that web pages can be developed and published by anyone. If such code were allowed to run without any restrictions, it could cause harm. A code sandbox is an environment for running programs such that their access to resources is limited, thus limiting their ability to harm the system they are running on. A sandboxed app can only access its own code and data, thus preventing it from doing damage to other apps or compromising sensitive data held by other apps. Sandboxing is more of a goal than a technology, as many techniques are used to sandbox code. None of these techniques are foolproof, but combinations of them can be highly effective in practice.

1014    The nature of the limits placed on sandboxed code can vary greatly. A regular process is a kind of sandbox in that it places limits on code behaviour, but processes are very permissive sandboxes because they can consume large amounts of memory and CPU time, and because they have access to the system call API which is only partially protected against malicious use. The term sandbox is normally used for much more restrictive execution environments.

1015    Whilst sandboxes can allow code to run directly on the CPU and instead focus on limiting system call access, most sandboxes instead run code using some sort of language runtime. A language runtime is a translator used for apps written in code different from that understood by the CPU. So, what is known as common language runtime provides the services and runtime environment to Microsoft’s intermediate language code, with the former including the just-in-time compiler which converts the latter code to machine code which can be further executed by the CPU.

1016    Now much like a human translator, a language runtime must preserve semantics while respecting the limits of both parties. Just as an English to Japanese translator may censor language to prevent an English speaker from offending a Japanese one, a language runtime will enforce security guarantees as part of the translation process. Language runtime- generated code stands in contrast to native compiled code, which is already written in machine language and can be run directly by the CPU. Language runtimes can be used even for native machine code, as any code can be analysed and transformed before it is run. In practice, however, most sandboxed execution environments run code that is in source code or in a “byte code” form, being a language that is designed for computer execution rather than human review but that is not any CPU’s native machine code. So, web pages include code in the form of JavaScript (source code) and WebAssembly (byte code). Both are executed inside the extremely restrictive web sandbox that web browsers implement inside of their app processes.

1017    Third, let me say something about anti-malware software which as its name suggests attempts to defend systems against malicious software. Such software implements security policies that disallow specific programs, code patterns, and program behaviours as an attempt to approximate the policy of “do not run malicious apps”. Anti-malware suites scan files on disk, run every time new programs and data are downloaded, and observe running program behaviour looking for disallowed patterns. Modern malware scanning software uses three primary analyses to detect malicious software being signature scanning, heuristic analysis, and behavioural analysis. Signature scanning involves matching segments of app code against a database of known malware. Heuristic analysis involves identifying sequences of commands and instructions not typically found in a well-intentioned app. And behavioural analysis involves detecting unusual and potentially malicious behaviour while an app runs.

1018    Now when a malware scanning software finds a problem, it will quarantine or otherwise defend the system against the detected threat. Many programs are heavily obfuscated using code packers that compress, transform, and encrypt them. Such obfuscation can be used for legitimate security purposes, say, to protect trade secrets. But obfuscation can also protect malware from detection. To counter packers, anti-malware suites run programs inside of a sandbox for a short period of time in order to observe them in their unpacked form.

1019    Anti-malware is constantly evolving because malware is also evolving, as attackers always want to bypass the latest anti-malware defences. Malware and anti-malware thus are in an arms race where both sides must constantly adapt. Anti-malware is therefore only semi-automated. Defenders must often manually analyse malicious programs in order to develop new ways to detect and stop them.

1020    Whilst anti-malware software can run entirely locally on a host computer, the problem has become so complex due to attacker sophistication that virtually all current ones run on cloud servers in addition to running locally. A scan may run on a user’s computer to look for common threats, but it will also upload novel files to a cloud service for further analysis.

1021    Fourth, let me say something about code hardening.

1022    Now it should be apparent that security policy at the operating system level is enforced through code, which because it is mostly written by humans is imperfect. In practice, much of an operating system and key parts of important apps are involved in enforcing security policy with imperfect code. These imperfections, known as vulnerabilities, can allow attackers to subvert an operating system’s security policy in many ways, such as by allowing a user to read a file that they are not authorised to read or by injecting code into the kernel that then allows an attacker to bypass all security policies. Code hardening mechanisms limit the ability of attackers to find and exploit vulnerabilities.

1023    There are three basic techniques for code hardening: vulnerability scanning, runtime restrictions, and runtime variation.

1024    Vulnerability scanners inspect code looking for known software vulnerabilities. Because there are fundamental limits on the ability of programs to analyse other programs, vulnerability scanners cannot find every programming error that could result in a vulnerability. But they can help developers learn how to program more securely when they are integrated into software development processes.

1025    Runtime restrictions and variations change how code runs in ways that make the lives of attackers more difficult while not impacting most legitimate code. Common restrictions limit a program’s ability to modify its own code or otherwise create new code at runtime.

1026    Runtime variations change the arrangement of code and data in memory and the patterns by which code modules interact. Variation is an effective defence because legitimate programs rarely depend on the specifics of how their code operates at a low level, yet attackers need these details to exploit certain classes of vulnerabilities such as code injection attacks. Code injection attacks rely on attackers being able to corrupt the contents of code and data in memory in order to add their own code as the program runs. If the attacker cannot predict how the target program is organised in memory, their corruption attempts will not lead to predictable changes in the target’s behaviour.

1027    Fifth, let me say something about automated software updates, which allow already installed operating system components and apps to be replaced with newer versions. Software updates can be used for general software changes, such as adding, changing, or removing features, as well as for corrective changes, such as fixing a bug or security vulnerability in an app.

1028    Vulnerabilities will inevitably be found in software that need to be addressed. While anti-malware and software hardening can limit the damage of found vulnerabilities, sophisticated attacks can chain together vulnerabilities to bypass security mechanisms. So, even the most minor of vulnerabilities should be fixed once they are known. Best practice requires some amount of automated software updates because otherwise security vulnerabilities will not be patched or fixed in a timely fashion, thus increasing the likelihood the vulnerabilities will be exploited.

1029    Software update distribution uses the same online methods used for manual software installation. The difference is that the updates are applied by a background service that mostly runs without user interaction. Many app stores, as an additional service, automatically update apps that users have installed from their store. This can be performed both by centralised app stores such as the Play Store as well as by third-party app stores such as Steam or the Samsung Galaxy Store. But automatic updates for apps need not be managed by an app store. Many apps on Windows and macOS, such as Chrome and Firefox, automatically update even when obtained through direct download. The key technical challenge of software updates lies not with their distribution but with their creation. Any change to software, no matter how minor, can create a bug that will cause problems for end users. Updates to repair vulnerabilities can break key functionality and can themselves cause programs to crash. As a result, any patch must be extensively tested before it is widely deployed. Some of this testing can be done by the software developers using automated tools, however, any automated test suite can only cover a subset of use cases and deployment environments. Software updates are thus staged. They are deployed to small populations initially, and larger groups only get updates so long as problems have not been found. Such staging inherently limits the speed at which updates can be distributed. Until updates are fully disseminated systems must rely on other defences.

1030    Sixth, let me say something about behaviour limiters, which prevent attacks by limiting the ability of users and programs to do potentially dangerous activities.

1031    The distinguishing feature of behaviour limiters is that they restrict user actions that are not explicitly against any fixed operating system security policy but that nevertheless are potentially dangerous. A user should be able to visit any website they wish, and running services should be able to communicate with any system and decide for themselves whether the access is authorised or not. But behaviour limiters provide guardrails to protect against situations where such flexibility may result in potentially malicious activity as attackers have developed specific ways to take advantage of that flexibility. Behaviour limiters are thus equivalent to safety policies such as “do not walk alone at night” and “do not talk to strangers”, which are guidelines that can prevent some bad outcomes but at the cost of limiting legitimate activity.

1032    The most common form of behaviour limiters restricts network communication. Web browsers prevent users from visiting known websites distributing malware and network firewalls disallow communication with services from untrusted sources. But behaviour limits are also placed on users, for example, when they attempt to modify system files. As another example, many attackers attempt to trick people into entering their usernames and passwords onto web pages impersonating legitimate ones. Such “phishing” attacks are primarily mitigated using behavioural limiters, for example by blocking known phishing sites.

App signing and trusted computing

1033    When computers were first developed, all computer users were also programmers, and as such operating systems were designed to allow every user to create and run their own programs. But today most users are not software developers, and as a result most do not need the ability to create their own programs. But what they do need is a way to ensure that they only run trustworthy programs.

1034    Anti-malware systems by themselves are inherently limited because they are attempting to detect malicious programs, and there are infinite ways to be malicious. Today the primary defence against malware is not actually anti-malware suites. Instead, systems are protected by only allowing authorised apps to be installed and run. Determining what apps should and should not be authorised is a question of app distribution.

1035    Let me say something here about how systems can know whether software is authorised and how unauthorised software is excluded.

1036    The key technology here is app signing, which is just the use of digital signatures on program files. If a program installer is signed with a trusted key, it is allowed to run to install the program. If a program binary is signed with a trusted key, the kernel will allow it to be executed. App signing is separate from file permissions and other access control mechanisms. For a program to run, the file has to be marked as executable by the current user and the program should have a valid signature. Security technologies evolve over time and new technologies tend to overlay rather than replace older technologies, sometimes producing situations where it can be difficult to determine which security mechanism prevented a given action.

1037    In order for app signing to work in a way that attackers cannot easily bypass, one must make sure that the code verifying app signatures is also protected. With trusted computing, all relevant code must be signed using a trusted key, going all the way to the boot loader that loads the operating system kernel. With trusted computing, “trusted” is being used in the more technical computer security sense. Rather than saying that something is trustworthy, trusted in the computer security sense means that if the relevant code is not trusted, all security guarantees are lost.

1038    So, in computer security it is possible for something to both be trusted, where the security of the system depends on it, and untrustworthy because it has or can be compromised. The trusted keys themselves are stored in a special tamper-resistant hardware security module that ensures that the keys are protected and that signature verification is done in a trustworthy manner. If a device manufacturer installs the proper keys when the system is created, one can have strong assurances that the system will only run software that has been properly signed.

1039    Just like all software, the code implementing trusted computing can itself have vulnerabilities. Software hardening mechanisms can limit their exploitability. Nevertheless, vulnerabilities can be found in trusted computer systems, and when they are found they are the highest priority vulnerabilities to fix because they can potentially undermine every other computer defence.

1040    I will say something more about security concerning app distribution later.

Apple’s devices – operating system security

1041    Now Apple’s devices running iOS combine hardware security modules, operating system mechanisms, and app audit processes to create a tightly integrated system that has largely excluded many classes of malicious software.

1042    Professor Somayaji provided the following summary, which in its key elements I did not understand to be contentious.

1043    Apple secures its devices at the operating system level using security technology similar to that of its peers in mobile and home computer markets. iOS largely shares its core security technology with macOS, and that technology is very similar to that provided by its peers. What differentiates iOS security from macOS security and that of most other operating systems are Apple’s policies governing how these security technologies are used.

1044    Apple maintains iOS’s security by preventing the execution of unauthorised apps and limiting the capabilities of authorised apps. These restrictions are in place on iOS and other operating systems because attackers have two fundamental attack strategies: they can either attempt to get their own malicious apps installed, or they can try to corrupt otherwise legitimate apps to make them behave maliciously. Neither of these restrictions can ever be absolute, but together they provide greater protection than either on its own.

1045    iOS prevents the execution of unauthorised apps using digital signatures, a cryptographic technology that assures the integrity and authenticity of code and data. These digital signatures ensure that only Apple-approved apps can run on iOS. By Apple policy, the iOS App Store is the canonical source of apps authorised to run on iOS. The digital signing of apps secures iOS to the extent that malicious apps are excluded from the iOS App Store.

1046    Whilst other operating systems limit what apps may be installed and their capabilities, in general they impose fewer restrictions than iOS because of user expectations and requirements. On most personal computer operating systems such as macOS and Windows, users may install apps from any source or may develop apps from scratch. When run, such apps may then access any resources, including local and remote files, that the current user may access. This setup enables workflows where multiple apps are used together to edit images, process videos, or analyse data, for example. In contrast, iOS apps are isolated from each other through the app sandbox, a set of technologies designed to isolate apps from each other. Sandboxed apps cannot share data or otherwise interact without explicit user action, making complex multi-app workflows awkward at best.

1047    Further, Apple makes an ecosystem of tightly integrated products designed to provide a unified customer experience. So, an incoming text message can be read on an Apple Watch, replied to on an iPhone, and later reviewed on an iPad or an iMac. This tight integration is achieved in part through a largely unified technology stack, with Apple devices sharing chip designs, operating system components, system libraries, and interface patterns. While this integration has advantages for Apple device interoperability, it also reduces interoperability and compatibility with non-Apple devices. Many of the features which Apple extends to its own devices within its ecosystem are technically capable of interoperating with third-party devices, but decisions by Apple restrict this potential compatibility.

1048    When core functionality across Apple and third-party devices is built on existing industry standards, those standards can allow for some amount of interoperability. But the proprietary additions that enable tight integration by Apple are not standardised to the industry, and so are not interoperable to third-parties without practices such as reverse engineering. In the past, Apple has pulled apps that reverse-engineered protocols from the App Store. Additionally, the viability of reverse-engineered services is further complicated by the fact that modifications to Apple’s proprietary technologies often cause unofficial, reverse-engineered systems to break. Sometimes these updates are in the interest of consumers, as those that allow counterfeit AirPods to be detected. Others, such as updates to AirPlay, can disable previously working integrations with third-party devices. So, Apple integrating products with proprietary technologies reduces interoperability with products from other companies.

1049    Items of Apple’s hardware and apps enjoy compatibility with iOS and with each other, as Apple is the maker of its hardware, apps and iOS. But the same degree of compatibility is not extended to third-party devices, apps, or operating systems, such as Android. Despite that, from a technical perspective, compatibility across the Apple ecosystem of products and technologies and that of third-party platforms is feasible, evidenced by the compatibility features that Apple extends to its own products and technologies and by the temporarily successful efforts of third-parties to reverse engineer and interoperate with Apple’s services and devices. It is thus Apple’s decision to restrict compatibility.

1050    Now many of Apple’s products, including the iPhone, Mac, iPad, and Apple Watch, share the same technical foundation. The similarities start at the kernel level. iOS, macOS, and watchOS all share the same XNU kernel architecture, meaning that they share the same general logical structure, with slight differences in implementation.

1051    XNU kernel is derived from the Darwin operating system, an operating system which was developed and released by Apple in 2000. The Darwin kernel is in turn a direct development on top of the kernel adopted by NeXTSTEP, the operating system developed by NeXT Inc. Elements of the NeXTSTEP operating system, such as the UNIX architecture, and sharing user interface objects like the app dock, can be seen even in the latest macOS.

1052    From the time when it first launched, Darwin served as the kernel architecture for macOS. Then when the iPhone was launched, it used a version of macOS, albeit modified to work with a touch screen. iOS adopted a more distinctive interface overtime, but continues to share technical foundations with macOS, such as the shared kernel. Later, the iPad and the Apple Watch were released with operating systems derived from the iOS operating system.

1053    In this way, iOS, macOS, iPadOS, and watchOS each are driven at the core by minor variations of the same kernel.

1054    This commonality also applies from a security perspective. Past vulnerabilities discovered at the kernel level on one of these four operating systems has caused Apple to issue fixes across all operating systems.

1055    Apple operating systems also share the same framework architecture which allows apps to run on the operating system. Frameworks refer to the operating system libraries which provide an app access to the necessary APIs. These APIs are used to communicate with other layers of the operating system to provide basic functionality for all apps.

1056    For instance, the Foundation framework developed by Apple is implemented on iOS, macOS, iPadOS, and watchOS and provides fundamental functionality to apps, like creating or reading files in the file system, access to date and times as well as enabling an app process.

1057    There are other such frameworks that are shared across iOS, macOS, and watchOS which enable the same functionality across different platforms. These frameworks include AVFoundation, which enables loading of audio-visual assets within the app, CoreBluetooth, which enables the communication of Apple devices with any Bluetooth device, MapKit, which enables developers to access Apple Maps within their app and use geographical data, GameKit, which enables users to interact in game and allow multiplayer games, and PushKit, which allows the device to respond to push notifications.

1058    Even though the operating systems share technical similarity under the hood, they can appear different as a result of the user interface of the device. The user interface is in turn an outcome of the desired purpose of the device. Each operating system is optimised to run on devices with different purposes creating the need for having a distinct user interface for these devices.

1059    So, the user interface on a Mac is different from the user interface on an iPhone because the medium of interaction is different. Interaction is done via a mouse and keyboard in the former, compared to touch on the latter. In this way, even though the interface designed for each operating system may feel different to a user, they are using the same libraries, kernel and other foundational architecture, making them fundamentally the same.

1060    In addition to similarities at the operating system level, Apple devices are also similar at the chip level. Chips provide the necessary computing hardware for the device that they are developed for. More fundamentally, a chip is a set of electronic circuits and miniature switches, that is, transistors that follow the binary instruction supplied to them.

1061    iPhones run on the A series chips, Macs and iPads run on the M series chips, and the Apple Watch runs on the S series chips. But these chips share similarities in their design and manufacturing.

1062    So, both the M series chips and the A series chips are developed as ARM-based system on a chip (SoC), that is, a chip that combines the CPU, GPU and other necessary components. The M1 chip and the A14 chip share the same 5nm manufacturing technique which allows for similar performance. This means that both the M series chips and the A series chips follow similar instructions as laid out by the Arm organization, which primarily designs ARM processors.

1063    The CPU cores are made up of IP cores which are blocks of logic used to make the integrated circuit for a product. These IP cores are the same across M1 and A14.

1064    Moreover, the S series chips are modelled after the A series chips, extending the hardware similarity to the Apple Watch. Further, the M series chips, which the Mac and iPad run on, are also capable of running iPhone apps, highlighting analogous development capabilities across these devices.

1065    Apple also employs the hardware root of trust model to establish a chain of trust based on the hardware of the device. Chips designed by Apple allow certain security features such as kernel integrity protection, fast permission restrictions and a page protection layer, which in turn are available due to specific engines built onto the chip.

1066    For instance, the memory protection engine is used for verification of data shared between the various components of the chip. There are other engines with more nuanced roles that are built right into the chip to enable the features to exist.

1067    All the latest chips such as A14+, S6+ or M1+ support the same set of security features by incorporating the same engines, which in turn means the same level of security is derived from the hardware for iPhone, Macs, Apple Watch and iPad.

1068    Before turning to app distribution in much greater detail, let me say something about Professor Somayaji’s comparative analysis.

Platform comparison of key operating system security mechanisms

1069    Professor Somayaji compared the security mechanisms of six operating systems: the open source version of Android (AOSP), a GMS-certified version of Android, Apple’s iOS and macOS, and Microsoft’s Windows and Xbox. His evidence, which I have considerably drawn from, was not the subject of serious challenge.

1070    Now all of these operating systems use essentially the same security technologies in order to implement different security policies. Security differences between platforms, then, are mostly due to differences in their security policies. Since almost all security mechanisms are similar across AOSP and the GMS certified version of Android, one can refer to both of these as “Android”, although individual versions may have specific differences.

Authentication and access control

1071    File permissions are what an operating system uses to determine who can access which files on the device. Typically, they are stored as attributes of individual files. In other words, instead of having a centralised database of access permissions, each file will contain information about who is allowed to use it and for what purpose. Like all access control methods, file permissions define the entities that may access the files and what kind of access those entities should be given. File permissions are typically expressed in terms of users and groups of users as the entities and permissions as read, write, or execute access. Professor Somayaji’s table 2 compares the file-based access control technologies of the five operating systems.

1072    There are two basic models of file-based access control or “grouping models” in table 2, being the Unix model and the Windows model.

1073    The Unix model is older and more restrictive. Individual files can only belong to a single user and group and for the most part the Unix model only supports read, write, and execute access control.

1074    Windows allows for more flexible definitions of entities using access control lists coupled with finer-grained permissions that separate the ability to modify file data and metadata.

1075    In practice, however, both systems are flexible enough to express virtually any file-based security policy that an operating system user or administrator would want to establish, and in fact most permissions on modern systems are set automatically and are never updated.

Digital signatures and app signing

1076    Now I have already touched on app signing, but let me add the following.

1077    All modern operating systems can verify digital signatures on apps. Signature verification allows the operating system to identify the signing entity, which is often the developer of the app or the distributor of the app. Signatures are trusted when they are valid and are part of a chain of certificates that end in a trusted certificate that is ideally stored in secure hardware. Signatures are untrusted when they originate from an entity outside the chain of certificates. The major differences in how operating systems treat app signatures is not in the technology used to verify them but policy decisions defining which, if any, signatures are required for apps to be run. As shown in Professor Somayaji’s table 3, all platforms support the verification of app signatures and hardware roots of trust.

1078    Android, iOS, and Xbox require all apps to be signed, and iOS and Xbox require that the signature be trusted. On Android, app signatures can be self-signed by the developer, which is not considered to be trusted. Self-signing an app involves creating and using a developer-generated cryptographic key to sign the app, instead of obtaining a key from an entity inside the chain of trust, such as a Google key in the case of Android. It is possible to directly download apps on Android that have been signed by untrusted keys, although users experience a high degree of friction while installing such applications. macOS and Windows allow for the execution of unsigned and signed but untrusted apps, although both make the execution of such apps onerous, displaying warnings and on macOS requiring non-intuitive user actions to allow them to run; I would note here that such required non-intuitive user actions can be simply described as frictions.

1079    Further, encryption and cryptographic signing are standard technologies supported by all modern platforms. They all provide cryptographic tools to develop, store and maintain digital signatures in the form of public and private keys. Android offers the Android keystore system that allows for generation, storage and retrieval of cryptographic secrets including user passwords. The Android keystore system has a number of components that fulfill different functions, for instance the Keymaster TA, which is the software running on a specific chip that enables all the keystore operations, and the Gatekeeper TA, which is responsible for authenticating user passwords and supplying information to the Keymaster TA. iOS and macOS also offer the iCloud keychain which is an encrypted database which allows for storage and retrieval of cryptographic secrets including user passwords. Windows provides the Microsoft strong cryptographic provider, which is a software module that runs cryptographic algorithms for the purposes of encryption and authentication. Further, Microsoft provides mechanisms that can be used for private key storage.

Sandboxing

1080    Now I have already touched on sandboxing, but let me add the following.

1081    All modern operating systems enforce some degree of sandboxing, but the implementation of this sandboxing varies across platforms. As can be seen in Professor Somayaji’s table 4, all examined operating systems support all the listed features.

1082    They all support basic process-level confinement where user-space programs can only see their own virtual address space and must access outside resources through the kernel. They all support further app-level confinement where apps by default have very limited access to system resources such as location information and cameras; additional access is granted through per-app permissions. On Android, the sandbox is enforced at the Linux kernel level, where every app is isolated and runs its own processes. This is achieved by assigning a unique UNIX user ID to each app as well as a separate directory to store its files and data. Granular permissions either at runtime or at installation are then used to grant resources to the app such as the camera or microphone. Android, iOS, and Xbox apps are confined by default, while on Windows and macOS most apps are unconfined, except for those installed through their app stores. All these operating systems support file system virtualisation in which an app sees a special, bespoke version of the filesystem. This constitutes a specialised and especially robust approach to sandboxing. With iOS, file system virtualisation is the standard for all apps.

1083    A more restrictive sandbox is more secure, all else being equal, but restrictions inherently limit functionality and can do so in a way that interferes with the user experience. On Android, sharing of files and data between apps can only be done using an “Intent” or a “ContentProvider”, both of which are services specifically defined and mediated by the operating system to share information securely. As well, these services require permissions from the user before apps can share data, which lends to the strength of the sandbox. For instance, apps cannot read or modify files in storage outside of the app’s sandbox without restricted and specialised permissions or explicit user consent.

Malware protection

1084    Malware scanning exists across all popular operating systems as a means of detecting potentially malicious code in downloaded apps. A notable exception exists in the open source version of Android, which does not ship with any malware detection software integrated with the operating system. Instead, malware detection is carried out by Google Play Protect on Android devices, which is a proprietary service only available with the Play Store to Android devices. Apart from this distinction in Android, the general approaches to malware scanning are consistent across platforms. Malware scanning is not a distinguishing security feature of any platform; rather, each platform has techniques for addressing malware that were developed to deal with the specific types of malwares faced by each platform. Professor Somayaji set out a tabulated relevant comparison.

1085    Malware scanning exists across all popular operating systems as a means of detecting potentially malicious code in downloaded apps. While the exact processes behind each platform’s malware scanning is kept confidential, the general approaches to malware scanning are consistent across platforms. Malware scanning is not a distinguishing security feature of any platform. Rather, each platform has techniques for addressing malware that were developed to deal with the specific types of malware faced by each platform. A comparison is set out in Professor Somayaji’s further table 4:

1086    Each of iOS, macOS, Android, and Windows perform a combination of signature scanning, which match segments of app code against a database of known malware, heuristic analysis, which identify sequences of commands and instructions not typically found in a well-intentioned app, and behavioural analysis, which detect unusual and potentially malicious behaviour while the app runs. macOS, Android, and Windows all perform malware scanning when new apps are downloaded. Scanning workloads are shared between the on-device processors and remote servers belonging to Apple, Google, and Microsoft. Typically, on-device scanning will perform a more basic analysis to save system resources, while server scanning will employ more intensive scanning processes.

1087    In malware scanning, iOS is the exception. iOS performs no on-device scanning. Instead, malware scanning occurs automatically during Apple’s app review process. As only apps made available through the iOS App Store can be installed on any iOS device, any apps that are generally able to be installed will have passed Apple’s server-side scan. But custom apps on iOS can be installed on devices belonging to developers, testers, and within approved organisations. Such apps may not be scanned by Apple before installation.

App distribution – modes, technology and security

1088    Professor Somayaji gave evidence concerning app distribution which I have largely drawn on and accept, unless I indicate otherwise.

1089    Now apps are mostly distributed via computer networks, and often through app stores. Further, in some ways, distributing apps today is the same as distributing any type of digital information. The information is placed on servers and clients receive that information when it is requested. The web technology that is used to distribute news, social media, music, and video can also be used to distribute apps. The difference is that apps can change how computers work, potentially in fundamental ways.

1090    Even with all the security technology, any app distribution model must take into account this characteristic of apps and the risks that accompany it.

1091    Now the operating system itself can mitigate the risk of an app by limiting its available functionality. I have discussed operating systems in an earlier section of my reasons.

1092    But there are additional strategies to mitigate the risk of an app beyond what the operating system itself is capable of, including analysing its properties through an app audit and verifying its origin and integrity through developer vetting.

1093    App audit refers to the process by which an app is tested for security and compliance with any policies enforced by the app distributor prior to being offered for distribution or otherwise certified by a given entity. Apple conducts app audits on apps submitted to their store prior to hosting those apps.

1094    Developer vetting refers to the process by which a developer, either individual or organisation, is accredited by a given entity. Developers must be certified by Apple before they can submit apps to the App Store. This certification is granted through developer vetting.

1095    Now as Professor Somayaji observed, along with technical measures to mitigate risk, there is also an inevitable human component, as someone must make the app available, someone else must decide to download and install it, and someone must use it. In general, users lack the time and skill with which to evaluate the trustworthiness of apps on their own merits. Indeed, even skilled code auditors can miss significant security issues. So, ensuring that end users can trust the apps that they download is a function of how trustworthy the other parties with which they interact are, being app developers and app distributors. In this way, ensuring security in app distribution is similar to ensuring trust in any supply chain. Ensuring secure app distribution is a social process that is dependent on trust between the parties developing, distributing, and using the software. These trust relationships can be supported, but not replaced, by technical mechanisms.

1096    Now there are two stages of app distribution, being app procurement and app curation.

1097    App procurement is the process by which a user selects and installs an app on their device, and includes the discovery, retrieval, and installation of apps. App curation is the process by which a distributor defines the set of available apps for users to procure and includes developer vetting and app auditing. The security steps and technologies used in app procurement are important, but relatively commoditised. The security technologies do not change meaningfully regardless of where the app is obtained, meaning that they do not drive differences in security outcomes between app distribution channels on the same platform.

1098    Contrastingly, app curation can vary substantially between distributors. Depending on the curation policy of the app provider, app curation can range from the laissez-faire approach, which allows all apps to be procured, to the rigorously thorough approach, which allows apps to be procured if they come from an accredited developer and have been thoroughly tested.

1099    I will say more about app procurement and app curation in a moment.

1100    App distribution embraces the processes involved in getting apps from developers to users’ devices. App distribution necessarily includes the process by which users discover, retrieve and install apps, and optionally including a process where an entity, for example, an app store decides which apps are made available for procurement.

1101    The security of a device depends in part on the security of the apps installed on it. If an attacker can get a malicious app installed onto a device, or if an attacker can compromise a vulnerable app, they have the potential means of compromising the security of the device if they are able to circumvent operating system protections. The challenge of app distribution lies in determining how to make sure users only discover, retrieve and install safe, non-malicious apps.

1102    App stores make app distribution convenient for users and developers by unifying app discovery, app retrieval, and app installation. A user can search for an app, select it, and have it installed all through a single interface and a single service. But there are disaggregated alternatives for each step in app distribution. Apps can be found by searching through a general web search engine or by directly navigating to a developer’s website. App retrieval can be as simple as clicking on a link to download a file. App installation generally just requires opening an installer or dragging an icon to a desired installation location.

1103    Attackers, using a variety of techniques, can trick users into downloading and installing malware. To prevent this, users must have a way to assess the trustworthiness of an app before it is installed. End users are not given the level of access to evaluate apps directly, and even if they were, most lack the expertise to do so. So, they must rely upon the recommendations of others. An app store implicitly endorses every app that it lists and provides further information through reviews and rankings. Similarly, web search engines such as Google also offer a kind of endorsement by the rankings it gives to search results. In both a web search engine and an app store, if one searches for a well-known app, one is most likely safe in downloading what is highly ranked. But if one searches for the wrong thing, click on the wrong ad or scroll too far down, one may find oneself installing malware. The App Store has a review process designed in part to exclude malware. But in practice, attackers do get their apps listed on the App Store, just as they can get their apps highly ranked in web search engines. The core reason both can lead users to malware is the same: both accept submissions from virtually any source, and both use complex yet imperfect methods to screen and rank submissions so as to minimise the chances users will be directed to sources they should not be seeing.

1104    As I have previously endeavoured to explain, iOS devices are internet-connected devices running an operating system as capable as that on any current computer, and so could download and install software from anywhere on the internet. But due to Apple’s policies and restrictions encoded in iOS, only apps from the App Store may be installed on any iOS device. There are other Apple approved ways to get apps onto iOS devices. Apple allows developers to build and install apps on their own devices and distribute them to select testers. Apple also allows organisations to distribute custom apps to their members. And web apps from any source can be accessed through the included web browser, Safari. But these limited exceptions show how restrictive native app distribution is on iOS relative to other platforms. This operating-system-level policy is different from that of Windows, Android and macOS, as they all allow third-party apps and even app stores to be installed without the direct approval of Microsoft, Google or even Apple.

1105    Now although technical mechanisms can help improve the security of app distribution in any context, ultimately secure app distribution relies on users having a process by which they can be assured they are installing only trustworthy apps. The App Store has at times been a source of untrustworthy apps. Many malicious apps have been distributed via the App Store, having been approved by Apple’s reviewers. So, limiting app installation to the App Store does not guarantee that users are not exposed to malware. While the damage these apps have done has been limited by the restrictions iOS places on all apps, these same restrictions apply to all apps on iOS.

1106    Whilst increased scrutiny in the review process could in principle lower the rates of malware in the App Store, in Professor Somayaji’s opinion, problems arise not primarily because of inadequate review, but because there are almost no barriers to submitting apps.

1107    Now in Professor Somayaji’s opinion, allowing app distribution outside of the App Store would not significantly decrease the security of iOS devices, so long as there remain ways for users to determine whether apps have been vetted and who had done the vetting. He said that third-party app stores could be a way to enable this, as there are examples of them on other platforms having very strong security records. Alternatively, he said that allowing apps to be directly downloaded can also be secure so long as users can verify the authorship of apps. These are contentious matters that I will return to later. Let me return to another topic.

1108    Whilst all native apps that run on iOS must go through the App Store, Apple has made it possible for non-reviewed apps to run on iOS in the form of web apps. Web apps are app-like pages that run in a web browser. Web apps are comparable in some ways to native apps. But because they are confined and restricted by the browser in ways that native apps are not, in many situations web apps cannot offer the same user experience as native apps. Web apps on iOS are restricted in the memory, CPU, and local storage they can use. They also cannot send push notifications, use Bluetooth devices, or update when not being used, among other limitations.

1109    A third category of apps on iOS is streaming apps. Streaming apps run entirely on a remote server, with the app’s output being mirrored in real time on the user’s device. These types of apps are called streaming apps because data streams back and forth continuously between the device and the server. Access to a streaming app can be provided by a dedicated native portal app or a web portal app. In both cases, the portal app on the user’s phone sends inputs from the user’s device, for example, touch screen taps, through the network to the remote server which is running the app. The remote app then renders an output frame based on the result of the input. The output frame is then streamed back to the user’s device in real time. This loop creates the illusion that the user is interacting with an app on their device rather than an app on a server somewhere far away.

1110    I will return to these other possibilities later.

Stages of the app distribution process

1111    Now as shown in Professor Somayaji’s figure 3, at a high level one can divide the app distribution process into two parts, being app procurement and app curation.

1112    App procurement is the process by which an app is discovered, retrieved, and installed on a device. App procurement follows a process which is largely consistent regardless of app distribution method. In a direct download model, the app is procured directly from a developer website, whereas in an app store model the app is procured through a hosted app store.

1113    From a security perspective, the app procurement process involves a number of technologies, such as on-device malware scanning and signature verification, which help to verify that the app being installed is the one that the user meant to install and is free of detectable malware. These technologies achieve a foundational baseline of security regardless of how an app is acquired.

1114    As I have said earlier, app curation is the process by which the set of available apps are determined by, for example, developer vetting and app auditing. Unlike app procurement, app curation is managed by an outside party, such as an app store, rather than by the operating system. As such, methods and processes for app curation vary substantially between app distribution models. Variation in the app curation process can lead to differences in security outcomes. App curation is compatible with the app store model or the direct download model. In the app store model, app curation is typically done by the app store host to decide which apps to make available for download. In the direct download model, app curation is done by a trusted entity to certify apps as trustworthy. Once certified, apps can be downloaded from any source, including directly from the developer. One process of certifying apps for direct download used by Apple is called notarization. Now whilst Apple uses the term notarization, the general process of automatically signing apps that have passed a given set of tests is one that could be used by any operating system. The makers of other operating systems, however, use other strategies for signing apps.

App procurement

1115    Let me elaborate on the key concepts behind app procurement, being the process through which an end user discovers, downloads and installs an app.

1116    In its simplest form, a user downloads the app from somewhere they are familiar with, installs it, and runs it. Yet most of the time the process is more elaborate as users do not necessarily even know what app they want to run, and even if they do, they do not know where to find it. To discover apps, users can do a general search in a web search engine, they can look through recommendations at a review site, or they can search inside of an app store. On iOS devices, the only way for regular users to procure native apps is through the preinstalled App Store. On macOS devices, users can procure native apps through the preinstalled macOS app store, third-party app stores, or through the web.

1117    Once the user has found what they are looking for, they then download the app and proceed to install the app. These three steps are performed whether a user procures an app from an app store, in which case app discovery and app retrieval are facilitated by the app store, or via direct download, in which case app discovery and app retrieval are facilitated by a browser, normally by visiting a web search engine.

1118    App installation is a technical process where the app’s compatibility, authenticity, and integrity are verified, it is scanned for malware, its resources are unpacked and organised in the filesystem, and the app is integrated into the host system by adding shortcuts to launchers, registering for notifications, and requesting permissions to access various resources.

1119    Whilst these technical mechanisms do impact security, they are not differentiating factors in security outcomes across different systems, as the technology is largely commoditised as I have said above. Then, once the app is installed, the user will run the app. As part of the runtime process, the user can be asked whether or not the app should be allowed access to resources such as the camera, microphone, and a user’s contacts, which does have a material impact on security outcomes. This process is described in Professor Somayaji’s figure 4.

1120    So, app procurement encapsulates three fundamental processes, being app discovery, app retrieval, and app installation. Procurement differs between platforms in relatively minor ways at a technical level. The same basic methods underly all online app distribution models. So, the procurement methods for app distribution are largely commoditised. What varies are how those methods are integrated into each platform and what policies they implement.

Procurement models across major platforms

1121    Now to provide real-world case studies, Professor Somayaji examined how app procurement varies between three platforms: iOS, macOS, and Steam for Windows. These case studies provide context through which to assess security components of procurement and their effectiveness.

1122    Let me first address the App Store for iOS. Professor Somayaji’s figure 29 shows the standard app procurement process on iOS.

1123    Searching for an app begins in the App Store. iOS does not support native app download through the web. Rather, the App Store is the only channel through which apps can be distributed for consumer iPhones. The App Store facilitates app discovery and app retrieval, and app installation. From the App Store, users discover apps either through searching for them or browsing catalogues maintained by Apple.

1124    Once users select an app, they must explicitly authorise the downloading and installing of any new app using either a biometric authenticator or a password.

1125    Once an app is downloaded by the user, iOS installs it automatically. During installation, iOS checks the app’s signature to ensure that it has not been tampered with since it was approved on the App Store and checks the app’s format to ensure that it can be run on the device. There is no malware scanning that takes place on-device. Antivirus scans are instead conducted during the curation phase when Apple reviews apps prior to distribution.

1126    Finally, when running the app, users are prompted to approve the app’s access to any privileged resources, such as the device camera or photo library.

1127    Let me next address the macOS notarized direct download. Professor Somayaji’s figure 30 shows the standard app procurement process for the direct download of apps on macOS.

1128    Whilst macOS also has a macOS app store, the procurement process through the macOS app store is similar to that of the App Store. The direct download method of procuring apps on macOS involves searching for an app in a web browser, visiting a website that hosts the desired app, downloading the app, and finally installing the app.

1129    Depending on the type of app downloaded, direct download installation on macOS can follow one of two processes.

1130    One process is .dmg installation. If a disk image file (.dmg) file is downloaded, double clicking on the file causes the disk image to be opened. This is the same process used when apps are installed through physical media, like a USB. The user then drags the app icon to the apps folder to complete installation.

1131    Another process is .pkg installation. If a software package (.pkg) file is downloaded, double clicking on the file runs an installer. The installer places the app’s files in different parts of the system including but not limited to the apps folder, and runs setup programs to integrate the app with the system.

1132    In both of these installation methods, macOS checks the digital signature on the app installer, runs a malware scan that is integrated into macOS, and verifies that the app is compatible with the system. Apps that pass the signature check are said to be notarized, meaning that they have been published by developers registered with Apple and the app is certified to have passed automated app scans conducted by Apple on their server. I have dealt with the process of notarization elsewhere in my reasons. When downloaded via a web browser, macOS asks the user to verify that they want to proceed with the install and will display when and from which website the app was downloaded. If the app has not been notarized, macOS will disable installation unless the user explicitly indicates they wish to open it using the settings menu.

1133    Let me next deal with Steam on Windows. Professor Somayaji’s figure 31 shows the app procurement process when using Steam on Windows.

1134    To procure apps, users search through Steam and select an app to download from the catalogue of apps made available on Steam. Windows’ malware system performs automatic scanning of the app once downloaded. The compatibility and signature validity of downloaded apps is checked by the Windows operating system when the user attempts to install the app.

1135    Unlike iOS, once a user selects an app, they are asked to configure installation preferences, including the directory in which the app will be installed. This step is made necessary by the Windows operating system. But once the installation settings are set and the app is downloaded, the user opens the game from either the Steam portal or a desktop icon.

App curation

1136    Let me say something further about app curation, being the process by which app stores decide which apps to make available for distribution. App curation is conducted by the app distributor and is made up of many optional steps, as shown in Professor Somayaji’s figure 5.

1137    Each of these steps do have a material impact on security outcomes for apps, but they also come with trade-offs.

1138    App curation is generally made up of developer relationships and app audits, where an app audit consists of malware scanning, automatic app policy compliance scanning, and manual review. To ensure security in app curation, first there has to be a relationship between the developers and the distributor. This developer relationship is the heart of the curation process, in that the distributor must decide whether or not a developer’s apps should be made available to the distributor’s customers. Then, when an app is given by the developer to the distributor, the distributor needs to do basic due diligence to make sure that the app follows their policies before it is released for distribution. Parts of this process can be automated, such as malware scanning and automatic policy compliance scanning, whereas others can be manual such as a manual review.

1139    From a security standpoint, the goal of curation is to make sure that distributed apps are free of malware and other security risks, such as ensuring user data is kept private. There are two ways to achieve this goal. The first way is by only distributing apps from trusted developers and organisations being developer vetting. The second way is by reviewing each app to ensure that it is safe to use being app auditing.

1140    Most app stores on the market will employ some combination of both, though with varying degrees of emphasis. Some app stores accept submissions from loosely vetted developers but focus heavily on reviewing each app submitted, whilst other app stores thoroughly vet their developers to maintain confidence that no malicious apps will be submitted in the first place.

1141    Developer vetting is the process by which app stores learn about the identity and history of developers in order to ensure that apps distributed on the app store come from trusted developers and organisations. Developer vetting can range from the most basic, such as verifying that the developer has a unique username before allowing them to submit apps, to highly rigorous, in which developers are treated as potential business partners rather than simply users of the distribution platform. Rigorous developer vetting may include evaluating a developer’s history of app development and potential for future success before allowing them to submit apps for publication.

1142    In a robust developer vetting process, additional information is learned not only about the developer, but also the value that the developer will bring to the user. This increasing gradation of information strengthens the trust and security that can be built between app stores, developers, and users.

1143    App auditing is the process by which apps are examined against the app store’s policies and criteria in order to ensure that apps meet the app store’s standards. Typical categories for app audits include security, functionality, and design. Security audits aim to reduce the number of apps that contain malware, functionality audits aim to ensure that apps behave as is described and do not exhibit bugs, and design audits aim to ensure that apps follow a cohesive look-and-feel that users will enjoy.

1144    Broadly, app auditing can be conducted through automated and manual examination. Automated examination is further carried out by static and dynamic analyses, in which static analyses examine how the app’s code behaves without being run, and dynamic analyses examine how the app’s code behaves when run. Manual examination is the process by which a human reviews an app against a set of criteria.

1145    For an app audit that considers functionality and design factors in addition to security factors, automated examination is typically conducted for security tests, whereas manual examination is typically conducted for functionality and design tests.

1146    The strength of automated review is the breadth of criteria which it can test for in a short amount of time. Its weakness is that it can only reliably evaluate characteristics that can be expressed precisely, and it cannot easily evaluate qualities that are based on complex contexts such as community guidelines, ethical considerations, and use of intellectual property.

1147    These shortcomings are where manual review is strongest, but manual review’s limitations are that it is substantially slower, can only be feasibly done for a relatively small number of criteria, and, because people are conducting the review, that evaluation will be inconsistent.

1148    As a result of these complementary differences, automated and manual review are often used in tandem and applied to settings in which they are strongest. So, automated review can be applied to determine if an app includes any code which belongs to a list of well-known malware, whereas manual review can be applied to determine if an app’s design has the desired look-and-feel required by an app store’s style guidelines.

1149    The effectiveness of the manual aspect of app auditing is determined by the resources, in terms of both quality and scale, devoted to manual review and the complexity of the problems reviewers are tasked with detecting.

1150    There are some forms of malicious code which looks harmless to the automated app audit but can be caught by a human. So, a phishing app that is attempting to impersonate a well-known banking app might be easy for a human to identify as they may be familiar with the bank and the existing app. Such an attack can be difficult to catch via automated means.

1151    But there are inherent challenges in using manual review to detect malware, especially if the malicious code does not change the visible behaviour of the app. Whilst it is possible for a reviewer to manually examine the source code of an app, such a review requires considerable skill and is very time consuming. So, malicious applications can pass a manual review so long as the malicious behaviour is hidden, say, by having it only run after a certain time or in a certain place.

1152    The relationship between users, developers, and app stores is one of delegated trust. The user trusts that the curator will curate safe apps, and the curator must have trust in each of the apps it distributes, either because it has gone through developer vetting or because it has gone through app auditing. To the extent that users place trust in the safety of a curator’s brand, malware that evades detection and makes it either through notarization or onto an app store can be particularly harmful in eroding this trust.

Curation models across major platforms

1153    Unlike app procurement, which is largely carried out by commoditised methods and tools, app curation is a differentiating factor for platforms in ensuring high security app environments. App curation includes components such as developer relationships, malware scanning, automatic policy compliance scanning, and manual review. App curation can be performed either on an app store model, which involves limiting the set of apps available for download on the store, or a notarization model, which involves limiting the set of apps that can be installed by the device using cryptographic signatures.

1154    Before comparing curation models across major platforms, it is convenient to provide an overview of the objectives of curation from a software security standpoint, as well as some of the theoretical foundations and practical implications of curation.

1155    From a security perspective, the purpose of curating a set of apps that can be obtained through a given distribution channel is to provide assurance that the apps obtained are safe to use. Traditionally, when users can install any app without restriction, users become responsible for making judgments around which apps and developers they trust to not behave nefariously. Curated distribution models like app stores or notarization serve as an abstraction of trust. If the user trusts that the app curator has taken necessary precautions to filter out malicious developers and apps, the user should be able to trust that apps they obtain from that curated set will be safe to use.

1156    The idea that app stores or notarizing entities can be trusted to curate safe software finds a basis in the notion of a chain of trust. The chain of trust framework addresses the problem of ensuring that all software running on a device is safe. The core idea of the framework is that each piece of software should only be allowed to introduce new software that it has identified as trustworthy. So, a mobile device might only allow a specific set of operating systems to be booted. The operating system, in turn, might only allow approved software to be installed, for example, third-party app stores or notarized apps. In this way, each piece of software acts as a link in the chain, maintaining an indirect line of trust between any new software run and the original device loading the operating system.

1157    The objective of app curation, whether carried out by a notarizing entity or an app store, is to ensure that the chain of trust is preserved. Apps meeting the curation standards should come with an assurance that they are safe to use. For current app distribution models on iOS, macOS and other platforms such as Steam, trust is maintained by requiring developers and apps to go through a process before they are endorsed for distribution. With such an arrangement, users are implicitly trusting that the app auditing organisation does its job. The details of the process by which this happens need not be public. End users must have a belief that if an app is endorsed by the organisation, that endorsement has meaning. An endorsement communicates quality and safety only to the degree that end users trust that proper developer vetting and app auditing has occurred. The risks can be very high for the endorsing organisation, as even minor lapses that are widely publicised can lead to a loss of trust.

1158    Now whilst the basic process of app distribution is mostly the same, the processes used to perform app curation across the App Store, macOS notarization and the Steam store vary significantly. These processes are connected with different outcomes in malware prevalence across each platform. No one process is inherently superior on all metrics. All manage trade-offs for factors including review time, degree of automatability, and level of required security.

1159    Now developer vetting and app auditing are common practices in the software industry and are carried out by both Apple and third-party app stores. Professor Somayaji compared processes for developer vetting and app auditing across a selection of popular app distribution channels. He compared three examples, being a first-party centralised app store model, a direct download model and a third-party app store model.

1160    First, as an example of a first-party centralised app store model, he considered the App Store.

1161    Second, as an example of a direct download model, he considered macOS notarized direct download, which allows users to download apps that have been approved, that is, notarized by Apple directly from developer websites. Though macOS also supports both a first-party Mac app store as well as third-party app stores, for the purposes of this comparison, he considered notarized direct download exclusively.

1162    Third, as a popular example of a third-party app store model, he considered Steam on Windows, a specialised app store on Windows managed by Valve which distributes gaming apps. Steam is also available for Mac and Linux. Professor Somayaji focused on Steam on Windows because it is an example of a third-party app store that has been successful on an operating system with a significant history of malware. But beyond the details around how Steam interacts with the operating system to install software, Steam is similar between operating systems.

1163    Professor Somayaji’s table 5 provides a general overview of the App Store, macOS notarized direct download and Steam for Windows from the perspective of app curation practices, highlighting that app curation is a differentiating factor in how platforms ensure app security.

1164    Each platform utilises a unique approach to vetting developers and reviewing submitted apps, and differences in each approach highlights the factors that impact security most. Steam, relative to the App Store and macOS notarized direct download, places greater emphasis on ensuring trusted developer relationships and managing app submissions. Steam vets developer organisations who submit apps to their platform and performs an extensive app audit for each submitted app. In addition, Steam specialises in an app niche, gaming, which means they can focus all of their quality assurance resources on a single genre of apps. Steam has a reputation within the industry for being free of malware and minimal history of permitting malware on the store, as described in table 5.

The App Store

1165    Let me say something more about developer vetting for iOS.

1166    Prospective developers must first enrol in the Apple developer program, which requires the following administrative information, described in Professor Somayaji’s table 6, to be provided to Apple.

1167    If developers enrol through the Apple developer app, an additional identity verification step is required. Developers must submit a photo ID, which Apple maintains is for the purposes of confirming identity and preventing fraud. In the most basic pathway to enrolment, however, developers can enrol as individuals through Apple’s website, which does not require a photo ID. When enrolling through Apple’s website, enrolment is confirmed automatically upon payment.

1168    Once enrolled, developers gain access to the Apple developer portal, which can be used to request a certificate. In addition to the above, developers must provide a valid email address to obtain an iOS app development certificate. Once the certificate is obtained, developers can begin submitting apps to the App Store.

1169    No additional information related to history of app development, intent for future app development, or developer legitimacy is required for developers to enrol in the developer program. Nor is there any manual review of requests for iOS app development certificates, which are granted automatically to enrolled developers.

1170    Let me turn to the question of app auditing for iOS, that is, app review.

1171    Apple’s app review includes both automatic and manual components, and compares submissions against a set of guidelines, the App Store review guidelines, which define what is and is not allowed on the App Store.

1172    As the content of the guidelines makes clear, Apple’s app review process is not exclusively focused on security considerations. The guidelines are categorised into five groups: safety, performance, business, design, and legal. In total, these groups contain over 200 individual guidelines, including guidelines moderating the media content of apps and the stylistic look of apps. So, a portion of Apple’s app auditing process checks for media content and stylistic compliance in addition to the checks for technical security.

1173    In assessing how Apple conducts app review, Apple claims to review 90% of apps less than 24 hours after submission. Though Apple spent about 30 minutes reviewing each app during the early days of the App Store, an expedited process introduced in 2009 brought review times down to 13 to 15 minutes per app. The internal diagram depicted in Professor Somayaji’s figure 6 shows the revised process.

1174    Further diagrams show the steps carried out during each phase of review. As illustrated in Professor Somayaji’s figure 7 below, the 10 minute initial review phase performs standard manual checks to ensure that nothing is obviously wrong with the app content, UI, performance, and business model.

1175    Since the second phase of app review, highlighted in figure 6 above, is used as part of the app reviewer largely double checks the work of the initial review within a 3-minute average time frame, shown in Professor Somayaji’s figure 8.

1176    Now according to Professor Somayaji, these guidelines describe a process that is far from that of a full app security audit, where the appearance, behaviour, design, and code of an app would all be carefully reviewed over an extensive period of time such as hours, days, if not longer in order to find potential security problems. I have no difficulty in accepting his evidence in this respect.

1177    Apple makes clear that its strategy for the App Store is to aggressively minimise the time required for app review.

1178    Now as Professor Somayaji said, which I accept, an approach to App Store moderation that prioritises cost minimisation above all else will naturally result in sacrifices in the quality of review. The task that manual reviewers are asked to perform in that time is not a trivial one. Apple’s process entails more than 900 different possible reasons for an app rejection.

1179    Further, based on an undated Apple presentation titled “Review Accuracy”, it seems to me that the process suffers from substantial accuracy issues.

1180    In an audit of 386 app review decisions involving 70 reviewers but with trainees excluded, Apple found that 22% of app approvals and 30% of app rejections were decided incorrectly. Further, the review accuracy score was 87.2% (average by reviewer). So, good but not great.

1181    Apple’s app review process represents a low trust environment, evidenced by the approval and rejection statistics for first-time and previously-approved apps being submitted for update. In January 2021, 65% of the apps submitted to the App Store for the first time were rejected, while 23% of the existing apps on the App Store were rejected for updates.

1182    Let me next discuss the extent to which Apple’s malware scanning provides effective security protections. In practice, Apple’s app review process has allowed malware into the App Store including scams.

1183    Scams included fake VPN apps which tricked users into paying for services by falsely claiming that their device was compromised with malware, apps charging customers for free iOS features, and apps falsely claiming to be developed by major tech companies.

1184    In addition to routine scam apps found on the App Store, several major incidents involving particularly destructive malware on the App Store have occurred from time to time.

1185    Given that malware can go undiscovered on the App Store and can be publicly undisclosed even when discovered, it is difficult to precisely quantify the extent of malware on the iOS App Store.

1186    It is not in doubt that Apple has some history of experiencing malware in the App Store.

1187    Let me at this point say something about macOS.

macOS notarized direct download

1188    The macOS platform uses a program called Gatekeeper to manage security for apps downloaded directly from the internet, that is, not through the macOS app store. When a user downloads an app, Gatekeeper uses signature verification to check whether or not the app has been notarized. A notarized app is one that has been verified as having been made by a legitimate Apple developer account and having passed a malware scan conducted on Apple’s servers.

1189    If the app is notarized, the user can run it immediately. If the app is not notarized, macOS still allows users to run it, but only after having granted it special permissions from the settings menu. Non-notarized apps have not undergone curation. They can come from any source and have not passed any manner of review. But the set of notarized apps is a curated one.

1190    Now developer vetting for macOS follows an automatic approval process largely the same as developer vetting on iOS. Notarization is available to developers who are part of the Apple developer program, for which the registration process is described above.

1191    Once a developer joins the Apple developer program, the process of obtaining a developer ID certificate is similar to obtaining the iOS development certificate. Developers must provide a name and email address, after which the developer ID certificate is automatically granted. With a developer ID certificate, developers can submit macOS apps for notarization.

1192    Like with iOS, the process of developer vetting is entirely automated, and relies on basic identifying information such as name and organisation without considering additional information, such as the development history, of the developer.

1193    Now in order for an app to be notarized, it must pass an app audit comprised of an automated suite of scans administered by Apple. The scans check the app for malware. Additionally, the scans require that the app conforms to technical specifications to improve security and performance, for example, banning entitlements that bypass security checks, and requiring protection against code injection attacks, among others.

1194    After passing the automated tests, an app is granted a certification of notarization by Apple, allowing it to be procured from outside the macOS app store. Once a user downloads the app from the web, it is the role of macOS’s Gatekeeper to verify that the app has been notarized, allowing the user to install the app. The user can also modify Gatekeeper settings to bypass the verification and download non-notarized apps.

1195    Notarization on Mac has only been available since 2019, making it a much more recent development than either Steam or the App Store. As a result, its long-term susceptibility to malware is difficult to assess. But it is clear that notarization provides imperfect defences against malicious apps.

1196    With similar standards of developer vetting as are used for the App Store, the risk of malicious parties becoming certified in the Apple developer program and finding ways to evade app scanning remains.

1197    But the fact that macOS notarization is imperfect does not mean that it would be unfit for iOS devices. The current app auditing model that Apple uses on iOS devices is imperfect. Further, while notarized apps are not subject to manual review, they are also not listed in an app store where they receive an implicit endorsement simply by being listed. Now one can look at the results of a web search in order to determine what results are relevant and safe. Notarization is a protection on top of this assessment process by users, not a replacement.

1198    Further, in practice macOS and iOS are deemed to have equivalent security in the macOS ecosystem as Apple’s iCloud data syncing processes given macOS devices get equivalent access to user data as iOS devices, including messages, contacts, calendars, photos, and passwords.

1199    In Professor Somayaji’s opinion, both app notarization and the App Store provide significant but far from perfect protections against malware. But because of the strong app sandboxing on iOS, his opinion is also that notarized iOS apps downloaded outside of the App Store would pose less of a risk to iOS than notarized apps on macOS.

Security and technical feasibility of alternative distribution models on iOS

1200    Let me now turn to another topic concerning alternative distribution models on iOS and summarise aspects of Professor Somayaji’s evidence in that respect.

1201    Now as Professor Somayaji said, there is no perfect mechanism of app distribution. Instead, the differences across iOS, macOS and Steam are better characterised as trade-offs between multiple factors.

1202    Now enabling direct download on iOS would mean allowing users to download and install iOS apps directly from developers. On platforms that support direct download, apps are generally available for procurement through developer websites. So, on Mac, you can download the Spotify app directly from the Spotify website.

1203    Allowing for direct download does not necessarily mean allowing users to install and run any app they find on the internet. Cryptographic signing technology allows operating systems to verify the authenticity of apps regardless their distribution source.

1204    In other words, the operating system does not have to take the distributor’s word that a given Spotify app available on the internet is in fact the official Spotify app. This can be stamped and verified cryptographically through notarization.

1205    Notarized direct download on macOS represents a sensible implementation of the direct download model.

1206    Apple notarizes macOS apps by automatically scanning them for malicious content and signs them if they pass the scan. Then, users can download notarized apps from any procurement source, and Apple is able to verify that the app has already passed Apple’s notarization scan.

1207    Now the notarization used for macOS is fallible and can let through malware, but two considerations counterbalance that fallibility.

1208    First, the App Store is also fallible, and has a substantial history of letting through malware.

1209    Second, if iOS were to allow direct download of notarized apps, with notarization implemented similarly as it is today on macOS, this would be more secure than the current direct download model on macOS as a result of strict app sandboxing.

1210    Apple has a substantial amount of technical control in deciding the conditions on which to grant notarization certificates. Whilst Apple currently certifies developers who enrol in its Apple developer program to submit apps for notarization, it would be technically feasible for Apple to construct a model on iOS in which notarized distribution is available only to developers who have been background checked or vetted by Apple.

1211    In other words, once the trustworthiness of the developer is verified, Apple could allow those trusted developers to directly provide certified apps to users that have passed an automatic review process.

1212    The process for notarizing apps on macOS is an automated one. But there is no technical requirement that notarization be automatic. The check that is done to notarize apps is fully determined by the notarizing entity. The lack of notarization on iOS is not a technical limitation.

1213    Now ultimately, a direct download model places more control in the hands of the user to determine how they want to procure apps. If iOS supported the direct download of notarized apps or non-notarized apps, users could choose to stick to the App Store for the same app procurement experience iOS devices support today, that is, the App Store, or could choose to obtain apps directly from developers. This is a choice consumers are capable of making. Apple offers this choice to macOS users.

1214    So, it is Professor Somayaji’s opinion that notarized direct download, in combination with the rigorous security protections of iOS, would likely result in a substantial degree of app security that would be less vulnerable to malware than macOS is today.

1215    Let me say something about Professor Somayaji’s evidence concerning the security implications of allowing third-party app stores on iOS.

1216    Allowing third-party app stores on iOS would require Apple to accredit third-party app stores to be installable on iOS and to permit apps distributed through those app stores to run on iOS. In other words, Apple would only need to review and approve the third-party app stores, trusting that they will properly review apps submitted to their store.

1217    This is a delegated and specialised model and contrasts with Apple’s current centralised model in which Apple reviews every individual app that is submitted to the App Store.

1218    And in the event that an app store fails to live up to security expectations, Apple could revoke its accreditation by rescinding its cryptographic certificate, effectively removing the store and all its apps from iOS devices everywhere. Apple would have this power so long as it maintains control of iOS, because any operating system has ultimate control over what apps it will and will not run.

1219    From a security perspective, the key question is whether or not third-party app stores would be capable of maintaining the degree of security offered by the App Store.

1220    To address this question, first consider the security quality of the App Store based on an analysis of its security practices.

1221    The App Store is best characterised as utilising centralised review, or the process by which apps are reviewed by a central organisation before being published. Centralised review stands in contrast to delegated and specialised review, in which app auditing responsibilities are delegated to specialised, third-party organisations before being published. Steam serves as an example of delegated and specialised review, as it focuses narrowly on a specific app category, being games.

1222    In Professor Somayaji’s opinion, largely due to the scale at which Apple’s centralised review attempts to operate, and the inherent trade-offs it faces between scale and accuracy in identifying malware, Apple’s app review system is more prone to error.

1223    By contrast, delegated and specialised review, exemplified by Steam, allows distributors to build close-knit developer relationships, allocate more time per app submission, and specialise within a niche, all of which are conducive to reducing error in app audits.

1224    Further, store specialisation is important only to the degree it helps improve trust between developers and the app store. Shared interests are an important way people develop trust in each other, but it is far from the only way that trust can be developed. App audits can be delegated to third-party organisations like Steam which can then review the segment of apps submitted to their platform.

1225    Now Apple currently offers an alternative app procurement model on iOS, known as the developer enterprise program, which is a form of delegated trust and specialised review. This program allows large organisations to develop and deploy proprietary, internal-use apps to their employees. In other words, Apple allows third-party organisations to transfer apps directly to their employees, empowering these organisations to own the trust relationship with their users directly.

1226    Apps that are part of the developer enterprise program are not reviewed by Apple, but rather Apple reviews the enterprises which apply to this program.

1227    This model demonstrates both Apple’s ability to ensure that trustworthy apps are distributed to iOS device users without requiring app review and centralised app distribution, and demonstrates the technical feasibility of adding alternate app distribution methods to iOS.

1228    This example from the developer enterprise program is extended further when considering how many organisations have internal app portals in which they review and determine the set of available third-party apps for their employees, much like Apple does in its app review process for its users.

1229    So, Microsoft has an internal app portal that has over 10 million downloads and enables organisations to review third-party apps and make them directly available for their employees across Windows, macOS, iOS, and Android. Using this app portal product, the assurance responsibility is delegated across many organisations.

1230    Finally, let me return to the question of whether or not third-party app stores are capable of maintaining comparable security to the App Store.

1231    In Professor Somayaji’s opinion, the basic security processes of the App Store can be carried out to a comparable, or in some cases superior, degree of rigor by third-parties.

1232    In terms of developer vetting, his review of Steam’s developer vetting process relative to Apple’s shows that third-parties like Steam are capable of conducting background checks on developers that are more rigorous than the one Apple performs for its developers by virtue of their scale and scope.

1233    In terms of app auditing, the two key components that relate to security are automatic malware scanning and manual malware review. Automatic policy compliance scanning pertains less to security than it does content moderation.

1234    Automated malware scanning is a well understood, commoditised technology offered by a variety of first-party and third-party firms across computer platforms. As a result, it is not a substantial differentiator in security models between platforms. Third-parties app stores would be capable of offering malware scanning as part of their app curation process.

1235    As to manual review, by comparing the app auditing process of Steam to the app review process on iOS, third-parties routinely manually review apps for potentially malicious activity in much the same way that Apple reviewers do. Further, due to the fact that Apple app reviewers have no direct relationship with developers and generally spend 15 minutes or less on an app, third-parties like Steam can offer increased rigor by allocating more time to audit apps in the context of closer developer relationships.

1236    Ultimately, perfect review of software is a difficult task, and there are significant limitations to manual review. No human reviewer can read and comprehend every line of code and every possible logical state of an app being reviewed. The degree to which a distributor can trust that the developers whose apps it publishes are good faith actors is imperative in assuring particularly high degrees of security. So, in Professor Somayaji’s opinion, distribution models in which developers are vetted, and trust is built between developer and distributor, are less prone to distributing malware than distribution models in which developers are not known entities. In his opinion, third-parties like Steam are just as capable, if not more capable, of fostering high-trust and secure app stores as Apple.

1237    So, in Professor Somayaji’s view there is no compelling security reason why third-party app stores like Steam should be forbidden from distributing apps on iOS devices.

1238    I will return to questions of security later in my reasons, but I should make clear at this point that I substantially accept and agree with the views expressed by Professor Somayaji.

1239    Let me now turn to the question of different types of apps and Professor Somayaji’s evidence in that regard.

Native apps and non-native apps/web-apps

1240    Apple through the App Store has control over what native apps iOS device users can access. These native apps are also subject to the App Store review guidelines laid out by Apple. But since web apps are accessed through web browsers, they are not subject to the same guidelines that Apple imposes on native apps. That means any web app can be accessed on iOS devices through a web browser.

1241    Further, with the creation of progressive web apps (PWAs), a type of modern web app, the web can be used to run apps that can, in some cases, perform functions similar to that of native apps despite their limitations.

1242    In Professor Somayaji’s opinion, with which I agree, despite being accessible by iOS device users outside of the App Store, web apps face limitations in functionality as compared to native apps.

1243    These differences are the result of inherent technical limitations that web apps face, as well as browser and OS-level policy decisions made by platforms to place less trust in web apps and, in turn, extend less functionality to web apps.

1244    Now as Professor Somayaji points out, the web is built with a mix of multiple technologies that that have evolved since the web was created over thirty years ago.

1245    Originally, the web was comprised of primarily HTML (hypertext markup language) and HTTP (hypertext transport protocol). HTML is a language for creating documents viewable on the web with links to other documents, and HTTP is a network protocol for requesting and receiving HTML documents. The ease of creating documents in HTML and of setting up a web server to distribute them via HTTP were some of the key factors enabling the growth of the web.

1246    To view webpages, a client computer requests a uniform resource locator (URL) through its web browser, which directs them to the web server at that URL’s location. A web server is a program running on a networked computer that receives requests for HTML documents that it has. The resulting HTML document at the specified URL is then displayed on the client computer’s web browser. Any HTML document can refer to any other document, whether it is on the originating server or on any other web server.

1247    As the web grew, the people using and developing it wanted it to do more. Whilst from very early on HTML documents could include images, they only supported simple formating and layout directives. It was possible to make text bold or to change the background, but design options such as multiple columns or different fonts, which were commonplace with word processors, were impossible on the web. To address these functional limitations, Cascading Style Sheets (CSS) was added. Similarly, while HTML documents supported the creation of very simple graphical user interfaces, such as allowing users to select options from a list and to click on buttons, more complex interfaces were impossible because there was no way to add the logic needed for such interfaces. JavaScript was developed as a simple programming language to make web pages interactive.

1248    In their early forms, the combination of HTML, HTTP, CSS and JavaScript had numerous limitations. But those limitations were outweighed by the ability to exchange information and then run programs on essentially any computer connected to the internet. Whilst technically web pages as originally intended still exist, most websites today are better thought of as web apps given the additional functionality provided beyond simply viewing text or images.

1249    Web apps typically have two components, being a client and a server.

1250    The web client is the portion of the web app that runs directly inside of the browser on the user’s device. The web client utilises the browser’s, and in turn the device’s, computing resources to run. Web clients are often responsible for rendering the web app as well as reading and responding to user input such as clicks and scrolls.

1251    The web server is the portion of the web app that runs remotely on a server managed by the website operator and communicates with the web client over the network. The web server is often responsible for deciding what content to show a user, what ads to run, and sending the web client the data to load new pages when the user clicks away from their current page.

1252    In contrast, consider the world of native app development. Native apps had to be developed targeting a specific set of hardware and operating system. Apps that could run on multiple platforms were possible but were very expensive to develop. A web app, which is effectively a program with a graphical interface, could run on anyone’s computer. All the user had to do was click a link.

1253    Despite the ease of procuring web apps, when compared to native apps, web apps are restricted in their functionality as a result of both inherent technical limitations as well as policy and trust decisions made by platforms. Native apps in turn are the primary app type developed for mobile devices and are used the most. To understand why, it is necessary to understand the functionality limitations experienced by web apps as opposed to native apps.

1254    Now a distinction between web apps and native apps is that native apps are more trusted relative to web apps.

1255    On traditional computers, when you install a native app, it has access to much of the data and resources of your computer. That is, because the app was installed, modern platforms must assume that the user trusts its code and the people who created it to some degree, otherwise they would not have installed it.

1256    Contrastingly, visiting a web page, and thus a web app, implies no such level of trust. The user may have just clicked on a series of hyperlinks that led them to the web app, and there is no technical restriction preventing users from visiting malicious webpages. So, the web must take security as a fundamental concern in a way that has never been the case for native apps.

1257    To allow web apps to run safely, web browsers implement an app-level sandbox, which is an execution environment inside of a process that has limited access to local and remote resources. Resources such as CPU, memory, display, storage, network, and other running apps cannot be freely accessed by web apps. They are limited by the runtime environment provided by the web browser with assistance from the operating system’s security mechanisms. As a result of the browser sandbox, web apps are restricted as compared to native apps.

1258    Web apps cannot run native code on the user’s device. Instead, web code must go through an abstraction layer, a language runtime, that both hides details of the local system and mediates access to system resources. Whilst it uses different technology, the language runtime in the browser serves an analogous function to the operating system kernel, except with more restrictions. In contrast, native apps can just run native code and have direct access to the features provided by the operating system. The use of a language runtime adds to the total use of computing resources required for web apps versus native apps.

1259    Now native apps are distinguished by their direct access to the operating system, rather than them being native code, in other words machine code. Web apps are different because they must live within the JavaScript/WebAssembly language runtime. This language runtime severely sandboxes code, preventing it from having direct access to the operating system.

1260    Whilst most native apps are compiled to machine code, they can also use language runtimes. So, Python requires its own language runtime, and other frameworks allow native iOS applications to be written in Python. The Python language runtime, however, does no sandboxing and allows code to have direct access to the operating system. Further, if high performance is needed, libraries compiled to machine code may be added. Indeed, Python is used for high-performance AI applications using numerical libraries written in C that have been compiled to machine code.

1261    Further, web app clients, being the part of the web app run in the browser, have access to limited and ephemeral storage in the client, and any important resource must be stored on the server. For complex web apps, this constraint can mean start-up delays as code and data are downloaded, and delays can continue during usage as additional code and data are accessed. This is inherently different for native apps, as necessary code and data can all be downloaded and installed at once, speeding up overall performance.

1262    Additional limitations include the fact that web apps typically cannot function without communicating with a web server, due to being accessed through the web and frequently requiring connection to web server backends. Native apps, on the other hand, can be completely local to a device and so can run without access to the internet, assuming that their functionality makes sense in such a context. By virtue of running in the browser, web apps have mediated access to devices that constrain their functionality. In contrast, native apps have direct access to whatever functions the operating system chooses to permit the app to access.

1263    Much of the progress in the web platform has been aimed at working around the constraints described above. The degree to which this is possible, however, depends upon which web standards have been implemented by the web browser in which the web apps are run. Web standards, in this context, are the resulting technical implementation based on browser-level policy decisions made by the web browser’s owner. These policy decisions made by the browser owners are constrained by the restrictions placed on browsers and other apps by the operating system.

1264    Furthermore, as seen in Professor Somayaji’s figure 11 below, web apps have an additional layer, the browser engine, which translates information between the web documents implementing the app and the operating system facilitating the code’s functionality. Whether or not the browser engine supports the technical translation of functionality between a given web document and the operating system is determined by what standards are implemented by the browser developer.

1265    Whilst the web started out as a relatively simple set of technologies, being the original versions of HTTP and HTML, that simplicity imposed many constraints on the kind of tasks the web could be used for. In contrast, the modern web is an extremely powerful set of technologies that can enable some classes of apps that are comparable to their native equivalents yet can be run on almost any system. But this portability comes at a significant cost. Modern web apps must run in a modern web browser that has a browser engine that supports current web technologies.

1266    Now whilst there are many web browsers, there are only three browser engines that support the modern web: WebKit, Blink, and Gecko. While all three are open source and accept outside contributions, all are tied to specific organisations that develop web browsers. WebKit is led by Apple and is the core of Safari. Blink is led by Google and is the core of Chrome. Gecko is led by Mozilla and is the core of Firefox. Microsoft used to develop its own browser engine, Trident, that was the heart of its Internet Explorer web browser. But today, Microsoft’s main browser is Edge and its core is Google’s Blink.

1267    Browsers on iOS are limited in the degree of native functionality they provide to web apps because they can only use Apple’s WebKit as provided by iOS. This is because other browser engines are forbidden on iOS.

1268    Web browsers on other operating systems, such as Chrome for Android, support more web standards, through the support for web APIs, than WebKit does on iOS. In addition to unsupported web APIs, there is some functionality that native apps can access on iOS for which no web standard exists.

1269    Let me now say something about PWAs which Mr Moore SC for Google particularly seemed to extol the virtues of, no doubt in accordance with his instructions. Contrastingly, Mr Darke SC for Apple was lukewarm on their intrinsic merits.

1270    Recent years have seen the emergence of an improvement on basic web apps, being PWAs. PWAs are fundamentally still web apps. They run on web code inside of a browser. But due to the introduction of new web features, PWAs can be accessed through home screen icons like a native app and support some amount of offline functionality. Whilst PWAs can be launched like native apps, they still run in the web sandbox and thus are functionally restricted in many of the same ways that basic web apps are.

1271    On iOS devices, PWAs cannot be saved to the home screen from third-party browsers such as Chrome or Firefox. iOS PWAs can only be saved from Apple’s Safari browser.

1272    Furthermore, all PWAs on iOS devices are run on the same core browser software or browser engine regardless of which browser app the user chooses to use. This is because Apple requires that all browsers on iOS adopt WebKit, Apple’s own browser engine.

1273    The user experience for accessing a PWA is different than for accessing a native app, since PWAs are distributed through the open web. To access any web app on iOS, users first search for the app using a browser, then open a link directed to a website which loads the web app. PWAs can further be saved to the home screen, emulating the appearance of a native app. The user can open the “share” menu at the bottom of the Safari UI and follow prompts to add a link to the iOS home screen.

1274    Native apps are distributed through the App Store. In contrast to the above, the user searches for the desired app, then selects the desired app from the search results, and finally selects the app to be installed.

1275    But in addition to the inherent limitations faced by web apps as compared to native apps on all platforms, there are further constraints on web apps on iOS devices. To a large extent, web apps access device functionality, such as camera, memory and sensor data, through web APIs. These APIs are supported by the browser and allow web apps to make requests for device functionality accessed through web code. The browser translates the API requests into native requests for device functionality, and passes access back up to the web app.

1276    The support for various web APIs is a function of the policy-based trust decisions taken by the browser owner, which in turn are constrained by the operating system’s security policies.

1277    Despite this theoretical capability for web apps to access additional device functionality through web APIs, Apple limits the web APIs that iOS WebKit can support.

1278    Since Apple requires that all iOS browsers adopt WebKit, as discussed previously, iOS WebKit’s lack of support for these APIs becomes a platform-wide restriction for users on iOS devices.

1279    In Professor Somayaji’s table 8 is a list of core app features available to native apps on iOS platforms that web apps on iOS cannot use due to iOS WebKit’s lack of support for existing web APIs. This list represents a wide range of basic app functionality that have been implemented on other browsers but are not extended to web apps for iOS devices. Some of these APIs represent core app functionality, such as the Task Scheduler API, which allows apps to schedule a process or notification for a future time, or the Background Sync API, which allows apps to perform network syncing to enhance app performance.

1280    In addition to iOS WebKit’s lack of support for existing web APIs, there are a number of key features that native iOS apps can take advantage of which no web app, on any browser, can access. Such features are listed in Professor Somayaji’s table 9.

1281    I will return to the topic of web apps later when I discuss other evidence concerning web apps and PWAs as part of addressing questions of substitutability and competitive constraints.

Streaming apps

1282    Let me set out some evidence of Professor Somayaji concerning streaming.

1283    The App Store review guidelines include policies which restrict how streaming apps can be distributed through App Store. While Apple’s policies permit streaming apps on the App Store in theory, an app which offers access to a catalogue of other apps through a single app is not permitted on the App Store.

1284    This conflicts with the model that cloud gaming apps use on other platforms. Cloud gaming apps traditionally use a single connection app to allow users to access their remote server, on which users can access a multitude of games.

1285    In effect, for streaming apps to be allowed on iOS, each game title offered on the streaming platform would have to be individually submitted to the App Store as a separate app. This requirement imposes additional costs on streaming service providers, requiring that they develop, quality control, and maintain a number of different apps which all provide the same basic service, connecting to the cloud computer and streaming game output.

1286    Today, none of the major cloud gaming service providers are distributed through the App Store. Professor Somayaji’s table 11 summarises app distribution channels for major cloud gaming service providers.

1287    Access to cloud gaming services is instead provided through browser apps and only through Apple’s Safari browser. Web apps on iOS have limitations in access to local device capabilities.

1288    Now the performance differences between native and streaming apps are significant, as outlined in Professor Somayaji’s table 12, which highlights the minimum recommended network requirements for native gaming apps and streaming gaming apps.

1289    High bandwidth and low ping times in particular are needed to make cloud gaming feasible. Cloud gaming service providers need to stream game screen outputs to the player’s computer at a frame-rate that is high enough to make the game feel smooth and responsive. Doing so, especially for high-definition outputs, requires a large amount of data to be transferred over the network. For this reason, the bandwidth of the player’s internet connection must be high, and must be comparable to the bandwidth needed to stream an HD movie continuously with no interruptions or delays.

1290    But unlike video streaming services, cloud gaming also requires low network latency or low “ping.” The ping time for a particular game user is the time it takes for the user’s device to send a message to the cloud server and receive a response back. This is important for cloud gaming because it represents the minimum possible time between when the user presses an input button and when the user sees the game update, without considering the additional time required for the server to process and render the game frame in response to user input.

1291    Good ping time is not just a matter of having a strong network connection at home. It often requires players to be geographically proximate to the servers rendering their game. In part, this limitation is due to the maximum speed at which data can travel utilising in part the electro-magnetic spectrum.

1292    So, it takes light more than 100ms to travel from Australia to the US and back again. That means an Australian game player connecting to a US server could never have less than a 100ms ping time, even if network routing and traffic were perfectly optimised to send data directly at maximum speed between the two countries. As shown in table 12 above, a 100ms ping time is too high for a recommended cloud gaming use case.

1293    Further, in addition to differences in network requirements between streaming and native apps, there are also additional cost considerations. Unlike native apps, which are built for and run on specific platforms, streaming apps are hosted on and streamed from a web server to the user’s device. This requires additional processing power and server infrastructure to run the games, such as content delivery networks, as well as additional resources such as multiple graphics processing units (GPUs).

1294    Examples of technical components that cloud gaming providers must purchase and maintain which are not needed for hosts of native online gaming services are described in Professor Somayaji’s table 13.

1295    The exact cost of running a cloud gaming service depends on a variety of different factors, including location, performance requirements, business partnerships, and more. As a rough estimate, streaming software firm Parsec estimates that not considering licensing fees for the video games streamed, a cloud gaming provider can expect to spend $0.36 per customer per hour on network and hardware expenses. Though that number may seem small, for a popular game like Minecraft, with hundreds of millions of active users, hosting costs can quickly become substantial.

1296    Moreover, streaming apps require a high amount of data bandwidth to carry out the streaming that is required for their functionality. As the table shows, requirements for running streaming apps can be as high as 20GB per hour. To put this in perspective, if an average user in Australia were to use streaming apps, they would consume an entire month’s data usage in approximately a day. This would mean increased costs to purchase plans with a higher data limit.

1297    I have discussed elsewhere other evidence concerning streaming when addressing questions of substitutability and competitive constraints.

Some legal and economic principles concerning market definition

1298    Section 4E of the CCA sets out a limited inclusive definition of “market” in the following terms:

For the purposes of this Act, unless the contrary intention appears, market means a market in Australia and, when used in relation to any goods or services, includes a market for those goods or services and other goods or services that are substitutable for, or otherwise competitive with, the first-mentioned goods or services.

1299    And it is well apparent from s 4E that the requisite parameters of the market are to be governed or at least informed by the concepts of substitution and competition.

1300    Further, s 4E of the CCA relevantly confines a market to one that is wholly or partly in Australia. This means that the CCA will not relevantly apply to a market that is wholly outside Australia, but will apply if the market is wholly within or includes Australia, albeit that the market may encompass other places as well.

1301    A market is an area of close competition between firms, or the field of rivalry between them in the sense of the field of actual and potential transactions between buyers and sellers amongst whom there can be strong substitution, at least in the long run, if given a sufficient price incentive.

1302    The then Trade Practices Tribunal in Re Queensland Co-operative Milling Association Ltd (Re QCMA) (1976) 25 FLR 169 at 190 said:

… We take the concept of a market to be basically a very simple idea. A market is the area of close competition between firms or, putting it a little differently, the field of rivalry between them. (If there is no close competition there is of course a monopolistic market.) Within the bounds of a market there is substitution—substitution between one product and another, and between one source of supply and another, in response to changing prices. So a market is the field of actual and potential transactions between buyers and sellers amongst whom there can be strong substitution, at least in the long run, if given a sufficient price incentive. …

1303    Now the identification and definition of a market for particular services is purposive or functional in the sense that it requires a focusing process to select what emerges as the clearest picture of the relevant competitive process in the light of commercial reality and the purposes of the particular normative legal standard being considered.

1304    The functional approach to market definition does not permit analysis of competition in a manner divorced from the commercial context of the putative contravention which precipitates the analysis. So a well-defined market should reflect or be consistent with the commercial reality of the relevant commercial relationship and dealings.

1305    Further, the market definition must serve the function of providing an appropriate lens through which to analyse the relevant impugned conduct.

1306    In Australian Competition and Consumer Commission v Pacific National Pty Ltd (No 2) (2019) ATPR ¶42-633; [2019] FCA 669 (Pacific National first instance), I made various observations at [82] to [99]. I should say that the Full Court in Australian Competition and Consumer Commission v Pacific National Pty Ltd (2020) 277 FCR 49 (Pacific National on appeal) in the joint reasons of Middleton and O’Bryan JJ and separately Perram J did not take issue with these propositions. Let me set them out, albeit with some modification so as to tailor them to the present context.

1307    First, at a conceptual level a market is an economic tool used to analyse asserted anti-competitive conduct. It is a conceptual framework to analyse competitive processes and market power. But it is to be used and applied having regard to the text and context of the statutory provision which gives rise to the relevant inquiry in the first place. If the question is whether conduct is caught by a particular statutory provision, the concept of a market must be informed by the context in which the question is posed (Air New Zealand Ltd v Australian Competition and Consumer Commission (2017) 262 CLR 207 at [57], [58] and [62] per Gordon J).

1308    Further, one “begins with the problem at hand (the impugned conduct) and asks: what market identification best assists in the assessment of that conduct and its asserted anti-competitive attributes?” (Air New Zealand at [127] per Gordon J).

1309    Second, to accept context and the importance of the reason why one is posing the question in the first place is not to deny that a detailed examination of the facts are all important when dealing with questions of market definition, given that one must centre on the commercial realities of the market and any competition taking place therein.

1310    Third, as McHugh J said in Boral Besser Masonry Limited v Australian Competition and Consumer Commission (2003) 215 CLR 374 at [247]:

Section 4E does not define what a market is for the purposes of the Act. But it makes clear that the parameters of the market are governed by the concepts of substitution and competition. The inclusion of the terms “substitutable” and “competitive with” in s 4E also means that market definition must be determined in accordance with economic principles. The terms of the Act have economic content and their application to the facts of a case combines legal and economic analysis. Their effect can only be understood if economic theory and writings are considered.

(citations omitted)

1311    Fourth, there is no one correct answer to market definition. As was pointed out by McHugh ACJ, Gummow, Callinan and Heydon JJ in NT Power Generation Pty Ltd v Power and Water Authority (2004) 219 CLR 90 at [68]:

The Act is seeking to advance the broad goal of promoting competition. Certain provisions of the Act, particularly in Pt IV, necessarily turn to a significant degree on expressions which are not precise or formally exact. One example is “market”: there can be overlapping markets with blurred limits and disagreements between bona fide and reasonable experts about their definition, as in this case. Other examples are “substantial”, “competition”, “arrangement”, “understanding”, “purpose” and “reason” (which need only be a “substantial” purpose or reason: s 4F). It is not appropriate to subject the application of this type of legislation to a process of anatomising, filleting and dissecting in the fashion advocated by PAWA.

(citation omitted)

1312    Fifth, to be competitors, parties must be rivals or constrain each other in respect of the relevant acquisition or supply of goods or services. Parties constrain each other if they supply substitutable goods or services to the same class of customers or if they would do so given a sufficient price incentive. The sphere of that actual or potential rivalry or what has been described as competition is sometimes referred to as the market. Indeed, to have relevant rivalry in relation to relevant goods or services, including their ready substitutes on the demand side and on the supply side, whether in terms of their type or supply source and depending upon the cross-elasticity of demand and the cross-elasticity of supply, presupposes the context in which such rivalry occurs. The rivalry is not in the ether. The space where it occurs is usually given the label of “market”. Its dimensions are also geographic (the geographic area of supply and acquisition), functional (the level of the distribution chain at which the supply and acquisition occurs) and temporal but with one qualification. If one is talking about the temporal aspect, one is usually referring to the long run anyway when assessing substitution possibilities on either the demand side or the supply side, with any shorter timeframe moving into the realm of a conceptual discussion of sub-markets.

1313    Sixth, let me at this point say something more on the question of substitutability.

1314    The product and geographic boundaries of a market are partly defined by considering the products and geographic sources of supply that are substitutable for the relevant good or service in question.

1315    Substitution may occur on the demand side or on the supply side. And substitutability itself is a question of degree. Demand side substitution occurs where buyers will switch their patronage from one firm’s product to another, or from one geographic source of supply to another, if given a sufficient price incentive. Supply side substitution occurs where sellers adjust their production plans in response to a sufficient price incentive, substituting one product for another in their output mix, or substituting one geographic source of supply for another. And the greater the degree of substitutability on the demand side or the supply side the greater the degree of competition between the suppliers of the relevant goods or services.

1316    Now in the context of considering questions of substitution, the hypothetical monopolist test (HMT) or what is sometimes known as the small but significant non-transitory increase in price (SSNIP) test can be used to assess substitution possibilities on the demand side.

1317    The thought experiment, whether built upon detailed data of the relevant variables or assessed more qualitatively, starts with the hypothetical monopolist supplier and the product or service in issue to define the product and geographic market; the test does not assist concerning defining the functional dimension

1318    The question posed is whether a hypothetical monopolist supplier could profitably impose a SSNIP, say between 5 to 10%, for the supply of the relevant product or service, with the terms of sale of all other products and services held constant. The SSNIP being considered is relative to the prices that would prevail but for the alleged anti-competitive conduct.

1319    If the SSNIP could not be profitably imposed, the next best substitute on the demand side is added to the market definition. The new market is then tested with the SSNIP test. If a SSNIP could be profitably imposed, then you have your market definition. If not, you again add the next best substitute to your market definition and test again, and so on. The idea is to find the smallest area (product and geographic) over which the hypothetical monopoly supplier can impose a SSNIP which then provides the boundaries of the market.

1320    Now the HMT is only a conceptual aid to assist in market definition, nothing more. And as I say, it is a test looking at demand-side substitutability rather than supply-side substitutability.

1321    The economic rationale that informs this conceptual framework is as follows.

1322    If a hypothetical monopolist can profitably sustain a SSNIP above competitive levels, there must be no other goods or services within the market that are sufficiently close substitutes to the candidate good or service for customers to switch to so as to render the SSNIP unprofitable.

1323    If a hypothetical monopolist cannot profitably sustain a SSNIP above competitive levels, there must be other goods or services that are sufficiently close substitutes to the candidate good or service to which customers can switch, thus rendering the SSNIP unprofitable. Those other goods or services can therefore be included within the market. The exercise is then repeated with the broader set of substitutable goods or services until the SSNIP is rendered unprofitable.

1324    Now in certain markets the presence of what is known as the cellophane fallacy may demand that an assessment of substitution under the HMT must be considered with additional caution.

1325    The cellophane fallacy occurs when the starting price for the narrowest set of goods and services is already significantly above the competitive price. In such a case, a price increase above the prevailing price might result in customers switching to alternatives and render that SSNIP unprofitable. But in those circumstances, it would be wrong to suggest that those alternatives should be included in the relevant market. Such switching behaviour could stem from the fact that either competitive pressure was being exerted from alternative suppliers or the hypothetical monopolist was already charging significantly above the competitive price. I will discuss the cellophane fallacy in more detail later.

1326    Let me note here another point. Most of the authorities describe the SSNIP test in terms of whether a SSNIP would be profitable, not whether it would be profit maximising, which is not the same thing. Now there was a debate between the economists in the Google proceeding concerning this distinction and I will discuss this question in my separate reasons in that proceeding.

1327    Let me make another point. A reliable application of the SSNIP test requires sufficient quantitative data to perform the necessary calculations, in particular, to ascertain the competitive price of the product in question. But in the absence of sufficient quantitative data, the SSNIP test can only be used as an aid to focus the inquiry. It may be applied as a thought experiment or framework to make a qualitative assessment about the product and geographic dimensions of the market.

1328    Further on the question of substitution, it is not in doubt that although s 4E refers to substitutability it is not necessarily the defining feature for identifying a market, as was said in Air New Zealand by the plurality at [25] and [26] in analysing Re QCMA.

1329    Further, one is concerned with close competition in the form of strong substitution, where the evidence indicates there will be a relatively high demand or supply response, given price incentives. Substitution is a question of degree.

1330    Further, one needs to consider the temporal dimension of a market which is the length of time over which substitution possibilities are to be considered in determining its parameters. The CCA is relevantly concerned with substitution possibilities in the longer run and not with a short run, transitory situation.

1331    The temporal dimension was further explained in Re Tooth & Co. Ltd (1979) 39 FLR 1 at 38 and 39 as follows:

… we should be basically concerned with substitution possibilities in the longer run. This does not mean we seek to prophesy the shape of the future – to speculate upon how community tastes, or institutions, or technology might change. Rather, we ask of the evidence what is likely to happen to patterns of consumption and production were existing suppliers to raise price or, more generally, offer a poorer deal. For the market is the field of actual or potential rivalry between firms.

1332    But the long run does not refer to a particular time period, but rather is to be understood in a technical sense, as referring to operational time, being the time required to implement a redeployment of existing capacity in response to relevant incentives.

1333    What constitutes the long run is therefore determined by the commercial realities of the industry in question.

1334    Seventh, the definition of a market does not require satisfaction of any size, value or other de minimis threshold. There may be both a wider and a narrower area of rivalry. But if the narrower area itself constitutes a market, then it is power and conduct in that area that is to be examined.

1335    Eighth, as McHugh J pointed out, the “views and practices of those within the industry are often most instructive on the question of achieving a realistic definition of the market” (Boral Besser Masonry at [257]). And in this regard, as he said, the “internal documents and papers of firms within the industry and who they perceive to be their competitors and whose conduct they seek to counter is always relevant to the question of market definition”. So, what market actors do or do not do can inform market definition. Further, what market actors perceive others to be doing or not doing or what they could do, which perceptions may inform their own actions, can also inform the question of market definition.

1336    Ninth, there is no one correct answer to market definition. Moreover, as Deane J explained in Queensland Wire Industries Pty Ltd v Broken Hill Proprietary Co Ltd (1989) 167 CLR 177 at 196:

…The economy is not divided into an identifiable number of discrete markets into one or other of which all trading activities can be neatly fitted. One overall market may overlap other markets and contain more narrowly defined markets which may, in their turn, overlap, the one with one or more others. The outer limits (including geographic confines) of a particular market are likely to be blurred: their definition will commonly involve assessment of the relative weight to be given to competing considerations in relation to questions such as the extent of product substitutability and the significance of competition between traders at different stages of distribution…

1337    Tenth, there may be sub-markets. Accepting, as one must, that within a market there may be demand-side substitutability and supply side-substitutability, there may be even more narrowly defined markets within the broader market where there may be discontinuity in substitution possibilities particularly in the short term so that only a closer and more immediate set of substitutes are relevant. So, such sub-markets may be a useful tool in conceptualising and analysing the short-run effects of change.

1338    Eleventh, a market ought not be defined in an unduly narrow manner. Taking too rigid an approach is apt to lead to unrealistic results. A market that is too narrowly described will create the appearance of more market power than in fact exists, and too broad a description has the converse effect.

1339    Twelfth, in Queensland Wire, Mason CJ and Wilson J said that “[d]efining the market and evaluating the degree of power in that market are part of the same process, and it is for the sake of simplicity of analysis that the two are separated” (at 187).

1340    Thirteenth, in Singapore Airlines Limited v Taprobane Tours WA Pty Ltd (1991) 33 FCR 158, French J said that there is necessarily a close relationship between the delineation of a market and the description of the distribution of power within it. His Honour then added that there is feedback between any proposed market and the structure and power distribution which that proposed market throws up.

1341    Now to conclude at this point I would note the observations in Australian Competition and Consumer Commission v Flight Centre Travel Group Limited (2016) 261 CLR 203 at [68] to [70] per Kiefel and Gageler JJ that I do not need to set out. But Flight Centre is instructive here as an example of taking into account the commercial context in which the relevant conduct takes place so as to ensure that the market is not divorced from commercial reality.

1342    Flight Centre was a travel agent that sold international airline tickets to customers as agent for certain airlines. The airlines also sold air tickets directly to customers. The ACCC alleged that the travel agent had contravened the price fixing provisions of the CCA by attempting to persuade each airline to agree not to sell tickets directly to customers at prices lower than the fares made available to the travel agent. The critical issue in the case was whether, despite the agency relationship, the airlines and Flight Centre were nonetheless in competition with each other.

1343    A majority of the Court rejected the ACCC’s primary contention that Flight Centre and the airlines competed against each other in a market for the supply of distribution services to airlines and booking services to customers. The basis for this rejection was that it was quite artificial to describe an airline as providing those services to itself when it was selling a ticket directly to a customer. But as noted at [73], there was no want of realism in describing Flight Centre as having provided distribution services to an airline when selling that airline’s ticket to a customer.

1344    Despite rejecting the ACCC’s primary market, the High Court determined that the special terms and conditions of the agency agreement between Flight Centre and the airlines meant that the travel agent was in competition with each airline in the market for the supply to customers of contractual rights to international air carriage. The decisive considerations were twofold. First, Flight Centre’s authority under the agency agreement extended not only to deciding whether or not to sell an airline’s tickets, but also to setting its own price for those tickets. And second, there was nothing to constrain Flight Centre in the exercise of that authority to prefer the interests of the airlines to its owns interests.

1345    Another feature of the Flight Centre case is that the question of market definition was approached by starting with questions as to what was being supplied, to whom, and at what price.

1346    Now it may be accepted that one should not take the functional approach to market definition too far and that one should not “construct, or deconstruct and reconstruct, the supply of a service in a manner divorced from the commercial context of the putative contravention which precipitates the analysis” (Flight Centre at [70]).

1347    And as demonstrated by the facts in Castlemaine Tooheys Ltd v Williams & Hodgson Transport Pty Ltd (1986) 162 CLR 395 at 403, Wilson J explained:

Here the transactions under scrutiny encompassed no more than the supply of goods. The beer was to be supplied at the premises of the retailer. Each supply was a single transaction which could not be broken up into its several elements of sale and delivery without doing violence to the reality. Delivery to the premises was an essential and therefore inseparable concomitant of the supply of the beer. In different circumstances it might well be appropriate to characterize the delivery of the goods as the supply of a service. But not here. No question of supplying a service arises.

1348    Now Apple says that it is artificial to split out the provision of payment solutions services as a separate market and that even if justified by economic theory it would not be consistent with commercial reality to do so. And Apple says that to do so would not truly reflect the commercial reality of the relevant relationship (Flight Centre at [123] per Nettle J).

1349    But in my view there is no artificiality or a lack of commercial reality by positing a separate market. And it cannot be the case that a supplier, purely by imposing a tie under a contractual obligation, can by such a means define away a separate market. And to use the words of Wilson J, the payment solution service was not “an essential and therefore inseparable concomitant” of app distribution services provided by Apple. I will return to this topic much later in my reasons as there is a little more to say about it.

1350    In summary then, the relevant frame of reference is as follows. I should first identify what is said to have been done in contravention of the CCA, what product or services are being supplied by the allegedly contravening party, and then ask what market definition best assists an assessment of that conduct and its asserted anti-competitive attributes.

1351    Further, as the defined market should comprise an area of potential close competition in particular goods or services and their substitutes, the appropriate starting point is to consider what the allegedly contravening party supplies, to whom, and at what price.

1352    And where the relevant goods or services are supplied under a contract, including in particular an agency contract, the approach to market definition must be consistent with the provisions of the contract under which the relevant goods and services are supplied. If that is not the case, the market definition will become divorced from the commercial context of the putative contravention and will not accord with commercial realities.

Apple’s threshold difficulties

1353    Now Apple criticises what are said to be Epic’s finely-drawn single-brand markets, which by definition erect Apple as the only supplier in those markets. It is said that to define a product dimension in a way that excludes other brands of the product will exclude real substitution possibilities.

1354    Further, Apple says that a functional, yet commercially realistic, approach to market definition does not countenance the identification of a market in which competition would be possible only in the theoretical circumstance that the defendant grants access to its property, which it otherwise does not permit and would not permit even in competitive conditions where existing conditions are truly not competitive.

1355    Apple made reference to Monroe Topple & Associates Pty Ltd v Institute of Chartered Accountants in Australia (2001) 122 FCR 110 where Monroe Topple alleged that the ICAA engaged in contravening conduct which substantially lessened competition in a market for the supply of certain support services to candidates seeking accountancy certifications.

1356    It was said that the ICAA had substantial market power in a CA certification market, being a market for the supply of the certification and admission to membership of the ICAA of persons as chartered accountants. But the trial judge rejected the pleaded market because there was absent the essential element of potential competition and potential substitutability in respect of the relevant services. It was said that certification and admission to membership of the ICAA was uniquely ICAA’s to grant such that there was no possibility for any substitutable product or for any competitor to enter the supposed CA certification market. That conclusion was upheld on appeal.

1357    Now Apple accepts that a market may be a field of not only actual but also potential rivalry. And a substantial lessening of competition in a market calls for a comparison of likely future competitive conditions with and without the impugned conduct, rather than a before and after comparison.

1358    Clearly, as Apple accepts, Part IV of the CCA leaves room for cases where the appropriate market lens is a field of rivalry that does not yet exist, but is only nascent or potential. But whilst a market may be a field of potential rivalry, Apple says that it cannot be just a field of theoretical rivalry. And it says that the distinction between potential and theoretical rivalry is important.

1359    A market may exist even though the rivalry it describes is merely potential because, say, the sources of substitution and therefore constraint arise from the real prospect of new entry or even a reasonable perception of the real possibility of new entry. But Apple says that putative rivalry is not elevated from the purely theoretical to the cognisably potential where that putative rivalry could only exist if one fashioned mandatory relief to compel a firm to supply a service that it has never supplied and where the non-supply of the service cannot be shown to be the outworking only of a lack of competitive conditions.

1360    Apple accepts that a market can exist even if there is only one seller, because even formidable barriers to entry could change, such that one can meaningfully postulate potential competition.

1361    But Apple says that as Heerey J explained in Monroe Topple, “the position is different when the good or service is incapable of separation from the identity of the supplier” (at [82]).

1362    Now Apple says that the point is particularly acute where the property in question is intellectual property. It says that this is so because intellectual property arises from statutory norms which offer limited monopoly rights to incentivise investment and innovation. It says that the good or service is, because of the intellectual property rights which define it, incapable of separation from the identity of the supplier.

1363    Firms compete to innovate and acquire those statutory rights. So, when one asks of an intellectual property holder who might have a degree of market power by virtue of its IP rights, whether it would be able to restrict supply in competitive conditions, one cannot take a temporal perspective that excludes the anterior competition for the IP rights.

1364    Apple says that it is illogical, by reason of internal contradiction, to posit competitive conditions in which its IP rights do not exist, and then conclude that, in those conditions, it would need to licence those rights in order to compete with others also licensing the rights.

1365    Apple says that whilst competition law properly regulates IP rights-holders from dealing with their property in ways that might impair competition in relevant markets, competition law does not seek to undermine IP rights through the use of markets unrealistically defined by reference to those rights.

1366    Further, Apple says that other authorities illustrate the need to identify potential rather than hypothetical competition.

1367    Queensland Wire concerned the supply by BHP of Y-bar, a steel product which was used to manufacture star pickets, a popular kind of rural fencing.

1368    Now Apple says that the case did not depend on a confected single-brand market. Rather, BHP straightforwardly had substantial market power in a market for steel products. It supplied Y-bar to its own subsidiaries, who then traded in a competitive market for rural fencing. It refused to supply Y-bar to its subsidiaries’ actual competitor(s) in rural fencing markets or offered to supply on prohibitive terms.

1369    Apple says that BHP’s control of Y-bar did not arise from particular innovation or intellectual property. It arose from its dominance in the manufacture of steel products generally. BHP’s position was not analysed in a market for the supply of BHP Y-bar. On the contrary, the upstream market was simply steel products and BHP had substantial dominance in the market even conceived at that level of abstraction, which was appropriately capable of taking account of substitutes had they existed. If there had been a competitive market for steel products, BHP could not have afforded to restrict its supply of Y-bar.

1370    Apple says that such circumstances are far removed from the present context before me, where the conditions under which Apple operates its App Store are conditions it has developed in order to compete with other platforms. They are not conditions which Apple can only afford to offer because of market power.

1371    Apple has referred to Dowling v Dalgety Australia Limited (1992) 34 FCR 109 which concerned a livestock association established by three major pastoral houses to manage the Goondiwindi Saleyards at which they conducted livestock auctions. Mr Dowling, an independent auctioneer, wanted access to the saleyards in order to conduct his auctions, but the association’s agreement was that the saleyards would not be let to outside agents. There were no satisfactory alternative locations at which Mr Dowling could auction livestock. Mr Dowling argued that there was a market for auctioning livestock in Goondiwindi and sought an order compelling the association to permit him to auction livestock at their Goondiwindi Saleyards.

1372    But the relevant market was found to be livestock selling services, not just auctioneering services. That was because all selling services were closely related and substitutable, though auctioneering was the most popular.

1373    Moreover, in considering s 46, the trial judge accepted the association’s submission that no market existed that arose from the right of ownership of the Goondiwindi Saleyards as it might, for example, where a proprietor was in the business of granting licences to use the saleyards and refused to do so.

1374    Apple says that a firm’s investment in its own platform to facilitate transactions between buyers and sellers, however integral to the firm’s commercial success, does not become common property under competition law because others assert that they would like to use it to compete with the firm.

1375    Further, Apple says that NT Power is not an example of the capacity of s 46 to emulate access remedies otherwise available under the distinctive regime in Part IIIA of the CCA.

1376    Now the High Court observed in obiter dicta that s 46 might be attracted to conduct involving a refusal to supply intellectual property, or a supply of it on particular conditions, and that remedies for contravention of s 46 could involve coercive supply of goods or services, and the Court also rejected a submission that a firm’s exploitation of property rights was necessarily outside the control of s 46 given that property rights can be a source of market power. But Apple says that that was not to say that one can define a market by reference to a firm’s property rights in order to bootstrap the analysis of market power.

1377    Now the markets in question were electricity markets involving the functions of transmission, distribution and, perhaps, infrastructure and carriage. But the Power and Water Authority (PAWA) had market power in one or more of those markets because it was the owner of natural monopoly assets. It did not have market power because the market had been defined as PAWA-branded electricity.

1378    As in Queensland Wire, if PAWA had been supplying electricity services in a competitive market, then it could not commercially have restricted supply to NT Power.

1379    Apple says that these cases illustrate that there is no basis to take a firm’s property such as intellectual property as the starting point for defining the product dimension of a market. Rather, the product dimension should be characterised in a commercially realistic fashion, which allows for the possibility of substitutes. Apple says that it may then be, on factual analysis, that a firm has market power because of some accumulation of property rights relevant to trading in that market.

1380    In summary, Apple says that Epic’s posited market for iOS app distribution is, by definition, a market for the provision of rights to access Apple’s platform, with all of the associated tools, technologies and supporting intellectual property, and use Apple’s platform by distributing third party apps outside the App Store. But Apple does not and never has granted such rights.

1381    Further, Apple says that it makes no sense to posit that there is and has been since 2008 a market in which Apple has actual or potential rivals in the provision of a service of this kind. No such rivals could exist unless Apple decided, for the first time, to grant them the rights that they would need to operate in this way.

1382    So, Apple says that Epic’s market for iOS app distribution services is contrived and legally impossible. It says that it is not a sensible lens to analyse commercial realities or the conduct that has occurred.

1383    Further, Apple says that I cannot use my fairy wand to wave into existence either a market or a compulsory access regime. It says that it is not within my power to compel Apple to bring a market into existence by ordering that Apple grant the necessary access to its tools, technology and supporting intellectual property. It is said that Epic is in substance trying to create a compulsory access regime in respect of Apple’s iOS ecosystem, but through Part IV of the CCA, not Part IIIA.

Analysis

1384    Now I have no difficulty in rejecting Apple’s self-centred argument that there can be no field of rivalry between Apple and any potential competitor for the provision of services for the distribution of iOS apps or for the provision of in-app payment solutions services, in circumstances where Apple’s intellectual property rights give it exclusive control over any market in which Apple might compete with such competitors.

1385    As Epic points out, to posit that Apple’s exclusive control over any relevant market arises by reason of Apple’s lawful control over its intellectual property begs the question as to whether, on the facts of this case, Apple’s control has been lawfully exercised. Neither intellectual property rights nor the terms of an intellectual property licence can provide any shield against the operation of the CCA in the absence of a relevant statutory exemption or exception.

1386    Furthermore, even if access to a corporation’s property is a prerequisite to the functioning of a market, that does not mean that that market does not exist for the purposes of competition law. And if the conduct of that corporation in respect of such a market otherwise satisfies the terms of ss 45, 46 or 47, the corporation will thereby commit a contravention, a consequence of which might include an order requiring the contravener to give competitors access to its property.

1387    As Epic correctly characterised the matter, Apple’s argument amounts to a contention that the market definition exercise depends wholly on Apple’s commercial choices and that the iOS app distribution market should be rejected because competition in that market depends on Apple granting access to its property, which Apple does not do and which is no more than theoretical. I have no difficulty in rejecting such an Apple-centric perspective.

1388    Now in Queensland Wire, BHP was the only manufacturer of Y-bar in Australia, and no significant quantities had been imported. A Full Court of this Court had decided that because BHP had never sold Y-bar, there had never been a market for Y-bar so as to attract the operation of s 46.

1389    On appeal, Deane J found that a local market nevertheless existed for Y-bar. It was sufficient for the existence of such a market that there be an arm’s length potential purchaser and a potential vendor. The fact that there were no local arm’s length sales of Y-bar arose only because BHP’s price was unrealistically high. His Honour (at 196) was of the view that:

… a market may exist for particular existing goods at a particular level if there exists a demand for (and the potential for competition between traders in) such goods at that level, notwithstanding that there is no supplier of, nor trade in, those goods at a given time — because, for example, one party is unwilling to enter into any transaction at the price or on the conditions set by the other. …

1390    Necessarily, any sale by BHP of Y-bar to a potential purchaser would have involved a transfer of BHP’s property to the purchaser, which property BHP had not previously made available to any arm’s length purchaser otherwise than for an unrealistically high price.

1391    In NT Power, the appellant, NT Power, sought access to electricity transmission and distribution infrastructure owned by PAWA. Without that access, NT Power could not sell electrical power to consumers. Those facts did not cause the High Court to question the existence of a market or markets predicated on PAWA’s infrastructure, namely, the market or markets for the supply of services for the transport of electricity along PAWA’s infrastructure, including its transmission and distribution network.

1392    Relevantly, the plurality also considered a submission by PAWA as to the relationship between the provisions of Part IIIA of the CCA and s 46. Aside from noticing that s 44ZZNA provides that Part IIIA is to have no effect on the operation of Part IV, their Honours made these pertinent observations about the operation of s 46 in cases concerning access to property, including intellectual property (at [85]):

… The legislative scheme contemplates that whether the conduct is refusal to supply intellectual property, or the supply of it on particular conditions, s 46 can be attracted. The fact that s 46 can apply to intellectual property rights, and hence to the market power which they can give, suggests that it can apply to the use of market power derived from other property rights not specifically mentioned in the Act. …

(citations omitted)

1393    Now as I have said, Apple says that the iOS app distribution market should be rejected because competition in that market depends on Apple granting access to its property, which Apple does not and would not do, and which is no more than theoretical.

1394    But as Epic correctly points out, the same oddity that is said to attend Epic’s case would arise in asking whether it is rational or possible for a new entrant to trespass onto the real property of a business and start conducting a rival business from that property. But that is, in substance, the same circumstance as arose when NT Power sought access to PAWA’s property to start conducting a rival business to PAWA’s.

1395    The fact that the property was PAWA’s did not mean that it was not rational or possible to ask whether NT Power could compete with PAWA, or that there did not exist any relevant market. To the contrary, the relevant market or markets were predicated on PAWA’s property, which was also a key criterion in determining the existence and extent of its market power.

1396    Further, according to the plurality in NT Power, property rights can be a source of market power attracting liability under Part IV of the CCA, and “intellectual property rights are often a very clear source of market power” (at [125]).

1397    Further, even if Apple could establish that the markets for which Epic contends are subject to Apple’s exclusive control by reason of its intellectual property rights, it does not follow that those markets are in any way artificial, or that Apple does not have substantial power in them, or that Apple’s anti-competitive conduct falls outside the scope of ss 45, 46 and/or 47 of the CCA.

1398    In NT Power, PAWA was found to have substantial power in markets for the supply of services for the transport of electricity along PAWA’s infrastructure, howsoever defined, which were therefore defined by reference to PAWA’s proprietary infrastructure. The majority rejected a submission that certain markets did not exist because PAWA did not supply goods and services in the market, and had only ever used its infrastructure for its own purposes. It did so because there was at least the potential for transactions, including because NT Power wanted to acquire the relevant services.

1399    Moreover, in Queensland Wire Deane J observed (at 196):

While actual competition must exist and be assessed in the context of a market, a market can exist if there be the potential for close competition even though none in fact exists. A market will continue to exist even though dealings in it be temporarily dormant or suspended. Indeed, for the purposes of the Act, a market may exist for particular existing goods at a particular level if there exists a demand for (and the potential for competition between traders in) such goods at that level, notwithstanding that there is no supplier of, nor trade in, those goods at a given time – because, for example, one party is unwilling to enter any transaction at the price or on the conditions set by the other. It is, however, unnecessary to pursue that question for the purposes of the present appeal.

1400    Dawson J stated (at 200):

… It must be sufficient to constitute a market that there is a product for exchange, regardless of whether exchange or negotiation for exchange has actually taken place.

1401    Toohey J said (at 211 and 212):

… It would be a curious consequence if the offering by B.H.P. of a limited supply of Y-bar established a market for that product but the withholding of supply altogether meant that there was no market. …

1402    Contrastingly, Apple seeks to deny the potential for transactions in the iOS app distribution market by focusing exclusively on Apple’s own perspective. In so doing, it ignores that there exists a “product for exchange”, that there exists demand for alternative iOS app distribution services, and that there exist potential suppliers of iOS app distribution services other than itself.

1403    I agree with Epic that that self-reinforcing constricted focus is inconsistent with both NT Power and Queensland Wire.

1404    Further, Apple’s reliance on the statement of McHugh J in Boral Besser Masonry is misplaced. Rather than considering the possibility of rivalry, his Honour was referring to interactions between producers and consumers in addressing the different question of substitution at the outer bounds of an extant market.

1405    But in the present case there is nothing theoretical about the interactions between producers and consumers of iOS app distribution services. Apple supplies those services at a considerable scale every day. This is to be contrasted with the potentialities that were sufficient for the definition of markets in Queensland Wire and NT Power.

1406    Further, Australian Competition and Consumer Commission v Pfizer Australia Pty Ltd (2018) 356 ALR 582 is also inconsistent with Apple’s contention.

1407    Greenwood, Middleton and Foster JJ held that Pfizer had market power in the market for the supply of atorvastatin that spanned two relevant periods, with the first period being from late 2010 until late 2011, during which atorvastatin was supplied only by Pfizer under its subsisting patent, and the second period being between January 2012 and May 2012, during which Pfizer continued to supply its branded drug under its subsisting patent but also launched a generic atorvastatin. In this second period, Pfizer also licensed another entity to market atorvastatin on and from 19 February 2012. There was also a third period after May 2012 when the patent expired but the Court did not have any evidence that would have allowed it to define a market for that period.

1408    It was said at [238]:

Three separate periods are to be identified and distinguished. The first period is the period before January 2012. In particular, the period between late 2010 and late 2011. Throughout this first period, atorvastatin was supplied in Australia only by Pfizer and only as a branded product (Lipitor). Pfizer accepted at trial and on appeal that, throughout this first period, the relevant market was the atorvastatin market (as defined by the ACCC). The second period is the period between January 2012 and 18 May 2012. During this second period, Pfizer continued to supply Lipitor but also launched its generic atorvastatin under the name “Atorvastatin Pfizer”. After 18 February 2012, Ranbaxy Australia began to supply its generic atorvastatin (Trovas) in Australia. Its market share was insignificant. A number of other substantial manufacturers of generic pharmaceuticals intended and were expected to commence supply of generic atorvastatin soon after 18 May 2012. The impending entry of those generics manufacturers was going to be a close constraint upon Pfizer in the relevant market after 18 May 2012. The basis of that close constraint was the ability of those generics manufacturers to supply and thus compete, not only in respect of atorvastatin, but across a range of generics which was their usual mode of supply. The third period is the period after 18 May 2012, the date when the atorvastatin patent would expire.

1409    It was said at [256]:

For the duration of the whole of the period of the relevant impugned conduct for s 46 purposes and up until the time when pharmacies could sell generic atorvastatin under the PBS acquired from Pfizer’s competitors (Ranbaxy Australia from 1 April 2012 and others from 1 June 2012) there was no supply-side substitutability by reason of Pfizer’s patent.

1410    More generally, and consistently with what I have said earlier as to how market definition should be approached, it was said at [282] and [286]:

The starting point for our consideration of the correct definition of market in the present case is the identification of what it is that is said to have been done in contravention of s 46 and in contravention of s 47.

…

As the authorities make clear, the Court begins with its articulation of the impugned conduct and asks what market identification best assists the assessment of that conduct and its asserted anti-competitive attributes. The Court is looking to identify the area or areas of close competition of relevance to the impugned conduct. What is the field or rivalry between the relevant competitors?

1411    Further, it was said at [294] to [298]:

As to time, as we have already mentioned, ultimately the parties agreed that, in the period from mid-2010 to the end of 2011, the relevant market was the atorvastatin market. Throughout that period, Pfizer had control of the atorvastatin patent and, for that reason, had a monopoly over the supply of atorvastatin in Australia which it exploited by supplying Lipitor, its branded product, as a single molecule. It did not supply its generic product atorvastatin Pfizer at any time during this period.

The second and most significant period was the period from January 2012 up to the date when the atorvastatin patent expired (18 May 2012). This was the period when the critical steps giving effect to Project LEAP, viz the making of the bundled offers in January and February 2012 and the subsequent supply of atorvastatin in accordance with those offers, were taken.

The third period was the period after the expiry of the atorvastatin patent ie the period after 18 May 2012. This was the period to which Pfizer’s allegedly anti-competitive purposes were directed. The primary judge noted (at [260]) that the definition of the relevant market post 18 May 2012 had not been addressed in the evidence before him so that, for that reason, could not be resolved. In the same paragraph of his Reasons, his Honour also observed that, whether there was a generics market for pharmaceuticals in 2012 and 2013, as submitted by Pfizer, was not a question which had to be resolved in the present case. These remarks were correct. …

Thus, it was essential in the present case to define the relevant market as it existed in the period between January 2012 and 18 May 2012 and to have some reasonable idea of that market in the period immediately after the expiry of the atorvastatin [patent].

The critical issue insofar as the definition of the relevant market in the first half of 2012 was concerned was: What was the product dimension of the relevant market? The ACCC and its expert, Dr Pleatsikas, were of the opinion that the product dimension was the single molecule atorvastatin. Pfizer and its expert, Dr Addanki, argued that the true product dimension of the relevant market in this period was a broad range of generic pharmaceuticals, even though atorvastatin was never supplied as part of such a range at any time in this period nor had it been so supplied at any time in the past.

1412    Further, it was said at [302] and [303]:

Ranbaxy Australia was the only supplier of atorvastatin in Australia in addition to Pfizer in the period from January 2012 to 18 May 2012. Other generics manufacturers were not supplying in the market until June 2012. For some months after June 2012, atorvastatin continued to be supplied as an individual molecule and not as part of any broad range of generic pharmaceuticals. This period was, as expected by all relevant players, a period of intense competition. The competition was, however, in respect of the supply of the single molecule — atorvastatin — and not in respect of a broad range of generic pharmaceuticals which by then included atorvastatin.

As submitted by the ACCC, Pfizer’s submissions failed to distinguish between substitution possibilities and close constraints. Pfizer’s approach also blurred the distinction between defining a market and discerning whether any particular supplier of goods has market power in that market as defined.

1413    I would just interrupt the flow here to say that Apple’s case and Google’s case both suffer from a failure to properly distinguish between substitution possibilities and close constraints as I will discuss in detail later and also in my reasons in the Epic v Google proceeding.

1414    Further, it was said at [307]:

For all of the above reasons, Pfizer has failed to demonstrate error in the primary judge’s conclusion that the relevant market for the purposes of the ACCC’s s 46 case and for the purposes of its s 47 case throughout the period from mid-2010 to 18 May 2012 (and for some months thereafter) was the atorvastatin market (ie the market postulated by the ACCC). …

1415    So, an essential step in the reasoning was to define the relevant market in the second period because that was the period in which Pfizer was alleged to have taken advantage of its market power by making bundled offers to pharmacies that covered both its patented product and its generic version of atorvastatin. The Court held that the subsistence of the patent in the first period and the second period did not prevent the recognition of a market for the supply of goods and services within the meaning of s 46.

1416    Now Apple further argues that the CCA does not countenance markets defined by reference to its intellectual property rights. But the iOS app distribution services market is defined by reference to services actually supplied by Apple, rather than being defined by reference to intellectual property rights.

1417    In any event, and as Epic points out, Apple’s argument is merely another way of saying that a market should not be defined if it consists of the provision of services utilising particular property of a single firm, contrary to NT Power and ACCC v Pfizer.

1418    Further, I also agree with Epic that Apple’s reliance on Monroe Topple is likewise misdirected.

1419    Heerey J said at [82]:

… Of course, a market can exist even if there is only one seller (or buyer). This is because the concept is as much concerned with potentialities as present actualities. Barriers to entry may be formidable, for example in preprivatisation Australia where telephone services were provided by a statutorily entrenched monopolist. But this could change, as in fact it did. In such a case the good or service is something external to the monopolist. The possibility always exists, however theoretical, for the good or service to be provided by new entrants to the market. But the position is different when the good or service is incapable of separation from the identity of the supplier. To take another example, there might be said to be an Australian novelists' market in which novelists compete to sell their novels to publishers. But one would not say there was a separate Tim Winton novels market or a separate Richard Flanagan novels market.

1420    Tamberlin J said at [130] to [133]:

Where there is no competition in the market, because of domination by a monopoly, it cannot be said that “the market” has disappeared. While there may be no present competitive activity in a market dominated by a monopoly, it does not follow that there is no market because there is an absence of actual competition. There may be potential competition. However, prima facie, at least, the absence of actual or prospective competition in the goods or services in question or their substitutes, is an important indication that there is no market.

In my view, it is not correct to contend that the position in the present case is similar to that which prevails where there is a market but no competition or substitutability because an existing monopoly precludes any competitive or substitution activity. In the case of a market dominated by a monopoly there may remain the prospect of future potential competition by the market being opened up. In the present case there is no real prospect of such potential competition. The conferral of a professional, educational certification or endorsement that the standards of a particular professional body have been met cannot, in my opinion, be considered analogous to a market in relation to a brand product. As the primary judge emphasised, the service offered and the training and educational activity engaged in are unique.

To speak in terms of a “CA certification market” therefore in the present case, is artificial and inappropriate.

The contention that there is not a CA certification market so narrowly defined, in circumstances where there is a broader market for certification services, is supported by the fact that there is a broader market for certification which sits more easily with the concepts of competition and substitution within a market. The existence of such a market tends to indicate that it is too narrow an approach to proceed on the narrower basis that there is a separate CA certification market.

1421    Further, he said at [137]:

… If one asks the question who apart from the ICAA can confer CA certification as a chartered accountant either at the present time or foreseeably in the future? The answer must be “no-one”. This is because only the ICAA can ever confer such a CA certificate according to its standards and requirements. The grant of its certification cannot ever be the subject of substitution or competition. It is not possible to envisage the provision of CA certification by the Society or any other body. Other bodies apart from the ICAA and the Society may be established from time to time and may offer admission into their accounting profession, but such entry involves a different service or product in a broader market namely, the market for certification as opposed to CA certification. If the ICAA conducts itself in an unreasonable way in relation to its certification, then candidates for admission to the accounting profession can go to the Society, or any other body that offers certification, rather than to the ICAA.

1422    The following conclusions can be drawn from Monroe Topple.

1423    Both Heerey J and Tamberlin J expressly distinguished the case before them from a case where there is an existing monopoly but its existence does not exclude the prospect of future potential competition being opened up.

1424    Further, Heerey J and Tamberlin J concluded that the alleged CA certificate market was artificial because the change from the initial PY Training Program to what was called the CA Program was in reality simply a variation of a single professional training and qualification program, and no new market came into existence with that change.

1425    Further, Tamberlin J concluded that the supposed CA certification market was artificial because only the ICAA could ever confer a CA certificate, and the grant of such a certificate could not ever be the subject of substitution or competition.

1426    But I agree with Epic that the above circumstances have no analogy to the iOS app distribution market, which does not presuppose that any third party assumes the identity of Apple.

1427    Absent Apple’s conduct, there could and would likely be potential suppliers of iOS app distribution services. The present unity of product and supplier in Apple’s case is the result of a commercial decision made and enforced by Apple, rather than inhering in any intrinsic inability of any firm other than Apple to supply iOS app distribution services.

1428    Further, Dowling v Dalgety does not stand for the proposition that a firm’s “own platform … does not become common property under the competition law because others assert that they would like to use it to “compete” with the firm”. Such an assertion is inconsistent with the way in which Dowling v Dalgety was explained and distinguished in NT Power, where the majority concluded (at [126]):

In short, Dowling v Dalgety Australia Ltd is not authority for any general proposition that a property owner who declines to permit competitors to use the property is immune from s 46. That proposition is, in any event, intrinsically unsound.

1429    Further, s 44ZZNA demonstrates that recourse to Part IIIA to inform the scope of Part IV is misplaced. Section 44ZZNA provides that the former is to have no effect on the operation of the latter.

1430    Moreover, in NT Power it was concluded at [85]:

Indeed, the supposed disharmony would weigh against s 46 being used to create an access regime of any kind, and Lee J, who was of the opinion that s 46 “does not purport to interfere with the due exercise of rights of property per se”, gave various examples of the supposed inability of one competitor to obtain access to the real or personal property of another. However, private traders could be obliged to supply goods or services against their will before s 2B was enacted, provided the preconditions to s 46 liability were satisfied. Lee J accepted that this was so for intellectual property rights. The exclusion by s 51 of various types of conduct from Pt IV is limited in relation to intellectual property rights. In deciding whether Pt IV has been contravened, anything specified in, or specifically authorised by, a Commonwealth Act must be disregarded - but not an Act relating to patents, trademarks, designs or copyrights: s 51(1)(a). A contravention of a provision of Pt IV is not to be taken to have been committed by various licences and other contracts, arrangements or understandings relating to patents, registered designs, copyright and other rights, and trademarks - but this does not apply to ss 46, 46A and 48: s 51(3). The legislative scheme contemplates that whether the conduct is refusal to supply intellectual property, or the supply of it on particular conditions, s 46 can be attracted. The fact that s 46 can apply to intellectual property rights, and hence to the market power which they can give, suggests that it can apply to the use of market power derived from other property rights not specifically mentioned in the Act. It follows that, provided the notoriously difficult task of satisfying the criteria of liability can be carried out, s 46 can be used to create access regimes, and that s 2B is not to be read down as if it could not.

1431    So, s 46 can be used to create access regimes, including with respect to intellectual property rights, and so to the market power which they can give.

1432    Further, s 51(1)(a) makes it clear that Parliament did not intend that intellectual property rights could provide a broad shield to contraventions of Part IV. Indeed, as Epic says, that result is indisputable following the repeal of s 51(3), which, in any event, never applied to s 46 and did not in terms extend to refusals to license intellectual property.

1433    Now Apple’s whole case thesis seems to be that because it has exclusive rights to certain broadly-asserted intellectual property, it should be at liberty to exploit its rights in that property, including in relation to the provision of services that are not the subject of any intellectual property, in a manner outside or beyond the constraints of the provisions of the CCA. But if that is its case, I reject it.

1434    Let me make one other point. Epic Games ran a similar case as the present case in the Northern District of California (Epic Games Inc v Apple Inc, 559 F Supp 3d 898 (ND Cal, 2021)) and on appeal to the United States Court of Appeals for the Ninth Circuit (Epic Games, Inc v Apple, Inc, 67 F 4th 946 (9th Cir. 2023)). But its market definition was not accepted. But it is unproductive to analyse those reasons in any detail. I am applying legal and economic concepts under Australian law on the basis of the evidence and arguments put before me.

1435    Now before proceeding further I should say something about the economic experts. I will then elaborate further on some of the economic themes by reference to some of the economic literature. I will discuss some other legal principles applicable to s 46 much later in my reasons after I have disposed of market definition questions.

The economic experts — general

Epic’s experts

1436    In the Apple proceeding Epic led evidence from Professor Julian Wright and Professor Avi Goldfarb on economics and econometric questions.

1437    Professor Wright has considerable expertise in platform economics, including digital platforms. These have been the subject of both his research and teaching activities, as well as his consulting to regulatory authorities and commercial entities.

1438    Professor Wright, an expert economist, gave evidence for Epic in the Apple proceeding. He is a professor in the Department of Economics at the National University of Singapore.

1439    Professor Wright prepared two reports dealing with questions of market definition, market power and competition questions generally. His second report responded to the reports of Professor Hitt, Mr Houston and Dr Majumdar.

1440    Professor Wright participated in a joint expert report with Professor Hitt, Professor Goldfarb, Mr Houston, Mr Holt and Dr Majumdar. He gave evidence in concurrent evidence sessions and was cross-examined by Mr Darke SC for Apple.

1441    In my view Professor Wright displayed extensive expertise and had complete independence and objectivity. In terms of independence and objectivity he had the edge over Professor Hitt and Mr Houston in my view.

1442    I have no caveats at all over his reliability and most of his views concerning the underlying subject matter. As should be apparent, where opinions have conflicted I have preferred the evidence of Professor Wright over the evidence of Professor Hitt and/or Mr Houston.

1443    Now Mr Darke SC attempted in cross-examination to cast doubt on Professor Wright’s framework and his conclusions. But in my view he was substantially unsuccessful. In my view Professor Wright’s evidence particularly concerning market definition best accorded with the commercial reality of what Apple was doing, the services it supplied, the context and the framework within which I should assess Apple’s alleged conduct.

1444    It is convenient to mention one other matter at this point.

1445    Mr Darke SC on one particular day cross-examined Professor Wright about his understanding of IAP and how that fitted into the question of market definition and in particular whether there was a separate payments solutions market. The next day, although the parties and I had moved on to a new topic, Mr Darke SC sought to go back for his hat so to speak on the previous day’s topic. I did not permit this, and no doubt Mr Darke SC may have felt aggrieved by not being permitted to revisit the topic with the witness. But the Court had to move on. Moreover, the questions more turned on fundamental base facts as to what Apple was supplying or providing and at particular points, which were matters for me and submissions ultimately, rather than economic theory. If Professor Wright was in error in the foundational factual position, then his secondary and overlayed opinions would fail for lack of a proper foundation as I explained to Mr Darke SC, albeit that he seemed reluctant to so accept.

1446    Professor Goldfarb, a professor in marketing, data science, artificial intelligence and economics at the University of Toronto, Canada, gave expert evidence for Epic in both the Apple proceeding and the Google proceeding.

1447    He had specific and detailed expertise in analysing consumer behaviour related to digital markets and applying econometric analysis to such topics. Of all of the experts addressing such topics, his views on the appropriate econometric and associated analysis and questions had the most influence and weight with me.

1448    In the Apple proceeding, in his two primary reports he addressed the substitutability of the usage of native apps on iOS devices with other apps, the substitutability of in-app purchases with out of app purchases, the Fortnite hotfix event and Fortnite adjusted revenues in that context. He also replied to Professor Hitt’s and Mr Houston’s evidence.

1449    He also participated in a joint economic expert report with Professor Hitt, Mr Houston, Mr Holt, Professor Wright and Dr Majumdar. His evidence was given in concurrent evidence sessions. He was cross-examined by Mr Darke SC for Apple.

1450    In my view Professor Goldfarb was a very impressive and reliable witness and I have no significant caveats about any of his evidence. I will discuss the specific subject matter of his evidence in the Apple proceeding later. But I should note that for the most part I have preferred his evidence over the corresponding Apple witnesses, namely, Professor Hitt and Mr Houston.

1451    In the Google proceeding, in his primary report Professor Goldfarb addressed analogous questions but focused on Android smart mobile devices. In his reply report he responded to the reports of Professor Asker and Professor Gneezy.

1452    He also participated in a joint economic expert report with Professor Asker and Ms Edwards-Warren. His evidence was given in concurrent evidence sessions. He was cross-examined by Mr Moore SC for Google.

1453    I would make similar observations concerning the quality of Professor Goldfarb’s evidence to what I have said about his evidence in the Apple proceeding. Specifically, where there have been differences between Professor Goldfarb and Professor Asker on econometric analysis, I have preferred the views of Professor Goldfarb.

1454    Professor Goldfarb also participated in a joint expert report with Professor Gneezy and Professor Luca. In a concurrent evidence session he was briefly cross-examined by Mr Yezerski SC for Google. I will address that evidence later.

1455    Finally, lest there be a doubt, I have accepted his themes dealing with the perspective and behaviour of users, which have been colloquially described in the evidence as, first, “clicks are costly” and, second, “device first”.

1456    His second report was directed to assessing the extent to which iOS users and developers treated alternative platforms as substitutes for iOS native app usage and in-app purchases.

Apple’s experts

1457    Apple led evidence from Professor Loren Hitt and Mr Greg Houston.

1458    Professor Hitt, an expert economist, gave evidence for Apple. He is a professor in the Operations, Information and Decisions Department, Wharton School, University of Pennsylvania.

1459    He prepared a report dealing with questions of market definition, market power and competition questions generally. He also responded to reports from Professor Wright, Professor Goldfarb and Mr Holt.

1460    Professor Hitt participated in a joint expert report with Professor Wright, Professor Goldfarb, Mr Holt, Mr Houston and Dr Majumdar and gave evidence in concurrent sessions. He was cross-examined by Mr Young KC for Epic and Mr Bannon SC for the class applicants.

1461    There is little doubting Professor Hitt’s fine expertise and his distinguished background. But I did prefer the evidence of Professor Wright and Professor Goldfarb. I say that for several general reasons.

1462    First, Professor Hitt did not have complete independence given that he had previously given evidence for Apple and had already formed and expressed views on analogous questions in related US proceedings.

1463    Second, I did not consider that he approached the market definition question by properly looking at Apple’s position and alleged conduct and then formulating a definition based upon or properly considering what Apple did and supplied or is alleged to have done.

1464    Third, in relation to market definition and what Apple supplied or provided to developers and users, I found his product or service description of “app transactions” and a market for “app transactions” or a sub-set or many subsets thereof to be problematic. I will elaborate on this later.

1465    Fourth, he did not have the much deeper experience as an anti-trust economist that Professor Wright had. Indeed, it would seem that he did not have significant experience in carrying out any HMT analysis or test. Professor Hitt’s research has focused on the economic value of information technology and consumer behaviour.

1466    Let me elaborate on the first point.

1467    Now Professor Hitt has been retained by Apple to provide evidence in numerous proceedings, including the proceedings brought by Epic against Apple in the US. Professor Hitt said that, whilst not a majority of his work, this constituted a substantial portion. In my view, Professor Hitt’s ongoing and repeated role as an expert witness on behalf of Apple has affected his ability to bring a fully objective mind to the issues in this proceeding.

1468    Further, there were problematic aspects concerning the source of his knowledge and the bases of his opinions. For example, in answer to questions posed in cross-examination, Professor Hitt suggested that his opinions were sound because he had had the opportunity to study the App Store for approximately five or six years, with great access to documents and materials. Now whilst those documents may have been disclosed in Professor Hitt’s reports in proceedings in the US, it is not apparent that they were all disclosed in his report in this proceeding.

1469    More specifically, Professor Hitt’s role in the proceedings brought by Epic against Apple in the US causes me some doubt in accepting his evidence, particularly where it is contradicted by Professor Wright.

1470    In the US proceedings, Apple led evidence from Professor Lafontaine and Professor Schmalensee, in addition to Professor Hitt.

1471    In those proceedings, Professor Hitt relied on Professor Lafontaine for the identification of the relevant product and for market definition. In the present proceedings, Professor Hitt adopted the procedure for defining markets advanced by Professor Lafontaine.

1472    Similarly, in the US proceedings, Professor Hitt relied on the evidence of Professor Schmalensee for two-sided market issues as to the particular case. This tends to support the view that I should prefer the evidence of Professor Wright over that of Professor Hitt in relation to matters concerning two-sided markets as applied to the present case, given Professor Hitt’s evident partial reliance on the opinions of others for his understanding of those issues. Professor Hitt’s partial reliance on Professor Schmalensee also affected his assessment of whether IAP is a separate product. In the US proceedings, it was Professor Schmalensee who addressed that question. Professor Hitt did not give evidence on the topic. The views proposed by Professor Hitt in his evidence in this proceeding were derived from those expressed by Professor Schmalensee. I would accord limited weight to Professor Hitt’s evidence on this topic, given its evident derivation from the opinions expressed by a different expert whom Apple elected not to call in this proceeding.

1473    Now I accept that Professor Hitt did in some sense exercise a degree of independence. But it does seem to me that the views of others had some influence, and he did not have complete independence.

1474    I will return to another point concerning Professor Hitt in a moment. But let me first say something about Mr Houston.

1475    Mr Houston, an expert economist and the founding partner of Houston Kemp, gave evidence for Apple in the Apple proceeding concerning market definition, market power and other competition questions. He responded to Professor Wright’s evidence. He also prepared a supplementary report. He also dealt with some aspects of Mr Holt’s evidence.

1476    He also participated in a joint expert report with Professor Hitt, Professor Wright, Professor Goldfarb, Mr Holt and Dr Majumdar. But I constrained his participation in the concurrent evidence sessions for reasons previously indicated to the parties, save that he did participate in one concurrent evidence session with Professor Hitt and Mr Holt.

1477    Mr Houston was separately cross-examined by Mr Young KC for Epic. Further, Mr Bannon SC for the class applicants cross-examined Mr Houston in the concurrent evidence session that I have just mentioned.

1478    Clearly, Mr Houston is a fine economist and a very experienced expert witness. But I had significant difficulties with the way in which he had been retained, being briefed with significant US evidentiary material from prior proceedings that may have coloured his approach and influenced his views on market definition so as to align with the views of Professor Hitt and Apple’s apparent theme on market definition across the litigation that it was involved with.

1479    There was a considerable overlap between his evidence and the prior US evidence of Professor Hitt and Professor Schmalensee as set out in the table in the aide memoire that Mr Young KC handed to me. Before he prepared his evidence, he was briefed inter-alia with the evidence of Professor Hitt and Professor Schmalensee in the US proceeding. But in fairness, he was also briefed with both Apple’s and Epic’s contentions in the US proceeding.

1480    In my view this all cast doubt on whether his views were completely independent and objective. Mr Houston’s reasoning must have been influenced by these materials, either consciously or subconsciously. I have not accepted Mr Houston’s protestations to the contrary during cross-examination. Whether or not Mr Houston or members of his staff consciously followed the evidence of Professor Hitt and Professor Schmalensee, in my view his reasoning was likely to be significantly influenced by those materials.

1481    I have no difficulty in saying that on the overlapping topics and where there has been a conflict I have preferred Professor Wright’s evidence over Mr Houston’s evidence on market and competition questions. But there were aspects of Mr Houston’s evidence concerning matters of general theory concerning two-sided platforms that I found to be useful and which I will address in a moment.

1482    Let me deal with one other topic. During cross-examination, Professor Hitt revealed that he had had an email exchange with Mr Houston during the conclave, which was not copied to Professor Wright or Professor Goldfarb. That email, when subsequently produced in response to a call, revealed that Professor Hitt and Mr Houston had a substantive exchange about Professor Hitt’s report, their contributions to the joint expert report, and the evidence of both Professor Wright and Professor Goldfarb, without the knowledge of Professor Wright or Professor Goldfarb. But having considered the matter carefully and heard Epic’s criticisms on the topic, in my view although the exchange was undesirable it did not substantially undermine their credibility. Having said that, it may be necessary for the Court to modify its applicable practice note so as to make it clear that such communications between only experts for one party during the running of a conclave are not desirable and ordinarily should not take place absent a compelling reason.

1483    I will say something later about Apple’s evidence led from Dr Adrian Majumdar and the class applicants’ evidence led from Mr Derek Holt on some economic questions concerning profitability and market power.

1484    Let me at this point say something about the economic literature and some of the general economic themes discussed by the experts before me in the Apple proceeding.

1485    I should also note here that the economic concepts including the HMT that I have discussed in my reasons in Epic v Google apply to my discussion in these reasons, although of course more quantitative analysis was involved in the evidence in that proceeding by virtue of Professor Asker’s detailed analysis.

Some economic literature relevant to markets

1486    A useful summary of some of the relevant economic principles is set out in M. Motta, Competition Policy: Theory and Practice (Cambridge, 1993) at 101 to 113 which I have drawn from.

Implementing the SSNIP test

1487    As I have indicated, the SSNIP test provides a useful approach to market definition, but it is necessary to discuss how to make it operational. And obviously, the reliance on a hypothetical monopoly situation entails that there exists no data that would allow for a literal application of the test. But let me discuss the tools that can be used to implement the test.

1488    Let me say something about own-price elasticity. One of the most useful pieces of information relevant to the definition of a product market is the own-price elasticity of demand, which is defined as the percentage change in the quantity demanded that follows a 1% increase in the price of a product. Suppose for instance that one is interested in the merger between two sellers of bananas, and you want to define the relevant market. Knowing that the own-price elasticity is, say, 0.2, one can infer that a 10% increase in the price of bananas will lead to a 2% decrease in the demand for bananas. Since only a very small number of consumers will turn to other fruits or stop buying altogether, the price rise is likely to be profitable. So, with this data it would be appropriate to define the relevant market as the market for bananas.

1489    But the simple statistical observation that over a certain period a 10% increase in banana prices has been associated with a 2% decrease in the number of bananas sold does not get you very far. A number of other variables will probably play a role in the demand for bananas, such as the prices and availability of other fruit, the general price level, disposable income and so on. Imagine for instance that in the period considered the price of bananas rose by 10% but the prices of oranges, apples, pineapples and kiwi fruits all rose by a different amount. Then the observation that demand for bananas has decreased by 2% is of no help, as many other variables affecting the demand for bananas have also changed.

1490    To take into account the different variables that are likely to have an impact on the demand for bananas, one needs to formulate and estimate an econometric model. And it is from such a model, and to the extent that it gives results that are statistically significant, that one should obtain estimates of elasticities that can be properly used for anti-trust analysis.

1491    Elasticity estimates should be obtained from representative data, and the time span one looks at matters. Consumers might take time to adjust their behaviour to a price change, and the demand reduction after a price rise is not likely to be immediate. Moreover, the appropriate time span will probably change from market to market.

1492    Let me say something about cross-price elasticities. If obtained from a properly specified econometric model, cross-price elasticities might also help to understand the competitive constraints exercised by other products on the product or group of products under examination for market definition purposes. The cross-price elasticity between products A and B is defined as the percentage change in the demand for product B when there is a 1% increase in the price of product A.

1493    When own-price elasticity for the product considered, say product A, is high enough to lead one to believe that a hypothetical monopolist would not profitably raise prices of product A in a small but significant way, it becomes important to identify which products exercise a constraint on A. Cross-price elasticities might help to rank the closest substitute, which together with product A will become the object of the next step of the HMT.

1494    When estimates of cross-price elasticities, say between bananas and any other fruit, are low, they indicate that such other fruit are not perceived by consumers as substitutes for bananas, and suggest a separate market for bananas.

After-markets or secondary markets

1495    One question that sometimes arises is how to define markets when there exist primary and secondary products, which are also called after-markets, such as cars (primary product) and spare parts (secondary product), or washing machines (primary product) and technical assistance (secondary product). Often, a certain type of secondary product is designed for and can fit only a certain brand of the primary product. So, a certain brand of cars may require special headlights that do not fit any other brand. If the car maker also produces headlights, defining the relevant product market as headlights for a particular brand of cars might result in a dominant position of the car maker in the secondary market, even if the car maker has a weak position in the primary market.

1496    Now the framework offered by the HMT can be useful in addressing this problem.

1497    The relevant question is whether a hypothetical monopolist, to continue the example, selling spare parts for a certain car brand would be able to profitably increase prices in a significant way. Note that if existing consumers have already bought that certain car brand they cannot turn to other spare parts; it is supposed that they are incompatible. But consumers who are considering whether to buy that particular brand of car might turn to other car makers instead, to the extent that they base their purchase decision on the overall estimated lifetime cost of the car, which includes the price of the car and the expected cost of replacing spare parts and getting after-sales services, and so on. If the spare parts at hand are sufficiently important for the overall expected cost of the product, and there are a sufficient number of buyers who will take it into account, the hypothetical monopolist will not find it useful to impose a SSNIP, and the market should be defined as the market for cars and spare parts together.

1498    In practice, the answer to the question of whether secondary products should be defined as a separate market will depend on the following variables. First, whether the price of the secondary product at issue is a considerable proportion or not of the price of the primary product. Ashtrays will more likely be put into a separate market than car engines. Second, one must consider not only the price of the spare part but also the probability of its replacement. Prices being equal, a spare part which is commonly known as very likely to break down will be less likely to be put into a separate market than a spare part whose failure probability is widely expected to be very low; the latter would not be considered by consumers when buying the car. Third, one needs to consider that some buyers are more sophisticated than others. When the buyers are final consumers, they might be less informed about the probability that spare parts or after-sales services are needed and they might be less aware of those secondary products’ prices. Conversely, when the primary product is an input which is bought by a firm, one would expect the buyer to be better informed about the expected cost, as to both the probability that they are needed and their costs, of secondary products. In the latter case, the market definition will, all else being equal, be wider than in the former.

1499    Now a notable case about after-markets or secondary markets is Eastman Kodac Co. v Image Technical Services Inc. 504 U.S. 451 (1992) which I do not need to dwell on for the moment.

The cellophane fallacy

1500    I have already touched on the cellophane fallacy, but let me say a little more. P. Davis and E. Garcés discuss the cellophane fallacy in Quantitative Techniques for Competition and Antitrust Analysis (Princeton, 2010) at 207 to 209. Let me draw on their discussion.

1501    In United States v E. I. DuPont de Nemours & Co 351 US 377 (1956) the issue that needed to be determined was whether cellophane was the appropriate product for market definition purposes. At that time DuPont sold 75% of all cellophane wrap but only 20% of all flexible packaging material, a potential alternative market definition.

1502    The Court accepted Dupont’s market definition as flexible packaging material and accordingly that DuPont had not attempted to monopolise that market. The reason given was that at the prevailing price levels, the Court found substantial evidence of demand substitution between cellophane and other packaging materials, such as greaseproof paper.

1503    This case has given rise to the term or label cellophane fallacy. It arises in the following way. If one was looking at evidence from a market which was already monopolised, then the price would already be raised to the point where a number of consumers would already have looked around for imperfect substitutes and indeed switched to them. Furthermore, the remaining customers may substitute away in large numbers if prices were further increased by small amounts since monopolists will always increase prices up to a level where their demand becomes elastic. As long as the demand elasticity is below 1, it is profitable to raise prices and a monopolist would already have done so.

1504    But this provides a difficulty when defining markets in the anti-trust context using evidence of observed levels of substitution.

1505    One will find lots of substitution at monopoly prices and so one will always find markets to be larger than one would if competitive prices were used as the benchmark, since prices will have been raised to the point where consumers are considering switching.

1506    What is the lesson from all of this? For the HMT one should evaluate the profitability of a price increase starting from competitive conditions, that is, starting with competitive prices and margins. But the difficulty is that one may not know what the competitive conditions are, and any assumptions about the competitive price level may problematically determine the answer for market definition. So, if one determines that actual prices are more than 5% above the unobserved and assumed competitive market prices, then one will conclude that the market definition is sufficient and the player is a monopolist. But such an approach would be circular. The assumption would determine the conclusion.

1507    Now whilst I am here I may as well say something about the reverse cellophane fallacy.

1508    Take the scenario when observed prices are below competitive prices. At prices below competitive prices consumers may think that the choice between two products is obvious and so little switching between products in response to small variations in relative prices may occur and be observed. If so, one may conclude that the markets should be narrowly drawn even if, in truth, pricing constraints are severe. The context of a possible predatory pricing scenario is where one must be careful of making the reverse cellophane fallacy.

1509    I should note that Davis and Garcés explained the following scenario. If consumers react to new information by making an explicit evaluation about whether to continue with a particular activity, that is, re-optimising, whereas in the absence of change they will continue with their present activity, then as with more traditional menu costs, it may be optimal for the firm to introduce price changes in large discrete amounts infrequently rather than small amounts frequently. The result may be that observed prices are below the competitive level so that firms will appear to have a clear incentive to increase them. The implication for market definition may be that markets are drawn too narrowly in such situations.

1510    Let me now turn to some economic evidence concerning two-sided platforms.

Economic principles governing the analysis of two-sided platforms

1511    Let me here set out some of the economic evidence and literature concerning two sided-platforms. I should say upfront that there was substantial agreement between the experts concerning the relevant concepts, albeit that there were differences in expression. Where any substantive difference arises and also matters, I will identify this.

1512    But I should make one important point upfront. It is important to make a distinction between a two-sided platform and a two-sided single market. One should not collapse that distinction. The reader will understand that distinction from the careful analysis of Breyer J (in dissent) in Ohio v American Express Co 585 US 529 (2018) at 552 et seq. In the case before me I have a two-sided platform(s), but that does entail any two-sided single market definition. And even if it was appropriate for the majority in Ohio v American Express to find a two-sided single market, I am dealing with the question of market definition in the context of the CCA. And in that sense, the analysis that I am required to carry out has a greater resonance with Breyer J’s approach, albeit in dissent.

Two-sided platforms — Mr Houston’s evidence

1513    Mr Houston for Apple gave evidence that network effects or network externalities exist where the value a user derives from a business or platform is affected by the behaviour of other users of the same business or platform. In the case of two-sided platforms, these effects may be either direct, where demand from a customer in group A depends on the demand from other customers in group A, or indirect, where demand from a customer in group A depends on the demand from customers in some other group, B.

1514    Now there is a more comprehensive definition of two-sidedness that identifies three conditions for platforms to emerge. Those conditions are that there must be, first, two or more distinct groups of customers, second, network effects associated with customers on opposite sides interacting, and third, a need for an intermediary to internalise those network effects.

1515    There is also an alternative definition of two-sidedness, which is to the effect that a platform is two-sided if the platform can affect the volume of transactions by charging more to one side of the market and reducing the price paid by the other side by an equal amount.

1516    It has also been suggested that a platform is two-sided if the price structure it sets is non-neutral, that is, if the decomposition of prices between the two sides can affect the degree to which the two groups of customers transact. For this to be true, customers on opposite sides of the platform must not be able to defeat a change to the price structure by privately contracting with one another and negotiating a degree of pass-through. If this were possible, an intermediary would not be required to internalise the network effects between the two sides.

1517    There are two distinct forms of network effects concerning two-sided platforms.

1518    First, there are membership effects, whereby one group of users derives greater value from a platform when there are more users in the other group, and vice versa, holding all else equal.

1519    Second, there are usage effects, whereby one group of users derives greater value from a platform when users from the other group use the platform more, and vice versa, holding all else equal.

1520    In summary, the relevant economic characteristics and features of two-sided platforms, which distinguish them from typical, one-sided firms, are that, first, they attract two distinct groups of users, second, they internalise the indirect network effects linking the two groups of users, of which there are two forms, and third, the volume of interactions between the two groups of users can be affected by adjusting the price structure, that is, by adjusting the individual prices charged to each side rather than just their sum.

1521    An important consequence of indirect network effects is that substitution away from a platform, in response to an adverse change in terms, by one group of users will most likely affect the propensity for substitution by the other group of users. The adverse change in terms for one group of users is likely to cause a feedback loop.

1522    So, an increase in the price charged to users in group A may result in a reduction in quantity demanded from a platform by that group. The indirect network effects then imply that users of group B derive less benefit from interacting with the platform because there are fewer users of group A using the platform, and so the group B users reduce their demand for the platform. And what then follows is that the indirect network effects then imply that users of group A derive even less benefit from the platform because there are fewer users of group B using the platform, and so the group A users reduce their demand further, and so on.

1523    Further, these feedback loops can increase the responsiveness of demand to changes in price even if, say, customers on side A are not very sensitive to price.

1524    Accordingly, the pricing decisions of a two-sided platform typically depend on two matters.

1525    First, the price elasticity of demand for the product or service offered, as it applies in relation to each side, and the relative price elasticity of each side compared to the other side.

1526    Second, the sizes of the network effects conveyed by each side in relation to the other.

1527    It is common for a two-sided platform to set a low, zero or sometimes negative price to users on one side and a positive price to users on the other. For example, shopping centres are two-sided platforms which seek to attract and facilitate interactions between consumers and tenants, that is, providers of goods and services. Shopping centres tend not to charge consumers to enter a shopping centre or to transact with tenants but, rather, derive the majority of their income from charges applying to tenants. If, for example, group A exerts large positive network effects on group B, it may be profit maximising for the platform to grant free access to group A and earn all revenue from group B. This strategy would encourage many group A users to join the platform, which would in turn entice many users from group B by means of the positive indirect network effects being exerted.

1528    In contrast, it is much less common for products or services provided in other contexts to involve a zero price. A firm may charge a zero price for products that are strongly complementary, such as premium upgrade strategies and free software.

1529    In addition to pricing decisions, platforms may establish conditions of use that govern the conduct of platform users to ensure that users on one side do not reduce the value of the platform for the other side. Such conditions might reasonably be expected from a platform facing effective competition seeking to maximise the number of interactions it facilitates. A platform may undertake an efficient business response in which it has established efficient rules for reducing negative externalities. Such a platform might exclude a user of the platform who violates the rules of the platform.

1530    For a two-sided platform it is necessary to account for two matters.

1531    First, the fact that substitution can take place on both sides of the platform.

1532    Second, that there are feedback loops caused by indirect network effects, whereby substitution away from the platform by one group of users can lead to substitution by the other group, and vice versa, which may lead to a low, zero or negative price for users on one side and/or may lead to conditions of use governing the conduct of users on either or both sides.

1533    The presence of indirect network effects means the marginal cost of serving each side is not necessarily the appropriate frame of reference for competitive prices charged on either side of a two-sided platform. Indeed the price on one side could be well above marginal cost, while the price on the other side could be below marginal cost.

1534    Two-sided platforms have been categorised in the literature as either two-sided transaction platforms or two-sided non-transaction platforms, where the former are identifiable by the presence of an observable transaction between users on each side of the platform, facilitated by the platform. An equivalent definition is that a two-sided platform is a transaction platform if it is possible to charge users on a per-transaction basis, rather than just for membership of the platform.

1535    Whilst membership effects are a feature of all two-sided platforms, usage effects linking the two groups of customers are a feature of two-sided transaction platforms.

1536    Usage effects are present when members of one group of users derive greater value from a platform when the other group uses the platform more. Accordingly, all else equal, the network effects linking the customer groups of a two-sided transaction platform are stronger than those linking customers of a two-sided non-transaction platform.

1537    When conducting an assessment of competition which may include considering a two-sided transaction platform, one relevant product to consider is the transaction facilitated by the platform.

1538    Further, for a transaction between users on opposite sides of a two-sided platform to occur in fixed proportions, the ratio of users on each side involved in a transaction must be constant. For example, a transaction between an app user and a developer always involves exactly one user and developer, that is, the ratio is one.

1539    Let me deal with some further aspects raised by Mr Houston concerning the SSNIP test. But let me be clear that what he discussed was his views concerning the SSNIP test in its application to a two-sided transaction market, being a single market. Now I have rejected that foundation. But some of his points are not completely beyond redemption and so I will record them here. He said the following.

1540    A typical SSNIP test, which is applied to assist in the definition of a one-sided market, hypothesises a 5 or 10% price rise and asks the question as to whether substitution by consumers, or entry by alternative suppliers, would be so great as to cause the price rise to be unprofitable.

1541    In applying this to a two-sided transaction market, a modified SSNIP test should generally account for the following.

1542    First, it should consider all relevant prices charged in the candidate market supplied by the hypothetical monopolist, that is, prices charged on both sides of the platform.

1543    Second, it should allow the hypothetical monopolist to adjust the relative price structure, that is, the ratio of the prices paid by the two groups of users, in the optimal manner.

1544    Third, it should account directly for the presence of indirect network effects.

1545    So, it must incorporate within-platform, cross-side effects, that is, the value derived by customers on one side of a platform from the number and usage of customers on the other side of the same platform.

1546    And it must incorporate cross-platform, cross-side effects, that is, the value derived by customers on one side of a platform from the number and usage of customers on the other side of a rival platform.

1547    A single-sided analysis that does not consider these effects is likely to give rise to unreliable conclusions. Such an analysis will tend to overstate the profitability of a potential price rise, because it does not take into account an important potential effect of a reduction in demand on one side, being the likelihood of reduced demand on the other side and so on. By consequence, a single-sided analysis entails a significant risk that a market is defined too narrowly. A hypothetical monopolist does not face close competitive constraints if a SSNIP is profitable, and so additional products/services may not be added to a candidate market for which a SSNIP is profitable. It follows that overstating the profitability of a SSNIP may cause a market to be defined too narrowly.

1548    In addition, the typical SSNIP test, that is, one in which a small price rise typically of 5 or 10% is hypothesised, becomes inoperable when the existing price is zero, as is commonly the case on one side of a two-sided platform. 5% of zero is still zero.

1549    Pricing decisions by two-sided platforms typically depend on the price elasticities of demand and the sizes of the network effects on each side of the platform. This contrasts with pricing decisions in traditional markets, which tend to relate more closely to the marginal cost of production.

1550    Consequently, prices on either side of a platform may be above or below marginal cost, independently of the potential presence or absence of substantial market power.

1551    Examining the prices set by a two-sided platform without appropriately accounting for two-sidedness risks the erroneous conclusion that a firm is exercising substantial market power, when in reality it is effectively constrained by rivals. Further, it can lead to the erroneous conclusion that competition in a market is operating effectively, when in reality a firm is exercising substantial market power.

1552    The standard SSNIP test framework must be modified to offer reliable results in a two-sided context. Similarly, the assessment of competition and competitive constraints must be adapted to address the presence of indirect network effects for essentially the same reasons, that is, a change in the number of users or their demand on one side of a platform can affect demand on the other side.

Multi-sided platforms — Professor Wright’s evidence

1553    Professor Wright for Epic explained the following matters.

1554    Multi-sided platforms are intermediaries which enable interactions between different groups of affiliated users. The platforms provide products and services that bring together groups of users in two-sided networks. By affiliation, what is meant is that users make a deliberate choice to join or participate on the particular platform. For example, online marketplaces like eBay enable sellers to have their products discovered by potential buyers, and if these buyers have created an account with the marketplace, to purchase from sellers.

1555    Multi-sided platforms often exhibit network effects.

1556    Network effects arise when the value of a product increases as more people use the product. For example, the value of eBay to potential buyers is likely to increase as the number of sellers offering products on eBay increases. The value of eBay to sellers is also likely to increase as it attracts more potential buyers.

1557    For such markets, economists describe the two sides as being linked together by cross-side network effects, which is often called indirect network effects. This implies that the demand from one group of users can affect the demand from the other group. For example, compared to a rival marketplace, sellers may prefer to list on eBay if eBay has a larger number of signed up buyers that use it and buyers may prefer to sign-up to and use eBay if it has a larger number of sellers listing products.

1558    For such platforms, there is a need to consider whether to define a relevant market for the products offered by the platform(s) as a whole, that is, encompassing user groups on each side together, or to define separate markets for the products offered by the platform(s) to each side.

1559    There is no consensus among economists on the right approach. Some economists adopt a single market approach in some situations. Others always use the two separate markets approach.

1560    Now just to flag the point here, in my view the correct approach involves the rejection of a single two-sided transaction market approach, and I have addressed this in detail later and separately in discussing the relevant focal product for the purposes of market definition under the requirements of the CCA in the light of the impugned conduct under consideration and the question of substitutability.

1561    Now regardless of whether one adopts a single market approach or a multi-market approach, when the demand from both sides of a two-sided platform is linked by cross-side network effects, interactions between the two sides should be taken into account in assessing potential competitive constraints as part of market definition and the assessment of market power.

1562    And as is the case with all multi-sided platforms, an assessment of market power on one side also involves a consideration of any competitive constraints provided by the operation of the other side of the platform.

1563    So, if prices charged on one side have an impact on the other side’s demand, that should be taken into account in the HMT.

1564    Professor Wright considered that a key determinant of whether it matters if a single-market or multi-market approach is used is whether substitution possibilities are very different on each side.

1565    Where substitution possibilities differ significantly between sides, a multi-market approach provides the flexibility to allow for the scope of the market to vary depending on whether the perspective of customers on one side or the other is being considered.

1566    Further, differences in substitution possibilities on the different sides of the platform may warrant a multi-market approach.

1567    Whether substitution possibilities are actually significantly different between the different sides of a platform can depend on a range of factors including the degree of product differentiation on each side, or each user group’s perception of product differences, and behavioural factors such as the homing decisions on each side. This refers to the decision by users to adopt only one platform for a given product or adopt multiple platforms for the same product (multi-homing).

1568    For example, sellers can sign up to and list their products only on eBay, or they can also simultaneously sign up to and list them on other marketplaces in Australia, such as Amazon, Etsy, Facebook Marketplace and Gumtree.

1569    Likewise, consumers can consider signing up and purchasing only on eBay, or they can create accounts with multiple marketplaces so that they can consider making a purchase from whichever one(s) they prefer.

Two-sided platforms — Professor Hitt’s evidence

1570    Professor Hitt for Apple focused on platforms with two sides, for example, developers and consumers, or two-sided platforms, although the same insights generally extend to platforms with more than two sides. He further focused on a specific type of two-sided platform, being a two-sided transaction platform.

1571    Professor Hitt aligned a two-sided transaction platform with a single two-sided transaction market. I have rejected that latter concept, but for the moment it is convenient to set out here his evidence, particularly as it concerns two-sided platforms. He said the following.

1572    A two-sided transaction platform generates value by facilitating transactions, being a simultaneous and observable exchange, usually involving payment, between two customer groups. Not all two-sided platforms facilitate transactions. So, newspapers are two-sided platforms that bring together advertisers and readers who view the ads. But the interaction between the two sides does not typically lead to a transaction through the platform.

1573    Economists generally recognise transaction platforms as having particularly strong bilateral indirect network effects.

1574    Platforms generally, and transaction platforms specifically, have distinct economic characteristics that distinguish them from other types of economic arrangements.

1575    First, two-sided platforms bring two different sets of customers together and facilitate interactions between them through the platform. To be successful, a firm operating a two-sided platform needs to attract users from both customer groups through a strategy that involves choosing a set of services to offer, policies and rules governing the behaviour of participants, and pricing. Making these decisions, that is, platform governance, is important in enabling platforms to create value.

1576    In D Evans, “Governing Bad Behavior by Users of Multi-Sided Platforms,” (2012) 27(2) Berkeley Technology Law Journal 1201, it is said (at 1203 and 1204):

Multi-sided platforms create value by helping two or more different types of users, who could benefit from getting together, find and interact with each other, and exchange value. They include software platforms (e.g., Apple’s iOS), financial exchanges (e.g., NASDAQ), search engines (e.g., Microsoft’s Bing), social networks (e.g., LinkedIn), shopping malls (e.g., Water Tower Place in Chicago), advertising-supported media (e.g., CNN), and e-commerce sites that connect business and shoppers (e.g., Amazon). Multi-sided platforms solve a transaction problem that prevents these different types of users from getting together on their own to exchange value. There are positive externalities between the multiple types of users. Platforms provide ways to promote these positive externalities and thereby create value for the community of users they serve.

Whenever people and businesses get together, and in any community, there are many opportunities for people and businesses to behave badly and to thereby generate negative externalities. This bad behavior can reduce economic efficiency and in the extreme lead to the tragedy of the commons. Multi-sided platforms such as eBay develop governance systems to reduce this bad behavior and minimize negative externalities …. Multi-sided platforms develop systems of rules and penalties to manage many of the same kinds of problems that communities subject to public laws and regulations face. These platforms enforce such rules by exercising their property rights to exclude users from the platform. In some cases, the rules and penalties imposed by the platform are similar to, and in some cases close substitutes for, rules and penalties adopted by a public regulator.

Private control is likely to be more efficient than social control in dealing with negative externalities in platform communities. The platform owner can monitor bad behavior more closely and deal with this behavior more quickly than can a public regulator. Multi-sided platforms face antitrust complaints concerning reductions in service or denial of service by the platform. …

1577    Second, two-sided platforms are characterised by indirect network effects.

1578    In B Jullien et al, “Two-sided markets, pricing, and network effects,” in K Ho et al (eds), Handbook of Industrial Organization, (2021, vol 4) it is said (at 490 and 491):

We generally consider a two-sided market to be one in which at least two distinct sets of agents (or sides) interact through an intermediary—the platform—and in which the behavior of each set of agents directly impacts the utility, or the profit, of the other set of agents. The impact of one set of agents on the other, and the resulting feedback to the first set of agents, is an indirect network effect.

1579    Indirect network effects exist when the value of using the platform to customers on one side of the platform is higher when there are more customers on the other side of the platform.

1580    A network effect is indirect when the value to one group of customers depends on how many members of a different group participate.

1581    In C Tucker, “Network Effects and Market Power: What Have We Learned in the Last Decade?” (2018) Antitrust 72, it is said (at 72):

Economists use ‘network effects’ to describe contexts in which a good or service offers increasing benefits the more users it has. Network effects can be direct—for example, a fax machine becomes more useful as other people also use fax machines. Network effects can also be indirect so that they flow across different sets of users. For example, Uber would not be a very useful app for a rider if there were no drivers using the platform. Similarly, drivers would not want to use the Uber app if no riders were using it.

1582    Due to indirect network effects, it is critical for a two-sided platform to attract and retain customers on both sides of the platform. Failing to do so can lead to a negative feedback loop: a loss of customers on one side of the platform makes the platform less attractive to customers on the other side of the platform, which may depress their participation and in turn lead to more exit from customers on the first side of the platform, and so on. This type of feedback loop may amplify the impact of a change in a platform’s services, prices, or policies.

1583    In D Evans and R Schmalensee, “Failure to Launch: Critical Mass in Platform Businesses,” (2010) 9(4) Review of Network Economics 1, it is said (at 4 and 22):

If the business finds itself with less than this critical mass of participants, however, network effects will drive a downward spiral toward a stable equilibrium with zero participation.

…

In the case of indirect network effects, which is our primary focus, participation by each customer group affects the quality of the product experienced by the other group, and, though the dynamics are more complicated, participation levels below critical mass will set off a similar downward spiral.

1584    These dynamics often require two-sided platforms to adopt more sophisticated and complex strategies for running the platform compared to those of other firms.

1585    Specifically, two-sided platforms must balance the need to attract customers from both sides and establish a profitable platform. So, a firm may choose to establish rules that limit certain behaviours of customers on one side of the platform to the benefit of the customers on the other side of the platform. But if this rule attracts customers to the latter side, it can ultimately increase the value of participating on the platform for customers on the former side through indirect network effects.

1586    A two-sided platform will also need to consider its pricing structure, as it has many options for how to structure payments for different sides of the platform. The firm may choose to set different prices or a different price structure, for example, a fixed fee for access or a commission as a percentage of transactions, on each side of the platform.

1587    In D Evans and R Schmalensee, “The Industrial Organization of Markets with Two-Sided Platforms,” (2007) 3(1) Competition Policy International 151, it is said (at 160 and 161):

For many platforms it is possible to charge two different kinds of prices: an access fee for joining the platform and a usage fee for using the platform. . . . The profit-maximizing reliance on access versus usage fees depends on many factors including the difficulty of monitoring usage and the nature of the externality between the two sides. …

1588    In many instances, a platform may choose to set a zero price, or even a negative price in the form of rebates or rewards, to one side of the platform to increase demand by customers on the zero-price side of the platform as this will in turn increase demand by the customers on the other side of the platform when indirect network effects are strong.

1589    Further, an overall pricing strategy may not be set to maximise profits from either side in isolation and instead take into consideration both the direct and indirect effects of the strategy. So, discounting an unbundled component can increase profits to the point where negative prices become optimal.

1590    Now Professor Hitt described the App Store in the following terms.

1591    The App Store is a two-sided transaction platform that allows consumers and app developers to transact with each other on iOS devices. The App Store must attract both consumers, on the one side, and app developers, on the other, in order to establish a successful transaction platform. Furthermore, the App Store is subject to bilateral indirect network effects. Consumers value the platform more when there are more app developers on the other side, and vice versa.

1592    As such, the App Store provides a variety of services and features to attract both app developers and consumers. Apple chooses to offer many services and features for free and only charges directly for a small subset of services and features, or bundles of services and features.

1593    In particular, Apple charges app developers a commission for paid downloads and digital in-app purchases, including in-app subscription purchases, which is a percentage of the price paid by users, as well as an annual developer fee to transact through the App Store. Apple does not charge consumers directly for using the App Store. Only developers pay commission, and only on paid downloads and in-app purchases.

1594    Generally speaking this was an accurate description in my view.

1595    Let me at this point say something about an economic article that Professor Hitt drew my attention to.

Two-sided transaction markets — Filistrucchi

1596    In L Filistrucchi et al, “Market Definition in Two-Sided Markets: Theory and Practice,” (2014) 10(2) Journal of Competition Law & Economics 293, it is said (at 300):

However, one of the first and most important contributions of the theory of two-sided markets is that giving away a product for free may be a profit maximizing strategy for a firm, even for a monopolist. The reason is that by giving away a product for free, a platform boosts the number of people receiving that product. Although it loses money on one side, it may recover this loss on the other side, making higher profits overall than if it were to sell on both sides at a positive price.

1597    Further, and as Mr Houston also flagged, issues arise when attempting to extend the SSNIP test to a two-sided market. The authors expressed the following views.

1598    First, given that in a two-sided market firms set two prices, one on each side of the market, the question is which price the hypothetical monopolist should be raising.

1599    Second, given that in a two-sided market there are indirect network effects between demands and therefore profits on the two sides, the issue is whether one should consider profits on one or both sides of the market.

1600    Some economists have warned against the application of a one-sided SSNIP test in defining markets when two-sided platforms are involved.

1601    The first reason is that, in a two-sided market, the traditional SSNIP test cannot be applied as it is usually conceived. Market definition should account for both sides of the market in order to correctly assess the competitive constraints faced by firms. The logic of the SSNIP test should thus be extended, and therefore also the formulae for critical loss analysis, in order to account for the indirect network effects between the two sides of the market when judging the profitability of a price increase.

1602    Considering a two-sided platform with sides A and B linked by positive indirect network effects, the application of a one-sided SSNIP test on side A would only account for the direct effect that a price increase will have on the demand and profits of side A. It will not account for the fact that a reduction of the number of customers on side A is likely to lead to a reduction of the number of customers on side B such that, if the price on side B is kept constant, there would be a loss in profits also on side B. It would also not envisage the fact that the smaller number of customers on side B will in turn reduce the demand of side A, and so on. Hence, it would also underestimate the loss in profits on side A.

1603    Positive indirect network effects between the different sides of the platform reduce the profitability of any price increase. As there is always at least one positive indirect network effect, the risk of applying a standard SSNIP test, which does not account for feedback effects, is that in such cases the market will be defined too narrowly.

1604    The second reason why the test should be modified is that, if one wants to use a SSNIP test or critical loss analysis in a two-sided market, one should follow the original rationale of the test, that is, defining the market as the smallest set of products on which a monopolist would find it profitable to exercise market power by non-temporarily raising the price above the current competitive level by a small but significant percentage at least.

1605    In order to ensure that the test is based on the same rationale, the SSNIP test in a two-sided market should take into account the changes in profits on both sides of the market and all feedback between demands on the two sides of the market following the hypothetical monopolist’s price increase.

1606    In a market characterised by a transaction between end users, for example, in the payment card market, the SSNIP test should be implemented by raising the price level, that is, the price of the transaction, allowing the monopolist to optimally adjust the price structure, that is, the ratio between the prices paid for a given transaction by the two sides.

1607    In a market without a transaction among end users, for example, in a media market, the test should instead be implemented by raising first the price on one side of the market, and then the price on the other side of the market, each time allowing the hypothetical monopolist to optimally adjust the price structure. Only if the market were found to be characterised by a single externality could the traditional SSNIP test and single-sided formulae for critical loss analysis could be applied to define the market on the side that does not exert an externality on the other.

1608    Now whilst there is consensus in the literature that one should take into account changes in profits on both sides of the market and all feedback between demands on the two sides, it is debated whether the hypothetical monopolist should be allowed to optimally adjust the price structure.

1609    In particular, some economists have suggested new formulae to perform critical loss analysis in a two-sided market when one wants to define two interrelated markets. These formulae are derived under the assumption of linear demands and constant marginal costs, as is usually the case in single-sided markets, but also under the additional assumption that the hypothetical monopolist raises the price on one side while keeping the price on the other side fixed.

1610    Contrastingly, other economists have claimed that the hypothetical monopolist should be allowed to optimally adjust the price structure, that is, roughly, the ratio of the two prices, when it is asked to raise the price on either side or the price of the transaction. They point out that a real monopolist would adjust the price structure when asked to raise the price, so that if one wants to know whether a hypothetical monopolist in the market would find it profitable or optimal to raise price on one side by a given amount, then one should allow it to optimally adjust the price structure.

1611    Dr Filistrucchi has proposed some critical loss analysis formulae to perform the SSNIP test in a two-sided non-transaction market under the usual assumptions of linear or isoelastic demand and constant marginal costs. He has then argued that, while using the standard single-sided critical loss analysis formulae would lead to the definition of a relevant market that is too narrow, adopting the formulae proposed by others would lead to the definition of a market which is too large.

1612    Indeed, not allowing the price structure to be adjusted optimally would overestimate the loss in profits due to the increase in prices, because by definition the optimal adjustment by the hypothetical monopolist will tend to reduce such a loss.

1613    Now all of this is very well, but as I say I have rejected a single two-sided transaction market.

1614    Let me at this point say something about the economic literature concerning tying.

Two-sided platforms — tying

1615    Let me start off with some general themes.

1616    In a chapter, Assessing the Competitive Effects of Bundling (Economics of Antitrust: New Issues, Questions and Insights (2004) edited by Dr L. Wu, NERA) at 109, Mr Houston and Ms Carol Osborne wrote the following concerning bundling and tying which I generally accept.

1617    The first strategy is product bundling, which occurs when distinct products are sold as a package, say the products are technologically integrated such as computer hardware with software.

1618    The second strategy is tying, which differs from bundling in that the products are generally sold separately allowing the consumer to choose the relative quantities in which the products are sold, but one product is only made available or priced at a discount on the condition that the other is purchased as well.

1619    In most cases, bundling and tying are beneficial for consumers in that they lead to lower prices. Sellers value these strategies because they may increase the firm’s sales, reduce its cost of providing maintenance and service, or assure product performance and quality. But some firms may attempt to engage in bundling or tying to reduce or eliminate competition. In such circumstances, the near-term benefits of lower prices or improved product performance or quality for consumers may come at the expense of higher prices and reduced choices later on.

1620    More often than not, bundling arrangements form part of a sensible competitive strategy. These may arise from either the demand or supply side characteristics of bundled products. So, bundling may reflect synergies or cost savings that are achieved when the bundled products are produced jointly as part of the same manufacturing process.

1621    Similarly, consumers will benefit if bundling can reduce the cost of delivery or the transactions costs from having to deal with multiple vendors. The installation of cable connections for Internet and pay-TV services together, for example, is considerably more cost-effective than installing them separately.

1622    But not all bundling arrangements are innocent of anti-competitive intent or effect. Some bundles are designed or priced in an attempt to gain, retain, or abuse market power. So, bundling may facilitate predation or below-cost pricing that is intended to remove a rival in the long term. Bundling may also enable a firm to leverage its power from one market to another through price and non-price means.

1623    They also commented on leveraging market power through tie-ins in the following terms.

1624    A firm with monopoly power in the provision of a particular product may attempt to leverage this into a second market by tying the purchase of the first product (the tying product) to the purchase of a second product (the tied product).

1625    That the objective of such leveraging may be to increase the price of the tied product above competitive levels has largely been refuted on the basis that it “double counts” monopoly profits.

1626    If a multiproduct firm faces competition in the market for the tied product, consumers will impute the value of the tying product. Under these circumstances, the firm can be no better off than if it had supplied the products both individually and in bundled form.

1627    An alternative anti-competitive leveraging strategy depends on the bundling firm’s ability to reduce rivals’ sales in the tied market to the point where they become unprofitable and are forced to exit. This is more likely to be feasible in industries characterized by substantial fixed costs, in which firms require some minimum level of sales to remain profitable at the competitive price.

1628    Firms may use bundling or tie-in arrangements to leverage power from one market to another without necessarily affecting the prices paid by consumers. So, if a firm has a monopoly in one product, it may be able to compel consumers to purchase from it other products that they may otherwise have purchased from rival companies or not have purchased at all.

1629    Despite the potential for bundling and tying arrangements to be used in this way, such non-price strategies often form part of a competitive strategy by firms, including those that may have monopoly power, to increase sales, improve efficiency or ensure product quality.

1630    Because efficiencies of this kind can increase market share, it is not at all clear that consumers have been harmed, even if there is a reduction in the number of competitors in the marketplace.

1631    In D Evans and R Schmalensee, “Markets With Two-Sided Platforms” in Issues in Competition Law and Policy (2008, American Bar Association) ch 28 it was explained by Dr Evans and Professor Schmalensee that under a rule of reason analysis the economics of two-sided platforms can provide an explanation for certain tying practices that seem to reduce consumer choice and harm consumers.

1632    So, a platform provider may design the platform including the various services and features to harness internalised externalities, minimise transactions costs between the customers and both sides, and maximise the overall value of the platform.

1633    As part of harnessing externalities, the platform provider may want to increase positive indirect network effects whilst limiting negative indirect network effects. As a consequence, the two-sided platform may impose requirements on side A that do not benefit them directly and which customers on that side might even reject after comparing private benefits and costs.

1634    But such requirements may benefit side B. And if the demand increases on side B, these requirements may increase the value placed on the platform on side A, and in fact could increase value so much that the feature provides a net benefit to side A.

1635    Further, the potential for profits on the other side provides a possible incentive for exclusive contracts in two-sided platforms.

1636    Further, for two-sided platform businesses, it is at least possible that there is an externality. Exclusive contracts on one side might help a platform gain market power on other sides. The consumers agreeing to the exclusive contracts on one side might, at least in the short run, gain from or be indifferent to exclusivity, but they may not take into account the costs to consumers on the other sides from decreased platform competition.

1637    It is possible for a two-sided platform to use exclusive contracts to exclude competitors. But as with exclusivity in one-sided markets, this can only be a concern if one firm has exclusivity over most or all of the market and if the exclusivity is persistent and durable. For example, consumers on the non-exclusive side could respond by moving to a competing platform, so exerting pressure on consumers on the exclusive side to end exclusivity.

1638    Moreover, in markets with significant buyer concentration, the buyers would be reluctant to agree to exclusivity if there is some expectation that it will lead to dominance by that platform, as that will likely result in higher prices in the future for all sides.

1639    As with one-sided markets, one needs to consider whether the efficiencies from exclusive contracts, for example, in helping to create a platform that might not otherwise exist for the benefit of consumers, offset possible costs from reducing competition.

1640    In M Whinston, “Tying, Foreclosure, and Exclusion” (1990) 80(4) The American Economic Review 837, Professor Whinston also explained the following matters.

1641    A firm engages in tying when it makes the sale or price of one of its products conditional upon the purchaser also buying some other product from it.

1642    A primary basis for condemning this practice relies upon the leverage theory of tying, that is, tying provides a mechanism whereby a firm with monopoly power in one market can use the leverage provided by this power to foreclose sales in and thereby monopolise a second market.

1643    Now in recent years the leverage theory has come under attack. The standard criticism seems to proceed along the following lines.

1644    Suppose that a firm is a monopolist of some good A that a consumer values at level VA and that costs CA to produce. Say the consumer also consumes some other competitively supplied product B that he values at level VB and that can be produced at a unit cost of CB. Now, the monopolist could require the consumer to purchase good B from it if he wants good A, but what will the monopolist gain? The consumer will only purchase such a bundle if the price of the bundle is no larger than VA + CB, and so the monopolist can do no better than earning (VA – CA), the level it earns selling good A independently. So, there is only one monopoly profit that can be extracted.

1645    Resonating with these themes are the observations in R Posner, Antitrust Law: An Economic Perspective (1976, University of Chicago Press) where it was said:

[A fatal] weakness of the leverage theory is its inability to explain why a firm with a monopoly of one product would want to monopolize complementary products as well. It may seem obvious ... but since the products are by hypothesis used in conjunction with one another ... it is not obvious at all. If the price of the tied product is higher than the purchaser would have to pay on the open market, the difference will represent an increase in the price of the final product or service to him, and he will demand less of it, and will therefore buy less of the tying product. …

1646    But tying may be an effective and profitable means for a monopolist to affect the market structure of the tied good market, that is, monopolise it, by making continued operation unprofitable for tied good rivals.

1647    Now the literature assumes that the tied good market has a competitive, constant returns-to-scale structure. But with this assumption, the use of leverage to affect the market structure of the tied good market is impossible.

1648    So, in contrast to a concern over the effects of tying on market structure, the focus in the literature is on a demand-side notion of leverage, which is the idea that taking the prices charged by tied good competitors as given, a firm might be able to extract greater profits from consumers by tying.

1649    But in Professor Whinston’s models he addressed three questions. First, can tying succeed in altering the market structure of the tied good market, and if so, how? Second, is it a profitable strategy? Third, what are the welfare consequences? Let me say something about the first and second questions.

1650    As he concluded, tying can lead to a monopolisation of the tied good market. The mechanism through which this exclusion occurs is foreclosure. By tying, the monopolist reduces the sales of its tied good market competitor, thereby lowering his profits below the level that would justify continued operation.

1651    Tying is frequently a profitable strategy for the monopolist in these models, and it is often so because of its potential for altering the market structure of the tied good market. But the particular circumstances in which tying is a desirable strategy for the monopolist depend in part on whether he is able to make a pre-commitment to tie.

1652    In many circumstances this is indeed possible. One of the primary ways in which this can be accomplished is through product design and the setting of production processes, both of which may involve significant sunk costs. By bundling components of its system together or by making interfaces between the separately sold components incompatible with their rivals' components, firms can pre-commit to their marketing strategy.

1653    So, tying can be profitably used as an exclusionary device.

1654    Professor Whinston also considered the case of complementary products used in fixed proportions.

1655    He first considered a model of fixed proportions where the tied good market involves differentiated products with scale economies in production and an oligopolistic, rather than a competitive, market structure.

1656    In such a case, a monopolist of one component never finds it worthwhile to tie in order to reduce the level of competition in the market for the other component.

1657    The key point is that with complementary products used in fixed proportions, the monopolist can actually derive greater profits when its rival is in the market than when it is not because it can benefit through sales of its monopolised product from the additional surplus that its rival's presence generates due to product differentiation.

1658    Professor Whinston’s analysis demonstrates that once one allows for scale economies and strategic interaction, tying can make continued operation by a monopolist's tied market rival unprofitable by leading to the foreclosure of tied good sales. Such a strategy can be a profitable one for a monopolist, often precisely because of this exclusionary effect on market structure.

1659    Let me note one other matter here. Apple says that Professor Wright only sought to disavow the application of the principles discussed by Professor Whinston on the basis that IAP is a separate product by reason of there being separate demand. But Professor Wright discussed the principle in the article and explained why he did not think it was applicable to the present circumstances, namely because in-app purchases and app downloads are not consumed in fixed proportions.

Market definition – the parties’ cases

1660    Let me begin with some introductory remarks on the parties’ positions.

Epic’s case on the relevant market – summary

1661    Let me begin by setting out a summary of Epic’s case on market definition. It is convenient for the moment to address Apple Inc and Apple Pty Ltd together.

1662    Epic says that Apple contravened s 46(1) by engaging in conduct that had the likely effect or purpose of substantially lessening competition in the iOS app distribution market. I will say something about the iOS in-app payment solutions market later.

1663    Epic says that Apple supplies a range of services for the distribution of iOS apps from developers to iOS device users, including curation, display, search, downloading and updates. It says that the iOS restrictive terms and the iOS app distribution conduct concern those services and that Apple’s conduct prevented iOS developers and iOS device users from using any alternative distribution channel for iOS apps, and required the use of IAP for all in-app purchases of digital content.

1664    Epic says that the appropriate lens through which to assess whether Apple has substantial market power in relation to the distribution of iOS apps, and the purposes and likely competitive effects of Apple’s conduct, is the market for the supply of services to developers and iOS device users for the distribution of iOS apps to iOS device users. And it says that Apple is presently the monopoly supplier in the market and faces no material competitive constraints.

1665    Epic says that app distribution is the process involved in getting apps from developers to users’ devices. And it necessarily includes the process by which users discover, retrieve and install apps.

1666    It says that a developer of an iOS app that wishes to have it accessed by iOS device users must have a means by which to make it available to them. Similarly, it says that iOS device users who wish to access iOS apps must have a means of doing so. The App Store is the mechanism that Apple offers, and the sole mechanism Apple permits, to facilitate both outcomes.

1667    Epic says that the primary role of the App Store is the distribution of apps to iOS device users. An important function of the App Store is to deliver apps to iOS devices. Apple uses a centralised distribution model to distribute native apps through the App Store. This is the procurement element of app distribution encompassing app discovery, app retrieval and app installation.

1668    Epic says that Apple’s role extends beyond the mere delivery of iOS apps. Apple is also responsible for marketing iOS apps, and soliciting and obtaining orders for iOS apps. Further, Apple, through the App Store, helps users discover new apps every day. Through the App store, Apple provides services for the discovery and distribution of apps.

1669    Epic says that the iOS app distribution conduct and the iOS restrictive terms prevent the distribution of iOS apps to iOS device users other than through the App Store and require Apple to be appointed as the developers’ agent for the marketing and downloading of apps on the App Store. So, there is the preclusion of any other app store on iOS.

1670    Epic has relied upon Professor Wright’s approach which commenced the market definition exercise by recognising the nature of the conduct that is under examination and treating services for the distribution of iOS apps as the focal product. Contrastingly, Professor Hitt and Mr Houston asserted that the relevant product is app transactions.

1671    Now Epic says that there is imprecision in the use of that term by Professor Hitt and Mr Houston. Apple does not supply “app transactions”, and nor does the App Store. Developers and iOS device users engage in relevant transactions, such as downloads, the acquisition of paid apps, updates and, subsequently, in-app purchases that take place between developers and iOS device users after the iOS app has been downloaded.

1672    Epic says that what Apple does do through the App Store is supply services to enable the search for, discovery, download and update of iOS apps. Apple also supplies in-app payment solution services, which facilitate in-app purchases in iOS apps that have already been discovered and downloaded.

1673    Now Epic says that Professor Hitt and Mr Houston did not cogently articulate what it means to say that the product supplied by Apple is “transactions”. But let it be assumed that the only sensible meaning one can ascribe to the notion is that it refers to the services Apple provides to facilitate transactions such as downloads, updates and later in-app purchases. Epic says that nevertheless Apple through the App Store provides services that do more than facilitate paid transactions. Moreover, it says that the avenues of potential competition with Apple extend beyond the facilitation of downloads, updates and in-app purchases.

1674    Epic says that the definition of “app transactions” used by Professor Hitt and Mr Houston encompasses quite different concepts. On the one hand it includes downloads and updates, but on the other hand it includes in-app purchases.

1675    Epic says that Professor Hitt and Mr Houston did not explain why it is appropriate to shoe-horn these separate types of services together into one product. Moreover, most of Professor Hitt’s and Mr Houston’s asserted competitive constraints are at most relevant only to in-app purchases and not downloads and updates.

1676    Epic says that a monopolist supplier of services for downloading and updating iOS apps could only be constrained by behaviour that sees a reduction in demand for the services it supplies, being services for downloading and updating iOS apps, which will not occur if iOS device users continue to use iOS apps.

1677    Demand for those services, as well as the other elements of the service supplied by Apple, will not be diminished simply by an ability for users to purchase digital content outside an iOS app for use within the app.

1678    Epic says that the market definition process is to be undertaken with a view to identifying the market that best assists an assessment of the conduct said to be done in contravention of the CCA. That market must have economic and commercial reality and not be artificial and contrived.

1679    Epic says that the idea of a market for “transactions”, abstracted from the actual services supplied to developers and users by Apple through the App Store, is such an artificial construction.

1680    As used by Professor Hitt and Mr Houston, Epic says that the notion of “app transactions” does not include many aspects of the services provided by Apple, such as curation, display and discoverability. And it says that in fact, Professor Hitt and Mr Houston mostly used the term to refer only to in-app purchases of digital content.

1681    Epic says that the conduct at the heart of the claim is the prevention of other avenues of distribution of iOS apps. And a market definition that excludes key elements of the services provided by app stores, including Apple through the App Store, would frustrate an analysis of the competitive effects of that conduct.

1682    It says that it would not permit an inquiry as to the effects of the conduct on the ability for there to be competition from new app stores across multiple dimensions, including in relation to curation, search and discovery. Indeed these elements are missing from the product dimension of the market posited by Professor Hitt and Mr Houston.

1683    Consequently, Epic says that “app transactions” is not the correct lens through which to assess current, or counterfactual, competitive conditions.

1684    Further, Epic says that an abstract notion of “transactions” as the relevant product would also be at odds with the core notion of a market for the purposes of the CCA, being one for the supply of goods or services. Section 4E defines a “market” as a market in Australia for goods and services, including other goods and services that are substitutable for, or otherwise competitive with the first mentioned goods and services. A market is a space in which transactions take place in respect of goods or services. The transactions take place in the market. They do not define its product dimension.

1685    Epic says that the relevant product for beginning the market definition inquiry comprises the services Apple provides through the App Store that facilitate the distribution of iOS apps.

1686    Now following the determination of the focal product, Epic says that the next task is to identify whether there are any close substitutes for the relevant services supplied by the firm in question, which impose close competitive constraints on a supplier of those services.

1687    Epic says that substitutability involves questions of degree. Moreover, the fact that customers may on occasion select one product rather than another does not establish that those two products are substitutable, so as to be within a single market. They may be distinct products for each of which there is a distinct demand. What is relevant to consider for present purposes is substitution that imposes a significant constraint.

1688    So, Epic says that applying the concepts of close competition and substitutability to a particular case is not a simple matter of asking whether two or more products have ever been interchanged, or whether they serve the same or similar functions, let alone whether some users have ever used both products. Evidence that some consumers acquire two types of services is at least as consistent with those services being independent or complementary products as it is with them being substitutes.

1689    Now Epic says that the inquiry as to whether a supplier of the relevant services would face close competitive constraints can be assisted by an application of the HMT, both at a qualitative level and through a more quantitative application of the SSNIP test.

1690    Now in the present case, Epic says that Apple is the only supplier of iOS app distribution services and it is the actual monopolist of those services. So, it says that evidence in relation to the App Store is probative of whether a hypothetical monopolist of those services would face competition from close substitutes.

1691    Now Epic says that various potential avenues of substitution could plausibly have been a source of competitive constraint, such as the possibility of substitution to services related to Android native apps, web apps, and the availability of non-mobile devices, such as PCs and consoles on which different versions of an app that has been configured for a different operating system may be distributed.

1692    But Epic says that none of these possibilities, whether assessed separately or collectively, impose a close competitive constraint on Apple. It has made the following points.

1693    First, it says that services for the distribution of native apps on Android are not a close substitute for such services on iOS. Before an iOS device user could even consider substituting in that fashion, they must use an Android device. But it says that the evidence suggests that most do not.

1694    The majority of iOS device users do not also have an Android device on which they could obtain, use or transact in apps. So, to access an Android app, the vast majority of iOS device users would need to purchase an Android device. But Epic says that users are unlikely to take that step for the purpose of accessing different app distribution services in response to changes in the price of distribution services. And that is particularly so at any point in time at which the user would not otherwise be acquiring a new device, given the cost of a device.

1695    Further, Epic says that even for those users who are otherwise intending to acquire a new device, something that occurs at lengthy intervals, there are significant barriers to an iOS device user acquiring an Android device, including switching costs and network effects.

1696    Further, it says that developers and users are unlikely to treat distribution of native apps through Android devices as substitutable with distribution on iOS devices. So, a supplier of iOS app distribution services will not be closely constrained by the possibility of developers or iOS device users substituting to distributing or obtaining apps on Android devices.

1697    Second, Epic says that a potential alternative to the distribution of apps on iOS devices is the use of web apps. Web apps are app-like pages that run in a web browser, but there are substantial differences between native apps and web apps that mean they are not close substitutes. Further, users and developers do not view them as close substitutes.

1698    Epic says that the prospect of developers and users switching to using web apps does not closely constrain Apple in its supply of iOS app distribution services, and would not constrain a hypothetical monopolist of those services.

1699    Epic says that because users and developers do not treat web apps as close substitutes for native apps, the ability to distribute and obtain an app as a web app does not impose a close competitive constraint on the supply of iOS app distribution services.

1700    Third, Epic says that a potential alternative to distribution of apps on iOS devices is the distribution of differently configured apps on non-mobile devices, such as PCs and consoles. But it says that they are not closely substitutable.

1701    It says that many apps are developed specifically for mobile devices and are not available on non-mobile platforms. Further, switching to obtain an app on another platform is not an option for users of those apps.

1702    It says that users are not likely to incur the cost of obtaining a PC or console in response to modest changes in the price of iOS apps, or in-app purchases, or the number and variety of apps available on iOS. Further, even those iOS device users who do have a PC or console are unlikely to treat using apps on them as substitutable with using apps on their iOS device. This is consistent with Professor Goldfarb’s observation that users tend to display behaviour consistent with a concept described as “device first”.

1703    It says that there are two key aspects to this concept, which concept I have discussed in detail elsewhere. One aspect is that several external factors are central to the choice of device, including location, time of day, Wi-Fi access, time, and mental attention available. The other aspect is that different devices are conducive to different usage experiences in terms of time spent, information frictions, connectivity, and need for focus. Together, these features suggest that the usage of smartphone and other devices, by the same users, often involve different motivations and contexts.

1704    Now Epic points out that Professor Goldfarb conducted his own analysis of Fortnite usage data around the time Fortnite was removed from the App Store in August 2020. But Epic says that even in this extreme case, which was the economic equivalent of an infinite price increase, iOS users did not substitute the vast majority of their lost gameplay with play on PCs or gaming consoles.

1705    And Epic says that there was a similar lack of diversion of spending by iOS Fortnite users from iOS to other devices following the removal of Fortnite, which is consistent with the conclusion that iOS device users do not treat the acquiring of digital content on non-iOS devices as substitutable for doing so on iOS devices.

1706    In general, Epic says that the evidence establishes that iOS device users do not view using apps on non-mobile devices as closely substitutable for doing so on an iOS device and would not switch to obtaining and using an app and the associated distribution services on a non-mobile device in response to modest changes in the price of iOS apps, or in-app purchases on iOS apps, or number and variety of apps available on iOS.

1707    Now Apple says that it is constrained by the ability of iOS device users to purchase digital content through a channel other than on iOS, but to use the content in their iOS app. But Epic says that this is not a real or relevant constraint.

1708    First, it says that it is not a mechanism that involves any reduction in the quantity of iOS app downloads or updates, or iOS app distribution services. A user engaging in that behaviour must still obtain and update the relevant iOS app from Apple using the App Store. There is no substitution away from the services provided for facilitating distribution of iOS apps.

1709    Second, it says that the ability of an iOS device user to use digital content purchased on another channel, in an iOS app, is dependent on both the developer and Apple permitting this to occur. Many developers do not allow such behaviour. Further, although Apple presently allows users of iOS apps to use content purchased on different channels, it did not do so before 2018. Moreover, Apple always has the power to remove this permission at its sole discretion.

1710    Third, it says that it would seem that iOS device users, developers and Apple do not consider purchasing digital content on non-iOS channels for use in iOS apps to be a close substitute for purchasing that content in the iOS app, let alone a close constraint on iOS app distribution services.

1711    Fourth, it says that there are significant frictions associated with leaving an iOS app to make a purchase on a non-iOS channel. So, iOS device users are unlikely to treat that option as a substitute for making an in-app purchase within the iOS app.

1712    Let me address in summary another point made by Epic.

1713    Epic points out that Professor Wright’s application of the HMT further demonstrates that there are no close constraints on iOS app distribution services. This is so for the following five reasons given by Professor Wright.

1714    First, developers are not likely to delist their apps from iOS in response to a modest increase in commissions. Doing so would deprive them of the ability to reach the large and valuable base of iOS device users, who do not multi-home to a significant extent and are unlikely to switch to another mobile device for the sake of accessing a single app.

1715    Second, developers are not likely to alter their business model away from paid downloads or in-app purchases to an advertising-supported model. For many developers, monetising through in-app advertising is unlikely to be attractive due to its effect on the user experience. Even for those developers for whom in-app advertising may be an option, they would be able to utilise that option without surrendering the option of monetising through paid downloads and in-app purchases.

1716    Third, most developers are prevented by Apple’s rules from diverting users to acquiring digital content on another channel by turning off in-app purchases in iOS. Even for those developers who could utilise an exception to do this, it is unlikely to be attractive for many developers due to the increased frictions associated with out-of-app purchases for users.

1717    Fourth, developers are unlikely to increase app or in-app purchase prices on iOS to divert users to alternative channels. Similarly, developers are unlikely to decrease the quality of their iOS apps relative to those apps on other platforms in response to an increase in commissions.

1718    Fifth, even if some developers do pass on an increase in commissions in the form of higher app or in-app purchase prices, this is unlikely to have a sufficiently large effect on users’ demand to make the commission increase unprofitable for Apple.

1719    For these reasons, Epic says that the relevant market is the iOS app distribution market.

1720    Now Epic has pleaded an alternative market that encompasses services for the distribution of native apps on iOS and Android devices, which I will refer to as the app distribution market. But I do not need to elaborate further at this stage on this alternative save to say that in my view, a market defined in this way does not provide the most appropriate lens through which to assess the competitive effects of the iOS app distribution conduct or iOS restrictive terms.

Apple’s case on the relevant market - summary

1721    Apple says that the alleged market for iOS app distribution services ought not be accepted. It is said that the alleged market for the distribution of iOS apps to iOS device users is both too narrow and too broad.

1722    Apple says that it is too narrow because it improperly excludes all non-iOS app transactions. Consequently, it ignores substitute app transaction platforms on which app developers and app users engage in app transactions, as is demonstrably the case in respect of Fortnite.

1723    And Apple says that it is too broad because it combines all app transactions across all types of apps, be they for games, dating, music, banking, photography or otherwise. This is divorced from reality. Different competitive conditions apply to different types of apps and the relevant substitute transaction platforms will differ. There is a distinct game industry that exists to develop, market and address game apps, but not other apps.

1724    Further, Apple says that the alternative alleged market for the distribution of iOS apps and Android apps to iOS device users and Android devices is similarly too narrow. It is limited to only tablet and smartphone distribution, to the exclusion of other app transaction platforms that connect developers and app users. It is also too broad for the same reasons.

1725    Further, the alleged iOS in-app payment solutions market fails to recognise that in-app payment solutions services are an essential part of an app transaction and so are not in a separate market.

1726    Further, in seeking to isolate a market limited to the provision of payment solutions on iOS devices, Apple says that Epic disregards the fact that developers can choose to monetise their apps on different transaction platforms and by means other than in-app purchases, and that app users can also choose their transaction platform, and sometimes a particular payment method.

1727    It is said that the artificiality of Epic’s alleged markets may be demonstrated by analysing the extent to which it is rational or possible for new entrants to enter the relevant market. Here the relevant market on Epic’s case is the “market” for the provision of services by which Apple distributes apps to iOS users. This defines the market itself as something that Apple has exclusive control over by virtue of its intellectual property rights. There is no field of rivalry. I have elaborated on the detail of this argument elsewhere.

1728    Apple says that it makes little sense in that context to ask whether it is rational or possible for a new entrant to enter that postulated market, when that could not occur unless and until Apple chooses to allow it. That is not because, for example, of any power arising from the competitive environment in which Apple operates. It is simply because of Apple’s lawful control over its own property. That was true in 2007 when Apple invented the iPhone, and chose initially to distribute only its own apps. That remained true in 2008 when Apple chose to allow third party developers, on specified terms, to use Apple’s intellectual property and gain access to the platform. The same oddity would arise in asking whether it is rational or possible for a new entrant to trespass onto the real property of a business and start conducting a rival business from that property.

1729    Apple says that that analysis reveals that the alleged markets, in addition to being at odds with commercial reality, are of no functional utility in understanding competitive forces. It also seeks to convert the protections against anti-competitive conduct in Part IV of the CCA into a compulsory regime for free access to the Apple software and iOS user base.

1730    Now Apple says that the relevant product for market definition in this case is app transactions, not app use, app distribution services or in-app payment solutions. App transactions comprise app downloads, in-app purchases including subscriptions and app updates.

1731    Apple says that there is substitution between platforms when it comes to such transactions. And it is said that this can be illustrated in the case of Fortnite by focusing on the transactions by which a commercial return is gained by Epic. Epic’s virtual currency (V-Bucks) consists of fungible digital items, and generally V-Bucks acquired from any source can be used within Fortnite on any platform and in any form of the game, that is, native app or game streaming service, to exchange for digital content such as a dance move. That digital content travels with the user’s account and can be used wherever and however Fortnite is played.

1732    Apple says that it is not in dispute that the App Store is a two-sided transaction platform that facilitates transactions between app developers, who supply apps and in-app content to app users, and app users who acquire apps and make in-app purchases from developers. It says that such platforms facilitate observable transactions between app users on both sides of the platform. The platform generates value for both groups of users when there is a transaction between them. It says that the transaction is the relevant product, and market definition must take into account both sides of the platform.

1733    Apple says that there is nothing anomalous in treating both app downloads and in-app purchases together. It says that the App Store, like other platforms, facilitates both types of transaction and developers can substitute between them. If, for example, Apple increased the App Store commission rate for app downloads, but not in-app purchases, developers who monetised their apps by charging for downloads could easily switch to charging for in-app purchases. That is demonstrated by the fact that developers have moved markedly from paid downloads to in-app purchases since the introduction of the latter on the App Store in 2009.

1734    Apple says that to separate app downloads and in-app purchases would be to confusingly bifurcate a single transaction platform. Apple says that the problematic result, which arises on Epic’s case, is that the facilitation of in-app purchase transactions does not form part of any relevant market, despite such transactions accounting for the vast majority of paid transactions facilitated by the App Store since at least 2014.

1735    Apple says that the choices of developers and app users to use a particular transaction platform depend on a range of factors such as the attributes and services offered by the platform and the value developers and app users each attribute to the platform. App transaction platforms therefore compete not just on price such as commissions payable by developers, but also quality and features offered to developers and app users.

1736    Further, app users who download apps may pay a fee for app downloads and/or in-app purchases, in which case the developer may have to remit commission to the platform provider. So far as the App Store is concerned, Apple collects a fee only when a developer chooses to charge the user for app downloads or to make in-app purchases of digital goods and services.

1737    So, Apple like many other app platform providers charges commissions on such app transactions, not usage.

1738    Apple also says that Professor Goldfarb’s focus on time spent playing or using an app was not appropriate because the data shows that app users do not necessarily play where they pay. Moreover, for many apps, use is free.

1739    Further, Apple says that apps may be downloaded by a single user onto many types of physical devices such as smart phones, PCs, tablets, game consoles, smart TVs, TV streaming devices, set top boxes, virtual reality equipment and wearable devices. App users may use several different devices and multi-home to engage with substantively the same app. But Apple says that the use of a device is not to be conflated with an app transaction. App transactions are the product that transaction platforms facilitate.

1740    Apple says that a threshold problem for Epic’s alleged markets is that the competition the subject of this case does not relate to app distribution or use, but to app transactions.

1741    Apple says that app transactions are what the App Store facilitates or, in other words, produces, and developers, app users and Apple only benefit from the App Store if such transactions occur. Even developers who do not monetise their apps through paid transactions, for example, developers who monetise through advertising, do not benefit unless app users first transact by downloading their apps. Platform operators are driven by transactions, from which they may derive revenue. Developers, including of “freemium” games such as Fortnite, share that fundamental focus upon transactions. A “freemium” game is free to download, but has paid offerings within the game. In order to define a market, it is necessary to identify the field of rivalry. The rivalry here relates to transactions, and in particular revenue resulting from transactions.

1742    Platform operators compete to win transactions and thereby win revenue. Apple says that it is erroneous to suggest that a service must be identified. But even if it were necessary, Apple says that the App Store does provide a service, that is, facilitating transactions between developers and app users.

1743    And Apple says that it is not appropriate to attempt to break up this service into its component parts such as curation, display and search. The facilitation of transactions on the App Store includes all of those supporting activities.

1744    Further, Apple says that there is nothing elusive or novel about a transaction market or a two sided transaction market; see, for example, Filistrucchi, L et al, “Market definition in two-sided markets: theory and practice” (2014), which I have discussed earlier.

1745    Further, Apple says that in analogous US litigation the subject of Epic Games Inc v Apple Inc, 559 F Supp 3d 898 (ND Cal, 2021) and Epic Games, Inc v Apple, Inc, 67 F 4th 946 (9th Cir. 2023), it was found that the relevant market was for transactions. Now it is convenient for me to say here that this was little more than a jury point. Foreign cases and their conclusions are a function of their different legislative, precedential, evidentiary and adversarial foundations as applied to the issues identified and the arguments put and fought. It is simply unproductive to linger on any analysis of them.

1746    Further, Apple says that app users can readily transact on their platform of choice. Apple says that that reality is demonstrated by Fortnite, Epic’s game.

1747    Fortnite is available to be downloaded as an app for free and played on multiple platforms, including PCs, PlayStation, Xbox, Nintendo Switch and Android mobile devices. Fortnite can also be played through a web browser, on an iOS device or any other device with a web browser, using a game streaming service. Generally, a key feature is cross-platform play.

1748    The playing of Fortnite delivers no revenue to Epic. Epic earns revenue from transactions which some app users make to acquire V-Bucks for use within the game. V-Bucks can be purchased on all of the platforms where the game can be played and using any device. They can also be purchased from the Epic Games Store website, using any web browser, and by acquiring redeemable cards from retail stores. V-Bucks can be redeemed for digital content, such as “skins” and “emotes”, which can be used within the game. Commercially, it does not matter where or when those V-Bucks are redeemed for such digital content. The redemption can occur on any platform, regardless of where the V-Bucks were acquired, with the exception of Nintendo Switch. This is known as cross-wallet functionality. Digital content that has been acquired by a user through this process stays with the user’s account, wherever they choose to play Fortnite.

1749    Apple says that these elements of the commercialisation, user experience and functionality of Fortnite expose the artificiality of Epic’s market analysis. Apple says that Epic’s analysis isolates the distribution of a particular technical form of the game, that is, a native app on a particular platform being in this context iOS, without regard to the alternative ways that Fortnite is in fact accessed and played, and V-Bucks are purchased.

1750    Further, Apple says that when it comes to market definition the relevant issue is not limited to actual substitution, but includes potential substitution. Market participants are constrained by both actual and potential substitution. Apple says that there is the potential to substitute transactions in games like Fortnite. It is open to any developer, in a number of ways, to substitute away from a platform or away from particular charges. This can occur by providing a discount on its preferred platform and promoting that discount to app users, by monetising its apps in a way that does not attract commission, by removing its apps from a platform, or by reducing the resources it expends on developing and updating apps for one platform relative to others. And Apple says that even if Epic chooses not to take advantage of the options available to it, that does not deny the potential for substitution. This includes Epic’s choice ordinarily to maintain uniform pricing for V-Bucks on different platforms, and so negating any incentive for app users to engage in actual substitution.

1751    Further, as Apple points out, Professor Goldfarb has propounded two aphorisms in support of the proposition that app users do not substitute between competing platforms: “device first” and “clicks are costly”. But Apple says that each should be rejected.

1752    Now “device first” is the proposition that app users will choose a device first and that they will therefore not substitute between platforms. But Apple says that that proposition is not supported by the economic literature. It is said that the literature relied upon by Professor Goldfarb establishes the much less contentious proposition that users behave differently on different devices. App users can and do move transactions to another platform, such as a website or web app. They can do this without even changing devices and without changing the amount of time they spend playing from one device to another.

1753    Further, Apple says that “clicks are costly” involves the contention that different platforms, for example, web apps or game streaming services, are not substitutes for native apps because they require more clicks. Again, Apple says that the use of this slogan is not supported by the cited economic literature. Further, Apple says that the contention lacks an evidentiary foundation. It is said that the evidence does not establish any substantial difference in clicks, let alone that it is sufficiently costly to mean that app users do not substitute or could not substitute with an incentive, for example, between native apps and a website or a web app.

1754    Now I should note here that I have discussed Professor Goldfarb’s aphorisms elsewhere in my reasons and have largely accepted Professor Goldfarb’s exposition and the utility of these two pithily expressed concepts.

1755    Generally, Apple says that the market proposed by Epic is too narrow in that it ignores multiple other competing platforms that connect developers and app users.

1756    Moreover, Apple says that it is too broad in that it covers all apps, despite the very different competitive conditions applying to different types of apps, including in particular game apps.

1757    Further, Apple says that it operates, in respect of Epic, in a two-sided market for digital transactions in respect of game apps, facilitating those transactions for both sides by means of the App Store two-sided transaction platform.

1758    Let me say something more about Apple’s case concerning two-sided platforms. Apple says that Epic’s case fails to take account of the features of two-sided platforms. And it makes the following points.

1759    First, Apple says that such platforms attract two distinct groups of users.

1760    Second, it says that they have indirect networks effects between app users and developers comprised of the following elements. There are membership effects where one group of users derives greater valuer from a platform with more users in the other group and vice versa. There are usage effects where one group of users derives greater value from a platform when users from the other group use the platform more, and vice versa. Further, the attractiveness of the platform to one side is affected by the attractiveness of the platform to the other side, such that the needs of both sides need to be balanced. App users value the App Store more highly if there are more developers offering more apps and in-app purchases, and vice-versa. Apple therefore has an interest in ensuring that the platform is secure and reliable for app users and that digital products are delivered to app users as promised, whilst also assisting as many developers as possible to make quality apps available on the App Store.

1761    Third, Apple says that the volume of interactions between the two groups can be affected by the price structure(s) on each side.

1762    Professor Goldfarb used the “device first” concept in support of his view that use of native apps on iOS devices are not substitutable with usage on other devices. But Apple says that he thereby failed to analyse consumer substitution behaviour with respect to app transactions. A consumer facing a price increase for transactions through one platform could choose to move the transaction to another platform without shifting the time they spend playing from one device to another.

1763    Apple says that Professor Wright conflated the costs of switching mobile devices with switching costs for shifting app transactions away from the App Store, when in fact iOS app users need not switch mobile devices to substitute transactions as they could for example make transactions through websites accessible through any mobile device.

1764    Apple says that as a result of indirect network effects, substitution on one side of the platform will likely affect the propensity of substitution on the other side, with changes in terms on one side likely to cause a feedback loop. Fewer users on one side or users on one side transacting less may reduce the demand on the other side.

1765    Accordingly, Apple says that pricing decisions on two-sided platforms typically depend on price elasticity of demand and network effects conveyed between both sides. Pricing strategy is therefore directed not to maximising profits from either side in isolation, but must consider the effects of the strategy on both sides. Unlike one-sided markets, it is common for two-sided platforms to set a low, zero or negative price to users on one side and a positive price to users on the other. The presence of indirect network effects also means that the marginal cost of serving each side is not necessarily the appropriate frame of reference for competitive prices on either side of the two-sided platform.

1766    Apple says that the commercial context in which app transactions occur includes payment of commissions to Apple for paid app downloads and in-app purchases. Other app transaction platforms on which developers and app users may transact act as a competitive constraint on Apple. Those platforms too, have an interest in maximising the quantity and value of transactions on their platforms.

1767    Further, Apple says that in a two-sided market any attempt to apply the SSNIP test is complicated and needs to take account of various matters being the following: (a) the prices charged on both sides of the platform; (b) the optimal adjustment of the price structure; (c) the presence of indirect network effects and positive feedback loops; and (d) so, within-platform, cross-side effects, being the value derived by customers on one side of the platform from customers on the other side of the same platform, and cross-platform, cross-side effects, being the value derived by customers on one side of the platform from customers on the other side of a rival platform.

1768    Further, part of Apple’s case is that gaming apps are separate and distinct from other apps.

1769    Apple says that the App Store and other app transaction platforms facilitate transactions involving very different types of apps, including games, video streaming, medical, music, finance, business, health and fitness, social networking, dating, shopping, weather and magazine and newspaper apps. Further, these disparate transactions are not all substitutes for each other.

1770    Apple says that transactions for different types of apps face different competitive conditions, which must be taken into account when defining a market. There are different competitive conditions across genres for transactions, such that it is not appropriate to cluster all app transactions into a single market. Apple says that the evidence demonstrates that it is in the two-sided market for digital transactions in respect of game apps in which the relevant the conduct occurs, and must be analysed.

1771    Further, Apple says that developers’ monetisation strategies differ by app type. It has made the following points.

1772    First, it says that one has the fact that 98.4% of in-app revenues for game apps were from non-subscription in-app purchases. In contrast nearly all other app genres generated the majority of their revenue on the App Store from subscription in-app purchases.

1773    Second, it says that one has the fact that the proportion of app transactions that were free was higher in genres such as shopping, finance and travel (over 97% were free) as compared to genres such as games (70%), sports (71%) and magazines and newspapers (51.3%).

1774    Third, it says that only 4.5% of business apps were monetized through the App Store, in contrast with over a quarter of photo and video apps that monetized directly through paid transactions in the App Store.

1775    Fourth, it says that the average commission rate for in-app purchases was 18.6% for entertainment apps compared to 29.8% for game apps.

1776    Further, it says that developers tend to focus on particular genres. So, 17.1% of developers that offered more than one app through the App Store offered only game apps. App developers in health and fitness, magazines and newspapers, stickers and sports were also concentrated in individual app genres and did not develop apps for other genres. On the other side of the transaction platform, many app users transacted through the App Store only for specific genres. So, 34.6% of user accounts only made paid transactions for a single app genre. App users may also focus their spending in narrow categories. So, 25.4% of user accounts that spent money on game apps did not spend money on any other genres.

1777    Further, it says that many platforms distinguish between transactions for games and non-games, with games often being categorised under a separate tab. Of the 27 different categories of apps which developers may choose to classify their app on the App Store, the only category of apps which has a separate tab is for games. Games are arranged under a “Games” tab, whereas apps in the other 26 categories are arranged together under an “Apps” tab.

1778    Further, it says that Apple’s business is structured such that teams are split between games and non-gaming categories. Further, games are generally released globally, whereas distribution of non-game apps may vary between each local App Store. Some competitive platforms such as Steam exclusively or nearly exclusively provide game app transactions. Some platforms such as Microsoft Store charge different commissions on game app transactions as compared to non-game app transactions.

1779    Further, it says that game developers, save for large organisations like Microsoft, generally specialise in development of game apps. This means that the ease of substitution by developers between production of game apps and production of other apps is limited, so that conditions of competition which apply to the ability to substitute transactions may be different. The technology used in the development of game apps and non-game apps is different. Non-game developers tend to focus on native, web or hybrid “approaches” to building apps rather than utilise a particular engine. Game developers tend to make greater use of graphics processing and technology.

1780    Let me say something about Apple’s case concerning substitutability of transactions across different platforms.

1781    Apple says that the relevant question for substitution of transactions across platforms is whether there is a sufficiently strong competitive constraint from the potential for app users and developers to make substitute transactions on alternative platforms to the App Store if Apple increased prices or reduced the quality of service to either or both user groups.

1782    Apple says that given that the App Store is a two-sided transaction market, substitutability for both sides of the platform being app users and developers must be accounted for.

1783    Now other than the SSNIP test, Apple says that Epic’s assertion that substitution is either non-existent or limited rests principally on two slogans: “device first” and “clicks are costly”. It says that those slogans should be rejected.

1784    Further, it says that a critical characteristic of app users and developers with respect to game app transactions is that they engage in multi-homing, that is, they make transactions facilitated by many platforms across a range of devices. This further enforces the ability and tendency of app users and developers to substitute transactions across platforms.

1785    It says that developers almost invariably develop apps on multiple platforms, except for instances where console and PC game app transaction platforms such as the Epic Games Store which have negotiated exclusivity arrangements that limit distribution on other platforms.

1786    It says that in the case of app users, they too make use of multiple platforms.

1787    Further, it says that other app transaction platforms are in the same markets for different types of app transactions as the App Store because of the close competitive constraints from app users and developers transacting outside the App Store.

1788    In particular, Apple says that the following consequences are likely if it either increases the price it charges to app users (presently zero) or developers such as commissions for facilitating transactions between them, or reduces the quality of the App Store.

1789    First, developers may substitute away from the App Store by one or more of several means, including offering app users the ability to transact on other platforms at the same or a different price, monetising their apps in ways that do not attract commission, removing their apps from the App Store, or reducing the resources they expend on developing and updating apps for the App Store relative to other platforms.

1790    Second, app users may substitute their transactions from the App Store to other app stores with little or no effort, especially in light of multi-homing behaviour and the fact that transactions for the same digital content such as V-Bucks can be made on different platforms and used across platforms.

1791    Third, the first two matters may cause the numbers of app users, developers, apps and the value of app transactions on rival transaction platforms to increase at the expense of the App Store.

1792    Fourth, Apple says that the matters just referred to may lead to a mutually reinforcing cycle of indirect network effects for both developers and app users, causing developers to focus further on alternative transaction platforms that are more popular with app users and therefore more profitable, and causing app users to increase further their use of alternative transaction platforms with more developers and a greater number of higher quality apps.

1793    Further, Apple says that the close substitutability of rival app transaction platforms is also evidenced by the ability of rival platforms to expand quicky and easily to serve additional users at low marginal cost, and the marginal cost to Apple from each additional transaction on the App Store is low, which means the variable margin on each transaction is high and losing sales has a large impact on Apple.

1794    Further, Apple says that as to game app transactions in Australia, such transactions may occur on or by using various modes or mechanisms.

1795    Further, Apple says that it is a matter for developers to choose the transaction platforms on which to offer their games. If a developer chooses not to offer a game on a specific platform at any given point in time that does not preclude that platform from being a substitute, bearing in mind that a market includes the area of potential as well as actual close competition. And developers may expand the reach of their games on platforms over time.

1796    Further, Apple says that game developers also decide where and how app users will pay for games, hence facilitating app user substitution across platforms. For example, developers can enable customers to use in-game currency purchased through alternative platforms on iOS devices, that is, cross-wallet play. Developers may allow linking of in-game content and game progression across devices using a common user account which spans different game app transaction platforms, that is, single sign-on, thereby enabling continued game play, that is, cross-progression. Offering virtual currency and single-sign on are features that further strengthen substitutability between app transaction platforms. All of these matters further reinforce the conclusion that transactions through alternative game app transaction platforms can be functional substitutes for transactions through the App Store.

1797    Apple also says that various particular characteristics of game app transactions and real world competition also demonstrate that transactions on other platforms are substitutes for game app transactions on iOS. First, the same transactions such as the purchase of V-Bucks can be effected across multiple platforms including PCs, consoles and web streaming services. Second, substitution occurs not just within the same game but also between similar games on different platforms. Third, there is growing cannibalisation between hand-held gaming devices and smartphones. Fourth, cloud gaming services can offer a comparable gaming experience to native PC and console game apps, and their revenues continue to grow. This demonstrates their ability to constrain the market power of the App Store and other game app transaction platforms. Fifth, if app users own multiple devices such as iPads, PCs, Android phones, handheld game devices and smart TVs, then the distribution of apps on iOS devices can be a substitute for the distribution of apps used on non-iOS devices, including devices that are not smartphones or tablets.

1798    So, Apple says that Epic’s proposed iOS app distribution market and app distribution market do not properly identify the product in issue, fail to identify close substitutes and ought be rejected.

1799    Apple says that the true market in which Apple provided services to Epic via the App Store is the market for game app transactions, or other app transactions, which can be performed across a wide array of platforms.

1800    Now it will become apparent from what follows that I have generally accepted the main themes of Epic’s analysis and its market definition. Let me now turn in more detail to the question of the relevant focal product to begin with for the purposes of market definition.

Market definition – what is the relevant product?

1801    Let me say at the outset that I have preferred Professor Wright’s approach to the approach of either Professor Hitt or Mr Houston in determining the appropriate product dimension for market definition purposes.

1802    Professor Wright approached the task of market definition from the starting point of identifying the conduct at issue including identifying the services supplied by Apple that are particularly affected by the impugned conduct.

1803    Further, I agree with Epic that his identification of the services provided by Apple accords with the commercial realities.

1804    Now contrastingly, Professor Hitt said that the relevant product is “app transactions”. And he arrived at that conclusion from the premise that the App Store is a two-sided platform that facilitates transactions. So, his identification of the product derived from his description of the nature of the App Store as a transaction platform, rather than any analysis of what services Apple actually provides. But I agree with Epic that that is a problematic approach.

1805    Moreover, Professor Hitt’s market definition approach was not tailored to an assessment of the conduct at issue in this proceeding. Indeed, and as Epic has pointed out, Professor Hitt conceptualised the market first, as something which exists independently of the conduct at issue, before looking to see whether the conduct fits within the market.

1806    As Epic points out, when pressed during cross-examination to identify where in his written market definition exercise he took the conduct into account, Professor Hitt was only able to refer to his recitation of the pleaded allegations. His written analysis took little account of the conduct at issue.

1807    Further, Mr Houston also failed to assess the relevant product in a commercially realistic way tailored to the conduct at issue.

1808    Further, Mr Houston’s analysis was not directed to ascertaining what service Apple in fact supplies as a matter of commercial reality. Rather, he focused more on Apple’s present monetisation strategy.

1809    Further, Professor Wright, having identified the relevant candidate products by reference to the commercial reality and having regard to the conduct at issue, then conducted a thorough assessment of the substitution possibilities for those services. This included a detailed and methodical review of all potential avenues of substitution. It also included assessments of the incentives faced by developers and users, existing data on their behaviour, and estimates of elasticities of demand. It has not been suggested that Professor Wright failed to take into account any relevant possible avenue of substitution.

1810    His analysis was both qualitative, in considering the likelihood of developers responding to price or quality changes by substituting away from Apple’s services, and quantitative, through use of a SSNIP test.

1811    Contrastingly, Professor Hitt’s substitution analysis began with the proposition that the mere existence of other app transaction platforms, and the mere fact that developers and consumers multi-home, confirms that competition occurs for transactions.

1812    Professor Hitt accepted that these matters were an important part of his justification of his choice of market. He suggested that his substitution analysis, done subsequently, was also included.

1813    But when one considers Professor Hitt’s analysis of constraints, it is apparent that he did not consider whether developers and users would switch away from their existing use of services supplied by Apple in response to small changes in the price or quality of those services. Further, it is apparent that he relied principally on the fact that developers and users multi-home and, on occasion, engage in transactions for digital content on devices other than iOS devices. But that is not an assessment of whether the various alternatives are close economic substitutes. They are not.

1814    Similarly, Mr Houston failed to engage in an assessment of the likelihood of substitution in response to small changes in price or quality of Apple’s services. In essence, as Epic correctly characterised it in my view, he just made an assertion of the ability of developers and users to move away from Apple’s services, coupled with an unsubstantiated statement that they would have the incentive to do so. But there is no analysis to enable one to conclude that they would be likely to do so. So, Mr Houston did not address the costs involved in switching, or in making out of app purchases.

1815    As Epic put it, the evidence of Professor Hitt and Mr Houston amounted to little more than an assertion that it is technically possible for users and developers to use different services, that is, that there are technical substitutes for Apple’s services.

1816    Now in my view app distribution services is the correct focal point for market definition.

1817    App distribution is the process involved in getting apps from developers to users’ devices. It necessarily includes the process by which users discover, retrieve and install apps, which may include a process of curation, through which a distributor defines the set of available apps.

1818    In contradistinction to disaggregated alternatives, app stores make app distribution convenient for users and developers by unifying app discovery, app retrieval and app installation.

1819    A developer of an iOS app who wishes to have it accessed by iOS device users must have a means by which to make it available to such users. Similarly, iOS device users who wish to access iOS apps must have a means of doing so.

1820    The App Store is the mechanism that Apple offers, and the sole mechanism Apple permits, to make iOS apps available to users.

1821    Apple is an intermediary that provides a range of intermediary services for which it levies a commission upon developers. In the case of each developer, Apple provides those services pursuant to the DPLA and either the schedule 1 agreement or schedule 2 agreement.

1822    Irrespective of whether a developer makes available a free app, a paid app, or an app with in-app purchases, Apple provides the same range of services to developers as their agent pursuant to these contracts. Those services include hosting the app, marketing and promoting the app, soliciting and obtaining orders for the app from users, and preparing apps for download by users by adding a security solution and other optimisations.

1823    Professor Wright correctly commenced his market definition exercise by recognising the nature of the conduct under examination. By reference to the services Apple provides pursuant to the DPLA, he then correctly identified services for the distribution of iOS apps as the focal product.

1824    Apple contends for a market which it describes as a market for app transactions. Apple says that the single product supplied via the App Store is app transactions, with that term described as comprising a download, an app update, or an in-app purchase. So it is said that the product dimension is a download, an app update, or an in-app purchase. But in my view that market definition is artificial. Further, and as Epic pointed out, there are three things to note.

1825    First, an app transaction defined in that way is not a good or a service.

1826    Second, the product alleged to be supplied through the App Store was limited to the transaction, in distinction to the other elements of the App Store, such as creating a platform through which developers can publish their apps and from which a consumer can download the application, and the facilitation of observable transactions.

1827    Third, the concept of an “in-app purchase” is not confined to in-app purchases of digital content and includes in-app purchases of physical goods or services.

1828    Moreover, Apple’s defence eschews any notion that the relevant product supplied by Apple comprises services for facilitating the downloads, updates and in-app purchases said to constitute the relevant product.

1829    Apple is not the buyer or seller of apps in a meaningful way in the present context. The vast majority of transactions take place between developers and users. Apple supplies the platform and provides platform services.

1830    Now Professor Hitt’s opinion was that Apple provides a variety of services related to apps, but the relevant product is “app transactions”, defined to mean app downloads, app updates and in-app purchases, where in-app purchases is defined to mean in-app purchases of digital content. That definition of the relevant product can be contrasted with Professor Hitt’s opinion that the App Store provides a variety of services and features to attract both app developers and consumers.

1831    Further, Mr Houston said that the product supplied by Apple was transactions. In his first report, Mr Houston was explicit that services provided by Apple, such as support services and App Store tools, were not part of the relevant product. He was clear in his opinion that services offered by Apple to users, such as the provision of the ability to download apps and the curation of the App Store, were not part of the relevant product.

1832    Further, in its written opening submissions, Apple said that the relevant product for the purposes of market definition is “app transactions”. But Mr Darke SC for Apple, recognising the difficulty in advancing a case that defined the product dimension of a market by reference to nebulous “app transactions”, which were neither a good nor a service, put something different in his oral opening submissions in an attempt to address the problem. He said:

… when we talk about the relevant product to market definition in this case being app transactions, we are talking about services for facilitation of app transactions. And we don’t mean facilitation in a narrow or technical sense; we mean the range of services the App Store provides, proprietary tools and technologies, an App Review process, marketing support, app and in-app purchase discovery services, and a safe and secure system for effecting digital transactions and so on, all of which encourage or promote app developers and users to transact with each other.

1833    But the contrast between this attempted finesse and the written opinions expressed by Professor Hitt and Mr Houston, and Apple’s pleaded case, is well apparent.

1834    Now Apple disputes all of this and says that Professor Hitt’s second “key takeaway” in chapter 5 of his report was that the App Store creates value by facilitating transactions. Moreover, on 18 separate occasions in his report, Professor Hitt explained that his conception of the markets was premised on Apple providing services to facilitate transactions. Further, Apple says that similarly, on 24 different occasions Mr Houston said that his conception of the market was also based on the facilitation of transactions. But I agree with Epic’s characterisation of their evidence. I will deal with this in a moment.

1835    Now following this change in position, the economic expert witnesses participated in a conclave and produced a joint report, and Mr Houston produced a supplementary report.

1836    In the joint report, Professor Hitt said that services that are offered to facilitate app transactions, such as app discovery, quality assurance, or payment processing, enable and facilitate the provision of app transactions and are an integral part of the delivery of app transactions. But despite this, he said that the appropriate product for examining all of Apple’s challenged conduct is app transactions.

1837    As for Mr Houston, I agree with Epic that in his supplementary report he said contradictory things. He said that the markets for app transactions include the provision of services designed to allow and encourage app users and developers to make app transactions, for example, app curation and discovery services. But then he said that a market cannot be identified by reference to those services as there are no relevant actual or potential transactions.

1838    Now in the concurrent evidence session, Professor Hitt said that the relevant product is app transactions. But he agreed that the App Store provides many other services, such as discovery and app review, that are an integral part of providing app transactions.

1839    Now as Epic correctly contends, there are only two possibilities as to the way in which the position adopted by Apple’s expert economic witnesses can be assessed. One alternative is that Apple’s experts maintained the view expressed in their initial reports that the only relevant product is app transactions. The alternative is that each of Apple’s experts changed his position and now accepts that the relevant product includes the full range of distribution services, including app curation and app discovery.

1840    I agree with Epic that the first of these alternatives is the preferable understanding of their evidence, since Professor Hitt’s and Mr Houston’s entire market and competition analysis proceeded on the basis that the relevant product is app transactions and not the wider set of services provided by Apple to developers via the App Store. And if that is the case, there is a significant discrepancy between the evidence given by the economic experts and the case that Mr Darke SC opened with.

1841    Alternatively, if one opts for the second alternative, it follows that Apple’s experts now accept that the relevant product includes the full set of distribution services, including app curation and app discovery. But this focal product is in substance indistinguishable from the relevant product definition advanced by Epic and supported by Professor Wright.

1842    In these circumstances, but subject only to the appropriateness of payment solutions being treated separately, it is appropriate to adopt the relevant product proposed by Professor Wright as the foundation of the market definition inquiry. That position is fortified when one considers the commercial evidence.

1843    Let me now set out in some detail Apple’s case on the relevant product for the purposes of market definition.

Apple’s arguments concerning the relevant product

1844    As I have said, Apple says that app transactions are what the App Store facilitates or, in other words, produces, and what developers, app users and Apple benefit from if such transactions occur. Platform operators are driven by transactions, from which they derive revenue. Developers, including of freemium games such as Fortnite, share that fundamental focus upon transactions.

1845    Apple says that Epic’s markets do not have a locus of transactions. Instead, they are an artificial construct designed to arrive at the conclusion that there are not one, but two single product markets, of the kind that antitrust economists consider theoretical.

1846    Apple points out that it has been observed that single product markets are just as unlikely in the particular context of digital platforms. In B Jullien and W Sand-Zantman, “The Economics of Platforms: A Theory Guide for Competition Policy” (2021) 54 Information Economics and Policy 1, it was said (at 10):

… Given that platforms with very different profiles may compete, the concept of a single product market definition or several independent markets will not fit the situation of platforms, except in rare occasions. Indeed platform competition involves a nexus of markets, related through heterogenous envelopment strategies …

1847    Further, according to Apple, one of the other difficulties with Epic’s case is the assertion that the propositions that it advances about app markets are universally true, including for non-game apps. It says that it is wrong to assume that propositions about game apps are true of non-game apps.

1848    Apple says that consideration of the commercialisation, user experience and functionality of Fortnite exposes the artificiality of Epic’s market analysis. That analysis isolates the distribution of a particular technical form of the game, that is, a native app on a particular platform, being iOS, without regard to the multitude of alternative ways that Fortnite is in fact accessed and played, and without regard to the fact that the game is monetised through the sale of V-Bucks.

1849    Apple made reference to Epic’s own conduct when it launched Project Liberty. Epic was aware that it could count on the revenue streams continuing to flow from transactions on competitor platforms. Epic encouraged Fortnite users to carry on playing, and carry on buying V-bucks, on competitor platforms. As predicted, the users did, and the “party continued” just as Epic said that it would.

1850    Apple says that even accepting for the sake of argument that it is appropriate to narrow the focus just to iOS users playing Fortnite and engaging in transactions within the Fortnite game itself on iOS devices, it can be seen that Epic’s market is artificially narrow.

1851    Apple says that even on that premise, there are substitutable services. An iOS user on an iOS device can today play Fortnite, and engage in transactions within Fortnite for digital content, without using an iOS native app. That is because Fortnite is available on game streaming services that can be accessed from any iOS device, without downloading any app or accessing the App Store. There is no requirement for Epic to comply with the App Store review guidelines, use IAP or pay Apple any commission.

1852    Further, Apple says that there are different competitive conditions in respect of game apps. Quite apart from the question of the various features that distinguish game apps from other apps, there are entire platforms that are either exclusively, or almost exclusively, directed to game apps or, more accurately, to monetising those apps through game app transactions.

1853    Further, Apple says that there are different characteristics of game apps as compared with non-game apps and has made the following points.

1854    On the App Store, apps in the category of games are arranged under a “Games” tab, whereas apps in the 26 other categories are arranged together under an “Apps” tab. Further, teams within Apple’s editorial and business management streams are split between games and non-games categories. That includes different teams for curation and business development of games and non-games. Further, Apple Pty Ltd tracks billings for the games category separately from other aspects of the App Store business.

1855    Further, developers of game apps, save for large organisations like Microsoft, tend to specialise in the development of games. Developers of non-game apps often specialise in the development of one or more non-game apps.

1856    The tools used by game developers tend to be very different from those used by other types of developers. Games developers make greater use of graphics processing and technology in the development of their game apps than non-game developers.

1857    There is generally also a different approach to monetisation. Game developers tend to monetise via in-app purchases, while developers of non-game apps have become increasingly focused on subscription revenue.

1858    Further, with very limited exceptions such as China and Korea, games in the App Store are generally released globally, whereas the distribution of non-game apps may vary between each local App Store.

1859    Further, Apple says that the realistic substitution possibilities differ for different app genres. A proper attempt to define a market for distribution or even payment solutions would need to account for the variation in substitution possibilities as between different app genres.

1860    Apple says that it cannot be assumed that a single market for all apps would be an appropriate lens to examine relevant competition.

1861    So, Professor Hitt identified distinct markets for digital game app transactions and TV and video streaming app transactions. He identified differences in competitive environments for other kinds of app such as books and audiobooks, music and audio streaming, news and magazines, and social media.

1862    Now Professor Wright said that segmenting distribution services according to app type was inappropriate because the distribution services that Apple provides are the same for different app genres. But Apple says that Professor Wright conceded that he did not know the specifics, and he agreed that the differences seemed plausible or reasonable.

1863    Relatedly, Professor Wright said that treating different app genres as generating different markets was inappropriate because of supply-side substitution possibilities, that is, a supplier of distribution services to game app developers could easily supply the same services to video app developers. But Mr Houston said that there was no evidence of the degree or likely strength of these supply-side substitution possibilities.

1864    Apple says that Professor Wright’s speculation took insufficient account of the indirect network effects of two-sided platforms. Professor Wright agreed that the strength of indirect network effects can vary between app genres.

1865    Apple says that consideration of different app genres does not involve any departure from commercial reality. Certain platforms focus principally on particular app genres, such as the Epic Games Store and Steam, which service games apps and do not distribute video-streaming apps. The Microsoft Store separates games apps, for which it charges a 30% commission, and other apps, and has different policies for each.

1866    Let me turn to another point that Apple has raised concerning the inappropriateness of making a distinction between distribution services and payment solutions.

1867    Apple says that the distinction between distribution services and payment solutions does not reflect the reality of the products that Apple, and other app platforms, supply.

1868    Apple says that in defining a product dimension, it is appropriate to start with a consideration of the total package of economic value or utility that the App Store offers.

1869    Apple says that whether it is then appropriate to divide the total package into discrete products must take into account that, as a matter of commercial reality, most products are composites of various parts. That is because, from an economic perspective, offering a single product is likely to be beneficial for consumer welfare when doing so reduces distribution costs, lowers the cost of ensuring compatibility, enhances accountability or protects intellectual property.

1870    Apple says that the starting point must therefore be that the App Store, like two-sided transaction platforms in general, provides the single basic service of facilitating the transactions between app developers and app users.

1871    It says that there is no relevant difference between describing what Apple supplies as services facilitating app transactions, or app transactions simpliciter. Both descriptions capture the same economic concept. It says that app transactions simpliciter are the productive outcome of the facilitation services. Focus on that outcome permits attention to constraining substitution possibilities.

1872    Apple says that it is constrained by the possibility that developers and users consummate their transactions somewhere else, that is, using someone else’s facilitation services, including the possibility of self-supply. More precisely, Apple is constrained by the possibility that developers and users consummate paid transactions, for which the App Store derives commissions, elsewhere.

1873    Apple says that for Epic to start from the position that Apple supplies a distribution service risks over-simplifying the service to a one-sided service to app developers. Apple is a two-sided platform and supplies at least most of its services jointly to developers and users. There are strong network effects.

1874    Further, Apple says that to identify the product as distribution does not appropriately reflect the legal and economic nature of the relationships between Apple, app developers and app users which are created or affected by the DPLA. Apple says that the following key points should be emphasised in relation to the appropriate characterisation of the product.

1875    First, Apple says that Epic is wrong to discern in the DPLA a separate agreement for the distribution of apps, distinct from the licence to use Apple's tools and technologies, derived from and including its associated intellectual property. There is a single commercial bargain between Apple and the developer, which includes the terms of the schedules. There is a licence to use Apple’s tools and technologies, derived from and including its IP, to test and develop apps for distribution, if selected, on the App Store on all the terms set out in the DPLA and the applicable schedule.

1876    Second, Apple says that although the DPLA is an agreement between Apple and an app developer, many of its terms reflect the fact that Apple is providing a service jointly to app developers and app users.

1877    Where the developer intends to charge end-users a fee for the app or within the app through the in-app API, the developer must enter into an agreement with Apple in the form of the schedule 2 agreement before any such commercial distribution of the app or the additional content, functionality or services for which the developer will charge a fee. The terms of schedule 2 are then incorporated into the DPLA (clause 7.2).

1878    Apple’s distribution of an app is conditioned on the app not affecting app users in certain specified, detrimental ways. So, an app must tell the user that a video or microphone recording is being made. There are limitations on apps collecting user or device data, including location data. Further, apps cannot contain objectionable or inappropriate material. Further, apps cannot contain malware or viruses or the like.

1879    Apple has the right to make refunds to users, and where necessary to require the developer to reimburse or grant Apple a credit for the amount refunded.

1880    So, Apple says that it would involve a legal misconstruction of the DPLA to say, simplistically, that Apple supplies distribution services. The service it supplies encompasses distribution of certain apps, but the distribution component cannot be isolated from the true service, which is a two-sided service to developers and users to facilitate transactions between them.

1881    But Apple says that even if I took a narrower view of the DPLA, so that it was confined to the relationship between Apple and an app developer, that formal relationship would nonetheless be seen as one which expressly contemplates simultaneous relationships between app developers and app users, and Apple and app users.

1882    An appropriate product dimension for the purposes of market definition would not exclude from view those relationships, with a resulting product, such as distribution services, that failed to capture commercial reality.

1883    Apple says that the economic exercise of market definition would miscarry if it was tied too closely to a purely formal contractual analysis.

1884    And even if I started with a conception of Apple’s service as a distribution service, it does not follow that “payment solutions” should be excised from the distribution service.

1885    Apple says that there is some vagueness about precisely what Professor Wright categorised as distribution versus payment solutions. It seems, ultimately, that Professor Wright conceived of the payment solution product as the narrowest functionality required to facilitate the actual payment for an in-app purchase of digital content, and that anything else was either part of the distribution service or omitted from his analysis.

1886    Professor Wright’s separate identification of iOS in-app payment solutions as a distinct product rested on an assumption that Apple facilitates in-app purchases of digital content only insofar as it provides the payment solution. His assumption was that it is the app developer that is delivering the content to the end-user. Apple says that that assumption is incorrect.

1887    In fact, in respect not only of app downloads and updates, but also in respect of in-app purchases, Apple provides access to the iOS operating system, a range of proprietary technologies and tools such as SDKs and APIs which developers use to develop and test digital content for in-app purchase, App Store review of digital in-app content, discovery services for digital in-app content, and security and related services.

1888    Moreover, Apple says that these services, including the use of SDKs and APIs to develop and test new in-app content, App Store review of new in-app content, and discovery services for such content, continue to be provided in relation to in-app purchases after the app to which they relate has been distributed and without any need for the app to be updated.

1889    Apple says that Professor Wright accepted that he did not precisely know what Apple was doing versus what the app developer was doing in relation to effecting digital in-app purchases.

1890    Further, Apple says that he later accepted that Apple’s proprietary technologies for testing and developing in-app content, app review for digital in-app content, marketing and discovery services, and security and related services contribute to the value of in-app purchases and fall outside of his iOS in-app payment solutions market. Those services he subsequently claimed to include in his distribution service.

1891    Further, Apple says that Professor Wright did not have a technical understanding of how this distinction might be drawn, saying that if there were some minor technical aspects that the hypothetical monopolist needs to allow the app developer to unlock, or access the API, then that would be included within his distribution service. And he accepted that, on his analysis, there is not a bright-line distinction.

1892    Apple says that this vagueness about the product definition arises because the product definition does not reflect the commercial reality of the product that Apple and other platforms supply, which is app transactions, facilitated by an integrated package of services including in-app payment solutions.

1893    Now Apple says that Professor Wright’s analysis of a separate iOS payment solution for in-app purchases proceeded on the assumption that the payment solution is the technology that has been used to facilitate in-app purchases and that the other features of Apple’s IAP are separate from the payment solution and missing from the analysis or part of distribution. And it is said that he referred to IAP as primarily the payment solution because that was his focus.

1894    But Apple says that that evidence revealed that Professor Wright’s product definition was driven by his focus rather than a real-world, practical appreciation of IAP.

1895    Apple says that the commercial reality is that it does not provide a payment solution in the narrow sense of Professor Wright’s a priori focus.

1896    Apple provides IAP, which is much more than payment facilitation, and even then does so as part of its supply of a wide range of services that facilitate not only in-app purchases but all app transactions.

1897    Apple says that Epic's proposed iOS in-app payment solutions market depends on the supply of iOS in-app payment solutions being a separate service from that of facilitating app transactions. It is not. It is an integral part of that service.

1898    Apple says that it does not provide a discrete payment solutions service, and it does not purport to operate in a market that involves competition against providers of payment solutions services. Payment processing is just one aspect of the broad suite of services comprising the IAP system.

1899    IAP is functionally integrated into iOS, the App Store and Apple’s “commerce engine”. It is economically problematic to suggest that the App Store or IAP is in competition with payment processors or to compare their commissions.

1900    Apple says that although the feature of payment processing is technically capable of being separated and treated as a separate component part of a transaction, that is not evidence that there is a standalone market for iOS in-app payment solutions.

1901    And Apple says that it is irrelevant that in particular jurisdictions it has been legally compelled to disaggregate a part of the broader service that Apple ordinarily offers. That has resulted in a sub-class of developers, and their users, who no longer receive the same kind of services associated with access to IAP and the Apple commerce engine, from any source.

1902    Apple says that where third-party payment processing is available to developers, the evidence establishes that there is almost no take up of third-party payment processing under reasonable pricing conditions.

1903    Apple says that it is commercially unrealistic to separately identify the payment solution as a distinct product dimension when, in commercial fact, the App Store utilises an integrated service involving a payment solution to provide the benefits of integration which cannot be provided otherwise.

1904    It says that Professor Wright’s separate identification of iOS in-app payment solutions as a distinct product involves the further economic contortion of separately identifying a one-sided service to developers, even though the App Store is a two-sided platform and even though, in every other respect, the App Store is properly characterised in an economic sense as providing services jointly to developers and users.

1905    Distinguishing payment solutions in this way from discovery, review, security and other services was based on an unconvincing assertion that the payment solution, unlike other components of Apple’s product, is clearly offered by Apple to the developer.

1906    Apple says that the economic contortion is even more apparent in Professor Wright’s iOS app distribution market, in which he located the payment solution for app downloads. Professor Wright described this as a one-sided service to the app developer as part of an overall two-sided service, which is the whole distribution service to app users and app developers.

1907    Apple says that a commercially realistic view of the App Store does not involve these artificial distinctions.

1908    There is indeed an overall two-sided service to app users and app developers of which payment solutions is a component along with all the other services that Apple provides to facilitate app transactions.

1909    It is artificial to include the payment solution for app downloads in the overall service and to hive-off the payment solution for in-app purchases.

1910    Let me deal with another dimension in this context being whether the payment solution for physical goods and services falsifies or points against the integrated product definition. Epic says that it is a point against such a definition, but Apple disagrees.

1911    Apple says that it does not facilitate transactions for physical goods or services to the same degree or in the same way as in relation to transactions for digital content. That is the reason why IAP is not available for physical goods and services.

1912    That does not point to payment solutions being a distinct and severable product. As a matter of economic characterisation, it simply reflects that there are some app transactions for which the full suite of Apple’s facilitative services is not and cannot be deployed. That is not to deny that the product Apple supplies is a full suite of services to facilitate app transactions.

1913    Apple says that Professor Wright accepted that it is more economically efficient to integrate the in-app payment solutions for digital goods than for non-digital goods.

1914    The platform effects of requiring non-integrated payment solutions for non-digital goods cannot be equated with the platform effects of permitting non-integrated payment solutions for digital goods.

1915    Because of the technical control that Apple has over digital content and delivery, it has a level of security, assurance and integrity to protect from adverse platform effects. For non-digital goods, Apple does not have that level of control or involvement to begin with.

1916    Further, on this topic, Apple says that the evidence establishes an absence of distinct demand for in-app payment solutions. I have dealt with this question in a separate part of my reasons. It suffices to say here that I have rejected this submission.

1917    Further, Apple says that a further difficulty with Professor Wright’s separate iOS payment solution for in-app purchases product is that splitting the transactions which the App Store monetises, being downloads and in-app purchases, into separate markets fails to take into account the constraints that each place on the other.

1918    A developer can respond to a commission increase by changing its monetisation strategy. In fact, developers have over time shifted from monetising downloads to monetising in-app purchases. The fact that this shift has occurred even in the absence of any difference in commission rates for paid downloads and in-app purchases makes it plain that substitution between those types of transactions could and would occur in response to a such a difference.

1919    Professor Wright did not accept that the developer’s optionality as to monetisation represented true substitutability. His evidence was that the ability to make in-app purchases is conditional on the app first having been downloaded, so that the download cannot be avoided by recourse to in-app purchases.

1920    Apple says that that reasoning does not reflect the reality that a profit-maximising app store is motivated to ensure that paid transactions occur on its platform. That motivation might lead an app store to care about free, being zero-price, transactions, to the extent that network effects will attract and retain paid transactions. To that extent, the desire to retain free transactions will act as an additional constraint on the app store. But the motivation to attract and retain paid transactions means that a developer’s options for monetisation are necessarily the primary constraint on a profit-maximising app store.

1921    Apple says that it is particularly significant in this respect that in-app purchases make up some 98% of App Store billings. A developer can choose to monetise in a way that avoids payment of commission to Apple, for example, by monetising in-app purchases which can be transacted outside of the App Store.

1922    Now there seemed to be a suggestion in Professor Wright’s evidence that if Apple had market power in a distribution market, then monetisation options would not constrain Apple, because Apple could always extract value at the point of the download. But Apple says that that assertion is not based in any evidence, or commercial reality, and is not obviously true given the strong network effects that have led to overwhelmingly free downloads.

1923    Apple says that to define a market by reference to the theoretical possibility that Apple might remove the ability of developers to substitute between paid downloads and in-app purchases is at odds with commercial reality given that Apple has allowed developers to choose between those and other forms of monetisation without deviation since the introduction of in-app purchases in 2009.

1924    It also overlooks the fact that the existing monetisation options plainly reflect Apple’s preferred method of monetising the App Store and that most app stores provide developers with the same monetisation options.

1925    Let me deal with one final matter concerning services provided by Apple to facilitate in-app transactions.

1926    An issue that assumed some prominence in the context of the economic evidence was the connection between the services provided by Apple to facilitate app downloads and the services provided by Apple to facilitate the provision of in-app content.

1927    Apple says that it is artificial to treat the provision of in-app content to a user as a separate transaction between the developer and the user that occurs independently of Apple and the App Store.

1928    In a variety of ways, Apple says that it facilitates and remains involved in the provision of in-app content to iOS users.

1929    First, in-app content is developed and operates through the developer’s use of Apple’s tools and technologies, including iOS itself and the various SDKs and APIs provided by Apple. Apple provides developers with access to a suite of tools that enable the creation of in-app digital content that operates on iOS.

1930    Second, Apple’s app review process includes review of in-app content. That is an ongoing process.

1931    Third, Apple promotes both apps and in-app content to users.

1932    Fourth, the delivery of in-app content depends on the operation of Apple’s IAP system and the use of Apple’s tools and technology, which is also facilitated through the DPLA.

1933    Fifth, Apple assumes responsibility for dealing with users in respect of issues and concerns about the delivery of in-app content, including refund requests.

1934    More generally, Apple says that there is no relevant temporal distinction between the relationship between Apple and the developer that facilitates app downloads, and the relationship between Apple and the developer that facilitates the provision of in-app content.

1935    The process of review of apps and of in-app content is ongoing. The technical facilitation is continuous. The promotional activities of Apple are continuous. Apple’s responsibility for the delivery and performance of in-app content is continuous.

1936    So, Apple says that there is an ongoing relationship that spans the availability of an app for download, the provision of in-app content for the app and beyond. So, for example, Apple will promote in-app content for an app that has already been downloaded and thereby encourage the further transaction involving the provision of in-app content.

1937    Apple says that these points are illustrated by considering the example of Fortnite, which has delivered significant economic returns to Epic through the monetisation of in-app content, provided on a continuous basis and regularly updated.

Analysis

1938    Now as Epic points out, clearly Apple does not produce or supply app transactions as such. Any such transaction is something engaged in by and between a developer and a user.

1939    As Epic points out, to reflect the commercial reality, the focal product must reflect the services Apple is obliged to provide under its contracts with developers and market definition that is not consistent with the relevant contract under which the services are provided is not commercially realistic.

1940    As clause 7 of the DPLA provides, if selected by Apple, an app may be “distributed … through the App Store”. If a developer wishes to avail itself of this service, to have its app delivered to users via the App Store, it must appoint Apple as its agent.

1941    The obligations Apple assumes if it is appointed as a developer’s agent are enumerated in schedule 1 in respect of free apps or in schedule 2 in respect of paid download apps or apps with in-app purchases of digital content.

1942    Clause 1.1 of schedule 2 provides that a developer appoints Apple as its agent for the marketing and delivery of the developer’s app to users, and that Apple will make the app available for download by users through the App Store for and on behalf of the developer.

1943    In furtherance of the appointment of Apple as a developer’s agent, Apple is authorised and instructed to do various things, including to market, solicit and obtain orders on the developer’s behalf for the developer’s app, to provide hosting services to allow users to access the developer’s app, to make copies of, format, and otherwise prepare the app for acquisition and download by users and to allow users to access and re-access copies of the app.

1944    These services are clearly encompassed by the concept of app distribution services.

1945    And as pointed out by Epic, it is in consideration for Apple’s provision of these services, as agent for the developer, that Apple is entitled to its commission.

1946    Further, it is not seriously in issue that Apple is not involved in making the purported transactions. Apple supplies services to enable the search for, discovery, download, and update of iOS apps. When an app is downloaded and paid for, when it is later updated, and when in-app digital content is purchased and used, the transactions are between the developer and the user. Apple’s DPLA makes that clear.

1947    And as I have already said, the services for which Apple is remunerated through its commission are those app distribution services.

1948    I agree with Epic that it is detached from commercial reality to adopt a market definition exercise that commences with the elusive concept of “app transactions” as the focal product, instead of the services that Apple provides to facilitate the distribution of apps and for which Apple earns its commission.

1949    Now, as Epic points out, the conclusion that Apple provides distribution services to iOS app developers and iOS users is also apparent from the way in which Apple describes its operations. There is no mention within Apple’s internal documents of the App Store supplying app transactions. Rather, the documents are replete with descriptions of services properly characterised as distribution services.

1950    And I agree with Epic that from the earliest days of the App Store, contemporaneous documents tell a consistent and more realistic story. Mr Jobs described the App Store at the launch of Apple’s SDK on 6 March 2008 in this way:

… So you are a developer and you’ve just spent two weeks or maybe a little bit longer writing this amazing app and what is your dream? Your dream is to get it in front of every iPhone user and hopefully they love it and buy it, right? That’s not possible today. … Well, we are going to solve that problem for every developer, big to small, and the way we are going to do it is what we call the “App Store”. This is an application we’ve written to deliver apps to the iPhone … And so our developers are going to be able to reach every iPhone user through the App Store. This is the way we are going to distribute apps to the iPhone.

1951    Mr Jobs went on to explain how Apple proposed to curate the App Store, and make it easy for users to discover and install iOS apps:

So let’s take a look inside the App Store … We’ve got Categories here if you want to find a game, if you want to find a business application, you want to find an application about finance, as an example. Easy to find stuff and browse the different categories. Of course, we’ve got our top downloads, top 50 in this case, where I can see what the most popular apps are being downloaded. And, if I know what I want, I can easily search for something, in this case a Backgammon game, and instantly find it. I can tap on it, get some screen shots and get a write-up on it. And if I’m interested in using it, this one happens to be free, I just tap up there and I tap the “install” button and the app is wirelessly downloaded to the iPhone using the cell network or Wi-Fi. It’s that simple to put the app right on the phone.

1952    As is apparent, these statements emphasise that the services provided by Apple are in the nature of search, discovery and facilitation of distribution.

1953    Further, Mr Schiller said that an important function of the App Store is to deliver apps to iOS devices and the goal of the App Store is to allow third-party distribution. And Mr Federighi also explained that Apple opened the App Store in 2008 to distribute native apps from third-party developers to iPhone users and that Apple uses a centralised distribution model to distribute native apps through the App Store.

1954    More recently, in its Form GD notification to the European Commission dated 3 July 2023, Apple explained that its “App Stores have each been designed to distribute apps to a specific OS and device”, “[t]he App Stores are distribution channels to reach end users, some of which may be considered as (much) more significant gateways than others. … each Apple App Store serves as a gateway to reach a distinct group of end users” and that the “iOS App Store plays a significant role in the distribution of apps to end users”.

1955    I agree with Epic that it is apparent that the contractual framework, and Apple’s conception of its economic activity, confirm that the relevant product which it provides is services for the distribution of iOS apps.

1956    Now Apple says that it and its experts have always said that the relevant product is services for facilitating transactions, but this assertion is problematic for the reasons given by Epic.

1957    First, the relevant references served up by Apple do not meet the descriptions given to them by Apple.

1958    Second, Professor Hitt and Mr Houston each distinguished between services for facilitating app transactions and the transactions themselves, the latter of which they said were the relevant product.

1959    Third, to the extent that Professor Hitt and Mr Houston conducted an analysis of substitution possibilities, they did so by reference to transactions and, more particularly, purchases of digital content, and not the services for facilitating transactions.

1960    Fourth, their key reasoning, including their concentration on digital content purchases on other platforms, proceeded on the footing that the relevant product was “app transactions” and the relevant market was for “app transactions”.

1961    Generally, I agree with Epic that Apple’s approach is not consistent with a proper competition assessment or a suitable market definition exercise.

1962    The conduct at the heart of Epic’s claim is Apple’s prevention of other avenues of distribution of iOS apps, which requires examination of how iOS apps can be distributed to iOS device users, and from whom the services for facilitating that distribution can be acquired. And to exclude key elements of the services provided by Apple through the App Store to facilitate that distribution would frustrate an analysis of the competitive effects of that conduct. It would not permit an inquiry as to the effects of the conduct on the ability for there to be competition from new app stores across multiple dimensions, including in relation to curation, search and discovery.

1963    Consequently, I agree with Epic that app transactions is not the correct lens through which to assess current, or counterfactual, competitive conditions.

1964    Instead, Apple’s conduct involves the supply of all of the services it provides to developers as agent pursuant to the DPLA. These services, and the impugned conduct, affect all apps distributed through the App Store. The product dimension must accurately account for the full bundle of agency services that Apple provides under the DPLA to enable a proper inquiry as to the effects of Apple’s conduct.

1965    Further, Apple’s attempt to combine in-app purchases with app downloads and updates into one relevant product is problematic. Downloads and updates of iOS apps cannot be substituted for comparable services on non-iOS channels without changing device. iOS app users who choose to purchase digital content on other channels to use in an iOS version of an app must still use Apple’s distribution services to download and update the app.

1966    Apple’s attempt to combine downloads, updates and in-app purchases as if they were a single product supplied by Apple diverts attention from the question of whether Apple has market power arising from its control of app distribution services for iOS devices.

1967    I agree with Epic that the product definition proposed by Apple does not allow me to test whether Apple’s actual supply of distribution services is constrained by the prospect of users acquiring substitutable distribution services elsewhere, or even by reason of the fact that Apple has since 2018 allowed digital content purchased by a user on other non-iOS channels to be used within the user’s iOS apps.

1968    Contrastingly, the separate consideration of services for distribution and services for in-app payment solutions permits a proper assessment of whether Apple has market power, and whether its conduct affects competition, in respect of each of those sets of services.

1969    Further, I reject the suggestion that the appropriate competition assessment requires consideration of a conglomeration of services because Apple’s provision of distribution services is constrained by the threat of users making purchases of digital content elsewhere. As Epic points out, any such threat exists only because of Apple’s present monetisation strategy, namely, the collection of revenue in respect of its distribution services by means of commissions on paid app downloads, in-app subscriptions and other in-app purchases of digital content.

1970    Moreover, that state of affairs does not suggest that Apple’s distribution services are the subject of any constraint from out-of-app purchases, and in fact suggests a lack of constraint. Further and indeed, Apple could, in its absolute discretion under the DPLA, revert to a position where it banned the use of content purchased elsewhere.

1971    More generally, Apple is the sole supplier of iOS app distribution services. And if it wanted to, it could at any time change the way in which it monetises all or any of its services. It could charge fees to all apps, regardless of monetisation scheme, for listing on the App Store. It could increase the charges it already levies for discovery through ads in the App Store or for preferential featuring within search results. And it could charge developers a percentage of revenue derived from in-app advertising. Indeed, it could adopt any number of other monetisation schemes that do not involve app transactions.

1972    And as Epic points out, the ability to monetise in other ways highlights the need to consider the constraints facing Apple and the competitive effects of its conduct through the lens of the services it supplies, in distributing apps and separately in providing a payment service to facilitate certain in-app purchases.

1973    Ultimately, the relevant question is what if any close substitutes exist for Apple’s iOS app distribution services, and separately for Apple’s payment service.

1974    In my view, a proper assessment of the current state of competition, and of the effect of Apple’s conduct, requires me to consider the services that Apple supplies to facilitate app distribution, and to do so separately from Apple’s provision of its payment service in connection with in-app purchases of digital content.

1975    Now Apple seeks to criticise the separate treatment of in-app payment solution services on the basis that, in reality, Apple supplies a single integrated service. But I do not accept this position.

1976    First, even assuming that Apple supplies various services as a package, the relevant question for the purpose of determining whether there is a tie is whether there is distinct demand for the different component services. There is.

1977    Second, as a matter of fact, Apple’s services are not as integrated as Apple has put.

1978    Third, bearing in mind the purposive approach to market definition, it is preferable to consider the services distinctly, as it enables a more accurate consideration of the competitive conditions in the factual and counterfactual.

1979    Now Apple says that Epic’s pleading about payment services is exceptionally narrow.

1980    But the pleaded concept of services enabling or facilitating the acceptance or processing of payments is a wide one. Apple itself says that it provides a wide range of services in facilitating in-app purchases. Neither Epic’s nor Apple’s conception of facilitation excludes the provision of a range of features that affect the quality or utility of the payment services.

1981    Furthermore, Epic’s case about payment services does not involve deconstructing important elements of Apple’s ecosystem. On Apple’s own evidence, its distribution of apps for physical purchases where it mandates alternative payment systems does not have the effect of deconstructing its ecosystem. Nor do the various exceptions that Apple allows where alternative payment systems can be used have that effect.

1982    Let me now address in more detail Apple’s focus on monetisation for the purposes of market definition.

1983    Now Professor Hitt and Mr Houston sought to justify their focus on “app transactions” on two bases. First, they said that Apple is compensated for the services it provides in facilitating transactions on the App Store almost entirely through the commission earned from paid downloads and in-app purchases. Second, they said that app stores receive revenue when app transactions take place, meaning that a separate competition assessment of services beyond the transaction is not warranted.

1984    But I agree with Epic that this focus on Apple’s commission ignores important ways in which the App Store benefits Apple. Specifically, it ignores the way in which Apple monetises its search and discovery services through its search ads. And it overlooks that the provision of distribution services to as many developers and users as possible generates significant benefits for Apple beyond its commission, as discussed below.

1985    The App Store is a two-sided platform which exhibits indirect network effects. A mutually reinforcing feedback loop is created, whereby app users derive value from being able to access more apps, and app developers derive value from being able to distribute their apps to more users.

1986    This feedback loop is based primarily on user and developer engagement with, and use of, the App Store, rather than transactions only.

1987    As Epic points out, the commercial importance of App Store usage to Apple stems from the fact that the more users engage with the App Store, the more likely it is that Apple will generate revenue. Examples of the ways in which Apple benefits from distributing all apps no matter how they are monetised on the App Store are as follows.

1988    First, there is greater revenue from search advertisements on the App Store. Apple earns revenue from developers who pay to place an advertisement that shows up at the top of a search result if their app is appropriately related to a user’s search.

1989    Second, there is greater usage of monetised apps. Many users desire both monetised apps and non-monetised apps. The more users engage with the App Store to acquire non-monetised apps, the more likely they are to engage with monetised apps as well.

1990    Third, there is an increased audience for Apple’s own apps distributed through the App Store.

1991    Fourth, there are greater payments from Google pursuant to arrangements that require Apple to make Google Search the default search engine in certain iOS apps.

1992    Fifth, there is greater revenue from the annual membership fee that Apple charges developers. Increased App Store usage by users attracts more developers which then leads Apple to collect more in membership fees.

1993    Sixth, Mr Schiller gave evidence that Apple distributes apps even where it does not receive a commission in exchange for doing so, because it confers a commercial benefit to Apple. Apple does not charge any commission for free apps, but nonetheless gains a commercial benefit through making its hardware, software and services more attractive to consumers. Moreover, Apple benefits from the multi-platform rule under which Apple does not receive any commission from eligible apps. Specifically, as I have discussed elsewhere, the rule allows an iOS user to bring content onto their iOS app, which promotes greater use of the iOS app and delivers a series of indirect benefits to Apple.

1994    And clearly Apple benefits from the multi-platform rule through network effects.

1995    I agree with Epic that the focus of Apple and its expert witnesses on its commission is untenable because it would create an implausible outcome. If Apple were to change its monetisation strategy, such as by charging for App Store listings or charging more for advertising, instead of levying a commission on in-app purchases, the relevant product would also have to change despite the App Store still supplying the same distribution services.

1996    It is problematic for Apple to focus on monetisation. Apple does not charge a commission for the majority of app transactions such as free apps or apps offering in-app purchases of physical goods and app updates. And most users do not undertake paid app transactions. The majority of app developers do not monetise via in-app purchases of digital content.

1997    So, as Epic points out, the focus on monetisation misses a substantial portion of the relevant interactions, which therefore risks an erroneous assessment of competitive conditions. As Professor Wright explained, there are many aspects of distribution services that Apple could monetise at any time that it wanted.

1998    Let me say something more about the question of in-app purchases.

1999    Now as I have discussed in detail elsewhere, in-app payment solutions services are a separate product from distribution services and should be treated as such. In short, payment solution services can be, and are, supplied separately from distribution services, and there is distinct demand for those services.

2000    Now given the assertions by Apple to the effect that in-app purchases are part of the same relevant product as downloads and updates, there are further reasons why it is inappropriate to treat the payment service that Apple supplies to facilitate in-app purchases of digital content as part of the same product as app downloads and updates.

2001    First, Apple plays a different role in respect of in-app purchases. Whereas Apple takes responsibility for hosting, marketing and delivering all apps to users as agent for developers, it plays no role in effecting in-app purchases if one leaves aside its payment service.

2002    Second, Apple refuses to play any role in relation to in-app purchases of physical goods or services.

2003    Third, clause 3.1 of the schedule 2 agreement provides that developers, rather than Apple, are responsible for hosting and delivering content or services sold by the developer using IAP, that is, in-app purchases of digital content. This is in contrast with Apple’s role in respect of app downloads.

2004    This difference alone suggests that it is a mistake to treat in-app purchases as part of the same product supplied by Apple as app distribution services.

2005    Fourth, the inclusion of in-app purchases of digital content within the product description is at odds with the exclusion of in-app purchases of physical goods or services. The substantive difference between the two is that Apple compels the use of IAP for the former but prohibits it for the latter. This is a choice about Apple’s monetisation strategy.

2006    Now the suggestion put to Professor Wright in cross-examination, and said to be supported by evidence referred to in an aide memoire handed to me at trial, that Apple is involved in in-app purchases through the app review process is a distraction.

2007    All that evidence shows is that Apple reserves the right to review additional content that a developer wishes to add to the functionality of its app in a way that will work with Apple’s in-app purchase API when a later purchase transaction arises. That is, in substance, the same as Apple’s role in reviewing app updates.

2008    Importantly, it is a step that precedes, and is disconnected from, any actual in-app purchase by a user.

2009    Apple’s involvement in any subsequent purchase that a user might initiate is limited to the compelled use of IAP.

2010    Apple’s present strategy of monetising app distribution services through commissions on certain in-app purchases should not drive the selection of the relevant product. Moreover, Apple’s conception of app transactions as comprising app downloads, app updates, and in-app purchases is problematic because in-app purchases are a fundamentally different type of transaction when compared to downloads and updates.

2011    Generally, I do not consider in-app purchases initiated by a user as part of the same market in order to consider the true economic constraints on Apple.

2012    First, a monopolist supplier of services for downloading and updating of iOS apps could only be constrained by behaviour that produces a reduction in demand for the services it supplies, that is, services for downloading and updating iOS apps.

2013    That will not occur if iOS device users continue to use iOS apps. Demand for those services, as well as the other elements of the service supplied by Apple, will not be diminished simply by users being able to purchase digital content outside an iOS app for use within the app.

2014    Second, a demonstration of the separateness of app downloads and app updates on the one hand, and Apple’s provision of its payment service when a user makes in-app purchases on the other, can be found in Apple’s own conduct both in the early days of the App Store and today in various parts of the world, where it has been required by regulation to permit developers to acquire payment solution services from third-party providers.

2015    Let me now say something as to the relevance of IAP being integrated.

2016    Now Apple said that Professor Wright conceived of the payment solutions product as the narrowest functionality required to facilitate payment. But Professor Wright’s evidence was that he considered that payment solutions provide additional services, such as tracking payment and analytics.

2017    Further, Apple has said that the separate identification of iOS in-app payment solutions as a distinct product rests on an erroneous assumption that the developer, and not Apple, delivers the in-app digital content to the user. But the assertion that it plays a role in delivery of in-app digital content to users cannot be maintained, for the following reasons.

2018    First, Apple’s own agreements provide that the developer is responsible for hosting and delivering in-app content sold using IAP. Now although Apple may in some circumstances facilitate the delivery, many developers do not involve Apple in the actual delivery portion of the in-app content. The developer delivers the purchased content.

2019    Second, none of the matters that Apple lists as evidence that it facilitates in-app purchases of digital content, such as providing access to iOS and to a range of proprietary technologies which developers use to develop and test digital content for in-app purchase, are involved in the process for app downloads and updates. They are related to the ancillary step of development and testing.

2020    Third, in any event, those matters do not make Apple part of the transaction in which a user purchases and a developer delivers in-app digital content. That transaction takes place through the use of Apple’s IAP functionality. They are part of the distribution services that Apple provides before the user gets to the in-app purchase stage that enables the unlocking of the content from the developer.

2021    Further, the nature of the service supplied by Apple is necessarily a question of fact, about which none of the experts was able to give direct evidence. So, I do not accept Apple’s assertion that an integrated payment solution enables the provision of benefits that cannot otherwise be provided.

2022    Now Apple says that because it forces developers to use IAP for the in-app purchase of digital content, it offers an integrated service involving a payment solution that is a different product to an unintegrated payment solution.

2023    But third-party payment solutions offer a wide variety of features, many of which are equivalent to those offered by IAP such as data analytics, and some of which IAP does not offer such as refund management and the ability to have a direct relationship with customers. And as Epic says, this is an example of product differentiation, which is a normal feature of many markets that benefits developers who have varied needs and for whom Apple’s one-size-fits-all approach is unsatisfactory.

2024    But in any event, Apple does not explain how the existence of any such integrated benefits makes it commercially unrealistic to identify payment solutions as a distinct product. Indeed, it is in tension with its own position where Apple itself has made the commercial choice not to supply IAP, or to allow developers to use an alternative to IAP, in a range of app transactions on the App Store, including in-app purchases of physical goods or services, such as Uber, Airbnb and Booking.com, and for the benefit of participants in its video partner program.

2025    I agree with Epic that there is nothing inconsistent about the existence of two separate but tied product markets.

2026    Further, in support of its contention that payment solutions for in-app purchases are part of an integrated service, Apple relies on the alleged need for a platform operator to deny developers the choice that they would otherwise exercise to acquire those services separately.

2027    But the evidence on which Apple relies does not bear on the question of whether it is appropriate to treat the services separately. But in any event, I am not satisfied that there are any platform benefits that would be significantly undermined by developers having the ability to use alternative payment solutions.

2028    Further, I reject the suggestion that a third-party payment solution would make the App Store significantly vulnerable to security breaches. I have addressed this in detail elsewhere.

2029    Moreover, Apple’s own commercial choice to mandate the use of third-party payment solutions for purchases of physical goods and services suggests that it does not consider such payment solutions to pose a material risk to the App Store. As Epic points out, Apple does not impose any additional security or data privacy requirements in respect of those alternative payment solutions.

2030    In my view there is no significant additional security risk associated with the use of alternative payment solutions for in-app purchases of digital goods and services that does not already exist in the case of in-app purchases of physical goods and services.

2031    Generally, I agree with Epic that a proper competition assessment is better able to be carried out if I consider the services for distribution of iOS apps separately from services for facilitating payments for in-app purchases.

2032    So, in my view, Epic’s identification of the relevant focal product is correct.

Application of the HMT

2033    Now as I have indicated elsewhere, the HMT starts by identifying the focal product and then considers if a hypothetical monopolist of that product could profitably impose a small but significant and non-transitory increase in price (SSNIP). If the answer is yes, that product forms a relevant market for competition analysis, because there are no other products that are sufficiently close substitutes. If a SSNIP would not be profitable, because customers would switch to other products, the market scope is expanded to include those products and the question is asked again. The process is repeated until a relevant market for competition analysis is identified.

2034    So, the HMT searches for the close competitive constraints on the focal product. If the SSNIP is profitable, all the close competitive constraints are under the power of the hypothetical monopolist. If the SSNIP is not profitable, the hypothetical monopolist is disciplined by competitive forces and the market definition needs to be expanded to capture those constraints.

2035    Now with sufficient and probative data, the HMT can be performed wholly or substantially quantitatively. But it is more often used as a guiding structure, with various qualitative and quantitative analyses being used to perform the thought experiment. Professor Wright took such a hybrid approach.

2036    Now the HMT’s application is more complex when the service is provided through a platform connecting two distinct user groups. So, it is necessary to take into account the presence of network effects, sometimes referred to as feedback effects. In this case, iOS developers and iOS users are connected by Apple’s role as an intermediary in operating the App Store. It is important to account for two matters.

2037    The first matter is any feedback loop(s) that may arise in response to the SSNIP. That is, one needs to consider not only the direct response to the SSNIP but also how that response may create feedback loops between the distinct user groups participating on the platform.

2038    The second matter concerns differences in the substitution options available to each of the distinct user groups. Substantial differences may justify defining separate markets for each user group.

2039    Further, the cellophane fallacy, which I have introduced earlier in my reasons, creates the need for caution in considering evidence of substitution to assess the relevant market. Conceptually, the relevant market should be assessed by considering likely switching in response to a SSNIP applied to the competitive price level.

2040    But there may not be direct evidence on such switching if prevailing prices are already substantially above the likely competitive level, reflecting that the firm in question already has market power. If so, the relevant market may need to be defined by reference to a range of indirect evidence.

2041    Now one type of indirect evidence is evidence from similar markets in other jurisdictions or settings which are more competitive or in which there have been changes in the prices of similar products. Such evidence may provide information on the competitive price level and/or the likely share of customers that would switch between products when there are changes in the relative levels of the prices of those products.

2042    Another type of evidence is the extent of switching at prevailing price levels.

2043    So, if few customers switch away from the firm’s product in response to an increase in its price, then it is likely that switching would be even more limited if the firm was setting prices below the prevailing price level, but still above the competitive level, given that customer willingness to switch away from a product is likely to increase the higher the price of that product relative to the price of potential alternatives. Similarly, if a small price reduction causes little increase in the sales of the product at the expense of sales of other products, then it is unlikely that the product has close substitutes. Alternatively, if a small price reduction, relative to the price of alternative products, causes a large increase in sales of the product as a result of switching from other products then it is more likely that the product is supplied in a broader market containing the other products.

2044    Now before proceeding further, let me summarise the views of Professor Wright before descending into the detail. I have found Professor Wright’s views to be more persuasive than the views of Professor Hitt or Mr Houston.

2045    Professor Wright assessed whether a hypothetical monopolist for the supply of iOS app distribution services in Australia would likely find it profitable to sustain a SSNIP above the competitive level or whether there exist close substitutes for the supply of such services. He concluded that the hypothetical monopolist would likely find it profitable to sustain a SSNIP above the competitive level and therefore he identified a relevant market limited to iOS app distribution.

2046    He showed that a SSNIP applied to any commission level at or below the current level charged by Apple is likely to be profitable. The profitability of such a SSNIP arises from the likely limited extent of switching to alternatives by app developers and app users in response to an increase in Apple’s commissions. This is evidence of the iOS app distribution market being a relevant market.

2047    He examined evidence of commission rates of app stores on other operating systems where there are multiple app stores. He found that Apple’s current commission rate is generally already far more than 5 to 10% higher than the effective commission rate of these other app stores.

2048    He considered this to be further direct evidence that a SSNIP above the competitive price level would be profitable for Apple, that is, the monopolist supplier of distribution services for iOS apps, and hence of the iOS app distribution market being a relevant market.

2049    But contrastingly, Professor Hitt and Mr Houston said that Professor Wright’s two approaches to conducting an HMT were deficient and failed to address any relevant questions. They said that his analysis suffered from circular reasoning and biased interpretations of available evidence. They said that Professor Wright’s application of the HMT framework was unreliable and had a fundamental deficiency.

2050    But Professor Wright said that the HMT provided a useful conceptual framework to determine whether different types of products should be part of the relevant market.

2051    First, Professor Wright’s application of the HMT did not assume that Apple is a monopolist. He started his analysis with a candidate market for the supply of services for the distribution of iOS apps. He explained that Apple is the monopolist supplier in this candidate market. He found that a SSNIP applied to Apple’s current commission rates would be profitable based on evidence of a lack of actual substitution. He acknowledged that this finding implies that Apple sets its current commission rates below the level that would maximise its profit and he provided observations consistent with this. He concluded that there is a relevant market for iOS app distribution.

2052    Importantly, his application of the HMT framework could have resulted in Apple not being a monopolist, for example, that the App Store is in the same market as other app stores that provide distribution services for apps for use on different operating systems. He could have concluded so if the evidence had been consistent with a sufficient degree of actual substitution to these alternative app stores rendering a SSNIP unprofitable and necessitating the expansion of the candidate market in the HMT framework to include these other app stores.

2053    Second, Professor Wright’s application of the HMT framework considered all avenues of substitution for app distribution services and the extent of indirect constraints, not involving the supply of app distribution services, including all those identified by Professor Hitt and Mr Houston. He identified all potential substitutes available to both app developers and app users as well as potential indirect constraints, including all those identified by Professor Hitt and Mr Houston, who often only focused on in-app purchases. He did not ignore any potential alternatives or constraints. Rather, he considered each one individually and in combination. He examined the relevant evidence and drew conclusions about the likelihood of actual substitution to alternatives for app distribution services. He also considered indirect constraints not involving the substitution of app distribution services, such as app users purchasing digital content in other channels with the intention of using that digital content in their iOS apps in response to a SSNIP.

2054    He concluded that the App Store has no close substitutes for app distribution services.

2055    Third, Professor Wright’s application of the HMT framework considered the relevant starting price, anchored in market reality.

2056    To determine the relevant market for assessing Apple’s conduct, he considered what Apple is currently effectively charging for app distribution services. Given Apple is tying app distribution services on iOS and in-app payment solutions on iOS, he estimated an effective price for app distribution services based on Apple’s commission on paid app downloads and an estimate of the proportion of Apple’s commission on in-app purchases which can be considered as payment for app distribution services.

2057    Now Professor Hitt and Mr Houston criticised Professor Wright’s allocation of Apple’s commissions between app distribution services and in-app payment solutions but failed to acknowledge that his findings were robust to any allocation of commissions. In other words, he would still have found that Apple is the monopolist supplier of app distribution services on iOS regardless of allocation.

2058    Further, Professor Wright’s approach was conservative as it allocated a fraction of the commissions charged on in-app purchases to app distribution services. If he had instead assumed that the only price for app distribution services is the commission on paid downloads, then he would have considered switching in response to a SSNIP, which is only applied to the commission on paid downloads, which would be a much more limited SSNIP given that most app developers’ revenue is generated through in-app purchases.

2059    The level of switching away from iOS by app developers and app users in response to this much more limited price increase would be expected to be less than the level of switching in response to a SSNIP applied to both paid downloads and in-app purchases, and so it is more likely that a limited SSNIP would be profitable for Apple.

2060    Fourth, Professor Wright’s application of the HMT framework considered the two-sided nature of the relevant platform, both by anchoring the price increase in commercial reality, and by accounting for indirect network effects. His application of the HMT framework considered a SSNIP applied to the price level, that is, the level of commission and reflected assumptions on the level of pass-through, accounting for possible variations in the incidence of price changes on app developers versus on app users. His application of the HMT framework also considered indirect network effects. He assessed the likely overall profitability of the SSNIP taking into account the likely responses of app developers and app users, and any feedback effects between them. He explained that because app users’ reactions to the SSNIP have no material impact on app developers’ decisions in relation to distributing their apps via the App Store, any potential subsequent rounds of feedback effects between app developers and app users would be insignificant.

2061    Fifth, Professor Wright’s application of the HMT framework started with the narrowest relevant set of products, that is, iOS app distribution services not further segmented by app genre.

2062    Professor Wright took the approach, with which I would agree, that the market definition exercise should be a focusing process to provide the clearest picture of the relevant competitive process in light of commercial reality. It should be tailored to the conduct at issue.

2063    As Professor Wright analysed the matter, and with which I would agree, in the present case Apple through the App Store provides essentially the same app distribution services irrespective of the app genre. Further, Apple’s conduct applies across all genres of apps, with only very limited special exemptions for some app genres or specific apps. Only developers of apps covered by the reader rule, which is limited to certain genres and requires Apple’s approval on an individual app basis, are permitted by Apple to stop allowing iOS in-app purchases whilst allowing purchases of digital content on other channels.

2064    Sixth, whilst the HMT is a standard and useful framework for market definition, information on the precise amount of switching which would take place in response to a SSNIP is often not available. So, as Professor Wright said, and with which I would agree, although the HMT may be used as an aid to arrive at the appropriate market definition, it need not be used. And its utility will depend on the extent to which it is based on adequate data.

2065    Professor Wright sought to apply the HMT by reference to the data he had been given. But he faced some data limitations in doing so, so he also based his assessment on a range of qualitative evidence demonstrating how the relevant markets and competition within them are working in practice.

2066    Further, Professor Wright considered that the comparison of Apple’s commission with competitive benchmarks was informative. He explained that Apple is profitably setting its commission significantly above the competitive benchmarks of the commissions set by app stores on other operating systems where there are multiple app stores. He said that the evidence is consistent with Apple finding it profitable to sustain a SSNIP above the competitive price, that is, above the competitive commission level. He said that the evidence suggested that the App Store is not subject to the same competitive constraints as the app stores which charge substantially lower commissions, and that the App Store is not competing closely with those other app stores.

2067    Professor Wright considered this to be direct evidence that a SSNIP above the competitive price level would be profitable for Apple, that is, the monopolist supplier of services for the distribution of iOS apps, and hence of the iOS app distribution market being a relevant market.

2068    But even if Professor Wright were to accept that the product was app transactions, that would not have altered his approach to the HMT framework, and he would still have found the existence of an iOS-only app transactions market.

2069    Let me now address Apple’s arguments in more detail.

Apple’s arguments

2070    Apple says that there are real difficulties adapting the HMT framework to two-sided transaction platforms. It says that there is a need to consider the effects on users on both sides and any sort of network effects or interactions between the two sides. It says that the framework should, in response to an increase in commissions charged to developers, allow for change that Apple might make on the app user side. It says that one needs to consider two prices or total price having regard to the two-sided platform.

2071    In the face of those difficulties, Apple says that Professor Wright’s HMT test is not reliable. It says that an HMT framework applied to a two-sided platform needs to consider indirect network effects, and it says that Professor Wright accepted that his SSNIP test did not allow for indirect network effects.

2072    Apple relied upon Professor Hitt’s summary of the key limitations, which limitations related to the substitution possibilities available to developers, the demonstrated ability for new entry, the ability for developers to enable switching by users, and limitations relating to the fact that these real-world facts are not sufficiently accounted for in the assumed elasticities of Professor Wright’s model.

2073    Further, Apple says that there was an inappropriate starting assumption that Apple is offering a price that is less than the optimal monopoly price but more than the competitive price.

2074    Further, Apple says that the substitution possibilities available to developers are particularly important.

2075    The SSNIP test assumes that developers react to a SSNIP only by passing through (0% to 100%) the increase to app users. The reliability of the quantitative analysis therefore depends on the robustness of the anterior analysis assessing the likelihoods of different developer responses.

2076    Those responses to a SSNIP likely include, for example, offering exclusive content on other platforms, developing new apps for other platforms first, delisting from the App Store and offering differential pricing.

2077    Apple says that these possibilities present developers with wide options and complicated choices which a single measure of elasticity does not capture.

2078    Apple says that Professor Wright’s model did not allow for any of those developer responses, or any of those complex choices. There is an absence of any allowance for elasticity of supply. The HMT assumed that developers will simply continue to supply regardless of the price increase, regardless of elasticity and regardless of pass-through. Apple says that this leads to bizarre consequences.

2079    So, the model assumed that developers would continue to supply even when it costs them money to process a transaction.

2080    Apple also says that Professor Wright in his analysis also produced a positive result for Apple when a 100% price increase so as to increase commission to 60% is applied. And whilst Professor Wright’s response that the model was not made to assess such a large increase could be accepted, the point was that by reason of the failure to allow for any developer response, his analysis results in a profit being generated on various alternative assumptions.

2081    Apple said that the same result can be achieved by adjusting elasticity instead of the SSNIP. Large adjustments can be made and Professor Wright’s model continues to project a profitable result for Apple.

2082    Apple says that this undermines the integrity of the model because the model predicts a profit in almost any conceivable scenario, and indeed in many that are not conceivable.

2083    Now Professor Wright accepted that an HMT test should commence with the narrowest candidate market, because an HMT can only reject a market for being too narrow. But Apple says that the iOS app distribution market is too broad in the sense that distribution services is too wide having regard to the different competitive conditions for games, video streaming and other categories of app.

2084    Professor Wright accepted that his SSNIP test would, arithmetically, show as profitable a price increase of some 100%.

2085    Now whilst Professor Wright explained that in that scenario the assumed elasticities would also need to be increased, Apple pointed out that Professor Hitt said that, nonetheless, in the model you can “crank up” the elasticity of demand substantially and still reach the same conclusion.

2086    Apple says that that also casts doubt on the reliability of the model. As Professor Hitt later summarised, the quantitative model was only possible because Professor Wright narrowed it down to an Apple-based market, and that once you do that “the numeric thing doesn’t add anything additional. … you’re just chasing consumer price elasticity”.

2087    In other words, Apple says that the numerical HMT test does not add anything to Professor Wright’s more qualitative opinions about likely responses to a SSNIP.

2088    Apple says that the unreliability of Professor Wright’s SSNIP analysis is also illustrated by the implication that Apple is a monopolist that has failed to set a profit-maximising price.

2089    Let me say something about the elasticities used by Professor Wright and Apple’s criticisms.

2090    Professor Wright placed reliance on internal Apple documents, which he considered supported a demand elasticity assumption of minus 1.

2091    But Apple says that those documents record Apple’s consideration of price tier changes, that is, to users, in response to economy-wide events, such as changes in tax and foreign exchange rates.

2092    Apple says that holding all else equal, such elasticities do not address a change in the price of iOS apps alone or of any individual iOS app.

2093    Apple says that the literature suggests, and Professor Wright agreed at least conceptually, that holding all else constant, elasticity of demand figures relating to price changes in response to economy-wide events will be lower than elasticity of demand figures relating to an increase in the price of iOS apps. As Professor Hitt explained, economy-wide price increases would be expected to affect all of the platforms.

2094    Further, as Professor Hitt said, Professor Wright’s elasticities were general price elasticities. They did not address cross-channel behaviour.

2095    Apple says that that is significant because if one has two goods that are essentially the same, available on multiple channels and used by the same users, that is, multiple channels or platforms on which the same users can and do purchase the same digital content, then if there were price differentials between those channels, users would have the ability to substitute to the lower price channels. Developers have invested a significant amount of resources in facilitating that.

2096    Consistently with that, Professor Hitt later gave the example of two stores next to each other with the same prices for identical goods, in which one store lowers its price. Professor Hitt said that the elasticity of demand in that case is likely to be very high and that Professor Wright’s elasticity figures do not address that type of scenario.

2097    As Professor Hitt said, the response to price changes in two different channels on an identical good would likely be significantly greater than the market-wide response if, for example, a developer decided to increase their price or even if all developers decided to increase their prices by a certain amount.

2098    Moreover, Apple says that the figures that Professor Wright has drawn from the documents are not always consistent with the documents themselves.

2099    The relevant documents indicated that elasticities had increased for some bigger titles. Professor Wright did not know how many apps would be in this category. He did not factor this in, treating the elasticities as average elasticities. But he accepted that the response of larger developers of larger apps would have a bigger effect, in terms of discipline, upon a SSNIP by the hypothetical monopolist. That tends to indicate that his use of an average elasticity in the SSNIP test understated the true elasticity relevant to a SSNIP. Professor Wright also said that he did not know exactly how Apple assessed the elasticities.

2100    So, Apple says that no weight can be placed on his assumption or inference that the recorded figures are relevant figures.

2101    Further, Apple says that the lack of observed pass-through in Professor Hitt’s natural experiments does not reliably imply a lack of substitution possibilities. And Professor Wright was careful not to put the claim any higher than those matters being consistent.

2102    But as Professor Hitt explained, the lack of observed pass-through is also consistent with many other things. There are several other explanations for the observation, including developers’ prices being set by reference to competitors rather than App Store commission, or forms of commitment to uniform pricing across platforms such as most-favoured nation clauses.

2103    And Apple says that this does not involve any foreclosing assumption that there are substitution possibilities. It just shows that the observation is not inconsistent with substitution possibilities.

Analysis

2104    Professor Wright’s application of the HMT appropriately started by considering the services that Apple offers through the App Store, being iOS app distribution services. Whilst Apple is the actual monopolist of these services, because of the impugned conduct, its services are the appropriate starting point for the inquiry.

2105    Now Apple criticised the application of the HMT to iOS app distribution services, arguing that starting the HMT with this product involved circular reasoning because Apple is alleged to be a monopolist. But I agree with Epic that this criticism is misplaced.

2106    Professor Wright’s analysis commenced by identifying the products actually supplied by Apple, namely iOS app distribution services and his subsequent analyses were directed to ascertaining whether the market should be expanded to include other, substitutable, services. If there were such substitutes, then his analysis would have involved considering a further iteration of the HMT, incorporating those services, in which case the hypothetical monopolist would have supplied services beyond those supplied by Apple.

2107    Moreover, as Professor Wright explained, saying that a market definition exercise cannot commence with the allegedly monopolised product creates a circumstance where one could never define a market already monopolised by a single firm. Obviously that is an untenable position to take.

2108    Indeed, as Epic said, an appropriate HMT will often start with a product supplied by a single firm, even if that restriction is imposed by way of the geographic market dimension. The purpose of the HMT is then to identify which other firms or products need to be included in the market analysis.

2109    Now when applying the HMT to an allegedly monopolised product, one potential issue is that the price charged for it may already be above competitive levels. This needs to be considered when interpreting the HMT results to avoid the cellophane fallacy.

2110    In particular, and as I have touched on conceptually elsewhere, when considering the behaviour of some developers or users in switching away from services supplied by Apple, one needs to be mindful of the possibility that they are doing so because the price Apple is charging is well-above the competitive level, in which case their behaviour is not informative of the substitution behaviour one would see in response to small price increases above the competitive level.

2111    Now Professor Hitt suggested that Professor Wright started from a premise that Apple is a constrained monopolist, such that a SSNIP will almost always pass. But Professor Wright explained that his analysis did not assume that Apple was a monopolist and would have been valid if Apple were in a competitive environment.

2112    Further, Professor Wright’s starting point was not too broad. It was said that the HMT should commence with narrower product subsets, such as digital game app transactions, that is, downloading, updating, and making in-app purchases in game apps, and video streaming app transactions, that is, downloading, updating, and making in-app purchases in apps for streaming movie and TV content. But I reject this for the reasons largely advanced by Epic.

2113    First, the HMT, and the market definition exercise more generally, are conducted to identify a market to analyse specific impugned conduct. Apple provides the same services to all developers irrespective of the type of app they develop. Further, Apple’s conduct at issue, and in particular the iOS app distribution conduct, is neither confined to nor targeted at gaming or video streaming apps, and nor is Epic’s complaint.

2114    Second, and relatedly, the approach suggested by Apple’s experts would have the unrealistic consequence of requiring the competitive effects of Apple’s conduct to be assessed in as many different markets as there are app genres.

2115    Professor Hitt’s approach would require definition of different markets for assessment of competitive effects in respect of dating app providers and music streaming apps. Now as Epic said, the unreality of this is highlighted by asking the rhetorical question: in what market or markets should the assessment be made of the competitive effects of Apple’s conduct on a firm that wished to distribute another app store? Professor Hitt’s evidence was that this may well require the definition of every possible app transaction market that reflected the whole variety of apps to be distributed by the other app store.

2116    Third, because the services offered by an app store do not differ by app genre, a hypothetical monopolist of a genre-specific app store would be constrained by the prospect of app stores that supply services for other genres beginning to offer services to the genre in question.

2117    And as Epic explained, even if the impugned conduct were limited to the distribution of video streaming apps or gaming apps, which it is not, the starting point would have to be the distribution of video streaming apps or gaming apps on iOS devices, not the distribution of video streaming apps or gaming apps on all devices. The HMT would then need to be applied to assess if a SSNIP on distribution for those apps on iOS devices would lead consumers to seek distribution services from other platforms, or if suppliers of distribution services for other app genres on iOS would move to supply their services for the genre which is exposed to a SSNIP.

2118    Because there is no functional difference between distribution services for different app genres on iOS, one ends up back at a market for iOS app distribution services and a consideration of the ability to substitute to other platforms.

2119    I also agree with Epic that this same issue caused Apple’s experts to erroneously identify paid app downloads as substitutable with free app downloads in combination with an in-app purchase. These “transactions” are not proper substitutes because both require the consumption of iOS app distribution services.

2120    It is true that in the case of the paid download, payment to Apple is made as part of the consumption of the distribution services, and in the case of the use of an in-app transaction to unlock content within a free app, the payment is made when consuming the tied payment solutions service. But in both cases, the distribution service is being consumed and Apple is being paid. The monetisation point has just shifted from the distribution service to the tied payment service.

2121    If one defines a market by reference to the point of monetisation, one will erroneously identify these two uses of the same service as relevant substitution. But if one defines the market by reference to the actual product being supplied, one will correctly identify that this change in monetisation does not result in a change in the consumption of the relevant product.

2122    Now to conduct the quantitative HMT, Professor Wright estimated an effective price for Apple’s iOS app distribution services by combining Apple’s commission on paid downloads with a portion of its commission on in-app purchases. Apple’s economic experts criticised this approach. But the commission on in-app purchases is for more than just payment processing and instead represents compensation for all of Apple’s services provided through the App Store.

2123    The commercial evidence is clear. Schedule 2 to the DPLA expressly provides that the commission is payable as consideration for Apple’s distribution services. Apple itself considers that its commission on paid apps and in-app purchases is primarily related to the distribution services provided by the App Store. The commission structure, including the commission on in-app purchases, is the model by which the entire App Store is monetised. When forced to adjust the model by regulation, Apple has effectively attributed the majority of the in-app commission to distribution. Through the App Store, Apple provides a platform to distribute iOS apps to consumers.

2124    Now as Epic says, there are numerous ways that Apple could charge for this service. But because Apple chose to do so by tying the service to the use of another service, Professor Wright had to determine an effective price. But that does not mean that the focus of the HMT should shift away from app distribution to some other problematic concept advanced by Apple.

2125    Moreover, I agree with Epic that Professor Wright did not cherry-pick a particular commission allocation mix. Professor Wright conservatively considered all potential scenarios, including one in which all of the commission on in-app purchases is attributed to the effective price for distribution services.

2126    And Professor Wright’s application of the quantitative HMT conservatively considered the full 5 to 10% SSNIP range.

2127    Now Apple put forward a theoretical criticism that only increasing the effective price on developers does not allow the hypothetical monopolist to optimally adjust prices by also imposing a price onto iOS app users. But there is no commercial evidence to suggest that a hypothetical monopolist operating in this market would raise prices on app users. Instead, as Epic said, it is principally via a pass-through of the SSNIP on the commission that users are impacted, whether through changes in price or quality.

2128    Further, Professor Wright’s analysis, through the mechanism of pass-through, does involve the imposition of higher prices on app users as a result of the SSNIP.

2129    In any event, as Epic said, Professor Wright’s approach would, if anything, risk delineating a market that is too broad, because allowing for profitable re-optimisation of commission structures would only make a SSNIP more profitable.

2130    Now it is not in doubt that Professor Wright considered the full range of potential responses by both developers and users, both individually and in combination.

2131    For developers, these responses included, first, delisting from the App Store to divert users, second, changes to development decisions/priorities, third, decreasing investment in their iOS apps, fourth, changing their monetisation model and, fifth, passing through some or all of the commission increase to users.

2132    For users, Professor Wright considered ways by which users could either remain on iOS but reduce their expenditure such as out-of-app purchases, web apps or non-mobile device channels, or change mobile devices by switching to Android. Apple’s economic experts did not identify any other substitution possibilities.

2133    Moreover, the evidence that I have discussed elsewhere demonstrates that developers and users do not consider native iOS apps to have close substitutes. Further, out-of-app purchases do not constrain the hypothetical monopolist of the iOS app distribution services.

2134    Now Professor Wright’s quantitative HMT demonstrated that, using Apple’s transaction data and Apple’s calculations of market elasticities, imposing a SSNIP would be profitable for the hypothetical monopolist of iOS app distribution services.

2135    And as Epic rightly said, this finding was robust to a range of reasonable assumptions in respect of the size of the SSNIP, the elasticity of demand figure used, the level of pass-through to app users and the vertical integration of the hypothetical monopolist into devices.

2136    But because Apple monopolises iOS app distribution services, the successful SSNIP alone cannot be a clear identification of the relevant market. This is because the successful SSNIP raises the question as to why Apple has not already imposed a SSNIP. That is, on the assumption that firms seek to maximise profits, a firm in Apple’s position would be expected to have already imposed any profitable SSNIP.

2137    I agree with Epic that the commercial evidence explains why Apple’s commission is below the rate that its market power may allow.

2138    First, as Epic said, Apple’s rate was not set following an analysis of the revenue stream it would generate. At most, it might have resulted from very limited research into the rates on other platforms, but there are no records to verify this. Now the evidence from Apple’s executives indicated that the original goal of the App Store was not to generate substantial profits but to enhance the value of Apple’s devices. But as demand for iOS apps has grown, and as Epic points out, Apple’s closed approach to app distribution has protected its commission rates from competitive forces and allowed it to generate substantial returns.

2139    Second, as App Store revenue has grown, Apple has come under intense regulatory scrutiny. Accordingly, Apple’s recent conduct is consistent with it defending the pre-existing commission structure from regulatory intervention.

2140    Further, as Professor Wright observed, the small business program is at odds with other commercial platforms in that it gives commission decreases to the App Store’s smallest customers whilst maintaining commission levels for its largest customers. As I discussed with counsel during the hearing, this runs contrary to commercial logic.

2141    Now Professor Hitt and Mr Houston made various criticisms of Professor Wright’s analysis of substitution in response to a SSNIP.

2142    First, it was said that Professor Wright only evaluated the extent of substitution by considering the likelihood of each potential response by developers and users to a SSNIP in turn, rather than considering the overall total effect of potential responses.

2143    Second, it was said that Professor Wright did not adequately account for feedback loops resulting from network effects on the App Store, which would amplify the responsiveness of users on one side of the platform to a reaction by users on the other side of the platform to a price increase.

2144    But I agree with Epic that Professor Wright did account for these factors in his HMT. He also addressed them through his analysis of pass-through, quantity natural experiments and elasticity. Apple’s own evidence of a lack of pass-through demonstrates the aggregate lack of substitution across channels. Further, Professor Wright’s quantity natural experiments are strong evidence that there is virtually no response as a whole from both users and developers, even accounting for any feedback loops between them, to substantial relative changes in iOS commission rates. And further, Apple’s own elasticity figures capture the combined impact of all forms of substitution in response to small price changes implemented by Apple.

2145    Let me deal in more detail with some of the points made by Apple’s experts against Professor Wright’s analysis, some of which I have already touched on briefly. Five specific criticisms were made, each of which I reject largely for the reasons advanced by Professor Wright specifically and Epic generally.

2146    First, as I have already mentioned, it was said that Professor Wright’s application of the HMT framework assumed that Apple is a monopolist.

2147    Now as to this first criticism, Professor Hitt said that Professor Wright assumed but did not demonstrate that there are no close competitors to Apple in either the actual market or the alternative hypothesised market in the HMT. In other words, it is said that Professor Wright assumed that Apple is a monopolist.

2148    Professor Hitt claimed in this respect that Professor Wright’s approach was to simply ask whether an assumed monopolist, when subject to regulation that requires it to set lower prices than it would like, would have an incentive to increase prices to reach profit-maximising levels. The result will always be that it does. So, it was said that his application of the HMT framework would be unreliable. This is not correct.

2149    Professor Wright’s application of the HMT framework did not assume that Apple is a monopolist. He started his analysis with a candidate market for the supply of services for the distribution of iOS apps. He explained that Apple is the monopolist supplier in this candidate market. Given the risk of the cellophane fallacy affecting his analysis, he explained that the results of his analysis need to be interpreted with the following in mind.

2150    If such a SSNIP was found not to be profitable, the test would not be directly determinative as to whether a SSNIP applied to a lower commission rate would be profitable. In that case, this test could not be relied on to define the relevant market without further examination of the evidence. This is because the fact of a SSNIP being found not to be profitable could stem from either competitive pressure from alternative suppliers, or Apple already maximising monopoly profit.

2151    In this case, the test with this result, on its own without further examination of other evidence, would not identify the relevant market.

2152    In such a case, it would be necessary to examine the likelihood of the first point compared to the second point. That is, it would be necessary to examine whether the SSNIP is likely to be unprofitable due to competitive pressure from alternative suppliers in the same market, being the first point, or due to indirect constraints that only become binding at the monopoly price, for example, app developers and app users forgoing app distribution services to use web apps, or app users conducting purchases of digital content on app developers’ websites or alternative channels for use in their iOS apps, thereby constraining Apple’s monetisation of app distribution services via commissions charged on in-app purchases, which suggest the cellophane fallacy is present, being the second point.

2153    If such a SSNIP were found to be profitable, it would suggest that a SSNIP applied to a lower commission rate would also be profitable. This is because app developers and app users are less likely to substitute to alternative channels when the commission on iOS app distribution services is lower. In this case, the test would evidence that the candidate market is a relevant market.

2154    But Professor Wright acknowledged that for a SSNIP applied to Apple’s current commission rates to be profitable, Apple must set its current commission rates below the level that would maximise its profit.

2155    Professor Wright provided reasons for why Apple is likely not maximising profit, at least before considering any regulatory risk. Apple faces regulatory pressure. Further, Apple apparently did not initially set a 30% commission rate to maximise its profits but instead set the rate based on other major platforms’ headline commission rates for digital content at the time.

2156    Further, Professor Hitt’s own evidence is consistent with Apple not maximising profits.

2157    Apple has maintained the same commission rate for most of its revenue base over time despite, according to Professor Hitt, significant growth in the market.

2158    Further, Apple has generally maintained the same commission rate for most purchases of digital content across different genres, despite them, according to Professor Hitt, facing different demand conditions and competitive constraints.

2159    Further, Professor Wright did not assume that Apple is a monopolist. In particular, his application of the HMT framework could have resulted in Apple not being a monopolist, for example, that the App Store is in the same market as other app stores that provide distribution services for apps for use on different operating systems, if the evidence had been consistent with a sufficient degree of substitution to these alternative app stores, rendering a SSNIP unprofitable and, therefore, necessitating expansion of the candidate market in the HMT framework to include these other app stores.

2160    If such a SSNIP were found not to be profitable, the test would not be determinative. This is because the result could stem from either competitive pressure from alternatives, or Apple already maximising monopoly profit.

2161    In this case, the test with this result, on its own without further examination of other evidence, would not identify the relevant market. It would then be necessary to examine the likelihood of competitive pressures from alternatives compared to the second scenario, that is, to examine whether the SSNIP is likely to be unprofitable due to competitive pressure from alternative suppliers in the same market, or due to indirect constraints which suggest the cellophane fallacy is present.

2162    For instance, based on the SSNIP analysis of Professor Wright, if the evidence had been consistent with an elasticity of demand as high as 3.7 with an app developer pass-through rate of 90%, then his analysis would have found the SSNIP to be unprofitable. Because of the risk of the cellophane fallacy, he would have had to further examine the reason for the SSNIP being unprofitable, that is, whether the high elasticity of demand at the current commission level is driven by Apple facing competitive pressure from alternative app stores or being constrained from other channels, such as web apps or conducting purchases of digital content on websites.

2163    If the high elasticity of demand was driven by Apple being constrained from other channels, then it would suggest that the cellophane fallacy is present and that Apple is already maximising its monopoly profit.

2164    The critical elasticity would be 3.5, if losses of device sales from iOS users that would switch to non-iOS devices in response to a SSNIP are accounted for.

2165    As explained by Professor Wright, he expected low levels of pass-through from app developers to app users, that is, the 90% pass-through rate was conservative as it suggests that the SSNIP is almost entirely borne by the app users, which makes it more likely for the SSNIP to become unprofitable. For pass-through rates of 75% or 50%, which Professor Wright still considered to be too high, the elasticity of demand would have had to be up to 4.2 or 5.9 respectively, before the SSNIP would become unprofitable. These critical elasticities would be 4.0 and 5.7 respectively if losses of device sales are accounted for.

2166    That said, and as explained by Professor Wright, the evidence is consistent with a much lower elasticity of demand, in the range of 0 and 2. Additionally, Professor Wright expected the app developer pass-through rate to be limited. So, the evidence is consistent with the SSNIP being profitable.

2167    Professor Wright’s approach to market definition contrasted with the approach of Professor Hitt.

2168    Professor Hitt’s market definition did not follow the logic of the HMT. As I have explained earlier, under the HMT framework, the assessment starts by considering a hypothetical monopolist of the relevant product(s) of the firm under investigation in a focal area. The first question to be considered is whether it would be profitable for the hypothetical monopolist to sustain a SSNIP above competitive levels. If “yes”, then the relevant market is defined as the relevant product(s) of the firm in the focal area. If “no”, and assuming that the situation is not one in which the cellophane fallacy applies, the scope of the products and/or geographic area under consideration is expanded to include the next product and/or geographic area that are the closest substitutes to the product(s) and area(s) already being considered. The question then asked is whether a hypothetical monopolist of the expanded product group/geographic area could profitably sustain a SSNIP above competitive levels. This process is repeated until a product group and geographic area are found such that a hypothetical monopolist supplying that product group in that geographic area could profitably sustain a SSNIP.

2169    But Professor Hitt did not start with the narrowest possible set of relevant products given the conduct in question, that is, Apple’s conduct which applies to iOS apps only, and then follow this sequential process. Rather, he started with the widest possible market in terms of potential alternative suppliers, that is, all app stores on all different operating systems, as well as other channels where purchases of digital content could be made, despite providing very limited evidence of substitution between these different channels.

2170    Professor Hitt’s and Mr Houston’s market definition did not rely on any quantitative evidence of actual substitution for app distribution services. They only identified potential avenues of substitution. They did not account for actual substitution, or how app developers and app users would react to a SSNIP.

2171    Further, Professor Hitt’s interpretation of the HMT included the idea that the signature component of the test is that one begins by changing the competitive structure of the candidate market and placing its products under the control of a hypothetical monopolist.

2172    But under Professor Hitt’s interpretation of the HMT framework, whereby it is necessary to change the competitive structure of the candidate market from the outset, one could never define a market that has already been monopolised by a single firm, as I have already mentioned.

2173    Professor Hitt’s interpretation of the HMT was at odds with Mr Houston’s approach to market definition, which started with the product that is being provided by Apple on the App Store and then considered whether there is a sufficiently strong competitive constraint from the potential for app users and developers to make substitute transactions on alternative platforms to the App Store if Apple increased prices or reduced the quality of service on the App Store to either app users or app developers.

2174    Second, it was said that Professor Wright’s application of the HMT framework resulted in an artificially narrow relevant market as it only considered a limited number of possible substitution options.

2175    Now as to this second criticism, Professor Hitt and Mr Houston said that Professor Wright’s conclusion that app developers and app users would be unlikely to sufficiently respond to a SSNIP such as to make it profitable, and ultimately that there is a relevant market for the supply of services for the distribution of iOS apps, was drawn by reference to an irretrievably compromised market definition process.

2176    In particular, they said that Professor Wright did not properly account for all avenues of substitution.

2177    But when implementing the HMT, Professor Wright identified all potential substitutes for app distribution service available to both app developers and app users, as well as potential indirect constraints, including those related to in-app purchases as opposed to app distribution services. He considered each one individually and in combination.

2178    He examined the relevant evidence and reasoned to conclusions about the likelihood of actual substitution to alternatives for app distribution services and of indirect constraints not involving the substitution of app distribution services, such as app users purchasing digital content on other channels with the intention of using that digital content in their iOS apps in response to a SSNIP.

2179    He concluded that the App Store has no close substitutes for app distribution services.

2180    Third, it was said that Professor Wright’s application of the HMT framework did not use a relevant or defensible measure of price when evaluating the effects of an increase in price.

2181    Now as to this third criticism, Professor Hitt and Mr Houston said that Professor Wright did not use a relevant or defensible measure of price when evaluating the effects of an increase in price. In particular, they said that the starting price, that is, the commission rate, that he used was artificially split between two products, being app distribution services and in-app payment solutions, instead of considering only app transactions as a single product.

2182    In this respect, Professor Hitt said that Professor Wright’s analysis used the same price, that is, the commission rate, for both the iOS app distribution market and the iOS in-app payment solutions market. Professor Hitt said that one price cannot simultaneously represent the price for two products, that is, distribution and payment processing, if these are indeed separate markets.

2183    Similarly, Mr Houston said that the price upon which Professor Wright imposed a SSNIP was applied, among other transactions, to the commission collected by Apple on in-app purchases, even though in-app purchases were excluded from the iOS app distribution market that he defined. Mr Houston seemed to suggest that this made Professor Wright’s approach unreliable.

2184    But Apple’s experts failed to engage with the reasoning of Professor Wright. He explained why, to determine the relevant market for assessing Apple’s conduct, he considered what Apple is currently effectively charging for app distribution services.

2185    Given that Apple is tying app distribution services on iOS and in-app payment solutions on iOS, he estimated an effective price, that is, commission rate, for app distribution services based on Apple’s commission on paid app downloads and an estimate of the proportion of Apple’s commission on in-app purchases that can be considered as payment for app distribution services. This was for the following reasons.

2186    App distribution services on the App Store include the integral service of accepting and facilitating payments for paid download apps. This occurs during the matching process between app developers and app users on the App Store, in which the latest version of the app is delivered by Apple via the App Store to the app user. As such, the commission Apple charges app developers for paid download apps is a relevant price for app distribution services.

2187    App distribution services exclude services to app developers for accepting and facilitating payments for iOS in-app purchases after the app user and app developer have already been matched and the latest version of the app has been delivered by Apple via the App Store to the app user. But it may be that some proportion of the commission charged for iOS in-app purchases is effectively an additional payment levied on app developers for iOS app distribution services via the App Store.

2188    Reflecting this, Professor Wright considered a SSNIP based on a 5 to 10% increase on the full commission that Apple collects for paid apps, and a 5 to 10% increase on the commission that Apple collects for iOS in-app purchases net of the 5 percentage points which he assumed relates to the competitive price for Apple’s payment solution.

2189    That said, Professor Wright disagreed with Professor Hitt and Mr Houston for the following reasons, which I accept.

2190    As I have said, they criticised Professor Wright’s allocation of commissions collected by Apple between app distribution services and in-app payment solutions but failed to acknowledge that Professor Wright’s findings were robust to any allocation of commissions. He explained that his conclusions on the relevant market were not sensitive to the assumption he made as to what proportion of the commission on iOS in-app purchases is effectively a payment for distribution. Indeed, he considered all possible allocations.

2191    Further, as I have said, they failed to recognise that Professor Wright’s approach was conservative, as it allocated a fraction of the commission charged on in-app purchases to app distribution services. If he had instead assumed that the only price for app distribution services is the commission on paid downloads, then he would have considered switching in response to a SSNIP that was only applied to the commission on paid downloads, which would be a much more limited SSNIP given that most app developer revenue is generated through in-app purchases.

2192    As I have said, switching away from iOS by app developers and app users in response to this much more limited price increase would be expected to be less than the switching in response to a SSNIP applied to both paid downloads and in-app purchases, and so it is more likely that a limited SSNIP would be profitable for Apple.

2193    So, Professor Wright’s finding that the SSNIP on commissions for both iOS paid downloads and iOS in-app purchases is profitable also implies that a SSNIP on iOS paid downloads alone would be profitable.

2194    Similarly, Professor Wright also found that a SSNIP on the commission charged on in-app purchases, where the entire commission is allocated to the in-app purchases, would be profitable. He also showed that if one does not allocate between app distribution services and in-app payment solutions and apply a SSNIP to both simultaneously, then the SSNIP is still profitable and Professor Wright would still have found an iOS-only market, although he did not consider combining app distribution services and in-app payment solutions to be the correct lens through which to examine Apple’s conduct and its effect on competition. Again, this shows that his conclusions on the relevant market for app distribution services and in-app payment solutions were not sensitive to any allocation of commissions.

2195    Apple is currently tying app distribution services on iOS and in-app payment solutions on iOS. Professor Wright considered it reasonable to assume that a share of the commission on iOS in-app purchases is also an effective payment for app distribution services.

2196    This would appear to be consistent with Apple’s change in pricing policy in response to regulatory interventions in the Netherlands and South Korea, as well as recently in the US and in the EU.

2197    Apple has permitted the use of different payment solutions in the Netherlands for dating apps and has pre-approved four third-party payment solutions for in-app purchases in South Korea.

2198    App developers opting for third-party in-app payment solutions pay a 26% to 27% commission rate on in-app purchases in cases where they otherwise would have paid a 30% commission rate. These commission rates were not made in response to competition from other platforms, but rather in response to regulatory interventions.

2199    Similarly, in the US Apple has allowed app developers to use a link to their own website for purchases of digital content alongside Apple’s IAP. App developers opting for the use of a link to their own website pay a 27% commission rate on purchases of digital content conducted on app developers’ websites in cases where they otherwise would have paid a 30% commission rate.

2200    In the EU, as a response to the Digital Markets Act, Apple will explicitly charge a 3% additional commission fee for the use of IAP on apps distributed through the App Store, which app developers will not incur if they use a third-party or their own in-app payment solution.

2201    Fourth, it was said that Professor Wright’s application of the HMT framework did not properly account for the two-sidedness of the platform by only implementing the price increase on one side of the platform, by not allowing the hypothetical monopolist to optimally adjust price level and structure and by failing to sufficiently consider indirect network effects.

2202    Now as to this fourth criticism, Professor Hitt and Mr Houston said that the typical SSNIP is difficult to apply to a two-sided platform and, if it is to be applied, it must be augmented to account for optimal adjustments of price, indirect network effects and feedback loops. Further, they said that Professor Wright’s application of the HMT framework fell short in accounting for two-sidedness.

2203    In particular, they said that it did not allow for increasing prices simultaneously on both app users and app developers independently. They said that it did not allow for optimal adjustment of the hypothetical monopolist’s price structure following the SSNIP. And they said that it did not sufficiently consider the indirect network effects and positive feedback loops associated with substitution on the App Store.

2204    Let me make a number of points.

2205    Professor Wright’s application of the HMT framework anchored the price increase in commercial reality.

2206    Now Professor Hitt said that it would be nonsensical to apply a SSNIP only to app developers. He said that the only way that Professor Wright allowed consumers to be affected by a SSNIP was through developers’ decisions on whether to pass through the commission rate increase to consumer prices, which would make Professor Wright’s analysis no different from the assessment of a SSNIP on a one-sided input supplier. Professor Hitt said that when applying a SSNIP on commissions charged for paid downloads and in-app purchases, Professor Wright did not consider app developers that currently distribute apps on the App Store but monetise those apps outside or partially outside of the App Store.

2207    Professor Wright disagreed with Professor Hitt for the following reasons, which I accept.

2208    It is incorrect that the HMT framework cannot be applied to Apple’s commission rate. Apple’s commissions apply to paid downloads and in-app purchases, and are directly incurred by app developers, being only one side of the platform. Apple does not charge app users a direct price for using the App Store. So, Professor Wright considered it reasonable to consider a SSNIP on current commissions, whilst accounting for possible pass-through from app developers of the commission increase into higher app and/or in-app prices paid by the app users.

2209    But in any event Professor Wright did consider different levels of pass-through in his analysis, including unrealistically high levels, and therefore implicitly accounted for a change in the way Apple could charge for app distribution services, that is, the incidence of the commission and so whether it would be supported by app developers only or also by app users indirectly.

2210    His approach was consistent with the literature referred to by Mr Houston, which posits that in a two-sided transaction platform one should instead check the profitability of an increase in the price level, that is, the sum of the prices paid for the transaction by the two parties, and then consider potential changes in pricing structure.

2211    Given that the App Store and other similar app stores do not set a price to app users for using their services, Professor Wright’s SSNIP did indeed apply to the relevant price level levied on the app developers, that is, the level of commission.

2212    In any case, his assumptions on the level of pass-through accounted for possible variations in the incidence of changes in the price level, that is, the commission level, on the two sides, that is, app developers and app users.

2213    Further, Professor Wright disagreed that his analysis would be no different from the assessment of a SSNIP on a one-sided input supplier. This is because he allowed for the possibility that if app and in-app prices had changed enough such that many app users switched away from the App Store, there could be feedback effects on app developers’ decisions to make their apps available on the App Store. This is a difference from the standard analysis of a one-sided input supplier.

2214    Professor Wright did consider app developers that currently distribute apps on the App Store but monetise those apps partially outside or entirely outside of the App Store.

2215    Apple also charges app developers annual fixed fees to distribute their apps on the App Store, imposed on all app developers, regardless of whether those app developers monetise their apps partially or entirely outside of the App Store. Professor Wright did not include annual developer fees in his quantitative analysis of the SSNIP. But he explained that this did not affect his conclusions for the following reasons.

2216    These are fixed fees and hence do not impact developers’ costs of supplying additional sales. This makes these fees unlikely to be passed through into developers’ prices for app and in-app purchases, as fixed costs, unlike marginal costs, do not directly impact a firm’s profit-maximising level of prices and volumes provided that the firm is able to recover its fixed costs.

2217    Further, the size of these fees, being USD 99 or USD 299 for the Apple developer enterprise program, also makes them likely to be absorbed by all but the very smallest app developers.

2218    Further, to the extent that app developers do absorb these increases in fixed fees, as Professor Wright considered likely given their relative immateriality, this would increase the profitability of the overall SSNIP for Apple.

2219    So, ignoring them in a quantitative assessment of whether a SSNIP is likely to be profitable is a conservative assumption. It makes the SSNIP less likely to be profitable, and ultimately it makes it less likely to find a relevant market for iOS app distribution services, with Apple being a monopolist in this relevant market.

2220    Apple also earns revenue on search advertisements, which would be relevant in terms of distribution services for all apps distributed on the App Store regardless of monetisation.

2221    Professor Hitt and Mr Houston focused only on commission revenue and ignored Apple’s revenue from search advertising on the App Store. Apple has two distinct sources of advertising revenue, being revenue from advertising and search results on the App Store, and revenue from advertising and web search engines outside the division to which the App Store belongs to. Only the former is potentially relevant for a SSNIP.

2222    In any event, the purpose of the market definition exercise is to identify competitive constraints faced by Apple and ultimately examine the existence of market power and the effects of the conduct at issue on competition. As evidenced by Professor Wright’s application of the HMT framework, clearly Apple could sustain a SSNIP on its current commission levels, which is evidence of market power in itself.

2223    Further, Professor Wright said that the Apple experts focused on potential avenues of substitution for specific types of digital content only, being game apps and video streaming apps, and did not consider actual substitution in response to any potential app and/or in-app price changes on the app user side.

2224    Further, Professor Wright’s application of the HMT framework did consider indirect network effects.

2225    Mr Houston said that Professor Wright’s approach failed to properly account for indirect network effects. Professor Hitt further said that the existence of strong indirect network effects on a transaction platform such as the App Store makes analysing a SSNIP more complicated, and that the literature often suggests that doing so requires many data inputs that often makes such an exercise difficult to conduct. Similarly, Mr Houston claimed that the typical SSNIP is very difficult to apply to a two-sided market and, if it is to be applied, must be augmented.

2226    But Professor Wright did account for indirect network effects for market definition purposes and demonstrated that this can be done in a rigorous way.

2227    He explained that the iOS app distribution market involves a multi-sided platform, in which app developers and app users will each value the presence of the other. The demand of app developers to use the App Store is likely to depend on the number of users acquiring iOS apps and making iOS in-app purchases. Further, the demand of app users to use the App Store is likely to depend to some extent on the number of iOS apps made available by app developers in the App Store. These inter-relationships mean that there can be feedback effects whereby changes in the number of app developers or app users can impact the demand for and usage on the other side of the platform.

2228    He further explained that the HMT should take into account the multi-sided nature when examining the profitability of a price increase for the distribution of iOS apps, including any feedback between the two sides of the platform.

2229    Professor Wright therefore assessed the likely overall profitability of the SSNIP taking into account the likely responses of app developers and app users, and any feedback effects between them. He explained in this respect that given that there is no material impact from user reactions to the SSNIP on app developers’ decisions, at the margin, in relation to the App Store, it implies that any subsequent rounds of feedback effects between app developers and app users would be insignificant.

2230    Now on this latter point, Mr Houston said that this finding conflicted with the economic literature on this topic, which recognises that even when sensitivity to price on one side is low in isolation, demand on that side may be very price-sensitive once feedback loops are considered.

2231    But the economic literature does not speak to the strength of indirect network effects in a given case, and certainly not with respect to a marginal change in price as is relevant for a SSNIP test. Rather, the literature stresses the importance of accounting for these factors in the assessment, which Professor Wright did.

2232    Further, even if indirect network effects may be present, the extent to which they influence the result of the SSNIP test should be investigated on a case-by-case basis, which ultimately depends on the strength of these indirect network effects at the margin, that is, the strength of the feedback effects in response to a small change in the usage of the platform by either side of the platform.

2233    As Professor Wright said, Professor Hitt and Mr Houston provided no evidence that indirect network effects would be especially strong, at the margin, in the present case.

2234    Professor Hitt and Mr Houston also agreed with Professor Wright’s theoretical predictions about low pass-through from app developers to app users in the factual world. Professor Hitt found no pass-through empirically with natural experiments. As Professor Wright said, the evidence is consistent with insubstantial, if any, feedback effects in response to a SSNIP.

2235    In any event, Professor Wright noted that Professor Hitt’s and Mr Houston’s focus on feedback effects through participation and app usage was inconsistent with their primary focus on app transactions, and, in particular, in-app purchases.

2236    By their logic, if a SSNIP led to a reduction in app transactions on the App Store, then that would not affect the participation of app users or app developers on the App Store as those app users/developers would continue to use the App Store but would reroute their app transactions through alternative channels. As such, there could not be a strong feedback effect or downward spiral under their logic. Instead, such a feedback effect would arise if app developers exited the App Store altogether or app users switched to using another operating system, both of which Professor Wright assessed as potential forms of substitution in his analysis. He found neither was likely to be a significant factor, which is why any feedback effects would be weak.

2237    Further, Professor Wright’s application of the HMT framework conservatively considered that the hypothetical monopolist would not optimally adjust the price structure.

2238    Professor Hitt said that Professor Wright’s approach did not allow the hypothetical monopolist to optimally adjust the price structure or to raise prices that consumers pay to the platform at all. Similarly, Mr Houston said that Professor Wright did not allow for the optimal adjustment of the price structure following the SSNIP such that his approach would not properly account for two-sidedness.

2239    Professor Wright first noted that Apple is not charging app users for app distribution services. Professor Hitt and Mr Houston provided no evidence that Apple would consider charging app users for access to the App Store, or for downloading apps or updating apps. In this case, there is nothing to re-optimise on the app user side.

2240    That said, if it were profitable for a hypothetical monopolist app store to start charging app users directly for app distribution services as part of a SSNIP, then Professor Wright’s approach of ignoring this possibility would be conservative compared to that scenario, that is, his approach would tend to delineate too broad a market.

2241    He found that without adjusting the price structure, a hypothetical monopolist would find a SSNIP profitable. If a hypothetical monopolist were to also adjust the price structure to increase its profits, a SSNIP would be even more profitable.

2242    Fifth, it was said that Professor Wright’s application of the HMT framework did not start with the smallest set of substitute products for which a hypothetical monopolist would find it profitable to increase prices, that is, commission rates, and instead asserted a market for all iOS apps.

2243    Now as to this fifth criticism, Professor Hitt and Mr Houston said that Professor Wright included all apps together in his market for iOS app distribution but did not contemplate the question of whether different types of apps should be the subject of such a broad grouping, and so in the same product dimension of the market. They said that his analysis should have started with a series of candidate markets for a narrower set of apps, in particular, gaming apps or video streaming apps.

2244    Professor Wright disagreed with their claim that his market definition is too wide because it encompasses all iOS apps across genres.

2245    Professor Wright proceeded on the basis that identifying a market and defining its dimensions is a focusing process through which one aims to provide the clearest picture of the relevant competitive process in light of commercial reality, and should be tailored to the impugned conduct at issue. In that sense, market definition exercises are purposive, instrumental or functional. I could not agree more.

2246    Now given that, first, Apple provides through the App Store essentially the same app distribution services irrespective of the app genre, second, Apple’s impugned conduct applies across all genres of apps with only limited exemptions for some app genres or specific apps and, third, indirect network effects between app developers and app users on the App Store work across all genres of apps and not for specific app genres only reflecting the fact that these indirect network effects result from app user and app developer participation on the App Store, I agree with Professor Wright that it is not appropriate to delineate the relevant market by app genre to assess the effect or likely effect of Apple’s impugned conduct.

2247    Let me now address some other in one sense discrete topics.

Technical substitutes

2248    Now Apple says that there are technical substitutes across a range of platforms and devices including iOS devices. Further, it says that whilst technical substitutes are not necessarily close substitutes, technical substitutes do by definition respond to price changes between them. And it says that there is at least some economic substitution that occurs between these technical substitutes.

2249    Professor Hitt was of the view that substitution by even a small number of users could constitute economically meaningful substitution as platforms are constrained by the risk of losing even small numbers of users. He expressed the view that even if a small percentage of users move, that could be relevant and could be a concern to a developer or Apple in relation to the App Store.

2250    But of course the issue in controversy is the extent to which there would in reality be meaningful close substitution in response to price changes.

2251    Moreover, a feature of this case is that there have generally not been relevant price changes, such that there is a lack of direct evidence of switching behaviour in response to any price changes.

2252    Now Professor Wright said that whether there is substitutability is an empirical question that would only be addressed by whether, assuming that technically one could readily transact across platforms or devices, there was movement that was responding to a price change. But of course if prices are the same across the different channels, this empirical question would not be answered.

2253    Now Professor Wright gave evidence on whether one sees substitution in response to changes in conditions, such as might be embodied in Apple’s elasticity estimates. Further, Professor Wright analysed the lack of quantity changes in other natural experiments that he referred to.

Elasticity documents

2254    Professor Wright considered various Apple documents which contained estimates of the price elasticity of demand of iOS users for iOS apps. These estimates were derived and relied on by Apple when considering price changes for apps and in-app content in the App Store and similar services. These documents show that Apple observed very limited change in demand by consumers when faced with a price change. The documents show that Apple made commercial decisions on that basis.

2255    Now Professor Hitt said during cross-examination that he agreed with the elasticity estimates Professor Wright derived from these documents. But nevertheless, Apple criticised Professor Wright’s reliance on this evidence during cross-examination on the basis that these documents contained estimates of elasticity calculated in the context of broader economic changes, such as changes to foreign exchange rates and taxation.

2256    But as Professor Wright explained, the fact that these documents often refer to elasticity in the context of considering whether to implement price changes in response to macroeconomic trends of this kind does not diminish the value of the elasticities and nor do they necessarily indicate the context in which these figures were calculated.

2257    Professor Wright agreed that the elasticity of demand in response to economy-wide events will be lower than in circumstances where there are price changes in iOS apps, ceteris paribus, but he cogently explained why that did not affect his views as to the reliability of the figures he used.

2258    Professor Goldfarb also said that even where price changes in such a context were relied upon to calculate elasticity, this broader economic context does not affect the reliability of the results, because the elasticity estimates compare the effect on demand of a price change relative to there being no change in price for iOS apps or in-app purchases. The broader macroeconomic context is a given in such a scenario.

2259    Further, these estimates were used at the highest levels of management within Apple. So, in response to direct requests from Mr Cook, Apple management provided estimates of elasticity based on responses to price changes arising from changes in taxation and foreign exchange rates.

2260    Moreover, Apple did not lead any lay or expert evidence about elasticities of demand or the circumstances in which the estimates relied on by Professor Wright were prepared.

2261    I have no difficulty in drawing the inference that the estimates relied on by Professor Wright were reasonably accurate. And given Apple’s own internal reliance on these elasticity estimates and the agreement between the experts as to their magnitude, I accept that they provide probative evidence that iOS users would not meaningfully reduce their expenditure on iOS apps and in-app purchases when faced with a SSNIP in the price of app downloads and in-app digital content.

Pass-through

2262    Now Professor Hitt conducted several natural experiments concerning three of Apple’s programs in which Apple lowered its commission rates for certain types of apps.

2263    First, there was the small business program with effect from 1 January 2021, where Apple reduced the commission rate to 15% for developers with global App Store net developer revenues of up to $1 million in the previous calendar year.

2264    Second, there was the auto-renewing subscription policy with effect from June 2016, where Apple reduced commission rates from 30% to 15% after a subscriber’s first year of an auto-renewable subscription.

2265    Third, there was the video partner program which commenced in 2016, where Apple reduced its commission rates from 30% to 15% for participants in the video partner program, provided a user signs up using Apple’s IAP.

2266    Professor Hitt’s findings, which were accepted by Professor Wright, from his three natural experiments were that many of the affected app developers did not lower consumer prices for app downloads and in-app purchases when faced with a reduction in App Store commission rates in the actual world.

2267    So, Professor Wright, Professor Hitt and Mr Houston all agreed that developer pass-through of Apple’s commission rate changes was and would be limited in the factual world, although there was some disagreement as to whether the pass-through would be zero.

2268    Now Professor Wright said that the fact that app developers had not passed-through commission changes indicated that there is limited app user substitutability between different channels. Contrastingly, Professor Hitt and Mr Houston said that there can still be substitutability between channels when there is limited pass-through. To support their position, Professor Hitt and Mr Houston threw up various theories.

2269    But let me make the following points based upon Professor Wright’s evidence which I have accepted.

2270    First, Professor Hitt’s natural experiments disclosed a lack of user substitution across channels.

2271    Now Professor Hitt asserted that his findings from the natural experiments did not indicate a lack of substitution, as there are many factors influencing a developer’s choice to pass through a commission rate change on one platform. But the minimal pass-through that Professor Hitt found from his natural experiments is consistent with a lack of substitution across channels.

2272    I accept Professor Wright’s conclusion that a lack of substitution across channels is the most natural economic explanation for why there was no positive pass-through.

2273    Professor Wright explained that the lack of evidence of pass-through was consistent with a lack of substitution across channels and was inconsistent with Professor Hitt and Mr Houston’s basic theory of transaction-level substitution. Professor Wright explained the theoretical foundation for this view. The logic is straight-forward. If app users readily substituted between different channels, app developers would have a strong incentive to reduce their app and/or in-app prices on iOS following a reduction in Apple’s commissions. The incentive would be to divert purchases from platforms with higher commissions to iOS in order to benefit from Apple’s lower commissions.

2274    Further, Apple relied on Professor Hitt’s comments on Professor Wright’s evidence about the implications of a lack of pass-through to contend that Professor Wright was careful not to put his opinion higher than that the lack of observed pass-through was consistent with a lack of substitution.

2275    Now in the joint expert report, Professor Wright was clear that the lack of pass-through was inconsistent with the basic theory of transaction-level substitution proposed by Professor Hitt and Mr Houston. And in cross-examination, he expressed the view that limited pass-through indicates that there is no substitution between the App Store and alternative channels.

2276    Second, Professor Hitt’s and Mr Houston’s alternative pass-through theories were flawed.

2277    Now to justify the argument that there is substitution across platforms despite there being no pass-through, Professor Hitt and Mr Houston made a number of problematic arguments. And they contorted themselves in an attempt to avoid the fact that a lack of substitution across channels is the most natural economic explanation for limited pass-through.

2278    Professor Hitt said that in relation to app developers who monetise through in-app advertising in addition to in-app purchases or paid downloads, some developers would respond with negative pass-through. Professor Hitt said that some app developers would raise prices in response to lower commission rates because with lower commission rates, using in-app purchases may become more profitable for them than alternate sources of monetisation like in-app advertising.

2279    But this monetisation strategy only applies where app users cannot pay to avoid watching advertisements. For example, users of online newspaper subscriptions cannot pay an extra fee to avoid advertisements. If developers who partially monetise through advertisements also give users the option to purchase a premium account to avoid advertisements, as occurs with, for example, YouTube, there would likely be pass-through. If there is a commission decrease, such developers would be incentivised to decrease the premium subscription price to increase the number of users who purchase the premium account, that is, the payment method subject to the lower commission.

2280    Now it was agreed that there is a mix of the two advertising monetisation models. But Professor Wright found that the majority of developers provide users with the option to avoid advertisements, as is done by the developers of YouTube, Microsoft Office and Duolingo. Professor Hitt’s reasoning was at odds with the economic literature, which finds that app users consider in-app advertising and in-app purchases to be substitutes in terms of purchasing additional digital content for a given app. I accept that positive pass-through is more likely for developers who monetise partially through advertisements and who consider advertising a reasonable substitute for in-app purchases.

2281    Further, Professor Hitt said that as developers compete with other providers of digital content that do not pay commissions to Apple, some developers would choose not to pass-through commission changes. But even if developers are facing this mode of competition, economic theory indicates there would be some positive pass-through. The only exception in which there would be no pass-through is if there was perfect competition. If there was perfect competition, economic theory indicates that the price would be zero because it would be priced at marginal cost. Professor Hitt’s response, being that some developers do have positive marginal costs, is inconsistent with his own findings of limited pass-through. If some developers have positive marginal costs, economic theory suggests that pass-through would be greater than limited.

2282    Further, Mr Houston said that even when there is substitution across different channels, multiple effects would be at play which could either increase or decrease app developer profits if prices were reduced on iOS following a reduction in Apple’s commissions. But as Professor Wright said, this reasoning is ultimately misleading as it does not consider the net effect of these effects, which is what is relevant to developer decisions.

2283    On the contrary, Professor Wright formally demonstrated that the net effect is positive for a single app developer offering its app on two substitutable channels. Professor Wright also explained that a net positive effect is likely when the app developer competes with apps that are not subject to the commission change. By contrast, Mr Houston did not provide any evidence nor formal economic analysis to support his view.

2284    I accept Professor Wright’s opinion that minimal developer pass-through in Professor Hitt’s natural experiments is indicative of a lack of substitution across channels. This is the most natural inference to draw from the economic evidence relating to pass-through and I have no hesitation in drawing it.

2285    Third, let me say something further about the quantity natural experiments.

2286    Now Professor Wright adapted Professor Hitt’s three natural experiments to consider whether Apple’s reduction in commission for some developers precipitated a change in the quantity billed on the App Store as opposed to a change only in developer prices. Professor Wright found that there was no clear shift in quantity following the reduction in Apple’s commission rate, which is consistent with app developers not improving the quality of their iOS apps, or putting in more effort such as by advertising, to divert app users to the App Store.

2287    These findings demonstrate that there was no user or developer substitution across channels in response to these price changes. They also demonstrate that there was no developer response that would affect demand for Apple’s services, such as a reduction in investment in the quality of the app.

2288    Now Professor Hitt agreed with the findings of Professor Wright’s quantity natural experiments. Professor Hitt accepted that if there is no pass-through into prices, there would not be any expected quantity change in response to a commission change. So, developers are unlikely to react to a commission change in a way that leads to lower levels of demand for their iOS apps and, therefore, for Apple’s services.

2289    But Professor Hitt then failed to explain why there was no quantity change despite there being, on his thesis, options for developers to react to the commission rate through quality adjustments and changes to business models. Quantity effects of this kind would be the most direct way to assess whether a change in iOS commissions actually affected quantity on iOS as opposed to other channels, and Professor Wright’s analyses demonstrated that there is no clear shift.

2290    Furthermore, Professor Wright demonstrated that for relative price changes in the other direction, that is, where Apple’s commission rate underwent a relative increase, there are similarly no observable quantity effects.

2291    Professor Wright concluded that, in January and February 2022, there was no noticeable change in the number of subscription transactions or in the number of subscription apps on the App Store following the large reduction in the Play Store’s commission for subscriptions. The change resulted in Apple’s effective commission rate being around 80% higher than Google’s for apps that were directly affected by the change. Despite the limited time period, if there is strong substitution across channels, one would have expected some decline in the number of subscription transactions through developers managing to divert some of their transactions to the Play Store with its significantly lower commissions.

2292    Professor Wright’s quantity natural experiments provide evidence that both users and developers do not react to substantial relative changes in iOS commission rates. They demonstrate that developers did not respond in any meaningful way that led to consumers changing their spending habits following a commission change on iOS. Professor Wright’s findings suggest the following.

2293    Developers do not treat other channels of distribution as substitutable for the App Store, as they did not seek to steer users to iOS in response to a reduction in Apple’s commission, or the flipside scenario, through price or quality adjustments or any other means.

2294    Further, users do not substitute spending on other channels with spending on iOS in response to a reduction in relative commission on iOS, or the flipside scenario, either directly or in response to lower levels of investment by developers.

2295    Professor Hitt’s only real criticism of Professor Wright’s quantity natural experiments was that the time horizon of one year may not be long enough to observe a relevant quantity response, or that quantity responses might occur “off-app” so as to not be detectable in App Store data. These are not convincing arguments for the following reasons.

2296    Professor Wright used the same data and time horizon for his quantity analysis as Professor Hitt himself used in his report in relation to the natural experiments. If one year would be a reasonable period to observe a change in price, it should remain a logically sound period to observe a change in quantity, especially in response to the same event.

2297    Further, as Professor Wright said, a one year time horizon is the normal period for the application of the HMT. It is unclear why a time period that is considered to be appropriate for antitrust economic analyses such as the HMT would be somehow inappropriate to observe a quantity response on iOS as a result of a significant change in Apple’s commission. If it takes more than a year to see any response in quantities, it can hardly be said that there are close competitive constraints.

2298    Further, developers may respond to a commission change in a myriad of ways, some of which may produce faster quantity responses on iOS than others. For example, if a developer were to respond to a commission reduction on iOS by offering exclusive in-app content, it is plausible to expect an increase in the volume of transactions on the App Store within a year period. On the other end of the spectrum, Professor Wright accepted that it is possible that a long-term change in developer investment into iOS, for example, less frequent updates compared to on other platforms, may not have a discernible quantity effect within a year.

2299    But on balance, given the potential breadth of developer quality responses to a change in iOS commission rate, it is telling that by the end of one year, there was no observable quantity change at all between Professor Wright’s control and treatment groups across the three natural experiments.

2300    Further, if anything, given the size of the commission changes in the natural experiments, one would have expected to see a larger quantity shift within one year than in response to a small price change. The fact that there was no clear shift at all within the time period undermines the opinions of Apple’s experts regarding substitution.

2301    Further, Apple has not adduced any evidence to substantiate Professor Hitt’s claim that extending the time horizon for the natural experiments would reveal a quantity response. The natural experiments were based on App Store data, and it would be reasonable to expect that if there were data from later years that supported his claim, Apple would have relied upon that data. As it stands, Professor Hitt’s argument does not rise above the level of mere conjecture. I reject it.

2302    Let me deal with one final matter by way of a thought experiment, which was raised by Professor Wright in his analysis.

What if the product is app transactions?

2303    Even assuming that the focal product is app transactions, encompassing app downloads, app updates and in-app purchases, according to Professor Wright this would not have altered his approach to the HMT framework and he would have found the existence of an app transactions market for iOS apps only.

2304    This is because his analysis had already considered all forms of potential and actual price-based substitution and constraints.

2305    In particular, as part of his various sensitivity analyses, he considered the profitability of a SSNIP applied on Apple’s full current commission rates across all paid transactions combined, that is, paid downloads and in-app purchases.

2306    Professor Wright considered the effect of the Australian App Store increasing its effective commission rate in 2021 by a SSNIP of 7.5%. He assumed this would apply as a 7.5% increase on the full commission collected for paid apps and iOS in-app purchases, that is, he assumed, for the sake of the exercise, that no share of Apple’s commission on iOS in-app purchases is attributable to the payment solution.

2307    As he explained, given the iOS app distribution conduct, Apple is currently the monopoly supplier of such distribution services with distribution taking place via the App Store. As such, evidence in relation to the App Store can help inform whether a hypothetical monopolist would face any close substitute(s) or indirect constraints so as to render a SSNIP unprofitable. He therefore referred interchangeably to the App Store and the hypothetical monopolist for the supply of iOS app distribution services.

2308    In response to such a SSNIP, few app developers would be likely to delist their apps from the App Store. This is because of the large and valuable app user base that the App Store provides, much of which is unique to iOS. App developers are much more likely to absorb some or all of the commission increase as lower net revenue, and pass-through any remaining part onto app users through higher app and/or in-app prices.

2309    So, Professor Wright considered that effectively all app developers would continue distributing their apps on the App Store.

2310    Professor Wright assumed that there would be an overall pass-through rate of 50%, even though economic theory suggests pass-through rates may be considerably lower than this. He expected that very few if any apps would exit from the App Store. These would likely be smaller apps that are Australia-focused and that over the relevant period generate limited iOS revenues so that they only marginally cover their fixed costs of remaining active on iOS. These apps would not have any material impact on the profitability of the SSNIP for Apple because such apps generate relatively little revenue and app users may simply substitute to alternative iOS apps when such apps leave and hence continue to generate commission revenue for the Australian App Store.

2311    So, Professor Wright considered that effectively all app developers would continue distributing their apps on the App Store.

2312    Professor Wright considered that app users affected by the price increase from the pass-through would reduce their demand for apps. He assumed a market elasticity of demand of -1, in line with the evidence reviewed.

2313    Based on these considerations, Professor Wright estimated that Apple would make an additional annual profit of AUD 39.7 million from the SSNIP. This additional profit would derive from Apple earning a higher commission on approximately the same user expenditure in line with the assumed overall elasticity of demand.

2314    So, Professor Wright concluded that such a SSNIP would be profitable.

2315    Now this supported an iOS-only app transactions market. But as I have indicated, Professor Wright did not consider app transactions as the product to be the correct lens through which to examine the effects of Apple’s conduct, and neither do I.

2316    Finally, Professor Wright considered that it is not appropriate to delineate markets by app genre, even if he were to have incorrectly adopted Professor Hitt’s and Mr Houston’s approach to defining the relevant product. I do not need to linger on this last point given my primary conclusion on product definition.

2317    In summary, in my view Professor Wright’s evidence and analysis is both cogent and compelling. His application of the HMT supports the product dimension of the relevant market contended for by Epic.

Concepts relevant to the behaviour of users

2318    In addressing the question of substitution, it is convenient to begin with some concepts, and for that purpose it is necessary to discuss some evidence from Professor Goldfarb.

2319    Now the questions Professor Goldfarb was asked to answer relate to two general areas.

2320    The first of those is the substitutability of usage of native apps on iOS devices with other apps, whether on the same or other devices. The second area relates to the substitutability of in-app purchases with out-of-app purchases.

2321    In responding to these questions, Professor Goldfarb relied on two key concepts that relate to how devices are used by consumers to help inform his conclusions around the substitutability of different types of apps, on different types of devices, and the substitutability of in-app and out-of-app purchases. These concepts have been labelled by Professor Goldfarb as “device first” and “clicks are costly”.

2322    I should say at the outset that generally speaking I accept these two concepts and Professor Goldfarb’s evidence concerning them. It will be convenient for me from time to time to use the labels, although I accept that they are not technical terms and the relevant literature hardly uses them as terms of art.

The concept of “device first”

2323    Device first describes a behaviour that users often exhibit in choosing devices to use and activities on those devices. By devices, one is referring to smartphones, PCs, tablets, and gaming consoles.

2324    The device first concept, related to circumstances where users look to engage in activities on electronic devices, has two key aspects. First, external factors such as context such as a free afternoon, and environment such as at home or work are central to the choice of device. Second, different devices are conducive to different usage experiences, such as gaming or watching a movie. For leisure activities, a user seeks to maximize enjoyment of leisure time subject to what devices are available to them, the amount of time they have to allocate, and their individual preferences.

2325    Even if the consumer has multiple devices available, like both a PC and smartphone, given time constraints or other preferences, gaming on smartphones versus PC or watching a movie on a smartphone versus streaming on a Smart TV may not be direct substitutes given the other constraints faced by a user.

2326    Nevertheless, device first is an important driver of behaviour, but not the only driver of behaviour. There could be examples where a user is indifferent between using one device or another given their devices available and use context. There are certain productive or communication activities that are particularly suited to one device or another, in which a user chooses the task first and then the device most suited: for example, work-related tasks or text messaging.

2327    Professor Goldfarb developed his understanding of this concept through his work studying differences in internet search behaviour and environmental context for consumers on mobile phones versus a PC. Specifically, this concept underlies his finding that smartphone searchers prefer geographically close brand results and top-ranking placements compared to consumers searching on PC. The device first concept is also consistent with other findings around consumer preferences across different devices leading to differing device choices depending on use context. He summarised these findings across several other academic studies.

2328    A paper by Jung et. al., (2019) encounters user behaviour related to device first when estimating the differences in user engagement with online dating Apps on smartphones versus PCs (Jung, J., Bapna, R., Ramaprasad, J., & Umyarov, A. “Love unshackled: identifying the effect of mobile app adoption in online dating” (2019) MIS Quarterly, 43(1), 47 to 72). The authors find that, on average, users are more engaged with online dating Apps on mobile phones and ultimately achieve more matches as they log in more often and throughout the day compared to PC use. Increased engagement with dating Apps via mobile phones was found to be related to ubiquitous access to smartphones, including more frequent, but shorter use sessions. The researchers additionally find differences in impulsivity and levels of inhibition in use of online dating Apps on smartphones versus PC, with differences in inhibition particularly strong for men.

2329    Professor Goldfarb considers that these differences could be reflective of differing user preferences leading them to seek smartphones over PC for use of this particular app or be reflective of the environment a user was in at the time. This appears to be reflective of a device first consumer decision making process, whereby a user with multiple spare moments throughout the day chooses to use their mobile phone and engage with an online dating app on their mobile phone given environment, time constraints, and device availability, making use of these Apps on smartphones of limited substitutability with PC.

2330    Aguiar (2019) also studied users’ allocation of time between smartphones and PCs across a broader set of content categories (Aguiar, Luis, “Going mobile: The effects of smartphone usage on internet consumption”, JRC Digital Economy Working Paper, No. 2019-07, European Commission, Joint Research Centre, Seville). Key differences were found in the ways users allocate time to different web domains through browsers or apps accessed on smartphones versus PC. The authors find empirical evidence of an increase in usage of social networking and gaming domains as smartphone usage increases relative to desktop, but that time spent on other domain categories such as shopping, news, search, money management, and price/product comparison is inversely related to smartphone usage. The authors note that the latter categories are ill-suited for smartphones, which have higher costs associated with searching and processing information.

2331    These findings, that different categories of activities are more suited to smartphones or PC and that user behaviour is different on smartphones and PCs, underlie the second aspect of the device first concept, that different devices are conducive to different usage experiences. These search and information processing costs are likely one reason why smartphone use might be associated with shorter but more frequent sessions and make it an appropriate device choice in some circumstances, while a PC would be an appropriate device choice when the user has more time available. The features of the device determine its selection and the extent to which it is a substitute or a complement for other devices.

2332    In Professor Goldfarb’s research with Ghose and Han (2013) (Ghose, A., Goldfarb, A., & Han, S. P. “How is the mobile Internet different? Search costs and local activities” (2013) Information Systems Research, 24(3), 613 to 631), the authors studied differences in the ways users deploy smartphones and PCs for internet search, finding that smartphone users show stronger preferences for brands that are geographically closer to their location and that the ranking of results is a more relevant factor on smartphones. The importance of geographic proximity suggests that users search on smartphones when on-the-go.

2333    That ranking results are more important emphasizes that, as detailed in Aguiar (2019), the cost of searching is higher on smartphones, leading users to have lower depth of searching, including the process of scrolling further down a screen to see lower ranked search results.

2334    Professor Goldfarb also found differences in search behaviour on smartphones versus PCs. Consumers who perform searches on both smartphones and PCs tend to have different components of their search process carried out on each device. While search on smartphones emphasizes more broad browsing, search on PC is more in-depth and occurs at a point when a consumer is more likely to make a purchase. This again demonstrates behaviour consistent with device first. Different devices are conducive to different usage experiences.

2335    Other literature also notes key differences between user behaviour on smart mobile devices and other devices.

2336    Lurie et. al. (2018) note that two factors are likely to directly and interactively affect mobile decision-making and choice (Lurie, N. H., Berger, J., Chen, Z., Li, B., Liu, H., Mason, C. H., ... & Venkatesan, R. “Everywhere and at all times: mobility, consumer decision-making, and choice” (2018) Customer Needs and Solutions, 5, 15 to 27 at 16). Those are a device’s capabilities and the extent those capabilities are available regardless of time and location, and mobile context or use setting defined by where the user is and what he or she is doing.

2337    Andrews et. al. (2016) also find that mobile context matters to users’ behaviour on devices, finding that consumer behaviour on smartphones, specifically susceptibility to mobile ads, varies depending on how crowded the use environment is (Andrews, M., Luo, X., Fang, Z., & Ghose, A. “Mobile ad effectiveness: Hyper-contextual targeting with crowdedness” (2016) Marketing Science, 35(2), 218 to 233).

2338    Ransbotham et. al. (2019) finds that content such as online reviews created on smart mobile devices are more concrete and less extreme than reviews created on desktop devices, though of lower quality (Ransbotham, Sam & Lurie, Nicholas & Liu, Hongju. “Creation and Consumption of Mobile Word of Mouth: How Are Mobile Reviews Different?” (2019) Marketing Science 38(5):773 to 792 at page 774, 786).

2339    These differences in user behaviour on smart mobile devices compared to desktop devices are consistent with users choosing different activities and approaches to those activities when using smart mobile devices. The device becomes central to the usage case, and hence external factors such as location and time available that determine device selection, play an important role in determining usage.

2340    As the above literature suggests, smart mobile devices have several key features that make them suitable for use in situations when other devices are unsuitable. For example, due to the small size, portability, and cellular data availability for smartphones, users often have the ability to use their smartphone in situations in which other devices, for example, a gaming console or PC, would be unavailable. In contrast, when users anticipate that they will have an extended period of time in the same place, they may sit in front of a PC. Once the device is chosen, features on smartphones such as geolocation can further assist a user in specific contexts, like looking for a local restaurant when away from home or having the ability to take photos for social media accounts with a built-in camera. Further, that gaming consoles have controllers and more advanced computer chip technology make them more suitable for intensive play. Once a user selects a device, all these factors affect the activity chosen.

2341    Like smartphones, tablets also have their own usage situations. An internal November 2016 Google document containing research on tablet users notes that of the tablet users surveyed, many described using their devices at a certain time, in a certain location each day (“Understanding Tablet Users). This description is consistent with the first aspect of device first, that external factors such as context and environment are central to the choice of device. For example, a tablet may be a user’s device of choice while at home but not in a fixed location within the home. Users may use tablets in such situations as lying in bed or while sitting on their couch and watching television at the same time.

2342    Because smart mobile device usage is often a function of situational convenience, if a user’s preferred smart mobile device app is unavailable, they are likely to choose a different activity or app on their smart mobile device rather than switch to an alternative non-smart mobile device.

2343    When Fortnite became unavailable on iPhones, users who previously played Fortnite on their iPhone while commuting, for example, are likely to have switched to an alternative activity on their iPhone during that time, such as playing a different smartphone game or scrolling a social media account. Further, mobile gaming enables on-the-go play as one important feature. Further, the advantages of gaming on mobile include that it is location-independent. Finally, mobile gaming can be a secondary, multitasking activity, meaning that users are playing a game on mobile while they are also watching TV. A PC or console would not be a viable substitute in such circumstances.

2344    Whilst playing Fortnite on PC may be an additional, complementary activity in which some smartphone Fortnite players engage, that PC-playing time is unlikely to replace the mobile device playing time.

2345    This evidence suggests users often display behaviour that suggests a concept that he calls “device first”. There are two key aspects to this concept.

2346    First, that several external factors are central to the choice of device, including location, time of day, Wi-Fi access, time, and mental attention available.

2347    Second, that different devices are conducive to different usage experiences in terms of time spent, information frictions, connectivity, and need for focus.

2348    Together, these features suggest that the usage of smartphones and other devices, by the same users, often involve different motivations and contexts.

2349    Now Professor Hitt made a number of assertions that Professor Goldfarb misapplied the literature and otherwise introduced concepts with no academic basis.

2350    Professor Hitt asserted that Professor Goldfarb’s definition of “device first” stated that consumers will choose which apps to use only after they have chosen a device. This is not correct. The concept of “device first” has two main components. First, external factors and environment are central to the choice of device. Second, different devices are conducive to different usage experiences.

2351    Professor Hitt quoted Professor Goldfarb’s explanations of “device first,” in that “context (e.g., free afternoon, spare five minutes before class) . . . [is] central to the choice of device,” that “different devices are conducive to different usage experiences,” and that “consumer preferences across different devices [lead] to differing device choices depending on use context”.

2352    Professor Goldfarb explained that device first describes a behavior that users often exhibit in choosing devices to use and activities on those devices. Professor Goldfarb further explained that device first is an important driver of behavior, but not the only driver of behavior.

2353    The literature from which Professor Goldfarb drew these concepts consisted of his own work and the work of other established researchers. This literature found that apps on different devices have different user experiences and context specific use cases leading to differing user behaviour. Contrary to Professor Hitt’s assertions, each of these papers established at least one of the two factors, that is, user experience and context.

2354    In Ghose, Goldfarb, and Han (2013), Professor Goldfarb found that differing environmental contexts and user experience lead to variation in internet browsing between mobile phones and personal computers.

2355    In Jung et al (2019), the authors noted that mobile app adoption induces users to become more socially engaged, relative to PC users. This is consistent with “device first”. Researchers find that the increased engagement on mobile phones is because mobile app users log in more frequently throughout the day compared to PC users. The authors of this paper themselves note that their findings show complementarity between mobile and PC usage of these apps.

2356    Professor Hitt stated that Aguiar (2019) only compares activity levels across devices. Professor Goldfarb summarised that the author finds that certain categories of apps (e.g., gaming and social networking) are more suitable for smartphones and others (e.g., shopping, news, search, money management, price/product comparison) are more suited to desktop.

2357    The authors stated that the empirical analysis shows an increase in the usage of social networking and gaming domains as smartphone usage increases relative to desktop. On the other hand, time spent on other domains categories such as shopping, news, search, money management, and price/product comparison decrease with an increase in smartphone usage.

2358    Professor Goldfarb emphasised that the authors noted that the latter categories are ill-suited for smartphones, which have higher costs associated with searching and processing information. In other words, different devices have different usage experiences and this paper addresses these differences.

2359    In Han et al., (2022), the authors focus on the consumer purchase decision process to demonstrate that different situational contexts lead to different usage patterns on devices; see Han, S., Han, J. K., Im, I., Jung, S. I., & Lee, J. W. “Mapping consumer’s cross-device usage for online search: Mobile-vs. PC-based search in the purchase decision process” (2022) Journal of Business Research, 142, 387 to 399, at 388. Specifically, consumers tend to engage in pre-research with mobile early, and then followed by PC-based search closer to the purchase date. Different devices also have marked differences in when or how they are used for a given purpose. In the case studied in the paper, this was for the search for information and price quotes, and ultimately, the purchase of a good.

2360    Andrews et. al. (2016) studied how mobile phone users react to ads when they find themselves in different contexts. The authors showed that consumers behave differently when their commute is crowded versus not. This provides direct evidence that use context and environment directly influences how users behave.

2361    Finally, Ransbotham et. al. (2019) studied the change in attitude of users when participating in the same activity (online reviews) but via different platforms (smartphone vs. non-smartphone). The study found that users provide different reviews when interacting on smartphones versus personal computers. The authors point out that mobile reviews tend to be in real-time and more concrete, which suggests that the situation (on-the-go versus at home) shapes how users interact.

2362    The research from these papers demonstrates “device first”. Each paper supports the points that either external factors are central to the choice of device, for example, location, time of day, mental attention, etc., and/or that different devices are conducive to different usage experiences in terms of time spent, information frictions, connectivity, and need for focus.

2363    The usage of smartphones and other devices, even by the same users, often involves different motivations and contexts.

2364    Applying the “device first” concept, Professor Goldfarb explained that native app usage on smartphones is highly dependent on external factors and environments. Further, it provides a different usage experience than non-smartphone app usage, that is, apps on desktop computers, laptop computers, or gaming consoles.

2365    So, consumers are not likely to treat native apps on smartphones, namely iOS apps on iOS devices, as substitutable with apps on desktop computers, laptop computers, or gaming consoles, except to a limited extent.

2366    Generally speaking I accept Professor Goldfarb’s “device first” concept.

The concept of “clicks are costly”

2367    Now “clicks are costly” is a phrase Professor Goldfarb used to describe the phenomenon of users finding the requirement to execute additional steps to perform activities on electronic devices such as information gathering or transaction, to be burdensome enough to deter the user from completing the activity.

2368    Evidence of this effect can be found in academic literature. Any type of friction that may exist between the desire of a consumer to buy or acquire a good and executing the buying or acquiring reduces the likelihood of the user following through.

2369    The frictions users experience need not only be actual clicks themselves but include cognitive costs and the cost of time. Users encounter such frictions while navigating screens that include clicks and scrolls, considering and understanding the prompts to ensure selecting the right buttons, any evaluation of potential risks in the process, the entering of sensitive information, and the cost of time that the process requires. As the information required becomes more complex, the cost increases, although there can be significant costs to even small steps or simple requests.

2370    Search costs in general have been widely studied in the economic literature. One strand of that literature aims to quantify the search costs present in different markets.

2371    In Honka, E. “Quantifying search and switching costs in the US auto insurance industry” (2014) The RAND Journal of Economics, 45(4), 847 to 884, the author quantified search costs in the automobile insurance market by analyzing the impact of the steps a customer must execute to obtain quotes from insurance providers. Honka finds that internet searches for quotes have a cost of $35 on average which is approximately 5% of the premium prices paid by consumers. In the study, search costs include, among other things, going to insurers’ websites, inputting car and driver characteristics, and consenting to information disclosures. The results suggest that consumers find these costs high enough as to deter them from engaging in further searches and save money, which the author mentions as the main driver for customer retention in this market.

2372    In Honka, E., Hortaçsu, A., & Vitorino, M. A. “Advertising, consumer awareness, and choice: Evidence from the US banking industry” (2017) The RAND Journal of Economics, 48(3), 611 to 646, similar results were shown in a different market, namely bank accounts. They estimate search costs associated with finding a new bank account in the US banking industry and find that search costs equal as much as about 30% of the interest earnings in bank accounts on average, which, similarly to the car insurance case, is a sizable amount relative to the end good in question but likely smaller in absolute terms.

2373    The study of Hu, M., Dang, C., & Chintagunta, P. K. “Search and learning at a daily deals website” (2019) Marketing Science, 38(4), 609 to 642 estimated search costs, among other relevant features, in online deals websites. The core of the business model studied involves daily emails to customers with offers of promotional deals. The search steps consumers execute in this context include clicking and scrolling both the email and website. The authors quantify search costs to be between $26 and $98 per deal (transaction), which is a significant share of the price at which the items studied (i.e., deals being advertised) are sold, and large relative to the time required to undertake the searches. In the paper, the mean price (USD) of a deal is $37.28 with a standard deviation of $109.64. Hence a search cost of $26 would represent a 69.74% of a deal with the average price.

2374    In Jeziorski, P., & Segal, I. “What makes them click: Empirical analysis of consumer demand for search advertising” (2015) American Economic Journal: Microeconomics, 7(3), 24 to 53, there was a study of the costs of search for consumers looking at advertising on the internet. In their paper, the authors use a mathematical model of ad clicking costs as a function of ad position, scrolling to get to the option, and a cost associated with the click itself. Part of the utility maximization process being modeled is that the user minimizes (costly) clicks relative to the benefit derived. The results of their paper show that search costs are 10 to 24 times bigger for an ad placed fifth than that placed first in an ad list. Again, simple process frictions such as scrolling down a page and clicking have a large impact on consumer completion of tasks, that is, consumer clicking through to an advertisement.

2375    Professor Goldfarb has also studied search costs in online markets, in particular in mobile settings. In his paper with Ghose and Han (2013), they show how different search costs are when comparing personal computing and smartphone browsing. Using data from an unnamed South Korean microblogging site (a la Twitter), they found that search costs are higher for smartphone searches than for personal computer browser searches.

2376    Professor Goldfarb notes that over the course of the development of the internet and online markets, many costs that were relevant in brick-and-mortar settings have decreased in online markets. In Professor Goldfarb’s paper (2019) (Goldfarb, A., & Tucker, C. “Digital economics” (2019) Journal of Economic Literature, 57(1), 3 to 43), the authors review how digital technology has changed economic activity by significantly reducing costs associated with the “traditional” economy, one of them being search costs. This does not mean, however, that search costs have become non-existent or are less relevant. Whilst lower search costs overall have allowed for business to grow and for the variety of goods being offered to increase, that is, it is easier to find rare and niche products for example, and less costly to display available items for sale online than in physical shelves, search costs remain large enough to have a meaningful impact on user behaviour.

2377    In short, there is strong evidence in academic literature that users find the various frictions they encounter when engaging in searches for a particular product or answer, or transactions to obtain a desired good, to have a cost. While this cost can differ depending on the channel used, such as smartphone versus computer and digital versus physical goods, the cost overall remains often surprisingly high. In situations where users encounter frictions, some users choose not to incur these high costs of the friction associated with additional clicks, and thus will not complete the associated transactions.

2378    Now the clicks are costly concept indicates that users should be more likely to execute transactions if there are fewer frictions in the process.

2379    Professor Goldfarb performed an analysis examining user iOS App Store transactions before and after Apple enabled iOS devices to allow for biometric user authentication in 2013, first with the introduction of Touch ID. The introduction of Touch ID decreased the number of steps required by a user to execute a transaction. Instead of having to enter a password each time to make a transaction, users only needed to touch the biometric sensor on their phone to make a purchase.

2380    Professor Goldfarb expected that due to the costs users associate with clicks, once users can more easily execute transactions through Touch ID biometric authentication rather than the additional click required with typing in passcodes and/or passwords, their number of transactions will increase.

2381    The analysis showed that users execute 13.84% more transactions per month when using a biometric enabled iPhone relative to a non-biometric enabled one. This is consistent with the clicks are costly concept.

2382    His analysis found a significant effect of biometric-enabled transaction flows on the number of transactions executed, underlining the concept that clicks are costly. That fewer clicks lead to more transactions in this example on iOS is more broadly applicable to the clicks are costly concept. This result indicates that two Apps with differing amounts of clicks, for example, native app versus web app, or differing payment models such as in-app and out-of-app, may not be strong substitutes if additional clicks on one form would lead to fewer transactions.

2383    Professor Goldfarb disagreed with the implication made by Professor Hitt that Professor Goldfarb has misapplied his own research. Despite the relevance to his analysis and resulting opinions, Professor Hitt did not substantively engage on these points.

2384    Honka (2014) refers to “clicks are costly” as “search and switching costs”. These costs are the “steps a consumer must execute to obtain quotes from insurance providers”. That the paper studies search costs in automobile insurance does not make it any less relevant for the matters here discussed, as Professor Hitt implied in his report.

2385    Professor Goldfarb noted that Professor Hitt’s arguments that these literature do not apply because they are not specifically about app distribution or purchase platforms is a moot point given that the entire practice of applied microeconomics is to study certain phenomena, for example, the impact of search costs on consumer behaviour, using available data in one specific market such as insurance markets and discussing how these points might generalize to other markets. To say a research paper is not applicable to understanding how consumers are impacted by general concepts like search costs would then invalidate most empirical microeconomic research.

2386    On the contrary, it highlights that consumers can face significant costs when selecting between otherwise potentially substitutable products. This is directly related to the matter at hand. It illustrates why consumers do not consider in-app purchases as substitutable with out-of-app purchases, except to a limited extent, and why consumers do not treat native apps on iOS as substitutable with web apps on iOS, except to a limited extent.

2387    Similar generalizable points can be drawn from a study of the US banking system by Honka et al (2017). Here, the authors not only establish that search costs impact consumers, but they quantify just how large search costs in the form of additional clicks are for consumers relative to the value of the good they are seeking.

2388    Hu et al (2019) provided search costs estimates for “online deals websites.” The authors estimate the search costs associated with scrolls, clicks and navigation through several windows, undertaken by users in order to purchase the deal they want. These actions are similar to the set of steps that an app user has to follow in order to conduct an out-of-app purchase.

2389    Relatedly, Jeziorski and Segal (2015) provides a theoretical foundation and empirical estimation of the costs associated to scrolling and clicking on ads (links). This paper shows how changing the position of ads (e.g., links or buttons) changes the cost of scrolling and clicking for consumers.

2390    Further, Professor Goldfarb referred to his own work in Ghose et al (2013). The authors studied how search costs vary when users complete the same set of tasks, which was to navigate and engage in a microblogging site, in different platforms. They found that, in this particular case, search costs were higher when completing tasks on a mobile device (smartphone) than when doing so on a personal computer. The authors explained that this is likely because the smaller screen generates a need to scroll to search more frequently on a mobile device. It was said because consumers exert more cognitive effort (and perhaps more physical effort) while scrolling down a list of items displayed on small screens, they expected the ranking effect based search costs to be higher on a mobile phone as compared to a PC. They expected this to be true regardless of whether users engage in directed search or undirected browsing.

2391    Across a range of products, each paper assessed frictions in digital markets, arising from clicks, scrolling, navigating through windows, and other actions.

2392    Professor Hitt did not adequately acknowledge that native app users have to undertake such actions in order to either access or use a web app or to make an out-of-app purchase. Understanding the considerable cost of these actions for consumers is thus relevant to Professor Goldfarb’s conclusions around substitution.

2393    Further, I should note that Apple accepted that additional clicks can add friction to a process. But Apple said that it does not follow that the degree of “clicking” involved in moving between devices and platforms is so significant as to prevent substitution in and of itself. I accept what Apple says. But it is one matter that must be considered.

2394    Further, I also agree with Apple that there is no abstract rule about how many clicks could lead to abandonment of transactions. One cannot realistically specify a number of clicks which will cause a user to abandon a transaction. The significance of clicks in any given case will depend on a combination of factors and the overall effect will be a question of degree.

2395    Now in one sense I can agree with all of this. But clearly the “clicks are costly” theory supports the notion that the greater the number of clicks required, the less the attraction to the user or potential user all else being equal, which may impact on the likelihood or prospect of substitution.

2396    Further, Apple’s offering of biometric features, which reduce clicks, is another reflection of the “clicks are costly” principle. As I have said, Professor Goldfarb tested this concept directly in the biometrics analysis he performed. As I have said, that analysis showed that Apple’s technology changes over time reduce frictions for consumers and increase the number of transactions that consumers make. With each additional click removed, consumers spend more.

2397    Now I agree with Epic that Professor Hitt made several criticisms about this biometric analysis without offering evidence to support his assertions or an alternative interpretation. They were unconvincing.

2398    Generally speaking, I accept Professor Goldfarb’s clicks are costly concept.

Is the relevant metric usage or spending?

2399    Let me address another conceptual difference between the experts.

2400    Now Apple said that a vice in Professor Goldfarb’s evidence was his focus on usage, rather than spending.

2401    Apple said that usage of apps on iOS is free and so generates no revenue for Apple. So, as Professor Hitt explained, when considering competitive constraints on the App Store, it is necessary to focus principally on paid transactions, that is, spending rather than usage.

2402    Now Professor Goldfarb sought to justify his focus on usage by saying that that is what gives consumers value. But Apple said that that in itself is a doubtful proposition, price being a much more direct measure of value than usage.

2403    But in any event, Apple says that the question of what gives consumers value is not the relevant question for market definition. The relevant question is what close constraints are there on the ability of Apple profitably to raise the price or reduce the quality of the relevant product it supplies?

2404    Accordingly, it says that it is necessary to focus on the sources of Apple’s revenue and profit, rather than the source of value to consumers.

2405    Moreover, Apple said that usage is not a good proxy for spending in the present case. That is because users do not necessarily spend, that is, make transactions, on the same platform as they use a particular app. So, usage and spending may be split across platforms.

2406    Now Professor Goldfarb accepted that, on occasion, Fortnite users pay and play on different platforms. But according to Apple he attempted to minimise the extent to which that occurs by reference to an analysis of Fortnite data in table 5 of one of his reports. But Apple says that that attempt should be rejected.

2407    Table 5 records that, between 1 January 2020 to 9 August 2020, close to 92% of Fortnite users who had a paid Fortnite transaction on a particular platform on a given day only played on that day on the same platform.

2408    Apple says that that analysis takes no account of users who transacted and played on a single day purchasing more V-Bucks than they spent during their play on that day, that is, users purchasing on one platform with a view to spending on that platform and other platforms on which they play over subsequent days.

2409    Indeed, Apple says that purchasing V-Bucks on one day and using them on another day is likely given that Epic sells V-Bucks in bundles that do not correspond to the price of digital items. So, if a user wished to purchase a skin for 1,200 V-Bucks, it would be necessary to purchase a bundle of 2,800 V-Bucks, being the next option above 1,000 V-Bucks. Apple says that facilitating this sort of activity is the point of Epic enabling cross-wallet functionality in Fortnite.

2410    Relatedly, Apple says that there is evidence of Fortnite users on both iOS and Android not paying where they play.

2411    So, between January and July 2020, a fair percentage of Fortnite users with gameplay on iOS and at least one Fortnite transaction made a purchase only on a non-iOS device; that is, they played on iOS, but paid only on non-iOS devices.

2412    Likewise, between February 2018 and November 2021, a majority of Android and Play Store Fortnite users transacted exclusively outside Android stores and the Play Store respectively.

2413    Further, Apple said that the Fortnite hotfix diversion further demonstrates that users can and do move between platforms.

2414    Professor Hitt estimated that the share of iOS user spending that was diverted to other platforms in the 4 and 12 weeks following the Fortnite hotfix was 36.9% and 29.3% respectively, resulting in Epic recapturing 48.8% and 37.1% of iOS user net revenue in those periods. Those figures are generally consistent with Professor Goldfarb’s calculations.

2415    Apple said that as Professor Hitt observed, on any view that is a substantial amount of movement of iOS user spending from one platform to others.

2416    Whilst the diversion figures reduce over longer periods, being to 28.5% and 23.7% of iOS user spending over 20 and 28 weeks respectively, those longer periods are more likely to be affected by events extraneous to the hotfix and are, therefore, less reliable.

2417    Apple said that it would be odd to think that a Fortnite user who had diverted their spending from iOS to other platforms for, say, 12 weeks following the hotfix, would suddenly decide, because of the hotfix rather than some new, extraneous event, to cease their Fortnite spending.

Analysis

2418    Now I have little concern with Epic’s focus on app usage in determining matters of substitution. It is either directly relevant or it is a useful proxy.

2419    I agree with Epic that spending, whilst not an irrelevant consideration, is not the sole or even best way of assessing the substitutability of iOS or Android app distribution services. App usage is an appropriate metric because it is the natural proxy for the acquisition of distribution services. One needs to download an app in order to use it. Moreover, I have accepted Epic’s case that the relevant product is distribution services, and not transactions.

2420    Now Professor Hitt and Mr Houston assert that user spending is the relevant metric rather than app usage. But I disagree.

2421    Apple benefits from the usage of iOS apps, indeed the mere usage. Apple does not charge any commission for free apps, but nonetheless gains a commercial benefit through making its hardware, software and services more attractive to consumers.

2422    Further, Apple benefits from the multi-platform rule under which Apple does not receive any commission from eligible apps. Specifically, the rule allows an iOS user to use content within their iOS app that they have purchased elsewhere, which promotes greater use of the iOS app. This delivers a series of indirect benefits to Apple.

2423    Similarly, as to the reader rule, it is clear that even without receiving a commission, there would be indirect benefits to Apple from having more good apps on the App Store.

2424    Further, Professor Hitt acknowledged that free apps are an important part of the value created by the App Store for users, and that services relating to these apps are a critical part of the services offered by the App Store. But if that be so, this reflects the relevance of usage as a metric to assess substitution. An exclusive focus on user spending is not appropriate.

2425    Moreover, as well as these direct benefits to Apple arising from app usage, Professor Goldfarb explained that usage of native iOS apps provides benefits to developers across all monetization strategies, including through direct network effects. And as should be apparent, the usage of an app also generates benefits for users.

2426    Now Professor Hitt claimed that multi-homing gives users the ability and incentive to alter the value or volume of transactions they make without changing the devices they own, or how they use those devices. He asserted that a consumer facing a price increase for transactions for content through one platform could choose instead to make their transactions on another platform without shifting the amount of time they spend playing from one device to another.

2427    But I agree with Epic that the evidence demonstrates that users are unlikely to switch in this way. Now Professor Hitt sought to address the common occurrence where users may not have their PC or console with them by positing that users may substitute between transactions inter-temporally, but there was little evidence that users do this.

2428    Further, I agree with Epic that Professor Hitt’s and Mr Houston’s position further depends on their problematic view that the relevant product is transactions, which I have not accepted.

2429    I also agree with Epic that their position fails to engage with the benefits Apple, developers and users obtain from usage and is narrowly focused on the manner in which Apple presently monetises its services.

2430    Further, Professor Goldfarb analysed Fortnite data and found that there was a strong correlation between a user’s total expenditure and total playtime and between the proportion of their expenditure and usage which takes place on a given platform. Indeed, it is likely that the longer a user spends in an app, the more likely they are to make in-app purchases.

2431    This is intuitive in the context of Fortnite, as Epic said. For example, two friends may play or use Fortnite together with only one making in-app purchases. It is reasonable to expect that, if the non-paying user stops playing Fortnite, the enjoyment their friend (the paying user) derives from Fortnite is diminished and they may make fewer or no in-app purchases as a result.

2432    Further, I accept Epic’s position that the positive correlation between usage and spend was an important reason why Epic implemented cross-play on Fortnite. Cross-play refers to the ability of Fortnite users who access the game from different platforms (eg, Xbox and iOS) to play together in the same session of Fortnite.

2433    Further, as Epic points out, Professor Hitt’s own findings suggest that usage and spend are likely to be correlated. Based on the Fortnite data, he found that Fortnite users spend the vast majority (91.5%) of their time playing Fortnite on non-iOS devices. Further, he found that the vast majority of Epic’s Fortnite revenue (91%) is generated on non-iOS platforms.

2434    Let me address Professor Asker’s analysis.

2435    Professor Asker focused only on substitution in revenue but acknowledged that usage was linked to revenues because of the importance of indirect network effects. But this supports Professor Goldfarb’s point that usage is relevant to understanding indirect network effects at least.

2436    Further, as Professor Goldfarb and Ms Edwards-Warren explained, the network effects created by different usage patterns may take time to have an impact upon spending. As a result, understanding substitution of usage is important to understand revenue substitution. Further, substitution in usage of one app may also affect usage and spending on other apps, thereby having broader network effects. Considering only users that spend also excludes the majority of users and apps.

2437    I agree with Epic that all these matters indicate that both usage and spending are relevant to the substitution inquiry in the present case, consistent with Professor Goldfarb’s evidence as to the strong correlation between the two.

2438    Further and in any event, Professor Wright’s SSNIP analysis took into account spend.

2439    Let me now turn to some specific topics concerning competitive constraints and substitution.

Competitive constraints and substitution — mobile vs non-mobile

2440    Now Apple put a case that significant competitive constraints and substitution existed as between mobile and non-mobile services, particularly concerning playing games and game apps.

2441    Of course Epic’s case was not confined to game apps, so substitution (if any) in that narrower dimension does not answer Epic’s case concerning its product definition of the relevant market. But if I had accepted Apple’s ambitious app transactions market, then Apple’s point might have more force in the context of its formulated market definition. But Apple’s point is generally relevant to broader competition questions in any event.

2442    Now as Apple contends that questions of substitution, market definition and market power as they relate to game apps must be assessed in the particular technological context in which apps are downloaded, accessed and played, and in which transactions relating to in-app content occur, let me begin by setting out the various types of devices used to play games and engage in game app transactions.

2443    Generally there are devices such as laptop computers including Windows and macOS versions, desktop computers (PCs) including Windows and macOS versions, iOS mobile smartphone devices, Android mobile smartphone devices, iPads, being tablets manufactured by Apple and operated using iOS, and tablets using non-Apple operating systems, in particular Android. Let me elaborate on some others.

2444    Nintendo Switch is a handheld gaming console manufactured by Nintendo. It is designed to operate either in a fixed console mode when it is plugged into its dock, or as a handheld console. If it is played in fixed mode, it is connected to a TV or other monitor with a cable.

2445    In handheld mode, it can be played offline or connected to wireless internet, including by using a hotspot internet connection through a mobile device. In handheld mode, a Nintendo Switch has a built-in display and battery life sufficient to maintain a reasonable gaming session. It is functionally equivalent to a tablet, but with physical game controls integrated on either side of the screen.

2446    PlayStation is a gaming console manufactured by Sony. Its primary mode of operation requires being connected to a TV or a monitor display using an HDMI cable, with the console connected to the internet through either a wireless connection or a cable. The user uses the game controller, which is connected to the console using Bluetooth or a wire.

2447    PlayStation 5 has a web browser that can be accessed by the user.

2448    PlayStation can be used in remote play mode, where the game runs on the console but the game is displayed and played on a mobile or iPad that is connected to the console through the internet. A PlayStation controller can be connected to the mobile phone or iPad using Bluetooth.

2449    PlayStation Portal Remote Player is a dedicated device that is used to play remotely through a PlayStation console. Remote play requires a wi-fi connection, including by hot-spotting from a mobile device.

2450    Xbox is a console manufactured by Microsoft. It connects to a TV or monitor using an HDMI cable and connects to the internet using through a wireless connection or a cable. It has a game controller that connects to the Xbox using a Bluetooth connection or a wire.

2451    Xbox can be played in remote play mode using a mobile or tablet that is connected to the internet. An Xbox controller can be connected to the mobile phone or tablet using Bluetooth.

2452    Microsoft does not yet have a dedicated device for remote play, but there have been media reports suggesting that Microsoft is intending to launch one.

2453    There are various manufacturers of Windows laptops. They connect to the internet through a wireless connection or a cable and are operated primarily using a mouse or a keyboard. It is also possible to use a dedicated game controller on a laptop, either through Bluetooth connection or a wired connection. Web browsers are a standard feature of every laptop operating system.

2454    Smartphones and tablets all have web browsers and touchscreen controllers. They can all be connected to a dedicated game controller using a Bluetooth connection.

2455    Another handheld device that can be used to play games is a Steam Deck, which is manufactured and distributed by Valve, the operators of the Steam app store. A Steam Deck can be used offline or online using a wireless connection. A similar handheld gaming device is the ROG Ally.

2456    Like the Nintendo Switch, a Steam Deck can be connected to a TV or monitor, or used as a handheld mobile device with a built-in display, controls and battery life sufficient to maintain a reasonable gaming session.

2457    Smart TVs are televisions with internet connections that can run apps on the television. The Samsung Gaming Hub can be used to play games on smart TVs. Samsung promotes Fortnite as a featured game on the Samsung Gaming Hub. It is played through game streaming services.

2458    Further, virtual reality headsets can also be used. Meta sells a MetaQuest virtual reality headset. Meta also distributes games that can be played using the headset. And Apple distributes a similar virtual reality headset called the Vision Pro, which can access a web browser.

2459    Let me identify the options for distributing game apps and transactions for digital content.

2460    Now the following distribution and access channels exist for either downloading or accessing game apps on smartphones and tablets: web app distribution via a web browser, that is, non-native apps; websites for playing games directly through a browser; the App Store for iOS native apps; the Android marketplaces for native Android apps, being Google’s Play Store and other Android third party app stores, for example, Samsung Galaxy Store and Amazon Appstore; direct distribution websites for sideloading of native apps on Android devices; game streaming services; game subscription services; websites directly distributing in-app content; examples include the Epic Games Store website, Xbox store, and the PlayStation store.

2461    The following distribution and access channels exist for either downloading or accessing game apps on laptops and desktops utilising Windows and/or iOS: online app stores, such as the Mac App Store, Steam and PC game stores; websites for direct distribution of native apps; websites for direct distribution of in-app content; game streaming services; game subscription services; websites directly distributing in-app content such as the Epic Games Store website, Xbox store, and PlayStation store; Google Play Games for PC, which was released in 2022 and is an emulator that enables a device to run software designed for another platform.

2462    Google Play Games for PC enables users to play on their PCs games accessed through the Play Store and designed for Android. It is now available in over 50 countries across the world with over 250 titles.

2463    Each of the gaming consoles Xbox, PlayStation and Nintendo operate their own console specific stores.

2464    When it comes to conducting transactions for in-app digital content for game apps, the following platforms are available in Australia: PC platforms such as Steam, Microsoft Store and the Mac App Store; device-specific platforms for smartphones and tablets such as the App Store, the Play Store, Huawei AppGallery and Samsung Galaxy Store; console-specific platforms such as the Sony PlayStation Store, the Microsoft Store for Xbox and the Nintendo eShop; web browsers accessing publisher-owned stores such as Epic Games Store, CD project and Electronic Arts where transactions occur through the developer’s website; web browsers accessing indie game stores, such as Green Man Gaming, Humble Bumble, Indie Gala, and itch.io.; web portals, such as Agame, Big Fish Games and Crazy Games; games subscriptions services where games may be downloaded for a monthly price, such as Apple Arcade and Netflix Games; cloud gaming services, where app users can live stream games via remote servers, such as Xbox Cloud Gaming (XCG), NVIDIA GeForce Now, PlayStation Plus Premium and Amazon Luna; and social media platforms such as Meta and Twitch.

2465    Let me set out a brief description of game streaming services, although I have dealt with web streaming in more detail elsewhere.

2466    Game streaming services enable users to play games on a device, including a PC, gaming console, smartphone or tablet that is connected to the internet, without the games in question being installed as apps on the user’s device. Processing of the game occurs remotely, on servers accessed by the internet which receive and send signals from the user, with video of the game streamed to the user’s device.

2467    Game streaming services are growing in popularity as a distribution method. The emergence of game streaming as an option for users and developers, and a competitive constraint on pre-existing platforms, exemplifies a broader point. The games industry is a fast-moving industry when it comes to technological change. The platforms available on computer, console and mobile apps, game streaming services and websites have evolved rapidly over time and continue to do so.

2468    The trend is towards improvements in the performance and popularity of game streaming services. This will be linked to technological improvements in the capabilities of remote servers, continued advancements in internet speeds and reduction in costs as scale increases.

2469    As I have said elsewhere, I accept that such services may in certain contexts be substitutes. But they are not on any reasonable view close substitutes, particularly given their technical limitations and difficulties referable to the user experience.

2470    Further, as Apple has identified, there are other services for accessing games.

2471    A related and in some cases overlapping way of accessing games is through a game subscription service. These involve a developer or an app store providing users with access to a library of first-party games developed by the owner of the service and/or third-party games on a subscription basis. Such games may be available for download and/or streamed using cloud internet functionality.

2472    Game subscription services have grown in popularity since 2014. Examples of popular game subscription services include the following.

2473    EA’s Origin Access is a service that was first launched on the PC and Xbox One in 2014, then on PlayStation 4 in 2019, then Steam in 2020. It has since been rebranded to EA Play Basic and EA Play Pro.

2474    Google Play Pass is a service that is offered by Google and gives users of Android devices access to over 450 games. Google pays royalties to developers to publish games.

2475    Apple Arcade is a service that is offered by Apple and gives users of iPhones, iPads, Mac computers and Apple TV access to over 200 games. Apple Arcade supports cross-progression so that users can start playing a game on one device and then pick up where they left off on another Apple device.

2476    Xbox Game Pass is Microsoft’s game subscription service for Xbox which provides users with access to hundreds of first-party and third-party games. Microsoft offers an equivalent service for Windows PCs. The highest Game Pass subscription, Xbox Game Pass Ultimate, allows users to access the library from their Xbox or PC and stream Xbox games to other devices using Xbox Cloud Gaming. In June 2023, Microsoft announced that it had executed a deal with NVIDIA to provide for the streaming of PC titles available through Game Pass via NVIDIA’s GeForce Now streaming service.

2477    PlayStation Plus (formerly PlayStation Now) is Sony’s game subscription service for PlayStation which offers hundreds of first-party and third-party games to users and enables them to play purchased games online. The highest subscription tier expands the library of games available to users and allows them to access games using cloud streaming on a test basis.

2478    Netflix Games is available within the Netflix App on iOS through the App Store and Android devices through the Play Store, and via Netflix’s video streaming service.

2479    Ubisoft+ is a service offered by Ubisoft on Windows PCs and Xbox. Some games in Ubisoft+ can be streamed using Amazon Luna. Games in Ubisoft+ are also available via streaming on GeForce Now.

2480    GameClub is a service offered by Take-Two Interactive on iOS and Android devices. Cross-play between Android and iOS devices is available for some games accessed via GameClub.

2481    Nintendo Switch Online is a service offered by Nintendo for the Nintendo Switch.

2482    Now before proceeding further, it is necessary to say something more about the technical concepts applicable to the operation of games.

2483    Many games are monetised by facilitating in-app transactions using a digital currency that is acquired with real money, and then available to be spent to acquire digital content associated with the game.

2484    Cross-wallet functionality in a game means that a user may acquire game currency for their account on one platform but spend that currency on a different platform. Cross-wallet functionality makes it easier for users to switch platforms, which includes switching to iOS and switching away from iOS. Cross-wallet functionality can promote greater use of the iOS app, which delivers indirect benefits to Apple.

2485    In most cases, the user experience to effect transactions to purchase game content or bonus features is substantially the same on different platforms. For example, in Fortnite, a user who purchases V-Bucks from the Epic Games Store website via a web browser can use those V-Bucks on in-game purchases on their mobile phone, PC or console. All consoles have cross-wallet functionality except Nintendo.

2486    Cross-platform play or cross-play enables users to play the same game across platforms, so that users playing a game on one platform, for example, a console can play with or against users on a different platform, for example, a PC. For example, PC and mobile users can battle each other in Star Trek: Fleet Command and PC, mobile, Xbox, PlayStation and Nintendo Switch users can all play in the same session of Among Us. Successful cross-play games include Minecraft, Hearthstone, Roblox, Genshin Impact, and Rocket League, each of which can be cross-played between mobile and PC.

2487    Cross-progression functionality allows a user to play and progress within a game on one device and then continue their progression for that game on another device. As with cross-wallet functionality, this is facilitated by the user operating an account that can be activated on multiple devices and platforms. Games with cross-progression functionality include Call of Duty: Modern Warfare and Star Trek: Fleet Command.

2488    In around 2017 developers, including Epic and Microsoft, began approaching Apple expressing the view that cross-platform and cross-wallet play was a growing trend in gaming and should be facilitated. In around 2018, Fortnite became the first AAA game to enable cross-platform play functionality across consoles, PCs and mobile devices.

2489    If Apple wanted to continue to be viewed favourably by developers and consumers, it had to offer comparable features to other game transaction platforms, such as cross-platform and cross-wallet play. In light of these trends, and in response to developer feedback, Apple decided to permit this capability in apps on the App Store.

2490    Apple’s rules allow for in-app content acquired elsewhere to be used within native apps downloaded from the App Store. Pursuant to the reader rule and multi-platform rule, consumers can use content purchased outside an iOS app, inside an iOS app, without making any in-app payments. So, users that have purchased subscriptions to Netflix via their website can access the content under those subscriptions in their iOS apps without making any payment for the subscription or any additional content they may choose to access.

2491    The multi-platform rule creates convenience and efficiencies for users who utilise different app marketplaces for gaming. Apple receives no commission on paid content purchased through other platforms and used in apps on iOS devices. Moreover, Apple does not impose pricing parity requirements on developers and pricing is at the discretion of developers using the price matrix.

2492    Through the combination of cross-progression and cross-wallet functionality on multi-platform games, users can shift between devices. This in turn encourages them to play each game more frequently.

2493    Epic was involved in the promotion of cross-play, cross-purchase and cross-progression, and has benefited from those functionalities. Cross-play in particular results in users spending more time and money. These functions serve to facilitate users moving freely between devices when playing, and conducting transactions in relation to, Fortnite.

2494    Of course some of these concepts also apply to non-game contexts.

2495    Let me say something about multi-homing by users, which is relevant to the question of substitution.

2496    A characteristic of app users and developers with respect to game app transactions is that they engage in multi-homing, that is, they make transactions facilitated by many platforms across a range of devices. So, there is the ability of app users and developers to substitute transactions across platforms.

2497    App users make use of multiple platforms. Many iOS users have access to devices with other game app transaction platforms.

2498    An Apple survey of iPhone owners in October 2020 found that 46% owned a Mac laptop or desktop, 56% owned a Windows PC laptop or desktop, 25% owed a gaming console and 9% owned a non-iPad tablet. An Apple survey of iPad buyers in June-September 2021 found that 58% owned a Windows PC laptop or desktop, 19% owned a gaming console and 17% owned a non-iPhone smartphone.

2499    The ability to transact through a web browser or a game streaming service, as an alternative to transacting within a native app, means that alternative platforms can be available even on the same device including on an iOS device.

2500    The following particular characteristics of game app transactions and real world competition also demonstrate that transactions on other platforms are substitutes for game app transactions on iOS.

2501    First, the same transactions, for example, the purchase of V-Bucks, can be effected across multiple platforms including PCs, consoles and web streaming services.

2502    Second, substitution occurs not just within the same game, but also between similar games on different platforms.

2503    Third, there is growing cannibalisation between handheld gaming devices, such as the Nintendo Switch, Steam Deck and ASUS ROG Ally, and smartphones.

2504    Fourth, cloud gaming services can offer a comparable gaming experience to native PC and console game apps, and their revenues continue to grow. This demonstrates their ability to affect the market power of the App Store and other game app transaction platforms.

2505    Fifth, if app users own multiple devices such as iPads, PCs, Android phones, handheld game devices, smart TVs, etc, then distribution of apps on iOS devices can be a substitute for distribution of apps used on non-iOS devices, including devices that are not smartphones or tablets.

2506    Let me at this point say something about Fortnite.

Fortnite — relevant features

2507    Fortnite is free to download. Further, Fortnite is available to play, without downloading any native app, through game streaming services.

2508    Now because of cross-play functionality, Fortnite can be played by users on any device where the game is available, and players within a game of Battle Royale can play against others who are playing the same game on a different device or platform.

2509    Further, because of cross-progression functionality, the progress that a user makes playing the game on any particular device or platform will be recognised on any other device or platform where that user plays Fortnite.

2510    Further, the primary method of monetisation of Fortnite involves users spending real money to acquire V-bucks. V-bucks can be acquired from within the app on any device or platform, within the game on a streaming service or at the Epic Games Store on the internet. It is not possible to acquire V-bucks, or spend V-bucks, while playing the game.

2511    Because of cross-wallet functionality, where a user acquires V-bucks from any source, those V-bucks will be associated with the user’s account and be available to be spent on any device or platform, with the exception of Nintendo Switch.

2512    Further, any digital content acquired by a user by spending V-bucks remains accessible by the user on any device or platform.

2513    Further, Fortnite is available via game streaming services in Australia. That option is actively promoted by Epic, including as a means of playing Fortnite on iPhones. The Epic website states that there are many ways to play Fortnite on mobile devices. Further, for example, in March 2020, Mr Sweeney published a tweet stating that cloud streaming services will also be key players in ending the iOS and Google payment monopolies and the 30% “taxes” imposed by Apple and Google.

2514    In addition to Epic, various of the game streaming services actively promote playing Fortnite on their service. NVIDIA promotes Fortnite as a game available to be played through its GeForce Now streaming service. The GeForce website promotes powerful 4K cloud gaming being available in Australia. There is full cross-wallet, cross-progression and cross-play through NVIDIA GeForce Now.

2515    In May 2022, Microsoft introduced Xbox Cloud Gaming in Australia. Mr Sweeney expressed his excitement about this development in a tweet at the time. Mr Sweeney described the launch of Xbox Cloud Gaming as “monumental” news because Fortnite became available via Xbox Cloud Gaming to play for free, streaming on web browsers on iPhone, iPad and Android. Through that mode of access, there is no need for a subscription to the streaming service. Epic does not need to pay any commission to Apple or Google for in-app purchases made through the streaming service. Further, Epic has encouraged users to play Fortnite on Xbox Cloud Gaming.

2516    Further, when Mr Grant announced the launch of Fortnite on Xbox Cloud Gaming, he noted that anything with a web browser could run Fortnite. Further, Xbox Cloud Gaming used Epic’s Fortnite mobile touch controls, so that a user could play Fortnite on an iOS or Android device without having to buy an external game controller.

2517    Fortnite can now be played using the following devices and connection methods: on an Xbox console, using the Fortnite app downloaded on the console, or using a game streaming service through the web browser on the console; on a smartphone or tablet device, connected remotely to an Xbox console using the Fortnite app downloaded on the console; on a PlayStation 4 or PlayStation 5, using the Fortnite app downloaded on the console, or using a game streaming service through the web browser on the console; on a smartphone or tablet device, connected remotely to a PlayStation 4 or PlayStation 5 console using the Fortnite app downloaded on the console; on a PlayStation Remote Portal, connected remotely to a PlayStation 4 or PlayStation 5 console using the Fortnite app downloaded on the console; on a Nintendo Switch, using the Fortnite app downloaded on the device; on a Steam Deck device or a ROG Ally device, using a game streaming service; on an Android smartphone or tablet device, using the Fortnite native app downloaded through the Samsung Galaxy Store, or directly downloaded from the Epic Games Store; on an Android smartphone or tablet device, using a game streaming service through a web browser or a game streaming app; on an iOS smartphone or tablet device, using a game streaming service through a web browser; on a laptop or desktop Windows computer, using the Fortnite app downloaded from the Epic Games Store in the case of a Windows laptop or using a game streaming service through the web browser on the computer; and on a laptop or desktop macOS computer, using a game streaming service through the web browser on the computer.

2518    Further, Fortnite is promoted on the basis that it is the same game across all platforms, notwithstanding that there are variations in the technical performance of the game on different platforms.

2519    Now as Apple points out, decisions about the development and exploitation of Fortnite have been informed by data about the behaviour of users, in terms of both play and expenditure, across different devices.

2520    I accept that levels of retention and monetisation of Fortnite players were lower on iOS and Android than on other platforms. And I also accept that hard-core gamers, who play more regularly and for longer, tend to play Fortnite more on console whereas casual gamers tend to play more on mobile.

2521    Further, Epic’s customers generally make transactions through multiple platforms.

2522    Professor Hitt engaged in a detailed analysis of Fortnite user behaviour with respect to app transactions and sources of Epic’s Fortnite revenues. His analysis revealed the following.

2523    First, in the period 26 February 2018 to 9 August 2020, before Fortnite was removed from the App Store, only 9.04% of Fortnite revenue in Australia was through the App Store.

2524    Second, in the period 26 February 2018 to 9 August 2020, Fortnite users who made transactions via the App Store spent approximately five times more on Fortnite on other transaction platforms such as PlayStation Store and Xbox.

2525    Third, between January and July 2020: (a) 25.9% of app users with an iOS purchase in Fortnite also made purchases on a different platform; (b) among Fortnite users with gameplay on iOS and who had at least one Fortnite transaction, 61.5% also purchased on a platform other than iOS; (c) 38.2% of app users who purchased V-Bucks on iOS also redeemed them on a different platform; (d) 23.8% of app users who redeemed V-Bucks on iOS also purchased V-Bucks on a different platform.

2526    Fourth, in the four weeks following the removal of Fortnite from the App Store, 36.9% of gross iOS spending on Fortnite in Australia moved to other platforms.

2527    Now according to Apple, this data is indicative of the existence and substitutability of rival game app transaction platforms through which Epic transacts with Fortnite users. I accept that there is some substitution, but none of the points that Apple has made indicates close substitutability such as to impact on questions of market definition.

2528    More generally Professor Hitt said that for each platform on which Fortnite is available, a large number of Fortnite users already access Fortnite on at least one additional device. These users could therefore make game app transactions for Fortnite through those different game app transaction platforms. This demonstrates that these consumers can easily substitute game app transactions through other platforms.

2529    Professor Hitt said that the specific subset of users who accessed Fortnite on iOS spend the vast majority of their time and money with regard to Fortnite on non-iOS devices and through game app transactions other than the App Store.

2530    Professor Hitt said that many Fortnite players on iOS make purchases, including purchases of V-Bucks, on alternative game app transaction.

2531    Professor Hitt said that Fortnite users spent the vast majority of their time playing Fortnite on non-iOS devices, and the vast majority of Epic’s Fortnite revenue was generated on non-iOS platforms.

2532    But Professor Hitt had to accept that these measures of multi-homing were not informative of whether these purported alternatives are close substitutes for the services provided by the App Store. Considering multi-homing in isolation does not really advance the correct inquiry.

2533    Further, I also agree with Epic that Mr Schiller’s assertions that of iOS Fortnite users who made paid transactions between January 2020 to July 2020, more than half only made purchases on non-iOS platforms, and that this content was nevertheless accessible on iOS devices, only evidences multi-homing behaviour.

2534    Further, according to Apple, users do not pay where they play. But in my view, if this is meant to be a statement of general application then it is false. In my view, the reverse position is the general rule. Users generally speaking pay where they play.

2535    Now Apple criticised Professor Goldfarb’s analysis of Fortnite data that showed that users overwhelmingly pay where they play in the course of a day, primarily on the basis that users may purchase V-bucks on one day and use them on a different platform on another day. But as Epic said, the premise for this criticism was that users were likely to purchase more V-bucks than they immediately needed.

2536    But as Professor Goldfarb pointed out, the Fortnite data shows that the most common purchase is of the lowest amount of V-bucks. Moreover, his view was that if users did not pay and play on different platforms within a single day, there was no reason to think they were likely to do so from one day to the next.

2537    Moreover, there is a strong correlation between the propensity of a user to play on a platform and pay on that same platform.

2538    Now Apple pointed to evidence of instances in which a user with game play on iOS and at least one Fortnite transaction made a purchase only on a non-iOS device as evidence of users not playing where they pay. But as Professor Goldfarb explained, these statistics were not consistent with users not paying where they play, namely, that they do not measure the type of behaviour sought to be measured. He also addressed similar data and explained why it was not relevant. These statistics could capture instances of users who might only have played once on iOS, but otherwise played and spent on non-iOS platforms.

2539    Further, the vast majority of Epic’s active user base uses either PC or console. The percentage of users using streaming services is in the same ballpark as the percentage of users that play on Android.

2540    There are cohorts of gamers who prefer to play the same game on a mobile device rather than play the game on PC.

2541    It is not uncommon for players to play a game across multiple devices and to pick up on one device a point of gameplay reached on another device.

2542    I have separately discussed Google’s quantitative analysis elsewhere.

Perspective of developers

2543    Let me say something more on the matter from the perspective of developers and the relevant evidence.

2544    Now some developers seek to release their apps on both mobile and non-mobile platforms, where that is technically feasible and sensible. It would seem that developers recognise the discrete user bases and use cases.

2545    Epic launched Fortnite on mobile devices even though the app was already available on PC and consoles. As Mr Sweeney explained, to expand the Fortnite user base, he believed that it was necessary to make Fortnite accessible to users across as many devices as possible, and that expanding onto mobile would attract new users who may have heard about Fortnite, but who did not or did not usually play games on a personal computer or console.

2546    Mr Sweeney’s views about the desirability of making Fortnite available on mobile were based on his understanding of the differences between mobile and non-mobile devices, and the distinct user bases on those platforms.

2547    He said that there are important differences between personal computers, consoles and mobile devices. Consoles are almost exclusively used for gaming whereas personal computers and mobile devices are general purpose devices, which have a wide range of functions including web browsing, sending and receiving emails and operating software applications. It was his understanding that many people who owned mobile devices did not own personal computers or consoles. He perceived that mobile devices were treated as a necessity and were owned by many people who would never engage with Fortnite on a personal computer or console.

2548    Mr Sweeney explained that he saw expanding onto mobile as an opportunity to enable existing Fortnite users to play Fortnite when they were away from their PC or console.

2549    But device differences also pose challenges for developers who make their apps available across mobile and non-mobile platforms. Mr Sweeney gave evidence of challenges Epic confronted when seeking to optimise Fortnite for mobile devices due to smaller screen size, lower quality display, and the need to accommodate touch screen controls. These challenges make clear that developers cannot easily switch between distributing apps on mobile devices and non-mobile devices, or vice versa, even if that were otherwise commercially attractive.

2550    Mr Sweeney’s views about the complementary or supplementary nature of mobile and non-mobile devices were tested in cross-examination. He gave the following evidence which I accept.

2551    When it was put to Mr Sweeney that if PCs and consoles did not compete with mobile platforms, there would be no point highlighting their relative value propositions, Mr Sweeney responded that one could highlight their value propositions because they are complementary and that both could be a valuable part of a user’s life and gaming interests. He said that gamers use mobile devices to play games in some contexts, like when they are on the go, and they use consoles to play games in other contexts, which is when they are using their television. And he said that some gamers use both in different scenarios.

2552    When asked whether he regarded consoles and PCs as competing with mobile platforms for gamers, Mr Sweeney said that he did not think that they are in competition. He said that a console does not fit in one’s pocket, but in a broader sense, they are all devices that a user could use to play a game in various situations. He did not think that anybody could possibly choose a console instead of a mobile device.

2553    When taken to a document in which Mr Sweeney said that bringing Fortnite to iOS and Android would sell a lot of Xboxes, he explained that when a user is at their TV, the user would want to have the better experience, but when the user is on the go, the user could have the mobile experience.

2554    Mr Sweeney explained his use of the word “complementary” in the following terms:

Well, your Honour, what I mean specifically here with gamers is that a lot of people play mobile games when they’re on the go, and some of those gamers also own a console, and if you’re in front of your TV, then you would probably play on your console, and you would find that a better experience in that scenario but an impossible scenario when you’re not at your television, and that a gamer might enjoy Fortnite more and play Fortnite more if they’re playing it both on mobile and on console.

2555    Mr Sweeney was taken to an email chain with Mr Spencer, head of Xbox Gaming at Microsoft, that included references to the possibility of Fortnite users on mobile devices upgrading to consoles. It supported the view that mobile usage is supplementary to, rather than a close substitute for, console usage. There would be no need for users to “upgrade” if consoles did not provide a materially improved experience for users.

2556    Indeed, if a user who plays Fortnite on a mobile device chooses to “upgrade” to playing Fortnite on console, it is difficult to conceive of them playing Fortnite on console instead of mobile, which is what substitution presupposes.

2557    There are many contexts and times of the day where a user does not have access to their console or PC. As to a potential drift of Fortnite users from mobile to consoles, there is an important distinction between drift, as a long-term trend, and substitution. Just as the long-term trend from horse and cart to the motor car is not understood by economists to be an example of substitution, long-term trends from mobile to console gaming should not be misconstrued as indicative of competition.

2558    Such movement is not about people choosing at the margin of substitution and, as such, it is not informative as to whether users would substitute from mobile to non-mobile platforms in response to a small change in relative price or quality.

2559    But I do accept that to some extent there is some competition between mobile and non-mobile platforms, but not such as to impact on the question of market definition.

2560    Mr Weissinger said that launching Fortnite on mobile devices would mean users could easily play Fortnite “on the go”, wherever they are, such as outside of the house, on public transport, at work, at a friend’s house or when travelling.

2561    Mr Grant said that developing Fortnite for multiple platforms allowed Epic to access as many potential users as possible and, for users with multiple devices, developing Fortnite for multiple platforms provided those users with ways to play Fortnite in a range of situations.

2562    Further, mobile and non-mobile user bases are drawn from different demographics.

2563    Mr Weissinger explained that it was his view at the time that mobile-specific characteristics would enable Epic to attract a new and different audience to Fortnite beyond the traditional personal computer and console gaming user base. He identified that the new and different audience included casual gamers who do not own specific gaming hardware, primary mobile gamers for whom mobile is their primary gameplay device, and a large potential user base of women.

2564    Mr Allison stated that the distribution of mobile versions of games on mobile devices is important to game developers, as almost everyone has a mobile phone but not everyone has a personal computer or console, and many of those who own a personal computer do not use it for gaming. By distributing a title on both Android and iOS mobile devices, developers access a much broader range of potential users, including casual or “on the go” users, who may otherwise be unlikely to interact with the title on personal computers or consoles.

2565    Mr Schiller recognised that developers will commonly develop for and release games on most major platforms at or about the same time. Mr Schiller pointed to Minecraft, an app owned by Microsoft, being available on multiple platforms including the App Store, Play Store, Nintendo eShop and the PlayStation Store. This is in addition to the app being available on the Windows Store and the Xbox Store, each owned by Microsoft.

2566    Ms Wong said that developing cross-platform apps enables developers to maximise monetisation across platforms concurrently.

2567    She said that the broad range of content distribution channels means that developers have greater choice to develop cross-platform apps, maximising monetisation across platforms concurrently. For example, a game can be made available for download on the Play Store and the App Store for mobile play but also be made available as a console game via Xbox, Nintendo and PlayStation, as well as being included in a games subscription service such as Xbox Games Pass and Apple Arcade.

2568    She also said that in her experience, the platforms that a developer chooses are largely driven by the style of the game and the developers’ preference in accordance with their business strategy. For example, she had observed that for a deep immersive game where the gameplay mechanics are made for PC, a developer may choose to only develop for Steam, assuming the core players will play at home where they have access to Wi-Fi, a large screen with their PC, laptop and/or TV, good quality audio and comfort to play for hours. Alternatively, if the game can be equally engaging on the small screen, such as mobile or tablet, and consumer demand to play “on the go” is present, a developer may choose to include a mobile app release of their game and distribute on the Play Store and the App Store.

2569    There was broad agreement among the lay witnesses that releasing an app on both mobile and non-mobile platforms is additive. If they were substitutes, developers would expect cannibalisation between platforms and would have little incentive to develop apps that are compatible with PCs and consoles in addition to mobile apps.

2570    Let me deal with some other aspects of Professor Hitt’s evidence.

2571    First, Professor Hitt’s evidence on the use of mobile, PC, and gaming consoles was consistent with these platforms serving separate consumer bases. Professor Hitt’s evidence did not support the notion that consumers treat native apps on iOS devices as substitutable with native apps on “non-iOS” devices.

2572    Professor Hitt’s discussion of app platforms highlighted the distinction between mobile, PC, and console products. As Professor Goldfarb pointed out, Professor Hitt’s evidence was consistent with these platforms serving separate consumer bases.

2573    He said that game developers choose which app platforms to design for depending on specific context factors of their game. He also said that developers choose what app platforms to develop for based on a game’s specifications, the available developer tools on a given platform and consumer preferences.

2574    That a developer chooses to design a game only for console is not in itself compelling evidence that gaming consoles and smartphones are substitutable products. Instead, it can indicate that these devices serve different consumer bases.

2575    Take the Nintendo Switch device’s inability to handle games that take advantage of the processing power of Xbox or PlayStation consoles. A developer of a game requiring a high degree of processing power would not treat the Switch and perhaps any smart mobile devices as a substitute for Xbox or PlayStation.

2576    The game that they would be required to design for use on the Nintendo Switch or a smart mobile device would likely have a different gaming experience when compared to that on Xbox or PlayStation, and would serve a supplemental audience to the developer’s core audience. That different gaming experience may then attract different sets of users. For users who do use apps across more than one device, the different gaming experience may attract that user at a given point in time.

2577    That popular games such as Minecraft or Genshin Impact have offerings across multiple devices and their associated app platforms does not suggest that these are substitutable platforms. They are offerings for different consumers seeking different user experiences. Minecraft has different user experiences on mobile versus PC. Users of Genshin Impact use different devices in different contexts.

2578    The different platforms that developers choose to design their games for create different usage experiences and thus target different users or users in specific contexts. The latter in particular relates to the concept of “device first”. Different devices are conducive to different usage experiences.

2579    Second, Professor Hitt did not refute the results of Professor Goldfarb’s substitution analysis across native apps on iOS and apps on desktop, laptops, and gaming consoles.

2580    The evidence that consumers and developers see native apps on iOS, desktop, laptops, and gaming consoles as differentiated products aligns with the proposition that consumers do not treat these platforms as substitutes, except to a limited extent.

2581    Professor Goldfarb assessed whether consumers treat the usage of the Fortnite native app on iOS as substitutable with apps on other desktop, laptop, or gaming consoles by analysing the changes in play hours following removal. Professor Goldfarb used this analysis to understand consumer behaviour when faced with the equivalent of an infinite price increase, testing whether consumers divert any of their usage to other apps.

2582    Professor Goldfarb found that for users who had used Fortnite only on iOS prior to the removal, 33.52% of use on Fortnite’s iOS native app was recovered on native apps on non-iOS devices by one year post-removal.

2583    For users who used Fortnite via the iOS native app along with the Fortnite app on other non-iOS devices, Professor Goldfarb found similar low diversion of use to other platforms post-removal.

2584    Now Professor Hitt dismissed this result for not focusing on transactions. But this removal analysis shows that when a user’s preferred mobile platform was no longer available, the user did not make up the majority of those lost play hours or lost spend on other platforms. Over the long term post-removal, users even reduced their play hours on some other platforms.

2585    Professor Hitt did not address this analysis in his criticism of the device first concept.

2586    Professor Hitt said that to formally test for the device first concept, one would need to determine whether users are more likely to substitute to a different activity on the same device than to the same activity on a different device.

2587    Professor Goldfarb considered the results of the removal analysis in light of this suggestion. Should the device first concept hold, when a Fortnite iOS user no longer has access to the Fortnite iOS app, they would not switch to use Fortnite on a different device. Instead, they would switch to another activity on their iOS device.

2588    Whilst Professor Goldfarb could not formally test switching to usage of an alternative activity on a user’s iOS device, Professor Goldfarb did observe that users do not switch a majority of time previously spend using iOS Fortnite to using Fortnite on other devices. This is consistent with the device first concept, in that different devices are conducive to different usage experiences. It supports the idea that users do not treat native apps on iOS, and desktop, laptops, and gaming consoles as substitutes, except to a limited extent.

2589    Further, I agree with Epic that Mr Schiller’s evidence made clear that Apple is in reality substantially indifferent to competitive developments in the PC sector. This is incompatible with the notion that Apple competes with PC stores. Indeed, and as Epic points out, it contradicts evidence that the App Store competes in an increasingly crowded market of app transaction platforms, which are available across multiple devices including tablets, smartphones, laptops, PCs, Macs and game consoles.

2590    Further, Apple’s approach to cross-platform functionality and its introduction of the multi-platform rule is further evidence that the App Store is not subject to any meaningful competitive pressure from PC stores. Apple sought to depict itself as being less restrictive than other platforms.

2591    Further, Mr Schiller gave evidence that, under the multi-platform rule, Apple receives no commission on paid content purchased on a non-iOS platform. Moreover, Apple does not require developers to maintain price parity between platforms. Developers are free to price their in-app content on the App Store higher than the same content sold through other platforms. The multi-platform rule applied to Fortnite, and if a user purchased V-bucks on another platform they could use those same V-bucks on iOS, unless the other platform imposed restrictions preventing cross-wallet functionality. In such circumstances, no commission would be payable to Apple.

2592    Further, Google’s approach to cross-platform functionality indicates that it does not perceive non-mobile platforms to be a substantial competitive threat.

2593    Generally, in my view Apple’s and Google’s respective conduct demonstrates a recognition that users generally speaking are unlikely to switch from iOS or Android devices to using PC or console platforms. There is no real and substantial substitution, although there is a lot of complementary usage.

PCs and consoles — analysis

2594    Now it seems clear to me from the evidence that mobile devices and non-mobile devices serve different purposes. Further, they have distinct user bases. Moreover, for the most part, insofar as their user bases overlap, their usage is complementary or supplementary.

2595    The distinct roles of mobile and non-mobile devices is reflected in a number of observable characteristics about the industry. Many mobile apps are not available on PCs or consoles, and vice versa. Further, a sizeable proportion of iOS users do not have a PC or a console, and are unlikely to obtain one if the price of iOS app distribution services were to increase.

2596    From a user’s perspective, if an app the user wishes to use is not available on non-mobile platforms, they will plainly not switch to using those alternative platforms to use that app.

2597    Further, even where an app may be available on both mobile and non-mobile platforms, users are unlikely to consider these close substitutes.

2598    There are important technical differences between mobile and non-mobile devices that mean they lend themselves to use in different contexts or for different purposes.

2599    Further, whilst many developers do not release the same app on mobile and non-mobile platforms, including because of the unique characteristics of mobile and non-mobile platforms, many do. For those developers, this strategy is aimed at reaching the largest pool of potential customers so as to maximise monetisation across platforms concurrently.

2600    Now it may be accepted that users and developers multi-home across devices. But the fact that there is multi-homing behaviour is not of any real significance. Measures of multi-homing are not themselves informative as to whether these purported alternatives are, in fact, close substitutes for the services provided by the App Store. The possible availability of other channels is insufficient to establish that they are close constraints. To establish the latter proposition, one needs evidence of actual substitution, including switching by app users and developers to other channels in response to relative price changes. There is no such evidence.

2601    Further, whilst the Fortnite removal event was an extreme scenario and limited to a single app, it is instructive of the limited degree to which iOS device users are willing to switch to using alternative platforms. Even in this extreme case, being removal or, in economic terms, an infinite price increase, iOS users did not substitute the vast majority of their lost gameplay with play on PCs or gaming consoles. Nor did they switch the substantial majority of their spending. The evidence indicates that users do not treat usage or the purchasing of in-app content on iOS devices as substitutable with those activities on non-mobile devices.

2602    Further, if limited substitution occurred following the removal of Fortnite, then even more limited substitution would be expected following a SSNIP.

2603    Now Apple says that the App Store competes with transaction platforms on PCs and consoles, and that it is constrained by the prospect of iOS users and developers of iOS apps switching to those platforms.

2604    Google says that PCs and consoles provide close competitive constraint to the Play Store in Professor Asker’s markets for facilitating transactions for digital content.

2605    Further, Professor Hitt and Mr Houston said that it is easy to make app transactions across different app stores on different devices, that there is a lack of significant switching costs for app users, and that there is widespread multi-homing. Similarly, Professor Asker referred to the high degree of cross-platform ability to transact as a reason that other transaction venues should be considered substitutes to the Play Store.

2606    Now the relevant question is whether users and developers switch away from using either iOS or Android app distribution services to an alternative on PCs and consoles, in response to a small change in the relative price or quality of those services.

2607    Postulated behaviour that leaves demand for iOS or Android app distribution services unchanged is not relevant to this inquiry.

2608    There are basic differences between mobile and non-mobile devices and as a result they have distinct user bases and their usage is complementary or supplementary.

2609    As such, users generally do not switch between the App Store and Android app stores on the one hand, and PC and console platforms on the other, and will not do so in response to small changes in the price or quality of iOS or Android app distribution services. This is confirmed by the low diversion of Fortnite usage and expenditure from iOS and Android to other platforms following the removal of Fortnite from those platforms.

2610    These characteristics of the user bases are a result of the following.

2611    First, a sizeable proportion of mobile device users do not have a PC and/or console, and would be unlikely to obtain one if the price of mobile app distribution services were to increase.

2612    Second, mobile device users who do have a PC or console do not have access to those devices at all times or in all contexts, and use them for distinct reasons from those for using mobile devices.

2613    Third, mobile device users are unlikely to switch to using their PC or console once they have decided to use their mobile device on any particular occasion.

2614    Because users do not substitute PC and console platforms for the App Store or Android app stores, developers must develop for iOS in order to distribute their apps to iOS device users and must develop for Android in order to distribute their apps to Android device users. Consequently, developers are unlikely to consider distribution of their app on non-mobile devices as a substitute for each avenue of mobile distribution.

2615    Indeed, many popular PC and console apps are not available as native mobile apps. This is in part because of the difficulty of porting apps from PC or console to mobile. Further, many apps developed for mobile are not also developed for PCs or consoles, further limiting the ability or willingness of users to switch between the two.

2616    Let me get into the detail by observing, as I have already said, that the user bases of mobile and non-mobile devices are distinct.

2617    Many mobile device users do not own a PC or console and will not acquire one to access apps.

2618    Mobile devices have surpassed other types of device to become a near ubiquitous part of modern life. But ownership rates of PCs and consoles are considerably lower.

2619    An iPhone buyer study conducted by Apple found that, among iPhone buyers in Australia in the fourth quarter of 2020, 20% owned and used a console, and 60% owned and used a PC. This figure excludes Macs. Despite having access to internal Apple documents recording the proportions of iPhone buyers who owned and used non-mobile platforms, Professor Hitt preferred to rely on a survey conducted by a third party which concerned a less relevant question, being the proportion of Australian internet users that had accessed the internet in the previous six months using particular devices.

2620    In considering whether users of iOS devices are likely to switch to accessing apps on non-mobile devices, the proportion of iPhone owners, as opposed to the population at large, that own and use those non-mobile devices, as opposed simply to having at least once used them to access the internet, is a more useful metric.

2621    The same is true of Android users. A December 2018 Google survey identified that 47% of US Android smart mobile device users owned a Windows laptop and 20% also owned a MacBook. Console ownership is even lower. For example, a July 2023 Google document estimated that there are around 3.7 billion mobile users globally, but only 300 million console users.

2622    In other words, a material proportion of mobile device users do not own and use a PC or console and would need to incur the substantial cost of purchasing such a device to switch. The only reliable way to access these users is through their mobile device. For these users, a significant barrier to switching to use a console or PC will be that they must first purchase that device. Users would not do this in response to a small relative increase in the price, or decrease in quality, of iOS or Android app distribution services.

2623    Further, mobile and non-mobile devices have different use cases and are used in different contexts.

2624    Even for those users who have both mobile and non-mobile devices, users treat use of the different types of device as supplementary or complementary, rather than as substitutes, because they have different use cases and are used in different contexts. App usage rather than in-app spending is the appropriate metric.

2625    Certain basic differences between mobile devices and PCs mean they are suited to different use cases, and for use in different contexts. From a technical perspective, Professor Somayaji explained the following.

2626    Different categories of hardware address different consumer needs. For example, desktop and laptop computers typically offer significant amounts of computing power, large displays, and support use cases where users spend an extended block of time using an app while in one place. Mobile phones, by contrast, have evolved to support use cases where users need rapid access to data and contacts while on the go, and feature responsive, network-connected hardware packed into a small and portable form factor. Gaming consoles, as a third variation, are computers that have adapted almost exclusively to provide optimal gaming experiences, and typically feature strong graphics processors and game controllers designed specifically for gaming use cases.

2627    In part reflecting these technical differences, many apps are only available on mobile devices, and not on consoles or PCs. This means that, in many cases, it is not possible for users to switch from accessing their app on their mobile device to accessing the same on their PC or console.

2628    Of the top 100 revenue generating apps on the App Store in 2021, 46% were distributed on mobile devices only, and 18% were also distributed on one or more consoles. Of the top 50 revenue generating apps on the Play Store, 38% were distributed on the Microsoft PC store and 10% were distributed on the Microsoft Xbox Store, with other PC and console stores containing an even lower proportion. The position is similar in respect of free apps on the Play Store. In addition, the inverse comparison also shows a lack of crossover. The top games on PC and console stores do not appear on the Play Store.

2629    In addition, many apps are written specifically for use on mobile devices. There is no real prospect that users of these apps on mobile devices will switch to using these apps on non-mobile devices, even if they are available.

2630    Now Professor Goldfarb explained the effect of technical differences on users’ device usage in the following terms, which seemed to me to be not contentious, and indeed in some respects obvious.

2631    Smart mobile devices have several key features that make them suitable for use in situations when other devices are unsuitable. For example, due to the small size, portability, and cellular data availability for smartphones, users often can use their smartphones in situations in which other devices such as a gaming console or PC would be unavailable. In contrast, when users anticipate they will have an extended period of time in the same place, they may sit in front of a PC. Once the device is chosen, features on smartphones such as geolocation can further assist a user in specific contexts, such as looking for a local restaurant when away from home or having the ability to take photos for social media accounts with a built-in camera. Certain features of PCs may better help users express themselves, as shown in the higher quality associated with online reviews written on desktop devices. That gaming consoles have controllers and more advanced computer chip technology make them more suitable for intensive play. Once a user selects a device, all these factors affect the activity chosen.

2632    Professor Goldfarb’s evidence was reinforced by other witnesses whose evidence addressed the difference between mobile and non-mobile devices, including portability of mobile devices, the higher performance and processing power of PCs and consoles, and the need for users to use additional hardware or accessories, as compared to mobile.

2633    Professor Goldfarb used the term “device first” to describe how users’ choice of the device they wish to use is influenced by the particular context a user finds themselves in, the activity they wish to engage in, and the particular features of the device(s) available to them. He identified two key aspects to this concept.

2634    First, several external factors are central to the choice of device, including location, time of day, Wi-Fi access, time, and mental attention available.

2635    Second, different devices are conducive to different usage experiences in terms of time spent, information frictions, connectivity, and the need for focus. Together, these features suggest that the usage of smartphones and other devices, by the same users, often involve different motivations and contexts.

2636    In the case of mobile devices, he reasoned that their usage is often a function of situational convenience. So, should the user’s desired app be unavailable on their mobile device, a user is more likely to switch to using a different app on that device, or engage in a different activity entirely, rather than switch to a non-mobile device to access the app. That reasoning is supported by the views of developers and users as recorded in Epic’s and Google’s internal documents reflecting the result of interviews conducted by Google with developers of games apps and survey responses from Fortnite players that indicated the ways in which they access the app on different devices.

2637    Professor Goldfarb’s description of consumer behaviour using the language of device first was clear and supported in substance by the literature including some articles he authored.

2638    Based on his analysis including the Fortnite removal event, Professor Goldfarb concluded that users do not treat usage of native apps on non-mobile platforms as substitutable for usage of those apps on iOS and Android devices, except to a limited extent.

2639    Professor Goldfarb’s analysis of the Fortnite removal event indicates that there is no meaningful degree of substitution between mobile and non-mobile platforms and corroborates his evidence about consumer behaviour. The Fortnite removal event shows that users do not treat apps on mobile and non-mobile devices as substitutes. Now when considering this analysis, it is important to bear in mind the following.

2640    When a product with several close substitutes is no longer available, one would expect all, or nearly all, the demand for that product to transfer to its substitutes. Therefore, if users treated access to Fortnite on different platforms as closely substitutable, then almost all the use and spending which would have occurred through those platforms should transfer to the remaining platforms. In this regard, the experts generally agreed that a small increase in the price of Fortnite in-app purchases would not be expected to induce as much substitution as occurred following its removal, which can be thought of as an infinite price increase.

2641    Further, Fortnite has far more cross-platform functionality than most mobile apps, and is unusual in its availability on other platforms, including consoles and PCs. As a result, it would be expected that the extent of diversion observed following the removal of Fortnite would be far greater than what one would expect for almost all apps on the App Store and the Play Store.

2642    Professor Goldfarb found that following the removal of Fortnite from the App Store, iOS users did not substitute the vast majority of their lost gameplay with play on PCs or gaming consoles. In fact, users who played on iOS as well as another platform decreased their average playtime on those other platforms when Fortnite was removed from the App Store.

2643    Analysing Fortnite spending data from the same period also supports a lack of substitution between these devices. Professor Goldfarb and Professor Hitt agreed that only around 30 to 35% of the revenue which would have been earnt from iOS Fortnite users was diverted to other channels following the removal.

2644    Now given the experts’ agreement on approximate diversion figures, I reject Apple’s suggestion that these results are driven by lower levels of retention of Fortnite players on iOS. Any such difference would also be reflected in the pre-removal period, and is thus disproved by the fact that both Professor Goldfarb and Professor Hitt found that their treatment and control groups exhibited parallel trends. Further, Apple has not presented any evidence to substantiate this claim.

2645    This evidence strongly indicates that users do not treat apps on iOS devices as substitutable with apps on PCs and consoles, whether in relation to usage or spending. Moreover, even if limited substitution occurred following the removal of Fortnite, then even more limited substitution would be expected following a SSNIP.

2646    The same conclusions can be drawn from Professor Goldfarb’s analysis of the Fortnite removal event in respect of Google.

2647    In respect of diversion in usage, Professor Goldfarb found that for users who only played Fortnite via the Play Store, complete removal led to only around 19 to 44% diversion to non-Android channels.

2648    In respect of diversion in revenue following removal, Professor Goldfarb’s results in table 11.B showed that around half of spending was lost altogether, only around a third of spending diverted to non-Android channels and diversion to Samsung Galaxy was the single largest figure, except at a post 52 week period.

2649    Now Professor Asker’s diversion analysis is also relevant, but his analysis was affected by methodological flaws in his econometric analysis. I have dealt with Professor Asker’s results elsewhere in my reasons in the Epic v Google proceeding.

2650    Mr Sweeney also said that the removal of Fortnite from the App Store and Play Store resulted in very limited user switching between mobile and non-mobile platforms.

2651    Now Mr Sweeney was taken to an email from him to Microsoft in which he described the extraordinary opportunity that Project Liberty would provide Microsoft.

2652    Mr Sweeney explained that the opportunity that he was referring to was that Fortnite was likely to become unavailable through the two leading mobile app stores, leading users who wanted to play Fortnite to consider the possibility that they might want to play it on console, and that if it were unavailable on mobile, then perhaps they could play it on another device.

2653    That Mr Sweeney hoped that some users who would otherwise be lost would play on consoles following this event does not speak to substitution. The fact that some mobile device users may choose to play Fortnite on a console or PC is not indicative of what would occur as a result of small changes in the relative price or quality of iOS app distribution services.

2654    In cross-examination, Mr Sweeney was taken to a board update which contained projected profit and loss impacts if Fortnite were removed from the App Store and Play Store. This depicted that a proportion of mobile revenue would transfer to other platforms. He was also taken to a document which contained projections of the revenue impacts of Fortnite’s removal from iOS and the Play Store. This depicted that if Fortnite were removed from iOS and the Play Store shut down, some additional revenue would move to PlayStation 4.

2655    But given the nature of the removal of Fortnite, it is unsurprising that Epic forecast that some lost revenue would be recovered through other channels. In any event, regardless of Epic’s perceptions I have Professor Goldfarb’s analysis which showed that very little diversion occurred in practice.

2656    Further, let me say something about Apple’s views about mobile usage.

2657    Ms Wong’s evidence corroborated the views expressed by Professor Goldfarb and Professor Wright that mobile usage is supplemental to non-mobile usage. She said that she had observed that Australian users consume a range of digital content across their personal devices. Users switch between devices depending on varied factors, including, but not limited to, the type of content that they are consuming, the time of day, access to Wi-Fi, and their location, whether that be at home, in transit, or in some other location.

2658    Further, Apple’s own assessment of how its customers use its products, including mobile devices, being iPhones, and non-mobile devices, being Macs and Apple TV, reveals a similar picture of supplementary usage.

2659    In July 2023, Apple made a submission to the European Commission in relation to the designation of a series of its products as Core Platform Services, some extracts of which were drawn to my attention. The submission described in detail the ways in which Apple ensured that its mobile and non-mobile products were suitable for distinct use cases. It contained reference to users using different devices to pursue different and unique combination of use cases. The submission reflected Apple’s view that iOS was predominantly used for [REDACTED] [REDACTED] [REDACTED] whilst macOS was predominantly used for [REDACTED]. Further, Apple itself accepted that it was immaterial whether two services have overlapping user groups. What mattered was whether these user groups use the services in question for the same or a different purpose. And so, Mac users who acquire an iPad are not doing so to replace their Mac, but because they use the right tool at the right time. Further, Apple recognised that each App Store serves as a gateway to reach a distinct group of end users because demand for apps in the App Stores is driven by the Apple device used by a given end user. Consistent with their function as distinct sales channels to reach different end user groups, each App Store offers different App Store Connect functionalities to developers.

2660    It follows that the fact users use both mobile and non-mobile devices, that is, multi-home, does not evidence substitution.

2661    Let me now deal with some other matters and return to the question of some relevant functionalities.

Cross-wallet and cross-platform functionality

2662    Now Apple says that the whole point of cross-wallet functionality is to enable users to switch purchases of identical virtual currency between platforms.

2663    But I agree with Epic that such functionality does not establish the requisite substitution. Cross-progression and cross-wallet functionality allow users to take virtual currency or other items of digital content purchased while playing on one device and use it when playing on a different device.

2664    Now Epic introduced cross-progression and cross-wallet features in order to encourage users to play Fortnite in more contexts and to grow its revenue. This seems to have been based on Epic's recognition that mobile usage is supplementary to console and PC usage, and that users tend to pay where they play.

2665    Now Mr Sweeney accepted that the concern of console platforms regarding user switching was well founded. But he believed that any outflow of revenue from one platform to another would be negligible. So, Mr Sweeney offered the true up arrangement to Sony to assuage its concerns.

2666    Now Apple relies on that arrangement in support of its contention that there is competition between platforms. But I agree with Epic that the fact that [REDACTED] [REDACTED] since the introduction of a materiality threshold demonstrates that Sony’s concerns were short-lived and problematic.

2667    As Epic points out, it would seem that Mr Sweeney was confident that users would not switch devices to obtain cheaper V-Bucks such that he offered to compensate Sony in the event that users did so.

2668    In September 2018, Epic and Sony agreed to amendments to their exclusivity and co-marketing agreement to permit cross-play and cross-progression between PlayStation, Xbox and Switch. Those amendments included a clause under which Epic was required to make a payment to compensate Sony for any shortfall in its 30% commission entitlement by reason of Fortnite users on PlayStation spending more money on other platforms relative to the amount of time played on PlayStation, referred to by Epic as a true-up payment. The purpose of these payments was to ensure that Sony was not worse-off as a result of permitting cross-progression.

2669    A formula was devised to determine the quantum of any such payment. The formula required Epic to make payment to Sony if the revenue earned [REDACTED] [REDACTED] was less than the sum of revenue earned [REDACTED] [REDACTED] and revenue earned by [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] multiplied by [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED]

2670    Epic made [REDACTED] payments to Sony pursuant to this clause between September 2018 and September 2019. The payments were made approximately [REDACTED].

2671    The table below contextualises the size of these payments by reference to the 30% commission Epic ordinarily paid Sony to distribute Fortnite. The table sets out the gross revenue earned by Epic from Fortnite on PlayStation [REDACTED] and the [REDACTED ][REDACTED] as reported to Epic’s board, the ordinary commission Epic paid to Sony over that period, which is calculated by taking 30% of such gross revenue, the amounts of each true-up payment for roughly the same time periods, and the true-up payments expressed as a percentage of the ordinary commission payment:

2672    Now the first true-up payment was for the period [REDACTED] [REDACTED][REDACTED] whereas the gross revenue figure to which it is compared is for the period of [REDACTED] [REDACTED]. Further, the last true-up payment was for the period of [REDACTED] [REDACTED], whereas the gross revenue figure to which it is compared is for the period of [REDACTED] [REDACTED] . The effect of this is that the percentage figure for the first row is a slight overestimation, while the figure in the last row is a slight underestimation of the true position.

2673    Now accounting for these discrepancies, it would seem that the true-up payments as a percentage of the ordinary commission paid to Sony remained roughly constant between [REDACTED] and [REDACTED].

2674    This shows that the [REDACTED] between playtime and spend on PlayStation following Sony’s agreement to implement cross-progression was [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] [REDACTED] .

2675    Sony appeared to consider these true-up payments to be [REDACTED]. In early September 2019, Epic and Sony agreed further amendments to their exclusivity and co-marketing agreement to apply a materiality threshold with the effect that Epic would not have to make any true-up payments if divergence between Fortnite user spend and play time on PlayStation fell below a certain threshold. [REDACTED] [REDACTED] [REDACTED] [REDACTED]

2676    There is little merit to Apple’s suggestion that Epic maintained the same price of V-Bucks across different platforms to prevent users switching between platforms.

2677    Further, Apple suggested that console manufacturers were concerned about users switching between platforms in response to changes in the price of V-Bucks.

2678    But as Epic points out, there are various reasons why console manufacturers might not have wanted the prices of V-Bucks to be different on different platforms. They may, for example, have been concerned about there being news stories about them being less attractive than another platform, their customers’ perceptions, and their reputation. Further, there are also complicated Japanese rules pertaining to virtual currency and there may have been Japanese regulatory concerns held by Sony and Nintendo.

2679    Further, even assuming that the console manufacturers were concerned about users switching between platforms in response to changes in the price of V-Bucks, their concern would have been about switching away from their platform. They would not be concerned about users switching to their platform from iOS. The presence of that concern would not support Apple’s case. Users with iPhones have greater opportunity to switch from a console or PC to a mobile device than the opposite, because when they play on a console or PC, they are likely to have their iPhone with them. The converse is not true.

2680    Further, and more generally, the existence of any concerns that console manufacturers held regarding the diversion of spend away from them to iOS does not provide any evidence of close substitution away from the services supplied by Apple in connection with its iOS apps.

2681    Further, as to Mr Sweeney’s evidence concerning Nintendo he explained that regulatory concerns may also have been a motivation for Nintendo to decline to permit cross-wallet functionality.

2682    Further, Apple has not put forward any evidence to the effect that Apple itself is concerned about the prospect of users switching away from iOS as a result of cross-platform functionality.

2683    Moreover, cross-platform functionality presents a commercial opportunity for Apple, rather than a threat.

2684    Apple’s distribution of iOS apps via the App Store to iOS mobile users provides a gateway to reach a different user group than its distribution of Mac OS apps via the Mac OS Store to PC users.

2685    It is the user who initiates any purchase of digital content or virtual currency on another device they own on a different platform. The developer offers that purchase opportunity and delivers the purchased content on that other platform. The developer may also offer cross-platform functionality in its apps, subject to that feature not being blocked by a particular platform.

2686    The multi-platform rule allowing users to access content purchased on other platforms in their iOS apps was only introduced by Apple in 2018, and it is subject to a condition that the same content must be available for purchase within the iOS app via IAP.

2687    Allowing out of app content purchases to be used in the iOS app maximises user engagement with iOS and brings value to Apple in the form of increased usage of iOS apps and resultant direct and indirect network effects.

2688    The commercial benefits that flow to Apple are also evident when the two different options available to Apple are compared.

2689    If an iOS user makes digital purchases of virtual currency or other content on a different device on a different platform and is able to use that content elsewhere, but not within the user’s iOS app, that result would effectively degrade the quality of the user’s iOS app. For instance, users are likely to perceive that their iOS Fortnite experience is a lesser experience than on other platforms because they cannot access virtual currency or other content that they have previously purchased on another platform.

2690    Conversely, the user’s ability to use that currency or other content within their iOS app would make the use of Fortnite on iOS more attractive, causing the user to spend more time on iOS.

2691    Let me deal further with a topic.

2692    Professor Hitt, Mr Houston and Professor Asker said that users can substitute from in-app purchases on iOS and Android devices to in-app purchases on non-mobile devices.

2693    Further, Professor Hitt said that game developers can facilitate consumer substitution across platforms to make transactions by, for example, enabling customers to use the digital products or in-game currency they purchase through alternative platforms on their iOS devices. And Mr Houston pointed to Fortnite as an example of a game that can enable this kind of substitution. Professor Asker said that developers can and do transact with consumers for content that can be used on an Android device, even if the transaction venue does not allow app downloads onto an Android device. He went on to assess whether other game app developers offer the same degree of cross-platform functionality as Fortnite.

2694    Now as I have said, Fortnite has various cross-platform features. It has the functions of cross-progression, cross-play and cross-wallet.

2695    As should be apparent, cross-wallet and cross-progression make it technically possible for users to switch between mobile and non-mobile platforms to buy V-Bucks and use the items they redeem with those V-Bucks on any platform on which they play Fortnite. Cross-play facilitates gameplay between different users.

2696    But I agree with Epic that this idea of Professor Hitt, Mr Houston and Professor Asker of close substitution is problematic to say the least.

2697    As Epic says, few developers offer the kind of cross-platform functionality that is available in Fortnite. Epic was the first developer to achieve cross-play, cross-progression and cross-wallet across all platforms on which a gaming app is available for download, with the exception of cross-wallet on Switch.

2698    And as Epic says, attaining full cross-platform functionality is complex and costly, and is only a realistic option for large game developers. Even then, most seek only to offer cross-platform functionality between non-mobile devices, not between mobile and non-mobile devices.

2699    Fortnite is the only AAA gaming title that allows full cross-platform support between mobile devices and other devices. As Mr Sweeney said, Epic has explicitly bucked the trend by trying to build games supporting multiple platforms.

2700    Now Professor Asker said that many developers offer the same cross-wallet and cross-progression functionality as Fortnite, by reference to the top 25 games apps by 2021 Australian Play Store consumer spending. But Ms Edwards-Warren showed such evidence to be unreliable. None of the 25 games to which Professor Asker referred is available on the same number of platforms as Fortnite. Only two are available on consoles, and they are only available on some consoles, not all. Five are only available on mobile platforms being Android and iOS, so their users have no substitution options to consoles and no substitution options to PCs. Moreover, those five games account for 20% of the top 25 games apps and [REDACTED] of Australian consumer spend on in-app purchases across the 25 game apps in 2021. The remaining 18 are only available on a PC platform and mobile platforms being Android and iOS. I have discussed further analysis of Professor Asker’s evidence and Ms Edwards-Warren’s evidence in my reasons in Epic v Google.

2701    It seems to me on the evidence that Fortnite is an outlier. Its cross-platform functionality is not representative of what is or could be offered in gaming apps, let alone all apps.

2702    Further, even in respect of Fortnite, Professor Hitt, Mr Houston and Professor Asker relied on the technical possibility of substitution. But as Epic says, there is little evidence to suggest that substitution of the kind to which they refer actually occurs.

2703    Mr Houston said that users who made Fortnite transactions on iOS in the 12 months prior to Fortnite’s removal from the App Store made 30% of their purchases on iOS and 70% on other platforms. But as Epic says, that is simply evidence of multi-homing. Multi-homing is not evidence of substitution.

2704    Professor Hitt said that between 26 February 2018 and 9 August 2020, users who played Fortnite on iOS devices made 83.4% of their purchases in terms of revenue on non-iOS devices. But that too is not evidence of substitution. As Professor Hitt accepted when cross-examined, each of those users might have only played Fortnite once on iOS between those two dates, and otherwise played and spent on Fortnite on non-iOS platforms for the rest of the time. They might have tried the iOS game once, had a poor experience and never went back to the iOS version.

2705    Further, this data also showed that users spent 83.5% of their time on non-iOS devices, illustrating that in-app purchases are related to usage.

2706    Professor Asker similarly said that most spending by Android and Play Store Fortnite users while Fortnite was available on the Play Store occurs via console stores, and appears to have accepted that this evidence only goes to whether Android and Play Store users are readily able to substitute their spending to other transaction venues. He also found that among users that ever spent on Fortnite using Android, 85.9% spent only through non-Android channels from 26 February 2018 to 8 November 2021.

2707    Professor Goldfarb’s analysis demonstrated that Fortnite users do not engage in substitution of the kind to which Professor Hitt, Mr Houston and Professor Asker referred.

2708    Professor Goldfarb tested whether such substitution occurs by analysing datasets of daily transaction and gameplay records for Australian Fortnite users in 2020, prior to the removal of Fortnite from iOS and the Play Store. His analysis demonstrated that for over 99.9% of the transactions he observed, the user transacted on only one platform in a day. Further, his analysis demonstrated that of the users who transacted on only one channel per day, 91.84% transacted and played on the same platform, and only 1.88% played on a different platform to the one on which they transacted.

2709    Professor Goldfarb’s analysis demonstrated that the overwhelming majority of Fortnite users pay on the same platform as they play.

2710    There is no merit to Professor Hitt’s and Mr Houston’s suggestion that Professor Goldfarb’s analysis did not account for potential inter-temporal substitution, that is, substituting away from making an app transaction at one point in time to making that app transaction at another point in time.

2711    Neither Professor Hitt nor Mr Houston referred to any data, or conducted any analysis, to suggest that any such inter-temporal substitution occurs. It does not. For over 99.9% of the transactions that Professor Goldfarb observed, the user transacted on only one platform in a day. If there is no inter-temporal substitution across an entire day, there is no reason to believe that there would be any such substitution from one day to the next.

2712    Now Apple put some further matters in an attempt to bolster its experts’ theories.

2713    First, Apple said that Epic’s reason for keeping the price of V-Bucks identical across all platforms, mobile and non-mobile, was to avoid the risk of users switching platforms if Epic were to price its V-Bucks more cheaply elsewhere.

2714    But the evidence suggests that Epic’s reason for wanting the price of V-Bucks to be the same is to ensure that users perceive that Epic is treating them equally. Epic does not want users that play Fortnite only on some platforms to feel that they are getting a poor deal. If users see different prices of V-Bucks on different platforms they may become frustrated. Unsurprisingly, it would seem that players react negatively to better deals being available on some platforms that are not available to them. This could impact upon trust in Epic and its brand.

2715    Now Professor Hitt said that there may be benefits developers get by keeping prices uniform and that offering differential pricing will result in less transparency. He said that sometimes consumers can react badly to price discrimination.

2716    But Mr Sweeney did not consider there to be a realistic prospect of users switching devices to obtain cheaper V-Bucks. In his experience, users usually do not go off and hunt through other devices to look for better prices. It was not a phenomenon he had ever observed at any significant scale. He also said that if the price of V-Bucks differed between platforms he thought that the outflow of revenue from one platform to another through such effects would be negligible. I have no reason not to accept his evidence.

Out-of-app payments

2717    One mechanism of so-called substitution advocated by Professor Hitt and Mr Houston was through the purchase of digital content on another, non-iOS channel, followed by consumption of that content within a native iOS app. But I agree with Epic that this is not a form of substitution, either on Epic’s or Apple’s view of the relevant products.

2718    The ability of users to acquire content outside of a native app, but use it within the app, is dependent on them having obtained the native app. On iOS that is necessarily done through the App Store, involving the provision by Apple of its iOS app distribution services.

2719    The postulated constraint involves no substitution away from those services at any moment. Moreover, Apple could at any moment revert to its pre-2018 position where it prohibited the use within an iOS app of content that had been purchased outside that app.

2720    I reject the suggestion that Apple’s provision of services related to the download and update of native apps is constrained by the ability of users to make out-of-app purchases.

2721    As I have said, that constraint, to the extent it exists, is simply a product of Apple’s present choice of monetisation strategy, to which it and a hypothetical monopolist cannot be assumed to be wedded. As Epic points out, this state of affairs does not suggest that Apple’s distribution services are the subject of any constraint from out-of-app purchases, particularly in circumstances where Apple could change how it monetises its services.

2722    But nevertheless, and as Epic points out, Professor Wright considered this constraint in his HMT. Professor Wright considered whether users would divert their spend outside of iOS in response to a SSNIP in his assessment of whether that SSNIP would be profitable. He concluded that such diversion of spend would be unlikely, for at least the following reasons.

2723    First, not all developers of iOS apps offer their digital content outside of iOS. For those apps that do not, out-of-app purchases are not possible.

2724    Second, many developers do not set different prices on different channels.

2725    Third, even for apps where out-of-app purchases are possible, users may not be aware of that possibility. The anti-steering provisions contained in the App Store review guidelines prevent developers from directing iOS users to alternative methods to purchase content.

2726    Fourth, even where users are aware of the possibility, users are unlikely to divert unless they are aware that alternative payment solutions are cheaper, and obtaining such comparative pricing information of app content across different sources can be difficult.

2727    But I agree with Epic that even if the above difficulties were to be overcome, the evidence would suggest that users are unlikely to engage with the process of conducting out-of-app payments instead of in-app purchases on native apps.

2728    Professor Goldfarb found that out-of-app payments present a significantly inferior experience to making in-app purchases, in part because users are left to identify alternative payment channels and each additional step in that process reduces the likelihood of an out-of-app purchase. Separately, leaving a native app to make a purchase elsewhere can be disruptive to the user experience, particularly during immersive experiences in some apps, such as in the middle of a game. Professor Goldfarb’s “clicks are costly” theory readily confirms such a notion.

2729    Further, the additional steps for out-of-app purchases being the less tailored nature of external payment flows, redirection to external websites and the higher number of steps in the transaction process, likely result in further drop-outs in the course of making a payment.

2730    Now Professor Hitt and Mr Houston have asserted that the App Store is closely constrained by the ability for users and developers to quickly and easily substitute from purchasing in-app content through native apps on iOS to making these purchases through alternative channels.

2731    But I agree with Epic that Professor Hitt and Mr Houston have only relied upon the possibility of technical substitution and have not engaged in any analysis of actual substitution patterns to support their theory.

2732    So, Professor Hitt did not analyse the extent to which consumers and developers actually do, in fact, substitute and justified this on the basis that he did not consider there to be a clean experiment that could be done to analyse the degree of substitution.

2733    Likewise, Mr Houston did not look at whether users and developers actually engage in substitution behaviour, but rather made assertions about the ability and incentive of app users and developers to substitute transactions away from the App Store.

2734    Now Epic pointed out the obvious, which is that whether a consumer can or might do something is different to looking at the question of close substitutability. Technical substitution is a necessary but not sufficient condition for answering that question.

2735    Now Professor Hitt and Mr Houston have claimed that substitution is likely to constrain Apple because transactions for in-app content on different platforms are homogenous, and users multi-home across multiple devices which offer the ability to purchase those homogenous transactions.

2736    But if this view matched reality, developers would already have the ability and incentive to steer users towards purchasing in-app content on channels with lower commission rates. But in reality the following would appear to be the case, as Epic points out.

2737    First, many apps which could remove in-app purchases from iOS under the reader rule in order to steer users to transact elsewhere do not do so.

2738    Second, many developers do not allow in-app content to be purchased outside of iOS and then transferred back to the iOS app.

2739    Third, even where in-app content can be purchased on alternative channels, many developers do not charge differential prices to encourage users to purchase content outside of iOS.

2740    Fourth and overall, more than 162 million in-app purchases were processed through the App Store in Australia in 2021, despite the fact that it has a much higher effective commission rate than other channels.

2741    Now in an attempt to address the problem that the reality did not match their theory, Professor Hitt and Mr Houston asserted that the commission rate charged by the App Store is justified by the high quality of the services it offers, which render its quality-adjusted prices competitive with the prices charged by other platforms. But this explanation only demonstrates that their theory of substitution is problematic to say the least.

2742    The primary mechanism of substitution asserted by Professor Hitt and Mr Houston is the substitution of purchases of in-app content, which they say can occur without regard to the platform on which a user actually uses the app. On this view of the world, it is unclear how the quality of the App Store’s services relating to the distribution of apps would be expected to affect the platform on which users decide to purchase in-app content.

2743    Further, any claim that the quality of the experience of transacting for in-app content is highly differentiated across platforms would be inconsistent with Professor Hitt and Mr Houston’s own argument that transactions are homogenous.

2744    Now Mr Houston ultimately attempted to address the issue by drawing a distinction between the transaction which is homogenous across platforms, and the services which are provided to facilitate the transaction, which he claims can be differentiated between platforms. But this is all problematic.

2745    As Epic points out, if the services provided by Apple for in-app purchases were of such a high quality compared to other platforms, then users of apps which offer uniform pricing across different platforms would be expected to perform a disproportionate number of their transactions through the App Store. But this is not what is observed, and is inconsistent with the following matters.

2746    First, Professor Goldfarb gave evidence that the proportion of a Fortnite user’s game-time and expenditure which takes place through a given platform are highly correlated, indicating that any difference in the quality of the services provided by the App Store relating to transactions for in-app content is insufficient to incentivise users to substitute their expenditure to iOS.

2747    Second, users who accessed Fortnite on iOS in Australia between February 26, 2018 and August 9, 2020 spent 83.5% of total time playing Fortnite on non-iOS platforms and directed 83.4% of total expenditure to non-iOS platforms.

2748    Moreover, and as Epic has pointed out, this inconsistency was highlighted by Professor Wright and Professor Goldfarb during the concurrent economic evidence as follows:

PROF WRIGHT:     So I think Professor Hitt has alluded to the uniform price and we agree on that. But one can think about the quality adjusted price and Professor Hitt has made claims about making transactions on iOS is much better and so on and so forth. If that was the case, you would expect that people would play on wherever they wanted to play but when they wanted to transact and buy they would come to iOS because it’s so much better. These are people who have both devices. And I don’t think - I think Professor Goldfarb’s evidence speaks to the fact they just don’t do that. So I think it’s still relevant.

HIS HONOUR:     What do I infer from the fact they don’t do that, that the price and quality are the same?

A:                 That’s what I would take from it, yes.

Q:     If I assume that the price and quality are the same, what we’ve been going through doesn’t speak at all to the question of economic substitutability; is that right?

A:                 That’s right.

Q:    Do you agree with what I’ve just said, Professor Goldfarb?

PROF GOLDFARB:     Yes. Either the price or quality are the same and it’s relevant or the quality is different and then it lacks substitution.

2749    It would seem apparent that developers recognise that, although it would be cheaper to transact with users on other channels, users are unlikely to substitute to purchasing in-app content outside native iOS apps in reality.

2750    Now when asked about this apparent inconsistency by Professor Wright, Professor Hitt’s response was to point to Epic’s investment in the Epic Games Store. But I agree with Epic that the proposition that Epic’s decision to create its own store, with the significant cost that that entails, is an example of developers making use of close substitution options only has to be stated to be rejected.

2751    Now Professor Hitt also said that developers may reduce their relative investment in iOS apps to drive users to alternative channels. But this is not supported by the evidence, and as Professor Wright explained it is an unlikely course.

General

2752    I should note that the fact that I have found that various other products and services are not close constraints and therefore are not part of the relevant product dimension of market definition does not entail that the availability of such products and services do not provide some form of competitive constraint.

2753    In my view they do provide a competitive constraint to some extent although not such as to deny the market definition that I have found or Apple’s substantial market power in such a market.

Web apps and streaming – substitutes?

2754    Now in considering the close substitutes for iOS app distribution services, it was common ground that the task is to assess what, if any, alternatives users and developers would switch to in the sense of using instead of iOS app distribution services in response to a small change in the price of those services.

2755    Such an analysis must consider the alternative ways in which developers and users can make use of services akin to distribution services. And one must then consider other means by which developers and users can interact with each other, which could theoretically constrain Apple’s provision of iOS app distribution services, but which do not involve the provision of distribution services.

2756    Now in this section, I will focus on web apps and streaming apps, which Apple asserts are close substitutes. And let me start by making the following brief observations by way of summary.

2757    In my view and as Epic rightly contends, the use of web apps does not involve the use of any alternative app distribution services, as it is a particular version of a developer’s website. So, it sits in a different position to the possibilities of users and developers interacting through native apps on non-iOS devices.

2758    Further, web apps are in my view not a close substitute for native iOS apps from the perspective of users or developers, and the ability to use them does not act as a close competitive constraint on Apple’s provision of iOS app distribution services. In my view web apps are not close substitutes for native apps for two reasons.

2759    First, the evidence led before me clearly demonstrates that the user experience differs substantially between the two, principally because web apps have significant inherent functional limitations which native apps do not share.

2760    Second, as the evidence also demonstrates, the limitations of web apps mean that, in many cases, developers must use native apps instead of web apps or otherwise substantially compromise the functionality of their apps.

2761    Moreover, although Apple sought to deny this reality, as users and developers do not treat web apps as close substitutes for native apps, the prospect of developers and users switching to using web apps does not closely constrain Apple in its supply of iOS app distribution services.

2762    Further, I also agree with Epic that streaming apps on an iOS device do not involve the use of alternative app distribution services. A native streaming app is subject to the same restrictions as other native iOS apps, including that it must only be distributed through the App Store, and therefore through the use of Apple’s iOS app distribution services.

2763    Further, the evidence demonstrates that streaming apps are not close substitutes for native apps because, for the vast majority of users, streaming apps suffer from a number of limitations compared with native apps.

2764    Of course, I accept that those limitations may, on occasion, be overcome, but streaming is not a realistic alternative to native apps. Further, the lack of substitutability is demonstrated by the low level of uptake and use.

2765    Let me begin with web apps and set out Apple’s arguments.

Web apps – Apple’s arguments

2766    Apple says that app developers can offer web apps which often have, in many respects, the same appearance and functionality as a native app but are developed using web technology. Moreover, developers may sell the same or very similar content that a user could purchase through an iOS app on a traditional website. iOS device users can access these websites on their iOS devices through any web browser.

2767    Apple says that the user’s experience of web apps and native apps is, in many cases, largely indistinguishable. iOS native app transactions are close substitutes for web app transactions for developers and app users in many instances.

2768    Apple says that both web apps and native apps have advantages and disadvantages. Further, for certain types of apps, web apps are substitutable for native apps. Mr Grant gave Amazon and Starbucks as examples of apps where web apps could substitute for native apps. Other examples of apps that are available as web apps are Instagram, Facebook, Tinder, Netflix and Amazon.

2769    Since the launch of the iPhone in 2007, developers have been able to make available web apps on iOS devices. In relation to web apps developers need not enter into the DPLA or comply with the App Store review guidelines.

2770    Now web apps are not required to go through app review. Web apps provide a suitable option for developers who do not wish to comply with the various requirements in the guidelines. Web apps are also commercially advantageous to developers because there is no commission payable on digital content available for purchase in web apps. There has been, and will continue to be, a trend towards monetising on web apps including on PC and mobiles rather than in native apps.

2771    Apple says that there is considerable technical flexibility when it comes to web apps. Web apps can adapt to the user’s screen size or orientation. Web apps can adapt to input method, such as a keyboard. For some types of apps, cross-platform development costs will be much lower for web apps than for native apps.

2772    Web apps are updated on the internet when a developer chooses to update them, so that the next time the user opens the app, it will be updated, without the user taking any steps to update the app. This gives the developer control over the content and frequency of updates. On iOS, web apps can send push notifications to users.

2773    Now one limitation with web apps is the restriction on the amount of device storage that a web app can use. Web apps have an overall quota of up to 20% of the total disk space on iOS devices, which is 25 GB on the smallest iPhone 15. That does not preclude web apps being used for games, although it does restrict the use of web apps for AAA games, which typically require more storage and RAM. Web apps can work well for casual games such as Pacman and Hangman. Some casual games can operate efficiently as a web app.

2774    Apple says that web apps can be made readily accessible on iOS devices. An iOS user can create a button on the homepage of their iOS device for webpages, which enables the immediate launch of the app, thus saving the user the need to open a browser and navigate to the webpage.

2775    A website or progressive web app (PWA) can be configured to display a banner, which can be used to invite users to add the website or PWA to their home screen.

2776    The same technique for adding a home screen link on an iOS device can be used to create shortcuts to pages on websites. So, a Fortnite user can create an icon for the Epic Games Store site or the page on the Epic Games Store website where V-bucks are sold, and provide a ready means of accessing that option to purchase V-bucks.

2777    Now Google has made analogous arguments which it is more convenient to address here than in my separate reasons in the Epic v Google proceeding.

Web apps – Google’s arguments

2778    Google says that web apps provide a close competitive constraint on the services provided by Google Play for four reasons. First, they provide a means of consuming and/or purchasing app-based digital content on any mobile device, because a web app is delivered via a web browser. Second, web apps are a functional substitute for many kinds of native apps, and the level of this functional substitutability is continuing to increase. Third, many prominent app developers use web apps, and in some cases do so exclusively. Fourth, these facts mean that web apps represent a significant revenue threat to the Play Store, because Google earns no service fees on purchases of app-based digital content via web apps.

2779    When a web app is distributed to an Android mobile device other than via the Play Store, Google does not receive a service fee when digital content is purchased within that web app.

2780    Although web apps and PWAs are often referred to interchangeably within Google, there are differences between them. A web app is experienced entirely within a web browser. A PWA is a website with a manifest file that defines its name, the icon for the home screen of a user’s device, and whether the app should use the typical browser user interface or display in full screen. When added to the home screen, the icon effectively serves as a convenient launchpad from the home screen to the web browser. PWAs typically offer other additional features, such as push notifications, offline use, Bluetooth functionality, and the ability to display the app as a full screen.

2781    Now Google helps developers to build PWAs, including by offering a free course “Learn PWA” which teaches developers the fundamentals of PWAs, how to upgrade existing web content to a PWA and how to create an offline, installable app. It maintains a dedicated developer relations team that frequently publishes content relating to PWAs so that developers can better understand what they are and how to create them.

2782    Google’s focus on PWAs is in contrast to Apple, which has not embraced PWAs. Web developer groups have repeatedly criticised Apple for the lack of PWA support in Apple’s web browser, Safari.

2783    Now Epic says that web apps are not close substitutes for native apps essentially for two reasons. First, it says that the user experience differs substantially between native apps and web apps, principally because web apps are said to have significant inherent functional limitations which native apps do not share. Second, it says that the limitations of web apps mean that developers must use native apps instead of web apps or otherwise substantially compromise the functionality of their apps. But Google says that there are several problems with Epic’s position.

2784    The first problem is that when one has regard to the types of native apps that are popular amongst users, especially those on which users transact and accordingly make up the largest share of the Play Store’s revenue, it is apparent that web apps can and often do serve as functional substitutes for those sorts of apps. In this respect, whilst a web app would not in every case be an exact functional equivalent of a native app, this does not detract from web apps being meaningful substitutes for many, if not most, kinds of native apps. This is because native apps come in all shapes and sizes.

2785    So, the native app, Fortnite, is an “AAA” gaming app. Indeed, it was the first AAA gaming app brought to mobile devices, such as Android, in its AAA form. Such titles are typically of higher quality than most other gaming apps available on mobile devices. They demand more of the mobile device’s memory and storage, especially because of their graphical quality. Fortnite can be played on NVIDIA GeForce Now and Xbox Cloud Gaming, which are both available as web apps and allow Fortnite to be played on mobile devices.

2786    But not all gaming apps that are distributed on Android devices, whether on or off the Play Store, are as demanding as Fortnite. Most are not. In most cases, those apps are far from demanding on an Android device’s capabilities, and as such are more than capable of being provided as a web app.

2787    Take, for example, the native apps that constitute the largest category by spending on the Australian Play Store, namely gambling or casino apps.

2788    In 2021, the developers of the top 10 apps represented [REDACTED] of the Australian Play Store’s service fee revenue. The developer of the top grossing app, [REDACTED] [REDACTED], an entity named [REDACTED], was associated with [REDACTED] of the Australian Play Store’s service fee revenue.

2789    Three of the top five highest grossing apps are casino or slots apps, that is, [REDACTED] [REDACTED] [REDACTED] The fourth highest grossing app, [REDACTED] [REDACTED], is a casual game, that is, not one that requires high end graphics or processor speed.

2790    Now for casual, less sophisticated or simple apps like casino apps, the difference between a native app and a web app is likely to be of much smaller scale and the web app may work just as well as the native app. The more casual the app, the more that a web app is less disadvantaged compared to a native app. Casual apps of this nature would include shopping apps and social media apps.

2791    Now for video apps like YouTube or TikTok, for example, the web app could also work quite well, albeit without some additional functionality such as the ability to download videos to watch later offline.

2792    Mr Richard Byers, a principal software developer for Chrome at Google, gave as an example the Twitter/X web app.

2793    In April 2017, Twitter as it then was named launched a PWA called Twitter Lite. Twitter observed a 65% increase in pages per session as compared to their previous mobile website, a 75% increase in tweets sent, and a 20% decrease in bounce rate, being the frequency of users leaving a website without taking any actions. It also led to lower data consumption, requiring less than 3% of the device storage space compared to Twitter for Android. X/Twitter presently continues distributing content via its web app.

2794    Mr Byers rejected the suggestion that as a general proposition users always prefer native apps over web apps. It depends on the use case, that is, how the user chooses to interact with the app. So, for example, a user would have no difficulty using web apps such as video streaming apps, given that such content is just as easily accessed on a website.

2795    Mr Byers also disagreed with another general proposition that was put to him, being that web apps are subject to inherent technical limitations which means that they do not perform as well as native apps. He said that there was much misunderstanding about that topic, and that to say that web apps perform poorly when compared to native apps is incorrect.

2796    In response to the suggestion put to him that the proposition is borne out by Google’s internal documents, he replied by disagreeing with the characterisation of the documents. Google seeing opportunities to make web apps better is not tantamount to Google admitting that web apps are poor substitutes for native apps.

2797    Google also says that the second problem with Epic’s assertion that web apps are not close substitutes for native apps is the lay and expert evidence that was to the effect that where there are functionality gaps between native apps and web apps, they are diminishing, and rapidly so.

2798    Mr Grant acknowledged that there have been improvements in the capabilities of web apps from the time of his first affidavit in the Apple proceeding, October 2022, being a period of about 1.5 years.

2799    Mr Owens considered that web technologies had improved to the point where some web apps could utilise many of the device functions on a mobile device, just like a native app. For example, web apps can be coded to make use of a phone’s camera and to send notifications to users just like a native app.

2800    Further, Google has worked to improve the experience and capability of web apps and continues to do so. Google invests in web apps at least in part because it has a powerful financial incentive to do so. Operating in a web browser such as Chrome generates mobile ads revenue. Google has made faster progress than Apple in supporting features available to web apps.

2801    Now Mr Byers confirmed that Google has realised that it needs to meet Android device users where they are by offering them web apps that create the experience of a native app even if under the hood so to speak it is in fact a web app. From at least 2015, that has been Google’s aim.

2802    Google does not want users experiencing web apps to report a poor experience or to think about whether the app is a native app or a web app. It wants to make web apps better for users and developers even if that might result in greater competitive pressure on the Play Store. He referred specifically to a long-running internal project “Fugu”, which was previously called “Fizz”, which was focused on closing the capability gap between web apps and native apps. This work is continuing and web apps are getting better at simulating the experience of a native app.

2803    Further, many of the internal Google documents that Epic says show the functional limitations of web apps are some years out of date. They do not reflect current web app functionality. Web apps is an area that is undergoing rapid development.

2804    Google says that the third problem with Epic’s position that web apps are not substitutes for native apps is that web apps also have advantages over native apps that partially offset any disadvantages.

2805    Mr Grant acknowledged the following points. First, both web apps and native apps have certain advantages and certain disadvantages. Second, for some types of web apps, there are likely to be much lower cross-platform development costs than for native apps. Third, for certain types of apps, web apps are substitutable for simpler apps that have a lower set of requirements on mobile device hardware, for example, a web store like Amazon, apps where the user is interacting with the app in a casual manner or a social media app. Fourth, on the question of discoverability, users can search for web apps using Google Search or any other internet search engine. Fifth, for more casual games, being games appealing to a wide audience, a web app can work well. Sixth, web apps are updated on the internet as and when the developer chooses. Unless there is an update to the OS required to make use of the updated web app functionality, updates to a web app do not depend on a user downloading and installing an update. This is a way in which web apps give the developer control over the content and frequency of updates.

2806    Further, Mr Owens acknowledged that he has observed a shift in developers, who have native applications and web applications, trying to incentivise or shift customers, who can purchase products in both places, to make in-app purchases on the web rather than in native apps so that developers can take advantage of less restrictions or lower fees.

2807    In other words, there has been some shift in monetisation from native apps to monetisation on the web. But the extent of growth in this trend is debatable.

2808    Mr Owens also acknowledged that he had publicly stated that web apps could be built that bypassed the systems for native apps and “provide just as good an experience” and that “we’re going to increasingly see that more and more”. Mr Owens thought that “companies are going to start with this shift from app to web … to get around a lot of these fees”. Mr Owens provided his view on how things might develop in the future, that is, that there would likely continue to be a shift from native apps to web apps, and that the shift would allow developers to avoid having to pay app store fees on the App Store and on the Play Store.

2809    Mr Byers also gave evidence of the advantages enjoyed by web apps, especially from the perspective of developers. They include cross platform functionality, familiar and accessible app development technology such as JavaScript, CSS and HTML, greater discoverability, as web apps being websites are indexable by default and easily caught by a web search, and increased user engagement upon launch of a web app. Further, no service fee is payable to Google whether on a cost of accessing the app or making purchases within it.

2810    Google says that web apps also have development cost advantages over native apps.

2811    A developer who already has a website may need to decide to build a native app or extend the website to a web app. Many may choose to forgo the costs of building a native app and expand their existing investment in the website to make it a more modern web app. For a developer who already has a website and is looking to expand app discoverability or improve user engagement, a web app is a viable option. It may only require a small investment in converting a website into a web app as opposed to building a new native app.

2812    Further, many app developers prefer to distribute their web apps for reasons of discoverability and cost-efficiency, converting existing websites into web apps rather than building native apps. Some developers may bypass native apps altogether.

2813    Now Epic sought to criticise Mr Byers for presenting an unbalanced picture and for being an advocate for Google because he did not address the disadvantages of web apps in his evidence in chief or, as Mr Byers put it himself, he did not “make the case for native apps”. Google says that those criticisms are unwarranted for the following reasons.

2814    First, Google says that it is implicit in Epic’s criticism that Mr Byers assumed the role of an independent expert witness. While aspects of his evidence were adduced through the prism of s 79, that does not mean that he was put forward as an independent expert. He has been an employee of Google for over 13 years.

2815    Second, Google says that it is unsurprising that Mr Byers sought to defend web app functionality in his evidence when the main focus of his role at Google is to improve the experience of the web in Chrome and to most effectively distribute digital content on web browsers. It says that it is unsurprising that a company executive would speak to the merits of the product for which they are personally responsible.

2816    Google also says that there is a further problem with Epic’s position that web apps are not close substitutes for native apps because of supposed difficulties with using web apps. Web apps are used by Android users and developers alike and used extensively.

2817    For many developers and content providers, websites and web apps are the sole means of distributing their content on Android devices.

2818    Many prominent app developers that offer content and monetise content do so by website as well as by app whether native or web, including dating services like Tinder and Bumble, social media platforms such as Facebook and Twitter/X, and news services such as The Age, the Australian Financial Review and The Australian.

2819    Data contained in Google’s internal documents reveal the steady growth of daily active users (DAU) of PWAs on mobile and desktop. They have been embraced by many large developers and OEMs, including Microsoft and Samsung.

2820    As of April 2023, 24 million users use an installed web app on Android each day and 140 million users use an installed web app on Android each month. This usage accounts for 1.8% of the time spent in Chrome on Android. Given the volume of activity that no doubt occurs on the world’s most popular web browser, that proportion is far from being trivial.

2821    Web apps also contribute to a significant portion of new mobile user acquisition for many of the most popular apps, for example, 28.25% for Pinterest, 27.76% for Snapdeal, 22.52% and 20.18% for Facebook Lite and Facebook respectively, 14.74% for Shopee, 13.06% for X, 8.53% for Instagram and 7.26% for Amazon.

2822    Let me deal with some other matters raised by Google with respect to the expert evidence.

2823    Now Epic seeks to support its assertion that users do not consider web apps to be close substitutes for native apps by referring to Professor Goldfarb’s “clicks are costly” concept. It says that web apps have more “clicks”. But Google says that this assertion is problematic.

2824    First, Google says that it is wrong to say generally that web apps require more clicks than native apps. There is friction in all app install processes, native or web.

2825    Professor Somayaji gave inconsistent evidence about this, saying on the one hand that web apps are easily procured by users, but then proceeded to spend a subsection of his report endeavouring to show the supposed burden when trying to install them.

2826    As Professor Traynor observed, the screen flows contained in that section of Professor Somayaji’s report are selective, with the flow describing the installation of a native app from the Play Store already starting with the user having navigated to the app page.

2827    Second, Google says that these problems with Professor Somayaji’s evidence carry over to Professor Goldfarb’s evidence to the extent that the latter relies on the former.

2828    Third, Google says that in any event, even if web apps do involve more clicks, Professor Goldfarb’s appeal to behavioural economics without empirical data to support it does not allow me to conclude anything with respect to the use of native apps versus other types of apps including web apps.

2829    The literature on which Professor Goldfarb relied to support the proposition that “clicks are costly” is not relevant to the choices made by users of Android devices, let alone the choices they might make as between native apps and web apps.

2830    Now putting Professor Goldfarb’s “clicks are costly” to one side, Google says that what matters for market definition is whether sufficient customer spending would divert from the hypothetical monopolist to substitution possibilities enabled by the web among other possibilities in response to increased prices or lower quality.

2831    Sufficient customer spending can divert even if a subset of developers partially substitute to web apps, websites or webstores and continue to distribute via Android app stores.

2832    In this regard, many apps, being both native apps and web apps, are integrated with and steer users toward the app developer’s website on which they can transact, typically at a discount. They include Spotify, Twitter/X, Facebook, Words with Friends 2, TikTok, and Pandora. Some apps are consumption-only in the sense that no transaction occurs in app but must occur on the app developer’s website. The Netflix app can be downloaded on the Play Store for free but requires a subscription which can only be obtained on Netflix’s website. Other examples include Kindle owned by Amazon and Stan.

2833    Google says that Professor Asker also considered that web apps are competitively meaningful substitutes for some native apps and not for others. Substitution is competitively meaningful where some developers and users accounting for a sufficient share of the Play Store’s revenue are willing to substitute. For many apps, especially those lower end casino apps not requiring high performance of an Android device being the category of apps which accounts for the largest share of the Play Store’s revenue, web apps are a cheaper and equally effective distribution channel. Substitution does not have to be all or nothing.

2834    Professor Asker gave two examples that are illustrative of the power that developers wield.

2835    First, Spotify threatened to pull its content from the Play Store and rely on web distribution unless Google discounted its service fee. Google did so, lowering it to 4% of any content purchased within any version of Spotify downloaded from the Play Store. Such manoeuvring is consistent with Spotify viewing its webstore as a sufficient substitute to the Play Store to forgo using it for any in-app transactions.

2836    Second, Netflix rebuffed Google’s offer of a discounted service fee of 10% in return for allowing in-app transactions. To this day, its app functions on a consumption-only basis. This is consistent with Netflix viewing its website, on which transactions can occur, as a sufficient substitute to the distribution of its app via the Play Store.

2837    Further, Google said that the difficulty with Ms Edwards-Warren’s analysis is that it focuses inappropriately on functionality of access and not where users and developers transact. But even taking up Ms Edward-Warren’s metric of usage, Professor Asker still reached the same conclusion being that web apps impose some constraints on native apps.

2838    Now in his exhibit 71, which I have not seen necessary to reproduce, Professor Asker summarised the ComScore data to identify the top 20 apps with the highest percentage of consumer usage via websites or web apps that also are among the top 5% of apps by overall consumer usage, restricted to apps that have a native app. The summary reveals that there are several well-known apps with high web app share including several news and retail websites. Google says that this is consistent with web apps being close substitutes in usage for some types of native apps.

2839    In exhibit 72, which I have also not reproduced, Professor Asker summarised the same ComScore data to identify the top 20 developers by total consumer usage that meet the following conditions. First, they must offer some content via both a website/web app and a native app. Second, both the website/web app and the native app must be among the top 5% of websites/web apps and native apps by usage respectively. The summary reveals that many prominent developers distribute content using both a website/web app and a native app, including developers of social media sites, music streaming services, video streaming, and games.

2840    Indeed for some of these developers, their top native app is no different from its web app, confirming that native apps and web apps can offer similar functionality.

2841    So, Google says that web apps and websites are not only functional substitutes for many kinds of apps, but substitutes for native apps, and therefore a competitive constraint on the Play Store.

Analysis – web apps

2842    Now of course on the question of market definition I am dealing with the question of substitution in terms of close constraints. And on any view, none of Apple’s or Google’s assertions or the evidence that they refer to goes anywhere close to establishing that web apps or PWAs are close constraints.

2843    And even accepting that they may offer some competitive constraint to both Apple and Google they go nowhere close to negating each of their substantial degree of market power.

2844    Now as should be apparent from what I have already said, web apps are app-like pages that run in a web browser, and they are not developed using a platform specific language but rather run on web technologies. And PWAs are web apps with some improved functionality compared with other more basic web apps.

2845    Contrastingly and as I have already explained, native apps are apps that are programmed to operate on a particular operating system and are developed using programming languages that are specific for the intended platform and cannot be run on a different operating system.

2846    In my view web apps are not close substitutes for native apps. It cannot seriously be doubted that the user experience differs substantially between the two. Web apps have significant inherent functional limitations which native apps do not share, and the limitations of web apps mean that, in many cases, developers must use native apps instead of web apps or otherwise substantially compromise the functionality of their apps.

2847    Clearly, native apps are superior to web apps. And users prefer native apps because they typically provide the best user experience.

2848    Moreover, and as Epic points out, as users and developers do not treat web apps as close substitutes for native apps, the prospect of developers and users switching to using web apps in response to a small change in the relative price or quality of iOS app distribution services and Android app distribution services does not closely constrain Apple or Google.

2849    Further, web apps are only a potential indirect constraint on the App Store and the Play Store. As Epic points out, web apps do not involve the consumption of app distribution services from an alternative supplier. Instead, app users are sourcing the native app or the web app themselves and app developers are finding interested app users and delivering the apps to them. As such, any constraint arising from the possibility that developers and users might switch to relying on web apps is at best only an out-of-market constraint.

2850    Further, the use of web apps does not involve the use of any alternative app distribution services, as it is simply a particular version of a developer’s website.

2851    Further, web apps have significant inherent limitations which mean that they are not close substitutes for native apps.

2852    Professor Somayaji’s evidence, some of which I have set out elsewhere, was that web apps are confined and restricted by the browser in ways that native apps are not, so in many situations web apps cannot offer the same user experience as native apps. Web apps on iOS are restricted in the memory, CPU, and local storage they can use. They also cannot for example use Bluetooth devices, or update when not being used, among other limitations.

2853    Whilst Apple recently enabled push notifications and app badge count for web apps, and imposed a new overall web app storage quota of 20% of the total disk space, a large number of other limitations identified by Professor Somayaji remain.

2854    In respect of web apps on Android, Professor Somayaji gave evidence that web apps are likewise restricted in the memory, CPU, GPU, and local storage they can use. Further, web apps are limited in the way that they can access hardware sensors and location data.

2855    And as I have set out elsewhere, Professor Somayaji gave evidence that web apps are further limited in other ways. They are unable to run native code, which adds to the total use of computing resources required for web apps versus native apps. They have slower overall performance compared to native apps due to the need to access resources stored on servers. They typically must communicate with a web server, requiring access to the internet. Further, in the iOS environment, web apps cannot access several core app features that are available to native iOS apps, such as biometric authentication, Siri, task scheduling and pairing with Bluetooth devices.

2856    Now whilst accepting that Instagram, Facebook and Tinder all have web apps on iOS devices, Professor Somayaji observed that there generally are flows to try to direct users of Instagram, Facebook and Tinder web apps to native apps.

2857    Whilst push notifications may have improved certain web app functionalities, developers’ continued effort to direct users to native apps is illustrative of the reality that web apps continue to suffer from functional limitations compared to native apps.

2858    Similarly, whilst storage associated with the operation of web apps on iOS may be sufficient to allow some casual games to work, storage quota could remain a limiting factor for other web apps, including for AAA games with detailed graphics like Fortnite.

2859    Further, functionality for web apps on iOS devices is further limited by the lack of support Apple provides for certain web APIs. As I have indicated elsewhere, Apple requires that all iOS browsers adopt WebKit as their browser engine. And the enabling of access to additional web APIs, which is within Apple’s control, does not overcome the limitations inherent to web apps as a consequence of their restriction by the web browser itself.

2860    Web apps are also slower at executing code than native apps. Unlike native apps, web apps are written in programming languages that are not specific to, or written in conjunction with, SDKs, and so its code cannot be compiled directly into machine-readable code but instead must be “interpreted” by the web browser in which it is executed. The process of interpretation adds computational time to the execution of an app and results in the processor executing less efficient code. As a result, interpreted code is generally three to five times slower to execute than compiled code.

2861    The result of this slower execution of code is that the performance of a given web app can be materially slower than that of an equivalent native app, and the user’s experience of the app suffers as a result of the delay.

2862    Now as I have said above, Google relied upon the evidence of Mr Byers to support its contention that web apps are close substitutes for native apps. But Mr Byers did not provide a balanced picture of web apps compared with native apps. Further, he did not undertake a balanced assessment of where web apps stand compared to native apps in terms of privacy and security.

2863    Now Mr Byers was taken to a 2020 document produced by Google titled Stateful Pilot Platforms Analysis, which compared performance issues of web apps and native apps (Android or iOS), and contained the statement “due to various constraints on the mobile environment, web [user interface] rendering performance just isn’t on the same level as native which directly translates to suboptimal user experience on mobile devices”.

2864    Mr Byers acknowledged that the document’s authors seemed to be saying that this was a reason why Google chooses to develop a native iOS app, a native Android app, and a desktop web app for some of its particular proprietary apps. Mr Byers agreed that the conclusion reached by the document’s authors, having examined the different capabilities of web apps and native apps, was that they are not mutually exclusive but complement each other in overall product and branding experience.

2865    Mr Byers also accepted that users often perceive native apps as more powerful, immersive and secure than websites in a browser, even if the underlying content is the same. He accepted that he had heard that it was a common perception of users that web apps, in comparison to native apps, “just feel off”. And he accepted that mobile device users have a strong preference for using native apps ahead of web apps or PWAs.

2866    Further, as Epic points out, the evidence establishes that web apps are less easily discovered and accessed by users on iOS because they cannot be found and downloaded from the App Store.

2867    Further, web apps face significant discoverability difficulties on Android as well. As Epic points out, when taken to Google’s document titled Progressive Web App Strategy 2021, Mr Byers acknowledged the following matters.

2868    First, if web developers do not have a ticket to participate in app launching and in discovery surfaces where users have been trained to find experiences on their device and where they frequently re-engage, they will choose native technology.

2869    Second, such users are likely to choose native technologies ahead of web apps to meet their needs. Now Mr Byers sought to qualify this by asserting that the authors’ intention was not to suggest that users will always choose native apps. Instead they were saying that there is a risk that they will, or that they may choose. But I reject such a qualification. As Epic points out, Mr Byers did not say that he had any qualifications about the accuracy and completeness of this strategy paper when he exhibited it to his affidavit.

2870    Let me say something specifically about PWAs. PWAs involve the installation of a webpage shortcut on the home screen. But even they fall materially short in terms of functionality compared with native apps.

2871    Professor Somayaji explained that due to the introduction of new web features, PWAs can be accessed through home screen icons like a native app and support some amount of offline functionality. But they still run in the web sandbox and thus are functionally restricted in many of the same ways that basic web apps are.

2872    As a result, PWAs do not meaningfully narrow the gap with native apps in terms of functionality and performance.

2873    Further, I agree with Epic that such documentary evidence as there is supports the proposition that Apple and Google are not constrained in their provision of app distribution services by the prospect of developers and users making use of web apps. No available internal documents suggest that either Apple or Google considers itself constrained in any meaningful sense by the prospect of developers switching to using PWAs.

2874    Further, as Epic points out, Mr Byers’ evidence during cross-examination was consistent with the view that PWAs are not close substitutes for native apps. Mr Byers acknowledged that PWAs will not replace native apps in the near future, and that it is true generally that mobile ecosystems are mostly about native apps, which remains true today.

2875    Let me turn to the question of whether users consider web apps to be a close substitute for native apps. Clearly, users do not treat web apps as close substitutes for native apps. Let me elaborate on some of the evidence.

2876    Now Professor Goldfarb hypothesised that web apps including PWAs would be used less frequently than native apps. Professor Goldfarb considered this hypothesis to be consistent with the “clicks are costly” label, which refers to the fact that additional steps reduce the consumer completion of actions.

2877    For some web apps, the steps required to access them are not as simple as the steps required to access native apps. For instance, to install a native app from the App Store, there were three steps; to install a native app from the Play Store, there were two steps. But to save a PWA icon to an iOS device’s home screen or to an Android device’s home screen to allow access comparable to a native app, there were five steps. Further frictions include logging in, accessing a password, searching for a domain or connecting to Wi-Fi. These limitations result in more limited web app usage.

2878    Professor Goldfarb tested this hypothesis empirically and concluded that neither iOS device users nor Android device users treat native apps and web apps as substitutes, except to a limited extent. Professor Goldfarb found that 85% of iOS device use and 89% of Android device use is on native apps. Professor Goldfarb said that if web apps were interchangeable with native apps, he would expect to see similar use across web apps and native apps. Instead, he saw an overwhelming preference for native apps, suggesting that users do not view them as interchangeable. He also found that based on separate analyses of data for the top 20 properties accessed by iOS device users and Android device users, users of those properties used the native app version the vast majority of the time. For both iOS devices and Android devices, users used native apps for 90% or more of time spent on most of the other properties considered.

2879    I agree with Epic that Professor Goldfarb’s analysis, which was based on time spent by users, is evidence of an absence of close substitutability.

2880    Now Professor Hitt undertook his own analysis, which was based on the proportion of users who have ever accessed a web app. Professor Hitt argued that Professor Goldfarb’s analysis of the data was flawed because it ignored the possibility that people can use these other things. Professor Goldfarb’s focus was on the quantity of usage. But Professor Hitt’s focus was on the possibility of usage, because “if you know you can use something, then it’s possible that you could switch under certain conditions”. But I agree with Epic that this speculation does not really assist in determining what users would do in response to a small price increase.

2881    As Professor Goldfarb noted in response, evidence that people can do two different things over a long time period is consistent with three different hypotheses. One is that they are substitutes, another is that they are complements, that is, they are used together, and another is consistent with the relevant markets being independent markets. Professor Goldfarb noted that often it is observed that people do two different things that effectively have nothing to do with each other. So, he did not see this analysis as being evidence for substitution or evidence for anything else. He thought it was a fact that is not relevant to the question.

2882    Whilst Professor Goldfarb’s analysis does not show any shift in usage following a price increase, it is relevant qualitative evidence that assists to understand consumer preferences and the costs of switching.

2883    Further, I agree with Epic that Professor Hitt overstates the popularity of web apps. Some users may briefly access a web app once but switch to using the native app version because they prefer the native app experience.

2884    Further, Professor Goldfarb compared the time spent on native apps with the time spent on web apps. He found that for every 10 minutes spent on native apps, iPhone users spend only 1.43 minutes on web apps.

2885    Now Professor Asker said that there are many popular apps for which consumers readily engage via websites or web apps by identifying the top 20 apps with the highest percentage of consumer usage via websites or web apps which were also among the top 5% of apps by overall usage. But as Epic points out, there were obvious defects with this analysis.

2886    First, as identified by Professor Goldfarb, the apps identified by Professor Asker represented a minimal amount of overall usage of Android smart mobile devices.

2887    Second, Ms Edwards-Warren pointed out that the apps identified by Professor Asker accounted for a tiny percentage of Google’s revenues, so that even if the developers of the apps identified by Professor Asker could divert all consumer spending to websites or web apps, it would be unlikely to discipline a hypothetical monopolist.

2888    Third, Professor Asker’s evidence that use of websites and web apps is increasing in relative terms over time did not address the fact that the relative increase was coming off a very low base and the increase in absolute terms is still very small.

2889    Overall, I agree with Epic that Professor Goldfarb’s analysis, which was based on actual use, is better evidence of substitutability than Professor Asker’s analysis based on whether products could be substitutes in theory. This is because the latter analysis does not show whether users or developers consider the use of one product to be reasonably interchangeable with another. So, as Epic pointed out, developers having web apps available does not suggest that such web apps are treated as substitutes for native apps by users. Such web apps could be independent or a complement to native apps.

2890    Further, Professor Goldfarb found that users do not treat native apps on iOS devices as substitutable with web apps, except to a limited extent and that this lack of substitutability is due to several factors, including that consumers do not consider most web apps to be functionally comparable to native apps, many developers find web apps technologically inferior, and there are additional user frictions (being the “clicks are costly” concept) that increase the cost for consumers to substitute from native apps to web apps.

2891    User frictions in moving from a native app to a web app on an iOS device is just one factor limiting substitutability. There are many technical factors that make web apps less enjoyable for consumers and make developers less willing to develop a web app alternative. For example, there are technical barriers for developers to create certain apps for Safari as rich as native apps.

2892    Consumers rarely use web apps compared to native apps. This shows the lack of substitutability between native apps and web apps. The interpretation of usage statistics was informed by documentation on the technical differences between native and web apps leading them to be differentiated products.

2893    The article authored by J. Xu et al, “News media channels: Complements or substitutes? Evidence from mobile phone usage” (2014) 78(4) Journal of Marketing 97 provides further background on why consumers do not treat web apps and native apps as substitutes, except to a limited extent. As Epic pointed out, the authors found that the introduction of a Fox News mobile app led to an increase in demand for the Fox News mobile site and concluded that this was evidence of economic complementarity.

2894    This research is consistent with Professor Goldfarb’s opinion that consumers do not consider web apps and native apps to be similar along key dimensions and thus treat them as independent products or, as with the Fox News mobile app and web app, engage with them in a complementary manner.

2895    Further, in my view actual use is more informative to understand substitution than if a user ever used a web app versus a native app.

2896    Professor Hitt said that many web apps, which include developer browser-based web sites, are competitive alternatives to native apps on iOS as most people have used both. He says that almost all iPhone and iPad users access both web apps and native apps on iOS devices, citing statistics relating to whether an iPhone or iPad user had ever accessed a given property on a native app or a web app. Professor Hitt further found that the number of unique iPhone and iPad users of Google, Facebook, Amazon, Microsoft, Twitter, and Comcast through web apps exceeds the unique number of users through native apps, and that this is further evidence of substitution.

2897    Contrastingly, Professor Goldfarb considered the total amount of usage and found that consumers use native apps much more than they use web apps. If consumers considered native apps and web apps as interchangeable, Professor Goldfarb would have expected to have seen more equal rates of usage.

2898    Professor Goldfarb found that 88% of iPhone app usage and 77% of iPad app usage is through native apps. For every 10 minutes spent on native apps, iPhone users spend only 1.43 minutes on web apps and iPad users spend 3.00 minutes on web apps. Numbers are calculated as the ratio of web app total minutes per device divided by the native app total minutes per device multiplied by ten. The large discrepancy in actual time spent highlights that users do not use web apps as much as native apps. This could be driven by the worse user experience and the requirement to engage in more steps to use web apps.

2899    The fact that consumers rarely use web apps in comparison to native apps is evidence that consumers do not treat native apps and web apps as substitutes, except to a limited extent.

2900    The same holds for the properties that Professor Hitt mentioned. For every 10 minutes that an iPhone user spends on a native app for Google, Facebook, Amazon, Microsoft, Twitter, and Comcast, they spend only 3.58, 0.69, 1.08, 2.73, 0.53, and 1.64 minutes on their respective web apps. For iPad users, similarly for every 10 minutes spent on a native app for Google, Facebook, Amazon, Microsoft, Twitter, and Comcast, a user will spend only 5.58, 0.55, 1.88, 4.69, 1.55, and 0.27 minutes on the respective web apps for these properties.

2901    Professor Goldfarb noted that use of Google via web app is an outlier in terms of time use. Given that the Google web app also includes Google Search and Google Search is often the default web page when a user opens a browser, which gives rise to a significant reduction in user friction, the measure of time use on Google Search relative to the native app is to be expected.

2902    This does not suggest that users would readily substitute to web apps if, for example, there were an increase in the price of transactions through native apps.

2903    In Professor Goldfarb’s opinion, limited multi-homing is not evidence of substitution. People can do two different things, such as eat both cheese and bread, in a complementary or independent manner. People can also do something once and have a bad experience and so not do it again, such as paying a bill in a mobile browser versus through an app.

2904    The evidence Professor Goldfarb provided on consumer use of native apps and web apps shows that users engage with native apps far more than web apps, and do not treat web apps as substitutable with native apps, except to a limited extent.

2905    Further, in my view developers do not consider web apps to be close substitutes for native apps.

2906    As Professor Goldfarb explained, because developers are seeking to attract and retain a large consumer base, they are incentivised to follow the preferences of their consumer base. Accordingly, the limited uptake of web apps by consumers will limit developers switching to use web apps as a substitute to native apps.

2907    Further, Professor Goldfarb found that the limitations on web apps compared with native apps are likely to influence the actions of developers, including by reducing the prospect of them developing web apps where the limitations on web apps would impact consumer experience.

2908    Indeed, Mr Grant gave evidence that it would not be possible to deliver the Fortnite experience, or even any significant aspect of it, via a dedicated Fortnite web app and such a web app would not offer a version of Fortnite that would be in any way similar in quality to games implemented as native apps. The slower performance of web apps means that, if Fortnite were offered as a web app, its frame rate would either be so slow that the app would be essentially unplayable, or the quality of the graphics would have to be reduced to the point they were unappealing.

2909    Mr Grant identified extensive reasons why web apps are not suited to the development of Fortnite and outlined other general limitations of web apps, including the following.

2910    The first aspect concerns limited gaming functionality. Both iOS and Android web browsers have more limited functionality than native apps which means that much of the functionality which allows Epic and other developers to create immersive and innovative native apps like Fortnite for iOS and Android devices cannot be replicated in web apps.

2911    Extended reality (XR) functionality like augmented reality, mixed reality, and virtual reality experiences, which have become an increasingly popular method for accessing digital content, are not available for web apps, limiting the deployment of many XR experiences on iOS and Android to native apps.

2912    Further, web apps are unable to achieve the level of graphical performance offered by native apps, simplifying or removing many aspects of the gaming experience, which would result in a less engaging user experience and a more limited version of the app.

2913    The second aspect concerns the limited download process. Because downloading a web app requires the user to keep their browser open for the duration of the download, as compared to native apps which can download apps and updates in the background, users are faced with the following inconveniences.

2914    First, users are unable to access other apps during the download process.

2915    Second, users are required to keep their web browser open, leave their phone unlocked, and prevent their phone from falling asleep for several minutes at a minimum during both the initial app installation process and app updates. Mr Grant noted that this would be a particular issue for Fortnite, as it is regularly updated to provide users with new gameplay and cosmetics. Whilst these updates are smaller than the initial install, each update would require the user to leave their phone unlocked with the web browser open for several minutes.

2916    Third, web apps provide some very limited offline functionality due to memory limitations, unlike native apps which are capable of being used even when the user is not connected to the internet. Games like Fortnite and Rocket League Sideswipe, if released as a web app, could not be played offline due to their memory footprints.

2917    Further, Mr Grant stated that other limitations of web apps include their limited ability to function in the background, as would be required by a music or podcast app, their inability to allow “‘background fetch’ or ‘background sync’”, which allow apps to gather updated information such as news or podcast episodes without user interaction, their inability to access the vibration function on mobile devices, their limited control over the keyboard of mobile devices, for example, they cannot show and hide the keyboard on demand, and their inability to warn users when the app is using significant memory.

2918    Further, Professor Somayaji gave examples of iOS apps which do not have corresponding web apps or have web apps with restricted functionalities. Further, Professor Somayaji also gave examples of Android apps with essential features which cannot be provided via web apps. Further, Professor Somayaji also gave examples of web versions of Google’s first-party apps which include messages to direct users to their native app counterparts, with messages on some web versions informing users that native apps offer better experiences. None of this evidence was the subject of serious challenge.

2919    Let me deal with one more topic that addresses the fact that Apple restricts web app functionality.

2920    Compared to native apps, web apps have an additional technology layer, the browser engine, which translates information between the web documents implementing the app and the OS facilitating the code’s functionality.

2921    Whether or not the browser engine supports the technical translation of functionality between a given web document and the OS is determined by the standards implemented by the browser developer. Professor Somayaji explained that to a large extent, web apps access device functionality such as the camera, memory, and sensor data through web APIs.

2922    Web browsers on iOS can support and utilise fewer web standards, which are implemented through web APIs, than web browsers on non-iOS OSs, such as Chrome on Android, because iOS WebKit does not support several important web APIs.

2923    Apple requires all browsers on iOS to adopt Apple’s WebKit as the browser engine, and forbids other browser engines from operating on iOS. This means no iOS web apps can access these important APIs. As such, iOS web apps have even less functionality than a non-iOS web app.

2924    Professor Somayaji listed 19 APIs that are available to iOS native apps and to non-iOS web browsers but not iOS browsers due to iOS WebKit. Some of these APIs represent core app functionality such as the Task Scheduler API, which allows apps to schedule a process or notification for a future time, or the Background Sync API, which allows apps to perform network syncing to enhance app performance.

2925    Indeed, and as Epic points out, the lack of substitution between web apps and native apps underpinned Apple’s original decision to enable third party native apps on iOS in response to developer and user demand.

2926    In summary, web apps are not close substitutes for the distribution of native apps on iOS or Android.

2927    I agree with Epic that the prospect of developers and users switching to using web apps does not closely constrain Apple in its supply of iOS app distribution services or Google in its supply of Android app distribution services.

2928    But even if web apps or PWAs offer some form of competitive constraint, they separately or in combination with other matters do not deny Apple’s or Google’s substantial degree of market power that I have discussed later, or provide any significant constraint on such power.

2929    Let me turn to the question of streaming services and begin with Apple’s arguments.

Game streaming services – Apple’s arguments

2930    Game streaming services operate by processing the relevant games on remote servers connected by the internet to a user’s device, and can be accessed on any device that has a web browser of the kind supported by the service.

2931    Apple says that this arrangement offers certain technical advantages over downloading and playing the native app version of a game. It made the following points.

2932    First, consumption can happen on any kind of connected device with a screen, typically via a web browser. As a result, games can be available and played on devices which otherwise may not have the technical capacity to run the game as a native app on the device. This is attractive to developers because of the opportunity to access a broader range of devices, such as low-quality Android devices. This has expanded the range of games available across platforms and the quality of games available on mobiles devices, and contributed to increasing convergence between the games available on various platforms.

2933    Second, developers can bypass the steps normally involved in developing a platform specific version of game.

2934    Third, because of the powerful servers that are used to run games on market-leading graphics cards, quality and frame rates on game streaming services are superior to mobile devices, consoles and most PCs.

2935    Fourth, on iOS devices, users can stream games by accessing a game streaming service through an internet browser or a web app. For example, NVIDIA GeForce Now is accessible on iOS through the Safari web browser. Users can create a shortcut icon on their iOS device so as to provide direct access to NVIDIA GeForce Now.

2936    Fifth, the experience using game streaming is similar to a PC gaming experience.

2937    Sixth, in-app purchases can be made within a game that is streamed on an iOS device. Apple receives no commission on these transactions with the developer, which are not visible to Apple.

2938    Now as Apple says, cloud streaming services enable users to stream apps, including games, remotely, without the app that is being streamed needing to be installed on the user’s device. Cloud streaming is in that sense platform agnostic, much like web apps. And as to games, there are two commercial models of cloud gaming services with some services offering a combination of the two. One model is where the cloud gaming service allows users to stream games from game subscription services. And another model is where the cloud gaming service allows users to access games that they already own but does not enable a user to play games that they do not already own. This model is known as the “bring your own game” approach.

2939    Further, Apple points out that resembling cloud streaming, albeit technically distinct, is “remote streaming”, which is also described as “remote play”. This is where a game is streamed from another device owned by the user, usually over a local Wi-Fi network, such as a PC or a computer as opposed to cloud infrastructure provided by a streaming provider. An example is PS Remote Play, which allows PlayStation users to stream content from their PlayStation console to any other device over a high-speed connection and at no cost.

2940    Now as Apple points out, the most popular cloud gaming services are the following.

2941    Amazon Luna is available on Windows PCs, Amazon Fire tablets, Chromebooks, as a web app within web browsers on iOS and Android devices, and on certain smart TVs. Amazon Luna offers access to a library of third party titles including Fortnite and titles available through Ubisoft+, Jackbox Games or Amazon’s Luna+ catalogue.

2942    NVIDIA GeForce Now is available on Windows and Mac PCs, Android TV, Shield TV, a streaming device for TVs, Google Chrome, iOS via a web browser and Android. Users can access games that they have previously purchased, such as via Steam or the Epic Games Store, or which are available under a compatible game subscription service. NVIDIA and Microsoft recently announced that some games available via PC Game Pass / Game Pass Ultimate will be streamed on GeForce Now.

2943    PlayStation Plus, under which subscribers to the highest tier of Sony’s PlayStation Plus can remotely stream certain games from its library of first-party and third-party titles to their PlayStation 5 console.

2944    Xbox Cloud Gaming (xCloud), under which subscribers to Microsoft’s Game Pass Ultimate subscription tier can stream a wide library of games to their Xbox, Windows PC, iOS device via a web browser, Android device and certain smart TVs. Fortnite can be played on xCloud.

2945    Other cloud gaming services include Boosteroid and Blacknut, both of which are available on Android devices from the Play Store and via the web.

2946    Apple says that the promotional material used by the game streaming services reflects an appreciation that those services supplement or are alternatives to platforms that operate by facilitating the downloading of native apps.

2947    Let me turn to another topic.

2948    Now game streaming services require an internet connection to operate. But Apple says that the connection need not involve particularly high internet speeds. Game streaming typically requires only a stable internet connection at a reasonable speed. Apple makes the following points.

2949    The requirement for a stable internet connection is not peculiar to game streaming services. All games offering multi-player cross-platform play require a stable internet connection, even when played as a native app. Latency is therefore an issue with online multiplayer games on native apps, as it is for cloud gaming. So, a game of Battle Royale in Fortnite is processed on a remote Epic server, which processes all of the input and output data of the various participants, including those playing a native app on a mobile, PC, tablet or console. Up to 100 players play in the same game and the device on which each of them is playing has to communicate with an Epic server via the internet.

2950    Let me say something about the concepts of ping and jitter.

2951    The ping number is the time, measured in milliseconds, that it takes data to get from the user’s device to the relevant server and back to the user’s device. Ping is affected by how far the user is from the server. It is not the case that a user with a lower ping will always have a better experience than a user with a higher ping, because there is a level below which the difference will not be perceptible to the user.

2952    A consistent internet connection results in less variability of the ping, called jitter. Jitter can be present on all types of internet connection, but there is a threshold below which the jitter will not impact the user’s experience.

2953    Now the speed and consistency of an internet connection depend on how many people are using the same connection and what they are doing on it. So, streaming videos or downloading files on a household connection could slow it down and affect the Fortnite experience for someone playing on the same connection.

2954    Delay in the internet connection can manifest as lagging, where there is a slight delay in processing the game. By default, players are put into games with others in the same region unless they select a different region. The server is agnostic about the type of device that the player is using.

2955    Apple says that Fortnite users playing on different devices and with internet connections of different quality can still play together in the same game, including users playing via a game streaming service. Epic does not make any adjustment for the fact that players are using a streaming service when matching players into a game.

2956    Epic’s website includes information about the system requirements for playing Battle Royale. It also includes tips for players that only just meet the system requirements, for example, players can adjust their graphics setting.

2957    The quality of the Fortnite experience can also depend on the type of device that the user is playing on, including the display and input hardware. A higher end device will typically process data faster than a lower end device. The graphics performance of the device will also create some variability in how each participant experiences the game.

2958    It is convenient at this point to say something about Google’s case.

Game streaming services – Google’s arguments

2959    Google says that cloud streaming services provide a significant competitive constraint on the services by the Play Store for three reasons. First, cloud streamed apps are capable of being delivered to the user via their web browser, thereby bypassing native apps entirely. Second, cloud streaming is for the average Australian Android device user a genuine functional substitute, including for AAA gaming apps such as Fortnite. Third, many developers particularly of gaming apps have taken up cloud streaming services as a means of distributing their apps on mobile, at least in part because it means that they do not need to create a platform specific version.

2960    Google has made the following points. Google says that gaming via cloud streaming is attractive to users because it allows for multi-platform play, that is, simultaneously across multiple devices, mobile and non-mobile. Further, Google says that depending on the cloud streaming service provider and device to which it can stream, cloud gaming enables uses to do the following.

2961    First, they can play games on a device of their choosing, such as their mobile device when they are away from their console or PC or because, as is the case for a not insignificant number of users, they prefer to “play on glass”.

2962    Second, they can play games that are not otherwise available on a particular device, such as games developed for a particular console that have been made available on mobile devices through cloud gaming.

2963    Third, they can play games on powerful servers that generally run games on market leading graphics cards and enable users to play games at much higher quality and frame rates than they would experience on a mobile device, console or most PCs.

2964    Fourth, they can play games without re-purchasing the game where they already own it on a particular device, such as on their PC where they already own the Xbox version of the game.

2965    Fifth, they can play games on-demand, without waiting potentially lengthy periods for the game to download, install and update. This can be an added benefit for users whose device does not have the significant storage capacity required for some modern games.

2966    Sixth, they can play games from genres previously not well represented on mobile devices, such as massive multiplayer online games which allow a large number of players to simultaneously inhabit a virtual world and which traditionally required expensive hardware to run with high quality display settings.

2967    Let me say something about Google’s case concerning the functional substitutability between native apps and cloud streamed apps.

2968    Google says that it is not the case that a person using a native app will always have a better experience than a user using a streaming service.

2969    The amount of data consumed while streaming a game will vary depending on multiple factors including the resolution quality of the stream and the length of the session. Indeed, Mr Grant admitted that his own preferred method of playing Fortnite is by cloud streaming it to his iPad using a web app, rather than using his PlayStation 5.

2970    Further, if a user has a reliable internet connection most of the time, gaming streaming can work well. There has been an improvement in internet services and networks.

2971    Further, whilst Professor Somayaji suggested in his first report that performance differences between native apps and cloud gaming apps are significant, and highlighted the minimum recommended network requirements for native gaming apps and cloud gaming apps, he did accept the following.

2972    First, he accepted that the bandwidth, latency and data cap figures that he cited were not fixed for every gaming app but are a range, and vary depending on the precise app that one is using. There were not necessarily minimums.

2973    Second, regarding recommended bandwidth for native apps, which was said to be 4 Mbps, he accepted that the figures on which he relied were imprecise and to some extent unclear concerning the precise type of game to which the figures related.

2974    Third, regarding recommended bandwidth for cloud gaming, which was said to be 25 Mbps, he was shown a contemporaneous document being from Microsoft Xbox Cloud Gaming’s website which confirmed that the best performance would be achieved at rates of 10 Mbps on mobile devices. He acknowledged that the requirements for cloud gaming are reducing as a result of various improvements such as decompression, and providers having more and better hardware. He said that his position on cloud gaming is not that it cannot work well, but rather that it is different in the sense that it relies on the relevant network.

2975    Fourth, he confirmed that the hardware enabling cloud gaming technology is improving, which in turn makes providers better at compression, thereby lowering the amount of network capacity required to stream content to a user’s device. In other words, improvements in technology are lowering the bandwidth requirements.

2976    Fifth, regarding latency or ping, he acknowledged that he relied on an academic article from 2016 to establish that cloud gaming requires latency of less than 20ms. There were various contemporaneous documents from the websites of cloud and remote streaming providers that contradicted that claim. The NVIDIA GeForce Now website notes that for the “best experience”, a latency of under 40ms is recommended. The Microsoft Xbox Remote Play website notes that a latency of under 150ms is required but a latency of under 60ms “is optimal”.

2977    Sixth, regarding latency, he explained how game developers have figured out how to “mask” latency by having the game predict what the user is doing. He accepted that this was a technological advance.

2978    Seventh, he was taken to evidence of median mobile internet speeds and median latency in Australia, being respectively 91.29 Mbps and 21ms. When asked whether such a median download speed would be adequate to play a game via cloud streaming, he agreed that this would fit the recommendations. When asked the same question with respect to latency, he gave the same answer.

2979    Eighth, regarding data caps, he was taken to the document that he relied on in support of the figure of 20 GB per hour, being a document for the now defunct Google Stadia. He agreed that that figure was for a particular resolution, and that for lower resolutions the data usage would typically be under 12.6 GB per hour. He accepted that other cloud streaming providers that have outlasted Google Stadia could use different compression approaches that might result in less data being used.

2980    Ninth, as to data caps, he was also taken to a WhistleOut magazine article which contained the results of testing of Microsoft xCloud Xbox, being the original name for Xbox Cloud Gaming. It revealed that it would use about 3 GB per hour no matter the title played. He accepted that he had no reason to think that other cloud game streaming services might not also use 3 GB per hour although he added that that was “a lot” of data.

2981    But Google had to concede that cloud streaming and cloud gaming are not functionally equivalent to native apps.

2982    Let me set out Google’s position concerning the extent to which cloud streaming services are used by app developers. Google says that cloud streaming has assumed particular significance in recent years. Mr Sweeney described it as the key to ending the “iOS payment monopoly”.

2983    Mr Rawles, the managing director of Global Games and Play Partnerships at Google, explained that cloud streaming enables game developers to do the following.

2984    First, they can expand the platforms on which their game is available, including those that their game has not otherwise been developed to support. So, a game that has only been developed for PCs can become available on consoles, mobile devices and smart TVs.

2985    Second, they can reach and monetise their games across a wider audience of users, including those that do not own a gaming console or PC or prefer to play games on a different platform, such as a mobile screen.

2986    Third, they can focus their capital, resources, and investments on creating high-quality user experiences rather than creating platform specific versions of a game.

2987    Fourth, they can enable users to engage in de facto cross-play with their friends on a different platform where they do not own that platform or a version of the game compatible with that platform.

2988    In essence, Google says that cloud streaming has the effect of expanding the universe of platforms on which developers can distribute their games. The cost for game developers to switch from native app distribution to cloud streaming is likely to be low. Now whilst a developer would need to come to a commercial agreement with one of the cloud streaming providers, that would not be a problematic exercise for most developers and in any case would be significantly less burdensome on the developer compared to building a separate version of their game for, say, a mobile device

2989    Further, Epic was an early adopter of cloud streaming services. Fortnite was the first free-to-play game made available via Xbox Cloud Gaming.

2990    One particularly attractive aspect of cloud streaming to Epic was that there was no need for Epic to pay any service fees to Google or Apple on in app purchases.

2991    In September 2021, Mr Sweeney described Fortnite being available on Xbox Cloud Gaming as “[o]ne MASSIVE opportunity …. I think this will expand the audience like 5x compared to expecting people to buy a peripheral from the store”. In other words, Epic considered that launching Fortnite on Xbox Cloud Gaming was a sizeable opportunity. It would be five times more popular or the potential audience of Fortnite players on Xbox Cloud Gaming would increase by five times if Fortnite was released on that service. With Xbox Cloud Gaming, players do not need to buy an external game controller to play Fortnite. They can play on an iOS or Android device.

2992    In internal presentations following the implementation of the hotfix, Epic described its mobile strategy as “[r]e-launch Fortnite on Android Globally […] Using hybrid sideload + cloud streaming flow to drive Fortnite Growth.”

2993    On 6 May 2022, Fortnite launched as a beta on Xbox Cloud Gaming. Mr Grant sent an internal email stating:

…

Tomorrow at 12pm EST we’ll announce that Fortnite is available to play, for free, via Xbox Cloud Gaming Beta on iOS, iPad, Android, Windows, and Mac.

….

That means regardless of hardware, players in 70% of our markets will have the option of playing Fortnite at 60Hz with Xbox Series S level graphics for free with no need to install or patch the game!

….

We are now at the point where anything with a web browser can run Fortnite :)

…

2994    The reference to “70% of our markets” was a reference to 70% of the markets where Fortnite was available, including Australia.

2995    As at the present, Xbox Cloud Gaming has Fortnite available without a subscription, and Epic pays no commission on in-app purchases to Apple or Google. Further, GeForce Now and Luna allow for Fortnite to be played on an Android device. Further, the percentage of the Fortnite user base using Android is roughly equivalent to the percentage that is playing it by means of cloud streaming.

2996    Let me deal with some other points made by Google.

2997    Google says that it is possible for Android mobile device users to sideload or direct download a cloud streaming provider’s native portal app and cloud stream an app that way. And it is possible to download a cloud streaming provider’s native portal app from a pre-installed app store other than the Play Store, such as the Samsung Galaxy Store.

2998    Further, Google says that cloud streaming of games on an Android mobile device generally works for the average Australian having regard to improvements in, first, internet connectivity, and second, the cloud streaming technology.

2999    Further, Google noted that Professor Goldfarb said that cloud streaming services are not substitutable for native apps, with this being based on finding that few users adopted cloud streaming services to play Fortnite on Android devices relative to the number of users playing Fortnite on mobile as a native app prior to the removal of Fortnite from the Play Store.

3000    But Google said that as Professor Asker observed, Professor Goldfarb’s evidence showed that for high-end performance games, cloud streaming is a viable substitute, given that in May 2022 there were four times as many Fortnite mobile users accessing Fortnite via cloud streaming than via a native app.

3001    Further, Google said that cloud streaming via mobile devices is increasing in popularity in Australia. The number of monthly installations of cloud streaming apps via the Play Store increased from 9,690 installations in January 2020 to 11,305 installations in November 2023, being a 17% growth over a three-year period. Total installations over this period were over 500,000 and specifically over 200,000 for the most popular cloud streaming service, Xbox Game Pass, with there being approximately 11 million active Android smartphones in Australia in a given month during this period.

3002    Now these arguments are all very well, but they go nowhere close to establishing close competition, close constraint or substitution. Moreover, much of Google’s case on this aspect seemed to be or resonate with little more than a marketing pitch. Let me elaborate.

Analysis – streaming apps

3003    Now as Epic points out, streaming apps run entirely on a remote server, unlike native apps which run on a user’s mobile device. Users control streaming apps by making inputs in a “portal app” on their mobile device, which continuously streams those inputs to the server, and receives a stream of data back from the server. The portal app can either be a web app or a native app.

3004    Now as Professor Somayaji explained in his evidence, some of which I have set out elsewhere, the portal app on the user’s phone sends inputs from the user’s device through the network to the remote server which is running the app. The remote app then renders an output frame based on the result of the input. The output frame is then streamed back to the user’s device in real time. This loop creates the illusion that the user is interacting with an app on their device rather than an app on a server somewhere far away.

3005    I agree with Epic that streaming services offered via a native portal app cannot be a substitute for app distribution via an app store, because the native portal app itself needs to be distributed.

3006    To the extent that the native portal app is distributed via an app store, as is necessarily the case on iOS devices, the streaming app cannot be a substitute for the distribution services provided by that app store, as the app store’s distribution services are still utilised and the app store’s rules must be observed.

3007    To the extent that the native portal app is distributed via direct downloading, as may occur on Android devices, but not iOS devices, that process confronts all of the challenges associated with direct downloading. The distribution of native streaming apps via direct downloading is also not a substitute for distribution via app stores.

3008    Further, whilst theoretically a native portal app could be distributed via pre-installation on Android devices, but not iOS devices, that distribution route is not a substitute for distribution via app stores.

3009    Accordingly, and as Epic correctly identifies, the only relevant question for consideration is whether streaming apps that stream to web portal apps are substitutes for native apps on iOS and Android devices, such that developers or users may forgo iOS and Android distribution services in favour of streaming via those web portal apps.

3010    Streaming apps that stream to web portal apps are not a close substitute for native apps on iOS and Android devices and therefore not a means of avoiding iOS and Android app distribution services. There are limitations associated with streaming that are common to both native and web apps, as well as limitations that are unique to web apps.

3011    In summary, streaming apps are not close substitutes for native apps as Epic correctly points out. First, for the vast majority of users, streaming apps suffer from a number of limitations compared with native apps. Second, the low user uptake of streaming apps despite significant investment by developers is consistent with streaming apps not being substitutes for native apps. Third, streaming apps are only an option for certain kinds of apps like high performance gaming apps or video streaming apps.

3012    Streaming apps suffer from a number of limitations. Streaming app are highly dependent on the quality of users’ internet connection as they need high bandwidth to relay inputs and stream high-definition outputs, and low network latency or ping time. Further, streaming apps consume a large amount of data for each hour of use. Further, streaming apps require significant server and hardware investments by developers. Further, streaming apps require users to carry out several steps, which produces additional friction to access. Further, streaming apps are not able to facilitate features that use on-device hardware. Further, streaming apps suffer from the additional limitations of web apps.

3013    Further, streaming apps are only an option for certain developers who offer high performance gaming apps or video streaming apps.

3014    Further, as Professor Somayaji explained in his evidence, streaming apps provide a materially inferior experience to native apps for the vast majority of mobile device users. I will elaborate on some of this in a moment. I have also set out his evidence in detail elsewhere.

3015    Now Apple relies on general assertions made by Mr Schiller and Mr Federighi to the effect that users can stream games on iOS devices, that game streaming is like a PC gaming experience and that it is also possible to make in-app purchases whilst game streaming on iOS. But as Epic points out, Apple’s evidence only points to the mere existence of streaming apps on iOS devices. This is not sufficient to establish that they are close substitutes for native apps.

3016    Further, Google’s lay evidence was essentially limited to generalised statements about game streaming apps that do not account for the specific issues that users of game streaming apps confront on mobile devices, as distinct from PCs and consoles.

3017    I agree with Epic that evidence regarding the game streaming experience on PCs and consoles cannot be extrapolated to game streaming experiences on mobile devices via a web portal app. Accordingly, Google’s evidence is of limited assistance. I am concerned with the prospect of users switching away from native apps on mobile devices to streaming apps on mobile devices.

3018    For these reasons, streaming apps that stream to web portal apps are not close substitutes for native apps on mobile devices, for either developers or users.

3019    Consequently, the prospect of developers and users switching to using streaming apps does not closely constrain Apple in its supply of iOS app distribution services or Google in its supply of Android app distribution services, or any hypothetical monopolist of these services.

3020    Let me address the quality of the internet connection required.

3021    When using game streaming apps, mobile device users are required to have a significantly better internet connection compared with native apps. This is not limited only to internet speed.

3022    Many of the processes that occur on a user’s device when using a native app occur on a remote server when using a streaming app. Each input a user makes in the portal app must be streamed to the remote server where it is processed, and an output frame rendered, which is then streamed back to the portal app on the user’s device.

3023    Specifically, the internet connection required to ensure a smooth and responsive streaming experience involves higher bandwidths, being the amount of data that is transmitted per time interval, and lower latency or ping.

3024    In respect of latency or ping, low latency is critical with streaming apps because a smooth user experience is reliant on there being minimal delay between when a user presses an input button and when the user sees the app respond to that input. The related concept of “jitter” refers to the rate at which ping changes over time.

3025    Both ping and jitter can be highly disruptive to the user’s experience if the lag time a user experiences between their input and the corresponding change in the app is too long. As Professor Somayaji explained, streaming apps require ping times of less than 20 milliseconds to be able to provide a comparable experience to native apps, for which a ping time of less than 80 milliseconds is sufficient. I prefer this evidence over cloud gaming companies’ self-serving marketing statements that suggest that a higher latency internet connection can achieve an acceptable user experience.

3026    In respect of bandwidth, streaming apps require at least 25Mbps of bandwidth to provide a sufficiently high framerate for it to feel comparable to a native app, whereas native game apps can generally run smoothly at a bandwidth of 4Mbps.

3027    Now although Australia may have a median mobile download speed of 91.29Mbps and a median latency of 21 milliseconds, Professor Somayaji pointed out that median data is not informative of actual user experience as internet speeds will vary from time to time.

3028    Professor Somayaji gave evidence that running streaming apps is feasible in some but not all contexts. He identified that running streaming apps would not be feasible when a user’s mobile device is connected to a cellular network, which can face dips in connectivity, for example, when the user is in transit. Further, mobile devices connected to cellular networks consistently fail to achieve the requisite internet connection for streaming apps. In practice, network connections are not consistently strong for mobile devices simply due to variations in signal strength due to geographic features (trees, buildings, bridges, etc.).

3029    Mr Grant gave evidence that native apps, unlike streaming services, can reduce the impact of high ping or an unstable network connection on a player’s performance by implementing a technique known as client-side prediction, which predicts actions that will occur or the actions that will result from the player’s input. But that technique cannot be used within streaming apps because the image the user sees is created on the remote server and not their device, which will also be affected by high ping because it must be streamed from the remote server to the portal app.

3030    In cross-examination, Mr Sweeney emphasised the importance of an adequate internet connection when gaming via streaming services. Mr Sweeney said that Fortnite game play can accommodate relatively poor internet connections when they are run as a native app, but not as a streaming app.

3031    Further, Mr Rawles acknowledged the importance of a sufficient internet connection to a user’s experience of streaming. He said that by its nature, cloud gaming is highly dependent on the quality of the internet connection between the user’s device and the streaming infrastructure. His evidence was that there will always be a degree of latency or lag between a user’s input, the server receiving that input, and the video feed that is returned to the user.

3032    But Mr Rawles sought to downplay the impact of latency on the streaming experience, with a series of statements unsupported by documents or analysis.

3033    He said that latency also exists in native games that have online multiplayer functionality due to the need to connect to a server. But whilst it is true that native apps with online multiplayer functionality must communicate with remote servers, they do not do so to the same extent as streaming apps. This is because native apps process user inputs on the device. Contrastingly, in the case of streaming apps, every user input is sent directly to the server and this makes every user action subject to network delays.

3034    Further, he said that streaming apps typically only require a stable internet connection at a reasonable speed. But in so stating, Mr Rawles acknowledged the importance of a stable internet connection, which is challenging to maintain on mobile devices connected to cellular networks and particularly when the user is not stationary, that is, they are in transit.

3035    Further, he said that unless a user is cloud gaming on a poor internet connection or playing a game at a competitive level, experiencing a small amount of latency from a remote server is unlikely to have a material impact on their gaming experience. But Professor Somayaji’s evidence was that streaming apps require latency levels approximately four times lower than native apps, and that these levels are challenging to achieve for users of mobile devices.

3036    I prefer the evidence of Professor Somayaji and Mr Grant to the evidence of Mr Rawles. This is particularly so given that Mr Rawles did not have commercial responsibilities that would be expected to give him a strong basis to express opinions on the technical limitations of streaming apps.

3037    So, the use of streaming apps relies on user access to a fast and reliable internet connection, with low latency, that is out of reach for many users, and particularly users of mobile devices. It is unsurprising therefore that streaming apps have failed to gain popularity among mobile users.

3038    Let me now say something about the question of data consumption.

3039    I agree with Epic that it is not viable for most users to use streaming apps on mobile devices over cellular networks because they consume too much data. It does not seem to be contentious that streaming apps consume significantly higher quantities of data than native apps because all user inputs must be streamed from the device to the server and rendered video output must be streamed from the server back to the device. Professor Somayaji estimated that using a high quality online game as a native app consumes roughly 300 megabytes per hour. A comparable experience of the game using a streaming app will consume roughly 20 gigabytes per hour.

3040    Mr Grant and Professor Somayaji gave evidence that such high levels of data consumption present a particularly acute problem for mobile device users.

3041    Mr Grant’s evidence was that because streaming is dependent on the internet, it uses more data than running a local app. For example, streaming Fortnite through NVIDIA GeForce Now or xCloud requires, depending on connection and quality settings, around two to eight GB of data per hour of playtime, while using the native Fortnite mobile app requires around 50 to 100 MB per hour. This is a particularly significant issue for mobile device gamers. Mobile plans often have limited data allowances which would be insufficient for users wishing to play apps like Fortnite through a streaming service.

3042    Professor Somayaji gave evidence to contextualise the impact of high data consumption arising from streaming app usage on users. He said that if an average user in Australia were to use streaming apps, they would consume an entire month’s data usage in approximately a day.

3043    Mr Rawles also acknowledged that per session, streaming a game uses more data than would be used playing a game installed on a device. Mr Rawles also stated that using streaming apps is unlikely to entail a user purchasing a particularly expensive mobile plan unless they are regularly playing streamed games from outside of an established Wi-Fi connection, that is, using their cellular data.

3044    But the qualification is important in the context of mobile devices. In other words, a user is likely to need to purchase a more expensive mobile plan if they are regularly playing streamed games using a cellular data connection. Being able to regularly use apps outside of an established Wi-Fi connection is an important reason why users use mobile devices.

3045    Moreover, Mr Rawles acknowledged that he had no personal knowledge concerning the cost of mobile plans, data usage costs, NBN internet costs or the internet speeds accessible by a mobile device in Australia.

3046    For these reasons, I give little weight to Mr Rawles’ evidence that mobile device users are unlikely to need to purchase an expensive mobile plan to stream apps on their mobile devices.

3047    Mr Rawles’ claims are predicated on a narrow set of circumstances which do not accord with how users use their mobile devices in practice and are not informed by any knowledge of the relative costs to users of consuming more data by using streaming apps over cellular networks or fixed Wi-Fi connections.

3048    Mr Rawles also sought to downplay the limitations associated with streaming apps by claiming that they save a user from originally downloading the full game to their device. He also said that overall data demands depend on the video quality, length of gameplay session(s), and the complexity of the game being streamed, that is, whether it is a graphics-intensive multiplayer game or a casual 2D, single player puzzle game.

3049    This comparison does not assist. The correct question is whether a user is likely to switch from a native app experience to a streamed app experience of the same app. Because streaming apps must process user inputs remotely, a streaming app will necessarily consume more data than its native app counterpart.

3050    Let me turn to the question of cost and availability.

3051    As Epic points out, streaming apps are far more expensive to run than native apps, which has led streaming app providers to impose fees and access limits on users. Again, this matter undermines any suggestion that streaming apps are close substitutes for native apps.

3052    Professor Somayaji gave evidence about the additional infrastructure and processing power required to run streaming apps compared with native apps.

3053    He said that unlike native apps, which are built for and run on specific platforms, streaming apps are hosted on and streamed from a web server to the user’s device. This requires additional processing power and server infrastructure to run the games, such as content delivery networks, as well as additional resources such as multiple GPUs.

3054    Whereas native apps use the processing functions of the hardware on the user’s device, providers of streaming app services must purchase, maintain and operate sufficient hardware components for all of its users. This includes central processing units, graphics processing units, RAM and hard disk or solid state drive storage.

3055    These aspects of the streaming app model have two significant implications for users.

3056    Streaming app providers typically pass on some of their costs to users. This means that anyone who wishes to switch from a native app to a streaming app is likely to incur an additional cost.

3057    Indeed, Mr Rawles gave evidence that all of the cloud gaming services of which he was aware charge users a subscription fee, except where a free trial or free tier is offered, that is likely to cover at least part of the costs of running the infrastructure necessary for cloud gaming.

3058    Further, it is difficult for streaming app providers to add more hardware and server space to meet short term increases in demand for their service. The result is that users often have to queue to wait for server space to become available for them. Mr Grant gave evidence that, for users on free tiers of these services “you can find yourself waiting literally hours at times – I have experienced that myself – before you’re able to play”. Some providers also manage this problem by imposing limits on the amount of time that a user can use the app.

3059    This means that users considering switching from a native app to a streaming app must typically incur additional costs. Even when a user incurs those additional costs, they are not guaranteed immediate access to the app. They are only guaranteed a higher priority in a queue than other users, but may still need to queue depending on demand from other users, or their use of the app is limited to a specific amount of time because of server space limitations.

3060    These inherent limitations impose further, significant barriers to users, and in particular, mobile device users, switching from native apps to streaming apps.

3061    Let me now deal with the question of friction.

3062    Users must generally take additional steps to access a streaming app. Professor Goldfarb’s review of the academic literature and empirical analyses indicate that these additional steps deter use.

3063    Mr Grant described some of the additional frictions encountered by users when using streaming apps as compared to native apps. He gave evidence that such additional frictions lead users to prefer native apps over streaming services.

3064    He said that for users to play a game through a streaming service, they must first create an account associated with that service, as well as any accounts needed for the game itself. For example, for users to play Fortnite through NVIDIA GeForce Now or xCloud, they must first create an account with NVIDIA GeForce Now or Microsoft respectively, and then log into and link this account with their Epic account. By contrast, to play Fortnite as a native app, users only needed to log in with an Epic account. Purchasing V-Bucks is also less straightforward through a streaming service, as mobile features such as “autocomplete” and “password manager” are not available. Based on his industry experience and observations over time, he expects that this additional friction will result in users maintaining a preference for playing games through native apps directly as opposed to using streaming services, because it allows them to begin playing more quickly and conveniently.

3065    Mr Rawles also acknowledged that users would have to create an account for the cloud gaming service and connect that account to any game library or game subscription service from which they wish to play games, unless the cloud gaming service and game streaming service are already integrated, such as xCloud being included for certain Xbox Game Pass subscribers.

3066    Now Mr Rawles sought to downplay the effects of this friction by claiming that most users are unlikely to be materially derailed by an account sign-up screen or having to remember or write down their password when they would have already had to sign up to a game subscription service or app store to purchase the game they wish to play. He suggested that this may be particularly so for those wishing to play a game remotely or a complex game. But I agree with Epic that his position is contradicted, first, by empirical evidence in the form of user studies that find friction deters users and, second, by evidence of developers and software engineers. I would give Mr Rawles’ assertions little weight.

3067    I prefer Professor Goldfarb’s empirical evidence illustrating a low uptake of Fortnite on web streaming apps, which is consistent with the “clicks are costly” concept.

3068    Let me now address the aspect of reduced features on mobile devices.

3069    The users experience of streaming apps on mobile devices is inferior to the user experience of native apps because streaming apps are unable to offer certain features that utilise on-device hardware.

3070    For example, Epic implemented certain features in the native app version of Fortnite which improved the user experience, particularly on mobile devices, but which were not available via Fortnite as a streamed app. Those features included gyroscopic controls, which allow users to control where they are aiming within a game app by tilting their device or controller, and vibration feedback, which causes the users’ device or controller to provide feedback when they take certain actions, such as firing a weapon.

3071    Mr Sweeney gave evidence that this is a limitation of streaming apps. Mr Grant also gave evidence that the use of gyroscopic controls creates a more intuitive and immersive experience, and allows those playing on a mobile device to limit their reliance on touch screen controls, whilst the absence of vibration feedback makes the experience less attractive than playing the game via a native app.

3072    Let me say something about accessing streaming services via web portal apps.

3073    As Epic points out, streaming apps which stream to web portal apps face limitations over and above those faced by streaming apps which stream to native portal apps. This is because, in addition to the limitations described above, which are common to both streaming apps that stream to web portal apps and those that stream to native portal apps, web app limitations also apply to web portal apps.

3074    Professor Somayaji gave evidence that whilst a web app can serve as a portal to streaming apps, generally a user will have a higher quality experience through a native portal app. This is because where streaming apps run inside web browsers, their control over network communications is dependent on the web browsers and is more limited than that afforded by native portal apps. In other words, web portal apps share the technical limitations of web browsers which are largely optimised for “bursty communication patterns”.

3075    In a video streaming context, a browser may receive 10 seconds of video in one second so that it can tolerate a nine second delay in receiving the next batch of data. This design may be acceptable for certain audio and video streaming apps but not game streaming apps as it is essential for users to see the results of their actions immediately rather than seconds later.

3076    Contrastingly, native portal apps have the requisite control over network communications such that they are more suited to delivering a smooth and responsive game streaming experience provided that the user has an adequate internet connection.

3077    A further issue with web portal apps on iOS is that Apple restricts the ability of web apps to access key hardware features, and in doing so, impedes their functionality. As Professor Somayaji explained, traditional web apps that run on-device are restricted in terms of features since they run within the limitations of the browser. Features Apple restricts for web apps include the ability to use Bluetooth, and the ability to update in the background when the user does not have them open.

3078    Until recently, Apple imposed restrictions which made it challenging for streaming apps on iOS to use native portal apps. Those restrictions required providers of streaming services like NVIDIA and Microsoft either to distribute their portal apps as web apps or to distribute individual native apps to the App Store for each experience available via their portal app.

3079    Professor Somayaji gave evidence that this requirement was inconsistent with the model of game streaming services and increased the costs involved in delivering such a service.

3080    He said that whilst Apple’s policies permit streaming apps on the App Store in theory, an app which offers access to a catalogue of other apps through a single app is not permitted on the App Store. This conflicts with the model that cloud gaming apps use on other platforms. Cloud gaming apps traditionally use a single connection app to allow users to access their remote server, on which users can access a multitude of games.

3081    He said that in effect, for streaming apps to be allowed on iOS, each game title offered on the streaming platform would have to be individually submitted to the App Store as a separate app. This requirement imposes additional costs on streaming service providers, requiring that they develop quality control, and maintain a number of different apps which all provide the same basic service, being connecting to the cloud computer and streaming game output.

3082    Mr Grant gave evidence that Apple’s policies effectively prevented game streaming services from offering a native iOS app, with the result that they operate on iOS devices exclusively as web apps. This has meant that game streaming services on iOS offer an inferior user experience compared to game streaming services accessed through a native app.

3083    Accordingly, until recently, it was not feasible for streaming service providers to provide game streaming services via native portal apps.

3084    Apple recently revised its rules, and now no longer requires each title or game offered by a streaming service through the App Store to have its own native portal apps, provided each title or game to which streaming apps provide access adheres to the App Store review guidelines.

3085    That Apple now allows native portal apps on the App Store, which provide access to multiple titles or games by a streaming service, reveals the arbitrariness of its original position.

3086    In 2020, Apple reacted to the advent of streaming services by imposing requirements with which it knew streaming services would be unable to comply. At that time, Mr Schiller proposed in an email dated 8 August 2020 amendments to the App Store review guidelines, including to incorporate a requirement that each experience accessible via a streaming service’s portal app must be submitted to the App Store as an individual app. This was all unrealistic as Mr Schiller well knew, yet Apple implemented them.

3087    Finally, user adoption of streaming apps is low. Clearly users do not consider streaming apps to be close substitutes for native apps.

3088    Epic and its streaming services partners have not been able to overcome low user uptake. Epic, and Fortnite users, have strong incentives to make streaming work, given that Fortnite is otherwise unavailable on iOS devices.

3089    Following the removal of the Fortnite native apps from the App Store and the Play Store in August 2020, Professor Goldfarb’s analysis demonstrated that few users of mobile devices accessed Fortnite on mobile devices via a web streaming app. Even when the app in question can only be accessed via a streaming app, that is, on iOS devices, the take up is much lower relative to the native app.

3090    In his evidence in the Google proceeding, Professor Goldfarb considered Fortnite usage through web streaming apps on mobile devices and found that there was a low uptake following the introduction of streaming services in May 2022. In particular, the following may be noted.

3091    For Android mobile devices, Fortnite could be streamed via NVIDIA GeForce Now over a native app or via web streaming, and via the Xbox Cloud Gaming web streaming service. As the data did not distinguish between the NVIDIA native app and web streaming versions, Professor Goldfarb conservatively included all NVIDIA use, that is, some of the users attributed to web streaming would instead have used the native app version.

3092    For iOS devices, NVIDIA GeForce Now and Xbox Cloud Gaming were available as web streaming services. Unlike Android, no native app streaming options were available.

3093    As Epic points out, Professor Goldfarb analysed Fortnite monthly active user data, which measured the number of users who logged on to the app at least once in a given month, in Australia over two time periods.

3094    First, prior to the removal of Fortnite from the App Store and the Play Store in August 2020, the number of monthly active users on mobile devices was approximately 330,000 to 450,000 in May 2018, May 2019 and May 2020.

3095    Second, in May 2022, with Fortnite available through web streaming, the number of monthly active users increased to 60,283, but was still well below its pre-removal levels of mobile users.

3096    Professor Goldfarb said that there were vastly more players of Fortnite on mobile devices through native apps pre-removal, that is, in 2018 through 2020, than there have been since the web streaming apps became available. He found that the number of active users on mobile devices following Fortnite becoming available through streaming was around 13% of the mobile user base from before Fortnite was removed from the Play Store and App Store. This number falls to around 7% if one excludes those users who continued accessing Fortnite on a mobile device through a native Fortnite app.

3097    On this basis, Professor Goldfarb concluded that these factors and the limited evidence of use of Fortnite on web streaming apps on smart mobile devices compared to native apps on smart mobile devices prior to removal indicates that smart mobile device users, whether Android or iOS, do not treat these two mediums as the same and do not treat either as substitutes, except to a limited extent.

3098    In his evidence in the Apple proceeding, Professor Goldfarb also considered the uptake of web streaming apps by users of iOS devices specifically. Professor Goldfarb similarly concluded that the limited evidence of use of Fortnite on web streaming apps on iOS compared to native apps on iOS prior to removal indicates that iOS users do not treat these two mediums as the same and thus do not treat either as substitutes, except to a limited extent.

3099    The data did not permit Professor Goldfarb to consider only Android mobile devices users in his evidence in the Google proceeding.

3100    During his evidence, Professor Goldfarb accepted that his analysis of Fortnite play through web streaming was limited to the first few weeks in which Fortnite was available through that medium.

3101    Apple suggested that “[y]ou would, no doubt, have a higher percentage over a longer period of time”. Apple further suggested that the users who accessed Fortnite through web streaming during Professor Goldfarb’s short-term analysis demonstrate that game streaming apps are substitutable for native gaming apps, even for demanding AAA games like Fortnite. Professor Goldfarb rejected these propositions. So do I. There is no evidence to suggest that the usage of streaming versions of apps necessarily increases over time, and the suggestion that any limited uptake demonstrates substantial substitutability is not maintainable.

3102    There has been very low utilisation of Fortnite on streaming services. As Mr Grant said, only a very small proportion of the total Fortnite user-base play Fortnite via web streaming, notwithstanding that Epic worked hard with NVIDIA, Microsoft and Amazon over the past three or four years to support streaming services. The evidence before me was not limited to the first few weeks after which Fortnite was available on streaming services.

3103    I also give little weight to Mr Rawles’ assertion that cloud game streaming has emerged in recent years and is growing in popularity as a distribution method and his opinion that cloud gaming will continue to grow in popularity with users, developers and platforms. Further, Mr Rawles’ assertions are general and do not account for challenges particular to streaming apps on mobile devices. Further, Professor Goldfarb’s analysis of streaming data and the evidence of Mr Grant indicates a low uptake of Fortnite web streaming apps.

3104    Further, Mr Rawles asserted that Epic is an example of a developer who has reached numerous arrangements with cloud gaming providers to realise the benefits of cloud gaming. But the fact that Epic has reached agreements is of little relevance given the evidence that there has been no material uptake of those services.

3105    Epic has every incentive to ensure Fortnite succeeds as a streaming app on mobile devices. It is essentially the only way Epic can reach Fortnite users on iOS, and it is a means by which Epic can reach Fortnite users on Android, following the removal of its native Fortnite app from the App Store and Play Store.

3106    iOS users represent a distinct user base and so it is beneficial for Epic to reach those users. The same is true of Android device users, who are a distinct user.

3107    Consistently with this, Epic has made significant efforts to partner with providers of streaming services to bring Fortnite to their streaming services. But despite those efforts, low adoption by Fortnite users has persisted. That Epic, the developer of one of the world’s most popular games, has been unable to convince a significant portion of its users to access that game via web streaming apps demonstrates that users do not consider web streaming apps to be close substitutes for native apps.

3108    Mr Sweeney gave evidence that Epic has done its best to provide a good experience for users playing Fortnite via game streaming, that Epic has always supported NVIDIA’s efforts fully, and acknowledged that Epic actively promotes playing Fortnite on GeForce Now in Australia. Mr Sweeney gave similar evidence concerning Epic’s support for Microsoft’s xCloud streaming app.

3109    Indeed, in the case of Microsoft, Epic agreed to offer Fortnite through xCloud free of charge, so that users would not be faced with the additional costs typically required to access streaming services to play Fortnite. But even with this incentive, Epic recovered less than a tenth of its iOS pre-removal user numbers following the release of Fortnite on xCloud and GeForce Now.

3110    Mr Grant also gave evidence of Epic’s efforts to support NVIDIA and Microsoft. He said that making Fortnite available via cloud streaming services involved conducting extensive negotiations with NVIDIA and Microsoft covering issues relating to account requirements, subscription models, revenue sharing arrangements and the optimisation of Fortnite via cloud streaming and also involved addressing from an app development and technical engineering perspective, the complexities in achieving an enjoyable and functional Fortnite experience via cloud streaming. The game the user is playing is run on a remote server and delivered to the user’s device over the internet. In the case of xCloud, for example, the game is run natively on a remotely located Xbox, and the version of Fortnite being run on that Xbox is making use of Xbox-specific APIs.

3111    Now there are examples in Epic’s documents of positive statements made by Epic employees in anticipation of the launch of Fortnite on streaming services. But I agree with Epic that the context is all important. Clearly, Epic wanted to encourage the use of and to support streaming services. But that does not make them close substitutes.

3112    In summary, in my view web streaming apps are not close substitutes for the distribution of native apps on iOS or Android.

3113    Further, the prospect of developers and users switching to using web streaming apps does not closely constrain Apple in its supply of iOS app distribution services, or Google in its supply of Android app distribution services. And the availability of such a substitute for some contexts does not negate or impede either Apple’s or Google’s substantial degree of market power which I have discussed elsewhere.

Conduct of platforms in competing for developers and users

3114    Apple made various references to contexts and scenarios which it said demonstrated competitive behaviour in terms of platforms competing for developers and users. But none of this amounted to demonstrating close competition or close competitive constraints.

3115    Apple referred to the following matters which I largely accept save and except Apple’s ultimate conclusions therefrom.

3116    From the perspective of a platform operator, having a range of high-quality games and popular titles available is essential to attracting users that value the ability to play games on their device.

3117    Platforms to some extent engage in competition for the application of developer resources, which can include securing first release of games on a platform, as well as exclusive or non-exclusive availability of games. Platforms are continually trying to improve their features and services to attract game developers and users.

3118    Further, the evolution of cross-play, cross-progression and cross-wallet functionality suggests that platform operators to some extent see each other as competitors.

3119    Both Microsoft and Sony expressed concern that enabling these features would cause them to lose transactions to other platforms. And Nintendo’s resistance to facilitating cross-wallet functionality is a further demonstration of some substitutability. Epic had discussions with Nintendo specifically about cross-wallet functionality in Fortnite and Nintendo declined to adopt it. Nintendo requires that V-bucks purchased on Switch only work on Switch, and that V-bucks purchased off Switch do not work on Switch. Epic’s internal emails relating to these negotiations with Nintendo in 2018 referred to Nintendo having some valid concerns about cross-wallet functionality. Nintendo had a concern that facilitating V-bucks would enable users to use other platforms, rather than the Switch, to acquire V-bucks, to the commercial disadvantage of Nintendo.

3120    Let me set out some evidence of Mr Schiller which I have accepted.

3121    Mr Schiller said that the App Store to some extent competes in a market of platforms, which are available across multiple devices including tablets, smartphones, laptops, PCs, Macs, and game consoles.

3122    In 2008 Apple considered the different app commerce models used by Microsoft, Xbox, Nintendo, and PlayStation in an Apple in-app commerce presentation. Apple decided to allow in game commerce.

3123    Further, Apple came to fix the initial commission rate at the time of launching third party apps not by reference to expected costs in relation to the creation and development of the App Store, but by reference to Apple’s analysis of then publicly available information about other platforms’ commission rates for digital content.

3124    At that time there were multiple channels of distribution for software. The biggest channel was still CDs sold through stores, and Apple was knowledgeable about that channel of distribution because it was active in that channel.

3125    Apple knew that such channels were charging effectively between 50% and 70%. Mr Schiller said that this was the biggest consideration for Apple.

3126    Apple also looked to emerging digital download activities, including the digital marketplaces Steam and Handango, each of which charged a 30% commission rate at that time.

3127    Apple also considered the phone carriers. The carriers wanted to be software distribution channels for handsets at the time, and Apple spoke to Verizon, AT&T and T-Mobile about their models. AT&T did not have a published rate, but developed a commission rate based on approaches from developers. That rate was typically over 50%.

3128    Further, Mr Schiller gave evidence of Apple’s approach to attracting developers and the network effects of a two-sided platform.

3129    The App Store helps developers from start to finish, by helping them to build, test, market, and distribute apps and grow their businesses. Apple provides developers with access to a secure and accessible marketplace which provides developers immediate access to consumers in 175 regions and in over 40 languages. Attracting developers to this platform involves the following services and functionality by Apple.

3130    First, Apple's dedicated SDKs and developer services feature more than 150,000 APIs. When Apple releases new technologies and functionality, developers get access to those features automatically. These tools are regularly updated with improved features to enable developers to build, debug and optimise native apps.

3131    Second, developers can provide app updates such as to add new functions or fix technical issues to app users for free, and app users are automatically notified when updates are available.

3132    Third, Apple verifies user accounts to check that potential customers of developers are real, helps to ensure that developers are paid, and helps ensure that developers’ intellectual property is protected.

3133    Fourth, the App Store has a global marketing team whose sole purpose is to drive discovery and engagement. Campaigns and programs are created to assist, inform, and inspire users while also helping developers drive downloads and re-downloads of their apps and games.

3134    Fifth, Apple provides marketing, editorial and promotional support to attract new app users. It advises developers on how to improve their products and grow their business.

3135    Sixth, Apple provides tools and training to aspiring entrepreneurs, developers and designers.

3136    Seventh, Apple has around 5,000 employees in its AppleCare support team to respond to refund inquiries. Apple manages customer inquiries, support for billing issues, troubleshooting and refund requests.

3137    Further, there are benefits to members of the developer program such as access to training and development resources including videos, guides, source code and articles and developer forums, which enable communication with Apple engineers and other developers.

3138    Apple personnel and specialist support teams are made available to app developers to give advice on how they might improve their products or grow their businesses, to provide marketing, editorial, and promotional support to attract new users, and to assist developers to navigate foreign tax systems, calculate tax liabilities, and to collect and remit any sales taxes to the relevant tax authorities in those countries on their behalf.

3139    Developers can participate in the promotion of apps, developers and Apple at Apple’s worldwide development conference each year.

3140    Further, Apple’s continued innovations on hardware and software features such as biometric authentication tools, camera quality and graphics performance attract developers of apps.

3141    Further, Apple’s developer relations team based in Australia provides marketing and other support. The team regularly communicates with developers about new App Store features and opportunities to work with Apple to enhance developers’ apps and increase developers’ marketing exposure. The developer relations team also gives advice to developers on strategies to optimise user experience in their apps. Apple Pty Ltd provides guidance to Australian app developers to maximise consumer engagement, facilitate introductions with other countries, support use of the StoreKit API to facilitate monetising of apps, and assist with ongoing management.

3142    Developers are given access to tools and assistance to optimise their product page, for example by using engaging videos and images. There are many ways for developers to have their apps discovered and Apple Pty Ltd focuses on ensuring that developers utilise those channels and tools.

3143    Apple assists developers through the curation of the App Store. This involves the placement of apps and editorial content on the discovery page to assist marketing and build the profile of developers. At any given time, hundreds of apps are promoted on the App Store by Apple.

3144    Let me at this point say something about IAP.

3145    IAP gives developers efficient access to the iOS user base and effective tools for monetisation. Those tools allow for collecting and managing payment information from around one billion potential customers around the globe, handling conversions to 44 currencies and ensuring compliance with local tax laws. Apple assists developers to navigate foreign tax systems, and Apple calculates tax liabilities and collects and remit sales taxes to relevant tax authorities on their behalf. This facilitates transacting in the 175 countries in which the App Store operates.

3146    This is in a context where Apple facilitates for developers a variety of models for monetising their apps. Apple’s rules give developers the flexibility to choose how an app is monetised, including whether the selected monetisation model involves paying a commission to Apple. There are various options for developers to monetise their apps on the App Store. The models are often referred to as free, freemium, subscription, paid and paymium, which models I have discussed elsewhere.

3147    A substantial proportion of free to play games monetise through in-game advertisements alone or via hybrid monetisation, which comprises microtransactions, season-passes, in-game advertisements, rewarded ads and/or in-game branded promotions.

3148    Offering flexibility when it comes to monetisation is an aspect of attracting and retaining developers.

3149    Let me say something about the question of commission rates, although I have discussed this in detail elsewhere.

3150    In June 2016 Apple reduced its commission rate on subscriptions from 30% to 15% after the first year. Google considered reducing its service fee for subscriptions to match or be lower than Apple’s commission, and ultimately decided to match Apple’s commission 15 months after Apple’s announcement.

3151    Further, around seven months after Apple announced its small business program on 18 November 2020, Google reduced its commission for all developers on slightly better terms.

3152    Under Apple’s small business program, developers who earned up to one million in the preceding calendar year would pay a 15% commission. Contrastingly, Google’s reduced service fee of 15% has applied to the first million dollars in earnings for all developers.

3153    Further, there were examples of other responses and actions of platforms in the evidence, as was pointed out by Apple and Google.

3154    In 2018, in response to a loss of in-app purchase volumes by the Play Store to Amazon’s app store in Japan, Google launched the Google Play Points program in Japan. That program rewards users by giving them points when they engage with the Play Store. The points can be used to obtain in-app items or can be redeemed to support charitable causes.

3155    The Google Play Points program was introduced in South Korea in April 2019 in response to competition for high value users from Amazon’s app store and the Samsung Galaxy Store, as well as in response to Apple iOS making inroads into the millennial gamer segment.

3156    Further, the operators of Xbox, PlayStation and Steam use localised player engagement techniques to seek to encourage play to occur on their devices. A player’s achievements on Xbox include so-called bragging rights such as levels completed or the number of objects collected in a game. While the achievements are implemented by each game independently, a player’s total achievements are shown on the main Xbox dashboard and on their profile. Both PlayStation and Steam offer a similar functionality that developers can incorporate into games for use on those platforms. The achievements are contained within each platform’s ecosystem.

3157    Further, tools of this kind to promote user engagement are a matter of interest to developers in choosing how they operate on different platforms, and are also relevant to developers as techniques for driving transactions to more favourable platforms. One example concerned whether the psychological effects of the Xbox achievements system would lead more players into a scenario where Microsoft’s commission would be payable on purchases of V-bucks.

3158    Further, different platforms offer exclusive or discounted digital content to end users, including those who may have access to more than one platform where they can transact. Developers can choose to make games or content exclusive to particular platforms.

3159    Both the App Store and the Play Store market exclusive or discounted content to users via their Twitter accounts and in partnership with developers.

3160    Developers also market content available on their webstores, sometimes as a discount compared to the price that the same content would be available for in the relevant in-app store.

3161    The economic rationale of such promotions is to entice users to transact on one particular platform rather than another. In the case of platform operators, that is conducive to generating commissions. In the case of developers diverting business to direct supply websites, that is conducive to avoiding commissions and maximising revenue.

3162    Further, Epic has made deals with platform operators to provide exclusive Fortnite content for their platforms. So, the Fortnite Galaxy skin was an exclusive skin that was available only to people who owned a Samsung Galaxy Note 9 and accessed Fortnite through the Galaxy Store.

3163    In the iOS context, in exchange for enabling the gifting of digital content, Epic provided Apple with limited-time exclusive content for Fortnite on iOS, being the “Rogue Agent Pack”. In evidence was an App Store tweet promoting the Rogue Agent Pack as exclusive to the App Store.

3164    In an email chain dated 23 January 2020, an Epic employee, Mr David Shaw, sent Mr Weissinger some notes under the heading “Primary Business Engagements”. Under the sub-heading “Cross Play,” Mr Shaw’s notes included that “Microsoft is more lenient, but still has social and other requirements, e.g. … [e]xclusive skins must be timed exclusives”. Mr Weissinger’s evidence was that this reflected a requirement that, if there are exclusive skins associated with hardware bundles on any platform, they must be time limited exclusives so that others did not have any ongoing exclusivity.

3165    Mr Weissinger agreed that platforms engage in marketing activity to get as much usage of Fortnite as possible within their platform rather than on other platforms. He described that as seeking to “share shift” from other platforms.

3166    Further, Samsung wanted Fortnite to provide exclusive features or have updates released earlier on its Samsung devices than on other mobile devices, including iOS devices. This was intended to make Samsung more attractive relative to other Android and Apple smartphones. Epic agreed to a brief period of exclusivity of a day or two.

3167    Let me say something about the pricing commitments given by Epic to operators. Epic proceeded on the basis that it was obliged, informally or otherwise, to provide both Sony and Microsoft with V-Bucks at the lowest price. In the case of Sony there was a binding most favoured nation clause. And although Epic did not agree to a binding most favoured nation obligation with Microsoft, Mr Sweeney understood that Microsoft did not want to be undercut on pricing.

Cross-wallet functionality and other matters

3168    Some developers have invested substantial amounts of money to provide facilities for consumers to transfer their play, their progression, and their currencies across platforms. Developers like Epic have introduced features such as cross-wallet functionality, the point of which is to enable users to substitute purchases of identical virtual currency between platforms and to use that currency on any platform. I have mentioned this functionality earlier, but let me discuss it more here.

3169    The substantial investments of developers to enable such functionality are evidence of their views that users are inclined to substitute purchases of virtual currency between platforms. If developers believed that users only paid where they played, such investments would be wasted.

3170    Further, and relatedly, the resistance of the console platforms to the introduction of cross-progression and cross-wallet functionality evidences their views that they compete with other platforms, including mobile platforms such as the App Store, for app transactions.

3171    As to that, although Mr Sweeney first raised the cross-progression and cross-wallet functionality for Fortnite in January 2018, none of the console platforms agreed to it immediately.

3172    The first to agree was Microsoft (Xbox), which agreed to cross-progression, including cross-wallet, in March 2018. But that agreement was provisional and subject to a number of conditions. First, all purchases on Xbox had to be made through the Xbox store, that is, there was no linking out to alternative platforms. Second, Epic would offer marketplace item content parity across all ecosystems linked to Xbox. Third, Epic would not intentionally drive V-bucks and content purchases to one platform versus another.

3173    Whilst those conditions did not expressly refer to price parity, Mr Sweeney knew that Microsoft would be “up in arms about it" if Epic made V-bucks available on other platforms at lower prices than on Xbox. Indeed, Mr Sweeney ultimately accepted that Epic had proceeded at all times on the basis that it was obligated to provide both Microsoft and Sony with V-bucks at the lowest price received by any other platform or store and that that is because he understood that they were concerned users who would purchase their V-bucks on other platforms if they were available more cheaply there.

3174    Reinforcing this is the fact that Microsoft’s agreement to cross-progression and cross-wallet on the above terms was the product of a series of email exchanges in January and March 2018 between Mr Sweeney and Mr Phil Spencer, Microsoft’s executive vice president of gaming, in which Mr Spencer made plain his concern about losing commission on in-app purchases which Xbox users would now be able to make on mobiles and other platforms and would otherwise have made on their Xboxes.

3175    In connection with those exchanges, Mr Sweeney gave evidence that both Sony and Microsoft had expressed such a concern when he had advocated for cross-platform game play in the past and accepted that Mr Spencer’s email conveyed that he was concerned about price competition for in-app purchases from other platforms. Indeed, Mr Spencer’s concern persisted even after Mr Sweeney had offered him most-favoured nation pricing terms for Microsoft.

3176    It is plain from that series of exchanges that the conditions Microsoft imposed on its agreement to cross-progression and cross-wallet were driven by its concern that, without such conditions, it would lose commission on in-app purchases to other platforms, including mobile platforms such as the App Store.

3177    Mr Sweeney suggested that Microsoft’s concern about V-bucks being cheaper on other platforms could be financial or reputational. Given the terms of Mr Sweeney’s email exchanges with Mr Spencer in January and March 2018, the former is far more likely than the latter. But either way, such a concern indicates that Microsoft perceived itself as being in competition with other platforms, including the App Store. Even a concern about the reputational impact of being undercut on pricing by another platform can only arise if the other platform is seen as a competitor.

3178    Another feature of these emails between Mr Sweeney and Mr Spencer is Mr Sweeney’s view that the console manufacturers compete with mobile platforms to convert them from gaming on mobiles to gaming on consoles.

3179    As to Sony, in March 2018 it agreed to cross-progression with PCs and mobiles, but not with other consoles. But that was in return for a promise from Epic that the price for in-app purchases on PlayStation would be no higher than the lowest price on any other platform. Sony’s requirement that that promise be given likewise reflects its concern, which Mr Sweeney well understood, that it would otherwise lose in-app purchases to mobile platforms.

3180    Subsequently, in September 2018, Sony and Epic entered a short-term agreement to permit cross-progression, but not cross-wallet on PlayStation, PCs, iOS, Android and the other consoles. That agreement required Epic to offer Sony the same digital content and V-bucks as was available on all other platforms and to give Sony, in effect, most favoured nation pricing for all digital content and V-bucks.

3181    Mr Sweeney understood that Sony required Epic’s agreement to those terms to protect itself against PlayStation users making in-app purchases on other platforms, including mobile platforms, if the digital content were different or prices were lower on those other platforms.

3182    Under the September 2018 agreement, Epic also agreed to a revenue-sharing arrangement, the basic point of which was to ensure that Sony did not earn a lesser share of Fortnite revenue across all platforms than its share of Fortnite game play hours across all platforms. Mr Sweeney understood that Sony required Epic’s agreement to that arrangement because of the risk that with cross-progression, even if digital content and prices were the same across all platforms, in-app purchases that users would have made on PlayStation might be made on other platforms instead.

3183    That September 2018 agreement was replaced by a longer-term agreement between Sony and Epic in September 2019. The 2019 agreement was expanded to cover a streaming platform, Google Stadia.

3184    Whilst Google Stadia is now defunct, Mr Sweeney’s evidence was that the agreement also covered all of the other streaming platforms because they would fall into either the Xbox or Windows PC category.

3185    The September 2019 agreement, like that of 2018, also permitted cross-progression, but not cross-wallet. It likewise required Epic to offer Sony and to provide it with most favoured nation pricing for the same digital content and V-bucks as was available on all other platforms.

3186    It is plain that Sony’s reasons for requiring those clauses in the 2019 agreement must have been the same as its reasons for requiring the equivalent clauses in the 2018 agreement. Mr Sweeney assumed Sony’s reasons were some combination of concerns of financial loss or reputational concerns.

3187    The 2019 agreement also contained a revenue sharing arrangement in somewhat different terms from those in the 2018 agreement, but the basic point of which was to ensure that Sony did not earn commission on a lesser share of Fortnite revenue from players who played on multiple platforms than its share of Fortnite gameplay hours across all platforms. Mr Sweeney understood that Sony required Epic’s agreement to that arrangement for the same reasons as it had required the revenue-sharing arrangement in the 2018 agreement.

3188    Notwithstanding these earlier agreements, Sony did not agree to cross-wallet functionality for Fortnite until May 2022. A further written agreement recording that development was entered into. This most recent agreement contains similar terms requiring Epic to offer Sony the same digital content and V-bucks as are available on other platforms, most favoured nation pricing and revenue share requirements. It can be inferred that Sony’s reasons for requiring those terms are the same reasons that Mr Sweeney agreed motivated the inclusion of similar terms in the earlier agreements.

3189    It follows that the terms of each of these three agreements reflect Sony’s continuing concern that, without them, cross-progression and cross-wallet might well cause it to lose commission on in-app purchases to other platforms, including mobile platforms such as the App Store. That concern is clear evidence that Sony regards its PlayStation platform as being in competition with other app transaction platforms, including the App Store.

3190    The position as to Nintendo is even more stark. Nintendo still does not allow cross-wallet functionality. Its refusal to agree to that functionality is recorded in an internal Epic email sent by Mr Bill Fine to Mr Mark Rein and others on 27 April 2018. Mr Sweeney ultimately accepted that that refusal was most likely due to a concern that agreeing to cross-wallet functionality could cause Nintendo to lose revenue. Again, that reflects a belief on Nintendo’s part that its Switch platform competes with other platforms that do permit cross-wallet functionality, including the App Store.

3191    Further, the console manufacturers’ concerns about losing revenue to mobile platforms were well-founded. At the time of Nintendo’s refusal to agree to cross-wallet, Mr Sweeney perceived that there would be revenue bleeding out of console into mobile and thought Nintendo not agreeing to cross-wallet might be a good stopgap solution to that.

3192    As Mr Sweeney explained in his evidence, Epic had observed a trend where a cohort of Fortnite players was primarily playing on console, but primarily purchasing on mobile, and their mobile-play time was out of whack with their mobile purchasing. He further said that the cohort of players in question was non-trivial.

3193    And he ultimately accepted, consistently with his statement that Nintendo not agreeing to cross-wallet might be a good stopgap solution, that the trend Epic had observed was enabled by cross-progression, which both Microsoft and Sony had agreed to at that time, or cross-wallet, which Microsoft had agreed to, or both.

3194    Further, Epic’s views about substitution between platforms were also evidenced by its approach to the hotfix. For example, Epic projected that, in the event that Fortnite was removed from the App Store and the Play Store, between 30 and 70% of its lost revenue would transfer to other platforms, with a baseline projection of 50%.

3195    Epic encouraged Fortnite players to switch to other platforms by telling them that, according to a webpage screenshot taken in 2023 and titled “Join the Battle and Play in the #FreeFortnite Cup on August 23”, “the party continues on PlayStation 4, Xbox One, Nintendo Switch, PC, Mac, GeForce Now, Google Play, and through both the Epic Games App … or the Samsung Galaxy Store”.

3196    Mr Sweeney told Mr Spencer in an email on 5 August 2020 that Epic had plans, being the hotfix, that would provide an extraordinary opportunity to highlight the value proposition of consoles and PCs in contrast to mobile platforms, and to onboard new console users. Although Mr Sweeney attempted to justify that statement on the grounds that he might have thought consoles and PCs, on the one hand, and mobiles, on the other, were complements, the only rational explanation for referring to an extraordinary opportunity to highlight the value proposition of consoles and PCs in contrast to mobile platforms was a belief, which Mr Sweeney held, that they competed with each other.

3197    Further, even leaving aside functionality such as cross-progression and cross-wallet, it is plain that many significant developers make digital content for use in iOS apps available for purchase out-of-app.

3198    That is the case, for example, for each and every one of the top 25 iOS apps of all kinds by revenue and download, the top 25 iOS game apps by revenue, and the top 25 video streaming apps by revenue and download. A further example is the Epic Games Store, which is widely used for transactions.

3199    It only makes sense for developers to do this if they expect that at least some non-trivial proportion of iOS users will purchase such digital content out-of-app. Thus, such developers must view out-of-app purchases of digital content as substitutes for in-app purchases.

3200    Further, some developers make digital content for use in iOS apps available for purchase out-of-app at cheaper prices than in-app. The most likely explanation for this is that they do so to encourage users to acquire content out-of-app and thereby avoid the App Store commission, reinforcing the fact that they view those channels as substitutes. Developers can also offer free digital content in their web stores to encourage users to transact there.

3201    Further, a number of reader apps choose not to offer their digital content in-app at all, but only to make it available out-of-app. For example, various video streaming app developers have done that.

3202    Until April 2020, Amazon Prime Video did not have an option for users to purchase movie and TV titles in its iOS app. Such titles could only be purchased out-of-app, before being watched in-app.

3203    Similarly, none of Netflix, Stan nor Foxtel Go has an option for users to purchase a subscription in their iOS app. In each case, users had to purchase their subscriptions out-of-app, before viewing the subscribed for content in-app.

3204    Likewise, Amazon makes its Kindle e-reader app available on iOS, Android, Mac and PC, but does not allow paid transactions through the Kindle iOS or Android apps and transacts with consumers through the Amazon.com website or its Kindle e-reader device.

3205    Spotify makes its music streaming app available on iOS, Android, Mac and Windows, as well as other devices, but does not allow users to purchase subscriptions in the iOS app. iOS users have to subscribe to Spotify through a web browser before consuming the subscribed for content in the iOS app.

3206    In each of these instances, developers and the users who continue to download their iOS apps and transact for digital content out-of-app view out-of-app purchases as substitutes for in-app purchases.

3207    These industry practices also illustrate a further point. Developers who have, under the reader rule, made content available only outside the iOS app must have assessed that the transaction costs to users of making an out-of-app purchase are not so great as to deter the purchase.

3208    Further, platforms compete with each other for users by offering exclusive digital content. Epic has used the demand for exclusive Fortnite digital content to extract commercial advantages from platform operators.

3209    Further, the App Store has promoted exclusive digital content for Roblox, PUBG Mobile and Angry Birds 2. The Play Store has promoted exclusive digital content for Roblox, Star Wars: Galaxy of Heroes, and Pokemon Go.

3210    And an extension of this form of competition is that platforms have also sought to constrain competitors’ access to exclusive Fortnite digital content.

3211    Further, game streaming services compete with the App Store and other gaming platforms.

3212    So, in 2024 NVIDIA’s GeForce now website emphasised the ability to play on numerous devices including iPads and iPhones and sought to differentiate the service from platforms that allow for the download of native apps. It promoted the ability to “game anywhere, on any device, without any downloads” and emphasised that “[y]ou’ll never need to download, update or patch your favourite games again—everything is handled in the cloud”. Further, Mr Sweeney regards streaming services as alternatives to playing Fortnite using a native app. In March 2020, he published a tweet that read “[c]loud streaming services will also be key players in ending the iOS and Google Play payment monopolies and their 30% taxes”. That view is supported by the evidence that within a matter of weeks, Xbox Cloud Gaming achieved meaningful market share.

3213    Now I accept that all of these matters demonstrate some competition between platforms for developers and users, but I do not accept that this amounts to close competition or the existence of close competitive constraints. This competition does not deny my conclusions on market definition or the existence of a substantial degree of market power as I have found concerning both the Apple context and the Google context.

Conduct of developers in choosing between competing platforms

3214    Let me elaborate on certain aspects from the developers’ perspective.

3215    Choices of platform are affected by a number of considerations. If a platform has a reputation for security or good quality games, or processes transactions smoothly and securely, those factors are attractive to developers.

3216    The number of users is important. Further, the patterns of behaviour of users on different platforms may make certain types of users more attractive to developers than others.

3217    Further, marketing support provided by platforms is a factor affecting the platforms on which developers choose to launch.

3218    Further, from the perspective of a developer, the commission fee paid to the platform, which reflects a payment in exchange for a range of benefits, is obviously a consideration in terms of both the fee and the services provided in exchange.

3219    Let me set out some more detailed evidence on the subject.

The developer perspective about Apple’s services

3220    Mr Ringrose of SMG Studio, a game app developer, gave evidence about the types of tools, resources, services and opportunities that Apple provides to developers like him to enable developers to develop apps for iOS devices and distribute them through the App Store. The particular examples given by Mr Ringrose are the following, although I have already touched on some of these.

3221    First, there are SDKs for the development of apps for iOS devices.

3222    Second, there is App Store Connect, which is a central platform for developers to create product pages for apps on the App Store, to submit apps and app updates for Apple to review, to configure pricing, subscriptions, in-app purchases and release of developers’ apps, to view and respond to app user reviews for developers’ own apps and to access analytics that measure the performance of developers’ apps such as sales data, financial reports, download rates and other statistics and trends.

3223    Third, there is Xcode IDE, which is a software development tool Apple provides to developers to develop their apps for iOS devices, and which significantly reduces the time and resources needed to develop an app.

3224    Fourth, there is TestFlight, which is software that allows developers to conduct beta testing of their apps by making them available to up to 10,000 external testers prior to launch. Feedback provided by testers provides valuable information for improvements and identification of unwanted issues such as crashing and broken links before the app is launched on the App Store.

3225    Fifth, there is ReplayKit, which is an SDK that allows users to record video from their iOS device screen and audio from the app and device microphone so that users can share recordings with other users through email, messages and social media.

3226    Sixth, there is GameKit. which provides integration with Apple’s Game Centre social network gaming features and enhances gamers’ experience by providing a single user account for use across multiple games and Apple devices, the ability to add leaderboards for players to rank themselves among friends and other players globally, and the ability to reward players with prizes and achievements and thereby encourage them to stay in the game. Game Centre also enables multiplayer functionality including automatic matching and the option for users to invite friends to join a game.

3227    Seventh, there is StoreKit, with which developers may offer players additional content and add-on features by way of in-app purchase and subscriptions.

3228    Mr Ringrose also explained the benefits to him as a developer in relation to other aspects of distribution and monetisation. Apple’s services provide efficient processes for payment remission, currency conversion, local sales tax, chargeback facility, payment of payment processing fees, legal compliance such as parental guidance requirements, invoicing requirements and cooling-off periods, management of customer enquiries, support for billing issues, troubleshooting, addressing refund requests and processing refunds. By taking advantage of these services developers can avoid incurring costs they would otherwise incur if they distributed apps directly to users.

3229    Further, the efficiency and efficacy of the App Store app review process is a further aspect of differentiation which is of interest to developers.

3230    Mr Ringrose’s SMG Studio, which has submitted around 15 to 20 unique apps and thousands of individual submissions for app review, has found the App Store app review process to be straightforward, that approvals for apps and app updates have generally occurred within 24 hours of submission, and requests for expedited review of apps have been granted within a short period.

3231    Further, there is marketing and other support from Apple’s developer relations team based in Australia, which is the primary point of contact for Mr Ringrose’s studio to communicate with Apple and to provide feedback, ask questions or raise concerns about the App Store app review process or App Store generally. The developer relations team is proactive. It provides information about new App Store features and opportunities to work with Apple to enhance the developer’s apps and increase its marketing exposure.

3232    As a result of the App Store, Mr Ringrose’s SMG Studio has grown to make its game apps available to players in 175 countries and collects revenues on global transactions.

3233    The business model of SMG Studio also illustrates the variety of options available to developers to take commercial advantage of Apple’s offerings. Many of SMG Studio’s free to download apps include in-app advertising. In-app advertising is the largest source of SMG Studio’s revenue on the App Store and other platforms. SMG Studio does not pay any commission to Apple for revenue earned through in-app advertising in the App Store.

Choices available to developers

3234    As Apple has pointed out, developers make commercial decisions about the platforms on which they distribute their digital content, including apps and in-app content. There was no real contest concerning the following propositions.

3235    If a developer chooses not to offer a game on a specific platform at any given point in time, that does not preclude that platform from being a substitute, bearing in mind that a market includes the area of potential as well as actual close competition. Developers may expand the reach of their games on platforms over time.

3236    Developers have choices available to them as to the platforms on which they release software. Where an app is released on multiple platforms, developers have choices as to the order in which they release the app. Porting an app to a new platform requires a developer to commit substantial engineering time, resources and money. If their resources are limited, they make choices about which platforms to develop for and how much time to spend on developing for particular platforms.

3237    Game developers also decide where and how app users will pay for games, which facilitates app user substitution across platforms.

3238    Developers can enable customers to use in-game currency purchased through alternative platforms on iOS devices, that is, cross-wallet play.

3239    Developers may allow linking of in-game content and game progression across devices using a common user account which spans different platforms, that is, single sign-on, thereby enabling continued game play, that is, cross-progression.

3240    Offering virtual currency and single-sign on are features that further strengthen substitutability between app transaction platforms.

3241    All of these matters support the conclusion that transactions through alternative platforms can be functional substitutes for transactions through the App Store.

3242    Now developers will consider many variables when deciding whether to develop games for particular platforms, including the developer’s own resources, which platform and which user base represents the most apt target for the game, whether the developer has the skillset to develop for particular platforms, and the different price points for iOS and Android.