Epic Games Inc v Apple Inc (No 2) [2026] FCA 1552

Federal Court of Australia

Epic Games Inc v Apple Inc (No 2) [2026] FCA 1552

ORDERS

OTHER MATTERS:

In these orders the following definitions apply:

A.    “App Store” means in order 1 Apple’s App Store irrespective of the geographic region or labelling of the storefront, but in orders 2 to 11 means the App Store Australian storefront.

B.    “Developers” means developers of native iOS apps who are and remain admitted to the Apple Developer Program, wherever in the world such a developer is incorporated, resides or is otherwise domiciled.

C.    “Australian Apple Account” means an Apple Account with the country or region set to “Australia”.

D.    “User” means in orders 2 to 11 a user who has an Australian Apple Account.

E.    Save as aforesaid, the terms used in these declarations and orders shall have the meaning given to them in the liability reasons (Epic Games Inc v Apple Inc [2025] FCA 900) or these reasons on relief, but to the extent of any inconsistency the meaning given in these latter reasons shall prevail.

THE COURT DECLARES THAT:

1.    Since 6 November 2017, the first respondent has engaged in conduct in contravention of s 46(1) of the Competition and Consumer Act 2010 (Cth) (CCA), in that:

(a)    the first respondent had a substantial degree of power in the iOS app distribution services market and the iOS in-app payment solutions market at all relevant times;

(b)    the first respondent has engaged in conduct (described in sub-paragraph (c)) that had the purpose, and that had or was likely to have the effect, of substantially lessening competition in the iOS app distribution services market by:

(i)    requiring that app developers who wish to distribute iOS apps to iOS device users do so only via the App Store;

(ii)    prohibiting the distribution of iOS apps to iOS devices by any means other than the App Store, save for certain trivial exceptions expressly permitted;

(iii)    preventing or hindering app developers from developing or updating iOS apps for distribution through distribution channels other than the App Store;

(iv)    preventing or hindering iOS device users from downloading, installing or updating iOS apps, including alternative app stores, from websites or alternative app stores; and

(v)    imposing OS-level restrictions that prevent iOS apps from running on an iOS device unless obtained via the App Store or pre-installed by the first respondent;

(c)    the conduct comprised requiring app developers that wish to distribute iOS apps to enter into the developer program licence agreement (DPLA), the terms of which are non-negotiable, and to comply with the App Store Review Guidelines that impose the following terms upon those app developers, and enforcing those terms against developers, including the applicants:

(i)    iOS apps may be distributed only if selected by the first respondent in its sole discretion for distribution via the App Store, subject to trivial exceptions;

(ii)    an iOS app may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store, Custom App Distribution or TestFlight;

(iii)    app developers must not distribute their iOS apps to third parties via distribution methods other than those expressly permitted by the first respondent;

(iv)    interpreted code downloaded to an iOS app may not create a store or storefront for other code or iOS apps;

(v)    iOS apps may only use Application Programming Interfaces (APIs) which are contained in software provided to app developers by the first respondent in the manner prescribed by the first respondent and must not use or call any private APIs;

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

(vii)    app developers seeking to distribute iOS apps must appoint the first and second respondents as their agent for the marketing and delivery of the developer’s app to iOS users located in Australia; and

(viii)    app developers are prohibited from issuing any refunds to users of their iOS apps;

(d)    the first respondent has engaged in conduct (described in sub-paragraph (e)) that had or was likely to have the effect of substantially lessening competition in the iOS in-app payment solutions market by preventing or prohibiting app developers and users from using payment methods other than the first respondent’s payment solution (IAP) for purchasing digital content for use in-app, by:

(i)    requiring app developers to use IAP for all in-app purchases of digital content in iOS apps and prohibiting them from using an alternative payment method within that iOS app; and

(ii)    prohibiting app developers from directing users from within iOS apps to alternative payment methods for purchases of digital content;

(e)    the conduct comprised requiring app developers that wish to distribute iOS apps to enter into the DPLA and comply with the App Store Review Guidelines that impose the following terms upon those app developers, and enforcing those terms against developers, including the applicants:

(i)    if developers want to unlock features or functionality within their iOS app, they:

A.    must use IAP; and

B.    must not use their own mechanisms to unlock content or functionality;

(ii)    iOS apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP;

(f)    the first respondent enforced the contractual terms in sub-paragraphs (c) and (e) against the applicants by inter–alia:

(i)    refusing to allow the first applicant to offer Epic Direct Pay for any in-app purchases in iOS apps;

(ii)    removing the Fortnite app from the App Store on 13 August 2020; and

(iii)    terminating the first applicant’s Team ID ‘84 developer account on 28 August 2020.

AND THE COURT ORDERS THAT:

Fortnite and other iOS apps developed by Epic

2.    Upon written application being made by the applicants, the first respondent must do all things necessary (including procuring any act of any related corporation) to permit the Fortnite app and/or other iOS apps developed by the applicants (not including an alternative app store) to be (i) admitted or readmitted to the App Store subject to the applicants complying with the DPLA and App Store Review Guidelines (insofar as the provisions of the DPLA and App Store Review Guidelines are consistent with these orders), and (ii) made available for discovery, downloading, use and updating by iOS device users, in the same manner as other apps available on the App Store by taking the following steps:

(a)    processing in accordance with its usual business practices any of the following application forms or documents which are submitted by any of the applicants:

(i)    Apple Developer Agreement;

(ii)    DPLA and any Schedule thereto;

(iii)    Xcode and Apple SDK Agreement; and

(iv)    any variation or replacement of these application forms or documents;

(b)    accepting such application forms or documents which are in a compliant form;

(c)    in the case of tools and APIs (including software development kits) that are generally made available by the respondents to third-party app developers who distribute apps via the App Store, permitting the applicants to use such of the respondents’ tools and APIs (including software development kits) as are required for the development, distribution and updating of the Fortnite app and/or other apps developed by the applicants for macOS and iOS, in accordance with the applicable contractual terms and on substantially the same terms as generally apply to all such third-party app developers (insofar as those terms are consistent with these orders); and

(d)    processing and accepting in accordance with its usual business practices any compliant update to the Fortnite app and/or other iOS apps developed by the applicants which are submitted by any of the applicants for distribution via the App Store.

Competition in iOS app distribution

3.    Subject to orders 12 and 13, the first respondent must do all things necessary (including procuring any act of any related corporation) to ensure that users of iOS devices can discover, obtain and update iOS apps, including alternative app stores, via distribution channels other than the App Store (including via direct download and alternative app stores) provided those iOS apps have undergone an automated scan for genuine security and/or privacy reasons and been notarised by Apple or a suitably qualified third party (Alternative Distribution Channels), and that app developers can distribute and update such iOS apps to such users via Alternative Distribution Channels, including but not limited to providing access to all tools and APIs (including software development kits):

(a)    necessary for developers to develop and distribute iOS apps;

(b)    necessary for developers to develop iOS apps that are capable of creating an interface for displaying iOS apps and which may be used by an iOS user to discover, download, install and update iOS apps; and

(c)    necessary for iOS users to discover, download, install and update apps via Alternative Distribution Channels,

where such tools and APIs are made available in the same manner and on substantially the same terms as tools and APIs are made available to developers who distribute iOS apps via the App Store, and to users of iOS apps distributed via the App Store.

4.    Subject to orders 12 and 13, the first respondent must not (including by procuring any act of any related corporation) prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder users of iOS devices from discovering, obtaining and updating iOS apps, including alternative app stores, via Alternative Distribution Channels, or from using iOS apps obtained in that way on iOS devices, or prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder app developers from distributing and updating such iOS apps to such users via Alternative Distribution Channels, including but not limited to:

(a)    prohibiting, preventing or taking any action (including imposing a fee or condition) which is likely to hinder access to any tool or API (including software development kits):

(i)    necessary for developers to develop and distribute iOS apps and which are available to developers distributing iOS apps via the App Store;

(ii)    necessary for developers to develop iOS apps that are capable of creating an interface for displaying iOS apps and which may be used by an iOS user to discover, download, install and update iOS apps;

(iii)    necessary for iOS users to discover, download, install and update apps via Alternative Distribution Channels;

(b)    imposing any restrictions that prevent iOS apps from running on an iOS device unless downloaded from the App Store or pre-installed by the first respondent; and

(c)    making it a term of the applicants’ or any other app developer’s access to the App Store that they will not make their iOS apps available via an Alternative Distribution Channel.

5.    Subject to orders 12 and 13, the first respondent must not (including by procuring any act of any related corporation):

(a)    impose any fees or conditions for access to, or use of, Alternative Distribution Channels by iOS app developers or iOS users;

(b)    impose any fees or conditions for access to, or use of, any tool or API (including software development kits) necessary for app developers to develop and distribute iOS apps via Alternative Distribution Channels, that have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via Alternative Distribution Channels, including by imposing fees higher, or conditions more onerous, than those applied to developers of iOS apps which are monetised other than through in-app purchases (including free apps and apps monetised through advertising) when distributed via the App Store;

(c)    require the applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel to refrain from offering lower prices, or more favourable discounts or other benefits, to users who make purchases of digital content for use in that app when it is distributed via the Alternative Distribution Channel, as compared to when the app is distributed via the App Store;

(d)    require the applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel, and who allows users of those apps to access content, subscriptions or features they purchased from the applicants’ or developer’s own website or another distribution channel to also make that content, subscriptions or features available as an in-app purchase within their iOS apps distributed via the App Store;

(e)    prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder the applicants or any other operator of an alternative app store from making and implementing their own choices as to which apps they will distribute via any alternative app store that they operate;

(f)    require the applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel to appoint any particular person as their agent for the marketing and delivery of the developer’s app to iOS users located in Australia via that distribution channel;

(g)    prohibit the pre-installation of third-party apps, including alternative app stores, on iOS devices;

(h)    remove an app from, or disable an app installed on, an iOS device which has been obtained by a user via an Alternative Distribution Channel unless the app:

(i)    contains illicit, objectionable or harmful content; or

(ii)    constitutes malware or malicious code which poses a genuine security risk that either requires urgent elimination without prior notice or that has not been remedied following the first respondent (or a related corporation) providing the app developer with reasonable notice of the existence, nature and extent of that security risk; or

(iii)    is required by the requirements of the Online Safety Act 2021 (Cth) or any subordinate legislation or instrument made thereunder to be removed or disabled;

(i)    impose frictions on or impediments to the discovery, downloading, installation, execution or updating of any iOS apps available or distributed via Alternative Distribution Channels, including alternative app stores:

(i)    that are disproportionate to the security risk posed by those apps to iOS devices and iOS device users; or

(ii)    that otherwise have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via Alternative Distribution Channels or the use of such apps by iOS device users;

(j)    require the applicants or any other app developer who wishes to make, or makes, their iOS apps available for distribution via an Alternative Distribution Channel to offer or to use any particular payment method, or require that they must offer IAP as an alternative to the developer’s preferred payment method;

(k)    require the applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel to enter into any contractual arrangement with the first respondent (or any other person) as a condition of the applicants or the developer distributing their iOS apps via the Alternative Distribution Channel, other than in respect of the licensing of the first respondent’s tools and APIs for the development of iOS apps.

Competition in iOS in-app payment solutions

6.    Subject to orders 12 and 13, the first respondent must not (including by procuring any act of any related corporation):

(a)    require that app developers who distribute iOS apps via the App Store must use IAP for in-app purchases of digital content in those apps;

(b)    prohibit app developers who distribute iOS apps via the App Store from directing users to a payment method other than IAP for purchases of digital content;

(c)    prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder iOS app developers from:

(i)    using payment methods other than IAP for accepting and processing payments for in-app purchases of digital content within iOS apps distributed via the App Store or via an Alternative Distribution Channel;

(ii)    providing buttons, external links, or otherwise informing, leading or directing iOS device users from within an iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP; or

(iii)    using their own choice of payment method for accepting and processing payments for in-app purchases of digital content, provided that, where the conditions referred to in paragraph 7 below have been satisfied, the first respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP;

(d)    prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder iOS users from using payment methods other than IAP for purchasing digital content for use in-app, provided that, where the conditions referred to in paragraph 7 below have been satisfied, the first respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP.

7.    Subject to orders 12 and 13, the first respondent may only impose necessary and proportionate security requirements, as referred to in paragraph 6(c)(iii) or (d), or in paragraph 8(a) if they have first given the affected iOS app developers reasonable prior notice in writing that identifies and explains the nature and causes of that additional security risk, and why the proposed requirements are necessary and appropriate to address that risk. For the purposes of this paragraph, reasonable prior notice in writing can be given by direct communication with developers and where that is not reasonably practicable, by a notice published on a website maintained by the first respondent.

8.    Subject to orders 12 and 13, the first respondent must take all steps necessary to permit the Applicants and any other app developer (including by procuring any act of any related corporation):

(a)    to use a payment method other than IAP for accepting and processing payments for in-app purchases in apps distributed to iOS device users via the App Store or via an Alternative Distribution Channel, provided that, where the conditions referred to in paragraph 7 above have been satisfied, the first respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP; and

(b)    to provide buttons, external links, or otherwise inform, lead or direct iOS device users from within an iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP.

9.    Subject to orders 12 and 13, the first respondent must not (including by procuring any act of any related corporation) require that the applicants or any other iOS app developer who uses a payment method other than IAP for accepting and processing payments for purchases of digital content for use in-app:

(a)    refrain from offering lower prices, or more favourable discounts or other benefits, to users who purchase via a payment method other than IAP than those applicable to in-app purchases effected via IAP;

(b)    report the transactions accepted and processed using a payment method other than IAP or grant any audit right in respect of those transactions;

(c)    offer IAP in addition to the developer’s preferred payment method or prevent app developers from using payment providers that act as a merchant of record;

(d)    in connection with any iOS app distributed via an Alternative Distribution Channel, pay any fee in connection with:

(i)    in-app purchases made via a payment method other than IAP, or

(ii)    purchases of digital content from any website or from any developer’s platform for use in-app;

(e)    in connection with any iOS app distributed via the App Store, where:

(i)    in-app purchases are made using a payment method other than IAP, or

(ii)    purchases of digital content are made on any website or from any developer’s platform for use in-app,

pay a fee that exceeds any fee that is imposed on app developers who distribute iOS apps via the App Store in connection with in-app purchases of physical goods or services using a payment method other than IAP, plus any additional economic costs that are genuinely and reasonably incurred by Apple in connection with an iOS device user making an in-app purchase of digital content using a payment method other than IAP that are not incurred when a user makes an in-app purchase of physical goods or services using the same payment method.

10.    Subject to orders 12 and 13, the first respondent must not (including by procuring any act of any related corporation):

(a)    impose or require the introduction of any friction or impediment into the process whereby iOS device users can elect to use, or can in fact use, a payment method other than IAP when purchasing digital content for use in-app which is additional to those frictions or impediments that a user encounters when making in-app purchases of physical goods and services using a payment method other than IAP in an app distributed via the App Store; nor

(b)    impose any fees or conditions for access to, or use of, any tool or API (including software development kits) that is necessary for app developers to develop and distribute iOS apps that allow or enable developers and iOS device users to use a payment method other than IAP, which do not apply in respect of apps distributed via the App Store within which iOS device users can make in-app purchases of physical goods or services using a payment method other than IAP.

Compliance and discrimination

11.    Subject to orders 12 and 13, the first respondent must not (including by procuring any act of any related corporation) reject for distribution, discriminate against, take retaliatory action against, or otherwise disadvantage:

(a)    any of the applicants’ or any other app developer’s apps submitted for distribution via the App Store; nor

(b)    the applicants or any other app developer,

on the basis that:

(c)    the developer’s app is available for discovery, downloading, installing or updating via Alternative Distribution Channels;

(d)    the app uses or will use a payment method for accepting and processing payments for in-app purchases other than IAP; or

(e)    the developer of the app links or otherwise informs, leads or directs iOS device users from within the iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP.

Commencement date of certain orders

12.    Subject to order 13, orders 3 to 11 shall not commence operation until Noon (Melbourne time) on 1 March 2027.

13.    If Apple files and serves an application no earlier than 1 February 2027 but no later than 15 February 2027 with, at the same time, all necessary supporting evidence seeking an extension of the 1 March 2027 commencement date referred to in order 12 to 3 May 2027, then if the Court grants that application such date shall be extended to Noon (Melbourne time) on 3 May 2027.

Costs

14.    The first respondent pay 85% of the applicants’ costs of and incidental to the proceeding including reserved costs up to and including the trial on liability, on the standard basis.

15.    The parties’ costs of and incidental to the hearing on relief be reserved.

16.    Liberty to apply.

REASONS FOR JUDGMENT

BEACH J:

1    These reasons address the question of the relief sought by Epic Games Inc against the Apple parties consequent upon my findings against Apple Inc after the joint trial on liability where I found that it had contravened s 46 of the Competition and Consumer Act 2010 (Cth) (CCA).

2    It will be recalled that I heard four proceedings concurrently against the Apple and Google parties and delivered three sets of reasons being Epic Games Inc v Apple Inc [2025] FCA 900; (2025) 189 IPR 1; (2025) ATPR ¶42–910; Epic Games Inc v Google LLC [2025] FCA 901; (2025) ATPR ¶42–911; and Anthony v Apple Inc; McDonald v Google LLC [2025] FCA 902; (2025) ATPR ¶42–912. What I am about to say assumes some familiarity with the detail of those reasons and I have adopted my previous definitions of various terms unless indicated to the contrary.

3    Now there are four preliminary points worth noting before proceeding further.

4    First, I have today delivered a separate set of reasons in the Apple class action and the Google class action (Anthony v Apple Inc; McDonald v Google LLC (No 2) [2026] FCA 1553).

5    Second, it has not been necessary for me to address the question of relief in the action that Epic took against Google flowing from my s 46 findings in that proceeding as that action has now settled. On 6 March 2026 I made the following orders in that proceeding:

1.    The proceeding be dismissed.

2.    All costs orders previously made in the proceeding be vacated.

3.    There be no order as to costs.

6    Third, Epic has requested additional reasons from me concerning my rejection of its s 45 and s 47 cases, but I have declined that invitation. Admittedly, my reasons in Epic v Apple were a little brief on those topics, but nothing more was needed to be said or need be said.

7    Fourth, on 20 April 2026 I granted leave to the ACCC to intervene in this proceeding to permit it to make written submissions on the question of relief. I made the following orders:

1.    The Australian Competition and Consumer Commission be granted leave to intervene in the proceeding pursuant to s 87CA(1) of the Competition and Consumer Act 2010 (Cth) for the purposes only of making written submissions in relation to relief (the ACCC’s submissions on relief) in the form of annexure A to the ACCC’s submissions dated 10 April 2026 in support of its intervention application.

2.    The applicants and the respondents file and serve any further submissions in response to the ACCC’s submissions on relief (limited to 5 pages each) by noon on 27 April 2026.

8    The ACCC filed written submissions that focused on the ambit of the power under s 80(1), questions of extra–territorial effect and questions of international comity.

9    Now before proceeding further, it is worth recapping my principal conclusions in Epic v Apple concerning finding that Apple had contravened s 46. At [51] to [69] I made the following findings:

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.

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.

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.

Let me elaborate further on some of my key findings.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

10    In summary and in order to give effect to my liability findings, I have reached the following conclusions in terms of the appropriate relief.

11    First, I have largely accepted Epic’s formulation of the first declaration which embodies my principal liability findings concerning Apple’s contravention of s 46 of the CCA. This declaration is not limited to the location of the user, the app developer or the particular geographic region of the storefront of the App Store.

12    Second, I have rejected Epic’s proposed order and declaration that was sought under s 87 seeking to have certain contractual provisions declared void.

13    Third, I have made Epic’s proposed order concerning the admission or readmission of Epic’s Fortnite and other apps to the App Store, but only to the Australian App Store.

14    Fourth, I have largely made Epic’s proposed prohibitory and mandatory injunctions but with some important qualifications. These injunctions only impose requirements on Apple concerning the Australian App Store and users with an Australian Apple Account. But as for developers, they can be in Australia or anywhere else in the world so long as they are current members of Apple’s Developer Program. Likewise alternative payment solution providers can be in Australia or anywhere else in the world.

15    Fifth, the prohibitory and mandatory injunctions that I will make have no sunset provision. Apple has the capacity in the future to apply under s 80(3) to vary or discharge any of my injunctions if there are any material changes in circumstances. No doubt my successor will deal with any such application sympathetically.

16    Sixth, I have provided in my orders that the injunctions that impose technical and commercial changes, whether positive or negative in operation, are not to come into operation until Noon on 1 March 2027, with one shot given to Apple to obtain a further possible extension until 3 May 2027. But such a postponement does not apply to the declaration and the order concerning the re-instatement of Epic’s apps to the Australian App Store.

17    Seventh, in the light of what I have just said, it will be necessary to discuss with the parties whether if there is any appeal, any stay is necessary for the moment on any of my orders and if so what the terms and duration of such a stay should be.

18    Eighth, in terms of the costs of the liability trial I will order that Apple pay 85% of Epic’s costs. Now at the moment I have reserved the parties’ costs of the relief hearing, but I would suggest that costs be dealt with in the same way. Epic has been substantially successful in terms of its arguments, save on two aspects. The first aspect is that I have not granted any s 87 relief. The second aspect is that on the substantive mandatory and prohibitory injunctions I have not accepted the geographic scope that Epic sought. On that aspect, although I have largely rejected Apple’s legal arguments on the construction and operation of s 80, I have accepted its discretionary arguments for limiting the geographic reach to the Australian App Store and users who have an Australian Apple Account. On balance Epic should have most of its costs but there should be some discount to reflect these two aspects. In any event I will hear further from the parties on these questions.

19    Let me now turn to addressing what Epic has sought and at this stage begin with the declarations.

Declarations

20    Epic has sought the following declarations:

1.    Since 6 November 2017, the First Respondent has engaged in conduct in contravention of s 46(1) of the Competition and Consumer Act 2010 (Cth) (CCA), in that:

(a)    the First Respondent had a substantial degree of power in the iOS app distribution services market and the iOS in-app payment solutions market at all relevant times;

(b)    the First Respondent has engaged in conduct (described in sub-paragraph (c)) that had the purpose, and that had or was likely to have the effect, of substantially lessening competition in the iOS app distribution services market by:

(i)    requiring that app developers who wish to distribute iOS apps to iOS device users do so only via the App Store;

(ii)    prohibiting the distribution of iOS apps to iOS devices by any means other than the App Store, save for certain trivial exceptions expressly permitted;

(iii)    preventing or hindering app developers from developing or updating iOS apps for distribution through distribution channels other than the App Store;

(iv)    preventing or hindering iOS device users from downloading, installing or updating iOS apps, including alternative app stores, from websites or alternative app stores;

(v)    imposing OS-level restrictions that prevent iOS apps from running on an iOS device unless obtained via the App Store or pre-installed by the First Respondent; and

(vi)    prohibiting the pre-installation of third-party apps, including alternative app stores, on iOS devices;

(c)    the conduct comprised requiring app developers that wish to distribute iOS apps to enter into the developer program licence agreement (DPLA), the terms of which are non-negotiable, and to comply with the App Store Review Guidelines that impose the following terms upon those app developers, and enforcing those terms against developers, including the Applicants:

(i)    iOS apps may be distributed only if selected by Apple in its sole discretion for distribution via the App Store, subject to trivial exceptions (2023 DPLA (EPIC_AUS_00060297, 5 June 2023), clauses 3.2(g) and 6.9);

(ii)    an iOS app may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the App Store, Custom App Distribution or TestFlight (2023 DPLA, clause 3.3.3);

(iii)    app developers must not distribute their iOS apps to third parties via distribution methods other than those expressly permitted by the First Respondent (2023 DPLA, clause 7.6);

(iv)    interpreted code downloaded to an iOS app may not create a store or storefront for other code or iOS apps (2023 DPLA, clause 3.3.2);

(v)    iOS apps may only use Application Programming Interfaces (APIs) which are contained in software provided to app developers by the First Respondent in the manner prescribed by the First Respondent and must not use or call any private APIs (2023 DPLA, clause 3.3.1);

(vi)    app developers must not allow users to access content, subscriptions or features they purchased from the developer’s own website or another app distribution channel without also making it available as an in-app purchase within their iOS apps distributed via the App Store (App Store Review Guidelines, APL-EG_AUS_00077706, 14 February 2023, clause 3.1.3(b);

(vii)    app developers seeking to distribute iOS apps must appoint the First and Second Respondents as their agent for the marketing and delivery of the developer’s app to iOS users located in Australia (2023 DPLA, EPIC_AUS_00060389, Schedule 2, clause 1.1);

(viii)    app developers are prohibited from issuing any refunds to users of their iOS apps (2023 DPLA, Attachment 2, clause 3.4);

(d)    the First Respondent has engaged in conduct (described in sub-paragraph (e)) that had or was likely to have the effect of substantially lessening competition in the iOS in-app payment solutions market by preventing or prohibiting app developers and users from using payment methods other than the First Respondent’s payment solution (IAP) for purchasing digital content for use in-app, by:

(i)    requiring app developers to use IAP for all in-app purchases of digital content in iOS apps and prohibiting them from using an alternative payment method within that iOS app; and

(ii)    prohibiting app developers from directing users from within iOS apps to alternative payment methods for purchases of digital content;

(e)    the conduct comprised requiring app developers that wish to distribute iOS apps to enter into the DPLA and comply with the App Store Review Guidelines that impose the following terms upon those app developers, and enforcing those terms against developers, including the Applicants:

(i)    if developers want to unlock features or functionality within their iOS app, they:

A.    must use IAP (App Store Review Guidelines, clause 3.1.1); and

B.    must not use their own mechanisms to unlock content or functionality (App Store Review Guidelines, clause 3.1.1);

(ii)    iOS apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP (App Store Review Guidelines, clause 3.1.1);

(f)    the First Respondent enforced the contractual terms in sub-paragraphs (c) and (e) against the Applicants by:

(i)    refusing to allow the First Applicant to offer Epic Direct Pay for any in-app purchases in iOS apps;

(ii)    removing the Fortnite app from the App Store on 13 August 2020; and

(iii)    terminating the First Applicant’s Team ID ‘84 developer account on 28 August 2020.

2.    Pursuant to s 87 of the CCA, the contractual terms identified in paragraphs 1(c) and 1(e), insofar as they are contained in any contracts between the Applicants and the First Respondent, and any term to substantially the same effect, are void and of no effect from 6 November 2017.

21    I will set out the other orders that Epic seeks later.

22    Apple has sought the following declaration:

1.    On and from 6 November 2017, the First Respondent engaged in conduct in contravention of s 46(1) of the Competition and Consumer Act 2010 (Cth) (CCA) that:

(a)    had the purpose and effect, or likely effect, of substantially lessening competition in the Australian iOS app distribution services market, by preventing or prohibiting the direct downloading or sideloading of native iOS apps, including app marketplaces, to iOS devices associated with an Australian Apple Account, other than from the Australian App Store; and

(b)    had, or was likely to have, the effect of substantially lessening competition in the Australian iOS in-app payment solutions market by preventing or prohibiting:

(i)    developers and users from using payment methods other than IAP for in-app purchases of digital content within native iOS apps downloaded from the Australian App Store to iOS devices associated with an Australian Apple Account; and

(ii)    save in respect of “Reader apps”, developers from directing users of iOS devices associated with an Australian Apple Account, within native iOS apps downloaded from the Australian App Store, to purchasing mechanisms for digital in-app content other than IAP.

…

Definitions

In these orders:

“App Developers” means developers of native iOS apps who are and remain admitted to the Apple Developer Program.

“Australian App Store” means the App Store Australian storefront.

“Australian Apple Account”, formerly "Apple ID", means an Apple Account with the country or region set to “Australia” and associated with a payment method with an Australian billing address.

“Reader app” means magazine, newspaper, book, audio, music and video apps which may allow a user to access previously purchased content or content subscriptions.

23    I will set out the other orders that Apple seeks later.

24    As I have said, I will make in substance Epic’s proposed form of declaration 1. But I will not make its proposed form of declaration 2. In other words I will not make any order under s 87. Let me elaborate.

Proposed order 1 — declaration

25    Epic seeks a declaration under s 21 of the Federal Court of Australia Act 1976 (Cth) that embodies my principal findings.

26    The relevant principles are not in doubt.

27    First, I have a wide discretionary power to make declarations under s 21.

28    Second, there is utility in declaring contraventions of a statutory provision to have occurred in order to define and publicise the type of conduct that constitutes a contravention, to record my disapproval of the contravening conduct and to set out clearly the foundation on which consequential orders such as injunctions are grounded.

29    Third, I must be satisfied that a proposed declaration of contravention identifies the conduct that constituted the contravention.

30    The public interest supports the making of declarations that confirm the contraventions, convey my disapproval of them, deter the contravener and others from engaging in such conduct, and provide a basis for other orders aimed at fulfilling the statutory objective of promoting competition and protecting the public.

31    But Apple says that there are several deficiencies in the form of declarations sought by Epic.

32    First, it says that the declarations go beyond the gist of my findings and seek to summarise non-exhaustively each element of my reasoning that led to the ultimate findings of contravention. It says that the gist of my findings was that Apple had contravened s 46 by preventing or prohibiting the downloading or sideloading of native iOS apps from sources other than the App Store and by preventing or prohibiting payment methods other than Apple’s in-app purchase system (IAP) for in-app purchases of digital content. Any declaration should be limited to these findings. It says that it is unnecessary and inappropriate for me to engage in further explanation of the findings by building into the declaration a list of steps Apple took that constituted this conduct.

33    Second, it says that Epic’s proposed declarations are imprecise.

34    Third, it says that aspects of the declarations stray beyond the pleaded case and are not supported by my findings.

35    As to sub-paragraph 1(b)(iii), it says that there was no pleaded case, and I did not find, that app developers were prevented or hindered from developing or updating iOS apps for distribution through distribution channels other than the App Store.

36    As to sub-paragraph 1(b)(vi), it says that I did not find that Apple contravened s 46 by prohibiting the pre-installation of third-party apps. Further, it says that Apple manufactures the only devices on which iOS runs and has no need to issue a prohibition to itself. On this aspect I agree with Apple and, accordingly, I have not made this aspect of Epic’s proposed declaration.

37    As to sub-paragraphs 1(c)(iv) to (viii), it says that I did not find that there would be any contravention or other unlawfulness in Apple imposing terms of the type described in sub-paragraphs 1(c)(iv) to (viii) in a contract governing distribution via the App Store. To the contrary, I found that Apple’s ban on the distribution of third-party app stores via its own App Store (a “store within a store”) did not have an anti-competitive effect.

38    Further, it says that sub-paragraphs 1(c)(vii) and (viii) suggest that Apple engaged in anti-competitive conduct by including terms in the developer program licence agreement (DPLA) that required app developers to appoint Apple Inc or Apple Pty Ltd as their agent and prohibited refunds.

39    It says that whilst terms along those lines formed part of Epic’s pleaded case, I did not make any explicit finding that those terms formed part of the contravening conduct. Indeed, the finding referred to above suggests such terms would be licit if their aim was to prevent or control the distribution of third-party app stores through the App Store.

40    Fourth, it says that sub-paragraph 1(f) is inappropriate for the additional reason that it does not properly encapsulate the totality of the reasons for the removal of the Fortnite app from the App Store on 13 August 2020 and the termination of Epic’s developer account. Those actions have been found to have been lawful in the proceeding that Epic brought against Apple in the United States.

41    The US District Court for the Northern District of California found that Apple validly terminated Epic’s DPLA following Epic’s breach (Epic Games Inc v Apple Inc, 559 F Supp 3d 898 (ND Cal, 2021) at 1068). That finding was affirmed by the Ninth Circuit (Epic Games Inc v Apple, Inc, 67 F 4th 946 (9th Cir, 2023) at 999). In my reasons I will refer to these decisions as Epic v Apple (US, 2021) and Epic v Apple (US, 2023) respectively. Apple says that Epic was given the opportunity to cure its breach before Apple terminated its DPLA, but Epic chose not to (Epic v Apple (US, 2021) at 940 and 941). So, Apple says that those matters are not properly the subject of declaratory relief in Australia.

42    Apple says that any declaration should be made in the form proposed by Apple. And it says that its proposed declaration is concise, precise, and adequately captures the gist of my findings that identify the contraventions of s 46.

Analysis

43    In my view the need to record the gist of the findings does not require the terms of a declaration to be framed at such a high level of abstraction or generality that they fail to identify the scope and substance of the contravening conduct. Nor does it require a declaration to be so general that it undermines its own utility. I should say that the parties referred to Rural Press Ltd v Australian Competition and Consumer Commission (2003) 216 CLR 53, but I did not find it to be that useful concerning the present question. Moreover, it does not require me to reject Epic’s form of declaration.

44    A declaration of contravention must be sufficiently specific to give content to the matters identified as constituting the contravention and to be informative as to the basis on which I declare that a contravention has occurred. The declaration should accurately reflect the contravening conduct in a concise way. It is proper for a declaration to be framed so that it is informative as to the basis on which I declare that a contravention has occurred and contains appropriate and adequate particulars of how and why the impugned conduct is a contravention of the CCA. The level of specificity at which Epic’s proposed declaration is framed is appropriate.

45    Further, Epic’s declaration does not purport to rehearse my reasoning at large or to summarise every step in the analysis. Given the length and complexity of my reasons, such a task would be neither realistic nor desirable. Rather, in circumstances where I have found that both the architecture of iOS devices and the interlinking of multiple contractual restrictions produce the relevant prohibitory effect, it is reasonable to frame the declaratory relief in a way that reflects those essential facts.

46    Further, there is significant utility in adopting Epic’s more detailed framing.

47    Epic’s central claim throughout the proceeding was that Apple engaged, and continues to engage, in anti-competitive conduct by precluding developers from distributing native iOS apps through any channel other than the App Store, and by requiring that IAP be the sole payment solution for in-app purchases of digital content in iOS apps. That conduct was alleged to consist primarily of the imposition of prohibitive contractual terms in non-negotiable agreements between Apple and developers and the enforcement of those terms. That was the principal controversy on which the trial was conducted. Apple denied that the terms of the DPLA and associated agreements had the alleged anti-competitive purpose or effect. With some exceptions, I rejected Apple’s case and accepted Epic’s.

48    Apple purposefully foreclosed every rival channel for iOS app distribution and installed itself as the sole gateway to iOS users, whilst its IAP tie and anti-steering provision unlawfully entrenched and sustained its immensely profitable monopoly over in-app payments for digital content. Apple achieved this outcome through the architecture of iOS devices, coupled with its imposition and enforcement of a web of interlocking contractual restrictions and prohibitions.

49    Given both the gravity of the contravening conduct and the deliberate way in which it was implemented, it is appropriate to adopt Epic’s proposed declaration, which sets out the substance of Apple’s conduct and the key mechanisms by which it was implemented, so as to record my disapproval of the contravention and to define and publicise the type of conduct that constitutes a contravention in circumstances of this kind.

50    Epic’s declaration also has practical utility in clearly identifying the foundation for the consequential relief it seeks. It underpins the injunctive relief sought under s 80.

51    Now Apple contends that Epic’s proposed declaration is imprecise. But I agree with Epic that its proposed language is appropriate given that multiple actions and restrictive provisions combined to produce Apple’s contravening conduct.

52    Apple contends that aspects of Epic’s proposed declaration stray beyond the pleaded case and my dispositive findings.

53    But as to proposed sub-paragraph 1(b)(iii), the necessary updating of iOS apps forms part of the distribution services relating to the apps. Apple imposed various interlinked restrictions on developers that prevented developers distributing or updating apps other than through Apple. But if sub-paragraph 1(b)(iii) were to be omitted, that refinement would not disturb the substance of the contravention found or the foundation for the consequential relief Epic seeks.

54    As to proposed sub-paragraphs 1(c)(iv) to (viii), I described the “iOS restrictive terms” as a package of measures which together constituted the conduct that contravened s 46. In that context, proposed sub-paragraphs 1(c)(iv) to (viii) do not postulate a series of discrete, free-standing contraventions; they particularise the means by which the contravening conduct was carried on.

55    Proposed sub-paragraph 1(c)(iv) does not seek to relitigate the “store-within-a-store” case that I rejected. Those restrictions were pleaded and found to be part of the iOS restrictive terms that fortified Apple’s prohibition on rival iOS app distribution channels. They are therefore a proper component of a declaration that describes the conduct which I held had the purpose, effect or likely effect of substantially lessening competition in the iOS app distribution market.

56    Proposed sub-paragraphs 1(c)(v) to (viii) are supported by my findings. I explained the meaning and scope of the phrase “iOS app distribution conduct”, which included the imposition and enforcement of “the restrictive terms”. The meaning and scope of the restrictive terms was dealt with in my reasons and they include the terms identified in proposed sub-paragraphs 1(c)(v) to (viii). Further, in respect of proposed sub-paragraphs 1(c)(vi) to (viii), I found that each of the prohibitions that is the subject of those proposed orders had no cogent connection with any of Apple’s purported justifications and were for an anti–competitive purpose.

57    As to proposed sub-paragraphs 1(c)(vii) and (viii) in particular, it is possible that in some other contractual context that does not erect and entrench a monopoly distribution channel, terms requiring a platform operator to be appointed as agent or to control refunds might be unobjectionable, but that is not this case. In the setting of Apple’s closed iOS ecosystem, those provisions are properly understood as elements of the contravening conduct. Proposed sub-paragraphs 1(c)(vii) and (viii) do no more than record that reality by identifying specific terms of the DPLA and related agreements which, in combination with the other iOS restrictive terms, contributed to the substantial lessening of competition found by me.

58    Further, Apple contends that proposed sub-paragraph 1(f) of Epic’s proposed declarations is inappropriate because it does not reflect the totality of the reasons for the removal of Fortnite and the termination of Epic’s developer account, and because those steps have been held lawful in US proceedings. But proposed sub-paragraph 1(f) does not purport to state the totality of the reasons for those steps. It records that Apple enforced the impugned contractual terms by refusing to allow Epic Direct Pay being Epic’s in-app payment solution, removing Fortnite and terminating Epic’s developer account.

59    Declaratory relief may properly identify those acts insofar as they constitute enforcement of the contravening conduct that has been found to be unlawful under Australian law, irrespective of any findings in US proceedings.

60    Further, it is not necessary to confine the declaration by reference to Australian users. But I do propose to impose various limits on the prohibitory and mandatory injunctions which I will discuss in detail later.

61    Further, a theme of Apple’s complaints about Epic’s relief is that the orders regulate conduct beyond that pleaded and found to contravene the CCA. But my remedial power is not confined to prohibiting the precise conduct pleaded and found to constitute the contravention. I will discuss this in more detail later.

62    In summary, Epic’s proposed declaration is clear on its face. The relevant conduct engaged in by Apple is defined with precision.

Proposed order 2 — declaration that contractual terms void

63    Sections 87(1) and (2) provide:

(1)    Without limiting the generality of section 80, where, in a proceeding instituted under this Part, or for an offence against section 45AF or 45AG or subsection 56BN(1) or 56BZI(1), the Court finds that a person who is a party to the proceeding has suffered, or is likely to suffer, loss or damage by conduct of another person that was engaged in (whether before or after the commencement of this subsection) in contravention of a provision of Part IV, Division 2 of Part IVB, or Part IVBA or IVE, or of section 55B, subsection 56BO(1) or 56BU(1), section 56BZA, 56BZB or 56BZC, subsection 56BZD(1), section 56BZJ, 60C or 60K, a civil penalty provision of a gas market instrument or a civil penalty provision of the consumer data rules, the Court may, whether or not it grants an injunction under section 80 or makes an order under section 82, 86C, 86D or 86E, make such order or orders as it thinks appropriate against the person who engaged in the conduct or a person who was involved in the contravention (including all or any of the orders mentioned in subsection (2) of this section) if the Court considers that the order or orders concerned will compensate the first‑mentioned person in whole or in part for the loss or damage or will prevent or reduce the loss or damage.

…

(2)    The orders referred to in subsections (1) and (1A) are:

(a)    an order declaring the whole or any part of a contract made between the person who suffered, or is likely to suffer, the loss or damage and the person who engaged in the conduct or a person who was involved in the contravention constituted by the conduct, or of a collateral arrangement relating to such a contract, to be void and, if the Court thinks fit, to have been void ab initio or at all times on and after such date before the date on which the order is made as is specified in the order;

(b)    an order varying such a contract or arrangement in such manner as is specified in the order and, if the Court thinks fit, declaring the contract or arrangement to have had effect as so varied on and after such date before the date on which the order is made as is so specified;

(ba)    an order refusing to enforce any or all of the provisions of such a contract;

…

(f)    an order directing the person who engaged in the conduct or a person who was involved in the contravention constituted by the conduct, at his or her own expense, to supply specified services to the person who suffered, or is likely to suffer, the loss or damage;

…

64    Epic seeks a declaration pursuant to s 87(1) that certain contractual terms contained in any contracts between Epic and Apple, and any substantially similar term, are void and of no effect, being terms whose imposition and enforcement formed part of Apple’s contravening conduct.

65    Section 87(1) empowers the Court to make any order that it thinks appropriate, including any of the orders mentioned in s 87(2), if it considers that the order will, relevantly, compensate a person for, or prevent or reduce, the loss or damage that a person has suffered, or is likely to suffer, by conduct found to be in contravention of a provision of Part IV.

66    The relevant principles are not in doubt.

67    First, the references to loss or damage in s 87 should not be given any narrow meaning. They encompass any form of economic loss due to prejudice or disadvantage occasioned by a respondent’s unlawful conduct.

68    Second, to establish that an applicant is likely to suffer loss or damage, the applicant must establish at least a real chance or possibility of it being suffered.

69    Third, for the actual or potential loss or damage to be suffered “by” the contravening conduct, it is sufficient for an applicant to demonstrate that the contravening conduct was a cause rather than the cause of the loss or damage.

70    Now Epic says that it has suffered and is likely to suffer economic loss by Apple’s conduct in contravention of s 46. It says that but for Apple’s anti-competitive conduct in the distribution and payments markets, Epic could and would have competed in those markets.

71    Epic says that its actual and potential loss flows directly from Apple’s imposition and enforcement of the contractual terms identified in the declarations in sub-paragraphs 1(c) and (e) by which Apple: (a) prohibited developers including Epic from distributing iOS apps otherwise than via the App Store and prevented them from developing apps capable of distribution via alternative distribution channels; (b) prohibited developers including Epic from using a payment method other than IAP for in-app purchases of digital content; and (c) prohibited developers including Epic from directing users from within iOS apps to alternative payment methods.

72    Moreover, Epic says that by imposing and enforcing the offending terms on Epic, Apple foreclosed Epic’s ability to compete in iOS app distribution and to benefit from competition in in-app payment solutions for its own apps. It says that that loss was compounded when Apple removed Fortnite from the App Store and terminated Epic’s developer account. It says that Apple has not reinstated Epic’s developer account and Epic’s apps are still excluded from the App Store.

73    Epic says that those matters are sufficient to satisfy the requirement that Epic has suffered, and is likely to suffer, loss or damage by Apple’s contravening conduct, enlivening the Court’s power under s 87.

74    Further, Epic says that it is necessary to make the declaration of invalidity sought under s 87(2)(a), removing contractual obstacles to Epic distributing and updating iOS apps via alternative distribution channels, to developing such apps, and to offering Epic Direct Pay or any other alternative payment method for in–app purchases. Epic says that that relief would also facilitate readmission of Epic’s apps to the App Store which is dealt with in its proposed order 3 (order 2 as modified and made by me). It says that Apple could not rely on any alleged breach of the unlawful terms to refuse to deal.

75    Epic says that removing those obstacles and facilitating readmission will at least reduce the loss Epic would likely suffer if the relevant contractual terms were to remain in effect.

76    Epic says that the declaration sought is confined to Epic’s legal rights vis-à-vis Apple. It does not determine the rights of non-parties.

77    Epic says that it has identified loss or damage suffered, or likely to be suffered, by Apple’s contravening conduct which can be grouped under various heads. First, there is the loss of commercial opportunities, including the opportunity to compete and earn revenue in the iOS app distribution market and to distribute the Epic Games Store (EGS) on iOS devices. Second, there is the loss of the opportunity to benefit from lower commissions for Epic’s apps. Third, there is the loss of revenue following the removal of Fortnite and other Epic apps from the App Store.

78    Epic says that in that context, Apple’s narrow focus on the current profitability of the EGS mischaracterises the relevant inquiry. The question for s 87 is whether, in the counterfactual where Apple did not engage in the iOS app distribution conduct and iOS payment solutions conduct, Epic would have obtained, or been likely to obtain, a greater benefit or avoided a detriment. The current profitability of the EGS on other platforms is beside the point. Epic says that what matters is the nature of the opportunities in the iOS app distribution market that Epic was prevented from pursuing and the potential benefits thereby lost. It says that Epic lost benefits of that kind, including benefits flowing from increased user engagement with the Epic ecosystem and additional revenue from in-app purchases within Fortnite.

79    Further, Epic says that I treated Apple’s enforcement of its restrictive terms against Epic, including the removal of Fortnite and the termination of Epic’s developer account, as a paradigm example of the contravening conduct. It says that loss flowing from those steps is therefore loss suffered “by” the contraventions for the purposes of s 87. And it is sufficient that the contravening conduct was a cause of the relevant loss. It need not be shown to be the sole cause.

80    Further, Epic says that the availability of injunctive relief under s 80 does not negate a real and ongoing risk of economic loss or prejudice for the purposes of the “likely to suffer” limb of s 87. It says that unless the impugned contractual terms are declared void, Apple retains the ability to rely on them in its dealings with Epic. It says that that continuing exposure is itself a source of commercial prejudice and disadvantage and constitutes a sufficient risk of future loss or damage to enliven s 87, in addition to the past loss already identified.

81    Further, Epic says that there is no reason in principle why relief under s 87 cannot be framed in ambulatory terms so as to void identified unlawful terms in any contracts between Epic and Apple in which they appear.

82    Further, Epic says that an order in the terms sought is apt to prevent or reduce loss or damage because, unless the impugned terms are declared void, Apple remains free to invoke Epic’s alleged breach of those terms as a basis for maintaining the termination of, or refusing to reinstate, Epic’s developer account. Epic says that this would perpetuate the exclusion that I identified at [4130] to [4132], where I said:

On 28 August 2020, Apple terminated Epic’s 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 its Team ID ‘84 Account were removed from the App Store, including in Australia. This meant that new iOS device users could not download those apps and existing iOS users of those apps could no longer update their iOS versions of those apps.

In August and September 2021, more than one year after the termination, Epic made several requests for reinstatement of its Team ID ‘84 Account. For some time, Apple had not reinstated Epic’s account, despite Epic’s commitment to complying with the App Store review guidelines.

83    Further, Epic says that declaring the terms void removes any anti–competitive contractual basis for any future refusal to deal and reduces the real risk of continuing economic prejudice to Epic.

84    Further, Epic says that its s 87 relief is to facilitate the readmission of Epic’s apps by removing an illegitimate contractual basis for exclusion.

85    Further, Epic says that clause 6.9 of the DPLA and the stipulated “sole discretion” in the prefatory words to that clause as to which apps are distributed via the App Store does not answer that point. Epic says that any such discretion must be exercised consistently with the CCA and cannot lawfully be exercised by reference to contractual terms that I have declared void under s 87 because they form part of the contravening conduct.

86    Further, Epic says that s 87(2)(a) is not limited to cases where the impugned provision is already invalid at general law. It says that s 87(2)(a) empowers me to declare a contractual provision void where that is an appropriate means of compensating a person, or of preventing or reducing loss or damage resulting or likely to result from a contravention, even if the provision would otherwise be valid at general law.

87    Further, Epic says that declaring the impugned provisions void as between Epic and Apple is an orthodox exercise of the power in s 87(2)(a) to prevent or reduce loss arising from that contravening conduct. It says that the fact that the same provisions might also operate in other jurisdictions, and have been held lawful under US antitrust law, does not immunise them from being set aside as a matter of Australian law for the purpose of addressing Australian market contraventions.

88    Further, Epic says that proposed order 2 is not to be read only as a retrospective declaration aimed at an historical situation. Epic says that s 87(1) confers a broad power to make “such order or orders as [the Court] thinks appropriate” if the Court considers the order will compensate for, or prevent or reduce, the loss or damage, or likely loss or damage. It expressly contemplates orders “including” those in s 87(2). Epic says that the remedial power is not confined to the particular forms in s 87(2) and there is no textual basis to read s 87 as incapable of supporting an ambulatory order that bites on future contracts, provided the s 87(1) criteria are satisfied.

Analysis

89    Now Epic by proposed order 2 seeks an exercise of the power in s 87(1) to make an order of the kind contemplated by s 87(2)(a). But I agree with Apple that there are three requirements for the exercise of that power that are not satisfied here.

90    First, an order under s 87(1) can only be made if I find that a party has suffered, or is likely to suffer, loss or damage by the contravening conduct.

91    Second, orders can be made under s 87(1) only in so far as those orders will compensate or will prevent or reduce the loss or damage that is identified. In Marks v GIO Australia Holdings Limited (1998) 196 CLR 494 it was said by McHugh, Hayne and Callinan JJ at [43]:

If loss or damage is shown to have been suffered or to be likely to be suffered, orders of the kind prescribed by s 87 may be made. Proof of loss or damage (actual or potential) is therefore the gateway to the s 87 remedies. But the identification of loss or damage is important in the operation of s 87 not only for this reason but also because the power to make orders under s 87 is limited to making orders “if the Court considers that the order or orders concerned will compensate … in whole or in part for the loss or damage or will prevent or reduce the loss or damage … ” (s 87(1) and (1A)). That is, the Court can make orders under s 87 only in so far as those orders will compensate (or will prevent or reduce) the loss or damage that is identified.

92    Third, the power under s 87(2)(a) does not convey a broad discretion to declare provisions of a contract void. The power is usually exercised where a contractual provision is void because of the application of a provision of the CCA or some other legal principle.

93    Now in Tenji v Henneberry & Associates Pty Ltd (2000) 98 FCR 324, French J found that the breadth of the power under s 87(2)(a) was broader than that suggested in Webb Distributors (Aust.) Pty Ltd v State of Victoria (1993) 179 CLR 15 at 37 and that orders under s 87(2)(a) can have an operational rather than declaratory role. And his Honour expressed the view that the width of operation attributed to s 87 in Marks represented the appropriate position. But I agree with Apple that in any event nothing in Tenji expressly indicates that the power in s 87(2)(a) extends to declaring void individual provisions of a contract that do not form part of the contravening conduct. I should say for completeness here that the considerable breadth that I have given to s 80, which I will discuss in the next section, has no necessary tension with what I have said here concerning s 87(2)(a). Section 80 is a different power and the width of the scope of that power is justified in part by its public purpose together with what is said or necessarily implied in ss 80(4) and (5).

94    Further, French J’s observation in Tenji at [14] that s 87(2)(a) can have an operational rather than declaratory role was directed to an order declaring that an existing contract was void ab initio on certain terms rather than contemplating that an order could be made declaring a contract not yet entered into to be void.

95    Further, I have not found that Epic has suffered, or is likely to suffer, loss or damage as a result of Apple’s contraventions of s 46. Now Epic says that such a finding follows from my findings that but for the contravening conduct, Epic would have competed in the distribution market and the payments market.

96    Now I found that in the counterfactual there is a real commercial likelihood that the EGS would launch on iOS, and in those circumstances, Epic would offer Epic Direct Payment to developers and consumers using the EGS. But I did not find that Epic’s launch of the EGS would have been profitable. To the contrary, I found that the EGS business has operated at a loss since 2018 and will continue to do so until 2027 at least.

97    Now Epic says that its loss was compounded when Apple removed Fortnite from the App Store and terminated Epic’s developer account. But the US courts have found that Apple acted lawfully in removing the Fortnite app from the App Store and terminating Epic’s developer account, following Epic’s breach of its DPLA and after Epic chose not to remedy the breach. Moreover, I have not separately found that Apple acted unlawfully in taking those steps. Further, as Apple points out, such a finding would have been contrary to the findings of the US courts, by which the parties are bound. So, it cannot be said that any loss that Epic suffered as a result of Fortnite being removed from the App Store is a loss occasioned by the contravening conduct.

98    Epic also asserts that Apple’s contravening conduct foreclosed Epic’s ability to benefit from competition in in-app payment solutions for its own apps, but no particulars of loss to that effect were given by Epic in its case against Apple. Further, I have not found that Epic suffered loss or damage by these means, for instance, by paying higher commissions for in-app purchases of digital content than it would have done in a relevant counterfactual.

99    Further, Epic’s proposed order 2 does not identify any specific contract to which it would apply. As drafted, it would apply to “any contracts between the Applicants and the First Respondent”.

100    Now Epic’s proposed order would encompass the DPLA between Epic and Apple that Apple terminated on 28 August 2020. But as I have said, the US courts have found that termination to be valid. I agree with Apple that an order retrospectively declaring a provision of that contract to have been void during the period from 6 November 2017 until 28 August 2020, cannot properly be described as an order that would compensate, prevent or reduce any loss, and so cannot be made under s 87. As Apple says, Epic does not explain how the order could be said to compensate, prevent or reduce any loss in these circumstances. Further, Epic says that Epic Games Sweden AB now has a developer account, but Epic Games Sweden AB is not a party to this proceeding so Epic’s proposed relief would not extend to its DPLA.

101    Further, I agree with Apple that an order in the form that Epic proposes would not be limited to declaring void terms that contravene the CCA or are otherwise unlawful. The order would regulate the relationship between the parties globally, including by declaring void terms that the US courts have found to be valid under US antitrust law.

102    Further, Epic says that the reference to “any contracts” in its proposed orders was intended to capture existing contracts and any future contracts entered into after the date of the order. But so framed and as Apple put it, the order has an ambulatory or springing effect that will operate to automatically void the terms of any future contract that may be entered into between Epic and Apple anywhere in the world. But to suggest that such a forward looking order could be made under s 87 is problematic.

103    First, the power to make orders under s 87 is not at large. In my view s 87(2) does not contemplate an order voiding the terms of a future contract, and even if it did this is not such a case as would warrant such an order.

104    Second, the proposed order would void terms that would not necessarily have any anticompetitive purpose or effect, on their own, if included in any future agreement. I agree with Apple that to automatically void any such term when included in any future agreement between Epic and Apple would accordingly be an unwarranted overreach that goes beyond my findings.

105    For the foregoing reasons, I will not grant any relief under s 87.

106    Let me now turn to the mandatory and prohibitory injunctions that Epic seeks. But before getting into the detail of the particular orders sought, it is necessary for me to address some questions of principle concerning s 80, which include questions dealing with the scope of s 80, any required geographical nexus and the effect of any orders on intellectual property rights.

Injunctive relief: competition in the relevant markets

107    Sections 80(1) and (3) provide:

(1)    Subject to subsections (1A), (1AAA) and (1B), where, on the application of the Commission or any other person, the Court is satisfied that a person has engaged, or is proposing to engage, in conduct that constitutes or would constitute:

(a)    a contravention of any of the following provisions:

(i)    a provision of Part IV;

…

(b)    attempting to contravene such a provision; or

(c)    aiding, abetting, counselling or procuring a person to contravene such a provision; or

(d)    inducing, or attempting to induce, whether by threats, promises or otherwise, a person to contravene such a provision; or

(e)    being in any way, directly or indirectly, knowingly concerned in, or party to, the contravention by a person of such a provision; or

(f)    conspiring with others to contravene such a provision;

the Court may grant an injunction in such terms as the Court determines to be appropriate.

…

(3)    The Court may rescind or vary an injunction granted under subsection (1) or (2).

108    Let me deal with some general points concerning s 80 before proceeding further.

109    The first and obvious point to make is that there is a distinction to be made about the ambit of the statutory power under s 80 on the one hand, and the exercise of that statutory power on the other hand. Apple at times in its submissions wrongly conflated this distinction.

110    The second and general point to make concerns whether s 80(1) should be construed so that the Court is only empowered to make an order restraining or dealing with the specific contravening conduct as so found or similar conduct. In other words, s 80(1) does not empower me to restrain conduct in the future that was not found to be unlawful or within a like class. Now as to this aspect a number of points can be made.

111    First, the text of s 80(1) and the concluding words “the Court may grant an injunction in such terms as the Court determines to be appropriate” do not explicitly or implicitly indicate any such limitation.

112    Second, to say the least the very text of ss 80(4)(b) and (5)(b) points against any such limitation.

113    Third, if by reason of any contravening conduct economic harm has been caused, there is no good reason why either a prohibitory or mandatory injunction must be tied in its terms to preventing a repetition of the precise prior infringing conduct or like conduct. If economic harm has been caused to the applicant or more generally participants in the relevant market, assuming for the moment any necessary geographic nexus, by the contravening conduct, there is no good reason why any mandatory or prohibitory injunction cannot be made or tailored to addressing or ameliorating such economic harm that has been caused by the contravening conduct. In such circumstances there is clearly a nexus between the injunction and the contravening conduct in the sense that the injunction is dealing with the effect or likely effect of the contravening conduct. So, the injunction is dealing with the effect of what has been caused by the infringing conduct.

114    Fourth, if one considers for a moment the text of s 80(1), there is nothing that would suggest that an order could not be made, whether mandatory or prohibitory in its terms, dealing with the harmful economic effects of prior contravening conduct, including ordering the infringer to do something or not do something even if otherwise lawful. Such an order in terms of the power to make it, as distinct from whether or not the order should be made, is consonant with the text, context and purpose of s 80 including the public purpose of that provision.

115    The third point concerns the question of territorial nexus or the geographic reach of s 80 which I will address in a separate section of my reasons.

116    Let me descend into more detail concerning the relevant principles.

117    First, once a contravention or proposed contravention has been established, the Court’s discretion in formulating the terms in which a final injunction may be granted under s 80(1) is as wide as the statutory phrase “as the Court determines to be appropriate”. And that phrase has to be construed and applied conformably with s 2 which provides:

The object of this Act is to enhance the welfare of Australians through the promotion of competition and fair trading and provision for consumer protection.

118    Second, s 80 exists to enforce the public interest in upholding the legislative enactments embedded in the various prohibitions under Part IV. As such, s 80 should be construed so as to give the fullest relief which a fair reading of its language permits.

119    Third, ss 80(4) and (5) provide:

(4)    The power of the Court to grant an injunction restraining a person from engaging in conduct may be exercised:

(a)    whether or not it appears to the Court that the person intends to engage again, or to continue to engage, in conduct of that kind;

(b)    whether or not the person has previously engaged in conduct of that kind; and

(c)    whether or not there is an imminent danger of substantial damage to any person if the first‑mentioned person engages in conduct of that kind.

(5)    The power of the Court to grant an injunction requiring a person to do an act or thing may be exercised:

(a)    whether or not it appears to the Court that the person intends to refuse or fail again, or to continue to refuse or fail, to do that act or thing;

(b)    whether or not the person has previously refused or failed to do that act or thing; and

(c)    whether or not there is an imminent danger of substantial damage to any person if the first‑mentioned person refuses or fails to do that act or thing.

120    Broadly, ss 80(4) and (5) empower the Court to restrain or require the performance of certain conduct by a person:

(a)    in the case of s 80(4)(a) or s 80(5)(a), whether or not that person intends to engage or not engage in that conduct;

(b)    in the case of s 80(4)(b) or s 80(5)(b), whether or not that person previously engaged or did not engage in that conduct; or

(c)    in the case of s 80(4)(c) or s 80(5)(c), whether or not there is an imminent danger of substantial damage if that person does or does not engage in that conduct.

121    The new forms of ss 80(4) and (5) were inserted in 1983 to widen the Court’s power to grant injunctive relief, which was previously limited to restraining a contravention of the then TPA and now the CCA. Parliament’s enactment of the new forms of ss 80(4) and (5) made clear that s 80 permits the grant of both negative and mandatory injunctions over a wide range of conduct.

122    The explanatory memorandum to the Statute Law (Miscellaneous Provisions) Bill (No 1) 1983 (Cth) said at 112:

Section 80 provides for the granting of an injunction to restrain a person from engaging in certain conduct.

Sub-section 80(1) is repealed and replaced by new sub-section 80(1) which provides that, where on the application of the Minister, the Trade Practices Commission or any other person the Court is satisfied that a person has engaged in, or proposes to engage in, conduct that constitutes or would constitute or be in certain ways related to a contravention of a provision of Parts IV or V of the Act the Court may grant an injunction in such terms as it determines to be appropriate having regard to all relevant matters. This sub-section is subject to sub-section 80(1A) (which prevents a person other than the Minister or the Trade Practices Commission seeking an injunction in major cases)

The effect of the amendment is to widen the Court’s power to grant injunctive relief which is at present generally limited to restraining a contravention of the Act. The amended provision will enable the Court to grant more effective injunctive relief, including mandatory injunctions and other injunctive relief.

Sub-sections 80(4) and (5) are repealed and replaced. Proposed sub-section 80(4) substantially reproduces the provisions of the present sub-sections 80(4) and (5), subject to amendments to reflect the enhanced power of the Court under new sub-section 80(1).

Proposed new sub-section 80(5) makes like provision with respect to mandatory injunctions as new sub-section 80(4) makes with respect to injunctions restraining conduct.

(my emphasis)

123    Fourth, the power should be read liberally to give effect to the relevant statutory purpose, without making implications or imposing limitations not found in the express words. So, the provision “means what it says” (Truth About Motorways Pty. Ltd. v Macquarie Infrastructure Investment Management Ltd (2000) 200 CLR 591 at [13] per Gleeson CJ and McHugh J).

124    Fifth, the enhanced power is however confined by the need for the Court to be satisfied that the terms of an injunction are “appropriate”.

125    The grant of power in s 80(1) is not confined by traditional equitable principles, but the discretion is not at large. There must be a nexus between the contravening conduct and the conduct that is the subject of the injunction. Further, the injunction should not prohibit conduct falling outside the boundaries drawn by s 80.

126    As was established in ICI Australia Operations Pty Ltd v Trade Practices Commission (1992) 38 FCR 248, there must be a sufficient nexus between the contravening conduct that enlivens the s 80 power and the conduct that is the subject of the injunction made in response to the contravening conduct. The terms of an injunction will not be appropriate if, on its face, it operates upon a range of conduct some of which does, but some of which does not, have the relationship with the found contravention.

127    Gummow J in ICI said (at 267):

Finally, there are the provisions of s 80(4) and (5). They provide that the power of the court to grant prohibitory and mandatory injunctions may be exercised in circumstances where, under the general law, there ordinarily would be a good answer to an application for injunctive relief. There may have been no previous infraction of the law, there may be no threat of any infraction or further infraction of the law, and there may be no imminent danger of substantial damage by the act or omission of the defendant.

…

Section 80(1) confers upon the court the power to grant an injunction where it is satisfied that a person has engaged or is proposing to engage in conduct that constitutes or would constitute conduct of the description in pars (a)-(f). The power of the court to grant an injunction is controlled by the words “in such terms as the Court determines to be appropriate”.

Thus, the terms of the injunction will not be “appropriate” if, on its face, it operates upon a range of conduct some of which does, but some of which does not, have the relationship required by s 80 with contravention of the Act. The injunction should not prohibit conduct falling outside the boundaries drawn by s 80: see Thomson Australian Holdings Pty Ltd v Trade Practices Commission (1981) 148 CLR 150 at 161. The same limitation applies to mandatory injunctive relief. It is, in my view, no support for the grant of an injunction which, from the outset, has an operation outside the boundaries of s 80, to say that it is open for the party enjoined to apply under s 80(3) to vary the injunction so as to bring its operation wholly within proper limits. The party in question should not be placed under any such obligation in the first place.

The succeeding subsections, in particular subss (4) and (5), take subs (1) further by indicating that the power may be exercised whether or not there are present certain circumstances which I have described as ordinarily considered essential by courts of equity exercising their inherent or traditional jurisdiction. But that is not to say that the matters referred to in s 80(4) and (5) are irrelevant to the consideration by the court of the question of whether an injunction is to be granted, and if so, to the determination of the appropriate terms of such an injunction.

128    Now the fact that a person to be restrained has not engaged and does not intend to engage in conduct of the kind to be enjoined is not irrelevant to the question of whether relief under s 80 is appropriate. But ss 80(4) and (5) make clear that the absence of any one or more of these elements is not fatal to the grant of an injunction under s 80 as a matter of power.

129    Now I agree with the parties that s 80 has various limits that it is well to identify.

130    The first limit is that the power is confined by reference to the subject-matter, scope and purpose of s 80. Moreover, s 80 requires a relationship between the contraventions as found and the terms of the injunction; see also Australian Competition and Consumer Commission v Pacific National Pty Ltd (2020) 277 FCR 49 where Middleton and O’Bryan JJ at [343] acknowledged that s 80 had been amended in 1983 and that the effect of those amendments had been to broaden its scope and at [344] cited with approval Merkel J’s judgment in Australian Competition and Consumer Commission v Z-Tek Computer Pty Ltd (1997) 78 FCR 197.

131    In Australian Competition and Consumer Commission v Real Estate Institute of Western Australia Inc (1999) 161 ALR 79, French J explained (at [22] and [23]):

Significant elements of the proposed orders have the form of mandatory injunctions. By virtue of s 80(5) the power of the court to grant an injunction requiring a person to do an act or thing may be exercised whether or not it appears to the court that the person intends to refuse or fail to do that act or thing and whether or not the person had previously refused or failed to do that act or thing. The court’s power to grant such injunctions is not conditioned upon it being demonstrated that the person the subject of the order has contravened the Act in a way that is specifically addressed by the order. Nevertheless, the power is conditioned upon there having been a contravention or participation in a contravention in one of the various ways set out in s 80(1) and the terms of the injunction must be such as “the Court determines to be appropriate”. The latter terminology requires an evaluative judgment in forming the terms of the injunction to be granted. To some extent questions of power and discretion merge under the rubric of appropriateness.

Merkel J has said in Australian Competition and Consumer Commission v Z- Tek Computer Pty Ltd (1997) 148 ALR 339 at 343 that “… there must be a nexus between the conduct alleged or found to constitute the relevant contraventions and the injunctions granted”. See also Australian Competition and Consumer Commission v Office Link (Aust) Pty Ltd (1997) ATPR 41–598. Such a requirement is derived from the evident policy of the Act and the grounding of the power under s 80 upon the fact of a contravention. The question whether there is a sufficient nexus between the order sought and the contravention alleged involves an evaluative judgment. At one level the orders sought may be so remote from the contravention alleged that the question is readily resolved as one of power. Thus an injunction directing implementation of a compliance program covering all of the provisions of Pt V in answer to an alleged contravention of Pt IV of the Act might well be thought so remote from the contravention as to be beyond the purpose of s 80 and thus beyond its power. A fortiori such an order might be thought inappropriate even if strictly within power. I respectfully agree with his Honour in relation to that aspect of his approach in the Z-Tek case.

132    French J observed that remoteness from the contravention may also a fortiori be reason to refuse to exercise the discretion to grant relief even if strictly within power.

133    The second limit is that s 80 must be read and applied within the constitutional limits of federal judicial power under Chapter III of the Constitution, which is limited to the resolution of “matters”, in the sense of justiciable controversies.

134    The third limit to the power in s 80 and any exercise of the discretion is that injunctions should be granted in clear and unambiguous terms. Of course injunctive relief should not be so precisely expressed as to encourage evasion of the spirit but not the letter of the injunction.

135    Let me return to the ICI case. There were three issues on appeal in that case. First, whether it was correct to construe s 80 as a discretion to refuse to grant an injunction in an appropriate case rather than as a discretionary power to grant an injunction. Second, whether the exercise of the discretion to grant an injunction had miscarried. Third, whether the form of the injunction was inappropriate.

136    In the course of addressing the first issue, Lockhart J said about the scope of the power under s 80 (at 256):

... There is no doubt that subs (4) and (5) depart from the general law in permitting injunctions to be granted in the circumstances therein mentioned; but in my opinion they do not suggest legislative nihilism.

In my opinion subs (4) and (5) are designed to ensure that once the condition precedent to the exercise of injunctive relief has been satisfied (ie contraventions or proposed contraventions of Pt IV or V of the Act), the court should be given the widest possible injunctive powers, devoid of traditional constraints, though the power must be exercised judicially and sensibly.

137    Now Apple says that the observation that s 80 confers the widest possible injunctive powers, subject to being exercised judicially and sensibly, did not mean that the Court could restrain any conduct at all, even lawful conduct, so long as there was some connection to contravening conduct that enlivened the power.

138    And Apple says that no different position emerges from Truth About Motorways. In that case, Gummow J said (at [79] and [80]):

Section 52 thus is an exercise by the Parliament of its powers to create new norms of conduct and require their observance by specified sections of the community. The legislature may also, in exercise of its powers, adapt remedies known at general law or modify them or create new remedies. It may do so not only to prevent or to compensate for injury done by violation of the new federal norm of conduct, but to enforce or induce compliance with the federal law. An example of the latter was the treble damages provision of s 11 of the Australian Industries Preservation Act 1906 (Cth). The validity of s 11 was upheld in Redfern v Dunlop Rubber Australia Ltd.

Part VI (which contains s 80) and Pt XII (which contains s 163A) make provisions which effect the attainment of one or more of those ends. In many cases, the remedy sought under s 80 for a prohibitory injunction would have the character of enforcing present compliance or inducing future compliance with the norm of conduct imposed by s 52, and a declaration would provide consequential relief. In the present case, the mandatory injunction sought would be apt to counterbalance the injury to the public interest allegedly sustained by the publication of the Statement.

[footnotes omitted]

139    Apple made the following points. The sentence “[i]n the present case, the mandatory injunction sought would be apt to counterbalance the injury to the public interest allegedly sustained by the publication of the Statement” was confined to the facts of that case. Truth About Motorways concerned standing. The underlying conduct was alleged misleading conduct relating to the publication of a prospectus. Until the relevant misrepresentation had been dispelled through a corrective statement, there was a continuing misleading representation. The mandatory injunction to which Gummow J therefore referred (at [80]) was directed to preventing the continuation of the contravening conduct. So, Apple says that the observation was not directed to some notion of redressing injury to the public at large, but rather was consistent with the notion that s 80 is confined to restraining or preventing conduct found to be prohibited. But in my view Apple reads Gummow J’s observations too narrowly. Let me say something more on the public interest question.

140    Section 80 is a public interest provision that empowers the Court to grant relief where it is “appropriate” to the public interests to which Pt IV is directed, being to protect and to promote competition. And this public interest character remains the same whether s 80 is invoked by the ACCC or a private litigant. Provided the orders remain appropriate to the public interest purpose of the provision, a private litigant may also and incidentally obtain a benefit. The text and context of s 80 does not suggest that it has any different reach, character or purpose when the applicant for relief is a private litigant rather than the ACCC. And part of what informs the broader public interest character of the injunction power is that relief under s 80 can be sought on the application of the ACCC or any other person.

141    The prohibitions in Part IV are directed at enhancing the welfare of Australians through the protection and promotion of competition (see s 2). It is that public interest to which any relief under s 80 is to be directed in the present case. The protection of competition in Australian mobile app marketplaces is of significant public benefit. Australian consumers rely extensively on mobile apps to provide a range of goods and services in their daily lives. Competition in digital app marketplaces improves the welfare of Australians by increasing choice and efficiency for consumers.

142    Sometimes that public interest purpose may be served by a narrowly framed negative injunction prohibiting the commission of the specific conduct found to have contravened the CCA. But where the contravening conduct has been implemented through a web of interlocking contractual and technical measures that foreclose markets, it may be both necessary and appropriate to grant an order that remedies the contravening conduct and its effects by prising open the market to competition, and which prevents the recurrence of the same substantial lessening of competition by different means.

143    Now one of the ways in which s 80 can be seen to protect broader public interests is that it is not limited to simply preventing a repetition of the particular contravening conduct. This sets the power apart from traditional equitable injunctive relief directed to the protection of private interests.

144    As Lockhart J explained in ICI (at 256 and 257):

Subsections (4) and (5) of s 80 are novel because they empower the court to grant injunctive relief notwithstanding that the defendant has not previously engaged in the prohibited conduct or does not intend to engage in it again or to continue to engage in it or there is no imminent danger of substantial damage. Yet these are the traditional requirements for equitable injunctive relief.

These subsections substantially depart from the traditional basis for the grant of injunctions in Chancery …

…

Injunctions are traditionally employed to restrain repetition of conduct. A statutory provision that enables an injunction to be granted to prevent the commission of conduct that has never been done before and is not likely to be done again is a statutory enlargement of traditional equitable principles. But this is because traditional doctrine surrounding the grant of injunctive relief was developed primarily for the protection of private proprietary rights. Public interest injunctions are different. Parts IV and V of the Act involve matters of high public policy. … These are legislative enactments of matters vital to the presence of free competition and enterprise and a just society. This does not mean that the traditional equitable doctrines are irrelevant. For example, it must be relevant to consider questions of repetition of conduct or whether it has ever occurred before or whether imminent substantial damage is likely: but the absence of any one or more of these elements is not fatal to the grant of an injunction under s 80. That is the effect of subss (4) and (5) (subs (4) in relation to the prevention of conduct and subs (5) in relation to a mandatory injunction). Their presence is not an indication of a new statutory house, rather an old house with some modern extensions.

145    The framework set out above is consistent with Foster v Australian Competition and Consumer Commission (2006) 149 FCR 135.

146    In Foster, the Full Court explained the requisite nexus between the contravention found by the Court and the terms of the injunction in the following terms (at [35]):

In our view, the need, suggested by the authorities, for a nexus between the contravention of the Act which the Court has found and the terms of the restraint which it then decides to impose is a specific reflection of Lockhart J’s insistence that the power be exercised “judicially and sensibly”. It goes to the appropriateness of the relief contemplated by the concluding words of s 80(1), not to the extent of the power to grant it. If the Court considers that a complete prohibition, whether permanently or for a specified period, on a respondent’s engaging in a particular field of commercial activity or industry is required to protect the public from conduct of the kind which constituted the contravention, s 80 is wide enough to support such a prohibition as a matter of power. …

147    The Court extracted part of the second reading speech for the Bill for the 1983 amendments to s 80, in which the Attorney-General described the then statutory power as seriously inadequate, including because the Court was not able to make orders corrective of the results of the relevant contravention. The Court said (at [25]):

To similar effect, the perceived deficiencies in s 80 as it existed before the amending Act were described as follows in the then Attorney-General's Second Reading Speech in support of the amending Bill:

This power is seriously inadequate. First it merely enables the Federal Court to enjoin a person from doing that which he is already under a legal obligation not to do. Secondly, the Federal Court's power effectively to prevent repetition of the conduct is restricted — in proceedings for breach of an injunction it could be necessary to prove all the elements of a contravention (including, where applicable, the effect on competition). Thirdly, the Federal Court is not able to make orders corrective of the results of the contravention (except in the case of corrective advertising provided for in s 80(A)). [Statute Law (Miscellaneous Provisions) Act (No 1) 1983 (No 39, 1983), Second Reading, 18 May 1983.]

(my emphasis)

148    In Medibank Private Ltd v Cassidy (2002) 124 FCR 40, another Full Court said at [26] and [27] in relation to the 1983 amendments:

… [The] powers of the Court were expanded significantly. That is to say, instead of authorising the Court to grant an injunction restraining a person from engaging in conduct, the Court was empowered to grant an injunction in such terms as the Court determines to be appropriate.

That change of language clearly empowered the Court to make mandatory orders in addition to restraining orders. That was recognised by the Parliament in the explanatory memorandum that was circulated in connection with the Bill for the Act to amend s 80 …

149    Let me synthesise some propositions from these authorities and from the terms of s 80 read in context and also in light of s 2.

150    First, although a traditional application of s 80 may involve restraining conduct that has been found to contravene the CCA or like conduct, s 80 is not so limited. Section 80 can also be used to restrain conduct not found to have contravened the CCA provided that there is a sufficient nexus with the contravening conduct as so found. And that sufficient nexus may be established if the injunction is directed to addressing or ameliorating the harmful effects of the prior contravening conduct. In other words the relevant nexus is established flowing from or by reason of the consequences of the prior contravening conduct. Moreover, it also follows that for the subject matter of the injunction in terms of prohibiting future conduct, s 80 does not require that such future conduct itself needs to be shown to involve a likely contravention of the CCA if not restrained. The future conduct to be restrained could be otherwise lawful if the restraint is necessary to ameliorate or address the harmful effects of prior contravening conduct. And indeed to so accept this point is to accept an attractive symmetry. Section 80 also empowers the Court to grant a mandatory injunction to address the harmful effects of prior contravening conduct. And of course the mandatory injunction could only be in terms of requiring lawful conduct. As a matter of symmetry then and the text, context and purpose of s 80, there is no good reason why s 80 cannot be used to grant a prohibitory injunction concerning what is otherwise lawful conduct provided that it has the relevant nexus with addressing the effects or consequences of prior contravening conduct.

151    Second, as I have said, s 80 and the relief that can be granted thereunder concerns the public interest and its protection. But this is not to say that the position of a private litigant seeking orders under s 80 is irrelevant. Such a litigant may be expected to seek relief appropriate to advance its own interests. But it is necessary to ensure that the orders are “appropriate” to the public purposes of the protection and promotion of competition for which the power has been conferred. And provided that they are, there is nothing inappropriate about the fact that those orders may also confer a benefit on the private party. Moreover, there is no requirement that any injunctive relief ordered under s 80 to protect and promote competition in Australia be limited to Apple’s conduct towards Epic as opposed to other developers.

152    Third, Apple’s intellectual property rights are no shield against the scope and application of s 80. I have already held that neither those rights nor licence terms afford immunity from Part IV, and Parliament confirmed as much in s 51(1)(a) following the repeal of the former s 51(3). Coercive supply can be an appropriate remedy for misuse of market power, and I found that access to Apple’s tools is essential for developers to develop and distribute iOS apps. I will elaborate on the intellectual property question later, but before that I need to deal with some matters of geography.

153    Fourth, in order to avoid an inferno of appellate scrutiny more unforgiving than Dante’s allegorical circles due to any vice in my choice of expression, I need to make one point. The words in s 80(1) “to be appropriate” could be seen to be a condition on the exercise of power, they could be seen to require an evaluative judgment or they could be seen to involve an exercise of discretion. For convenience I will refer from time to time to the exercise of discretion. But if I was to formulate my reasons in the other ways, no different result would arise. So when I say or indicate from time to time that in the exercise of my discretion I will make the particular order, I also intend by such short–hand to indicate that that is my evaluative judgment of what is “appropriate” and also that this stipulated condition for the exercise of the statutory power has been satisfied.

154    Finally, Epic’s originating application also sought “[s]uch further or other orders as this Honourable Court sees fit”. Contrary to Apple’s assertions, Epic is not precluded from seeking injunctive relief in terms that refine and particularise the relief described in its originating application so as to reflect my findings on liability.

Geographic scope

155    Epic seeks relief that would apply globally, such that third party marketplace operators and developers distributing via third party marketplaces or websites who wished to use alternative distribution and alternative payment solutions could distribute and transact with any user globally, not just with users who have an Australian Apple Account.

156    Contrastingly, Apple’s proposed relief is limited to users of iOS devices associated with an Australian Apple Account and the Australian App Store.

157    I should say upfront that I am more disposed to Apple’s position on this aspect. But before getting into the legal issues it is worth saying a little more about how Apple’s systems are currently configured.

158    Now to access the functionality of iOS devices, users must create and sign into an Apple Account. In doing so, a user will set their geographic location, which is generally their country of residence or what has been described in the material before me as the home country. Users can also enter their chosen payment credentials such as a debit or credit card and billing information, which must be associated with the selected country or region, in order for any upfront payments to obtain the app or in-app purchases for digital content to be made.

159    The identification and location of users by reference to their Apple Account and the exclusive association of users with specific geographical App Store storefronts has been one of the foundations of iOS since the inception of the iPhone. All of Apple’s tools, technologies and systems including the software development kits (SDKs), application programming interfaces (APIs), frameworks and entitlements, which I have described in detail elsewhere, under both its standard business model and in each jurisdiction where a bespoke model permitting alternative distribution or alternative payments, or both, has been implemented, presuppose that each user and device is associated with one App Store storefront exclusively.

160    There are 175 localised App Store storefronts with over 40 languages and supporting over 40 different currencies, each with unique tax regulations which require adjustments in pricing, and geo-specific local laws and regulations as regards distribution and transactions for digital goods and services. So, for example, in Australia there are newly introduced social media restrictions for under 16 year olds and in Saudi Arabia there are strict content distribution regulations on mobile devices. Apple as the marketplace operator of the App Store assumes responsibility for each of its 175 storefronts and enforces its contractual terms, policies and guidelines in accordance with the local laws and regulations.

161    The country set within a user’s Apple Account settings determines the storefront associated with the account. So, the Australian App Store storefront is accessible to users whose country is set to Australia, who have an Australian billing address and Australian payment method. The services, content types, features or functionality depends upon the home country selected for the Apple Account.

162    Further, in jurisdictions where Apple has been required to facilitate alternative app distribution, the user must be located in that jurisdiction and their billing account details must be associated with that jurisdiction. So, if a US user with an US Apple Account tried to download a marketplace app in Japan or Europe, then Apple’s devices would not permit that functionality to be unlocked for the US user, even if they were physically located in Japan or Europe. It is a feature of the entitlements and frameworks which enable developers to use alternative distribution and alternative payments in these jurisdictions that all users and devices, in relation to whom the relevant entitlement permits alternative distribution or payments to be used, must be located in the relevant jurisdiction and have an Apple Account set to the relevant jurisdiction such as Europe or Japan.

163    Now whilst the subset of iOS users to whom apps can be distributed by alternative means is confined geographically, being currently to users with a Japanese Apple Account or an Apple Account for a country in Europe, there is no equivalent geographical criterion limiting availability of alternative app distribution for developers, in respect of those Japanese and European users. So, developers anywhere in the world who meet and accept Apple’s basic eligibility criteria are able to distribute apps to those Japanese and European users, while they are also physically present in Europe or Japan, via alternative channels.

164    Now it is possible for a user to change the country or region of their Apple Account. But in order to do this, a user will be required to cancel all their subscriptions made via the account and spend any unspent balances in the App Store Storefront in the country or region in which they are currently located. In order to make payments to obtain the app or in-app purchases for digital content in the country or region to which they move their Apple Account, the user must have payment credentials, including billing information, associated with the selected country or region. If a user cannot supply payment credentials associated with that country or region, they will be able to download free apps only and will not be able to make in-app purchases of digital content within those apps.

165    Whilst it is technically possible for a user to have more than one Apple Account, each with a different region or country, a user can only be signed into one Apple Account at a time on the same device, that is, a user cannot simultaneously be signed into two accounts on the same device such that they could not access both the US App Store storefront and Australian App Store storefront concurrently.

166    Further, for completeness, let me make four other points. First, there is presently no technical mechanism to enable an app downloaded whilst signed into one Apple Account to update once the user signs out of that account and into their other Apple Account associated with a different region or country. Second, if the functionality of what is known as family sharing has been invoked, then all family members must share the same home country. Third, devices can only be associated with a different Apple Account once every 90 days. Fourth, Apple has lauded the virtue of its form of orders by saying that even if the relief is limited to users of Australian Apple Accounts, international visitors who are in Australia for any material length of time can benefit from the form of their orders simply by adopting an Australian Apple Account. But that possibility is not as straight-forward as Apple would have it for the reasons that I have indicated.

Apple’s principal arguments

167    Apple says that Epic’s proposed orders do not include any language limiting the scope or effect of the orders to markets in Australia and for that reason should not be made.

168    Apple says that Epic’s pleaded markets were the Australian iOS app distribution markets and the Australian iOS in-app payment solutions market. Epic pleaded that the geographic scope of the markets is limited to Australia or that the markets in Australia form part of global markets (excluding China). And Apple said that the relief Epic claimed was confined to those markets or else to the Australian App Store or to contractual terms operating in Australia or in relation to iOS device users in Australia.

169    Further, Apple says that if Epic’s geographically open-ended relief were to be entertained, significant additional evidence would be required in order to address it, including evidence that such relief would prohibit Apple from engaging in conduct deemed lawful in other countries.

170    Apple refers to the fact that in the US, Apple’s prohibitions on sideloading and alternative app stores and the requirement that iOS apps use IAP for in-app purchases of digital content were challenged by Epic but found to be lawful; see Epic v Apple (US, 2021) and Epic v Apple (US, 2023). Apple points out that the US courts only found a violation of California’s Unfair Competition Law by reason of the anti–steering provision in the DPLA prohibiting developers from directing users to other platforms that was said to involve an unfair practice.

171    Apple says that it follows that Epic’s geographically unlimited orders should not be entertained. Contrastingly, Apple says that the orders proposed by it achieve the appropriate geographic limitation. First, they make it explicit that the declarations apply to the Australian iOS app distribution market and the Australian iOS in-app payment solutions market. Second, they confine the injunctions to conduct concerning the Australian App Store storefront and iOS devices associated with an Australian Apple ID.

172    Apple says that Epic’s ambit claim for relief regulating Apple’s iOS app distribution and iOS in-app payment solutions conduct globally should be refused, and Apple’s geographical parameters should be adopted whichever form of relief is otherwise granted.

173    It says that the activities Epic seeks to bring within the iOS app distribution and iOS in-app payment solutions markets, as “markets in Australia” pursuant to s 4E of the CCA, formed no part of those markets as pleaded or found at trial.

174    Further, it says that even if I was otherwise empowered to make orders in the terms sought by Epic, I should not make orders regulating Apple’s conduct in the iOS app distribution and iOS in-app payment solutions markets in respect of users outside Australia, except to the extent that such users participate in the relevant Australian markets. It says that if I was to go broader, then this would interfere with the balance struck by various foreign courts and by regulators in other countries in regulating analogous conduct in their own jurisdictions.

175    Further, Apple says that Epic has not established that the supply of iOS app distribution services or iOS payment solutions services in the identified categories, that is, to app developers and other providers in relation to iOS users outside Australia, which users are not otherwise relevantly participating in the Australian markets by reason of having an Australian Apple Account, form part of the markets analysed in its case in these proceedings.

176    Apple says that the markets in which its conduct was analysed were markets for the supply of iOS app distribution and iOS payment solutions services in respect of iOS users in Australia.

177    Apple says that Epic now seeks to widen those markets to encompass activities in relation to apps distributed to iOS users elsewhere, but it says that my liability findings do not support that extension.

178    Apple says that Epic’s case had been conducted on the footing that the iOS app distribution services market and the iOS in-app payment solutions market are each a market in Australia within the meaning of s 4E of the CCA because and insofar as the users to whom app developers and payment solutions providers were alike geared were iOS users in Australia.

179    Apple says that Epic’s economic expert, Professor Wright, defined the product market by means of a hypothetical monopolist/small but significant and non-transitory increase in price (HMT/SSNIP) analysis based on an increase in the commission payable on iOS app distribution services in relation to iOS users in Australia only.

180    Apple says that Professor Wright considered that the supply of services for the distribution of iOS apps in Australia is not constrained by the supply of app distribution services in other countries, that no international firms can enter to supply iOS app distribution services in Australia so as to make a SSNIP on the Australian App Store commission unprofitable and that the App Store in Australia is specifically curated for Australian users, such that in the factual a relevant market to assess the effect or likely effect of Apple’s iOS app distribution conduct on competition in Australia is a market limited to Australia.

181    Apple says that Professor Wright applied the 7.5% increase in Apple’s commission to iOS app distribution services in the Australian App Store only

182    Apple says that Professor Wright proceeded on the basis that developers would be insensitive to the cost savings available by delisting from the Australian App Store because they defrayed fixed costs across revenue generated by operating on App Stores globally. So, Professor Wright proceeded on the basis that the costs and benefits of delisting from the Australian App Store storefront could be analysed on the assumption that commissions in other App Store storefronts were unchanged.

183    Further, Apple says that Professor Wright’s definition of the iOS payment solutions product market was derivative of his analysis of the iOS app distribution product market, and was similarly focused on services in relation to iOS users in Australia, exclusively.

184    Further, Apple says that Professor Wright did not conduct a SSNIP analysis by reference to a global commission increase. Rather, Professor Wright explained his view that app developers would also be unlikely to stop investing in maintaining and upgrading their apps in response to such a global increase in commissions. This view was advanced in support of Professor Wright’s proposition that, since developers have fixed costs of investing in, maintaining and upgrading apps globally, they are unlikely to be sensitive to an increase in commissions on the Australian App Store.

185    Apple says that this analysis supplemented Professor Wright’s analysis of a SSNIP on the Australian App Store storefront, not a SSNIP analysis by reference to a global commission increase. Apple says that the relevant appendix to his report did not contain any analysis of the kind Professor Wright considered (at 10.56 to 10.57 of his report) that it would be possible to conduct, namely, of the iOS app distribution services market in its global geographic dimension. And it says that Professor Wright’s report went no further than entertaining the possibility of such analysis.

186    So, Apple says that Epic’s case was conducted on the basis that the product dimension of the relevant markets was Australia specific. Apple says that the product markets as defined by Professor Wright and accepted by me had a geographical dimension built into them. It is said that they concern the supply of iOS app distribution and payment solutions services to developers in respect of Australian iOS users only.

187    Further, Apple says that whether or not the geographical dimension of the product market so understood is Australia specific or global is immaterial. It says that the conduct of Apple that has been in issue in these proceedings, and which stands to be regulated by remedies granted by me, is its conduct in relation to iOS users in Australia, rather than Apple’s conduct in relation to iOS users anywhere else.

188    Further, Apple says that Epic did not lead any evidence or cross-examine any Apple witness concerning the varieties of app developer or the activities of Australian developers abroad.

189    Further, Apple says that Ms Wong’s evidence concerned her team’s efforts to maximise their Australian developers’ use of Apple’s offerings in the development and distribution of apps on the Australian App Store.

190    Before proceeding further, it is convenient at this point that I set out some of her evidence given at the liability trial which was as follows:

At any given time (including as at the date of this affidavit), Apple Australia ordinarily provides direct support and guidance to approximately 30 to 50 Australian app developers, in the development and distribution of their apps on the Australian Storefront, including in their use of Apple Inc.’s tools and services, to maximise consumer engagement, and to market and promote developers’ apps on the Australian Storefront.

Apple Australia’s engagement with developers occurs independently of Apple Inc. My team, and other Apple Australia teams, decide which developers we work with and how we interact with them.

For example, my team works with the Australian free to air television networks (Seven, Nine, Ten, ABC, SBS) in relation to the apps they offer through the Australian Storefront. It is important that these apps are available on the Australian Storefront, to meet consumer expectations, and that they work faultlessly on Apple devices. Thus, we work closely with these developers on their apps to optimise the consumer experience, even though these developers pay no commission to Apple.

In my experience as Business Lead of the Australian Storefront, Apple Australia interacts with developers on an individual basis. Developers may have entirely different needs from each other. For example, I have observed that developers are often at different stages of growth in respect of their business, and have different app styles and genres, number of apps, plans for development of their app(s) on, often, multiple platforms (for example, iOS, PC, console) and plans for expanding distribution to App Store storefronts outside Australia. In my experience, developers may also have cause to use different tools within the suite of tools which Apple Inc. makes available to assist in developers’ initial and progressive development of their app for the App Store. In light of this experience, the teams within Apple Australia tailor their engagement to the particular circumstances, and needs, of each developer at the relevant time.

From time to time, Apple Australia reports on activity with those developers we manage in Australia to our United States and International counterparts. This is done by communications which include monthly updates on noteworthy success stories based on app downloads and engagement from consumers relating to the Australian Storefront. This can include sharing our learnings and experiences on a piece of curation, an Australian developer’s app(s) worthy of promotion in other regions or a method of promotion we have adopted.

Otherwise, the majority of my, and my team’s, interaction with Apple Inc. and its related entities is for the purpose of maximising our Australian developers’ use of Apple’s offerings in the development and distribution of apps on the Australian Storefront. For example, my team and I collaborate with other Apple personnel in our equivalent positions globally to introduce Australian developers to other countries for the purpose of facilitating the distribution of their apps in those countries via other country-specific App Stores.

Internally, my team works with Apple Australia’s Developer Relations team during the development stage of a new app. The role of Developer Relations is to engage with developers on the availability and use of Apple’s APIs from Apple’s Developer Program to optimise their apps and maximise consumer engagement. As apps are updated and are the subject of new releases, we continue to engage with the Developer Relations team to connect with developers and provide assistance or guidance to a particular developer. This forms part of our continuing engagement with developers and their apps post launch on the Australian Storefront.

If a developer chooses to monetise an app through paid downloads or in-app transactions for digital content, they need to implement StoreKit APIs. My team supports developers during the development phase of an app with StoreKit API implementation for their app. Business Managers will assist with trouble shooting for developers by connecting them with Apple Inc.’s App Store Commerce team, who oversee commerce operations of the App Store. Post launch, and as part of ongoing management, especially with subscriptions, my team will assist developers seeking to maximise the lifetime value of each customer using the tools available in StoreKit.

We also work with Product Marketing and Publicity teams within Apple Australia to help with the selection of apps and games suited to showcase key features of individual Apple devices.

All of the activities I have referred to in paragraphs 68 to 70 above, relate to apps and games by local Australian developers. I have observed during my interactions with Apple personnel in other geographic regions that the App Store and Developer Relations teams in respective international markets experience equivalent issues with their own local developers and on occasion we have discussed common approaches to addressing such issues.

191    Further, in rejecting Epic’s case of knowing involvement of Apple Pty Ltd in Apple Inc’s contraventions, I observed that it had not been put to the relevant witness Ms Wong that the Australian App Store was a monopoly. I said at [6135]:

So, despite direct evidence from Ms Wong of her understanding that competition exists across multiple platforms, it was not suggested that she knew that the Australia App Store was a monopoly or that Apple had conducted itself in particular ways with a purpose or effect of substantially lessening competition. Nor are there any documents that provide the basis for such a finding.

192    Further, Apple says that Epic did not lead any evidence or cross-examine any witness to establish any preference of developers to use one payment solutions provider to serve iOS users across all geographical regions. Further, it says that Epic did not lead any evidence or make any submission to the effect that there even exist any actual or likely Australian payment solution providers who wish to provide services in relation to iOS apps distributed outside of Australia.

193    Further, Apple says that the counterfactual which Epic asked me to analyse was one in which impediments for alternative app stores and direct downloading of apps on iOS devices were removed. It says that given that the relevant markets were framed by references to Australian iOS device users and the Australian App Store storefront, it was necessarily implicit in this that the impediments were to be removed in respect of Australian iOS devices only.

194    It says that the factual was characterised by the inability of either developers or users to switch to an app store outside of Australia for the distribution of apps to iOS device users in Australia, and the inability of international suppliers of app distribution services to enter and offer iOS app distribution services in Australia.

195    Now Epic submits that making orders omitting various categories of activity would likely damage the future state of competition in s 4E markets in Australia. It says that the ability of Australian developers, app store and website operators, and payment solution providers to service international customers within a global market that encompasses Australia will directly affect their ability to compete with Apple and others in the s 4E markets, constraining their growth so they can never achieve scale sufficient to enhance the state of competition in Australia through such advancements as quality and price.

196    But Apple says that that proposition was not foreshadowed in any pleaded allegation, is not tethered to any lay or expert evidence led at trial, and finds no support in my liability findings.

197    Apple says that it is a theoretical question whether its conduct in restricting the supply of distribution services and payment solutions services to developers in respect of iOS users outside Australia could operate to foreclose entry or expansion by Australian developers in this fashion. And it says that to establish any real commercial possibility of such an anti-competitive effect or purpose would require proper analysis of that conduct, on the identified market participants, in a defined market, but Epic has not undertaken that exercise.

198    Now before getting into the legal arguments concerning geographic scope, I should address Apple’s arguments concerning how the liability case was pleaded and was run. I would say upfront that the way the case was pleaded and run was not as narrow as Apple would have it.

The pleaded markets

199    At the outset it is to be noted that there are elements in the second further amended statement of claim (2FASOC) that are broader than Australia.

200    First, there are the pleas concerning the parties and their activities (see for example [1] to [30]). Further, the 2FASOC refers repeatedly to the App Store as distinct from the Australian App Store (see for example [24] to [30], [43] to [47B], [95] and [106] to [109]).

201    Second, the pleas of the relevant markets at [90] to [94] make clear that Epic’s case was to the effect that the markets were markets in Australia either because their geographic dimension was limited to Australia or because they formed part of a global market but excluding China. I should say that the case as run made little of any such limitation on geographic dimension.

202    Third, although the s 46 allegations from [114] refer to the definitions of “the Australian iOS App Distribution Markets” and “the Australian iOS In–App Payment Solutions Markets”, they clearly embrace the case of the Australian market being part of a global market but excluding China.

203    Now Apple joined issue with the pleaded geographic markets, but it did not assert that the geographic dimension of any market defined by reference to the services pleaded by Epic was confined to Australia.

204    Epic pleaded that there was a market for the supply of services for the distribution of iOS apps to iOS device users. This was the product dimension of the pleaded market; it was geographically unconstrained. The restrictive terms of the DPLA that Epic attacked applied to all developers and all iOS device users, wherever located. Various allegations supporting Epic’s pleaded market definition, were not restricted to activities in Australia.

205    Further, Epic pleaded that there was a market for the supply of services to app developers for accepting and processing payments for in-app purchases within an iOS app. This pleading of the product dimension was also geographically unconstrained. The pleadings that formed the basis of the pleaded in-app payment solutions market were not restricted to activities in Australia.

206    Further, in the context of the pleaded payments markets, the market concerns the supply of payment processing services to app developers for inclusion in their iOS apps that, in the absence of Apple’s restrictions, could and would be distributed anywhere. In fact, Australian app developers have been seeking, and were being encouraged by Apple, to distribute their apps to countries beyond Australia.

207    Further, the conduct alleged to give rise to contraventions was similarly not limited to Australia. At its core, Epic’s case in respect of the iOS distribution services market was that Apple ensured that the App Store was the sole means for developers to distribute iOS apps and for iOS device users to obtain iOS apps. The pleading to this effect was not geographically constrained.

208    Further, Epic’s pleaded allegations as to the lessening of competition caused by Apple’s conduct were similarly not limited to circumstances involving Australian iOS device users.

209    Epic pleaded that, but for Apple’s conduct, Apple would have faced the threat of entry by competitors and vigorous and effective competition in one or more of the pleaded markets from alternative methods of iOS app distribution, including competing app stores. This was an allegation not constrained by geographic constraints on the location of the firms offering the alternative methods of distribution, the developers who use those methods, or the users who access apps through them. Epic pleaded a substantially similar allegation in relation to the in-app payment solutions market.

210    Further, the Australian market labels in declarations 1 and 2 in the further amended originating application (the FAOA) import the defined terms in the 2FASOC including the global market alternative. Declarations 1 and 2 allege the s 46 contraventions by incorporating the pleaded conduct via cross-references. Those allegations are not geographically confined. Where, in those paragraphs, the pleading refers to Australian iOS device users it does so inclusively, not by way of geographic limitation on the impugned conduct.

211    The key relief is [7] of the FAOA, which operates by reference to the declarations, and hence the geographically unconstrained pleaded conduct that was alleged to affect competition in s 4E markets. I do not read down the declarations or [7] by reason of the express Australian limitations elsewhere in the FAOA.

212    Of course, Epic’s case is directed to protecting competition in s 4E markets bearing upon competition in Australia. But that does not answer the separate question as to what scope of restraint is necessary to do that effectively, and therefore “appropriate” within s 80.

213    Let me turn to the economic evidence. Again, this covered a broader geographic reach than Apple would have it.

Epic’s economic expert evidence

214    Epic’s expert evidence was to the effect that the markets extend beyond services provided in respect of Australian iOS device users. Now Apple says that Epic’s case was conducted on the footing that the relevant markets are markets in Australia within the meaning of s 4E because the users to whom relevant services were provided were users in Australia.

215    But Epic’s case was that, in each pleaded distribution market, Apple’s conduct foreclosed competition in relation to the supply of distribution services to all iOS users and the supply of in app payment services to developers.

216    Apple focuses exclusively on the markets from the perspective of device users and ignores the perspective of developers located in Australia or elsewhere who would supply their apps to users in Australia, or from Australia to other countries, but for Apple’s unlawful conduct. Likewise, the payment solutions market concerns the supply of payment solutions by payment providers, located in Australia or elsewhere, in various ways, including to Australian app developers who may supply their apps to users located in Australia or elsewhere, and to overseas developers who may supply their apps to users located in Australia.

217    Further, the economic expert evidence was not confined to considering services in respect of iOS users in Australia only.

218    First, Professor Wright conducted three analyses to determine the relevant markets. He conducted a qualitative analysis which considered what if any close substitutes existed. He conducted a traditional SSNIP on Apple’s commission rates which took into account Australian App Store transactions data. And he conducted a reverse SSNIP which compared Apple’s effective commission rates to PC app stores, and working backwards determined that the candidate market was no broader than the pleaded iOS app distribution market. Professor Wright’s analysis of substitution possibilities and competitive constraints was conducted in a qualitative manner by reference to matters that were not limited to Australia.

219    Second, Professor Wright’s conclusions about developer responses to a SSNIP were also dependent on matters that were not specific to Australia. So, for example, Professor Wright’s analysis of the likelihood that developers would delist from the App Store was not limited to the Australian App Store. And his detailed analysis was directed to a global increase in commissions, not an increase in commissions on the Australian App Store.

220    Third, although as to the reverse SSNIP Professor Wright relied on Australian App Store data, the underlying commission rates for each comparator store were global.

221    Further, Professor Wright’s evidence as to the iOS in-app payment solutions market was similarly not confined to Australia. His assessment of substitution possibilities was not so limited.

222    More generally, Professor Wright’s evidence was that the product dimension would not change if one adopted a global geographic frame of reference.

223    Further, it is convenient to note here that because of the presence of Apple’s restrictions, the supply of services for the distribution of apps in Australia was not constrained by the supply of those services outside Australia. And so Professor Wright concluded that the relevant market was one limited to Australia “in the presence of Apple’s restrictions”. Resonating with that theme, in Epic v Apple (US, 2021) at 991 the trial judge found Apple’s factual basis for its assertion of a domestic market “to be weak” on the basis that “Apple’s restrictions appear to be imposed by Apple, rather than by market forces”. And as was also explained (at 1027), “Apple’s engagement in [the defined market] does not change based on national borders. Developers globally access the platform based on the same set of rules and agreements”.

224    Further, Professor Wright gave evidence that it would be possible to assess the effect of Apple’s conduct on a global basis and observed that this would be particularly relevant in the case of developers who operate globally. His evidence was that the geographic frame of reference would be global, but excluding countries with very different competitive conditions arising from significantly different regulation.

225    He also made clear that his conclusions as to the product scope of the market, as well as whether Apple had market power and the effect of its conduct on competition in Australia, would be the same whether he adopted the Australian or global frame of reference. His view was that in either case there were no close substitutes for the supply of services for the distribution of iOS apps.

226    Professor Wright’s evidence in respect of the iOS payment solution market was to similar effect. He also concluded that if one adopted a geographic frame of reference beyond Australia, the product dimension of that market would remain limited to the supply of payment solutions to developers for iOS in-app purchases, and his conclusions on market power and competitive effects in the iOS in-app payment solutions market would be unchanged.

227    Further, a global frame of reference is also supported by the evidence led in Epic v Google. Ms Edwards–Warren concluded that the geographic scope of the Android mobile app distribution market and the in-app payment solutions market was likely global.

228    Let me then say something more generally about how the case was run at trial.

Epic’s case at trial

229    Epic’s case at trial was that the markets extended beyond services provided in respect of Australian iOS device users.

230    And the global focus of Epic’s submissions was consistent with the evidence of Apple’s own witnesses as to the manner in which Apple operates the App Store.

231    So for example, Ms Wong gave evidence that her team collaborates with other Apple personnel to introduce Australian developers to other countries for the purpose of facilitating the distribution of their apps in those countries via other country specific App Stores. Ms Wong had direct experience of Australian developers distributing their apps overseas and being encouraged to do so by Apple. But in the presence of Apple’s restrictions, that could only be done through other country specific App Stores.

232    Further, Epic made submissions as to the geographic scope of the iOS in-app payment solutions market, namely that it was at least as wide as Australia and may be global.

233    Epic led evidence from Mr Owens of Paddle, the developer of payment solutions that could be used in iOS apps both outside Australia and in Australia. It also led evidence from Epic, including about the EGS and Epic Direct Pay. Again, neither of these are limited to apps for distribution to users in Australia. The evidence before me gave a picture of the activities of developers focused on the provision of services and apps both in Australia and globally.

234    Now Apple contends that Epic did not lead any evidence to establish that developers had a preference to use one payment solutions provider across jurisdictions. But I made findings in Epic v Google to the effect that developers do prefer to have a single payment solution. At GJ[5499] I said:

Now under the UCB program developers are compelled to offer Google Play Billing alongside their preferred alternative payment solution. As Epic says, this is unattractive for developers. App developers prefer all payments to be facilitated by a single payment solution so that the developers are only dealing with one payment solution provider and can consolidate transaction data from a single source.

235    Apple also says that Epic did not lead evidence of Australian payment solution providers, which is said to support the conclusion that the case run by Epic was confined to iOS users in Australia. But as Epic says, the fact that Australian developers have to date been foreclosed from participating in the markets by Apple’s unlawful conduct means that there could be no evidence of those providers existing at present. Further, there is a real likelihood that developers will seek to use alternative in-app payment solutions if they are able to.

236    Generally, I do not agree with Apple’s assertions to the effect that Epic’s case was pleaded and run on a constricted geographic basis. But to say this does not get Epic home in justifying the expansive and ambitious global reach of its proposed orders.

237    Let me now turn to s 80 and some relevant principles concerning its geographic reach. I will then say something concerning international comity and then turn to the discretionary factors to which comity is also relevant.

Section 80 — extra–territorial operation

238    Section 80 is not to be read as subject to territorial constraints beyond those otherwise present in the structure of the Act. Further, there is nothing in the text of s 80 that contains any express or implied territorial constraint.

239    Indeed such constraints are expressly denied by s 5 which provides:

(1)    Each of the following provisions:

(a)    Part IV;

…

(b)    Part XI;

…

(f)    the remaining provisions of this Act (to the extent to which they relate to any of the provisions covered by paragraph (a), (aa), (ab), (b), (ba) or (c));

…

extends to the engaging in conduct outside Australia by:

(g)    bodies corporate incorporated or carrying on business within Australia; or

(h)    Australian citizens; or

(i)    persons ordinarily resident within Australia.

…

(2)    In addition to the extended operation that sections 47 and 48, and Divisions 3 and 4 of Part IVE, have by virtue of subsection (1), those provisions extend to the engaging in conduct outside Australia by any persons in relation to the supply by those persons of goods or services to persons within Australia.

240    Sections 5(1)(a) and (g) provide that Pt IV extends to the engaging in conduct outside Australia by a company that carries on business within Australia. Sections 5(1)(f) and (g) then provide that the remaining provisions of the CCA, to the extent to which they relate relevantly to Pt IV, similarly apply to the engaging in conduct outside Australia by a company that carries on business within Australia. Section 80 is a provision which relates to Pt IV insofar as it provides for an injunction to be granted consequent upon a contravention of a provision of that Part.

241    So, s 5(1) displaces the presumption of statutory interpretation that legislation will not have an extraterritorial effect, which can also be described as the “presumption in favour of international comity”; see BHP Group Ltd v Impiombato (2022) 276 CLR 611 at [23] per Kiefel CJ and Gageler J.

242    In analogous reasoning in Karpik v Carnival Plc (2023) 280 CLR 640 concerning s 23 of the Australian Consumer Law when read with s 5 of the CCA, it was observed (at [19]):

The so-called common law “presumption” against extraterritoriality – that subject to a contrary intent, words in a statute describing acts, matters or things in general words are to be read so as not to have extraterritorial effect – is an interpretive principle only. …[T]he application and force of the presumption depends upon the extent to which the provisions of a statute depart from common expectations that Parliament’s concern with the subject matter is limited to matters within its territory. It may have little or no role to play where, as will be seen in relation to s 23 of the ACL read with s 5(1)(c) and (g) of the CC Act, the statute expressly departs from those common expectations. In sum, the application or consideration of the presumption cannot precede the question of interpretation – being whether the statute expressly or impliedly addresses the territorial reach of its subject matter.

[footnotes omitted]

243    Further, any necessary geographic nexus is built into the structure of Part IV and s 80. Relief under s 80 is premised on the finding of a contravention of Part IV. But conduct will constitute a contravention of Part IV of the Act only insofar as it has an effect on competition or trading practices in a market in Australia, within the meaning of s 4E of the Act.

244    So, in Air New Zealand Ltd v Australian Competition and Consumer Commission (2017) 262 CLR 207 it was found that s 45 of the then TPA was contravened by conduct which occurred largely in Hong Kong, Singapore and Indonesia, because the conduct being the entering into of contracts which amounted to price fixing nonetheless occurred within a market in Australia; see at [33] to [35] per Kiefel CJ, Bell and Keane JJ.

245    Further, s 80 is to be interpreted in light of the object of the CCA, which is (s 2) to “enhance the welfare of Australians through the promotion of competition and fair trading and provision for consumer protection”.

246    The prohibitions in Part IV are directed at enhancing the welfare of Australians through the promotion of competition. The advancement of the objects of Pt IV extends to the protection of competition for the benefit of all persons physically located in Australia, including those who use international devices, and all app developers physically located in Australia, including those who wish to supply apps to users overseas. But considerations of practicality and comity are not irrelevant to the making of any decision as to the scope of “appropriate” relief in the circumstances of the case.

247    Further, where an injunction is directed at conduct outside Australia, limitations in enforceability through foreign courts are not a bar to injunctive relief under s 80, but of course are a relevant consideration in the exercise of the Court’s discretion. Of course, limitations on enforceability may be of less significance in the context of statutory public interest injunctions, as compared to traditional equitable relief, because the aims of the public interest injunctive relief extend to the broader regulatory purposes of the CCA.

248    But regardless of its geographic reach, any injunction imposed will ultimately operate as part of the domestic law of Australia. Section 80 is not capable of and does not purport to affect a person’s rights under foreign law in respect of the same or similar subject matter. Whether Australian judgments will be recognised in other jurisdictions and in what circumstances is a matter for foreign law and not for me in considering the purpose and scope of s 80, although it is not irrelevant to the exercise of discretion.

A little on international comity

249    The presumption against extra–territoriality is a specific application of the general presumption that every statute is to be interpreted and applied as far as its language permits so as not to be inconsistent with the comity of nations or with established rules of international law; see Impiombato at [28] to [32] per Kiefel CJ and Gageler J.

250    But I should also note what Gordon, Edelman and Steward JJ said (at [59], [61], [63] and [71]):

In statutes, like the Federal Court of Australia Act, where there is no express provision relevantly addressing the territorial reach of the subject matter of the statute, the task is to identify the hinge (also referred to as the statutory springboard, general subject matter, object of legislative concern, central conception, character or central focus) of the statute and identify its territorial connection, if any. …

…

Only after identifying the hinge of the provisions and revealing the territorial connection (if any) of the subject matter, does the question of the application of the common law presumption against extraterritoriality arise. The so-called “presumption” is an interpretive principle whose force depends upon the extent to which the hinge of the provisions departs from common expectations that Parliament's concern with the subject matter is limited to matters within its territory. Put another way, the general common law presumption of territoriality – that an enactment describing acts, events, matters or things in general words, so that, if constrained by no consideration lying outside its expressed meaning, its application would be universal, should not be understood as extending extraterritorially – is a rule of construction only and “it may have little or no place where some other restriction is supplied by context or subject matter [of the statute in issue]”. …

…

Section 21(1)(b) of the Acts Interpretation Act 1901 (Cth) does not compel a different approach or give rise to a different conclusion. Section 21(1)(b) provides that “[i]n any Act … references to localities jurisdictions and other matters and things shall be construed as references to such localities jurisdictions and other matters and things in and of the Commonwealth”. Section 21(1)(b) does not answer the question: what is the matter or thing which should be construed, subject to contrary intent, as “in and of” the Commonwealth? …

…

It is unnecessary to fully address the question, raised in submissions, of whether the common law presumption only applies where a statute extends to subject matters over which, according to the comity of nations or international law, another sovereign or state properly has jurisdiction. That is not what Pt IVA does. For present purposes, it is sufficient to recognise that the common law presumption has been stated without reference to, and applied without reliance on, the comity of nations or international law. The “presumption” is a rule of statutory construction.

(footnotes omitted)

251    And as to the Acts Interpretation Act 1901 (Cth), Kiefel CJ and Gageler J said at [36]:

The concern of s 21(1)(b) of the Acts Interpretation Act with “references to localities jurisdictions and other matters and things” in a Commonwealth statute is not with the manner of expression of a statutory reference but more substantively with the subject matter to which statutory reference is made. Its instruction that all such references are to be “construed” as “references to such localities jurisdictions and other matters and things in and of the Commonwealth” is a requirement that the statute be construed to ensure that a connection exists between the subject matter to which the statute refers, on the one hand, and the Commonwealth of Australia understood compositely as a geographically bounded polity, on the other hand. The “exact nature” of the requisite connection is not prescribed. That is left by the provision to be determined in the construction of the particular statute: “to be implied or imported upon a consideration of the context and the subject matter”.

(footnotes omitted)

252    The content of the general presumption was discussed by Dixon J in Barcelo v Electrolytic Zinc Company of Australasia Ltd (1932) 48 CLR 391 at 423 and 424, quoting what was said by James LJ in Niboyet v Niboyet (1878) 4 P.D. 1 at 7 that:

[i]t is always to be understood and implied that the legislature of a country is not intending to deal with persons or matters over which, according to the comity of nations, the jurisdiction properly belongs to some other sovereign or State.

253    Now in Karpik, it was held that one should start with the text, context and subject matter of the statute before applying the presumption dealing with extraterritoriality. It was said at [22]:

Princess’ submissions incorrectly invert the inquiry. This Court has recognised that there is a rule “that an enactment describing acts, matters or things in general words, so that, if restrained by no consideration lying outside its expressed meaning, its intended application would be universal, is to be read as confined to what, according to the rules of international law administered or recognized in our Courts, it is within the province of our law to affect or control”. However, that rule is “one of construction only” which “may have little or no place where some other restriction is supplied by context or subject matter”. Put in different terms, determining whether the text, context or subject matter of the statute supplies the territorial connection necessarily precedes the application or consideration of the so-called presumption, not the other way around.

254    As an interpretative principle, the presumption should inform the proper construction of s 80(1) or the manner in which I should exercise my discretion under that section.

255    Now Epic says that the presumption has no work to do in this case as s 80 is expressed in unqualified terms and s 5 expressly addresses extraterritorial operation. But the absence of an express territorial limit in s 80 is not determinative. Indeed, the presumption has most commonly been applied to statutes expressed in general words which if “taken literally in their widest sense, would apply to the whole world” (Impiombato at [27]).

256    Clearly, s 80 is broad enough to permit me to prohibit or mandate acts abroad, but the question in this case is how far I can go in prohibiting or mandating acts abroad, having regard to considerations of comity.

257    Now in Neilson v Overseas Projects Corporation of Victoria Ltd (2005) 223 CLR 331 Gummow and Hayne JJ at [90] said:

Once Australian choice of law rules direct attention to the law of a foreign jurisdiction, basic considerations of justice require that, as far as possible, the rights and obligations of the parties should be the same whether the dispute is litigated in the courts of that foreign jurisdiction or is determined in the Australian forum. This is not a consideration which seeks uniformity for the sake of the aesthetic value of symmetry. Nor is it a precept founded in notions of international politeness or comity. As has been said, comity is “either meaningless or misleading”; it is “a matter for sovereigns, not for judges required to decide a case according to the rights of the parties”.

(footnotes omitted)

258    But their Honours were there addressing the limited role that comity plays in choice of law rules applicable to private causes.

259    In CSR Ltd v Cigna Insurance Australia Ltd (1997) 189 CLR 345 at 395 and 396, the majority approved of the definition adopted by the Supreme Court of the United States in Hilton v Guyot (1895) 159 US 113 at 163 and 164, being that:

“Comity”, in the legal sense, is neither a matter of absolute obligation, on the one hand, nor of mere courtesy and good will, upon the other. But it is the recognition which one nation allows within its territory to the legislative, executive or judicial acts of another nation, having due regard both to international duty and convenience, and to the rights of its own citizens or of other persons who are under the protection of its laws.

260    In Lipohar v The Queen (1999) 200 CLR 485 at [100], Gaudron, Gummow and Hayne JJ referred to Hilton but added a reference to Story by saying:

In any event, the common law doctrine of comity is neither “a matter of absolute obligation, on the one hand, nor of mere courtesy and good will, upon the other”. As Story put it, in the nature of things comity cannot “be defined and fixed”, but “must necessarily depend upon a variety of circumstances which cannot be reduced to any certain rule” …

(footnotes omitted)

261    Now as to s 5, as I have indicated it extends the provisions of Part IV to the engaging of conduct outside Australia by bodies corporate incorporated or carrying on business within Australia, Australian citizens, and persons ordinarily resident in Australia. So, one can have regard to conduct abroad by Australians and bodies corporate who carry on business in Australia when determining whether there has been a contravention of s 46. But it does not follow that my power to grant a remedy for any contravention arising from conduct abroad is unconstrained. I have to consider what is “appropriate”. And clearly, considerations of international comity and the courts’ traditional respect for those considerations are not irrelevant to that question. It is not irrelevant to consider whether to prohibit or mandate acts that properly fall within the legislative or regulatory competence of other nations, even if those acts have the territorial nexus described by s 5.

262    Now Epic says that Apple has not proved a positive entitlement under any foreign law to refuse to open its platform. But of course the US courts have affirmed that their antitrust laws do not require Apple to make alternative app distribution available or to allow alternative payment solutions in apps distributed via the App Store, although steering to out-of-app payment methods must be allowed under California unfair competition law.

263    On one view, the orders proposed by Epic would be in tension with that legislative choice and impose the requirements of Australian law on Apple when dealing with US citizens in relation to the distribution of apps occurring wholly within the US. Moreover, as Apple points out, this is what US courts have declined to do when Epic sought worldwide orders in the US courts, out of respect for the legislative and regulatory processes of other nations (Epic v Apple (US, 2021) at 1058).

264    Further, in Epic Games Inc. v. Google LLC (ND Cal, No. 20-cv-05671-JD, 2024), Order Re UCL Claim And Injunctive Relief, at Section II, Subsection B, pages 7 to 8, Judge Donato said:

The initial question for the injunction is where it will apply geographically. The jury found a relevant geographic market of worldwide except for China for both of the product markets, which was a conclusion that was amply supported by the evidence at trial. See JMOL Order at 14-15. Even so, the permanent injunction is limited to the United States.

This is due mainly to principles of comity and deference to the rights of other countries to address anticompetitive conduct under their own laws and regulations. The record indicates that enforcement agencies around the world are investigating Google's conduct with respect to the Play Store. See, e.g., Dkt. No. 700 at 3 (granting Google's motion in limine to “exclude evidence or argument re foreign proceedings and investigations”); Dkt. No. 644-2 at ECF pp. 61-68 (discussing foreign investigations and regulatory reports); see also Dkt. No. 958 (Google’s Objections) at 87-89 (describing extensive legal, investigative, regulatory, and other informal proceedings underway in foreign jurisdictions). It is neither the right nor the duty of a United States court to preempt the enforcement powers of other nations by imposing an injunction that would operate within their borders. Consequently, the Court elects, as a prudential matter, not to interfere in the administration of antitrust laws outside the United States. See Mujica v. AirScan Inc., 771 F.3d 580, 598 (9th Cir. 2014) (“International comity is a doctrine of prudential abstention, one that ‘counsels voluntary forbearance when a sovereign which has a legitimate claim to jurisdiction concludes that a second sovereign also has a legitimate claim to jurisdiction under principles of international law.’”) (citation omitted).

265    Further, regulators and legislatures in the EU and Japan have not been silent. They have put in place detailed regulatory regimes which no doubt reflect their best assessments of what promotes the public interest within their jurisdictions. Those assessments may not accord with what I consider best promotes the welfare of Australians, but it is not my prerogative to superimpose my own view over those foreign regulators and legislatures where they have turned their minds to the same or similar questions concerning the players and the platforms operating within or subject to their jurisdictions.

266    Further, I agree with Apple that the absence of evidence or regulatory silence regarding the position in the remaining countries in which Apple does business does not mean that the entitlement of those jurisdictions to regulate dealings with their citizens or corporations is to be overridden. Those countries are entitled to introduce their own specific regulation of methods of app distribution or in-app payments for digital content. They may also have broader policy interests relevant to the regulation of app distribution for all I know. Clearly, I was not asked to and could not embark on a voyage of discovery to address such questions.

267    So for example and as Apple put it, I need not enquire into the competition laws of Malaysia or their enforcement to recognise that the regulation of dealings between Apple and Malaysian citizens is a matter properly within the legislative and regulatory competence of Malaysia. The mere fact that some Malaysian app developers may have an attenuated territorial nexus with Australia because they supply apps to Australian consumers or wish to do so, does not mean that the legislature intended to empower me to intervene and regulate Apple’s dealings with those persons in their own home jurisdiction.

268    Moreover, regulatory silence may equally reflect that a regulator in another jurisdiction has made a conscious choice not to regulate. A foreign regulator that did not bark may be like Conan Doyle’s canine for all I know.

269    Now Apple goes so far as to say that having found a s 46 contravention, I am not empowered by s 80(1) to grant injunctions that intrude into areas that properly fall within the jurisdiction of other nations, namely, the extent to which those nations consider it necessary or desirable as a matter of local law and policy to require Apple to allow their citizens to access iOS apps through alternative distribution channels or pay for digital in-app content using alternative payment solutions.

270    Apple says that I must construe the CCA and s 80 in particular having regard to the statutory subject matter and statutory context. And it also says that it is a principle of interpretation that statutory provisions should be interpreted, so far as possible, to be consistent with international law; reference was made to Kingdom of Spain v Infrastructure Services Luxembourg Sàrl (2023) 275 CLR 292 at [16].

271    But I am empowered to grant relief that I determine to be “appropriate” within the meaning of s 80. And s 80 when read with s 5 displaces the presumption against extra–territorial effect. Further, relief will be “appropriate” if it advances the public interest objectives of the CCA by addressing or remedying the effects of Apple’s unlawful conduct. Moreover, complying with Epic’s proposed relief would not necessarily upend and supplant the legislative and regulatory balances struck by other states’ legislatures and regulators.

272    In summary then, I do not accept Apple’s absence of power argument in terms. But in any event Apple says that each of the matters that it has relied upon concerning international comity are relevant to the exercise of my discretion under s 80, which if I might say so is a more powerful point in its favour.

Epic’s nexus arguments

273    Now Epic says that there is an appropriate nexus between the relief Epic has proposed, and the supply of distribution services and payment solutions within, into and out of the markets in Australia.

274    First, it says that the proposed relief applies to any iOS users physically located in Australia, whether or not they have an Australian Apple Account.

275    Second, it says that the proposed relief applies to any developers that are incorporated in or carry on business in Australia, supplying services anywhere.

276    Third, it says that the proposed relief applies to Australian citizens or persons normally resident in Australia, supplying services anywhere, or using services anywhere.

277    Fourth, it says that the proposed relief applies to the supply of payment processing services to an Australian developer, wherever the developer or the payment supplier may be located.

278    Fifth, it says that the proposed relief applies in the course of or in relation to trade or commerce in Australia or between Australia and another country.

279    Sixth, it says that the proposed relief applies to the supply of goods and services to the Commonwealth or an instrumentality of the Commonwealth, wherever the Commonwealth officers, entities or instrumentalities may be located.

280    Let me now turn to some more detailed arguments of Epic.

281    Epic says that in Epic v Apple (US, 2021), the Court rejected Apple’s contention that its self-imposed business structures involving country specific storefronts dictated that the relevant market was geographically confined to the US. The Court explained at 991 that it:

finds more persuasive that Apple actually treats app distribution as a global enterprise. Its rules and guidelines apply globally to all storefronts, the business development team engages with developers globally, the DPLA applies globally, and the complexity and justification for the complexity of the IAP system is due in large part because of the global nature of the business.

282    Further, Epic says that I expressly contemplated that the relevant markets may be global, and that was consistent with a number of my findings about the services Apple supplied to developers, which were not confined to Australia.

283    Consistently with the expert evidence, Epic says that I conducted an analysis of competitive constraints and substitution possibilities that was not limited to Australia. My findings as to the choices available to developers and the constraints their behaviour may place on Apple were, by and large, not geographically tied. This was consistent with Professor Goldfarb’s conceptual evidence, which was accepted by me and is of global application. Epic says that my findings about the relevant product do not admit of a conclusion that the product has a built in geographic limitation.

284    Epic says that my analyses of Apple’s market power and the competitive effects of Apple’s conduct were similarly not tied to iOS users in Australia. Further, in Epic v Google, I concluded that rival app stores are concerned with the ability to compete for global, not only Australian, revenues.

285    Further support for a global frame of reference is found in Epic v Google, where I found that the geographic scope of the payments solution market was likely global, but excluding China.

286    Epic points out that my reasons consistently use the expressions “iOS app distribution services market” and “iOS in-app payment solutions market” without appending the adjective “Australian”. In the key summary of conclusions, I stated that Apple’s restrictions on direct downloading or sideloading had the purpose and effect or likely effect of substantially lessening competition in the iOS app distribution services market, and that its imposition of IAP had the effect or likely effect of substantially lessening competition in the payment solutions market. The same formulations reappear in my closing summary of findings. Those are the markets in which the contraventions are found to have occurred, and the declarations ought to reflect that language.

287    Further, Epic says that the geographic dimension of those markets is already dealt with in my reasons. In relation to the iOS in-app payment solutions market, I said (at [5981]):

Finally, let me just make the separate point that the economic experts agreed that the geographic dimension of the market is at least as wide as Australia. It may be global, save for any countries which have different competitive conditions from Australia, for example, due to applicable regulation. For the purposes of this case it does not make a material difference.

288    Epic says that that observation is equally applicable to the iOS app distribution services market. The economic experts agreed that the geographic dimension of “the relevant market or markets in which to assess the competitive effects of the alleged iOS App Distribution Conduct” was at least Australia.

289    Epic says that those markets are properly characterised as markets in Australia within the meaning of s 4E, because the relevant rivalrous behaviour and demand include Australia, even if the same economic markets extend beyond Australia. And they are not confined, as a matter of economic analysis, to some Australian-only sub-segment of the App Store or to devices linked to Australian Apple IDs.

290    Now stopping at this point for a moment, I largely agree with Epic’s detailed description and arguments, but ultimately this does not avail Epic.

291    As to injunctive relief, Epic says that the orders should not be confined to conduct concerning the Australian App Store storefront and iOS devices associated with an Australian Apple ID. Epic has made the following points.

292    First, I have already found that Apple Inc carries on business in Australia for the purposes of s 5(1)(g). The relevant provisions of the CCA apply to Apple Inc. Apple Inc carries on business within Australia for the purposes of s 5(1)(g). The relevant provisions therefore apply to its conduct outside Australia.

293    Second, by s 5(1)(g), Pt IV including s 46 applies to conduct engaged in outside Australia, by a body corporate that carries on business in Australia. Section 46(1) is directed to conduct of a corporation with a substantial degree of power “in a market” that has the purpose, or has or is likely to have the effect, of substantially lessening competition “in that market”. Section 4E then defines “market” as “a market in Australia”. The combined effect is that s 46 can, and in this case does, catch extraterritorial conduct of Apple Inc which has the proscribed purpose, effect or likely effect in markets in Australia.

294    Third, whether there is a “market in Australia” is a practical, commercial question about where the relevant rivalrous behaviour and demand are located, not a formal question about where contracts are made or services commence. A market may be partly in and partly outside Australia. It is enough that the field of rivalry and the pursuit of customers includes Australia, even if the same economic market extends elsewhere. On my findings, each of the iOS app distribution market and the iOS in-app payment solutions market is a market “in Australia” in that sense, notwithstanding that each may also have a broader geographic dimension.

295    Again I can agree with these three points of Epic but ultimately they do not persuade me to accept the geographic reach of what Epic seeks.

Proposed orders 4 to 6 (iOS app distribution services) — geography

296    Epic says that in relation to proposed orders 4 to 6 (orders 3 to 5 as modified and made) which concern competition in iOS app distribution, I have identified an iOS app distribution market as a market for the supply of app-distribution services. Those services are supplied on both sides of the platform: to developers, by enabling or facilitating their iOS apps to be discovered, downloaded and updated by iOS device users; and to iOS device users, by enabling them to discover, obtain and update iOS apps.

297    Epic says that developers, including Australian developers and non-Australian developers whose apps are, or but for Apple’s restrictive conduct would be, supplied in or into Australia, are customers for iOS app distribution services. They acquire those services from Apple in order to have their apps discovered, downloaded and updated by iOS device users, including users in Australia. But for Apple’s restrictive conduct, Apple and alternative app store operators whether based in Australia or elsewhere would compete to supply those iOS app distribution services to those developers. That rivalrous pursuit of developers as customers forms part of the iOS app distribution market and is competition in a “market in Australia” within the meaning of s 4E, even though the same distribution services are or may be used by those developers to reach users outside Australia.

298    On that footing, Epic says that limiting proposed orders 4 to 6 so that they focus exclusively on iOS device users in Australia, or exclusively on iOS device users associated with an “Australian Apple ID”, rests on flawed assumptions about the relevant markets and would unjustifiably narrow the scope of the injunctive relief.

299    Further, Epic says that on the user side of the platform, the same logic applies. But for Apple’s conduct, alternative app store operators would compete to distribute iOS apps to iOS device users in Australia. The relevant demand is that of iOS device users who are in Australia, whether as residents or as visitors, not that of a subset of users whose Apple IDs happen to be configured in a particular way.

300    Epic says that Apple’s proposed definition of Australian Apple ID is tied to the country/region setting and to the presence of a payment method with an Australian billing address. That formulation necessarily excludes iOS device users physically in Australia whose Apple IDs are associated with non-Australian billing addresses. Epic says that those users are part of the demand-side of the iOS app distribution services market in Australia, and Apple competes, or would but for its own restrictions face competition, for their custom.

301    Epic says that developers and payment solution providers in Australia that supply services in Australia and globally (excluding China), are also part of the supply-side of the iOS app distribution services and iOS payment solutions markets that encompass Australia, where the supply has a relevant impact on competitive rivalry in that market.

302    Epic says that to confine the injunctions to conduct concerning the Australian App Store storefront and iOS devices associated with an Australian Apple ID is therefore to depart from the markets in which the contravention has been found and from the statutory conception of a “market in Australia”. And it would allow Apple to continue to engage in conduct, outside that artificially defined subset of storefronts and Apple IDs, which has a substantial lessening effect on competition in the iOS app distribution services market in Australia. Epic says that that result would be inconsistent with the operation of s 5 and s 4E, and it is not appropriate as a matter of remedial discretion under s 80.

Proposed orders 7 to 9 (iOS in-app payment solutions services) — geography

303    Epic says that parallel considerations arise in relation to the iOS in-app payment solutions market concerning proposed orders 7 to 9 (orders 6 to 8 as modified and made). I accepted Epic’s posited market as a market for the supply of services to app developers for accepting and processing payments for in-app purchases, involving the provision of a payment solution enabling or facilitating app developers to accept and process payments for in-app purchases within an iOS app. Apple’s tying of IAP and its related anti-steering measures have been found to substantially lessen competition in that market.

304    On that footing, Epic says that the primary customers in reality in the iOS in-app payment solutions market are app developers, including Australian developers and non-Australian developers whose apps are, or but for Apple’s restrictive conduct would be, supplied in or into Australia. They acquire in-app payment solutions services so that payments for in-app purchases of digital content in their iOS apps can be accepted, processed and settled for their users. Epic says that but for Apple’s tying and anti-steering conduct, there would be competition to supply those in-app payment solutions services to developers, including in respect of transactions with users both in and outside Australia.

305    Epic says that the rivalrous pursuit of Australian developers, and non-Australian developers whose apps serve iOS device users in Australia, is competition in a “market in Australia” within the meaning of s 4E, even if the same payment solutions are or may be used by those developers to serve users in other jurisdictions.

306    Epic says that it follows that on the developer side, injunctive relief directed to restoring competition in the iOS in-app payment solutions market should not be confined by reference to the Australian App Store storefront or to iOS devices associated with an Australian Apple ID.

Whether Apple’s proposed orders appropriately limited

307    Further, Epic says that Apple’s position and proposed relief leave major gaps.

308    First, Epic says that they do not address the supply of app distribution services to developers participating in the relevant markets in Australia, including Australian-incorporated/domiciled developers and developers whose apps are, or would be but for the contravening conduct, distributed in or into Australia, insofar as those developers distribute apps to users outside Australia, or users not associated with an Australian Apple ID.

309    Second, Epic says that they do not address the supply of app distribution services by Australian app store operators or website operators, insofar as those operators distribute apps to users outside Australia, or users not associated with an Australian Apple ID.

310    Third, Epic says that they do not address the supply of payment solution services to Australian developers, insofar as those developers’ apps are used by users outside Australia, or users not associated with an Australian Apple ID.

311    Fourth, Epic says that they do not address Australian developers that steer users out-of-app to conclude transactions for digital content for use in-app, insofar as those users are outside Australia, or are not associated with an Australian Apple ID.

312    Fifth, Epic says that they do not address the supply of payment solution services by Australian payment solution providers to developers, insofar as those developers’ apps are distributed to users outside Australia, or users not associated with an Australian Apple ID.

313    Sixth, Epic says that in limiting its proposed order l(b) to native iOS apps downloaded from the App Store Australian storefront, Apple excludes apps providing for alternative payment solutions that have been obtained outside the App Store by direct downloading or sideloading.

314    Moreover, Epic says that these omissions would damage, or likely damage, the future state of competition in s 4E markets in Australia. It says that the ability of Australian developers, app store and website operators, and payment solution providers to service international customers within a global market that encompasses Australia will directly affect their ability to compete with Apple, and perhaps others, in the s 4E markets, constraining their growth so they can never achieve scale sufficient to enhance the state of competition in Australia through such advancements as quality and price.

Analysis — what is appropriate?

315    Even if Epic were to establish that making orders in the terms it seeks is within the power enlivened by my findings of contravention, discretionary considerations do not favour relief in the terms sought by Epic. Putting it another way, the geographic reach sought by Epic is not appropriate.

316    I agree with Apple that to grant relief in the global terms sought would have or may have a tendency to interfere with the balances struck by regulators of other states responding to the same conduct, in ways not shown to be necessary to protect competition in the relevant markets in Australia. Generally, I agree with Apple that the grant of relief in the global terms sought by Epic is not “appropriate” within the meaning of s 80.

317    As Apple correctly points out, there are at least three different non–standard iOS app distribution and in-app payment regimes under which Apple is now required to operate.

318    In the US, Apple’s practice of prohibiting distribution of native iOS apps other than through the App Store storefront has been upheld as permissible under US antitrust law, such that alternative app marketplace apps and web distribution are prohibited.

319    In the EU, Apple is required to permit both alternative app marketplaces and web distribution, but is only required to do so on specified conditions, and is permitted to apply a number of security and privacy protections to alternative distribution which Epic’s proposed orders would forbid.

320    In Japan, Apple is required to permit alternative app marketplaces, again on specified conditions and on terms that permit Apple to apply various security and privacy protections, but is not required to permit and does not permit web distribution.

321    In the EU, Japan and South Korea, Apple is required to permit alternatives to IAP, but is permitted to use disclosure screens for users to assess their risk appetite in proceeding with a change to the IAP process in providing their payment details to a source other than Apple, for apps distributed via the App Store.

322    I agree with Apple that if orders were made in the terms proposed by Epic, Apple would be required to alter, reorganise and reconfigure iOS and the tools and APIs which developers use to create, distribute and maintain iOS apps, not only in respect of iOS users using devices associated with the Australian Apple Account, but in effect globally.

323    And as Apple points out, the effect of Epic’s orders would be to forcibly restructure Apple’s supply of products and services, not only in Australia or in respect of iOS device users with an Australian Apple Account, but in respect of each of the 175 geographical regions in which Apple currently operates.

324    I agree with Apple that this would or may inappropriately interfere with the regulatory balances struck and judicial determinations made by other states’ regulators and courts.

325    As Apple points out, in the US, Fortnite, being among the universe of iOS apps which will become available by alternative distribution in Australia, would become accessible to users associated with the US App Store storefront by means of alternative distribution. That is an outcome which US antitrust law, as clarified through Epic’s suit against Apple in California, has not mandated.

326    As Apple points out, in Japan, in relation to iOS users associated with the App Store Japan storefront, to whom web distribution is not currently available, Apple would be required by the operation of my orders to make web distribution available to iOS device users, notwithstanding that Japanese regulators in mandating that Apple make alternative marketplace apps available have not required Apple to permit web distribution.

327    Further, and as Apple points out, in the EU and Japan, in respect of iOS device users associated with App Store storefronts in the EU or Japan, extant EU and Japanese law strictures as to such matters as disclosure screens and fees for alternative payments and distribution would be supplanted by my orders. Conditions on access to alternative app distribution, which Apple has been permitted to apply in these jurisdictions, would be superseded and avoided. If Apple continued to apply those conditions, conformably with the directives of regulators in those jurisdictions, it may violate my orders. Let me be more specific for a moment concerning Japan.

328    In relation to Japan, the Mobile Software Competition Act (MSCA) Guidelines of July 2025 promulgated by the Japan Fair Trade Commission recognise a range of conditions Apple may apply as “justifiable reasons” under Articles 7 and 8 of the MSCA, including cybersecurity reviews of alternative app stores, parental control features restricting minors’ access to alternative app stores, alternative payment services and link–outs, requirements that alternative payment services properly handle payment information and ensure appropriate refund and cancellation procedures and neutral pop–up warnings informing users of the risks of redirection to deceptive or misleading websites.

329    The Commission said (at pp 25 and 26):

D. Understanding Justifiable Reasons

(A) General Principles

For Article 7 and Article 8, Items 1 to 3 of this Act (excluding cases where the specified software under Article 8, Item 3 is a browser), actions deemed necessary for ensuring cybersecurity for smartphone use, protecting information related to smartphone users, safeguarding youth who use smartphones, or achieving other objectives stipulated by the Cabinet Order (prevention of significant delays or other abnormal operations of smartphones (hereinafter referred to as “prevention of abnormal operations of smartphones”) and prevention of gambling and other criminal activities conducted using smartphones (hereinafter referred to as "prevention of criminal activities conducted using smartphones”), as defined in Article 2 of the Cabinet Order for the Mobile Software Competition Act (Cabinet Order No. 376 of 2024, hereinafter referred to as "the Order")) (collectively defined as "Ensuring Cybersecurity, etc.") may qualify as "justifiable reasons" for noncompliance if these objectives are difficult to achieve through other less competition-restricting actions. Even if a designated provider’s action appears to fall under Article 7 or Article 8, Items 1 to 3 of this Act, it will not constitute a violation of Articles 7 and 8 as long as there is an accepted justifiable reason.

(B) Specific Examples of Justifiable Reasons

Specific examples of the objectives for justifiable reasons listed in (A) above are as follows.

These examples are illustrative only, and whether a justifiable reason is recognized requires individual, case-by-case examination.

a. Ensuring cybersecurity for smartphone use refers to ensuring cybersecurity in smartphones as defined in Article 2 of the Cybersecurity Basic Act (Act No. 104 of 2014) (Note 1).

Specifically, this includes:

•    Measures to prevent OS features from being used in a way that harms the smartphone or smartphone user due to unauthorized access by third parties to OS features.

•    Measures to prevent data stored on smartphone devices (e.g., confidential documents, location history on smartphones, authentication information related to multi-factor authentication) from being leaked, lost, or damaged due to unauthorized access by third parties.

•    Measures to prevent smartphone operation from stopping or smartphone performance from significantly deteriorating due to excessive load on smartphone features through the use of OS features (including cases where unauthorized use of Wi-Fi or other networks by third parties results in the cessation or significant deterioration of network features).

•    Measures to prevent data stored on the smartphone device (e.g., photo data, contact data) from being leaked, lost, or damaged due to defects (e.g., those caused by programming bugs) in individual software that accesses OS features on the smartphone.

•    Measures to prevent alternative application stores that do not implement measures against malicious software (malware, ransomware, etc.) from being provided on the basic operation software of a designated provider of basic operation software.

•    Measures to prevent individual software (excluding browsers) that incorporates browser engines without vulnerability countermeasures from being provided in the application stores of designated providers, etc., of basic operation software.

330    Epic’s proposed orders may not allow that second last dot point.

331    The Commission also said (at pp 27 and 28):

c. Safeguarding youth who use smartphones refers to preventing minors from becoming involved in trouble or problems when using smartphones.

Specifically, this includes:

•    Regarding in-app purchases in individual software, measures to establish parental control features in the basic operation software to prevent excessive or erroneous charges by minors, and to restrict the use of all payment systems (including alternative payment systems) by minors based on parental consent.

•    Regarding alternative application stores that provide individual software containing harmful content for minors, measures to establish parental control features in the basic operation software to prevent minors from using such alternative application stores, and to restrict their use by minors based on parental consent.

•    Measures to require alternative application stores to implement appropriate age restrictions (ratings) for individual software or content/features provided through individual software, and to restrict the use of such features, from the perspective of appropriate use by minors.

•    Measures to require alternative application stores to set stricter privacy protection standards for information related to minor smartphone users than for non-minors (e.g., not displaying targeted advertisements based on profiling of information related to minor smartphone users).

332    Epic’s proposed order 7(c)(iii) may not allow for this.

333    The Commission said (at pp 47 and 48):

4. Article 8: Prohibited Conduct by Designated Providers of Application Stores

(1) Item 1 (Prohibition of Restricting or Hindering the Use of Alternative Payment Management Services, etc.)

A. Basic Approach

Article 8, Item 1 of this Act prohibits designated providers of application stores from imposing conditions that prevent individual app providers from using alternative payment management services (i.e., payment management services other than those provided by the designated provider, including its subsidiaries; hereinafter referred to as “designated providers, etc.” in this section) when offering individual software through the application store. It also forbids designated providers from obstructing individual app providers from enabling smartphone users to make payments using other methods without relying on payment management services. By prohibiting actions that restrict the use of alternative payment management services, etc. (meaning either alternative payment management services or other payment methods that individual app providers can offer to smartphone users without utilizing payment management services), this Act aims to enhance competition in individual software by allowing app providers to offer diverse payment services.

334    The Commission said (at pp 58 and 60):

(F) Actions that "Prevent" the Provision of Goods or Services Through Related Web Pages, etc.

Actions that prevent the provision of goods or services through related web pages, etc., refer to conduct that, while not directly prohibiting the display of external promotional information or the provision of link-outs in the terms of use within this individual software, creates a high likelihood of making it difficult to provide goods or services through related web pages, etc., including the display of external promotional information and the provision of link-outs. Such actions include imposing unreasonable technical restrictions on individual app providers, placing excessive financial burdens on them, or steering smartphone users away from obtaining goods or services through related web pages, etc. These actions constitute "preventing" the provision of goods or services through related web pages, etc., if they create a high likelihood of making such provision practically difficult.

The impact of such actions on the likelihood of making provisions difficult is assessed comprehensively based on various factors, including the nature of the designated provider's conduct, the duration of the conduct, the degree to which the conduct affects individual app providers offering goods or services through related web pages, etc., and the extent of impact on smartphone users utilizing the individual software.

C. Hypothetical Scenarios

…

•    Hypothetical Scenario 87: A designated provider, without reasonable grounds, limits the number of displayed link-out destinations or does not allow payment web pages as link-out destinations (excluding the use of pop-up displays that provide explanations, using neutral expressions, about transitions to external websites when tapping the link).

335    The Commission said (at pp 61 and 62):

D. Hypothetical Scenarios of Justifiable Reasons

Based on the basic understanding of the applicability of justifiable reasons in 3 (1) D above, hypothetical scenarios where justifiable reasons are typically recognized and do not constitute violations, and hypothetical scenarios where justifiable reasons are typically not recognized and constitute violations, are as follows:

(A) Hypothetical Scenario Where Justifiable Reasons are Accepted and Not Considered Violations

Hypothetical scenarios of actions that are typically recognized as having justifiable reasons and are not considered violations of Article 8 include the following:

Hypothetical Scenarios:

•    Hypothetical Scenario 93: A designated provider, as a provider of basic operation software and an application store, displays a pop-up using neutral expressions warning smartphone users that clicking on a link-out may redirect them to external websites that mimic legitimate ones in an attempt to deceive users or cause misunderstandings, and informs users that once redirected, the designated provider no longer controls the external website, because the designated provider cannot control the risk of smartphone users being redirected to such deceptive or misleading websites via link-outs. This action, while potentially causing smartphone users to abandon transitioning to external websites via link-outs and thus hindering the provision of goods or services on external websites, contributes to the prevention of criminal activities conducted using smartphones. Furthermore, if the content of the pop-up warning users, using neutral expressions, about the risk of being involved in fraudulent activities if they transition to an external website via a link-out is factual, is not discriminatory towards individual app providers, is limited to the necessary scope in light of its purpose, and if the designated provider has no way to control such risks or no more effective way to convey the content to users, it is considered that there are no other means to achieve that purpose. Therefore, a justifiable reason is recognized, and it does not violate Article 8 of the Act.

336    Epic’s proposed orders may be against hypothetical scenario 93. Epic’s proposed orders 6(a), (e), (h), (i) and 11(a) (orders 5(a), (e), (h), (i) and 10(a) respectively as made and modified) may preclude these protections.

337    So in summary and in terms of what I consider to be “appropriate” and/or in the exercise of my discretion, it seems to me that the appropriate balance is struck by limiting my orders to the Australian App Store and users with an Australian Apple Account. And in that respect let me make the following points.

338    First, this limitation is consistent with focusing on markets in Australia and competition in such markets.

339    Second, my orders will specifically allow for the participation of developers wherever they are in the world and payment solution providers wherever they are in the world, with consequential benefits to Australian users.

340    Third, Epic poses the question: what about visitors to Australia who do not have an Australian Apple Account? But this is down in the weeds. If they are here long enough they can get one. It is their choice if this is significant enough to them. Further, Epic asks the question: what about Australian users abroad? But again, the fact that they may have to use an international Apple Account and so may not get similar access is a matter for them.

341    Fourth, Epic makes some fair points about Australian developers, app store operators, website operators and payment solution providers who may want to extend their reach beyond Australia to international users which, if achieved, may strengthen their position in the Australian markets. That is all true, but a line needs to be drawn which is appropriate and which I have drawn.

342    Let me now turn to the question of intellectual property rights.

The relevance of Apple’s intellectual property rights

343    I made it clear in my liability judgment that intellectual property rights are not a shield against the operation of the CCA in the sense of their exercise being used as a basis for immunising a party from the operation of s 46 or their existence being used as a basis to deny an appropriate remedy for such a contravention.

344    In NT Power Generation Pty Ltd v Power and Water Authority (2004) 219 CLR 90 it was accepted that coercive supply can be an appropriate remedy for misuse of market power. And in context it was recognised that s 46 can be attracted by two distinct types of conduct in relation to intellectual property being either the refusal to supply intellectual property, or the supply of it on particular conditions. It was said by the majority (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.

(footnotes omitted)

345    Now in the present case I found that Apple contravened s 46 in prohibiting the sideloading of native apps from sources other than the App Store and prohibiting payment methods for in app-purchases other than IAP.

346    But Apple says that I did not find that Apple contravened s 46 by refusing to licence the software that developers use to develop apps, which is currently licensed by the DPLA. In the language of NT Power, Apple says that the contravention occurred by the supply of Apple’s software on particular conditions, not because of a refusal to supply that software. So, I said at [5305]:

I agree with Epic that on the evidence, in a counterfactual that removes the impugned conduct, there is at least a realistic chance that Apple would license its intellectual property in a way that would permit alternative modes of iOS app distribution.

347    Apple says that my findings justify relief directed to Apple’s prohibition on sideloading and alternatives to IAP. But it says that my findings do not give rise to a right on the part of Epic or developers generally to a compulsory licence of Apple’s software. Further, Apple says that my findings do not give rise to a right to a licence on any particular terms, so long as those terms do not prohibit sideloading or alternatives to IAP.

348    Further, Apple says that there is no statutory regime generally providing for the compulsory licensing of software in the Copyright Act 1968 (Cth); as Apple says, one can compare this with ss 133 to 136A of the Patents Act 1990 (Cth) which deal with the compulsory licensing of patented inventions. I should say here that I accept that the regime dealt with under Part VI of the Copyright Act dealing with collective licensing organizations (see the s 136(1) definition of “licensor”), licensing schemes and the powers given to the Copyright Tribunal under s 157 is not of any present relevance; for a summary of this regime see Copyright Agency Ltd v Isentia Pty. Ltd. (2022) 405 ALR 619 at [5] to [12] per Jagot, Beach and Burley JJ.

349    Now Apple characterises Epic’s proposed orders in the following terms.

350    Apple says that proposed order 3(c) (order 2(c) as modified and made) is a compulsory licence for Epic of Apple’s tools and APIs including SDKs required for the development, distribution and updating of the Fortnite app and/or other apps developed by Epic for macOS and iOS.

351    It says that proposed orders 4(a) and (b) (orders 3(a) and (b) as modified and made) would provide a compulsory licence for all developers of all tools and APIs including software development kits necessary for developers to develop and distribute iOS apps, including alternative app stores, on the same terms as tools and APIs are made available to developers who distribute apps via the App Store.

352    It says that proposed order 4(c) (order 3(c) as modified and made) is a compulsory licence for iOS device users of software necessary to discover, download, install or update apps via alternative distribution channels on the same terms as tools and APIs are made available to users of apps distributed via the App Store.

353    It says that proposed order 5(a)(i) (order 4(a)(i) as modified and made) would in effect impose a compulsory licence for developers by enjoining Apple from prohibiting, preventing or taking any action, including imposing a fee or condition, which is likely to hinder access to any tool or API including software development kits necessary for developers to develop and distribute iOS apps and which are available to developers distributing iOS apps via the App Store.

354    It says that proposed order 5(a)(ii) (order 4(a)(ii) as modified and made) would in effect impose a compulsory licence by enjoining Apple from prohibiting, preventing or taking any action, including imposing a fee or condition, which is likely to hinder access to any tool or API including software development kits necessary for developers to develop iOS apps that are capable of creating an interface for displaying iOS apps and which may be used by an iOS user to discover, download, install and update iOS apps.

355    It says that proposed order 5(a)(iii) (order 4(a)(iii) as modified and made) would in effect impose a compulsory licence for iOS users by enjoining Apple from prohibiting, preventing or taking any action, including imposing a fee or condition, which is likely to hinder access to any tool or API including software development kits necessary for iOS users to discover, download, install and update apps via alternative distribution channels.

356    It says that whilst not compulsory licences, proposed orders 6(b) and 11(b) (orders 5(b) and 10(b) as modified and made) would regulate the fees that Apple can charge for licensing its software to developers using alternative distribution channels, including by preventing the imposition of fees that are higher than those charged to developers of other types of apps, who are currently charged only the annual developer fee.

357    It says that proposed order 6(b) would prevent Apple from imposing any fee or condition on a licence of any software tool, API or SDK necessary for app developers to develop and distribute iOS apps via alternative distribution channels that have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via those channels. It says that this prohibition extends to imposing any fees higher, or conditions more onerous, than those applied to free apps and apps monetised through advertising, distributed via the App Store, which are currently charged only the annual developer fee. In other words, Apple says that unless it decides to increase the fee that it charges to developers of apps that are free or monetised through advertising and distributed via the App Store, proposed order 6(b) would prevent Apple from charging developers using alternative distribution channels any fee higher than the current annual developer fee. Generally, Apple says that there is no basis in the judgment for imposing such a restriction on Apple’s licensing of its copyright works. It says that it would conflict with Apple’s normal exploitation of its copyright works including licensing for a fee and prejudice Apple’s legitimate interests as the owner of those works. And it says that proposed order 6(b) would also be anti-competitive and adverse to the interests of consumers and developers of free apps.

358    Further, Apple says that proposed order 11(b) would prevent Apple from imposing any fees or conditions on the licence of any software tool, API or software development kit necessary for app developers to develop and distribute iOS apps that enable payment methods other than IAP, if such fees and conditions do not apply with respect to apps distributed via the App Store which enable in-app purchases of physical goods or services using a payment method other than IAP. Now at present, Apple does not impose any fees or particular conditions on apps that allow the purchase of physical goods which may not use IAP. As such, Apple says that proposed order 11(b) would appear to prevent the imposition of any fees or particular conditions on the licence of any software tool, API or SDK necessary for app developers to develop or distribute iOS apps that enable payment methods other than IAP, unless Apple were to increase fees payable by developers of apps that allow the purchase of physical goods.

359    Generally, Apple says that there is no basis in my judgment for any of the above orders to be made.

360    Further, Apple says that the orders proposed by it are preferable to those proposed by Epic because they preserve Apple’s freedom to deal with its own intellectual property in terms of its protected tools and technology, whilst preventing any continuation or repetition of the contraventions that I have found. In this respect Apple points to some evidence concerning alternative app distribution given by Mr Zachary Friedland, whose factual description I largely accept. I will say something more about Mr Friedland’s position and his detailed technical evidence much later.

361    Apple was required to develop updated versions of iOS so that iOS could access the new APIs and other technologies that enable alternative app distribution. It was necessary for iOS users in the EU and Japan to download an updated version of iOS in order to use alternative app distribution, and it was not technically possible to provide alternative app distribution to users who did not update the version of iOS on their device.

362    Now in updating the version of iOS on their devices, users make a copy of a new copyright work. That new copyright work, as well as the new APIs and other new or modified SDKs and software programs, are licensed to developers under the DPLA for use in developing and testing apps.

363    Mr Friedland also explained that Apple makes pre-release versions of iOS updates available to developers in order to test the new functionalities and APIs. Those pre-release versions are similarly copyright works licensed to developers under the DPLA for use in developing and testing apps.

364    Further, the updated iOS SDK now comprises the MarketplaceKit Framework. SDKs typically comprise a number of frameworks, which are a structured bundle or directory comprising a code library, image files, header files, reference documentation and APIs that are published within the framework. The MarketplaceKit Framework enables developers to create an alternative app marketplace that can function on iOS devices and facilitates installations, downloads, and updates of apps made available on alternative app marketplaces. In order to use the MarketplaceKit Framework, developers must download the updated version of the iOS SDK, making a copy of the SDK on their computer and reproducing the copyright works that comprise the SDK and the MarketplaceKit Framework specifically, such as the code in the code library, image files, header files, reference documentation and API documentation. Developers’ use of code from a code library or image files involves making further copies of those copyright works. In at least some instances, developers’ use of header files and APIs also involves reproducing Apple code. I will return to discuss the MarketplaceKit Framework in more detail later.

365    The App Licence Delivery software tool is an example of software that Apple developed and licensed to developers, in order to facilitate alternative app distribution. The App Licence Delivery software tool works with Apple’s digital rights management and content protection system known as Fairplay. In order for an app that has been installed on an iOS device to run, Fairplay uses cryptography to confirm that the user is presently entitled to use the app. That was an existing system used by the App Store that was extended and packaged into the App Licence Delivery tool to make equivalent functionality available to developers using alternative app distribution. The App Licence Delivery software tool has an associated SDK. To use the App Licence Delivery software tool and the associated SDK, developers download them from the Apple developer website, so making a copy of the copyright works comprising the software tool and the SDK.

366    Further, in order to enable alternative app distribution, Apple developed alternative distribution packages (ADPs). Apple’s systems generate an IPA file for each specific operating system and device. An IPA is an electronic package file which comprises everything that is needed for an Apple device to install an app. I should note that an “IPA” is more jargon than acronym. IPA files are used for App Store distribution such that the developer does not require a licence of Apple’s code that has been incorporated into the IPA file, because it is Apple that makes the IPA files available for downloading. Developers download ADPs, and the IPAs packaged in them to their own servers to make them available to users to download via alternative distribution. In doing so, developers use the copyright in Apple’s code that has been incorporated into the IPAs and the ADPs.

367    Mr Friedland’s evidence also discussed numerous new APIs that have been developed in order to facilitate alternative app distribution and in-app payment solutions, including the MarketplaceAppExtension APIs, the External Purchase APIs, and others. I will elaborate on the concept of MarketplaceAppExtension later. I have found that Apple’s APIs are a valuable resource and their use may involve reproducing Apple code and so a copyright work and likely also using Apple’s confidential information.

368    It is convenient now to address another topic concerning Apple’s reference to some international treaties. Let me identify at this point some relevant provisions before addressing the parties’ arguments.

Some international treaties

369    Australia is a party to several treaties that require it to respect the exclusive rights of intellectual property owners, including the Berne Convention for the Protection of Literary and Artistic Works of 9 September 1886, as revised [1978] ATS 5, the Agreement on Trade–Related Aspects of Intellectual Property Rights (TRIPS) being annexure 1C to the Marrakesh Agreement establishing the World Trade Organisation [1995] ATS 8, and the World Intellectual Property Organisation Copyright Treaty (Geneva, 20 December 1996) [2007] ATS 17.

370    Membership of the Berne Convention and TRIPS is near–universal and membership of the WIPO Copyright Treaty is also widespread. Australia, the United States, Japan and all countries in the EU are parties to all three treaties.

371    Articles 9(1) and (2) of the Berne Convention provide:

(1)    Authors of literary and artistic works protected by this Convention shall have the exclusive right of authorizing the reproduction of these works, in any manner or form.

(2)    It shall be a matter for legislation in the countries of the Union to permit the reproduction of such works in certain special cases, provided that such reproduction does not conflict with a normal exploitation of the work and does not unreasonably prejudice the legitimate interests of the author.

372    By article 2(6) the protections of the Berne Convention extend to authors and their successors in title. Article 4 of the WIPO Copyright Treaty and article 10(1) of TRIPS both provide that computer programs will be protected as literary works for the purposes of the Berne Convention.

373    Article 9(2) of the Berne Convention provides that member countries’ legislation may permit the reproduction of literary works in “certain special cases”, provided that the reproduction “does not conflict with a normal exploitation of the work and does not unreasonably prejudice the legitimate interests of the author”. Equivalent provisions are found in article 10 of the WIPO Copyright Treaty and article 13 of TRIPS.

374    Articles 10(1) and (2) of the WIPO Copyright Treaty provide:

(1)    Contracting Parties may, in their national legislation, provide for limitations of or exceptions to the rights granted to authors of literary and artistic works under this Treaty in certain special cases that do not conflict with a normal exploitation of the work and do not unreasonably prejudice the legitimate interests of the author.

(2)    Contracting Parties shall, when applying the Berne Convention, confine any limitations of or exceptions to rights provided for therein to certain special cases that do not conflict with a normal exploitation of the work and do not unreasonably prejudice the legitimate interests of the author.

375    In article 13 of TRIPS, limitations are expressly limited to those that do not prejudice the legitimate interests “of the right holder”. Article 13 provides:

Members shall confine limitations or exceptions to exclusive rights to certain special cases which do not conflict with a normal exploitation of the work and do not unreasonably prejudice the legitimate interests of the right holder.

376    Further, article 40 of TRIPS specifically allows for legislation concerning intellectual property “licensing practices or conditions” that may have an “adverse effect on competition in the relevant market”, provided that such measures are adopted “consistently with the other provisions of this Agreement”. Articles 40(1) to (4) provide:

(1)    Members agree that some licensing practices or conditions pertaining to intellectual property rights which restrain competition may have adverse effects on trade and may impede the transfer and dissemination of technology.

(2)    Nothing in this Agreement shall prevent Members from specifying in their legislation licensing practices or conditions that may in particular cases constitute an abuse of intellectual property rights having an adverse effect on competition in the relevant market. As provided above, a Member may adopt, consistently with the other provisions of this Agreement, appropriate measures to prevent or control such practices, which may include for example exclusive grantback conditions, conditions preventing challenges to validity and coercive package licensing, in the light of the relevant laws and regulations of that Member.

(3)    Each Member shall enter, upon request, into consultations with any other Member which has cause to believe that an intellectual property right owner that is a national or domiciliary of the Member to which the request for consultations has been addressed is undertaking practices in violation of the requesting Member's laws and regulations on the subject matter of this Section, and which wishes to secure compliance with such legislation, without prejudice to any action under the law and to the full freedom of an ultimate decision of either Member. The Member addressed shall accord full and sympathetic consideration to, and shall afford adequate opportunity for, consultations with the requesting Member, and shall cooperate through supply of publicly available non-confidential information of relevance to the matter in question and of other information available to the Member, subject to domestic law and to the conclusion of mutually satisfactory agreements concerning the safeguarding of its confidentiality by the requesting Member.

(4)    A Member whose nationals or domiciliaries are subject to proceedings in another Member concerning alleged violation of that other Member's laws and regulations on the subject matter of this Section shall, upon request, be granted an opportunity for consultations by the other Member under the same conditions as those foreseen in paragraph 3.

377    Further, I should also note article 1(1) of TRIPS which provides:

(1)    Members shall give effect to the provisions of this Agreement. Members may, but shall not be obliged to, implement in their law more extensive protection than is required by this Agreement, provided that such protection does not contravene the provisions of this Agreement. Members shall be free to determine the appropriate method of implementing the provisions of this Agreement within their own legal system and practice.

378    And I should also note that articles 8(1) and (2) of TRIPS provide:

(1)    Members may, in formulating or amending their laws and regulations, adopt measures necessary to protect public health and nutrition, and to promote the public interest in sectors of vital importance to their socio-economic and technological development, provided that such measures are consistent with the provisions of this Agreement.

(2)    Appropriate measures, provided that they are consistent with the provisions of this Agreement, may be needed to prevent the abuse of intellectual property rights by right holders or the resort to practices which unreasonably restrain trade or adversely affect the international transfer of technology.

379    I will say something about the Australia–US Free Trade Agreement (Washington, 18 May 2004) later.

Apple’s arguments based on these treaties

380    Now because I found that Apple’s prohibitions on alternative app distribution via direct downloading and alternative app stores contravene s 46, that conduct can be enjoined in Australia, consistent with Australia’s obligations under the Berne Convention, the WIPO Copyright Treaty and TRIPS.

381    But Apple submits that other aspects of Epic’s proposed injunctions would, if made, put Australia in breach of its obligations under the Berne Convention, TRIPS and the WIPO Copyright Treaty.

382    Apple says that Epic’s proposed orders seek to impose terms upon Apple’s licensing of its IP-protected software, tools and technologies that go far beyond enjoining the prohibition of alternative app distribution and alternative payment solutions. In doing so, Apple says that they seek to prohibit Apple from licensing its proprietary software on terms that have not been found to contravene the CCA. Apple says that that would conflict with its normal exploitation of the copyright in its software and other copyright works and prejudice its legitimate interests as the owner of that copyright. So, Apple says that Epic’s proposed injunctions are not consistent with Australia’s obligations under the Berne Convention, TRIPS and the WIPO Copyright Treaty.

383    Further, Apple says that the lack of any geographic limitation in Epic’s proposed injunctions also offends Australia’s obligations under the Berne Convention, TRIPS and the WIPO Copyright Treaty. It says that those treaties allow for members to include exceptions to copyright owners’ rights in their national legislation, in “certain special cases” that do not conflict with the normal exploitation of the work or unreasonably prejudice the copyright owner’s legitimate interests. And Apple had to accept that one particular type of exception recognised in article 40 of TRIPS is members’ legislation regarding licensing practices that have an “adverse effect on competition in the relevant market”. But Apple says that that exception, and the more general exceptions for “certain special cases” in article 9 of the Berne Convention and article 10 of the WIPO Copyright Treaty, should not be understood to extend to Australia regulating the terms on which Apple licenses its copyright so that iOS apps may be developed and then distributed in markets outside Australia. It says that for the purposes of article 40, for example, the “relevant market”, which state parties may regulate, is plainly their own national market, not a global or international market.

384    Further, Apple says that the same licence conditions that I have found to contravene the CCA have been found not to contravene US antitrust law. Apple says that this underscores why a contravention of one State party’s competition law would not be understood to give rise to an entitlement under article 40 of TRIPS to regulate Apple’s copyright licensing on an international or global basis.

385    Generally, Apple says that Epic’s proposed orders would inappropriately interfere with other States’ intellectual property laws by imposing compulsory licences of global territorial scope in conflict with other States’ laws that enshrine Apple’s exclusive rights as a copyright owner. And in particular, Apple says that Epic’s global compulsory licences would conflict with US copyright law, which grants Apple exclusive rights in those copyright works, as well as the copyright laws of other states that also provide for those exclusive rights in their own intellectual property laws consistent with their obligations under the Berne Convention, TRIPS and the WIPO Copyright Treaty.

Analysis

386    Now as I have already indicated, Apple in the present case seeks to characterise the contravening conduct as the supply of Apple’s intellectual property on particular conditions, rather than as any refusal to supply that intellectual property. Apple says that the contraventions found by me consist only in a prohibition on the sideloading native iOS apps from sources other than the App Store and a prohibition on the use of payment methods other than IAP for in-app purchases of digital content.

387    Given the contraventions so framed, Apple says that my findings justify only relief directed to removing those prohibitions, and do not support what it describes as any compulsory licence or right to a licence on particular terms, because the contravening conduct did not involve a refusal to supply IP.

388    Now as Epic correctly says, underpinning this position is the enthymematic fallacy that for the purposes of my remedial powers Apple’s conduct must be divided into two mutually exclusive categories. The first category is conduct that prohibits the sideloading of native iOS apps and the use of third party payment solutions for in-app purchases of digital content. The second category is ancillary conduct that could or did assist those prohibitions, including Apple’s ability to withhold the tools, technologies and supporting IP necessary for those alternatives to function.

389    Now Apple contends that my findings justify relief directed only to the first category, but not the second category. But I would reject Apple’s position.

390    First, dividing Apple’s contravening conduct into direct prohibitions and supposedly ancillary measures is inconsistent with my findings as to the practical manner in which Apple has foreclosed competition in the relevant markets. I accepted that the use of Apple’s tools and technology, supported by Apple’s IP, is essential in order for a developer to distribute native apps and digital in-app content on iOS devices. I also found that unless legally compelled to do so, Apple has never licensed those tools, technologies or supporting IP to enable the distribution of apps or the conduct of in-app transactions for digital content outside its walled garden. So, the prohibitions on sideloading and on third party payment solutions did not operate in isolation. They were reinforced and made effective by terms which enabled Apple to withhold the tools, technologies and supporting IP necessary for sideloading and third party payment solutions to operate in practice. It is the way in which this intricate web of terms and technical measures operate together to foreclose competition in the relevant markets that I found contravenes s 46.

391    Apple seeks to constrain, at a practical level, my power to remedy the contravening conduct. But I am not confined to granting relief which merely removes specific prohibitions. Section 80 permits me to formulate the appropriate injunctive relief to suit the needs of the case. Apple’s narrow form of relief would leave it free to engage in conduct that would render my orders ineffective. Contrastingly, the orders proposed by Epic respond directly to the way the contravening conduct operates in practice, including Apple’s use of its IP, tools and technologies as part of the overall foreclosure mechanism.

392    Second, Apple relies on NT Power at [85] to suggest that a refusal to supply is a distinct category of conduct from supply on conditions, and that it necessarily follows that distinct remedial consequences attach to each refusal to supply may, on Apple’s case, support an order in the nature of coercive supply, whereas supply of IP on particular conditions may only be remedied by injunctions directed at those conditions. And that artificial dichotomy underpins Apple’s contention that I cannot grant relief in the nature of coercive supply.

393    But s 46 can be attracted by either conduct consisting of a refusal to supply IP or conduct consisting of supply on particular conditions. And I agree with Epic that what was said in NT Power at [85] does not purport to classify those as distinct species of contravention to which different and limited remedies attach. As I have already held, if the conduct of a corporation in respect of a market otherwise satisfies the terms of s 46, the corporation thereby commits a contravention, a consequence of which might include an order requiring the contravener to give competitors access to its property.

394    Once a contravention of s 46 is established my remedial powers are relevantly governed by s 80, which is concerned with whether the proposed orders are appropriate to prevent, restrain or remedy the contraventions and their effects. Section 80 is not confined to orders that mirror, in form, the precise way in which the contravention was committed.

395    I agree with Epic that nothing in NT Power prevents me from making orders in the nature of coercive supply in an appropriate case, even if one were to accept Apple’s characterisation of the conduct as the supply of IP on particular conditions, and not a refusal to supply IP.

396    Third, Apple’s submission also mischaracterises my findings about the ways in which Apple licenses its IP. I found that Apple contravened s 46 by imposing and enforcing contractual conditions that prevent app distribution other than through the App Store, and equivalent conditions. Those terms are contained in instruments such as the DPLA and its schedules. By contrast, the intellectual property on which Apple now relies is licensed through separate contractual arrangements which I found were exogenous to the DPLA.

397    The Xcode agreement authorises developers to substantially reproduce “Apple Software”, comprising Xcode, Apple SDKs and Apple APIs including any SDKs or APIs that may be necessary for a developer to use in the development of an iOS app, in the executable code of apps developed for inter-alia iOS. Apple’s Xcode is the default integrated development environment being a software application for developing apps for Apple devices.

398    The iOS Software Licence Agreement authorises iOS device users to reproduce Apple Software by downloading and installing apps on an iOS device, thereby creating a copy of the apps’ executable code.

399    I concluded that Apple’s existing IP licensing arrangements are exogenous to the DPLA and likely would, absent the impugned conduct, permit alternative modes of iOS app distribution. Further, as I have indicated in my liability reasons, schedule 2 to the DPLA imposes conditions on developers who choose to offer in-app purchases of digital goods. But schedule 2 does not apply to developers who monetise their apps in other ways, even though those developers use the same Apple software in the same manner. And as I found, the 30% service fee required by schedule 2 is not a licence fee in respect of any Apple IP. For the same reason, the conditions in schedule 2 are not conditions in respect of any IP licence. Developers who monetise through other models can continue to use the same IP in an identical way without accepting those conditions.

400    Now Apple’s position appears to be that whilst its contravention of s 46 justifies injunctions restraining Apple from preventing or prohibiting the direct downloading of native iOS apps and from preventing or prohibiting developers and users from using payment methods other than IAP, my liability findings otherwise leave Apple free to exploit its IP rights as it sees fit, including by withholding the tools, technology and supporting IP that I have found are essential to iOS app development and distribution, and also essential to the incorporation of software features in an iOS app to facilitate the use of alternative payment methods.

401    But Apple could reproduce the same substantial lessening of competition by shifting from what it appears to characterise as a supply on exclusionary conditions, to outright refusal to supply the necessary IP and tools. But I have already rejected Apple’s case theory that because it holds exclusive rights over certain broadly asserted intellectual property it is thereby free to exploit those rights as it sees fit.

402    In my view Epic’s proposed relief explicitly preserves Apple’s ability to continue to license its tools and APIs for the development of iOS apps and to impose lawful fees or conditions for the use of that IP.

403    What the orders would prevent is Apple using its IP licensing arrangements as a means of recreating the circumstances or conditions that I have found to contravene s 46. Given Apple’s foreshadowed threat to replicate the impugned conduct through a complete or constructive refusal to license its IP, it is appropriate to frame the injunctions so that Apple must provide access to the relevant IP in a manner that does not have the exclusionary purpose or effect identified in the reasons. Failing to do so would leave Apple at liberty to avoid my remedies by declining to license that IP at all, or by licensing it only on terms that would perpetuate the same substantial lessening of competition.

404    Fourth, Apple contends that in determining relief I should have regard to the absence in the Copyright Act of a general compulsory licensing regime of software copyright, beyond specified collective licensing regimes. But Epic’s proposed orders are not a compulsory licence as such and nor do they confer on Epic or any other developers any free-standing proprietary rights in Apple’s copyright. And to the extent that certain orders require Apple to continue making available its tools and APIs, they are orders in the nature of coercive supply of the kind recognised as permissible in NT Power and in my reasons. The orders Epic seeks do not establish a free-standing compulsory licensing regime for software. They enjoin Apple from deploying or restructuring its IP licensing arrangements in a way that would allow the recurrence of, or continuing effects from, the contravening conduct.

405    Now as I have discussed previously in my liability reasons, s 51(1)(a) together with the repeal of former s 51(3) make clear that Parliament did not intend intellectual property rights to provide a broad shield to contraventions of Pt IV. That result is beyond doubt following the repeal of s 51(3). But in any event s 51(3) never applied to contraventions of s 46.

406    Once Apple’s use of its IP including copyright has been found to form part of its misuse of market power in markets in Australia, the remedial response is governed by the CCA.

407    Now I have found that the use of Apple’s property is essential for a developer to create native iOS apps, and that in order to distribute such apps and digital in-app content on iOS devices, third parties require permission to access and use a suite of tools and technologies offered by Apple, supported by Apple’s IP.

408    To grant appropriate remedies for Apple’s misuse of market power, it is therefore necessary to make orders ensuring that the necessary tools and technologies are licensed in a way that permits the development and distribution of iOS apps and in-app content via alternative modes of distribution. I should not now make orders that would leave scope for Apple to refuse to license the IP necessary to remedy its contraventions of s 46, or to license it on terms that would have the same or similar effect as the impugned conduct.

409    Further, Apple wrongly submits that Epic’s proposed orders would have the effect of eliminating or severely curtailing Apple’s ability to seek compensation for tools, technologies and services it provides in the Australian market. The true position is that Epic’s proposed orders only prevent Apple from using fees, conditions and technical dependencies to hinder developers’ practical freedom to use alternative app distribution channels or payment methods.

410    Epic’s proposed relief does not eliminate Apple’s ability to seek compensation for the use of its intellectual property. I have already found that Apple’s intellectual property licensing terms are exogenous to the restrictive terms, and likely would, absent the impugned conduct, permit alternative modes of iOS app distribution.

411    Epic’s proposed orders preserve Apple’s ability to license its tools and APIs: proposed orders 6(b), 6(k), 10(e), 11(b) (orders 5(b), 5(k), 9(e) and 10(b) respectively as modified and made). What they curtail is Apple’s ability to impose fees or conditions in ways that would, in practice, perpetuate the impediments to competition already found by me. This is not a hypothetical concern. As I found, in the European Union, Apple’s core technology fee and the restrictions implemented more generally in response to the Digital Markets Act (Regulation (EU) 2022/1925) (DMA) were designed to dissuade developers from taking up alternative payment solutions. I will deal further with the DMA later in my reasons.

412    Further, as to Epic’s proposed orders 10(b) and 10(d) (orders 9(b) and 9(d) as modified and made). The former relates to reporting and audit rights in respect of transactions processed using an alternate payment method, while the latter relates to the payment of fees to Apple in connection with transactions for digital content for use in apps distributed via an alternative channel. Apple submits that those orders would effectively prohibit Apple from seeking compensation for the value of its tools, technologies and services provided to developers in respect of apps and payments made via alternative channels. But proposed orders 10(b) and 10(d) do not prevent Apple from licensing its tools and APIs, or from obtaining lawful remuneration for use of those tools and APIs, nor for services which Apple actually provides. The order only relates to specific commercial transactions, between parties that do not include Apple, in circumstances where Apple is not providing the relevant payment service.

413    My findings support the conclusion that imposing fees on those transactions deters the uptake of alternative payment solutions, rather than compensates Apple for any service it provides.

414    In that limited way, Epic’s proposed orders rule out one anti-competitive method by which Apple might choose to monetise its intellectual property. But that limitation does not prevent Apple from monetising its intellectual property otherwise than by “taxing” transactions that take place between developers and users for the purchase of digital content, but not physical goods or services, via a payment method which is not supplied by Apple. The existence of that narrow limitation is not a sound objection to the relief sought. It is necessary to prevent Apple from relocating its anti-competitive restrictions to the conditions that govern the licensing of and access to tools, APIs and functionality that are essential if competition is to emerge in the payments market.

415    Contrastingly, Apple’s proposed orders would leave it free to impose “reasonable terms” on access to the tools and APIs necessary to enable alternative iOS app distribution and payment methods: Apple’s proposed orders 2(b) and 3(b). Apple would thereby be able to use its control over access to its intellectual property and developer tools to continue hindering or preventing competition in practice. I do not propose to grant relief which leaves Apple with a very broad latitude to determine what “reasonable” terms it will impose for access to the tools and APIs necessary to distribute iOS apps via alternative channels or to use alternative payment methods for the purchase of digital content.

416    Further, Epic’s proposed orders would not put Australia in breach of treaty obligations. Article 40 of TRIPS is titled “Control of Anti-competitive Practices in Contractual Licences”. In article 40(1), Members agree that licensing practices or conditions that restrain competition “may have adverse effects on trade”. Article 40(2) then preserves members’ power to adopt “appropriate measures to prevent or control” practices that have an “adverse effect on competition in the relevant market”.

417    Section 80 is such a measure and it empowers me to make orders remedying serious and prolonged contraventions of s 46 and preventing Apple from achieving the same anti-competitive outcomes via alternative means. In this regard, it is also to be recalled that I held (at [1431]) that 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”.

418    Finally, article 8(2) of TRIPS affirms that “[a]ppropriate measures ... may be needed to prevent the abuse of intellectual property rights by right holders”. The word “abuse” maps onto my finding that Apple has misused its market power, much of which derives from its IP rights.

419    I said at [1362], [1363] and [1385]:

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.

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.

…

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.

420    The three–step test in article 13 of TRIPS, article 9(2) of the Berne Convention, and article 10 of the WIPO Copyright Treaty governs legislated limitations and exceptions to exclusive rights. An order under s 80 is not such a limitation or exception. In any event, the test is satisfied.

421    The proposed orders address a certain special case being identified contravening conduct in identified markets. They do not conflict with any normal exploitation of Apple’s copyright. The concept of “normal exploitation” does not include modes of exploitation that a court has determined must be addressed to remedy the effects of a contravention of competition law, nor modes of exploitation that, in my assessment of Apple’s conduct, would risk being deployed to reproduce the anti-competitive effects of the conduct that I have found to contravene s 46.

422    And nor do they unreasonably prejudice Apple’s legitimate interests. Any order will, ex hypothesi, be one that I have found to be appropriate, and therefore reasonable, to remedy Apple’s contravening conduct and its effects and to prevent its continuation, whether in the same or a different guise. Apple has no such legitimate interest.

423    Further, Apple says that the absence of a geographic limitation in Epic’s proposed orders offends Australia’s treaty obligations. But article 40(2) of TRIPS does not exclude legislation that may operate on or in respect of a market that includes, but which is not confined to, Australia. Apple’s contrary reading is inconsistent with the object and purpose of article 40(1), which recognises that anti-competitive licensing practices “may have adverse effects on trade”, that is, on commerce across borders. Further, the fact that Apple’s restrictive terms have not been found to contravene US antitrust law is irrelevant. Article 1(1) preserves members’ freedom to implement TRIPS “within their own legal system and practice”. And as Epic points out, differences in competition enforcement across member states are the premise of article 40, not an objection to its operation. But I do not need to linger further on the geographic limitation question given that, as against Epic’s position, I am going to impose a geographic limitation on the users and the App Store in the orders that I make.

424    Further, even if I was satisfied that Epic’s proposed orders would put Australia in breach of the TRIPS, the Berne Convention or the WIPO Copyright Treaty, Apple identifies no mechanism by which that conclusion would operate as a constraint on my power under s 80. Despite some commentary both vain and in vain from top down academic types who would wish or pretend otherwise, treaties unincorporated by legislation do not form part of Australian domestic law. Although statutes should be construed consistently with such obligations where a constructional choice is available, Parliament may legislate inconsistently with international obligations. Section 80 confers a broad discretion in terms that admit of no constructional choice to be made by reference to the treaties that Apple identifies. Moreover and as I have said, the repeal of s 51(3) removed the only IP-specific carve-out from Part IV, and s 51(3) never applied to s 46 in any event. Apple’s tendentious treaty entreaties go nowhere.

425    Further, let it be accepted that Australia’s international obligations are to be weighed as part of my discretionary considerations, which I have done.

426    Take chapter 14 of the Australia–US Free Trade Agreement (Washington, 18 May 2004) [2005] ATS 1, articles 14.2(1) to (3) of which provide:

(1)    Each Party shall maintain or adopt measures to proscribe anticompetitive business conduct and take appropriate action with respect thereto, recognizing that such measures will help realise the objectives of this Agreement. To this end, the Parties shall consult from time to time about the effectiveness of measures that a Party has undertaken. Each Party shall ensure that a person subject to the imposition of a sanction or remedy for violation of such measures is provided with the opportunity to be heard and to present evidence, and to seek review of such sanction or remedy in a court or independent tribunal of that Party.

(2)    Each Party shall maintain an authority or authorities responsible for the enforcement of its national competition laws. The enforcement policy of each Party’s central government authorities responsible for the enforcement of such laws includes treating non-nationals no less favourably than nationals in like circumstances, and each Party’s authorities intend to maintain this policy, in that regard.

(3)    The Parties recognize the importance of cooperation and coordination between their respective authorities to further effective competition law enforcement in the free trade area. The Parties shall cooperate in relation to the enforcement of competition laws and policy, including through mutual assistance, notification, consultation, and exchange of information.

(a)    The Parties recognize their existing mechanisms for cooperation in relation to competition law enforcement, specifically:

(i)    The Agreement between the Government of Australia and the Government of the United States of America relating to Cooperation on Antitrust Matters of 1982; and

(ii)    The Agreement between the Government of Australia and the Government of the United States of America on Mutual Antitrust Enforcement Assistance of 1999.

(b)    The Parties shall work to further strengthen their cooperation in these areas. Such cooperation shall include consideration by a Party’s central government authorities responsible for the enforcement of its competition laws, where feasible and appropriate, of a request by the other Party’s central government authorities responsible for the enforcement of its competition laws to initiate or expand enforcement activities.

427    An order under s 80, being an effective remedial response to my findings of contravention of s 46 is “appropriate action” of the kind article 14.2(1) contemplates.

428    Further, Apple has invoked Australia’s obligations under the Berne Convention, TRIPS and the WIPO Copyright Treaty to seek to narrow the scope of my orders, but there is an evidentiary gap that underlies them.

429    I have already found that Apple failed to prove the value of any intellectual property rights that Apple said would inevitably need to be licensed by the developer of an iOS app, and that consequently I could not speculate as to what a commercial return might be if Apple were to monetise its investments differently in the counterfactual. I said at [5338]:

Now Apple says that there is no evidence that any licence fee it might lawfully charge would be so low, or the other terms it might offer would be sufficiently attractive, as to permit viable third-party stores or direct downloading. But Apple has failed to prove the value of any intellectual property rights that Apple says would inevitably need to be licensed by the developer of an iOS app. Accordingly, I cannot speculate as to what a commercial return might be, if Apple were in the counterfactual to seek to monetise its investments in some different way.

430    That finding sits alongside my rejection of Apple’s s 51(3)(a) defence on the basis that Apple had not identified any specific inventions or works of the relevant kind, with the result that it could not discharge its burden of establishing the factual elements of that defence.

431    The relief stage has given Apple a further opportunity to address that gap. It has not done so. Mr Friedland’s evidence identifies categories of technology said to facilitate alternative distribution and payments.

432    That evidence does not engage with my findings on the evidence at trial. I said at [6183] to [6185]:

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. That is, there is no evidence that any Apple code is exploited by developers in relation to iOS app distribution.

Accordingly, the iOS restrictive terms, to the extent that they preclude developers from distributing their native iOS apps through alternative channels to the iOS App Store, are not conditions which impose restrictions on the use of any intellectual property rights of Apple in relation to app distribution. They are not conditions “of” any licence to use the intellectual property rights in any Apple software or tools to develop native iOS apps.

Further, there is no evidence that, absent the requirement in the DPLA that developers must use IAP for in-app purchases of digital content within iOS apps, Apple’s iOS SDK and APIs would be exploited by a developer implementing an alternative payment solution for their iOS app.

433    That evidence does not provide a value for any Apple intellectual property it identifies.

434    That evidence does not clearly distinguish between intellectual property developed specifically to enable alternative distribution and payments, and pre-existing intellectual property that is already deployed in the App Store and in connection with IAP.

435    That evidence does not identify what promotion of that intellectual property is already compensated through the USD 99 annual developer program fee, which I found is the consideration for the licence of Apple Software under the DPLA.

436    That evidence says comparatively little about the intellectual property nexus for in-app steering and linked-out payments, as distinct from alternative app distribution.

437    To the extent Apple’s complaint is that Epic’s proposed orders cut down its freedom to monetise its intellectual property differently in the future, that submission carries no weight. Apple’s freedom is a freedom to monetise lawfully, which Epic’s proposed orders preserve. What the orders prevent is Apple deploying its IP–licensing arrangements as a mechanism of foreclosure of the kind that I have already condemned.

438    If Apple in the future wishes to restructure its monetisation in a way that is consistent with my findings, it remains free to do so. And it can seek any necessary variation of the orders at that point, on a properly developed evidentiary basis. What Apple cannot do is resist the making of remedial orders now by appeal to future monetisation strategies whose contours and justification it has not articulated.

439    The position is supported by a related observation. At no point has Apple identified the business model, including the IP-licensing model, that it would propose to adopt under either its own proposed orders or Epic’s. Nor has it chosen to call a witness who could give that evidence. In such circumstances, I discount any weight to be given to any complaint that Epic’s proposed orders interfere with a lawful commercial model Apple has, or might have, in mind.

440    Apple’s IP–based complaints, including those resting on Australia’s international obligations, ultimately depend upon the proposition that Epic’s proposed orders deprive Apple of a commercial return on identifiable, valuable intellectual property that is in some material way distinct from what Apple already monetises through existing arrangements. Apple bore the burden of establishing that proposition. It has not done so.

441    Further, s 80 operates as part of the domestic law of Australia. It is not capable of affecting, and does not purport to affect, Apple’s rights under foreign law. Whatever exclusive rights US copyright law or elsewhere confers on Apple are unaffected.

442    Let me now turn to a different topic concerning Apple’s position in other jurisdictions. The conduct of Apple in other jurisdictions that I am about to discuss is not irrelevant context that in part informs my exercise of discretion when dealing with the need for the precise orders that I intend to make, the terms of which I will discuss in more detail in later sections.

443    Now I have previously discussed questions of international comity, but what I am here discussing is more focused on Apple’s behaviour in other jurisdictions and how this has been dealt with.

Apple’s behaviour in other jurisdictions

444    In my liability findings I discussed the practices that Apple has adopted in other jurisdictions to circumvent the effect of regulatory obligations in connection with the App Store.

445    In response to regulatory developments in South Korea and the Netherlands and Apple’s decision to impose a 26% or 27% commission on developers who opted to use a third party payment solution for in-app purchases in those jurisdictions, I found that those commissions were uneconomic, providing a choice that was illusory, and that Apple had “set the commission rates to block any genuine prospect of competition from suppliers of alternative payment solutions” with the effect that Apple had replaced a contractual tie with an economic tie: [5881], [5884] and [5995].

446    In response to the DMA, Apple’s response to being forced to permit developers to use alternative payment solutions for in-app purchases was to impose “a series of restrictions designed to dissuade developers from taking up that option, including an obligation to pay a core technology fee”: [5830].

447    Epic has filed further evidence addressing developments concerning Apple in California and the European Union that have occurred since the trial concluded on 4 July 2024.

448    In response to regulatory or judicial constraints imposed in connection with the App Store that are anything other than detailed, prescriptive and precise, Apple has systematically implemented practices that seek to circumvent the practical effects of those constraints.

449    In combination with my earlier findings, these matters are relevant to informing the type of relief to be ordered in these proceedings so as to ensure that the distribution and payments markets are opened to competition effectively.

Developments in the United States

450    In the California proceeding, Apple’s anti-steering restrictions were found to contravene California’s unfair competition laws. As a consequence, Judge Gonzalez-Rogers granted an injunction in the California proceeding ordering Apple to permit developers to link-out to alternative payment solutions from within iOS apps, to inform users that purchases outside of apps were available, and to communicate with customers through information obtained in those apps (Epic v Apple (US, 2021) at 1058).

451    The injunction came into effect on 17 January 2024. In response to the injunction, Apple published alternative payment guidelines for developers seeking to avail themselves of the benefit of the injunction. Those guidelines required developers who wished to use external purchase links in their apps to enter into the following terms: (a) developers must pay a 27% commission to Apple on in-app purchases made via the developer’s website; (b) developers must report transactions taking place outside the app to Apple; and (c) developers must display a “disclosure sheet” in a form prescribed by Apple, warning of privacy and security risks associated with using external purchase links.

452    On 13 March 2024 Epic filed a motion to enforce the terms of the injunction. On 30 April 2025 Judge Gonzalez–Rogers granted Epic’s motion and made findings that Apple had the goal of “maintaining [Apple’s] anticompetitive revenue stream”, that Apple “wilfully selected a commission rate that in practice made all alternatives to IAP economically unviable” and that Apple imposed a range of restrictions on external purchase links that were in contravention of the terms of the injunctions (Epic Games, Inc v. Apple Inc, 781 F Supp 3d 943 (ND Cal, 30 April 2025)).

453    Judge Gonzalez-Rogers made two findings of contempt against Apple, and permanently enjoined Apple from imposing any commission or any fee on purchases that consumers make outside an app, from restricting or conditioning inter–alia developers’ style, language, flow or placement of links for purchases outside an app, from prohibiting or limiting inter–alia the use of buttons or other calls to action, from excluding certain categories of apps and developers from obtaining link access, from interfering with consumers’ choice to proceed in or out of an app by using anything other than a “neutral message” apprising users that they are going to a third party site, and from restricting a developer’s use of dynamic links of a certain type.

454    Further, on 16 May 2025 Epic filed a further motion to enforce the injunction after Apple refused to accept Epic’s submission of a version of Fortnite to the US App Store which included a link-out to make purchases via Epic’s website.

455    On 4 June 2025, the United States Court of Appeals for the Ninth Circuit denied Apple’s motion for a partial stay of the injunction. On 11 December 2025, the Ninth Circuit affirmed Judge Gonzales-Rogers’ finding that Apple was in contempt and affirmed in part and reversed in part the civil contempt sanctions (Epic Games, Inc v Apple Inc, 161 F 4th 1162 (Cal, 11 December 2025) 1180 to 1194).

Continental developments

456    On 25 March 2024, the European Commission opened an investigation into Apple for noncompliance with the DMA.

457    On 24 June 2024, the Commission announced its preliminary view that Apple’s App Store steering rules were in breach of the DMA, including the fees imposed on developers who steered users to their own payment solution outside the App Store. It announced that it was opening a further investigation into Apple’s updated alternative terms addendum including in relation to the core technology fee, the multi-step journey to directly download apps, and the eligibility requirements for developers to offer alternative app stores or directly distribute apps on iOS.

458    On 23 April 2025, the Commission announced its finding that Apple had breached its anti-steering obligation under the DMA and stated in a press release that:

Due to a number of restrictions imposed by Apple, app developers cannot fully benefit from the advantages of alternative distribution channels outside the App Store. Similarly, consumers cannot fully benefit from alternative and cheaper offers as Apple prevents app developers from directly informing consumers of such offers. The company has failed to demonstrate that these restrictions are objectively necessary and proportionate.

459    The Commission made the following findings in relation to Apple’s implementation of its DMA obligations based on the alternative terms addendum: (a) Apple failed to show that requiring developers to submit external links to it for approval was objectively necessary and proportionate to protect end user security; (b) Apple had not justified why a disclosure sheet was necessary every time an end user links-out, nor why the disclosure sheet displayed by Apple at link-out should be displayed with the design and wording chosen by Apple; (c) Apple’s core technology fee prevented developers steering users and concluding transactions outside the app free of charge, as required by the DMA.

460    The Commission fined Apple 500 million Euros and ordered it to remove technical and commercial restrictions on steering. It also ordered Apple to: (a) allow developers to steer users to any destination or channel of their choice; (b) allow developers to steer users towards all types of offers including alternative app marketplaces and other apps; (c) use neutral prompts or disclosure sheets only where essential to inform users they are transacting with the app developer rather than Apple; (d) allow developers to communicate and promote offers and steer users free of charge; (e) only charge fees related to facilitating initial user acquisition, that is, not charge developers fees in relation to already-acquired users; (f) limit these fees to an amount commensurate to the value of that initial acquisition; and (g) not impose any fee to cover services linked to the acquisition of end users.

461    On 26 June 2025, Apple announced additional changes in the EU in response to the Commission’s decision. The revised alternative terms addendum that Apple has issued propose a revised fee structure for purchases of digital in-app content on apps distributed other than through the App Store.

462    Let me now say something about Apple’s practices in Japan.

Japan

463    Apple now permits alternative distribution channels in Japan. But it has not just removed pre-existing restraints. Rather, Apple now requires developers who wish to distribute an “alternative app marketplace” to obtain authorisation to do so from Apple, through an “entitlement request”. Such requests will only be granted if developers satisfy a suite of eligibility criteria and agree to abide by various ongoing requirements imposed by Apple, including publication of marketplace terms, acceptance of apps that meet those terms, monitoring and anti-fraud obligations, and intellectual property review mechanisms.

464    To qualify for an app marketplace entitlement, the developer must either provide Apple with a USD 1 million standby letter of credit and maintain it for at least 6 months, or be a member of good standing in the Developer Program for at least 2 years and have an app that had more than 1 million first annual installs worldwide on iOS in the prior calendar year.

465    So it would seem that, absent legal restraint, Apple is likely to impose additional conditions on alternative distribution channels that are apt to hinder new entry into the iOS app distribution market, and will enable Apple to exercise control or influence over, and/or to impose restrictions on, the nature and operation of those alternative app distribution channels that do enter.

466    I agree with Epic that this affirms both the utility and desirability of the restraints sought by it in proposed orders 5, 6(a), 6(c) and 6(k) (orders 4, 5(a), 5(c) and 5(k) respectively as modified and made).

467    Further, the evidence relating to alternative payment methods in Japan shows that, where a developer offers an alternative payment method for digital goods or services within an app, or directs users to a website to purchase digital goods or services, Apple requires the developer to also present IAP as a payment option at the same time. Apple seeks to justify this by saying that this, apparently, is to “provide a consistent and transparent user experience when offering alternative payment methods for digital goods and services within your app”.

468    Apple further requires that IAP “must be provided as an option on every screen where your app merchandises a digital good or service for purchase and offers a payment option” and that the display of IAP “must be at least as prominent as any other payment option shown”.

469    I agree with Epic that this conduct supports Epic’s proposed orders 6(j) and 10(c) (orders 5(j) and 9(c) respectively as modified and made). It seems to me that absent appropriate restraint, Apple is likely to require developers to offer IAP as an alternative to the developer’s preferred payment method.

470    Moreover, this also supports proposed order 7(c) (order 6(c) as modified and made). Because many developers prefer as Epic described it a “one stop shop”, Apple’s conduct in compelling them to offer IAP in addition to any alternative payment method will, in practice, prevent many developers from offering alternative payment methods at all.

471    Apple also requires that apps using alternative payment methods must present users with an in-app “disclosure sheet” that lets users know “they’ll be transacting with the developer and not Apple”. Apple has said that “a future iOS release” will give users the ability to opt out of showing the screen for future transactions in the app, but it appears that this option is not currently available.

472    In my view this conduct demonstrates the need for proposed order 11(a) (order 10(a) as modified and made), since it clearly signals that Apple is otherwise likely to impose additional frictions or impediments into the user’s payment experience.

473    Let me now turn to the specific orders sought, which I will address in detail under a number of heads of subject matter.

Fortnite and other iOS apps developed by Epic

474    Epic has sought the following orders on this topic:

3.    Upon written application being made by the Applicants, the First Respondent must do all things necessary (including procuring any act of any related corporation) to permit the Fortnite app and/or other iOS apps developed by the Applicants (not including an alternative app store) to be (i) admitted or readmitted to the App Store subject to the Applicants’ complying with the DPLA and App Store Review Guidelines (insofar as the provisions of the DPLA and App Store Review Guidelines have not been declared void under paragraph 2 and are consistent with the balance of the orders made by the Court), and (ii) made available for discovery, downloading, use and updating by iOS device users, in the same manner as other apps available on the App Store by taking the following steps:

(a)    processing in accordance with its usual business practices any of the following application forms or documents which are submitted by any of the Applicants:

(i)    Apple Developer Agreement;

(ii)    DPLA and any Schedule thereto;

(iii)    Xcode and Apple SDK Agreement; and

(iv)    any variation or replacement of these application forms or documents;

(b)    accepting such application forms or documents which are in a compliant form;

(c)    in the case of tools and APIs (including software development kits) that are generally made available by the Respondents to third-party app developers who distribute apps via the App Store, permitting the Applicants to use such of the Respondents’ tools and APIs (including software development kits) as are required for the development, distribution and updating of the Fortnite app and/or other apps developed by the Applicants for macOS and iOS, in accordance with the applicable contractual terms and on substantially the same terms as generally apply to all such third-party app developers (insofar as those terms have not been declared void under paragraph 2 and are consistent with the balance of the orders made by the Court); and

(d)    processing and accepting in accordance with its usual business practices any compliant update to the Fortnite app and/or other iOS apps developed by the Applicants which are submitted by any of the Applicants for distribution via the App Store.

Competition in iOS app distribution

475    Epic has sought the following orders on this topic:

4.    The First Respondent must do all things necessary (including procuring any act of any related corporation) to ensure that users of iOS devices can discover, obtain and update iOS apps, including alternative app stores, via distribution channels other than the App Store (including via direct download and alternative app stores) provided those iOS apps have undergone an automated scan for genuine security and/or privacy reasons and been notarised by Apple or a suitably qualified third party (Alternative Distribution Channels), and that app developers can distribute and update such iOS apps to such users via Alternative Distribution Channels, including but not limited to providing access to all tools and APIs (including software development kits):

(a)    necessary for developers to develop and distribute iOS apps;

(b)    necessary for developers to develop iOS apps that are capable of creating an interface for displaying iOS apps and which may be used by an iOS user to discover, download, install and update iOS apps; and

(c)    necessary for iOS users to discover, download, install and update apps via Alternative Distribution Channels,

where such tools and APIs are made available in the same manner and on substantially the same terms as tools and APIs are made available to developers who distribute iOS apps via the App Store, and to users of iOS apps distributed via the App Store.

5.    The First Respondent must not (including by procuring any act of any related corporation) prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder users of iOS devices from discovering, obtaining and updating iOS apps, including alternative app stores, via Alternative Distribution Channels, or from using iOS apps obtained in that way on iOS devices, or prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder app developers from distributing and updating such iOS apps to such users via Alternative Distribution Channels, including but not limited to:

(a)    prohibiting, preventing or taking any action (including imposing a fee or condition) which is likely to hinder access to any tool or API (including software development kits):

(i)    necessary for developers to develop and distribute iOS apps and which are available to developers distributing iOS apps via the App Store;

(ii)    necessary for developers to develop iOS apps that are capable of creating an interface for displaying iOS apps and which may be used by an iOS user to discover, download, install and update iOS apps;

(iii)    necessary for iOS users to discover, download, install and update apps via Alternative Distribution Channels;

(b)    imposing any restrictions that prevent iOS apps from running on an iOS device unless downloaded from the App Store or pre-installed by the First Respondent; and

(c)    making it a term of the Applicants’ or any other app developer’s access to the App Store that they will not make their iOS apps available via an Alternative Distribution Channel.

6.    The First Respondent must not (including by procuring any act of any related corporation):

(a)    impose any fees or conditions for access to, or use of, Alternative Distribution Channels by iOS app developers or iOS users;

(b)    impose any fees or conditions for access to, or use of, any tool or API (including software development kits) necessary for app developers to develop and distribute iOS apps via Alternative Distribution Channels, that have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via Alternative Distribution Channels, including by imposing fees higher, or conditions more onerous, than those applied to developers of iOS apps which are monetised other than through in-app purchases (including free apps and apps monetised through advertising) when distributed via the App Store;

(c)    require the Applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel to refrain from offering lower prices, or more favourable discounts or other benefits, to users who make purchases of digital content for use in that app when it is distributed via the Alternative Distribution Channel, as compared to when the app is distributed via the App Store;

(d)    require the Applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel, and who allows users of those apps to access content, subscriptions or features they purchased from the Applicants’ or developer’s own website or another distribution channel to also make that content, subscriptions or features available as an in-app purchase within their iOS apps distributed via the App Store;

(e)    prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder the Applicants or any other operator of an alternative app store from making and implementing their own choices as to which apps they will distribute via any alternative app store that they operate;

(f)    require the Applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel to appoint any particular person as their agent for the marketing and delivery of the developer’s app to iOS users located in Australia via that distribution channel;

(g)    prohibit the pre-installation of third-party apps, including alternative app stores, on iOS devices;

(h)    remove an app from, or disable an app installed on, an iOS device which has been obtained by a user via an Alternative Distribution Channel unless the app:

(i)    contains illicit, objectionable or harmful content; or

(ii)    constitutes malware or malicious code which poses a genuine security risk that either requires urgent elimination, or that has not been remedied following the First Respondent (or a related corporation) providing the app developer with reasonable notice of the existence, nature and extent of that security risk;

(i)    impose frictions on or impediments to the discovery, downloading, installation, execution or updating of any iOS apps available or distributed via Alternative Distribution Channels, including alternative app stores:

(i)    that are disproportionate to the security risk posed by those apps to iOS devices and iOS device users; or

(ii)    that otherwise have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via Alternative Distribution Channels or the use of such apps by iOS device users;

(j)    require the Applicants or any other app developer who wishes to make, or makes, their iOS apps available for distribution via an Alternative Distribution Channel to offer or to use any particular payment method, or require that they must offer IAP as an alternative to the developer’s preferred payment method;

(k)    require the Applicants or any other app developer who wishes to make, or makes, their apps available for distribution via an Alternative Distribution Channel to enter into any contractual arrangement with the First Respondent (or any other person) as a condition of the Applicants or the developer distributing their iOS apps via the Alternative Distribution Channel, other than in respect of the licensing of the First Respondent’s tools and APIs for the development of iOS apps.

Apple – order

476    Contrastingly, Apple has sought the following order:

2.    Pursuant to s 80(1) of the CCA, the First Respondent must not (including by procuring any act of any related corporation):

(a)    prohibit:

(i)    users of iOS devices associated with an Australian Apple Account from discovering, obtaining and updating native iOS apps, including alternative app stores, via direct downloading or alternative app stores, or from using iOS apps obtained in that way on such iOS devices; or

(ii)    App Developers from distributing and updating native iOS apps to such users via direct downloading or alternative app stores; or

(b)    unreasonably prevent or hinder users of iOS devices associated with an Australian Apple Account or App Developers from engaging in the conduct described in subparas (a)(i) or (a)(ii), and without affecting the generality of the foregoing this will permit the First Respondent (and any related corporation) to impose reasonable terms on any licence or other access of its tools and APIs (including software development kits) necessary for such users of iOS devices or App Developers to engage in that conduct.

…

4.    Orders 2 and 3 are to have effect for a period of 5 years with effect from the date that is 6 months from the date of these orders.

Definitions

In these orders:

“App Developers” means developers of native iOS apps who are and remain admitted to the Apple Developer Program.

“Australian App Store” means the App Store Australian storefront.

“Australian Apple Account”, formerly "Apple ID", means an Apple Account with the country or region set to “Australia” and associated with a payment method with an Australian billing address.

“Reader app” means magazine, newspaper, book, audio, music and video apps which may allow a user to access previously purchased content or content subscriptions.

477    Before proceeding further, it is convenient to make the following points concerning Apple’s proposed orders.

478    I agree with Epic that if I was to make Apple’s proposed orders, it would not ensure that the necessary tools, APIs and functionality were provided on terms that did not stifle competition in the relevant markets.

479    Further, Apple’s proposed orders are only prohibitory in nature, and turn on whether Apple has unreasonably prevented or hindered the relevant conduct. Accordingly, I am not satisfied that if Apple’s proposed orders were made, Apple would take the positive steps necessary for competition to emerge in the relevant markets. As Epic points out, limited prohibitory injunctions like those proposed by Apple would leave Apple with considerable scope to preserve the substance of the restraints that I have previously condemned.

480    Contrastingly, Epic’s proposed orders will require Apple to take positive steps to ensure that users can discover and developers can distribute iOS apps via alternative distribution channels, including by providing developers with access to all necessary tools and APIs on substantially the same terms as tools and APIs are made available to developers who distribute iOS apps via the App Store.

481    Further, Epic’s orders will require Apple to take positive steps to permit developers to use payment systems other than IAP and to provide external links. I will discuss this topic in a separate section of my reasons.

482    Let me turn to the specific orders and address Epic’s proposed order 3 first. But before doing so I should make clear that in the discussion of this proposed order and the following orders, “user” refers to a user with an Australian Apple Account and “App Store” refers to the Australian App Store.

Proposed order 3 (order 2 as modified and made)

483    Now Apple says that Epic’s proposed order 3, which is in the form of a mandatory injunction directed to Epic’s apps being admitted or readmitted to the App Store, should not be made. I would note that this corresponds, with modification, to order 2 that I have made.

484    Apple says that Epic did not bring a case alleging a refusal to deal with it on the part of Apple generally or in any specific respect. There was no case or controversy brought and it says that I made no finding to the effect that Apple contravened s 46 by refusing to deal with Epic.

485    Further, Apple says that Epic’s order impinges upon the operative effect of existing terms of Apple’s DPLA that are not related to the conduct that has been found to have contravened s 46 and which, in some cases, have been unsuccessfully challenged by Epic in this proceeding.

486    Apple says that Epic’s proposed order 3 would operate to re-enliven and vindicate aspects of the case Epic did bring which have been rejected. So, it said that by clause 6.9 of the DPLA, Apple reserved the right to select at its sole discretion which iOS apps will be distributed on the App Store and will be available by that means to iOS device users. And under schedule 2 to the DPLA, Apple reserved the right to cease offering an iOS app for download at any time without cause.

487    Apple says that Epic included these terms among its catalogue of restrictive terms, but it says that no finding has been made that imposing or giving effect to these terms contravened s 46.

488    In addition, Apple says that clause 11.2 of the DPLA also provided that either party “may terminate this Agreement for its convenience, for any reason or no reason, effective 30 days after providing the other party with written notice of its intent to terminate”. But it says that that part of clause 11.2 was challenged by Epic.

489    Further, Apple says that the US courts have held that Apple acted lawfully in removing the Fortnite app from the App Store and terminating Epic’s developer account and says that there is no proper basis for me to order Apple to reverse an exercise of its contractual rights which the US courts have upheld.

490    Further, Apple says that proposed orders 3(a), (b) and (d) would effectively force it to deal with Epic. But it says that I have not made findings to the effect that Apple has contravened, or would contravene s 46 or any other provision, by refusing to deal with Epic. And it says that nothing determined by me warrants any compulsion of Apple to deal with Epic irrespective of the specific contractual discretions which the DPLA contains.

491    Apple says that proposed order 3(c) would force it to give Epic access to such of Apple’s intellectual property as Epic considers desirable. But it says that nothing in my findings warrants forcing Apple to give Epic the run of its intellectual property. It says that those findings went no further than identifying that some unspecified portion of Apple’s SDKs and APIs are essential to developers in the sense that it is not practical for a developer to develop native apps for iOS without them.

492    Further, Apple says that proposed order 3(a) purports to require processing of the identified forms or variations of them, whereas proposed order 3(b) requires Apple to accept such application forms or documents as are in a compliant form. It says that the order is ambiguous in that the forms referred to are actually standard form contracts that govern Apple’s relationship with all developers. In any event, whether or not applications or forms as Epic may submit are in a compliant form is not a matter which Apple can reasonably be required to assess on pain of being held in contempt to the extent of any error in that assessment.

493    Apple says that proposed order 3(c) would compel it to permit Epic to use such of the respondents’ tools and APIs including SDKs as are required or desirable for the development, distribution and updating of Fortnite and/or other apps developed by Epic for macOS and iOS; I note that what is proposed does not include “or desirable”. Apple says that the tools and APIs that may be required by or desirable to Epic is indeterminate and the order does not in terms place any limit on Epic’s desires. Further, it says that the findings in this matter do not give rise to any basis for relief relating to apps developed for macOS.

494    Further, Apple says that proposed orders 3(a) and (d) require Apple to deploy usual business practices in implementing a regime which will be, in the context of Apple’s global operations, highly unusual and specific to Epic and the Australian App Store. It says that this is a criterion which Apple cannot be expected to meet on pain of being found to be in contempt of court.

495    Further, Apple says that the effect of the order would be to override Apple’s right under the DPLA terms to select, at its sole discretion, which iOS apps will be distributed in the App Store, which right has not been found to contravene s 46 or any other relevant provision.

496    Further, Apple says that the proposed orders where Apple is only required, upon written application by Epic, to permit the Fortnite app and other iOS apps developed by Epic to be admitted or readmitted to the App Store if Epic complies with the DPLA and the App Review Guidelines, and uses Apple’s tools and APIs in accordance with applicable contractual terms, do not address these issues.

497    Apple says that if the injunctions proposed at paragraphs 2 and 3 of Apple’s proposed orders are made, then Epic can apply for a new DPLA and seek to have Fortnite and any other iOS apps it develops added to the App Store like any other developer.

498    Apple says that injunctive relief in the form proposed by it would enjoin Apple from preventing or prohibiting sideloading or direct download of apps including app stores or from preventing or prohibiting use of payment methods other than IAP for in-app purchases of digital content in relation to iOS devices associated with an Apple ID registered in Australia. And it says that that is all the injunctive relief that my liability findings support.

Analysis

499    As is apparent, Epic’s proposed order 3 requires Apple to do all things necessary to ensure that iOS apps developed by Epic are admitted or re-admitted to the App Store, and made available for discovery, downloading, use and updating by iOS device users, in the same manner as other apps available on the App Store.

500    Moreover, as Epic correctly points out, the specific matters identified in sub-paragraphs (a) to (d) of order 3 reflect my recognition of the developers’ need to access Apple’s tools and APIs, including SDKs, in developing apps, as well as the importance of apps being able to be updated as required.

501    In my view this mandatory injunction but limited to the Australian App Store is warranted given my finding that Apple’s removal of Fortnite from the App Store and termination of Epic’s developer account was a paradigm example of Apple’s enforcement of its restrictive terms, in contravention of s 46.

502    But for Apple’s contravening conduct in imposing and enforcing those terms on and against Epic, Epic’s apps, including Fortnite, would be available for discovery, downloading, use and updating via the App Store. As Epic says, the mandatory injunction proposed prevents Apple from continuing to contravene s 46 by enforcing, or purporting to enforce, its restrictive terms against Epic.

503    Moreover, proposed order 3 is a targeted exercise of s 80 that remedies Epic’s ongoing exclusion from the Australian App Store. Epic’s proposed orders are targeted at requiring Apple to do what is necessary to admit or readmit Epic’s apps to the Australian App Store. Of course these orders do not prevent Apple from exercising its contractual rights in the future for legitimate reasons.

504    Further, I am not required to make separate findings that, in every but for scenario, Epic’s apps would necessarily remain available via the Australian App Store irrespective of any legitimate exercise of Apple’s contractual discretions.

505    As I found at [5227]:

Further, Epic also makes the good point that there is an inherent difficulty in the notion that Epic is required to prove contractual terms which would be acceptable to Apple in the future. Any litigation could be defeated by Apple simply stating that such terms would not be acceptable, which would provide Apple with a form of non-justiciable fiat such that it could always escape the reach of ss 45, 46 and 47.

506    I agree with Epic that it would not be feasible to require it to prove that in the counterfactual its apps would remain available in every conceivable scenario.

507    Further, my power to grant relief under s 80 is not limited by the operation of United States law. And the US courts’ conclusions about the contractual validity of Apple’s conduct under US law do not limit my power to grant relief under the CCA to address the competition law consequences of Apple’s conduct in Australia, particularly as the order that I propose to make will be limited to the Australian App Store.

508    Further, proposed order 3(c) will grant Epic the tools necessary to remedy Apple’s contraventions of s 46 and does not give Epic “the run” of Apple’s IP. I found that decentralised distribution of apps cannot occur without access to Apple property. Apple itself identified the software that it considered necessary for developing an iOS app or alternative app store that is capable of distribution on iOS.

509    I agree with Epic that Apple should not be permitted to remain free to withhold the tools that I have found are essential to iOS distribution and development.

510    Further, and contrary to what Apple has said, in my view Apple should not be permitted to repeat the same impugned conduct in respect of macOS. My findings give rise to a clear basis for relief relating to apps developed for macOS. I found that macOS and iOS are based on the same core technologies and source code and that a developer’s access to that technology is governed, or largely governed, by the same contractual provisions. It would be an illogical result if Epic were only allowed access to the necessary tools for iOS while simultaneously being denied access to those very same tools for macOS.

511    Finally, there should be no difficulty with proposed order 3 in circumstances where the mandatory injunction proposed is subject to Epic complying with the DPLA and App Review Guidelines. The order is necessary for the reasons given elsewhere. Apple’s complaints about the geographic scope of order 3 have been addressed elsewhere.

512    Let me now turn to Epic’s proposed orders 4 to 6 dealing with injunctions directed at competition in the distribution market.

Proposed order 4 (order 3 as modified and made)

513    Apple says that the further mandatory injunctive relief sought by Epic’s proposed order 4 should also not be made. I would note that this corresponds, with modification, to order 3 that I have made. Apple says that proposed order 4 does not respond to any aspect of the controversy or case that has been contested between the parties, and so is not within my power to grant by way of relief in these proceedings.

514    Apple says that no case has been brought alleging that it is or should be required by the CCA to positively facilitate distribution by developers of iOS apps via alternative distribution channels, much less discovery by users of apps so distributed. And it says that Epic has claimed no form of mandatory injunctive relief analogous to proposed order 4.

515    Further, Apple says that insofar as this order purports to require Apple to provide access to all tools and APIs including SDKs that are necessary for developers to develop and distribute iOS apps or necessary for developers to develop iOS apps that are capable of creating an interface for displaying iOS apps, nothing in my liability findings supports the grant of that relief.

516    Indeed, Apple says that my findings positively disfavour the grant of such relief, since they posit and presuppose that in a world without the impugned conduct, that is, the world which the making of orders enjoining the impugned conduct will create, Apple will likely license its intellectual property to developers of its own volition and in its own interests. Apple says that it was an integer of the finding of contravention that in the counterfactual Apple “could and likely would license its intellectual property” as I said at [5237]. And it says that Epic chose not to seek to establish how or to what extent or on what terms Apple would likely do so.

517    So, Apple says that there was no case or controversy concerning the terms upon which Apple would licence its intellectual property in a world without the contravening conduct. And it says that my findings do not give rise to a right on the part of Epic or developers generally to a compulsory licence of Apple’s software.

518    Apple says that in circumstances where the “with and without” analysis was integral to determining whether impugned conduct contravenes Pt IV, it was incumbent upon Epic to articulate any parameters it says should apply to Apple’s conduct in the counterfactual in the liability hearing.

519    Apple says that Epic, having made the forensic decision that a finding in the terms of [5237] was sufficient for its purposes, should not be permitted to now ask me to further prescribe the shape of the world without the contravening conduct in granting relief.

520    Further, Apple says that making available tools and APIs in the same manner and on substantially the same terms as tools and APIs are made available to developers and users of apps distributed via the App Store would limit Apple’s commercial freedom to set the terms on which it licenses its intellectual property in a manner that my liability findings do not justify.

521    Apple says that I accepted that it should have such freedom. In substance I observed that Apple could take lawful action in restructuring the way it recovers compensation or adopting alternative monetisation strategies, if it were restrained from imposing and enforcing the iOS restrictive terms.

522    I said at [5375]:

In summary, I am satisfied that if I were to restrain Apple from imposing and enforcing the iOS restrictive terms, there is a commercially realistic chance that any lawful response taken by Apple in restructuring the way in which it recovers compensation, or adopting an alternative monetisation strategy, would not have the same or similar effect as the impugned conduct.

523    Further, Apple says that it is particularly necessary that that should be so given that the tools and APIs addressed by proposed order 4, being for the development of alternative app stores and sideloading, are not tools and APIs made available to developers and users of apps distributed via the App Store.

524    Further, Apple says that it would be inappropriate to order that it do all things necessary to ensure that iOS device users and app developers can utilise alternative app distribution. It says that such an injunction would be of uncertain scope. Indeed it goes so far as to say that such an order could be understood as requiring Apple to subsidise app developers wishing to use alternative app distribution, but lacking the financial or technical resources to do so.

525    Further, Apple says that Epic’s proposed order 4 would require that existing and new software tools, APIs and SDKs be licensed and made available to developers and iOS users in the same manner and on substantially the same terms as tools and APIs are made available to developers who distribute iOS apps via the App Store and to users of iOS apps distributed via the App Store.

526    But it says that nothing in my liability findings justifies an order requiring this. And it says that such an order would unreasonably prejudice Apple’s interests as an intellectual property owner.

527    Further, Apple says that Epic’s proposed order 4 is inconsistent with my judgment, which pre-supposed that with the exception of terms found to contravene s 46 Apple would retain its commercial freedom to deal with its intellectual property. It says that there is no competition analysis demonstrating that it would be anti-competitive for Apple to licence its intellectual property, including tools that specifically facilitate alternative distribution, other than on substantially the same terms as other tools and APIs are made available to developers who distribute apps via the App Store. And in those circumstances, Apple says that Epic’s proposed order would interfere with normal processes of innovation, intellectual property licensing and competition.

528    Further, Apple says that such an order would be an unjustified practical impediment to appropriate licence conditions for specific tools. Apple points out that it presently attaches detailed conditions to specific APIs, tools and technologies. It says that there is no basis for an order that would restrict Apple from similarly imposing specific conditions on APIs, tools and technologies that facilitate alternative app distribution. It says that those tools ensure the security of alternative app distribution via mechanisms such as making cryptographically signed IPA files available to developers in ADPs and allowing cryptographic communication between the App Licence Delivery software tool and Fairplay. It says that it may be appropriate for Apple to impose specific conditions on the use of those tools and that my orders should not prevent that.

529    Now in contrast to its criticisms of Epic’s proposed order, Apple has extolled the virtues of its proposed order 2.

530    Apple’s proposed order 2 is an injunction that restrains Apple from prohibiting users of iOS devices associated with an Australian Apple Account from discovering, obtaining and updating native iOS apps, including alternative app stores, or from using iOS apps obtained in that way. The injunction also restrains Apple from prohibiting app developers from distributing and updating native iOS apps to such users via direct downloading or alternative app stores. In addition, order 2 restrains Apple from unreasonably preventing or hindering users of iOS devices associated with an Australian Apple Account, or app developers, from engaging in that conduct, but provides that Apple may impose reasonable terms on any licence or other access of its tools and APIs including SDKs necessary for such users of iOS devices or app developers to engage in that conduct.

531    Apple says that its proposed injunction is appropriately focused on the conduct that I have found to have contravened s 46 and notes five features.

532    First, Apple’s proposed injunction restrains Apple from prohibiting the distribution of apps via direct downloading and alternative app stores, but not sideloading. During the hearing on relief, Apple used the expression “direct downloading” to refer to the downloading of apps from alternative distribution channels that are subject to review and notarization by Apple, whereas it used the terminology of “sideloading” to refer to the downloading of apps from alternative distribution channels without any process of notarization or review by Apple. I will use that terminological distinction for present purposes. Apple says that an injunction extending to direct downloading and alternative app stores, but not sideloading, is appropriate because I proceeded on the basis that if alternative app distribution was ordered in Australia, Apple could, and would, adopt a system of app review and notarization, consistent with Australian law. It is convenient to say at this point that I agree and a proviso about security scanning and notarization is now included.

533    Second, via the definition of app developers, Apple’s proposed order 2 clarifies that developers of native iOS apps will have the benefit of the injunction so long as they are and remain admitted to the Developer Program. Apple says that that is appropriate given that I proceeded on the basis that Apple could, and would, continue to conduct significant security procedures in relation to the iOS ecosystem. It says that I did not find that Apple’s requirement that developers be members of the Developer Program in order to distribute iOS apps was unlawful or problematic. And it says that that requirement is appropriate in order to ensure that Apple can continue to protect iOS users from fraudulent and malicious developers.

534    Third, Apple’s proposed injunction applies to iOS devices associated with an Australian Apple Account, which will allow Australian iOS users to download and update apps on their iOS devices via alternative distribution channels. Apple says that the injunction allows for developers globally to distribute native iOS apps to Australian iOS users via alternative distribution channels. It says that that is the appropriate geographical scope of the orders that I should make in this case. Further, Apple says that it is also consistent with the technical manner in which Apple makes apps available to iOS users globally. Each iOS user globally has an Apple Account associated with one of the 175 geographic-specific App Store storefronts. In jurisdictions where alternative app distribution is available, it is facilitated via that system, which pre-supposes that every device is exclusively associated with a single geographic-specific App Store storefront, but allows developers globally to distribute to users in each geographic location. Now as I have already indicated I have modified Epic’s proposed orders as a whole to reflect such a geographic limitation.

535    Fourth, Apple says that its proposed order 2 restrains it from unreasonably preventing or hindering iOS users with an Australian Apple Account, or app developers, from distributing and downloading apps via alternative distribution channels. It says that that addresses the spectre Epic raises of Apple seeking to avoid the operation of my orders. Apple says that because of the range of conduct which might be construed as preventing or hindering iOS users or developers from using alternative distribution channels, including the adoption of necessary and appropriate security measures, measures to protect users’ privacy, measures to protect users who are minors, measures to adapt to unforeseen and presently unforeseeable technological changes, measures to respond to developer or user fraud, and the imposition of fees and other conditions on access to Apple’s IP-protected tools, technologies and services, my orders must permit Apple to act reasonably.

536    Fifth and more specifically, Apple says that its proposed order 2 recognises that an injunction restraining it from unreasonably preventing or hindering alternative app distribution will require it to license or otherwise grant access to its software tools and APIs which are necessary for that form of distribution to occur, and makes it clear that Apple can impose reasonable terms in doing so.

537    Apple says that I proceeded on the basis that if alternative app distribution was ordered, Apple would be entitled to licence its intellectual property necessary for app development and distribution on reasonable terms. Indeed, it points out that I found at [6298]:

Further, Apple’s terms protect legitimate commercial interests. It is entitled to seek a commercial return on its highly valuable intellectual property-protected assets, which it generated by taking the risk of vast expenditure on research and development, and which developers like Epic take the benefit of.

538    Apple says that the terms of its proposed order 2 is necessary because in its absence a prohibition on hindering alternative app distribution could be interpreted as prohibiting any limitation on a licence of Apple’s software tools and APIs, including reasonable fees and conditions.

Analysis

539    In my view, proposed order 4 reflects my finding that Apple contravened s 46(1) by prohibiting the distribution of iOS apps via alternative distribution channels, and prevents Apple from continuing to contravene s 46 by requiring it to take positive steps to ensure the viability of app distribution via those channels.

540    Further, the specific matters identified in orders 4(a) to (c) reflect the recognition of the need to access Apple’s tools and APIs in connection with the development of iOS apps, and the fact that Apple makes such tools and APIs available in connection with the distribution of iOS apps via the App Store.

541    Now Apple has advanced four criticisms against proposed order 4 which I reject.

542    First, Apple argues that Epic has not explained why proposed order 4 is necessary to undo or prevent the anti-competitive foreclosure that I have found.

543    But I found that Apple contravened s 46(1) by deliberately foreclosing every rival channel for iOS app distribution, that is, banning direct downloading and alternative app stores, and thereby installing itself as the sole gateway to iOS users. To remedy that situation, it follows that Apple must no longer be free to foreclose rival channels for iOS app distribution.

544    As I found, every alternative form of iOS app distribution envisaged in this proceeding cannot occur without access to Apple property. The various SDKs/APIs that Apple supplies are essential in the sense that developers cannot practically develop iOS apps without them.

545    So, if Apple were free to withhold access to those tools and APIs that are necessary to develop and distribute iOS apps, simply because the developer chose to distribute its iOS apps through an alternative method of app distribution, then developers would have no viable way of distributing apps outside the App Store. This would defeat my findings and the utility of injunctive relief, and perpetuate the anti-competitive conduct and the damage to the public interest.

546    I should exercise my injunctive power under s 80 in a way that offers practical relief. Proposed order 4 does that, responding directly to the way the contravening conduct actually operates. Its scope is limited and proportionate, in that it is confined to those tools and APIs that are necessary for the viability of alternative app distribution and which Apple already makes available to developers for the App Store. As such, it merely asks that alternative channels of app distribution be provided the minimum necessary playing ground to compete.

547    The mandatory operation of proposed order 4 is warranted as a corollary of the corresponding prohibitive obligation in proposed order 5, and to safeguard against Apple’s persistent pattern of resistance to external constraint. I said at [6005]:

In these instances, even regulatory obligations have not prevented Apple from devising ways by which it can continue to foreclose competition. The same applies to Apple’s response to the enactment of the Digital Markets Act.

548    Second, Apple argues that proposed order 4 does not respond to any aspect of the controversy or case that has been contested between the parties, and that nothing in the liability judgment supports the grant of that relief.

549    But consonant with the broad and public interest discretion under s 80, the requirement that there be a sufficient nexus between the order sought and the contravention found is not to be inflexibly or mechanically applied. It is an evaluative judgment. Nor is it to be artificially limited. Section 80(5)(b) makes clear that the Court may grant an injunction requiring a person to do an act or thing whether or not the person previously refused or failed to do that act or thing. I agree with Epic that the freeing of the Court’s injunctive power under s 80 from this constraint is necessary to uphold the public interest purpose of s 80.

550    Accordingly, in circumstances where I found that Apple foreclosed rival channels for iOS app distribution and that developers cannot practically develop iOS apps for such channels unless they have access to certain SDKs/APIs that Apple supplies, an order requiring Apple to take positive steps to ensure the viability of alternative channels of app distribution bears a sufficient nexus to the contravening conduct.

551    Third, Apple argues that my counterfactual findings positively disfavour mandatory relief involving access to its intellectual property, on the basis that I assumed, in the counterfactual, that Apple could and would likely license its intellectual property of its own volition. Apple claims Epic chose not to prove how or on what terms that would occur, and there was therefore no case or controversy about Apple’s licence terms. Given that, Apple says there is no basis now to dictate those terms by way of relief, and in any event I should in my discretion refuse to allow Epic to run its case in that way at a separate relief hearing.

552    Now the assumptions that I made concerning the likelihood of Apple licensing its intellectual property in a world without the impugned conduct were made for the purpose of facilitating my counterfactual inquiry. They were directed to the liability question, being whether removing the impugned conduct would result in increased competition.

553    They were not directed to confining my remedial powers and nor could they be. As I noted at [3791] and [3792]:

What must be proved on the balance of probabilities is that there is real commercial likelihood of a substantial lessening of competition. It is not necessary to prove each predicted fact on the balance of probabilities. The counterfactual is no more than an element of the calculus aimed at detecting the existence and extent of a change in the competitive process. It is not a matter that needs to be separately proved as if it were a primary fact.

Conduct which lessens competition in a part of the market can constitute a substantial lessening of competition in that market, even if the conduct is not market-wide or does not otherwise affect the whole market. This is because “it is the degree to which competition has been lessened which is critical, not the proportion of that lessening to the whole of the competition which exists in the total market” (Dandy Power Equipment Pty Ltd v Mercury Marine Pty Ltd (1982) 44 ALR 173 at 192; 64 FLR 238 at 260 per Smithers J).

554    It is a tool that operates by way of a hypothetical comparison between two projected states of competition. It is not a matter that needs to be separately proved as if it were a primary fact.

555    As such, to read into the terms of s 80 an implied limitation that the relief granted must mirror the bare assumptions used in the counterfactual inquiry misunderstands the nature and purpose of that inquiry. I am free under s 80 to grant such injunctions as I determine to be appropriate to prevent, restrain or remedy the contravening conduct and its effects.

556    As I have said, I assumed for the purpose of the counterfactual inquiry that there is at least a realistic chance that Apple would license its intellectual property in a way that would permit alternative modes of iOS app distribution. I did not make the finding that Apple should be free not to do so, or to do so on the terms it sees fit. I said (at [1384] to [1387]):

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.

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.

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 s 45, s 46 or s 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.

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.

557    Yet Apple now in effect asks me to treat that assumption as necessitating the grant of some permanent entitlement to complete commercial freedom.

558    In any case, there is no unfairness to Apple in settling the operational detail of mandatory relief at this stage of the proceedings. I bifurcated the questions of liability and relief, to which the parties agreed. Moreover, I specifically held that Epic was not required to prove the form of contract that Apple is likely to accept in the counterfactual. Apple cannot now complain that Epic should have done so in more detail. Apple has had notice of the orders Epic proposes and an opportunity to respond.

559    Further, Apple appears to suggest that the relevant counterfactual is the world which the making of orders enjoining the impugned conduct will create. But in populating the counterfactual, I did not take into account the remedial orders that I would grant in the event that I made a finding of liability. To do so would be a speculative and unworkable exercise.

560    Fourth, Apple contends that the requirement in proposed order 4 to make tools and APIs available in the same manner and on substantially the same terms as for App Store distribution would radically limit its ability to set the terms on which it licenses its intellectual property as it pleases, and is contrary to my finding at [5375]. In that paragraph I said:

In summary, I am satisfied that if I were to restrain Apple from imposing and enforcing the iOS restrictive terms, there is a commercially realistic chance that any lawful response taken by Apple in restructuring the way in which it recovers compensation, or adopting an alternative monetisation strategy, would not have the same or similar effect as the impugned conduct.

561    But that paragraph forms part of the counterfactual analysis and recognises that there is a commercially realistic chance that any lawful response Apple may adopt in restructuring its monetisation would not have the same or similar effect as the impugned conduct. It is not a finding that Apple must be left free of any obligation at the relief stage that is appropriate to prevent the recurrence of the contravening conduct or its effects.

562    I agree with Epic that there is no relevant uncertainty in a mandatory injunction requiring Apple to do all things necessary, and this is a standard formulation of words. The purpose of the mandatory injunction is to require Apple to do what is necessary to ensure iOS device users and app developers can utilise alternative app distribution.

563    Further, order 4 does not amount to a compulsory licence of Apple’s intellectual property. As Epic points out, order 4 operates in personam, does not compel any transfer of Apple’s property, and does not confer on Epic or any other developer any free-standing proprietary rights in Apple’s copyright. To the extent that the order requires Apple to continue making available its tools and API, they are orders that are permissible.

564    Proposed order 4 does not prohibit Apple from imposing conditions on the use of APIs, tools and technologies to ensure the security of app distribution. The order provides that Apple’s APIs, tools and technologies are to be made available in the same manner and on substantially the same terms as those tools are made available to developers who distribute apps via the App Store, and to users of such apps. So, to the extent that Apple attaches conditions to specific APIs, tools and technologies made available to such developers and users, the same conditions are permissible under proposed order 4.

565    Finally, and for the reasons that I have previously addressed, I have limited the geographic reach of proposed order 4.

Proposed order 5 (order 4 as modified and made)

566    Apple says that insofar as Epic’s proposed order 5 purports to enjoin Apple from preventing or prohibiting sideloading including of alternative app stores, the prohibitive injunction proposed by Apple to that effect is sufficient. I would note that proposed order 5 corresponds, with modification, to order 4 that I have made.

567    Apple says that to the extent that proposed order 5 goes further than Apple’s proposed injunction, it too goes beyond Epic’s pleaded case and is not supported by and is, in respects, contrary to my findings.

568    Apple says that Epic did not allege that Apple would, in a future without prohibitions on sideloading of iOS apps, hinder or deter users or developers from using alternative distribution channels, or that any such conduct would contravene s 46. It only brought a case, relevantly, to the effect that Apple should be enjoined from prohibiting the development and use of alternative app stores and direct downloading.

569    Moreover, to the extent that proposed order 5, particularly order 5(b), purports to enjoin Apple from imposing frictions on the use of alternative distribution channels, Apple says that it is not supported by, and is countermanded by, the liability findings. It points to the following matters.

570    First, I did not accept that evidence concerning the EU showed that Apple was imposing frictions that were wholly disproportionate to the risks involved.

571    Second, I accepted that it may be appropriate to have some degree of friction, in terms, before setting an alternative marketplace as a default, but implicitly before permitting a user to engage with an alternative marketplace, given the security risks involved. So I said at [4631] to [4634]:

Now I do agree that it may be appropriate to have some degree of friction before setting an alternative marketplace as a default. Generally speaking I accept the following three points.

First, disclosure screens and other user interactions can yield security benefits because they require users to understand what they are about to do on their device. Such screens ask users to engage with more information before acting without understanding the implications of their actions.

Second, the screens and requirements depicted in publicly available materials concerning third party marketplace installation in the EU on iOS devices provide meaningful context and content for the actions that the user is attempting to take, and can assist the user in making a more informed decision.

Third, it may be appropriate to have multiple screens, and therefore multiple interactions, when different types of information are being presented and multiple consents are required.

572    Third, I was not then able to draw any specific adverse conclusions as to Apple’s warnings or installation processes for third party marketplaces and found that it had not been shown that Apple’s imposition of frictions on directly downloaded apps and alternative app stores in the EU was wholly disproportionate to the risks involved.

573    Further, Apple says that Epic’s proposed order 5 could also inhibit the discharge by Apple of its regulatory obligations under the Online Safety Act 2021 (Cth). In particular, under the Online Safety Codes made pursuant to that Act, Apple is required to implement tools and take steps to help reduce the risk of harm to children when using interactive devices including mobile phones and tablets. Apple says that any relief granted in these proceedings should preserve its ability to meet those obligations. I should say now that I have modified proposed order 5 to reflect this.

574    Further, Apple says that proposed order 5(a) would in effect impose a series of compulsory intellectual property licences on Apple that Epic did not seek in the FAOA and which my findings do not support.

575    Further, it says that proposed order 5 would apply to any and all would be app developers. In that way, it would deprive Apple of the ability, for example, to limit access to its tools and APIs for app development and alternative app distribution to developers who have been admitted to its Developer Program and, in the case of alternative app marketplace operators, to those who meet such additional requirements as Apple might reasonably impose. Depriving Apple of that ability is inappropriate.

576    Further, Apple says that an order restraining any action including by imposing a fee or condition which is likely to hinder alternative app distribution is not appropriate. That restraint would at least arguably prevent Apple from imposing reasonable fees and conditions, indeed any fees, when licensing the IP–protected tools and technologies that facilitate app development and alternative distribution. It would at least arguably prevent Apple from imposing reasonable conditions on alternative distribution, to protect the security of the iOS ecosystem. Apple says that that is not consistent with my liability findings, with Apple’s legitimate interests as an intellectual property owner, or the imperative of preserving the security for iOS devices and users.

577    Further, Apple says that a difficulty with the restraint on any action including by imposing a fee or condition which is likely to hinder alternative app distribution is that Epic’s proposed order 5 operates indiscriminately in respect of all developers. Apple says that even relatively benign fees and conditions might be likely to hinder at least some of the millions of developers in the Developer Program. And it says that the prohibition on taking any action including imposing any fee or condition which is likely to hinder access to certain tools and APIs including software development kits is repeated in order 5(a) and is inappropriate.

578    Further, Apple says that Epic’s proposed order 5(c) would restrain Apple from making it a term of any developer’s access to the App Store that they will not make their iOS apps available via an alternative distribution channel. It says that I have made no finding and there is no expert economic evidence or other economic analysis establishing that such a term would be anti-competitive or, indeed, other than pro-competitive. It says that I found that platforms engage in competition for developers’ resources which can include exclusive availability of games, which the platforms can then use to attract users. Further, it says that although there is no evidence that Apple intends to engage in exclusive agreements with developers, restraining it from doing so would be to inappropriately restrain a form of competition that Epic and other platforms engage in, particularly in circumstances where this is not relief sought in the FAOA. Moreover, it says that whilst such relief might be appropriate in response to a contravention of s 47, no such contravention has been established.

579    Finally, Apple says that its proposed order 2 renders Epic’s proposed order 5, insofar as aspects of it might otherwise be appropriate, unnecessary.

Analysis

580    Proposed order 5 is framed as a negative injunction that prohibits Apple from prohibiting, preventing or taking any action which is likely to hinder: (a) users of iOS devices from discovering, obtaining and updating iOS apps via alternative distribution channels, or from using iOS apps obtained in that way on iOS devices; or (b) app developers from distributing and updating such iOS apps to such users via alternative distribution channels. Before proceeding further I would again note that what follows is to be read with the geographic limitation on “user” and “App Store” that I have previously indicated.

581    Now proposed order 5(a) reflects my finding that Apple imposes technical restrictions, encoded in iOS, that mean only native apps from the App Store maybe installed on an iOS device, apart from certain trivial exceptions.

582    As to proposed order 5(b), the App Store is currently the sole, and therefore the dominant, channel for the distribution of iOS apps. This order restrains Apple from using that position to leverage its control over the App Store to hinder the growth or viability of alternative distribution channels.

583    Now Apple says that proposed order 5 exceeds Epic’s pleaded case and is not supported by my findings. And it says that Epic never ran a case that Apple would, in a future without prohibitions on the sideloading of iOS apps, prohibit, prevent or take any action which is likely to hinder users or developers from using alternative distribution channels or that any such conduct would contravene s 46.

584    But my remedial power is not confined to prohibiting the precise conduct pleaded and found to constitute the contravention as I have discussed earlier in my reasons.

585    And as I have indicated earlier, if the object of the injunction could stretch no further than proscribing the specific contravening conduct, then the offending party would be free to exert the exact same anti-competitive effect but through a modified form of conduct. Not only would this risk compromising the utility of my order and exposing the public to further harm, but it would also require the applicant to bring a fresh round of proceedings each time the offending party so varied its conduct.

586    As such, contrary to Apple’s nostalgic attempt to take me back to the dawn of the golden age of the 1980s, s 80 today permits me to grant injunctions that are appropriate to prevent, restrain or remedy that contravening conduct and its effects. Specifically, that includes restraining apprehended modes of conduct which, although not themselves the historical contravention or its centrepiece, would re-create or perpetuate the same preclusion or lessening of competition.

587    This approach is particularly apt here where the contravening conduct was based on interlocking restrictions that operated at multiple levels and targeted both developers and users, and included iOS level restrictions that prevented apps running unless they were obtained via the App Store or Apple’s pre-installation of the app. The range of restrictions that Apple relied upon to deploy, implement and enforce its contravening conduct supports the making of proposed order 5.

588    A contravention of s 46 is achieved only where the commission of certain conduct is accompanied by either a prohibited purpose or effect. Where conduct has been found to contravene s 46 because of its particular effect on competition, it follows that the successful remedy will be the one that ends not just the offending conduct itself, but also the perpetuation of its associated anti-competitive effect. In this way, the remedial purpose of s 80 is brought in line with the purpose of the CCA more generally, being to protect and enforce the public’s interest in upholding the high matters of public policy embodied in the legislative enactments of Pt IV, namely, the procurement and maintenance of competition in trade and commerce.

589    In short, I agree with Epic that it was not necessary for it to have run a case that, in a future without direct prohibitions, the specific conduct enjoined under proposed order 4 would have contravened the CCA. I found that the contravening conduct has the effect that no alternative source of supply of app distribution services is available to developers or iOS device users other than the App Store, which precludes competition.

590    Given that finding, alongside the finding that access to certain of Apple’s SDK/APIs are necessary for the viability of alternative channels of app distribution and the findings outlined, proposed order 5 contains a sufficient nexus to the relevant contravention.

591    Further, given my finding concerning Apple’s history of deploying deterrence tactics to protect its preferred arrangements, even in the face of legal compulsion proposed order 5 is an appropriate exercise of my discretion. I said at [4092]:

I agree with Epic that Apple’s ability to deploy such deterrence tactics to protect its preferred arrangements, even in the face of legal compulsion, manifests its substantial degree of market power.

592    Further, Apple contends that in so far as proposed order 5(b) enjoins Apple from imposing frictions on the use of alternative distribution channels, it is unsupported by and contrary to the liability findings. I accepted that some degree of friction may be appropriate before setting an alternative marketplace as a default, and was not able to draw any adverse conclusions about Apple’s warnings or installation processes for third-party marketplaces, finding that it had not been shown that Apple’s EU frictions are wholly disproportionate to the risks involved. I said at [4631], [4635] and [4639] the following:

Now I do agree that it may be appropriate to have some degree of friction before setting an alternative marketplace as a default. Generally speaking I accept the following three points.

…

I am not presently able to draw any specific adverse conclusions as to Apple’s warnings or installation processes for third party marketplaces in the EU.

…

Further, Apple has imposed friction on directly downloaded apps and alternative app stores in the EU, requiring a multi-screen installation process for directly downloaded apps and distribution and operational restrictions on directly downloaded apps and alternative app stores. But in my view it has not been shown that this is wholly disproportionate to the risks involved.

593    But proposed order 5(b) is not intended to prohibit frictions altogether. So, proposed order 6(i), which addresses the topic directly, reads:

The First Respondent must not (including by procuring any act of any related corporation):

…

(i)    impose frictions on or impediments to the discovery, downloading, installation, execution or updating of any iOS apps available or distributed via Alternative Distribution Channels, including alternative app stores:

(i)    that are disproportionate to the security risk posed by those apps to iOS devices and iOS device users; or

(ii)    that otherwise have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via Alternative Distribution Channels or the use of such apps by iOS device users;

…

594    Proposed order 5 is consistent with my findings that some degree of friction may be appropriate and that the EU evidence did not establish that Apple’s existing frictions are wholly disproportionate.

595    It is appropriate that I grant an order directed at preventing Apple from prohibiting, preventing or taking any action which is likely to hinder users and developers from using alternative distribution channels. It is foreseeable that Apple could diminish the viability of alternative distribution channels. I will further discuss the question of frictions in dealing with proposed order 6(i).

596    Further, proposed order 5(b) is directed at a more fundamental problem. It responds to my findings that, by Apple’s policies, contractual restrictions and technical restrictions encoded in iOS, only native apps from the App Store may be installed on an iOS device, apart from certain trivial exceptions, and that Apple pre-installs a few native Apple-developed iOS apps on iOS devices supplied in Australia. That absolute technical barrier is a core mechanism by which the App Store is made the sole distribution channel. Removing it is necessary to remedy the contravening conduct and its effects in the iOS app distribution market. It does not conflict with my acceptance of proportionate security related frictions.

597    Finally, Apple contends that proposed order 5(c) might be appropriate if there had been a contravention of s 47, but there was no such finding. But given Apple’s market power, if it could make access to the App Store conditional on developers not using alternative distribution channels, it could restore the position of the App Store as the sole source of iOS apps by contractual means, even though formal prohibitions on sideloading and alternative app stores were removed. Again, s 80 does not confine injunctive relief to prohibiting only the precise legal form of the contravening conduct, nor to conduct characterised under the same Pt IV provision.

598    Proposed order 5 does not prevent Apple from imposing conditions when licensing IP-protected tools and technologies that are necessary for app development and alternative distribution. However, given Apple’s pattern of conduct in using fees to suppress the emergence of competition, any fees must adhere to guardrails of the kind imposed on Apple by the United States Court of Appeals for the Ninth Circuit discussed earlier. Such fees and conditions would not objectively operate to hinder users or app developers in the manner prohibited by the order. Order 5 is framed by reference to an objective standard and will not be contravened by reason of unintended and objectively unlikely effects on individual developers with idiosyncratic characteristics.

599    Now Apple advances the contention that it should now be free to make it a term of any developer’s access to the App Store that they will not make iOS available via an alternative distribution channel. This suggests that unless restrained, Apple could continue to take steps to suppress competition. Now I agree with Epic that it is irrelevant that there is no finding in Epic v Apple that such a term, in isolation, would be anti-competitive because, of course, it did not exist. But there is evidence and findings in Epic v Google that supports Epic’s position by analogy of such a realistic possibility or risk; the utility of my findings in Epic v Google I accept can be put no higher than that.

600    In that proceeding at GJ[4154] I said:

Further, Google’s own assessment was that “[f]or any alternative mobile store to be successful at scale … it would need at least a couple of titles from our top ~25 developers identified by Hug”.

601    So, if Google could prevent even some of its top 25 developers from launching their titles exclusively on an alternative app store, that alternative app store would not be able to compete at scale. This of course is the strategy that Google pursued through Project Hug. This conduct limited the ability of rival app stores to compete on quality with the Play Store by differentiating themselves by attracting exclusive or early content. And I found that Google’s agreements with certain developers preventing those developers from releasing titles exclusively on alternative app stores had an anti-competitive purpose, and likely had an anti­competitive effect. Now Google argued that neither the GVP agreements nor the AVP agreements required Play Store exclusivity, but as I found at GJ[4276]:

Google also says that neither the GVP agreements nor the AVP agreements require Play Store exclusivity. But in circumstances where the Play Store is the incumbent, it does not require exclusive content in order to maintain its user base. Rather, as Epic points out, it is prospective rivals who require exclusive or differentiated content, to draw users away from the Play Store. Project Hug denied them that content.

602    The inability of rival app stores to offer exclusive or differentiated content, or even early access to content, from major developers, was found by me to be a real impediment to the success of a rival Android app store, since, without access to exclusive or differentiated content from key app developers, it will be even more difficult to entice users and developers away from the Play Store. I said (at GJ [2844]):

Seventh, during the relevant period, by reason of the GVP and AVP agreements, rival Android app stores were unable to offer exclusive or differentiated content, or even early access to content, from the major developers who were party to those agreements with Google. This is a real impediment to the success of a rival Android app store, since, without access to exclusive or differentiated content from key app developers, it will be even more difficult to entice users and developers away from the Play Store.

603    It would seem that Apple may require developers who wish to distribute apps via the App Store to agree to terms with more far-reaching anti-competitive effect than the terms of the impugned Project Hug agreements. Whilst the GVP agreements did not technically require developers to release content exclusively on the Play Store, the fact that those agreements prevented exclusive releases off–Play was enough to render the terms anti­competitive in likely effect in circumstances where the Play Store is the incumbent. So, the same would be true of any terms imposed by Apple requiring developers to distribute apps exclusively through the App Store if they wish to utilise that distribution channel at all, given the App Store’s status as the incumbent app distribution channel in the distribution market.

604    My findings in Epic v Google support the proposition that a restraint on the imposition of such terms as proposed by order 5(c) is justified.

605    Finally, and as I have indicated, proposed order 5 would not prevent Apple performing its Australian statutory obligations. I have added a necessary carve-out to ensure that proposed order 5 does not inhibit Apple’s compliance with its obligations under the Online Safety Act and associated Codes.

Proposed order 6 (order 5 as modified and made)    

606    Apple says that Epic’s further prohibitive injunction in proposed order 6 is also unwarranted. I would note that this corresponds, with modification, to order 5 that I have made.

607    It points out that proposed order 6 stipulates 11 categories of conduct and that the common thread running between these appears to be that each category of conduct represents means by which an operator of an ecosystem in Apple’s position could seek to disfavour direct downloading of native apps.

608    Apple says that whether it could or would engage in such conduct, and whether if and to the extent that Apple did so that conduct would contravene the CCA, was not the subject of any pleading by Epic, and was not explored at trial and in my liability findings. It says that I have made no findings and there is no evidence that any of those 11 categories of conduct would contravene the CCA.

609    Apple says that it follows that the conduct the subject of proposed order 6 lies outside the case or controversy brought before me in these proceedings.

610    Further, Apple says that a further reason why proposed order 6 should not be made can be found in the assumptions that justified my liability findings.

611    It says that I found as an aspect of the counterfactual that Apple’s conduct in the counterfactual would be lawful, that is, Apple would not impose other anti-competitive restrictions that would have the same or similar effect as the iOS app distribution conduct. I also declined to draw an inference that, in the counterfactual, Apple likely would not license alternative app stores.

612    And it says that Epic declined to specify how or on what terms it said Apple’s offering would change in the counterfactual, and asked me only to find that in the counterfactual Apple could and likely would licence its intellectual property.

613    But it says that Epic’s proposed order 6 now seeks in effect to populate what I said in [5220] with negative content. In that paragraph I said:

In the counterfactual, the impediments that Apple imposes on alternative app stores and direct downloading on iOS devices would be removed. It must also be assumed that Apple’s conduct in the counterfactual would be lawful, that is, Apple would not impose other anti-competitive restrictions that would have the same or similar effect as the iOS app distribution conduct.

614    Apple says that proposed order 6 seeks to convert my finding that in the counterfactual Apple would not impose other anti-competitive restrictions into a long series of restrictions on Apple’s conduct in the world without the impugned prohibitions, presumably on the footing that if Apple were to take any of the steps proposed order 6 would proscribe, it would contravene s 46.

615    Apple says that in circumstances where Epic’s case was that it was not required to specify how Apple’s offering would alter in the counterfactual and the liability findings accepted that the counterfactual was sufficiently clearly delineated by the proposition that Apple could and would license its intellectual property, there is no warrant or occasion for Epic now to seek to confine and limit, as proposed order 6 seeks to do, the ways in and terms on which Apple may license its intellectual property.

616    Apple says that if it was to be alleged and found that any of the categories of conduct itemised in proposed order 6 would, if engaged in, contravene s 46, the time for that was in and through the competition analysis integral to my liability findings.

617    Apple says that Epic, having refused to specify in any way how it said Apple would restructure its offerings if its prohibitions on alternative app stores and sideloading were found to be unlawful it cannot now be heard to allege and I should not enter into any analysis or make any findings about what avenues are open to Apple in a world without those prohibitions.

618    Further, Apple says that contrary to proposed order 6(a), there is no basis either in principle or in my liability findings for restraining Apple from imposing any fees or conditions on access to, or use of, alternative distribution channels. Epic seeks to justify this order on the basis that, where an app is distributed via an alternative distribution channel, Apple provides no distribution service such that it can be inferred that any fee or condition that Apple might elect to impose would, more likely than not, be designed to maintain Apple’s dominance in one or both of the relevant markets. But Apple says that this overlooks the fact that the development and use of such channels requires access to Apple’s intellectual property and that transactions via alternative distribution channels take place in an ecosystem Apple has built and maintains, and must be permitted to earn revenue in and through. Accordingly, there is no basis for inferring that any fee Apple might charge would have an illicit purpose.

619    Further, Apple says that there is no basis in my reasons or otherwise to restrain Apple from imposing any fees or conditions on access to alternative distribution channels by iOS app developers and iOS users.

620    As I found, it is appropriate that Apple be able to recover a commercial return on its highly valuable IP-protected assets, including the tools and services that facilitate alternative app distribution. Moreover, Apple must be able to impose appropriate conditions on the use of technologies that facilitate alternative distribution. Apple’s proposed order 2 would prevent Apple from imposing terms that unreasonably prevent or hinder the use of alternative app distribution. Beyond that, no order in the nature of Epic’s proposed order 6(a) is appropriate.

621    Further, Apple says that proposed order 6(b), if it is said to do something other than enjoin the imposition of any fees at all, would require Apple to assess whether any fee had an effect or likely effect of lessening competition before imposing it. But it says that analysis of that kind cannot be required of a party in order to ascertain whether or not a given step would place them in contempt of court.

622    Further, Apple says that Epic is wrong to say that Apple would necessarily be acting with a substantial proscribed purpose if it were to act contrary to such a prohibition.

623    Further, one part of order 6(b) is a prohibition on the imposition of fees or conditions on access to, or use of, tools or APIs including SDKs that have the purpose, effect, or likely effect of preventing, hindering or deterring alternative app distribution. But Apple says that Epic’s proposed limitation, which adopts statutory language of purpose, effect, or likely effect but couples it with a different concept of preventing, hindering or deterring, creates a standard too complex and subjective to be properly used in an injunction. Moreover, that prohibition would extend to conduct with the likely effect of deterring alternative distribution.

624    Apple says that there is no justification in the judgment or otherwise for such an onerous limitation on Apple’s licensing of intellectual property and it is not required to address or prevent the conduct that I found to be in contravention of s 46 of the CCA. Apple has millions of developers and almost any condition, no matter how benign, would be likely to deter at least some of them from taking up alternative distribution, thus putting Apple at risk of contempt of this proposed injunction.

625    Further, the other part of order 6(b) is a prohibition on imposing fees higher, or conditions more onerous, than those applied to developers of iOS apps which are monetised other than through in-app purchases, including free apps and apps monetised through advertising, when distributed via the App Store. Apple says that this would either preclude Apple charging any fee beyond the annual USD 99 developer program fee or require it to impose fees not presently charged on such developers who have not been heard. But Apple says that it is not appropriate for me to impose any limits on the fees that Apple can charge by reference to the fees that it charges to particular categories of developers, being in this case developers of free apps and those monetised through advertising. Those developers have not had an opportunity to be heard in this proceeding.

626    Further, Apple says that there was no allegation and no finding by me that charging different categories of developers different fees, in the licensing of Apple’s intellectual property, would have anti-competitive effects. The ability to charge different licensees different prices is an ordinary incident of intellectual property rights and a common practice where different licensees exploit the intellectual property in different ways or earn different revenues (or no revenue) from that exploitation.

627    Specifically, I found that in 2021 more than 85% of apps on the Australian App Store storefront were free to download and did not have any in-app purchases. Apple facilitates the creation and distribution of those apps by licensing its software and other tools used to develop the apps and charging those developers only the annual program fee of USD 99.

628    Epic’s proposed orders would require that, unless Apple is willing to license its software to Epic and other developers who use alternative distribution for the same USD 99 fee, it must charge developers of free apps more. Apple says that that is not reasonable, and is not shown to be pro-competitive, in circumstances where Epic unlike developers of free apps would be expected to earn very substantial revenues from the iOS version of Fortnite.

629    Further, Apple says that ultimately, order 6(b) would undermine the viability of the business model that Apple has adopted in relation to free apps, adversely impacting upon the majority of developers whose apps are free, and also consumers who benefit from the availability of free apps.

630    Further, Apple says that proposed orders 6(c) and (d) would prevent Apple from competing with alternative distribution channels by requiring that app developers offer App Store users no less favourable terms and conditions than they offer users of alternative distribution channels. It says that there is no foundation in my findings against Apple or in the evidence for preventing Apple from competing by such means, a fact which Epic’s reliance on findings in Epic v Google underscores.

631    It says that no part of [4822] and [4823] records a finding that each and every one of the many provisions of the DPLA and the App Review Guidelines Epic sought to impugn was imposed and enforced in contravention of s 46.

632    Further, Epic’s proposed order 6(c) seeks to limit the manner in which the App Store can compete with rival app stores, by prohibiting Apple from making it a condition of App Store distribution that an app, or digital content for use in app, not be made available on more favourable terms, or with other benefits, elsewhere. Apple says that such a limitation would be market–distorting in circumstances where it would not equally apply to the EGS, the Play Store, the Samsung Galaxy Store, or any other app store or platform that the App Store competes with.

633    Further, proposed order 6(d) would restrain Apple from entering into “most favoured nations” arrangements with developers, by requiring them to make content, subscriptions or features available via their apps distributed on the App Store if that content, subscription or feature is made available to users of the same app on other platforms. Apple says that such a restraint would also be market–distorting.

634    Further, it says that most favoured nation clauses are not inherently anti-competitive and they can be legitimate competitive responses to exclusive arrangements that are common in this industry. Again, Apple says that no economic analysis demonstrates that it would be anticompetitive for Apple to engage in such conduct, and there is no basis for me to enjoin Apple from engaging in it.

635    Further, Apple says that Epic’s proposed order 6(e) would restrain it from prohibiting, preventing, or taking any action, including imposing any fee or condition which is likely to hinder an alternative app store operator from making and implementing their own choices as to which apps they will distribute via their app store, contrary to [4736] to [4739]. I said at [4736] to [4739]:

As to the third matter, post-distribution security would be maintained irrespective of decentralised distribution.

Under a decentralised app distribution model, Apple would be able to maintain its ability to safeguard the security of iOS devices after apps are distributed, regardless of their distribution channel.

First, Apple would have the ability to remove and disable bad apps distributed outside the App Store, given that those apps would have passed through iOS notarization or its equivalent. Apple’s digital signing of all iOS apps means that Apple can at any time revoke the signature of an iOS app, such that it ceases to be capable of being installed or run on an iOS device. It follows that Apple would be able to enforce any decision it might make about the threat posed by an arbitrary iOS app to the security of iOS devices. Apple would thereby act as a single point of enforcement, regardless of the app’s distribution channel.

Second, given that each and every iOS app would be centrally reviewed by Apple, Apple would at any time be capable of re-scanning or re-analysing a previously submitted app, based on any new information, intelligence, or progress in scanning technology. And if an app previously thought to be innocuous were to be identified as malicious in this way, Apple could disable it by revoking its digital signature.

636    Apple says that that order would prevent Apple from engaging in notarization or other forms of app review and so it is inappropriate and inconsistent with my judgment. Further, Apple says that whatever other operation it might have, the order is unnecessary in circumstances where Apple proposes an injunction in its proposed order 2 that would restrain it from unreasonably preventing or hindering alternative app distribution.

637    Epic says that proposed order 6(e) addresses the risk that Apple may attempt to limit the choice of alternative app store operators as to which apps they distribute, but Apple says that this asserted risk is incidental to Apple’s legitimate, pro-competitive interest in maintaining the safety and security of its ecosystem.

638    As to proposed order 6(f), Apple says that my liability findings provide no warrant for limiting Apple’s freedom to regulate its ecosystem in the manner proposed. Proposed order 6(f) would prevent Apple from requiring app developers using alternative distribution channels only to use as agents, for example, persons who meet certain standards of technical and financial security. Moreover, Apple says that Epic’s proposed order 6(f) is unnecessary in circumstances where Apple’s proposed order 2 would restrain it from unreasonably preventing or hindering alternative app distribution.

639    As to proposed order 6(g), Apple says that a restraint on it prohibiting the pre-installation of third–party apps on iOS devices is unwarranted, for the reasons already given in respect of the declaratory relief sought in order 1(b)(vi). Further, proposed order 6(g) remains inappropriate in circumstances where Apple is the only manufacturer of iOS devices.

640    Further, Apple says that proposed order 6(h) goes beyond the pleaded case, by reference to steps which I found Apple would be permitted to take in the counterfactual and employs matters of controversy and judgment (“poses a genuine security risk”; “requires urgent elimination”) which cannot practicably form part of any workable regime of injunctive relief.

641    Further, Apple says that Epic’s proposed order 6(h) would require it to give developers reasonable notice of the existence, nature and extent of security risks before disabling or removing apps. It says that this is inappropriate because it cannot be assumed that all of the developers in its Developer Program are acting in good faith. It says that order 6(h) is inappropriate because it would prevent Apple from acting immediately to protect iOS users from fraud and other security risks. It says that in the case of a bad actor, disclosing any security vulnerability which Apple has identified to that developer could aid in the bad actor reverse engineering Apple’s malware detection capabilities. Moreover, it says that Professor Somayaji agreed that there are circumstances in which apps should be disabled or deleted from end-user devices without notice to developers, including, at least, in the case of malicious apps and apps that compromise sandboxing. I will say more about Professor Somayaji’s evidence later.

642    Further, Apple says that proposed order 6(i) has the same problems as proposed order 5 insofar as the latter order would limit Apple’s ability to impose frictions on the use of alternative distribution channels. Further, it says that the imprecise nature of the drafting makes it unclear whether any default safety settings and tools implemented by Apple pursuant to its Online Safety Act obligations could be characterised as impermissible frictions or impediments that are prohibited by proposed order 6(i).

643    Further, Apple says that I declined to find that Apple imposed disproportionate frictions or impediments on alternative app distribution in the EU and accepted that some such restrictions are appropriate.

644    Further, Apple says that the evidence from Mr Grant does not justify revisiting my finding that it has not been shown that Apple’s installation process in the EU is disproportionate to the security risks involved. Nor does it justify a finding that Apple is likely to impose disproportionate frictions in the future.

645    Further, Apple says that proposed order 6(j) is unsupported by the liability findings against Apple and unduly limits, in a manner that is contrary to my disposition of arguments concerning the pro-competitive aspects of the impugned conduct, Apple’s ability to regulate its ecosystem. This restraint would prevent Apple from requiring the app developers who use alternative distribution channels only to use payment methods which meet certain standards of technical and financial security.

646    Further, Apple says that Epic’s proposed order 6(j) would prohibit it from requiring that developers offer or use any particular payment method in apps distributed via alternative distribution channels. Apple says that to the extent that that order is intended to, or could be interpreted to, prevent Apple from requiring that developers use payment methods that adhere to technical and financial security standards, it is inappropriate. It says that I have found, relevantly, that Apple has a legitimate interest in maintaining the overall standards of the ecosystem.

647    Further, Apple says that proposed order 6(k) seeks to repurpose reasons on aspects of power and market to justify restraints targeting asserted or apprehended anti-competitive effects. It would fetter Apple’s commercial freedom in a manner and to an extent which none of the liability findings justify.

648    Apple says that proposed order 6(k) would prevent it from requiring that developers enter into any contractual arrangement other than a licence of Apple’s tools and APIs for the development of iOS apps as a condition of distributing apps via alternative distribution. But Apple says that that prohibition is inappropriate and not justified by my findings.

Analysis

649    Proposed order 6 is a negative injunction, prohibiting Apple from engaging in specific categories of conduct that would lessen or prevent competition in the distribution market. It does not prevent Apple from imposing fees or conditions on the distribution of iOS apps via the App Store, or for the use of IAP. Nor does it prevent Apple from charging app developers a fee for their use of Apple’s tools or APIs to develop and distribute iOS apps.

650    Now Apple has raised a number of general objections in relation to proposed order 6, but none have any real merit.

651    First, Apple contends that proposed order 6 is outside the case or controversy. But proposed order 6 responds to my findings. I found that Apple’s iOS app distribution conduct had both the purpose, and the effect and likely effect, of substantially lessening competition. Further, I found that Apple’s conduct was engaged in for the substantial purpose of maintaining the App Store as the only store-like interface on iOS devices, with a view to protecting Apple’s revenue from any threat of competition. Further, I found that the practical effect was that no alternative source of supply of iOS app distribution services was available to developers or iOS device users other than the App Store, which precludes competition.

652    Proposed order 6 responds to those findings by enjoining Apple from engaging in 11 specific types of conduct. That approach is warranted by findings which establish that Apple devised and pursued a deliberate and comprehensive strategy of foreclosure in relation to iOS app distribution. I found at [4108]:

Second, it could not seriously be doubted that Apple imposes and enforces its restrictive terms with impunity. The fact that Apple is not constrained by competition is apparent from its uninhibited ability to impose and enforce its restrictive terms concerning iOS app distribution. Apple enforces those terms inflexibly and refuses to accommodate the needs of even the largest developers. The instances in which Apple has enforced its restrictive terms to foreclose competition are too numerous to set out in full.

653    I also found that Apple devises ways by which it can continue to foreclose competition even in the face of regulatory obligations, and that its response to the DMA in Europe was designed to dissuade developers from taking up alternative payment solutions. I said at [5830] and [6005]:

As I have explained elsewhere, in Europe, where Apple has been forced to allow developers to offer alternative payment solutions for in-app purchases, Apple imposes a series of restrictions designed to dissuade developers from taking up that option, including an obligation to pay a core technology fee. But even under those conditions, Apple accepts that some large developers may value having their own alternate payments arrangement.

…

In these instances, even regulatory obligations have not prevented Apple from devising ways by which it can continue to foreclose competition. The same applies to Apple’s response to the enactment of the Digital Markets Act.

654    If one was not to enjoin Apple from engaging in specific conduct that would undermine the viability of alternative distribution channels, this would leave the door open for Apple to continue its pattern of imposing further terms, conditions and charges upon developers designed to prevent the emergence of competition. Apple has repeatedly implemented practices of purported compliance that seek to circumvent the practical effects of regulatory and judicial constraints. So, absent appropriate restraint, it is likely that Apple would employ similar circumvention techniques here.

655    Second, Apple contends that whether it could or would engage in conduct the subject of proposed order 6 and whether that conduct would contravene s 46 was not pleaded by Epic, and was unexplored at trial and in the liability findings. But s 80 permits injunctions that are appropriate to prevent, restrain or remedy Apple’s contravening conduct and its effects, including orders that restrain apprehended modes of conduct which re-create or perpetuate the same foreclosure and anti-competitive purpose. But in any event, many of the sub-paragraphs of proposed order 6 are directed at conduct which I condemned and were the subject of detailed evidence and reasoning.

656    Third, Apple has emphasised its freedom to regulate its ecosystem and the threat that proposed order 6 poses in denying or severely limiting the means by which Apple can monetise and regulate its ecosystem.

657    Apple’s asserted freedom to regulate its ecosystem is no shield. It is not a freestanding interest that I am required to safeguard when exercising my powers under s 80. That provision authorises me to fashion orders that are appropriate to prevent, restrain or remedy the contravening conduct and its effects. In this case, I am authorised to grant relief that safeguards competition in the iOS app distribution market that has hitherto been completely foreclosed, even if in doing so the orders fundamentally alter the way Apple currently operates.

658    Further, Apple does not own any such ecosystem. It holds copyright in the iOS operating system which it has fully licensed to users. And it needs and licenses developers to create iOS apps for users. All of Apple’s licensing decisions and arrangements are subject to the CCA. Further, s 80 exists to restrain the misuse of commercial power. The fact that an injunction may fetter Apple’s power or freedom where Apple has misused it is not an objection.

659    Fourth, Apple claims that proposed order 6 impermissibly seeks to populate the counterfactual assumption with a list of negative prescriptions, but that Epic declined at trial to specify how Apple’s offering would change beyond a finding that Apple could and would license its IP; see what I said at [5220] and [5237].

660    But Apple has confused the relevant inquiry. Assumptions and findings about Apple’s licensing of its IP were for the purposes of my counterfactual inquiry and directed to the liability question. They do not confine my remedial powers. As I have said elsewhere, I am free under s 80 to grant such injunctions as I determine to be appropriate to prevent, restrain or remedy the contravening conduct and its effects and to prevent any attempt to circumvent the relief ordered. An implied limitation that the relief granted must mirror the bare assumptions used in the counterfactual inquiry cannot be read into the terms of s 80.

661    Let me now go through the sub-paragraphs of the proposed order 6.

Proposed order 6(a)

662    As to proposed order 6(a), I found that in the European Union in response to the DMA, Apple requires developers who wish to distribute iOS apps via alternative distribution channels to pay Apple a so-called core technology fee based on downloads (CTF). I found that the CTF, and restrictions implemented by Apple more generally in response to the DMA, were designed by Apple to dissuade developers from taking up alternative payment solutions. Order 6(a) responds to those findings. Where an app is distributed via an alternative distribution channel, Apple provides no distribution service. Accordingly, it is reasonable to infer that any fee or condition that Apple might elect to impose for access to, or use of, an alternative distribution channel would, more likely than not, be designed to maintain Apple’s dominance in one or both of the relevant markets. Apple should therefore be restrained from doing so. To be clear, this order would not prevent Apple from charging a fee in connection with the use by developers of its technology.

663    Apple claims that there is no basis in principle or in the findings to restrain it from imposing any fees or conditions on access to alternative distribution channels. It contends that the development and use of such channels requires access to its IP, and that transactions occur within an ecosystem Apple has built and maintains, so it cannot be inferred that any fee would have an illicit purpose.

664    But proposed order 6(a) is directed at the kind of charges that Apple has imposed in response to the DMA, which I have found were designed to dissuade developers from using alternative payment solutions. In light of those findings and my conclusions as to Apple’s substantial anticompetitive purpose, there is a sound basis for relief that prevents Apple from imposing additional, channel-specific fees or conditions targeted at alternative distribution channels. Proposed order 6(a) leaves intact Apple’s ability to charge for legitimate use of its IP and tools.

665    Proposed order 6(a) proscribes additional, channel-specific fees or conditions, including core technology type fees structured by reference to downloads via alternative distribution channels, that have the purpose, effect or likely effect of deterring the use of those channels.

666    In continuing to protest Epic’s proposed prohibition on the imposition of fees or conditions on access to alternative distribution channels, Apple ignores my finding that the charges Apple imposed in response to the DMA were designed to dissuade developers from using alternative payment solutions. A prohibition on equivalent fees in respect of alternative distribution channels is appropriate in light of the conduct Apple has engaged in to date, and my findings as to Apple’s anti-competitive purpose. The same reasoning requires a prohibition on conditions; see proposed order 6(a).

667    Further, Apple has led no evidence that any Apple IP is used when a developer’s app is downloaded by an iOS user. Nor is there any evidence as to the costs associated with it offering the necessary tools to developers and users to permit app distribution via alternative channels.

668    I said at [5319], [5325] to [5331] and [5338]:

So, I infer that any SDKs or APIs that may be necessary for a developer to use in the development of an iOS app are the subject of the Xcode agreement.

…

As to Apple’s suggestion that additional Apple software would be necessary to develop alternative app stores or to facilitate direct downloads, Apple has led no evidence to this effect. It was in a position to do so. I would not draw inferences favourable to Apple in the absence of such evidence. Apple’s contention is inconsistent with the evidence before me as to the development of alternative app stores or apps available for direct download on macOS.

Further, as Epic points out, there are additional reasons that justify me in rejecting any suggestion that Apple is willing to license its software for use in developing iOS apps only on the condition that they be distributed solely through the App Store.

First, Apple permits developers to distribute their iOS apps to individuals within their organisation on a limited number of devices. Developers enrolled in the Apple developer enterprise program can distribute internal-use-only apps to employees of large organisations.

Second, Apple permits distribution by developers of “Custom Apps” through “Custom App Distribution”, being the store functionality that enables users to obtain apps through the use of Apple business manager, Apple school manager, or as otherwise permitted by Apple.

Third, in Europe Apple permits the distribution of iOS apps outside of the App Store. This demonstrates the possibility of Apple licensing any intellectual property necessary for the distribution of iOS apps through alternative methods of distribution when its preferred monopoly position is disturbed.

Now Apple says, without evidence, that there is no reason to think that Apple would extend access to its SDKs and APIs to assist in the development of alternative app stores for iOS to developers beyond Europe, or that developers could create such apps without Apple’s SDKs and APIs.

Even if I accepted the premise that such software would be necessary, which is unsupported by the evidence, these are not inferences that I would draw given Apple’s failure to lead evidence on the topic.

…

Now Apple says that there is no evidence that any licence fee it might lawfully charge would be so low, or the other terms it might offer would be sufficiently attractive, as to permit viable third-party stores or direct downloading. But Apple has failed to prove the value of any intellectual property rights that Apple says would inevitably need to be licensed by the developer of an iOS app. Accordingly, I cannot speculate as to what a commercial return might be, if Apple were in the counterfactual to seek to monetise its investments in some different way.

669    Apple’s complaint that it ought not be prohibited from imposing fees or conditions that have the likely effect of prohibiting, preventing or taking any action which is likely to hinder the distribution or updating of iOS apps via alternative distribution channels on the basis that such a prohibition is overly onerous should be rejected. Such a prohibition is appropriate having regard to my findings as to Apple’s substantial anti-competitive purpose in prohibiting alternative distribution channels, and its conduct in other jurisdictions where it has sought to maintain its existing business model and to raise obstacles to competition to the greatest extent possible in the face of regulatory intervention.

Proposed order 6(b)

670    As to proposed order 6(b), I found that the decentralised distribution of iOS apps cannot occur without access to Apple’s intellectual property. Further, I accepted that Apple ought to be able to charge developers for the use of its intellectual property, provided that the imposition of any such charge was lawful and not itself contrary to s 46. Order 6(b) reflects these matters, by restraining Apple from imposing any fees or conditions for access to Apple’s tools or APIs necessary for app developers to develop and distribute iOS apps via alternative distribution channels that have the purpose, effect or likely effect of preventing, hindering or deterring the distribution or updating of iOS apps via alternative distribution channels.

671    Proposed order 6(b) identifies a specific example of a proscribed fee or condition, being a fee that is higher, or a condition more onerous, than those applied to developers of iOS apps which are monetised other than through in-app purchases when distributed via the App Store. I found that developers of iOS apps currently access the same tools or APIs to develop and distribute iOS apps as part of the Developer Program, irrespective of monetisation method, and that developers pay Apple a fixed annual program fee, which is currently USD 99, to gain access to Apple’s technology and tools for, and associated with, the development of apps, whether for iOS, iPadOS, macOS or other Apple operating system.

672    In all the circumstances, including my finding of Apple’s long-held and unlawful purpose in foreclosing competition in the distribution market, if Apple were now to impose selectively disadvantageous fees or conditions for access to its tools and APIs on developers of apps monetised through in-app purchases, at least a substantial purpose for engaging in that conduct would be a proscribed purpose. In addition to evidencing a proscribed purpose, the imposition of deterrent fees or conditions of that kind would likely reproduce the exclusionary effects that I found to contravene s 46.

673    Now Apple contends that if proposed order 6(b) is not read as a blanket ban on any fees, it would require Apple, before imposing any fee, to analyse whether it has the effect or likely effect of lessening competition before imposing it.

674    The “purpose, effect or likely effect” formulation is not an impermissibly uncertain standard. It uses familiar language, and is directed to a concrete question, being whether the fee or condition would materially obstruct distribution via alternative distribution channels, not whether it has some abstract “effect on competition”. ICI at 261 endorsed the expression “to the like effect” as an example of a permissible injunction.

675    Apple further contends that the parity requirement would either preclude Apple charging any fee beyond the USD 99 annual developer fee or require it to impose new fees on those other developers. But this mischaracterises the nature of proposed order 6(b), which employs a non-discrimination safeguard, not a fee cap nor a compulsory fee on developers. Proposed order 6(b) uses the fixed annual program fee as a comparator to prevent Apple imposing selectively disadvantageous fees or conditions on developers whose apps are distributed via alternative distribution channels. It prevents Apple from imposing additional or more onerous fees on alternative distribution channels by reason of their use of those channels, and in so doing, prevents Apple from preferencing distribution through the App Store.

676    Against the findings as to Apple’s substantial anti-competitive purpose and pattern of devising anticompetitive strategies set out above, it is appropriate under s 80 to frame relief which constrains the use of fees as a mechanism of foreclosure, including by building in a non-discrimination standard so as to prevent the inappropriate preferencing of the App Store.

677    Contrary to Apple’s contention, the non-discrimination safeguard imposed by order 6(b) is appropriate having regard to my findings. I found that developers of iOS apps currently access the same tools or APIs to develop and distribute iOS apps as part of the Apple Developer Program irrespective of monetisation method. Further, I found that developers pay Apple a fixed program fee to gain access to Apple’s technology and tools for, and associated with, the development of apps, whether for iOS, iPadOS, macOS or other Apple operating systems.

678    In those circumstances, having regard to my findings as to Apple’s unlawful purpose in foreclosing competition in the distribution market, if Apple were now able to discriminate between developers who monetise their apps through in-app purchases and those who do not, that would obstruct the emergence of competition. And a substantial purpose of such discrimination would be a proscribed purpose.

679    Against the background of my findings as to Apple’s anti-competitive purpose and pattern of devising anti-competitive strategies, it is appropriate in the public interest to use the wide power conferred by s 80 to constrain Apple’s use of fees as a mechanism of foreclosure through imposing a non-discrimination standard as proposed by order 6(b).

680    Apple’s attempt to oppose order 6(b) on the basis that developers who do not monetise their apps through in-app purchases have not had an opportunity to be heard should be rejected. Epic is a developer of, inter alia, free games. Further, order 6(b) is not inherently adverse to such developers’ interests. Whether or not that is so depends on whether Apple makes a business decision to increase fees imposed on such developers in response to my orders. Apple has led no evidence that it will. It should not be assumed that Apple will take that course, given that Apple benefits from the creation, availability and usage of iOS apps by reason of network effects and so is incentivised to provide services to encourage developers to offer iOS apps, including for free.

681    Nor is there any evidence to support the assertion that order 6(b) would undermine the viability of the business model that Apple has adopted in relation to free apps. The objective of s 80 is to advance the public interest, and Apple’s business choices cannot stand in the way of that objective.

Proposed orders 6(c) and (d)

682    As to proposed order 6(c), in Epic v Google I found that Google prohibits price competition in the context of the user choice billing (UCB) program, other than in South Korea (GJ[638], [5374], [5379]). Conduct of a similar kind is addressed by order 6(c), in the context of the distribution market.

683    I agree with Epic that the fact that Apple does not currently require price parity between platforms is beside the point. Until now, Apple has eliminated any opportunity for price competition altogether by foreclosing all alternative distribution channels for iOS apps.

684    As to proposed order 6(d), I found that one of the terms of the DPLA that Apple imposed and enforced on developers in contravention of s 46 was a term prohibiting app developers from allowing users to access content, subscriptions or features they purchased from the developer’s own website, or another app distribution channel, without also making it available as an in-app purchase within their iOS apps distributed via the App Store, subject to limited exceptions. In Epic v Google, I found that Google had entered into agreements with certain developers which required them to ensure that the core content, features and functionality of mobile titles available on the Play Store were the same as on comparable platforms and through other mobile distribution channels, which clauses were found to be directed at hindering rivals from competing by enticing users away from the Play Store. Proposed order 6(d) responds to those findings by restraining Apple from hindering competition in the distribution market by limiting product differentiation as between the App Store and rival distribution channels.

685    Apple contends that proposed orders 6(c) and (d) would prevent it from competing with alternative distribution channels by requiring that developers offer App Store users no less favourable terms and conditions than users of alternative distribution channels. Apple claims there is no foundation in my findings for restraining Apple in this way, and that no part of my judgment records a finding that each of the relevant provisions of the DPLA and the App Review Guidelines that Epic impugned was imposed and enforced in contravention of s 46.

686    Proposed orders 6(c) and (d) prevent Apple from using its market power to suppress price and content differentiation on rival channels and, in doing so, neutralising that source of competition. They do not prevent Apple from competing with alternative distribution channels on the merits.

687    As I have said, Apple has until now completely foreclosed competition in iOS app distribution by eliminating alternative distribution channels altogether. Given Apple’s substantial anti-competitive purpose and pattern of devising anti-competitive strategies, it is appropriate under s 80 to restrain Apple from continuing to insulate the App Store from competition by undermining the effectiveness of alternative channels.

688    The order prohibits Apple from requiring developers who use alternative distribution channels to refrain from offering their apps at lower prices or with favourable discounts or benefits, compared to when the same app is distributed via the App Store. Any such requirement imposed by Apple, a company with continuing market power, would be likely to suppress competition between the alternative channel and the App Store. The order does not prevent Apple responding to such discounts or benefits by a competitor such as the EGS by offering its own discounts or benefits.

689    Proposed order 6(d) restrains Apple from hindering competition in the distribution market by limiting product differentiation as between the App Store, and rival distribution channels. As I have said, it responds directly to my finding that the contravening conduct included a term prohibiting app developers from allowing users to access content, subscriptions or features they purchased from the developer’s own website, or another app distribution channel, without also making it available as an in-app purchase within their iOS apps distributed via the App Store. Contrary to Apple’s assertions, proposed order 6(d) does not depend on a finding that every provision of the DPLA and the App Review Guidelines that Epic challenged was individually held to contravene s 46.

690    Proposed order 6(d) provides that Apple must not require developers who make app contents, subscriptions or features available via alternative distribution channels to also make that same content available when the app is distributed via the App Store. In a competitive market, there is no reason why a developer should not be able to offer differentiated content that preferences one distribution channel over another, including where it is cheaper or commercially beneficial for it to do so.

691    Further, Apple’s submission that proposed orders 6(c) and (d) are unsupported by competition analysis and would be market-distorting ignores the evidence adduced and findings made in the Epic v Google proceeding.

692    Certain of the AVP agreements included price parity clauses of the kind prohibited by order 6(c) (GJ[4175]), and the GVP agreements included “content parity” clauses of the kind prohibited by order 6(d) (GJ[4129]). I found that these terms of the AVP agreements had an anti-competitive purpose, and the terms of the GVP agreements were both anti-competitive in purpose and likely effect. The primary reason I did not consider the AVP agreements to be anti-competitive in likely effect was because AVP agreements were only signed with four developers.

693    If an incumbent with substantial market power such as Apple were permitted to impose price parity and content parity clauses on all developers, as Apple seeks to do, self-evidently the effect would be to substantially lessen competition in the app distribution market. The evidence and my findings in Epic v Google suggest this to say the least.

Proposed order 6(e)

694    As to proposed order 6(e), this order addresses the risk that Apple may attempt to limit the choice of app store operators as to which apps they distribute via their alternative app stores, much as Apple has done in respect of developer choice of payment methods for purchases of digital content for use in-app.

695    Apple’s contention that proposed order 6(e) would prevent it from requiring apps offered by alternative app stores to be notarised by Apple is not correct. Proposed order 6(e) is not directed at neutral security measures such as notarisation or malware scanning. It is directed at preventing Apple from using its market power to dictate which apps an alternative app store operator may carry, for anti-competitive reasons.

Proposed order 6(f)

696    As to proposed order 6(f), I found that Apple’s current arrangements under the DPLA, which include a requirement that developers appoint it as the developer’s agent for the marketing and downloading of the developer’s iOS apps, gives rise to a relationship of forced agency. That is an aspect of Apple’s conduct that I found has the purpose and effect of substantially lessening of competition in the distribution market. There can be no warrant for Apple requiring the appointment of any particular person as a developer’s agent in respect of the distribution of iOS apps via alternative distribution channels, and proposed order 6(f) restrains Apple from doing so.

697    Apple contends that the forced agency findings were part of a broader complex of conduct and do not justify a specific restraint of the kind in proposed order 6(f). It also claims that the order would prevent Apple from requiring developers using alternative distribution channels to use only agents who meet certain technical or financial security standards.

698    I treated the forced agency structure as one aspect of the iOS restrictive terms imposed and enforced by Apple with a substantial anti-competitive purpose and effect. That forced agency was expressed to apply generally, and prevented a developer independently managing the distribution of its own apps, the supply of its own or chosen payment solution, and its relationship with its own customers. It was part and parcel of Apple’s contravening conduct. Section 80 permits me to target particular features of that complex of conduct, where doing so is appropriate to prevent or remedy the contravention and its effects. Proposed order 6(f) is a narrowly-focused restraint on replicating that forced-agency model in relation to alternative distribution channels.

699    Given that Apple’s forced-agency arrangements formed part of the contravening conduct and that Apple has used its asserted power over its so-called ecosystem control to foreclose competition, there is no warrant for preserving a freedom to insist on particular agents in respect of alternative distribution channels.

Proposed order 6(g)

700    As to proposed order 6(g), I found that Apple prohibits the pre-installation of third-party apps, including app stores, on iOS devices, and that this prohibition is an aspect of Apple’s contravening conduct. Order 6(g) responds to this finding.

701    Apple contends that a restraint on prohibiting pre-installation of third-party apps including alternative app stores is unwarranted for the same reasons it has given in relation to declaratory relief for preinstallation (proposed order 1(b)(vi)). But as I say, the prohibition on pre-installation was regarded by me as an aspect of the contravening iOS app distribution conduct.

Proposed order 6(h)

702    As to proposed order 6(h), I made findings to the effect that under a decentralised app distribution model Apple could implement a notarization or equivalent process, which would permit Apple to be able to enforce any decision it might make about the threat posed by an arbitrary iOS app to the security of iOS devices, including by revoking its digital signature. Order 6(h) enjoins Apple from exercising any such power, other than in the limited circumstances identified in sub-paragraphs (i) and (ii).

703    As I have said, Apple contends that proposed order 6(h) goes beyond the pleaded case because it regulates steps which I treated as measures Apple could legitimately take in the counterfactual. Apple also claims that the concepts “poses a genuine security risk” and “requires urgent elimination” are matters of controversy and judgment which cannot practicably form part of a workable regime of injunctive relief.

704    Proposed order 6(h) is directed at the same kind of power Apple has already been found to have unlawfully used as part of the contravening conduct: the ability to remove apps and cut off developers, exemplified by the removal of Fortnite and termination of Epic’s developer account, which I treated as a paradigm instance of Apple enforcing its restrictive terms to shield itself from competition.

705    In a world of decentralised app distribution where I have found Apple will likely implement notarisation and the ability to revoke signatures, it is appropriate under s 80 to constrain Apple from using that ability as a renewed mechanism of foreclosure in respect of apps obtained via alternative distribution channels.

706    The “genuine security risk” and “requires urgent elimination” language is not out of step with ordinary injunctive standards, which may use expressions such as “material risk” and “serious danger”.

707    Contrary to Apple’s contention, proposed order 6(h) strikes an appropriate balance between the need to restrain Apple from taking steps to stifle competition under the guise of security measures, and the need for Apple to disable or delete malware without notice to developers in certain circumstances. Now Epic says that this is achieved by the use of the disjunctive in proposed order 6(h)(ii), but I will make this clearer in the order that I will make. The order does not prohibit Apple from removing or disabling apps that pose a genuine security risk that requires urgent elimination without notice.

Proposed order 6(i)

708    As to proposed order 6(i), I found that frictions in the downloading and installation process for an app discourage users from obtaining the app (GJ[2459], [4766], [4821]). Installation friction comprises both the warning presented to users as well as the total number of steps required for installation (GJ[4819]).

709    Proposed order 6(i) restrains Apple from imposing frictions or impediments on the discovery, downloading, installation, execution or updating of iOS apps available or distributed via alternative distribution channels that are disproportionate to the security risk posed by those apps.

710    I was clear as to the meaning of disproportionate in this context, so an injunction hinging on the imposition of disproportionate frictions or impediments is appropriately precise. I said at GJ[5031] to [5033]:

In Professor Somayaji’s opinion, the key factor in determining whether installation friction is applied proportionately in relation to security risk is whether the installation process helps a user discern between safe apps and malicious ones.

If friction is applied proportionately, users are less likely to install risky apps and will be informed about risks associated with the app which may help them to exercise prudence when using the app after choosing to install it. By contrast, friction applied to apps that are known to be safe is disproportionate, does not serve a security purpose and can be detrimental to security, particularly where its overuse leads to users becoming desensitised to actual risks.

I have accepted Professor Somayaji’s views given his expertise and reliability.

711    Now Apple contends that proposed order 6(i) impermissibly limits Apple’s ability to impose frictions on the use of alternative distribution channels, contrary to the liability findings on EU frictions. It also contends that the drafting is imprecise and creates uncertainty as to whether default safety settings and tools implemented under the Online Safety Act could be characterised as impermissible frictions or impediments.

712    But proposed order 6(i) does not restrain Apple from imposing any frictions and impediments. It restrains only those frictions and impediments that are disproportionate to the security risk or that otherwise have the purpose, effect or likely effect of preventing, hindering or deterring the use of alternative distribution channels.

713    And I agree with Epic that the importance of ensuring that Apple does not impose disproportionate frictions is underscored by the further evidence of Mr Grant which addresses iOS user behaviour in the direct download flow for the EGS in Europe on iOS devices after Apple reduced installation frictions in that flow.

714    The evidence shows that iOS users who attempted to directly download the EGS app onto iOS devices dropped off at a significantly lower rate, in other words proceeded to complete their download of EGS at a significantly higher rate, after Apple reduced friction in its direct downloading install flow on iOS devices in the EU. I agree with Epic that the practical importance of orders which preclude or at least minimise unnecessary frictions in the app installation or payment processes is supported by the evidence of Mr Grant.

715    Mr Grant explained that from May 2024, in response to ongoing enforcement of the DMA, Apple began allowing users in the EU to directly download apps, including the EGS, onto iOS devices. Since then, Apple has updated iOS such that the installation flow has improved for users in the EU who attempt to install EGS from the Epic Games website. In short, for users with iOS version 18.5 or earlier installed on their device, the installation flow comprised several more steps than it did for users with iOS version 18.6 or later.

716    Data pertaining to mobile installation of EGS before and after 29 July 2025 when iOS 18.6 was released shows a marked reduction in the drop off rate after the number of steps in the installation flow was reduced. Specifically, from 1 June to 15 July 2025, when the old installation flow applied, the drop-off rate between the commencement and conclusion of the installation process was 63%. Contrastingly, from 30 July 2025 to 15 September 2025, when the new installation flow applied, the overall drop off rate across all recorded EGS installations from iOS devices was 47%. When considering EGS installation attempts exclusively from devices running iOS 18.6, the average drop off rate in the same period was only 24%.

717    This data illustrates two things. First, it shows that minimising unnecessary frictions in the installation flow is important for any developer who seeks to distribute their iOS app outside the App Store. Second, it shows the anti-competitive effect that such restrictions can have if they are allowed to persist. Moreover, it is convenient to note here that the same applies to alternative payment methods. As Epic points out, if users face more steps and frictions to complete transactions for the same good using a third-party payment solution when compared to using IAP, then developers using those alternative solutions are disproportionately affected by the implementation of disclosure sheets. This could lead to lower user spending and increased issues like cart abandonment.

718    Now Mr Friedland says that disclosure sheets or information sheets can be beneficial from a security perspective when they provide relevant information that is proportional to the risk posed by an app during installation. But even if they are proportional to risk, as Professor Somayaji said such disclosure sheets are only appropriate if present for all apps at a similar level of risk, irrespective of the source of installation.

719    Professor Somayaji said that implementing disclosure sheets for all app distribution channels except for App Store apps on iOS devices, by default, is a policy decision that is not based on any security or technical constraints and goes beyond Apple’s responsibilities as a platform owner. This differentiated implementation of disclosure sheets in iOS default settings privileges an app distribution method that is not inherently more secure or trusted than other third-party app stores. In other jurisdictions where Apple has enabled alternative app distribution, apps that are available for distribution through direct downloads or via alternative app stores are already subject to Apple-controlled notarization and review processes, which include automated scanning for functionality, safety, security, and privacy prior to certification. Moreover, because iOS apps are sandboxed, as implemented in other jurisdictions, apps available through alternative distribution will be sandboxed, which further strengthens security and reduces the likelihood that any app will compromise other apps. Under these conditions, apps installed on iOS devices from alternative sources would offer a similar level of protection to iOS devices as the App Store.

720    App installation could require just a single informative screen, and alternative app stores require no additional restrictions for security so long as they must abide by iOS notarization requirements. But such disclosure sheets are only effective when the overall installation friction is proportional to security risks. Otherwise legitimate, well-vetted apps offered via direct downloads and alternative app stores can end up stigmatized relative to potentially less safe App Store downloads.

721    The refreshed version of disclosure sheets implemented by Apple in the EU do not provide information to the user that is proportional to the security risks of app installation from alternative sources compared to the security risks of app installation from the App Store.

722    Now Apple opposes proposed order 6(i) on the basis that I declined to find that Apple imposed disproportionate impediments on alternative app distribution in the EU. But as I have previously made clear, my liability reasons were based only on an historic position in the EU. It was always my expectation that I would be taken to further evidence at the relief hearing to be brought up to date on developments in the EU, and I am not precluded from now considering whether what Apple might propose in terms of screen warnings or frictions is disproportionate.

723    Further, given Apple’s breach of s 46 and its conduct, as Epic correctly described it, in seeking to obstruct the emergence of competition where it has been left free to do so in other jurisdictions, it is in the public interest that I should prohibit Apple from imposing disproportionate frictions on, or impediments to, the discovery, downloading, installation, execution or updating of iOS apps available or distributed via alternative distribution channels.

724    I will further discuss the topic of disclosure sheets later in the context of discussing proposed orders 7 to 11.

Proposed order 6(j)

725    As to proposed order 6(j), the effect of Apple’s conduct to date has been that any app developer who wishes to make their iOS app available for distribution on iOS must use IAP for all in-app purchases of digital content. Order 6(j) seeks to ensure that Apple does not require developers who make their iOS apps available for distribution via an alternative distribution channel to offer or to use any particular payment solution, or require that they must offer IAP as an alternative to the developer’s preferred payment solution, being conduct which would deter developers from distributing their apps via alternative distribution channels.

726    Apple contends that proposed order 6(j) is unsupported by the liability findings and unduly limits its ability to regulate its alleged ecosystem. It says the order would prevent Apple from requiring developers using alternative distribution channels to use payment methods that meet certain technical and financial security standards.

727    But a narrow restraint preventing Apple from tying access to alternative distribution channels to IAP, or to any particular payment method, is a necessary and warranted measure aimed at ensuring that Apple cannot deter developers from using those channels.

728    Proposed order 6(j) would not prevent Apple in a genuine case from requiring that developers cease using payment methods that do not comply with generally accepted technical and financial security standards. But as Epic points out, Apple has never considered it necessary to examine or review the technical and financial security standards of payment systems that developers use to facilitate the purchase of physical goods or services. As Epic not unfairly described it, Apple’s new found desire to require that developers use only payment solutions that adhere to technical and financial security standards, and then only for payment solutions facilitating digital purchases, suggests that its real objective is to generate obstacles to the use of payment methods other than IAP when deployed for digital purchases.

729    Further, there is no good reason at all why Apple should be permitted to force on developers the requirement that IAP be offered as an option; I would make a similar point concerning proposed order 10(c).

Proposed order 6(k)

730    As to proposed order 6(k), I found that Apple was compelled to make various changes in connection with iOS app distribution by force of the DMA, and that under that regime, developers were only able to obtain the benefit of those changes by agreeing to the alternative terms addendum for apps in the EU. Moreover, I found that restrictions imposed on developers under the alternative terms addendum were designed by Apple to dissuade developers from taking up alternative payment solutions. Further, I found that the decentralised distribution of iOS apps cannot occur without access to Apple’s intellectual property. Proposed order 6(k) responds to those findings, by restraining Apple from requiring developers who make their apps available for distribution via an alternative distribution channel to enter into any contractual arrangement with Apple, or any other person, as a condition of the developer distributing their iOS apps via the alternative distribution channel, other than in respect of the licensing of Apple’s tools and APIs for the development of iOS apps.

731    Apple contends that proposed order 6(k) improperly repurposes reasons on power and market structure into restraints aimed at asserted or apprehended anti-competitive effects, and would fetter Apple’s commercial freedom to an extent not justified by the liability findings.

732    Against the backdrop of my findings regarding Apple’s DMA response, there is a real and stark risk that Apple would, in a world of decentralised app distribution, seek to replicate its DMA model by forcing developers to accept a bundled contractual arrangement as the price of using alternative distribution channels.

733    Apple identifies no legitimate reason why developers who use alternative distribution channels should be compelled to contract with Apple or its nominee beyond what is necessary to license Apple’s IP for the development of iOS apps.

Competition in iOS in-app payment solutions

734    Epic has sought the following orders on this topic:

7.    The First Respondent must not (including by procuring any act of any related corporation):

(a)    require that app developers who distribute iOS apps via the App Store must use IAP for in-app purchases of digital content in those apps;

(b)    prohibit app developers who distribute iOS apps via the App Store from directing users to a payment method other than IAP for purchases of digital content;

(c)    prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder iOS app developers from:

(i)    using payment methods other than IAP for accepting and processing payments for in-app purchases of digital content within iOS apps distributed via the App Store or via an Alternative Distribution Channel;

(ii)    providing buttons, external links, or otherwise informing, leading or directing iOS device users from within an iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP; or

(iii)    using their own choice of payment method(s) for accepting and processing payments for in-app purchases of digital content, provided that, where the conditions referred to in paragraph 8 below have been satisfied, the First Respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP;

(d)    prohibit, prevent or take any action (including by imposing a fee or condition) which is likely to hinder iOS users from using payment methods other than IAP for purchasing digital content for use in-app, provided that, where the conditions referred to in paragraph 8 below have been satisfied, the First Respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP.

8.    The First Respondent may only impose necessary and proportionate security requirements, as referred to in paragraph 7(c)(iii) or (d), or in paragraph 9(a) if they have first given the affected iOS app developers reasonable prior notice in writing that identifies and explains the nature and causes of that additional security risk, and why the proposed requirements are necessary and appropriate to address that risk. For the purposes of this paragraph, reasonable prior notice in writing can be given by direct communication with developers and where that is not reasonably practicable, by a notice published on a website maintained by the First Respondent.

9.    The First Respondent must take all steps necessary to permit the Applicants and any other app developer (including by procuring any act of any related corporation):

(a)    to use a payment method other than IAP for accepting and processing payments for in-app purchases in apps distributed to iOS device users via the App Store or via an Alternative Distribution Channel, provided that, where the conditions referred to in paragraph 8 above have been satisfied, the First Respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP; and

(b)    to provide buttons, external links, or otherwise inform, lead or direct iOS device users from within an iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP.

10.    The First Respondent must not (including by procuring any act of any related corporation) require that the Applicants or any other iOS app developer who uses a payment method other than IAP for accepting and processing payments for purchases of digital content for use in-app:

(a)    refrain from offering lower prices, or more favourable discounts or other benefits, to users who purchase via a payment method other than IAP than those applicable to in-app purchases effected via IAP;

(b)    report the transactions accepted and processed using a payment method other than IAP or grant any audit right in respect of those transactions;

(c)    offer IAP in addition to the developer’s preferred payment method or prevent app developers from using payment providers that act as a merchant of record;

(d)    in connection with any iOS app distributed via an Alternative Distribution Channel, pay any fee in connection with:

(i)    in-app purchases made via a payment method other than IAP, or

(ii)    purchases of digital content from any website or from any developer’s platform for use in-app;

(e)    in connection with any iOS app distributed via the App Store, where:

(i)    in-app purchases are made using a payment method other than IAP, or

(ii)    purchases of digital content are made on any website or from any developer’s platform for use in-app,

pay a fee that exceeds any fee that is imposed on app developers who distribute iOS apps via the App Store in connection with in-app purchases of physical goods or services using a payment method other than IAP, plus any additional economic costs that are genuinely and reasonably incurred by Apple in connection with an iOS device user making an in-app purchase of digital content using a payment method other than IAP that are not incurred when a user makes an in-app purchase of physical goods or services using the same payment method.

11.    The First Respondent must not (including by procuring any act of any related corporation):

(a)    impose or require the introduction of any friction or impediment into the process whereby iOS device users can elect to use, or can in fact use, a payment method other than IAP when purchasing digital content for use in-app which is additional to those frictions or impediments that a user encounters when making in-app purchases of physical goods and services using a payment method other than IAP in an app distributed via the App Store; nor

(b)    impose any fees or conditions for access to, or use of, any tool or API (including software development kits) that is necessary for app developers to develop and distribute iOS apps that allow or enable developers and iOS device users to use a payment method other than IAP, which do not apply in respect of apps distributed via the App Store within which iOS device users can make in-app purchases of physical goods or services using a payment method other than IAP.

Compliance and discrimination

735    Epic has sought the following order on this topic:

12.    The First Respondent must not (including by procuring any act of any related corporation) reject for distribution, discriminate against, take retaliatory action against, or otherwise disadvantage:

(a)    any of the Applicants’ or any other app developer’s apps submitted for distribution via the App Store; nor

(b)    the Applicants or any other app developer,

on the basis that:

(c)    the developer’s app is available for discovery, downloading, installing or updating via Alternative Distribution Channels;

(d)    the app uses or will use a payment method for accepting and processing payments for in-app purchases other than IAP; or

(e)    the developer of the app links or otherwise informs, leads or directs iOS device users from within the iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP.

Apple – order

736    Apple has sought the following orders:

3.    Pursuant to s 80(1) of the CCA, the First Respondent must not (including by procuring any act of any related corporation):

(a)    prohibit App Developers who distribute native iOS apps to users of iOS devices associated with an Australian Apple Account from both:

(i)    using any payment methods other than IAP for accepting and processing payments for in-app purchases by such users of digital content in those apps; and

(ii)    directing such users from within those apps to out-of-app payment methods for purchases of digital content for use in-app; or

(b)    unreasonably prevent or hinder App Developers from engaging in the conduct described in both subparas (a)(i) and (a)(ii), and without affecting the generality of the foregoing this will permit the First Respondent (and any related corporation) to impose reasonable technical and security requirements on the use of payment methods other than IAP.

4.    Orders 2 and 3 are to have effect for a period of 5 years with effect from the date that is 6 months from the date of these orders.

…

Definitions

In these orders:

“App Developers” means developers of native iOS apps who are and remain admitted to the Apple Developer Program.

“Australian App Store” means the App Store Australian storefront.

“Australian Apple Account”, formerly "Apple ID", means an Apple Account with the country or region set to “Australia” and associated with a payment method with an Australian billing address.

“Reader app” means magazine, newspaper, book, audio, music and video apps which may allow a user to access previously purchased content or content subscriptions.

737    Let me now turn to a detailed discussion of Epic’s proposed orders 7 to 11 dealing with competition in the payments market. Again, the proposed orders that I am discussing and those that I will make are to be read with the geographical limitation on “users” and the “App Store” that I have indicated.

Proposed order 7 (order 6 as modified and made)

738    Epic’s proposed order 7 seeks to enjoin Apple from preventing or prohibiting the use of alternative payment solutions to IAP for in-app purchases of digital content. And it prevents Apple from requiring app developers who distribute iOS apps via the App Store to use IAP for in–app purchases of digital content in those apps. I would note that proposed order 7 corresponds, with modification, to order 6 that I have made.

739    Now Apple says that the prohibitive injunction in its proposed order 3 is sufficient, but it says that Epic’s proposed order 7 goes further than this.

740    Proposed order 7(b) enjoins Apple from prohibiting developers from directing users of apps distributed through the App Store to a payment method other than IAP for purchases of digital content.

741    Proposed order 7(c)(i) enjoins Apple from prohibiting, preventing or taking any action which is likely to hinder iOS app developers from using payment methods other than IAP for accepting and processing payments for in-app purchases within apps distributed via the App Store.

742    Proposed order 7(c)(ii) enjoins Apple from prohibiting, preventing or taking any action which is likely to hinder iOS app developers from providing buttons, external links, or otherwise informing, leading or directing iOS device users from within an iOS app to a payment method for accepting and processing payments for purchases of digital content other than IAP.

743    Proposed order 7(c)(iii) enjoins Apple from prohibiting, preventing or taking any action which is likely to hinder iOS app developers from using their own choice of payment method(s) for accepting and processing payments for in-app purchases of digital content, provided that where the conditions referred to in proposed order 8 have been satisfied, Apple may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP.

744    Proposed order 7(d) enjoins Apple from prohibiting, preventing or taking any action which is likely to hinder iOS users from using payment methods other than IAP for purchasing digital content for use in-app, provided that, where the conditions referred to in proposed order 8 have been satisfied, Apple may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP.

745    Apple says that save insofar as it purports to restrain Apple from prohibiting or preventing the use of alternative payment solutions to IAP, proposed order 7 is not supported by my liability findings.

746    First, Apple says that proposed orders 7(b) and (c)(ii) are directed at the maintenance of the anti-steering rule. But Apple says that it has not been demonstrated or found that that rule would, in the absence of the IAP exclusivity requirement, have the effect or likely effect of substantially lessening competition in any relevant market. So, once maintenance of the IAP exclusivity requirement is removed, there is no need for any injunction against the anti-steering rule.

747    In that regard, the relevant liability findings were to the effect that Apple’s iOS payment solution conduct, comprising the IAP exclusivity requirement and the anti-steering rule, had the effect or likely effect of substantially lessening competition. Whilst the findings deal with the IAP exclusivity requirement and the anti-steering rule concurrently in places ([432], [433], [5652] and [5653]), the relevant finding is in terms that the IAP exclusivity requirement and the anti-steering rule together contravene s 46.

748    I said at [5654], [6111] and [6113]:

In my view by this conduct, Apple prevents developers from acquiring services for facilitating payment for digital content in iOS apps other than from IAP, with the effect or likely effect of substantially lessening competition. In doing so, Apple forecloses alternative payment solutions from participating in the relevant market.

…

For these reasons, the iOS payment solutions conduct has the effect or likely effect of substantially lessening competition in the iOS in-app payment solutions market and also I might add the iOS app distribution market.

…

Further, in terms of the IAP restrictions being the payments tie provision and the anti-steering provision, I have found that they were imposed or have been maintained at the start of the relevant period with the effect or likely effect of substantially lessening competition in the payment solutions market. But I have rejected Epic’s purpose case in this context.

749    Apple says that Epic did not seek any finding, and no finding has been made, that Apple’s anti-steering rule of itself and in isolation from the IAP exclusivity requirement had an effect of substantially lessening competition. No analysis of the discrete effect of the anti-steering rule forms part of the competition analysis. There is no discrete finding to the effect that the anti-steering rule of itself contravened s 46.

750    The only discussion of the anti-steering rule per se in the competition analysis of the iOS payment solution conduct concerns the effect of removal of the anti-steering rule on competition in the iOS app distribution market. In this regard I said (at [6110]):

Generally, if Apple ceased engaging in the impugned conduct, it is likely that alternative app stores on iOS would seek to differentiate themselves by offering developers alternative in-app payment solutions. Moreover, the anti-steering provisions hinder the ability of alternative app stores to compete.

751    But Apple says that that discussion is supplementary to a finding about the effect on competition of removal of the iOS payment solution conduct as a whole, and is not in terms that the anti-steering rule has an effect or likely effect of substantially lessening competition.

752    Apple says that the effect of Apple’s proposed relief will be to remove the IAP exclusivity requirement. In circumstances where, as a result, alternatives to IAP will be able to be used in-app, it is difficult to see that maintenance of the anti-steering rule, that is, a prohibition on steering users to alternative payment solutions outside an app, would be likely to have any anti-competitive effect. And developers who do wish to steer users to alternative payment solutions may already do so by email and other means of communication outside an app.

753    Second, Apple says that proposed order 7(d) is not only unnecessary, but also uncertain in its scope and so inappropriate to be made.

754    Apple says that it is unclear what conduct would constitute preventing, hindering or deterring iOS users or app developers from behaving in the ways described. It says that conduct the subject of order 7(d) might, for example, include informing users that certain benefits, like the ability to manage their subscriptions in one place, use parental controls, or access Apple customer support, will not be available if they use an alternative to IAP. But Apple says that there could be no reasonable objection to Apple informing users of such matters.

755    More generally, Apple says that Epic also did not allege or submit that any of the steps Apple has taken in response to specific regulatory regimes implemented in other jurisdictions and markets would, if adopted here, contravene s 46. Yet Apple says that Epic now seeks to repurpose and rely upon reasons concerning other topics to justify restraints targeting apprehended anti-competitive effects which were not the subject of any sustained analysis or argument in the liability hearing.

756    Further, Apple says that my finding on liability was that Apple contravened s 46 by requiring developers to use IAP exclusively, that is, Apple contravened s 46 by requiring that developers use IAP for in-app payments for digital services to the exclusion of any other payment solution. But Apple says that Epic did not bring any case alleging that Apple contravened or would contravene s 46 by requiring developers to include IAP among the payment solutions available to users in purchasing digital content in app.

757    Further, Apple says that if Epic’s proposed order 7(a) were made, Apple would be prohibited from requiring developers distributing via the App Store to offer IAP as a means to purchase digital content in app. Apple says that such a prohibition would enjoin a form of legitimate commercial activity, being Apple’s insistence at its option that its own payment solution be among the solutions developers make available non-exclusively to users for digital purchases, in apps built using Apple software and distributed through the App Store. Apple says that this was never alleged or found to contravene s 46.

758    Likewise, Apple says that order 7(b) would enjoin Apple from prohibiting developers distributing apps via the App Store from directing users to a payment method other than IAP. Apple says that this is problematically in absolute terms, and unqualified by any condition to the effect that the prohibition only applies to the extent that Apple also requires the exclusive use of IAP.

759    Apple says that the conduct found to contravene s 46 was Apple’s prohibition on developers steering users from within iOS apps to alternative payment solutions for in-app purchases of digital content (the anti–steering rule) in the context of Apple’s enforcement of the requirement that developers which supply iOS apps use IAP for all in-app purchases of digital content (the IAP tie). To be clear, the concept of steering means directing users from within an iOS app, including by means of linking out, to out of app payment methods for accepting and processing purchases of digital content for use in–app.

760    I said at [5651] to [5653]:

Let me now say something about the relevant conduct at issue being the iOS payment solution conduct. And in this respect there are two aspects.

First, one has the existence and Apple’s enforcement of the requirement that developers which supply iOS apps use IAP for all in-app purchases of digital content, which the parties have referred to as the IAP tie.

Second, one has Apple’s prohibition on developers steering users from within iOS apps to alternative payment solutions for in-app purchases of digital content, which the parties have referred to as the anti-steering rule.

761    Apple says that Epic did not bring any case seeking to restrict Apple’s ability to prevent developers from directing users to non-IAP payment methods. Its case concerned Apple’s prevention of steering to external payment solutions, as applied in the context of Apple’s requirement of the exclusive use of IAP for in-app payments for digital services.

762    As I have indicated, Apple says that it should be enjoined from applying the combination of a requirement that developers use IAP for in-app payments exclusively, and a prohibition on steering users to out-of-app payment systems. It says that that specific combination of conduct is what I found contravened s 46.

763    And as I have indicated, Apple says that I made no finding that Apple’s requiring the use of IAP non-exclusively for the purchase of digital content on apps distributed through the App Store would contravene s 46. Apple also says that I made no finding that Apple’s preventing developers from directing users of apps distributed through the App Store out of app to accept and process payment for digital services would lessen competition, in the absence of any requirement that IAP be used for in-app payment to the exclusion of all other payment solutions.

764    Apple says that both of these steps which it takes or may take in respect of apps operating on its hardware using its proprietary software distributed through its own store front would be enjoined by Epic’s orders. Apple says that nothing in my findings justifies the grant of that relief.

765    Epic’s proposed orders then seek to apply the equivalent restrictions to all developers irrespective of distribution channel and in terms so broad that they would practically prevent Apple from taking any step to regularise the acceptance and processing of payments for digital content.

766    Epic’s proposed order 7(c) would enjoin Apple from prohibiting, preventing, or taking any action which is likely to hinder iOS developers from: (i) using payment methods other than IAP for taking payments for digital content within apps; (ii) steering users out of app to take such payments; or (iii) using their own choice of payment method, subject to the imposition of what Epic calls necessary and proportionate security requirements.

767    Proposed orders 7(c)(ii) and (iii) would enjoin Apple from engaging in conduct which Epic has not alleged and I have not found to contravene s 46. The iOS payment solutions conduct consisted of a requirement to use IAP exclusively coupled with a prohibition on developers steering users to alternative payment solutions.

768    Apple says that Epic did not bring any case alleging that it would be anti-competitive for Apple to prevent developers from directing users out of app to external payment service providers or platforms. Apple says that Epic’s proposed order would restrain conduct not shown to be anti-competitive, such that to restrict it would not be an appropriate exercise of the power in s 80.

769    Apple also says that the language of this proposed order is broad and indeterminate.

770    Apple says that if any step taken were to prevent even one developer from doing any of the things identified in proposed order 7(c)(i) to (iii), Apple would be in contempt of an order so framed. It poses the question: how many iOS developers must an action taken by Apple be “likely to hinder” before the order is infringed? It says that a step which would be likely to hinder any app developer, or perhaps any two app developers, would transgress this order. And it says that the question on any contempt application would be not whether any two developers were in fact hindered, but whether those developers were likely to be hindered, a threshold which would be lower and which would be even more uncertain, so rendering Apple’s bridge over the chasm on contempt more precarious still.

771    Apple says that the consequence of this uncertainty would be practically to disable it from taking any step to regularise the acceptance or processing of payments for in-app content.

772    Now to support payment solutions other than IAP in foreign jurisdictions where Apple is required to permit such payment, Apple has created a set of APIs which can display disclosure sheets to the user for transactions made other than via IAP through apps distributed via the App Store; as I have touched on earlier and as I will return to later, these are described as External Purchase APIs.

773    Apple says that the use of disclosure sheets, being a means of educating users of a change in the standard process, that is, IAP, so that the user is provided with the opportunity to assess their risk appetite in proceeding with providing their payment details to sources outside of Apple, may prevent or be likely to hinder some developers somewhere from using alternative payment methods.

774    Apple says that it would risk contempt of my orders by using any equivalent mechanism in facilitating alternative payments in respect of users affected by my orders.

775    Now Apple accepts that Epic has sought to mitigate some part of this uncertainty by introducing a proviso in its proposed order 7(c) to the effect that “where the conditions referred to in paragraph 8 below have been satisfied, the First Respondent may impose requirements that are necessary and proportionate to address any additional security risk posed by a payment method other than IAP”.

776    Epic’s proposed order 8 provides that Apple may impose necessary and proportionate security requirements if they have first given the affected iOS app developers reasonable prior notice in writing to the developer directly, or by public notice that identifies and explains the nature and causes of that additional security risk, and why the proposed requirements are necessary and appropriate to address that risk.

777    But Apple says that this proviso does not address or overcome the inability to take pro-competitive steps to regulate processing of payments for digital content which Epic’s proposed order 7(c) otherwise creates. Apple complains that Epic’s notice requirement is unworkable and counterproductive and has made the following points.

778    First, it says that some security requirements are urgent. It says that Epic’s requirement of notice before action is taken against security threats would reduce the efficacy of any eventual response by Apple to that threat.

779    Second, it says that for some security threats, publicity is antithetical to mitigation. Apple says that if it were required to disclose to affected developers or to make public generally the nature and causes of any additional security risk to iOS users, that disclosure is likely to reduce the efficacy of Apple’s response to that risk and to other security risks.

780    Apple says that Epic’s proposed order 7(d) has the same problems.

781    Epic’s proposed order 7(d) would enjoin Apple from prohibiting or preventing or taking any action (including by imposing a fee or condition) which is likely to hinder iOS users from using payment methods other than IAP for digital purchases. Apple says that this order has the same vice as order 7(c), in that any step which poses a likely hindrance to any two users, at any time and anywhere, would contravene the order, putting Apple in contempt. Apple says that because the class of users is so much wider than the class of developers, even taking iOS users with an Australian Apple Account only, the jeopardy in which this would place Apple in hazarding any step to regulate the acceptance and processing of payment for app users’ purchases of digital content is all the more problematic.

782    Further, Apple says that the proposed orders, by creating uncertainty, would operate to disable Apple from earning any competitive return on its investments in iOS by any version of the monetisation strategy it has previously implemented. Apple says that the External Purchase APIs facilitate the reporting of transactions for the purposes of Apple collecting its commission on transactions made through apps distributed via the App Store and alternative distribution channels. It says that charging any commission on payments accepted or processed by alternative means is a step which could prevent or be likely to hinder some developers somewhere from taking such payments.

783    So, Apple would risk contempt in charging any commission in respect of any payment taken by alternative means from an iOS user affected by my orders.

784    Now Apple says that its proposed relief avoids the problems which Epic’s revised orders pose.

785    Apple’s proposed order 3(b) would enjoin Apple from unreasonably preventing or hindering app developers from both using any payment methods other than IAP for accepting and processing payments for in-app purchases of digital content and directing such users from within those apps to out-of-app payment methods for purchases of digital content for use in-app.

786    It says that an order in that form would attain the anti–avoidance remedial objective which Epic advances in support of its proposed relief, namely, forestalling any attempt Apple may make to impose some equivalent of the contravening conduct by other means. But unlike Epic’s order, Apple says that it would attain this objective without restraining conduct which has not been shown to be anti–competitive, in the manner that Epic’s proposed order 7(c) will.

Analysis

787    Proposed order 7 is a negative injunction, prohibiting Apple from imposing and enforcing the IAP tie and the anti-steering provision, which conduct I found to contravene s 46(1).

788    Proposed orders 7(a) to (b) will prevent the continuation and repetition of Apple’s contravention of s 46(1) in requiring app developers that wish to distribute iOS apps via the App Store to use IAP for in-app purchases of digital content in those apps, and in prohibiting such developers from leading users to a payment method other than IAP for purchases of digital content.

789    Proposed orders 7(c) and (d) will prevent Apple from continuing to substantially lessen competition by conduct which has substantially the same or similar effect as the IAP tie and the anti-steering provision.

790    These orders are necessary given my findings that, even when compelled by law in other jurisdictions to permit developers that wish to distribute iOS apps via the App Store to use payment methods other than IAP, Apple has restructured its commission to make it economically unviable for most developers to use an alternative payment method.

791    As I put it, the “choice” Apple has presented to developers in these jurisdictions is illusory. Proposed orders 7(c) and (d) are directed to prohibiting such conduct, which I found was engaged in to block any genuine prospect of competition from suppliers of alternative payment solutions. I said at [5881]:

Now in my view the low take-up rate of alternative payment solutions demonstrates that the “choice” Apple has presented to developers in these jurisdictions is illusory. Apple has set the commission rates to block any genuine prospect of competition from suppliers of alternative payment solutions.

792    I found that Apple contravened s 46 by imposing its payments tie and the anti-steering rule. In other words, I was of the view that both the payments tie and the anti-steering rule amounted to material contravening conduct. Indeed, Apple rejected thousands of apps for distribution on iOS for violating its payments tie or for violating the anti-steering rule. It is therefore appropriate that Apple be enjoined from maintaining each of the payments tie and the anti-steering rule.

793    Now it is unsurprising that Epic did not bring a case alleging that Apple contravened s 46 by requiring developers to include IAP among the payment solutions available to users in purchasing digital content in app in circumstances where, at the time Epic brought its claim, Apple had never allowed the use of any payment solution other than IAP for in-app purchases in iOS apps. Such a case would have been hypothetical.

794    The same is true of the complaint that Epic’s case only attacked Apple’s prevention of steering to external payment solutions, as applied in the context of Apple’s requirement of the exclusive use of IAP for in­app payments for digital services. Once again, the fact that Epic’s case was tailored to Apple’s conduct in the factual, rather than hypotheticals, was appropriate.

795    Apple’s contention that this ought result in me confining the relief to be ordered to a prohibition on the precise conduct found to be anti­competitive ignores the fact that my remedial power is not confined to prohibiting the precise conduct pleaded and found to constitute the contravention.

796    In any event, the need for proposed orders 7 and 8 is made plain by the evidence led and my findings in the Epic v Google proceeding.

797    Under the UCB program, Google required developers to make Google Play Billing available alongside any alternative payment solution the developer chose to offer. That is, the UCB program involved the very conduct in which Apple seeks to engage, whereby developers are required to include IAP among the payment solutions made available to users.

798    Ms Edwards-Warren’s evidence was that a requirement that developers offer Google Play Billing alongside an alternative payment solution did not reflect a competitive market.

799    I found that app developers entitled to access the UCB program remained subject to the payments tie, albeit in a varied form as they were not permitted to only offer an alternative payment solution: GJ[637]. The choice offered to developers to use an alternative payment solution under the UCB program was found to be not commercially real as app developers remained constrained by the payments tie, even when they had access to UCB: GJ[642]. This was so even putting pricing to one side: GJ[5509]. I also found (GJ[5866]) that the scope for competition within the confines of the UCB and developer own billing (DOB) programs was very limited, and neither program provided developers with a real choice of alternative payment solutions.

800    This evidence and these findings make plain that any continued insistence that developers offer IAP as a means to purchase digital content in app, even if alternative payment solutions are offered alongside IAP, constitutes an impermissible tie that is likely to stifle competition in the payment solutions market.

801    My findings in the Epic v Google proceeding similarly demonstrate why it is appropriate that Apple be prohibited from preventing developers from directing users out of app to accept and process payment for digital services, even if Apple does not mandate the use of IAP for in–app payments.

802    Google’s anti-steering rule prohibited apps required to use Google Play Billing from leading users to a payment method other than the Play Store’s billing system: GJ[5484]. This rule was found to have an anti-competitive effect: GJ[6051], [6053]. Importantly, these conclusions were not confined to those jurisdictions where UCB and DOB were not available.

803    Accordingly, the anti-steering rule was found to be anti-competitive even where developers were able to offer an alternative payment solution to Google Play Billing for in-app purchases.

804    The prohibition on preventing steering in proposed order 7(b) is appropriate in those circumstances.

805    Further, as Epic points out, Apple has not led any specific evidence that shows any need to collect commission on transactions made through alternative payment solutions so as to earn a commercial return on its investments.

806    There is no evidence that such transactions involve any use of Apple’s copyrighted SDKs or tools, or that they involve any additional service being supplied by Apple: [5313] to [5338]. And despite being on notice, Apple has again chosen not to adduce any such evidence.

807    In circumstances where I found that, even when Apple has been compelled in other jurisdictions to permit developers of iOS apps to offer payment methods other than IAP, Apple has restructured its commission to make it economically unviable for most developers to use an alternative payment method so as to block any genuine prospect of competition from suppliers of alternative payment solutions, a prohibition on the imposition of fees that are likely to hinder iOS app developers from using payment methods other than IAP is appropriate.

808    I said at [5859], [5860], [5871], [5872] and [5880] to [5882]:

But I agree with Epic that the low take-up of that opportunity can be explained by the fact that, if developers do pursue it, Apple still charges a commission of 27% in the Netherlands or 26% in South Korea.

As Epic points out, using an alternative payment solution in those circumstances would make no sense for the vast majority of developers. To be worthwhile, they would need to find an alternative payment solution that they consider to be equal to or better than IAP and that charges less than 3% in the Netherlands or 4% in South Korea, or which offers other benefits that can outweigh the cost increase that would need to be incurred to make use of the alternative.

…

In other words, Apple did not structure the commission to make it viable for developers to choose an alternative payments provider to IAP. Rather it set its commissions at a level that would make it economically unviable for most developers to use an alternative payment system in South Korea and the Netherlands. Mr Schiller conceded as much during cross-examination.

I agree with Epic that this supports the inference that the revised commissions charged by Apple in South Korea and the Netherlands understate the true costs to developers of adopting an alternative payments system for in-app purchases. Moreover, that inference is fortified by the fact that Apple’s costs of providing in-app payment services are unlikely to be vastly different to Google’s costs, which also exceed 3% or 4%.

…

Further, the regulatory requirements in South Korea and the Netherlands were directed at opening up the in-app payments market, yet Apple’s changes in purported compliance with these requirements were based on an estimate of costs that it knew was unrealistic and out of reach for developers. The reality is that developers would pay commissions that exceed 30% if they used an alternative payment system. The vast majority of developers are therefore unlikely to do so, as they would suffer a loss.

Now in my view the low take-up rate of alternative payment solutions demonstrates that the “choice” Apple has presented to developers in these jurisdictions is illusory. Apple has set the commission rates to block any genuine prospect of competition from suppliers of alternative payment solutions.

In all the circumstances, I would infer that the practical effect of Apple charging a service fee that is only 3 or 4% less than 30% is to offer developers the option of using an alternative payment system at an economically unviable cost.

809    Further, I agree with Epic that s 80 does not require a separate, standalone finding that the anti-steering rule, in isolation, contravened s 46 before that aspect of the contravening conduct can be restrained. Once a course of conduct has been found to have the effect or likely effect of substantially lessening competition, it is orthodox to enjoin each of its components. As Epic points out, there is no basis on which Apple should be permitted to select the aspects of the contravening conduct it should be enjoined from engaging in.

810    An injunction that removes the payments tie but leaves the anti-steering rule intact would leave in place a material and foreseeable obstacle to the take-up of rival payment solutions and the ability of alternative channels on iOS to compete with the App Store. This would fall well short of what is appropriate to prevent, restrain or remedy the contravening conduct and its effects for the purposes of s 80.

811    An anti-steering injunction is not only called for by my findings of liability. It is also necessary to create the conditions for competition from rival payment solution providers that Apple has comprehensively foreclosed for many years.

812    As to proposed order 7(d), Apple argues that the language of the order is unclear, and could capture benign conduct such as informing users that certain benefits, being centralised subscription management, parental controls or Apple support, will not be available if they use non-IAP payments, or setting minimum security/fraud standards for third party payment methods.

813    Proposed order 7(d) is necessary to prevent Apple from continuing to substantially lessen competition by conduct that has the same or similar effect as the IAP tie and the anti-steering provisions. Such an order is necessary because, as found by me, even when Apple has been compelled by law in other jurisdictions to permit developers that wish to distribute iOS apps via the App Store to use payment methods other than IAP, Apple has restructured its commission to make it economically unviable for most developers to use an alternative payment method.

814    As I said, this was conduct engaged in by Apple to block any genuine prospect of competition from suppliers of alternative payment solutions. The language in proposed order 7(d) is an appropriate method by which to prevent Apple from engaging in such conduct again.

815    Let me now say something more specifically about proposed order 8.

Proposed order 8 (order 7 as modified and made)

816    Proposed order 8 is directed at giving developers reasonable notice of any new security requirement which Apple proposes to introduce in connection with the use of alternative payment methods. But it only operates in the confined circumstances that are the subject of proposed orders 7(c)(iii), 7(d) and 9(a), which are concerned with additional security risks posed by a payment method other than IAP. I would note that proposed order 8 corresponds, with modification, to order 7 that I have made.

817    Proposed order 8 of Epic’s proposed relief outlines the requirement that Apple may only impose necessary and proportionate security requirements after it has provided a written notice to the affected developers that identifies and explains the nature of the risk. Specifically, proposed order 8 applies to the use of alternative payment solutions other than IAP. Under this provision, Apple may not take any action that prevents iOS app developers from offering third-party payment solutions for accepting and processing payments for in-app purchases of digital content for use in-app, unless there is a security risk associated with the use of third-party payment solutions and Apple has provided a written notice of the security risk to developers in advance.

818    Now Mr Friedland gave evidence that if a malware or security risk was identified, Apple would want to take action immediately to protect its users, rather than waiting for a notice period.

819    Further, Mr Friedland also raises concerns with respect to Apple’s prior notice as it could aid in the bad actor reverse engineering Apple’s malware detection capabilities.

820    Proposed order 8 requires Apple to give appropriate notice to developers regarding necessary and appropriate security requirements, but there is no requirement that Apple discloses the detailed nature of the underlying security issue in a way that would assist exploitation. Further, to the extent Apple is already aware of circumstances to which order 8 of Epic’s proposed relief would apply in which Apple would want to take action immediately to protect its users, Apple should notify developers in advance. Such notice would allow Apple to take reasonable actions such as removing discovered malware without any further notice to developers.

821    Further, proposed order 6(h)(ii) addresses the conditions under which Apple is allowed to remove or disable apps, including when the app “constitutes malware or malicious code which poses a genuine security risk that…requires urgent elimination” or when a security risk has not been remedied following “reasonable notice of the existence, nature and extent of that security risk.” Proposed order 8 does not prevent Apple from taking action immediately under proposed order 6(h)(ii), which latter proposed order I have tweaked to make this clear.

822    Further, proposed order 8 only applies to security requirements that are “necessary and proportionate to address any additional security risk posed by a payment method other than IAP” (proposed orders 7(c)(iii), 7(d), and 9(a)).

823    Now in order to determine the extent to which proposed order 8 impairs Apple’s ability to manage or prevent security risks to iOS devices and iOS device users, Professor Somayaji discussed the scenarios in which it is reasonable for Apple to take security-related actions without providing a written notice to developers.

824    The scenarios Professor Somayaji considered were the following: (a) a malicious app has been distributed to end-user devices; (b) a vulnerability in a distributed app can be used to exploit users but the app is otherwise legitimate; (c) a vulnerability in a distributed app can be used to exploit devices but the app is otherwise legitimate; and (d) a vulnerability in system software can be used to exploit users. Let me discuss his analysis of those scenarios.

825    In scenario (a), what is considered is the possibility that a malicious app was distributed and installed on a user’s device. And since the app is malicious, it provides no meaningful utility to the user and jeopardizes the user’s safety and their personal data. In such a case, the response is the same no matter how the app has been distributed. The app needs to be disabled or deleted from end-user devices. This response is drastic but is otherwise straightforward, as malicious apps do not have any legitimate purpose and so removing them is in the end user’s interests, and such removal can proceed without prior notification of the app author or the parties that help distribute the app. Further communication may be needed after the immediate situation is resolved, but such communication should not delay the situation from being addressed. Now this scenario is already covered under Apple’s policies. Apple’s systems on iOS devices regularly check installed third-party apps against a list of known malware identified by Apple. Where an app contains malware, the user’s device prevents the user from opening it and displays an alert recommending that the user delete it.

826    In scenario (b), one is considering the possibility that an otherwise legitimate app, that is, an app that provides certain functionality to the user and is safe to run on a user’s device, has a newly discovered security vulnerability. Whilst Apple can feasibly disable the app from running on the user’s device, this would neither solve the security risk nor allow the user to access the functionality offered by the app. As this scenario is the only one where there is an explicit vulnerability in the app itself, this scenario is the one that is most likely to apply to apps with payment related vulnerabilities. The other scenarios deal with outright malicious apps or security vulnerabilities in the operating system’s code rather than application code. In this case, because the app is legitimate, disabling or removing it from devices could have a negative effect on users. Further, because device–level security remains intact where only the user of the app is at risk, other apps are not affected, and the security risk can potentially be mitigated though changes in user behaviour, including by potentially receiving instructions from app developers on actions to take or avoid. In this scenario, then, no matter how the app is distributed, in almost all circumstances the security issue should be communicated to the app developer, and that developer would be expected to issue an update to resolve it.

827    In the case of alternative payment solutions, communications from Apple can help the developer identify problems with code related to the third-party payment solutions and rectify those issues. Additionally, such communication from Apple does not affect Apple’s ability to manage security risks to iOS devices as communications regarding vulnerabilities in specific payment solutions only affect users of specific apps, and those users are otherwise still secure.

828    In scenario (c), what is considered is a legitimate app that has been distributed and installed on a user’s device. The security vulnerability in this case can have widespread consequences by compromising the iOS device itself. So, a legitimate app could be used to compromise app sandboxing and so enable malicious access to all data on a device. The security vulnerabilities in this case pose significantly higher risk to users and the platform in general, as the vulnerable app can be used to compromise the security of the devices on which it is installed. Further, because the security mechanisms of the device are also at risk, the platform owner may need to take steps unilaterally to preserve the integrity of the platform. So, in these circumstances it is possible that a platform owner such as Apple could have reason to act unilaterally and without prior notification of the app developer, potentially disabling vulnerable apps until the app developer can release an updated version and Apple has had time to update iOS itself.

829    And under scenario (d), let it be assumed that the platform owner identifies a systemic security vulnerability in the underlying operating system. Sometimes fixing such systemic vulnerabilities impacts the functionality of some legitimate apps until the apps are updated. This scenario is potentially the most serious violation of security as it can affect all devices no matter which apps are installed on the user’s device. If system security updates can be distributed without impacting legitimate app functionality, no coordination with app developers is required. But in this case, the system-level security update impacts the functionality of legitimate apps, which requires them to be updated. Unless the affected apps have small user populations and/or use cases that can tolerate disruptions, any unilateral action by the platform owner could cause harm to end users. There is no good option in this scenario, as disclosing the vulnerability to developers could also disclose it to attackers, potentially facilitating wide-scale attacks before mitigations have been put in place.

830    So, in summary the proposed requirement for Apple to inform third-party app stores and other developers using alternative app distribution methods is not relevant to scenario (a), as the app is malicious. In scenario (b), which is the most likely scenario where security vulnerabilities with specific third-party payment solutions may be identified, Apple should provide developers a written notice because the impacts of the security issues are limited to users of specific apps, and the overall security of the platform is not affected. In scenario (c), because disclosure can be made just to affected app developers who have a vested interest in retaining app functionality, it is reasonable for Apple to provide a notice to developers in advance, before taking any unilateral action. In scenario (d), confidentiality related to operating system security could be much harder to maintain and potentially all devices could be at risk. So, Apple here might be justified in taking unilateral actions to protect platform security, but app developer cooperation is also essential.

831    But in any event, proposed order 8 does not relate to scenario (d) as proposed order 8 applies to security updates related to alternative payment solutions on iOS devices, and alternative payments are not directly facilitated by the operating system. So, when specific third-party payment solutions have security vulnerabilities, Apple should inform developers before imposing security requirements that could impact the functionality of legitimate apps that may use those payment solutions.

832    Further, neither security considerations nor Apple’s technical frameworks make disclosure sheets necessary when app developers use alternative payment methods. I will return to the topic of disclosure sheets later when I discuss proposed order 11.

Proposed order 9 (order 8 as modified and made)

833    Epic’s proposed order 9 is a mandatory injunction requiring Apple to permit the use of payment methods other than IAP and the steering of users to alternative payment mechanisms outside an iOS app. I would note that proposed order 9 corresponds, with modification, to order 8 that I have made.

834    Apple says that no such order was sought in the FAOA and it says that nothing in Epic’s pleaded case or my liability findings warrants the grant of such a mandatory injunction. Apple says that it is not open to Epic to seek or for me to make proposed order 9.

835    Apple says that so far as the case that was run and has been determined goes, proposed order 9 is superfluous, achieving no more of that which is open to Epic than is effected by Apple’s proposed order 3.

836    Apple says that to the extent that order 9 seeks to replicate in the form of a mandatory injunction the strictures which Epic’s proposed order 7 would impose in negative terms, it also has the deficiencies identified above, including by reason of its preclusion of the anti-steering rule.

Analysis

837    Proposed order 9 is a mandatory injunction, requiring Apple to permit Epic and other app developers to use payment methods other than IAP for accepting and processing in-app purchases in iOS apps including but not limited to apps distributed via the App Store, and further to permit app developers to steer iOS device users from within an iOS app to a payment method other than IAP for accepting and processing payments for purchases of digital content.

838    Proposed order 9 thereby requires Apple to permit conduct that, until now, has been prohibited by the IAP tie and the anti-steering provision, being provisions that Apple has hitherto enforced against Epic and other app developers in contravention of s 46.

839    Order 9 is warranted, since Apple’s proven conduct in other jurisdictions demonstrates that prohibitive injunctions alone may not be sufficient to ensure Apple ceases to stifle competition in the payments market.

840    Order 9 requires Apple to permit pro-competitive conduct and choice in the payments market, and will operate together with the negative injunction in order 7 to restore competition to that market.

841    Now although proposed order 9 was not sought in the FAOA, Epic is not precluded from seeking injunctive relief beyond that specifically claimed in its originating application for the reasons above, including because Epic’s originating application included injunctions expressed in general terms given it preceded my findings, I directed that questions of relief be dealt with after its determination of contraventions and Apple has had a full opportunity to answer the case on relief, including by evidence.

842    Apple contends that proposed order 9 is superfluous because prohibitory relief would prevent Apple from maintaining IAP exclusivity. But s 80 empowers me to grant both prohibitory and mandatory injunctions where appropriate to prevent, restrain or remedy the contravening conduct and its effects.

843    Apple also submits that proposed order 9 merely replicates, in mandatory form, what Epic seeks to achieve by proposed order 7 and inherits the same alleged defects, including as to anti–steering. But I have rejected those alleged defects.

Proposed order 10 (order 9 as modified and made)

844    The further prohibitive injunction which is Epic’s proposed order 10 is analogous to its proposed order 6, but in respect of payments rather than app distribution. I would note that proposed order 10 corresponds, with modification, to order 9 that I have made. Apple says that for similar reasons to those that it advanced concerning proposed order 6, order 10 is also unwarranted.

845    Apple says that proposed order 10 would dramatically limit its commercial options, truncating the choices as to monetisation strategy which remain open to it. Apple says that proposed orders 10(a) to (d) would render unavailable to it a series of means of monetising its ecosystem and promoting pro-competitive outcomes on the basis of findings in other proceedings and in respect of steps taken in other jurisdictions. And it says that none of this was specifically analysed or argued for in Epic’s case against it.

846    Apple also says that Epic seeks to justify these and further limitations on Apple’s commercial freedom and ability to commercialise its intellectual property not by allegations and findings of current or apprehended contraventions of the CCA made against Apple, but by findings made against Google in respect of conduct in which it was not alleged Apple had or would engage.

847    Apple says that Epic seeks to draw support by reference to observations that I made about Apple’s response to regulations imposed in the EU, the Netherlands and South Korea, in my reasons explaining that in-app payment solutions constitutes a separate product market. But Apple says that Epic is redeploying observations made elsewhere in my liability reasons to suit extraneous purposes here.

848    Further, Apple says that proposed order 10(d) would enjoin it from levying any fees in connection with in-app purchases made by a method other than IAP within any iOS app distributed by an alternative distribution channel. And it says that proposed order 10(e) would do likewise in connection with any purchase of digital content for use in-app, in connection with any iOS app distributed via the App Store.

849    Now Epic seeks to justify these proposed orders on the basis that Apple provides no distribution or payment services to developers in such scenarios, such that it can be inferred that the purpose and likely effect of the charge is to deter developers from using alternative payment methods and/or alternative distribution channels. But Apple says that the implicit premise is that Apple provides no service to developers in respect of such transactions, but it says that that premise is unavailable. It says that the transactions take place in an ecosystem that Apple has built and maintains. It says that the inference that any fee must have an illicit purpose therefore does not follow.

850    In any event, Apple says that none of Epic’s factual assertions and logical inferences in support of proposed order 10(d) or (e) have been made or drawn by me. Further, Apple says that such proposed orders rely upon false premises. One premise is that the only explanation for such price discrimination is that it is a means of imposing the anti-competitive payments tie on those developers who offer in-app purchases of digital content, by financially dissuading them from offering a payment solution other than IAP. And it says that the other premise is that any higher or other fees could not be explained or justified other than, once again, as a means of imposing the anti-competitive IAP tie on developers, and so ought to be prohibited by me. But Apple says that as the creator and custodian of the ecosystem patronised by the relevant developers and users alike, it should be permitted to charge fees for providing that service. And it says that both premises are false.

851    Now proposed order 10(e) allows Apple to supplement the amount of any fee or commission it may charge in respect of app users’ purchases of digital content, which the order otherwise caps at the amount Apple charges by way of commission on physical purchases being currently nil, so as to recoup any additional economic costs that are genuinely and reasonably incurred by Apple in connection with an iOS device user making an in-app purchase of digital content using a payment method other than IAP that are not incurred when a user makes an in-app purchase of physical goods or services using the same payment method.

852    But Apple says that even if there was a basis for some form of restraint upon Apple’s conduct contemplated by proposed order 10(e), an order in this form does not meet the requirements of clarity and certainty which it says should attend the exercise of the discretion in s 80. But even if these problems of uncertainty could be overcome, Apple says that proposed order 10(e) casts this Court in the role of market administrator, a role which is incompatible with a Chapter III judge and incompatible with the exercise of the power conferred on me by s 80.

853    Generally, Apple says that proposed order 10 would risk denying it the flexibility to regulate its own ecosystem in order to protect and promote the pro-competitive benefits that its ecosystem brings, preventing it from earning a fair return for its investments in and the services it provides through that ecosystem, and subjecting it to the risk of liability for contempt. And Apple says that none of those outcomes was weighed in my competition analysis constituent of my liability findings.

Analysis

854    As Epic points out, proposed orders 10(a) to (d) are based on my findings that Apple’s iOS payment solutions conduct had the effect and likely effect of substantially lessening competition in the payments market, and that when compelled to remove equivalent restrictions in other jurisdictions, Apple adopted monetisation strategies designed to make the choice of alternatives illusory and to block any genuine prospect of competition from suppliers of alternative payment solutions.

855    Moreover, there can be no serious objection to drawing on my findings in Epic v Google when fashioning relief. Evidence in one proceeding was evidence in the other. And as Epic correctly points out, proposed order 10 seeks to deal with techniques that I have already recognised in Epic v Google as devices used by a dominant platform to neutralise developer choice and suppress effective competition in in-app payment solutions once exclusivity requirements are removed. Contrary to what Apple says, those findings can be used to frame relief directed at Apple. And absent such an order, I can and do infer that Apple may take similar steps as at least a realistic possibility.

856    Proposed orders 10(b) and (c) enjoin a narrow set of conditions that Apple has enacted overseas. Contrary to Apple’s assertions, this was the subject of considerable analysis and Apple’s witnesses were cross-examined about the purpose, commercial reality and effect of the measures implemented overseas.

857    As to proposed order 10(a), in the context of its UCB program other than in South Korea, Google requires app developers to offer users the same price, irrespective of the payment solution they select. I found that this effectively prohibited price competition (GJ[638], [5374], [5379]). Conduct of that kind is restrained by order 10(a).

858    As to proposed order 10(b), in both the United States and EU, Apple has required developers who seek to use an alternative payment method for purchases of digital content for use in-app, whether by way of an in-app payment solution or by way of out-of-app payments, to report such transactions to Apple and to grant Apple extensive audit rights. Conduct of that kind is restrained by order 10(b)

859    As to proposed order 10(c), in the EU, Apple requires developers that wish to use an alternative payment method to contract directly with end users in relation to all transactions. I found in Epic v Google that equivalent conduct prevents the developer from using a payment solution provider that acts as a merchant of record. Let me elaborate on what I said in Epic v Google.

860    I found that under UCB Google does not permit app developers to offer an alternative payment solution without also offering Google Play Billing (GJ[637], [5374], [5379], [5499], [5509]). This is unattractive for developers, as they prefer all payments to be facilitated by a single payment solution so that the developers are only dealing with one provider and can consolidate transaction data from a single source (GJ[5499]). I further found that Google prevents app developers from using payment providers that act as a merchant of record in the context of UCB and DOB (GJ[640], [641], [5375], [5379]). Using such a provider is a way to take administrative and operational burdens away from the app developer, such that restrictions of that kind would preclude app developers from obtaining a desirable service, prevent alternative payment providers from competing with Apple on the merits, and prevent those payment providers who do act as a merchant of record from competing in the payments market (GJ[641], [673], [5376]). These forms of conduct are addressed by proposed order 10(c).

861    Further, as to proposed order 10(c) I repeat what I said concerning proposed order 6(j) concerning requiring the option of IAP.

862    As to proposed order 10(d)(i), it restrains Apple from requiring developers from paying any fee in connection with in-app purchases made via a payment method other than IAP within any app distributed via an alternative distribution channel.

863    Proposed order 10(d)(ii) restrains Apple from requiring developers to pay any fee in connection with purchases of digital content from any website, or from any developer’s platform, for use in-app, where the app was distributed via an alternative distribution channel.

864    Now as Epic correctly says, proposed order 10 is directed at predictable strategies that Apple has devised and employed overseas to dissuade or block alternative payment solutions where it has been compelled to open up the payments solutions market. And the justification for this order draws on my findings in relation to Apple’s introduction of transaction-linked fees, including the CTF, where developers make use of alternatives, and which I found to be designed to dissuade developers from taking up the option of using alternative payment solutions, and deterrence tactics employed to protect its preferred arrangements.

865    So, in the EU, Apple has required developers that wish to use alternative payment solutions or that lead users to payment methods outside an app to agree to the alternative terms addendum, under which developers must pay a new fee referable to the sale of digital goods or services in apps distributed via the App Store as well as a new fee referable to the number of app downloads being the CTF. The alternative terms addendum also required developers to pay an additional fee on the proceeds of sales of digital goods or services for developers who also use IAP.

866    I said at [4081] to [4083]:

First, there is a default commission of 17% on the proceeds of sale of digital goods or services for apps in the EU storefronts of the iOS App Store.

Second, there is an additional 3% commission on the proceeds of sales of digital goods or services for developers who also use Apple’s payment processing service.

Third, there is a Core Technology Fee (CTF) of 50 euro cents in respect of each first annual install per year. The CTF has the following characteristics.

867    I found that these fees are designed to dissuade developers from taking up the option of using alternative payment solutions for in-app purchases. The CTF in particular discourages the uptake of alternative payment methods because an app which achieves some degree of popularity will cause its developer to incur a substantial debt to Apple irrespective of whether the developer has generated any financial benefit from that app, including in circumstances where the developer would not have owed Apple any commission under the prior regime.

868    I said at [4086] and [4087]:

Further, the CTF is dependent upon a single variable, being the number of app downloads. It is conceivable, therefore, that an app which achieves some degree of popularity will cause its developer to incur a substantial debt to Apple irrespective of whether the developer has generated any financial benefit from that app.

So, if a game developer releases a free game which attracts two million annual downloads, that developer will incur an annual CTF of half a million euros, in circumstances where it would not have owed Apple any commission under the prior regime. If the developer subsequently publishes yearly app updates to its two million users, that fee will be incurred on an annual basis.

869    I found that these deterrence tactics, which include the CTF, were employed by Apple, in the face of legal compulsion, to protect its preferred arrangements.

870    I said at [4092]:

I agree with Epic that Apple’s ability to deploy such deterrence tactics to protect its preferred arrangements, even in the face of legal compulsion, manifests its substantial degree of market power.

871    In the context of developers who distribute iOS apps via alternative distribution channels, or that distribute apps via channels including the App Store, but who happen to sell digital content on a website or through their own platform for use in-app, the imposition of such fees could only be directed to dissuading such developers from using alternative payment methods, given that Apple would not be providing them with any distribution or payment service.

872    Let me now address proposed order 10(e) in more detail which seeks to enjoin Apple as follows:

The First Respondent must not (including by procuring any act of any related corporation) require that the Applicants or any other iOS app developer who uses a payment method other than IAP for accepting and processing payments for purchases of digital content for use in-app:

…

(e)    in connection with any iOS app distributed via the App Store, where:

(i)    in-app purchases are made using a payment method other than IAP, or

(ii)    purchases of digital content are made on any website or from any developer’s platform for use in-app,

pay a fee that exceeds any fee that is imposed on app developers who distribute iOS apps via the App Store in connection with in-app purchases of physical goods or services using a payment method other than IAP, plus any additional economic costs that are genuinely and reasonably incurred by Apple in connection with an iOS device user making an in-app purchase of digital content using a payment method other than IAP that are not incurred when a user makes an in-app purchase of physical goods or services using the same payment method.

873    Proposed order 10(e) addresses fees that Apple ought to be restrained from charging developers who use a payment method other than IAP in connection with in-app purchases made within any iOS apps distributed via the App Store. I found that the fees Apple charges developers in South Korea and the Netherlands, where it is required to permit developers to use an alternative payment method to IAP for in-app purchases, were based on an estimate of costs that Apple knew was unrealistic and out of reach for developers, and which ensured that the choice presented to developers was illusory.

874    I said at [5880] to [5884]:

Further, the regulatory requirements in South Korea and the Netherlands were directed at opening up the in-app payments market, yet Apple’s changes in purported compliance with these requirements were based on an estimate of costs that it knew was unrealistic and out of reach for developers. The reality is that developers would pay commissions that exceed 30% if they used an alternative payment system. The vast majority of developers are therefore unlikely to do so, as they would suffer a loss.

Now in my view the low take-up rate of alternative payment solutions demonstrates that the “choice” Apple has presented to developers in these jurisdictions is illusory. Apple has set the commission rates to block any genuine prospect of competition from suppliers of alternative payment solutions.

In all the circumstances, I would infer that the practical effect of Apple charging a service fee that is only 3 or 4% less than 30% is to offer developers the option of using an alternative payment system at an economically unviable cost.

Moreover, the fact that any developers in the Netherlands and South Korea have chosen to use an alternative payment solution to IAP is strong evidence of independent demand, given that it is demand to use a third-party payment solution even when it is likely to be more costly to do so than using IAP.

Further, the “implied” price at which Apple offers IAP to these developers is only 3 or 4% and is not a real or competitive price. It is an artificial construct, designed to ensure limited take-up of alternative payment solutions. Its effect is simply to replace a contractual tie with an equivalent economic tie.

875    The “implied” price at which Apple offered IAP to developers in those jurisdictions was found to be not a real or competitive price. Apple’s fee structures were found to be an artificial construct, designed to ensure limited take-up of alternative payment solutions and had the effect simply to replace a contractual tie with an equivalent economic tie.

876    Now Apple’s proven conduct in offering developers an illusory choice of that kind is addressed by proposed order 10(e) via two routes.

877    First, Apple would be prohibited from charging developers who use an alternative payment method to IAP, in connection with in-app purchases made within an app distributed via the App Store, a fee that exceeds fees imposed on developers who distribute apps via the App Store which allow users to make in-app purchases of physical goods or services using a payment method other than IAP. Clearly, the application of the IAP tie to digital goods and services only is a choice about Apple’s monetisation strategy, which presumably is for its own benefit.

878    In circumstances where Apple provides the same app distribution services to iOS app developers, regardless of how their iOS apps are monetised, and regardless of the nature of any in-app purchases, no justification can be offered for Apple imposing selectively disadvantageous fees in relation to digital goods and services as compared to physical goods and services, in circumstances where IAP is not used for either form of in-app purchase. I said at [2000] to [2010]:

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.

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.

Second, Apple refuses to play any role in relation to in-app purchases of physical goods or services.

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.

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.

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.

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.

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.

Importantly, it is a step that precedes, and is disconnected from, any actual in-app purchase by a user.

Apple’s involvement in any subsequent purchase that a user might initiate is limited to the compelled use of IAP.

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.

879    The only explanation for such price discrimination is that it is a means of imposing the anti-competitive payments tie on those developers who offer in-app purchases of digital content, by financially dissuading them from offering a payment solution other than IAP. It is appropriate that I enjoin Apple from such conduct.

880    Second, Apple would be prohibited from charging developers who offer an alternative payment method to IAP, in connection with in-app purchases made within an app distributed via the App Store, a fee that exceeds X plus any additional economic costs.

881    Now I said at [5859] to [5862]:

But I agree with Epic that the low take-up of that opportunity can be explained by the fact that, if developers do pursue it, Apple still charges a commission of 27% in the Netherlands or 26% in South Korea.

As Epic points out, using an alternative payment solution in those circumstances would make no sense for the vast majority of developers. To be worthwhile, they would need to find an alternative payment solution that they consider to be equal to or better than IAP and that charges less than 3% in the Netherlands or 4% in South Korea, or which offers other benefits that can outweigh the cost increase that would need to be incurred to make use of the alternative.

I agree with Epic that the cost structure imposed by Apple makes this a relatively unlikely proposition. Apple’s own costs of IAP are likely to be greater than 4%.

Payment processing costs vary substantially depending on the FOPs that are offered. Google estimated that they are around 4% when credit cards, PayPal, eWallets and bank transfers are offered but 6% when direct carrier billing and gift cards are included. IAP offers nearly 200 payment methods in total, including credit cards, PayPal, eWallets and, importantly, direct carrier billing and gift cards. Even accepting that Apple’s payment processing costs may not be the same as Google’s costs, they are likely to be far higher than 4%, and certainly higher than 3%.

882    Now proposed order 10(e) does not deny Apple the ability to obtain remuneration for services it in fact supplies. It is directed at fees imposed in connection with in-app purchases made within any iOS app distributed via the App Store that function as a proxy for the payments tie, that is, charges structured so as to deter developers from using non-IAP payment methods.

883    As Epic points out, this is not a hypothetical threat. I have already found that in response to regulatory obligations in the EU, Apple introduced a 17% commission and the CTF in a way that was designed to dissuade developers from taking up the option of using alternative payment solutions and that those deterrence tactics were employed to protect its preferred arrangements. I agree with Epic that there is a proper basis to infer that differential or supra-competitive charges imposed on non-IAP transactions would be used as a mechanism of foreclosure rather than as neutral remuneration for App Store distribution.

884    Now in-app purchases of physical goods and services have some different elements when compared to purchases of digital content, but their relevance is that Apple’s approach to apps in that class demonstrates that Apple can and does provide App Store distribution without levying a transaction-linked fee on those in-app purchases as I recognised in my liability reasons.

885    Apple’s main complaint in respect of proposed order 10(e), leaving aside its global objection to relief that extends to conduct not specifically found by me to contravene the CCA, is that the order lacks clarity and certainty. But the phrase “economic costs that are genuinely and reasonably incurred” is readily understood. It refers to costs that Apple genuinely and reasonably incurs when iOS apps are distributed via the App Store using payment methods other than IAP, that is, distribution costs. Apple is a sophisticated company. What is required of Apple to comply with proposed order 10(e)(ii) is clear. Let me address a related topic.

886    On 11 December 2025, the US Court of Appeals for the Ninth Circuit delivered its reasons for judgment in Apple’s appeal from the first instance decision of Judge Gonzalez-Rogers, in which Apple was held in contempt of orders consequential on Apple’s anti-steering restrictions, having been found to contravene Californian competition laws. I have referred to this decision (Epic Games, Inc v Apple 161 F.4th 1162) earlier.

887    Now her Honour at first instance permanently enjoined Apple from inter-alia imposing “any commission or any fee on purchases that consumers make outside an app”. The Ninth Circuit said (at 1185) that “[t]he biggest problem with the commission prohibition is that it permanently prohibits the compensation that Apple can receive for linked-out purchases of digital products, regardless of whether the commission is itself prohibitive”. The Court went on to say (at 1186) that “[t]he district court’s commission prohibition goes too far by denying Apple any way to purge its contempt by, for example, imposing a non-prohibitive, reasonable commission or fee”; query the additional words here in light of its later statement.

888    The Court offered some guidance for the remittal of the matter on what a permissible commission or fee regime could look like for purchases made via external links from iOS apps distributed via the App Store, that is, for charges associated with Apple’s coordination of linked-out transactions rather than for App Store distribution generally. The Court said that Apple should be able to charge a commission on linked-out purchases based on the costs that are genuinely and reasonably necessary for its coordination of external links for linked-out purchases, but no more. And the Court said that Apple should receive no commission for the security and privacy features it offers in connection with external links, and its calculation of its necessary costs for external links should not include the cost associated with the security and privacy features it offers with its IAP.

889    They said the following (at 1187 and 1188):

We recommend some possible courses of action to the district court regarding an appropriate commission or fee limitation on remand. Apple should be able to charge a commission on linked-out purchases with the following in mind: (a) Apple should be able to charge a commission on linked-out purchases based on the costs that are genuinely and reasonably necessary for its coordination of external links for linked-out purchases, but no more. We refer to these costs as “necessary costs.”; (b) In making a determination of Apple’s necessary costs, Apple is entitled to some compensation for the use of its intellectual property that is directly used in permitting Epic and others to consummate linked-out purchases. In deciding how much that should be, the district court should consider the fact that most of the intellectual property at issue is already used to facilitate IAP, and costs attributed to linked-out purchases should be reduced equitably and proportionately; (c) Apple should receive no commission for the security and privacy features it offers to external links, and its calculation of its necessary costs for external links should not include the cost associated with the security and privacy features it offers with its IAP; (d) Apple should not be able to charge any commission for linked-out purchases until such time as the district court has approved an appropriate fee, but both parties should be encouraged to reach agreement and/or seek the court’s approval of its proposed fee expeditiously; and (e) The district court may determine how best to make the referenced determination but one possibility includes inviting the parties to provide expert testimony based upon which it would determine the appropriate fee or commission to be chargeable for Apple’s actual costs of providing services for linked-out transactions. The district court might also consider whether to establish a “Technical Committee” somewhat like what was done in In re Google, 147 F.4th 917, to aid it in determining a reasonable fee and/or commission that Apple can charge for linked-out purchases. See id. at 954-55.

[footnote omitted]

890    That approach is not inconsistent with the concept underpinning proposed order 10(e).

Proposed order 11 (order 10 as modified and made)

891    By its proposed order 11(a), Epic seeks to prohibit Apple from imposing frictions or impediments into the process by which iOS device users can elect to use, or can in fact use, a payment method other than IAP when purchasing digital content for in-app use, which are additional to the frictions or impediments encountered when making in-app purchases of physical goods or services. I would note that proposed order 11 corresponds, with modification, to order 10 that I have made.

892    Apple points out that in part Epic seeks to justify this order by reference to findings that I have made in relation to Google. It says that the making of this order would align with my finding that the purported choice Google offered to developers to use an alternative payment solution to Google Play Billing in the context of the UCB and DOB programs is not a commercially real choice, where Google imposes frictions or impediments on users where an alternative payment solution is used.

893    Now I would note here that in GJ[642], [5491]–[5497] and [5500] I said the following:

Again, the choice being presented to developers by Google is not commercially real. App developers remain constrained by the payments tie, even when they have access to UCB.

…

It must comply with user experience requirements prescribed by Google. Initially, those requirements were set out in the interim guidelines. Presently, they are set out in an alternative billing APIs document.

The interim guidelines stipulated requirements that included the following matters.

First, the first time the user initiated a purchase, they had to be shown an information screen whose text and context had to be exactly as prescribed by Google, including a statement that “Only purchases through Google Play are secured by Google”.

Second, a billing choice screen had to be shown to the user before every purchase.

Third, the purchase price had to be shown to the user before they were shown either the information screen or the billing choice screen.

Fourth, the buttons for the alternative payment solution and Google Play Billing had to be represented in a fair and equal manner on the billing choice screen, and all components of that screen had to contain the exact text and elements prescribed by Google.

The alternative billing APIs document explained that once a developer integrates with Google’s alternative billing APIs, as participating developers are now required to do, then the Play Store renders and manages the applicable information and user choice screens, such that the user experience is dictated by Google. That user experience is not materially different from that required under the interim UX guidelines.

…

Further, the billing choice screen introduces additional friction into the payment flow.

894    Epic also says that this conduct, if not enjoined, would likely dissuade developers from adopting payment methods other than IAP, and would in substance continue the IAP tie.

895    But Apple says that no order should be made against it on that basis.

896    First, it says that I did not find either in the Apple or Google judgments that Google’s conduct in respect of the UCB or DOB programmes contravened s 46.

897    Second, it says that even if such a finding had been made in respect of Google’s conduct vis-a-vis its users, that finding would not justify or support the imposition of any restraint upon Apple, which was not alleged to have engaged, or to be likely to engage, in any cognate conduct and which conduct, accordingly, has not been the subject of evidence or submissions.

898    Third, it says that it is notable that the gloss Epic has sought to apply to proposed order 11(a) departs from the terms in which the order is cast. Epic described the conduct the subject of proposed order 10 as only display warnings proportionate to security risk. Proposed order 11(a) does not in terms permit Apple to display warnings proportionate to security risk.

899    Apple says that Epic’s proposed order 11(b) is analogous to its proposed orders 6(b) and 10(e)(i), in that it seeks to enjoin Apple from imposing fees or conditions for access to or use of its intellectual property which do not apply to developers selling physical goods or services through App Store apps. In that way, like those other orders, proposed order 11(b) would prevent Apple for charging any fee for its intellectual property, beyond the annual USD 99 Developer Program fee, or else require it to impose additional fees on developers of apps through which physical goods or services are purchased.

900    Apple says that not only is such relief outside that claimed in the FAOA and its pleaded case, but it also suffers from the other vices identified above in respect of those analogous orders. It says that there is no basis for finding that, if Apple were to impose fees or conditions for access to or use of its intellectual property beyond those permitted by proposed order 11(b), such conduct would necessarily contravene s 46. In those circumstances, the proposed order should, like its analogues, be rejected in limine.

Analysis

901    Proposed order 11 imposes additional negative injunctions that are directed to ensuring that Apple does not engage in specified conduct to limit the take-up or use of alternative payment solutions and thereby lessen competition in the payments market. Again, in terms of users and the App Store, I will apply the geographic limitations that I have previously indicated.

902    First, proposed order 11(a) prohibits Apple from imposing frictions or impediments into the process by which iOS device users can elect to use, or can in fact use, a payment method other than IAP when purchasing digital content for in-app use, which are additional to the frictions or impediments encountered when making in-app purchases of physical goods or services. This conduct, if not enjoined, would likely dissuade developers from adopting payment methods other than IAP, and would in substance continue the IAP tie.

903    Such an order is warranted in circumstances where I found that Apple used deterrence tactics to protect its preferred arrangements ([4092]) and I accepted that “clicks are costly”, meaning as I said in my main reasons that the more friction is imposed in respect of a particular transaction, the less likely it is that a user will complete that transaction.

904    This aligns with my finding that the purported choice Google offered to developers to use an alternative payment solution to Google Play Billing in the context of the UCB and DOB programs is not a “commercially real” choice, where Google imposes frictions or impediments on users where an alternative payment solution is used (GJ[642], [5491] to [5497], [5500]).

905    Second, proposed order 11(b) prohibits Apple from imposing fees or conditions for access to, or use of, any tool or API or SDK that is necessary to develop and distribute iOS apps that allow or enable developers and iOS device users to use a payment method other than IAP. As discussed above, in the European Union, where Apple has been prohibited from requiring developers to use IAP for in-app purchases of digital content, it has taken steps to impose fees, including the CTF that I found was designed to dissuade developers from taking up alternative payment solutions ([5830]). Conduct of a similar kind is addressed by order 11(b).

906    Apple contends that proposed order 11 would prohibit or impede its “implementation in Australia of means to protect user security and privacy”. I agree with Epic that that is code for introducing disclosure screens of the kind that Apple uses in other jurisdictions.

907    Moreover, Apple has failed to explain why security considerations require frictions of this kind when alternative payment methods are used to purchase digital content, but not when alternative payment methods are used to purchase physical goods and services within iOS apps distributed via the App Store.

908    Further, I found (at [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.

909    That finding is consistent with Professor Somayaji’s evidence that third-party payment methods are not inherently riskier than IAP, and that the use of disclosure screens serves only to make a distinction between IAP and third-party payments that has no firm basis in security.

910    And as Epic says, if disclosure screens were needed to protect user security and privacy, one would expect Apple to impose them equally in other contexts, including when alternative payment methods are used to purchase physical goods and services. Let me deal in more detail with disclosure sheets, drawing on Professor Somayaji’s evidence in part.

Disclosure sheets

911    Now Mr Friedland has stated that “External Purchase APIs […] when called upon: […] present appropriate disclosures to the user” and that the disclosure sheets “are a means of educating users of a change in the standard process (that is, IAP) so that the user is provided with the opportunity to assess their risk appetite in proceeding with providing their payment details to sources outside of Apple.”

912    But there are a significant number of transactions that a user may be conducting in iOS apps that do not involve Apple. For instance, Apple already allows some video streaming apps to use third-party frameworks for payment processing, rather than being restricted to using IAP. On the other hand, Mr Friedland states that disclosure sheets give users the opportunity to assess their risk appetite when using non-Apple payment methods. But this distinction is not justified.

913    Furthermore, the ability to use third-party digital payment solutions is only available to a select few subscription services that have negotiated special terms with Apple, that are not required to implement disclosure sheets for payments. As a result, there is no need for Apple to add additional disclosure sheets that simply inform users that they are transacting with the developer and not Apple only for in-app transactions for digital goods.

914    Further, if users face more steps and friction to complete transactions for the same good using a third-party payment solution, compared to IAP, then developers using those alternative solutions are disproportionately affected by implementation of disclosure sheets, which could lead to lower user spending and increased issues like cart abandonment. Instead, if disclosure sheets are implemented in a uniform fashion, a single payment solution like Apple’s IAP is not advantaged as it is offered with the same number of steps as required for third-party payment solutions. If Apple were to implement the current set of disclosure sheets for alternative payment solutions adopted in other jurisdictions, in response to my orders, such disclosure sheets for alternative payment solutions would only serve to make a distinction between Apple’s in-app payments and third-party payments for purchasing in-app digital content.

915    Further, some implementations of alternative payments on iOS devices include disclosure sheets, whilst other implementations do not. This demonstrates that the implementation of disclosure sheets for payments processed using alternative payment solutions is a policy decision by Apple. Apple uses disclosure sheets for alternative payments in Japan. But Apple does not require disclosure sheets when developers use non-Apple payment methods for certain types of purchases, including in-app purchases of physical goods or other goods and services consumed outside an app. Similarly, Apple does not require disclosure sheets for purchases of digital goods made via external purchase links in the United States.

916    Mr Friedland states that the StoreKit framework APIs that facilitate external purchases within an app, when called upon present appropriate disclosures to the user. Mr Friedland further contends that order 11 of Epic’s proposed relief restricts Apple’s use of disclosure screens, if they are considered to be a form of friction. Mr Friedland maintains that if orders 9, 10, and 11 were made concurrently, then certain of the sub-orders in Epic's proposed orders 10 and 11 could not practicably be implemented technically.

917    But the use of disclosure sheets is not a technical necessity and only serves to make a distinction between Apple’s IAP and third-party payments for purchasing in-app digital content. In fact, the orders that Mr Friedland contends could not practically be implemented, are already implemented in a similar fashion in the US.

918    Apple implements a handful of policy decisions related to disclosure sheets for alternative payment solutions on iOS. Policy variations are currently based on parameters such as jurisdiction, app type and category of item purchased. Apple does not require disclosure sheets for all alternative payment solutions. In addition to not requiring the use of IAP for physical goods and certain digital goods, Apple also does not require disclosure sheets for alternative payments for physical goods and services. In fact, developers cannot use IAP for the purchase of physical goods and services and items otherwise consumed only outside the app. Goods and services that are consumed outside the app can only be paid for using other purchase methods, and there is no associated disclosure sheet.

919    In most jurisdictions for which Apple allows alternatives to IAP for processing payments for in-app purchases of digital goods consumed in the app, developers must include in-app disclosure sheets that appear to a user before the app opens an external link or opens an in-app alternative payment.

920    In Japan, for example, these disclosure sheets that are shown below explain that the user will be “transacting with the developer and not Apple,” that features like payment methods stored in Apple and Apple-managed refunds are unavailable and that the transactions, “including their privacy and security, will be managed by the developer”.

Alternative Payment Disclosure Sheets in Japan in March 2026

921    Whilst Apple has announced plans to allow users to eventually turn off the disclosure sheet for future transactions in Japan, currently Japanese App Store users see these disclosure sheets for every transaction made using an alternative payment method for in-app purchases.

922    In contrast to Japan and other jurisdictions where Apple requires disclosure sheets for use of alternative payment solutions, app developers in the United States are no longer required to use disclosure sheets or entitlements for alternative payments. Between 16 January 2024 and 30 April 2025, app developers in the United States had been allowed to use links to external payment methods for their iOS apps. However, Apple implemented a 27% commission on such payments and instituted strict requirements on external payment links, including requiring use of the StoreKit External Purchase Link Entitlement and StoreKit APIs. I will elaborate on StoreKit External Purchase Link Entitlement later. The use of these entitlements also included restrictions that limited link formatting and placement and mandated in-app disclosure sheets, which were shown as follows:

External Purchase Disclosure Sheet in the United States in January 2024 and April 2025

923    On 30 April 2025, and as I have previously indicated, Judge Gonzalez–Rogers took Apple to task for, inter–alia, its dodgy disclosure sheets.

924    On 1 May 2025, Apple implemented new external app payment guidelines for the US that allowed app developers to use buttons and links to external payment methods within their apps without entitlements or disclosure sheets with non-neutral messaging and allowed app developers to encourage app users to use payment methods other than IAP. Some app developers including Spotify and Patreon rapidly submitted new versions of their apps that included external links and made use of alternative payment methods. These new app experiences did not include large disclosure sheets, and as of March 2026, app-based purchases in the United States on apps such as Spotify and Patreon continue to offer external payment links that immediately send the user to the app developer’s website to complete the transaction without a disclosure sheet as shown below:

Patreon External Purchase in the United States in May 2025

External Purchase Link Examples in the United States in March 2026

925    Not only does the removal of this restriction highlight that implementation of alternative payment systems is feasible on iOS devices, but it also showcases how the use of disclosure sheets is a policy decision made by Apple, rather than a decision based on any security or technical constraints. The disclosure sheets currently implemented for processing in-app purchase of digital goods only seek to notify the user that, for example, “This app does not support the App Store’s private and secure payment system.” Such an intermediate step does not contribute to user security, especially given that users regularly purchase physical and, in some cases, digital goods within apps, without attributing the transaction to Apple. Moreover, Apple’s IAP, which is a centralized means of payment processing, does not provide any security advantages over a decentralized means of payment processing.

926    In summary, the use of disclosure sheets for alternative payment solutions only serves to make a distinction between Apple’s in-app payments and third-party payments for purchasing in-app digital content and does not contribute significantly to user security.

General matters

927    Now as I have said, Apple contends that no such order should be made. Now true it is that Epic partly justifies the order by reference to my findings in Epic v Google about the UCB/DOB programs, but Apple says that I did not find that Google’s conduct in relation to those programs contravened the CCA. And it says that Apple itself was not alleged to have engaged in any cognate frictions conduct, nor to be likely to do so in future, and so there is no foundation for such a restraint.

928    But as I indicated earlier in my reasons, the question under s 80 is whether the orders are appropriate to remedy the contraventions and their effects. The provision is not confined to enjoining specific acts that have already been found to contravene. And I can formulate relief that addresses the mechanisms by which the contraventions operated and that prevents their re-emergence in a different guise.

929    Proposed order 11(a) is supported by my findings that Apple has misused its market power by tying IAP to in-app payments for digital content and foreclosing rival payment solutions.

930    Further, as set out earlier, I have already found that when obliged in other jurisdictions to permit third-party payment solutions or alternative distribution channels, Apple has responded by imposing various commissions, fees and other restrictions. I described those choices as uneconomic, illusory and designed to block any genuine prospect of competition.

931    In summary there is a real risk, supported by findings and further evidence, that absent proposed order 11(a), Apple will respond to any opening of the in-app payments market by imposing frictions on non-IAP transactions in ways that perpetuate the substantial lessening of competition that I have found.

932    Further, Apple’s criticisms of proposed order 11(b) regurgitate its earlier complaints about the scope of the originating application, the treatment of Apple’s IP and the requirement that enjoined conduct itself constitute a contravention, all of which have been addressed in relation to proposed orders 6(b) and 10(e).

Proposed order 12 (order 11 as modified and made)

933    Proposed order 12 would impose a broad and imprecise prohibition on Apple taking any steps to reject for distribution, discriminate against, take retaliatory action against, or otherwise disadvantage Epic or its apps, or any other developer or their apps, on the basis that their app is available through alternative distribution channels or uses or links to third party payment services. I would note that proposed order 12 corresponds, with modification, to order 11 that I have made.

934    Apple says that relief in this form has not been claimed in the FAOA, and is not supported by any aspect of its pleaded case or my liability findings.

935    It says that the core of Epic’s case attacked Apple’s prohibitions on alternative app stores, direct downloading of iOS apps, and use of alternatives to IAP for in-app purchases of digital content, as well as Apple’s anti-steering rule. It did not identify, much less attack, any conduct in which it was alleged Apple was likely to engage against developers or their apps which took advantage of the removal of those prohibitions or the anti-steering rule should that occur. No such conduct has been explored in these proceedings.

936    It says that the purpose of the grant of relief is not to restore competition to the distribution or payments market generally, but to respond to the case or controversy brought before the Court by Epic concerning specific practices said to lessen competition in those markets, and to give effect to the findings of contravention which have been made.

937    Further, Apple says that the grant of relief in these proceedings provides no occasion to seek to anticipate and forestall all possibilities of conduct lessening competition in the future by putting Apple at risk of contempt.

938    Further, it says that the proposed order would also operate to fetter contractual discretions which Apple presently maintains and which have not been the subject of any adverse finding in the liability judgment.

939    Apple under the terms of the DPLA reserves wide discretions to itself to reject for distribution or to cease distributing any app through the App Store including by reason of non-compliance with published App Review Guidelines.

940    Apple says that proposed order 12 attacks and undermines those discretions. Any exclusion of an app or developer who uses alternative distribution channels or third-party payment services might be characterised as discrimination or retaliation in breach of the order, with the result that Apple could not exercise its contractual discretions without running the gauntlet of contempt proceedings. Relief which operated in such a manner would be inappropriate.

Analysis

941    Let me say something concerning the injunctive relief dealing with compliance and anti-discrimination.

942    Proposed order 12 is a negative injunction directed to prohibiting Apple from rejecting for distribution, discriminating against, taking retaliatory action against or otherwise disadvantaging Epic or any other app developer both specifically in submitting apps for distribution via the App Store, or more generally, on the basis that the developer’s app is available for distribution outside the App Store, the app uses or will use a payment method other than IAP, or the developer links or otherwise informs, leads or directs users from within their app to a payment method other than IAP.

943    Proposed order 12 is the corollary of the prohibitive injunctions proposed by orders 5, 6, 7, 10 and 11 (orders 4, 5, 6, 9 and 10 respectively as modified and made).

944    If Apple were permitted to comply with those orders while at the same time taking retaliatory action against developers who took advantage of the opportunity to distribute apps outside the App Store, to use payment methods other than IAP, and/or to steer users to payment methods other than IAP, Apple could subvert the intended effect of those orders.

945    In such circumstances, proposed orders 5, 6, 7, 10 and 11 would be deficient in achieving their objective, and would be unlikely to restore competition to the distribution market or the payments market, as Apple’s retaliatory action would likely stifle competition in both those markets.

946    The injunction proposed by order 12 ensures that proposed orders 5, 6, 7, 10 and 11 have their intended effect of restoring competition in the affected markets.

947    Apple contends that proposed order 12 is impermissibly broad and imprecise, falls outside the relief sought in the FAOA and pleaded case, is unsupported by the liability findings, seeks to restore competition inappropriately and would improperly fetter Apple’s contractual discretions.

948    But as Epic points out, it is incorrect to say there is no basis in my findings for a restraint on discriminatory or retaliatory action against developers who use alternative distribution channels or payment methods.

949    I have already found that Apple has foreclosed competition by enforcing the requirement to use IAP and its anti-steering rule against developers even when IAP is not suitable for the developer ([4118]). I found that Apple rejected the Spotify app when it sought to communicate with customers about subscriptions ([4121]). I found that Apple rejected apps/games which use 3rd party payments (including WePay) to bypass IAP ([4122]). I found that Apple terminated more than 2,000 developer accounts since 2017 for failing to use IAP ([4123]). Further, I found that Apple’s conduct towards Epic is a paradigm example of its enforcement of the restrictive terms: [4124], [4130] to [4132].

950    More broadly, I made findings about Apple’s use of other mechanisms to undermine the practical effect of regulatory and judicial constraints in foreign jurisdictions. Proposed order 12 is directed to preventing that same pattern of retaliatory enforcement from being deployed against developers who take up the opportunities created by the other orders.

951    Further, s 80 is essentially a public interest provision directed to upholding the competition norms in Pt IV. It confers a broad power to make orders that are appropriate to prevent, restrain or remedy contraventions and their effects. Opening the distribution and payments markets to effective competition in the wake of a s 46 contravention is not some free-floating policy objective. It is the direct way in which the contravention and its effects are prevented, restrained and remedied, and as such it is fully authorised by s 80.

952    Apple remains free to enforce legitimate App Review Guidelines and to exercise its contractual discretions on other, lawful grounds. The fact that Apple’s discretions would be constrained so that they cannot be exercised for exclusionary purposes is a feature, not a vice. The liability findings show that Apple has previously used those wide discretions to enforce the IAP tie and anti-steering rule in a way that substantially lessened competition.

953    Finally, let me put a match to yet another straw man argument of Apple. Apple suggests that it could not exercise its discretion without running the risk of being in contempt. But if Apple acts for reasons unrelated to the matters in sub-paragraphs (c) to (e), it will not infringe the proposed order. And as Epic says, Apple can readily record those reasons (if legitimate) in a way that practically protects it from any such liability.

The question of timing – technical evidence

954    During the hearing on relief and as I have already indicated, I heard evidence on some technical questions from Epic’s expert, Professor Somayaji, who had given evidence before me at the trial on liability, and from a technical management witness called by Apple being Mr Friedland, who had not given evidence at the trial on liability. Let me begin with his evidence.

955    Mr Friedland, the Senior Director of Software Engineering at Apple, was cross-examined. But it is not necessary to descend into the detail of the cross-examination. Much of his technical evidence properly so called was not challenged. Rather what was challenged concerned speculative timing questions as to how long it would take and what would be involved in technically and commercially implementing my orders, which of course at the time of his evidence were uncertain. Mr Friedland expressed views on these questions which in my view were not wholly unreasonable although they at times bordered on taking a counsel of perfection approach. I will address my judgment call on the timing questions later, of course taking into account his evidence.

956    Mr Friedland leads the Digital Supply Chain Engineering team (DSCE) which is responsible for acquiring and managing the content for Apple’s media businesses. Within DSCE there are approximately 480 engineers structured into either line of business teams or horizontal functions; these latter functions include encoding media, rights and pricing engineering, processing images, quality engineering and the like.

957    Within the App Store line of business within DSCE there are approximately 110 engineers. There is a dedicated App Store Connect engineering team working on the web portal and APIs for developers to manage iPhone and iPad apps. App Store Connect is the portal interface through which developers can upload, submit and manage their apps.

958    There is an app processing engineering team that is responsible for processing what are described as binaries from developers and converting them to a final form that is deliverable on an iPhone or iPad. The description of “a binary” or its plural form is short-hand for in essence the object code of an app, which is of course in binary form, being the compiled and executable file of the software that can be run directly on the relevant device. There is a TestFlight engineering team, responsible for running a beta testing service that is agnostic to final distribution. There is an editorial engineering team responsible for how apps are featured on the Today tab on the App Store. And there is an app review engineering team responsible for building tools, workflows and automations utilised by Apple’s App Review team to detect content in apps submitted for review that violates the App Review Guidelines and other Apple policies.

959    The DSCE team designs, engineers and deploys the workflows, tools and controls through which developers interact with Apple in the process of designing, developing, distributing, operating and updating native iOS apps. This has been described as the technical plumbing. For that purpose, the DSCE team works with dozens of peer teams across Apple including the App Store client team, various server engineering teams, the product teams, and the operating systems teams under Mr Craig Federighi, who was a witness for Apple in the liability trial before me.

Alternative app distribution

960    Mr Friedland gave evidence that there are seven discrete technical processes and workflows that must be formulated, designed and implemented in order to enable alternative app distribution on an iOS device in a jurisdiction where Apple is required to allow alternative app distribution and payment including Australia. First, there is the process of developing or modifying and making available a framework comprising a large number of APIs, and other software tools to facilitate different components of alternative app distribution. Second, there is the process of creating and conferring entitlements to access the APIs that facilitate alternative app distribution. Third, there is the process of setting parameters and creating workflows for review and notarisation of apps as applicable. Fourth, there is the setting of parameters and creating workflows for installation of apps for alternative distribution and marketplace apps. Fifth, there is the setting of parameters and creating workflows for updates to alternative distribution apps. Sixth, there is the process of tracking, calculating and raising fees. Seventh, there is the process of managing the transition and roll-out period to developers and consumers. Further, underpinning each of these seven workflows is a set of legal terms, and a mechanism for tracking which marketplaces and developers have signed which versions of Apple's terms in order to unlock distribution in the particular jurisdiction. Let me identify his specific evidence on these workflows, which evidence I largely accept.

Developing tools, technology and services for creating and configuring an alternative distribution app: frameworks, SDKs, APIs and entitlements

961    Developers can use the same tools and technologies including Xcode, the iOS SDK and other SDKs and APIs to build a native iOS app regardless of whether the app will be distributed through the App Store or an alternative distribution channel. In that sense, iOS native apps, in terms of their creation by developers using these tools, are distribution channel agnostic. Apple SDKs include a collection of source code and object code, libraries, APIs and header files that enable developers to build apps that can run on Apple branded products.

962    But building and operating an alternative app marketplace, or enabling distribution of a native iOS app through such a marketplace or via direct download from a developer’s website, requires additional SDK features and frameworks and access to those features through new or modified APIs. Developers cannot create that functionality for themselves because, in order to enable such functionality, Apple must develop and/or make available private APIs that are interoperable with iOS and the many features of iOS devices, which are not required by and are therefore not available to developers who choose to distribute through the App Store.

963    Not all features of iOS and iOS devices are automatically available to all developers. The private APIs that are necessary to facilitate alternative app distribution operate at permission levels which are too privileged for developers to access without Apple's involvement, as they permit access to the operating system of users’ devices that would allow, for example, developers to read other apps' data and personal user data.

964    In jurisdictions where legal or regulatory requirements do not permit Apple to operate according to its standard business model for app distribution, Apple has developed additional features within iOS in order to conform to the specific requirements of each jurisdiction.

965    In order to enable alternative forms of app distribution initially in Europe and later also in Japan, Apple was required to make changes to the iOS SDK. Apple developed a new framework, called the MarketplaceKit Framework, which was made available to developers via an update to the iOS SDK and is now part of that SDK. To use the MarketplaceKit Framework, developers must download the updated version of the iOS SDK. I should note here that a framework means a structured bundle or directory comprising shared resources, including a dynamic shared code library, image files, header files and reference documentation in a single package. An application accesses the capabilities of a framework via APIs, which are published within the framework.

966    I have touched on the MarketplaceKit Framework earlier, which comprises a large number of APIs that enable developers to create, test, distribute, install and update an alternative app marketplace on iOS devices and facilitate web distribution of a native iOS app from a developer website to an iOS device. An alternative app marketplace is a marketplace operated by a third party developer from which apps are available for distribution once the marketplace is installed on the user’s iOS device from a developer’s website. Some of those APIs were newly developed for the purpose of facilitating alternative app distribution. Others are essentially APIs that were previously private APIs used by Apple and not previously available to developers. Creating public APIs based on the private APIs to permit developers to use them for the purpose of facilitating alternative app distribution requires extensive analysis by Apple of the relevant private API because the permission levels to call upon these private APIs affect operating system functionality and have historically been private to Apple.

967    Apple uses a technical mechanism called “entitlements” to control access to certain APIs and, through them, to features and information in iOS and on user devices. Entitlements are granted upon the developer meeting certain criteria, and in some instances, commitments to ongoing requirements, to protect users and developers, as defined by the applicable policy and legal documentation. Once granted, the entitlement is the technical mechanism which is recognised by iOS as an indicator to either lock or unlock access to the relevant APIs. The term “entitlement” is also used more generally to describe a permission that Apple grants to certain developers that allows the developer’s apps access to specific APIs functionality and services.

968    Apple builds end-to-end workflows across App Store Connect, the developer portal, the server APIs being Apple APIs which are run on Apple’s servers, and the client APIs being Apple APIs which are built into an SDK that is made available to a developer and run directly on a user’s device, to support the technical implementation of entitlements. Entitlements are the means Apple has deployed to control access to aspects of the MarketplaceKit Framework that enable non-standard functionality within iOS. The criteria and commitments to ongoing requirements which grant access to these entitlements have differed depending on the unique circumstances in each jurisdiction. Whilst marketplace apps are supported in both Europe and Japan, different criteria define developer eligibility to distribute marketplace apps in Europe and Japan. As to web distribution, developers have to satisfy specified criteria in Europe, but Apple does not enable web distribution in Japan.

969    Once a developer has been granted an entitlement to access certain APIs, the entitlement is cryptographically embedded into the code signature of their apps’ binary. Those code signatures are recognised and verified by iOS and signal the permissions that are unlocked by that entitlement, that is, the APIs which the app is permitted to use or call. This enables the developer to access features in the SDK to which they would otherwise not have access. It also prompts iOS, and the device upon which an app runs, to grant that developer’s apps access to call APIs and to use features of iOS to which the app and device would otherwise not have access.

970    There is an entitlement called the Alternative App Marketplace Entitlement that grants access to the MarketplaceKit Framework that facilitates alternative app marketplaces in Europe and Japan. Although the entitlement is the same for each jurisdiction, there are distinct commercial terms, that is, terms which a developer must meet in order to gain access to the entitlement, that govern in each jurisdiction.

971    Different aspects of the MarketplaceKit Framework are used to implement alternative app distribution in Europe and Japan, consistent with the regulatory requirements in those jurisdictions. For example, Apple is required to facilitate alternative app marketplaces in Japan, but not web distribution. In order to facilitate alternative distribution in Australia, the MarketplaceKit Framework will need to be updated in order to provide functionality that is specific to Australia. Any such changes will depend on the detail of my final orders. Let me elaborate further.

972    Professor Somayaji said that Apple’s MarketplaceKit framework and its underlying functionality is included in the latest version of the iOS SDK.

973    Furthermore, a comparison of alternative app distribution in the European Union and Japan illustrates how the MarketplaceKit framework can support different features and offerings depending on jurisdiction. The table below summarizes the current availability of alternative app marketplace distribution on iOS devices in comparison to the rest of the world.

Availability of Alternative App Distribution Channels Across Jurisdictions

974    Note that in the EU, app developers are allowed to offer their app for installation through their own websites, in addition to offering app installation from alternative marketplace apps. But in Japan, Apple only allows installation of apps from alternative marketplaces and does not allow installation from a developer’s website. In both Japan and the EU, alternative marketplaces can be downloaded from the marketplace developer’s website. Technically, there is no significant difference between the installation of a marketplace app from the developer’s website as is allowed in both Japan and the EU, compared to any other native app made available through a developer’s website on iOS, as both rely on the same domain-authorized web distribution mechanism designed to ensure authenticity of the original app binary.

975    Whilst both types of app installation use the same entitlements, Apple conducts policy checks to restrict certain functionality in Japan that is available in the EU.

976    iOS verifies device eligibility for apps from alternative distribution using on-device processing. In order to maintain eligibility, users must physically be located in the allowed jurisdiction. Further, the document indicates that iOS devices conduct additional checks to enforce the policy that users must be in the eligible country or region to install alternative app marketplaces and new apps through alternative app distribution.

977    Apple infrastructure thus supports significant variation in alternative app distribution policies.

978    In addition to the Alternative App Marketplace Entitlement, there are other specific entitlements in both Europe and Japan, which grant developers the ability to call different APIs in the MarketplaceKit Framework, for example, “com.apple.developer.marketplace.app-installation”. This entitlement enables an app to sell other apps as an alternative app marketplace.

979    Given entitlements are granted at the time of creating / approving the binary code of the app, with the passage of time, legal documents can lapse, terms can change and certain vulnerabilities in the app can be identified at a later stage by Apple. Therefore, while the entitlement unlocks the APIs on the user’s device, Apple conducts a series of server checks along the way, for example at app installation time, to ensure that Apple can monitor and manage the Apple ecosystem over time.

980    In addition to the MarketplaceKit Framework, Apple has developed other tools to facilitate alternative app distribution, for example, the App License Delivery software tool and associated App License Delivery SDK which developers can download from Apple’s developer website.

981    The App License Delivery software tool works with FairPlay. In order for an app that has been installed on an iOS device to run, FairPlay uses cryptography to confirm that the user is presently entitled to use the app. This was an existing system used by the App Store that was extended and packaged into the App License Delivery software tool to make equivalent functionality available to developers using alternative app distribution.

982    Developers use the App License Delivery software tool to generate digital keys, using cryptography, that indicate that the user is entitled to use an app that the user has downloaded via an alternative distribution channel. That permission or licence may be time-limited. As well as being a security and digital-rights management measure, this enables developers to use monetisation strategies such as selling time-limited access to an app, which might then be renewed like a subscription.

983    A further example of plumbing that needs to be developed and implemented to support alternative app distribution is a mechanism for developers to identify an authorised web domain from which users can download and install a web distribution app or marketplace app. Apple provides a mechanism for the developer to add the domain to their App Store Connect account, via the App Store Connect API, ensuring that the web distribution app and marketplace app only install from the developer's chosen website. This mitigates a risk of a bad actor impersonating the developer and, for example, offering malicious apps or apps that infringe the intellectual property rights of the developer or third parties.

984    A further example of the plumbing necessary to facilitate alternative distribution is the creation of ADPs, which are the packages that contain the actual binaries that run on each version of iOS. As I have already touched on, ADPs are electronic packages of IPA files, including an index to the IPA files, used to facilitate alternative app distribution.

985    To the extent that Apple is able to re-use SDKs, APIs, frameworks and entitlements, which are already used to facilitate alternative distribution in Europe or Japan, the time which will be required to implement alternative app distribution in Australia will be reduced, relative to what will be required if it is necessary for Apple to develop technologies that are specific to Australia. The extent to which SDKs, APIs, frameworks and entitlements can be reused depends on the extent of the differences in the technical and business requirements between the jurisdictions. The more specific the requirements of any order that I might make, the more additional engineering is likely to be required and the more time will be required.

986    In order to enable alternative distribution in Europe, and later Japan, it was necessary for Apple to update iOS in order for iOS to implement the newly created APIs and other technologies that are used for alternative distribution. It was necessary for users in those jurisdictions to install the newly released version of iOS on their devices in order to use alternative app distribution. It was not technically possible to provide alternative app distribution to users who did not update the version of iOS on a compatible model of the device. A further iOS update may be necessary to facilitate alternative distribution in Australia. If that is the case, alternative distribution will only be available to users once they update their device by installing an updated version of iOS. Generally, devices that are more than about eight years old will not be compatible with a new iOS update.

App Review for alternative app distribution

987    Let me say something about alternative app distribution being of course a channel of distribution other than the App Store for native iOS apps on iOS devices, being directly from developers’ websites or from alternative app marketplaces.

988    Once an app is created and configured by the developer and supplied to Apple, Apple would seek to review that app for security, privacy, and other risks and considerations against the set of guidelines Apple creates to inform the review of apps which are to be available for the target distribution in that jurisdiction.

989    During this second stage of the process of designing and developing a bespoke business model to respond to my orders, Apple would determine the applicable guidelines, including formulating the criteria to be assessed, and the mechanism of app review, based on the legal order, and then design tools and workflows to support the same.

990    In order to build the supporting tools and workflows, Mr Friedland’s team would consider the scope of the review based on the criteria including data to be provided by the developer, the type of review and whether the review is the same or different from other places in which alternative distribution has been enabled, that is, Europe and Japan. His team would generally not commence building, reconfiguring or adjusting tools and workflows to support the app review process until any order that I made had been analysed by other teams in Apple and the criteria and form of review settled.

991    There are two sub-workflows when it comes to a developer submission and app review.

992    One workflow looks at the app binary which would need to be submitted by the developer regardless of the elected distribution channel. Apple would develop tools that can "x-ray" the binary and interrogate its components. Generally, these tools are storefront agnostic, but there would need to be some technical work to enable Apple's systems to extract the relevant entitlements, cross reference what is permitted against the legal terms and policies, and present the findings to the reviewers in the course of reviewing apps. To the extent that new entitlements or new business logic combinations need to be created for Australia alone, Apple would work on extending the existing tools to match the requirements of the entitlement or business logic.

993    The other workflow looks at the metadata. This is this second workflow where one has a fork in the process if the developer indicates the app is exclusively for alternative distribution as opposed to App Store distribution. There are fewer requirements for exclusively alternative distribution apps since some of the metadata is for App Store display. Any app that is reviewed for App Store distribution is also eligible for alternative distribution. The degree to which the workflow built for Japan and/or Europe could be re-deployed in Australia will depend on the degree of similarity in requirements between those jurisdictions and what is ultimately ordered in Australia, and secondary to that, Apple's commercial decisions on the approach to app review for alternative distribution in Australia, which impacts the scope of metadata collected and reviewed. Examples of metadata that might be collected in a different format for Australia, compared to other jurisdictions, would be the age rating regional regulatory identifiers, or disclosures. For this workflow, there may need to be technical adjustments in the App Store Connect experience and as part of the review process. It is also necessary to build a loop in the workflow to collect and assess those additional metadata fields.

994    To the extent the app review policies for alternative distribution are the same between Australia and Europe or Japan, then Apple would seek to reuse as much of the existing solution as possible. However, where there are deviations then there would need to be a fork somewhere in the workflows to collect and assess what is necessary for Australia.

995    Any app review process implemented in Australia will have to reflect the set of App Review Guidelines to be enforced there. If full app review against all of these guidelines which apply to the App Store were to be undertaken, it would be necessary to build a bespoke technical solution to facilitate this type of review for alternative distribution of apps through a third party marketplace or by direct downloading from a developer website, in Australia.

996    If notarisation were to be deployed, it would be necessary to build into the workflow a code-signing mechanism at the end of the review process. This would create and attach the digital certificate signalling that the app has been through the requisite review channels, and is the mechanism which ensures at the time of installation that the binary has not been changed since Apple’s review.

997    The term “notarisation” for iOS apps under the Europe and Japan solution describes a different process to the app notarisation process which occurs for macOS apps. For macOS apps, notarisation entails a specific flow with an automated scanning process for malicious content and malware before certification. For iOS apps in Europe and Japan where the developer elects to distribute their apps solely through alternative distribution channels, those apps go through a baseline app review, with automated and human review steps checking for accuracy, functionality, safety, security and privacy. Where the developer of iOS apps in Europe and Japan elects both App Store distribution and alternative distribution, there is no baseline app review as those apps are subject to Apple's app review process for App Store distribution, such that upon meeting the App Review Guidelines, the apps are also certified for alternative distribution and are not subject to any further or separate review. Accordingly, the tools are different for macOS than they are for alternative iOS app distribution to iOS devices.

Status Based Checks for App Developers

998    Apple has already built mechanisms in the EU that use characteristics of the developer to implement differentiated user experiences with the developer’s app.

999    In March 2024, Apple introduced “trader status,” a categorisation associated with an app developer that allows the developer’s app to be distributed in particular ways within certain geographic regions. Following the introduction of this attribute, Apple required all app developers to declare a trader status, but the category is only used to determine how apps are distributed within the EU. When an app developer is not considered a trader in the EU for a particular app, app users associated with the EU App Store receive a notification that certain consumer protection laws do not apply. If an app developer is considered a trader for an app distributed within the EU, certain contact information is published about that app developer.

1000    When Apple first implemented trader status, it prevented app updates for all apps distributed within the EU for which developers had not submitted their trader status. Apple later removed all apps from the EU App Store for which trader status was not provided and verified. Apple did not remove those apps from other App Stores. So, Apple has the capability to introduce a new developer-based policy, verify that developers meet the requirements of that policy, and allow users to access the associated app based on the policy relevant to both the developer and the user.

1001    Whilst trader status implemented in the EU is an example that may require Apple developers to provide additional information, Apple also collects certain developer attributes and information based on developer location. When a developer enrols in the Developer Program to build iOS apps, Apple collects developer information, including name, age, contact information, location information and preferred language. Based on the user’s App Store region, Apple may display some of the developer’s information, including contact information and business information. For example, app developers based in South Korea are required to provide additional information about their identity, including email address, business registration number, and, for companies, company name and phone number, that is displayed on app product pages.

1002    The Apple Developer Enterprise Program also offers an example of developer-based policies that allow users to download apps irrespective of the user’s primary App Store based on developer attributes. The Developer Enterprise Program illustrates the presence of technical infrastructure that would allow for alternative app distribution without significant technical changes to iOS. The Developer Enterprise Program appears to be agnostic to the user’s primary App Store and instead requires valid enterprise certificates. The use of this certificate-based infrastructure allows Apple to alter app behaviour to remotely disable apps if the developer’s status changes, that is, if the developer is no longer a member of the Developer Enterprise Program.

1003    So, Apple has mechanisms within its infrastructure to allow apps to function differently based upon geographic and other characteristics of their developers.

Consolidating IPAs and ADPs for distribution

1004    Once an app passes the review mechanism which Apple elects to deploy, and provided that the developer meets any lawful criteria Apple chooses to impose, Apple’s processes prepare a deliverable asset for distribution of that app to iOS devices.

1005    All applications must be signed before they can be installed and executed on a device, ensuring only Apple approved apps run on iOS devices. In order to sign an application, developers need to attach a provisioning profile to their app. Provisioning profiles are required for all developers and are issued by Apple, based on the criterion provided by developers for distributing their apps. These provisioning profiles also include entitlements. The embedded entitlements are validated by iOS as part of the app’s execution process.

1006    iOS enforces app security through a series of validation checks. These include verifying the app’s code signature, which confirms the provisioning profile, ensures the developer is actively registered with Apple, and validates that the app’s entitlements are authorised for proper functionality. If these validation checks are not satisfied, iOS prevents the application from being installed or executed.

1007    Access to special app capabilities, such as use of alternative payment sources, is present within the iOS SDK, but these capabilities are not automatically granted to developers. Instead, access is determined by Apple’s policy decisions, which are implemented through entitlements granted or withheld via its developer infrastructure. Once approved, these entitlements are incorporated into a developer’s provisioning profile. In this way, provisioning profiles operate as a mechanism through which Apple can selectively enable access to platform capabilities without modifying the underlying frameworks themselves. Moreover, the App Store Connect develops multiple versions of an app submitted for review by the developer, such that each version of the app is unique to different iOS versions and devices. As a result, two instances of the same app, built from the same binary using the same SDK, can exhibit different functionality depending solely on the provisioning profiles, iOS version, or device they are tied to.

1008    Apple’s systems take the binary, that is, what the developer has developed in Xcode, and prepare a set of IPA files, which comprises everything which is needed for the device to install and run the app. Apple's processes must generate multiple versions of each app. Each IPA corresponds to a specific operating system and device. For example, the IPA generated for iOS 17 for an iPhone 15 Pro is different to that generated for iPadOS 17 iPad Mini, which is different in turn to that generated for iOS 26 for an iPhone 17, and so on. Apple also creates smaller delta packages which contain only the differences from the previous version, for streamlined updates. Creating the IPAs involves running proprietary tools to generate the binaries and digitally signing them.

1009    IPA files are generated for apps distributed via the App Store. In order to allow alternative distribution, Apple created ADPs which I have already described. It is only in the form of an ADP that apps for alternative distribution can be downloaded onto a user’s iOS device.

1010    Once Apple has created the ADP for an app, developers can download the ADP to their own servers, from App Store Connect. An API can also be used to automate this process. The developer then uses the ADP to distribute its app, whether via an alternative marketplace app or web distribution. Apple also built a mechanism to notify the marketplace that the ADP is available, if the app developer chooses to help streamline the process.

1011    The iOS device and Apple’s systems take the ADP as an input to initiate the installation of an alternatively distributed app. All files within an IPA are cryptographically signed so that Apple’s systems can verify their authenticity and that they have not been altered.

1012    In addition to provisioning and entitlement-based authorization, Apple provides mechanisms that allow developers to define conditions under which an application may be installed or executed on a device. For example, developers can specify installation requirements that check attributes such as the user’s age rating eligibility, minimum supported operating system version, and required device capabilities. These conditions are evaluated prior to installation and execution and can prevent an app from being installed or used if the specified criteria are not met. This demonstrates that application availability and functionality can be conditioned on defined criteria through system-level configuration.

1013    These system-level controls extend beyond static installation requirements to include user-specific authorisation mechanisms that determine whether and how an app may execute at runtime. On iOS, user-specific authorisation is enforced through FairPlay via Apple’s App License Delivery mechanism. FairPlay uses cryptography to confirm that a user is entitled to run an app, and the app will only execute on the device if that entitlement is verified. The App License Delivery SDK extends this system to apps distributed outside the App Store by enabling developers to generate digital keys that represent a user’s authorisation to use an app obtained through an alternative marketplace or website. Apple’s App License Delivery SDK implements this model by enabling developers to operate licence servers that generate per-download licences that the operating system retrieves at install time. These licenses are verified by FairPlay at runtime and may be time limited, expiring after a defined period unless renewed, and can also be revoked dynamically.

1014    Consistent with this model, during app installation a user-specific license is issued that authorizes execution of the app on a particular device. This license includes cryptographic keys used by the operating system to validate and enable the app’s execution, and is bound to the user’s account and device context, ensuring that only authorized users can run the app. In this way, Apple enforces user-specific and device-specific access and functionality through system-level verification, such that app behaviour is determined dynamically based on user-specific authorisations.

1015    These same mechanisms would be deployed to support alternative distribution in Australia.

Installation of alternative distribution apps

1016    When a user is browsing an alternative app marketplace or a developer’s website and viewing the information presented on a developer’s website or marketplace for a particular app, the user’s device is interacting with the app developer’s server, the marketplace, and, where applicable, the marketplace’s server. Apple’s servers are not involved.

1017    When a marketplace app or a developer's website would like to initiate an app installation, Apple’s primary involvement is to assess whether the installation on the iOS device is safe for the user and that the user understands what they are installing, and to facilitate the install itself. This is the final opportunity for Apple to implement measures to protect both the user and the developer before the app is downloaded onto the user’s device.

1018    When a user initiates an installation of an alternative distribution app from a website, the user's click calls on a set of APIs to start the installation process. In doing so, the browser, developer's server and devices’ operating system, iOS, communicate to pass the consent to install the relevant ADP file, and the cryptographic keys exchanged between the App License Delivery software tool and the FairPlay system.

1019    If the app that is to be installed is a marketplace, its binary will include information that tells iOS that the app is a marketplace and that the developer has access to the applicable entitlement, such as the Alternative App Marketplace Entitlement for Europe and/or Japan. Apps that contain the necessary “entitlement” code are able to call the APIs that are necessary for a marketplace to function on an iOS device.

Installation or disclosure sheets

1020    I have discussed this topic earlier and need say nothing more about it here.

Apple checks before installation

1021    Apple would also implement a series of checks during the installation process, to ensure the authenticity of the app and that the developer's intent to distribute via the alternative channel is still in effect. The function and purpose of these checks is to ensure that the app's binary is what was reviewed by Apple, has not been altered since it was reviewed by Apple, and is not unauthorised by the developer or third party marketplace. These checks guard against the risk that an alternative app marketplace or website distributor replaced the app binary reviewed by Apple with a different, unreviewed binary that could contain malicious code, and that the app was not subsequently found to have malware after the ADP was generated and signed.

1022    At the time the user’s device initiates the app installation, Apple’s servers check whether the app intended to be installed on an iOS device is still eligible for distribution. Apple checks whether the app has been taken down by the developer since the developer received the ADP, whether the developer remains a current member of the Developer Program, and for web distribution, that the website is owned by the developer initiating the install to prevent unauthorised distribution. This communication involves an interaction between the set of iOS APIs, Apple’s servers and the browser app to verify all these checks. For marketplace app installation, additional checks are made to verify the marketplace is in good standing and the relationship between the marketplace and developer is intact so that the developer can revoke a relationship and be guaranteed that Apple will respect that wish and stop distribution.

1023    Where an app does not pass these checks, prior to installation of the app by the user, Apple is able to block installation on the user's device, consistent with Apple's purpose of protecting the user from harmful apps and protecting the developer from unauthorised distribution. Where the app has already been installed on an iOS device from a developers’ website or a marketplace app, it is not clear as to the means by which Apple could remove the app.

1024    Finally, in so far as the technical solution to facilitate the installation of alternative apps in Australia is concerned, and even assuming there are no new requirements in Australia when compared to other jurisdictions where Apple has been required to facilitate alternative distribution, Apple would still need time to undertake technical work to extend the developer/marketplace onboarding flows to cover Australian-based alternative distribution and ensure the correct legal arrangements are in place for that territory. Further, it would need to extend the on-device eligibility for users in Australia with an Australian Apple Account to enable web and marketplace app installation, which would require an iOS update. Further, it would need to extend the mechanisms of calculating and billing for the selected business model for the Australian dollar and any local tax implications.

Updates for alternative distribution apps

1025    In order to support alternative app distribution within iOS, it is also necessary to make provision for apps distributed other than via the App Store to be updated periodically.

1026    There are two cases applicable to app updates, depending on whether the app is downloaded from a marketplace or, in Europe, directly via web distribution; web distribution of apps is not enabled in Japan.

1027    The App Store’s update daemon, being a program that runs in the background without direct user control, runs periodically and updates apps automatically when certain conditions are met, that is, when an iOS device is internet–connected usually via Wi-Fi, connected to power and automatic updates have been enabled by the user. When those conditions are met, the daemon automatically downloads and installs any updates for apps on the device without the need for user involvement. By this means the user always has the most up to date version of the app made available by the developer.

1028    In the case of apps distributed by alternative app marketplaces in Europe and Japan, Apple designed and made available to marketplace operators an equivalent but bespoke functionality to facilitate updates. This functionality, which is called MarketplaceAppExtension (formerly MarketplaceExtension), comprises a new set of APIs within the MarketplaceKit Framework. These APIs are made available to developers of apps for distribution via alternative app marketplaces in Europe and Japan through the alternative app marketplace entitlements, which, upon the developer meeting the relevant criteria, can be referenced in the code of the app’s binary. This functionality, where enabled by the marketplace operator, is invoked periodically by iOS, to allow the marketplace app to call the developer's server to check whether a newer version of the previously-installed app is available and then, where an update is available, to initiate that update to the user’s device. The MarketplaceAppExtension functionality can be used by developers to build their own bespoke update mechanisms for their marketplaces. This process, in contrast to the App Store daemon process, does not involve or require the marketplace app to make a call upon Apple's servers, nonetheless, when the update is triggered by the marketplace, Apple servers would be consulted, like they would be for an initial installation, to conduct various checks, for example, that the updated binary is not marked with malware.

1029    In this way, in making these tools available, Apple gives marketplace developers greater control over updates of apps, including as to the terms on which it distributes updates from its marketplace.

1030    In the case of direct web distribution, there is no marketplace app on the iOS device to manage the update. Generally, once a day iOS will find all web distributed apps. The iOS device will then check for a manifest file on each website to listen for app updates. The iOS device creates a list of apps and versions that can be installed from that domain. If the developer provides the required metadata for available updates, Apple actions the updates.

1031    Given that my orders are to be confined to users in Australia, the tools described above would form the basis for an automatic update solution for marketplace apps made available in Australia, and Apple would adopt a similar process in respect of updates for direct web distribution.

Tracking, calculating and raising fees for alternative distribution

1032    Because the terms of the business model in which alternative app distribution is permitted can only be selected once the specifics of my orders are known, the technical design and development of the platform infrastructure to support that new business model cannot be fully determined. For example, the rights and pricing engineering for alternative distribution and alternative payment solutions can only be designed and implemented once the approach to charging developers and alternative app marketplace operators is resolved.

1033    Whatever commercial model is adopted, Apple’s commercial teams would need to develop a set of eligibility criteria and contractual terms. Mr Friedland’s team would then be responsible for building any technical workflows, to assess the chosen eligibility criteria and to record where the relevant eligibility criteria have been met.

1034    The following considerations arise in determining the appropriate solution in Australia.

1035    At install time, the device itself uses location services and other criteria, such as the Apple Account associated with the device, to determine whether the device is eligible for alternative distribution. If so, the device is permitted to attempt installation from the alternative app marketplace or directly from the developer's website. It is likely that Apple would use an analogous system for Australia.

1036    After an installation has occurred via APIs on the device, the device makes a call to Apple servers to report that the installation has happened, the territory and what app was installed. Analytics tools process that report into aggregate account data including the storefront, number of unique installs, device and time period.

1037    The system calculates whether the thresholds for the fee or commission have been met, which is turned into a balance. Those systems and the workflows to be used in enabling the calculation of the relevant fee or commission will be dependent on the monetisation approach adopted in Australia. There are likely to be modifications to the systems and workflows for calculations.

1038    Finally, billing the developer the requisite fee and collecting the balance involves a further technical workflow across a number of systems, including handling of new currency and taxation considerations.

1039    It is likely that Apple would re-use parts of the existing technical solution where the requirements match or are similar. So, Apple could re-use the workflow for calculating and sending a bill to the developer if the orders permit that form of monetisation by Apple. What else Apple is able to re-use and what it will be required to design afresh will depend on my orders.

Preparations for testing, roll-out and transition phase

1040    Once the engineering solution has been established, and prior to the launch of the new model, there is a period of time required to test and qualify the new workflows and technology. Multiple teams within Apple would be involved in preparing the public facing documentation which describes the changes to the model and guided steps to implementation. Further, it would be necessary to staff support teams who must be trained with the expertise to address developer and user queries on the solution for a specific jurisdiction.

1041    Changes to the technical model for app distribution and in-app digital transactions would require an iOS update. Apple would require time to implement that iOS update. Each periodic iOS update ordinarily comprises thousands of software bundles.

1042    There are rigorous testing standards for OS updates, which are conducted internally by Apple, as well as part of what Apple refers to as a “seed release”, which is a pre-release phase or beta testing phase. During the pre-release phase, Apple releases the update to developers who wish to participate and who download the pre-release iOS update in order to test the new functionalities and APIs and provide feedback for Apple’s consideration of any modifications or further engineering builds which are required. The pre-release update is also then released for users who would like to beta test, and to cellphone carriers who are responsible for testing that the iPhone/iPad continues to operate with their network and approving the update for release to users. Apple’s release “cadence” for the final versions of an update to the OS has generally been approximately 3 to 4 months. The pre-release phase is generally undertaken during that window.

Alternative in–app payment solutions and steering

1043    In relation to other jurisdictions like South Korea, the Netherlands, Europe, Japan and the United States, if Apple were ordered to facilitate alternative payment solutions in an app other than IAP, whereby a user can complete a transaction for digital goods and services within an app using an alternative payment provider (a payment service provider (PSP)) other than Apple, or steering users within an iOS app to alternative out-of-app payment methods, there are a number of technical processes which Apple would need to consider.

1044    To enable in-app purchases of digital content and services that use Apple’s IAP, Apple makes available to developers a framework called StoreKit. StoreKit includes the ability to call APIs and look up a developer's product catalogue, which is reviewed and hosted by Apple, and to initiate and verify a transaction. When a developer opts in for alternative payments, then, to the extent that the developer and the user uses alternative payment solutions, that catalogue is no longer available. Apple effectively steps out of the process, leaving the developer to call their own backend server to determine what they wish to offer and the price of in-app purchases.

1045    As I have touched on earlier, for alternative payment solutions other than IAP, Apple has created a set of APIs called External Purchase APIs, within the StoreKit framework, that can display disclosure sheets to the user, for transactions made through apps distributed via the App Store, and facilitate reporting of transactions for the purposes of Apple collecting its commission on transactions made through apps distributed via the App Store and alternative distribution channels.

1046    This is different from the functionality offered by Apple’s IAP functionality, where Apple handles the end-to-end payment processing, including, for example, management of the in-app content and pricing schemes, purchase flows with many supported payment types, customer service and refunds, and Apple’s fraud monitoring. Apple does not process the third-party payments, and for apps distributed via alternative distribution channels, Apple’s IAP does not function for in-app transactions of digital content, for example, calls to StoreKit would not function where the app is installed outside of the App Store.

1047    There are entitlements for facilitating alternative payment solutions, both for payments in the app and linking out. The concept of linking out means providing a hyperlink for users from within an iOS app to out–of–app payment methods for accepting and processing payments for purchases of digital content for use in–app.

1048    In both the Netherlands and South Korea, the entitlements are called StoreKit External Purchase Entitlement granting developers the ability to implement third party payment systems and enabling such systems within an app, and StoreKit External Purchase Link Entitlement, enabling apps to include links that direct users to make and complete an external purchase for in–app digital goods. Although Apple has adopted the same name for these entitlements across multiple jurisdictions where Apple has been required to facilitate alternative payment solutions and linking out, the components of those entitlements, for example the eligibility criteria and the permissions to which they grant access, differ by jurisdiction and there is a storefront list inside the binary to indicate which storefronts the alternative payment option is enabled for. To be granted either of those entitlements, the developer must provide certain app information, payment processing information and the developer’s website URL for customer support and for linking out.

1049    These entitlements are part of the StoreKit framework and, like the MarketplaceKit framework, is already included in the iOS SDK. While this functionality is present on iOS devices, Apple restricts access to it using entitlements. In this way, the StoreKit External Purchase Entitlement and the StoreKit External Purchase Link Entitlement operate as permissions enabling access to “private APIs” that allow developers to integrate this functionality within their apps.

1050    The specific requirements governing the alternative purchase entitlements and their implementations within the StoreKit framework vary across jurisdictions. The variations in current implementation and available capabilities across jurisdictions for alternative payment mechanisms on iOS are illustrated in the table below.

Availability of Alternative Payment Mechanisms Across Jurisdictions

1051    These differences in functionality are largely driven by policy decisions implemented by Apple in response to regulations in various jurisdictions, rather than technical constraints. For example, in the United States, developers may offer alternative payment links and steering without requiring the StoreKit External Purchase Entitlement or StoreKit External Purchase Link Entitlement. Requiring the entitlements to access this functionality is a policy decision by Apple, and the implementation in the US highlights that the StoreKit framework can support alternative payment functionality without additional technical gating.

1052    As an example, consider the workflow for facilitating external payment links and external purchases on iOS. For external purchases, Apple’s developer documentation outlines the “canPresent” property, which implements certain policy decisions from Apple. Specifically, developers are required to check the “canPresent” property before allowing external purchases. This check in turn uses data collected by Apple to verify that the App Store “storefront” is eligible to offer external purchases, the person making the transaction is eligible and the developer’s app configures the entitlement and country codes where alternative payment methods are allowed.

1053    Apple’s infrastructure thus currently supports significant geographic variation in iOS in-app payments.

1054    Similar entitlements would need to be developed for Australia, with the eligibility criteria, scope of information sought from the developer and access granted by means of the entitlement, determined in accordance with the legal order.

1055    If a developer has a StoreKit External Purchase Entitlement or a StoreKit External Purchase Link Entitlement, the name of the entitlement is cryptographically embedded into the code signature of their app’s binary, which is then recognised by iOS and signals the permissions that are unlocked by those entitlements. The entitlements provide access to the External Purchase APIs which are necessary to facilitate external purchases within an app other than IAP and to offer external purchase links because those APIs, when called upon, do the following.

1056    First, they verify for the running app whether the user is eligible.

1057    Second, they present appropriate disclosures to the user, for transactions made through apps distributed via the App Store. The form of the disclosure sheets varies across jurisdictions, but they explain that purchases are made through a source other than Apple, for acceptance by the user. As with disclosure sheets for alternative app distribution, they are a means of educating users of a change in the standard process, that is, IAP so that the user is provided with the opportunity to assess their risk appetite in proceeding with providing their payment details to sources outside of Apple.

1058    Third, they report to Apple external purchase tokens, which are unique strings that are generated by Apple and received by a developer’s app or website where a customer elects to view a developer’s external purchase offerings. This enables Apple to keep track of external purchase attempts but not the completed transaction, which can then be used to verify reporting of completed transactions by the developer to Apple, for Apple to then calculate the applicable commission or fee and any taxes Apple is obligated to pay.

1059    Without access to these External Purchase APIs, developers cannot enable this functionality in their app in compliance with Apple's terms and conditions.

1060    The solutions across the Netherlands, South Korea, Europe, Japan and the United States utilise APIs and entitlements that have slightly different behaviours and disclosure sheets depending on the requirements in each jurisdiction.

1061    As is the case with the technical solution for facilitating alternative distribution in Australia, if Apple were required to facilitate alternative payment solutions or steering, depending on the legal requirements, and the commercial business model constructed by Apple within the bounds of that order, cross-functional teams would develop a bespoke solution that matched the requirements. That solution would include developing, inter–alia, entitlements based on certain eligibility criteria, geo-based unlocking of the desired functionality, functionality which allows tracking, reporting and calculation of commissions for transactions outside of the App Store and through payment solutions other than IAP, and designing and building disclosure sheets. Apple would seek to use prior work from other jurisdictions, but bespoke engineering for Australia is likely to be required.

1062    Mr Friedland would expect the technical effort will be less resource intensive than for South Korea, the Netherlands and Europe, since his team would build on the prior work for those jurisdictions where possible. Given the steps described above for a technical engineering solution that involves alternative payment solutions and linking out in Australia, that is, limited to iOS devices associated with an Australian Apple Account, and taking into account the work to be undertaken by cross-functional teams and the testing / roll-out phase of an operating system update, it is estimated that it would take several months to develop and prepare for commercial release.

General considerations and conclusions on timing

1063    In Professor Somayaji’s opinion, the changes required to enable alternative app distribution and alternative payment solutions would likely require limited technical effort. He would expect less than six months. In his view much of the infrastructure required to implement Epic’s proposed relief has been developed in the form of frameworks such as StoreKit and MarketplaceKit, and most if not all of the further implementation effort required for Epic’s proposed relief should involve changes to automatically enforced geographic policies, not changes to code. As a result, such changes should not require substantial technical effort.

1064    Professor Somayaji said that whilst specific rules regarding alternative app distribution and alternative payment solutions can be implemented by changing the source code of Apple’s iOS operating system and its App Store infrastructure systems, that is not how deployment-specific constraints are typically addressed in software systems. Instead, standard practice is to implement policy engines. Thinking of software infrastructure as plumbing, policy engines would be the valves that enforce certain policies based on their settings. When plumbing is placed into a structure, it is built to accommodate likely changes, with valves and other controls put into place to allow water flow to be regulated or diverted as necessary. Similarly, a policy engine allows software to adapt to changes in policy without requiring code changes. The engine is given a new policy in the form of changes to the underlying settings and the functionality of the system changes.

1065    Professor Somayaji said that in this system the mechanism or code by which certain functionality is facilitated does not require changing. Specifically, mechanism and policy are separated. Source code is implemented so that it could enforce a variety of policies rather than assuming a single policy will always be used. Thus, when policy changes, the same code can be used under a different policy setting. In general, a separation between mechanism and policy improves software longevity because mechanism or code changes are more costly and more prone to errors than policy changes. For this reason, the separation of mechanism and policy and the subsequent use of policy engines has long been a design principle of operating systems.

1066    Professor Somayaji gave the example of a basic user account system. If the system only has five user accounts, an administrator with appropriate access could, in principle, add the usernames and passwords for the five users directly to the operating system’s code. In this example, the operating system would recognize those five users and allow them to access the system. However, to add a sixth user or to remove a previously authorised user, the entire operating system would have to be rebuilt and re-installed after changing its code. In contrast, consider the same system with a policy engine. When deciding whether a user is authorised, the policy engine simply queries the relevant database to verify if the user is able to access the system or not. The contents of the database can be changed at any time without requiring any code changes.

1067    Now it was said by Mr Friedland that developing entitlements that are specific to Australia requires significant technical work. But Professor Somayaji gave the following response.

1068    In the context of iOS, entitlements are deployed by Apple to control access to aspects of relevant frameworks such as MarketplaceKit and StoreKit. In this way, entitlements are access control mechanisms that gatekeep access to functionality that only some apps are allowed to have. Adding a new entitlement or changing how an existing one works is thus a modification to the app-level access control mechanisms of iOS. In other words, new entitlements are a policy change that control access to already existing functionality.

1069    If one assumes that the iOS entitlement system is a reasonably well-designed access control mechanism that was built with the expectation that entitlements would change over time, then basic changes to iOS entitlements, on their own, would require modest levels of engineering effort, for example, changing a small number of lines in a handful of files. The potential complexity of adding or modifying entitlements would instead lie in the implementation of mechanisms that facilitate actual functionality that is to be enabled, rather than the entitlement itself.

1070    Apple has already implemented the key functionality behind the potential new entitlements that may be required in response to my orders. To give some apps special privileges would thus primarily entail Apple’s addition or modification of policies. These new or modified policies will gatekeep certain functionality and restrict that functionality to users with an Australian Apple Account.

1071    Further, because much of this existing functionality is only available in certain jurisdictions, Apple has likely already created policy engines throughout their systems that could be used to enable alternative app distribution and alternative payment solutions in response to my orders. Such policy engines are typically needed because otherwise legislative, administrative or other local changes in requirements anywhere in the world would require software updates across the iOS ecosystem, which would be impractical. Instead, policy engines would turn most such changes into updates to policy databases, which engineers can change with minimal effort.

1072    Apple already manages significant variation in app distribution policies across jurisdictions. Apple handles significant geographic variation by operating the App Store in 175 jurisdictions. The App Store has over 40 languages and supports over 40 different currencies, each with unique tax regulations which require adjustments in pricing, and geo-specific local laws and regulations as regards distribution and transactions for digital goods and service. In turn, iOS devices communicate with the App Store to identify the apps available for distribution. For instance, Apple’s devices would not permit certain functionality based on where the user is located and the billing account details of the user. Further, iOS verifies device eligibility for apps from alternative distribution using on-device processing. In order to maintain eligibility, users must physically be located in the allowed jurisdiction. So, there are systems on iOS that already identify where the user is located and consequently which apps are available to the user based on rules across jurisdictions.

1073    Another example of policy engines are the systems that ensure only licensed software can be installed on an iPhone. Apple uses an app installation process in which only custom app binaries, unique to each individual device, are permitted to be installed on that device. Apps must be given a user-specific license so the operating system knows the app is authorized for the user, and apps are “thinned” so only the media assets that are required for that specific device are included with each app. This licensing mechanism means that Apple already chooses which apps are authorized on a user’s device, and that authorization is determined by policies enforced collectively by policy engines on iOS devices and Apple servers.

1074    There are various policy variations and entitlements that Apple has previously implemented, specifically with respect to frameworks required to enable alternative app distribution channels and alternative payment solutions.

1075    Apple has implemented differentiated policies that result in varied functionality available to developers and users across multiple jurisdictions. Such differentiated policies also indicate that Apple has built parameters that can be tweaked within a reasonable timeframe to implement solutions in response to the relief ordered by me, using the same underlying technical components such as StoreKit and MarketplaceKit.

1076    Further, according to Professor Somayaji, the introduction of specific policies or updates required for different policy engines would not be extensive across different teams and ultimately would not require a substantial amount of technical effort.

1077    As part of enabling alternative app distribution and alternative payment solutions on iOS devices, some changes would need to be introduced across the following four core areas, being developer onboarding processes, software development tools such as Xcode, automated app review systems and on–device implementations. Apple has already conducted extensive work with respect to solutions developed across other jurisdictions.

1078    In order to allow alternative app distribution and alternative payment solutions on iOS devices, Apple would likely set some criterion based on which developers are allowed to receive the requisite permissions and entitlements. Apple may require certain terms which a developer must meet in order to gain access to the requisite entitlement. But the complexity of enabling alternative app distribution or alternative payment solutions does not arise from policy implementation or eligibility criteria design but instead arises in the development of the mechanisms that facilitate these functions on iOS devices. Such mechanisms have already been deployed by Apple in other jurisdictions. So, changes to the criterion and specific workflows that allow developers to participate in alternative app distribution or offer alternative payment solutions would require minimal changes to include additional policies or change existing policies, which would then be enforced by the requisite policy engines.

1079    After the developer has successfully enrolled and is determined by Apple to be eligible to participate in alternative app distribution or offer payment solutions other than IAP, the developers would need to be able to build these capabilities into their app. I have referred to Apple’s Xcode earlier in my reasons. Some changes to Xcode may be required before developers are able to integrate this functionality into their apps. Apple has already deployed versions of Xcode that allow developers to add the requisite entitlements within their apps. These updates would take minimal technical effort to implement in Australia.

1080    Further, there would need to be some technical work for the app review system implemented as part of my orders in Australia. But given that notarization has already been implemented by Apple in other jurisdictions as part of the app review process for apps distributed through alternative distribution channels, the implementation of app review processes in compliance with my orders would not require a significant amount of technical effort. A notarized direct download model will not lead to a deterioration of security on iOS, assuming app sandboxing remains the same on iOS devices.

1081    Finally, for iOS devices to recognise the entitlements introduced in response to my order to facilitate alternative app distribution and payment solutions other than IAP, Apple would likely need to introduce some on-device changes. Such on-device changes typically require an operating system update. Operating system updates require careful evaluation and testing as flawed updates could affect the functionality of billions of devices. Because of the risks associated with changing core operating system software, such changes would take more technical effort than the potential updates that would be required across other components. However, since the core functionalities required to implement Epic’s proposed remedies already exist in iOS, the on-device code changes should be minimal. Apple has already implemented alternative app distribution and alternative payment solutions on iOS in other jurisdictions. As a result, the requisite technical work would involve updating the entitlements that gatekeep the relevant functionality.

1082    So, including the approximate three to four months stated by Mr Friedland for testing iOS updates, Professor Somayaji expects the total technical effort required for implementing solutions according to my orders in Australia to be less than six months.

1083    Now Apple seeks a period of time to comply with whatever injunctive relief that I grant. And Apple says that it would require up to six months if the relief were limited to iOS devices associated with an Australian Apple Account.

1084    Professor Somayaji’s opinion is that Epic’s proposed orders, particularly if geographically limited, do not require significant engineering work and principally involve policy changes that can be developed and deployed by Apple in less than six months.

1085    Now as I have indicated, Mr Friedland’s evidence explains why about six months will be required to implement alternative distribution and alternative payments in Australia. He describes seven discrete technical processes and workflows that must be formulated, designed and implemented in order to enable alternative app distribution in Australia.

1086    Further, I accept that this will not be an exercise simply in adjusting valves in existing plumbing or simply making policy changes. As Mr Friedland’s evidence makes clear, the exercise required of Apple in order to implement my orders will involve both engineering changes and the formulation and implementation of new policies.

1087    Further, before Apple knows what orders it must comply with, it cannot design or implement the engineering and policy changes required to enable it to conform to those orders. Whether and to what extent Apple will be able to redeploy existing tools, such as the mechanism it has designed to facilitate updates of apps downloaded by alternative distribution, will depend inter–alia on whether Apple’s deploying those existing mechanisms would comply with my orders.

1088    Further, the technical solution for facilitating alternative payments or steering would depend on the requirements of my orders and the business model adopted within the bounds of the orders. It will likely involve bespoke engineering for Australia.

1089    Based on those matters, Mr Friedland estimates that it will take some months to engineer and test a technical solution to provide alternative app distribution and alternative payments to iOS devices associated with an Australian Apple Account, and prepare it for commercial release, once the particular requirements of my orders are known. Particularly given the likely need for an iOS update, and the need to ensure that changes appropriately preserve security to the extent possible, Apple says that its proposal that it be given six months to implement its proposed injunctive relief is reasonable and appropriate.

The start date

1090    In all the circumstances and given that I have limited the operation of the orders to the Australian App Store, it is appropriate that I fix a start date of some four months away being 1 March 2027. That should be sufficient for Apple working efficiently to deal with the necessary technical and commercial issues involved.

1091    But I will provide in my orders for an additional two months flexibility if Apple can justify this as being needed on the evidence. I will provide in my orders that Apple can apply no later than 15 February 2027 but no earlier than 1 February 2027 for a further two months period which, if justified on the evidence then filed, may result in the start date being postponed until 3 May 2027.

Duration of injunctive relief

1092    Apple says that any injunctions ordered should be in effect for a period of five years from the date by which compliance is required. It says that the facts that give rise to my orders are not a permanent state of affairs. It says that the supply of services of iOS app distribution and iOS in-app payment solutions occur in dynamic markets that will evolve with technological innovation, eventually beyond recognition.

1093    Given the nature of these high–tech markets, Apple says that five years is an appropriate time period to ensure that the contraventions are remedied. Further, it says that such a fixed time frame will ensure that my orders do not endure when they are no longer justified or appropriate to prevailing technologies and market conditions.

1094    Now in my view, to make orders that are only to operate for a fixed time is inapposite.

1095    First, any such fixed term is arbitrary. Adopting Apple’s logic, why not three years? Or why not 10 years? I am not able to satisfactorily ascertain what such a fixed term should be on the current evidence.

1096    Second, I do not need to set a fixed term given s 80(3) which provides:

The Court may rescind or vary an injunction granted under subsection (1) or (2).

1097    If, in the known world, market changes or technological advances have taken place which justify a rescission or variation of the orders that I have made, then that can be established on the evidence and factual matrix then available. In other words, if Apple’s predictions are correct then it can seek and justify any required rescission or variation at the later appropriate time.

1098    Third, to require Apple to invoke s 80(3), if it so chooses, appropriately puts the onus on it to substantiate any material market or technological change that it says justifies any rescission or variation. In terms of knowledge of any such change or its significance, Apple is in a better relative position than Epic to have knowledge of and to identify such a change and its significance. It is appropriate that it bear the onus under any s 80(3) application.

Costs

1099    Apple submits that the appropriate costs order in terms of the trial on liability is that it pay 70% of Epic’s costs of the proceeding on the standard basis.

1100    Apple points out that I accepted Epic’s case that Apple’s prohibition on direct downloading (or sideloading) of native apps, and on alternative payment solutions for digital in-app purchases, contravened s 46. But I rejected Epic’s case that Apple’s refusal to distribute alternative app stores via the App Store contravened s 46. I also rejected Epic’s case concerning various terms of the DPLA and App Review Guidelines and rejected Epic’s claims under ss 45 and 47 and its unconscionable conduct claims.

1101    Apple says that accordingly the proceeding is properly characterised as one in which there has been some degree of mixed success. So it says that it is appropriate that there be some apportionment of costs. Apple submits that an appropriate apportionment is that Apple pay 70% of Epic’s costs.

1102    Now the focus of Epic’s case was its allegation that Apple’s conduct contravened s 46, which Epic established. Further, the aspects of the case on which Epic did not succeed factually overlapped with the areas of the case in which Epic did succeed. Nevertheless I agree with Apple that some reflection should be made in the costs order for the fact that Epic did not succeed on some of its causes of action.

1103    In my view, Epic should have 85% of its costs of the liability trial. As to the parties’ costs concerning the hearing on relief, I will reserve the parties’ costs at this stage.

Conclusion

1104    For the foregoing reasons, I propose to make orders in the terms set out at the outset.

Associate:

Dated:    22 October 2026