Research and analysis

Interim report

Updated 26 January 2022

Executive summary

Introduction

Mobile devices with internet connectivity such as smartphones and tablets now play a fundamental role in the lives of UK citizens, providing fast and convenient access to a wide range of products, content and services. In addition to communication, mobile devices also give us instant access to the latest news, music, TV and video streaming, shopping, games, fitness tracking and much more. They can also be connected to a wide range of other devices such as smart speakers, smart watches and home security and lighting. These products and services are now able to work in combination with each other, in a way that strengthens the value and functionality of each, within what we refer to as mobile ecosystems.

Mobile ecosystems can be broadly characterised as comprising the following core set of products:

• mobile devices: portable electronic devices that can be held in the hand, including smartphones and tablets, and can connect to the internet

• mobile operating systems: the pre-installed system software powering mobile devices

• mobile applications (or ‘apps’): pieces of computer software providing functionalities to mobile devices. Some apps come pre-installed on devices (including, notably, mobile app stores and browsers), while others can be selected and installed by the user.

Mobile devices generally come with at least one app store and one browser pre-installed on them. These are the 2 key channels through which users and content providers can connect through 2 main channels of content distribution:

• native apps: these are applications written to run on a specific operating system and, as such, interact directly with relevant elements of the operating systems in order to provide relevant features and functionality. Native apps can be pre-installed on devices or otherwise are typically downloaded through app stores ^{[footnote 1]}

• browsers and web apps: mobile users can access websites through the browser on their devices, or ‘web apps’, which are applications built using common standards based on the open web, and are designed to operate through a web browser. Web apps have additional functionality compared to standard websites.^{[footnote 2]} Web apps should in principle work on all browsers and on any operating system due to the common standards of the open web

When consumers today purchase a mobile phone, they effectively enter into one of 2 mobile ‘ecosystems’ – one operated by Apple, powered by the iOS ^{[footnote 3]} operating system; the other operated by Google, powered by Google-compatible versions of the Android operating system.^{[footnote 4]}

The operating system on a mobile device determines and controls a range of features that are important to users of mobile devices, ranging from the appearance of the user interface, through to the speed, technical performance, and security of the device. They can also determine what kinds of software (applications) can run on top. As suppliers of the 2 key mobile operating systems in the UK, Apple and Google are able to make a number of key decisions that can have significant implications for the products and services that are accessed online.

Apple and Google also control the key gateways through which users access content on mobile devices and through which content providers can access potential customers:

• Apple’s App Store is the only permitted app store on iOS devices and Google operates the Play Store, which is used for the discovery and download of over 90% of all native apps on Android devices.^{[footnote 5]} Apple and Google are in a position to determine which apps are allowed in their store, how apps are ranked and discovered, and also often charge significant levels of commission (up to 30%) on app developers’ revenues from in-app transactions, by requiring these transactions to be made through their own in-app payment systems. At the same time, Apple and Google also offer their own ‘first-party’ apps to users.

• Apple’s browser, Safari (over 90%) and Google’s browser, Chrome (75%) have very strong shares of browser usage in their respective mobile ecosystems and are generally pre-installed for use when a user first turns on the device. As Apple operates the only browser ‘engine’^{[footnote 6]} that runs on iOS and as Google operates the main browser engine on Android devices, each is in a position to determine the functionality and standards that will apply not only to their own browsers, but to competing browsers and, in turn, to web apps.

Figure 1 below illustrates how the control of their respective operating systems give Apple and Google the ability to influence outcomes in other aspects of the overall ecosystem.

Figure 1: the choice between Apple’s and Google’s mobile ecosystems

Figure description: A diagram showing the nature of the choice between Apple and Google’s mobile ecosystem and the control each firm has over the main gateways through which users access online content. The diagram lists user choices on the device manufacturer level, the operating system level, for pre-installed apps and for user accessed content. For Apple, the diagram shows Apple as the only choice on the manufacturer level, on the operating system level there is only iOS, for preinstalled-apps there is the AppStore, Safari and other Apple apps. Users can access native mobile apps and web content. For Google’s ecosystem, the diagram lists Samsung, Huawei, Google, and other OEM’s as decive manufacturers; and Android as the only operating system. On the level of pre-installed apps the diagramm lists Play Store, OEM app stores, Chrome, OEM browsers, and other Google/OEM apps. Users can access native mobile apps through the Play Store and OEM app stores, and web content and side loaded apps via Chrome or OEM browsers.

What is at stake for consumers?

As well as accounting for the majority of internet usage in the UK – with internet users spending almost 3 hours a day on average online using a smartphone or tablet – mobile devices are also the channel through which an increasing range and volume of other products and services are accessed and consumed. Mobile devices are a platform through which millions of apps from hundreds of thousands of app developers are made available to users and also an important platform for innovation.

It is important to recognise that Apple’s and Google’s control over their respective ecosystems can give rise to a number of positive outcomes. For example:

• having an operating system, app store, and a core set of apps (as well as, for Apple, mobile devices) developed by a single provider help guarantee that products work seamlessly together, and are easy and convenient for users. Apple’s and Google’s ecosystems have each proven to be highly valued by consumers. We have received evidence that overall users’ satisfaction with both iOS and Android smartphones is high with over 9 in 10 satisfied with their device.

• Apple and Google (and others) have engaged in innovation that has improved the features, functionality and performance of their mobile devices and operating systems as well as the tools they provide to support app developers. This innovation will have benefitted users as it has made devices quicker, more powerful and increased the number of things consumers can do on their mobile devices

• we have heard from some app developers that Apple’s and Google’s stewardship of their ecosystems, in particular through app review processes and strong security features, helps to create consumer confidence and trust, which is vital for small start-ups and unknown brands. We have also heard that having 2 stable, secure, and trusted platforms helps to create the conditions that are needed to encourage investment in future innovation, and that by providing and maintaining app stores with low costs of entry for the majority of developers, Apple and Google enable new businesses to come forward that otherwise may not be viable

• we also recognise that the revenue earned from Apple’s and Google’s core services funds the provision of a large number of other valued services for free to users, including the app stores, browsers and their underlying engines, and many other first-party apps

However, the level of control exerted by Apple’s and Google’s in relation to operating systems, app stores and browsers means that it is very difficult for another ecosystem to emerge. Further, because Apple and Google control the way that browsers perform on their devices; and also set the terms for access to their app stores for native apps, they are able to limit competition from third parties in various ways within their ecosystems.

Weak competition within and between Apple’s and Google’s mobile ecosystems can affect consumers in the following ways:

• innovation: barriers to competition (particularly from third parties) risk holding back innovation in digital markets. For example, certain types of service may not be available to users (such as cloud gaming services on iOS devices), or certain developments in technology may be held up where Apple or Google do not have a clear incentive to promote these (such as web apps on iOS devices). Further, third parties investing in innovative products such as apps, services or connected devices which could complement the existing ecosystems may be discouraged from doing so, for example due to a fear of their data being used in order to further the development of Apple’s and Google’s own apps. Consumers may also lose out indirectly where, for example, the way that app stores are designed (including the ranking of apps) or terms imposed on app developers by Apple and Google, such as high rates of commission, have an impact on which apps succeed.

• the user experience: although overall satisfaction with smartphones is high there may be some ways in which users are not making informed and effective choices within mobile ecosystems. For example, the pre-installation of certain apps or setting certain apps as the ‘default’ can have significant impacts on user behaviour and give an advantage to Apple’s and Google’s own apps. The design of app stores and in particular the way in which search results are ranked can have a significant impact on which apps succeed

• privacy, security, and safety online: through design choice or other policies, Apple and Google are often in the position of acting in a quasi-regulatory capacity in relation to users’ security, privacy, and online safety. In many cases they opt to make decisions on behalf of consumers. However, it is not always clear if these numerous choices – ranging from restrictions on browser functionality to policies that affect targeted advertising – are in all cases made fully in the interests of consumers. For example, in many cases it seems decisions made on the grounds of protecting users’ security and privacy would also serve to give an advantage to first-party apps, or otherwise limit consumer choice

• prices: both Apple and Google are consistently making substantial profits with high margins, meaning that their prices go well beyond recovering the costs of providing these goods and services. In particular, Apple’s device sales, as well as for app distribution and search advertising revenue for both firms, are all highly profitable. We can infer from this that the prices charged for Apple’s devices, Google’s search advertising fees and each firms’ app store commissions, are likely to be above a competitive rate in each case. These high prices will in most cases ultimately be borne, directly or indirectly, by consumers

An important challenge within this market study is to consider the extent to which potential consumer harms are sufficiently justified by the possible benefits identified by Apple and Google regarding their positions and practices.

Some parties argue in particular that opening up ecosystems to greater competition and choice may mean less convenience for users, or create risks for security and privacy protections. These considerations are considered further in this report and will continue to be a key focus in the second half of our study.

Finally, some of Apple’s and Google’s practices and restrictions on third parties may also form part of the way in which Apple and Google compete with each other to attract and retain customers for their mobile ecosystems. We have taken this into account as part of our assessment, where relevant.

Apple’s and Google’s business models and incentives

As illustrated by Figure 2, Apple and Google have different business models, each with their own key sources of revenue. This affects their incentives and the way that they have developed their mobile ecosystems over time.

Figure 2: breakdown of Apple’s and Google’s 2020 global revenue

Figure description: A chart showing key sources of revenue for Apple and Google in 2020. For Apple the breakdown is: Devices the majority of its revenue, second highest source are other services, third is the App Store, fourth advertising (search), fifth advertising (other). For Google the highest source of revenue is advertising (search), followed by advertising (other), third highest revenue source is Play Store the fourth other services.

Source: CMA analysis based on data submitted by Apple and Google. Note: There are some limitations to this data that we will seek to address for our final report: in particular the chart does not include revenue for Google’s mobile device sales and the Apple devices total excludes wearables. In each case we anticipate including the omitted data will make a small change to the overall picture.

Apple has made the vast majority of its mobile device revenues from sales of comparatively more expensive mobile devices. Through its vertically integrated model, it operates tight control over the hardware and software that run on those devices, in order to achieve security, interoperability and ease of use within its mobile ecosystem. Apple argues that its integrated model gives its products a distinctive ‘look and feel’ and that quality, security, privacy and integrity of user experience that they provided as a result of their vertically integrated offering attracts consumers to their devices.

Apple’s primary source of revenue comes from selling hardware and its associated operating systems (the iPhone and iOS) – in 2020 around 80% of Apple’s worldwide revenue came from its hardware, with around 50% coming from the iPhone alone. This means that Apple is likely to have an incentive to: (i) invest in new or enhanced features, services, and connected devices over time to maintain loyal customers, and also to encourage periodic replacement of older devices; and (ii) add friction to the process of switching away from Apple, as it does not earn any revenue from users of devices from other manufacturers.

Between 2016 and 2020, ^{[footnote 7]} Apple’s revenue growth has mainly been driven by ‘services’ (that is, income that is driven from content or applications that run on a mobile device) and from the operation of its App Store in particular. In order to pursue this growth strategy, Apple’s incentive is to encourage the download of native apps which offer paid content through its App Store as the primary way for users to access content on iOS devices, given the commission it receives from certain in-app purchases. This could be to the detriment of the development of browsers and web apps on iOS devices and native apps which are free to the user (although in some cases funded through advertising). Apple is also able to pursue policies which given an advantage to its own revenue-generating apps (such as Apple Music) over those of rivals, or otherwise block access to or increase development costs for third parties on its platform.

By contrast, Google is predominantly an advertising business. The majority of Google’s UK revenues are generated from search advertising, which totalled £6.8 billion in 2019 in the UK. Google therefore has a strong incentive to invest in products and services, such as its operating system and browser and to ensure that these are as widely adopted as possible, in order to generate traffic for its search engine and its other services that earn advertising revenues, including YouTube. This strategy has been successful to date, with more time spent on Google sites each day (52 minutes) by UK internet users than on any others.^{[footnote 8]} Through the provision of these services, it is also able to take an active role in maintaining and promoting common standards across the open web.

While the Android operating system is available on an open-source basis, most manufacturers use a ‘Google compatible’ version of Android (referred to in this report as ‘Android’),^{[footnote 9]} for which they are also able to licence key apps and services from Google. We consider Google’s agreements with device manufacturers seek to ensure that key Google apps are pre-installed prominently, such as its browser (Chrome) and its app store (the Play Store), and that Google Search is the default search engine at various search access points.

Like Apple, Google earns substantial revenue from its app store, which has seen rapid growth. Google appears to be moving towards tighter rules around the Play Store in certain respects, which are more closely aligned to those of Apple, in order to drive greater revenues in this aspect of its business (particularly around the use of its own payment system for in-app purchases, through which it also collects a commission ^{[footnote 10]}. As a result of its operation of the Play Store, Google controls the main method of offering native apps across the vast majority of Android devices and, as for Apple above, there is a risk that Google could give an advantage to its own apps and services or otherwise block access to or increase development costs for third parties on its platform.

Both firms are highly profitable

Despite the differences in their business models, both Apple and Google earn substantial profits from their mobile ecosystems, with very high margins, and high returns on capital employed.

On a global basis, Apple made $67.1 billion in profit in 2020, and recent disclosures indicate that this grew to $109.2 billion in 2021.^{[footnote 11]} We have estimated that in recent years, Apple’s return on capital employed has been over 100% – a high figure in any sector.

Google made $48.1 billion in profit globally in 2020.^{[footnote 12]} Based on analysis from the CMA’s market study into online platforms and digital advertising,^{[footnote 13]} we have estimated that the return on capital employed for the Alphabet Group (Google’s parent company) was 39% on average between 2011 and 2019. That previous study concluded that this figure had been well above any reasonable competitive benchmark for many years.

Gross margins represent the amount of money that companies retain after incurring the direct costs of providing the goods and services. Figure 3 illustrates the relative gross margins that Apple and Google earned from their main sources of revenue in 2020, indicating the strong performance of the app stores and search advertising for both firms.

Figure 3: gross margins by main sources of global revenue in 2020

Figure description: Gross margins for both Apple and Google by source of revenue. Apple’s highest margins are from advertising (search), closely followed by both advertising (other) and App Store, lastly lower margins are achieved with devices. Google’s margins are all lower than Apples. Google’s highest margins are achieved with advertising (search) closely followed by the Play Store, advertising (others) appears approximatly a third of the size of the other margins, no gross margins are shown for devices.

Source: CMA analysis of data submitted by Apple and Google. Note: Apple earns revenue from search advertising through a revenue share agreement with Google. Also, to note there are some limitations to this data that we will seek to address for our final report: in particular the chart does not include data for Google’s device sales.

The context of this market study

As set out in the statement of scope published at the launch of this study, following recommendations made by the CMA in our earlier market study into online platforms and digital advertising, and through the Digital Markets Taskforce,^{[footnote 14]} the government has indicated that it intends to establish a new, pro-competition regulatory regime to address concerns relating to digital platforms with ‘strategic market status’ (SMS). A Digital Markets Unit (DMU) has been established within the CMA on a non-statutory basis to begin work to operationalise the new regime, and the government intends to introduce legislation to put the regime on a statutory basis when legislative time permits. The government recently consulted on proposals to bring this new regime into force,^{[footnote 15]} which would result in firms assigned with SMS by the DMU facing enforceable codes of conduct, and potential pro-competitive interventions to address the sources of their market power.

The CMA expects that this market study will contribute towards the establishment of the new pro-competition regulatory regime, in particular by helping to inform the assessment of whether Apple or Google should be designated with SMS in relation to any of the activities captured by the scope of this study. This study also provides an opportunity to consider how, were Apple and Google to be so designated, key elements of the regulatory regime (as currently proposed) – in particular codes of conduct and pro-competitive interventions – might be used to address the potential harms to competition and consumers identified. Our preliminary views on these issues are set out further below.

As also noted in the statement of scope, in parallel to our work to develop the new regulatory regime, the CMA is also making use of our existing powers to the fullest extent possible to address concerns in digital markets. We have also launched 2 competition law enforcement cases, in connection with the prohibitions in the Competition Act 1998, which are related to important aspects of this market study. The first is an investigation into Apple’s App Store, in which the CMA is investigating Apple’s conduct in relation to the distribution of apps on iOS and iPadOS devices in the UK, in particular, the terms and conditions governing app developers’ access to Apple’s App Store.^{[footnote 16]} The second is an investigation into Google’s ‘Privacy Sandbox’ browser changes, in which the CMA is investigating Google’s proposals to remove third-party cookies and other functionalities from its Chrome browser.^{[footnote 17]} The CMA has recently published a notice of intention to accept modified commitments offered by Google and launched a consultation on these modified commitments.^{[footnote 18]}

Our competition enforcement cases focus on specific suspected breaches of competition law, while our market study is seeking to provide a broader, overarching view of these interconnected markets.

We are also aware that other competition authorities and government bodies around the world are looking at similar issues to those we are considering in this study, or have previously carried out work in this area. For example, the European Commission is investigating whether Apple has breached competition law in relation to its distribution of apps,^{[footnote 19]} having previously fined Google for imposing anticompetitive restrictions on Android device manufacturers and mobile network operators.^{[footnote 20]} In addition, a number of private enforcement cases have been brought in the USA, UK and other jurisdictions, relating (among other issues) to Apple’s and Google’s management of their respective app stores.^{[footnote 21]} Several other agencies are carrying out similar sectoral studies of mobile platforms, while new forms of regulation – including the sort of ex ante rules being considered in the context of the DMU – are also under consideration in a number of jurisdictions around the world, for example as part of the Open App Markets Bill in the United States and the proposed Digital Markets Act in the EU. In South Korea, legislation has recently been introduced which, among other things, prohibits Apple and Google from mandating the use of their in-app payment systems for in-app purchases of digital content.

Further action by other authorities could potentially result in changes that would affect market conditions in the UK. We continue to monitor the work carried out in other jurisdictions and, in turn, aim to contribute to the global debate on how to tackle the problems associated with digital platforms with substantial market power. This reflects our belief that the most effective way to promote competition in these markets will be through action that is internationally coherent, by achieving a common understanding of the problems and broad agreement over the way to tackle them.

Summary of competition concerns

As noted in our statement of scope, the CMA has structured its work according to the following 4 themes:

• theme 1: competition in the supply of mobile devices and operating systems
• theme 2: competition in the distribution of mobile apps
• theme 3: competition in the supply of mobile browsers and browser engines
• theme 4: the role of Apple and Google in competition between app developers

The initial findings of this market study are set out by theme below. Within these themes, we also explore the links that exist between Apple’s and Google’s different activities across their ecosystems.

Theme 1: competition in the supply of mobile devices and operating systems

Under Theme 1, we have been considering the extent to which there is competition in the supply of mobile devices and operating systems. This has included considering (among other issues) the extent of price competition, whether there may be natural barriers to entry and expansion in the supply of mobile operating systems such as network effects and economies of scale and whether there are barriers to switching that ‘lock’ consumers into a certain mobile ecosystem. In doing this we have also considered how Apple and Google may have contributed to any barriers to entry or barriers to switching.

Consumers enter Apple’s or Google’s mobile ecosystems the first time they purchase a mobile device that uses the iOS or Android operating system. Apple and Google have an effective duopoly in the provision of operating systems that run on mobile devices, with similar shares of supply in the UK. In particular:

• Apple is the largest player in the supply of both mobile devices and operating systems with a share of [50% to 60%] of active smartphones as well as [50% to 60%] of active tablets in the UK in 2020 ^{[footnote 22]}

• in contrast, Google has a small presence in mobile devices with most Android devices being manufactured by third parties. Google’s Android is the second largest mobile operating system, with Android devices accounting for [40% to 50%] of all active smartphones and [20% to 30%] of active tablets in the UK in 2020

We have found that there is limited user-driven competition because most users purchasing a device are buying a replacement device and rarely switch between operating systems. Also, there appears to be limited price competition between iOS and Android devices and each effectively has its own segment of the market, with iOS dominating sales of high-priced devices and Android dominating sales of low-priced devices.

The evidence indicates that there are material barriers to switching between devices using the iOS and Android operating systems. The barriers include challenges that users may face when seeking to transfer data, apps and manage subscriptions when they switch devices, which stem in part from requirements to use Apple’s and Google’s in-app payment systems. The characteristics and Apple’s first-party apps, services and connected devices pose a further barrier to switching, due to their incompatibility, or limited compatibility, with devices built by other manufacturers. Barriers to switching are thus asymmetric, affecting users of Android and iOS but falling more heavily on iOS users. Overall, these factors mean that Apple and Google do not appear to be competing strongly with each other for users for their respective operating systems.

In addition, Apple and Google both benefit from material barriers to entry and expansion faced by rival providers of operating systems.

• there are significant indirect network effects – the benefit to users of an operating system increases with the volume and quality of content and apps they can access through that operating system and similarly the benefit to content providers/app developers increases with the number of users they can access through an operating system. This means it is difficult for a new operating system to gain traction as they cannot attract one set of customers without the other

• Google has various agreements with device manufacturers. These include agreements under which Google agrees to share a percentage of its search advertising revenue with the device manufacturer (typically in return for use of a Google compatible version of Android and setting Google Search as the default search engine at various points on their devices) and, in some cases, a percentage of its revenue from Play Store transactions for meeting additional requirements in relation to the Play Store.^{[footnote 23]} It is very difficult for rivals seeking to attract manufacturers to their competing operating systems to replicate these arrangements

• the barriers to users switching away from their current mobile ecosystems would substantially limit the chances of a new entrant. These barriers are greatest for Apple users, accounting, for [50% to 60%] of active smartphone users and [50% to 60%] of active tablets, in part due commercial decisions made by Apple

Given these barriers to entry and the fact that Android is the only licensable mobile operating system in the UK (and is the only large licensable operating system we are aware of internationally),^{[footnote 24]} manufacturers have no credible alternative option but to use the Android operating system. Given this, Apple and Google face limited competitive constraints from providers of alternative operating systems for mobile devices.

Theme 2: competition in the distribution of mobile apps

Under Theme 2, we have examined the extent to which Apple and Google, as owners of the main app stores in their respective ecosystems, have market power in the distribution of native apps. This includes the extent to which there are suitable alternatives to the main app stores through which consumers can download and app developers can distribute native apps, as well as alternative methods through which a user can access the same content (for example, web-based alternatives and alternative devices such as games consoles).

The App Store on iOS and Play Store on Android are the key gateways through which app developers can distribute apps to users on mobile devices. Our initial findings are that the App Store and Play Store face a lack of competition from within and outside of their respective ecosystems as a method of delivering native apps to users:

• in Apple’s ecosystem, the App Store is the only method of native app distribution and so 100% of native apps downloaded on iOS devices are through the App Store

• on Android devices,^{[footnote 25]} [90% to 100%] of native apps are downloaded from the Play Store. Although alternative app download methods ^{[footnote 26]} do exist on Android, these are not viable or popular alternatives to the Play Store for the majority of users or app developers. Alternative app stores can be pre-loaded on Android devices (for example, those of the main device manufacturers^{[footnote 27]}) but face significant barriers in attracting a sufficient number of app developers and users to be successful. Further, Google’s agreements with manufacturers^{[footnote 28]} mean that the Play Store is pre-installed and prominently displayed on the vast majority all Android devices

• ‘web apps’, which in principle allow developers to offer their apps directly to users circumventing the app stores, are not currently a suitable alternative to native apps for most app developers. In particular, web apps do not currently provide the same features and functionalities as native apps. The evidence indicates that this is largely due to restrictions on the features and functionalities of web apps that result from the fact that browsers on iOS devices must use Apple’s own WebKit browser engine. The lower functionality for web apps on iOS means that developers are unlikely to be able to rely on web apps for iOS and this is likely to significantly increase development costs, as the efficiency saving from having to only develop one app (ie one web app as opposed to a native app for each operating system) is lost

• the App Store and Play Store do not represent strong competition for each other, as alternatives for users or app developers. The largest app developers are available on both app stores and see them as complements rather than substitutes due to their size and because most App Store users do not use the Play Store and vice versa. That is, they are, in effect, unavoidable trading partners for many app developers. In addition, as noted above, users rarely switch between Apple’s and Google’s operating systems when buying a replacement device

• the App Store and Play Store do not face significant competition from alternative devices, such as desktops or games consoles, largely because they are used differently to mobile devices, which can be used ‘on the go’. Therefore, non-mobile devices are not seen as a viable alternative option for mobile app developers

Apple and Google are able to exercise the market power of their app stores through their processes for reviewing which apps can be listed on their app stores. Apple and Google set the rules to be followed by app developers and have discretion over whether to approve or reject apps. This control has enabled Apple to block certain types of apps being present on iOS altogether (such as cloud gaming services) and for other types of apps, the app review process for the App Store and Play Store provides an incentive or ability for Apple and Google to confer an advantage over their own apps and services and, more widely, can mean uncertainty and increased development costs for app developers.

In addition, Apple and Google require app developers to use their payment systems for certain in-app transactions relating to digital content consumed within the app, and charge an average commission of close to 30%.^{[footnote 29]} These commissions result in Apple and Google making substantial and growing profits (with high margins) from their app stores, consistent with market power.

We have also identified certain ways in which the control of access to the App Store enables Apple to introduce policies and terms, such as App Tracking Transparency, which may operate to the detriment of ad-funded apps, and which push users towards apps which derive revenue from users having to make in-app purchases (in relation to which it is able to collect a commission). These are considered further under Theme 4. In some respects such as these, we have found that Google does not have such strict rules as Apple.

Theme 3: competition in the supply of mobile browsers and browser engines

Alongside app stores, mobile browsers are the key gateway in the mobile ecosystem between users and content providers. Mobile browsers are a type of app that enable users of mobile devices to access and search the internet and interact with content on different websites through the open web. Mobile browsers also enable users to access web apps. Native apps can also be installed directly from mobile browsers through ‘sideloading’ on Android devices. Alongside app stores, mobile browsers are one of 2 key gateways in the mobile ecosystem between users and content providers. Browser engines are responsible for key functionality in browsers as they enable browsers to load and display content on a web page.

Under Theme 3, we have examined the extent to which Apple and Google, as owners of the 2 largest browsers and browser engines on mobile devices, have market power in the supply of mobile browsers. This includes an assessment of potential barriers to entry and expansion such as the restriction within iOS on browser engine choice, the role of web standards and webpage compatibility, consumer behaviour and the role of pre-installation and default settings for browsers on mobile devices. We have also assessed whether Google’s and Apple’s positions in the supply of browsers may enable them to hold up effective competition in ways which may protect their market position across their other activities (notably, their app stores or in the case of Google, its search advertising business).

Apple’s browser, Safari (over 90%) and Google’s browser, Chrome (75%) have very strong shares of browser usage in their respective mobile ecosystems. There are just 3 browser engines: WebKit (provided by Apple); Blink (by Google); and Gecko (by Mozilla). All browsers on iOS have to use WebKit and most browsers on Android use Blink (the key exception being Firefox which uses Gecko), such that the position of both Apple and Google in browser engines is even stronger than in browsers.

We have found that by requiring all browsers on iOS devices to use its WebKit browser engine, Apple controls and sets the boundaries of the quality and functionality of all browsers on iOS. It also limits the potential for rival browsers to differentiate themselves from Safari. For example, browsers are less able to accelerate the speed of page loading and cannot display videos in formats not supported by WebKit. Further, Apple does not provide rival browsers with the access to the same functionality and APIs that are available to Safari. Overall, this means that Safari does not face effective competition from other browsers on iOS devices.

The evidence also suggests that browsers on iOS offer less feature support than browsers built on other browser engines, in particular with respect to web apps. As a result, web apps are a less viable alternative to native apps from the App Store for delivering content on iOS devices. As noted above under Theme 2, the lower functionality for web apps on iOS means that developers are unlikely to be able to rely on web apps for iOS and this is likely to significantly increase development costs, as the efficiency saving from having to only develop one app (ie one web app as opposed to a native app for each operating system) is lost.

Both Apple and Google appear to influence user behaviour in other ways that serve to cement their market power in browsers. In particular, both Apple and Google use pre-installation, default settings and choice architecture to maximise use of their own browsers within their respective ecosystems. Although Google also displays browser choice screens on Android devices, the above shares of supply demonstrate that most Android users choose Chrome in practice. In addition, where users do exercise choice over their ‘default browser’, ^{[footnote 30]} these are overridden in certain contexts, such as when a browser is launched within a particular app.

This control over browser functionality also leads to concerns about Apple and Google being able to protect or expand market power in other activities – in particular, by Apple undermining the potential competitive constraints that face its App Store as a method of distributing apps to users; and by Google distorting competition in the market for the supply of ad inventory and in the market for the supply of ad tech services.

Theme 4: the role of Apple and Google in competition between app developers

Under this theme, we have examined the ways in which Apple’s and Google’s conduct as app store providers affects competition between app developers. This has included exploring concerns that Apple or Google could be using their position as operators of app stores to:

• give an advantage to their own apps and related services compared to those of competitors, in a way that may harm competition and consumers
• distort competition between third parties
• entrench their position of control over app distribution

Apple and Google are able to use their control over their app stores, operating systems and (in Apple’s case) devices to set the ‘rules of the game’ for competition between app developers. This influence ranges from determining what features or business models app developers can implement, to shaping users’ choices about which apps to use. We have considered several ways in which this control could be harmful to competition:

• there are a number of examples of hardware and software functionality on an iPhone that Apple does not allow other app developers to access, such as the technology that enables contactless payments. This could serve to preference Apple’s products and restrict innovation. Google appears to be less restrictive, in part because, given that the vast majority of Android devices are made by other companies rather than by Google, Google cannot control access to hardware to the same extent as Apple

• app review processes can be opaque and rules can be inconsistently applied. Both Apple and Google have a wide discretion to reinterpret and change rules, and remove apps or block apps or app updates, where they consider that their rules are not being complied with. App developers have no choice but to make changes to their apps to meet Apple’s and Google’s requirements, while delays and uncertainty can add to development costs

• the pre-installation of apps and setting certain apps as defaults (which Apple and to a lesser extent Google control in their respective ecosystems) can have significant impacts on user behaviour and give an advantage to Apple’s and Google’s own apps

• the design of app stores and in particular the way in which search results are ranked can have a significant impact on which apps succeed. This creates the potential for Apple and Google to distort competition by giving an advantage in rankings to their own or certain third-party apps. It also means that changes to app store search algorithms may cause substantial disruption to app developers’ businesses, and we have heard concerns that these changes are made non-transparently and with a lack of notice

• we have also heard particular concerns about Apple using commercially sensitive data or information about app developers that is obtained through operation of its app store, either to develop new products, or to otherwise gain a competitive advantage through its access to data about the financial performance of other apps. This may be facilitated by contractual terms that weaken developers’ intellectual property rights

Overall, we consider that there are various improvements that could be made put in place regarding the operation of app stores, including safeguards to ensure that Apple and Google are not able to give a competitive advantage to their own apps.

We have also considered 3 sets of specific practices which, as well as influencing competition in app markets, may have broader competitive implications, such as protecting market power in app distribution. These are: rules around payments for in-app purchases, Apple’s ‘App Tracking Transparency’ (‘ATT’) policy, and Apple’s restrictions on cloud gaming.

Both Apple and Google have rules around purchases of digital ‘in-app’ content, which require certain app developers with ‘digital’ apps to use only Apple’s or Google’s in-app payment system to process transactions; ^{[footnote 31]} and through which Apple and Google collect a commission of up to 30% for in-app payments for digital content. The payment rules also restrict the ability of app developers to inform consumers within an app of the ability to purchase in-app content (possibly at a cheaper price) elsewhere, such as on a website (often termed ’anti-steering provisions’). Apple and Google both say that that the obligation to use their payment systems is necessary for them to collect a commission on the sales that developers make as a result of distributing apps through their app stores.^{[footnote 32]}

In addition to complaints about the level of commission payable, we have heard concerns that the use of Apple’s and Google’s payment systems makes it more difficult for users to switch devices (because they cannot manage subscriptions made through Apple or Google on their new device after they have switched to another operating system). These rules may also reinforce the market power of app stores as a way for users to discover and pay for content, as app developers cannot make any reference within an app to other payment options for accessing content on mobile devices (such as websites), which may be cheaper.

There are also concerns that in-app payment rules ‘disintermediate’ app developers from their users, because Apple and Google are the direct seller where purchases are made through their respective in app purchasing systems. The effect of this is to reduce the control that developers have over pricing and refunds, leading to complaints that app developers are less able to respond to users of their apps and worsening the consumer experience. Finally, in-app payment rules may also distort competition between apps that face these requirements and Apple’s and Google’s own apps (which are not subject to a commission).

Two further issues relate only to Apple’s rules for apps made available through its App Store. The first is Apple’s App Tracking Transparency (ATT) policy, launched in April 2021, which Apple told us is intended to empower consumers by giving them greater transparency and ability to control the sharing of their own data. The change requires app developers to show a specific prompt to request users’ permission to collect certain data, in particular identifiers used to monitor users’ activity across apps.

We are supportive in principle of market developments that promote greater control and choice for consumers in a way that is competitively neutral, and ATT has the potential to deliver some consumer benefit in the form of enhanced privacy and user agency over the way that personal data is used for personalised advertising. However, we are concerned that Apple may not be applying the same standards to itself as to third parties, and the design and implementation of the ATT prompt to users may be distorting consumer choices. Ultimately this may mean that Apple is able to entrench the position of the App Store as the main way of users discovering apps, may give an advantage to Apple’s own digital advertising services, and could drive app developers to begin charging for previously free, ad-funded apps.

Second, through its control of the App Store, Apple has been able to block the emergence of cloud gaming on the App Store, which is currently permitted on Android. Cloud gaming is a potential threat to the model of accessing native apps through app stores, since it represents an alternative method of game discovery and distribution. Apple’s policy may also protect its competitive position in mobile devices and operating systems, as cloud gaming services may reduce the importance of high-quality hardware and make it easier for users to switch between platforms.

Initial views on ‘Strategic Market Status’ (SMS)

In its July consultation on a new pro-competition regime, described above, the government proposed that firms designated with SMS would be required to follow a legally enforceable code of conduct, which would manage the effects of market power by setting out how firms with SMS are expected to behave. The codes are intended to offer clarity to both users and firms designated with SMS, aiming to influence the latter’s behaviour in advance to prevent negative outcomes before they occur.

Building on the CMA’s advice through the Digital Markets Taskforce, the government’s consultation proposed that designation of SMS should require a finding that a firm has substantial, entrenched market power in at least one digital activity, providing the firm with a strategic position. There are essentially 3 components to this assessment, which are:

• digital activities: the government has proposed that: (i) products, services and processes could be regarded as a single activity if they all can be described as having a similar function or, if in combination, can be described as fulfilling a specific function; (ii) such activities are to be considered ‘digital’ where digital technologies are a ‘core component’ of the products and services provided as part of that activity

• substantial and entrenched market power: this arises when users of a firm’s product or service lack good alternatives to that product or service, and there is a limited threat of entry or expansion by other suppliers; further, such power is entrenched where it is expected to persist over time and is unlikely to be competed away in the short or medium-term

• strategic position: a position is strategic where the effects of market power are likely to be particularly widespread or significant

Based on our assessment to date, in our view:

• Apple would meet the government’s conditions (as currently proposed in its consultation, for possible SMS designation by the DMU) for each of the main activities within its mobile ecosystem, namely its iOS operating system and the devices on which it is installed, its app store, and its browser and browser engine

• Google would meet such proposed conditions for possible SMS designation by the DMU for each of the main activities within its mobile ecosystems, namely the Google-compatible Android operating system, its app store, and its browser and browser engine

We have considered further below how the regime proposed in the government’s consultation, if implemented in that form, may apply to Apple and Google were the DMU to designate them with SMS status. First, however, we consider the potential interventions that could address the competition concerns identified in our study to date.

Initial views on potential interventions to address competition concerns

Overall, the CMA is of the preliminary view that a number of possible interventions may make positive differences to businesses that seek to offer products on Apple’s and Google’s platforms, and also to users of mobile devices.

We have given initial consideration to potential interventions that could contribute towards at least one of the following high-level objectives:

• taking action to address the sources of market power, with a view to reducing barriers to competition or otherwise opening up markets to greater competition and choice

• addressing harms to competition and consumers where market power is being exploited

At this stage, we have not reached any final views as to whether any particular interventions are warranted. Instead, we aim to assess in broad terms the relative merits of possible interventions, with a view to inviting stakeholders’ input on likely effectiveness of such interventions, in encouraging competition within and between mobile ecosystems, and if so whether the benefits to competition and choice they would deliver would outweigh any costs. For example, measures to allow greater choice within ecosystems may also create increased risks to device security or user privacy. Further, measures which reduce the extent of integration between the different products and services within mobile ecosystems could also worsen the user experience or erode consumer trust.

There may be complex trade-offs between these various considerations. We therefore encourage stakeholders responding to the consultation on this interim report to provide evidence both on the potential benefits to competition and choice they expect would result from the interventions described, and on any potential risks and costs (including how important such risks, such as risks to security or user experience, can be mitigated or managed).

Addressing the source of market power

The CMA has considered possible interventions that are directed at the ability of Apple and Google to exercise market power through measures that may increase competition or choice in operating systems, methods of app distribution on mobile devices and mobile browsers and browser engines.

First, we have considered interventions designed to allow third parties to carry out activities that are currently reserved for only Apple or Google within their ecosystems, which can harm mobile users by tying them into other services as a result of their choice of device, or certain policies or practices which mean that a substantial proportion of users are locked into Apple’s and Google’s related services. This could include measures such as:

• removing barriers for other methods of installing apps on mobile devices, which could include allowing alternative or additional app stores, or allowing sideloading, under certain conditions

• removing restrictions that are imposed by Apple and Google in relation to offering alternative payment options for in-app purchases for digital apps

• changes to policies that currently reinforce the position of app stores as the primary method of accessing content or which disadvantage apps that are monetised in ways other than through in-app payments (for example Apple’s rules relating to cloud gaming and advertising prompts

• greater choice of browser engines within mobile ecosystems; or a requirement to offer certain forms of functionality and interoperability to third-party browsers

The measures referred to above regarding browsers and browser engines may also lead to greater functionality being available for web apps and a more widespread uptake of this type of app on mobile devices. This could have the broader effect of reducing the barriers to entry for new operating systems, by breaking a link between operating systems and control over distribution of content through native apps which are accessed through Apple’s and Google’s app stores.

In allowing greater competition for these activities than currently exists, it may mean that Apple and Google need to provide additional information or functionality to third parties than they presently do. Therefore, the above measures may need to be combined with certain interoperability requirements, such as requiring that third parties are provided with the necessary APIs to be able to compete with Apple or Google’s own products or services. In particular, equitable interoperability would allow parties access on equal terms to others (including Apple’s and Google’s own products and services), effectively prohibiting self-preferencing and discrimination against third parties.^{[footnote 33]}

We acknowledge concerns that such measures could give rise to increased security or privacy risks and that mobile ecosystems play an important role in protecting consumers from such risks, for example by checking apps do not contain malware and by limiting access and use personal data. If considering the case for any such interventions, we would therefore expect to consider also what conditions might be appropriate for Apple and Google to impose on third parties to address such risks.

As an example, Apple has told us that as a result of its requirement that all browsers on iOS be based on its own browser engine, WebKit, it is more readily able to fix any privacy and security concerns that arise in a timely manner, and reduce risks for users. We will be looking to test the effectiveness of alternative mechanisms to address such concerns, and will engage with stakeholders to develop our understanding of the effectiveness of different interventions. 76. We have also considered demand-side interventions that are focussed on making it easier for users to switch between devices that come with different operating systems. These measures are aimed at ensuring that many of the key features of mobile ecosystems that users value (for example data, apps, app content and subscriptions) can be easily transferred to and accessed on an alternative device.

Another possible barrier to competition in relation to mobile operating systems relates to the impact of Google’s placement and revenue sharing agreements associated with key products such as Chrome, Google Search and the Play Store. These agreements are conditional on manufacturers using a compatible version of Android and licensing a number of popular Google apps including the Play Store, Google Maps, YouTube, and Gmail as well as Google APIs or Google Play Services and, under a separate licence, Google Search and Chrome apps. These arrangements can harm the ability of suppliers of versions of Android that do not use Google’s products (such as ‘forked’ versions of Android) to attract device manufacturers, as other manufacturers are unlikely to be able to replicate the payments Google makes under these arrangements. We have therefore considered interventions which could involve ensuring that core features or functionalities are available within the open-source version of Android.

However, we are mindful that Google has previously invested significantly in the development of Android and continues to incur significant ongoing expenses associated with this operating system. Sharing the benefits of these investments with Google’s rivals could dampen Google’s incentive to invest and innovate in its platform. Further Google has told the CMA that there is a material risk that its apps would not run properly on such devices and that this would harm its reputation. We are therefore seeking to understand the impact of such interventions, and whether technical and compatibility issues could be overcome.

We also consider interventions which aim to make it easier for users to choose alternatives to Apple and Google, where such choice already exists within their mobile ecosystems. Currently Apple’s and Google’s ecosystems are heavily integrated and, even where there is in theory a choice, the large majority of users use the products that are typically pre-installed, prominently placed, and often set as a default on their device, including Apple’s and Google’s own browsers and Google’s Play Store. The design of choice architecture^{[footnote 34]} and the approach to determining defaults is another key consideration of our study as we have found that this design can heavily influence consumer decision-making within mobile ecosystems, both in choice of apps and in other preferences, including the choices offered by Apple’s ATT prompt. We are therefore considering a range of potential interventions to prevent Apple and Google from benefiting unduly from these biases, which could include prompting consumers to make an active choice in setting a default for a key product and making it easier to exercise or alter such choices.

These interventions may be less likely to result in the kind of privacy or security risks associated with interoperability. However, to the extent that these markets will nevertheless remain heavily influenced by the power of defaults, a requirement to introduce alternative forms of choice architecture may on its own have a more limited effect on consumer behaviour. In addition whilst some forms of intervention on choice architecture can deliver benefits for users, such as making it easier for those users who wish to exercise choice, too many choice screens can also introduce burdens on consumers or ‘decision fatigue’ which will also affect the effectiveness of the intervention.

For this reason, some parties have called for direct interventions restricting the pre-installation of certain products as the default on mobile devices. Such measures would also require redesigning choice architecture to allow users to make a choice in the absence of a default or pre-installation. There may be a fine balance to be struck in ensuring that a choice screen for browsers is designed in a way – and presented at an appropriate frequency – to ensure the competition benefits outweigh the cost of introducing the mechanisms, and the possible frictions and burdens to users from being faced with choice screens too often. As part of responses to our consultation, we would welcome views on the proportionality of such measures.

Remedies aimed at addressing harms to competition and consumers where market power is being exploited

We have also given preliminary consideration to the merits of particular interventions which could protect against the effects of Apple’s and Google’s market power, in particular in relation to themes 3 and 4 above. This could include a range of interventions which are targeted at specific forms of conduct, such as:

• requiring Apple and Google not to restrict unreasonably third-party access to hardware and software that is necessary to compete more equitably in browsers or app development. This would include through the design of Apple’s browser engine

• requirements for Apple and Google to carry out a fair and transparent app review process

• a requirement for Apple and Google to provide more transparency about their algorithms for ranking apps and in particular the factors that influence how apps are displayed on the app store. This may include a requirement to give reasonable notice of any material changes to the working of the algorithm, if that is likely to affect positioning of apps and therefore demand for app developers’ services

• restrictions on Apple and Google sharing and using data or insights gained from the operation of their app stores or app review process in developing their own apps

• a requirement for Apple and Google to allow alternative in-app payment options to be displayed alongside their own payment services within apps. This may necessitate Apple and Google finding other, potentially less restrictive, ways of charging a commission for the use of their app stores

• a requirement that Apple and Google should remove from their rules the ‘anti-steering’ provisions that prevent developers from notifying users of alternative off-app payment options, and which further restrict app developers from offering a choice of payment systems to users

• a requirement for the consistent treatment of own apps and third-party apps for privacy purposes

• requiring an amendment to Apple’s policy on cloud gaming apps on iOS devices, so that cloud gaming service providers could offer apps which allowed users to stream multiple different games without these games each needing a separate listing on the App Store

What links these points is an objective of addressing the ability of Apple and Google to use their role in setting the ‘rules of the game’ for competition between app developers in a way which acts in their own interests or creates uncertainty or increases development costs for app developers.

We will assess these potential interventions in the second half of our study, including in particular a targeted assessment of arguments from Apple and Google as to why particular restrictions or rules for third-party apps are justified. As noted above, both Apple and Google have referred to privacy and security risks associated with allowing additional interoperability to the device, for example that allowing third parties access to the same APIs as first-party apps might give them access to personal data, or that allowing interoperability with aspects of hardware could cause risks to the user’s security. We welcome views and evidence on the benefits and costs of such interventions, whether the concerns raised by Apple and Google can be addressed as part of any interventions, and if so whether the costs of doing so would be proportionate to the benefits. 85. Given the broad spectrum of products and services within mobile ecosystems, we have also considered the role of separation remedies, as such interventions could help to prevent certain conflicts emerging and the leveraging of a market position from one area of market strength into a related activity.

In particular, we have considered the potential role for forms of separation in respect of Apple’s and Google’s own app development businesses, which compete actively with other app developers that rely on the mobile ecosystems. Options to implement this form of separation could include either data separation, specifically between data received through app store and app review processes and the teams responsible for app development; or operational separation, which would impose additional requirements to run app development operations independently from app store and review processes, and to ensure that Apple and Google offer comparable terms to other app developers that are available to their own apps and services.

The links between the different segments of mobile ecosystems have a number of implications for potential interventions. Some interventions will be most effective when designed in combination with others – for example, enabling greater choice for some areas within mobile ecosystems may also require some form of interoperability requirement. Taken together, the objective of such a package of remedies could be to lead to sufficient potential entry to address the market power that currently exists within mobile ecosystems. In contrast, some of the interventions outlined above could potentially be regarded as alternatives. As part of our further assessment of interventions, we will whether they may need to be implemented in combination to be effective, or whether the staggering of interventions is more appropriate, for example to allow time for testing whether any particular interventions have been effective in practice.

DMU powers

As discussed above, the government has recently consulted on proposals for a pro-competition regime for digital markets, which would include requiring firms designated with SMS status to follow codes of conduct that promote ‘fair trading, open choices and trust and transparency’. Based on the assessment in this interim report, we consider the framework currently under consultation could be an effective means of implementing the interventions we have considered in relation to those digital activities – operating systems (and devices for Apple); app stores and browsers and browser engines – in which Apple and Google appear in our view to meet the proposed criteria for possible designation with SMS.

Our preliminary view is that many of the potential interventions above would be consistent with the types of measures effected through codes of conduct, like those envisaged for the DMU by the government consultation. For example, that consultation envisages that codes of conduct would enable the following types of requirements:

• to trade on fair and reasonable contractual terms
• not to apply unduly discriminatory terms, conditions or policies to certain customers
• not to unreasonably restrict how customers can use platform services
• not to influence competitive processes or outcomes in a way that unduly self-preferences a platform’s own services, or services for which the platform derives a commercial benefit, over rival services, including through use of preferential access to data
• not to bundle or tie the provision of products or services in markets where the SMS platform has market power with other services in a way which has an adverse effect on users
• not to unreasonably restrict interoperability with third-party technologies where this would have an adverse effect on users
• to hold own apps/services accountable to the same privacy standards as are being imposed on third parties
• not to unreasonably restrict APIs or hardware in a way which has an adverse effect on users

The government has also proposed that the DMU should have powers to impose pro-competitive interventions (PCIs) to open up competition to the SMS platforms. PCIs would be targeted at the sources of market power, and would work alongside the code of conduct that is intended to address the adverse effects of market power. For example, PCIs could be appropriate where Apple and Google would need to introduce new functionality to be able to interoperate with third parties and to support competition within the mobile ecosystem.

In summary, our initial view is that if the government implements the framework broadly as currently envisaged, the framework for codes of conduct and PCIs envisaged in its consultation could be effective in addressing the types of concerns associated with exploitation of market power in the markets within the scope of this study, in addition to reducing market power for particular activities over time.

Decision on whether to make a market investigation reference

Where the CMA considers that there is a case for a more detailed examination of a market (or markets) it may refer the market(s) for an in-depth market investigation.^{[footnote 35]} A market investigation seeks to determine whether features of the market(s) have an adverse effect on competition, and if so, the CMA decides what remedial action, if any, is appropriate to take using its order making powers, or recommends remedial actions for others to take.

Based on our initial findings, we believe there are reasonable grounds for suspecting that features of the following markets could be restricting or distorting competition in the UK:

• mobile operating systems, with a focus on the closed nature of Apple’s ecosystem, and on the nature of Google’s licensing agreements with device manufacturers

• app stores and app distribution, with a focus on addressing the sources of Apple’s and Google’s market power in native app distribution within their respective ecosystems

• browsers and browser engines, with a focus on Apple’s WebKit restriction and other barriers to competition such as pre-installation, default settings and choice architecture

The CMA nevertheless has a discretion whether or not to make a market investigation reference, and one of the factors taken into account when exercising this discretion is whether it is the most appropriate mechanism for assessing the issues and delivering the required outcomes. 95. We also take into account any stakeholder representations encouraging us to make a market investigation reference. Since issuing our market study notice on 15 June 2021, we have not received any such requests in response to our statement of scope or in our subsequent engagement with stakeholders.

Our current assessment is that the DMU – through a combination of the anticipated enforceable codes of conduct and pro-competitive interventions – will in principle be best placed to tackle the competition concerns identified by this market study to date. In particular, this is because the interconnected nature of the activities carried out by Apple and Google within their ecosystems is likely to necessitate a package of interventions aimed at assessing potential harms to competition from a number of different angles, which in some cases potentially requires iterative design, testing, and trialling.

On this basis, the CMA has decided not to make a market investigation reference. Notwithstanding this, the CMA will continue to keep under review the potential use of all its available tools during and following the second half of the market study, taking into account any relevant market or legislative developments that may arise. This includes the possibility of making a market investigation reference at a later point in time or taking enforcement action under our competition or consumer powers.^{[footnote 36]}

Next steps

This interim report provides an update on the progress we have made to date in this market study. It sets out our initial findings on a wide range of potential concerns within each of our 4 themes and identifies the range of potential interventions we are considering in order to address them. We welcome responses by 7 February.

In the second half of the study, we intend to gather more evidence to test and refine our thinking in relation to the competition concerns outlined above. In particular, we will be undertaking more comprehensive quantitative analysis of various market dynamics and gathering further evidence on the existence or otherwise of trade-offs between competition, security, and privacy in the context of mobile ecosystems.

We will set out conclusions and recommendations for interventions in our final report, which we will publish by 14 June 2022.

1. Introduction

Context

On 15 June 2021, the CMA launched a market study into mobile ecosystems,^{[footnote 37]} setting out its intention to gain a better understanding of a major component of the digital economy, and to gather evidence to inform an assessment of whether competition is working well for consumers and citizens in the UK.

The study was deliberately scoped broadly, both to enable us to investigate the wide range of concerns and potential issues that have been brought to our attention in these related markets; and to provide us with a holistic perspective of how each of the components of mobile ecosystems interrelate, and how differing business models in this sector can drive incentives and behaviour.

As set out in our statement of scope, the conclusions we reach in this market study will also contribute towards a broader programme of work, which includes the proposed establishment of a new pro-competition regulatory regime for digital markets, and our active competition and consumer enforcement work. This is consistent with the CMA’s Digital Markets Strategy, refreshed in February 2021,^{[footnote 38]} which emphasises that a key objective across our work in digital markets is to support the establishment of the Digital Markets Unit (DMU) within the CMA to oversee a new pro-competition regulatory regime. In establishing the DMU, we hope to deliver a step-change in the regulation and oversight of competition in digital markets and in turn drive dynamic innovation.

In July 2021, the government launched a consultation on its proposals for the new pro-competition regime, which are intended to drive greater dynamism in the UK tech sector, empower consumers, and drive growth across the economy.^{[footnote 39]} The government’s proposals build on the recommendations by the Digital Competition Expert Panel, chaired by Professor Jason Furman,^{[footnote 40]} and are informed by subsequent findings and recommendations from the CMA’s market study into online platforms and digital advertising,^{[footnote 41]} and the advice of the Digital Markets Taskforce.^{[footnote 42]}

Evidence Gathering

We have consulted a large number of parties throughout the last 6 months, which has enabled us to gather a broad range of evidence that reflects a diverse set of perspectives. This has involved a high volume of submissions from parties, in response to our statement of scope, an online questionnaire for app developers, and our formal requests for information. We are grateful to all those parties who have engaged with our work and enabled us to make substantial progress in the first half of our market study. Figure 1.1 summarises our progress to date in gathering evidence.

Figure 1.1: Overview of our evidence sources

Diagram providing an overview of CMA’s evidence sources: written responses to our Statement of Scope (53 responses, including 26 written submissions and 27 questionnaire responses.); stakeholder meetings (meetings with market participants, technical experts and commentators, app developers, industry trade bodies etc.); quantitative analysis (extensive analysis of market outcomes and financial reporting); requests for information (Requests sent to over 80 businesses operating in this sector); internal research (evidence gathering of choice architecture, default options, and app discovery mechanisms) and Third-party data (commisioned access to IDC mobile pricing data).

A summary of the responses to our statement of scope can be found in Appendix B.

The purpose of this interim report

Published half-way through our market study, the purpose of this interim report is to provide an update on our approach and our progress, to indicate the direction of travel our analysis is taking in relation both to concerns and potential interventions to address them, and to test these initial findings with stakeholders.

This interim report sets out our understanding of how the companies and markets within our scope function. We do this at a high level in Overview of mobile ecosystems, which provides an overview of mobile ecosystems in the UK and why they are so important, highlighting the key similarities and differences between the business models of Apple and Google, and setting out some descriptive statistics regarding various market outcomes.

The chapters that follow then provide a more focused and detailed description and assessment of competition within each of the major components of mobile ecosystems. In Competition in the supply of mobile devices and operating systems explains our analysis and findings regarding competition in the supply of mobile devices and operating systems, while in Competition in the distribution of native apps and in Competition in the supply of mobile browsers do the same for mobile app distribution and mobile browsers respectively. The role of Apple and Google in competition between app developers then sets out our findings on the role that Apple and Google play in competition between app developers.

Where there are elements of our work that are more complex or technical, or where our assessment is supported by a large volume of evidence, such as in relation to Google’s contractual agreements with device manufacturers and app developers,^{[footnote 43]} we have sought to provide additional detail in supporting appendices.

In Overview of potential interventions and Applying our findings to the proposed new pro-competition regime for digital markets, we discuss the ways in which the concerns we have identified could be addressed. Firstly, in Overview of potential interventions, we have set out a high-level overview of the types of interventions that we have identified, while highlighting some of the key considerations that we will examine for each in the second half of our market study. In Applying our findings to the proposed new pro-competition regime for digital markets provide our preliminary assessment of the extent to which these our concerns, and the potential remedies to them, could be adequately taken forward and addressed within the government’s proposed framework for the new pro-competition regime for digital markets referred to above.

In Our decision on a market investigation reference, we have set out and explained the reasoning for the CMA’s decision not to make a market investigation reference at the conclusion of this market study.

Finally, in Next steps, we have set out the next steps for the market study, including providing details of how to respond to our consultation on this interim report, and highlighting some areas for further work in the second half of this market study.

Consistent with our intention for this study to shine a light on these complex markets, we have attempted to reveal as much detail from our evidence and findings as possible. Through this interim report, we have surfaced a great deal of information that was not previously in the public domain. However, there has also been some information we have chosen not to publish – in some cases because the information is highly commercially sensitive, and in others because parties that provided the information to us indicated that they wished to remain anonymous for fear of repercussions in the market if their identity were revealed. There are as a result some instances where we have anonymised parties’ submissions, presented confidential numbers in ranges, or sought to make more generalised statements in order to convey the key messages while not disclosing confidential information. We indicate these instances with the use of [square brackets], and in some cases [REDACTED].

We hope that the disclosure and detailed analysis of the evidence we have obtained so far helps to take forward global debate and public understanding on these important topics, and ultimately lead to more positive outcomes for consumers.

2. Overview of mobile ecosystems

Key findings

• mobile devices, and particularly smartphones, and are the most widely used device for accessing the internet. In 2020, UK adult internet users spent an average of over 3 and a half hours a day online, of which almost 3 hours was spent on a smartphone or tablet. This is reflective of generally high levels of satisfaction amongst mobile devices users

• in the UK, consumers are in practice faced with a binary choice between 2 mobile ecosystems – either Apple’s or Google’s. This gives them both a high degree of control over the main gateways through which users access content online: the operating system; the app store; and the browser

• while there are similarities in the range of products and services that they provide, Apple and Google have different business models. This is illustrated most clearly by the contrast in their primary sources of revenue – Apple makes around 80% of its revenue from device sales, while Google makes more than 80% of its revenue from advertising

• differing sources of revenue create different incentives for each firm. As a result, Apple’s mobile ecosystem is tightly integrated and generally referred to as being a closed system, whereas Google’s is more open in some regards, including in relation to app distribution and browser competition on Android devices. In many cases, Apple justifies its closed approach on the grounds of protecting its users’ security and privacy

• both Apple and Google are highly profitable, and have been consistently so for many years, with high returns on capital employed, and high margins associated with their main revenue streams

• these issues matter to consumers: if competition within and between mobile ecosystems is not working well, this can mean consumers missing out on innovative new products and features, while more generally facing a lower quality experience and higher prices

• Apple and Google may also use market power to reinforce or strengthen their position in other activities, such as digital advertising, which can lead to higher prices for goods and services across the economy

Introduction

Mobile devices with internet connectivity such as smart phones and tablets now play a fundamental role in the lives of UK citizens, providing fast and convenient access to a wide range of products, content and services. In addition to communication, mobile devices also give us instant access, either via dedicated apps or the through open web, to the latest news, state of the art cameras, music, TV and video streaming, fitness tracking, shopping, banking, food delivery services, maps and navigation, games, and many more. They can also be connected to, with the potential to control, a wide range of other technology and devices such as smart speakers, smart watches, home security and lighting, and even vehicles. These products and services are able to work in combination with each other, in a way that strengthens the value and functionality of each, within what we refer to as mobile ecosystems.

There has been a dramatic evolution in the role and uses of mobile phones over the last 2 decades. Mobile devices, and particularly smartphones, are the most commonly owned devices by UK consumers,^{[footnote 44]} and are the most widely used device for accessing the internet.^{[footnote 45]} In 2020, UK adult internet users spent on average over 3 and a half hours a day online, with 68% of this time on smartphones, and just 18% and 13% on desktop^{[footnote 46]} and tablets respectively.^{[footnote 47]} Furthermore, mobile devices were estimated to account for more than half of UK online shopping in 2019, with total mobile expenditure predicted to more than double by 2024.^{[footnote 48]} In addition to online spending, smartphones and watches are increasingly being used for contactless payments, as a substitute for cards and cash – nearly a third of the adult population were registered to use mobile payments by the end of 2020, an increase of 7.4 million people compared to 2019.^{[footnote 49]}

As so many products and services are now accessed via a mobile device, the benefits of a highly competitive and dynamic market for mobile devices and the associated software are significant. Consequently, any developments in the competitive dynamics of these markets can have far reaching ripple effects across our economy and society. Therefore, in order to understand the extent to which these markets are working well for consumers, and to identify potential opportunities for greater competition and choice in this sector, we must examine each of the key competitive gateways through which mobile content is accessed and controlled. This is why we chose to scope our study broadly, looking at competition between – and within – mobile ecosystems.

This chapter provides a high-level overview of mobile ecosystems in the UK by setting out the following:

• a description of what we mean by mobile ecosystems, and their key components
• an explanation of the business models of Apple and Google, and how these lead to differing incentives and decisions for how to manage their ecosystems
• a summary of our analysis regarding the financial performance of Apple’s and Google’s mobile ecosystems
• an explanation of what may be at stake for consumers when competition for the activities within mobile ecosystems are not working well.

Many of the issues and concepts that we introduce in this chapter are subsequently discussed in more detail throughout the remainder of the report.

What are mobile ecosystems?

While mobile ecosystems contain a broad spectrum of hardware and software, they can be broadly characterised as comprising the following core set of products:

• mobile devices: portable electronic devices that can be held easily in the hand, including smartphones and tablets, which can connect to the internet
• mobile operating systems: the pre-installed system software powering mobile devices
• applications (or ‘apps’): pieces of computer software providing additional functionalities to the devices and mobile operating system on which they are installed

The majority of apps that users are most familiar with are what we refer to as ‘native’ apps – these are apps written to run on a specific operating system and, as such, interact directly with relevant elements of the operating systems in order to provide relevant features and functionality. Web apps, which can be regarded as an alternative to native apps, are applications built using common standards based on the open web, and are designed to operate through a web browser. Some native apps come pre-installed on devices at the point of purchase, whereas other native apps and web apps can be selected and installed by the user, as follows:

• a range of pre-installed native apps come together with a given mobile device. The most important of these apps are mobile app stores and browsers. Mobile app stores are marketplaces for mobile users to discover and download native apps on their mobile devices, while mobile browsers are apps they use to access the web. Together, they constitute the 2 major access points for content and service providers to reach consumers, and every mobile device comes with at least one of each preinstalled

• user-installed apps can be installed by consumers at any point after they have purchased and setup their mobile device. They are primarily native apps that are distributed through mobile app stores but, can in some cases be distributed through the browser, which can be used to find ‘web apps’, ^{[footnote 50]} and also to download app packages directly (so called ‘sideloading’)

Within a mobile ecosystem, there are 3 main ways that users can access online content and services: (i) through a native app that has been pre-installed onto the operating system; (ii) through a native app that is downloaded from the app store; or (iii) on the open web through a browser.

In the UK, consumers are in practice faced with a binary choice between 2 mobile ecosystems – either Apple’s or Google’s. Figure 2.1 shows the nature of this choice between Apple’s and Google’s ecosystems, and in particular illustrates the control that each firm has over the main gateways in their respective ecosystems through which users access content online.

Figure 2.1: the choice between Apple’s and Google’s mobile ecosystems

Figure description: A diagram showing the nature of the choice between Apple and Google’s mobile ecosystem and the control each firm has over the main gateways through which users access online content. The diagram lists user choices on the device manufacturer level, the operating system leve, for pre-installed apps and for user accessed content. For Apple, the diagram shows Apple as the only choice on the manufacturer level, on the operating system level there is only iOS, for preinstalled-apps there is the AppStore, Safari and other Apple apps. Users can access native mobile apps and web content. For Google’s ecosystem, the diagram lists Samsung, Huawei, Google, and other OEM’s as decive manufacturers; and Android as the only operating system. On the level of pre-installed apps the diagramm lists Play Store, OEM app stores, Chrome, OEM browsers, and other Google/OEM apps. Users can access native mobile apps through the Play Store and OEM app stores, and web content and side loaded apps via Chrome or OEM browsers.

Mobile devices

Smartphones and tablets

For the purpose of this market study, we use the term mobile devices relatively narrowly to refer to smartphones and tablets, which is consistent with the approach taken in work by regulators in other jurisdictions.^{[footnote 51]}

There are many similarities between smartphones and tablets, both in terms of the supply chain, and also the functionalities that they offer. We note that there are also some important differences in the way that these devices are used:

• smartphones have a greater reach than tablets, with 91% of households having access to a smartphone, compared with 65% having a tablet^{[footnote 52]}

• UK internet users spend a greater share of their time online using a smartphone than tablet, with almost 2 and a half hours per day on smartphones, and less than half an hour per day on tablets^{[footnote 53]}

• smartphones and tablets may often be used for slightly different purposes and at different times. Given their smaller size and more prevalent connectivity to mobile data, smartphones tend to be carried everywhere with their user, while tablets are in practice less mobile. Further, given the larger screen of tablets, they may lend themselves slightly better to watching video content for longer periods.

Given these factors, there are some areas where we have separated out our analysis of smartphones and tablets, though these instances are limited by the availability of device specific data and evidence. However, due the greater reach, use, and general importance to users, it is smartphones that are the primary focus of our study.

There are a large number of manufactures of mobile devices, though the majority of sales of new smartphones are shared between: Apple [40% to 50%], Samsung [20% to 30%], and Huawei [5% to 10%], and the majority of new tablet sales shared between Apple [30% to 40%], Amazon [20% to 30%] and Samsung [10% to 20%]. Google’s share of mobile device sales is still comparatively small, with [0% to 5%] of smartphone sales and [0% to 5%] of tablet sales in the UK in 2020.^{[footnote 54]}

Connected devices

Within this study we are also interested in the wide range of products and services that can connect to, and in many cases be controlled by, mobile devices. Examples of such connected devices include wearables, such as watches and earphones, smart speakers, home security and lighting, TVs, and vehicles.

Apple and Google hold positions in many of these downstream markets, such as in wearables (Apple Watch and FitBit); smart speakers (Apple HomePod and Google Home); and operating systems for vehicle infotainment (Apple CarPlay^{[footnote 55]} and Android Automotive OS).

As with apps and other downstream services, we are primarily interested in technologies that connect to mobile devices where they may either: serve to insulate Apple or Google from competition; or, where Apple and Google may use their gatekeeper positions to give a competitive advantage to their own apps and services in such downstream markets.

Figure 2.2 below provides a simplified illustration of how central some examples of these technologies are to our focus in this study.

Figure 2.2: devices within mobile ecosystems

Figure Description: This figure illustrates devices within mobile ecosystems in concentric circles from the inside moving out: In the center mobile devices are show as central focus of our study. Most relevant to our assessment of consumer lock in are wearables for example, watches and earphones. Relevant to our understanding of competition and trade-offs across the ecosystems are smart speakers and voice assistants, smart home technology for example lightning and security. Connected TVs and connected or autonomous vehicles inform our understanding of potential longer-term impacts of limited competition.

Mobile operating systems

Mobile operating systems are pre-installed system-level software that come with smartphones and tablets, which enable them to run programs and applications. A mobile operating system loads when the device is turned on, and just like with a desktop computer, it displays a home screen with icons for selecting and accessing a range of applications, in addition to facilitating a range of less visible uses, like the input from a keyboard and mouse, managing memory allocated to programs, and keeping time.

Mobile operating systems include features similar in purpose to desktop computer operating systems, along with other features related to mobile telephony and data connectivity. They have 2 layers within them – the primary user-facing software, and the lower-level system that operates in real-time managing the hardware.

The operating system determines and controls a range of features that are important to users of mobile devices, ranging from the appearance of the user interface, through to the speed, technical performance, and security of the device. They can also determine what kinds of software can run on top, including all applications, such as native apps or websites run in a browser.

There are 2 main mobile operating systems in the UK – Apple’s iOS and Google’s Android – each installed on roughly half of active smartphones in the UK. Apple’s operating system is tightly integrated with its devices and not available on other devices, whereas practically all other devices use a version of Android, which is available on an open source basis, subject to certain agreements between Google and device manufacturers.^{[footnote 56]}

As suppliers of the 2 main mobile operating systems in the UK, Apple and Google are able to make a number of key decisions that can have significant implications for the providers of products and services that are accessed online. For instance, they can determine (or, in Google’s case, heavily influence^{[footnote 57]}) which applications are pre-installed onto the device when it is first switched on. They can also place limits or restrictions on the channels through which software and applications can be downloaded onto the device.

App stores

An app store is an online marketplace for the buying and selling of mobile apps – they provide a platform that connects consumers with apps, and app developers with consumers. There are only a small number of app stores with a material share of app distribution:

• the App Store is operated by Apple, and is available only on its own devices. No other app stores can be accessed on Apple devices

• the Play Store is operated by Google, and is generally pre-installed on Android devices,^{[footnote 58]} in some cases alongside other app stores

• a small number of mobile device manufacturers, including Samsung, Huawei and Amazon provide access to their own proprietary app stores. They achieve only a small share of downloads on their respective devices relative to the App Store and the Play Store (around [0% to 5%] between them).^{[footnote 59]}

App stores enable consumers to search, select, purchase, install, and review millions of apps – there are around [1 to 1.5] million apps available on the App Store, and around [2.5 to 3] million apps available on the Play Store.^{[footnote 60]} In parallel they enable many hundreds of thousands of app developers to describe, distribute and promote their apps to millions of users.

Operators of app stores take steps to ensure that apps on their stores meet minimum standards including in relation to quality, security, privacy, and legal requirements. Where apps are deemed not to meet these requirements, they are prevented from being distributed through the relevant store. Apple, Google, and other operators of app stores manage this through their app store review processes.

Mobile browsers

Browsers enable users of mobile devices to access and search the internet and interact with content on different sites. Other than through the app store, web browsers are the most important way for users of mobile devices to access content and services over the internet. In addition, browsers are one of the key sources of traffic for content providers, in particular search engine providers.

Mobile devices are typically sold with one or more browsers pre-installed, typically with one set as the default for instances when a user clicks on a link within another application. For example, Apple’s iPhones and iPads come with Apple’s Safari browser pre-installed, and mobile devices using the Android operating system generally come with Google Chrome pre-installed. There are a large number of other browsers available – in a small number of cases these are pre-installed on Android devices by the individual manufacturer (for example, Samsung Internet), while others such as Firefox and Edge can be downloaded by the user from an app store.

Browsers are generally monetised through the sale of advertising on search engines, either by directing users to the browser vendor’s search engine, or alternatively, through payments from a search engine provider that pays to become the default search engine on a browser. For browsers that are not operated by a provider of a search engine, Google is set as the default on the vast majority.

A browser comprises 2 main elements:

• a browser engine, which transforms web page source code into web pages that people can see and engage with, and which is responsible for the key functionality and web compatibility of a browser, as well as for performance issues such as speed and reliability

• a branded user interface (UI), which is responsible for user-facing functionality such as synchronisation, remembering passwords and payment details, as well as the general appearance of features such as tabs and menus. The UI sits on top of the browser engine and comprises all the brands familiar to users, such as Chrome, Edge, Safari, Firefox, Samsung Internet.

• Today, there are just 3 main browser engines under active development: Apple’s WebKit, Google’s Blink, and Mozilla’s Gecko.^{[footnote 61]} Figure 2.3 illustrates the timeline for browser engine development since the late 1990s.

Figure 2.3: timeline of modern browser development

Figure description: An illustration of the development of browser engines over time. It shows the main steps of Opera’s, Apple’s, Google’s, Microsoft’s and Mozilla’s browser engines’ development. It also shows the related browsers and when the browser engine is not in active development or not used by major browsers.

Apple and Google are gatekeepers to online content

Operating systems, app stores, and browsers each act as a gateway between consumers and the businesses that want to reach them online:

• as providers of the primary mobile operating systems, Apple and Google can make decisions affecting the type of features on a user’s device that apps can access and utilise and, to varying degrees, control which apps are pre-installed on devices

• as providers of the 2 main app stores, Apple and Google effectively control the terms of access between consumers and developers of native apps. They decide which apps are allowed in their store, how apps are ranked and discovered, and the commission that will be taken from app developers’ revenues

• as providers of the 2 most widely used browsers and browser engines, Apple and Google determine the functionality and standards that will apply to providers of online content that want to reach consumers through websites and web apps via the open web

In each of these 3 cases, Apple and Google have each captured such a large proportion and volume of consumers in the UK that their ecosystems are, for practical purposes, indispensable to online businesses.

Apple and Google are each able to act as gatekeepers to roughly half of UK consumers with mobile devices, and as a result can set the terms of access for providers of online content and services, whether through native apps or websites and web apps. In Chapters 3 to 5, we assess the extent of market power that these gatekeeper positions provide each firm with, and then later in Applying our findings to the proposed new pro-competition regime for digital markets we discuss whether these positions, should, based on our preliminary assessment, result in them meeting the expected conditions for designation with Strategic Market Status (SMS) by the DMU.^{[footnote 62]}

The business models of Apple and Google

On the face of it, from a consumer perspective, there appear to be many similarities between Apple’s and Google’s mobile ecosystems. For example:

• while quality may vary between some devices, there are a set of hardware features that are common across many models of smartphone, including, for example, a camera, touchscreen, GPS, and contactless payment technology
• with regard to the software – an operating system, an app store, a browser, a mapping service, and many other apps and services come pre-installed for free with all mobile devices
• the most popular and frequently downloaded apps are generally available for download on most devices, with no major observable difference in prices, regardless of whether a consumer is accessing the App Store or the Play Store

Despite these similarities, there are a number of important differences in the structure and focus of Apple’s and Google’s businesses that affect their incentives and decision-making in a number of areas. This is shown most starkly by an analysis of their primary sources of revenue, with Apple earning most of its revenue from devices, while Google is primarily an advertising business.

Revenue and incentives

Sources of revenue

Figure 2.4 provides a breakdown of Apple’s and Google’s total revenues, based on data provided to us by the companies in response to our requests. It shows that Apple makes the vast majority of revenue from selling devices (in particular the iPhone) whereas Google makes a similarly high proportion of its revenue from digital advertising (in particular search advertising).

Figure 2.4: breakdown of Apple’s and Google’s 2020 global revenue

Figure description: A chart showing key sources of revenue for Apple and Google in 2020. For Apple the breakdown is: Devices the majority of its revenue, second highest source are other services, third is the App Store, fourth advertising (search), fifth advertising (other). For Google the highest source of revenue is advertising (search), followed by advertising (other), third highest revenue source is Play Store the fourth other services.

Source: CMA analysis based on data submitted by Apple and Google.

Note: There are some limitations to this data that we will seek to address for our final report: in particular the chart does not include revenue for Google’s mobile device sales and the Apple devices total excludes wearables. In each case we anticipate including the omitted data will make a small change to the overall picture.

The contrast in the source of their revenue means that the 2 companies inevitably face differing incentives in operating certain aspects of their ecosystems.

Our assessment of Apple’s incentives

As is shown by Figure 2.4, Apple is predominantly a seller of devices, from which it generates around 80% of its revenue, and its business relies on loyal customers that make repeat purchases. It therefore has an incentive to invest in new or enhanced features, services, and connected devices over time to maintain loyal customers, and also to encourage periodic replacement of older devices. It also appears to have a strong incentive to add friction to the process of switching away from Apple, as it has only minimal potential revenue streams from users of devices from other manufacturers.

Apple would not stand to gain from opening access to all of the products and services that complement its device hardware, for example by licensing its operating system to other manufacturers or by enabling all of its first-party apps to be used on other devices, as this could serve to improve the quality of rival devices, and possibly place downward pressure on the price of Apple’s devices. In contrast, it would appear that Apple does have a strong incentive to provide access to app developers to features and functionality within the device – such as the camera or GPS technology – as these apps then serve to improve the quality and experience of Apple’s mobile ecosystem. However, we also note that Apple itself competes in many downstream app markets, which may provide it with some conflicts of interest in this regard.

Apple earns substantial and increasing revenues from its App Store, achieving higher gross profit margins than it makes on device sales.^{[footnote 63]} Also, as it sells high-end devices towards the upper end of the price range, it is in its interests for users to access content on the mobile device in such a way that makes use of this high-spec technology. This suggests that Apple has a strong incentive to encourage its users to access online content such as games via native apps downloaded from its app store rather than on the open web through a browser.

One area of alignment between the 2 firms’ incentives is in relation to directing users of Apple devices to Google Search. As was set out in the CMA’s market study into online platforms and digital advertising, Google’s payment to Apple in 2019 constituted the substantial majority of Google’s total 2019 default payments made in relation to the UK.^{[footnote 64]}

Our assessment of Google’s incentives

Google is predominantly an advertising business, with [80% to 90%] of Google’s global mobile revenue generated through advertising in 2020. As is shown by Figure 2.4, search advertising is the largest contributor, which relies on a thriving open web with all information being ‘searchable’. Google therefore has a strong incentive to invest in products and services, such as its operating system and browser, in order to generate traffic for its search engine and its other services that earn advertising revenue, including YouTube. This strategy has been successful to date, with more time spent on Google sites each day (52 minutes) by UK internet users than on any others.^{[footnote 65]} By provision of these services, it is also able to take an active role in maintaining and promoting common standards across the open web.

Google’s incentives to prevent consumers switching between devices appear to be weaker than Apple’s. This is partly because Android is present on many different devices on the market, but also because it earns a large proportion of its search advertising revenue on Apple devices (albeit that it has to share a proportion of that revenue with Apple).

Like Apple, Google earns substantial and increasing revenue from its app store. This suggests Google’s incentives between encouraging traffic through the web or native apps are somewhat more mixed than Apple’s.

These differing incentives are the primary reasons behind Apple’s ecosystem being less ‘open’ than Google’s, and vice versa. The main differences in this regard are set out below.

Comparing access within Apple’s and Google’s mobile ecosystems

Apple’s mobile ecosystem is tightly integrated and widely referred to as being closed, or a ‘walled garden’. In contrast, Google’s approach is more open with regard to some – but not all – aspects of its ecosystem.

This is explained below in relation to different elements of Apple’s and Google’s mobile ecosystems:

• licensing of operating systems: Apple does not license iOS to other device manufacturers, nor does it allow consumers to install alternative operating systems on its devices. In contrast, Google allows device manufacturers to license the Android operating system, although this comes with a range of conditions and incentives that support use and prominence of Google’s other services

• channels for native app distribution: Apple only allows native apps to be downloaded from its own proprietary app store. By contrast, users of Android devices have greater freedom to access and download apps from other sources, including alternative app stores, as well as to download apps directly from the web

• browser engines and functionality: both companies produce their own browsers and maintain their own underlying browser engines. Both browser engines are available on an ‘open source’ basis for other browser vendors to use. On iOS, Safari is pre-installed and set as the default browser, but users can download and use other browsers and also select them as the default option, though all browsers on iOS must be built upon Apple’s WebKit engine. On Android, device manufacturers receive financial incentives from Google for pre-installing the Chrome browser. Users are able to access other browsers on Android, which are free to be built on any browser engine

• interoperability of apps and devices: the majority of Apple’s apps and services are only available on Apple devices, with the notable exception of Apple Music. We understand there are also some limitations on the extent to which its connected devices, in particular wearables, are compatible with non-Apple mobile devices. Most of Google’s apps and services are available on iOS, and its connected devices are compatible with Apple’s mobile devices

The nature and impact of these differing approaches are examined in detail in relation to operating systems, app stores, and browsers in the following 3 chapters.

Profitability of Apple’s and Google’s mobile ecosystems

Despite the differences in business models and sources of revenue highlighted above, both firms continue to be highly profitable as their strong positions with respect to their mobile ecosystems translate into substantial revenues. This section summarises some of the main findings of our analysis of the financial performance of Apple’s and Google’s ecosystems, while this analysis is set out in full in Appendix D.

Services revenue has been growing for both firms

Both companies have experienced strong revenue growth over the last decade on a global and UK basis.

In 2020, Apple had total global revenues of $274.5 billion, which has more than doubled since 2011.^{[footnote 66]} In the UK, the CMA estimates that Apple had total revenues of around £[10 to 15] billion.^{[footnote 67]}

Figure 2.5: Apple Global Revenue (Devices & Services) between 2011 and 2021^{[footnote 68]}

Figure description: This chart is an illustration of the growth in Apple’s global revenues from 2011 to 2020. The chart shows a steady increase from 2011 to 2020 and increase in total services revenue.

Source: CMA Analysis from Apple 10K data

Up until 2015, devices were driving Apple’s overall revenue growth. However, as is shown by Figure 2.5, devices revenue was then relatively stable between 2015 and 2020, with growth in total revenue primarily driven by growth in services over this period. The App Store has been a key contributor to this growth, representing [20% to 40%] of Apple’s global services revenue in 2020. We note that in 2021, devices revenue grew substantially, which we understand to be in part down to 2 new iPhone releases in the same financial year.

In 2020, Google Services – which includes all its activities relating to mobile devices – had global revenues of $168.63 billion, which grew 11% from 2019.^{[footnote 69]} Revenues generated via mobile devices represented around 70% of this total, at $110 billion. In the UK, the total revenue earned by Google was £[5 to 10] billion.

Google has seen rapid growth in the value of customers billings on apps, with Play Store revenues for 2020 at $[200 to 400] million.

Both companies are highly profitable

On a global basis, Apple made $67.1 billion in profit in 2020, and recent disclosures indicate that this grew to $109.2 billion in 2021.^{[footnote 70]} Google made $48.1 billion in profit in 2020.^{[footnote 71]}

The fact that both Apple and Google earn substantial profits does not in itself raise competition concerns. In fact, for a period of time, such profits can be seen as a sign of innovative sectors working well, as the substantial investment and risk associated with bringing forward new innovation is rightly rewarded. This dynamic provides other businesses – and importantly their investors – with the required incentives to take such risks of their own.

However, we have seen that Apple’s and Google’s profitability has been sustained, and growing, for over a decade or more. Further, our analysis reveals that in addition to profits being high in absolute terms, they are also achieving very high margins and returns on capital employed. For example, we have estimated that in recent years, Apple’s return on capital employed has been over 100% – a high figure in any sector.

Based on analysis from the CMA’s market study into online platforms and digital advertising, we estimated that the return on capital employed for the Alphabet Group (Google’s parent company) was 39% on average between 2011 and 2019. The market study into online platforms and digital advertising concluded that this figure had been well above any reasonable competitive benchmark for many years.

Gross margins represent the amount of money that companies retain after incurring the direct costs of providing the goods and services. Figure 2.6 provides an illustration in relative terms of the margins that Apple and Google each earned from some of their main sources of revenue in 2020.

Figure 2.6: gross margins by main sources of global revenue in 2020

Figure description: Gross margins for both Apple and Google by source of revenue. Apple’s highest margins are from advertising (search), closely followed by both advertising (other) and App Store, lastly lower margins are achieved with devices. Google’s margins are all lower than Apples. Google’s highest margins are achieved with advertising (search) closely followed by the Play Store, advertising (others) appears approximatly a third of the size of the other margins, no gross margins are shown for devices.

Source: CMA analysis of data submitted by Apple and Google.

Note: Apple earns revenue from search advertising through a revenue share agreement with Google. Also, to note there are some limitations to this data that we will seek to address for our final report: in particular the chart does not include data for Google’s device sales.

We recognise that, in an ecosystem, the profits earned on one product or service should not be considered wholly in isolation from the other products and services within the same ecosystem. Nevertheless, we consider information on gross margins to be informative of the performance of different business activities, which could feed into each firm’s incentives.

What is at stake for consumers?

It is important to recognise the important role that mobile devices play in the lives of the majority of UK citizens, and that generally consumer satisfaction levels are very high. For example, we have received evidence that overall users’ satisfaction with both iOS and Android smartphones is high with over 9 in 10 satisfied with their device. This is in part due to substantial investment by Apple and Google over the years in bringing forward regular new features and updates to their products and services. This, in turn has been complemented by the wide range of innovative and complementary products and services from third parties within Apple’s and Google’s mobile ecosystems.

It is the very fact that mobile devices play such a key role in our lives that demonstrates why it is so important that these markets are working well and in the interests of consumers. While high satisfaction levels are a useful indicator of consumer experiences, we are also mindful that many of the potential harms from weak competition in technology markets may not be visible to consumers, particularly where they relate to missing out on new products and service that never make it to market.

In this section, we consider the different ways in which the competitive dynamics within and between mobile ecosystems can impact consumers, including in relation to:

• innovation
• prices
• user experience
• privacy, security, and safety online

In some areas, it has been put to us that the control that Apple and Google have over their respective ecosystems also delivers some important benefits to particular parts or participants of the ecosystems, which could be diminished if substantial changes were made. We are therefore mindful of potential trade-offs and unintended consequences as we consider the case for any intervention in these markets. We highlight some of these potential benefits and trade-offs in each of the sections below.

Innovation

Innovation in digital markets is key to unlocking new products and services that can radically transform the way we live our lives. Apple’s iPhone, first released in 2007, and Google’s search engine, launched in 1998, are perfect illustrations of this concept, as they have since inspired and evolved into each firms’ mobile ecosystems that are used globally by billions of people.

However, a lack of effective competition between Apple’s and Google’s mobile ecosystems (or the level of control exerted by Apple and Google within these ecosystems) can be expected to have a stifling effect on this kind of innovation, which could be seen in several ways:

• limited incentives for innovation from Apple and Google: while each firm has invested in regular updates and improvements to their products and services over time, it is unclear if this surpasses a baseline level of innovation that could be expected due to general external advancements in technology over this period

• holding back disruptive business models: the incentives for start-ups to invest and innovate will be dampened if Apple and Google demonstrate an ability and willingness to obstruct the development of disruptive business models that threaten to challenge their position. For example, it appears that decisions taken by Apple are currently holding up 2 new services that could challenge its business model – web apps (discussed in Competition in the supply of mobile browsers) and cloud gaming services (discussed in The role of Apple and Google in competition between app developers)

• threat of having innovations copied: many developers are concerned that Apple and Google have the ability and incentive to exploit their access to commercially sensitive information from their app stores in order to enter and advantage themselves in new markets. This expectation could discourage investment in new products and services that complement the existing ecosystems. For example, as set out in The role of Apple and Google in competition between app developers, we have heard some concerns from app developers that Apple has used their commercially sensitive information to develop competing products.

By contrast, we have also heard from some stakeholders that having the 2 stable, secure, and trusted ecosystems helps to create the conditions that are needed to encourage investment in future innovation. Further, by providing and maintaining app stores with low costs of entry for the majority of developers, they enable new businesses to come forward that otherwise may not be viable, and through stewardship of their ecosystems, in particular through app review processes and strong security features, Apple and Google can help to create consumer confidence and trust, which is vital for small start-ups and unknown brands.

Prices

The findings of our analysis of Apple’s and Google’s financial performance (as presented in Appendix D)) illustrate that both companies have consistently been highly profitable.

This is the case for Apple in the sale of devices, operation of its app store, and also indirectly from search advertising. For Google, this is the case with its app store, and from its digital advertising services.

In addition to our findings on competition that are set out in this report, our analysis of the 2 firms’ financial performance is consistent with the following outcomes:

• Apple is likely to be charging above a competitive price for its mobile devices – a cost that is borne directly by consumers. This appears to be consistent with our analysis of prices in Competition in the supply of mobile devices and operating systems, which shows Apple’s devices are generally sold at higher price brackets than the majority of Android device sales

• both companies are likely to be charging above a competitive rate of commission to app developers, which will ultimately mean users paying higher prices for subscriptions and in-app purchases such as within games. There are well publicised concerns from a number of app developers regarding the level of commission charged for certain types of in-app payments and subscriptions

• Google is able to achieve above a competitive rate for digital advertising, in particular search advertising, which will be passed through to consumers in the prices of goods and services across the economy. Apple takes a substantial share of this profit. In its market study into online platforms and digital advertising, the CMA found that Google had significant market power in search advertising, and that on a like-for-like basis, its prices for search advertising on mobile were 30 to 40% higher than those of its closest rival, Bing. As outlined above, a primary driver behind Google’s investment in mobile services is to direct traffic to its search engine, which serves to protect these revenues

We recognise that the revenue earned in these areas cross-subsidises the provision of a large number of other valued services for free to users, including the app stores, browsers and their underlying engines, and many other apps. However, even where the costs of providing these other services are taken into account, the profits earned by Apple and Google are still notably high.

The user experience

Mobile devices are highly valued by consumers, and in most cases satisfaction levels are high. However, this does not mean that the market is working perfectly for consumers, and we can expect the quality of users’ experiences within their chosen mobile ecosystem to be negatively affected by a lack of competitive constraint to Apple and Google.

There are various avenues for this harm to materialise. In many cases consumers will be unaware of the additional or alternative services they might be missing out on, or of the greater range of choices they could make. In other cases, they might attribute poor experiences online to app developers or content providers, when in fact they were a result of decisions made by Apple or Google.

In some circumstances, Apple’s and Google’s control over their ecosystems can lead directly to lower quality experiences for consumers. For example:

• as discussed in The role of Apple and Google in competition between app developers, through their requirements regarding in-app payments, Apple and Google prevent users from having a direct customer relationship with the provider of certain types of app, negatively affecting processes such as refunds and complaints

• as discussed in Chapters 3 and 4, opacity and friction in the process for switching between ecosystems can create hassle for consumers, limit and distort consumers’ choices, and potentially result in the devaluing of connected devices that are not compatible with other platforms. For example, in practice when users switch ecosystems, they would need to cancel any subscriptions they have with apps, and then re-subscribe on the new device

• consumers can be expected to lose out where they are not able to exercise meaningful and informed choice or control over issues that matter to them. There are a number of elements of Apple’s and Google’s mobile ecosystems where it appears that user choices are limited, potentially misleading, designed and presented in an unbalanced manner, or ultimately not respected. For instance, as discussed in Competition in the supply of mobile browsers, users can choose between alternative browsers on Apple devices, but in practice the underlying technology that drives performance and determines the key functionality is the same as that at of Apple’s Safari. This situation – which is not replicated on Android, nor on desktop browsers – gives users the impression of greater choice than is made available in practice. We also understand that in many instances on iOS and Android devices, users’ choices over the default browser are not respected.

Apple’s and Google’s control over their ecosystems could also harm competition for apps, for example due to self-preferencing practices towards Apple’s and Google’s own services, or other practices which create uncertainty or raise development costs for app developers. These impacts could be felt by consumers indirectly in the quality or availability of apps.

Security, privacy and safety online

Greater competition can generally be expected to result in Apple and Google taking decisions that are more in the interests of consumers over the longer term. However, there are several wider and related indicators of the quality of mobile ecosystems that are not necessarily in all cases directly related to the level of competition within the market.

Through the design choices that they make, through their individual practices, and through the rules and restrictions that they place on other market participants, Apple and Google are often in the position of acting in a quasi-regulatory capacity in relation to users’ security, privacy, and online safety. In many cases they opt to make decisions on behalf of consumers, in order to protect them from bad actors or harmful consequences online.

However, it is not always clear if these numerous choices are made fully in the interests of consumers in all cases, for example where users’ security and privacy are the justification for decisions that also serve to harm competition or limit consumer choice. This was one of the CMA’s concerns when it opened its case into Google’s Privacy Sandbox Proposals in January 2021.^{[footnote 72]} It is also the reason why we have examined in some detail in this interim report some policies and restrictions implemented by Apple, including its restriction on alternative browser engines on iOS and also in relation to its App Tracking Transparency (ATT) framework.^{[footnote 73]}

For many of the remedies being considered by this market study, in particular those intended to open up markets or give consumers greater choice, we will need to consider the potential trade-offs between allowing greater competition and choice within mobile ecosystems and consumer security, privacy, and online safety. While the evidence we have seen to date on such trade-offs has been limited and slightly mixed, we have yet to see compelling objective evidence that there are material differences in outcomes between Apple’s and Google’s ecosystems regarding user security.

Summary

An absence of effective competition to or between Apple’s and Google’s ecosystems could be expected to harm consumers in a number of ways. This harm to consumer welfare could derive from a wide range of sources, including in particular the holding back of innovative new services and restricting consumer choice, through to degrading user experience and the potential for high prices.

In the chapters that follow, we will discuss in greater detail the specific concerns we have in relation to mobile devices and operating systems, native app distribution, and browsers. An important challenge for this market study to address will be assessing the extent to which any of these concerns and potential consumer harms are sufficiently justified by the possible benefits and trade-offs identified by Apple and Google, in particular in relation to security and privacy. This will continue to be a key focus in the second half of our study. 

3. Competition in the supply of mobile devices and operating systems

Key findings

• Just over half of all mobile devices in the UK are made by Apple and come with its iOS operating system, while practically all other smartphones and many tablets come with Google’s Android operating system. This effective duopoly and the limited competitive constraints that are considered in this chapter mean that Apple and Google have substantial and entrenched market power in the provision of mobile operating systems that run on mobile devices. For Apple, we consider its position for operating systems and devices together, given Apple’s vertically integrated model.

• Apple and Google face limited user-driven competition from each other because most users purchasing a device are buying a replacement, and those existing iOS or Android users rarely switch to the rival operating system – this is in part due to material barriers to switching we have identified. These switching costs are asymmetric, with iOS users generally facing higher switching costs than Android users.

• There is limited price competition between iOS and Android devices and each appears to have developed its own segment of the market, with Apple’s iOS devices dominating sales of high-priced devices and devices using Android dominating sales of low-priced devices.

• Apple and Google both benefit from significant barriers to entry and expansion faced by rival providers of operating systems. This is reflected in the exit or failed entry of certain well-resourced companies in smartphones such as Microsoft and Amazon. Barriers to competition include:

  • Strong indirect network effects and economies of scale in the development and maintenance of mobile operating systems, because operating systems must achieve a critical mass of both users and app developers to succeed.
  • While Google licences its Android system to third-party device manufacturers, its complex set of agreements with and payments to these manufacturers mean that any new operating system seeking to attract device manufacturers would need to be able to match the financial incentives offered by Google and offer alternatives to Google’s core apps and APIs, which are important to the functioning of many Android apps.
  • The barriers to users switching away from their current mobile ecosystem would substantially limit the chances of a new entrant. These barriers are greatest for Apple users, accounting for [50% to 60%] of active smartphone users and [50% to 60%] of active tablets, in part due to commercial decisions made by Apple.

Introduction

Consumers enter Apple’s or Google’s mobile ecosystems the first time they purchase a mobile device that uses Apple’s or Google’s operating system. A mobile device always comes with a pre-installed operating system – for example, Apple’s iPhone always comes with iOS pre-installed on it and Google’s Pixel smartphone always comes with Android pre-installed.

This chapter sets out our research and findings in relation to:

• the nature of competition in mobile devices and operating systems
• competitive constraints faced by Apple and Google

In doing this we focus on:

• competition for mobile devices and operating systems jointly, because for users, the choice of mobile device and operating system are part of the same purchasing decision ^{[footnote 74]}

• competition between devices using different operating systems (that is, competition between iOS devices on Android devices) rather than competition between devices using the same operating system (that is, competition between the mobile devices of different Android manufacturers). This is because our primary focus in this market study is on Apple’s and Google’s mobile ecosystems and devices with the same operating system can be viewed as part of the same mobile ecosystem.

This chapter contains summaries of a series of user surveys that were submitted to us by parties. These surveys have been conducted as part of the companies’ general commercial strategies in order to assess user behaviour and preferences in their respective markets.^{[footnote 75]} We have observed that parties undertake research into their own products and also into those of their rivals, as would be expected. Therefore, the fact that a survey or statistic refers to the users of a particular device or product, does not necessarily mean that that the manufacturer of that device conducted or commissioned the research, or provided it to us.

In order to address confidentiality concerns, we have not published the sources of the surveys and, in some instances, we have redacted specific findings. The data set out in this chapter (and elsewhere in the report) should not be assumed to offer insights into any particular party’s commercial strategies.

Nature of competition in mobile devices and operating systems

In this section we consider evidence relating to:

• the parameters of competition for mobile devices and operating systems including evidence on user behaviour

• shares of supply in mobile devices and operating systems

Parameters of competition for mobile devices and operating systems

To enter Apple’s mobile ecosystem a user must purchase an iPhone or iPad as Apple’s iOS is not licensed to third parties, we consider these ‘iOS devices’. In contrast, to enter Google’s mobile ecosystem a user can purchase mobile devices from a range of manufacturers as Google licenses Android to third parties,^{[footnote 76]} we consider ‘Android devices’ to be devices using a version of Android operating system that falls within Google’s compatibility requirements.^{[footnote 77]}

The one exception to this definition is that Huawei currently uses a version of Android that falls within Google’s compatibility requirements, but relies on Huawei’s Huawei Mobile Services instead of Google Mobile Services due to US legislation in May 2019 which meant that Huawei could no longer access Google’s apps and services, including Google Mobile Services. This version of Android is only used in Huawei’s devices and we consider such devices ‘HMS devices’.

Finally, we consider any version of Android falling outside of Google’s compatibility requirements is an ‘Android Fork’. The only other mobile operating system that we are aware of is Amazon, which operates an Android Fork called Fire OS. Amazon operates a vertically integrated model like Apple, with the Fire OS only being used in Amazon’s own tablets.

In order to attract users, suppliers of mobile devices and operating systems will seek to make their devices attractive across a range of factors. This is because users consider a multitude of factors when choosing which mobile device to purchase. It is difficult to identify the exact importance of different factors due to their inter-related nature,^{[footnote 78]} and the fact they are likely to differ across users and user groups.^{[footnote 79]} Surveys have approached this question in different ways.^{[footnote 80]} However, certain parameters of competition are mentioned consistently in the survey evidence, which largely relates to smartphones:

• at a high-level, users often cite factors such as the operating system, brand (either of the device or the operating system), price, hardware specifications and ease of use as the most important factors when purchasing a mobile device ^{[footnote 81]}

• in terms of specific features or functionality, users often cite factors such as battery life, camera quality and screen size^{[footnote 82]}

Apple’s and Google’s views on the key parameters of competition for mobile devices and operating systems

Apple and Google have both provided submissions to us on the competition they face in relation to mobile devices and operating systems.

Apple told us that it ‘has a small market share for smartphones and tablets worldwide and in the UK’. Apple also told us:

• its mobile devices compete in markets characterised by aggressive price competition, frequent introduction of new products and services with rapid adoption of technological advancements by competitors, and price sensitivity on the part of consumers and businesses

• it considers the price and quality of its mobile devices, as well as the appeal of the iOS ecosystem, to ultimately drive device sales and said that its customer base would quickly evaporate if its offering were not competitive

• it identified Samsung and Huawei as 2 specific competitors in the premium segment who compete for the same smartphone users as Apple and also said that there have been some strong recent entrants such as Xiaomi and OnePlus with their high-end devices

• its devices and iOS are fully integrated and it considers the ‘success of Apple’s products is derived in very significant part from the strength, usability and functionality that iOS uniquely provides and Apple invests substantial amounts in developing and improving iOS’

• iOS competes with licensable mobile operating systems, particularly Google’s Android which is installed on most competing mobile devices. Apple said that it releases dozens of new features for iOS each year given the intense competition with Android and that iOS and Android compete on multiple dimensions including ease of use, security, reliability, and software stability

• its devices compete on dimensions of competition relating to the wider iOS ecosystem. Apple also said that the ‘importance of a thriving app ecosystem for the success of a device can hardly be overstated’

• it is also constrained by competition for peripherals, such as smart watches and headphones as users may not want to buy a mobile device that is not compatible with a wide range of attractive peripherals

Google told us that:

• it competes fiercely in the supply of mobile operating systems and this is primarily with Apple. Google said that the pressure to innovate and produce new versions and features for Android is the most significant competitive pressure Google faces, with Apple and Google competing vigorously to provide high quality mobile operating systems that are attractive to users and app developers

• android can only be successful if devices that run on Android proliferate and that, given most Android devices are produced by third-party manufacturers, these manufacturers exert competitive pressure on Google

• as Android is a freely available open source operating system, Google competes on quality parameters as shown by the regular releases of new versions of Android and the innovations and features included in those new versions

CMA assessment

Based on the survey evidence submitted to us and on responses from market participants, we consider that Apple, Google and other device manufacturers and mobile operating system providers compete to varying degrees over the following high-level dimensions of competition, which we will assess in the following sub-sections:

• the price of mobile devices: users can purchase their mobile devices as a standalone product (especially the case for tablets) or at the same time as purchasing a mobile phone contract with a Mobile Network Operator. The price of both smartphones and tablets can vary significantly based on the model being purchased – for example, low-end smartphones cost as little as £25 in 2020 while some high-end models cost over £1,500.^{[footnote 83]}

• features, functionality and performance: users care about the features and functionality, as well as the overall performance, of the mobile devices (the hardware) and associated mobile operating systems (the software) they purchase. The features, functionality and performance of devices and operating systems can be broken down in many ways. This includes the ease of use, security and privacy features, battery life, camera quality, screen size among others. Manufacturers and mobile operating system providers compete to offer new innovative features and functionality as well as innovating to improve the existing features and functionality of their mobile devices and operating systems

• content available on their devices: generally, mobile ecosystems that allow users to access more content, whether via native apps or mobile browsers, will be more attractive to users. In relation to native apps, this will depend on the app stores available to users on that device. In addition, manufacturers or mobile operating system providers may make their own apps or services available only on their devices, or devices using their operating system, to attract users

• interoperability: for some users, being able to use their mobile device with a range of other devices that they have, either other mobile devices or ‘connected’ devices such as smart watches, is an important factor when choosing a mobile device. Manufacturers and mobile operating system providers will therefore seek to ensure their mobile devices are interoperable with a range of other devices, as well as offering their own range of compatible devices

• brand: for some users, the brand of the mobile devices, including the associated operating system, is an important factor in their choice of device. Users’ perceptions of each brand will be driven by a variety of factors including past user experience, marketing and the dimensions of competition outlined above

We recognise that content available within a mobile ecosystem is important to users in their choice of device, as described in more detail below. This means that Apple and Google can generally be expected to have an incentive to ensure that a large number and high quality of content providers make their content available within their mobile ecosystems. Such content providers have 2 entry points into mobile ecosystems – through app stores, where they can make their content available through native apps, and through mobile browsers, where they can make their content available through webpages and web apps.^{[footnote 84]} These entry points, and the extent of competition for content providers at each, are discussed in subsequent chapters.

In the rest of this sub-section we first set out certain further context about the purchasing decisions made by users. Second, we set out specific evidence in relation to the pricing of mobile devices, the features, functionality and performance of mobile devices and the other parameters of competition identified above.

Context: evidence on user purchasing decisions

Understanding how and why users behave the way they do in the mobile ecosystems market is crucial to our assessment of how well the market is working for consumers and the wider economy.

As outlined above, we have received survey evidence from various parties about user purchasing decisions. In particular, this evidence focusses on user loyalty to the existing mobile operating system on their mobile device and the extent to which they switch between mobile operating systems. We consider the implications of this behaviour in our competitive assessment below.

First, we have found that users are generally buying replacement devices so are currently either within Apple’s or Google’s ecosystems: ^{[footnote 85]}

• especially for smartphones, most users are purchasing a replacement device,^{[footnote 86]} with survey evidence showing that less than 10% of purchases are buying their first smartphone. This is also consistent with the high rates of smartphone ownership in the UK^{[footnote 87]}

• while higher^{[footnote 88]} than for smartphones, the proportion of new users purchasing tablets is still low. For example, survey data from Q1 2019 showed that 13% of tablet purchasers are buying their first tablet ^{[footnote 89]}

Google said that because manufacturers (including Apple and Android device manufacturers) cannot discriminate between new and existing users, new users constrain behaviour in relation to existing users. While this may be the case to some extent, the fact that most users are buying replacement devices suggests that the competitive conditions faced by suppliers of mobile devices and operating systems will largely depend on the behaviour of and barriers to switching for existing users.^{[footnote 90]}

Second, we have found that users generally do not have both an iOS and an Android device.

Most users appear to only have smartphones that use one operating system given that 80% of users appear to only use one smartphone and evidence suggests that even when users are purchasing an additional smartphone rather than replacing their existing one, it is normally one using the same operating system.^{[footnote 91]}

While there may be more cross-ownership when considering smartphones and tablets with different operating systems, this appears still to be low. For example, a survey provided to us by [a party] showed that [60% to 70%] of respondents who owned an iPhone also owned a tablet and of those only [10% to 20%] had a tablet using another operating system (ie [10% to 20%] of all respondents who owned an iPhone). Similarly, only [50% to 60%] of respondents who owned a Samsung smartphone had a tablet and of those only [20% to 30%] had an iPad (ie [10% to 20%] of all respondents who owned a Samsung smartphone).

This is also consistent with evidence from app developers that only a small proportion of their users access their apps on both Apple and Android devices.

Third, we have found that users buying replacement devices do not generally switch mobile operating system, and this is particularly the case for Apple users.

While neither Apple nor Google could provide data for us to calculate actual rates of switching,^{[footnote 92]} survey evidence shows there is limited switching in practice between mobile devices with different operating systems and users are more likely to switch to Apple’s devices than switch away. For example, a survey provided to us by [a party] showed that during 2020 between [0% to 10%] of users who purchased a new Android device had switched from an Apple device. In contrast, between [10% to 20%] of users who purchased a new Apple device had switched from an Android device.

To some extent this difference might be driven by differences in the number of users purchasing a new Apple or Android device. Therefore, we have used results from a survey submitted by [a party] to assess switchers to and from Apple devices as a proportion of Apple’s user base. This shows that in 2020 users’ switching away from Apple (to Android) were 2.5% of Apple’s user base and that users’ switching to Apple (away from Android) were 8.0%.^{[footnote 93]}

In addition to the survey evidence, we requested evidence from Apple and Google to understand the average age of accounts associated with their devices to understand if users tend to stay within the same mobile ecosystem over time. However, neither party tracks such data.^{[footnote 94]}

Apple was able to provide some evidence on the average number of Apple devices that Apple users register over the life of their Apple ID, after they have initially purchased an iOS device. This data showed that [the average number of devices per Apple ID was in line with what might be expected given what survey evidence suggests about how long Apple smartphone users own their smartphones].^{[footnote 95]} However, Apple cautioned that Apple ID accounts do not necessarily represent unique users, because an account may be associated with multiple users and a user may have multiple accounts, such that this data does not represent precisely the average number of devices per user.^{[footnote 96]}

As outlined above, in this rest of this sub-section we set out specific evidence in relation to the pricing of mobile devices, the features, functionality and performance of mobile devices and the other parameters of competition identified above.

Evidence on the pricing of mobile devices

As discussed above, Apple, Google and other manufacturers consider price to be an important dimension of competition. For example:

• Apple told us that its devices ‘compete in markets characterized by aggressive price competition and resulting downward pressure on gross margins’ and ‘price sensitivity on the part of consumers’. Apple said that other manufacturers have top-end devices that are more expensive than any of Apple’s^{[footnote 97]} and that it has introduced new lower price points (such as the iPhone SE)

• Google told us that it considers that users take into account the device or contract price, but also stated that ‘price is unlikely to be determinative of the decision to choose an Android or iOS device since […] there is considerable overlap between Android and iOS devices at a broad range of price points’. In doing this Google, highlighted how Apple competed with lower-end Android devices through the SE range of iPhones

• Samsung said that price is [an important] driver of the purchase decision [REDACTED]. Samsung also said that it had a strong focus across all price points, [REDACTED], and that Apple had entered the mid-tier price segments with the iPhone SE

• Huawei considers price [of devices] to be one of the key parameters of competition in the UK and [REDACTED]. Huawei identified new entrants using Android as those competing fiercely on price terms, whereas it said Samsung and Apple tend to compete based on innovation and product specifications. Huawei said that it tries to compete with both by [REDACTED]

Given these views, we have assessed the prices of mobile devices to inform our competitive assessment – focusing on comparing prices of devices using different operating systems.^{[footnote 98]} We used data from the International Data Corporation (IDC) ^{[footnote 99]} on the volume and value of devices in the UK to understand the prices, excluding VAT, at which iOS devices and Android devices are sold. See Appendix C for details of the data and methodology used.

Figures 3.1 and 3.2 consider data for 2017 and 2020 respectively and show the proportion of iOS smartphones and Android smartphones respectively at each £100 price band.

For the purposes of this analysis we have not split out Huawei’s HMS devices.

Figure 3.1: Proportion of smartphones shipped into the UK by £100 price bracket (2017)

Figure description: A barchart that shows the volume of smartphone devices (both iOS and Android devices) that were shipped into the UK by £100 price ranges in 2017. The chart illustrates that Apple’s iOS devices dominate the sale of higher priced smartphones whereas Google’s Android devices dominated the sale of lower priced smartphones. The chart shows that in 2017, 66% of iOS devices were sold for more than £500 compared to 19% of Android devices. The chart shows that in 2017, 8% of iOS devices were sold for £300 or less compared to 63% of Android devices.

Source: CMA analysis of IDC data from ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’

Notes: For details on how the number of units shipped and average selling price data were consolidated, see Appendix C.

Figure 3.2: Proportion of smartphones shipped into the UK by £100 price bracket (2020)

Figure description: A barchart that shows the volume of smartphone devices (both iOS and Android devices) that were shipped into the UK by £100 price ranges in 2020. The chart illustrates that Apple’s iOS devices dominate the sale of higher priced smartphones whereas Google’s Android devices dominated the sale of lower priced smartphones. The chart shows that in 2020, 81% of iOS devices were sold for more than £500 compared to 20% of Android devices. The chart shows that in 2020, less than 1% of iOS devices were sold for £300 or less compared to 66% of Android devices.

Source: CMA analysis of IDC data from ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’

Notes: For details on how the number of units shipped and average selling price data were consolidated, see Appendix C.

As can be seen, while there may be both types of device sold at many price points (although no Apple devices are sold for less than £200), there is a gap between the price at which most iOS smartphones are sold, and the price at which most Android devices are sold. In particular, the IDC data indicates that:

• Apple’s iOS devices dominate the sale of higher priced devices even if, as noted by Google, there are Android devices at every price point. In 2017 66% of iOS devices were sold for more than £500, compared to just 19% of Android devices. By 2020, this gap had expanded, with 81% of iOS devices being sold for more than £500, compared to just 20% of Android devices^{[footnote 100]}

• Devices using Google’s Android dominate the sale of lower priced devices. In 2017, only 8% of iOS devices were sold for £300 or less, compared to 63% of Android devices. By 2020, this gap had expanded, with less than 1% of iOS devices being sold for £300 or less, compared to 66% of Android devices.^{[footnote 101]} This is despite Apple, Google and Samsung all referencing Apple’s introduction of the iPhone SE and its move into the mid-tier pricing – currently the iPhone SE appears to retail on a standalone basis for at least £359 when new,^{[footnote 102]} which is clearly above the price that most Android devices are sold at

The increase in the gap between the price at which most iOS smartphones are sold and the price at which most Android smartphones are sold is also reflected in changes in average prices. As shown in Figure 3.3, the IDC data indicates that between 2017 and 2020, the average price of iOS smartphones has increased relative to the average price of Android smartphones.

Figure 3.3: Average price, excluding VAT, of iOS devices and Android devices (not adjusted for inflation)

Figure description: A time series chart that shows the average price (excluding VAT) of iOS devices and Android devices from 2017 to 2020. The chart shows that the average price for iOS devices rose from £575 in 2017 to £721 in 2020 whereas the average price for Android devices initially increased from £282 in 2017 to a high of £336 in 2019 before dropping back to £300 in 2020.

Source: CMA analysis of IDC data from “IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2”

Notes: For details on how the number of units shipped and average selling price data were consolidated, see Appendix C.

In relation to tablets, Figure 3.4 below shows the volume of sales in 2020 at different price points for iOS tablets, Android tablets (including Amazon’s Fire OS tablets) and some Windows devices that the IDC data classifies as tablets.^{[footnote 103]}

Figure 3.4: Volume of tablet shipped into the UK by £100 price bracket (2020)

A bar chart that shows the volume of tablets (for iOS, Android, Amazon’s Fire OS and some Windows tablets) shipped into the UK by £100 price ranges in 2020. The chart illustrates that in 2020, all iOS tablets were sold for £200 or more, in which only 26% of rival devices were sold.

Source: CMA analysis of IDC data from ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’.

Notes: For details on how the number of units shipped and average selling price data were consolidated, see Appendix C.

The IDC data indicates the same broad picture for tablets. In particular, in 2020 the IDC data indicates:

• there is again a price gap between Android and iOS tablets as in 2020 the majority of Android tablets (83%) were sold for £200 or less, whereas the data indicates that no iOS tablets were sold for £200 or less in 2020^{[footnote 104]}

• all iOS tablets were sold for £200 or more, in which only 26% of rival devices were sold^{[footnote 105]}

• the majority of Windows devices in the data were sold for more than £700 and Apple’s tablets in the same price bracket only account for 9% of its sales.^{[footnote 106]} We note that most of the devices using the Windows operating system were manufactured by Microsoft^{[footnote 107]} and we have not generally considered them to be tablets in our broader analysis^{[footnote 108]}

The relative pricing between iOS devices and Android devices is consistent with the business models of Apple and Google. In particular:

• Apple’s primary source of revenue comes from selling hardware and its associated operating systems (for example, the iPhone and iOS) and its devices are highly profitable, as set out in the previous chapter. While Apple’s services are becoming increasingly important to its business, and are also highly profitable, the importance of hardware sales means that Apple has an incentive to maintain the prices of its hardware and this is consistent with the fact that most high-priced mobile devices are Apple devices

• Google’s primary source of revenue comes from selling digital advertising, primarily search advertising, rather than the sale of its devices or licensing the Android operating system, as set out in Overview of mobile ecosystems. Google said that licensing Android for free ‘has helped increase the number of smartphone owners by enabling [manufacturers] to develop quality smartphones and tablets at low cost’. Google said that this encourages more developers to create engaging apps and web-based services creating more opportunities for it to generate advertising revenue. ^{[footnote 109]} This is consistent with the fact that most low-priced mobile devices are Android devices

We consider the implications of the relative sale prices of iOS devices, Android devices and those of other operating systems in our competitive assessment below.

Evidence on the features, functionality and performance of mobile devices and operating systems

As set out above, evidence from market participants and consumer surveys has shown the features, functionality and performance of mobile devices and the associated operating systems are a parameter of competition, as they are important factors in users’ choice of mobile device.

For example, the survey evidence indicates that specific features such as battery life, ^{[footnote 110]} camera quality and screen size are some of the most important smartphone features for purchasers across different operating systems. ^{[footnote 111]} Similarly security and privacy, which are determined to a large extent by the operating system were identified as extremely or very important factors in the purchase decision for over half of iPhone and over 80% of iPad purchasers.

In addition, there is at least a perception among users that Apple’s devices are of a higher quality than those of other manufacturers. For example, a survey submitted by [a party] shows that Apple’s brand scored higher than Samsung’s brand on statements such as ‘is a premium brand’ (77% vs 54%), ‘has products with the latest innovation’ (68% vs 62%) and ‘has products with appealing design’ (64% vs 56%).

The suppliers of mobile devices and operating systems that we requested information from said that the features, functionality and performance of their devices or operating systems were an important parameter of competition. For example:

• Apple submitted that its ability to compete successfully depends heavily on ensuring the continuing and timely introduction of innovative new products, services, and technologies to the marketplace and this has seen it invest tens of billions of dollars in R&D in just the past few years

• Google said that the pressure to innovate and produce new versions and features for Android is the most significant competitive pressure it faces, with Apple’s iOS being its most significant competitor in this activity. Google said that the number of Android versions over time and the innovations and features they contained highlights this competition^{[footnote 112]}

Samsung said that innovation was important in providing the best experience for consumers and making its products more attractive in the face of innovation by rivals.^{[footnote 113]} [REDACTED]

Amazon said that providers compete on quality [REDACTED]. ^{[footnote 114]} Amazon submitted that with each generation of its tablets, it has worked to improve the core features of the display, performance, storage and battery life as they directly tie to a better user experience [REDACTED].

We understand that competition on features and functionality plays out through mechanisms including in-house innovation and the acquisition of innovative companies. Apple, Google and others have provided evidence of such innovation and acquisitions over time. For example, Figure 3.5 shows a table of the improvements in device features and capabilities in relation to the iPhone and Figure 3.6 is a visual representation provided by Google of the major iOS and Android releases over time.

Figure 3.5: Improvements in device features and capabilities from the iPhone to iPhone 13 Pro

Figure description: An illustration that shows the improvements in device features and capabilities from the iPhone to the iPhone 13 Pro. The diagram shows that the iPhone 13 has: a larger screen size (6.7 inches) than the iPhone (3.5 inches); a higher screen resolution (2778 x 1284) compared to 480x320, a differnt processor A15 Bionic vs a 412 Mhz Samsung ARM, more storage space (1TB vs 8GB), better Camera (12 megapixels and other features vs 2 megapixels) a longer battery life and additional features such as GPS, Facetime, Siri, ID, NFC, UWB, wireless charging and water & dust resistance.

Source: Apple.

Figure 3.6: Android vs iOS Releases (2007 to 2020) as presented by Google

Figure description: A representation of major version releases of iOS and Android between 2007 and 2020. Iphone iOS releases ascending from iOS 1 in 2007 to iOS 14 in 2020. Android releases stating with Android 1.0 in 2008 and moving on to Cupcake, Donut, Eclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, Jellybean, KitKat, Lollipop, Marshmallow, Nougat, Oreo, Pie, Android 10, up to Android 11 in 2020.

Source: Google.

Notes: Green indicates major version releases of Android and these are Google’s names for each version of Android while blue indicates major version releases of iOS. The scale of different updates may vary and does not necessarily indicate the total level of innovation – ie while there have been more versions of Android this does not necessarily mean there has been more innovation of the Android operating system and we have not sought to assess this.

Suppliers of mobile devices and operating systems may have an incentive to improve the features, functionality and performance of their devices for a number of reasons, including:

• as a result of competitive pressure from their rivals. In particular, given that features, functionality and performance of mobile devices and operating systems are important factors for users, the possibility of users switching to rivals is likely to generate some incentive for suppliers to innovate in order to make sure they are competitive relative to their rivals

• in order to generate incentives for users to replace their current mobile devices. As outlined above, over 90% of UK households own a smartphone and this means that most users buying a new smartphone are replacing an old one. As such manufacturers who generate revenue for each smartphone sold have an incentive to innovate in order to ensure that users have an incentive to buy a replacement smartphone – that is, there is a constraint from existing devices in users’ pockets. The incentives for this will differ depending on the significance of the revenue generated from upfront device sales, as well as factors such as the support provided to existing devices ^{[footnote 115]} or number of other manufacturers using the same operating system^{[footnote 116]}

• in order to increase the opportunities for generating revenue within the mobile ecosystem. Both manufacturers and operating systems generate revenue from users when they are within an operating system (for example, Android manufacturers can receive a share of the revenue Google generates from advertising and Play transactions on their devices. This means that they have an incentive to innovate in ways that increase the usage of mobile devices by users (for example, in terms of engagement or time spent) or increase the offerings available through apps (if innovations allow app developers to offer additional services or features that are charged for). This is because such innovations are likely to generate additional revenue for suppliers of mobile devices and operating systems and this may be of increasing importance given the more limited opportunities for further revenue growth in hardware^{[footnote 117]}

It is clear that over time Apple has improved the features, functionality and performance of its devices and iOS operating system and that over time Google has improved the features, functionality and performance of its Android operating system (both Android Open Source and through its own application programming interfaces (APIs) available in Google Play Services). For example:

• Apple provided a list of examples amongst the many enhancements and innovation it has introduced over just the last 5 years that included:

  • hardware and software innovations which improve the processing speed, functionality and quality of its mobile devices and connected devices such as innovations in chips, haptics and materials such as its Ceramic Shield Glass

  • hardware and software innovations in relation to privacy features such as Apple’s Face ID

  • software innovations at the operating system level that are provided to developers to assist in building new and improved apps such as CoreML and ARKit

• Google provided a list of examples that included:

  • software innovations aimed at improving the performance, battery and memory of Android devices

  • software innovations aimed at improving the privacy and security of Android devices

  • software innovations aimed at improving the user experience, including wellbeing

This will have benefitted users over time as the quality of mobile devices has increased. We consider what this tells us about the constraints faced by Apple and Google in our competitive assessment below.

Evidence on the content available on mobile devices, interoperability, and the importance of brand

Evidence from market participants has shown that overall, the quantity and quality of content available in a mobile ecosystem is very important to users.

This is because operating systems are 2-sided platforms that exhibit indirect network effects, whereby the benefit derived by users from using a given mobile operating system depends on the volume and quality of content they can access on that platform. In turn, content providers are also more likely to make their content accessible or develop native apps for mobile operating systems that have a larger number of users. We consider such indirect network effects, including how they can make it difficult for new entrants to challenge large incumbents, when assessing competition both in relation to mobile operating systems in this chapter and native app distribution in Competition in the distribution of native apps.

The importance to users of the quantity and quality of content available in a mobile ecosystem is reflected in the views we have received. For example:

• BlackBerry told us that iOS and Android overtook existing mobile operating systems through the development of ‘vast application ecosystems for Android and iOS creat[ing] compelling experiences for consumers that drove adoption of these mobile operating systems’.

• Huawei told us that ‘the richness of the ecosystem affects a user’s purchase decisions’ and that ‘a lack of apps would act as a major deterrent to users’. It also told us that ‘if the basic applications that users want are not pre-installed on a mobile device, this may influence their decision whether to purchase the device.’ Huawei provided research which supported this, showing [REDACTED].

Furthermore, consistent with the evidence set out above, we note that Amazon’s Fire Phone, based on Amazon’s Fire OS, was launched in the UK in September 2014 but exited the smartphones market a year later. On the reasons for its lack of success, it has been reported that a narrow selection of apps, including the inability to offer the Google Mobile Services suite of apps, made it difficult for its Fire Phone to successfully compete. ^{[footnote 118]}

As set out in Competition in the distribution of native apps, many of the same popular native apps are available on both iOS and Android devices, as noted by both Apple ^{[footnote 119]} and Google^{[footnote 120]}. Further, as can be seen in Competition in the distribution of native apps, the proprietary app stores of Huawei’s HMS devices and Amazon’s Fire OS tablets have a much smaller number of native apps and app developers than either the App Store or Play Store.

We consider the implications of the similarities and differences in available content across mobile ecosystems in our competitive assessment below.

As outlined above, manufacturers and mobile operating system providers seek to ensure their mobile devices are interoperable with a range of other devices, as well as offering their own range of compatible devices. For example, Apple offers devices such as the Apple Watch and AirPods, Google offers various Google Nest products and Samsung offers the Galaxy Watch and Galaxy Buds.

This is because some users consider it is important that their mobile device works with a range of other devices that they have, either other mobile devices or ‘connected’ devices such as smart watches. For example:

• in a 2020 survey submitted to us by [a party], [40% to 50%] of iPhone buyers surveyed reported that it was extremely important to their smartphone purchasing decision that Apple products work well with other Apple products

• a survey that was submitted by [a party] found that 33% of UK iPhone users stated that the device working with their other devices was a reason to choose iOS

• [70% to 80%] of UK iPad owners considered that the iPad working well with other Apple products and services was very important to their tablet purchasing decision

We consider the implications of any differences in interoperability across mobile ecosystems in our competitive assessment below.

Brand is also an important factor in users’ decision-making process. It is consistently cited as one of the top criteria for purchasing a new smartphone. Survey evidence submitted by [a party] shows that between iOS purchasers and Android purchasers, there is little difference in the importance placed on the ‘[operating system] brand’. However, iOS purchasers ([80% to 90%]) are more likely to care about the ‘smartphone brand/model’ than Android purchasers ([60% to 70%]). This may reflect the fact that Android purchasers can choose between a number of different smartphone brands all using Android.

In addition, survey evidence shows that among those intending to purchase a new mobile phone in the next 6 months, the vast majority of iOS owners identified Apple and the vast majority of Android owners identified smartphone brands using Android. In addition, survey evidence submitted by [a party] indicates that most smartphone purchasers are considering only one operating system and the proportion considering both has declined from 24% in 2019 to 16% in 2020.

Survey evidence indicates that, overall satisfaction with both iOS and Android smartphones is also high with over 9 in 10 satisfied with their device. Samsung owners ([60% to 70%] very satisfied) and iPhone owners ([60% to 70%] very satisfied) report particularly high satisfaction.

We consider the extent to which barriers to switching could contribute to this brand loyalty in our competitive assessment below.

Shares of supply for mobile operating systems and devices

We have considered shares of supply in relation to mobile devices and also according to mobile operating systems on active mobile devices in the UK. Mobile devices encompass both smartphones and tablets.

There are some differences in relative shares and the size of competitors based on the type of mobile device, so we consider smartphones and tablets separately below. In addition, it is possible to assess both the number of active devices and the number of new sales. ^{[footnote 121]} While both are set out in Appendix C, here we focus on active devices for operating systems and new sales for manufacturers. This is because operating systems can generate revenue from all active devices, whereas for most manufacturers revenue comes from the sale of new devices.

Smartphones

Both globally and at the UK level, Apple and Google hold a de facto duopoly over operating systems for both smartphones and tablets – the available data shows that almost all smartphones are either iOS or Android devices as well as roughly 75% of tablets.

Apple is also the largest device manufacturer given iOS is only available on Apple devices. In contrast, most Android devices are manufactured by third parties.

Smartphone manufacturers

Figure 3.7 shows the shares of supply based on data from market participants for Apple, Samsung, Huawei and Google in terms of new smartphones in the UK for the period 2015 to 2020. As can be seen, in the UK:

• between [40% to 50%] and [40% to 50%] of new smartphones sold in each year of this period have been Apple’s iPhones.

• between [20% to 30%] and [20% to 30%] of new smartphones sold in each year of this period have been Samsung phones such that Samsung has been the second largest manufacturer and the largest manufacturer of Android devices.

• In at least 2018 and 2019 the second largest manufacturer of Android devices has been Huawei with its share peaking at [5% to 10%] in 2019, although its sales declined in 2020 following US legislation in May 2019, which prevented new Huawei devices from accessing Google’s apps and mobiles services. At this point Huawei moved to using a version of Android that relied on its Huawei Mobile Services, as outlined above.

• Google’s Pixel smartphone share is very small – [0% to 5%] of new smartphones sales in 2020 in the UK.

Figure 3.7: Manufacturer shares of supply in the sale of new smartphones in the UK (2015 to 2020)

Figure description: A time series chart showing the shares of supply for Apple, Samsung, Huawei and Google in terms of new smartphones in the UK for the period 2015 to 2020 as described in the previous paragraph. The chart shows that between [40% to 40%] and [40% to 50%] of new smartphones sold from 2015 to 2020 were Apple’s iPhones, followed by Samsung smartphones between [20% to 30%] and [20% to 30%] and Huawei and Google.

Source: CMA analysis of data from market participants.

Notes: We have only received data from a limited number of manufacturers so shares do not sum to 100% as total volumes are based on operating systems data to calculate the total number of new sales.

Smartphone operating systems

While there are several manufacturers of smartphones, virtually all active smartphones in the UK come with either the iOS or the Android operating system, meaning that Apple and Google have a duopoly in the supply of smartphone operating systems. Figure 3.8 is based on data from market participants on active smartphones in the UK for the period 2015 to 2020. ^{[footnote 122]} This shows that:

• between [50% to 60%] and [50% to 60%] of active smartphones in each year of this period have been Apple’s iOS devices (ie half or more of active smartphones in the UK have been iPhones)

• between [40% to 50%] and [40% to 50%] of active smartphones in each year of this period have been Android devices

• currently Huawei’s HMS devices have a very small share of active smartphones at [0% to 5%] in 2020, although as outlined above they have only been available since 2019.

Figure 3.8: Operating system shares of supply in active smartphones in the UK – market participants data (2015 to 2020)

Figure description: A time series chart showing the operating system shares of supply for iOS (Apple), Android (Google) and HMS (Huawei) devices in the UK for the period 2015 to 2020. The chart shows that between [50% to 60%] and [50% to 60%] of active smartphones in the UK have had the Apple iOS operating system, Android [40% to 50%] and [40% to 50%] of active smartphones and Huawei [0% to 5%].

Source: CMA analysis of data from market participants

Notes: Apple provided data on ‘Transacting accounts’. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one smartphone, and one smartphone could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active smartphones.

As set out in Appendix C, in relation to mobile operating systems we put less weight on shares of supply based on data from Statcounter which uses data on page views by different devices rather than data on actual devices as provided by market participants. ^{[footnote 123]} However, such data is useful because the data covers a longer period (in the case of smartphones to 2009) and in doing so shows that historically there have been other large smartphone operating systems and attempts at entry by large companies providing operating systems in other markets.

For example, Figure 3.9 below shows shares of supply based on data from Statcounter as far back as 2009. As can be seen Blackberry OS (17%) and Symbian OS (16%) were the second and third largest providers of operating systems in 2009. The share of Symbian OS (owned by Nokia) was already in decline in 2009 and was essentially 0% by 2014. The share of Blackberry OS (owned by RIM which became Blackberry) initially increased, peaking at 37% in 2011, before declining swiftly as Google increased its share. These parties, and Microsoft’s Windows whose share peaked at 3% in 2015, are essentially no longer active. ^{[footnote 124]}

Figure 3.9: Operating system shares of supply in active smartphones in the UK (2009 to 2021)

Figure description: A time series chart showing the operating system shares of supply for active smartphones in the UK from 2009 to 2021. This chart shows that 17% and 16% of active smartphones in the UK were using the operating systems of BlackberryOS and Synbian OS respectively in 2009. The chart shows that by 2014, Symbian OS’s share of supply dropped to 0% and Blackberry OS’s was 0% by 2017. The chart shows that iOS and Android have been the largest operating systems since 2013 with over 40% each since 2015.

Source: Mobile Operating System Market Share United Kingdom Statcounter Global Stats.

Notes: Only operating systems with a share of 5 percentage points or more in any one year have been included except Microsoft’s Windows which is included for illustrative purposes. Because it uses a version of Android Huawei’s HMS devices are likely to be included within Android. In addition, Fire OS is likely to be included within Android as it is an Android Fork, however, we understand that Fire OS was only used in Amazon’s Fire Phone which was launched in the UK in September 2014 and discontinued in 2015.^{[footnote 125]}

Globally, Apple’s iOS and Google’s Android are the only 2 operating systems on smartphones with a material share of supply. However, their relative position does differ with Android having a much larger worldwide share based on Statcounter data of 73% in 2020, whereas iOS had a share of 26%. There are no alternative smartphone operating systems outside the UK that had a worldwide share of more than 1% in 2020.^{[footnote 126]}

Tablets

Tablet manufacturers

Figure 3.10 shows the shares of supply based on sales data from market participants for Apple, Amazon, Samsung, Huawei and Google in terms of new tablets in the UK for the period 2015 to 2020. As can be seen:

• Apple has consistently been the largest tablet manufacturer although Apple’s share has fluctuated starting at [40% to 50%] in 2015, before falling to [30% to 40%] in 2017 and then rising again to [30% to 40%] in 2020

• Amazon’s Fire OS is only available on its own Fire tablets, so Amazon’s share of tablets mirrors its share of tablet operating systems. It has been the second largest tablet manufacturer for most of the period considered, with Amazon’s share of new tablets growing materially from [10% to 20%] in 2015 to [30% to 40%] in 2017 before declining to [20% to 30%] in 2020

• as with smartphones, the share of Google’s Pixel tablet is very small – [0% to 5%] of new tablets in 2020 in the UK – with most Android tablets being manufactured by third parties

• Samsung has consistently been the largest manufacturer of Android tablets and the third largest tablet manufacturer for most of the period considered. Samsung’s share has been fairly consistent ranging between [10% to 20%] and [10% to 20%] of new tablets

Figure 3.10: Manufacturer shares of supply in the sale of new tablets in the UK – market participants data (2015 to 2020)

Figure description: A time series chart showing the shares of supply for Apple, Amazon, Samsung, Huawei and Google in terms of new tablets in the UK for the period 2015 to 2020. The chart shows that Apple’s tablet share started at [40% to 50%] in 2015 before falling to [30% to 40%] in 2017 and rising to [30% to 40%] in 2020, Amazon’s Fire tablet went from [10% to 20%] in 2015 to [20 to 30%] in 2020 and Samsung’s share was fairly consistent between [10% to 20%] and [10% to 20%].

Source: CMA analysis of data from market participants.

Notes: We have only received data from a limited number of manufacturers so shares do not sum to 100% as total volumes are based on operating systems data to calculate the total number of new sales.

Tablet operating systems

For tablet operating systems, the picture is slightly different to smartphones, due to the presence of Amazon’s Fire OS, which is an Android Fork. However, Apple’s iOS and Google’s Android are still the largest 2 operating systems used, with roughly 75% of active tablets in 2020. For example, Figure 3.11 shows the shares of supply based on data from market participants for iOS, Android, Amazon’s Fire OS and Huawei’s HMS devices in terms of active tablets in the UK for the period 2017 to 2020. ^{[footnote 127]} As can be seen:

• between [50% to 60%] and [50% to 60%] of active tablets in each year in this period have been Apple’s iOS devices (ie iPads) – its share has declined slightly over time

• Google’s Android has been the second largest operating system in terms of active tablets, but its share of active tablets has decreased from [20% to 30%] in 2017 to [20% to 30%] in 2020

• Amazon’s Fire OS has been the third largest operating system in terms of active tablets with its share of active tablets increasing from [10% to 20%] in 2017 to [20% to 30%] in 2020

Figure 3.11: Operating system shares of supply in active tablets in the UK – market participants data (2017 to 2020)

Figure description: A bar chart illustrating the factors influencing the smartphone purchase decisions for Apple, Huawei and Samsung buyers. The chart shows that ‘good price’ is particularly important for Huawei (64%) and Samsung (50%) buyers but less so for Apple (36%) buyers. In contrast, Apple buyers (60%) place greater importance on ‘know how to use their phones’ compared to Samsung (48%) and Huawei (17%).

Source: CMA analysis of data from market participants.

Notes: Huawei’s HMS devices have only been available since 2019 as set out above. Apple provided data on ‘Transacting accounts’. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one tablet, and one tablet could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active tablets.

As set out in Appendix C, we put less weight on shares of supply based on data from Statcounter as it uses data on page views by different devices and more weight on the shares of supply based on data from market participants.^{[footnote 128]} However, such data is useful in that it allows us to go back further to 2012 and in doing so shows that historically there have not been any other tablet operating systems with a material share of supply in active tablets. The Statcounter data set out in Appendix C does indicate a higher share of Apple (until 2020 over 70%) and lower shares for Android (lower than 20% until 2020) and Fire tablets (only 10% in 2020).

Globally Apple’s iOS is also the main operating system used on tablets, with Statcounter showing a worldwide share in 2020 of 59%, although this share has declined somewhat over time. This data does not actively split out Google’s Android from HMS devices or Android Forks such as Fire OS and these are used on the remaining tablets, with a worldwide share of 41% in 2020. Therefore, there are no alternative tablet operating systems outside the UK that had a worldwide share of more than 1% in 2020. ^{[footnote 129]}

Competitive constraint relating to mobile devices and operating systems

In this section we consider the competitive constraints faced by Apple in relation to its mobile devices and associated operating system iOS and the competitive constraints faced by Google in relation to is Android operating system. As outlined above, unless otherwise stated we have considered the constraint on devices and operating systems jointly, because a user’s choice of mobile device and operating system are part of the same purchasing decision.

In doing so, we have not carried out a formal market definition assessment, but instead looked at the competitive constraints faced by Apple and Google from across the sector including focusing on direct indicators of market power and barriers to entry and expansion.^{[footnote 130]}

This section is split into 2 parts. First, we consider the extent to which Apple or Google are constrained by user switching or the threat of users switching from using Apple devices to Android devices or vice versa.

• within this section on user switching, the first sub-section considers the initial competition for users at the point that users buy a mobile device, given this is the point that users enter a mobile ecosystem. In particular, we consider the implications of the user behaviour we have observed above and assess the level of competition that exists between Apple and Google as a result of the threat of users switching to devices using a different operating system

• the second sub-section considers whether there are barriers to users switching between mobile ecosystems and the implications of this for competition

Second, we consider the extent to which Apple or Google are constrained by the threat of entry or expansion by competing suppliers of mobile devices or operating systems. In doing this, we focus on both demand-side and supply-side barriers to entry and expansion faced by potential entrants.

We note that Apple and Google may compete to ensure users consume content on their devices and also to attract content providers and app developers. This competition is discussed in subsequent chapters and referred to where relevant as part of the assessment of competitive constraints below.^{[footnote 131]}

We note that in theory Google could be constrained by manufacturers of Android devices switching to use another operating system in their mobile devices. However, currently Android is the only licensable mobile operating system in the UK (and is the only large licensable operating system we are aware of internationally) ^{[footnote 132]} with other operating systems with any material presence in the UK only being used in first-party devices. ^{[footnote 133]} As such any constraint on Google from these manufacturers would only arise from them using a new entrant operating system (including entering with their own) and is considered as part of our assessment of barriers faced by potential entrants.

Competitive constraint from users switching

As set out above, here we first consider the evidence on user behaviour and the parameters of competition as set out above and what this tells us about user-driven competition. Second, we consider focus whether there are barriers to users switching between mobile ecosystems and the implications of this for competition.

User behaviour and parameters of competition

As set out above, survey evidence shows that:

• users are generally buying replacement devices so are currently either within Apple’s or Google’s ecosystems

• users generally do not have an iOS mobile device and another device using Android and vice versa

• users buying replacement devices do not generally switch mobile operating system, and this is particularly the case for Apple users

Overall, the evidence is consistent with only a small group of users being able and willing to switch between mobile devices using different operating systems, as a result of most purchasers of devices already being part of a mobile ecosystem, a low level of multi-homing between mobile ecosystems, and a low level of switching between operating systems. This suggest there is a limited competitive constraint on Apple and Google from rival suppliers of mobile devices and operating systems (including each other).

Apple has argued that the high level of loyalty observed on the part of users in the form of high numbers of repeat purchases is also consistent with the high levels of user satisfaction. Apple cited several sources showing a high level of user satisfaction among Apple users. In order to assess the significance of this argument, we have also considered evidence on the factors that feed into users’ decision making when purchasing a mobile device (ie the parameters of competition).

Pricing of mobile devices

Our analysis comparing the prices of mobile devices using different operating systems is set out above. This analysis indicates that:

• there is a price gap between the price at which most Android smartphones are sold and the price at which most iOS smartphones are sold and this gap has been increasing. In particular, Apple’s iOS smartphones dominate the sales of high-priced smartphones with 81% of Apple’s iOS smartphones being sold for more than £500 in 2020 whereas smartphones using Android dominate the sale of low-priced smartphones with 66% of Android smartphones being sold for £300 or less in 2020. ^{[footnote 134]} This is also reflected in the average price of iOS smartphones increasing relative to the average price of Android smartphones

• for tablets:

  • there is again a price gap between Apple’s iOS tablets and those using Android as in 2020 the majority of Android tablets (83%, including Amazon’s Fire OS tablets) were sold for £200 or less whereas the data indicates that no iOS tablets were sold for £200 or less in 2020.^{[footnote 135]}

  • Amazon’s Fire OS tablets have a material share of new tablet sales ([20% to 30%] in 2020 as set out in Figure 3.10). While we have as yet not been able to split out Amazon’s Fire OS tablets in our analysis, we understand based on the underlying data that they are generally sold for less than £200. For instance, the average price of Fire OS tablets in 2019 and 2020 was less than £80 (see Annex C).^{[footnote 136]}

This suggests that there is limited price competition between iOS devices and Android devices. For example, all other things being equal, we would expect the increasing price gap between iOS devices and those using other operating systems to lead to users switching away from iOS devices thus constraining Apple. However:

• for smartphones, Apple’s share of new sales has been largely stable at [40% to 50%] in 2017, [40% to 50%] in 2018 and 2019 and [40% to 50%] in 2020, as can be seen in Figure 3.11 above, despite the apparent increase in this price gap ^{[footnote 137]}

• for tablets, Apple’s share of new sales has increased to some extent from [30% to 40%] in 2017 and [30% to 40%] in 2020 ^{[footnote 138]}

• levels of user switching are low as set out above and this is particularly the case for Apple

We have also considered what survey evidence can tell us about the level of price competition between iOS and Android devices. 2 key conclusions can be drawn from the survey evidence we have received:

• first, price is identified as one of the top factors by both those who have recently purchased a device and those who intend to purchase a device^{[footnote 139]}

• second, several surveys show that price or the cost of the phone is less important for iOS users than it is for Android users. For example, Figure 3.12 below shows that ‘good price’ is particularly important for Huawei (64%) and Samsung (50%) buyers but less so for Apple (36%) buyers.^{[footnote 140]} In contrast, Apple buyers (60%) place greater importance on ‘know how to use their phones’ compared to Samsung (48%) and Huawei (17%). This suggests a strong attachment with the way the iPhone works as part of the iOS ecosystem among Apple buyers

Figure 3.12: Factors influencing smartphone purchase decision

Source: Survey evidence submitted to us by [a party].

Notes: Q. Which of the following factors influenced your decision to purchase your phone, and which was the most important reason? % important charted.

While only addressed by individual surveys, we have also reviewed other evidence showing the loyalty to iOS devices as being more familiarity driven rather than value driven ^{[footnote 141]} and that Apple is seen as more of a premium brand than other brands and has lower value for money associations than the largest Android device manufacturer Samsung. ^{[footnote 142]}

These findings support the view that price is an important parameter of competition as it is important in users’ choice of mobile device and that Android users are more price sensitive than iOS users. This is consistent with the pricing evidence set out above where Android users generally purchasing lower priced devices with iOS users generally purchasing higher devices. This suggests limited competition and that, for example, for many Android users more expensive iOS devices are unlikely to be an alternative.

Overall, this evidence is consistent with there being limited price competition between devices using different mobile operating system and thus a limited competitive constraint on both Apple and Google from rival suppliers of mobile devices and operating systems (including each other). This is particularly the case in relation to smartphones, although for tablets there is clearly a more direct price comparator for Android in Amazon’s tablets. We consider this evidence on pricing in the round with the factors set out below to consider the constraint Amazon’s Fire OS places on Google’s Android.

Other parameters of competition

As set out above, other key parameters of competition relate to: (i) the features, functionality and performance of mobile devices; (ii) the available content in each mobile ecosystem; (iii) interoperability of devices; and (iv) brand.

As outlined above, it is clear that Apple, Google and others have improved the features, functionality and performance of their mobile devices and operating systems over time.

However, it is difficult to understand how high this level of innovation is and whether it could have been higher with greater competition. For example, in technological sectors such as mobile devices some improvements and innovations are likely to occur naturally as a result of exogenous improvements in efficiency and functionality (ie technological advancements in related or other technological sectors are likely to be applicable to mobile devices as well). Also, as highlighted above, such innovation may also be driven by the need to encourage users to replace existing working devices with an ‘upgrade’ ie Apple and others may to some extent be competing against older models of their own devices.

As it is unclear how strong the competition on features, functionality and performance is, we consider this in the round alongside other evidence on the strength of competition. We also note that to the extent that learning costs are a barrier to users switching (see next sub-section) these costs may increase if innovation leads to greater differences in the features and functionality of different mobile devices and operating systems.

As outlined above, the available content on a mobile ecosystem is important to users. However, from a user’s perspective, the evidence suggests that the available content on a device does not play a material role in driving whether a user chooses an iOS device or an Android device. This is because, as set out in Competition in the distribution of native apps, many of the same popular apps are available on both iOS and Android devices, as noted by both Apple ^{[footnote 143]} and Google, ^{[footnote 144]} and such app developers consider it necessary to list on both, given that both provide access to a large volume of unique users.

The only exception to this that we have identified to date is that we have heard some concerns around Apple’s first-party apps and services serving as a barrier to switching by users because they are not available on Android devices. We consider these concerns in the next sub-section.

We have received relatively limited evidence on the strength of competition on interoperability. In particular, we have mainly heard concerns around the lack of interoperability of Apple’s first-party connected devices which we consider in the next sub-section.

Finally, survey evidence shows that brand is an important factor in users’ decision making and that that more emphasis is put on the phone brand by Apple users than Android users. There is also limited switching between mobile devices with different operating systems. The importance of brand to users and the low level of switching may be driven by factors such as the high levels of customer satisfaction observed in the survey evidence. However, it can also be driven by barriers to switching which we consider in the next sub-section.

Barriers to switching between mobile devices with different operating systems

As set out above, users buying replacement devices do not generally switch mobile operating system, and this is particularly the case for Apple users.

Factors such as consumer interia, satisfaction with the characteristics of Android and iOS devices and brand loyalty may each help drive prevailing switching rates. In addition, barriers to switching may affect rates of switching. For example, certain factors may:

• cause users to perceive switching to be difficult or costly (for example, because they would pose a ‘hassle’), discouraging potential switchers; and

• impose actual costs on users that do switch (for example, financial costs, time costs or learning costs).

Perceived barriers to switching, which discourage switching, may have a greater direct impact on switching rates than some actual costs for users that do switch. However, it is relevant to consider actual costs because they are likely to reinforce perceived barriers to switching if or when users learn of them, from personal or second-hand experience.

Taken together, these barriers may reduce the threat to Apple and Google that users may switch mobile ecosystem, for example to make savings or access new features. This may lessen the competitive constraints that apply to Apple and Google. In response to the CMA’s questions, [a party] also told us that barriers to switching are asymmetrical, deterring switching from iOS to Android (and thus lessening the competitive constraints that apply to Apple) rather than vice versa.

Respondents suggested that users face 3 categories of potential barriers to switching between mobile devices with different operating systems:

• learning costs associated with switching mobile ecosystem

• transferring data, apps and managing subscriptions across devices

• the availability and characteristics of Apple’s and Google’s first-party (ie developed and operated by Apple and Google) apps, services, and connected devices

Below we assess whether these factors could act as perceived barriers to switching and if they could constitute a barrier by imposing actual costs on users who do switch. We also consider whether barriers to switching may have asymmetrical effect – for example, by discouraging switching from Android to iOS but not vice versa.

It is difficult to assess the individual impact of each of these factors on users’ propensity to switch between mobile devices with different operating systems. However, we consider that, in aggregate, they pose material barriers to switching. To some extent these barriers apply to switching both to Android and iOS, ^{[footnote 145]} although several appear more significant with respect to switching from iOS to Android:

• we consider that the learning costs associated with switching mobile ecosystems create perceived barriers to switching and impose actual costs on switchers. Survey evidence suggests that this perception affects both Android and iOS users, but is more widespread among iOS users

• transferring data, apps and managing subscriptions across devices may impose significant time and financial costs on users switching to a different operating system. These costs apply to switching to Android and iOS, but fall more heavily on switching to Android

• the availability and characteristics of Apple’s first-party apps, services and connected devices pose significant barriers to switching to Android

These 3 types of barriers to switching are considered in more detail below.

We recognise that barriers to switching may, in some cases, be a natural part of any process of switching mobile device and ecosystem. Some barriers may also be the result of competitive differentiation between mobile ecosystems or of enhancements to devices. However, in other cases barriers to switching may have no such justification.

Learning costs associated with switching mobile operating systems.

Users may need to adapt to different controls, functionality, and features if they switch to a different operating system. Users considering switching may perceive this as a ‘hassle’ that would discourage them, while users who switch may incur time costs learning to adapt to a different device. ^{[footnote 146]}

Several respondents considered that learning costs are a perceived barrier to switching and affect those who do switch. They agreed with Microsoft’s view that operating systems differ in terms of their physical features, design, controls and functions and that adapting to this can be time-consuming and burdensome.

Apple stated that, while users may need to learn about different settings and button uses on different operating systems, such learning costs ‘would appear to be moderate’ due to the ‘high availability of video tutorials’ and because apps have versions on both Android and iOS.

Survey evidence indicates that, in 2017, [20% to 30%] of UK iOS users would have been concerned about finding it difficult to learn to use a new brand of device or operating system. [10% to 20%] of Android users felt this way.

In Q3 2020, [60% to 70%] of UK iOS users considered knowing ‘how to use their phone’ as an important influence on their purchasing decision (the most important factor for iOS users). By contrast, [40% to 50%] of Samsung users rated this factor as important and just [10% to 20%] of Huawei users.

The available evidence suggests that the learning costs associated with adapting to the different controls, functionality and features of an operating system could create the perception that switching will be difficult or a hassle, and impose time costs on switchers. Survey evidence suggests that these barriers are perceived more widely among iOS than Android users.

The extent to which learning costs deter switching may depend on, for example, users’ confidence in drawing on available tutorial information and their broader digital literacy. Some users may not consider learning costs a deterrent to switching, while they may be a significant deterrent to those least confident in their ability to adapt to a new device.

Transferring data, apps and managing subscriptions across devices.

As detailed below, multiple respondents set out views on whether challenges to transferring data, apps and managing subscriptions could constitute barriers to switching between iOS and Android.

First, some parties suggested that data held by apps and services (such as contacts, text messages and in-game progress), and data about which apps a user had installed on their prior device, may be unavailable to users after switching devices. Several app developers suggested that, while guidance, switching apps and tools are available to enable users to transfer their data, these options may not be effective in all cases. Microsoft considered that some users remain within the same ecosystem to ensure they do not lose data or have to make complicated data transfers.

[Parties] also submitted different views on the availability and effectiveness of switching apps intended to transfer users’ data to a new device. In response to our requests for information on this issue, [a party] informed us that Apple offers the Move to iOS app on Android, which can transfer users’ data to an iOS device, including data about which apps were installed on the user’s Android device (accessible via an Android API). However, there does not appear to be a mechanism through which a third-party switching app can reliably obtain data on which apps a user has installed on their iOS device. We have also heard that, under Apple’s App Store policies that preclude references to other mobile platforms, names such as Move to Android may not be permitted. Apple stated that multiple apps are available on the App Store to transfer iOS users’ data to a new device. ^{[footnote 147]}

Second, some app developers suggested that policies in relation to the use of Apple’s and Google’s proprietary systems for in-app purchases may cause some users to have to repurchase or resubscribe to paid-for apps and in-app content after switching. Parties commented that Apple prevents developers from requiring users to link developer accounts to their Apple ID. While app developers can prompt users to link their accounts, if users choose not to do so developers have no means to know whether switchers to Android have paid for a subscription on iOS. Parties did not raise equivalent concerns about Android. Google stated that Google Play’s billing system policies do not constrain developers from requiring app users to link their Android app to a developer account, which they can access from an iOS device if they choose to switch.

Third, some app developers stated that users still may not be able to manage (for example, upgrade or cancel) pre-existing subscriptions to paid-for apps and in-app content after switching to a device that uses a different operating system, even if they have recovered access to their paid-for in-app content. As such, a user may need to cancel subscriptions on their prior device before switching and re-purchasing them. [One developer] stated that some users may be charged for subscriptions they cannot use if they switch from an iOS to an Android device before cancelling / managing a subscription they have bought through Apple’s in-app payment system (Apple IAP). Epic Games noted that switchers may have, for example, multiple annual subscriptions bought on iOS that expire at different times, necessitating their cancellation and re-purchase because they would not be manageable on Android. Apple stated that neither subscriptions bought through Apple IAP nor Google Play can be transferred to the other company’s billing management system after switching. It considered that users would understand the need to cancel their current subscriptions and re-subscribe through another provider.

Survey evidence suggests that loss of access to data and to apps may deter switching, in particular to Android. For example, in 2017, [20% to 30%] per cent of iOS users would be concerned about losing the data on their phone, while [10% to 20%] of Android users agreed.

We consider that these factors pose barriers to switching that may affect a significant number of users, by causing them to perceive switching to be difficult or by imposing costs on switchers. In aggregate the barriers apply to both switching to Android and iOS, but fall more heavily on switching to Android:

• on balance it appears likely that a significant number of users could find it – or be concerned that it may be – difficult or impossible to transfer data such as contacts, messages, and passwords to a new device. While some users may feel confident using guidance, switching apps and tools to manage this process, others will not and may find that these approaches do not transfer all the data that they require to their new device reliably. This may discourage switching or impose for example, time costs on switchers as they resolve any resulting issues. Survey data indicates that both Android and iOS users perceive that switching could impose such costs, but that this perception is more widespread among iOS users. We will continue to explore the effectiveness and availability of switching apps in the second half of our study

• with respect to whether having to repurchase or resubscribe to paid-for apps or in-app content after switching may be a barrier to switching: responses suggested that Apple’s policies in connection with the use of IAP (and in particular, the fact that app developers cannot require users to link their app developer account with their Apple ID) contribute to the likelihood that switchers will be unable recover their paid-for apps and content. As set out in Competition in the distribution of native apps, iOS users have no alternative to Apple IAP to purchase paid-for apps or in-app content. It appears that Google Play’s billing system policies do not constrain developers from requiring users to link their Android apps to developer accounts, so that users can more easily recover paid-for apps and in-app content after switching

• nevertheless, the characteristics of both Apple IAP and Google Play’s billing system cause those switching devices to lose a significant degree of control over the ability to manage subscriptions bought on another mobile ecosystem. This could impose significant time costs for some users as they migrate subscriptions to their new device, plus financial costs where this process requires them to re-purchase for example, annual subscriptions

As discussed in detail in The role of Apple and Google in competition between app developers, Apple’s restrictions on cloud gaming services may help to maintain some of these barriers to switching. Cloud gaming services work across platforms and involve streaming games from the cloud to users’ devices, rather than relying on the processing power or storage of the device to run games. This means that a user of such services who switched from a high-end iPhone to a low-end Android phone would be able to access the same games at the same quality before and after switching. By restricting the availability of these services on its App Store, Apple may be obstructing a development in how users can access games, which could make switching from iOS to Android devices easier.

The availability and characteristics of first-party apps, services and connected devices.

We received a range of evidence and views from stakeholders on whether the availability and characteristics of first-party apps, services and devices could pose barriers to switching.

First, some parties highlighted that almost all of Apple’s first-party apps and services (including for example, iMessage) are unavailable on Android devices.^{[footnote 148]} Thus iOS users would lose access to them on their mobile device if they switch to Android. By contrast, Google makes many of its core first-party apps and services available to iOS users. Apple stated that investing in developing first-party apps and services only for Apple’s own products enables it to offer a better user experience. It considered that the availability of Apple’s apps and services solely on Apple’s products serves to differentiate them in the competitive device market. Apple also stated that these apps and services may not generate any revenue in themselves, so that it would be irrational to offer them on competing mobile devices.

Second, we heard concerns that users of multiple Apple devices may lose access to shared functionality between first-party apps, services and connected devices. For example, we understand that some first-party connected devices (for example, Apple Watch) cannot be used in conjunction with Android devices, while some apps and connected devices offer limited functionality when used on or with Android devices (for example, AirPods). Apple stated that its connected devices offer interoperability with third-party devices and services to the extent possible and are operable on a standalone basis.

Third, users may have a worse experience of interacting with friends’ and family’s Apple devices after switching. For instance, Android users sending number-based interpersonal messages to iOS users will reach the iOS device via Short Message Service (SMS) / Multimedia Messaging Service (MMS) technology, because Apple has not adopted the Rich Communications Standards (RCS) protocol for iMessage. By contrast, iOS users may send number-based messages to other iOS users via a faster, encrypted iMessage service that permits functionality (for example, message effects) unavailable when communicating with an Android user. In response to the CMA’s questions, we heard that Apple’s practices impair communications sent between non-iOS device users and iMessage users via SMS / MMS.^{[footnote 149]} Apple suggested that it has not adopted the RCS protocol for number-based messaging because RCS is a new technology and it is unclear how effective it will be. Apple noted that alternative third-party messaging services are available on Android and iOS. Parties also reported that iOS users may also need to manually disable iMessage, via their iOS device or online, to be able to receive messages sent to their number on an Android device.^{[footnote 150]}

As set out above, survey evidence that we have received suggests that a significant minority of users consider access to Apple’s first-party apps and the compatibility of iOS devices with other Apple devices when making purchasing decisions. For example, in a 2020 survey, [40% to 50%] of UK iPhone buyers stated that it was extremely important to their smartphone purchasing decision that Apple products work well with other Apple products. A 2021 survey for [a party] found that 33% of UK iPhone users stated that the device working with their other devices was a reason to choose iOS.

When considered together, these factors appear to pose barriers to switching from iOS to Android, which may cause many iOS users to perceive switching to be difficult or impose costs on switchers. The availability and characteristics of first-party apps, services and connected devices do not appear to be a barrier to switching from Android to iOS:

• the limited availability of Apple’s first-party apps and services on Android is likely to make switching less attractive to many iOS users. Broadly we do not consider that this is also likely to, for example, make switching appear difficult or imposes costs on switchers. However, the unavailability of apps such as iMessage on other operating systems is likely to contribute to other barriers to switching, set out below

• losing access to shared functionality between first-party apps, services and connected devices poses a barrier to switching for users who own multiple Apple devices and would, for example, no longer be able to use an iWatch or lose access to certain AirPods functionality (in some cases this may be the result of technical constraints on rolling out functionality interoperable with Android devices). Given the high proportion of iOS users that own multiple Apple devices and the potential replacement cost of devices such as smart watches, this barrier is likely to affect a significant number of users

• the diminished experience of interacting with friends’ and family’s Apple devices after switching – and features of iMessage in particular – also pose barriers to switching. The potential for users who do not disable their iMessage account to have difficulties using a new device for number-based messaging is a significant barrier. Apple’s approach of not adopting further potential interoperability with number-based messaging on Android devices (which iOS users may wish to receive) could also serve to diminish the experience of switchers to Android

Competitive constraint from potential suppliers of mobile devices or operating systems

We have also considered the extent to which Apple or Google are constrained by the threat of entry or expansion by competing suppliers of mobile devices or operating systems. In doing this we focus on both demand-side and supply-side barriers faced by potential entrants.

In this section, we briefly discuss the barriers to entry that potential suppliers of devices might face before then discussing in detail the barriers to entry faced by potential suppliers of mobile operating systems. The evidence suggests that, while the barriers faced by suppliers of mobile devices are not insurmountable, new entrant mobile operating systems face significant barriers to entry and expansion.

This is illustrated by the exit/failed entry of well-resourced companies in smartphones such as Microsoft and Amazon. The presence of barriers to competition is also shown by the difficulties faced by those using versions of Android without Google Mobile Services – for example, Huawei’s share of new sales declined materially after it could no longer access Google’s apps and services, including Google Mobile Services.

Barriers faced by suppliers of mobile devices

In theory, both Apple and Google could face a competitive constraint from new suppliers of mobile devices entering and attracting users. We have assessed the demand-side or supply-side barriers to entry that may exist below.

Manufacturers have told us that new suppliers of mobile devices face the following demand and supply-side barriers to entry and expansion:

• economies of scale in the manufacturing process

• upfront and ongoing R&D costs that are needed to develop and maintain innovate mobile devices to attract users

• ensuring the device comes with a wide variety of apps and services

• brand loyalty to existing brands, especially as the high level of device ownership means growth can most easily be achieved by attracting existing users from another brand

Overall, these barriers do not seem insurmountable if manufacturers are willing to use the Android operating system which, as outlined above, is the only licensable operating system in the UK. For example, Huawei is an example of a relatively new entrant in the UK that was able to grow to have a material share in the UK – peaking at [0% to 10%] of active smartphones in 2019 as can be seen in Figure 3.7 above. Other new entrants such as Xiaomi, OPPO and OnePlus were also identified by manufacturers, but so far appear to have a fairly small share in the UK. ^{[footnote 151]}

However, if a new supplier entered using the Android operating system then this would not place a constraint on Google at the operating system level. In addition, it is not clear that such new entrants are exerting a material constraint on Apple. In particular:

Manufacturers also identified existing brand loyalty and barriers to users switching as barriers to entry and expansion. As outlined above, Apple users are less likely to switch operating system than Android users and Apple users also face higher barriers to switching.

As shown in Figure 3.8, Apple has maintained its share of active smartphones over time despite increasing prices and a widening price gap with most other smartphones (as shown in Figures 3.1 to 3.3) and while its share of active tablets has declined slightly over time it has been between [50% to 60%] (as shown in Figure 3.11).

Barriers faced by suppliers of mobile operating systems

In this section we consider the barriers faced by potential suppliers of mobile operating systems. In particular, we consider:

• barriers arising from the development and maintenance of the underlying software needed for a mobile operating system

• barriers arising from the need to attract users and app developers to use an operating system

• barriers arising from the need to attract manufacturers to adopt an operating system

Overall, we consider that new entrant operating systems face material barriers to entry and expansion for the reasons outlined below. These barriers generally reinforce each other and are also reinforced by the material barriers to user switching outlined above, which make it more difficult for any new entrant to attract users away from their existing operating system.

As outlined above, these barriers are asymmetric with Apple users, who account for over 50% of both active smartphones and tablets, facing higher barriers to switching. In part this is due to the commercial decisions Apple has made in relation to its first-party apps, services and connected devices.

The existence of barriers to entry in the supply of mobile operating systems is consistent with evidence from [an Android device manufacturer], which highlighted the costs and uncertainty associated with developing mobile operating systems. They are also illustrated by the exit/failed entry of well-resourced companies in smartphones such as Microsoft and Amazon. Therefore, we consider that there are significant barriers to entry in the provision of operating systems, including for well-established device manufacturers and well-resourced companies.

The development and maintenance of a mobile operating system

There are significant economies of scale to providing a mobile operating system. Developing a completely new operating system requires significant time and financial resources and maintaining it so that it stays competitive (for example, via frequent updates and improvements) is also very resource intensive. Moreover, attracting interests from users, developers and manufacturers requires significant marketing efforts.

The existence of such economies of scale was confirmed by operating system providers. For instance:

• Huawei told us that there are barriers to entry and expansion in the provision of mobile operating systems, including the need for long-term technical efforts and substantial financial investment

• Amazon told us it invested significant time and resources in the development of Fire OS, the devices that run it, and the apps that run on it

• Apple told us that the investments it has made in iOS have amounted to ‘billions of dollars’ and that ‘[a] material part of these costs is fixed and unlikely to vary much with the number of users/app developers’

Indirect network effects

As outlined above, operating systems exhibit indirect network effects – the benefit to users of an operating system currently increases with the volume and quality of native apps they can access on that operating system, and similarly the benefit to app developers increases with the number of users they can access on an operating system.

The presence of indirect network effects is likely to act as a particular barrier to new entry and expansion as it creates a ‘chicken and egg’ problem – an operating system needs a critical mass of users to attract app developers, but also need a critical mass of app developers to attract users.

This is reflected in the views and evidence of market participants as set out above in the discussion of the parameters of competition above.

As set out in Competition in the distribution of native apps, evidence indicates that many app developers, particularly the most popular app developers accounting for the majority of downloads, make their native apps accessible on both iOS and Android. However, other mobile operating system providers submitted that obtaining a wide range of native apps, including the most popular and successful native apps, can be very difficult for new operating systems, thus constituting a barrier to entry. As set out below, this is also compounded by a lack of access to GMS which includes many of Google’s popular apps.

Overall, this means that iOS and Android, who have large app ecosystems, benefit from large indirect network effects. These indirect network effects act as a barrier to entry and expansion for alternative mobile ecosystems who cannot offer the same app ecosystems and thus struggle to attract users and app developers. ^{[footnote 152]}

In theory, these indirect network effects could be mitigated to some extent by web apps and cross-platform development tools. This is because both allow app developers to make their content available on multiple operating systems without having to develop native apps for each operating system. If web apps and cross-platform development tools were widely adopted, this could make it easier for new entrants to quickly gain access to a large volume of quality content without relying on app developers to incur the costs of developing native apps.

However, we do not consider either of these options currently reduce barriers to entry and expansion for operating systems. In particular:

• as outlined in Competition in the supply of mobile browsers, web apps are not currently comparable to native apps in terms of features, functionality or performance, though we understand this is to a large extent due to restricted functionality available through Apple’s WebKit browser engine. Therefore, only attracting web apps as a form of providing content is not currently an option for new entrants, and as such the functionality of Apple’s WebKit browser engine reinforces the position of Apple and Google in mobile operating systems ^{[footnote 153]}

• as outlined in Competition in the distribution of native apps, currently app developers appear to prefer developing separate native apps for each operating system to using cross-platform tools^{[footnote 154]} for a number of reasons, including that they consider native apps are better optimised for each operating system. In addition, for cross-platform tools to be effective in enabling the entry of a new operating system, the cross-platform tool would have to increase the range of operating systems it covers to include the new operating system

Attracting manufacturers

Any new entrant seeks to license its mobile operating system would also have to attract third-party manufacturers. We set out in this sub-section why new entrants are unlikely to be able to attract manufacturers away from Google’s version of Android. In doing this, we first set out manufacturers’ agreements with Google, and in that context we then consider:

• the barriers arising from financial incentives offered by Google to device manufacturers

• the barriers arising from the presence of indirect network effects

• the impact of Google’s historic compatibility agreements

Context: Google’s agreements with manufacturers

Google has a series of agreements with manufacturers of Android devices – our understanding of the hierarchy and relationship between these agreements is set out in Figure 3.13 below.

First, Google licenses the ‘Android’ trademarks to manufacturers to use on mobile devices conditional on those mobile devices meeting Google’s compatibility criteria. ^{[footnote 155]} Manufacturers who then want to license any of Google’s other apps and services relating to the Android operating system need to enter Google’s Android Compatibility Commitment (ACC) under which they agree to maintain compatibility with a baseline version of Android. ^{[footnote 156]}

Google told us it sought compatibility commitments when Android was nascent and the CDD’s compatibility requirement incentivised developers to write apps for Android, improved the availability and reliability of Android apps and enabled Android to compete better with iOS and other operating systems to attract developers.

Second, Google allows manufacturers to license Google Mobile Services (GMS), a collection of popular Google apps including Play Store, Google Maps, YouTube, and Gmail as well as a selection of Google proprietary APIs (or Google Play Services). If a manufacturer wants to pre-install one of Google’s apps included in the GMS suite then the manufacturer has to pre-install all of them and place the Play Store on the default home screen and the rest of the apps in a ‘Google’ folder on the default home screen.

As noted above, the GMS suite includes the Play Store, which is an important app as through this, manufacturers can provide users with access to a large volume of native Android apps which, as set out in Competition in the distribution of native apps, cannot currently be replicated by other Android app stores. In addition, both Google’s apps and APIs included in Google Mobile Services are important for ensuring that many native Android apps operate as they should do as outlined below.

GMS is licensed through the European Mobile Application Distribution Agreement (EMADA) and is conditional on the manufacturer using a compatible version of Android and entering Google’s ACC. Manufacturers also need to pay a license fee per activated device as set out in Appendix E and we understand from Google that it receives revenue from this EMADA license fee and incurs costs through its Placement Agreements as described below. We understand from Google that these sources of revenues and costs together represent a net cost.

Third, Google allows manufacturers in the UK to separately license Google Search and the Google Chrome browser. Licensing these 2 apps is conditional on the manufacturer entering Google’s ACC, thus using a compatible version of Android, and the EMADA.

Fourth, Google offers EMADA partners payments, both fixed payments per activated device and revenue shares. These payments are conditional on the manufacturer entering the EMADA (and thus the ACC) and compliance with certain requirements in relation to Google apps such as Google Search, Google Chrome and (in some cases) the Play Store.

Payments from Google to device manufacturers are made through the following agreements:

• placement agreements: these are per-device ‘activation payments’ for each device on which manufacturers pre-install the Google Search or Google Search and Chrome apps and satisfy certain placement obligations for either Google Search or both

• revenue sharing agreements:

  • Google shares a proportion of net advertising revenue from specific search access points on manufacturers’ devices in return for meeting a number of placement and promotion requirements relating to Google’s apps including Google Search and Google Assistant such as setting the Google Search app as the default search engine on all preloaded manufacturer browsers.^{[footnote 157]} The proportion of revenue shared with the manufacturer increases the more requirements that are met by a device

  • Google shares a proportion of net revenue from Play Store transactions where devices meet certain additional requirements in relation to the Play Store, namely setting the Play Store as the default app store and not preloading similar services, such as alternative app stores, on those devices.

Figure 3.13: Hierarchy of Google’s agreements with manufacturers

Figure description: The diagram is an illustration of the hierarchy of Google’s agreements with manufacturers. The diagram shows four main categories of agreements. These are: Compatibility agreements, which Google use to make sure manufacturers use a compatible version of Android on their devices; Agreements under which Google licenses its proprietary apps and APIs to manufacturers, meaning European Mobile Application Distribution Agreements (EMADA); Google Search and Chrome license agreements; and agreements under which Google makes payments to manufacturers, meaning Revenue Sharing Agreements (RSA) and Placement Agreements. The diagram shows that entering a category of agreements is conditional on having entered the previous one, meaning that manufacturers can only get payments if they license Google apps and APIs and can only license them if they use a compatible version of Android.

Source: CMA analysis.

Google told us that ‘RSAs reflect the normal competition’ between apps (and app stores) to seek promotion on manufacturers’ devices. It also told us that this competition better enables manufacturers to ‘monetise the screen space on their devices’ and thus leaves them with ‘more funds to invest in new and improved handsets (or to facilitate lower prices)’ and to ‘offer a user interface that competes closely with Apple’s ‘clean’ out-of-the-box set-up’.

Barriers arising from financial incentives offered by Google to device manufacturers

Google’s revenue share agreements all include setting Google Search as the default search engine on all preloaded manufacturer browsers. This allows Google to generate revenue from selling search advertising which it then shares with manufacturers (via its revenue sharing agreements), with the amount of revenue that is shared increasing in the number of search access points that are covered.

We understand from Google that the revenue it generates from the EMADA license fee is lower than the cost it incurs through the Placement Agreements – ie together they represent a net cost. This, combined with the revenue sharing agreements means that Google effectively pays manufacturers to use its operating system. As such a new entrant could not charge a fee for its operating system and entry would only be rational if the new entrant could monetise the operating system in another way – ie through monetising the default position at search access points. However, due to the strength of Google’s position in search engines and search advertising, Google is better able to monetise and can profitably make significant payments to manufacturers that new entrants, who would not have an equivalent position, are unlikely to be able to replicate.

In the market study into online platforms and digital advertising, the CMA found that:

• Google has significant market power in the general search sector, having had a share of supply of around 90% or higher in the UK for more than a decade, and in search advertising, where it accounts for over 90% of search advertising revenues ^{[footnote 158]}

• Google’s market power in search advertising has allowed it to charge higher prices to advertisers than its competitors – on a like-for-like basis, Google’s prices are on average [30% to 40%] higher on mobile devices than its main rival Bing ^{[footnote 159]}

• having been by far the largest search engine for more than a decade, Google benefits from higher perceived quality among many consumers, can generate more search advertising revenues from a given default and is able to pay more for default positions than other search engines ^{[footnote 160]}

Google is able to use its market power in search engines and search advertising in order to protect its position in mobile operating systems (and native app distribution as set out in Competition in the distribution of native apps). This in turn allows it to reinforce its position in search and search advertising. In particular:

• the revenue sharing agreements are conditional on manufacturers using a compatible version of Android and licensing Google’s apps and APIs included in Google Mobile Services (including the Play Store) which are important for ensuring that many native Android apps operate as they should. This ensures that manufacturers only receive a portion of Google’s revenue if they use Google’s version of Android and a core set of Google’s apps, (including the Play Store and all the other apps included in GMS) ^{[footnote 161]} are pre-installed on their devices

• Google’s extensive pre-installation and default positions, including via placement agreements and revenue sharing agreements, act as a significant barrier to expansion for rival search engines, by limiting their ability to access consumers, build their scale and grow into stronger competitors over time, as set out in the CMA’s market study into online platforms and digital advertising market study ^{[footnote 162]}

• the revenue sharing agreements also reinforce Google’s position in search advertising. This is because manufacturers’ use of Android allows Google to access extensive first-party data which is likely to give it a substantial advantage over smaller rivals in advertising, creating a barrier to entry and expansion as set out in the CMA’s market study into online platforms and digital advertising ^{[footnote 163]}

Given that rivals are unlikely to be able to replicate the payments Google makes to manufacturers, switching away from Android would entail manufacturers missing out on significant financial benefits that are paid for pre-installing or meeting certain requirements in relation to Google’s apps such as Google Maps, Gmail, YouTube Google Search, Google Chrome and the Play Store, which are all very popular with users.

In addition to the costs associated with foregoing Google’s revenue sharing agreements, manufacturers would incur further costs when switching away from Android. Specifically, manufacturers incur certain ‘integration costs’ when optimising their devices for a new operating system.

This is illustrated by [REDACTED].

Barriers arising from the presence of indirect network effects

We outlined above how mobile operating systems exhibit strong indirect network effects between users and app developers. These indirect network effects mean that the value of an operating system to a manufacturer increases with the number of users of that operating system and the volume and quality of native apps available from app developers. ^{[footnote 164]} In particular:

• while an alternative operating system may be able to replicate some of the factors users care about (for example, in terms of the features and functionality they offer) if an alternative operating system is only able to offer users a limited app selection then the operating system is less attractive to users and in turn manufacturers who would find it harder to attract users to their devices

• similarly, while factors that app developers care about could be matched by rival operating systems (for example, in terms of development tools) if an alternative operating system is only used by a lower volume and value of users then the operating system is less attractive to developers and in turn manufacturers who would find it harder to ensure their devices provide access to a larger volume of high native apps, including the most popular and successful native apps

This means that Android is highly attractive to manufacturers as:

• a large number of users are familiar with it – in the UK in 2020 there were [30 to 40] million active Android smartphones and [5 to 10] million active Android tablets

• it provides easy access to a large volume of native apps, including the most popular and successful native apps – in the UK in 2020 there were [800,000 to 900,000] app developers making a total of [2.5 to 3] million native apps available on Android devices through the Play Store

Other than Apple’s iOS, which Apple does not license to third parties, no other mobile operating system could provide manufacturers with access to such a large number of users or such a large volume of native apps, including the most popular and successful native apps.

In theory, the fact that Android is open source and can be used to start a new operating system makes entrants using a version of Android better placed than other new entrants to overcome this barrier and thus a more credible option for manufacturers. However, Google’s agreements set out above are a barrier to this.

Specifically, the licence of Google Mobile Services (which encompasses important Google apps and Google APIs), is conditional on the manufacturer using a compatible version of Android and this has 2 implications.

The licensing of Google’s core apps being conditional on meeting Google’s compatibility criteria means that Android Forks do not have access to Google’s popular native apps (although they are still available through web browsers). Manufacturers told us that the availability of popular apps, and in particular Google apps, ideally pre-installed ‘out-of-the box’, is an important success factor for a given mobile operating system. For example:

• Samsung told us it stopped using Microsoft Windows OS because consumers were increasingly familiar with Android and expected it, ‘as well as the huge range of apps and functionalities offered by the wider ecosystem’ which Microsoft Windows ‘could not match’

• as noted above while Huawei uses a version of Android that meets Google’s compatibility requirements, US legislation in May 2019 means that Huawei can no longer access Google’s apps and services, including Google Mobile Services. Huawei provided a research report according to which the absence of Google Mobile Services (GMS) and the Play Store was a significant factor in the perception of success of its products by customers. Huawei also told us that user perception of its devices may be negatively affected by the fact that [REDACTED]

• Amazon told us that customers expect a certain ‘out of the box’ experience with popular and desirable apps pre-installed on their device and that some of the most popular apps are Google apps such as Google Maps and YouTube, which are included in the GMS suite

Similarly, Apple said that Huawei’s shipment of devices dropped sharply, after Huawei was no longer able to use the Play Store and popular Google apps, such as YouTube and Gmail, in May 2019. Apple noted that smartphone sales data showed Huawei’s share plummeting from above 20% at the beginning of 2019 to below 2% in 2021.

In relation to these apps, Google told us that it does not license its native apps for mobile devices that use version of Android which fail to meet its compatibility requirements, but that they are accessible through web browsers on such devices. Google said that this was because there is a material risk that its apps would not run properly on such devices and that this would harm its reputation. We understand US sanctions may prevent the licensing of its apps to Huawei and, as outlined above, Huawei told us it lost access to GMS following US legislation in May 2019.

GMS also includes important APIs. As set out in The role of Apple and Google in competition between app developers, APIs are technological specifications that enable app developers to gain access for their apps to the mobile device’s hardware features, such as a camera or location services, or to particular services and other apps installed on the device. On Android devices, some of these APIs are housed in the Android open source code and some in GMS.

Where relevant APIs are housed in GMS it means that, to access relevant hardware or services, native Android apps have to integrate with Google’s apps (for example, to provide mapping functionality based on Google Maps) or Google’s APIs (for example, to provide push notifications). Where this is the case such features and functionality do not work on devices running versions of Android that do not use GMS.

This means that many native Android apps may not function properly on versions of Android without Google Mobile services. For example, Huawei told us that its smartphones sales revenue dropped [materially for both smartphones and tablets] between 2019 and 2020. According to Huawei, this was primarily attributable to the lack of availability of apps that rely on Google Mobile Services on newer models of Huawei smartphones and tablets – these apps were not available as from May 2019 Google Mobile Services could not be pre-loaded on these Huawei devices nor downloaded after purchase.

Similarly and as outlined above, Amazon’s Fire Phone was launched in the UK in September 2014, but exited smartphones a year later. ^{[footnote 165]} The Fire Phone used Amazon’s Android Fork Fire OS and it has been reported that the inability to offer the GMS suite of apps, made it difficult for its Fire Phone to successfully compete. ^{[footnote 166]}

Given the importance of GMS and the Google APIs it includes, we are also concerned by claims that over time Google has chosen to include important features and functionality in GMS rather than the open-source Android code. For example, a complaint filed by the Department of Justice in the US states that the APIs allowing basic ‘push notifications’ are included in Google Mobile Services rather than the open-source Android code. To the extent that more features and functionalities are included in Google Mobile Services this increases the reliance of native Android apps on Google Mobile Services making it more difficult to port them to versions of Android without Google Mobile Services. ^{[footnote 167]}

Google said that whether or not a device manufacturer chooses to license Google Mobile Services on top of Android does not alter the availability of Android or any of its features. Google also submitted that GMS includes APIs which enable third-party services to communicate with Google’s services (for example, Google Maps) and create feature-rich apps. On the latter, Google said housing such APIs in GMS allows Android devices to have the most up to date version of these APIs, ensuring that apps rely on these APIs work on all Android devices with GMS, even when the manufacturer does not update the underlying Android operating system version.

In relation to where an API is placed, Google submitted there are reasons for including an API in GMS and not in open-source Android code, including the extent to which the technology they use is proprietary to Google, the frequency of updates they need, etc. More specifically, Google submitted that [REDACTED].

We will consider these concerns and the reasons why Google includes APIs in either Google Mobile Services and open-source Android code further in the second half of our study.

Impact of Google’s historic compatibility agreements

Finally, as set out above, manufacturers that want to license Google Mobile Services need to enter an agreement called the ACC whereby, in the UK and EEA, manufacturers can distribute Android Forks alongside compatible versions of Android (subject to certain branding requirements). The ACC replaced Google’s Anti-Fragmentation Agreements, which were deemed to be anti-competitive by the European Commission in its Android Decision as they hampered the development of Android Forks. ^{[footnote 168]}

The provisions considered to be problematic were those that obliged manufacturers not to fork Android and not to distribute any devices using Android Forks alongside devices running on Google-compatible versions of Android.^{[footnote 169]} Consistent with this we have received evidence that these Anti-Fragmentation Agreements historically prevented manufacturers from using alternative operating systems. [REDACTED]

In summary, most manufacturers use Android for their devices given it is widely used by both users and app developers and required for accessing Google’s apps and services. Furthermore, as explained in Appendix E, there are significant financial benefits associated with compliance with certain promotion and placement requirements in relation to Google apps in Google’s agreements with manufactures, which further reduce their incentive to switch away. There is also evidence that Google’s previous Anti-Fragmentation Agreements historically prevented manufacturers from using alternative operating systems.

As a result, we consider that new entrant operating systems, including those using versions of Android that do not use Google Mobile Services, would find it very difficult to attract manufacturers away from the Android operating system in order to enter and compete with Apple and Google.

Key findings relating to mobile devices and mobile operating systems

We have found that Apple and Google have an effective duopoly in the provision of operating systems that run on mobile devices:

• because Apple’s iOS is only used in Apple devices Apple’s share of mobile devices mirrors its share of mobile operating systems. Apple is the largest manufacturer of mobile devices and has a share of [50% to 60%] of active smartphones as well as [50% to 60%] of active tablets in the UK

• in contrast, Google has a small presence in mobile devices with most Android devices being manufactured by third parties. Google’s Android is the second largest mobile operating system and with Android devices accounting for around [40% to 50%] of all active smartphones and between [20% to 30%] of active tablets in the UK in 2020

We have found that there is limited user-driven competition between mobile devices using different operating systems. This is because most users purchasing a device are buying a replacement device and rarely switch between operating system. Also, as detailed earlier in this chapter, there is limited price competition between iOS and Android devices, with Apple’s iOS devices dominating sales of high-priced devices and mobile devices using Android dominating sales of low-priced devices.

There are also material barriers to switching between devices using the iOS and Android systems, and we have observed certain issues relating to the transfer of data and content when a user switches device, including some that arise due to the requirements to use of proprietary in-app payment systems. These switching costs are asymmetric, with iOS users generally facing higher switching costs than Android users due to factors including Apple’s first-party apps, services and connected devices.

In addition, Apple and Google both benefit from material barriers to entry and expansion faced by rival providers of operating systems. This includes:

• barriers that are intrinsic to the product in question such as strong indirect network effects and economies of scale in the development and maintenance of mobile operating systems

• barriers that result from Google extending its market power. Google’s agreements with manufacturers mean that any new entrant looking to attract manufacturers would have to financially compensate manufacturers and offer them a range of attractive alternative options to Google’s first-party apps and services – in addition, even a new entrant using a version of Android without Google Mobile Services would lose access to many Android apps due to the loss of Google’s APIs

• barriers that result from the barriers to users switching between mobile ecosystems. In particular, these barriers are asymmetric with Apple users, who account for [50% to 60%] of active smartphones and [50% to 60%] of active tablets, facing higher barriers to switching. In part this is due to the commercial decisions Apple has made in relation to its first-party apps, services and connected devices

These findings support our initial conclusion that both Apple and Google have substantial and entrenched market power over the users of their mobile operating systems. Given Apple’s business model, this conclusion relates to its devices and operating system in combination.

4. Competition in the distribution of native apps

Key findings

• The App Store on iOS and Play Store on Android accounted for over 90% of native app downloads between them in the UK in 2020. The limited competitive constraints placed on them mean that Apple and Google each have substantial and entrenched market power in the distribution of native apps within their ecosystems.

• Apple prohibits all alternatives to the App Store for native app distribution on iOS, giving it a monopoly over native app downloads on its devices. Google allows alternative distribution channels, yet the Play Store retains over 90% of native app downloads across Android, HMS, and Fire OS devices, in part due to material barriers to entry and expansion faced by rival app stores.

• Current development and usage of web apps is substantially lower than native apps, and they are not regarded currently as a viable alternative by many app developers. We understand that this is in large part down to restrictions on functionality within Apple’s ecosystem, which could undermine the incentives to develop web apps across both ecosystems.

• The App Store and Play Store place a limited competitive constraint on each other. The largest app developers are available on both and see them as complements rather than substitutes due to their size and because most App Store users do not use the Play Store and vice versa. As noted in the chapter above, Apple and Google also face limited constraints from users switching between mobile ecosystems when buying a new device.

• Apple and Google face a limited competitive constraint from alternative devices such as PCs, laptops, gaming consoles and smart TVs. These devices are primarily used for different purposes and are mainly viewed by users as complements rather than substitutes, such that not being available on either iOS or Android devices is not an option for app developers.

• Through control of their app stores, Apple and Google are in a position to determine which apps are listed, ranked, and discovered. The average commission levels charged by Apple and Google on in-app purchases made through their own payment systems are close to 30%, from which they make substantial and growing profits (with high margins) from their app stores.

• Apple has blocked certain types of services on iOS altogether, such as cloud gaming services. There are further ways in which control of the App Store has enabled Apple to introduce policies and terms which may entrench its position of market power in relation to native app distribution, such as App Tracking Transparency. This policy may operate to the detriment of ad-funded apps, and push more users towards the App Store (where Apple derives a commission from users making in-app purchases). In certain areas such as this, we have found Google does not have as strict rules as Apple.

Introduction

This chapter sets out our preliminary assessment in relation to:

• the role of native app distribution in Apple and Google’s mobile ecosystems, including an overview of Apple’s App Store, Google’s Play Store, and other proprietary app stores available on Android devices, HMS devices, and Fire OS tablets

• key data on app store usage and revenue

• the competitive constraints faced by the App Store and Play Store from 3 sources:

  • first, the constraint from alternatives methods of accessing apps within each mobile ecosystem

  • second, the constraint on Apple and Google from the risk of losing consumers and app developers to each other’s app stores (that is, the indirect constraint that app stores across mobile ecosystems place on each other)

  • third, the constraint from alternative devices, such as PCs, laptops, games consoles and smart TVs, and the marketplaces associated with those devices

Role of app distribution in Apple’s and Google’s mobile ecosystems

Overview of the Apple App Store and the Google Play Store

As set out in Overview of mobile ecosystems, app stores are a gateway between mobile device users and app developers. That is, they are a way for: (i) app developers to distribute their products and services to users; and (ii) users to find and install native apps and engage with the products and services of app developers. As app stores serve to connect 2 different customer groups – users and app developers, they are a 2-sided platform. Further, as a user can only use a mobile app store after purchasing a mobile device, app stores and app distribution can be considered a secondary or after-market to the user market for mobile devices and associated operating systems (the primary or fore-market).

Native apps need to interact with the mobile operating system in order to provide their features and functionality, including to access relevant hardware features. The need for native apps to interact with the operating system gives operating system owners or controllers considerable influence over methods of native app distribution (and native apps more generally as considered in The role of Apple and Google in competition between app developers).

Apple and Google’s business models in relation to the App Store and Play Store

In the following paragraphs, we describe the role of the App Store and Play Store in the business models of Apple and Google.

Apple’s main revenue source comes from selling hardware and its associated operating systems. It also generates ‘services’ revenue from other sources, including the App Store through

• the commission charged in relation to app purchases and in-app purchases of digital content for third-party apps downloaded from the App Store

• advertising revenue generated through App Store Search Ads ^{[footnote 170]}

Apple submitted that its hardware revenue share is declining and that there is stable growth in the service aspects of its business. This growth is also reflected in our assessment of Apple’s profitability, in particular^{[footnote 171]} :

• In 2020, services accounted for approximately 34% of total gross profit globally, up from 24% in 2018.

• The services segment as a whole has substantially higher gross margins (66% in 2020) than those for Apple’s devices (32% in 2020) and its gross margins for services have been increasing over time.

• Within the services segment the App Store and Advertising (Third Party Licensing Arrangements and platforms) are the largest contributors to gross services income accounting for [75% to 100%] in 2020 and also had high gross margins of over [75% to 100%] in 2020.

Google generates the large majority of its revenue through selling digital advertising. The importance of the Play Store in Google’s business is increasing (accounting for approximately [0% to 20%] of global mobile revenue in 2020). This includes revenues from:

• the commission charged in relation to paid-for apps and in-app purchases of digital content for third-party apps downloaded through the Play Store

• advertising revenue generated through the Play Store

As set out in Appendix D, the Play Store also makes high margins.

Google submitted that its ad funded business model incentivises it to allow developers more methods to connect with users (for example, through third-party app stores, sideloading, web apps, websites) as the more ways users have to access content, the greater the amount of content they access and the more opportunities Google has to generate advertising revenues. ^{[footnote 172]} We consider below the extent to which users and app developers use such alternatives.

The development of native apps to work on iOS and Android devices

For software applications or ‘apps’ to work on an Apple mobile device, it has to interact with Apple’s iOS. Apple operates a ‘closed’ business model, meaning that the contents and code of the iOS system are not published, or directly available to app developers. Apple provides software and tools to app developers that allow them to write software that interacts with iOS, provided that they adhere to the terms contained in a number of agreements and guidelines. ^{[footnote 173]}

Android is open source, which means that any manufacturer could develop an operating system based on the open source Android code.^{[footnote 174]} Most Android devices are manufactured by third parties. As set out in Competition in the supply of mobile devices and operating systems, when using a Google-compatible version of Android, manufacturers are able to license the Android trademarks from Google as well as certain apps (for example, Play Store, Chrome, Google Search) and services. Google also provides software and tools to app developers that allow them to write software that interacts with Android.

Rules of access to the App Store and Play Store for app developers

In order to distribute apps on the App Store or Play Store, app developers must comply with the terms contained in a number of agreements and guidelines. Some of these documents are publicly available and some are confidential between the developers and Apple and Google.

• for access to the App Store, this includes entering into the Apple Developer Program License Agreement, joining the Apple Developer Program for an annual fee of $99 per year, and complying with Apple’s App Store Review Guidelines

• app developers who want to distribute apps on the Google Play Store must sign up for a Google Play Developer Account, accept the Google Play Developer Distribution Agreement and pay a one-time registration fee of $25. Among other things, the Google Play Developer Distribution Agreement requires app developers to comply with Google’s Developer Program Policies ^{[footnote 175]}

Aspects of these rules seek to promote and maintain the quality and safety of apps available in the respective app stores. For example, they include requirements about the content of apps; privacy (including the way in which apps collect customer data); and security.

Both the App Store and Play Store require that in-app payments relating to digital content must be made through their own proprietary payment systems, through which Apple and Google handle the processing of the transaction and also deduct a commission of up to 30% ^{[footnote 176]} before the payment is then remitted to the app developer. Apple’s and Google’s rules relating to in-app payments are explained further in The role of Apple and Google in competition between app developers and Appendix H.

Apple’s and Google’s app store rules are enforced by each of Apple and Google through an app review process, which applies both the first time that an app is listed on each app store and also for app upgrades. This leads to a number of apps and updates being rejected. This may be because of bugs or minor issues, issues relating to compliance with the guidelines, or in some cases, because of serious issues (for example, spyware or malware) or other contraventions of Apple’s and Google’s policies (which we discuss in more detail in The role of Apple and Google in competition between app developers). ^{[footnote 177]}

Users’ access to the App Store and Play Store

Apple’s App Store is pre-installed on iOS devices; and is the only approved app store. In addition, Apple does not allow the distribution of apps whose primary purpose is to distribute a competing app store. ^{[footnote 178]}

The Play Store is Google’s app store for Android. Google’s system is more open than Apple’s in that users can use third-party app stores on Android to acquire native apps. ^{[footnote 179]} However, in practice, the Play Store is the predominant app store on Android devices (see the section on shares of downloads below). We set out the reasons for this in our competitive assessment below.

Overview of the services and tools offered to app developers and users

Apple and Google each provide a variety of tools and services designed to attract app developers and users to their app stores.

Apple and Google provide app developers with tools for app development, testing and quality control; ^{[footnote 180]} APIs (for example, that help enhance an app’s functionality); guides and documentation with instructions on how to use the development tools; as well as advice and support. In addition, they make available a number of services and tools to help developers promote and distribute their apps to users. These include giving developers access to a platform on which to make their products available, tools to manage the release of their apps and updates and access to analytics about app performance. ^{[footnote 181]} They also include app discovery tools and features, services related to compliance (for example, with tax), as well as marketing tools and services. ^{[footnote 182]}

Apple and Google also provide various services to users designed to enhance their experience of app stores. This includes services relating to the discovery of apps, ^{[footnote 183]} such as search features, suggesting apps to users, displaying ratings and reviews given by other users; account management (such as management of subscriptions); customer support and handling of queries related to refunds; parental controls; security protections, and protecting users from harmful apps (including through the app review process and the monitoring of apps already published). ^{[footnote 184]} Other features include Apple’s Family Sharing ^{[footnote 185]} (which allows sharing across family members) and Google’s Play Points^{[footnote 186]} (allowing users to earn points and rewards to use on various apps and games).

Overview of other proprietary app stores

There are also third-party app stores, including those of manufacturers/other operating system providers. For example, Samsung, the largest manufacturer of Android devices, Huawei, which now uses a version of Android that uses Huawei Mobile Services (HMS devices), and Amazon, which uses Fire OS an Android Fork, all have their own propriety app stores.

These app stores are available in the following ways:

• Samsung currently pre-installs both its own Samsung Galaxy Store and the Play Store on its devices

• Amazon pre-installs the Amazon Appstore on its own tablet devices.^{[footnote 187]} Users of Android devices can download the Amazon Appstore through a process called ‘sideloading’

• Huawei has pre-installed its own AppGallery on all smartphones since January 2019 and on all HMS tablets^{[footnote 188]}. The AppGallery is the default app store for all smartphones launched in the UK since on or after August 2019. Users are able to install other app stores on their device ^{[footnote 189]}

Rules of access to alternative app stores

As for the App Store and Play Store, app developers must comply with the terms or ‘rules’ of access required by other app stores in order to distribute their apps:

• Amazon Appstore: app developers need to enter into the Amazon Developer Services Agreement and comply with the Amazon Appstore Content Policy.^{[footnote 190]} Amazon told us that the Amazon Appstore intake quality assurance team tests submitted apps to verify app compatibility with Fire tablets but also to check that each app works as outlined in its product description, does not impair the functionality of the Fire tablets or put customer data at risk. Amazon also told us it conducts regular quality assurance of apps published on the Amazon Appstore, for example, monitoring potential fraudulent apps or identifying apps with compatibility issues. Apps with compatibility or technical issues are suppressed until the issues are resolved with the developer, and apps determined to be fraudulent are removed or suppressed from appearing in the Amazon Appstore

• Samsung’s Galaxy Store: app developers must register their app through the Galaxy Store Seller Portal ^{[footnote 191]} and go through the quality assurance verification process. The Galaxy Store Seller Portal App provides an introduction of the guidelines on registering and distributing apps on the Galaxy Store, as well as developer terms and conditions and technical specifications

• Huawei’s AppGallery: app developers need to comply with the Huawei Developers Service Agreement and other agreement terms or service agreements which are applicable to the AppGallery Connect services used by the app developers, ^{[footnote 192]}as well as guidelines (including the App Gallery Review Guidelines^{[footnote 193]} ). Apps also go through an app review process before they are published on the AppGallery ^{[footnote 194]}

Services and tools offered to users and app developers

Alternative app stores also offer services and tools to app developers:

• Amazon referred in particular to: (i) access to the Amazon Appstore Developer Dashboard which enables them to upload and publish their apps on the Amazon Appstore; (ii) access the Amazon Developer Portal to consult documentation and references; ^{[footnote 195]} and (iii) marketing of apps by advertisements managed by the Amazon Ads team or app promotion via free editorial campaigns and merchandising placements managed by the Amazon Appstore Marketing team. In addition, Amazon submitted that it provides app developers with tools and technical support to enable them to create with minimal effort versions of their apps that are compatible with Amazon Appstore from versions they have published on other app stores (for example, Google Play)

• Samsung submitted that the Galaxy Store is capable of providing equal technical functionalities as those offered by Google Play, including installation, distribution and promotion of apps. Differences include the curated storefront on the Galaxy Store which promotes and offers exclusive apps and contents for users, including ‘Themes’ allowing users to personalise their phone display

• Huawei submitted that the AppGallery allows developers to distribute and install their apps on devices with Google Mobile Services and Huawei Mobile Services. AppGallery also has various promotional capabilities to support app developers, for example 3-second splash screen when opening the App Gallery; or automatic rotating banners promoting content

Alternative app stores also offer services and tools to users:

• Amazon referred to the quality assurance undertaken as part of the Appstore intake process, as well as the regular quality assurance of apps subsequently published on the Amazon Appstore

• Samsung referred in particular to search functions; providing recommendations to users; featuring a reviews and ratings system; and app curations (users are provided with a list of useful software that can allow them to enhance the use of their phone in conjunction with their already existing applications)

• Huawei submitted that the AppGallery allows users of its devices to search for, review, download and update apps as well as send comments on apps; it includes a security system to detect malicious behaviour or facilitate privacy checks; and also offers ways to discover, explore and share a wide range of mobile apps, for example, via app search functionality or top apps rankings per category

Key data on app store usage and revenue

In order to understand the relative position and size of different app stores, we have considered the shares of Apple, Google and various other app store providers based on the number of native app downloads in the UK in each year since 2017. We have also collected more general usage data from these market participants in relation to their proprietary app stores. This includes monthly data on the number of users downloading native apps, the number of native apps available and the number of app developers for each app store.

In addition, we have also gathered data from Apple and Google on the total customer billings made through their proprietary in-app payment systems (Apple IAP and Google Play’s billing system respectively) and the revenues generated through commission fees charged on transactions made through these payment systems.

Share of downloads

As can be seen by Figure 4.1 below, the App Store and the Play Store together represent over 90% of native app downloads through app stores across iOS devices,^{[footnote 196]} Android devices, HMS devices and Fire OS devices in the UK in 2020. Other app stores collectively represented [0% to 5%] of native apps that were downloaded through an app store (ie excluding sideloading). While these share of download figures are likely to overestimate the share of the App Store and Play Store to some extent, as they do not include all alternative app stores, it is consistent with evidence received from app developers on the relative importance of different app stores.

Figure 4.1: The proportion of downloads by app store across iOS devices, Android devices, HMS devices and Fire OS devices in the UK in 2020

Figure description: This piechart illustrates the proportion of downloads by app store across, Android, HMS and Fire OS devices in the UK in 2020. The chart shows that [90% to 100%] is downloaded on Google Play Store whereas [0% to 10%] is downloaded on other app stores.

Source: CMA analysis of data from market participants.

Notes: Based on first time downloads and individual segments are based on mid-points of the relevant range and not the actual data. For Apple this data is specific to the UK App Store, includes both first-party Apple apps and third-party apps and corresponds to transactions done through an iPhone or iPad.

Given the evidence of low levels of user switching between devices as set out in Competition in the supply of mobile devices and operating systems, iOS users and Android users could be considered different customer groups. Therefore, we have also considered downloads for iOS devices and Android devices separately (we assess the constraint Apple and Google place on each other in relation to native app distribution in detail below).

As set out above, the App Store is the only app store available on iOS devices, and therefore it has a 100% share, or a total monopoly, in relation to native app downloads through app stores on iOS devices in the UK.

Figure 4.2 below shows the shares of native app downloads of different app stores across Android devices, Huawei’s HMS devices^{[footnote 197]} and Amazon’s Fire OS devices in the UK in 2020. The Play Store is the main app store used on representing around [90% to 100%] of native app downloads through these app stores in the UK in 2020. Downloads through alternative app stores represent just [0% to 10%]. While these share of download figures are likely to overestimate the share of the Play Store to some extent, as they do not include all alternative app stores, it is consistent with evidence received from app developers on the relative importance of different app stores.

Figure 4.2: The proportion of downloads by app store across Android devices, HMS devices and Fire OS devices in the UK in 2020

Figure description: This bar chart shows the average number of native apps and average number of app developers available through app stores in the UK in 2020. The chart shows that Apple and Google are significantly larger in terms of both native apps and app developers than [the next largest app store].

Source: CMA analysis of data from market participants.

Notes: Based on first time downloads. Individual segments are based on mid-points of the relevant range and not the actual data.

Availability of native apps and app developers

In terms of native apps and app developers, Figure 4.3 uses monthly data to show the average number of native apps and average number of app developers available through certain app stores in the UK in 2020. As can be seen from this figure, Apple and Google are significantly larger in terms of both native apps and app developers than [the next largest app store]. In addition, the Play Store itself has significantly more native apps and app developers in total, despite the most popular native apps with the most downloads being available on both as outlined below.

Figure 4.3: Number of native apps and app developers available in each app store in the UK in 2020 (average of monthly data)

Figure description: This bar chart shows the average number of native apps and average number of app developers available through app stores in the UK in 2020. The chart shows that Apple and Google are significantly larger in terms of both native apps and app developers than [the next largest app store]

Source: CMA analysis of data from market participants.

Notes: [REDACTED]

User download activity, customer Billings and revenue from in-app payment systems

In terms of users downloading native apps, we have monthly data for the App Store and other app stores, but only daily data for the Play Store.

The monthly data shows that Apple is considerably larger than [the next largest app store] in terms of the number of users downloading native apps in any given month. In particular, in the UK:

• on average [20 to 30] million users downloaded at least one native app from the App Store in any given month in 2020

• in contrast, [1 to 1.5] million users downloaded at least one native app from [the next largest app store] in any given month in 2020

While Google’s data is not comparable, it does show that between [1.5 to 2.5] million users downloaded at least one native app per day through the Play Store for a short period in 2021.^{[footnote 198]} That the number of users downloading a native app from Google each day is higher than the number of users downloading a native app from the [next largest app store] each month.

We also received data from Apple and Google on the total customer billings made through their in-app payment systems (Apple IAP and Google Play’s billing system respectively) and the revenue they have generated through those payment systems. As explained in more detail in The role of Apple and Google in competition between app developers and Appendix H, app developers are required to use Apple IAP or Google Play’s billing system for certain transactions.

Figure 4.4 and Figure 4.5 show, separately for Apple and Google, how total customer billings and net revenue ^{[footnote 199]} generated through these payment systems in the UK have changed over time. As can be both Apple and Google have seen rapid growth in both customer billings and net revenue over the last 5 years. In addition, both are higher for the App Store than the Play Store.

Figure 4.4: Total customer billings and net revenue through Apple IAP in the UK (2011 to 2020)

A time series area chart showing the total customer billings and net revenue made through Apple’s In-App Payment (IAP) system between 2011 and 2020. The chart shows that Apple has seen rapid growth in both customer billings and net revenue over the last five years.

Source: CMA analysis of Apple data

Notes: We understand that both customer billings and net revenue include user spending on Apple’s first-party apps and third-party apps where such payments are made through Apple IAP (on an iPhone and iPad). The information is specific to the UK App Store.

Figure 4.5: Total customer billings and net revenue on apps (including Play Pass) through Google Play’s billing system in the UK (2012 to 2020)

Figure description: A time series area chart showing the total customer billings and revenue made on apps (including Play Pass) through Google Play’s billing system between 2012 and 2020. The chart shows that Google has seen rapid growth in both customer billings and net revenue over the last 5 years.

Source: CMA analysis of Apple data

Notes: We understand that both customer billings and net revenue include user spending on Apple’s first-party apps and third-party apps where such payments are made through Apple IAP (on an iPhone and iPad). The information is specific to the UK App Store.

Apple and Google both currently take a commission of 30% for payments made via Apple IAP and Google Play’s billing system, except in limited circumstances where a lower commission rate is applied, as described in Appendix H. In 2020 both Apple IAP’s average commission and Google Play’s billing system’s average commission were [close to 30%].

We also requested data from Apple and Google in relation to the average annual customer billing through Apple IAP and Google Play’s billing system per user of the App Store and Play Store. The data included in Table 4.1 shows that:

• App Store users spend more through Apple IAP than Android users spend through Google Play’s billing system – this has narrowly slightly since 2018

• for the App Store we also received data based on users of the App Store that engaged in a billable transaction in the UK.^{[footnote 200]} Average billings per user in the App Store were roughly [REDACTED] times higher when considering just users that engaged in a billable transaction – this implies that only around [REDACTED] of App Store users engage in a billable transaction in each year

Table 4.1: Average annual billings per user in the UK (2018 to 2020)

Year	App Store	App Store	Play Store
	Average customer billings per App Store User	Average customer billings per App Store User engaging in a billable transaction	Average customer billings on apps (including Play Pass) per active Android mobile device
2018	£[0 to 50]	£[50 to 100]	£[0 to 50]
2019	£[0 to 50]	£[50 to 100]	£[0 to 50]
2020	£[0 to 50]	£[50 to 100]	£[0 to 50]

Source: CMA analysis of Apple and Google data.

Note: We used Bank of England data to convert from US Dollars into Great British Pounds, this was done using the yearly data from XUAAUSS Bank of England Database

Competitive constraints faced by Apple and Google in respect of native app distribution

In this section, we have considered the competitive constraints faced by the App Store and Play Store in native app distribution. As with mobile devices and operating systems in Competition in the supply of mobile devices and operating systems, we have not carried out a formal market definition assessment for app distribution, but instead have assessed the alternatives or substitutes available to consumers and app developers, and the barriers to entry and expansion faced by providers of alternative means of app distribution.

To the extent that Apple and Google do not face strong competitive constraints from actual or potential alternative methods of app distribution, each are likely to have market power through their operation of the App Store and Play Store (which encompasses aspects of the operation of these app stores such as the app review process, the ranking of apps on the relevant store and associated advertising services provided to app developers).

We have assessed the following 3 potential competitive constraints faced by Apple’s App Store and Google’s Play Store.

First, we have considered the constraint from alternatives methods of accessing apps within each mobile ecosystem. This includes alternatives methods of native app distribution such as pre-installation, alternative app stores and sideloading and web-based alternatives to native apps.

App stores distribute apps that are native to each mobile ecosystem they tend to be operating specific – that is, Android app stores distribute native Android apps that would not work on iOS devices and similarly the App Store distributes native iOS apps that would not work on Android devices. Therefore, we consider the direct constraint arising from alternative app stores and the barriers to entry and expansion they face in this section on the competitive constraints from within each mobile ecosystem.

Second, we have considered the constraint on Apple and Google from the risk of losing consumers and app developers to each other’s app stores. That is, we focus on the indirect constraint that app stores across mobile ecosystems place on each other.

Third, we have considered the constraint from alternative devices, such as PCs, laptops, games consoles and smart TVs, and the marketplaces associated with those devices

Competitive constraints from within each mobile ecosystem

App developers can use alternatives to Apple’s App Store and Google’s Play Store to distribute their native apps, such as by having them pre-installed or make them available to users via alternative app stores or sideloading. In addition, app developers can also make their products and services available through web-based alternative such as web apps.

Alternative methods of native app installation

In this section we consider the constraint placed on Apple and Google by the following alternative methods of native app installation:

• pre-installation of native apps: this relates to the fact that Android device manufacturers can pre-install their own apps or apps from third-party developers on their devices

• alternative app stores within the mobile ecosystem: this relates to where users could use an alternative app store without switching device

• sideloading: this is where an app developer’s native app is download by the user directly from the developer’s web page or via peer-to-peer transfer

Lastly, we consider the extent to which accessing websites on mobile devices to purchase and consume digital content or services are a competitive constraint on the distribution of native apps.

Pre-installation

Pre-installation of third-party native apps on iOS devices is not an alternative within Apple’s ecosystem and thus does not constrain the App Store. Apple does not currently pre-install any third-party apps on its devices and we are only aware of one historical example of this. ^{[footnote 201]}

In contrast, pre-installation is allowed in Google’s ecosystem and Google said that pre-installation is a viable alternative through which app developers can distribute their native apps. Google said that app developers such as Facebook, Microsoft and Spotify all have pre-installation agreements with manufacturers. ^{[footnote 202]}

However, the pre-installation of third-party native apps on Android devices does not appear to be a viable alternative to the Play Store for the vast majority of app developers and thus does not constrain the Play Store for the following reasons.

First, evidence from the manufacturers we requested information from suggests that they are only likely to pre-install the most popular apps, their own first-party apps, or those of Mobile Network Operators. As a result, pre-installation is not a viable option for most app developers. For example, outside of first-party and Google apps, Samsung told us it had global agreements to pre-install a small number of popular native apps and non-global agreements to pre-install additional native apps, including those of Mobile Network Operators.

Further, not all of these third-party native apps are necessarily installed on all devices. For example, Huawei identified a number of different third-party non-Google apps that were preinstalled. Nearly all of these were pre-installed on less than half of Huawei’s devices in any one year.

Second, none of the app developers that we requested information from identified pre-installation as an alternative to the Play Store. Indeed, only a few mentioned it as being a method for distribution on Android devices, with one app developer saying its app was pre-installed on a limited number of smartphones and another app developer saying pre-installation account for less than 10% of its global installs.

Finally, as noted by the Australian Competition and Consumer Commission (ACCC), app developers have access to virtually all users who have an Android device through the Play Store, and to do the same through pre-installation would require coming to agreements with many manufacturers. As also noted by both the Netherlands Authority for Consumers & Markets (ACM) and ACCC in their recent reports, there are likely to be costs involved in terms of the fees paid to manufacturers as part of any pre-installation agreements and the costs of negotiating those agreements. ^{[footnote 203]}

Alternative app stores

As noted above, Apple does not allow third-party app stores on iOS devices ^{[footnote 204]} and as set out below, the sideloading of alternative app stores is not a credible option. This means that there are currently no rival app stores on iOS devices and no prospect of new entry such that Apple does not face a constraint from alternative app stores on iOS devices.

In contrast, alternative app stores to the Play Store are available on Android devices. They can either be pre-installed by the device manufacturer (for example, Samsung pre-installs its Galaxy Store) or sideloaded by the user. Users cannot download alternative app stores from the Play Store. ^{[footnote 205]}

Google submitted that it faces competition from other Android app stores and, in particular, from Samsung’s Galaxy Store which is pre-installed on all Samsung devices. In total, Google estimated that between 60 to 90% of UK Android devices have another Android app store pre-installed as Huawei also pre-installs its Huawei App Gallery, based on those parties’ market shares, according to public sources.

Google submitted that installation via third-party mobile app stores operates in essentially the same way as via the Play Store. Google said that app stores typically provide similar services including a ‘storefront’ to users from which they can find and download apps as well as security, marketing and in-app billing system services with similar headline fees to developers of around 30%. Google also said that some app stores may seek to attract users with special offers. ^{[footnote 206]}

Finally, Google said that it does not restrict developers from distributing their apps outside of the Play Store and this is specifically stated on its Play Console Help Page. ^{[footnote 207]}

We have found evidence that alternative apps stores place only a limited constraint on the Play Store within the Android ecosystem for the reasons set out below.

Usage of alternative Android app stores

First, the usage of alternative Android app stores, both by device users and app developers, is substantially lower than the Play Store.

In the UK, Samsung’s Galaxy Store is the most widely available alternative app store within the Android ecosystem ^{[footnote 208]} as the Galaxy Store is pre-installed on all Samsung smartphones which is the largest manufacturer of Android smartphones as set out in Competition in the supply of mobile devices and operating systems. Thus there are many Android devices with both the Play Store and Galaxy Store

However, Huawei said that the AppGallery is a relatively new entrant with a modest market presence, and its focus is on providing a good product for the user, rather than seeking to rival major app store providers, such as Apple and Google, directly. In addition, Huawei’s AppGallery, introduced into the UK in 2018, is pre-installed in all Huawei smartphones launched in the UK since January 2019. Since May 2019 Huawei has not been able to pre-install the Play Store due to legislation in the US (see Competition in the supply of mobile devices and operating systems). Given this, there are only a small number of Android devices that have both Huawei’s AppGallery and PlayStore pre-installed.

More generally, on various metrics the Play Store in the UK is by far the largest Android app store as shown in:

• figure 4.2 shows how the Play Store accounts for [90% to 100%] of downloads across Android devices, HMS devices and Fire OS devices in 2020

• evidence set out above shows that the number of users downloading a native app from Google each day is higher than the number of users downloading a native app from the [next largest app store] across Android devices, HMS devices and Fire OS devices each month

• figure 4.3 shows that the Play Store had a much larger number of native apps available to download from a much larger number of app developers than [the next largest app store] across Android devices, HMS devices and Fire OS devices in 2020

Second, app developers do not consider such alternative Android app stores to be a suitable alternative to the Play Store. For example, app developers who provided their views did not identify alternative app stores as suitable alternatives when asked about whether they could recapture users’ time and revenue if their apps were withdrawn from the Play Store.

This does not mean app developers do not use other Android app stores. Despite the costs involved (such as the costs of integrating their native apps with these app stores and adjustments needed due to different app store policies), some app developers said there were some benefits to using alternative app stores and referred to reasons such as accessing more users, ^{[footnote 209]} more favourable revenue share agreements or diversification of strategy. That other Android app stores are used by app developers for reasons such as providing access to more users, but not considered as alternative to the Play Store suggests that they are seen as complements to, rather than substitutes for, the Play Store.

Overall, the usage of these Android app stores by larger app developers who responded to our requests for information appears to be lower. For example, while all those app developers listed their apps on the Play Store, less than a third listed them on Samsung’s Galaxy Store, with the numbers for other Android app stores being smaller still. Consistent with this, evidence provided by app developers showed that downloads from alternative app stores were very low.

Barriers faced by alternative Android app stores

Third, we consider that alternative Android app stores, especially new entrants, also face barriers to effective competition:

• there might be limits on the usage of the alternative app stores operated by manufacturers. For example, while manufacturers’ app stores could be sideloaded, we set out below that sideloading is limited in practice. Similarly, while one manufacturer could seek to enter into pre-installation agreements with another manufacturer, we consider this is unlikely in practice. Although many manufacturers have their own app stores already, through their agreements with Google also pre-install the Play Store – as such it is not clear what incentive they would have to pre-install another manufacturer’s app store especially as the Play Store provides access to such a large range of apps

• app stores benefit from both network effects and economies of scale. In particular, there are significant indirect network effects at play in the provision of app stores – the benefit to users of an app store increases with the volume and quality of apps they can access through that app store and similarly the benefit to app developers increases with the number of users they can access through an app store. The presence of indirect network effects is likely to act as a particular barrier to new entry and expansion as it creates a ‘chicken and egg’ problem – an app store needs a critical mass of users to attract app developers, but also need a critical mass of app developers to attract users

Google’s agreements, policies and initiatives

Fourth, we consider that a range of practices by Google (including its agreements with manufacturers, its policies towards alternative app stores and recent initiatives aimed at app developers) are all likely to have limited the constraint from alternative Android app stores, including new entrants. As set out below, we consider that Google has been able to implement relevant agreements, policies and initiatives due to a combination of its market power in search and search advertising and the position of its Android operating system and the Play Store.

As set out in Competition in the supply of mobile devices and operating systems, and in more detail in Appendix E, Google has a range of agreements with manufacturers. Through its agreements with manufacturers, Google is able to ensure that the Play Store is pre-installed and prominently placed on the device home screen of the vast majority of Android devices. In particular, through these agreements:

• Google shares a proportion of its advertising revenue generated on Android devices with manufacturers that meet certain requirements – without a similar position in search advertising rivals cannot replicate such payments

• Google makes the licencing of key Google apps and APIs conditional on the pre-installation and prominent placement of the Play Store by a device manufacturer – some of which are important to the functioning of Android devices as they are needed to ensure many native Android apps function properly

The pre-installation and prominent placement of the Play Store, which provides Android users with access to a large volume of quality native apps (and more than any other app store), also means that those users have little incentive to use other Android app stores.

Google’s policies in relation to alternative app stores are also likely to reduce the likely constraint they impose on the Play Store. Third-party app stores are not available on the Play Store^{[footnote 210]} and, other than those preloaded by manufacturers, have to be sideloaded by users. As outlined below, sideloading is not widely used and thus not an effective way through which alternative app stores can access users of Android devices. One of the reasons for this is due to the security warnings put in place by Google (see Figure 4.6 below). In addition, apps downloaded from sideloaded third-party app stores cannot be updated automatically, although we understand this is to change with Android 12. ^{[footnote 211]}

We also have concerns around the impact of a recent initiative in relation to the Play Store that Google has implemented and changes to its revenue share agreements, which have the potential to further reduce the competitive constraint from rival Android app stores. The first of these is ‘Project Hug’ which involved Google targeting a number of major app developers and was implemented in 2019. Based on Google’s internal documents and 2 complaints made in the US, respectively by a coalition of 39 attorneys general and Epic Games,^{[footnote 212]} we understand this initiative to be part of a number of related initiatives targeting app developers (and particularly games developers) and alternative app store providers. ^{[footnote 213]}

The second of these is the changes to Google’s revenue share agreements. The most recent revenue sharing agreements (RSA 3.0) with manufacturers include the possibility for manufacturers to earn a share of Play Store revenue if they meet certain obligations in relation to the Play Store, as set out further below.

Project Hug

This initiative was implemented by Google from 2019 and targeted a number of major developers, and particularly game developers, to encourage them to continue to develop and distribute their apps via Play.

Google told us that the value it provides to developers under Project Hug comes in several forms, including in relation to the use of other Google’s products and services such as Google’s cloud, advertising and marketing services. In particular, [REDACTED]. The documentary evidence from Google also shows that Google estimated the value of these benefits to equate to an effective reduction in the commission rate to the relevant developers.

We understand from Google that, in exchange for the benefits listed above, developers agree to treat the Play Store at least comparably to other distribution platforms in terms of feature and content availability and timing of launch of their apps. In particular, developers agree to [REDACTED].

We are concerned that while Project Hug provided benefits to certain top app developers in the short term, including commercial benefits related to the use of other Google’s products and services, ^{[footnote 214]} it was aimed at reducing competition in the long term by undermining emerging competition from other distribution channels. In particular, rival app stores already face significant barriers to competing with app stores such as the Play Store given the presence of significant network effects, whereby app stores are only attractive to users if they have enough developers and vice versa.

A possible strategy for alternative app stores would be to establish exclusive relationships with key developers, which may agree to abandon distribution via the Play Store and only list on a rival app store. Samsung’s 2018 agreement with Epic in relation to the Fortnite app as well as its approaches to other popular developers to get exclusive distribution deals for the Galaxy Store, as referred in the Utah complaint, are examples of this. ^{[footnote 215]}

However, following Project Hug, alternative Android app stores would have to better Google’s offer in some way, in order to encourage them to forego the benefits on offer from Google (as well as its large user base) and abandon distribution via the Play Store (which currently accounts for [90% to 100%] of native app downloads on Android devices, HMS devices and Fire OS devices as outlined above). Therefore, by ensuring these important game developers keep distributing via the Play Store, Google makes it more difficult for rival app stores to compete by attracting material from these top apps which would not already be present on the Play Store.

Documentary evidence from Google indicates that Project Hug was a reaction to increased competitive threats the Play Store faced from alternative app distribution channels in 2019. We consider this includes alternative app stores seeking exclusive listings from app developers – as noted above, one rival, the Galaxy Store, had secured an exclusive listing from the popular app Fortnite.

Google’s objective appears to be to ensure key developers’ presence on the Play Store and encourage them to use other Google services. Internal documents indicate that, via Project Hug, Google would:

• encourage relevant developers to continue to distribute theirs native apps via the Play Store. As outlined above this was in the face of app developers establishing exclusive distribution relationships with alternative distribution channels and app stores, which is what Epic Games^{[footnote 216]} did in 2018 with the Samsung’s Galaxy Store and, based on the Utah complaint, Samsung was pursuing with other popular app developers as well

• discourage relevant developers from co-listing on other app stores in addition to the Play Store – with the view that this would create a cycle for Play whereby alternative app stores would have less top titles and in turn less users, which in turn would reduce smaller developers’ incentive to co-list on several app stores ^{[footnote 217]}

• encourage developers’ adoption of other complementary products and services offered by Google (as outlined above the initiative included value for developers in the form of Google’s cloud, advertising and marketing services) and thus deepen its relationship with such developers

RSA 3.0

As well as Project Hug, Google introduced the latest version of its revenue share agreements in late 2019 and implemented it with some manufacturers in the course of 2020 was RSA 3.0 contract framework.

As set out in Competition in the supply of mobile devices and operating systems and in more detail in Appendix E, Google’s RSAs involve Google sharing a proportion of net advertising revenue generated on devices that meet certain placement and default requirements relating to Google Search and Google Assistant. The revenue share that a manufacturer may get increases with the number of obligations met by a device. ^{[footnote 218]}

Based on Google’s documents and written submissions, we understand that as part of its latest revenue sharing agreements, manufacturers which comply with certain placement and default requirements relating to Google Search and Google Assistant can also receive a share of Google’s net revenue from Play Store transactions, if they also meet additional requirements relating to the Play Store. These requirements are setting the Play Store as the default app store and not preloading similar services to Google Play, such as alternative app stores, on their device. We further understand that under the previous RSA version, no payments for Play Store revenue were made to manufacturers by Google.

Due the recent nature of these agreements, we do not have a clear picture of the proportion of devices that they cover for each manufacturer, how this will vary in the near future and the extent to which the content of the agreements varies based on the specific manufacturer involved and intend to investigate this further in the second half of our study.

However, such agreements could represent a further barrier to effective competition from alternative app stores as well as alternative distribution channels more in general. In particular, Google is able to use its current position in native app distribution on Android devices to disincentivise the pre-installation of rival app stores and the usage of alternative distribution channels by manufacturers in a way that rivals cannot replicate, given that they do not have the same number of users on their app stores and do not have the scale to match such payments. ^{[footnote 219]}

Conclusion on the competitive constraint faced by the Play Store from alternative Android app stores

Google’s Play Store only faces a limited constraint from alternative Android app stores including from new entrants – in particular, alternatives to the Play Store are not widely used by users or app developers and face material barriers such as indirect network effects. Further, Google has the ability to target app developers with benefits, including complementary products and services, which may offer benefits to certain app developers in the short term, but in the long term could represent a barrier to emerging competition from other distribution channels, including other app stores. We will explore the role of these potential barriers to competition in the second half of the study.

Sideloading

Competitive constraint

Apple does not allow users to sideload native apps on its devices – Apple submitted that this is because the ‘iPhone was designed as a closed ecosystem where the operating system, iOS, was configured to prevent third-party applications or software from being downloaded to the phone’.

In theory, users could get around Apple’s restriction on sideloading by engaging in a process called ‘jailbreaking’ which allow users to install software not available through the iOS App Store and thus sideload alternative app stores and apps.^{[footnote 220]}

We understand that jailbreaking is technically difficult so unlikely to be a viable option for the vast majority of users. ^{[footnote 221]} In addition, Apple said that engaging in jailbreaking is a violation of the iOS end-user software license agreements and that, under those agreements, Apple may deny service for an iPhone or iPad that has installed any unauthorised software via jailbreaking.

Reflecting this, none of the app developers who responded to our requests for information considered this to be an alternative method through which to distribute apps. Indeed, one app developer said that it does not support its native app on devices which have been found to be jailbroken.

We understand that other exceptions to the App Store’s restriction on sideloading are limited in nature. For example:

• Apple’s TestFlight allows app developers to invite up to 10,000 users to sideload their apps for the purpose of testing ^{[footnote 222]}

• the Apple Developer Enterprise Program only allows large organisation to develop and deploy proprietary, internal-use apps to their employees.^{[footnote 223]} We understand that Apple has also taken action against app developers it has found to be in breach of this program ^{[footnote 224]}

Therefore, the App Store does not face a competitive constraint from users sideloading apps.

In contrast, sideloading is possible on Android devices. Google said that sideloading requires a few more steps than using an app store, but is neither materially more time consuming nor cumbersome. Google cited the example of Epic Games’ Fortnite app, where Samsung produced a guide showing 12 steps to install Fortnite via the Galaxy Store compared to 16 steps when done via sideloading.

Google also said that, while there are security risks, Android users can configure their browser to allow sideloading by default in the future by enabling downloads from ‘unknown sources’. Users that do this do not have to go through the additional steps, but users who do not configure their browsers in this way will have to go through the steps for each sideloaded app.

Google said that sideloading is a viable way of distributing apps to users, especially ‘in circumstances where the app is well-known and users are motivated to seek it out’. For example, Google said that Epic Games’ Fortnite app can be sideloaded as can WhatsApp.

We have found evidence that sideloading places only a very limited constraint on the Play Store for the following reasons.

First, while the data we have on sideloading is limited, it indicates that only a small proportion of downloads on Android devices are via sideloading. For example, Google provided data showing that in May 2021 [3.5 to 4] million off-Play Store installs were sideloaded (this includes downloads from alternative app stores that were not preloaded). ^{[footnote 225]} This compares to an average of [100 to 200] million installs per month through the Play Store during 2020.

Second, the majority of app developers that responded to our request for information did not use sideloading as a distribution channel or identify it as an alternative to the Play Store. Reasons provided for this included the process users have to go through on Android devices to sideload apps (see below), that sideloaded apps may lead to a suboptimal experience as features may break and because it requires users to turn off the security settings on their device.

The other app developers said their apps could be sideloaded, but just over half said they did not actively use the channel. Consistent with this, evidence provided by app developers showed that sideloading as a proportion of all downloads on Android devices were very low, with only 2 app developers who responded to our information requests from being an exception to this.

Google specifically identified Epic Games as an app developer who has a native app (in this case Fortnite) that users can sideload. While this is the case, Epic Games cited difficulties in doing so and outlined that the Android operating system makes it unreasonably difficult for users to sideload apps and, as set out below, identified a number of issues around sideloading. ^{[footnote 226]}

Third, we understand that there are factors that are likely to limit the viability of sideloading as an alternative to the Play Store for both users and app developers.

The first of these is that sideloading on Android devices involves an extended process and the lowering of Android’s security settings. For example, Figure 4.6 below shows the process for sideloading the Epic Games App based on information provided by Epic Games. We understand from Google that manufacturers can amend the steps involved in sideloading and language used in any warnings as they see fit. We will explore the extent to which this occurs in practice in the second half of our study.

Figure 4.6: Sideloading process for the Epic Games App

Figure description: A diagram showing the sideloading process for the Epic Games App. The chart shows that a user has to go through multiple steps and faces several warnings that are worded in a way to reduce the likelihood of users sideloading apps.

As can be seen above, a user has to go through multiple steps and faces several warnings that are worded in a way that is likely to reduce the likelihood of users sideloading apps. Indeed, several app developers identified this as a challenge involved in using sideloading. ^{[footnote 227]}

Our understanding is that these steps are the same for all sideloaded apps and as such do not take account of the individual risk of the app the user is trying to download. However, as set out above, users can configure their browsers to allow sideloading by default, meaning these steps are not needed.^{[footnote 228]}

Epic Games also said that in certain circumstances users may not be able to sideload at all on Android devices. Epic Games submitted that:

• users enrolled in Google Play Protect may be prevented from installing or have an app forcibly removed from their device if it is deemed ‘harmful’
• users enrolled in Google’s ‘Advanced Protection Program’ are prevented from sideloading any apps. These users can only use either the Play Store or another pre-approved, pre-installed app store (if available)

Google said that the additional steps, at least in the first instance of sideloading, are both modest and required for security reasons. Apple also raised security concerns with sideloading and these are discussed below.

The second factor that may have made sideloading less of a viable alternative is that sideloaded apps do not automatically update with the user having to update the app. Rather, users have to manually update these apps. One app developer, Epic Games, explained that this can be burdensome and time-consuming for its users given one of its native apps, Fortnite, is typically updated every other week.^{[footnote 229]}

However, Google said that its next update of the Android operating system (Android 12) will allow sideloaded apps to be automatically updated.^{[footnote 230]}

Security concerns

While their policies and approaches towards side-loading do differ, both Apple and Google both submitted sideloaded apps create additional security risks for users. We asked each company to explain the risks posed by sideloading. In relation to Apple, we also asked it about why its policy differs to its position in relation to Mac computers where sideloading is allowed.

Apple said that it has a multi-layered approach to security and user-reliability, including:

• customer security hardware which powers the critical security features in its mobile devices
• software protections which work to keep the operating system and third-party apps safe, allow secure and timely software updates, deliver secure communications and payments, and provide a safer experience on the Internet
• SDKs which secure a high level of reliability when upgrading iOS and ensure apps are prevented from interfering with the functioning of other apps or features
• an app review process which ensures every app and app update is comprehensively checked before it is made available for download

Apple submitted that sideloading is a recognised security threat.^{[footnote 231]} In particular, Apple said that allowing sideloading would have hugely negative consequences as even ‘a single app downloaded outside of the App Store could seriously undermine the functioning of an app downloaded from the App Store because it would not have the same limitations on its rights and ability to access other functions.’ Specifically, Apple said that:

• sideloaded apps could be configured to interfere with apps already downloaded causing them to no longer work or use excessive battery power or engage in invasive data collection

• features in sideloaded apps may no longer work following iOS updates, as iOS updates account for the structure of apps built with Apple’s SDKs, which could lead to potential conflicts with the sideloaded apps. In turn this could lead to users avoiding upgrading to new iOS versions, which would expose them to security breaches (as upgrades typically include security patches)

• users would not necessarily understand that these user experience issues were caused by apps downloaded outside of Apple’s control and it would therefore hurt Apple’s reputation

• the level of protection against malware would move from Apple’s high standard of review to a level set by the lowest standard offered by a third-party app store. This creates a risk not only for the individual device but also for the overall ecosystem – due to the risk of malware attacking other devices once it is on one iOS device, the increased incentive on hackers to target iOS when it is easier to penetrate the system, as well as undermining of upgrades of iOS when security patches are released

Therefore, Apple considers that preventing sideloading is vital, given the size of Apple’s user base and wealth of data contained on mobile devices would make Apple devices an attractive target.^{[footnote 232]} In addition, Apple also said that preventing sideloading was important as^{[footnote 233]} :

• users cannot make informed choices about the security threat
• security concerns lead to fewer apps being used impacting on the whole app economy
• the App Store protects developers as well as it stops the use of infected development tools that spread malware

In relation to Mac computers, Apple’s Craig Federighi (its Senior Vice President of Software Engineering) has stated the following: ‘we have a level of malware on Mac that we don’t find acceptable, and it is much worse than iOS.’ ^{[footnote 234]} Apple asserted that it had to make the iPhone considerably more secure and reliable due to: (i) the breadth and sensitivity of the personal data on mobile devices that exceeds computers; (ii) the fact mobile devices can be a user’s lifeline in an emergency and is integral to how users live, work and communicate; (iii) the iPhone’s size and portability meaning it may be more likely to be misplaced or stolen; (iv) the fact that the large size of the iPhone user base would make an additional appealing and lucrative target for cybercriminals and scammers.^{[footnote 235]}

Apple also submitted that the security and reliability of the iPhone is a competitive differentiator^{[footnote 236]} and is a reason why users choose iPhones over Android devices. This is consistent with survey data provided by Apple [REDACTED].

Google said that its ad-funded business model incentivises it to allow developers more methods to connect with users, including sideloading (third-party app stores, sideloading, web apps, websites) as it increases the volume of content delivered to users, which also increases the opportunities for Google to generate revenues from advertising through this content.^{[footnote 237]} However, Google submitted that sideloading can be used by malicious actors to avoid the security checks that app stores perform. In particular, Google said users most likely do not have the technical ability to scan sideloaded apps for malware of viruses themselves.^{[footnote 238]}

Google submitted that the sideloading process in place ensures that users are aware that there are risks involved in sideloading when compared to using preloaded app stores. Further, Google said the process is not tailored as Google considers that it can only reasonably warn the user as to the general risk level of the distribution channel, but not the specific app being downloaded. This is because Google has no way to know the risk level in advance of a download commencing (although Google said that Google Play Protect can scan apps during the sideloading process). There is therefore a security risk even in relation to well-known app developers and the level of risk may change regularly. In addition, Google also said that constantly adjusting the text for an infinite number of developers would be impracticable.

Conclusion on the constraints from all alternative methods of native app installation

In summary, Apple’s App Store does not face a constraint from any alternative methods of installing native apps, such as sideloading on iOS devices. This is primarily because Apple does not allow any alternatives.

In addition, we consider that Google’s Play Store only faces a limited constraint from alternative methods of installing native apps on Android devices. While Google’s ecosystem is more open, alternative app stores and the sideloading of native apps are not widely used by users or app developers. Reasons for this include the barriers they face such as indirect network effects and the warnings of the potential security risks of sideloading.

Web-based alternatives to native apps

Both Apple and Google consider that users are able to access and purchase content on mobile devices through web-based alternatives, including websites and web apps, and that these alternatives place a competitive constraint on their app stores.

Websites are a group of interlinked web pages that are navigable but static and accessible via web browsers. Web apps are applications built using common standards based on the open web, and are designed to operate through a web browser.

Web apps are superior to websites and more similar to native apps. In particular, web apps have more functionality than a regular webpage, including opportunities for interactions, partially operating offline, and (on Android) providing push notifications. The term ‘progressive web apps’ has been used to described newer web apps with added functionalities and these web apps can have an icon on a mobile device home screen just like a native app. When we refer to web apps in this section we are also referring to these ‘progressive web apps’.

Web apps can in principle also deliver efficiency savings for app developers. This is because the developer can develop one web app which can be used across browsers on any operating system due to the common standards of the open web. Web apps may involve lower development and maintenance costs compared to native apps, as these generally have to be written separately for each operating system.^{[footnote 239]} Web apps therefore enable developers to make their content available to a potentially much larger user base, without going through app review processes.

Given the possible similarities between native apps and web apps, we have considered whether users or app developers regard web apps as an alternative to developing native apps to be distributed through the main app stores.

In this regard:

• Apple has said that app developers can create web apps for iOS users. Apple also stated that several large app developers have made apps available as web apps including Facebook, Starbucks, Pinterest, Google, Match, Uber and the Financial Times.^{[footnote 240]} While Apple acknowledged that web apps cannot access all of the device features that are available to native apps and that in limited cases web apps can experience latency and other degradations in quality compared to native apps, Apple stated that for many types of apps, web apps can offer a feature rich experience that is comparable to native apps in terms of functionality, ease of use and user experience

• Google said that Android is a leader in facilitating web app technologies as recognised by third-party reports.^{[footnote 241]} Google said it had an incentive to support these alternatives as Google is an ad-funded business and increasing the volume of high quality content increases the opportunities to show users relevant ads. Google said that web apps (including progressive web apps) offer a more sophisticated experience to users than standard websites,^{[footnote 242]} are becoming increasingly sophisticated and are often comparable in quality to native apps. Google considers them to be a viable alternative to native apps and identified several app developers that used web apps, including Twitter^{[footnote 243]}

We first consider the competitive constraint faced by the App Store from users and app developers switching to web-based alternatives on iOS devices, before then considering the competitive constraint on Google’s Play Store from users and app developers switching to web-based alternatives on Android devices.

Competitive constraint from web apps in Apple’s ecosystem

The evidence suggests that currently web apps place only a very limited constraint on the App Store within Apple’s ecosystem, for the following reasons.

First, although Apple submitted there are not significant differences in the functionality of web apps depending on the browser a developer or a user chooses to use, Apple does impose restrictions on the browser engine that web browsers use on iOS devices. In particular, all web browsers on iOS devices have to use Apple’s WebKit browser engine (for example, Google Chrome on iOS devices is based on Apple’s WebKit, rather than Google’s Blink browser engine).

In addition, we understand that the use of the WebKit browser engine materially restricts the functionality of web apps compared to native apps, as considered further in the next chapter. Some examples of reduced functionality available for web apps on iOS devices includes:

• lack of push notifications: WebKit does not support push notifications to a user’s home or lock screen (although we understand that Apple may be in the process of implementing this now)

• lack of full screen display: the browser’s user interface remains visible in web apps^{[footnote 244]}

• lack of Web-Bluetooth: which provides the ability to connect and interact with Bluetooth Low Energy peripherals, such as printers and scanners, payment devices, smart lighting and home automation

• iOS mutes web apps by default: and touch input from users is required for audio to work

• lack of access to hardware rendering: web apps have to rely on software-based, single-thread rendering, which means less efficient processing and ultimately results in greater battery drain

Further, one app developer said that iOS users must click on the Safari browser and then click the ‘share button’ and scroll to select the ‘Add to Home Screen’ feature in order to place a web app icon on their home screen. This contrasts to the situation on Android devices where users receive a prompt that encourages them to add the web app to their home screen.

Second, as discussed in more detail in Competition in the supply of mobile browsers, Apple’s support of web apps on non-Safari browsers is even more limited than on its own Safari browser. For example, parties submitted that Apple does not allow any browser other than Safari to offer the functionality that enables users to add the icon of a web app to the home screen. We understand that this functionality is a prerequisite for any web app experience to resemble that of a native app.

Third, while most app developers that responded to our requests for information did offer the same products and services through web apps or web pages as through their native apps, most did not consider web apps and webpages to be adequate substitutes to native apps. Most of these app developers cited the inferior or limited functionalities and performance of web apps compared to native apps.

For example, [one developer] said that webpages and web apps are not adequate substitutes to offering native apps through the App Store. It said that the kind of functionalities that can be built on websites, and which are fundamental to limited compared to a native app and the performance is not as fluid. In relation to web apps, [one developer] said that they have generally inferior performance and prolonged load time compared to native apps, that they offer less functionalities and are less user-friendly. It said that the most significant limitations were around the lack of support for push notifications, the limitations on storage of offline data and files, that Apple removes files if the web app is inactive for a period, the reduced ability to store data that could be used to prevent malicious actors from using its services, function of geolocation and the lack of access to private information (for example, contacts).

Competitive constraints from web apps in Google’s ecosystem

Overall, the evidence suggests that web apps are not currently a viable alternative to native Android apps for many app developers. This means that the competitive constraint from web apps on the Play Store is likely to be limited. This is for the following reasons.

First, we understand that web apps on Android devices have greater functionality than on iOS devices, yet some app developers have told us that they consider there is still a gap in functionality between native Android apps and web apps. For example, [one developer] said that on Android devices, web apps have better functionality in terms of push notifications, storing of offline data and better geolocation among others, but that there is still a gap between the performance, speed and quality of native apps and web apps on Android devices.

In addition, as has been put to us by several technical experts, one of the main benefits of web apps is the ability to make a single app available through browsers on all operating systems (rather than producing a separate native app for each operating system). Therefore, the limited support for web apps on iOS devices is also likely to impact the use of web apps on Android devices. In particular: (i) there is little benefit to developing one web app across Android and iOS devices if there is limited features and functionality for web apps in one of these ecosystems; and (ii) the potential savings in development costs are undermined if a developer has to develop a web app for Android but also develop a native iOS app.^{[footnote 245]}

Reflecting this, most app developers submitted that they did not consider web apps and webpages to be adequate substitutes to native Android apps.

Second, Google’s data on the number of installations of progressive web apps via Chrome on Android devices indicates that web apps are used much less than native apps on Android devices. Google estimates that in the UK, progressive web app icons were installed by users on the screens of their Android devices via Chrome a total of [5 to 5.5] million times in 2019 (compared to [4 to 4.5] million in 2020). This is compared to the installation of [1.5 to 2] billion native apps from the Play Store for the UK in 2019.

Conclusion on the constrains from web-based alternatives

Overall, the evidence suggests that the development and usage of web apps is substantially lower than native apps, and that app developers do not regard these as a viable alternative to the development of native apps that are downloaded through the major app stores. The evidence submitted to us by technical experts indicates that this is in large part down to a combination of restrictions and limitations of functionality within Apple’s ecosystem, which undermines the incentive for developers to invest in web apps across both ecosystems.

This means that the competitive constraint from web apps on the download of native apps through the App Store and Play Store is likely to be limited at present.

Competitive constraints between Apple’s and Google’s app stores

Next, we have considered the competitive constraint faced by Apple’s App Store and Google’s Play Store from either app developers or users switching, or the threat of them switching, to other mobile ecosystems – specifically whether Google’s mobile ecosystem constrains Apple’s App Store and whether Apple’s mobile ecosystem constrains Google’s Play Store.

In this section we have not considered the constraint from either potential new entrant app stores that might arise due to entry at the mobile operating system or app stores on Huawei’s HMS devices or Amazon’s Fire OS tablets. This is because, as set out in Competition in the supply of mobile devices and operating systems, these alternative mobile operating systems place a limited constraint on Apple and Google at the operating system level given the presence of significant barriers to entry and expansion.

Overall, as set out below, we have found that Apple and Google face a limited constraint from each other in relation to the presence of each other’s app stores. This is because:

• the largest app developers accounting for most downloads are present on both the App Store and Play Store and would not delist from one of these app stores, due to the volume, value and uniqueness of users on each – this is particularly the case in relation to Apple, whose users on average spend more per year through Apple IAP than Android users spend through Google Play’s billing system, see Table 4.1 above. Therefore, the threat of app developers moving away from their app store does not appear to exert a strong competitive constraint on Apple’s or Google’s operation of their app stores

• users generally do not have both iOS devices and Android devices. This means that an iOS user would need to purchase a new device in order to access the Play Store, and an Android user would need to purchase a new device in order to access the App Store. As found in Competition in the supply of mobile devices and operating systems, such switching is limited in practice. As outlined below, there are additional factors, such as the transparency of app store conditions, that make such switching unlikely in response to changes in the price or quality of apps available in different app stores. Therefore, we would not expect user switching to place a competitive constraint on Apple and Google at the app store level

App developers

App developers use app stores as a gateway to access mobile device users, and a particular gateway is more valuable to an app developer the more users they can access through it. This means that mobile ecosystems can compete for app developers both directly (for example, in terms of the services they offer) and indirectly, by attracting users to their mobile ecosystems.

It is also important for mobile ecosystems to ensure that they attract a wide range of quality app developers. This is because the overall app ecosystem is an important factor in users’ choice of mobile device – as set out in Competition in the supply of mobile devices and operating systems, both past and current rivals to Apple and Google have either lost or struggled to attract users due to their weaker app ecosystems.

Both Apple and Google have told us that they competed with each other to attract app developers to their app stores. In particular:

• Apple submitted that there is a cost to developing a native app such that it needs to ensure that iOS is attractive to app developers otherwise they may not use iOS or may prioritise other digital platforms (for example, Android or games consoles). It also told us that developers are sensitive to factors including commission rates, the technical capabilities of devices, the available developers tools, the number of users and on the amount users are expected to spend that platform, and other services offered by the platform. Apple said that it has improved the terms it offers to developers over time

• Google submitted that it competes to bring developers to Android and keep their attention,^{[footnote 246]} as developers shift their resources and attention to the distribution channel that maximises their returns. Google said it faces fierce competition from Apple, with some high-profile app developers prioritising the App Store, given the volume and higher value of Apple users. It also said that it has reduced its service fees and introduced new features, investment and innovations to remain competitive and attractive to developers

In the sub-sections below, we consider the constraints that exist as a result of app developers reacting to either an increase in prices or decrease in quality of app stores by deciding to list their apps only on the Play Store and not Apple’s App Store or vice versa.

The Play Store was materially larger than the App Store in 2020 in terms of apps (roughly [2.5 to 3] million vs [1 to 1.5] million) and app developers (roughly [800,000 to 900,000] vs [500,000 to 600,000]) ^{[footnote 247]} so clearly some app developers only develop for one or the other. For example, there are new apps being developed all the time and these app developers may well decide to develop for just one mobile ecosystem in the first instance (for example, due to resource constraints).

The options available to app developers in terms of deciding to use just one of the App Store or Play Store will differ based on their current behaviour:

• app developers that currently use both the App Store and Play Store could just delist from either the App Store or Play Store
• app developers that only use the App Store could delist and then have to develop their apps to be used on the Play Store and vice versa
• app developers developing new apps could decide which app store to focus on

We consider each of these in turn below and set out why they are a limited constraint on Apple’s App Store and Google’s Play Store.

App developers delisting from either the App Store and Play Store

We understand that most large and popular third-party apps are present on both Apple’s iOS and Google’s Android. This was supported by evidence from a broad range of parties, including Apple and Google, and all of the large app developers that we requested information from. For example:

• Apple told us that popular and successful app developers almost universally choose to multi-home, that is, make their apps available on both Android and Apple devices

• Google told us that app developers typically multi-home across different operating systems and devices with many of the same apps, including popular apps^{[footnote 248]} and Google’s apps, being available on both Android and Apple devices. Google said that this means users have access to similar app catalogues

This is also consistent with the findings of studies by other national competition authorities.^{[footnote 249]} Further, while from 2015, academic research found that listing on both iOS and Android was common among the 3% of app developers that generated 80% of installed apps.^{[footnote 250]}

For app developers who have apps on both app stores, delisting from either the App Store or Play Store is unlikely to be a credible option. One of the key benefits to app developers of developing for iOS and Android is the ability to reach virtually all active smartphone users with the App Store and Play Store providing access to [50% to 60%] and [40% to 50%] of UK smartphone users respectively. As these users do not multi-home across iOS and Android, the App Store and Play Store both provide app developers with access to a large number of unique mobile device users.

Delisting from the App Store is likely to be particularly unattractive as:

• the App Store also provides access to [50% to 60%] of active tablets (compared to [20% to 30%] through the Play Store)

• Apple users are more valuable to apps using in app payment systems – for the UK in 2020 the average App Store user spent £[0 to 50] through Apple IAP^{[footnote 251]} compared to the average of £[0 to 50] per active Android mobile device through Google Play’s billing system.^{[footnote 252][footnote 253]}

Ultimately, for these app developers, delisting from the App Store or Play Store would mean forgoing existing revenue generated from users of that app store. Consistent with this, we have not seen material evidence of large app developers delisting from the App Store or Play Store and app developers who responded to our requests for information did not see this as an option.

App developers switching between the App Store or Play Store

A second possibility is that app developers who only have an app on the App Store could redevelop their apps for use only in the Play Store and vice versa. We understand this would involve significant costs as^{[footnote 254]} :

• native apps are written in the specific coding language for that operating system with the coding language of iOS and Android differing such that a developer would have to re-write its apps in a different coding language

• native apps are built using the specific framework of an operating system and these frameworks may differ across operating systems^{[footnote 255]} such that a developer would have to re-write its apps where relevant elements of these frameworks differed

This means that app developers would face a cost for redeveloping their apps for use in the Play Store/App Store.^{[footnote 256]} Given this and uncertainty around whether they would be able to replace their existing user base, it seems unlikely that app developers would switch from the App Store to the Play Store or vice versa. This is likely to be particularly the case for those only using the App Store, given users on average spend more per year through Apple IAP than Android users spend through Google Play’s billing system, on apps as set see out in Table 4.1 above.

Further, app developers only using one of the App Store or Play Store are likely to have smaller and less popular apps and therefore it is not clear that app developers of this nature would place a material constraint on Apple or Google in any event.

New app developers first deciding between the App Store or Play Store

Given the costs involved in developing native apps and the uncertainty of how new apps will perform, app developers may only develop their new apps for one mobile ecosystem initially.

For example, Apple stated that ‘app developers may face constraints to multi-homing (including liquidity or resource constraints) and therefore focus at first on the mobile platforms that are most profitable. Therefore, various mobile [operating systems] and other platforms have to compete for novel apps, ie for the entrants, who will typically not multi-home initially. It is important for mobile platforms to attract such entrants, as they often reflect the forefront of innovation, and help differentiate a mobile platform against its rivals.’

There appears to be some competition for new app listings between Apple and Google. They both provide app developers with tools and services aimed at making it easier for apps to be developed for their respective ecosystems and they have improved these tools and services over time. This is likely to have reduced the costs for app developers making it more attractive to develop for their mobile ecosystems. They have also provided app developers with new functionality over time which has provided app developers with new ways to innovate, increase content and generate revenue making opportunities.

However, this is likely to apply to new and thus less well-known apps making up a small proportion of downloads and if these apps become successful they are likely to have an incentive to develop for both mobile ecosystems given they each provide access to a separate group of users. It is also not clear that these apps would be visible to and affect the decisions of most users.

Google has also said that new cross-platform tools, including its own offering Flutter,^{[footnote 257]} are enabling app developers to build an app once and run it across iOS and Android and other operating systems without the need for any material re-coding or other work. Google submitted that 1 in 8 new apps on the Play Store were created using Google’s Flutter.^{[footnote 258]}

It is unclear to what extent app developers use these tools in practice, although they could reduce any competition for new apps. All of the large app developers who responded to our requests for information developed native apps for both Android and iOS. Less than a quarter mentioned cross-platform development tools and none would use them, for example, because native apps are better optimised for each operating system.^{[footnote 259]} For example, one app developer said that the technologies underlying a cross-platform development tool are held back by the pitfalls of both operating systems and the time taken to build the technology on top of updates to both operating systems.^{[footnote 260]}

Conclusion on constraint from app developers

Overall, we have found that there is a limited constraint on Apple and Google from the threat of app developers delisting from their app stores.

The evidence indicates that largest app developers accounting for most downloads are present on both the App Store and Play Store and would not delist from one of these app stores, due to the volume, value and uniqueness of users on each – this is particularly the case in relation to Apple, whose users spend more per year on average through Apple IAP than Android users spend through Google Play’s billing system.

We note that competition for app developers may also exist in relation to the prices charged in relation to and features of the native app made available on each app store. Evidence from app developers does show that, at least in some cases, they are willing to differentiate their app offerings across the App Store and Play Store. For example, some app developers explained that their native apps differed between iOS and Android devices because of differences in the functionality allowed by each operating system.

However, the competitive constraint placed on Apple and Google by any such differences depends on whether it would lead to users switching between using apps downloaded from the App Store and apps downloaded from the Play Store and vice versa. As set out in the next sub-section, we do not consider that the threat of such user switching places a significant constraint on Apple and Google in practice.

Users

Users who wish to switch between the App Store and Play Store must also switch between using an iOS device and an Android device. This can happen in 2 ways: (i) a user that has both an iOS device and Android device can simply switch their usage from one to the other; and (ii) a user that only has an iOS device or Android device would have to purchase a new mobile device to switch.

Most users only have either an iOS device or an Android device, as set out in Competition in the supply of mobile devices and operating systems, and we consider it unlikely that the relatively small number of users with both iOS devices and Android devices would provide a competitive constraint on Apple or Google.

This means that any constraint would only arise from users switching between the App Store and Play Store by purchasing a new mobile device. In that sense app distribution can be considered a secondary market to the primary market for devices and here we consider whether switching or the threat of switching by iOS users to Android devices or Android users to iOS devices in the primary market constrains Apple’s or Google’s behaviour in the secondary market.

Both Apple and Google consider their respective app stores to be an important part of the offering that comes with their mobile device/operating system and that they compete with each other for users:

• Apple told us that ‘the importance of a thriving app ecosystem for the success of a device can hardly be overstated’. Apple said that iOS and Android compete fiercely in terms of app availability and cited the example of Huawei’s drop in sales following the removal of the Play Store from new Huawei devices as evidence of the importance of app availability. Apple considers the importance of the app ecosystem is also reflected in the importance of the operating system in users’ decision making – Apple noted that [REDACTED]

• Google told us that ‘[operating systems] and app stores compete as a system’ and that ‘Play forms an important part of the Android platform that Google creates for [manufacturers], users and app developers.’ Google considers providing access to a wide range of popular and high quality apps to be an important parameter of competition and that across Android and iOS users have access to similar app catalogues as app developers typically multi-home. Google stated that as over 90% of apps are free on both the App Store and Play Store the cost of apps is of ‘very limited (if any) importance to users in deciding between mobile devices with different [operating systems]. Rather, it is the quality of apps available that matters to users’

Constraint from users switching

As set out in the previous chapter, as a general point we have found that both Apple and Google face a limited constraint from users switching (or the threat of users switching) between iOS devices and Android devices. In particular:

• most users purchasing a device are buying a replacement device and do not generally switch between mobile operating system, and this is particularly the case for Apple users

• there is limited price competition between iOS and Android devices with Apple dominating sales of high-priced devices and Android dominating sales of low-priced devices. The price gap between the 2 has grown over time yet this does not appear to have impacted on switching

• there appear to be material actual and perceived barriers to switching between mobile operating systems which include: (i) learning costs; (ii) barriers relating to the transfer of data, apps and managing subscriptions across devices, including some that arise due to requirements to use proprietary in-app payment systems; and (iii) barriers related to losing access to shared functionality between first-party apps, services and connected devices and having a worse experience of interacting with friends’ and family’s devices. These switching costs appear to be asymmetric, with iOS users generally facing higher barriers to switching than Android users

Further, it is more likely that users would switch if the actions of Apple or Google led to the largest app developers accounting for most downloads delisting from the App Store or Play Store. However, as found above, it is unlikely that these app developers would delist from one of these app stores, due to the volume, value and uniqueness of users on each.

While these app developers may differentiate their app offerings across the App Store and Play Store (for example, in terms of functionality as outlined above), we do not consider that this would lead to users switching between iOS and Android devices. This is both due to the general reasons set out above as well as the following factors.

First, new users who are not affected by barriers to switching and less likely to have existing brand loyalty make up a very small proportion of device sales each year. In addition, given they are buying their first devices they are likely to have a lower awareness of the conditions at the app store level and the extent to which they differ between the App Store and the Play Store.

Second, while existing users may have a better awareness of the conditions in relation to the app store they use, they are likely to have limited awareness of conditions on other app stores. In particular, this because they likely only have an iOS or Android device and not both so can only access the App Store or Play Store and not both.

In relation to both these 2 points, the lack of awareness will at least in part be due to a lack of transparency for users not currently using an app store. For example, users would generally have to have access to a native app on both app stores to understand any differences in the detailed functionality of that native app between iOS and Android devices. This would also be the case for in-app purchases and subscriptions which account for most of the user spending as set out in The role of Apple and Google in competition between app developers.

Third, users take into account a large number of factors when considering which mobile device and associated operating system to purchase. There are also multiple elements of cost that a user might incur in relation to a mobile device – the immediate cost of the phone and costs occurring in the future (ie deferred costs) relating to any accompanying mobile tariff and the cost of the apps, in-app content and subscriptions they will subsequently purchase. In the literature on markets and consumers it has been consistently observed that such complexity of costs (for example, multiple elements of cost across different time periods) are potentially problematic for consumers to consider when making purchasing decisions. This literature also identifies that deferred costs are likely to be ignored because myopia leads consumers to care more about present costs over future costs.^{[footnote 261]}

This means we would expect them to place more weight on more easily observable, immediate and quantifiable factors (for example, the upfront price or battery life) and less weight on less transparent, future and hard to quantify factors such as expenditure on apps, in-app purchases and subscriptions. Consistent with this in the survey evidence we have received apps, the prices of apps and the range of apps appear to have limited importance to users in their choice of device with a number of other factors being of higher importance.

Citing the findings of the Dutch competition authority, Apple considers that importance of the price and range of apps relative to other factors^{[footnote 262]} is driven by a lack of differentiation in the price and range of apps available across Apple’s ecosystem and Google’s ecosystem, such that users focus on areas of greater differentiation. Google stated that the cost of apps is of ‘very limited (if any) important users’ due to the fact that over 90% of apps on both the App Store and Play Store are free to download such that competition was on the quality of apps available.^{[footnote 263]}

Finally, the cost of a new device is likely to significantly outweigh any differences in the costs of apps.

The average price, excluding VAT, of an Apple smartphone in 2020 was £721^{[footnote 264]} which is considerably higher than the current levels of expenditure by users on apps, in-app purchases and subscriptions which was roughly £[0 to 50] per UK user of the App Store in 2020 or £[50 to 100] when considering UK users of the App Store engaging in a billable transaction^{[footnote 265][footnote 266]}. Users are unlikely to invest in a new smartphone due to a small rise in the prices of apps, especially when most native apps are free and the commission is currently at most 30% of the price so any increase may only have a relatively small impact on the overall price.

While the average price, excluding VAT, of an Android smartphone in 2020 was lower at £300,^{[footnote 267]} Apple’s SE iPhone currently retails on a standalone basis at £359 as set out in Competition in the supply of mobile devices and operating systems with the majority (66% in 2020) of Android smartphones being sold for less than £300.^{[footnote 268]} Given this, the lower spending of Android users in the Play Store (roughly £[0 to 50] per active Android device) ^{[footnote 269]} and evidence that Android users tend to be more price sensitive, we consider it even less likely that Android users would be likely to switch to a more expensive device.

Given mobile ecosystems are a 2-sided platform there may be a feedback loop – that is, if users switch then that could devalue the platform in the eyes of app developers such that app developers delist from the platform which would further devalue the platform in the eyes of users who could then switch and so on. We do not consider that there is likely to be a material feedback loop because, even with some user switching, app developers are unlikely to delist due to the volume, value, and uniqueness of the users in each mobile ecosystem.

Waterbed effect

As outlined above, Apple has argued that the commission it charges in relation to apps, in-app payments and subscriptions generates an incremental revenue flow which gives it an incentive to lower the price and increase the quality of its devices. This implies that any profits in native app distribution gives Apple the incentive to lower device prices (or otherwise offer consumers better terms for the purchase of a device). In support of this Apple has submitted a theoretical model which supports this waterbed effect under a number of conditions; and also submits that, while its margins on the iPhone have continuously decreased since 2012, App Store revenues have grown.

We accept that there is some waterbed effect as Apple has some incentive to lower the price of its devices in order to capture more app distribution revenue. We note that Android device manufacturers are also likely have an incentive to reduce device prices in order to capture more search advertising revenue through their Revenue Sharing Agreements with Google (see Appendix E for details on these agreements).

However, the relevant question is not whether there is a waterbed effect at all, but whether it is sufficient to offset Apple’s market power in native app distribution.

Whether the effect is sufficient will depend on a number of factors including the strength of the competitive constraint faced by Apple in the supply of mobile devices. In particular, this affects the extent to which lowering mobile device prices will lead to additional mobile device sales (and subsequent native app distribution revenues).

As set out above, as a general point we have found that Apple faces a limited competitive constraint from Android devices due to the key points outlined in the previous sub-section on user switching. This would suggest that the waterbed effect is unlikely to be sufficient to offset Apple’s behaviour in native app distribution.

Further, while it is difficult to assess the exact size of the waterbed effect, other evidence on barriers to entry and expansion and market outcomes are inconsistent with the position that it is sufficient to offset Apple’s behaviour in native app distribution.

First, Apple’s App Store makes gross margins of [75% to 100%] in 2020. At the same time Apple’s iPhone has the highest gross profit margin of Apple’s devices, having been relatively stable since 2018.

This suggests that the profits generated in the App Store are not being competed away by competition for mobile devices and operating systems – as outlined above, we consider Apple faces a limited constraint in relation to mobile devices and operating systems. This contrasts to other similar examples such as games consoles where, at least initially, we understand manufacturers often sell games consoles at a loss in order to capture revenue from games, subscriptions and accessories.^{[footnote 270]}

Second, while we have seen strong growth in the net revenue generated at the app store level between 2018 and 2020, we have also seen an increase in the price of Apple’s iOS smartphones both in absolute terms and relative to Android devices in the last 4 years. For example, Figure 4.7 shows that the average price, excluding VAT, of iOS smartphones in the UK is substantially higher than the average price of Android smartphones and this price gap has increased since 2017.^{[footnote 271]}

This does not appear to be consistent with the waterbed effect putting downward pressure on Apple’s prices in the device market. We are aware that this change in relative pricing may also be driven by other factors such as changes in the quality of the devices in question, however, we have not received any evidence to date to suggest this is driven by changes in the quality of the devices.

Figure 4.7: Average price, excluding VAT, of iOS devices and Android devices (not adjusted for inflation)

A time series chart that shows the average price (excluding VAT) of iOS devices and Android devices from 2017 to 2020. The chart shows that the average price for iOS devices rose from £575 in 2017 to £721 in 2020 whereas the average price for Android devices initially increased from £282 in 2017 to a high of £336 in 2019 before dropping back to £300 in 2020.

Source: CMA analysis of IDC data from ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’.

Notes: For details on how the number of units shipped and average selling price data were consolidated, visit Appendix C

Finally, Apple was not able to provide any internal documents to substantiate its claims that pricing decisions made by Apple at the device level are affected by service revenues.

Apple said that this was ‘precisely because this logic is foundational to Apple and has been inherent to the business model from the outset, Apple has been unable to identify specific business documents that discuss explicitly in the ordinary course the ‘link’ between the performance of the App Store and decision making for the device business’.^{[footnote 272]}

However, we consider it implausible that if service revenues were such a key factor in setting the prices of devices that there would be no documentation of this such as analysis seeking to optimise the pricing structure between the App Store and mobile devices. This is especially as optimising the pricing structure would not be trivial, particularly in the context of the observed increases in service revenues and the overall increase in the price of devices over time.

Apple has also stated that the incentives generated from its business model mean that the operation of the App Store will tend to pursue higher standards of quality, security, privacy and integrity of user experience (relative to a standalone app store), because the higher quality App Store attracts consumers to the device.

As outlined in the previous sub-section, we consider that it is unlikely that competition at the device level is likely to constrain behaviour at the native app distribution level. This is likely to be compounded by users’ lack of visibility of app store terms and prices when they purchase a device. For these reasons we also think it is unclear that the App Store would tend to pursue higher standards than a standalone app store which cannot rely on, for example, barriers to users switching to rival app stores.

In addition, it is not clear how these incentives would differ to those of Google in relation to the Play Store as, to the extent app stores do attract users to buy certain devices, Google has an incentive to attract more users to purchase Android devices as it increase the ad revenue they can generate and also the amount of data they can collect on users which further supports its ad-funded business.

Conclusion on competitive constraints between Apple’s and Google’s app stores

Overall, we have found that Apple and Google face a limited constraint from each other in relation to the presence of each other’s app stores. This is because:

• the largest app developers accounting for most downloads are present on both the App Store and Play Store and would not delist from one of these app stores, due to the volume, value and uniqueness of users on each – this is particularly the case in relation to Apple, whose users on average spend more per year through Apple IAP than Android users spend through Google Play’s billing system. Therefore, the threat of app developers moving away from their app store does not appear to exert a strong competitive constraint on Apple’s or Google’s operation of their app stores

• users generally do not have both iOS devices and Android devices. This means that an iOS user would need to purchase a new device in order to access the Play Store, and an Android user would need to purchase a new device in order to access the App Store. As found in Competition in the supply of mobile devices and operating systems, such switching is limited in practice. As outlined below, there are additional factors, such as the transparency of app store conditions, that make such switching unlikely in response to changes in the price or quality of apps available in different app stores. Therefore, we would not expect user switching to place a competitive constraint on Apple and Google at the app store level

Competitive constraints from alternative devices

This sub-section considers the competitive constraints faced by Apple’s App Store and Google’s Play Store from users and app developers moving their interactions to alternative devices such as gaming consoles, personal computers, and smart TVs.

Apple and Google submitted that they face competitive constraints from non-mobile devices, as users access content through both mobile devices and alternative devices. In addition, both cited gaming as a category which faces particular constraints from non-mobile devices such as gaming consoles and personal computers.

Overall, we have found that alternative devices are only a limited constraint on Apple’s App Store and Google’s Play Store. While there is a degree to which some of the same users access the same content through native apps on mobile devices and through alternative devices, this may be due to the complementary nature of cross-platform usage, as consumers may use these for different purposes. For example, mobile versions of apps may be used while ‘on the go’, while alternative devices may be used for longer-form or more intensive content. This implies that these alternative devices may not be substitutable for mobile devices.^{[footnote 273]}

We also note that, as set out in more detail in The role of Apple and Google in competition between app developers, the anti-steering rules of Apple and Google reduce the ability of app developers to steer users towards cheaper alternatives on alternative devices thus reducing the constraint they place on the App Store and Play Store.

Gaming consoles

Home gaming consoles, such as the Xbox and PlayStation consoles, are standardised computing devices tailored for video gaming, but which may also be used for other entertainment purposes such as video or music streaming, making them distinct from the more versatile personal computer. Handheld consoles such as the Nintendo Switch and Nintendo DS are portable gaming devices.

Apple and Google both submitted views and evidence that they face competitive constraints from gaming consoles. For example:

• Apple submitted that the ‘App Store faces vigorous competitive pressure from a variety of sources’ and identified alternative devices including PC platforms and console app platforms such as Nintendo’s eShop, Microsoft’s Xbox and Sony’s PlayStation, cloud-based gaming platforms and other platforms tablet devices. With respect to these alternative devices, Apple also said that there is a particular focus on gaming capability, and that ’Gaming applications often multi-home across game consoles, which are particularly attractive platforms for these types of applications’

• Google submitted that it faces competitive constraints from games consoles and PCs, and that this is a ‘particularly important competitive constraint because a large proportion of Play’s revenues come from users purchasing in-app content from games’ [REDACTED]. It also told us that games operate on multiple platforms, leading Play to compete to convince developers to focus their resources on mobile games

As a general point we note that gaming consoles are most relevant in relation to gaming apps, albeit this is an important category, [REDACTED].

Further, in contrast to the views expressed by Apple and Google, our analysis and the responses we have received from app developers indicate that there is limited substitutability between mobile apps and gaming consoles. In particular:

• we note that there are gaming app developers who do not make their apps available on gaming consoles, such as Niantic, and PLR Worldwide Sales Limited

• a growing amount of consumer time is spent on mobile devices, and in particular, users are increasingly using their mobile devices for gaming.^{[footnote 274]} This has led to mobile gaming being increasingly important to game developers

• a few large app developers told us that there is limited substitutability between mobile devices and gaming consoles for users. While the same users do play their games on both mobile devices and games consoles, this may be due to the complementary nature of different devices with consumers using them for different purposes and in different situations. This indicates that these devices may be complementary rather than substitutable. For example, Epic Games told us that gaming consoles have substantial hardware, rendering it impractical for consumers to access the internet anywhere and anytime, are far less portable, and lack key features like an easy-to-use camera and GPS. However, they have the advantages of a larger screen, more precise controls with a controller and superior performance. These reasons make gaming consoles well suited for stationary longer-term play, and less suited for use ‘on the go’, such as when commuting or waiting for an appointment, which mobile devices are better suited for. Microsoft submitted economic research by Compass Lexecon regarding mobile and console gaming, which found that native mobile games differ from console games in substance in significant respects, such as game selection, content and gaming experience, leading them to be less suitable substitutes for mobile app users.^{[footnote 275]} This analysis suggests that mobile gaming is a distinct market from console gaming, both for app users and developers

• there may be asymmetric substitutability between mobile devices and gaming consoles, such that consumers who predominantly use gaming consoles may occasionally use a mobile app in specific use cases or while on the go,^{[footnote 276]} but consumers who predominantly use mobile apps are less likely to switch to gaming consoles. This may partially be due to many mobile users not owning a gaming console, and this requiring a high up-front cost. For example:

  • both Epic Games and Microsoft’s submission of Compass Lexecon’s economic research found that there are high upfront costs to purchasing a gaming console. Consistent with this, we have found that, per year, the average user spending through Apple IAP (which includes any spending on gaming apps) is £[50 to 100] when considering users of the App Store engaging in a billable transaction^{[footnote 277]} compared to the upfront costs of gaming consoles, which is around £259 for Sony’s PlayStation 4 and £249 for Microsoft’s Xbox One S^{[footnote 278]}

  • additionally, Compass Lexecon’s economic research noted that mobile apps typically use a free-to-play model, with a minority of customers making in-app purchases. Comparatively, gaming console games typically require upfront payment, which can be in the realm of £60^{[footnote 279]}

As well as the examples given above of why consumers may find mobile devices and gaming consoles to not be substitutable, we have heard there are also differences which may make these less substitutable for app developers. For example, Microsoft’s submission of Compass Lexecon’s economic research found that high-end console games require considerably higher investment of money, time and resources, when compared to low-end games for mobile devices.^{[footnote 280]} It also found that most top iOS game app developers do not port their mobile games to consoles. According to preliminary analysis from Keystone, 15 to 25% of console developers develop for mobile, and less than 30 to 45% of mobile app developers also develop games for consoles.

Personal computers (PCs)

Apple and Google have submitted that they face competitive constraints from non-mobile alternatives such as personal computers (PCs – namely desktops and laptops).

In contrast to the views expressed by Apple and Google, our analysis and the responses we have received from app developers indicate that there is limited substitutability between mobile apps and PCs, though this may vary depending on the purpose of the app.^{[footnote 281]} Some apps also benefit from complementarity of use across multiple devices. In particular:

• across computers, tablets and smartphones, 68% of the time spent online in September 2020 was on smartphones, up from 65% in September 2019. In contrast, only 18% of the time spent online was via computers, and 13% via tablets^{[footnote 282]}

• while there may be some degree of multihoming and switching between mobile devices and PCs, many app developers told us that this is primarily due to these devices having differing use cases and capabilities, which make them suitable for different situations. This indicates that these devices may be complementary rather than substitutable, particularly for productivity and gaming apps. Other apps, such as those used for dating and food delivery services may be less suitable for use on a PC. For example, Epic Games told us that PCs are not good substitutes for mobile devices due to various differences in features that mean a PC cannot be used ‘on the go’. Microsoft told us that while some of its apps such as Outlook appear to have more multi-homing between mobile and PC, this may be due to consumers using these for different purposes. A significant amount of usage of mobile platforms is unique to mobile scenarios (while traveling, for example), where other types of non-mobile platforms are not a viable option

As well as the examples given above of why consumers may find mobile devices and PCs to not be substitutable, we have heard there are also differences which may make these less substitutable for app developers. For example, one app developer told us that different platforms have different developer APIs, so an app for one platform is essentially rewritten to operate on another platform. It told us that devoting the resources to write and maintain apps across platforms, and then make those apps work across platforms with each other, would only be worth the investment if there was sufficient customer demand, which there is not today.

Smart TVs

Apple and Google have submitted that they face competitive constraints from non-mobile alternatives such as smart TVs.

In contrast to the views expressed by Apple and Google, our analysis and the responses we received from app developers on smart TVs indicate that there might be some limited substitutability between mobile devices for particular use cases such as streaming or listening to music, and none otherwise.^{[footnote 283]}

While there may be some degree of multihoming with smart TVs, respondents also told us that this is primarily due to these devices having different use cases, which make them suitable for different situations. For example, smart TVs may be used for static consumption of longer-form content, while mobile devices may be used for consumption ‘on-the-go’.^{[footnote 284]} This indicates that these devices may instead be complementary, rather than substitutable.

[One app developer] told us that customers have specific use cases for accessing an app via different devices. For example, in the context of audio-visual entertainment services, customers may use a mobile device while travelling and a smart TV for longer-form content which they view at home. Spotify said that the user experience when using a smart TV is differentiated from mobile devices, such that they are not substitutable. For example, the Spotify app on a smart TV is intended to stream music out loud (ie without headphones) in a stationary place, and often to a greater volume level than that which a mobile device will usually play music over its speaker.

Apple’s and Google’s operation of their app stores

As noted above, to the extent that Apple and Google do not face strong competitive constraints from actual or potential alternative methods of app distribution, each are likely to have market power through their operation of the App Store and Play Store. This encompasses aspects of the operation of these app stores such as the app review process, the ranking of apps on the relevant store and associated advertising services provided to app developers).

In this section, we have considered whether evidence of aspects of Apple’s and Google’s operation of their app stores is consistent with market power. In particular, we consider the following rules set by Apple and Google in relation to access to their app stores:

• the commissions charged by Apple and Google on in-app purchases^{[footnote 285]}
• other key rules relating to the types of apps that are permitted to operate on their app stores

Commissions charged by Apple and Google on in-app purchases

Both the App Store and Play Store require that in-app payments relating to digital content must be made through their own proprietary payment systems, through which Apple and Google handle the processing of the transaction and also deduct a commission before the payment is then remitted to the app developer. Apple and Google both currently charge a commission of 30% for payments made via Apple IAP and Google Play’s billing system, except in limited circumstances where a lower commission rate is applied as described in Appendix H.

Apple has created certain exemptions for certain types of native apps and reduced commission rates to particular groups of native apps over time. In 2016, Apple reduced the commission on subscriptions after their first year to 15%.^{[footnote 286]} In January 2021, it introduced the Small Business Program,^{[footnote 287]} under which app developers that earn no more than $1 million in the previous year pay a reduced commission rate of 15% on in-app transactions.

Google has followed Apple in introducing similar reduced commission rates for certain types of app, although in some respects, Google has gone further:

• in 2018, similar to Apple, Google lowered its service fee on subscriptions after their first year to 15%. Google has in addition announced that from January 2022 this discount will apply to all subscriptions from the first day of a subscription^{[footnote 288]}

• in July 2021, Google lowered its service fee to 15% for the first $1 million of global earnings to all app developers.^{[footnote 289]} This is similar to Apple’s Small Business Program but applies not only to smaller developers earning less than $1 million, but also the first $1 million earned by larger developers

The changes made prior to 2021, which includes the reductions made by both Apple and Google to the commission on subscriptions after their first year to 15%, have not had a very material impact on the average commission rates for Apple’s and Google’s payment systems, which remain [close to 30%]. This demonstrates that these discounts only apply to a small proportion of transactions.

The additional changes made in 2021 have yet to be fully reflected in Apple’s and Google’s commission revenues. However, the effect of these discounts on Apple’s and Google’s commission revenues appears likely to be limited. As noted in The role of Apple and Google in competition between app developers, the vast majority of Apple’s and Google’s app store revenues come from a small number of larger apps. These apps would not benefit from Apple’s Small Business Program and only to a limited extent from Google’s discount on the first $1 million of global earnings. Although Google has lowered its service fee to 15% for all subscriptions going forward, this appears likely to have a limited effect on Google’s overall revenues from the Play Store as Google receives a relatively low proportion of its revenues from subscriptions.

Both Apple (visit footnote 230) and Google (visit footnote 231) submitted that the recent introduction of these discounts has been driven in part by competition. While we note that Google’s changes have closely followed Apple’s proposed changes, suggesting some competitive dynamic between the 2, it is not clear to what extent the changes are genuinely driven by competition.

While Apple prohibits alternative app stores on iOS devices, Google Play faces some direct competition from other app stores on Android devices, such as the Samsung Galaxy Store. We have not found evidence that these alternative app stores compete directly with Google Play by offering lower commissions. For example, similar to Google, the Samsung Galaxy Store has a 30:70 revenue split between Samsung and the app developer.^{[footnote 290]} The limited competition over the level of the commission from alternative app stores may be due to a range of factors set out above, which limit the ability of alternative app stores to attract transactions away from Google Play.

We have also considered how the Apple IAP and Google Play commissions compare to app stores on other mobile and desktop devices:

• Microsoft Store is available on Xbox gaming consoles and Windows devices. On Xbox, all transactions through the Microsoft Store are subject to a 30% commission fee from Microsoft. Microsoft has recently reduced the Microsoft Store commission on Windows from 30% to 12% for games in August 2021. For non-games, the Microsoft Store commission on Windows is 15%, and from July 2021, Microsoft has allowed developers of these apps on Windows to choose their own payment system for in-app purchases and avoid paying any commission to Microsoft

• Amazon Appstore, available as a native app for the Android and Fire operating systems, pays app developers a royalty of: (i) 70% on app downloads, in-app purchases and in-app subscription products sold through mobile devices for products other than movies and television; and (ii) 80% for in-app subscription products sold through mobile devices for movies and television^{[footnote 291]}

• Epic Games Store is available as a native app on Windows and Mac devices and plans to bring the platform to Android and iOS devices in the future. It charges a 12% commission on games. In addition, for games which are built using Epic’s Unreal Engine, the usual 5% revenue licensing fee is waived on sales through the Epic Games Store^{[footnote 292]}

• Steam is a digital game store available on desktop devices. It operates a revenue sharing agreement where Steam takes a 30% commission. However, once a game makes over $10 million, Steam’s split reduces to 25% and decreases further to 20% for all earnings beyond $50 million

These comparisons show that Apple IAP and Google Play commissions are broadly similar to those charged by other similar comparator app stores. However, it is difficult to draw a direct comparison between the App Store and Play Store with other app stores. First, as discussed below, app stores available on Android devices may have limited ability to attract customers away from Google Play by offering a lower commission due to Google Play’s advantages from preinstallation and indirect network effects. Second, Apple’s and Google’s app stores have a different business model to platforms, in that they also increase the value of their respective mobile devices and operating systems, from which Apple and Google already profit. This contrasts to ‘standalone’ app stores which do not provide this benefit, or, for example, to Microsoft’s Xbox, where consoles are priced at low, no, or negative margin, while profits are subsequently generated through the sale of games and subscriptions on the Microsoft Store.

As discussed in Overview of mobile ecosystems, with more detail in Appendix D, Apple and Google make substantial profits in app distribution and we estimate that the App Store’s gross profit margin was [75% to 100%] and that the Play Store’s global operating margins were [50% to 75%] in 2020, which is consistent with market power.

Other key rules relating to the types of apps that are permitted to operate on their app stores

Apple’s and Google’s ownership of their respective operating systems means that they are able to dictate the terms that govern the rules of competition for apps on their devices. This gives Apple and Google very strong positions in relation to the developers that use their app stores and contributes to their market power in app distribution.

A particular concern in relation to Apple, discussed in more detail in The role of Apple and Google in competition between app developers, is that Apple has used its control over access to the App Store to block the emergence of an innovative cloud gaming business model, where games are streamed to users’ devices through cloud platforms, rather than being downloaded individually as separate apps. One of the effects of this is to protect the position of the App Store as the place users on Apple devices go to discover and access games. Mobile gaming apps are the largest category of native apps in terms of downloads from the App Store (more than 30% in the UK in 2020) and generate over half of net revenue through Apple IAP. ^{[footnote 293]}

Apple’s and Google’s ownership of their respective operating systems also gives them control over APIs and the functionality these APIs govern access to. For many app developers these APIs are important. As discussed in The role of Apple and Google in competition between app developers, Apple has restricted access of some APIs to itself or to itself and certain privileged third parties, such as the APIs governing access to the technology required for contactless payments. The same concerns have generally not been raised about Google, with the one exception being around the restrictions on the ability of third-party voice assistants to access the same functionality within Apple’s and Google’s operating systems that Apple’s Siri and Google’s Google Assistant can access.

Apple and Google also have access to large volumes of commercially sensitive information on the businesses of the app developers who create apps for their respective ecosystems. As discussed in The role of Apple and Google in competition between app developers, we have heard concerns about Apple’s ability to use this sensitive information in order to develop its own apps or gain a competitive advantage over rivals.

Apple’s and Google’s app stores play a key role in app discoverability for developers. Apple and Google have the ability to influence the discoverability of apps on their app stores, through their control over the rankings of apps in search results and over which apps are featured as part of editorial content.

Finally, Apple’s control of the App Store enables it to introduce policies and terms which may support its competitive position, such as App Tracking Transparency (ATT), which presents prompts to users of apps in relation to the tracking of their personal data. The ATT framework has some benefits to users in terms of greater control over the processing of their personal data, while its design is likely to undermine the ability of app developers to acquire customers for their apps using mobile advertising outside of the App Store. We examine the design and impacts of the ATT framework in The role of Apple and Google in competition between app developers and Appendix I.

Key findings regarding the distribution of native apps through the App Store and Play Store

We have found that both Apple and Google have substantial and entrenched market power in native app distribution, with limited constraints on either the App Store or the Play Store from any of the potential sources of competition that we have assessed.

In relation to alternative methods of native app distribution:

• Apple does not face any constraint as it does not allow any alternatives
• Google’s Play Store only faces a limited constraint from alternative methods of native app distribution in its mobile ecosystem. While Google’s ecosystem is more open, alternatives to the Play Store are not widely used by users or app developers and face material barriers (particularly as the Play Store benefits from substantial indirect network effects which act as a barrier to entry and expansion for alternative app stores)

In addition, we have identified 2 of Apple’s policies that serve to entrench its position in native app distribution by undermining other forms of native app discovery within its mobile ecosystem – namely ATT and its policy on cloud gaming services. We have also identified certain agreements that Google has with manufacturers and a recent initiative aimed at app developers which are likely to have limited the constraint from alternative Android app stores, including new entrants. As further set out in The role of Apple and Google in competition between app developers below, Apple’s and Google’s policies on the use of their own payment systems and rules which restrict the ability of app developers to inform consumers within an app of the ability to purchase in-app content (possibly at a cheaper price) elsewhere, such as on a website, may also reinforce the market power of app stores as a way for users to discover and pay for content.

We have also found that the competitive constraint from web apps on the App Store and Play Store is likely to be limited. In particular, evidence suggests that the development and usage of web apps is substantially lower than native apps, and the view of many app developers we have heard from is that they are not currently a viable alternative distribution channel. We understand that this is in large part down to a combination of restrictions and limitations of functionality within Apple’s ecosystem, which undermine the incentive for developers to invest in web apps across both ecosystems.

We have also found that Apple and Google place a limited competitive constraint on each other in relation to native app distribution. This is because:

• the largest app developers accounting for the most downloads tend to multi-home on both the App Store and Play Store and would not delist due to the volume, value and uniqueness of users on each – this is particularly the case in relation to Apple whose users spend more. In addition, while app developers could favour one mobile ecosystem over another (for example, in terms of pricing, content or functionality), it is not clear how much this happens in practice and the impact on Apple or Google depends on whether it would lead to users switching

• while users could in theory constrain the App Store/Play Store by switching between mobile ecosystems, as set out in Competition in the supply of mobile devices and operating systems, we generally consider that Apple and Google face limited constraints from users switching between mobile ecosystems. In this context the extent of any competitive constraint is further limited by factors such as low multi-homing, a lack of transparency of the price and quality of apps in each app store and the uncertainty of app expenditures compared to high device prices mean that users are unlikely to switch

We have also found that Apple and Google face a limited competitive constraint from alternative devices. While there is a degree to which the some of the same users access the same content through native apps on mobile devices and through alternative devices, this may be due to the complementary nature of cross-platform usage, as consumers may use these for different purposes. For example, mobile versions of apps may be used while ‘on the go’, while alternative devices may be used for longer-form or more intensive content. This implies that these alternative devices may not be substitutable for mobile devices. Consistent with this, generally, app developers did not consider their offerings on alternative devices to be substitutes for their offerings on mobile devices.

5. Competition in the supply of mobile browsers

Key findings

• The combined share of supply for Apple’s and Google’s browsers on mobile devices in the UK amounts to around 90%, with Safari having a share of close to 50% and Chrome a share around 40%.

• Browser engines are the critical technology that enables browsers to load and display content on a web page. Their design is fundamental to the performance and capability of a browser. In 2020, at least 97% of all mobile web browsing in the UK was performed on top of Apple’s and Google’s browser engines.

• These positions provide Apple and Google with substantial and entrenched market power in the supply of mobile browsers and browser engines, which serve as a key gateway between consumers and online content providers.

• Both Apple and Google benefit from widespread pre-installation of their browsers on mobile devices, which is a key driver of browser use. In the UK, Safari is pre-installed and set as the default browser on all iOS devices, while Chrome is pre-installed on most Android devices, and the default on many.

• On iOS devices, Apple bans the use of alternative browser engines – this means that Apple has a monopoly over the supply of browser engines on iOS. It also chooses not to implement – or substantially delays – a wide range of features in its browser engine. This restriction has 2 main effects:

  • limiting rival browsers’ ability to differentiate themselves from Safari on factors such as speed and functionality, meaning that Safari faces less competition from other browsers than it otherwise could do; and
  • limiting the functionality of web apps – which could be an alternative to native apps as a means for mobile device users to access online content – and thereby limits the constraint from web apps on native apps. We have not seen compelling evidence that suggests Apple’s ban on alternative browser engines is justified on security grounds.

Introduction

Web browsers are a type of mobile application that enables users of mobile devices to access and search the internet and interact with content on the open web.^{[footnote 294]} Other than app stores, web browsers are the most important way for users of mobile devices to access content and services over the internet, spending a higher proportion of their time on browsers than on any other single native app.^{[footnote 295]}

In addition to the important role that browsers play in enabling users to search for and consume content, browsers are one of the key sources of traffic for search engine providers as well as other businesses that want to reach users with their content and products. Browsers also play a role in enabling businesses to monetise their content by serving users with advertising (or ‘ads’). These businesses, and the ad tech intermediaries operating on their behalf, in many cases collect and use data about users’ browsing behaviour, in order to display targeted ads to them.

In this chapter, we consider the level of competition in the supply of mobile browsers by covering the following topics:

• the supply of browsers
• the nature of competition faced by Apple and Google
• barriers to effective competition for browsers and browser engines
• the ways in which market power in the supply of browsers and browser engines on mobile devices can be used to reinforce or strengthen a market position in relation to other activities, such as digital advertising

The supply of browsers

How browsers work

Browsers comprise 2 main elements:

• a browser engine, which transforms web page source code into web pages (or web apps) that people can see and engage with
• a branded user interface (UI), which is responsible for user-facing functionality

Browser engines interpret the source code of each web page. The main reason that web pages sometimes look, load and work differently in different browsers is their browser engines. The browser engine is responsible for key functionality in a browser including its web compatibility (ie the browser’s ability to properly access and display the content on a particular web page). The browser engine also determines the range of possible user inputs (for example, camera, microphone or video game controller). As a result, browser engines control the type of content that can be developed on the web, and significantly influence the products and services which consumers can access online. Important components of browser engines include HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) layout and rendering functionality, a JavaScript engine and the core technology for a browser’s networking, UI backend and data persistence. The 3 key browser engines under active development are Google’s Blink, Apple’s WebKit, and Mozilla’s Gecko.

The browser UI is responsible for features such as favourites, browsing history and remembering passwords and payment details. It also determines the layout of the navigation bar and settings. The default search engine is set as part of the browser UI. The UI sits on top of the browser engine and is provided by all the brands familiar to users such as Chrome, Edge, Safari, Firefox and Samsung Internet.

Figure 5.1: Simplified anatomy of a browser

Figure description: An illustration that on the left hand side shows the user interface of a browser. On the right hand side it illustrates that 2 main elements of a browser are the user interface and the browser engine that controls the type of content.

In addition to web content being displayed in dedicated browser apps, there are certain instances where users access web content without a separate browser being opened, with web content instead being rendered in the context of native apps. Where this happens, the user, when clicking on a link to the website, remains in the native app and views the web content on a so-called in-app browser.^{[footnote 296]}

Examples of native apps with in-app browsers include a large variety of different types of apps, including chat apps such as Snapchat or WeChat, online social networks such as Facebook or Instagram, search widgets such as Google Search and Microsoft Bing Search, and email clients such as Gmail.

Browser vendors’ business models

There are many operators which distribute their own browser, although ultimately, as described below, the supply of mobile browsers is concentrated between Google’s Chrome and Apple’s Safari, and the supply of browser engines is concentrated between Google’s Blink and Apple’s WebKit.

As is shown by Table 5.1, some companies operate as standalone browser vendors, while others provide browsers alongside other complementary services, including search engines.

Table 5.1: Ownership and stewardship of browsers, browser engines and search engines by selected stakeholders

Organisation	Browser	Browser Engine*	Search Engine
Google	Chrome	Blink	Google Search
Apple	Safari	WebKit	-
Microsoft(**)	Edge	-	Bing
Mozilla Foundation	Firefox	Gecko	-
Samsung	Samsung Internet	-	-
Opera	Opera	-	-
DuckDuckGo	DuckDuckGo Privacy Browser	-	DuckDuckGo
Ecosia	Ecosia	-	Ecosia
Vivaldi Technologies	Vivaldi	-	-
Brave Software	Brave	-	Brave Search
Yandex	Yandex Browser	-	Yandex Search
Moonchild Productions	PaleMoon, Basilisk	Goanna	-

(*) As described below, modern browser engines are rarely proprietary; this table indicates where organisations are the steward of an open source browser engine in active development. Opera used a proprietary engine (Presto) until the release of Opera 15 in 2013.

(**) Microsoft continues to maintain 2 proprietary legacy browser engines, Edge HTML and Trident, which power the Edge Legacy and Internet Explorer browsers respectively. Microsoft’s modern Edge browser uses Blink.

Rationale for developing and distributing a browser

Browsers are not monetised directly, as web content can be provided through mobile browsers for free and users are not charged for using a browser. However, browser vendors are still able to generate revenues through their browser, namely through:

• search advertising (the primary way in which browser vendors derive revenue from browsers)
• other forms of advertising

In addition, there are certain other reasons why browser vendors may choose to develop and distribute a browser, including:

• using the browser to reinforce or strengthen a market position in relation to other activities
• missions of public interest (for example, to preserve the open web)

We describe in the sections below how each of these business models applies to some of the most popular browsers available today.

Search advertising

Search advertising, in which sponsored ads are provided in response to users’ search queries, is typically the most important source of revenue for browsers. Browsers generally come with a default search engine and thereby function as an important access point for search engines to users.^{[footnote 297]}

Browser vendors which set their own search engine as the default in their browser can thereby increase their own search advertising revenue. Microsoft, Ecosia and Yandex are examples of companies that link their browsers and search engine in this way.

While Google also used to do this, following the European Commission’s Google Android decision and the remedy that was imposed, Google no longer sets Google Search as the default in the UK and the EEA; it provides a choice to users via a search engine choice screen. From September 2021 onwards, Google has begun showing a revised choice screen and no longer charges search engines to be listed on the choice screen.^{[footnote 298]} The effect of a user selecting a search provider from the choice screen is to: (i) set the search provider in a home screen search box to the selected provider; (ii) set the default search provider in Chrome (if installed) to the selected provider; and (iii) install the search app of the selected provider (if not already installed). However, in practice almost all users choose Google Search: in the year to 31 August 2021 in the UK, in [90% to 100%] of cases in which the choice screen was used, Google Search was chosen.

Browser vendors without a search engine sell the default setting to a search engine provider. Safari, Mozilla and Samsung’s browsers are all monetised in this way. Browsers where Google Search is set as the default search engine accounted for over 99% of mobile browser pageviews in 2019.^{[footnote 299]}

The sale of search defaults attracts large payments.^{[footnote 300]} Google typically makes default payments on a revenue-share basis. Under these agreements, a percentage of the advertising revenue generated by the search engine through the search access point(s) is shared with the access point owner (ie the browser vendor), after some pre-defined costs have been deducted.

In 2019, Google made a total of just under £1.2 billion in payments to browsers for the direction of UK users’ search traffic to Google Search. Google’s payment to Apple in 2019 constituted the substantial majority of Google’s total 2019 default payments made for UK search traffic. Therefore, both Apple and Google make significant revenues from search traffic that is derived from users accessing their browsers on mobile devices.

This demonstrates an important link between Apple’s and Google’s control over their browsers and the revenues they are able to make in relation to search advertising. In the second half of the study, we will consider further the role of search agreements and any impact they could have on competition between browsers, in particular between Safari and Chrome on iOS devices.

Other forms of advertising

Browser vendors can also earn revenue from other forms of advertising, for example by promoting sites or showing static or video ads (display advertising) on the ‘new tab’ landing page. This typically accounts for a relatively small proportion of their revenue.

Using browsers to reinforce or strengthen a market position in relation to other activities

Some browser vendors develop and distribute a browser because it complements other products they sell:

• Apple submitted that ‘one of the key innovative features of the original iPhone was the Safari web browser, because it was the first mobile browser that was as capable and powerful as a desktop browser’

• Google distributes Chrome to improve user experience and drive content on the web (from which Google’s advertising business benefits)

• Samsung submitted that it produces a browser because it is important for users to have a browser on the device to be able to start browsing without further action; for example, this helps provide an experience that works ‘out-of-the-box’

• Microsoft told us that using Edge on Windows helps to make the Windows operating system better and more attractive to users, thereby increasing customer demand for Windows (we note that this relates to why Microsoft has a browser, rather than a mobile browser specifically)

The supply of a browser on a mobile device may also enable Apple and Google to strengthen or reinforce their market position in respect of other activities, such as in relation to the distribution of native apps. For example, Apple may be able to use its position as the steward of WebKit, the sole permitted browser engine on iOS, to limit the success of web apps and promote or reinforce the take up of native apps that are only accessed through its App Store. We consider these issues in more detail in the final section of this chapter.

Missions of public interest

Firefox is developed by a subsidiary of the Mozilla Foundation, a non-profit organisation. Mozilla submitted that offering a mobile browser developed with Mozilla’s values is part of its mission of a decentralised, interoperable and open web.

Tor is another browser developed by a non-profit organisation. It is operated by the non-profit Tor Project, with a mission to provide private access to an uncensored web.^{[footnote 301]}

Ecosia (which operates a browser and a search engine of the same name) uses its profits to plant trees.^{[footnote 302]}

Rationale for developing a browser engine

As noted above, there are 3 main browser engines under active development (across both mobile and desktop):

• Blink, which is controlled by Google, is used (on non-iOS devices) by Chrome and many other browsers including Edge.^{[footnote 303]}

• WebKit, which is controlled by Apple and provides the basis for Apple’s own web browser Safari and must also be used by any other browser on iOS devices. This means, for example, that the version of Chrome on iOS devices is based on WebKit rather than Blink.

• Gecko, which was developed by Mozilla and provides the basis for its own Firefox browser, and some other browsers.^{[footnote 304]}

All 3 major browser engines are open source projects: they are not directly monetised; their code can be viewed by anyone; and anyone can suggest changes.^{[footnote 305]} However, each browser engine has a ‘steward’, and it is the steward that determines which changes are ultimately accepted and that is therefore in control of the open source project.

One of the advantages of developing an open source browser engine is that it can benefit from development contributions from many sources. As it can be included in multiple browsers, an open source engine is also more likely to be prioritised by web developers (and therefore will tend to have greater compatibility with websites).

An important consequence of the open source status of these browser engines is that a developer can use their existing code as the starting point from which to develop their own browser engine (so-called ‘forking’). As was discussed in respect of mobile operating systems in Competition in the supply of mobile devices and operating systems, ‘forking’ from an existing code base can be less costly than developing a brand new code for a browser engine from scratch (which is highly resource intensive and very expensive as a result).

Box 5.1: History of browser engine development

• In the early years of the web, the most popular browser engines (the Netscape browser engine and Trident, the browser engine used in Microsoft’s Internet Explorer) were proprietary.

• Gecko was the first of the major modern browser engines to launch as an open source project. Its code was made open source in 1998.

• Apple created WebKit by forking an existing open source browser engine, KHTML, in 2001. In 2005, Apple made WebKit open source.

• Google launched Chrome using WebKit in 2008.

• Google deployed a new browser engine for Chrome, Blink (of which Google is the steward), by forking WebKit in 2013.

• Microsoft switched from using its proprietary EdgeHTML browser engine for Edge to Blink in 2020.

Visit Appendix F for a more detailed description of the history of browser engine development.

The stewards of the 3 main browser engines each have different rationales for developing their respective browser engine.

Apple requires all browsers on iOS to use its WebKit browser engine. As described above, Safari was part of the original iPhone’s competitive proposition at its launch and is based on WebKit. Apple may be incentivised to continue to invest in WebKit in order to compete as a supplier of mobile devices (although this incentive is likely to be limited given that, as discussed in Competition in the supply of mobile devices and operating systems, the browsing experience is only one factor amongst many in consumer decision-making when purchasing a mobile device).^{[footnote 306]} Apple submitted that WebKit today ‘focuses on providing stability, performance, battery efficiency, privacy, security, and ease of use’ for iOS device users. While in principle WebKit can be used by a browser running on non-iOS devices, no browser using WebKit has a material share of supply on Android (although, as described above, Blink is itself a fork of WebKit).

Google has stated publicly that its rationale for launching Blink was to ‘spur innovation and over time improve the health of the entire open web ecosystem’.^{[footnote 307]} Google’s internal communications, provided to the CMA in response to the CMA’s formal request, also set out a similar rationale. As explained in Overview of mobile ecosystems, Google’s primary source of revenue comes from search advertising, which is closely tied to web use – Google therefore has a strong financial incentive to support increased web browsing activity.

Mozilla told us that it develops the Gecko browser engine ‘to shape the internet and pursue our public mission of a decentralised and open web’.

As with the supply of browsers more broadly, we also consider that operators of browser engines may be able to use their control over web functionality to reinforce or strengthen their position in other activities (as discussed in further detail below), which provides a further potentially important rationale for developing a browser engine.

Shares of supply

Both globally and at the UK level, Apple’s Safari and Google’s Chrome browser are the largest browsers on mobile (and desktop) devices. The available data shows that the combined share of these 2 browsers on mobile devices in the UK amounts to around 90%, with Safari having a share of close to 50% and Chrome a share around 40%.^{[footnote 308]}

Apple and Google also have the largest browser engines. Their browser engines had a combined share of almost 100% on mobile devices in the UK, and largely mirrored the respective shares of their operating systems, with WebKit accounting for just over 50% and Blink just under 50%.^{[footnote 309]}

Below, we discuss shares of supply in more detail, considering in particular^{[footnote 310]} :

• shares of supply for browsers over time
• shares of supply for browsers and browser engines by operating system

Browser shares of supply over time

Figure 5.2 below shows the evolution of shares of supply for browsers on mobile devices in the UK from 2012 until 2021^{[footnote 311]}. In particular:

• currently, Safari and Chrome are the largest browsers. In 2020, their combined share of supply amounted to almost 90%, with Safari accounting for 48% and Chrome for 40%

• over time Safari’s share of supply has been relatively stable, although it has decreased slightly since 2012. In contrast, Chrome’s share of supply increased substantially, from 2% in 2012 to 40% in 2021

• Samsung Internet is the only other browser with a market share above 5%. It gained share significantly in 2016 and has remained at around 6% to 8% since

• while BlackBerry used to be the third largest mobile browser in the UK (15% in 2012), it has had virtually no presence (<1%) since 2017

Figure 5.2: UK browser share of supply (mobile)

Figure description: A time series area chart stacked to 100% that shows the evolution of shares of supply for browsers on mobile devices in the UK from 2012 until 2021. It shows that currently Safari and Chrome are the largest browsers, and Samsung Internet is the only other browser with a market share above 5%. It also shows that over time, Safari’s share of supply has been relatively stable whilst Chrome’s share of supply has increased substantially.

Source: Statcounter, Mobile browser share of supply UK 2012 to 2021

Note: Mobile refers to smartphones and tablets. The figure was calculated based on page views data from Statcounter. Android refers to AOSP-based browsers developed on top of the web browser apps made available through the Android Open Source Project. European Commission, Google Android decision, footnote 1034.

We have also considered shares of supply for browsers for mobile and desktop devices combined. Figure 5.3 below shows the evolution of these shares in the UK from 2012 until 2021. In particular:

• similar to their position on mobile devices, Safari and Chrome are also the largest browsers when considering mobile and desktop devices combined. However, Safari’s position on mobile and desktop devices combined is weaker (34% compared to 48% on mobile devices in 2020), while Chrome’s position is stronger (49% compared to 40% on mobile devices in 2020)

• both Safari’s and Chrome’s position has been growing over time, although their share has remined relatively stable in the last few years

• historically, Microsoft’s Internet Explorer and Mozilla’s Firefox had significant positions, with Internet Explorer being the largest and Firefox the third largest browser in 2012. However, over time, their shares decreased significantly, with each falling below 5% by 2019. Also, Edge, which replaced Internet Explorer, was able to only recapture a fraction of Internet Explorer’s share, and currently holds a share of around 6%

Figure 5.3: UK browser share of supply (mobile & desktop)

A time series area chart stacked to 100% that shows the evolution of shares of supply for browsers on mobile and desktop devices combined in the UK from 2012 until 2021. It shows that currently Safari and Chrome are the largest browsers, and Edge is the only other browser with a market share above 5%. It also shows that both Safari’s and Chrome’s share has remained relatively stable in the last few years.

Source: Statcounter, Browser share of supply UK 2012 to 2021

Note: Mobile refers to smartphones and tablets. The figure was calculated based on page views data from Statcounter. Android refers to AOSP-based browsers developed on top of the web browser apps made available through the Android Open Source Project. European Commission, Google Android decision, footnote 1034.

Browser and browser engines shares of supply by operating system

As set out above, each browser has an underlying browser engine. However, since the browser engine can differ by operating system, we have assessed shares of supply for browsers and browser engines by operating system. Since, as set out in Competition in the supply of mobile devices and operating systems, Apple and Google effectively have a duopoly in relation to mobile operating systems, we limit our assessment to iOS and Android.

For iOS, Table 5.2 below shows the following:

• Safari is the main mobile browser on iOS in the UK, with a share of supply of 92.6% in 2020. The only other sizable browser is Chrome, with 6.4%
• given that Apple imposes the restriction that browsers on iOS have to use Apple’s WebKit browser engine, WebKit on iOS has a share of supply of 100%

Table 5.2: 2020 UK mobile browser and browser engine percentage share of supply by operating system

iOS

Browser	Browser Engine	Mobile
Safari	WebKit	92.6
Chrome	WebKit	6.4
Firefox	WebKit	0.3
Other	WebKit	0.7

Android

Browser	Browser Engine	Mobile
Chrome	Blink	75.2
Samsung Internet	Blink	15.3
Firefox	Gecko	3.8
Smaller browsers	Blink	5
Other	Other/unknown	0.8

Source: App Annie browser usage data provided by a browser vendor.

Note: Calculated based on usage minutes data from App Annie. DuckDuckGo’s browser engine (OS’s WebView) is counted as Blink (1.6%); The browser Jetpack (0.3%) is counted as Other / unknown uses a WebKit fork.

For Android, Table 5.2 shows the following:

• Chrome is the main browser on Android in the UK. With a share of supply of 75.2% in 2020, its position is very strong, although less strong than Apple’s position on iOS. Samsung Internet is the largest competitor to Chrome on Android, with a share of 15.3%, while the next largest competitor, Firefox, has a share below 5%

• while browsers on Android are free to choose their browser engine, almost all browsers use Google’s Blink browser engine, resulting in Blink holding a share of at least 95%. The key exception is Firefox, which uses Mozilla’s Gecko browser engine

When considering browser engine shares across iOS and Android, WebKit has a share of supply of just over 50%, while Blink’s share of supply is just under 50%.^{[footnote 312]}

The nature of competition faced by Apple and Google

This section describes the competitive dynamics between the following:

• browsers for users: browsers primarily secure users through pre-installation and default settings on mobile devices. For users that actively choose their browser, browsers can seek to distinguish themselves on several dimensions of quality

• browser engines for browsers: absent restrictions, browser engines in principle would compete to be chosen by browsers by acquiring a high userbase, ensuring strong compatibility with online content, and implementing advanced features

• browser engines for online content providers: online content providers develop and host web pages. Browser engines seek to be prioritised by online content providers for compatibility, while online content providers typically test their content using the largest browsers (and hence the largest browser engines)

These 3 potential forms of competition are closely linked, as ultimately consumers use browsers to access the content produced by online content providers, and online content providers do so to attract users (and generate revenue, ultimately, through direct sales or advertising).

Competitive dynamics between browsers for users

Browsers seek to attract users both indirectly, in terms of pre-installation and default settings by device manufacturers, and directly, in terms of user installations.

Users tend to have a primary browser they use on their mobile device. While there is at least some multi-homing (that is, users using more than one browser on their mobile device), this appears to be more common on desktop browsers, where users may want to separate work and personal browsing.^{[footnote 313]}

Pre-installation and default settings

While some users make a deliberate choice for their browser, pre-installation and defaults are very important to the supply of browsers, as users tend to stick with the pre-installed and default browser (see below section on barriers to competition in browsers and Appendix G). Being the ‘default’ in this context means that the browser automatically opens and renders a web page upon a user clicking a link to a website (for example, in an email), without the user needing to select the browser manually.

Every mobile device comes with at least one browser pre-installed, although users can install additional browsers through the App Store (on iOS) or an app store or sideloading (on Android).

iOS devices

Since the launch of the iPhone in 2007, Safari has been the only browser pre-installed and set as the default browser on iOS devices. Apple submitted that the pre-installation and integration of Safari on its devices gives users the immediate internet access they expect to find when they power on their Apple device. Apple further submitted that a default browser is necessary for a seamless, uninterrupted experience across different apps and services.

Since September 2020, users can change the default browser in their device’s settings on iOS devices. To change the default, a user needs to first download the browser they wish to set as default as Apple has no other browsers pre-installed on iOS devices.

Android devices

Google has a range of agreements with other mobile device manufacturers to pre-install and set as default its apps including Chrome and Google Search, and as a result Chrome is pre-installed on most Android devices in the UK.^{[footnote 314][footnote 315]}

In 2018, the European Commission found in its Google Android investigation that Google had abused its dominant position in the worldwide market (excluding China) for Android app stores by tying Chrome with the Play Store and the Google Search App.^{[footnote 316]} The European Commission found that Google should be prohibited from: (i) licensing the Play Store to device manufacturers only on condition that they pre-install the Google Search app; and (ii) licensing the Play Store or Google Search app to device manufacturers only on the condition that they pre-install Chrome.

To implement the remedy that was imposed, Google now licences Chrome and Google Search separately (visit Appendix E for details). Device manufacturers that pay to licence the Google Mobile Services suite (which does not include Chrome) from Google can obtain Chrome at no additional cost and with no placement or default requirements.^{[footnote 317]} Device manufacturers can make further ‘Placement Agreements’ and ‘Revenue Share Agreements’ with Google, under which they promote Chrome or Google Search in return for payments. As a result of the Google Android decision, Google no longer sets Google Search as the default search engine in Chrome but provides users with a search engine choice screen (as discussed above).^{[footnote 318]}

Google’s agreement and fee structure provides device manufacturers with strong incentives to pre-install Chrome on their devices. Under Placement Agreements, Google pays device manufacturers which licence Chrome to pre-install the Chrome app and fulfil certain placement obligations on the user’s device. Under Revenue Share Agreements, Google pays device manufacturers a share of ad revenue generated from specific search and assistant access points, in return for certain placement and promotion of Chrome, and a requirement that Google Search is set as default in any pre-installed manufacturer browser.^{[footnote 319]}

Google provided aggregate figures for payments it made as part of its Placement and Revenue Share Agreements to the top 5 third-party Android manufacturers shipping devices into the UK, according to Statcounter.^{[footnote 320]} Google paid these manufacturers approximately $[1.5 to 2] billion in ad and Play transactions revenue from their devices under worldwide Revenue Share Agreements in 2020. Most of that figure was paid to Samsung, [REDACTED]. Google paid these manufacturers approximately $[1 to 1.5] billion in Search and Search/Chrome Activation Payments under Placement Agreements covering the UK, EEA and Turkey in 2020. Most of that figure was paid to Samsung, [REDACTED].

Other browsers are rarely pre-installed on Android devices. The main exception in the UK is Samsung, which pre-installs its own browser on its devices and sets it as default. It is noteworthy, however, that Samsung also pre-installs Chrome, though does not set it as the default browser.

User choice

As noted above, users tend to stick with the pre-installed and default browser, and only a minority of users make an active choice to use a particular browser.^{[footnote 321]}

However, Google submitted that, on Android, user choice is facilitated through a Play choice screen for browsers (which is a choice screen for downloading additional browsers) that is displayed at the first launch of the Play Store. We discuss choice screens in further detail in the section ‘barriers to competition in browsers’ and in Appendix G.

Parameters of competition for users

User installations of browsers depend on the quality of user experience; the importance users attach to the different dimensions of quality may vary by user. These dimensions include:

• security: browsers can protect consumers through features like integrated anti-spyware, anti-phishing, and antivirus^{[footnote 322]}

• speed: this dimension of competition, also known as ‘performance’, reflects the speed at which a browser responds to a user’s actions.^{[footnote 323]} Browser engines’ architecture is very important to browser speed. One important measure of browser speed is how fast a web page loads

• website compatibility: users want to use a browser which is compatible with most web pages (ie the browser can load the content without breaking any functionality), and therefore prefer a browser which uses a browser engine which is supported by online content providers^{[footnote 324]}

• privacy: browsers can share more or less data with advertisers, and can provide additional privacy protections for users, for example by including a built-in VPN^{[footnote 325]}

• features: for example, on desktop, Chrome’s key differentiating feature at launch was ‘draggable tabs’. Other possible browser features include password managers, ad-blocking and auto-complete^{[footnote 326]}

Browsers compete in terms of these dimensions of quality. Browsers may choose to focus on certain dimensions of quality, for example privacy, to differentiate themselves from other browsers and be able to more effectively compete for consumer segments that particularly value this parameter.

Alternatives to Safari on iOS

In addition to Safari, there are a number of other browsers that can be used on iOS, including Chrome, Firefox, Edge, Opera, DuckDuckGo and Brave.

Despite this, in 2020, only 7.4% of users of Apple mobile devices switched to other browsers, and almost all of this switching was to Chrome (which has a share of supply on iOS of 6.4%).^{[footnote 327]} Switching to Chrome may be driven by users’ desire to use a browser they are familiar with in other contexts, and to carry across information input in Chrome on other devices.^{[footnote 328]}

One limiting factor on the extent of switching is the lack of material differentiation between browsers that is possible on iOS devices, due to WebKit being the only browser engine permitted. In practice, this severely limits other browser vendors’ ability to distinguish themselves from Safari in many key parameters of competition, including speed, website compatibility and various aspects of feature support.

Alternatives to Chrome on Android

In addition to Chrome, there are a large number of alternative browsers available on Android, including Edge, Firefox, Samsung Internet, Opera, Vivaldi, Puffin, DuckDuckGo, Ecosia, PaleMoon, Brave and Yandex. However, Chrome’s share of supply on Android (75.2%) is far higher than any other browser’s; most of its competitors have an extremely small userbase.

Many of the competitors faced by Chrome have tried to differentiate themselves, in terms of the parameters of competition described above, with niche advantages:

• Microsoft markets Edge’s business-focused features^{[footnote 329]}

• Brave and DuckDuckGo focus on improved privacy^{[footnote 330]}

• Firefox’s mobile extensions library is frequently highlighted as a strength by reviewers^{[footnote 331]}

However, these browser vendors have low shares of supply, and almost all Android browsers use the Blink browser engine.^{[footnote 332]} While browser vendors can modify and distribute their own version of Blink, there is a high cost to maintaining modified browser engine features which have not been adopted by the browser engine’s steward (as discussed below). This reduces the scope for differentiation and competition between browsers on Android, as the competing Blink-based browsers perform similarly in many ways.

Competitive dynamics between browser engines for browsers

Since the browser engine is responsible for the key functionality that a browser offers, browser vendors’ choice of browser engines has a significant impact on outcomes in the market.

Parameters of competition for browsers

On operating systems which allow multiple browser engines, browsers choose a browser engine which will let them compete most effectively for users.

Browser engines determine website compatibility (as described in more detail in Appendix F), which is very important as ultimately the reason why people use browsers is to access content on the web. Browser engines are also crucial in determining many of the other parameters of competition in browsers, including speed, security, privacy and various browser features (as many features require enabling work in the browser engine in order to be implemented in the browser). Browser engines therefore play an important role in determining the scope for differentiation between browsers.

Alternatives to Apple’s WebKit and Google’s Blink browser engines

Competitive dynamics in browser engines differ between operating systems. On iOS, Apple requires browser vendors to use its WebKit browser engine – alternative browser engines are banned by Apple within its ecosystem. Browsers on iOS are also not able to modify WebKit (ie they are not able to ship a customised version of WebKit) but have to rely in the version installed by Apple. On Android (as well as on desktop operating systems such as macOS and Windows), browser vendors do in principle have greater choice over which browser engine to build their browser on.

However, in practice, over 95% of browser vendors on Android (including Chrome, Samsung Internet, Edge, Opera, Brave and Vivaldi) use (a version of) Blink. The key exception is Mozilla’s use of the Gecko browser engine (which it stewards) in Firefox.^{[footnote 333]} Browser vendors’ reasons for choosing Blink include its high web compatibility and Blink being seen as more technologically advanced than its competitors and benefiting from a rapid rate of upgrades.

Browser vendors that choose Blink can modify it and distribute their own version of Blink, instead of having to rely on the version of the engine already installed on Android.^{[footnote 334]} Being able to distribute their own version gives browser vendors some control over the browser engine, allowing them to add new features even if Google is not willing to incorporate them into Blink’s open source code base. However, there are important limitations to the extent to which browser engines are willing to make changes to the Blink browser engine, as changing too much from the original Blink version can lead to web compatibility issues (as also discussed in Appendix F) and make rebasing on top of newer Blink versions (in order to include updates to the open source code base) difficult.^{[footnote 335]}

This means that while the option to distribute a customised version of Blink increases the scope for differentiation between browsers engines and hence browsers, there are limits to the extent to which this differentiation is likely to take place in practice.

Competitive dynamics between browser engines for online content providers

Online content providers have an incentive to ensure web compatibility across browser engines (and browsers), as this allows them to reach more users. There are a series of open standards for the open web that should make it relatively straight forward for online content providers to achieve this.^{[footnote 336]}

However, browser engine developers can create and implement new and innovative features which are either not covered by, or enhance, an existing standard, and often a feature is first implemented in different browser engines to test and prove its value before becoming a standard. There is a tension between ensuring compatibility with existing standards and implementing cutting-edge features. Therefore, in practice, these standards are not always adhered to, making it more costly for online content providers to ensure web compatibility across browser engines. As a consequence, online content providers may not ensure web compatibility for all browser engines (and associated browsers). This means that browser engines seek to be prioritised by online content providers for web compatibility. We discuss the role of web compatibility for browser engine competition in further detail below.

Parameters of competition for online content providers

Browser engines compete for online content providers in terms of:

• their user base: online content providers are ultimately trying to produce content in a format which will be accessible to the maximum possible number of users. They will therefore typically target and test their web content using the largest browsers (and hence the largest browser engines) ^{[footnote 337]}

• specific features and functionality: where one browser engine provides superior features that are not included in other browser engines, some online content providers produce content which uses the features specific to that browser engine (although often while also providing a lower functionality version of their website which is compatible in other browsers). Also, and especially where the browser engine has a high user base, other browser engines can feel some pressure to implement the same features, even where this has not been agreed in standards bodies

Support for browser engines by online content providers

In terms of user base, Blink and WebKit are by far the largest browser engines, as indicated by their very high shares of supply. Firefox’s Gecko is the only other major browser engine, but its user base is very small (less than 5% of usage of Android devices).

All content providers we spoke to reported that they ensure compatibility with Chrome (and therefore Blink). Many specifically said that they ensure compatibility on both Chrome and Safari (ie Blink and WebKit) because these are the most popular browsers.

Given the large disparity in user bases, it is unlikely that Gecko (or any even smaller browser engine) is able to pose a significant competitive constraint on Apple and Google by offering specific features and functionality: in many cases, it may not be worth adopting these features and functionality for such a small user base, and in cases where they are adopted, online content providers would still provide a lower functionality version of their websites to be compatible with Blink and WebKit, given their large user bases. As a result, Apple and Google face very weak constraints from other browser engines in competing for online content providers.

With respect to competitive dynamics between Apple and Google on specific features and functionality offered to browser vendors using their browser engines, we note the following:

• Google has implemented a wide range of capabilities in Blink, from functionality to enable web apps to new device APIs (visit Appendix F for further detail). However, it appears that this is driven primarily by Google’s advertising business benefiting from the content on the web which this supports, and hence Google’s market power in display and search advertising – as opposed to competitive pressure from other browser engines

• Apple has been able to resist implementing many new features which Google has introduced in Blink (see discussion of WebKit’s quality in Appendix F and below).^{[footnote 338]} However, where Google introduces features which are particularly highly requested by online content providers, this can put pressure on Apple to do so too (although, as discussed below, in practice this is likely to be limited)

Alternatives to mobile browsers for accessing content

In principle, browsers on desktop devices (desktop browsers) can be an alternative for users to access content through browsers on mobile devices (mobile browsers), and native apps can be an alternative for online content providers to distribute content and users to access content through web pages and web apps on mobile browsers. These options can in theory increase the competitive constraints on mobile browsers and browser engines. However, as described below, in practice, these are not effective substitutes for mobile browsers.

Desktop browsers

Both Apple and Google submitted that desktop browsers pose a competitive constraint on mobile browsers. Google submitted that it requires less investment to offer a mobile browser when the developer already has a desktop browser and that most browser vendors offer both desktop and mobile versions. Apple submitted that it promotes Safari as a web browser, not a mobile or desktop browser specifically, because users can switch between a mobile device and a personal computer and access web content on both.

In its Google Android investigation, the European Commission found that desktop browsers do not belong to the same product market as mobile browsers.^{[footnote 339]}

We consider that, while desktop and mobile browsers provide similar functionality, there are important differences:

• from the perspective of users, they are significantly differentiated, as: (i) they are available on different devices and consumers may not own both; and (ii) they are used in different contexts – for example a desktop cannot be used ‘on-the-go’

• from the perspective of browser vendors, mobile and desktop browsers are less strongly differentiated: large browser vendors tend to supply both desktop and mobile versions of their browser, although there are exceptions and the presence of a given browsers may differ substantially between desktop and mobile^{[footnote 340]}

In practice the ability to switch to desktop browsers would not substantially increase users’ options, as Apple and Google have strong positions in desktop browsers. Similarly, there is little scope for new entry by desktop browsers on mobile devices, as all desktop browsers with a material market share are already present on mobile.

Native apps

Both Apple and Google submitted that the use of native apps which are accessed through proprietary app stores are an alternative to and pose a competitive constraint on the use of mobile browsers. Both parties submitted that, for a wide range of services, users have a choice of accessing content through either native apps or mobile browsers. Google further submitted that, in some cases, native apps provide a better experience due to their richer feature set compared to browser-based services.

In its Google Android investigation, the European Commission found that native apps do not belong to the same product market as mobile browsers.^{[footnote 341]}

We consider that native apps can generally display the same content as web pages and offer similar functionality, although we note that native apps tend to offer additional functionalities.^{[footnote 342]}

Despite similarity in functionality, there are also important differences between native apps and the use of web pages and web apps:

• online content providers told us that they tend to see native apps and web pages as complements: web pages have greater reach than native apps and are the primary channel for reaching new audiences and growing the user base, while native apps retain existing users and increase their engagement. Several content providers submitted that online advertising revenue is more limited on native apps compared to web pages

• native apps are more expensive to develop than web pages, as they typically have to be reproduced for each operating system

Overall, native apps do not appear currently to be a viable alternative for users who wish to access web pages (or web apps) on their mobile devices.^{[footnote 343]} We consider that it is unlikely that the presence of native apps materially constrains Apple and Google in their supply of mobile browsers and browser engines – and in practice, the fact that Apple and Google control both gateways to users means that they can implement policies which push users to the use of one channel rather than the other.

Barriers to effective competition for browsers and browser engines

In this section, we discuss barriers to competition that may prevent the alternative browsers discussed above from acting as an effective constraint on Apple and Google in the supply of mobile browsers and browser engines.

For the sake of clarity, we distinguish between barriers to competition in browser engines and barriers to competition in browsers, while in practice these points are strongly interrelated.

Barriers to competition in browser engines

As discussed above, competition in browser engines has a material impact on outcomes for browsers. Below, we therefore discuss barriers to competition in browser engines and their impact on competition in browsers.

The key barriers we have identified are the browser engine restriction on iOS and web compatibility. We discuss each of these in turn.

Browser engine restriction on iOS

Since the introduction of third-party apps on the iPhone in 2008, Apple has required all browsers on iOS to use WebKit as their browser engine and browser vendors are further not able to make any adjustments to WebKit but have to rely on the engine already installed by iOS.

Below, we assess both Apple’s stated rationale for only allowing WebKit as the sole browser engine on iOS (the ‘WebKit restriction’) and the impact of the restriction. We further discuss the potential strategic reasons behind Apple’s restriction.

Apple’s stated rationale

Apple told us that only allowing WebKit on iOS is motivated primarily by security and privacy considerations (visit Appendix F for further detail).^{[footnote 344]}

In particular, many modern websites run code from unknown developers. Apple told us that because of the WebKit restriction, it is able to address security issues across all browsers on the iPhone, for all iPhone users, quickly and effectively (given there is only one browser engine). It further told us that, in Apple’s opinion, WebKit offers a better level of security protection than Blink and Gecko.

In order to assess the validity of Apple’s stated rationale, we have considered 2 questions:

• whether having one browser engine allows for a quicker and more effective response to security issues
• whether WebKit performs better than other browser engines in terms of security

We discuss each of these in turn. For completeness, we further note that, shortly before publication of this report, Apple submitted that WebKit is tightly integrated with device hardware and the iOS operating system to deliver substantial security protections, and that third-party browser engines lack important features that Apple harnesses via tight integration between WebKit and iOS device hardware and software.^{[footnote 345]} We will assess this point in the second half of our market study.

Responding to security issues

With respect to responding to security issues, in discussion with Apple, the primary concern that Apple raised with us was about the very large number of apps that use a browser engine to render web pages. In particular, Apple told us that if these apps were allowed to use a non-WebKit browser engine, Apple would have to require each of those developers to update their own app, and that this would cause some vulnerabilities to persist for months, if not years. Apple also said that, if the WebKit restriction was lifted, all apps that use in-app browsing would have their own rendering version of the browser engine. Apple submitted that allowing different browsers to use different browser-rendering engines would make a rapid, efficient response to a privacy or security vulnerability in one browser impossible.

While we continue to assess the evidence that relates to in-app browsing within non-browser apps on this point, the problems described by Apple appear to be less relevant for dedicated browser apps. In particular:

• the number of browsers, especially those with material usage and downloads, is relatively limited, so there would not be a very large number of apps that need to update their browser engine

• on Android, where there is browser engine choice, there are only 2 main browser engines that are used (Blink and Gecko). This suggests that it is unlikely that the number of browser engines used by browsers would increase if browser engine choice was also introduced on iOS. Also, Apple could in principle retain some degree of control over which browser engines are enabled based on, for example, objective security grounds or speed of updates

• lifting the WebKit restriction only for browsers would still mean that Apple could no longer update across all engines in case of a security threat, which, according to Apple, would result in security updates being deployed slower. However, several technical experts told us that browser updates for Blink and Gecko deliver security updates faster to users than WebKit ^{[footnote 346]} – although we still need to assess this further

Apple told us that it would be challenging to find a precise definition for browser apps which excluded other apps. We do not consider the difficulties in determining whether an app is a browser or a non-browser app to be a significant hurdle, although we are still assessing to what extent differentiating the approach between dedicated browser apps and non-browser apps could incentivise third parties to create novel browser apps to circumvent the rule, which is a further argument submitted by Apple.

Overall, the evidence we have received to date does not suggest that Apple’s WebKit restriction allows for quicker and more effective response to security threats for dedicated browser apps on iOS. We will continue to gather evidence and views on the extent to which there are security benefits from only allowing the WebKit browser engine for in-app browsing within non-browser apps.

Security of different browser engines

With respect to the security of different browser engines, there are different opinions between which browser engine offers the highest level of security.

Apple submitted that WebKit offers the best security level. However, to date, Apple has not provided any objective evidence that supports this position, or that allowing alternative browser engines on iOS would lead to a material increase in security incidents. While Apple submitted studies that compare malware infections between iOS and Android devices, we note that these are not browser-specific and Apple has not evidenced that the malware infections are directly linked to browser engines. We have also not heard from any third parties that support Apple’s view.

Several stakeholders that we have spoken to have challenged the idea that WebKit offers better security than other browser engines. One group of technical experts stated that WebKit security fixes do not always get applied to all versions of iOS, leaving users on older but still recent versions exposed. One tech commentator submitted that they suspect that Safari is worse on security than most other browsers.

We intend to identify and assess further metrics and evidence on browser engine security in the second half of our study, but to date, we have not been presented with any compelling evidence that suggests WebKit is the superior browser engine on security grounds.

In addition, there have been some suggestions that the impact of browser engine security on overall device security, can, to a certain extent, be limited. In particular:

• Microsoft submitted that, because of the way that browsers are constructed (namely that they run in a ‘sandbox’), it is possible to ensure high security without having to impose a browser engine restriction

• a group of technical experts submitted that generally browsers are considered very secure compared to most other types of applications. They further told us that additional policies could be put in place. For example, if it can be shown that a browser vendor is not providing reasonable efforts to keep their browser secure, Apple could be allowed to either remove privileges from that browser or remove the browser from their platform

Finally, we also note that Apple does not require a similar browser engine restriction on macOS.^{[footnote 347]}

Overall, the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines.

Impact of the WebKit restriction

As a result of the WebKit restriction, there is no competition in browser engines on iOS and Apple effectively dictates the features that browsers on iOS can offer (to the extent that they are governed by the browser engine as opposed to by the UI). For example, browsers are less able to accelerate the speed of page loading, and cannot display videos in formats not supported by WebKit.^{[footnote 348]} While Apple submitted that WebKit permits for substantial differentiation between browsers and allows developers to build features and interfaces on top of WebKit, several browser vendors submitted that, due to the key role of browser engines, they are limited in differentiating their browser from other browsers on iOS. For example, one browser vendor submitted that it is not possible to offer as attractive or differentiated features to users on iOS, while another submitted that it is not able to substantially differentiate its browser from other browsers on iOS.

The WebKit restriction also means that browser vendors that use Blink or Gecko on other operating systems have to build their browser on 2 different browser engines. Several browser vendors submitted that needing to code their browser for both WebKit and the browser engine they use on Android results in higher costs and features being deployed more slowly.^{[footnote 349]}

Two browser vendors submitted that they do not offer a mobile browser for iOS due to the lack of differentiation and the extra costs, while Mozilla told us that the WebKit restriction delayed its entrance into iOS by around 7 years.

In addition to these direct impacts on competition, we received a large number of submissions that WebKit lags behind other browser engines in terms of feature support and performance in general as well as its support for web apps specifically. We discuss these below and provide additional technical detail in Appendix F.

WebKit feature support and performance

A large number of stakeholders made submissions that WebKit lags behind other browser engines in terms of feature support and performance. This includes submissions from several browser vendors, several technical experts and a tech commentator, and various app developers. For example:

• [One party] submitted that, due to the WebKit restriction, Chrome on iOS offers less attractive or differentiated features and that WebKit lags behind other browser engines in terms of compatibility. [This party] further told us that user feedback on crashes on iOS are ‘an order of magnitude higher’ than on Android

• Microsoft submitted that it believes that Blink provides better standards support and performance than WebKit, and that this means that Edge on iOS is slower than Edge on Android and new and evolving web standards are less likely to be supported

• Mozilla told us that its browser on iOS is more limited than its browser on Android, due to a large number of APIs not being available on WebKit

Additionally, we engaged with various stakeholders on test suites that compare WebKit to other browser engines. On the basis of the submissions received, we consider that while a variety of measures are likely to be relevant, compatibility and feature support appear to be particularly important. We have therefore focused on these measures.

A test suite measuring compatibility and feature support that was endorsed by Google as well as by several technical experts is the Web Platform Test (WPT) Dashboard, also referred to as wpt.fyi.^{[footnote 350][footnote 351]} This project provides various assessments of compatibility and feature support of different browsers.

Figure 5.4 below shows one of these assessments, namely the number of tests that fail in exactly one browser. The yellow Safari line (which represents any browsers built on WebKit) is a measure of how often other browsers are compatible, but Safari’s implementation is wrong. Conversely, the much lower Chrome and Firefox lines (representing browsers built on Blink and Gecko respectively) show that these browsers are considerably more likely to agree and be correct regarding core web standards.

Figure 5.4: number of tests which fail in exactly one browser (wpt.fyi)

Figure description: A time series line chart that shows the number of tests which fail in exactly one browser built on either WebKit, Blink or Gecko. It shows that browsers built on WebKit are considerably less likely to be correct regarding core web standards. It also shows that browsers built on Blink are the most likely to be correct regarding core web standards. It illustrates that browsers built on Gecko perform slightly worse than the ones built on Blink in this regard over time.

Source: web-platform-tests dashboard.

While we acknowledge that there are certain limitations to this assessment, we consider that, overall, it provides a meaningful comparison of the feature support of WebKit compared to other browser engines. Additionally, we note that a number of other test suites show similar patterns with respect to WebKit’s feature support,^{[footnote 352]} although there is also one assessment (focusing on the most painful compatibility bugs) which shows that while Safari was lagging behind browsers built on Blink or Gecko for most of 2021, it has recently improved significantly, following from Apple releasing Safari 15 as part of its iOS 15 release.^{[footnote 353]}

In addition to quantifications of feature support, several stakeholders (including [several browser vendors] and several technical experts and tech commentators) pointed to and provided extensive lists of features and APIs that Apple has not implemented or has only implemented on WebKit significantly after other browser engines (ie Blink and Gecko) did so.^{[footnote 354]}

Given the large number of features (as also indicated by the quantification of feature support discussed above), we still need to understand in more detail the extent to which Apple is not supporting them and Apple’s reasoning for it. Based on the evidence received to date, we consider that there appear to be 2 broad types of features in this context.

First, there appear to be various features that Apple does not support or has only supported significantly after other browser engines that are relatively uncontroversial and have no security, privacy or security concerns.

Apple submitted that, to the extent that certain features are not available at a given time, that may be due to differences in product development priorities, time and resource constraints, Apple’s concerns about security, privacy or performance issues with those features, technical barriers with making features widely available without compromising security, performance, or privacy, or lack of evidenced third-party demand for such features. Apple further noted for specific features that it is actively working on supporting them.^{[footnote 355]}

Second, there appear to be some features with respect to which there is some legitimate debate over privacy and security concerns. These include in particular access to hardware devices but also functionality such as the extent of support for push notifications and background synchronisation, both of which are APIs that extend service workers (scripts that browsers may use to respond to events related to a site, even if that site is not currently open in a foreground tab).

Apple has commented explicitly on some of these. For example, with respect to device APIs, Apple submitted that enabling access to these features presents well-known and substantial risks to privacy and security. Apple further submitted that it has publicly explained its reasoning for not implementing these features and that Mozilla has publicly registered similar concerns.

Importantly, due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS. This not only restricts competition (as it materially limits the potential for rival browsers to differentiate themselves from Safari on factors such as speed and functionality) but also limits the capability of all browsers on iOS devices, depriving iOS users of useful innovations they might otherwise benefit from.

Support for web apps

A key area in terms of limited feature support provided by WebKit appears to be web apps, and more specifically progressive web apps (PWAs). PWAs are a type of web app that create an experience that is more comparable to a native app than more conventional web apps would offer.^{[footnote 356]}

A large number of stakeholders submitted that WebKit provides more limited support for web apps by Apple either delaying the introduction of technical changes to WebKit that facilitate improved web app technologies or choosing not to implement them at all.^{[footnote 357][footnote 358]} There were further specific submissions on key features that WebKit does not fully support that relate directly to web apps. We list some of the key examples we were provided with below^{[footnote 359]} :

• no push notifications – WebKit does not support push notifications to a user’s home or lock screen (although we understand that Apple may be in the process of implementing this now)

• no full screen – the browser’s UI remains visible in web apps^{[footnote 360][footnote 361]}

• lack of lock-screen rotation^{[footnote 362]}

• limited support for persistent storage – as a default, cache and sign-in data only stored for 7 days on a web app

• no access to Web-Bluetooth^{[footnote 363]} – meaning that web apps are incapable of connecting to devices such as printers and scanners, payment technology, or home automation and lighting and other ‘Internet of Things’ devices

• no access through voice assistants – web apps cannot be accessed by using a voice assistant (for example, Siri)

• Worse integration with parental controls – for example, ScreenTime; some features unavailable to web apps (tracking activity, limiting usage or content restrictions)

• iOS mutes web apps by default – iOS mutes all web apps by default, and touch input from users is required for audio to work

• no access to mouse movement data for web apps.

• lack of access to hardware rendering – web apps have to rely on software-based, single-thread rendering, which means less efficient processing and results in greater battery drain

In addition to these submissions, one technical expert referred us to a website (developed by a Chrome Developer Advocate at Google) which checks whether a given browser supports 18 features that, according to the technical expert, ‘make web apps more powerful and keep users safer’.^{[footnote 364]}

Figure 5.5 below shows that Safari (based on WebKit) only supports 5 of these features, while Chrome on Android (based on Blink) support all. However, Firefox on Android (based on Gecko) also does not support many of the features that are not supported by Safari – although ‘Push Notifications’ ‘Storage Estimation’, ‘Persistent Storage’ and ‘Media Session’ are supported by Firefox but not by Safari. While we note that the list of selected features was developed by a Chrome Developer Advocate at Google and is therefore likely impacted by Google’s view on what features are important, we still see it as relevant evidence complementing the submissions on feature support discussed above.

Figure 5.5: Progressive Web App Feature Detector: (left to right) Safari on iOS and Chrome and Firefox on Android

Figure description: An illustration that shows how many of the above discussed 18 features Safari on iOS, Chrome and Firefox on Android support. Safari supports 5 of these features, Chrome on Android supports all, while Firefox on Android supports 7.

Source: Progressive Web App Feature Detector.Screenshots taken on iPhone XR running iOS15.1 and Samsung Galaxy S20 running Android 11 in November 2021.

While we still need to understand in more detail Apple’s reasoning for not supporting various features related web apps, the WebKit restriction appears to significantly limit the functionality of web apps, in particular PWAs, on iOS compared to native apps.

While we understand that it is, in principle, possible to have web apps on browsers that are based on WebKit, the limited support for web apps has important implications for app developers on iOS.

• some app developers are likely to still offer web apps (for example, because they particularly value offering a consistent cross-platform experience or because the web app features that are not supported on iOS are less essential to them). However, the functionality these app developers can practically offer will be more limited. We have heard concerns that this is not only the case on iOS, but also on Android (given that, as discussed in Competition in the distribution of native apps, web apps are used across operating systems) ^{[footnote 365]}

• other app developers may not be able to offer the functionality they want to offer through a web app, and this may lead them to choosing to develop a native app for iOS. This is likely to significantly increase development costs, as the efficiency saving from having to only develop one app (ie one web app as opposed to a native app for each operating system) is lost. Higher development costs may feed through to higher costs for users and certain apps not being developed (either not at all or not for both iOS and Android) ^{[footnote 366]}

Both of these implications suggest that the WebKit restriction is likely to impede the more widespread adoption of web apps, on iOS specifically but also on Android.

Potential strategic reasons for Apple’s WebKit restriction

There appear to be 2 main ways in which Apple can benefit, directly or indirectly, from the WebKit restriction.

First, Apple receives significant revenue from Google by setting Google Search as the default search engine on Safari, and therefore benefits financially from high usage of Safari. Safari has a strong advantage on iOS over other browsers because it is pre-installed and set as the default browser. The WebKit restriction may help to entrench this position by limiting the scope for other browsers on iOS to differentiate themselves from Safari (for example being less able to accelerate the speed of page loading and not being able to display videos in formats not supported by WebKit). As a result, it is less likely that users will choose other browsers over Safari, which in turn secures Apple’s revenues from Google.

Second, and as discussed in Competition in the distribution of native apps, Apple generates revenue through its App Store, both by charging developers for access to the App Store and by taking a commission for payments made via Apple IAP. Apple therefore benefits from higher usage of native apps on iOS. By requiring all browsers on iOS to use the WebKit browser engine, Apple is able to exert control over the maximum functionality of all browsers on iOS and, as a consequence, hold up the development and use of web apps. This limits the competitive constraint that web apps pose on native apps, which in turn protects and benefits Apple’s App Store revenues.

Conclusion

Overall, while we acknowledge that browsers constitute a certain vulnerability in terms of security for devices, we have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition and users from Apple’s WebKit restriction is justified on security grounds. In particular, we do not consider, based on the available evidence, that:

• Apple’s arguments on responding swiftly to security issues necessarily justify Apple’s WebKit restriction for dedicated browser apps on iOS^{[footnote 367]}

• differences in the security performance of alternative browser engines necessarily provide such a justification either: the security performance of WebKit is unlikely to be significantly better than that of the other 2 main browser engines, Blink and Gecko, and we note that there are certain safeguards such as sandboxes

We further consider that the limitation on the feature support that browsers on iOS can offer is likely to be significant. This appears to be particularly the case with respect to supporting web apps. While Apple should be free to decide where to focus its development efforts and which features to implement on Safari, the evidence indicates that forcing browsers to use its browser engine significantly limits the capability of all browsers on iOS devices and means that Safari faces less competition from other browsers than it would otherwise do.

In addition to potentially harming the functionality of competing browsers within Apple’s ecosystem, we consider that the WebKit restriction may also serve to support Apple’s highly profitable position in the distribution of native apps through its App Store, and in parallel the market power of its operating system. As discussed in Competition in the distribution of native apps, web apps could in principle also serve to undermine the indirect network effects of native app distribution, and as a result improve the chances of new operating systems entering the market successfully.

Web compatibility

As noted above, web compatibility refers to the browser’s ability to properly access and display the content on a particular web page, and primarily depends on the browser engine (ie although there may also be some differences between them, browsers with the same browser engine generally tend to perform similarly on web compatibility).

There are a series of open standards that should, in principle, address any concerns about web compatibility. However, in practice, compatibility issues remain. This appears to be due to: (i) certain browsers releasing features without going through formal standards development organisations and processes; and (ii) web developers not developing against standards but for a specific browser or set of browsers.^{[footnote 368]}

Web compatibility appears to be influenced by indirect network effects: the more users a browser engine has, the more likely online content providers will develop their website in a way that ensures compatibility with the browser engine and thus the more likely are users to use a browser that is based on this browser engine.^{[footnote 369]}

These network effects mean that it is more difficult for smaller browser engines to compete effectively and for new browser engines to enter. They also mean that browser vendors are less willing to substantially adjust their customised version of an open source browser engine or fork from it.

This is consistent with the submissions we have received from browser vendors:

• as noted above, browser vendors’ reasons for choosing Blink include its high web compatibility. By the same token, browser vendors commented on compatibility issues of smaller browser engines^{[footnote 370]}

• Microsoft’s considerations when switching its browser engine from EdgeHTML to Blink also indicate that smaller browser engines perform less well on compatibility (visit Box 5.2 below) [REDACTED]

• web compatibility has been cited as the key reason for discontinuation for Microsoft’s Trident and EdgeHTML browser engine as well as Opera’s Presto browser engine^{[footnote 371]}

Box 5.2 Microsoft’s browser engine switch

Microsoft previously offered its own proprietary browser engines (Trident and Edge HTML) with its browsers Internet Explorer and Edge. However, in 2018, Microsoft announced the transition to Blink and shipped the updated version of Edge in 2020.

Microsoft provided us with the following reasons for this switch:

• the decision was made to improve website compatibility
• in particular, Microsoft felt that it could not convince a sufficient percentage of developers to support the EdgeHTML version of Edge and test their sites against it, and this resulted in broken web experiences and users leaving Edge for Chrome

Microsoft considered other engines but concluded that Blink likely offered the best website compatibility at the time.

Microsoft considered other engines but concluded that Blink likely offered the best website compatibility at the time.

• [REDACTED]

Overall, this suggests that web compatibility is a key barrier to competition in browser engines in the following respects: (i) it limits the competitive constraint smaller browser engines pose on Blink and risks their viability; (ii) it limits the extent to which browser vendors using Blink are willing to make custom modifications to Blink; and (iii) it constitutes a barrier to entry (independent of whether such entry is achieved through forking or entry from scratch).

Barriers to competition in browsers

There are a relatively large number of alternative browsers alongside Safari and Chrome (visit Table 5.1 for a selection of browser vendors). However, these alternative browsers only account for a small share of supply of mobile browsers, with Samsung Internet being the only browser next to Safari and Chrome with a share of supply of mobile browsers above 5%.

In the previous section, we discussed barriers to competition in browser engines and how they limit competition in browsers. In this section, we assess additional reasons why the competitive constraints on Apple and Google’s browsers may be limited. In particular, we set out that there are material barriers to competition in browsers resulting from the following:

• Apple and Google influencing user behaviour through choice architecture,^{[footnote 372]} including in particular pre-installation and default settings

• native apps using in-app browsers which disrespect users’ default browser choice

• Apple, and Google in some instances, restricting competing browsers’ access to APIs and interoperability, which, in the case of Apple, reduces the other browsers’ ability to compete effectively and, in the case of Google, could to some extent limit other browsers’ competitiveness

Pre-installation and default settings

Most browser vendors highlighted user acquisition, and in particular the role of pre-installation and default settings, as a key barrier to expansion for browsers.

We assess pre-installation and default settings for browsers in detail in Appendix G. Below, we summarise the key aspects with respect to the current agreements, the impact of pre-installation and default settings on consumer behaviour, as well as the routes to users switching their browser.

Current agreements

On iOS devices, Safari is the only browser pre-installed and is set as the default browser. We have not received any evidence that competition takes place between browser vendors to be pre-installed or set as the default on iOS devices. Instead, and as a consequence of Apple being both the device manufacturer and a browser vendor, iOS devices are a closed system in this regard.

With respect to Android devices, Chrome is pre-installed on most Android devices. It is further set as the default browser on most Android devices other than Samsung mobile devices. In principle, this outcome could result from an effective competitive process for pre-installations and default settings: there is scope for competition for pre-installation and default settings on Android devices, given that Google is typically not the device manufacturer and given that – following the European Commission’s Google Android decision – Google can no longer tie licencing GMS (which includes the Play Store) to the device manufacturer also installing Chrome.^{[footnote 374]}

However, we are concerned that Google may be using its strong position in browsers or adjacent markets to ensure that Chrome is pre-installed on Android devices, thereby further entrenching its position in browsers. In particular, Google’s agreement and fee structure provides device manufacturers with strong incentives to pre-install Chrome on their devices: as discussed above, (i) under Placement Agreements, Google pays device manufacturers which licence Chrome to pre-install the Chrome app and fulfil certain placement obligations on the user’s device and (ii) under Revenue Share Agreements, Google pays device manufacturers a share of ad revenue generated from specific search and assistant access points, in return for certain placement and promotion of Chrome (as well as other requirements). We consider that it is difficult for other browser vendors to replicate these payments, in particular due to Google’s market power in search advertising.

We received several submissions from browser vendors on perceived difficulties of getting pre-installed on Android mobile devices because of Google. For example:

• Microsoft submitted that it has not achieved any significant deals for Edge to be pre-installed on mobile devices because ‘those channels of distribution are completely controlled by Google’

• [One browser vendor] submitted that while it actively tried to get [its browser] pre-installed on Android mobile devices, it was unsuccessful and has now deprioritised these efforts. [The browser vendor] further submitted that, albeit not knowing the details of the relationships between device manufacturers, mobile network operators and Google, challenges that it faced in getting its browser pre-installed seemed to relate to conditions placed on device manufacturers and mobile network operators by Google^{[footnote 375]}

We also considered the option for other browser vendors to be pre-installed alongside Chrome on Android devices. However, we find that this is likely to be unattractive:

• first, it would not be possible for browsers with search engines other than Google Search (for example, Edge, which has Bing as its search engine default) to be installed in a prominent place as Google’s Revenue Share Agreements with device manufacturers stipulate that Google Search is set as the default on all pre-installed browsers (other than Chrome) that are placed on the default home screen (unless in a folder) or the ‘minus one’ screen.

• second, paying to be pre-installed next to Chrome may be costly, in particular relative to potentially limited gain for the browser vendor. In this regard, Brave submitted that being pre-installed in addition to the default browser is expensive. We also understand that Chrome may be more prominently placed than other browsers. In particular, some device manufacturers that enter into a Revenue Share Agreement with Google choose, on a device-by-device basis, to earn an enhanced revenue share by meeting certain additional requirements, some of which relate to the placement of Chrome.^{[footnote 376]} Additionally, Brave submitted that non-default pre-installed browsers are often contractually precluded from appearing on the first screen and are relegated to more obscure screens that require several swipes for the user to access and are rarely opened by the user.

Impact of pre-installation and default settings on user behaviour

The evidence we have reviewed indicates that pre-installation and default settings have a significant impact on consumer behaviour, ^{[footnote 377]} although there is also some evidence that suggests that informed users sometimes do change default mobile browsers when given the opportunity.

First, and as can be seen from Figure 5.6, there is a strong correlation between the browsers that are pre-installed or set as defaults on mobile devices and their usage (as measured by their share of supply). In particular:

• Safari is the pre-installed default browser on all iOS mobile devices and its share of supply in iOS mobile browsers amounts to 93%

• Chrome is pre-installed on most (and set as default on around 44% of) Android mobile devices and has a share of supply in Android mobile browsers of 75% ^{[footnote 378]}

• Samsung Internet is pre-installed (alongside Chrome) and set as default on 56% of Android mobile devices and has a share of supply in Android mobile browsers of 15%^{[footnote 379]}

Figure 5.6: Pre-installation and share of supply of browsers on mobile devices in the UK, 2020

Figure description: A bar chart stacked to 100% that shows the pre-installation and share of supply of browsers on iOS and Android mobile devices in the UK in 2020. It shows that Safari is the pre-installed browser on all iOS mobile devices and its share of supply in iOS mobile browsers amounts to 93%. Chrome is pre-installed on most Android mobile devices and has a share of supply in Android mobile browsers of 75%. The Samsung Internet browser is pre-installed (alongside Chrome) on 56% of Android mobile devices and has a share of supply in Android mobile browsers of 15%. It also shows that Firefox and other browsers has limited share of supply.

Source: CMA analysis using App Annie data, provided by a browser vendorand Mobile operating system share of supply UK 2020, Mobile vendor share of supply United Kingdom UK 2020.

Note: Mobile devices refers to both smartphones and tablets. For this analysis, given that Chrome is pre-installed on most Android devices, we assumed, for simplicity, that it is pre-installed on all Android mobile devices. Samsung Internet is currently pre-installed on all Samsung mobile devices. Share of pre-installed Samsung Internet is calculated based on Samsung’s share as a mobile device vendor. Samsung pre-installs both Samsung Internet and Chrome and sets Samsung Internet as the default. Shares of supply are based on page views.

An even starker pattern can be observed when comparing Samsung Internet browser usage on Samsung devices (where it is the pre-installed browser alongside Chrome and set as the default) vs. non-Samsung devices (where it is not), as [most of] the usage of its browser is from devices where it is the pre-installed default browser.^{[footnote 380]} Similarly, Edge’s position on desktop (where it is pre-installed) is stronger than its position on mobile (where it is not).^{[footnote 381]}

Second, data received from Apple suggests that, since 2015, [20 to 30%] of users in the UK installed additional browsers or search-enabled apps on their iPhone and iPad devices, although Apple submitted that it anticipates this number to likely be even higher, as the percentage is based on downloads from only twenty popular browser and search apps available on the UK App Store.

Third, we have considered user research on browser usage in the context of pre-installation and default settings, including a consumer survey commissioned by the Australian Competition and Consumer Commission (ACCC) ^{[footnote 382]} and 2 user surveys conducted by [a browser vendor] on iOS users.^{[footnote 383]} These indicate that there is a strong tendency among consumers to adhere to pre-installed and default browsers. There appears to be a number of reasons why users do not switch to a different browser: while the survey evidence indicates that users have a preference for maintaining the status quo with respect to browser choice (ie despite being able to switch, they have a status quo bias^{[footnote 384]} towards the browser that is pre-installed or set as default), it also shows that some users do not know how to change their default browser. Additionally, however, the survey evidence also indicates that users stick with the pre-installed and default browsers because it is their preferred browser.

Ease of switching

The ease of switching appears to play an important role in how significant the impact of pre-installation and default settings is for users’ choice of browsers.^{[footnote 385]} In this regard, some browser vendors highlighted that users may not know how to change the default or that changing the browser is an involved process that requires a number of steps.

We discuss the ease of switching in detail in Appendix G. This includes an assessment of the key choice architecture elements that users encounter in their routes to switching and their impact on user behaviour.^{[footnote 386]}

Below, we summarise the key issues with respect to the ease of switching, covering the different ways that users can install additional browsers and change their default browser in turn.

User journey for changing the default browser

The user journey for changing the default browser on both iOS and Android devices involves a number of potentially complex steps. On both operating systems, the user journey involves downloading an additional browser from the respective app store, finding the relevant option on device settings and navigating to choose the preferred browser.

On iPhones, this results in changing default browser settings taking around 6 steps, while on Android, around 7 steps are required (depending on device type and manufacturer).

This is likely to strengthen the importance of pre-set defaults, as a more difficult or tedious process for switching makes users less able to and less likely to switch away.

Play choice screen for browsers (Android only)

Google submitted that, in April 2019, it implemented a choice screen which is displayed the first time a user opens the Google Play store on EMADA devices that preload the Google Search app or Chrome.^{[footnote 387]} This choice screen gives users the option to install additional browser apps, although it does not set or change the default.^{[footnote 388]}

Data provided by Google suggests that [a relatively large proportion] of newly activated Android devices in the UK show the Play choice screen for browsers. However, despite the Play choice screen being shown to a large proportion of newly activated Android mobile devices, according to data from Google, in [a very low proportion] of cases in which the Play choice screen for browsers is shown, the user downloads an additional browser.^{[footnote 389]} We therefore have concerns about the effectiveness of the choice screen.

Relatedly, we have 3 primary choice architecture concerns that are likely to limit the effectiveness of the Play choice screen for browsers: ^{[footnote 390]}

• first, the choice screen does not allow users to change the default browser setting at the time they decide whether to download an additional browser

• second, the choice screen only allows for the installation of additional browsers and any pre-installed browsers are shown in the screen above the options for downloading a new browser. In other words, when the user engages with the choice screen, a browser is already installed (which is not removed by installing an additional browser), which makes users less likely to engage in installing a different browser

• third, the choice screen is shown once when the user first opens the Play Store. Users may be less open to exploring alternative browsers when they are in the process of setting up their phone, rendering the choice screen less effective

Overall, we consider that the Play choice screen for browser can make it easier for users to install additional browsers on Android devices, thereby reducing the importance of initial pre-installation and making switching easier (although the choice screen does not let the user change the default browser). However, we have some concerns about the effectiveness of the current version of the Android choice screen and continue to assess the extent to which such choice screens for browsers could be made more effective.

Browser disambiguation box (Android only)

In addition to the Play choice screen for browsers, users of Android 11 and earlier versions can be prompted to change their default browser through a so-called ‘disambiguation box’. In particular, on Android devices running Android 11 or earlier versions, installing a new browser removes the default browser setting. The next time a user clicks on a link after having installed a new browser, the user gets shown the disambiguation box, which asks the user which browser they want to use to open links.^{[footnote 391]} Users can then make a one-off choice or change their default browser.

However, on Android 12 (which was released in October 2021), installing a new browser does not remove the default browser setting. This means that when a user clicks on a link after installing a new browser, the user does not get shown the disambiguation box for browsers. Given the discontinuation of this disambiguation box on Android 12, we do not consider disambiguation boxes to substantively reduce the importance of initial pre-installation and default settings.^{[footnote 392]}

Prompts displayed by browser operators and websites

On both iOS and Android, browser vendors as well as websites can display prompts asking the user if they want to switch their default browser. Examples of browser vendors that use or have at some point used such prompts include Google, Mozilla, Microsoft, Samsung and Brave.

The prompts can differ in terms of when they are displayed (for example, we understand prompts are shown when the respective browser is in use, but some browsers appear to also be able to send notifications when not in use) and the information they display (they may include information on how to change the default browser, on the benefits from switching the default browser, and display shortcuts for changing the default).

Prompts can be beneficial in terms of making it easier for users to switch their default browser and raising awareness about the process of switching. However, there are limitations to how effective they can be as well as certain concerns.^{[footnote 393]}

• browser vendors are only able to show prompts to a limited population of users (namely those that already have the respective browser installed on their device). Browser vendors may further not have visibility over whether their browser is set as the default, which restricts their ability to target users for which the browser is not set as the default. They also may not have access to the relevant API that allows them to launch shortcuts to changing the default browser settings

• there may be some concerns around the choice architecture of the prompts. For instance, encountering these prompts repeatedly could enhance the burden on consumers and reduce their engagement with the prompt, rendering them less effective

• to the extent that prompts are displayed by websites, these may primarily benefit Google (given that Google has a much wider web presence than other browser vendors, most notably through its position in Google Search)

Overall, we consider that while prompts can facilitate switching between browsers and thereby play some part in reducing the importance of initial browser default settings, their effectiveness is likely to be limited. Also, we consider that notifications displayed by Google web properties that prompt users to switch to Chrome may be problematic, insofar as they are likely to reinforce Google’s position in browsers even further.

Native apps using in-app browsers

As set out above, certain native apps have in-app browsers, meaning that, when clicking on a link to the website, the user remains in the native app and views the web content on a so-called in-app browser. We have only received limited data on the scale of in-app browser traffic, but various submissions suggest that in-app browser traffic is likely to be very significant.^{[footnote 394]}

There may be certain benefits that in-app browsers can offer to users, for example in terms of quicker loading and a more seamless experience, and we will seek to understand these better in the second half of the study. However, native apps using in-app browsers can also lead to barriers to competition in browsers and thereby harm consumers. We have identified the following 2 mechanisms for this:

• first, the use of in-app browsers results in user choice with respect to their default browser not always being respected
• second, there are certain restrictions on browser engine choice for in-app browsers

We note that the decision on whether a native app launches an in-app browser lies with the respective app developer (for example, Facebook decides whether its native app launches links in an in-app browser or an external browser),^{[footnote 395]} rather than with the user or Apple and Google as the providers of the respective operating system. While this means that Apple and Google as the providers of the respective operating system are not responsible for the use of in-app browsers, we consider that these mechanisms are still relevant to our assessment of barrier to competition in browsers. Also, we note that, through its use of an in-app browser for its search widget, Google, as the provider of the search app, is likely to be responsible for quite significant traffic to in-app browsers.

User choice of default browser not being respected through the use of in-app browsers

Native apps using in-app browsers means that user choice with respect to their default browser (whether determined through the device’s initially-set default browser or a user’s explicit default choice) is overridden, as the native app opens an in-app browser, rather than referring the user to their chosen default browser.^{[footnote 396]}

Overriding user choice is in particular problematic when it worsens user experience. This appears to be the case with in-app browsers in 2 respects.

First, in-app browsers do not apply the user’s stored preferences (for example, with respect to privacy) and do not remember the user’s previously stored passwords, login state, extensions or accessibility configurations, hence worsening user experience.

Second, we understand that the technology that native apps with in-app browsers leverage internally is called ‘web views’,^{[footnote 397]} and that web views are simple ways for app developers to include an in-app browser without incurring large development costs. One technical expert submitted that in-app browsers tend not to fully support various features that other browsers support, noting for example that the Facebook in-app browser on Android fails to support half of the most meaningful PWA features (despite being based on Blink which supports these features). This technical expert also submitted that debugging from in-app browsers can be challenging. This is liable to harm not only web developers but also users.

Restrictions on browser engine choice for in-app browsers

On iOS, in-app browsers have to be built on WebKit, such that similar concerns to those raised with respect to the WebKit restriction above also apply to in-app browsers (ie there is less differentiation and more limited feature support).

On Android, there appears to be browser engine choice for in-app browsers, but default settings may make it difficult to use a browser engine other than Blink, hence further strengthening the position of Blink.

• Google submitted that app developers are free to build their in-app browser on any Android-compatible browser engine of their choosing and would for example be able to build their in-app browser on GeckoView. However, we also understand that the default web view on Android is Android WebView (which is based on Blink)

• Mozilla told us that while app developers have a choice, it is more difficult for app developers to use a browser engine other than Blink, given that Blink is set as the default rendering engine in WebView on Android and using an alternative browser engine involves additional steps including having to install this alternative browser engine. Mozilla submitted that this results in less web page traffic going through alternative browser engines to Blink, creating further challenges to web compatibility. If this leads to additional web compatibility issues, then it can be expected to limit the competitive constraint that alternative browser engines exert on Blink, which in turn is likely to harm consumers

Restrictions on access to APIs and interoperability

Browsers, like other native apps, rely on APIs to be able to offer certain functionality. For example, on Android, APIs enable browsers to directly access the device’s camera and microphone.

Apple and Google’s ownership or influence in respect of their respective operating system gives them control over important APIs and the functionality that browsers can access. Through this control, Apple and Google are able to restrict access to APIs and the extent to which browsers can interoperate with the respective operating system. More importantly, it allows Apple and Google to give their respective own browsers (ie Safari and Chrome) access to more APIs than other browsers have access to. This is likely to limit other browsers’ functionality and, in turn, the competitive constraint they are able to impose on Safari and Chrome. We discuss the evidence considered to date on this issue below.

Apple

Most browser vendors told us that there are features used by Safari which are not available to other mobile browsers on iOS devices. Various stakeholders further commented on specific functionalities that Apple supports on Safari but restricts for other browsers on iOS. Below, we discuss some of the key examples.

• first, both Mozilla’s and Microsoft’s submissions pointed to extensive information on features used by Safari which are not available to other browsers on iOS relating to privacy and security.^{[footnote 398] [footnote 399]}

• second, 5 browser vendors commented on browser extensions or add-ons that are available on Safari but other browsers on iOS do not have access to. Examples of such extensions include content blockers and password managers. Mozilla further noted that the capabilities to have extensions is very important for Firefox users

• third, 4 stakeholders submitted that there are device APIs that provide access to certain features, such as audio features and webcams, which are available on Safari but not enabled for other browsers on iOS.^{[footnote 400]} We understand that these are necessary for building competitive video experiences, including messaging and videoconferencing

• fourth, several stakeholders commented on support for PWAs. While, as discussed above, support for PWAs is generally limited on iOS due to the WebKit restriction, we understand that there are certain features that, while enabled for Safari, other browsers on iOS do not have access to. Specific aspects mentioned include support for service workers (which enable capabilities such as push notifications and background synchronization) and functionality that enables users to add the icon of a web app to the home screen. We understand that this functionality is a prerequisite for any web app experience to resemble that of a native app

The submissions suggest that there are a large variety of functionalities that exist in Safari but that are not available to other browsers on iOS. We consider that at least some of them are significant in how they affect the functionality that other browsers are able to offer and may hence limit the ability of other browsers on iOS to compete effectively with Safari.

In the second half of the study, we will engage further with Apple on these APIs regarding whether and why these APIs are not available to other browsers on iOS.^{[footnote 401]} To the extent that there are legitimate security (or other) reasons for the restriction, we will need to consider further to what extent any resulting benefits from having the restrictions in place outweigh the cost of the limiting competition, or whether there might be less restrictive ways to achieve equivalent benefits.

Google

The evidence we received on the extent to which Google engages in conduct that restricts other browsers’ access to APIs (compared to the access it provides to Chrome) is mixed.

On the one hand, Samsung and Brave submitted that there are no major features that are available on Chrome which are not available to their own browsers on Android. Additionally, there were a number of browser vendors who did not raise any issues relating to API access in relation to Google.^{[footnote 402]}

On the other hand, Microsoft, Yandex and Opera gave the following examples of interoperability being more restrictive for other browsers than for Chrome.

• Microsoft submitted that Android enables Chrome to install PWAs on Android in a way to make them appear more native, while Edge is unable to register PWAs as deeply with the operating system, which limits integration with features of the operating system

• Yandex submitted that Google can prevent other browsers from using the technology which allows users to authorise on websites with biometrics

• Opera submitted that there may be certain ecosystem advantages enjoyed by the platform’s browser, giving as an example Chrome benefiting from a one-click login experience to the Google account associated with the device

Two browser vendors further commented on interoperability issues with respect to web services offered by Google running on alternative browsers.

• Mozilla submitted that certain browsers receive a different Google Search experience

• [one browser vendor] submitted that Google blocks other browsers from using Google Classroom and accessing Google’s comprehensive education services

Overall, there appear to be fewer concerns from rival browser vendors about access to APIs on Android compared to iOS. It is further unclear how important the APIs referred to above are for other browsers to be able to compete effectively with Chrome on Android. However, the restrictions could still, to some extent, limit the competitive constraint other browsers are able to exert on Chrome on Android.

In the second half of the study, we will engage with Google to assess the extent to which there are legitimate security (or other) reasons for the restriction, and if so, will need to consider further to what extent any resulting benefits from having the restrictions in place outweigh the cost of any limitation of competition, or whether there might be less restrictive ways to achieve equivalent benefits.

Conclusion on barriers to effective competition for browsers and browser engines

Overall, we consider that there are material barriers to competition in the supply of browsers engines as well as mobile browsers.

The key barrier to competition in browser engines is Apple requiring other browsers on iOS to use Apple’s WebKit browser engine. In addition, web compatibility limits browser engine competition on Android (where Google allows browser engine choice). These barriers also constitute a barrier to competition in mobile browsers, as they limit the extent of differentiation between browsers – given that browsers with the same browser engine are less able to accelerate the speed of page loading and offer certain functionality beyond what is prescribed by the browser engine.

In addition, there are key barriers to competition in browsers relating to:

• Apple and Google influencing user behaviour through choice architecture, including in particular pre-installation and default settings

• native apps using in-app browsers which disrespect users’ default browser choice

• Apple, and Google in some instances, restricting competing browsers’ access to APIs and interoperability, which, in the case of Apple, reduces the other browsers’ ability to compete effectively and, in the case of Google, could to some extent limit other browsers’ competitiveness

We consider that Apple’s and Google’s strong positions in mobile browsers and browser engines, combined with these barriers to competition, result in Apple and Google having substantial market power in the supply of browsers and browser engines.

Using browsers to reinforce or strengthen a market position in relation to other activities

This section explains the ways in which Apple and Google may be able to use their control over browsers and browser engines to reinforce or strengthen their market position in other activities, such as the distribution of native apps or revenues from digital advertising.

In particular, we consider that Apple and Google may use their position in browsers to reinforce or strengthen their market position in relation to other activities as follows:

• Apple limiting the functionality offered by web apps: Apple may use its position as the steward of WebKit, the sole permitted browser engine on iOS, to limit the success of web apps and increase the take up of native apps (which can only be accessed through its App Store). This could reinforce Apple’s very strong position in relation to the distribution of native apps on iOS as well as in the supply of mobile devices and operating systems, as it reduces the availability of web content which could help rival device manufacturers compete with Apple

• Google’s Privacy Sandbox Proposals: Google may use its market power in browsers and browser engines to reinforce its very strong positions in the supply of ad inventory and in the supply of ad tech services, through its Privacy Sandbox Proposals

• Apple’s Intelligent Tracking Prevention (ITP): Apple may use its position as the steward of WebKit, the sole permitted browser engine on iOS, to make open display advertising less attractive on iOS by limiting user tracking through its implementation of ITP in WebKit. This may decrease the competitive constraint of display advertising on search advertising. It could also reduce the viability of the web as a content distribution channel, which would reinforce Apple’s very strong positions in relation to the distribution of native apps on iOS as well as in the supply of mobile devices and operating systems

• Search agreements between Apple and Google: Apple receives significant revenues from Google Search traffic on Safari. The existence of Google Search as the default search engine on Safari reinforces Google’s very strong position in general search

We outline these matters further below, but plan to examine them further in the second half of our market study.

Apple limiting the functionality offered by web apps

As described above, WebKit provides limited support for web apps and, by Apple requiring all browsers on iOS to use its WebKit browser engine, the support for web apps on all browsers on iOS is reduced.

In principle, web apps could offer an alternative means for users to access content on mobile devices other than through native apps. As described in Appendix F, this approach has substantial advantages for developers, as they can develop a single program which is compatible with devices across all operating systems; however, in practice, due to the restricted capabilities of WebKit, web apps cannot provide functionality fully equivalent to that available to native apps. For example, WebKit does not allow web apps to send push notifications and limits the ways in which web apps can provide a ‘full screen’ experience.

Apple does not appear to have a strong incentive to promote the use of web apps as an alternative to native apps, given that web apps provide developers with an alternative way of distributing content to native apps (which can only be accessed through the App Store on iOS). In particular, web apps are available through browsers and are not subject to the terms and conditions which Apple imposes on app developers as a condition for access to the App Store, which include the obligation to use Apple’s payment system for in-app purchases of digital content (for which Apple takes a commission of up to 30%). Our concern is that Apple’s WebKit restriction materially inhibits the potential functionality of web apps – which have the potential to provide an alternative to native apps as a means for users to access content on mobile devices – and thereby limits the competitive constraint of web apps on native apps.

Further, ensuring that sufficient popular content is available on a device (whether accessible via browsers or native apps) is presently a key barrier to entry for rival providers of operating systems. If web apps were universally enabled to have similar capabilities to native apps, developers may be more likely to develop content for the web, in particular web apps, which could be accessed on any operating system. Therefore, by limiting the capabilities of web apps, Apple may increase the effects of this barrier to entry and protect its position in the supply of mobile devices and operating systems (which for Apple are closely linked).

Google’s Privacy Sandbox Proposals

Currently, some display advertising relies on the ability to identify individual web users and ‘track’ them across websites by means of third-party cookies (TPCs) and other forms of cross-site tracking. In 2019, Google announced its plans to remove support for TPCs in its Chrome browser and replace the functionality of TPCs and other forms of cross-site tracking with a number of changes through its Privacy Sandbox Proposals. The stated aim of the proposals is to remove cross-site tracking of Chrome users through TPCs and alternative methods such as fingerprinting, and replace it with tools to provide selected functionalities currently dependent on cross-site tracking.^{[footnote 403]}

We are concerned that, if implemented without regulatory scrutiny and oversight, the Privacy Sandbox Proposals might have had the effect of leveraging Google’s market power in browsers and browser engines to reinforce its very strong positions in the supply of ad inventory and in the supply of ad tech services. In particular, we consider that the proposals risked:

• distorting competition in the market for the supply of ad inventory and in the market for the supply of ad tech services, by restricting the functionality associated with user tracking for third parties while retaining this functionality for Google^{[footnote 404] [footnote 405]}

• distorting competition by the self-preferencing of Google’s own advertising products and services and owned and operated ad inventory^{[footnote 406]}

• allowing Google to exploit its apparent dominant position by denying Chrome web users substantial choice in terms of whether and how their personal data is used for the purpose of targeting and delivering advertising to them^{[footnote 407]}

On 7 January 2021, the CMA opened an investigation into Google’s Privacy Sandbox Proposals. This followed complaints of anticompetitive behaviour and requests for the CMA to ensure that Google develops its proposals in a way that does not distort competition.

To address the CMA’s concerns, Google UK Limited and Google LLC offered commitments providing for scrutiny and oversight by the CMA over implementation of, and announcements relating to, Google’s Privacy Sandbox proposals.^{[footnote 408]} The CMA reached the provisional view that the Proposed Commitments, which provided for the close involvement of the CMA in the development of the Privacy Sandbox Proposals, would address these competition concerns.^{[footnote 409]} It consulted publicly on these views.

After consideration of the responses to the CMA’s consultation and possible modifications to those commitments, Alphabet Inc., Google UK Limited and Google LLC offered revised commitments under section 31A of the Act. These commitments provided for enhanced scrutiny of the nature described above and additional obligations on Google. The CMA launched a consultation on Google’s modified commitments on 26 November 2021. While the role of monitoring the implementation of any commitments would fall to the CMA for the duration of those commitments, in the medium term the establishment of the DMU could provide a framework for regulatory oversight and scrutiny.

Apple’s Intelligent Tracking Prevention (ITP)

ITP comprises a set of changes to WebKit that aim to prevent cross-site tracking by default on all websites to address privacy concerns, and which create a set of alternative tools for practices that rely on techniques that can be used for tracking.

Implementation of Intelligent Tracking Prevention (ITP)

Apple implemented ITP in WebKit in stages between 2017 and 2020. Early versions of ITP merely limited the length of time for which cookies could be used to track a user in third-party contexts (ie on other sites), if the user had not visited the origin domain. However, in 2020 Apple introduced full TPC blocking. We understand that ITP now:

• blocks TPCs by default, with certain exceptions such as when the user actively consents^{[footnote 411]}
• frequently purges data stored in the browser^{[footnote 412]}

There are many parallels between ITP and Google’s Privacy Sandbox Proposals. However, in contrast to Google’s Privacy Sandbox Proposals that are marketed as a set of open standards that make the web more private and secure for users while also supporting publishers, Apple has positioned ITP as a strict privacy feature, suggesting that the ‘unintended’ impacts of which (including on advertisers) would need to be tolerated.^{[footnote 413]} Also, the functionality which Apple has introduced to replace TPCs appears to be less useful to advertisers than the equivalent functionality included in Google’s Privacy Sandbox Proposals.^{[footnote 414]}

Another important difference between Apple’s ITP and Google’s Privacy Sandbox Proposals is the extent to which they directly impact Apple’s and Google’s respective other activities. In particular, Google directly benefits from a distortion in competition in the supply of ad inventory and ad tech services, given its strong presence in both display and search advertising. Apple, on the other hand, does not have a meaningful presence in display advertising, such that there is less of a concern of Apple self-preferencing its own display advertising. Apple does also not have a meaningful presence in search advertising, although it does receive a high share of revenue from Google Search advertising to Safari users.

Potential harm to competition arising from Apple’s use of ITP

By reducing the information shared with advertisers, ITP improves users’ privacy.^{[footnote 415]} In this regard, Apple submitted that the goal of ITP is to limit tracking by default while still enabling websites to function normally, and to provide transparency and control over what user data is shared and how it is used. Notably Firefox was the first to implement tracking prevention (in Gecko) and Apple publicly credits it for inspiring ITP.^{[footnote 416]}

However, ITP also makes online display advertising less effective and user acquisition more expensive, harming online content providers and app developers through a reduction in revenue. As set out below, most of the 67 app developers and online content providers that we gathered evidence from on this issue reported some harm.^{[footnote 417]}

• 15 out of 34 online content providers reported that ITP has significantly impacted their ability to engage in targeted advertising.^{[footnote 418]} Similarly, 10 out of the 33 app developers told us that ITP has significantly impacted their business. Only 3 app developers said they had developed workarounds that partially mitigated the impact of ITP on their business.

• 8 out of 34 online content providers reported that ITP has measurably impacted their advertising revenue, half of which are news providers.^{[footnote 419]}, ^{[footnote 420]}. For example, one respondent reported a 71% reduction in CPM (cost per thousand impressions, an advertising pricing metric) on Safari over the course of the introduction of ITP, resulting in substantially lower advertising prices on Safari than Chrome. This is consistent with submissions by adtech providers to the CMA’s market study into online platforms and digital advertising that they had been significantly impacted by Apple’s decision to implement Intelligent Tracking Prevention (ITP) on Safari in September 2018.^{[footnote 421]}

By making online display advertising less effective and lucrative, ITP could, in principle, harm competition in several ways.^{[footnote 422]}

First, ITP could reduce the competitive constraint from display advertising on search advertising, including on Google which has a very strong position in search advertising. One online content provider specifically stated that it had switched towards search advertising in response to ITP. Google’s advertising rivals Snap and Facebook said that advertisers’ responses to ITP changes in 2021 hurt their third-quarter sales, while Google saw an increase in its revenue; ^{[footnote 423]} reportedly seeing a 44% increase in revenues generated on Google Search and other Google owned and operated properties for the third quarter, driven partly by growth in advertiser spending.^{[footnote 424]} Apple benefits from higher Google Search revenues through its Revenue Share Agreement with Google, through which it receives a high share of Google Search revenues generated through Safari. For consumers, a loss of competition in advertising can cause harm, for example, by increasing advertisers’ costs and causing these to be passed through to consumers.^{[footnote 425]}

Second, ITP could reduce the viability of the web as a content distribution channel, weakening the constraint this imposes on Apple in the distribution of native apps and ultimately in mobile devices and operating systems, in which Apple has a very strong positions.^{[footnote 426]} This loss of competition could harm consumers by: (i) allowing Apple to raise or defend high in-app payments obligations in the App Store,^{[footnote 427]} (ii) allowing Apple to raise the cost of advertising on the App Store (which could ultimately be passed through to the prices faced by users); ^{[footnote 428]} and ultimately by (iii) allowing Apple to raise or defend device prices.

In addition to the above effects on advertisers and online content providers (which impact consumers indirectly), assessing the overall impact of ITP on consumer welfare requires a balancing of several other effects (positive and negative) on consumers:

• ITP may be highly valued by users as a privacy protection measure. Tracked advertising may have been oversupplied by firms with market power.^{[footnote 429]} ITP also reduces the risk of TPCs being set without the users consent^{[footnote 430]}

• in certain cases, ITP can directly harm users’ experiences by breaking web functionality, for example where it deletes stored data

• ITP could also harm some users’ experiences directly by worsening the quality of advertising. Direct user harms of this kind mentioned by online content providers and app developers include higher incidences of less relevant or irrelevant advertising, a reduced ability to cap the frequency of adverts, a reduced ad variety due to lower bid participation rates on real-time bidding auctions. However, we also note that for some privacy-conscious users, this may be viewed as a positive outcome

• in combination with ATT, which, as described in The role of Apple and Google in competition between app developers, serves to limit the effectiveness of app-based advertising, ITP may reduce the ability of consumers to access free content funded by advertising (which in some cases may be consumers’ preference), given that fewer firms may be willing to provide free content if advertising is less effective

Building on recent collaboration on the CMA-ICO joint statement on the relationship between competition and data protection,^{[footnote 431]} and in relation to Google’s Privacy Sandbox Proposals, the CMA will continue to work in close partnership with the Information Commissioner’s Office (ICO), to understand how best to promote outcomes that are competitive, while consumer and data protection rights are respected, and citizens are empowered to exercise meaningful control over their personal data.

Specifically, in the second half of our study, we will seek to engage with the ICO to better understand the application of data protection law in respect of Apple’s ITP and ATT policies, and to understand the extent to which there might be data protection implications from any of the potential interventions we are considering.

Search agreements between Apple and Google

As described above, browsers are an important access point for search engines to users. Most consumers use the default search engines on their browser,^{[footnote 432]} and search defaults on browsers attract large payments. Apple receives a high share of Google Search revenue from Safari search traffic. This level of payment is likely to reflect Apple’s strong position in browsers (and other search access points). Google’s payments to Apple constituted the substantial majority of Google’s £1.2 billion total 2019 default payments made in relation to the UK.^{[footnote 433]}

As noted in the CMA’s market study into online platforms and digital advertising, Google’s extensive default positions in relation to general search act as a significant barrier to expansion for rival search engines and lead to weaker competition to Google in general search. We also noted that having been by far the largest search engine for more than a decade, Google benefits from higher perceived quality among many consumers, can generate more search advertising revenues from a given default, and is able to pay more for default positions than other search engines.^{[footnote 434]}

With respect to Chrome, we note that, as described above, Google no longer sets Google Search as the default in the UK and the EEA; it provides a choice to users via a search engine choice screen. However, in practice almost all users choose Google Search: in the year to 31 August 2021 in the UK, in [90% to 100%] of cases in which the choice screen was used, Google Search was chosen.^{[footnote 435]} Additionally, we received concerns from one search engine rival that Google uses Chrome to prompt users to re-set Google Search as their default if they set an alternative default search engine. Such prompts allow Google to use its market power in browsers to reinforce its very strong position in search.

Google Search’s default position on Safari gives rise to particular concerns, given Safari’s large share of supply with respect to both mobile browsers and browsers more generally. Next to Chrome, it is the only browser with a share of supply above 10%, and hence a key access point for search engines to users that – given Google’s ability to outbid rivals for default positions – rival search engines cannot access.

As noted in the CMA’s market study into online platforms and digital advertising, weak competition in general search may negatively affect consumers in several ways, including through: (i) Google facing weaker incentives to keep improving Google Search in the interests of consumers; (ii) Google collecting more consumer data (or offering consumers worse terms in return for their data); and (iii) higher prices for other goods and services (if Google is able to use its market power to raise search advertising prices above competitive levels).^{[footnote 436]}

Key findings in relation to mobile browsers and browser engines

Other than app stores, web browsers are the most important way for users of mobile devices to access content and services over the internet. Based on the evidence that we have reviewed so far, we provisionally find that Apple and Google have significant market power in the supply of mobile browsers and browser engines.

Both Apple and Google have very high shares of supply in mobile browsers (and browsers more generally), and their positions in browser engines are even stronger. The competitive constraints faced by Apple and Google from other mobile browsers and browser engines, as well as from desktop browsers and native apps, are weak, and there are significant barriers to competition on both iOS and Android.

On iOS, Apple requires all browsers to use Apple’s WebKit browser engine, resulting in Apple facing no competition in the supply of browser engines on iOS. The restriction further enables Apple to largely control the quality and functionality of all browsers on iOS, which limits the extent to which rival browsers can differentiate themselves from and exert a competitive constraint on Apple’s Safari browser.

Rival browsers on iOS are further limited in their ability to compete due to Apple pre-installing Safari and setting it as the default browser on all iOS devices. Apple also makes it difficult for users to change their default browser and, where users do exercise choice over the default browser, these are overridden in certain contexts. Rival browsers’ ability to compete on iOS is also reduced by Apple restricting their access to APIs and interoperability more than it does with respect to Safari.

On Android, Google allows browser engine choice, with browsers being able to choose an existing browser engine or create a new browser engine (including through forking). However, the need to preserve web compatibility is a key barrier to browser engine competition, resulting in most browsers being based on, and not diverging much from, Blink. Browser engine choice on Android therefore appears to only increase differentiation between browsers to a small extent, and the extent to which new features are offered on Android browsers is largely determined by what Google enables on Blink.

Google’s Chrome browser is pre-installed on most Android mobile devices and often set as the default browsers. Google has introduced some friction to the process for users to change their default browser than (although there are certain initiatives such as choice screens to facilitate user choice) and, where users do exercise choice over the default browser, these are overridden in certain contexts. These factors limit rival browsers’ ability to compete for users. There further appear to be some instances where Google limits rival browsers’ access to APIs and interoperability, and these restrictions could, to some extent, limit the competitive constraint other browsers are able to exert on Android.

We have concerns about Apple and Google using their market power in mobile browsers and browser engines to reinforce or strengthen their position in other activities. As set out above, these concerns relate in particular to Apple and Google potentially distorting competition in digital advertising, and Apple using its position in browsers to reinforce its very strong position in relation to the distribution of native apps on iOS, as well as in the supply of mobile devices and operating systems.

6. The role of Apple and Google in competition between app developers

Key Findings

• Apple’s and Google’s control over their respective mobile ecosystems allows them to set the ‘rules of the game’ for app developers who seek to use their app stores. We have found that in many cases, Apple and Google have the ability and incentive to provide their own apps with a competitive advantage:

  • Apple reserves access to certain hardware functionality, such as the contactless payments technology, protecting its services that use this technology from competition and potentially restricting innovation.

  • App review processes are opaque, and rules appear to be inconsistently applied, and could be used to favour Apple’s and Google’s own apps. Also, the resulting delays and uncertainty can add to development costs and hinder innovation by app developers.

  • Apple and Google can influence users’ choice of apps through pre-installation, setting apps as defaults, and design of their app stores.

  • Apple and Google have access to a range of commercially sensitive information from app developers. We have heard concerns that this information may be used by Apple or Google to develop products, enter new markets or gain a competitive advantage over third-party developers.

• Both Apple and Google require certain app developers to use their payment systems, through which they collect a commission of up to 30% on in-app purchases. In addition to complaints about commission levels, we have heard concerns that the requirement to use these payment systems may reduce developers’ control over pricing and refunds, distort competition between apps where these compete with Apple’s and Google’s apps (which do not pay commissions), and can make it harder for users to switch devices.

• Apple’s App Tracking Transparency policy, which aims to give consumers greater control of their personal data, may create consumer benefits by enhancing privacy and choice. However, Apple’s implementation of the policy may distort user choice and apply different standards to itself and to third parties. This may entrench the App Store’s position as the main way of users discovering apps, advantage Apple’s advertising services, or drive app developers to begin charging for previously free, ad-funded apps.

• Apple has inhibited the emergence of cloud gaming on the App Store. Cloud gaming threatens Apple’s position in app distribution since it represents an alternative method of game discovery and distribution. Apple’s policy may also protect its competitive position in mobile devices and operating systems, as cloud gaming services may reduce the importance of high-quality hardware and make it easier for users to switch between platforms.

Introduction

In this chapter, we consider the role of Apple and Google in competition between app developers, and the potentially damaging effects their conduct in this role may have on competition.

As set out in Overview of mobile ecosystems, apps are a critical component of mobile ecosystems and are one of the main channels through which businesses can connect to consumers online. The wide variety of apps available to consumers – millions of apps from hundreds of thousands of app developers – is one of the defining characteristics which sets modern mobile devices apart from earlier forms of mobile phones. It is therefore important for these markets to work well for consumers, and that effective competition in these markets is not undermined by Apple and Google.

Apple and Google, through control of the operating systems and (main) app stores in their respective mobile ecosystems, may influence competition in downstream app markets through a number of different mechanisms. This influence can be felt throughout the entire process of app development and distribution, in the following stages:

• app development: through control of their respective operating systems, Apple and Google determine the functionality available to developers when developing apps

• app distribution: Apple and Google set the terms of access to their app stores through terms and conditions which must be followed in order for app developers to be able to access users through the App Store or Play Store. Apple and Google unilaterally set, interpret, and amend the terms and conditions and enforce these through their app review processes

• app discovery: Apple and Google can influence the apps which consumers discover, download and use through the way they present choices to users within their operating systems and app stores (referred to as ‘choice architecture’)

• apps in use: Apple and Google may use insights that they gather through their gatekeeper role in the development of their own apps (and associated hardware or software)

In the first half of the chapter we assess how practices by Apple and Google in each of these stages may serve to preference their own apps or distort competition between third parties. In the second half of the chapter, we consider in more detail 3 practices which have the potential to affect competition between app developers and entrench market power upstream, and which cut across several of the stages referred to above. These are:

• certain requirements to use Apple’s and Google’s proprietary purchase systems for in-app purchases of digital content

• recent Apple changes to how app developers can collect and use data for mobile advertising on iOS (App Tracking Transparency, or ATT)

• Apple’s restrictions on cloud gaming services

The figure below summarises the practices we have assessed in this chapter and how they relate to the stages of app competition.

Figure 6.1: Apple and Google's role in app competition

Figure description: A diagram showing the practices assessed in this chapter and how they relate to the stages of app competition. The app development stage of competition is linked to software and hardware restrictions. App distribution is linked to rules and review processes. App discovery is linked to pre-installation and defaults, and app store design. ‘Apps in use’ is linked to inappropriate use of commercially sensitive information. Ther are also 3 practices that cut across different stages: IAP obligation cuts across app distribution, app discovery and apps in use. ATT cuts across app distribution and app discovery. Cloud gaming restrictions cut across app distribution and app discovery.

Overview of concerns

The broad concern that we assess in this chapter is that Apple’s and Google’s market power in app distribution, operating systems and, in Apple’s case, devices allows them to set the rules of competition for native apps. Apple’s and Google’s use of this ability could serve to:

• self-preference their own apps or services in a way that harms competition and consumers
• distort competition between third parties
• entrench upstream market power
• directly exploit consumers

Apple and Google have both emphasised to us that they are incentivised to ensure that users have access to a choice of high-quality apps through their respective app stores. Apple told us that the purpose of its App Store ‘is to add value to the iPhone’, and that its incentives are ‘to give consumers choice, while ensuring that its consumers are not exploited’. Similarly, Google told us that ‘Android users want a variety of high-quality apps, while Google and developers benefit when more users are happy with the Android experience’.

We recognise that the App Store and Play Store add significant value to Apple’s and Google’s respective mobile ecosystems, and so Apple and Google have a general interest in maintaining choice and quality in their app stores. However, we consider that each company’s incentives are unlikely to always be fully aligned with consumers’ interests. As discussed in Competition in the distribution of native apps, consumers do not fully take into account the value they will gain from the app store and app markets when choosing a mobile ecosystem, and the barriers to switching ecosystem mean they are unlikely to change their choice in response to a reduction in that value. As a result, Apple and Google may in some cases have an incentive to engage in practices that are harmful for competition or consumers, even if these could lessen the value or experience that users derive from their ecosystems.

In the following subsections we explain how we have approached considerations of harm to competition resulting from self-preferencing or from distorting competition between third parties offering products or services within mobile ecosystems, as these are more general concerns that apply to a range of practices we have considered. The concerns about entrenching market power and exploiting this position are more specifically tied to the individual practices which we have assessed in greater depth in the second half of the chapter.

Self-preferencing

The potential for self-preferencing arises in mobile ecosystems because Apple and Google have a dual role: as well as operating the app stores within their respective ecosystems, they compete with app developers who use those app stores to reach consumers. This can create conflicts of interest for Apple and Google, with the possibility to use their control over their respective app stores – as well as their control over their respective operating systems and, in Apple’s case, devices – to give their own apps or services a competitive advantage over rivals. As discussed further below, self-preferencing behaviour can be harmful to competition and to consumers.

In general, the main ways in which Apple and Google may be able to self-preference their own apps or services are:

• biasing consumer choice: using choice architecture to make consumers more likely to choose their products even if these products do not best meet consumers’ preferences

• giving their own products a (non-replicable) quality advantage: either by degrading rivals’ quality or by improving their own products in ways that are not accessible to rivals (for example, better integration with the platform)

• raising rivals’ costs through the fees charged for use of their platforms or through making it more costly in other ways for those rivals to access the platform compared to their own first-party products

• using information gained from app developers by virtue of their positions as platforms – which may in the long run harm third-party developers’ incentives to innovate

Regardless of the form of self-preferencing, a general concern is that it reduces the competitive pressure on Apple or Google to offer the most attractive product offering to consumers, as they can instead rely on advantages they gain by virtue of controlling their platforms.

Depending on the form of self-preferencing, it might also harm competition over the longer term by reducing incentives for rival companies to innovate or by entirely foreclosing competition in certain markets. It may also directly harm consumers by reducing the quality or increasing the price of the products available to them, or by causing them to use Apple’s or Google’s products when competitor products might have provided them with better value.

When assessing Apple’s and Google’s practices, we are mindful that certain types of self-preferencing could bring about benefits to consumers, particularly in the short term. Such practices could, for example, result in the creation of higher-quality apps and services by Apple or Google, or may increase the competitive pressure faced by third-party developers to improve their own product offerings. When evaluating whether the practices assessed in this chapter may cause harm to competition by allowing Apple and Google to self-preference their own services, we have also considered the potential short-term benefits to consumers of these practices.

Distorting competition between third parties

Certain aspects of the way in which Apple and Google operate their app stores may also have distortive effects on competition more broadly, even where it does not result in an advantage to their own downstream apps.

We have considered 2 types of concern:

• some practices by Apple or Google may systematically advantage certain types of app, or apps that follow particular business models, creating an uneven ‘playing field’ which may result in harm to competition and consumers

• some practices by Apple or Google may more generally be harmful to the ability of app developers to develop apps, compete, and innovate

First, in the same way that they may be able to give their own apps a competitive advantage, Apple and Google may also be able to give some third parties a competitive advantage over others, for example, by using choice architecture to bias consumers towards certain apps or by imposing higher costs on some apps than others. Apple and Google may be motivated to do this if they benefit more from the success of certain types of app. For example, they might have an incentive to give an advantage to apps which offer in-app purchases (as they can collect a commission on these purchases) over apps which monetise in ways which do not require any sharing of revenues with the app store owner. Or they could prefer apps which contribute to consumer ‘lock-in’ to their mobile ecosystem, such as apps that are exclusive to one operating system.

This could be harmful for consumers, as it may result in reduced availability or quality for those types of apps which are put at a disadvantage, and which may be preferred by at least some consumers to the types of apps given an advantage by Apple or Google.

Second, as set out in Competition in the distribution of native apps, our preliminary view is that both Apple and Google have substantial market power in relation to native app distribution. This market position potentially allows them to impose costs, set unfair terms and create significant disruption to the businesses of app developers. Such conduct could deter entry and innovation by developers, and ultimately result in higher prices, lower quality or less choice for consumers.

How Apple and Google influence app competition

In the first half of the chapter, we consider how a number of practices by Apple and Google relevant to different stages of app development and distribution have the potential to be used to preference their own apps or distort competition between third parties. We discuss each of the following areas:

• restrictions on access to hardware and software functionality
• the review processes used to allow apps onto the App Store and Play Store
• pre-installation and default-setting of certain apps
• design of the way users are presented with choices on app stores
• potential for collection and use by Apple and Google of commercially sensitive information and other data from app developers

Access to device hardware and software

Modern mobile devices have a range of built-in pieces of hardware and software, examples of which include Bluetooth, GPS, and motion sensors. The functionality that these pieces of hardware and software enable is part of what makes these devices so ubiquitous, as it allows them to be used for many different purposes.

Apps and services can make use of a device’s functionality through Application Programming Interfaces (APIs), which are pieces of software that facilitate communication between applications. For example, there are camera APIs that allow app developers to integrate photo taking capabilities into their apps and GPS APIs that allow them to make use of location data. Mobile devices have tens of thousands of APIs which control access to all aspects of the device.

Apple’s and Google’s ownership of their respective operating systems gives them control over important APIs and the functionality these APIs govern access to. The extent of control that Apple has over APIs is potentially greater than that of Google, in particular because Apple has more control over device hardware than Google, given its position as the sole manufacturer of iOS devices.^{[footnote 437]}

Apple and Google appear to have strong incentives to open up APIs to third-party developers to the extent that they benefit from the existence of good apps in their ecosystem and apps, in turn, benefit from access to APIs. Nevertheless, we have heard concerns from app developers that there are some critical APIs that Apple and Google do not permit third parties to make use of. These are discussed in more detail below.

There are also some APIs which Apple only allows certain third parties to access. In particular, Apple maintains a system of ‘entitlements’ that control which third parties are able to access certain APIs. Some of these entitlements are publicly listed, and developers can apply to Apple for them. For example, Apple’s CarPlay allows certain device features to be mirrored on an in-car display and, although the relevant APIs for CarPlay are not automatically available to developers, they can apply for an entitlement and Apple provides instructions on how to do so.^{[footnote 438]} We have heard that there are some entitlements that are not publicly listed and may be available by Apple’s invitation only.

Potential harm to competition

As discussed, APIs allow apps to access useful functionality. If apps are blocked from accessing useful APIs, their quality will be deteriorated relative to apps with access.

Our primary concern in relation to access to APIs is that Apple’s and Google’s restrictions on access to APIs may give a competitive advantage to their own apps and services. In some instances, they may also give a competitive advantage to certain privileged third-party apps, but we have not heard concerns about restrictions on API access distorting competition in this way.

The extent of harm to competition from restricting access to an API will depend on:

• the extent to which apps rely on the API to function – if it is central to their functioning, then restricting access to the API will render them useless or preclude them from access to the ecosystem at all, effectively removing competition to first-party or other privileged apps

• the extent to which competitors are restricted from accessing useful APIs – in some cases, competitor apps may be able to access an API but only after satisfying certain criteria and this will likely not be as harmful to competition as when access is blocked altogether

Apple’s and Google’s justifications for restricting access to APIs

Apple and Google often justify restricting access to APIs on the basis that these APIs govern access to functionalities which are sensitive for privacy or security reasons. For example, Google told us that there are APIs within Google Play Services that enable its first-party apps to access a user’s account details and that it would not be appropriate, for privacy and security reasons, to expose these details to third parties. Apple told us that providing access to certain APIs could impact user safety, security, and privacy as when these APIs allow apps to alter software such as that which manages the iPhone’s battery, or which regulates its temperature or radiofrequency exposure levels.

Apple’s justifications may often relate to user experience concerns, with Apple telling us it must be careful when providing access to APIs to ensure they work well with developers’ apps. In particular, Apple told us that ‘APIs have to be stable, well-tested and long-lived before being released’ to ‘ensure that the technology works.’ Furthermore, it claimed that [REDACTED].

The NFC chip

One notable piece of hardware to which Apple restricts access through restrictions on APIs is the near-field communication (NFC) chip. NFC is a short-range wireless technology which allows devices to communicate with each other at short distances. NFC has a range of innovative applications including access control, smart ticketing, and inventory management.

A key application of NFC chips on mobile devices is in enabling them to make contactless payments. The use of contactless cards which allow individuals to pay for things by holding them near payment terminals is now ubiquitous in the UK and NFC chips in mobile devices allow them to imitate contactless cards and make contactless payments themselves.

In 2014, Apple started putting NFC chips in iPhones and, along with this, released Apple Pay – a mobile payment and digital wallet service that allows users to make payments with their iPhones. Since 2014, Apple Pay has been the only mobile wallet on the iPhone that can make use of the NFC chip. This is in contrast to GMS-enabled Android devices where third-party mobile wallets can and do make use of NFC chips. Apple monetises Apple Pay by charging a fee to card issuers on payments made with it. In 2020, Apple’s net UK revenue from Apple Pay was $[30 to $40] million.

[One developer] told us that by reserving access to the NFC chip for its own payment service, Apple effectively deprecates the quality of rival mobile wallets and gives itself a competitive advantage in mobile payments. In particular, it claimed that NFC is indispensable for providing contactless mobile payments and that other technologies, such as QR codes, Bluetooth, or external ‘stickers’ that users attach to their phones, are not viable alternatives at scale.

Apple cites security concerns and customer experience for not letting developers access the NFC chip for payments, claiming that Android devices are susceptible to third-party attacks that can compromise customers’ card information.

[One developer] told us that, contrary to Apple’s claims, NFC access could be provided to third-party mobile wallets without jeopardising security. It gave the following reasons to support this claim. First, Apple already provides NFC access to third parties for security sensitive functions, such as opening automobile doors, accessing hotel rooms and college campuses, and tracking employee movements. Second, Apple can and does provide certain third parties with access to the secure element – where payment data is stored – without compromising security. Third, Apple could enable the storage of sensitive data in secure cloud environments, as Android devices do.

Contactless payments are increasingly popular with consumers, accounting for over a quarter of payments in the UK in 2020.^{[footnote 439]} By preventing rival mobile wallets from being able to offer such payments, Apple gives itself a clear competitive advantage. Payments is an area where security is important, however, this should not give Apple a blanket justification for restricting competition. Indeed, there are good reasons to believe that NFC access for payments could be provided to third parties, as is the case on Android, without compromising security.

Ultra-wideband chip

Another important piece of hardware that Apple restricts access to is the ultra-wideband (UWB) chip. This was included in the iPhone in 2019 but has not been accessible by third parties. UWB is a short-range wireless communication protocol which allows electronic devices to communicate with each other at short distances, and is used by Apple devices for spatial awareness, allowing iPhones to precisely locate other Apple devices.

Tile is a company that makes tracking devices which users can attach to their belongings and that allow them to locate these belongings with their mobile devices in case they lose them. According to Tile, access to the UWB chip would allow its users to locate belongings with greater precision. In particular, it told us that ‘whereas Bluetooth can tell you which room an item is located in, UWB can tell you precisely where it is in that room.’ Tile claims that, since 2019, it had made repeated requests to Apple to make use of the UWB chip and that Apple repeatedly denied these requests until September 2021, when Apple provided them with access to the UWB API. Tile told us that this considerably delayed the launch of its UWB trackers (which will not be ready for launch until 2022).

In 2021, Apple launched a new product called AirTag which is similar to Tile’s product but which does make use of the UWB chip. We discuss below in the section on collection and use of commercially sensitive information Tile’s concerns that Apple had access to a wide range of Tile’s sensitive confidential information before launching this competing product, and that Apple self-preferences its own product in other ways.

Apple recently announced that it would enable third-party device makers, such as Tile, to access the UWB chip. Given, however, that this comes after it has released its own product which makes use of the technology, it may have already benefited from restricting access: Apple released AirTag in April 2021 and it told us that it expects to be ready to provide third parties access to the UWB chip by the end of 2021 or early 2022.

Split-view-multitasking

One example of Apple granting certain third parties, but not others, privileged access to an API is with a function called split-view-multitasking. This function allows iPad apps that make use of the camera, such as video-conferencing apps, to do so while the user is in multitasking mode, which includes Split View and Slide Over mode.^{[footnote 440]}

In May 2021 it was reported by an app developer^{[footnote 441]} that Zoom was given access to this functionality and that it appeared to be the only meeting app that was. Furthermore, the developer reported that it appeared that there was no public process for applying for the entitlement to make use of this functionality.

Apple told us that it ‘offered a number of video conferencing apps access to run the iPad camera simultaneously in Split View and Slide Over with other apps.’ It also told us that ‘through entitlements, Apple provides early access to hardware or software to limited groups of developers in order to test new features and technology’.

It is not clear how Apple went about selecting Zoom to receive early access. Furthermore, we consider that there may have been ways that Apple could have tested the feature without potentially distorting competition, for example, by allowing developers to apply for the relevant entitlement.

Integration of third-party voice assistants

We have heard concerns that Apple and Google are able to limit the ability of third-party voice assistants to access device functionality. For example, neither Apple nor Google allow access to functionality that would allow third-party voice assistants to be activated through the use of a ‘wake word’, as is possible with their own first-party voice assistants.

We have also heard concerns that there are other ways in which third-party voice assistants are deprecated relative to first-party ones. For example, Apple’s Siri is able to read and send text messages on iOS devices, but third-party voice assistants are not. Additionally, Google’s voice assistant can perform multi-step tasks with the camera, which, again, third-party voice assistants cannot do.

Preliminary conclusions

Apple appears to be more restrictive than Google in respect to access to APIs, based on the fact that complaints we have heard about Apple’s behaviour in relation to access to APIs are far more numerous than those about Google’s behaviour.

Our preliminary view is that the proffered justifications for limiting third-party access to at least some aspects of device hardware and software are likely to be warranted. However, we are concerned that in some cases discussed above – such as access to the NFC chip – total restrictions on third-party access are likely to significantly distort competition and that there could be less restrictive approaches to controlling access to APIs which would foster competition without compromising security or user experience.

App review processes

As explained in Competition in the distribution of native apps, before developers can distribute their apps to consumers through Apple’s App Store or Google’s Play Store, they must submit the apps for app review. Each store has a set of rules that apps must comply with in order to be accepted – the App Store Review Guidelines or the Google Play Developer Program Policies. Every app or app update is reviewed for compliance with these rules before it can be distributed via the app store.

Aspects of these rules of access seek to promote and maintain the quality and safety of apps available in the respective app stores. For example, they include requirements about the content of apps; privacy (including the way in which apps collect customer data); and security. App review is an opportunity for Apple and Google to identify and address potential concerns with apps.

Apple told us that its app review process is an important tool contributing to the security offered by iPhones, emphasising the role of app review in ensuring that apps follow privacy guidelines, are screened for malware and do not access data or functions that are unnecessary for their purpose. It also said that, with regards to the App Store Review Guidelines, these need to be a ‘living document’ because the dynamic nature of app development means they must adapt to developer innovations and evolving risks from harmful actors.

Google told us that its interest in the app review process is to ensure there is a variety of high-quality apps on the Play Store. It said that apps are reviewed based on clear and objective criteria, including criteria related to security and privacy.

On the other hand, the existence of these app review processes means that Apple and Google effectively dictate the terms that third-party app developers must agree to in order to access their app stores and as set out below, we have heard concerns from app developers about the inconsistent interpretation and application of terms and conditions and about the transparency or quality of communication experienced during the app review process.

If an app is found to be in violation of one or more rules, the app (or app update) is not uploaded to the store, and the developer is given an explanation of the rejection and may revise their app to bring it into compliance before resubmitting it. This also gives Apple and Google a powerful position in respect of app developers seeking to bring their apps to users on the App Store and Play Store.

Both stores also offer an appeal process that a developer can use if they believe their app was mistakenly rejected. These processes result in other reviewers at Apple or Google re-evaluating the decision to reject an app and either confirming or overturning that decision. In the case of Apple, developers may also use this process to suggest changes to the guidelines.

While both Apple and Google publish the rules for admission to their app stores, Apple in particular gives itself wide discretion to reject apps for new reasons not covered by the existing rules – as ‘new apps presenting new questions may result in new rules at any time’, as well as including a broad statement that:

We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it.’^{[footnote 442]}

We consider the competitive effects of particular rules, such as the obligation to use proprietary in-app payment systems, later in this chapter. In this section we consider the effects of the review processes themselves.

Developer concerns

In order to understand the potential harms to competition arising from the operation of the app review processes, we asked app developers for feedback on their experiences with each of Apple and Google’s processes.

With regard to Apple, the majority of developers that we requested information from had negative experiences with the app review process. Developers variously described Apple’s app review process as ‘obscure’, ‘arbitrary’, ‘capricious’ and ‘kafkaesque’. These developers raised a large number of concerns about the issues App Store review had caused for their businesses, and we heard similar concerns from developers who responded to our online questionnaire. Developers’ concerns fell into 3 main categories:

• apps being rejected without sufficient explanation of the reasons for rejection
• changes in interpretation of the guidelines, over time or between reviewers
• apps being rejected for things that were seen as acceptable in other apps, or in Apple’s own apps

The most widespread issue with the App Store review process reported by developers was that the explanation they receive for the rejection of an app or update often does not provide them with enough information on Apple’s reasoning. This means that they do not understand how to address Apple’s concern and make their app compliant. Several developers said that Apple only provides them with a reference to which guideline their app was seen to be violating, without a clear explanation of why the app was in violation of the guideline or any guidance as to what changes needed to be made to the app for it to comply with the guidelines. One app developer stated, ‘Apple’s feedback is cryptic, forcing developers to determine for themselves the actions they must take to satisfy Apple’s requirements’.

While some developers found that they could come to an understanding of Apple’s concerns with their apps through communications with Apple (often through account managers at Apple), others found that Apple would not provide further explanation even after the developer asked for clarification or proposed solutions.

Another issue raised by developers is inconsistency in the interpretation of the App Store Review Guidelines. Developers provided examples of cases where:

• their app was rejected for something that had not caused rejections in previous versions of the app. For example, [a developer] told us that it ‘has had app builds rejected even when a feature or functionality has been present in the app for some period of time’

• developers were provided with contradictory interpretations from Apple employees of whether parts of their apps were in violation of the rules. For example, one developer told us that ‘Mitigation agreements reached between [that developer] and Apple reviewers are not always communicated to the next reviewer, which can lead to rejections on the same grounds that [the developer] has already addressed with other Apple reviewers or a different interpretation as to whether [the developer] is compliant’

• Apple changed its requirements (either changing the guidelines or its interpretation of particular guidelines) with limited or no notice, requiring the developer to make rapid changes to their app in order for updates to be accepted. For example, [one gaming app developer] told us that when Apple released the iPhone X, it had to make adjustments to all of its games to account for the different screen shape. According to [the developer], failure to adhere to Apple’s new requirements could have resulted in its games being rejected and, given the speed with which Apple devices are announced and released, it had very little time to comply and optimise its games

A related concern flagged by many developers was that their apps had been rejected for things that Apple appeared to permit in other apps, or even in its own services. [One developer], for example, found that Apple objected to it [REDACTED]. However, [the developer] told us it ‘believes that there are apps with similar functionality available on the App Store, for example [REDACTED]’. Relatedly, a number of developers who offered subscriptions or free trials found that Apple objected to their presentation of these offers, despite these designs being very similar to or even directly modelled on Apple’s own merchandising for its subscription services.

Raising these inconsistencies with Apple did not necessarily help developers’ attempts to get their app updates onto the store. In 2 cases, developers reported Apple telling them that its decisions regarding other apps were ‘irrelevant’ or that they should not compare their app functionality to other apps. Another developer told us that when it appealed an Apple decision on its subscription offering using screenshots of Apple’s own equivalent subscription offering, through the appeal process ‘Apple made clear that it did not hold its own proprietary apps to the same standard as third-party apps.’

Where developers had concerns with the app review process, they did not tend to view the appeal process as providing a solution to those concerns. While some developers had used the appeal process successfully to gain a better understanding of the reasons for an initially unclear rejection and in some cases ultimately to gain approval for their apps, others found that the appeals process was similarly opaque to the initial review. Some developers pointed out that the fact that the appeal review is conducted by another team of Apple employees means there is no guarantee that the review is conducted in a fair and objective manner – one gave the view that this process ‘merely enables Apple to mark its own homework’. Figures provided by Apple show that [10% to 20%] of appeals resulted in Apple changing its original decision.^{[footnote 443]}

Another developer said that it is hesitant to use the formal appeal process because of the risk of leaving the proposed app release ‘in limbo’ for a long period of time, and that it prefers to use more informal channels or escalate to other points of contact within Apple to resolve issues. A number of large developers referred to escalating issues outside of the formal app review and appeal process this way – a recourse to which smaller developers would not necessarily have access.

The effectiveness of the appeal process may also be hampered by the lack of documentation provided by Apple in the app review process. Basecamp told us that in its experience as of summer 2021, Apple escalated any potentially contentious conversations during the app review process to phone calls, and that when Apple considered that issues had been resolved it made all written correspondence from the Apple Developer portal unavailable to the app developer. In combination, these practices made it difficult for Basecamp to create a paper trail of Apple’s rulings. Similarly, eBay told us that Apple’s appeals portal ‘appears to erase historical conversations between eBay and Apple reviewers, making it difficult to escalate or call back to earlier statements’.

Apple confirmed to us that after a new version of an app is approved, previous correspondence is removed as ‘all issues have been resolved’, although it noted that developers can retain copies of correspondence by taking screenshots. It also told us that changes in October 2021 to its App Store submission process would result in correspondence being visible for a longer period of time (covering the last 10 submissions for the last 180 days, and, if the last App Store app binary submission in the former system was a rejection, that submission until that app version is approved).^{[footnote 444]}

We note that various aspects of the app review process discussed above would fall under the European Union’s Platform to Business (P2B) Regulation.^{[footnote 445]} The P2B Regulation imposes on online intermediation services (which includes app stores) transparency obligations to, among other things, ensure business users (ie app developers) are given sufficient notice of any changes to the provider’s terms and conditions, set out the considerations for any differential treatment the provider might give to its own products and services compared to those of developers, and to inform developers at or before the point they are delisted, suspended or terminated from the service (and the reasons why). Apple told us that it complies with the P2B Regulation insofar as it applies to the App Store. We have not assessed Apple’s specific compliance with the P2B Regulation. It is primarily for app developers, where they consider that Apple (or Google, in respect of the Play Store) has failed to meet the Regulation’s requirements, to make use of available internal complaints or mediation mechanisms or to bring proceedings before court to recover any losses.

In general, app developers appear to have faced fewer issues with Google’s app review process for the Play Store. Many developers told us that Google’s app review process is less onerous than Apple’s, with Google providing more clarity on reasons for rejection and being more willing to engage with developers to resolve any issues identified.

However, some app developers said that they faced at least some similar issues with Google’s app review as with Apple’s, including unclear reasons for rejection, changing enforcement of rules, and rules being open to interpretation. One small developer told us it had faced repeated issues with Google taking down its app and only providing unclear automated or standard responses messages, whereas Apple provided greater clarity.

There were also concerns that Google’s review process could become more like Apple’s. One developer pointed out that, although in practice Google’s process was currently less restrictive, ‘Google’s control and sole discretion over the Google App Review Process poses the same kinds of potential issues as the Apple App Store’s Review Process.’ Another developer indicated that Google was ‘following Apple’s lead’ and becoming more restrictive in its management of the Play Store.

Potential harm to competition

We consider that the issues regarding the app review process outlined above could result in Apple and Google giving preferential treatment to their own apps, but are also liable to hinder innovation by app developers more broadly.

There are a number of ways in which the app review process could allow Apple or Google to advantage their own apps over those of rivals:

• first, Apple or Google could advantage their own apps by delaying rivals’ app updates or making these updates more difficult. In this regard, Spotify alleged that Apple has ‘constantly sought opportunities to re-interpret [the guidelines’] meaning to restrict its rivals’ conduct’ and that since May 2016 it has ‘rejected the Spotify iOS app for newly invented, pretextual reasons at the start of nearly every promotional campaign season’

• second, even if the review process does not specifically target competitors, if it creates general uncertainty and delay for all third-party apps going through the app review process then Apple’s and Google’s apps still have an advantage in that they do not face these same costs. One developer explained that ‘Delays, or even the risk of delays, upsets our planning processes, can have revenue implications to our business and is detrimental to our users. Because Apple’s first-party apps do not have to undergo the same review process, Apple does not face this cost or uncertainty for its own competing apps’

• finally, the review process may give Apple and Google advance notice of new features being developed by their competitors. This is a concern raised by [an app developer who competes with Apple], who told us that it was ‘concerned about the level of information provided to Apple in the app review process’ and that ‘Apple could use the app review process to create a competitive disadvantage to [the developer] by delaying release of the app or copying [the app’s] new features’. This topic is discussed further in the section on collection and use of commercially sensitive data below

Further, ambiguity in the guidelines, inconsistent enforcement, and the delays created by the review process create the risk that development work on new features for apps could be wasted – this has the direct effect of denying consumers access to potentially valuable features that are discarded in order to pass the app review process, as well as the indirect effect of deterring development of these features in the first place. [One app developer], for example, expressed the concern in the context of app updates that each time Apple rejected its app it caused significant disruption to the developer’s business, as it created a challenge that was costly for the company, and required employees from across the company to triage, respond, and cure any of Apple’s concerns. The rejection of updates to the developer’s app for ‘opaque or seemingly arbitrary reasons’ and the associated delays in launching updates made it harder for the developer to compete, innovate, and comply with regulatory obligations.

Preliminary conclusions

Our preliminary view is that Apple’s operation of the app review process for the App Store, in particular its inconsistent interpretation of rules and lack of clear explanation of reasons for rejections, creates uncertainty, costs and delays for app developers. This in turn is liable to hinder innovation and may be used to the advantage of Apple’s own apps. We do not see any reason that such concerns should necessarily arise from an app review process aimed at ensuring quality and security. It does not appear that Google’s operation of the app review process for the Play Store currently gives rise to the same level of concerns, but we note the concerns by some developers that Google has the ability to act in the same way and may on some occasions carry out its app review process in a way that gives rise to the concerns outlined above.

Pre-installation and defaults

As discussed in Competition in the distribution of native apps, Apple and Android devices come with a number of ‘pre-installed’ apps, which means that a device can be used ‘straight out of the box’ with a set of core software and functionalities. Pre-installed apps are also sometimes set as default apps, which means that users can activate that app when they instigate a particular functionality on their device.

Below we examine how the pre-installation of Apple’s and Google’s first-party apps and, in some circumstances, setting these apps as defaults may affect user behaviour, thus influencing competition between different apps. The effects of these practices on competition between browsers and search engines have been discussed in more detail in Competition in the supply of mobile browsers.

Pre-installation and defaults on iOS and Android

Apple pre-installs a number of its own apps on iOS devices. The number of pre-installed apps, including the App Store, on Apple’s iPhones has increased significantly from 14 in 2007 to up to 40 in 2020. Apple does not pre-install third-party apps.^{[footnote 446]}

As discussed in more detail in Competition in the supply of mobile devices and operating systems and Appendix E on Google’s agreements with device manufacturers and app developers, a collection of some of Google’s most popular proprietary apps and APIs is made available for Android device manufacturers through the GMS suite, which is licensed in the UK under the EMADA.^{[footnote 447]} Manufacturers who enter into the EMADA are required to pre-install the full suite of apps on their devices.^{[footnote 448]}. Google Chrome and the Google Search app are licensed under separate agreements.^{[footnote 449]} The minimum number of Google apps required to be pre-installed has varied over time. In addition, Android phone manufacturers remain free to preload their own apps, including app stores, as well as other third-party apps, such as Facebook or Twitter.^{[footnote 450]}

Some of these apps are also set as defaults, which simplifies execution of a particular task. For example, if an iOS user receives a text in Messages or an email in Mail with a phone number, tapping on it will initiate a call in the Phone app or bring up the Contacts app to store that information. At present, Apple allows a user to change the default setting for the web browser (ie from Safari to another browser) and the mail client (ie from Mail to another mail client) only.^{[footnote 451]}

Google told us that it does not require manufacturers under the terms of the EMADA to set any of its apps distributed under EMADA as defaults.^{[footnote 452]} Nor does Google require the default status for Google Search or Chrome, which are licensed under separate agreements. However, device manufacturers can also enter into separate RSAs with Google (as explained in more detail in Competition in the supply of mobile devices and operating systems and Appendix E), pursuant to which Google shares a proportion of its revenues with manufacturers if they meet certain [promotional requirements (for example, default settings)].^{[footnote 453]}

Potential harm from pre-installation and default settings

Apple and Google submitted that users expect their phones to provide certain functionalities, such as allowing them to make a phone call, browse the internet or send a text message, as soon as they are set up.^{[footnote 454]} Pre-installation allows them to deliver fully functioning devices straight out of the box and also differentiate their devices from other competitors. Similarly, defaults allow users to experience a seamless, uninterrupted integration of different apps and services.

On the other hand, pre-installation can give Apple’s and Google’s first-party apps considerable advantages relative to third-party apps. Pre-installation makes Apple’s and Google’s own apps more easily discoverable and may shelter them from competition from third-party apps, which users need to actively search for and download. In particular, pre-installation may reduce user willingness to search for alternative third-party apps, particularly if the pre-installed app is functioning well.^{[footnote 455]} This may be less of an issue for well-known apps but may represent greater barriers to lesser-known apps which rely on search to be discovered.

[Various surveys provided to us] also give support that pre-installation and default settings can affect user behaviour, indicating that a not-insignificant proportion of Android phone users choose not to look for alternatives to pre-installed apps. While none of these surveys explain the reasons behind users’ choice not to download new apps or make other changes, we consider that at least some of these could be directly attributed to the effects of pre-installation. Several app developers also expressed concerns that pre-installation and defaults, in particular in the case of iOS devices, may confer a competitive advantage on first-party apps.

On the other hand, survey evidence [that we received] also indicates that the majority of users across different jurisdictions have deleted or disabled unused apps and, if needed, downloaded third-party apps of their choice to use instead. This indicates that the effects of pre-installation may be stronger for some app categories than others.

Our analysis of the 100 most popular third-party apps on each of Apple’s App Store and Google’s Play Store in 2020 in the UK has shown that around one fifth of them were competing against an Apple or Google app that had been pre-installed, although the number of apps competing with pre-installed Apple’s and Google’s apps varied across different app categories. With respect to Android devices, this also includes pre-installed third-party apps, indicating that device manufacturers continue to also pre-install apps that compete with those of Google. This analysis suggests that third-party apps which compete with pre-installed apps can also be successful, and that the effects of pre-installation of first-party apps are not insurmountable. In line with this, a number of documents submitted by Google, suggest that some pre-installed apps will be more successful than others.^{[footnote 456]}

While this shows that the effects of pre-installation can vary across app categories, we also note that neither the documents submitted by Google nor our analysis discussed above distinguish between the direct effects of pre-installation and other reasons contributing to the success of a particular app, and, therefore, significant weight cannot be attributed to them. We will consider undertaking further analysis to directly assess the effects of pre-installation in the second half of the market study.

The choice architecture designed into operating systems is also relevant. As discussed in more detail in Competition in the supply of mobile browsers, pre-set defaults have been shown to have a significant impact on user behaviour, influencing decision making across a range of behaviours. Default settings may exacerbate the negative effects of pre-installation, particularly where default settings cannot be changed or changing them is difficult. In such cases, default settings can confer additional functionalities to pre-installed apps, such as integrating them with other apps and the voice assistant,^{[footnote 457]} thus making them technically superior to third-party apps without access to such functionalities, in a similar way that APIs confer additional functionalities to apps with access to them (see the section above on access to device hardware and software for more detail).

We have seen that changing defaults on Apple and Android devices involves multiple steps and requires downloading and installing an alternative app, finding the relevant option on device settings and navigating to choose the preferred app. In addition, Android users that have installed several apps with the same functionality can also choose which app to use or set as the default using disambiguation boxes, which provides a simplified way for setting a default (visit Competition in the supply of mobile browsers for more detail).

Preliminary conclusions

The convenience associated with pre-installation and defaults can bring real benefits which are valued by the users of mobile devices. We consider it likely that these benefits may be the greatest to those that are less technologically savvy and would struggle to find and install apps which would allow them to achieve their mobile device’s full potential. On Android, pre-installation can also constitute an important app distribution channel, which represents a credible alternative to app stores and other sources of app distribution, though in practice only for a relatively small number of developers.^{[footnote 458]}

However, pre-installation and defaults can distort consumer choice and could lessen the competitive constraint faced by Apple and Google from third-party apps. We consider that the negative effects of pre-installation and defaults can vary across different app categories and are likely to be stronger for certain app categories, for instance, where users exhibit greater stickiness to pre-installed apps, or where the alternatives are lesser-known apps which rely more heavily on app store search to be discovered. Browser apps are a type of service that we have identified where this can have a significant impact (visit Competition in the supply of mobile browsers for more detail), but we will consider further whether there are any other app categories where the negative effects of pre-installation and defaults may outweigh the convenience benefits conferred by them.

Even where Google does not require manufacturers to pre-install or set its apps as defaults, its agreements providing financial incentives to manufacturers to pre-install or set certain apps as defaults (as for the RSAs referred to above) may nevertheless affect third-party apps’ ability to compete with Google’s first-party apps, by reducing device manufacturers’ incentives to pre-install and set as default competing apps, even where otherwise this would have been possible. We consider that the negative effects on competition are likely to be more widespread on Apple iOS devices, which allows users to change defaults for only 2 of all the Apple apps that come pre-installed on iOS devices.

App discovery through the App Store and Play Store

Within the App Store and Play Store, apps can be discovered in multiple ways:

• App store search^{[footnote 459]} – users can search for apps using app store search functions. Both Apple and Google have developed their own app store search algorithms, which rank and display apps in response to a user’s search query – these are widely referred to as ‘organic’ results. Search queries can be further split into categorical queries, which are searches for a generic type or category of app, for example, ‘music’, and navigational queries, which are searches for a specific app, for example, ‘Spotify’

• search results may also include paid advertisements, which tend to be prominently displayed and marked as ads. On the App Store, these are usually displayed above organic search results or under the ‘Suggested’ section of the ‘Search’ tab. On the Play Store, paid ads can be displayed among organic search results as well as in other app store sections, including the ‘related apps’ section and the Play Store home page.

• Apps can also be discovered by browsing various app store sections which group apps depending on their category, for example, ‘Games’, ‘Photo & Video’, or their popularity, for example ‘Top Charts’, ‘New and Trending Apps’ and through apps being featured in prominently displayed editorial sections, for example, ‘Today’ (Apple) and ‘Editor’s choice’ (Google) which showcase apps selected by Apple’s and Google’s editorial teams

Importance of different app acquisition channels

Our analysis based on Apple’s and Google’s data has shown that search is by far the most significant driver of app downloads. As seen from Table 6.1 below, [60% to 70%] of downloads on the App Store in the UK were a result of organic search listings. App Store search ads were responsible for [0% to 5%] of downloads, followed by clicks from browsing the ‘Games’ ([0% to 5%]) and ‘Apps’ ([0% to 5%]) sections of the App Store and the editorial Today’ section ([0% to 5%]) ^{[footnote 460]}

Similarly, [60% to 70%] of downloads from Google’s Play Store came through organic search on the Play Store. Search ads led to [5% to 10%] of downloads, while browsing Play Store ‘Games’ and ‘Apps’ sections led to [5% to 10%] and [0% to 5%] of downloads, respectively.^{[footnote 461]} We note however that these figures exclude the [30% to 40%] of downloads which had no information on download source, meaning that the figures may be over- or underestimated to some extent.

Table 6.1: Source of downloads on Apple’ App Store and Google’s Play Store in the UK

Apple’s UK App Store downloads(*)		Google’s UK Play Store downloads(**)
Download source	Proportion of all UK App Store downloads	Download source	Proportion of all UK Play Store downloads
	Organic search	[60% to 70%]	Organic search	[60% to 70%]
	App referral	[20% to 30%]	Third-party referrals	[10% to 20%]
	Web referral	[10% to 20%]	Search ads	[5% to 10%]
	Search ads	[0% to 5%]	Play Store browse – Games section	[5% to 10%]
	App Store Browse – Games section	[0% to 5%]	Play Store browse – Apps section	[5% to 10%]
	App Store browse – ‘Today’ section	[0% to 5%]
	App clip	[0% to 5%]

Source: CMA analysis using Apple’s and Google’s data.

(*) Based on [REDACTED] Apple’s UK App Store downloads between June 2020 and May 2021.

(**) Based on [REDACTED] Google’s UK Play Store downloads between [REDACTED] and [REDACTED]. Excludes downloads with no source of information, which accounted for [30% to 40%] of Google’s UK Play Store downloads.

At this stage, we have not been able to differentiate between categorical and navigational queries. Google’s own analysis shows that categorical and navigational queries account for [similar proportions] of organic search queries on the Play Store. Both types of searches also led to a similar number of installs.^{[footnote 462]} By contrast, Apple submitted that [the majority] of App Store search queries are navigational, [although we note that categorical queries also represent a significant proportion of search queries].

This shows that organic search represents the most important user acquisition channel on both Apple and Google app stores, although a substantial proportion of app downloads on Google’s and, in particular, Apple’s app stores come from navigational queries, where the importance of high search rankings will be more limited. We intend to explore the importance of navigational and categorical queries further in the second half of our market study. Paid placements and app features in other app store sections, including Apple and Google’s editorial sections, were considerably less important for app discoverability, although, as discussed in more detail below, we found that editorial features were often responsible for short-term increases in app downloads.

A significant proportion of app downloads also came from outside Apple’s and Google’s respective app stores. For Apple, before the introduction of Apple’s new privacy policy (ATT), app referrals (for example, clicks from other apps, such as Facebook, Instagram and WhatsApp) accounted for [20% to 30%] of downloads on the App Store and web referrals (for example, clicks from the web, such as clicks from Google’s search engine) accounted for [10% to 20%].^{[footnote 463]} Similarly, for Google, referrals from Facebook, Google quick search, Chrome, YouTube and other sources together accounted for [10% to 20%] of Play Store downloads.^{[footnote 464]}

App store rankings: potential harm to competition

Apple and Google each told us that an app’s ranking in organic app store search results is determined by their search algorithms, which apply equally to all apps and take similar parameters into account, including text relevance of search queries, user engagement with search results, and app popularity and quality.

Both Apple and Google publish certain information on their search algorithms to assist developers.^{[footnote 465]} They also occasionally update their search algorithms and adjust the weighting of different factors taken into account. While Google publishes periodical updates on its developer blog which discuss different parameters affecting an app’s ranking as well as some changes to Play Store search algorithm, Apple told us it does not usually publish any details of the changes to its search algorithms.^{[footnote 466]}

As discussed above, organic search, through categorical or navigational queries, is the most important customer acquisition channel for app developers. Developers’ responses to our questionnaire also confirm that app discoverability via organic app store search is an important determinant of an app’s success, with the majority of developers viewing an app’s ranking as being ‘very important’ or ‘important’. We understand that high app store search ranking is generally more important in the earlier stages of an app’s life cycle, following an app’s launch, or for lesser-known apps, for whom the majority of organic searches is likely to be driven by categorical rather than navigational queries.^{[footnote 467]}

The importance of high search ranking is also supported by behavioural science research. For instance, the CMA’s 2017 literature review on online search using different digital channels (for example, search engines and price comparison websites) found that the top 3 links account for more than 70% of the total clicks on mobile devices for vertically ranked search results.^{[footnote 468]} Salience, ie consumers’ tendency to focus on the most prominent search results,^{[footnote 469]} and primacy effects, ie the tendency to click on the search results shown earlier on the list,^{[footnote 470]} are the behavioural mechanisms responsible for greater click-through rates for higher placed search results.

Given the importance of app store search to the discoverability of apps, we have considered whether Apple and Google have an ability and incentive to run their respective app stores in a way that would allow them to: (i) self-preference first-party apps; and (ii) promote discoverability of apps which follow a specific business model, such as those using Apple and Google’s proprietary in-app payment systems (and thus generate ongoing commission income for them).

Both Apple and Google submitted that they do not self-preference first-party apps and that all apps are ranked and displayed according to the same principles. However, in the past, independent investigations by the New York Times and the Wall Street Journal reported that Apple’s App Store could have systematically ranked its own apps more favourably than competing apps.^{[footnote 471]}

In response to these allegations, Apple submitted that its apps have been ranked higher inadvertently, due to the combination of high text relevance,^{[footnote 472]} user behaviour data,^{[footnote 473]} and the use of a search feature called ‘Same Developer Boost’ which was intended to highlight apps by the same developer and applied equally to Apple’s own apps and third-party apps.^{[footnote 474]} In addition, Apple used a ‘cold start boost’ to manually surface its own apps above other apps. Apple explained that the ‘cold start boost’ applied to all apps with no user engagement data, including new third-party apps and Apple’s first-party apps, to make them more easily discoverable, as otherwise they could only be found through navigational searches.^{[footnote 475]}

Until September 2021, Apple also did not allow reviews and ratings for the vast majority of its apps,^{[footnote 476]} which is likely to have limited iOS users’ ability to compare Apple’s pre-installed first-party apps with third-party alternatives.^{[footnote 477]} While Apple claimed that this would not have led to Apple’s first-party apps ranking higher, combined with the effects of pre-installation, the absence of reviews and ratings for most of Apple’s apps could have further inhibited effective competition between Apple’s apps and third-party apps.

Google submitted that an app’s monetisation model does not influence its ranking in organic search results and that apps using Google’s in-app payment systems are treated the same as other apps when determining their ranking in search results. Apple submitted that [REDACTED]. Notwithstanding this, we would nonetheless note that, as third-party transactions processed through Apple’s and Google’s in-app payment systems are subject to an average commission of [close to 30%], Apple and Google do, in our view, have the ability and financial incentive to increase the discoverability of apps on their app stores from which they extract commission.

With respect to Google, one developer told us it noticed a drop in its apps’ ratings and rankings on the Play Store and navigational searches using its brand name not resulting in its apps being ranked first, which it believed was done in retaliation for it introducing its own billing system.

As shown by the ACCC’s Digital platform services inquiry, changes in the app store search algorithms can significantly affect an app’s ranking.^{[footnote 478]} However, the vast majority of developers that we have gathered evidence from thought that they were not provided with sufficient and clear information about how an app’s ranking is determined by Apple’s and Google’s search algorithms.^{[footnote 479]} Nor were they provided with any advance notice of changes to the search algorithms by Apple and Google.^{[footnote 480]}

We have therefore also considered whether Apple’s and Google’s app development teams had access to more detailed information on their respective search algorithms, enabling them to boost search rankings of first-party apps even when Apple and Google did not engage in self-preferencing. Apple and Google told us that their internal app development teams are not given any unique information or insights into the search algorithm that could advantage Apple’s and Google’s apps in organic search results. However, it remains unclear to us at this stage to what extent the separation between their internal teams that are responsible for search algorithms and app development is actively monitored or formally enforced.

Editorial content: potential harm to competition

Apps can also be discovered by being featured in ‘Apps’ and ‘Games’ tabs as well as being showcased in dedicated editorial sections, such as ‘Editor’s choice’ (Google) and ‘Today’ (Apple). Apple’s and Google’s editorial teams hand-select apps to be featured under different categories which they consider to provide users with the best experience, focusing, in particular, on high-quality apps, new apps, and apps with significant updates.^{[footnote 481]}

Most developers that we have gathered evidence from thought they were not provided with sufficient and clear information about how apps were chosen to be featured, despite having had their apps featured as part of editorial content.

While the developers’ views on the importance of being featured in editorial content were somewhat mixed, their responses generally suggest that there is at least some positive effect of being featured by way of increased downloads immediately following the feature, although the long term effects from being featured were unclear. Similarly, some independent attempts to measure the importance of being featured also show a significant increase in downloads following the feature.^{[footnote 482]}

Although we have seen Apple’s and Google’s first-party apps and game subscription services^{[footnote 483]} being featured in their editorial and other app store sections, we do not currently have evidence to suggest that Apple or Google self-preference first-party apps when selecting which apps to feature. Apple stated that, for instance, it does not have a policy of featuring Apple Arcade games ahead of other game apps. However, one developer expressed a concern that Apple was not featuring its apps in editorial sections as they were directly competing with Apple Pay.

In addition, we consider that certain apps, particularly those choosing not to use Apple’s and Google’s proprietary payment systems, may find it more difficult to be featured in Apple’s and Google’s editorial content.^{[footnote 484]} We have seen examples of Apple and Google removing such apps from their editorial features or rejecting to feature them altogether:

• Apple discussed using ‘punitive measures’ against Netflix and ‘pulling all marketing for them’, including removing all editorial features, in response to Netflix stopping using IAP.^{[footnote 485]} Additionally, ACCC’s digital platform services inquiry found immediate and noticeable reduction in the number of Netflix’s features on Apple’s App Store despite no observable reduction in Netflix’s user ratings and user numbers^{[footnote 486]}

• one developer told us it was informed by Google that its apps could not be included in Google’s editorial content unless it switched to Google Play’s billing system from its own payment system. [The developer told us that Google had indicated] to it that Google viewed the use of alternative payment methods as a policy violation

• internationally, the ACCC’s digital platform services inquiry found that apps using Apple’s IAP were selected more than proportionately for promotion on Apple’s editorial ‘Today’ section and ‘Apps’ and ‘Games’ sections^{[footnote 487]}

Preliminary conclusions

High and consistent organic search rankings can be important to an app’s success, and unforeseen changes in app store search algorithms can significantly affect an app’s ranking, which can be disruptive to app developers. This is particularly the case for new and lesser-known apps which rely primarily on categorical searches or to whom such short-term boosts in visibility are likely to be more important. While less significant in their relative importance, features in editorial or other app store sections can also have a positive effect on an app’s discoverability.

Our current view is that Apple and Google appear to have both the ability and the incentive to give an advantage to their first-party and certain third-party apps in search rankings or via app features, thus potentially distorting competition in the downstream app markets. In particular, our preliminary view is that Apple and Google have an incentive to prioritise first-party apps, especially those that are monetised, or third-party apps which depend on Apple’s and Google’s proprietary in-app payment systems, as the increased use of these apps would lead to a direct financial gain. We have also seen examples of Apple’s and, less so, Google’s search algorithms or editorial content giving apparent priority to such apps, which is consistent with Apple and Google having an ability to advantage certain apps.

This may also mean that users are being shown apps on the basis that they have been developed by the app store owner or offer paid content (which uses Apple or Google’s in-app payment system), rather than other objective factors discussed above. Ultimately, this may lead to higher prices for consumers, particularly where app developers are incentivised to include in-app purchases to make their apps more easily discoverable, and may discourage innovation across apps overall.

Concerns around the ability of Apple and Google to control their search results and which apps are featured in their editorial content are further exacerbated by an apparent lack of transparency around their search algorithms, including about upcoming changes to search algorithms that may affect an app’s ranking and how Apple’s and Google’s editorial teams select apps to feature in their editorial content. However, we also note that, as explained by Google, disclosing full information about certain parameters of its search algorithm, in particular proxy signals that determine specifically how an app scores against a particular parameter, would risk developers optimising their apps to ‘game the system’.

In our assessment of potential remedies, we will take into account the need to reach a balance which allows Apple and Google to protect the integrity of their search algorithms, while at the same time ensuring there is sufficient transparency about the terms and changes to their search algorithms such that app developers can adapt to changes in a timely manner, and so that they can trust and have confidence that their apps are competing on a level playing field against those of Apple and Google.

Collection and use of commercially sensitive information

By virtue of their positions in operating systems and app distribution, both Apple and Google have access to large volumes of commercially sensitive information on the businesses of the app developers who create apps for their respective ecosystems. We have considered whether their access to this information, and the use they might make of it, may be harmful to competition.

Types of information accessible to Apple and Google

Apple and Google each have access to a variety of non-public sources of potentially commercially sensitive information on third-party app developers:

• through the app review process, Apple and Google can gain early information on new app features before they are introduced. We have heard concerns that they may also be able to use the review process to require developers to provide sensitive information as a precondition for admittance to the app store

• as a result of the requirements for certain app developers to use Apple’s and Google’s payment systems for in-app purchases, Apple and Google have access to transactional-level sales data in relation to such transactions

• through their operation of app stores, Apple and Google also have access to data on downloads and usage of all apps. Some such information is made public, such as the top download charts, but more detail is available to Apple and Google, for example the amount of time users spend on individual apps

In addition, Apple’s MFi Program – through which Apple licenses certain technologies that allow accessories to connect to Apple devices – gives Apple access to additional information on manufacturers who produce these accessories. In some cases these manufacturers may also be app developers that produce an app that interoperates with their products. Participants in the MFi Program must provide Apple with product plans before producing new products, giving Apple advanced access to information on unreleased products. Apple told us that it restricts access to the business data provided by MFi Licensees to the MFi Program, limiting its use to purposes intended for the MFi Program.

The collection of some or all of this information may be necessary for Apple and Google to operate their app stores (and in Apple’s case its MFi Program) effectively. However, Apple and Google’s agreements with developers do not include any express restrictions on how Apple and Google may use the information they gather from developers. Apple’s Developer Licence Agreement even explicitly disclaims any confidentiality obligations over information that Apple collects from developers and gives Apple permission to use this information on an ‘unrestricted basis’.^{[footnote 489]}

Potential harm to competition

One way that Apple and Google could in principle use the information received through the above processes to inform the development of their own apps. For example:

• by using data from their app stores to identify fast-growing or successful apps, Apple and Google are able to choose to develop apps similar to those that have proven to be popular and valuable to users
• the development of apps by Apple or Google could also be facilitated by using the app review process as well as discussions with developers in the context of determining editorial content for the App Store and Play Store to gain detailed information on how these products work
• insights from transactional data from in-app payments could be used to determine the pricing model for new products

Another potential way that Apple and Google might be able to use this information would be to advantage their apps in markets where they are already active. In particular, Apple and Google may be able to use rivals’ data to optimise their own pricing and marketing strategies and to target customers.

We recognise that there are likely to be benefits to consumers in the short term of Apple and Google developing products which compete in downstream markets, as this may in the first instance bring about more choice or higher quality products, particularly if they can integrate these products with their devices or operating systems in a way that third parties would not feasibly be able to.^{[footnote 490]}

However, if app developers believe that Apple or Google will use their confidential information to compete against them, this could undermine their incentives to invest in developing innovative apps. App developers’ incentives to innovate would be particularly affected if other practices by Apple or Google make it harder for them to benefit from their innovations:

• if Apple or Google self-preference after entry, this could undermine the original innovator’s first-mover advantage and significantly reduce their ability to continue to make profits from their innovation, compared to a situation in which a third-party competitor entered the market. This would also reduce the benefits to consumers from new entry, as rather than needing to offer a better product to compete with the original innovator, Apple or Google could rely on the advantages they gain from control over their platforms to ensure success
• Apple’s and Google’s power over app developers may allow them to require developers to relinquish or weaken their intellectual property rights as a pre-condition for launching their products

Apple’s use of information

In our assessment of potential remedies, we will take into account the need to reach a balance which allows Apple and Google to protect the integrity of their search algorithms, while at the same time ensuring there is sufficient transparency about the terms and changes to their search algorithms such that app developers can adapt to changes in a timely manner, and so that they can trust and have confidence that their apps are competing on a level playing field against those of Apple and Google.

Collection and use of commercially sensitive information

By virtue of their positions in operating systems and app distribution, both Apple and Google have access to large volumes of commercially sensitive information on the businesses of the app developers who create apps for their respective ecosystems. We have considered whether their access to this information, and the use they might make of it, may be harmful to competition.

Types of information accessible to Apple and Google

Apple and Google each have access to a variety of non-public sources of potentially commercially sensitive information on third-party app developers:

• Through the app review process, Apple and Google can gain early information on new app features before they are introduced. We have heard concerns that they may also be able to use the review process to require developers to provide sensitive information as a precondition for admittance to the app store.

• As a result of the requirements for certain app developers to use Apple’s and Google’s payment systems for in-app purchases, Apple and Google have access to transactional-level sales data in relation to such transactions.

• Through their operation of app stores, Apple and Google also have access to data on downloads and usage of all apps. Some such information is made public, such as the top download charts, but more detail is available to Apple and Google, for example the amount of time users spend on individual apps.

In addition, Apple’s MFi Program – through which Apple licenses certain technologies that allow accessories to connect to Apple devices – gives Apple access to additional information on manufacturers who produce these accessories.^{[footnote 488]} In some cases these manufacturers may also be app developers that produce an app that interoperates with their products. Participants in the MFi Program must provide Apple with product plans before producing new products, giving Apple advanced access to information on unreleased products. Apple told us that it restricts access to the business data provided by MFi Licensees to the MFi Program, limiting its use to purposes intended for the MFi Program.

The collection of some or all of this information may be necessary for Apple and Google to operate their app stores (and in Apple’s case its MFi Program) effectively. However, Apple and Google’s agreements with developers do not include any express restrictions on how Apple and Google may use the information they gather from developers. Apple’s Developer Licence Agreement even explicitly disclaims any confidentiality obligations over information that Apple collects from developers and gives Apple permission to use this information on an ‘unrestricted basis’^{[footnote 489]}

Potential harm to competition

One way that Apple and Google could in principle use the information received through the above processes to inform the development of their own apps. For example:

• by using data from their app stores to identify fast-growing or successful apps, Apple and Google are able to choose to develop apps similar to those that have proven to be popular and valuable to users;

• the development of apps by Apple or Google could also be facilitated by using the app review process as well as discussions with developers in the context of determining editorial content for the App Store and Play Store to gain detailed information on how these products work; and

• insights from transactional data from in-app payments could be used to determine the pricing model for new products

Another potential way that Apple and Google might be able to use this information would be to advantage their apps in markets where they are already active. In particular, Apple and Google may be able to use rivals’ data to optimise their own pricing and marketing strategies and to target customers.

We recognise that there are likely to be benefits to consumers in the short term of Apple and Google developing products which compete in downstream markets, as this may in the first instance bring about more choice or higher quality products, particularly if they can integrate these products with their devices or operating systems in a way that third parties would not feasibly be able to.^{[footnote 490]}

However, if app developers believe that Apple or Google will use their confidential information to compete against them, this could undermine their incentives to invest in developing innovative apps. App developers’ incentives to innovate would be particularly affected if other practices by Apple or Google make it harder for them to benefit from their innovations:

• if Apple or Google self-preference after entry, this could undermine the original innovator’s first-mover advantage and significantly reduce their ability to continue to make profits from their innovation, compared to a situation in which a third-party competitor entered the market. This would also reduce the benefits to consumers from new entry, as rather than needing to offer a better product to compete with the original innovator, Apple or Google could rely on the advantages they gain from control over their platforms to ensure success

• Apple’s and Google’s power over app developers may allow them to require developers to relinquish or weaken their intellectual property rights as a pre-condition for launching their products

Apple’s use of information

A number of app developers and respondents to our statement of scope raised concerns about Apple in particular using its privileged access to information to imitate other successful products. These respondents indicated that this was a common practice by Apple which had affected a large number of third-party app developers. Several referred to reports in the Washington Post which included statements by Philip Shoemaker, Apple’s former director of App Store review, that data on which kinds of apps are successful was shared widely among Apple leaders and could be used to inform product development.^{[footnote 491]}

Masimo and Tile, both companies which produce products which are compatible with Apple devices as well as iOS apps to interact with those products, claimed that Apple has access to their commercially sensitive information and can use it to develop competing products. Box 6.1 sets out the details of these claims.

Both developers raised concerns about Apple’s MFi agreement, which includes terms which allow Apple to use any information submitted by licensees to develop its own competing products, requires licensees to agree that they have no knowledge of any Apple product infringing on any of their patents and allows Apple to terminate the agreement (forcing the licensee to stop selling their products which incorporate technology licensed from Apple under the MFi Program) if the licensee commences intellectual property or patent infringement proceedings against Apple. Apple submitted that the purpose of this language was to shield against frivolous lawsuits whenever Apple happened to release a product bearing some similarity to a licensee’s licensed product, and not as a means to steal licensee information. As noted above, we consider that if developers’ intellectual property rights are undermined by agreements with Apple or Google, this would be particularly damaging to developers’ incentives to innovate.

Box 6.1: Apple’s access to commercially sensitive information - case studies

Masimo

Masimo is a medical device company which offers pulse oximetry monitors that interact with users through smartphone apps, including on iOS. In 2020, Apple began offering similar pulse oximetry functionality in its Apple Watch devices. Masimo told us that:

• prior to introducing this functionality, Apple had hired several Masimo employees, including Masimo’s Chief Medical Officer and a Chief Technology Officer from a Masimo spin-off company after a meeting with Masimo

• [REDACTED]

• Apple’s MFi Agreement [gives Apple the ability to take advantage of innovations made by those companies required to agree to it, such as Masimo]

Tile

Tile makes trackers that allow users to find lost items with the Tile app. It also developed a ‘finding network’ so that anyone with the Tile app installed and the required permissions given can help other users find lost Tile trackers even when these are outside of Bluetooth range of the owner’s device. Apple developed its own finding network in 2019 (initially only for finding Apple devices) and started selling trackers in 2021.Tile told us that:

• Apple had access to a wide range of sensitive information on Tile’s products, through the App Store but also from previous partnerships between Apple and Tile, such as a collaboration on a Siri voice assistant integration for Tile

• since launching its competing products Apple had engaged in self-preferencing, including enforcing a complex and confusing process for users to grant Tile the necessary permissions, as well as the hardware restrictions discussed above

• Apple offers access to its Find My network to third parties, but only through the MFi agreement which contains restrictive terms which would prevent Tile from competing effectively with Apple

A number of developers that compete directly with Apple’s first-party apps also raised concerns about the potential for Apple to use its access to their data to provide itself with an advantage:

• Spotify stated that it cannot be excluded that Apple might be able to use IAP data to inform its own commercial decisions about Apple Music, including by observing the success of Spotify’s different offerings and using that to inform its own offering, using data on Spotify’s performance in different countries and regions to inform its strategy for penetrating new markets, and using data on churn and the effectiveness of promotional campaigns to target Spotify’s users with competing offerings at critical points (for example, before the end of a trial period).

• [One gaming app developer] told us that Apple has unique access to data such as what games users play and apps they use, how long they play for, how much money they spend in games and in other apps’ and could use this to shape its competing Apple Arcade service

• Proton Mail said it was concerned that Apple ‘could be using commercial data which it receives through IAP to gain a competitive advantage when it comes to its own product development’ and that this ‘could give Apple superior market intelligence over its competitors or any potential competitors’

Apple told us that it does not use information from the App Store to drive its decisions on what apps to develop. It acknowledged that it, like developers, has access to ‘de-identified analytics data’ from users who opt-in to providing said data, but told us that this data is only collected and used to help developers improve their apps. Apple also stated that App Store data is not shared with Apple’s services business, and that information used by the App Store Review team is not shared with any other business units in the ordinary course of business. With regards to the statements by Mr. Shoemaker referred to above, Apple challenged the veracity of these claims and indicated that Mr. Shoemaker was never involved in the development of any Apple apps or services.

Apple also questioned the value of the information it has access to for developing new products. It told us that App Store information ‘would be of limited value in guiding Apple’s product development decisions’ as iOS (and the App Store) represents a small share of the overall mobile market, and there is publicly available information on the most downloaded or highest revenue generating apps. Regarding any advance information gained through the app review process, Apple claimed this was ‘practically of no significance to the development of competing apps’, because the app review process lasts at most just a few days, after which the app would be released and made publicly available. On this last point, we note that the experience of many app developers has been that app review can be a more protracted process if Apple has reasons to reject an app, as discussed in the section on app review processes above.

We will seek to explore further with Apple how it uses data and any safeguards it puts in place to prevent this data’s use by Apple’s app development teams.

Google’s use of information

We have not heard similar concerns from developers regarding Google’s use of sensitive information to develop new products or to give its existing products a competitive advantage, although in principle the same potential issues arise given Google’s similar access to sensitive commercial information and the apparent lack of contractual restrictions on its use of this information.

One respondent to the consultation on our statement of scope referred to reported concerns about Google’s use of data on how users interact with third-party apps (from a program known as ‘Android Lockbox’) to help advance its own apps.^{[footnote 493]} This reporting suggested that Google used this data when planning the rollout of a YouTube feature rivalling TikTok, and more broadly used it to track how Google services were performing compared to rivals.^{[footnote 494]}

Google told us that:

• it ‘does not use non-public information on the success of certain types of apps in Play to make decisions about app development’

• information gathered ‘through third-party app developers’ interactions with Play (for example, during the app review process)’ is not made available to Google’s own app development teams

• the app usage data it collects is used ‘mainly’ to improve Android and Play features

We will seek to explore further with Google how it uses this data and any safeguards it puts in place to prevent this data’s use by Google’s app development teams.

Preliminary conclusions

Through the operation of their app stores, Apple and Google have access to confidential information about rival apps that has the potential to give rise to competition concerns. This may be particularly concerning when combined with other forms of self-preferencing, or with contractual terms that undermine rival app developers’ intellectual property rights. Developers’ concerns predominantly focused on Apple’s access to such information, although the same potential issues arise in principle for Google as well.

Although in theory this information could also be used by Apple and Google to develop new products and compete more closely with rivals, they should be able to use other forms of market intelligence to develop their products, rather than relying on commercially sensitive information from developers.

As a result of Apple and Google’s market power in relation to native app distribution, we consider it appropriate to explore potential interventions that would guard against the potential misuse of such information, which help to build trust and confidence of market participants.

Contractual terms and commercial practices relating to subscriptions, refunds and cancellations

As set out in our Statement of Scope, we are currently seeking to understand the nature of the relationships between Apple, Google, third-party app developers, and consumers, and how this may affect outcomes in downstream app markets. In particular, we are considering:

• whether the terms and conditions and policies that Apple and Google require third-party app developers to follow could have any harmful consequences for consumers and competition more broadly, such as automatic renewal of subscriptions that are no longer wanted

• whether similar concerns could arise in relation to Apple’s and Google’s own services which they provide directly to consumers

• the role of Apple and Google in relation to cancellation and refund requests for services accessed via the App Store or Google Play and, whether and how, this might impact on consumers and competition more broadly

We have obtained information from Apple, Google and other interested parties and have undertaken an initial review of what has been provided so far. We are in the process of completing an analysis of this and, if necessary, may undertake further investigations around consumers’ experience of purchasing apps and the process by which they are able to obtain refunds.

We will therefore be continuing to gather evidence during the second half of the market study, which will complement our ongoing examination of how choice architecture may affect consumers’ purchasing decisions.

Practices with broader competitive implications

In this second half of the chapter, we discuss 3 sets of practices that have broader effects, either in terms of entrenching the market position of Apple and Google in app distribution, or in other markets where Apple or Google carry out related activities. The practices we consider are:

• the obligation for app developers to use Apple’s and Google’s proprietary in-app payment systems for in-app purchases

• Apple’s introduction of restrictions on how app developers may collect and use certain user data through its App Tracking Transparency (ATT) policy

• Apple’s restrictions on cloud gaming services

Apple’s and Google’s app store payment systems

The main way in which both Apple and Google monetise their app stores directly is through requirements on certain developers to use their proprietary payment systems to process in-app purchases made by users, such as paid for aps, features or content within an app, or subscriptions. Apple and Google charge a commission of up to 30% for these transactions. We have heard several complaints from developers about the effects of having to use Apple’s and Google’s payment systems, which we consider in more detail in this section. The same concerns are also being separately considered by the CMA in the context of our competition enforcement case into Apple’s App Store under the Competition Act 1998.^{[footnote 495]}

Background

Apple’s and Google’s in-app payment system rules

Both the App Store and Play Store require that certain in-app payments must be made using Apple IAP and Google Play’s billing system respectively. For transactions which are handled by Apple IAP or Google Play’s billing system, Apple and Google effectively act as the seller of the relevant in-app purchase and have the contractual link to the consumer. Payment is taken from the user by Apple or Google and then remitted to the app developer after Apple and Google have taken a commission. Apple’s and Google’s payment system rules are described in more detail in Appendix H.

Apple’s rules require that apps which offer ‘digital’ content, defined in Apple’s guidelines^{[footnote 496]} as wanting ‘to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version),’ must exclusively use Apple’s own system (‘Apple IAP’) for in-app related payments. Conversely, apps which provide physical goods and services outside of the app cannot use Apple IAP and are able to use payment service provider (PSPs), such as Paypal or Apple Pay. Payments made using Apple IAP are then subject to a 30% commission collected by Apple, except in the limited circumstances where Apple has determined that a lower commission rate of 15% will apply, as explained in Appendix H.

As set out in Appendix H, certain types of app offering digital content are not required to use IAP. Most notably, a closed group of certain app types referred to as ‘reader apps’ (specifically: magazines, newspapers, books, audio, music, and video), are permitted to ‘disable’ the IAP function. Reader apps which disable IAP cannot then sell subscriptions or in-app content via the iOS device but can provide users with access to previously purchased content or subscriptions on a ‘read-only’ basis. In addition, it is possible for apps which offer ‘multi-platform’ services (apps that work across multiple platforms, such as iOS, Android, web browser, games consoles) to sell content on one platform that can then be accessed via their iOS app. Both reader apps and those offering multi-platform services are still subject to Apple’s anti-steering rules, which are explained in the paragraph below.

In addition to the obligation to use IAP, Apple’s has ‘anti-steering’ rules which restrict all app developers offering digital apps from referring, within the app, to other ways a user could pay for digital content, such as through a website. This means, for example, that app developers are restricted from informing users who are about to purchase a subscription via IAP that there were better or cheaper alternative subscriptions available on the app developer’s website that could also be used in the iOS app.

As set out in Appendix H, Apple’s anti-steering rules previously also restricted developers from communicating with iOS users outside the app (for example, via email) about other ways to make payments outside of the app, but in October 2021 Apple’s rules were amended so that such communications are now permitted.

The rules for Google Play’s billing system are broadly similar to IAP. Google’s payment rules ^{[footnote 497]} state that Play-distributed apps ‘requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods’ (for example, digital items such as virtual currencies; subscription services; and app functionality or content such as an ad-free version of an app) must use Google Play’s billing system. Conversely, apps offering non-digital content cannot use Google Play’s billing system and must use other payment solutions. Payments made using Google Play’s billing system are then subject to a service fee, typically of 30%, but with a reduced 15% rate applied in limited circumstances.^{[footnote 498]}

The requirement to use Google Play’s billing system also has exceptions:

• all ‘Consumption only’ apps,^{[footnote 499]} which offer services available across multiple platforms, are allowed to disable Google Play’s billing system and offer users access to subscriptions or in-app content purchased on other platforms on a read-only basis. By way of contrast, as set out above Apple only permits certain categories of apps to disable IAP

• Google Play’s anti-steering rules prevent app developers from providing users, within an app, with a direct link to a webpage containing an alternate payment method. They do not prevent app developers from using other means (such as email communications) to tell Android users about alternative payment options

In some respects, Google’s rules have become more closely aligned with Apple over time. For example, Google has updated its Payments policy and from September 2021 (or March 2022 for some granted an extension) all developers selling digital goods in their apps will be required to (solely) use Google Play’s billing system (and pay a service fee from a percentage of the purchase).^{[footnote 500]} Some parties told us that, prior to this update taking effect, some apps have given Android users alternative payment options for in-app purchases in addition to Google Play’s billing system, but after the updates to the policy have taken effect, they will only be able to use Google Play’s billing system. This may partly explain why fewer app developers in general have to date complained about Google’s payment rules.

How different app monetisation models are affected by in-app purchase rules

As noted above, only apps which offer ‘digital’ content consumed within the app, such as mobile games, are required to use Apple and Google’s payment systems. Apps which are used as a distribution channel for ‘physical’ products or services consumed outside the app, such as eCommerce or travel, cannot use Apple’s and Google’s in-app payment systems and do not pay the commission.

Some app developers have told us that the distinction between ‘digital’ and ‘physical’ is not always clear. For example, [one developer] has submitted that [REDACTED] are considered as ‘digital’ and are obliged to use Apple IAP, while apps that offer what is, in [one developer’s] view, a similar function, such as Uber, can use their own payment solution as the transaction is considered by Apple to be ‘physical’. [The developer] submits that in both cases the actual service is consumed outside the app while the actual transaction of connecting 2 users occurs within the app.

For apps that do offer ‘digital’ content, only apps that directly monetise content within the app are affected. This includes:

• paid apps, which require a one-off upfront payment to download and use the app
• subscription-funded apps, which require users to sign up to a rolling subscription to access the app
• apps offering paid in-app content, which require users to make in-app payments to access specific additional content or functionality

Wholly ‘ad-funded’ apps, which are offered to users for free and then funded by the sale of advertising inventory shown to users within the app, do not use Apple and Google’s payment systems and do not pay a commission to Apple or Google.

Apple’s and Google’s app store revenues are derived from a small proportion of apps. To assess revenue concentration the CMA considered the proportion of apps that accounted for 90% of the commissions received by Apple. This was [less than 5%] in the UK in 2020. Similarly, in the same period, [less than 5%] of the apps using Google Play’s billing system accounted for 90% of the total service fee revenue on apps (including Play pass) received by Google.

Figures 6.2 and 6.3 below show the distribution of Apple and Google’s app store net revenues^{[footnote 501]} across category of app.

Figure 6.2: Apple IAP net revenue by category in 2020

Figure description: A stacked bar chart showing the distribution of Apple’s retained revenues from IAP across different app categories and split between app downloads, in-app purchases and subscriptions. Ganes is shown as the largest bar followed by the music, entertainment and sports category.

Source: CMA analysis of CMA analysis of Apple’s data.

Notes: Apple categories have been grouped by the CMA for illustrative purposes as follows: Business, productivity: Business, Finance, Productivity; Education: Education; Food, shopping, travel: Food & Drink, Shopping, Travel; Games: Games; Health, fitness, medical: Health & Fitness, Medical; Lifestyle, social: Lifestyle, Social Networking; Music, entertainment, sports: Entertainment, Music, Photo & Video, Sports; News, books, design: Books, Developer Tools, Graphics & Design, Magazines & Newspapers, News, Stickers; Utilities: Navigation, Reference, Utilities, Weather

Figure 6.3: Google Play's billing system revenue by category

Figure description: A stacked bar chart showing the distribution of Google’s retained revenues from Google Play’s billing system across different app categories and split between app downloads, in-app purchases and subscriptions. Games is shown as the largest bar followed by the lifestyle and social category.

Source: CMA analysis of Google’s data.

Notes: Google categories have been grouped by the CMA for illustrative purposes as follows: Business, productivity: Business, Finance, Productivity; Education: Education, Parenting; Food, shopping, travel: Food & Drink, Shopping, Travel & Local; Games: Games; Health, fitness, medical: Health & Fitness, Medical; Lifestyle, social: Beauty, Communication, Dating, Events, Lifestyle, Social; Music, entertainment, sports: Entertainment, Media & Video, Music & Audio, Sports, Video Players; News, books, design: Art & Design, Books & Reference, Comics, News & Magazines, Personalization, Photography; Utilities: Auto & Vehicles, House & Home, Libraries & Demo, Maps & Navigation, Tools, Transportation, Weather

App store revenues are concentrated in mobile gaming, which, in the UK in 2020, accounted for [over half] of Apple IAP revenues and [over half] of Google Play’s billing system revenues on apps (including Play pass). The majority of Apple’s and Google’s app store revenues are derived from payments for one-off in-app features or content, such as a particular item purchased within a game experience. The remaining app distribution revenues are derived largely from subscriptions.

Apple’s and Google’s rationale for app store payment rules

Collection of commission

Both Apple and Google argue that the obligation to use their payment systems is necessary for them to collect commission for the sales that developers make as a result of distributing apps through Apple and Google’s app stores. For example, Apple submitted that the commission that it charges on in-app payments is not a fee for using IAP, but that the requirement to use IAP is so that it can collect a commission on eligible developer sales to iOS users. Apple submitted that the commission supports the overall App Store infrastructure and ecosystem, which facilitates the plethora of functions (including technology, customer connection and customer trust) that must be in place to lead to an in-app purchase in the first place.

Google also submitted that its payment policy enables the Play Store to collect its service fee in a way that aligns Google’s success with developer success, since Google makes money only when developers of certain apps successfully sell their apps, in-app content, or subscriptions to users.

Both Apple and Google argue that requiring that certain apps use their payment systems is the most efficient way for them to charge a commission and recoup the investments they have made in relation to their app stores:

• Apple submitted that if developers did not use IAP to process their in-app sales, Apple would have no effective way of tracking when transactions that are subject to its commission take place, or of calculating and collecting the money it is owed by hundreds of thousands of developers on those sales
• Google submitted that if it was no longer able to collect fees by requiring developers to use Google Play’s billing system, and instead required third parties to report their revenues and pay an invoice for 15% or 30% thereof, there would be scope for abuse and fraud, potentially giving rise to audits, disputes and litigation

Apple has argued that its IAP-related guidelines and rules are not unique to Apple but are in line with the business models and rules of many other digital marketplaces.^{[footnote 502]}

However, [one developer] has argued that there are viable alternative methods, commonly used elsewhere, which would enable the app store provider to obtain fair compensation. For example, Apple or Google could allow developers to use their own payment solutions and then report transactions made through these payment systems at regular intervals. [The developer] noted that similar reporting obligations (accompanied with audit rights) are standard practice when it comes to calculating royalties for IP licensing. Alternatively, or in addition, the app store provider could be notified in near real-time whenever a transaction takes place via a third-party payment system through the use of an API, in a similar way to those currently used by Apple to inform developers when transactions are carried out through Apple IAP.

We note that, in response to recent legislative changes in the country^{[footnote 503]}, Google has recently announced^{[footnote 504]} that in South Korea, developers will from 18 December 2021 be able to add an alternative in-app payment option, alongside Google Play’s billing system, for their mobile and tablet users.^{[footnote 505]} In this announcement Google states that it still intends to collect its commission from developers who sell digital content, but will deduct 4% when a user selects a developer’s alternative in-app billing system, to account for the developer’s costs in supporting it. This suggests that Google has found a technical solution that enables it to track in-app transactions where a third-party payment system is used, in order to collect its commission. We will seek to understand further the scope, details and impact of these changes in the second half of our study.

As noted in Competition in the distribution of native apps above, a requirement to use a platform’s payment system for in-app purchases for some digital goods is not unique to Apple and Google; the Xbox Store for Consoles, Steam and the Amazon App Store also require users to use the platform’s proprietary payment system for in-app purchases. Some other platforms do not implement such restrictions. The Epic Games Store, Samsung Galaxy Store and Microsoft Store for Windows offer their proprietary payment systems for in-app purchases but do not mandate the use of such systems.

Although Apple has referred to other platforms where use of a payment system operated by the platform owner is mandated, a simple comparison of requirements against other platforms is not necessarily informative. First, the rules of some platform owners are stricter than others in terms of the extent to which their payment systems are required to be used. Further and in any event, the lack of competition faced by Apple and Google’s app stores means that their restrictions on the use of alternative payment options are of particular concern, for the reasons set out further below.

User benefits

Both Apple and Google argue that use of their payment systems also results in user benefits, in that they provide users with a convenient and secure way of buying and managing digital content from third-party developers. For example, Apple submitted that IAP allows an iOS user to buy digital content within the app on an Apple device using the payment credentials the user has already registered with Apple and with the convenience of a few clicks. It said that this gives users of iOS devices a seamless, frictionless and safe way to buy digital content from third-party developers through the App Store. Apple further submitted that IAP provides the following benefits and features: Family Sharing and Ask to Buy;^{[footnote 506]} clear and conspicuous pricing;^{[footnote 507]} biometric authentication;^{[footnote 508]} email receipts and purchase history;^{[footnote 509]} Report a Problem and refunds;^{[footnote 510]} restore purchase;^{[footnote 511]} manage and cancel subscriptions;^{[footnote 512]} fraud prevention^{[footnote 513]}.

Apple’s and Google’s app store payment systems may be uniquely well-placed to deliver some of these benefits, particularly those which are connected to overall usage of the mobile device. The convenience of being able to use a single set of payment details and deal with a single trusted point of contact for payments appears to be an important benefit on which certain users may place significant value. In addition, app developers are also likely to indirectly benefit from users having greater confidence in placing transactions through Apple and Google’s app stores.

However, as noted further below, many user benefits can also be provided by alternative payment solutions. We note that non-digital apps are prohibited from using Apple’s and Google’s payment systems and are able to nevertheless process in-app transactions with little apparent negative consequence. Further, as we set out further below, the evidence from app developers discussed below suggests that alternative payment systems offer users several benefits that Apple’s and Google’s payment systems currently do not, such as greater flexibility in the pricing structures and payment methods offered to consumers and the ability to manage refunds directly.

Application of restrictions to apps selling digital content

Apple and Google submit similar reasons for why apps offering physical goods and services do not need to use their payments system.

Apple submitted that the primary reason why IAP does not apply to apps offering physical goods and services is because Apple ‘lacks the ability to verify the delivery of physical goods and services to the customer when performance of the transaction between the app developer and the user takes place outside of the device.’ Apple further submitted that the need to comply with consumer legislation, including product liability rules, as well as local tax codes across the 175 countries where the App Store is present would increase the complexity, expense and transactional risk to the App Store business.

Google submitted that ‘sales of physical goods or services present unique challenges. The sale of physical goods or services present potential liability concerns.’ Google further submitted that it is not able to track whether a transaction relating to physical goods has been fulfilled and so cannot provide the same level of developer support for the sale of physical goods and services, for example in minimising refund abuse, compared to digital goods and services.

While Apple and Google did not submit this as part of their rationale for only requiring apps that sell digital content to use their payment systems, some other stakeholders have speculated that Apple and Google may not be able to charge a commission to apps that sell physical goods and services as these often have low margin business models and would be unable to pay such a commission.

Potential harm to competition resulting from in-app purchase rules

As set out in Competition in the distribution of native apps, our preliminary view is that Apple and Google have market power in relation to native app distribution. This market power allows Apple and Google unilaterally to set rules for their app stores, including requirements for certain app transactions to be processed through their own payment systems, and their ability to refer to payment options outside of the app, as referred to above.

App developers have raised several concerns about how they are affected by this. Many expressed concerns about the level of the commissions, which we considered in Competition in the distribution of native apps. In this section we have considered the following possible harms arising from the payment system rules:

• the requirements for in-app purchases to be made through Apple and Google mean that app developers cannot choose alternatives for processing payments for digital content that better meet their needs;
• the requirements for in-app purchases to be made through Apple and Google mean that developers are ‘disintermediated’ from their users in certain respects;
• the requirements for in-app purchases to be made through Apple and Google (and the commission payable to Apple and Google for these transactions) distort competition between Apple’s and Google’s own apps and rival apps;
• the requirement for in-app purchases to be made through Apple and Google make cause billing issues for users who switch between iOS and Android devices and vice versa; and
• the anti-steering rules prevent developers from informing users of the fact that there may be alternative ways to pay for content outside of an app, limiting their ability to make informed choices and drive effective competition between distribution channels.

Our assessment in the section below focuses primarily on Apple IAP, as we have received most complaints about Apple’s rules in relation to the use of Apple IAP. This may reflect the fact that certain app developers have been giving Android users alternative payment options for in-app purchases in addition to Google Play’s billing system, as explained above. As set out below, we have also considered and sought evidence from app developers on how these issues apply to Google Play’s billing system and have highlighted the similarities and differences. In addition, as noted above, Apple’s and Google’s payment system rules are developing and several changes have been announced at various points over the past year. Consequently, the evidence and views from app developers are likely to reflect this evolving picture.

Choice of payment service processor

Apple’s and Google’s rules on in-app purchase effectively combine the provision of a distribution platform to app developers through their app stores with a payment service for in-app transactions. The result of using Apple IAP and Google Play’s billing system, is that Apple and Google effectively become the direct seller for the relevant transactions.

For transactions processed via Apple IAP, Apple becomes the ‘merchant of record’ for the transaction. Apple uses third-party acquirers to assist in processing payments facilitated by IAP.

Google is similarly the ‘merchant of record’ for transactions made via Google Play’s billing system^{[footnote 514]} but uses third-party processors and acquirers for the processing and front-line collection of funds.

A key impact of this is that app developers cannot use other third-party options for the processing of in-app payments. In the absence of Apple’s and Google’s payment system requirements, app developers would be able to choose third parties referred to as ‘payment service providers’ or PSPs (such as Adyen, PayPal and Stripe) to process in-app payments, which would mean that: (i) an app developer could choose to act as the direct seller for the payment transaction, with a third-party PSP processing the transaction on their behalf; and (ii) app developers would benefit from greater competition between PSPs to provide them services in relation to in-app transactions. Such services might include both the services required to process payments, for example via the card networks, or through other means such as carrier billing, and various other software services to collect the payment at the point of sale and detect fraud and analyse transaction data.

Most of the large app developers that responsed to our requests for information have suggested that Apple’s and Google’s payment systems are in various ways limited compared to the alternative payment solutions available from PSPs. Almost all developers submitted that they would not use Apple’s or Google’s payment systems if they were not required to. Some highlighted the difference in commission between Apple’s and Google’s systems and third-party PSPs as the main reason. However, many stated that the alternative payment solutions they used elsewhere were preferable, irrespective of the commission, as they offered greater flexibility and functionality and enabled the developer to offer a more consistent user experience across platforms.

For example, several app developers told us that use of Apple IAP means they are denied various aspects of pricing flexibility that would be available if they contracted with a third-party PSP:

• Apple requires that developers choose among pre-defined price tiers, limiting the precision with which developers are able to price their products and, in some cases, resulting in pricing discrepancies across different channels. In addition, tiers are fixed across currencies which forces developers to use the implied exchange rates set by Apple.
• Developers are limited in how they can offer bundled app subscriptions (in other words subscriptions to multiple apps offered together for a discount). Similarly, app developers are unable to offer additional paid features or promotions to existing subscribers or extend the length of free trial periods.
• Apple does not allow app developers to target discounts or promotions to specific groups of users, for example by offering student discounts or discounts to users who have used a free version of an app for a specific period of time.
• Apple IAP does not support scalable license-based models which can be used by multiple users (for example for business users).
• Apple only allows a maximum of 10,000 products to be made available within an app using Apple IAP. This restricts the ability of apps with a greater number of SKUs to offer ‘a la carte’ purchases rather than subscriptions.

With respect to pricing flexibility, Apple submitted that it considers the options available to developers are very flexible and provide developers with considerable choice and freedom to determine their own business offerings and that it is constantly engaging with users and developers to make improvements to the App Store. For example, Apple has recently announced plans to expand the number of price points available to developers for subscriptions^{[footnote 515]} and has recently launched subscription offer codes.

Most app developers submitted that Google Play’s billing system was similar to Apple IAP with respect to the pricing flexibility allowed, when it is required to be used. Some responded that they were currently required to use Apple IAP and not Google Play’s billing system, but that this was anticipated to change when Google more strictly enforces its rules in March 2022. A few noted relatively minor differences in the flexibility offered by Google compared to Apple. For example, one developer responded that Google provides a more robust and flexible set of tools and functionality than Apple to manage aspects of IAP processing, for example, providing developers more flexibility than Apple in setting and adjusting tax rates.

Several app developers also submitted that use of Apple IAP deprives developers of the ability to offer users certain payment options. For example, some highlighted that Apple IAP does not support carrier billing. One app developer responded that it is prevented from using alternative payment methods and that it is also required to adopt Apple’s grace periods of 60 days over its own shorter defaults, increasing the potential for fraud (as customers remain entitled to the benefits, they purchased during this grace period). 2 developers submitted that the obligation to use Apple IAP prevented developers from being able to provide an alternative in the event that IAP malfunctions, as one alleged had happened frequently in the past.

The requirement to use Apple’s and Google’s payment systems, rather than third-party PSPs, means that developers are less able to engage directly with users and take actions to improve transaction completion rates. One developer submitted that in the event a payment is declined, it does not know why the payment could not be processed and therefore feels it is unable to helpfully respond. We heard from one billing provider that its service could employ specific prompts to encourage users with insufficient funds to ‘top up’ as a means of improving completion rates.

Some developers also submitted that the obligation to use Apple and Google’s payment systems resulted in additional implementation costs for the developer. Some told us that implementing the promotional features that Apple IAP does support requires substantial engineering time and resources to build the necessary integrations. One developer submitted further that the impact of the coding requirements was particularly acute for its cloud-based service, as absent the IAP requirement the same code could run off-device on the server, regardless of the user’s device. In addition, some app developers submitted that separate business units are required to manage IAP payments, and the developer is unable to operate a single billing solution or its own payment infrastructure across multiple channels.

Apps that are required to use Apple’s and Google’s in-app payment systems do not have the benefit of competition between providers of payment systems. Based on the above, it appears that in the absence of the requirement to use Apple’s and Google’s systems, app developers would be able to choose, often bespoke, payment solutions that better meet their needs and those of their users, and that there would be a greater incentive for PSPs to innovate in payment solutions specifically designed for in-app payments.

Control over relationship between developers and users

As explained above, Apple and Google act as the direct seller in relation to Apple IAP and Google Play’s billing system’s transactions. This means they are responsible for key aspects of the sales process such as processing customer payments, refunds, and subscription cancellations.

Most developers we contacted who used Apple IAP responded that this made it more difficult for refund requests to be resolved effectively. For example:

• Several developers responded that Apple IAP limits the ability of developers to directly interact with customers and resolve certain service issues. This means that developers are less able to explain what has gone wrong with a purchase or how to use newly acquired content or approach customers with a special offer where the experience has not been satisfactory.
• Several developers responded that for IAP transactions, Apple does not always provide the information necessary to allow developers to reverse the purchase of content when a refund is requested or identify requests for repeated free trials. This has the potential to create incentives for refund fraud.
• Epic Games submitted that Apple has little insight into the complex IAP issues that customers present to it and so is ill-equipped to deal with refund requests itself. Epic asserted, for example, that Apple has no means of verifying claims by customers that errors in apps render their in-app purchases obsolete, and that as a result, Apple applies blanket rules for refunds which cause some customers to be treated unfairly and historically also allowed for fraudulent claims to be refunded.

Several developers also submitted that the lack of control developers had over refunds caused customer confusion as it was not clear to customers where to seek support depending on their service issue. Developers are unable to resolve issues relating to IAP transactions, such as refund requests, and would need to refer such requests to Apple. Many of these customers reportedly view transactions as occurring between them and the developer and express frustration when the developer cannot resolve their concerns.

[One app developer] submitted survey evidence (based on global rather than just UK users) which showed that only around [10% to 20%] of users on iOS reported positive satisfaction for refund requests, compared to around [70% to 80%] of users on its website or on Android (where the majority of users use the billing solution offered by the developer).

App developers also submitted that Apple IAP limits the information available to developers about their customers and thereby restricts their ability to improve their services and compete effectively. Several developers explained that using Apple IAP meant that they received limited transaction or payment data and so were unable to identify specific customers or use this information to improve their services. For example:

• Spotify submitted that Apple does not provide user-level information on cancellation and payment related errors in a timely fashion to enable it to better understand its own customers and adopt pro-competitive initiatives to win over customers;
• [one app developer] submitted that Apple does not provide it with data that could be used to customise its offers to particular users, provide a better customer experience and enhance platform safety by allowing [the developer] access to additional tools it could use to detect fraud, scammers and underage users;
• [one app developer] submitted that the way Apple has set up IAP does not allow developers to conduct A/B tests on their own users to be able to determine the appropriate price to charge in different geographies; and
• [one app developer] submitted that Apple does not provide data about the revenue generated by promotions and sales until long after the fact, and this data is often too generalised to ascertain what, if any, effect the promotion or sale has had.

Apple submitted that the App Store uses a variety of information to determine if a refund request should be approved, including consumption data^{[footnote 516]} that developers can send to the App Store in response to a refund request notification through its new Consumption API, if the customer has provided consent. In addition, when Apple receives a customer complaint, the AppleCare support team encourages the customer to communicate directly with developer. If the customer remains unsatisfied then Apple may refund the purchase. Apple subsequently sends a refund server notification to the developer, indicating the reasons for the refund.

App developer views regarding the effect of Google Play’s billing system on the relationship between developers and their customers were more mixed. Some told us that Apple and Google’s payment policies were largely the same and had the same effects, but others submitted that Google Play’s billing system allows developers greater control over cancelling subscriptions or directly issuing refunds. Some submitted that Google Play’s billing system provides transactional information at a transaction level (though the data it provides is still limited).

Overall, the evidence we have received from app developers suggests that Apple’s in-app purchase rules may make it harder for app developers to interact directly with their customers and receive valuable data necessary for them to improve their services. Google Play’s payment system may have a similar effect but there are indications that it is less restrictive in certain aspects. We recognise that some users may value the option of being able to transact with a single trusted party, such as Apple or Google. However, as discussed below, our provisional view is that it is likely that these benefits could also be achieved if users are given choice over whether to use Apple and Google’s sales systems or an alternative payment option that allows them to transact directly with developers.

Effects on competition between apps

The requirements to use Apple and Google’s payment systems also have the potential to distort downstream competition between apps. This is because these requirements affect digital apps that wish to monetise directly but do not affect other apps, such as those that have ad-funded business models or those that are operated by Apple and Google. This may put rivals to Apple and Google’s first-party apps at a competitive disadvantage. As discussed above, Apple and Google operate several apps that directly compete with app developers. Several developers that compete directly with Apple and Google’s apps have told us that being subject to the 30% commission places them at a significant disadvantage when competing with Apple and Google.

Some of these developers have chosen to absorb the cost of commission rather than pass it on to downstream customers. However, these developers then have fewer resources to invest in research and development to improve their product. Other developers have passed it on to customers, either wholly or in part. For example, it is the CMA’s understanding that Amazon Music charges customers using iOS devices a monthly subscription fee of £10.99^{[footnote 517]} (instead of the £9.99 monthly fee it charges customers subscribing using other devices^{[footnote 518]}), compared to Apple Music which is offered at £9.99 per month.^{[footnote 519]} Spotify submitted that it was forced to pass on the IAP commission in full when it was implemented in June 2014, increasing its price to £12.99 per month (again compared to Apple Music offered at £9.99 per month). In May 2016 Spotify subsequently chose to cease using IAP, becoming a Reader app under the Reader rule, though it has told us that this also negatively impacted its competitiveness against Apple.

Several developers have also suggested that their ability to compete with Apple’s and Google’s apps is also affected by the lack of control over their relationship with customers, for example in managing refunds and accessing transactional data, as described above. In addition, some developers have also raised the concern that use of their sales systems means Apple and Google have access to valuable data about app transactions, which it can use to compete with them and target which apps to develop, as discussed above in the section on the collection and use of commercially sensitive information.

In this regard, we note that the European Commission has sent a Statement of Objections to Apple expressing its preliminary view that Apple’s rules distort competition in the market for music streaming services by raising the costs of competing music streaming app developers^{[footnote 520]}.

Based on the above, our preliminary view is that the requirements to use Apple’s and Google’s payment systems (and pay the associated commission) for in-app payments on apps that compete downstream with Apple and Google – in circumstances where Apple’s and Google’s own apps do not pay a commission on equivalent in-app payments – may raise particular concerns, in light of their potential to raise the costs of their rivals and create a potential competitive disadvantage.

Impact of in-app purchase rules on ease of user switching between mobile ecosystems

Several developers have suggested that Apple’s and Google’s payment systems may make it more difficult for users to switch between iOS and Android, due to challenges in transferring subscriptions across mobile devices. This is because users may find it more difficult to access or manage subscriptions taken out through Apple IAP once they have switched to an Android device (and vice versa).

In relation to accessing subscriptions, Apple stated that, as most of the popular apps are by now available on both iOS and Android, users with paid app subscriptions can, in most cases, use the same subscription and app after switching device. Evidence from developers indicates that although developers may allow users to create log-in details which they can then use to access subscriptions and content across multiple devices, the ability of iOS subscribers to access their subscription on a different platform depends entirely on whether they choose to link their Apple ID with their newspaper/magazine account. If no such linking has taken place, the user cannot access their subscription elsewhere, as the publisher will not be able to recognise the user as an iOS subscriber. The European Publishers Council (EPC) submitted that Apple does not allow its members to require users to make this link – while members are able to prompt users, Apple requires that users are allowed to skip this step. This can cause serious problems if a user forgets that they bought the initial subscription via the app and changes phones.

Further, several developers told us that, even if an iOS subscriber has linked their account to a developer ID, allowing them to access their iOS subscription on other devices, they are still unable to upgrade, cancel, renew, or otherwise manage their subscription outside of the iOS app. This means that users must first cancel their IAP subscriptions before switching to an Android device or upgrading to a new service outside of the App Store. If they do not do so and lose access to their iOS device, it becomes more difficult for them to cancel their subscriptions or request refunds. App developers are unable to help these users because they lack the specific user data necessary to identify them as subscribers. This is one of several examples we have identified where a negative customer experience could be attributed by the user to the relevant app developer, rather than Apple or Google who set the rules of access to their ecosystem.

Apple confirmed that consumers who wish to transfer subscriptions to another provider need to cancel their current subscriptions and then re-subscribe through the other provider. Apple submitted that neither it nor Google could presume that a consumer intends to move a subscription simply due to a switch in device. Apple further submitted that it had made unsubscribing to a service extremely easy on iOS and that customers without an Apple device can obtain customer support by calling Apple Support or using iTunes software on a PC.

In addition to costs from transferring subscriptions, one developer submitted that imposing the Apple IAP requirement on iOS app developers allows Apple to retain exclusive access to consumers’ payment credentials, which enables Apple to maintain control over how, when and where those credentials are pre-filled. This means that app developers are unable to pre-fill customer payment details and re-engage customers across multiple channels. This may create unnecessary friction for users wanting to purchase content or subscriptions across alternative channels and consequently may to some extent reduce the competition faced by the App Store.

Evidence from Apple’s internal documents suggests that part of Apple’s rationale for the requirement to use its payment system may have been to make it more difficult for users to switch between devices. For example, in 2010, Apple executive Philip Schiller emailed then CEO Steve Jobs about an advertisement for a new Amazon Kindle app: ‘…the secondary message that can’t be missed is that it is easy to switch from iPhone to Android. Not fun to watch’. Steve Jobs replied: ‘What do you recommend we do? The first step might be to say that they must use our payment system for everything…’^{[footnote 521]}

With respect to switching from Android to iOS, similar issues may arise for users who have taken out subscriptions via Google Play’s billing system. However, the overall effect of use of Google Play’s billing system on switching costs appears less significant than for Apple IAP. In part this is because Google has not been as strict in enforcing that app developers use Google Play’s billing system as noted above – though this is due to change in future. In addition, other factors may make it easier to switch subscriptions from Android to iOS than from iOS to Android.

Overall, based on the above our preliminary view is that the requirement to use Apple’s and Google’s payment systems (rather than those of a third-party) may cause billing issues for users when they switch between iOS and Android devices, adding to the other switching costs discussed in Competition in the supply of mobile devices and operating systems.

Potential harm to competition resulting from anti-steering rules

As noted above, Apple’s and Google’s anti-steering rules restrict app developers from including any information or link within an app to alternative ways for making purchases ‘off app’ – for example, a link to a webpage containing a payment flow. This is particularly relevant to apps that are available on multiple platforms. Further, Apple’s rules also restricted developers from using other means (such as email communications) to tell iOS users about alternative payment options, until they were amended in October 2021.

Almost all the app developers we contacted who use Apple’s IAP and have apps available on multiple platforms have confirmed that the anti-steering rules prevent them from advertising to customers within a native app that cheaper purchase options are available outside the iOS app, such as via the developers’ website.

As a general point, the ability for users to make informed choices is important in driving effective competition between distribution channels. A possible concern is that the anti-steering rules may mean that users are unaware of alternative, possibly lower cost options for purchasing outside of an app. For example, iOS users may choose to take out subscriptions via Apple IAP because they are unaware that prices available through alternative channels are cheaper than those offered via iOS.

In relation to reader apps which have disabled Apple IAP, 2 app developers submitted that the anti-steering rules had the effect of introducing unnecessary user ‘friction’. Users of such apps may reach a ‘dead end’ as they are not able to complete transactions inside the iOS app and developers are prohibited from informing them about where they can complete transactions.

On the other hand, both Apple and Google argue that the anti-steering rules are necessary to prevent developers from deliberately encouraging customers to circumvent their payment systems at the point of purchase, after they have accessed an app and its content through their app stores. In their view, the anti-steering rules are a way of preventing other distribution channels from free riding on their investments. Apple further submits that other platforms, such as Spotify’s SoundBetter, eBay and 1stdibs.com, have similar policies.

Overall, Apple’s and Google’s anti-steering rules could serve to limit consumers from making informed and effective choices between distribution channels. We continue to assess whether these anti-steering rules are necessary to support Apple’s and Google’s incentives to make investments in their app stores and if these incentives would remain if the anti-steering rules did not apply to app developers.

Preliminary views on the impact of Apple’s and Google’s payment system restrictions

Many of the potential harms identified above could be avoided were app developers able to choose their own payments service providers and transact directly with users. Our preliminary view is that there may be viable alternative methods for Apple and Google to collect a commission for their app stores, while also allowing developers to handle payments directly which do not give rise to the potential harms to competition outlined above. For example, this may include reporting obligations (accompanied by audit rights) or the use of an API that notifies Apple and Google of transactions in real time. It is not clear that these alternatives would be prohibitively costly or challenging to implement and it would appear that both Apple and Google have the ability to effectively enforce against any requirements that they impose through the use of their app review processes.

We recognise that some users may value being able to transact with Apple and Google via their payment systems. However, our preliminary view is that it would be beneficial for users to be offered meaningful choice between use of Apple’s and Google’s payment systems and alternative payment solutions. This would allow users to express their preferences over the relative benefits offered by these alternatives and, importantly, would allow developers and users to make choices that can drive competition and innovation between payment solutions.

These issues are referred to further in Overview of potential interventions. We welcome views in response to the consultation on this interim report.

The effect of Apple’s new privacy framework on competition

This section examines the effects of Apple’s new privacy framework for apps, which is called ‘App Tracking Transparency’ (ATT).^{[footnote 522]} We assess whether and to what extent ATT undermines the current model of advertising to users of mobile devices and may benefit Apple’s own advertising services and reinforce its position in app distribution – in particular whether, by undermining user acquisition by app developers via mobile advertising, ATT might reinforce the role of the App Store as a source of discoverability for apps on iOS.

We first set out a brief explanation of the mobile advertising landscape (including Apple’s advertising services) and the changes brought about by the ATT framework, before going on to examine the extent to which this change has the potential to harm competition.

Mobile advertising landscape and changes from ATT

On mobile devices, advertisers can reach users with a variety of types of advertising through browsers, app stores and apps. We describe the mobile advertising ecosystem in more detail in Appendix I.

For app developers, mobile advertising serves 2 broad purposes:

• they can buy app install advertising to reach potential users and encourage app downloads^{[footnote 523]}
• they can sell in-app advertising within their apps to generate revenues (instead of or in addition to monetising through in-app purchases)

These are not mutually exclusive – one developer may sell in-app advertising space in the form of app install advertising for another developer. Figure 6.4 below shows examples of app install advertising and in-app advertising.

Figure 6.4: Examples of in-app and app install advertising

Figure description: Two images of iPhones showing advertising. Under the heading ‘App Install Advertising’, an iPhone with an advert for Beats Music with an ‘Install Now’ button. Under the heading ‘In-App Advertising’, an iPhone showing a pop-up advert for Wayfair with a ‘Shop Now’ button.

Source: Techlomedia and SiteProNews.

Before the introduction of ATT, app developers on iOS could access (without requesting user consent) a unique device identifier for each user that could be shared with advertising networks and used to match the same user across multiple apps – the ID for Advertisers (IDFA)^{[footnote 524] [footnote 525]}. Mobile advertising makes use of the ability to follow users and their activity across multiple apps and websites, in particular for the purposes of:

• targeting: advertisers can use information on a user’s activity to target the ads served to them
• attribution: in order to measure the effectiveness of ads, advertisers link users who click on an ad with actions that user carries out afterwards (such as downloading an app or making a purchase within an app)^{[footnote 526]}

Apple’s advertising services

While, as Apple told us, it ‘is not an advertising-based company’, it does have some advertising business which it described as ‘extremely limited’. This business, which generated 2020 revenues of approximately $[1.5 to 2] billion globally and $[150 to 200] million in the UK, is primarily made up of search ads that are served along with organic search results when users search in the App Store.^{[footnote 527]} This Apple Search Ads (ASA) service is offered exclusively to developers of apps in the App Store – in other words, Apple’s search ads are a form of app install advertising for developers distributing via the App Store.

Apple makes use of its users’ personal data for targeting its search ads. Apple told us that its advertising platform has been ‘carefully designed to adhere to Apple’s own high privacy standards’ and that its ASA offering relies on a ‘privacy-by-design’ on device solution that only uses a limited amount of first-party data to group users into segments of at least 5,000 users before ads can be displayed to them in the App Store. To group users this way, Apple uses data such as account information (for example birth year, gender, location), app and content downloads and purchases (for example from Apple Music, Apple TV, Apple Books and App Store’s app categories) and the types of news stories they read on Apple News.^{[footnote 528]} We understand that this includes data on downloads, purchases and in-app purchases for all third-party apps, segmented by App Store category.

Apple enables attribution for advertisers through its Apple Search Ads Attribution API. This allows advertisers purchasing search advertising from Apple to measure the number of app installs for the App Store and attribute them to Search Ads campaigns.

Changes introduced by ATT

App Tracking Transparency (ATT) is Apple’s new privacy framework released in April 2021. ATT is similar in its objectives to the ITP policy discussed in Competition in the supply of mobile browsers, but it is applied to apps as opposed to websites. As noted in the ICO’s recently published Commissioner’s Opinion, ATT is one of a number of initiatives that seek to address the privacy risks that online advertising poses and shift towards less intrusive tracking and profiling practices.^{[footnote 529]}

The ATT framework requires apps to show a specific prompt (the ATT prompt) to request users’ permission for the app to ‘track’ them. Without consumers opting into this prompt, developers cannot access their IDFA which as noted above is typically used to monitor users’ activity across apps.^{[footnote 530]} Apple’s App Review Guidelines also state that app developers should not engage in any other form of ‘tracking’ if users do not opt in when shown the ATT prompt.^{[footnote 531]}

Apple has provided a replacement for IDFA-based attribution and measurement in the form of SKAdNetwork, a free tool Apple makes available to developers and ad networks. Apple told us that SKAdNetwork APIs hold advertising data on-device separate from apps, ‘allowing advertising conversion measurement to be reported without users being tracked.’

However, we have heard concerns from app developers, ad networks and industry commentators that SKAdNetwork is an inferior alternative – with regards to attribution effectiveness – not only to IDFA-based attribution and measurement but also to the Apple Search Ads Attribution API Apple makes available to users of its own advertising services, as it gives developers less granular data and sends them information on conversions with a delay.

Apple offered the following definition of ‘tracking’ which it said was consistent with that of the World Wide Web Consortium (W3C):

‘Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites, or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers’.^{[footnote 532]}

We note that the W3C definition of tracking refers to users’ activity across multiple ‘distinct contexts’ and does not refer to companies. We consider that Apple’s definition, which distinguishes between collection of data within first-party and third-party properties with these distinctions seemingly based on corporate ownership, may favour large companies operating several first-party services and apps, including Apple itself.

In this regard, the joint statement of the CMA and the ICO on the relationship between competition and data protection recently highlighted specifically the risk of data protection law being interpreted by large integrated digital businesses in a way that unduly favours them over smaller, non-integrated suppliers.^{[footnote 533]} A recent opinion published by the UK Information Commissioner confirmed that ‘data protection law does not inherently favour the concept of a first party over that of a third party within the meanings web standards bodies or data categorisations given to those terms’.^{[footnote 534]}

With regard to tracking, the Information Commissioner explained that ‘from a data protection perspective, online tracking is a term that describes or refers to different processing activities, undertaken by different means, for different purposes. A variety of organisations can undertake it, from single businesses to large corporate entities. For example, a large organisation that operates multiple online services, or many smaller organisations sharing information between them’.^{[footnote 535]}

The Information Commissioner’s opinion goes on to say that, ‘in principle, online tracking can therefore be considered as processing activities involving the monitoring of individuals’ actions, especially over a period of time (including the behaviour, location or movements of individuals and their devices)’ with specific reference to this being for the purpose of offering goods and services to them, evaluating the effectiveness of services they use, and analysing or predict their personal preferences, behaviours and attitudes.^{[footnote 536]}

Based on our preliminary assessment of the issues, Apple’s own use of its users’ personal data appears to us to be no less consistent with this explanation of tracking from the ICO than that of third-party app developers.

Apple told us that what it does in terms of personalised advertising does not fall within its own definition of tracking and therefore its apps are not requested to show the ATT prompt. However, in September 2021, with the release of iOS 15, Apple introduced the Personalised Ads prompt that is presented to new users and to existing users whose device is set to Personalized Ads On upon launch of the App Store and proactively asks users to choose between allowing personalised advertising by Apple or not. Apple told us that the main reason for introducing this was to increase transparency and provide users with control over how their data is used and that Apple is ‘leading the industry, by expressly obtaining user permission to use first-party data to deliver Personalized Ads’.

Apple’s stated rationale for ATT

Apple told us ‘the goal of ATT is to empower consumers by giving them greater transparency and ability to control the sharing of their own data’ and that this policy strengthens this ability by giving users the choice, on a developer-by-developer basis, of whether to allow developers to ‘track’ them across other companies’ apps, websites, or offline properties using users’ IDFA. Apple also mentioned several stakeholders, including consumer protection associations and privacy advocates, which welcomed ATT as a positive development for the industry.^{[footnote 537]}

We share the view of the ICO that developments that empower individuals and enable them to have meaningful control over the use of their personal data can bring about positive change, both for consumers and competition more broadly. ATT has clearly introduced a greater degree of choice and control to users than they were afforded previously over whether and how their personal data is used for personalised advertising. To this extent we consider that ATT will have some benefits to consumers with regard to their privacy.

We also recognise that strong data protection and privacy is a key measure of a healthy market in the digital sector, and we have been working in close partnership with the ICO in recent years to ensure that our regulatory approaches work together to benefit the UK. As part of this, we both want to ensure that:

• people are empowered and have effective choice over the service or products they prefer, with a clear understanding of how and by whom their data will be used; and
• businesses compete on an equal footing to attract customers, with transparency in the way they operate and the provision of meaningful choice across the market.

However, it is unclear to us, based on our preliminary assessment, whether either of these conditions have been fully satisfied by the design and implementation of ATT. In particular, we are concerned that Apple has chosen a choice architecture for the ATT prompt that does not help consumers to make effective choices, in that it could unduly influence some consumers to opt out from data sharing in a way that is inconsistent with their preferences. We are also concerned that Apple is not applying the same standards to itself as to third parties when it comes to seeking opt in from consumers for personalised advertising. We discuss these concerns in more detail in the following sections.

Potential harm to competition

In this section we assess how Apple has designed the ATT framework, whether and how the ATT prompt’s design may be influencing consumers’ choice, and the framework’s effects on developers using mobile advertising for their app monetisation and user acquisition.

We then consider the following ways in which the changes brought about by ATT may harm competition and consumers by:

• unfairly advantaging Apple’s own advertising services, and particularly its search advertising business on the App Store
• increasing barriers to entry for app developers by making it more difficult to use advertising to acquire users
• making ‘ad-funded’ apps less attractive and therefore pushing developers on iOS to monetise their apps through direct purchases offered within the app for features and content; or
• protecting Apple’s market power in app distribution by undermining the use of mobile advertising as a means for app discovery

Impact of choice architecture on users’ choices to opt in

We consider the choice architecture (ie the environment in which users make choices) of the ATT choice screen to be very important because it may influence consumer decision making and thereby opt-in rates to personalised advertising. The CMA has previously discussed the choice architecture of data privacy screens, underpinning psychological mechanisms, and their potential influence on opt-in for personalised advertising within its final report of its market study into online platforms and digital advertising.^{[footnote 538]}

Apple has provided limited evidence on its rationale for the design and choice architecture of the ATT prompt, including its wording and layout such as the ranking and visual presentation of choices. Apple provided internal documents showing it has considered several versions of the prompt with different wording or choice highlighting, but it is unclear how it landed on its final choice. Apple told us that there was no user testing of the prompt, but that it had gathered feedback on the prompt from app developers and that this feedback fed into the final decision on the design of the prompt.

The ATT choice screen includes a bolded section, the text of which is set by Apple, followed by a ‘purpose string’ or byline, meaning a description of why the developer wishes to use the consumer’s data that the third-party developer can set, and finally 2 choice buttons: ‘Ask App Not to Track’ and ‘Allow’. In addition to setting the text in the purpose string, third-party developers can create pre-prompt screens that are shown to the user before the ATT prompt, which can be used by developers, for example, to explain the benefits of opting in.

We have identified several aspects of the choice architecture that we are concerned could unduly influence users to withhold consent. Figure 6.5 below displays an example of the ATT prompt and illustrates the key choice architecture features. A more detailed explanation of our concerns with the ATT choice architecture is provided in Appendix I.

Some of these key concerns are:

• Developers are barred from using the purpose string to offer incentives for opting into the ATT prompt. We discuss this issue more in depth below
• In relation to the use of the word ‘track’ in the ATT prompt, some evidence submitted to us suggests that the prompt language has limited comprehension among users
• While the prompt provides users with an active choice, the opt-out choice (‘Ask App Not to Track’) is presented first, which could influence users to opt out due to primacy effects ie a preference for the option presented first
• The customisable purpose string is in non-bold text while the non-customisable prompt above is in bold text, making it less salient or prominent to users
• However, we also note that for the developer created pre-prompt screens there are no barriers on how these are framed. For example, they can use language that the CMA has previously raised concerns about,^{[footnote 539]} such as users seeing ‘relevant ads’, to highlight the benefits of opting into the ATT framework

Figure 6.5: Choice architecture of the ATT prompt

Figure description: A screenshot of Apple’s ATT prompt with choice architecture elements labelled. The prompt, in bold, reads ‘Allow “iQIYI” to track your activity across other companies’ apps and websites?’. This is labelled as ‘ATT prompt: limited user comprehension of the word ‘track’’. There is non-bolded text below which reads ‘Provide more accurate personalized content recommendations’. This is labelled as ‘Purpose string: less salient than the prompt above in bold text’, and also with ‘bar on offering incentives in purpose string’. Finally there are two choice buttons: the top button says ‘Ask App Not to Track’ and the bottom button says ‘Allow’. These are labelled with ‘Choice buttons: Opt-out choice could be preferred due to primacy effects.

Note: Screenshot taken on iPhone XR running iOS 15.1 in November 2021.

Comparison between ATT and Personalised Ads prompt

As discussed above, Apple has introduced a Personalised Ads prompt asking for consumers to opt into sharing data to allow personalised advertising within Apple’s own apps. This prompt employs a different choice architecture compared to the ATT prompt. The prominent disparities include the ordering of the choice buttons. This could potentially result in significantly different consumer responses and thereby different opt-in rates for Apple’s own apps compared to the opt-in rates for third-party apps. An illustration of both prompts is provided in Figure 6.6.

Figure 6.6: Illustration of ATT prompt and Apple's Personalised Ads prompt

Figure description: A side-by-side comparison of Apple’s ATT prompt and Apple’s Personalised Ads prompt. For the ATT prompt, there is bold text that reads ‘Allow “Twitter” to track your activity across other companies’ apps and websites?’. There is non-bolded text below which reads ‘This helps Twitter show you more relevant ads’. Below this there are two choice buttons: the top button says ‘Ask App Not to Track’ and the bottom button says ‘Allow’. The Personalised Ads prompt has a bold heading of ‘Personalised Ads’, beneath which is the following text: “Personalised ads in Apple apps such as the App Store and Apple News help you discover apps, products and services that are relevant to you. We protect your privacy by using device-generated identifiers and not linking advertising information to your Apple ID. Turning on Personalised Ads increases the relevance of ads shown by letting us use data like account information, app and content purchases, and, where available, the types of News stories you read. Apple does not track you or share your personal information with any third parties.” Following this text are two choice buttons: the top button says ‘Turn on Personalised Ads’ and the bottom button says ‘Turn Off Personalised Ads’.

Source: Apple

A more detailed comparison of the choice architecture of the 2 prompts is provided in Appendix I. Our key area of concern related to the choice architecture distinctions regards the ordering of the choices. In the ATT prompt, the opt-out choice (‘Ask App Not to Track’) is presented above the opt-in choice (‘Allow’). On the other hand, in the Personalised Ads prompt, the opt-in choice (‘Turn on Personalised Ads’) is presented above the opt-out choice (‘Turn off Personalised Ads’). As discussed above, the option presented at the top may be favoured by users due to primacy effects. In addition, the Personalised Ads prompt states that ‘Apple does not track you’. However, given our preliminary view discussed above, it is possible that Apple’s use of data for Personalised Ads could also correctly be described as using ‘tracking’.

Apple’s restriction on incentives to opt in

Related to the design of the prompt itself, another important limitation that affects users’ choices is the inability of developers to offer any incentive for users to opt in to sharing their data. Apple’s App Store review guidelines prohibit developers from providing users with access to content or functionality, or any form of compensation, in return for enabling ‘tracking’.^{[footnote 540]}

Apple told us that the reason for this restriction was that ‘gating’ functionality in this way could be seen as contradicting various privacy guidance around the world.^{[footnote 541]} From a UK data protection law perspective, we note that the ICO’s guidance on valid consent does not preclude the possibility that parties might lawfully incentivise consent, so long as this does not unfairly penalise those who refuse.^{[footnote 542]}

Given that developers benefit from users opting in as it increases the effectiveness of their user acquisition and monetisation, allowing them to offer incentives would enable them to share some of that value with users. This would potentially benefit both users and developers, without restricting user choice. However, as the ICO’s guidance makes clear that providing consent to tracking should not be a condition of general access to content, organisations must be careful to ensure that offering incentives to consent does not cross the line into penalising those who do not consent to tracking.

Conclusion on choice architecture of ATT prompts

We recognise that prompting users for permission to enable personalised advertising for both third-party as well as Apple owned apps enhances user control over their data on Apple devices. However, the choice architecture of the ATT prompt is potentially problematic as the language and ordering of choices, combined with the bar on being able to offer incentives to users, may unduly influence some users to opt-out of sharing their data with third-party app developers in such a way that is inconsistent with their preferences.

The Personalised Ads prompt for Apple apps, on the other hand, employs substantially different choice architecture features than the ATT prompt, which – based on the relevant literature in behavioural sciences and evidence received from third parties – may result in higher opt-in rates on a like-for-like basis. We are surprised by the apparent lack of research and user testing conducted by Apple prior to implementation of both prompt screens submitted by Apple.

Actual opt-in rates so far

Given the recent introduction of the ATT prompt and the potentially different methodologies to calculate opt-in rates, we have received a wide range of estimates for opt-in rates from Apple, ad networks and app developers. Most of these estimates were based on an only partial adoption of iOS 14.5 where the ATT prompt was rolled out and therefore might be not representative of longer-term rates.

Apple told us that they do not have user level opt-in data due to privacy protections. Based on Apple’s internal assessment conducted at the prompt-level, ‘[a significant number] of the ATT prompts displayed were accepted by users to allow tracking’

Early estimates of opt-in rates, meaning the percentage of users who selected ‘Allow’ when shown the ATT prompt, we received from app developers are fairly varied, with several ranging around 20% to 30%.^{[footnote 543]} Public estimates we have seen from third-party providers are also varied and range from around 20% to 40% for the UK, approximately 5 to 6 months after the introduction of the ATT policy.^{[footnote 544]}

Despite the differences in the figures we have received from various developers and seen in media reports, we note that most of the estimates we have seen so far are significantly lower than the opt-in rate suggested by Apple. However, the recent introduction of the ATT framework and the partial adoption of iOS 14.5 might mean that it is still early to calculate robust opt-in figures or that current estimates are not necessarily informative of the longer-term trend. We propose to go back to developers and ad network operators in the second half of our study to check whether opt-in rate figures have changed compared to their early estimates and stabilised with increased adoption of iOS 14.5. This will allow us to form a better view of the absolute magnitude of the ATT impacts on developers.

Regardless of the precise percentage, it is clear that ATT has resulted in a substantial proportion of users of Apple devices to opt out of this form of personalised advertising. In addition to our concerns regarding the choice architecture of the prompt, we also recognise that this outcome will to some extent reflect the feeling among many consumers regarding the collection and use of their personal data.

Impact of ATT on developers

The ATT framework is likely to impact app developers engaging in mobile advertising in 2 main ways:

• by undermining developers’ ability to acquire users through buying app install advertising
• by undermining developers’ ability to monetise their app through selling in-app advertising

This is as a result of the reduced capabilities for targeting and attribution when advertisers cannot track users’ activity across apps. These restrictions mean that:

• Without accurate targeting of customers, the value of ad inventory is lower and so advertisers are willing to pay less for in-app advertising, while app install advertising is less effective as it is unable to target ‘high-value’ customers (for example customers who make frequent in-app purchases)
• Without attribution, advertisers cannot measure effectiveness and so cannot optimise their ad spend by allocating their budget to the most effective ads (for example ads which are more effective at encouraging the desired outcome). This makes both app install advertising and in-app advertising less effective

Despite the recent introduction of the ATT framework, some app developers told us that they have already seen an impact on advertising performance on iOS and on the effectiveness of their user acquisition, while a few told us they will change or are considering changing their monetisation strategy. For instance:

• [An app developer with multiple apps] told us that ATT impacted its revenue and customer acquisition strategy in relation to some of its apps and that it plans to increase its spending on Android compared to iOS and the acquisition marketing budget within iOS to be allocated to ASA.
• [An app developer] told us that ATT creates a difficulty in measuring the effectiveness of, and optimizing the targeting for, campaigns that drive iOS app installations but that it expects this would translate into a relatively small decline in new customers. ^{[footnote 545]}

Some developers provided some initial estimates of the ATT impact on their advertising revenue. In particular:

• [One developer] provided an internal assessment of ATT’s effects according to which ATT would reduce its ads revenue on iOS by 26%.^{[footnote 546]} The same developer also told us that the fact it will be restricted from combining data across properties to target ads means advertisers will likely place lower value on its advertising services on iOS, reflected in declining CPMs (costs per impression)
• Meta told us there would be an increase in costs for advertisers and declines in revenue for ad publishers as a result of ATT. Focusing on the impact on Meta Audience Network (MAN) (previously, Facebook Audience Network or ‘FAN’), used by developers to advertise on third-party properties and monetise by displaying third-party ads in their apps, Meta told us:
  • It will be more expensive for app developers to acquire users with average cost of mobile app install ads increased by [REDACTED] for campaigns on iOS 14.5 and above versions
  • CPMs might drop by an average of [REDACTED] across all iOS impressions when iOS 14.5 adoption increases

Moreover, due to Apple’s limitations on alternative measurement tools on iOS (as further explored in the section below) Meta told us that MAN stopped the delivery of certain campaign types on iOS which were particularly relied upon by small app developers and, as a result, revenue from MAN now accounts for only [REDACTED] of the overall revenue Meta gets from iOS users (down from [REDACTED] pre-ATT). Finally, to proxy the effect on ATT on publishers’ revenue, Meta provided the results of an experiment pre-ATT launch comparing the revenues earned by FAN publishers when using personalised and non-personalised advertising and estimated a revenue loss of over 50% with the latter.^{[footnote 547]}

• [One app developer] told us that its preliminary analysis of the impact of ATT indicated that it had resulted in a reduction of around 30% in its ad revenue. As this was less than 2% of its global revenue, however, it told us that it does not expect to change its revenue generation strategy as a result of ATT

We note that several companies which significantly rely upon mobile advertising, have publicly announced that their revenue has been severely hit by Apple’s ATT. For instance:

• Snapchat said in an earning call that its revenue in 2021’s third quarter was lower than expected and that it anticipates growth will further slow because of Apple’s ATT changes.^{[footnote 548]} In the same earning call, Snapchat said that SKAdNetwork worked less well than expected^{[footnote 549]}
• Facebook blamed Apple’s ATT for its slower sales growth in the same quarter and warned investors of further uncertainty for its advertising business.^{[footnote 550]} It announced it is working to address ATT’s challenges in relation to measurement and targeting, with the latter requiring a multiyear effort and re-building its systems^{[footnote 551]}

Other companies announced they were also affected by ATT changes, albeit to a lesser extent. For instance:

• Twitter said it was less affected by Apple’s policies than other companies because it relies more on contextual and ‘brand advertising’ rather than ‘direct response advertising’^{[footnote 552]} meaning the type of advertising whose payoff comes as a result of an action taken in direct response to an ad^{[footnote 553]}
• Google stated that ATT had a ‘modest’ impact on YouTube revenues, (primarily in relation to direct response advertising) and that it has been investing in privacy-preserving technology to support developers mitigate ATT’s impact on their businesses.^{[footnote 554]}

In summary, although it may be still early to quantify the exact impacts of ATT on app developers in terms of revenue loss, the impacts seem to be material, particularly for developers which rely heavily on mobile advertising for user acquisition and monetisation. Furthermore, the impacts seem likely to persist at least in the immediate term and to require significant investment from developers to adjust their processes and technology to the changes brought about by ATT and mitigate its effects.^{[footnote 555]}

A further concern is that, as developers and advertisers seek to mitigate these impacts, ATT might encourage consolidation in the market. In particular, given Apple’s definition of tracking and first-party data based on corporate ownership, ATT changes might incentivise companies to merge or vertically integrate to take advantage of a larger pool of first-party data.^{[footnote 556]}

For instance, industry experts have suggested that one unintended consequence of ATT might be the emergence of so-called ‘content fortresses’ meaning collections of first-party content under commonly owned ad tech infrastructure.^{[footnote 557]} Furthermore, some media reports suggest that consolidation between app publishers and ad tech providers might be already happening to counteract the effect of the deprecation of the IDFA.^{[footnote 558]}

We plan to investigate potential consolidation trends as a result of ATT in the second half of our study.

Self-preferencing of Apple’s advertising services

We have heard concerns that, through the ATT implementation, Apple might be favouring its own advertising, both in terms of personalised advertising served to Apple users and in terms of advertising services served to third parties, including developers.

Apple’s own advertising

We consider that Apple’s own personalised advertising, which we describe in detail in the section on Apple’s advertising services above, is likely to be favoured compared to personalised advertising performed by third parties. This may be happening in 2 main ways:

• first, by being presented differently to users compared to advertising performed by third parties, both in terms of language (ie Apple’s process behind it serving personalised advertising not qualifying as ‘tracking’) and design and choice architecture elements
• second, by being able to use a wide range of data, potentially coming from a range of Apple’s different apps and services as well as from user activity within third-party apps

As mentioned above, Apple’s definition of tracking appears to favour large companies operating several first-party properties, including Apple, which can easily rely on first-party data, including account information, app and content downloads and purchases to perform personalised advertising.

Google’s choice of not showing the ATT prompt following the introduction of ATT is consistent with this. In particular, given Google operates several apps and services under common corporate ownership, it is able to combine data gathered via those distinct apps and services without the need to access the IDFA to be able to link information to users and thus without being required to show the ATT prompt. The lesser impact on Google compared to other companies engaging in advertising is also illustrated by the lower revenue loss it experienced.^{[footnote 559]}

In terms of data used by Apple for personalised advertising, even though it told us it only uses ‘a limited set of first-party data’, it seems to consider as first-party data a very wide range of information, including personal data which relates to the user’s device, data relating to Apple’s own apps and services, and data on downloads, purchases and in-app purchases for all third-party apps (since this is treated as transaction data within Apple’s first-party App Store).^{[footnote 560]}

Apple’s advertising to third parties

As briefly mentioned above, differences in measurement and attribution between campaigns inside and outside of the App Store might push developers to increase their spending on advertising services directly provided by Apple within its App Store, which are less impacted by ATT. Although we are still investigating the difference between Apple Search Ads Attribution API and SKAdNetwork API and the extent to which these could serve to favour Apple’s own advertising services, there seem to be widespread concerns around SKAdNetwork and its limitations.^{[footnote 561]}

For instance, evidence we have seen suggests versions of SKAdNetwork to date offer more limited functionality compared to Apple Search Ads Attribution API given they give access to less granular app install attribution data.^{[footnote 562]} Furthermore, SKAdNetwork appears to be undergoing frequent changes and updates by Apple, and is thus a less mature API compared to Apple Search Ads Attribution API, which may be creating uncertainty for advertisers using it.^{[footnote 563]}

A few developers told us that, as a result of ATT, they have increased or plan to increase their marketing budget allocated to Apple’s search advertising services. However, overall evidence from developers suggests that they are still considering the extent to which their business will be affected by ATT and what they need to do (if anything) to better adjust to the ATT changes, including in terms of where to allocate their advertising budget.

Media reports suggest that ATT has had a significant positive impact on Apple’s advertising business.^{[footnote 564]} In particular, according to estimates by the mobile measurement company Branch, Apple’s Search Ads are now responsible for 58% of all iPhone app downloads that result from clicking on an advert, up from 17% a year ago. This more than threefold increase in Apple’s share of app install advertising came at the expenses of rivals and particularly Facebook and Snapchat.^{[footnote 565]}

Furthermore, despite Apple’s advertising business being currently relatively small compared to other Apple’s revenue streams and, according to Apple, ’a very limited part of its overall business’ it seems this is expanding:

• In May 2021, ASA introduced a second non-search advertising placement in addition to the search result one, which appears under the ‘Suggested’ section of the App Store Search tab. Differently from the traditional ASA which are served in response to a user’s query, this new category of ads appears on the App Store Search Tab, prior to the user executing a search query
• In June 2021, Apple expanded ASA to China
• Financial data submitted by Apple shows that Apple’s advertising revenues in the UK increased [significantly] between 2017 and 2020
• Analysts’ estimates suggest that Apple’s advertising business could reach $20 billion in revenue by 2025^{[footnote 566]}
• Apple told us that it had run limited tests on an additional advertising product currently in development. In particular, the product would [REDACTED].

Documents submitted by Apple show that there was some internal disagreement between Apple’s staff on the extent to which Apple should expand its advertising offering. They also show that at a similar time to when Apple was considering introducing the ATT framework, it was also considering expanding its advertising services to third parties.

In particular, Apple’s plan for the fiscal year 2021 includes several expansion proposals for its advertising services, including [REDACTED]’.

In the second half of our market study, we plan to explore Apple’s consideration of expansions and the extent these are informative of its incentives going forward as well as its current product development in advertising.

Competitive effects in app distribution

In this section we explore potential wider competitive effects as a result of ATT, including around concerns that Apple might be using ATT to reinforce its market power in app distribution and that ATT may cause developers to change their business models by shifting to monetisation models where Apple charges a commission.

ATT might reinforce Apple’s market power in app distribution

One impact of ATT may be that by undermining the value of app install advertising to app developers seeking to attract new users to their apps, Apple may be further strengthening the App Store’s role as a distribution channel and source of discoverability for apps, and therefore increase developers’ reliance on it as a means for acquiring users.

Although a majority of app downloads on iOS comes from App Store search results, downloads from app referrals (where a user arrives at the App Store page of an app by clicking a link in another app) appear to be a significant source of discoverability, accounting for approximately [20% to 30%] of downloads.^{[footnote 567]}

Based on data submitted by Apple, almost [REDACTED]% of app downloads come from direct searches for a particular app (ie navigational searches) – [60% to 70%] of downloads come from searches, and [the majority] of these are navigational. This makes app referrals even more significant for apps accounting for the remaining [REDACTED]% of downloads, which are not usually installed via navigational searches and thus are in more need for other ways to encourage downloads.

While using app install advertising does not allow developers to bypass the App Store, it does make the App Store less important for app discovery.^{[footnote 568]} As discussed above in the section on app discovery through the App Store, Apple has the ability through its design of choice architecture in the App Store to influence which apps are successful. However, if developers can find users outside the App Store, that ability is diminished. By undermining alternative discovery channels through ATT, Apple could therefore be strengthening its market power in app distribution.

We plan to investigate these concerns further in the second half of our study.

ATT might cause a shift in the way that app developers monetise apps

As described above, ATT is likely to reduce the revenues that developers can earn from in-app advertising. This means that the ad-funded business model for apps, on which Apple does not charge any commission for app distribution to developers, will likely generate less revenue for app developers compared to a pre-ATT world.

As a result, developers might turn to alternative ways to monetise apps, such as requiring payments within the app for certain contents or features, or via subscriptions. Given that Apple charges a commission on in-app purchases of digital content through IAP, including additional in-app content or features and on subscriptions, Apple has an incentive to encourage such a shift by developers.

Media reports suggest that app developers are already implementing changes in their monetisation model as a result of ATT, with some ad-funded games introducing in-app purchases.^{[footnote 569]} As mentioned above, although some developers told us that they might consider changing their monetisation strategy as a result of ATT, most of them are still considering what (if any) changes they will implement. We plan to consider these possible trends further in the second half of the study.

Consumer impacts

In line with the CMA’s joint statement^{[footnote 570]} with the ICO on the relationship between competition and data protection, we believe that more competitive markets will deliver the outcomes that consumers care about most, which increasingly include enhanced privacy and greater control over personal data. The relationship between competition and data protection can be mutually reinforcing, as well-designed policies and interventions that are aimed at preserving individuals’ privacy and place individuals in control of their personal data can promote positive competitive outcomes.

We recognise that Apple’s stated intention with ATT is largely consistent with this vision, but our preliminary view is that Apple’s current implementation of ATT is likely to result in harm to consumers in a number of ways:

• if, as contemplated above, less profitable in-app advertising makes free ad-funded apps less viable as a business model, this is likely to cause some developers of such apps to exit or to change business models, leading to consumers paying for apps instead or missing out on them entirely
• less efficient and profitable user acquisition increases barriers to entry for developers which is likely to result in less entry, reduced quality and innovation in the provision of apps, and higher costs for consumers
• Apple’s prohibitions on app developers offering incentives means that users are not able to gain a fair share of the value of their data, through missing out on offers and deals to sign up to personalised advertising
• less targeted advertising might mean consumers will see more ads than before as developers compensate for the reduction in revenue per ad (indeed some reporting has indicated that increased ad load is one way that developers are trying to counteract the effects of ATT)^{[footnote 571]}
• less targeted advertising means consumers see ads which are less relevant for them, although consumers who dislike targeted advertising might prefer this.

However, as noted above in relation to Apple’s rationale for ATT, there are likely to be benefits to consumers as a result of ATT in relation to privacy and personal data protection. ATT does give users more information and granular control over the use of their personal data by app developers than was previously available, and makes this choice easily accessible by surfacing an opt-in prompt rather than making users seek out settings to disable this form of data usage. While we have concerns about how the choice is presented, whether this seeks to influence choice towards opt-out, and the different approach Apple takes to its own data collection for personalised advertising, we recognise that such choice empowers individuals and enables them to have meaningful control over the use of their data.

When considering potential interventions in relation to our concerns about ATT, for which we provide an overview in Overview of potential interventions, we have therefore sought to identify ways in which the potential competition harms could be abated while retaining the benefits in terms of user choice and privacy.

We will continue to engage extensively with the ICO on the implications of Apple’s ATT changes, as well as any other market developments that have implications for the processing of personal data, to ensure that data protection considerations are adequately reflected in our assessments. In line with the CMA and ICO’s joint statement on the relationship between competition and data protection, we are confident that any areas of perceived tension between competition and data protection can be overcome through careful consideration of the issues on a case-by-case basis, with consistent and appropriate application of competition and data protection law, and through close cooperation between our 2 organisations.

Apple’s restrictions on cloud gaming services

The following section examines how Apple has used its control over app distribution on iOS to block the emergence of cloud gaming apps on its App Store. We examine the impacts of its actions on cloud gaming users and providers as well as whether Apple’s motivation to obstruct these services was influenced by its incentive to protect its:

• revenue from mobile device hardware
• position in app distribution via the App Store
• own gaming service, ‘Apple Arcade’

Apple’s restrictions on cloud gaming, which we detail below, have blocked apps from various providers.^{[footnote 572]} We have sought evidence from these providers to understand the issues faced around publishing cloud gaming apps on the App Store.

Cloud gaming background

Cloud gaming services provide mobile device users access to games which are far beyond the capabilities of even the top end of mobile devices. It achieves this by using the processing power of the cloud, instead of the user’s device, to run games. Previously, consumers of mobile gaming were restricted in the range and type of games which they could play by their device’s processing and storage capabilities. Cloud gaming services remove that restriction and consequently reduce the importance of the hardware capabilities of mobile devices. However, as Apple’s iPhones are typically top of the range in terms of hardware capabilities, cloud gaming may remove one of the unique selling points of Apple devices to consumers of mobile gaming and reduce the value of these products to consumers compared to other available devices.

Reducing the importance of the hardware capabilities of a consumer’s device may serve to lessen consumers’ switching costs between devices. If consumers were to switch from a high-end device in terms of hardware capabilities to a lower-end device, they may risk losing access to processing or storage-intensive app-based games which their newer device could not handle. However, in the presence of cloud gaming services, downgrading a device may not pose the same costs upon consumers.

Cross-platform, or platform-agnostic services such as cloud gaming services can be purchased on one device and accessed across various devices and platforms. The emergence of such services may serve to reduce switching costs between mobile devices, as a consumer’s subscription and access to the service is not tied to their device or a particular ecosystem, but rather to their account with the cloud gaming service provider.

Cloud gaming service providers were very positive about cloud gaming’s emergence and prospects in the gaming industry:

• Google submitted that ‘at a high level, cloud gaming may experience growth as low-latency internet connectivity continues to proliferate, cloud graphics processing capabilities continue to evolve, business models shift in favour of subscription models and publishers move to a direct-to-consumer model. Cloud-based streaming facilitates cross-platform play, a consistent user experience, and the convenience of not even having to download and update native apps’
• Microsoft submitted that cloud gaming technology provides benefits to various stakeholders, as well as to competition, arguing that it:
  • Benefits consumers by
    • enabling them to more easily discover and try a wider variety of games on their mobile devices
    • eliminating the need for consumers to purchase and upgrade expensive hardware
    • removing the hassle of downloading and updating each game on their device
    • providing greater flexibility in the user experience by enabling access from any device
  • Benefits game developers by
    • removing the need to develop, distribute or maintain different versions of their games across operating systems
    • allowing for a seamless experience of their games across operating systems
    • allowing them to distribute their work (for example, updates) quickly across operating systems
    • allowing them to reach a larger base of users without porting to multiple operating systems
  • Benefits cloud gaming service providers by enabling them to centrally manage large game libraries or improve their server-side hardware^{[footnote 573]} without requiring any changes to the user’s device^{[footnote 574]}
  • Increases competition between operating systems by removing the need for developers to write for each operating system separately. As gamers would no longer be limited to the games available on their operating system, they no longer face an opportunity cost of losing access to certain games when switching operating systems

Cloud gaming service providers may adopt different business models to monetise and grow their services. From subscription-only models (Microsoft, Amazon) to an à la carte offering with an optional subscription service (Google), or a free-to-play, in-app purchases and in-app advertising driven model (Meta), their chosen business model may affect how Apple’s restrictions affect their ability to offer a native app. In Table 6.2 below we set out high-level information on the business models adopted by some prominent cloud gaming service providers.

Table 6.2: Business models of prominent cloud gaming service providers

Cloud gaming service provider	Model	Content
Microsoft Xbox Game Pass Ultimate	Subscription required to access (£10.99 per month). In-app purchases present in some games.[footnote 575]	400+ games. First and third-party games, focus on AAA games.[footnote 576]
Google Stadia	A la carte games for purchase. Subscription service available (£8.99 per month). In-app purchases present in some games.	Games available on subscription, further games available à la carte.[footnote 577] Includes AAA games.
Facebook Gaming	Free for users to access. In-app purchase and advertising functionality available to developers. Provider may offer alternative compensation to developers for providing game content.	Large number of third-party HTML5 and web games. Limited number of third-party AAA games.[footnote 578]
Amazon Luna[footnote 579] [footnote 580]	3 subscription catalogues to choose from: Luna+ ($5.99 per month), Family ($2.99 per month) or Ubisoft+ ($17.99 per month). In-app purchases present in some games.	Third-party games, focus on AAA games. Different games in each ‘channel’ (for example, family-friendly, Ubisoft-only).

Apple has obstructed the development of cloud gaming services on iOS

Apple’s App Store Review Guidelines include various policies which restrict how cloud gaming apps can function as native apps from the App Store. Although game streaming is currently allowed in principle,^{[footnote 581]} Apple’s exception for streaming games includes caveats which prevent cloud gaming apps from being feasible to develop for the App Store in practice.

Under Apple’s Guidelines, an app which offers access to a catalogue of games is not permitted on the App Store. Each game must be individually submitted to the App Store such that it can be approved by Apple, has a product page, appears in charts and search, has user ratings and review and can be managed with parental controls. This means that each game must be individually downloaded to the user’s device, such that multiple games cannot be streamed from one app. Cloud gaming service providers may only create a catalogue app insofar that it links to the individual App Store product pages for each game.^{[footnote 582]}

All cloud gaming service providers had negative views on the effects these guidelines would have upon the feasibility of delivering cloud gaming apps on the App Store:

• [One cloud gaming service provider] submitted that these guidelines effectively prohibit game streaming platforms. It said that downloading each game contradicted the unique selling points of game streaming as users would lose the ability to try out and move between games quickly. [Another] told us that hosting games on its cloud gaming platform and making them appear as standalone games effectively amounts to a prohibitive ‘cross-publishing requirement’. [A third] raised the fact that many third-party games developers do not allow their games to be made available in this way because of customer confusion. [Another] told us that the full versions of various cloud gaming services had been blocked by the App Store
• Some providers additionally pointed to the technical barriers posed by the requirement to publish each game in their catalogue as a standalone app. [One cloud gaming service provider] told us that building, testing and rotating hundreds of iOS apps, as well as maintaining^{[footnote 583]} and submitting each update for review for each game was an insurmountable technical hurdle for the company as a developer. It said that any improvements to its client-side services would also require re-publishing each game. [Another] highlighted that Apple’s restrictions require developers to spend resources coding 2 versions of each game, which in some cases may be technologically infeasible.

In addition, these game streaming services are not included in the exemption from the obligation to use Apple’s IAP system which applies to other types of audio-visual streaming such as video and music. Most cloud gaming service providers saw this guideline as obstructive to their ability to deliver cloud gaming services on the App Store, although the extent to which this was the case varied by provider and business model:

• [One cloud gaming service provider] submitted that the IAP obligation created further technical barriers to the delivery of its cloud gaming services. It said that one of its key value propositions is the ability for developers to code a game once and have it available on all platforms. As developers must maintain iOS-specific versions of each game (old and new), the IAP requirement creates a large amount of technical and engineering work which many developers are not prepared to undertake
• [REDACTED]
• However, Meta, which uses a free-to-use in-app-purchase driven model, submitted that it was not permitted to offer IAPs on its gaming services: ‘Apple prohibited Facebook from offering the gameplay section of its Facebook gaming app on iOS (which is the section of the app where Facebook offers its cloud-gaming services on the Android version of the app). Apple also prohibited Facebook from offering IAPs for Instant Games and on the Facebook Gaming app on iOS which means Facebook cannot offer developers monetisation opportunities’

Apple’s internal documents demonstrate [some awareness that its policies would result in a deteriorated user experience of cloud gaming services]. [REDACTED]

[One cloud gaming service provider] submitted to Apple that its App Store policies presented significant challenges to cloud gaming services accessing the App Store. This provider submitted to Apple that its policies would:

• Result in a poor user experience: [REDACTED]
• Present challenges for game developers: [REDACTED]
• Present operational and business challenges to streaming platforms themselves: [REDACTED]

Direct impact on providers and consumers

Apple’s restrictions appear to have pushed cloud gaming service providers to offer their services through web apps on iOS rather than as native apps on the App Store. Table 6.3 below sets out where prominent cloud gaming service providers have made their services accessible on Android and iOS, as well as examples of which other devices they can be accessed from through web browsers or other app stores.

Table 6.3: Availability of cloud gaming services on Play Store, App Store and Web Apps

Cloud gaming service provider	Android Play Store	Android Web App	iOS App Store	iOS Web App	Other
Microsoft Xbox Game Pass Ultimate	Yes[footnote 584]	Yes	No	Yes	PC, Apple Mac, Xbox
Google Stadia	Yes	Yes	No	Yes	PC, Apple Mac, select compatible TVs[footnote 585]
Facebook Gaming	Yes	Yes	No	Yes	PC, Apple Mac
Amazon Luna	No	Yes	No	Yes	PC, Apple Mac, Fire TV

By examining how cloud gaming services perform on web apps compared to native apps on iOS, we can set out what the likely impact of Apple’s policies has been on cloud gaming service providers and consumers.

Evidence from cloud gaming service providers highlighted 2 areas of concern over the use of web apps compared to native apps to deliver cloud gaming services. First, providers may struggle to acquire and maintain users, and users may be unaware of the choices available to them or find it difficult to access a provider’s services due to issues concerning the discoverability, searchability and the ease of user engagement of web apps on iOS. Second, providers are forced to offer a lower-quality service, and users would suffer from a deteriorated gaming experience due to issues concerning the features and functionality of web apps on iOS. We set out these issues in turn below.

Discoverability, searchability and engagement

Web apps are not listed or discoverable on the App Store. The App Store does not distribute web apps, nor facilitate searching for them. Accessing a web app requires users to navigate to it themselves via Safari or another browser.

As discussed in Competition in the supply of mobile browsers, unlike native apps, web apps on iOS are not automatically added to the user’s home screen to aid future engagement with the app; users must manually ‘pin’ the web app to their home screen using Safari. Web apps on iOS also do not currently have the ability to send push notifications to re-engage previous users. These features of web apps on iOS hinder user re-engagement and as such the overall usage of cloud gaming services.

Most cloud gaming service providers from whom we received evidence highlighted discoverability, searchability and engagement as issues faced by cloud gaming service providers when using web apps over native apps:

• On the App Store’s importance in user acquisition, some cloud gaming service providers pointed to user behaviour and expectations as to why the App Store had such an influential position. [One cloud gaming service provider] submitted that turning to the store to discover content was simply what users were used to, and [another] submitted that Apple had ‘trained’ its users to discover mobile content this way. Further, [a third provider] said that developers have had no incentives to invest in the discoverability of webpages or web apps given their limited functionality compared to native apps and as such app discovery on iOS is driven by the App Store
• On the App Store’s importance in user retention and engagement, [one cloud gaming service provider] submitted that a web app could not store sign-in data locally for more than 7 days unless it is pinned to the home screen, requiring users to sign-in again every 7 days. [Another] pointed to user behaviour, stating that ‘educating’ consumers on how to engage with web apps ‘imposes challenges because it is not how customers are used to engaging with apps’. [A third] submitted that the inability of web apps to re-engage consumers through push notifications, amongst other issues, further disincentivises developers from investing in discoverability of their web apps rather than native apps on iOS

This means that users of gaming and cloud gaming services on iOS may have less choice of products and services, due to cloud gaming services only being available via web apps, as they may be:

• unaware of their ability to access cloud gaming services on web apps
• unsure how to access them even if they are aware of them
• unable to effectively discover or compare additional cloud gaming services even if they are using one already.

Features and functionality

Submissions from cloud gaming service providers suggest that a range of features and functionalities of cloud gaming services were hindered by using a web app over a native app on the App Store. A key reason for this is the limited support of browsers on iOS for web apps due to Apple’s restriction that all browsers on iOS have to use Apple’s WebKit, browser engine. As discussed in Competition in the supply of mobile browsers, WebKit lags behind other browser engines in functionality, in particular with respect to support for web apps.

Limitations of web apps on iOS that cloud gaming service providers saw as the most impactful upon the user experience of cloud gaming included, among others:

• the inability to offer full-screen mode
• lack of support for push notifications
• inability to access hardware-accelerated graphics rendering
• increased battery drain
• lack of support for persistent storage
• not being able to use Bluetooth to connect game controllers
• no access to mouse movement data

On the other hand, cloud gaming service providers submitted that there were some benefits to cloud gaming services from the use of web apps over native apps:

• users can play games on the service seamlessly without having to download an app
• it is possible to offer a consistent user experience across different platforms
• creating web apps may be less costly and time-intensive than creating native apps

Evidence on user data submitted by [one cloud gaming provider] suggests that [the adoption of its cloud gaming service was hindered on iOS by Apple’s restrictions].

Potential harm to competition

We have considered Apple’s incentives for imposing restrictions on cloud gaming services. On the one hand, Apple has an incentive to bring value to users through the App Store by providing high-quality and diverse content. The App Store becomes more valuable the better and broader its content is. On the other hand, there may be competing motivations which could provide Apple with reasons to impose restrictions on cloud gaming. We have assessed the following types of possible impact:

• protecting the importance of Apple’s hardware
• protecting Apple’s control over how apps can be discovered and accessed on iOS devices
• giving Apple Arcade a competitive advantage over competing services

Effects of Apple’s restrictions upon its hardware revenues

Cloud gaming services may reduce the barriers to switching away from Apple devices. We examine below how the emergence of cloud gaming services on the App Store may reduce the revenue that Apple generates via device sales by:

• reducing the importance of premium hardware on Apple iPhones for users’ experience of gaming apps
• reducing switching costs between devices by offering platform-agnostic services

Cloud gaming service providers considered that cloud gaming services on iOS may have the ability to reduce switching costs between devices by providing platform-agnostic services and reduce the reliance of consumers upon Apple iPhone hardware:

• [One cloud gaming service provider] submitted that operating system-neutral gaming services reduce the importance of the operating system and therefore reduce the cost of switching devices
• Microsoft submitted that cloud gaming technology increases competition between operating systems by removing the need for developers to write for each operating system separately; as gamers would no longer be limited to the games available on their chosen operating system, they do not face an opportunity cost of losing access to certain games when switching OSs.

Apple earned a net revenue of around [$6.5 to 7 billion] billion from iPhone device sales in calendar year 2020, representing roughly [50% to 60%] of its total net revenue generated in the UK. This increases to around [$8 to 8.5 billion], and [60 to 70%] of its net revenue, when factoring in the iPad.

Apple’s internal documents show that supporting the differentiating hardware factors of the iPhone was a relevant factor whilst discussing whether to allow xCloud on the App Store. In an internal document (email) in 2020, an Apple employee commented that [Apple has a strategic interest in supporting high-quality content that leverages the differentiated capabilities of Apple devices]. In a different context, as revealed in court documents in the Epic litigation, Apple’s Craig Federighi explained to an Apple employee who suggested that Apple acquire a cloud streaming company that cloud streaming apps would make ‘little sense for Apple (given our strength of providing high performance local compute)’, and that they would be ‘counter to our overall customer value proposition’.^{[footnote 586]}

Some cloud gaming service providers considered that protecting the position of the Apple iPhone, iOS operating system and Apple’s hardware revenue from iPhone sales were influencing factors in Apple’s decisions around the restrictions on cloud gaming on iOS:

• [One cloud gaming service provider] submitted that Apple has an incentive to restrict operating system-agnostic relationships between consumers and service providers as they would lower barriers that users must overcome to switch away from iOS devices. It said that Apple’s policies and practices that prevent these relationships from forming were apparently motivated by this incentive
• [Another cloud gaming service provider] submitted that Apple is the only manufacturer of mobile devices that is able to sell premium phones on a large scale, and that a transition to cloud-based services will reduce the need for high-end devices, thereby threatening Apple’s hardware business

As noted above, there is an inherent cost to Apple of preventing new and high-quality services such as cloud gaming from gaining access to the App Store, particularly given that they are available on the Google Play Store; users who wish to access cloud gaming may become more likely to switch to an Android device if they cannot access cloud gaming apps on their iOS devices.

However, we consider that, overall, the threat posed to Apple’s device revenue by cloud gaming services may outweigh these costs and so provide an incentive to obstruct the emergence of these services. Currently cloud gaming services are in a nascent stage of development – if, by blocking them from the App Store, Apple can hinder their development more broadly, it would be able to better defend the current prevailing situation, where users who want to play high-quality games need high-quality devices to do so, and so help protect its market position.

Effects of Apple’s restrictions upon its position in app distribution on iOS.

Apps which distribute a catalogue of games such as cloud gaming services act as a distribution mechanism, which over time may reduce the reliance of iOS users on the App Store for the discovery of and access to games. Additionally, apps distributing games which also operate across platforms can further reduce the reliance of iOS users upon the App Store as users may not discover or pay for the initial subscription service on the App Store at all.

Some cloud gaming service providers submitted that cloud gaming services and gaming platforms overall have the ability to undermine the App Store as a channel for accessing or discovering games:

• Microsoft told us that ‘Game-streaming subscription apps have the potential to change customer patterns and the role of mobile app stores, enabling the emergence of competition that simply could not otherwise develop.’
• [Another cloud gaming service provider] submitted that:
  • its gaming platform could threaten the App Store in game distribution: ‘Apple repeatedly made clear that it was rejecting [REDACTED] […] because it was concerned that it was trying to create a “gaming platform” that would rival Apple’s own App Store and Apple Arcade’
  • platform-agnostic services overall may pose a threat to the App Store, and therefore ‘By implementing restrictions of this kind, Apple […] undermines any source of intramural threat to the App Store’s hegemony’

Apple earned a net revenue around [$400 to 600 million] from digital content App Store billings in the UK in calendar year 2020, representing roughly [0% to 5%] of its total net revenue generated (excluding any advertising revenue). Further, gaming apps are a particularly key source of revenue from Apple, representing over half of Apple IAP revenues in the UK.

Some cloud gaming service providers submitted that they view Apple’s incentive to protect its position in app distribution, particularly with respect to the lucrative gaming market, as one of the reasons why it has restricted the emergence of cloud gaming services on its App Store:

• [One cloud gaming service provider] submitted that over time, game subscription services could challenge Apple’s position in game distribution and circumvent the App Store’s lucrative gatekeeping role because players would have an alternative discovery channel to the App Store, and would have access to new games that could not otherwise be played on iOS devices, exercising a competitive constraint on the App Store. It said that by foreclosing game subscription services, Apple protects its dominance in the market for game distribution through the App Store
• [Another cloud gaming service provider] submitted that Apple has a strong incentive to restrict the ability of consumers to access services on iOS devices through channels other than the App Store. It said that this incentive has apparently motivated Apple to set policies that prevent consumers and providers from interacting in this way.

We are mindful that by prompting cloud gaming service providers to offer their services via web apps instead of native apps, Apple may have provided an additional incentive for these developers to invest in web apps.

Apple’s internal documents demonstrate that it was aware of the potential threat that web apps may pose to the App Store, while acknowledging that web apps may not prove an optimal experience to users. In an email chain discussing whether Microsoft’s xCloud service could enter the App Store, an Apple employee said [REDACTED].

On the other hand, evidence from Amazon showed that Apple engaged with it to [REDACTED]. Nevertheless, as discussed above, on iOS web apps have a number of significant drawbacks compared to native apps for cloud gaming, both in terms of their features and functionality and in terms of discoverability and user engagement.

Overall, if users were to begin to turn to cloud gaming services to find new games rather than the App Store, this could pose a significant threat to an important revenue stream for Apple. Given the limitations of web apps on iOS – and Apple’s ability to maintain those limitations as discussed in Competition in the supply of mobile browsers – the potential threat from driving cloud gaming service providers to attempt to deliver their services through web apps seems likely to be much more limited.

The impact of the development of streaming services on music distribution may be an instructive example for the possible impact of cloud gaming on app (and specifically game) distribution. In 2010, revenues from music downloads outstripped music streaming revenues by a ratio of almost 10:1, but by 2020 this had reversed.^{[footnote 587]} Apple, which had made a significant majority of music download sales through its iTunes store, has by contrast only a 16% share in music streaming through Apple Music.^{[footnote 588]} If Apple expected cloud gaming services to have a similar impact on game distribution, this would likely provide a strong incentive to obstruct the emergence of such services.

Effects of Apple’s restrictions upon Apple Arcade

Apple Arcade is a subscription service where, for a single flat fee (£4.99 per month in the UK), users get access to the catalogue of games available on the service. Users access the games in the catalogue by downloading them directly to their mobile device as individual apps and the games use the processing power and storage of the device to run the games.

Apple Arcade is still a relatively new and growing service. Apple earned a net revenue of [$0 to $10] million from Apple Arcade billings in the UK in calendar year 2020, representing a very small proportion ([0 to 5%]) of its total net revenue. Worldwide, it is [REDACTED], although this may be expected of its business model in the early stages as its builds its user base. It generated around [$50 to $100 million] in 2020 with around [REDACTED] paid out to third-party game developers – a difference of around [REDACTED].

To the extent that Apple Arcade would face a competitive threat from cloud gaming services, Apple’s restrictions on cloud gaming would shelter Apple Arcade from competition. Overall, it is not clear how strongly Apple Arcade competes with cloud gaming services:

• Apple [REDACTED], and told us that Amazon Luna and Xbox Game Pass, both of whom offer cloud gaming services, were 2 competitors to its Apple Arcade service, although it also listed companies who do not offer cloud gaming services on mobile devices such as PlayStation, Electronic Arts, Activision/Blizzard and Square Enix
• However, cloud gaming service providers, while noting some similarities and competition between their services and Apple Arcade also highlighted important differences. In particular they noted the higher quality of games available on cloud gaming services given that processing is done in the cloud, and the ability to use the same service across devices as opposed to the ‘device-centric’ model of Apple Arcade

Internal email discussions from Apple regarding whether and how to permit Microsoft’s cloud gaming service on the App Store did not make any reference to a strategic interest of protecting Apple Arcade, and instead were focussed on Apple’s App Store Review Guidelines (mostly on its store-like functionality) as well as Apple’s strategic interest to emphasise the differentiating hardware capabilities of Apple devices.

Overall, we consider that while Apple may be incentivised to hinder the development of cloud gaming, any such incentive is likely to be driven more by the benefits to Apple of protecting its hardware revenues and its market power in app distribution than by the benefits of protecting Apple Arcade.

Apple’s stated rationale for restrictions on cloud gaming

Apple has provided various justifications for its App Store policies on cloud gaming. Apple claims that its policies around cloud gaming are justified on the grounds of security and privacy, as well as user experience and expectations.

Apple said that the App Store provides particular protections to its customers in relation to apps. It said that akin to other apps on the App Store, games must:

• have product pages which contain important information for all users such as privacy information labels and age ratings
• be subject to privacy-protective processes built into iOS (such as preventing apps from accessing device user and sensor data including location, contacts and photos without consent)
• be manageable by Apple’s Screen Time and Family Sharing features (which allows parents to limit the age ratings of apps, set time limits for device usage and approve purchases and downloads on a child’s device)

It said that if it were to allow individual software apps such as streaming games to be distributed within a streaming game service app, then these protections would fall away.

In addition, Apple submitted that its restrictions on cloud gaming are justified by fulfilling the user expectations of games on the App Store. Aside from having a product page and being subject to parental controls and privacy permission dialogues as mentioned above, which it said were also part of the user expectations for games on the App Store, it said that users expected games to be locatable in App Store searches and be eligible for featuring in App Store charts and editorial sections.

There are other types of app available on the App Store which allow users to access a variety of content, which is updated over time and is not reviewed individually by Apple. Apple submitted that the differing treatment of cloud gaming platforms compared to other media streaming platforms can be explained by the distinction between games and other types of content, for example creator apps such as Roblox or YouTube, or traditional media such as music or films. Specifically:

• It said that games are software applications which contain code which dictates the features, functionality and content accessible within them. It highlighted that users interact with games and are making decisions during those interactions such as buying an item, submitting personal information to create an account or granting consent for location information. It contrasted this to traditional media such as music and films, which are linear and static with no interactive features. Because of these differences, each game must be reviewed under the App Review Guidelines whereas traditional media content does not require individual review
• Regarding creator content, Apple said that users and creators of, for example, YouTube videos, Snapchat lenses or Minecraft worlds are not creating new software applications but rather are making content within the bounds of the software provided by the creator app developer. It noted that creator content can offer interactive features such as items for sale or data requests from users, but that it does not need review by the App Review Guidelines as these features occur within the confines of the creator app itself, which has already undergone review.

Our view at this stage is that the reasons cited by Apple do not provide a compelling justification for its restrictions on cloud gaming apps.

First, it is plausible that the privacy and security protections for games distributed through the App Store could be replicated for games within cloud gaming apps. These protections could be implemented through a mixture of Apple applying them to the cloud gaming app as a whole (given that that app would itself be distributed through the App Store) and cloud gaming service providers applying equivalent protections within their apps. In particular:

• Some information communicated on product pages could still be communicated in the product page for the cloud gaming app (for example privacy information labels) while others could be communicated for individual games within the cloud gaming app (for example age ratings). [One cloud gaming service provider] suggested that Apple is less well placed than gaming platforms or independent industry rating bodies (for example PEGI) to determine content ratings for games, while [another] argued that there are ‘significantly less onerous ways that Apple could review games without requiring every game to be published as a standalone app’.
• Privacy-protecting processes could be applied to a cloud gaming app as a whole, as the cloud gaming app would need to request user consent to access data in the same way as any other app.
• A cloud gaming app could also be subjected to the parental control features described by Apple. While this would only allow parents to set limits on total use of the cloud gaming app rather than on a per-game basis, this limitation could be addressed by cloud gaming service providers implementing their own parental controls – indeed, Microsoft, Amazon and Google’s cloud gaming services all already include such controls.

Second, contrary to Apple’s view, we have seen no evidence suggesting that users would expect to find and access individual streaming games within a cloud gaming service in the same way that they currently find downloadable game apps within the App Store. Further, users’ expectations may change over time as a result of innovation. Before streaming music became common, users may have expected to download individual songs from iTunes – this would not have been a good reason for Apple to prohibit music streaming apps.

Finally, the boundary between games and other types of streaming content is not always clear. For example, ‘creator content’ within apps such as Roblox can include a wide catalogue of user-generated games within a single app, while even ‘traditional media’ streaming platforms can contain interactive content – [one cloud gaming developer] highlighted interactive Netflix content such as ‘Black Mirror: Bandersnatch’ or ‘You vs Wild’.

Apple’s treatment of these other types of app provides a model for how it could allow cloud gaming apps on the App Store without compromising users’ safety or experience. For example:

• Video streaming apps such as Netflix or Disney+ present age ratings for individual pieces of content within their apps and allow users to set parental controls
• as noted by Apple, it does not need to review individual pieces of content within ‘creator apps’ even when they can access data or ask for payment, because this takes place within the confines of the already-reviewed creator app.

The fact that Google allows cloud gaming apps to be distributed through the Play Store, without any indication that this has compromised user safety, also indicates that cloud gaming services can be offered in a way that is compatible with privacy and security considerations.

Key findings in relation to the role of Apple and Google in competition between app developers

We have found that Apple’s and Google’s control over their respective mobile ecosystems allows them to influence competition in downstream app markets throughout the entire process of app development and distribution, and effectively set the ‘rules of the game’ for competition between app developers.

We have identified concerns that Apple’s and Google’s use of this influence in a number of areas may be harmful to competition, either by self-preferencing their own apps or services or by distorting competition between third parties:

• Apple and Google can determine the functionality available to apps through control of access to APIs. Apple reserves access to certain hardware functionality, such as the technology that enables contactless payments, protecting its services that use this technology from competition and potentially restricting innovation
• Apple and Google require developers to submit their apps for review before they can be distributed through their respective app stores. App review processes are opaque, and rules appear to be inconsistently applied. The resulting delays and uncertainty can add to development costs and hinder innovation by app developers
• Apple and Google can influence users’ choice of apps through pre-installation, setting certain apps as defaults, and through the design of their app stores. This allows them to favour their own apps, and means that they can cause significant disruption to developers’ businesses by making changes to app store search algorithms with little explanation or notice
• Apple and Google have access to a range of commercially sensitive information from app developers. We have heard concerns that this information may be used by Apple or Google to develop products, enter new markets or gain a competitive advantage against third-party developers.

We have also considered 3 sets of practices which, as well as influencing competition in app markets, may have broader competitive implications, such as entrenching market power in app distribution and exploiting this market position: Apple’s and Google’s rules relating to payments for in-app purchases, Apple’s ATT policy, and Apple’s restrictions on cloud gaming.

Both Apple and Google require certain app developers to use their payment systems, through which they collect a commission of up to 30% on in-app purchases of digital content. In addition to complaints about commission levels, we have heard concerns that the requirement to use these payment systems may reduce developers’ control over pricing and refunds, distort competition between Apple’s and Google’s apps (which do not have to pay commission) and third-party apps (which do), and make it harder for users to switch devices.

Apple’s App Tracking Transparency framework, which aims to give consumers greater control of their data, may create consumer benefits by enhancing privacy and user agency over the way their personal data is used for advertising. We are supportive in principle of market developments that promote greater control and choice for consumers in a way that is competitively neutral. However, we are concerned that Apple may not be applying the same standards to itself as to third parties, and the design and implementation of the ATT prompt to users may be distorting consumer choices. Ultimately this may entrench the App Store’s position as the main way of users discovering apps, advantage Apple’s own advertising services and drive app developers to begin charging for previously free, ad-funded apps.

Apple has blocked the emergence of cloud gaming on iOS. Cloud gaming poses a threat to Apple’s position in app distribution since it represents an alternative method of game discovery and distribution. Apple’s policy may also protect its competitive position in mobile devices and operating systems, as cloud gaming services may reduce the importance of high-quality hardware and make it easier for users to switch between platforms.

7. Overview of potential interventions

Introduction

In Chapters 3 to 6 of this interim report we have set out our initial findings regarding competition in the supply of mobile devices and operating systems, in mobile app distribution, and in the supply of mobile browsers and browser engines. Through that detailed analysis of the main gateways through which Apple and Google control access to online content, we have reached preliminary views on the competition concerns that we consider warrant consideration of potential interventions, including the market power that Apple and Google have across the mobile ecosystem.

This chapter provides an overview of the types of interventions that we have identified in the first half of the market study as potential ways to address the competition concerns identified and in relation to which we are inviting stakeholders’ views through our consultation on this interim report.^{[footnote 589]}

We have not at this stage sought to determine whether any individual intervention would be justified, and therefore we are not making recommendations or advocating any specific interventions at this time. Instead, this chapter sets out a high-level overview of the potential merits, risks and challenges associated with the potential interventions we have identified across the 4 themes of this market study. Where relevant, we outline our planned approach to gathering evidence in the second half of the study to further understand the effectiveness and potential risks of these interventions, in advance of our final report.

As noted further below, it may also be possible to prioritise and stagger the implementation of certain remedies, depending on which are regarded as being potentially most effective at driving greater competition and choice both within mobile ecosystems and between them.

In this chapter we set out:

• an overview of potential interventions that we have identified to address our concerns in each of the 4 themes covered in Chapters 3 to 6
• a summary of how these interventions might work together, given the interrelated aspects of the mobile ecosystem
• a reference to international developments which have the objective of giving powers to competition and regulatory authorities to tackle the competition problems that exist globally in digital markets, or litigation or enforcement proceedings that are relevant to the matters covered in this interim report

In this chapter we focus on the potential forms of the individual interventions to promote competition and address potential harms in the markets in the scope of this study, independent of the particular form of instrument that might be used to implement those interventions.

In the next chapter, we provide a summary of how the types of interventions identified below might fit within the government’s proposed legislative framework for the new pro-competition regime for digital markets, as introduced in the Introduction.^{[footnote 590]} As outlined in more detail in the next chapter, our initial view is that the proposed regulatory framework – anticipated to include legally enforceable codes of conduct and pro-competitive interventions (PCIs) – would provide suitable powers to the DMU to implement effectively any of the interventions we have identified that it ultimately finds to be justified. In particular, in the form currently proposed, that regime appears well suited to overseeing a set of interconnected remedies that will require continuing oversight, including ongoing engagement with the owners of the ecosystems, their rivals, trading partners and users.

Types of intervention under consideration

In this chapter, we have given preliminary consideration to potential interventions that could contribute towards at least one of the following high-level objectives:

• taking action to address the sources of Apple’s and Google’s market power, with a view to reducing barriers to competition or otherwise opening up markets to greater competition
• addressing harms to competition and consumers that may result from Apple’s and Google’s market power

Taking action to address the sources of Apple’s and Google’s market power

We are considering a range of interventions aimed at reducing the barriers to effective competition that we have identified to date in activities where we consider that Apple and Google exercise a position of market power; namely mobile operating systems,^{[footnote 591]} native app distribution, and mobile browsers. The types of interventions considered below may drive greater competition both within mobile ecosystems and also between Apple’s and Google’s respective mobile ecosystems. For example, in Remedy Area 1 we consider interventions that would make switching between devices more straightforward (between ecosystem competition), while in Remedy Areas 2 and 3 we consider interventions to make it easier for third parties to compete directly with Apple’s and Google’s app stores and browsers (within ecosystem competition).

With this objective in mind, we have identified several interventions designed to allow third parties to carry out activities that are currently reserved to only Apple or Google within their ecosystems, which can harm mobile users by tying them into other services as a result of their choice of device. Such changes may need to be supported by interventions to require interoperability that would allow access key functionalities, usually through use of APIs.

We have provisionally found that there are a number of aspects of the mobile ecosystem where interoperability is restricted, giving Apple and Google a ‘gatekeeper’ role for certain activities. This could be addressed through requirements on Apple and Google to improve interoperability, enabling more choice for key aspects of mobile ecosystems where currently either no choice is given or choice in practice is limited. This could include removing and amending existing restrictions from using third-party app stores or third-party payment systems, for example.

We are interested in the extent to which such interoperability remedies can be designed in a manner that mitigates potential downsides, including circumstances in which third parties would be able to interoperate with the mobile device without introducing security and privacy concerns. We also recognise that the current integration of mobile ecosystems may bring benefits both for user experience and for the overall integrity of the system, and that any interventions should not make it unreasonably difficult for Apple and Google to maintain these benefits. We will also be assessing the practical and commercial considerations associated with the introduction of new forms of interoperability – for example, where interoperability would come at a cost or require Apple and Google to introduce new processes, the way in which the costs would be recovered, and the terms on which different users would engage with the mobile ecosystems.

We have also identified a range of demand-side interventions targeted at empowering consumers to make meaningful and informed choices, which in many cases would make it easier for users to choose alternatives to Apple and Google should they wish to do so. Currently Apple’s and Google’s ecosystems are heavily integrated and, even where there is in theory a choice, the large majority of users stick to the services that are set as a default on their device, including Apple’s and Google’s own browsers and Google’s Play Store, which is pre-installed on Android devices. The design of choice architecture and the approach to determining defaults is another key consideration of our study as we have found that their design can heavily influence consumer decision making within mobile ecosystems. We are therefore considering a range of potential interventions to prevent Apple and Google from benefiting unduly from these biases, such as prompting consumers to make an active choice in setting a default for a key product and making it easier to exercise or alter such choices.

These interventions may be less likely to result in the kind of privacy or security risks associated with interoperability. However, to the extent that these markets will nevertheless remain heavily influenced by the power of defaults, a requirement to introduce alternative forms of choice architecture may on its own have a more limited effect on consumer behaviour. For these reasons, the ability to test and trial remedies prior to their implementation, as well as monitor their effectiveness on an ongoing basis, will be key to ensuring that remedies are designed as effectively as possible.

In addition, whilst some forms of intervention on choice architecture can deliver benefits for users, such as making it easier for those users who wish to exercise choice, too many choice screens can also introduce burdens on consumers which may also affect the effectiveness of the intervention.

Addressing harms to competition and consumers that may result from Apple’s and Google’s market power

As set out in Chapters 3 to 6 of this interim report, we have identified a number of ways in which the exercise or exploitation of market power by Apple and Google may currently be resulting in harm to competition and consumers. The interventions discussed in this section are aimed at preventing that harm from occurring.

First, Apple and Google may be able to leverage their market power in a way that favours their own businesses in markets that rely on mobile ecosystems. This conduct makes it more difficult for third parties to compete in related markets. Key areas where this may take place include where Apple and Google offer their own apps in competition with third parties, and in respect of browsers, where control of the browser (and its underlying browser engine) can be used to influence other markets. For example, restrictions on user tracking can make display advertising less effective and distort competition in digital advertising markets.

Many apps are able to work within and complement Apple’s and Google’s mobile ecosystems through interoperability. As discussed above, this is specifically by gaining access to APIs, which are pieces of software that enable developers to access data and perform actions across platforms. As discussed in The role of Apple and Google in competition between app developers, in principle, Apple and Google appear to have strong incentives to provide access to APIs to third-party developers as they benefit from having a large variety of apps available in their ecosystem. However, we have identified some circumstances where access to APIs is applied inconsistently to different parties operating within each of Apple’s and Google’s mobile ecosystems, and in particular, where Apple and Google have greater access to functionality than third-party competitors in downstream markets.

We have therefore considered whether there are interventions that could address the use by Apple and Google of their market positions in operating systems to treat the services they provide on mobile devices more favourably than those of third parties, such as through unreasonable restrictions on interoperability. This has been described as a restriction on ‘equitable interoperability’. Equitable interoperability is a concept which describes the form of interoperability where entrants are given access to a platform on directly comparable terms to the platform operator, in this case Apple and Google, making the market more open and contestable and effectively prohibiting unfair self-preferencing and undue discrimination against third parties.^{[footnote 592]} We found a number of examples – most of which relate to Apple – where competitors in downstream markets, such as providers of apps or connected devices, are not permitted to operate with the equivalent level of functionality as is provided to Apple’s or Google’s own products.

We have also considered whether specific interventions could limit the extent to which Apple’s and Google’s market power in the supply of mobile operating systems, in native app distribution, and in mobile browsers, is leading to harm to competition and consumers. In addition to ensuring that users and third parties can access Apple’s and Google’s platforms on fair and reasonable terms, this may include measures to improve the confidence and trust that other market participants have in Apple’s and Google’s decision-making. To be consistent with the broader principle that large digital firms such as Apple and Google should provide appropriate transparency to users, our initial view is that there should be a requirement to provide clear, relevant, accurate and accessible information to app developers both in relation to app review processes, but also in relation to how, for example, rankings on app stores are determined.

Finally, given the broad spectrum of interconnected products and services that are incorporated within Apple’s and Google’s mobile ecosystems, we have also considered the potential role of separation remedies.

Separation within an ecosystem is intended to overcome the conflicts of interest that can arise from operating multiple businesses within a mobile ecosystem, and therefore prevent the extension of a market position from one area of market strength into a related activity by removing the incentive to do so. In the course of this market study, and also in submissions to other investigations (including outside the UK), a number of stakeholders have proposed the use of such remedies. For example, we were asked to investigate requiring Google to sell Android and the Play Store, an intervention proposed in a recent academic paper. We have also considered whether a similar intervention in relation to Apple may bring benefits, for example, if it were required to sell its App Store or run it independently.

At this stage, we consider that the clearest case for there being benefits from separation in the markets in this study would be a form of separation of Apple’s and Google’s own app development from their wider mobile ecosystems. The separation of app development would have the objective of addressing the ability and incentive of Apple and Google to self-preference their own apps. Separation of app development would be a more intrusive alternative to the interventions above of more equitable interoperability, or requiring fair and reasonable terms for third parties to access the mobile ecosystems.

We set out the potential benefits and costs of this form of separation further in our discussion of potential interventions under Theme 4 below. Although we have considered other forms of separation, our initial view is that they would result in significant costs and might adversely affect user experience, and we have not seen evidence of sufficient benefits to justify such costs.

Potential benefits and costs from intervention

We have identified a range of potential interventions below. These interventions would only be appropriate if the benefits of such measures to competition and consumers are sufficient to outweigh any costs. We expect that introducing more competition or choice within mobile ecosystems could bring a number of benefits for users of mobile devices, which are discussed in more detail in Chapters 3 to 6. These include:

• increased potential for entry and expansion of competitors in the mobile ecosystem, potentially unlocking transformative innovation
• improved user choice for apps resulting in innovation and better user experience
• lower prices to consumers with regard to devices, in-app purchases and subscriptions, and goods and services across the economy that rely on search advertising
• Improved consumer user experience from interventions that would result in improved functionality of third-party apps and from improved experience for users, including access to better web app functionality and additional cloud gaming services

We also recognise that there are a number of potential risks and increased costs from interventions in these mobile ecosystems, which have been highlighted by Apple and Google as well as some other stakeholders. These include:

• Increased security risks: design and stewardship of mobile ecosystems plays an important role in protecting consumers from security risks, for example by checking apps do not contain malware. In particular, some measures which allow more choice or competition within an ecosystem could in principle result in weaker protection for the security of users’ mobile devices. This may be a particular concern where security is optimised across the ecosystem, and where changes in one part of the ecosystem could therefore have an adverse effect on the integrity of the system more generally. We recognise that this is an important risk and one that needs to be assessed on a case-by-case basis across the different potential interventions
• Privacy risks: the operation of app stores and browsers can also play an important gateway role in protecting consumers from privacy risks, for example by limiting the ability of apps to access and use personal data without appropriate consent, or by preventing providers of digital advertising services from using so called ‘finger printing’ techniques. Therefore, there is a risk that poorly designed interventions relating to how content is consumed on mobile devices could result in weaker consumer protection against privacy risks
• Risk of worse user experience: users greatly value the products and services accessed through their mobile devices. Any measures to prevent Apple or Google giving an advantage to their own apps and services could in principle inhibit popular or quality apps and services, or could worsen the user experience if they resulted in a more fragmented mobile ecosystem
• Consumer trust: a successful mobile ecosystem relies on consumer trust in being able to safely and securely download apps, including from smaller or lesser-known app developers. Any adverse effects on consumer trust from a poorly designed intervention would be likely to have a negative impact on users’ willingness to engage with the mobile ecosystem, which could reduce the benefits that they obtain from their mobile devices

We highlight our initial views on these points as relevant in relation to the potential interventions below, and invite feedback to support our further assessment in the second half of the study.

Overview of potential interventions

The section below summarises the potential interventions that we consider could address the competition concerns we have identified to date in relation to mobile operating systems and devices, native app distribution, mobile browsers and browser engines, and competition between app developers on mobile devices. These potential interventions will include remedies aimed at addressing the source of Apple’s and Google’s market power, and also remedies targeted at the harms that result from the ability to exercise market power. We consider interventions relating to each of our 4 themes in turn, before discussing potential interactions between them.

Given the cross-border nature of the issues identified, we also expect that some of the potential interventions we have identified may be more effectively and efficiently implemented by the firm on a global basis, rather than being implemented in only one territory. For instance, Google has announced that, if the CMA were to accept Google’s commitments in relation to the CMA’s investigation into its Privacy Sandbox, Google will apply these changes globally.^{[footnote 593]} By contrast, we expect that other interventions under consideration in this study could be readily implemented in the UK alone, independently of whether other jurisdictions were to require similar changes.

Remedy area 1: interventions relating to competition in the supply of mobile devices and operating systems

As described in Competition in the supply of mobile devices and operating systems, there are material barriers to switching between devices using the iOS and Android mobile operating systems, and Apple and Google both benefit from significant barriers to entry and expansion faced by rival providers of mobile operating systems. These features contribute towards there being limited user-driven competition between devices using different mobile operating system, with Apple’s iOS devices dominating sales of high-priced devices and mobile devices using Android dominating sales of low-priced devices.

This section provides a summary of potential interventions that could be targeted at reducing these barriers to competition. By improving the ability of users to switch between mobile operating systems and increasing the threat posed by potential rivals, these interventions could enhance the level of competitive constraints between devices using different mobile operating systems. In turn, these remedies could lead to customer benefits in the form of higher quality products and services, greater innovation and lower device prices. However, we are also aware of potential adverse effects associated with these interventions, such as technical constraints, dampening incentives to innovate and the possibility of privacy or security risks. These factors will need to be accounted for in the design of any remedies.

Remedies targeted at making switching between operating systems easier

The first set of possible interventions are demand-side interventions focused on making it easier for users to switch between mobile devices that come with different operating systems. These measures are aimed at ensuring that many of the key features of mobile ecosystems that users value (for example, data, apps, app content and subscriptions) can be easily transferred to and subsequently accessed on an alternative device.

A number of potential interventions that could reduce these potential barriers to switching are summarised below:

• As described in Competition in the supply of mobile devices and operating systems, we understand that the process of transferring existing apps and user data is more challenging when switching from iOS to Android devices than the reverse. As such, we are exploring interventions that would facilitate this functionality, for instance by ensuring that Apple provides necessary APIs to enable iOS users to migrate their apps and data to Android devices
• We are also interested in understanding the likely impact of interventions that would enable users to more easily manage their subscriptions with app developers across multiple devices and recover access to paid-for apps and in-app content after switching. This could be achieved, for example, by requiring Apple and Google to allow users to make in-app payments to their app provider directly or allow greater choice of third-party payment providers, which might make transferring subscriptions between iOS and Android devices more straightforward
• We have heard concerns regarding the lack of interoperability of Apple’s first-party products or services, such as apps or connected devices, which contributes to consumer lock in within its ecosystem. Potential interventions could include:
  • increasing the availability of Apple’s first-party apps and services on Android devices
  • allowing Apple’s first-party apps (for example, iMessage) and connected devices (for example, the Apple Watch) to interoperate fully with equivalent features of Android devices

Some concerns have been raised regarding the implications of any such interventions, particularly in relation to Apple’s first-party products and services. Apple stated that investing in developing first-party apps and services only for Apple’s own products enables it to offer a better user experience and that the availability of Apple’s apps and services solely on Apple’s products serves to differentiate them in the competitive device market. It is therefore possible that these interventions could dampen Apple’s incentive to innovate in the future, particularly if these products are provided for free, as the benefits of its innovation would be shared with third parties.

Furthermore, Apple stated that its connected devices offer interoperability with third-party devices and services to the extent possible and are operable on a standalone basis. Technical constraints could arise where the use of proprietary technologies that are integrated into the devices are necessary to perform certain functionalities. As a result, there may be legitimate technical constraints associated with rolling out functionality interoperable with Android devices.

We consider the case for interoperability to be greater in respect of functionality which is both directly helpful in overcoming identified barriers to switching and yet not highly, or recently, innovative. We are therefore interested in understanding the extent to which specific first-party apps and connected devices that users appear particularly to value, such as iMessage and FaceTime, fit these criteria and, if so, whether a clear technical solution or alternative would be available to support interoperability without introducing privacy or security risks.

Remedies targeted at barriers for rival providers of mobile operating systems

As described in remedy area 3 below in relation to browsers and browser engines, any remedies that lead to more widespread uptake of web apps – which can in principle operate on any operating system – could have the broader effect of reducing the barriers to entry for new operating systems.

However, app developers do not generally regard web apps as currently being a viable alternative to the development of native apps that are downloaded through the major app stores. As a result, the current providers of mobile operating systems must offer a wide range of native apps to attract users. Whilst differentiation at the operating system level could lead to improved functionalities and user experience, it may also lead to significant unavoidable costs for developers (for example, costs of redeveloping their Android and iOS apps to work on that new operating system), which may ultimately be borne by consumers. There is evidence that this is a significant barrier to entry for a completely new and distinct mobile operating system.

In this respect, we note that the availability of Android on an open-source basis has, in principle, provided a route into the market for new operating system providers. However, the experience of Amazon’s Fire OS, which runs on a forked version of Android, serves to illustrate some of the practical challenges associated with entry using a fork of Android. One particular concern we have identified relates to claims that over time Google has chosen to include important features and functionality in Google Mobile Services rather than the open-source Android code.^{[footnote 594]}

If this is the case, such changes have the potential to harm the ability of suppliers of versions of Android that do not include Google Mobile Services to attract app developers and, in turn, users, by making it more difficult for developers to create apps that are compatible with those versions of Android. This is consistent with feedback we have received from developers, that they would have to do a large body of work to make their apps compatible to use on Fire OS devices or other devices utilising forked operating systems.

A potential intervention could therefore involve ensuring that core features or functionalities, such as basic ‘push notifications’, are available within the open-source version of Android. This intervention would significantly reduce the cost to developers of making their apps available on versions of Android not using Google Mobile Services. If this meant that apps developed for one Android system could be made more easily available across alternative operating systems, it could overcome an important barrier to entry and expansion for rival providers of mobile operating systems.

Google told us that housing APIs in Google Mobile Services allows Android devices to have the most up to date version of these APIs, ensuring that apps that rely on these APIs work on all Android devices with GMS, even when the manufacturer does not update the underlying Android operating system version. Furthermore, we are mindful that Google has invested significantly in the development of Android and continues to incur significant ongoing expenses associated with this operating system. Sharing the benefits of these investments with Google’s rivals could dampen Google’s incentive to invest and innovate in its platform. We also welcome views on any read across between imposing such interventions on Google in respect of its open-source version of Android, and whether interventions could be appropriate in respect of Apple’s proprietary operating system.

Another area of concern relates to the impact of Google’s licensing agreement with respect to Google Mobile Services, which includes the Play Store, and Google’s placement and revenue sharing agreements associated with its Chrome, Google search, and in some cases Play products. In addition to affecting competition in the distribution of native apps and the supply of mobile browsers, as discussed further below, these agreements are conditional on manufacturers entering Google’s Android Compatibility Commitment, which can harm the ability of suppliers of forked versions of Android to attract device manufacturers. Specifically, this conditionality deprives manufacturers of:

• the availability of a collection of popular Google apps including Play Store, Google Maps, YouTube, and Gmail
• a significant income stream from the placement and revenue sharing agreements, which alternative providers could not match

It is therefore possible that interventions which involve making:

• Google’s collection of popular apps
• Google’s placement and revenue sharing agreements associated with its Chrome and Google search products available on forked versions of Android could improve competition between devices using different mobile operating systems.

Google has told us that there is a material risk that its apps would not run properly on devices using forked versions of Android and that this would harm its reputation. As a result, we are interested in understanding the extent to which these technical and compatibility issues could be overcome.

Finally, as an alternative to the remedies discussed above, it has been suggested that a separation remedy which prevents providers of operating systems from operating app stores would address conflicts of interest. We were told this separation remedy would also deliver additional benefits, such as preventing Apple and Google from exerting full control over their ecosystems.[^595] A different separation remedy was proposed by Oracle, which suggested that an ownership separation remedy between Google and Android, including the Play Store, would limit Google’s dominant position in mobile ecosystems and enhance competition and consumer choice across markets.^{[footnote 596]} A recent academic paper also advocated this intervention,^{[footnote 597]} justifying it on the basis that separation would ensure competition takes place on a level playing field and mitigates the risk of circumventing other remedies.

However, our initial view is that similar benefits could be delivered through less intrusive interventions. As a result, we are not currently minded to exploring these separation remedies in further detail, although we welcome views regarding their potential effectiveness and proportionality, including any adverse effects associated with them.

Box 7.1: views sought for Remedy Area 1

• In respect of making it easier for users to switch between mobile ecosystems, we are interested in views on:
  • the likely effectiveness of these potential interventions in addressing the competition concerns raised in Competition in the supply of mobile devices and operating systems
  • the extent of potential adverse effects associated with these interventions, such as technical constraints, dampening incentives to innovate and the possibility of privacy or security concerns, and what would be required to mitigate these risks
  • whether there are specific examples of first-party apps or connected devices that would benefit from greater levels of interoperability and whether technical solutions are available to deliver these interventions
• In respect of overcoming the barriers to entry and expansion faced by rival providers of mobile operating systems, we are interested in views on:
  • the likely effectiveness, and potential adverse effects, of interventions associated with ensuring that core features or functionalities are available within the open-source version of Android
  • whether making Google’s collection of popular apps, and Google’s placement and revenue sharing agreements associated with its Chrome and Google search products, available to providers of forked versions of Android could improve competition

Remedy area 2: interventions relating to competition in the distribution of native apps

As described in Competition in the distribution of native apps, the App Store on iOS and Play Store on Android are key gateways through which app developers can distribute native apps to users on mobile devices. Various stakeholders have called on us to explore interventions that would lead to native apps being made available to users through alternative distribution models. Recent draft legislative proposals in the EU and US have also included requirements to improve users’ ability to access third-party app stores and sideload third-party apps on iOS and Android devices and to allow users to alter their default settings.^{[footnote 598]}

The potential benefits from promoting alternative sources of competition in the distribution of apps are significant. Creating new mechanisms through which users can discover and engage with apps would improve choice for users could have the effect of reducing the extent of Apple’s and Google’s market power in app distribution. The effectiveness of such interventions will also have consequences for the balance of benefits and costs in respect of Remedy Area 4 which relates to how Apple and Google are able to exercise or exploit market power over app developers.

Interventions aimed at promoting this source of competitive constraint would have to overcome existing demand-side and supply-side barriers faced by alternative app stores. Apple prohibits all alternatives to the App Store for native app distribution on iOS, giving it a monopoly over native app downloads on its devices. While Google allows certain alternative distribution channels on Android devices, the data set out in Competition in the distribution of native apps indicates that the Play Store still retains [90% to 100%] of native app downloads across Android, HMS and Fire OS devices, in part due to a combination of barriers to competition that are inherent in the market, and in part due to agreements and initiatives implemented by Google.

Due to these differences in the key barriers to competition that we have identified in relation to each of Apple’s and Google’s ecosystems, we have identified a separate list of potential interventions for promoting greater competition to each firm.

For Apple, we have identified the following potential interventions to create alternative distribution channels on iOS for native apps:

• Requiring Apple to allow alternative app stores on iOS: alternative app stores could be made available through sideloading from the web, or Apple could be required to allow app stores to be available for download from its App Store. Enabling alternative channels through which users can discover and engage with apps could lead to greater choice for users and increase competitive pressures on the App Store. In turn, this could also lead to better terms of use for developers, including on price, and better outcomes for consumers including lower prices for apps.
• Requiring Apple to allow sideloading of native apps on iOS: as is already technically possible on Android devices, a requirement to allow sideloading of apps on iOS would provide an additional source of potential competition to the App Store.

Despite sideloading and alternative app stores being permitted on Android, these alternative distribution models have had relatively limited success to date within Google’s ecosystem. As a result, the 2 measures described may not on their own be sufficient to transform the market for native app distribution within Apple’s ecosystem. In practice, if either of these measures were taken forward, they may need to be complemented by additional interventions, including potentially the measures described below, to ensure that users are not unduly discouraged from accessing alternative distribution channels.

We have identified several potential interventions for Google, which are intended to ensure that the alternative distribution channels that are allowed are able to compete on a more level playing field with the Play Store:

• Breaking the link between Google’s Play Store and the payments made under its Placement Agreements and Revenue Sharing Agreements: at present, these payments relating to Chrome and Google Search products are conditional upon several agreements, including the pre-installation and prominent placement of the Play Store, which can make it more difficult for alternative app stores to attract users.
• Removing restrictions on accessing third-party app stores through Google’s Play Store: making third-party app stores available on both the App Store and Play Store could materially widen users’ access to alternative app stores and also provide a mechanism for alleviating some of the security concerns.
• Requirements to make sideloading easier: we understand that sideloading on Android devices involves an extended process and the lowering of Android’s security settings, and that this process is the same regardless of the likely risk posed by the app developer. Google said that the additional steps, at least in the first instance of sideloading, are both modest and required for security reasons.

As we found in Competition in the distribution of native apps, in addition to the practices described above, one of the greatest barriers to alternative app stores succeeding on Android devices is the existence of strong indirect network effects, whereby an app store has to achieve a critical mass of app developers to attract users and vice versa. We are interested in understanding the extent to which this ‘chicken and egg’ problem would continue to pose a challenge for the development and growth of alternative app stores if the concerns described above were addressed. In particular, we are interested in the impact on niche or specialised app stores that would require a lower critical mass of apps to gain traction with users.

Whilst these interventions have the potential to deliver significant benefits, a number of concerns have been raised regarding their potential adverse effects. Apple raised concerns regarding the very significant potential security and privacy implications of permitting third-party app stores to operate on iOS devices. Specifically, Apple told us that, if third-party app stores were able to operate on iOS devices, the level of protection against malware would move from Apple’s high standard of review to the lowest standard offered by a third-party app store, creating a risk for the individual device and the overall ecosystem. Furthermore, Apple submitted that a less secure ecosystem, in which users do not feel safe downloading apps, would reduce developers’ incentives to innovate because users would be less likely to take a chance on apps coming from new or lesser-known developers.^{[footnote 599]}

These security concerns also apply to sideloading. In fact, there appears to be a general consensus that sideloading carries greater potential privacy and security threats than downloading apps from a store, with Apple producing a report which concludes that these threats are increasingly common and predominantly present on platforms that allow sideloading.^{[footnote 600]} This is consistent with submissions from Google, which told us that sideloading can be used by malicious actors to avoid the security checks that app stores perform and that users most likely do not have the technical ability to scan sideloaded apps for malware or viruses themselves.^{[footnote 601]}

We agree that, without appropriate safeguards, there are potential security and privacy risks associated with permitting third-party app stores and sideloading. We are therefore interested in understanding whether safeguards could be introduced to mitigate these security risks and preserve the integrity of the operating systems and users’ experiences, for example through certification or alternative arrangements for security verification that prevent the installation of harmful apps.

Apple also has raised concerns that interventions could lead to developers free-riding on its significant investments into its mobile ecosystem.^{[footnote 602]} Specifically, Apple argued that the mere fact that it is large and profitable does not mean that developers should be allowed to make use of its services without abiding by reasonable rules or compensating Apple.

We agree that, in principle, free-riding is a legitimate concern. However, our financial analysis of Apple’s App Store suggests that the scale of its profits may allow sufficient room for competitive entry. Furthermore, app developers contribute greatly to the attractiveness and value that users attribute to Apple’s ecosystem, which Apple benefits from through the high prices it charges users for its iPhones. We also note that Google has continued to invest in its mobile ecosystem and app store without imposing outright prohibitions on the presence of alternative app stores or sideloading. We therefore consider that Apple is likely, under most plausible scenarios, to retain strong incentives to maintain investment in iOS and the App Store. In fact, these incentives may become even stronger if it needs to attract consumers who have alternative options.

Finally, as an alternative, or complement, to measures targeted at overcoming barriers to sideloading and accessing alternative app stores, we are considering potential interventions to support the wider development and use of web apps, as discussed in Chapters 4 and Competition in the supply of mobile browsers. We understand that, although app developers do not generally regard web apps currently as a viable alternative to the development of native apps for download through the major app stores, this is in large part because of a combination of restrictions and limitations of functionality within Apple’s ecosystem, which undermines the incentive for developers to invest in web apps across both ecosystems.

We therefore consider that requirements on Apple that lead to improved support for web apps within its ecosystem could also serve to increase the competitive constraint that they provide to both the App Store and the Play Store. Potential interventions that could lead to greater development and use of web apps are discussed within Remedy Area 3.

Box 7.2: views sought for Remedy Area 2

In respect of overcoming existing demand-side and supply-side barriers faced by alternative app stores, we are interested in views on:

• how to overcome any default biases associated with the preinstallation of a prominently displayed app store;

• the likely impact of breaking the link between Google’s Play Store and the payments made under its Placement Agreements and Revenue Sharing Agreements in relation to Google Search and Chrome;

• the extent to which indirect network effects would continue to pose a challenge to alternative app stores if other concerns were addressed;

• whether safeguards could be introduced to mitigate any security risks associated the use of alternative app stores to preserve the integrity of the operating systems and users’ experiences and if so, how these safeguards could be designed.

In respect of overcoming barriers associated with the use of sideloading, we are interested in views on how effective sideloading could be at increasing competition to the App Store, and whether safeguards could be introduced to mitigate the security risks.

Remedy area 3: interventions relating to competition in the supply of mobile browsers and browser engines

In Competition in the supply of mobile browsers, we identified a wide range of reasons for Apple’s and Google’s market power in the supply of mobile browsers and browser engines within their respective ecosystems, and potential harms that could result from that market power. We are considering 3 potential remedy areas that could address these harms:

• First, by making it easier to switch browser, resulting in greater competition between browsers;

• Second, allowing for more effective competition for browsers and web app developers on iOS by requiring Apple’s operating system to allow third-party browser engines on iOS, or in the alternative to require Apple to allow web app developers greater interoperability with its mobile ecosystem, to allow them to better compete with native app developers;

• Third, addressing the ability of Apple and Google to exercise market power by using browser settings to favour other parts of their mobile ecosystems, in particular digital advertising.

Remedies targeted at making switching between browsers easier

While there are a wider range of alternative browsers available, the large majority of mobile users continue to use Safari (on iOS) and Chrome (on Android) – it is possible that this may be, in part, due to certain barriers to changing default settings. We have identified 2 potential interventions to address this.

• The first would be requirements that make it more straightforward for users to change the default browser within their device settings. Our understanding is that switching the default is currently more complex than it needs to be, with multiple stages for the consumer to navigate through, which could reduce the likelihood of users trying out alternative browsers.^{[footnote 603]}

• The second would be to require that users’ choices for the default browsers are respected in all instances, and there are not disproportionate triggers and prompts to revert to Apple’s and Google’s browsers. As an example, we understand that Apple’s and Google’s voice assistants – Siri and Google Assistant – which are integrated with the operating system, will always revert to using Safari and Chrome respectively, regardless of the choice of default browser the user has made for their device.

It appears that these 2 interventions would be relatively low cost, and would not obviously introduce any significant privacy or security risks.

An additional, and possibly more intrusive intervention would be to mandate certain forms of choice screens to be displayed to users, or other requirements relating to the way choices are displayed. This type of intervention has been applied as a result of the European Commission’s Android Decision,^{[footnote 604]} and, through its market study into online platforms and digital advertising, the CMA considered that it could have benefits in promoting competition in the market for general search.^{[footnote 605]}

As discussed in Competition in the supply of mobile browsers, Google has also introduced choice screens and prompts for browser downloads and browser defaults. However, the choice architecture of Google’s existing choice screens may be sub-optimal in engaging consumers, for example due to the circumstances of when and how they are shown.^{[footnote 606]} The ‘disambiguation boxes’ which can prompt users to consider changing the browser default have also been removed in the latest Android 12 update.^{[footnote 607]} Apple does not offer any choice screens relating to browser defaults.

Well-designed choice screens have the potential to bring significant benefits where they allow markets to work better by increasing consumer awareness of alternatives and making it easier for users to make meaningful and effective choices that are in line with their preferences.^{[footnote 608]} However, there are also risks that, in practice, such choice screens may have limited impact on the browsers chosen as defaults and then used by users, and so should be considered alongside any interventions that would improve the competitive offering of third-party browser developers.

Google’s commercial arrangements with device manufacturers can include Chrome being pre-installed as the default browser on third-party devices,^{[footnote 609]} and some stakeholders have called for Google to be precluded from such arrangements, given its market power in both mobile operating systems and browsers. In considering restrictions on pre-installation and default of own browsers, it would be necessary to also take into consideration whether comparable interventions would be appropriate in respect of Apple’s closed ecosystem. Apple also has market power in both mobile operating systems and browsers; only Safari is pre-installed on iOS devices and it is always the default browser upon purchase of the device.

Any measures to limit Apple’s and Google’s pre-installation of their own browsers and setting them as defaults would also require redesigning choice architecture to allow users to make a choice in the absence of a default or pre-installation. There is a fine balance to be struck to ensure that a choice screen for browsers is designed in a way – and presented at an appropriate frequency – to ensure the competitive benefits outweigh the cost of introducing the mechanisms, and the possible frictions and burdens to users from being faced with choice screens too often. As part of any responses to our consultation, we would welcome views on the proportionality of such measures.^{[footnote 610]}

Remedies designed to enhance functionality and interoperability of browsers

We concluded in Competition in the supply of mobile browsers that a significant contributing factor to the market power of Apple and Google in relation to mobile browsers is the restrictions that they – and in particular Apple – are able to place on rival browsers. We have therefore identified a number of potential interventions aimed at removing these restrictions. These interventions are summarised below:

• Apple’s restrictions on competing browser engines: Apple does not permit the use of third-party browser engines within its mobile ecosystem – all browsers are required to use its browser engine, WebKit. We have not identified compelling evidence to date that suggests that, for dedicated browser apps, the potential impacts on competition or consumers from Apple’s WebKit restriction are justified on security grounds. We are therefore seeking to assess the merits of a requirement for Apple to allow alternative browser engines on iOS, at least for dedicated browser apps. This could be implemented by requiring Apple to permit third-party browser engines to interoperate with its iOS operating system, subject to those browser engines meeting conditions that would address any risks that might arise from a greater choice of browser engines (for example, complying with appropriate quality and security standards).
• Restrictions on the functionality of all browsers on iOS: as a possible alternative to requiring Apple to allow alternative browser engines, Apple could be required to enable access to specific features for browsers using WebKit on iOS, including supporting web app functionality. This could bring benefits from web apps providing a stronger competitive constraint on the App Store and the Play Store, while also reducing barriers to entry in the supply of new operating systems. We agree that, without appropriate safeguards, there are potential security and privacy risks associated with greater third-party interoperability with the iOS ecosystem.^{[footnote 611]} We are initially of the view that the costs and security risks associated with requiring access to core functions on the phone, such as push notifications, screen rotation and full screen capability should not be disproportionate.^{[footnote 612]}
• API access for rival browsers: we also have concerns regarding the differences in APIs that are available to Safari and Chrome by comparison with third-party browsers. This could be rectified by a requirement for Apple and Google to ensure that all browsers within a particular mobile ecosystem have access to directly comparable features and functionality through APIs^{[footnote 613]}. To the extent that some of the APIs and other functionality may be proprietary or increase costs for Apple and Google, such an intervention would also need to mandate the terms of such interoperability in a way that provides for access on fair and reasonable terms, potentially with guidance about how this would work in practice.

In its responses to our questions, Apple raised a number of concerns that introducing third-party browser engines, or increasing the interoperability of WebKit, could introduce privacy and security risks. Apple submitted that Webkit offers the best level of security, and has cautioned that ‘mandating use of third-party rendering engines on iOS would break the integrated privacy, security, and performance model of iOS devices’. Apple considers that by requiring apps to use WebKit, it is able to address security and privacy issues across all browsers on the iPhone for all iPhone users, quickly and effectively, and that ‘this is especially true when it comes to security vulnerabilities that have to be fixed as soon as possible in order to mitigate potential exploits by bad actors’.

However, as discussed in Competition in the supply of mobile browsers, the evidence that we have seen to date does not suggest that there are material differences in the security performance of WebKit and alternative browser engines. Further, and as discussed in Competition in the supply of mobile browsers, other parties have suggested that the impact of a browser engine on overall device security can, to a certain extent be limited.

We recognise Apple’s statements on the importance of security, and that this is a key consideration. We have also provided some initial views from other stakeholders, who suggest that security risks are manageable, including based on experience with Android and Google’s Blink browser engine, which do not have the same restrictions.

Remedies designed to address ability to exercise market power in browsers

Whilst digital advertising markets are outside of the scope of this study, the ability to exercise market power in these markets through the design of the browser results directly from our findings in Competition in the supply of mobile browsers.

In general search, Safari sets Google Search as the default, and, where the Google Search app is pre-installed on Android devices, users are presented with a choice screen.^{[footnote 614]} However, evidence suggests that this has as yet had limited effect on Android users choosing alternative search engines.^{[footnote 615]} In the CMA’s market study into online platforms and digital advertising, it considered interventions targeted at addressing Google’s market power in general search. Therefore, a further benefit of remedies to address the market power of Apple and Google in browsers may be to make competition to Google’s search engine more effective.

The CMA has separately considered the potential for Google’s design of its Privacy Sandbox Proposals within Chrome to favour Google’s own businesses, and has secured modified commitments from Google to resolve those concerns. These proposed commitments require Google to implement certain measures, designed to ensure appropriate data separation and to address the potential for self-preferencing through the design of the Privacy Sandbox Proposals. The CMA is now consulting on these modifications.^{[footnote 616]}

We have also identified concerns in Chapters 5 and The role of Apple and Google in competition between app developers that Apple’s design of measures that give users greater control over their personal data (ITP and ATT) may also serve to favour its own digital advertising business over those of third parties. These concerns result from the specific design and implementation of these measures. Potential interventions to address these concerns are considered within Remedy Area 4.

Whilst we are considering interventions that could address these effects of market power in browsers, this illustrates that any remedies designed to address the potential sources of market power for Apple’s and Google’s browsers set out in Remedy Area 3 could also have potential benefits in reducing the effect of that market power on competition in digital advertising markets, including search advertising.

Box 7.3: views sought for Remedy Area 3

In respect of the interventions outlined in this section, we are interested in views on:

• the likely effectiveness of these interventions in addressing the competition concerns raised in Competition in the supply of mobile browsers;

• the extent of security and other concerns, and what would be required to mitigate any costs associated with the intervention; and

• whether there are specific examples of restricted functionality or interoperability which have the greatest effect on third-party browsers, and therefore would be a priority for any intervention.

We are also interested in views on which interventions are capable of being tested and how such testing might be implemented.

We also invite views on whether changing default settings should be made easier and if so what approaches may be most effective in empowering users to change their browser default, and on whether choice screens and prompts can be an effective remedy in empowering consumers choice.

Remedy area 4: interventions relating to the role of Apple and Google in competition between app developers

In The role of Apple and Google in competition between app developers, we considered the effects of Apple’s and Google’s market power on competition between app developers and providers of other types of products and services in downstream markets. We found that Apple and Google affect competition in a number of ways, which may indirectly lead to higher prices for apps and in-app content, a worse user experience or reduced choice, and that users could miss out on innovative new products and services.

In this section we consider remedies which could be designed to address these potential harms.

Interventions designed to address ability to harm competition through the operation of the app store

In this section, we set out a number of interventions which could be directly targeted at addressing the ways in which Apple and Google are able to limit or distort competition, and therefore the harms that could arise. These are discussed in more detail below, but are focussed on requiring more equitable interoperability between Apple’s and Google’s mobile ecosystems and third-party app developers. We also have a particular concern about the way in which Apple and Google exercise the rule-making functions that they have in operating their respective app review processes.

Summarised below are the potential interventions we have identified to address Apple’s and Google’s ability to hold up competition through operation of their app stores.

We are considering the merits of ensuring that Apple and Google are not able to restrict third-party access to hardware and software unreasonably. To the extent that some of the APIs and other functionalities may be proprietary or increase costs for Apple and Google, this intervention might also need to mandate the terms of such interoperability.

Apple and Google have in some cases said that restricting access to APIs is justified where these APIs govern access to privacy and security sensitive functions. We agree that, without appropriate safeguards, there are potential security and privacy risks associated with greater third-party interoperability with the iOS and Android ecosystems, and appreciate that in some cases there may be legitimate reasons why third parties should not be allowed access. However, we have also heard views that privacy and security risks may not be sufficient to justify restricting interoperability.^{[footnote 617]}

We are also considering interventions that could reduce the ability of Apple and Google to provide their own apps with a competitive advantage through pre-installation and being set as the default option. In situations where pre-installation or default settings are creating or protecting a strong market position for a particular activity, a requirement may be that a device should not have pre-installed apps, or where pre-installation is in place, that it should be accompanied by appropriate choice architecture to make it easy to choose and switch to an alternative as the default. Pre-installation can limit consumer choice and lessen the competitive constraint faced by Apple and Google from third-party apps. We also recognise that the convenience associated with pre-installation and defaults can bring real benefits which are valued by the users of mobile devices, and generate consumer efficiencies in terms of time and cost of discovery and installation.

We are considering requirements for a fair and transparent app review process for determining whether native app developers can list their apps on the App Store and the Play Store. The app review process is an opportunity for Apple and Google to identify and address potential concerns with apps, such as user safety, inclusion of potentially harmful content, and reliable app functionality. However, it is also a process which affords them significant control over the app development process for all app developers.

Although we are not assessing individual complaints from developers as part of this market study, it is clear that the app review process means that Apple and Google have a gatekeeper role for native app developers. On that basis, it may be possible for Apple and Google to do more to: (i) ensure a consistent application of their relevant app developer guidelines; (ii) ensure a sufficient level of transparency over the reasons for any rejection of an app, or any requirement to make changes to an app as a condition of approval; and (iii) ensure that they deal with developers and device manufacturers on fair and reasonable terms, and do not unduly discriminate between or apply different standards to app developers.

Greater transparency should generate efficiency benefits, including reducing the potential for unnecessary delays in approvals for both new apps and upgrades, providing consumers with more timely access to greater quality products and services. Delays, or even risks of delays, can adversely impact business planning processes, launch dates, revenue generation, and ultimately investment decisions. Ensuring the app review process is not only clear and transparent, but also fairly designed and implemented, reduces Apple’s and Google’s potential to favour their own apps.

As a wider principle, these standards of fairness and transparency could potentially have broader application for any other review processes introduced within Apple and Google’s mobile ecosystems to support device security. For example, similar review processes could in principle be applied as a condition of supporting alternative app distribution channels as discussed in Themes 2 and 3 (for example, sideloaded apps, alternative app stores or progressive web apps).

A further possible measure would be to require Apple and Google to provide more transparency about their algorithms and in particular the factors that influence how apps are displayed on the app store. As with other markets where algorithms can have a material impact on customers, a lack of transparency about the basis for Apple’s and Google’s decisions can make it hard for some app developers to compete. We would also expect that this might include a requirement to give reasonable notice of any changes to the working of the algorithm which are likely to affect the ranking of apps and therefore demand for app developers’ services.^{[footnote 618]}

Apple and Google could be required to not unreasonably share information from one part of their business (the app store or app review process) to their app development businesses, which to some extent may involve formalising measures already likely to be in place. For example, there could be requirements about the access controls applied when sharing data between the relevant business units. This principle should apply whether or not Apple or Google have actually used information to advantage their own apps, because of the potential conflict of interest between these different functions within Apple and Google. Later in this chapter we also discuss how data restrictions could potentially also be achieved through more direct separation interventions.

We have discussed above the CMA’s investigation into Google’s Privacy Sandbox Proposals, and that Google has offered commitments that are designed to ensure consistent use of data by Google’s digital advertising businesses and third parties. We are concerned that Apple’s privacy initiatives (ITP and ATT) also result in differential treatment of Apple and third parties. In response to these issues, we are considering the merits of a requirement for consistent treatment of own apps and third-party apps for privacy purposes.

Additionally, we have some concerns that the ATT prompt in its current form does not empower users to make well-informed, meaningful and effective choices. As discussed in The role of Apple and Google in competition between app developers, Apple told us that the goal of ATT is to give consumers greater control over the sharing of their own data. Apple told us several stakeholders, including consumer protection associations and privacy advocates, welcomed ATT as a positive development for the industry. We believe that users benefit from greater privacy and control over the processing of their personal data. However, we are nonetheless concerned that the ATT prompt’s current choice architecture may not empower consumers to make fully effective decisions. We will consider further in the second half of the study whether any intervention might be justified that would: i) require Apple to provide equivalent attribution capabilities to third parties as it offers to users of its own advertising services, in order to level the playing field between Apple’s and third parties’ advertising services; and ii) consider whether any further guidance on how any prompt should be designed could help to enhance the privacy benefits by providing more effective and informed choice to users.

Finally, we will also consider if there is a case that Apple should amend its policy of imposing restrictions on cloud gaming apps, so that cloud gaming service providers could offer apps which allowed users to stream multiple different games without these games each needing a separate listing on the App Store. We will explore the extent to which a requirement not to unreasonably restrict cloud-based streaming apps may still allow Apple to impose rules targeted at achieving the security and quality of its devices.

In respect of cloud gaming, and as discussed in more detail in The role of Apple and Google in competition between app developers, Apple claims that its policies are justified on the grounds of security and privacy, as well as user experience and expectations.^{[footnote 619]} However, there may be other less restrictive ways in which Apple could ensure these protections are provided, for example through obligations imposed on the overall cloud gaming apps. The fact that Google allows cloud gaming apps to be distributed through the Play Store, without any indication that this has materially compromised user safety, also provides evidence that the issues identified by Apple may be able to be overcome.

These various interventions which target different parts of the app distribution process have a common purpose in improving competition in app distribution, including through reducing the ability of Apple and Google to self-preference in their dual roles as both app developer and app store owner. Collectively, these interventions could result in benefits to consumers through enhanced innovation and more intense competition throughout the entire process of app development and app distribution.

We also recognise the importance of app review processes in enabling Apple and Google to identify and address potential concerns with apps, such as user safety, and that without appropriate safeguards there are potential security and privacy risks associated with greater third-party interoperability with the iOS ecosystem. We recognise the stated intention of the steps being taking by both Apple and Google to provide consumers with greater choice and control over their personal data.

In the second half of this study we will be assessing the merits of these interventions, both individually and collectively to generate benefits to consumers without compromising privacy and security.

Interventions to address concerns with in-app payment systems

In The role of Apple and Google in competition between app developers, we considered concerns arising from the requirements on app developers to use Apple’s and Google’s payment systems for in-app transactions involving digital content. The concerns raised by developers include (i) app developers being prevented from choosing lower cost or higher quality alternatives for processing payments for digital content; (ii) app developers being ‘disintermediated’ from their users in certain respects; (iii) competition between Apple and Google’s own apps and rival apps being distorted; and (iv) the restrictions causing billing issues for users who switch between iOS and Android devices.

We are considering whether there would be benefits in interventions that would prevent Apple and Google from unreasonably restricting the choice of in-app payment services available to developers and users.

Allowing greater choice of in-app payment options would enable app developers to choose their own payment service provider and have a direct selling relationship with the user, rather than require them to exclusively use Apple and Google’s own payment systems. This intervention is likely to be of particular benefit to larger developers who place significant value on the flexibility of being able to use alternative payment systems, and we consider that developers who prefer to use the payment systems provided by Apple and Google should be free to continue to do so under this intervention, on fair and reasonable terms.

Some users may value being able to transact with Apple and Google via their payment systems for all their payments on their mobile devices so they are able to use a single set of payment details and deal with a single trusted point of contact. However, these benefits could be preserved if users are offered the choice between use of Apple and Google’s payment systems and alternative payment systems chosen by app developers. Alternative payment systems might also be able to offer users ‘one-stop’ tools to manage payments or subscriptions across different apps. This intervention would aim to enable these choices in a way that can drive competition and innovation in payment solutions for in-app payments.

Following this type of intervention, Apple and Google could seek alternative ways to collect a commission for use of their app stores. One of the risks of this intervention is therefore that Apple and Google find ways to introduce charges for use of their app stores that are less efficient or result in harmful unintended consequences. However, our current view is that there do appear to be viable alternative methods for Apple and Google to collect a commission for in-app payments in their app stores, while also allowing developers to handle these payments directly, for example through the use of reporting requirements and audit rights, or through an API. It is not clear that these alternatives would be prohibitively costly or challenging to implement and we consider that both Apple and Google have the ability to effectively enforce against any requirements that they impose through the use of their app review processes.

Allowing greater promotion of off-app payment options would require Apple and Google to allow developers to refer users within an app to alternative ways to pay content and subscriptions outside of the app, for example allowing them to provide a link to where prices are lower on a website. This would directly address concerns that Apple’s and Google’s anti-steering rules limit consumers’ access to the information they need in order to choose where best to purchase in-app content and subscriptions and also reinforce the market power of app stores as a way for users to discover and pay for content.

However, both Apple and Google argue that the anti-steering rules are necessary to prevent developers from deliberately encouraging customers to circumvent their payment systems at the point of purchase, and therefore prevent other distribution channels from free riding on their investments. As part of this consultation, we are considering whether or not Apple’s and Google’s anti-steering rules are wider in scope than is necessary.^{[footnote 620]}

We are also considering measures which restrict the potential for self-preferencing of Apple’s and Google’s own apps through requiring the payment of commissions from third-party apps active in sectors where Apple and Google also have their own first-party apps. To ensure that their own apps face the same competitive conditions when using their app stores as their rivals, Apple and Google could, for example, be required to: (i) allow apps to disable Apple’s and Google’s payment systems, so that any payments would have to be made off-app; and (ii) relax the anti-steering rules in relation to those apps where they compete downstream, allowing those developers to steer customers to alternative off-app payment options where the developers are not obliged to pay commission to Apple and Google.

However, this alternative is likely to only partially address concerns that downstream competition is distorted, as rival apps may still face disadvantages from the ‘frictions’ caused by users needing to make payments outside of the app.

We recognise that, as discussed below, there are a number of ongoing investigations of Apple’s and Google’s in-app payment systems, and some of these may lead to changes to their respective terms and conditions. We welcome views on the interventions above and other alternatives, noting that there are already ongoing developments in this area, such as the recently announced interventions in South Korea which are discussed further in The role of Apple and Google in competition between app developers and Appendix H.^{[footnote 621]}

Separation remedies designed to address leveraging of market power into app development

We have identified a number of potential risks for conflicts of interest for Apple and Google in the operation of their app stores. For instance, in many cases they are both the rule maker and the referee for app markets in which they themselves compete, and, subject to further analysis, we share some of the concerns raised by app developers that Apple and Google have the ability and incentive to provide an unfair advantage to their own apps. We have identified the following forms of separation which might address these concerns:

• Data separation: which would focus on the ability of Apple and Google to share potentially commercially sensitive data internally and potentially build it into their own technical design or commercial arrangements. As discussed above, we consider that a requirement not to share certain types of data could be appropriate in any case and some constraints on sharing of data may already be in place, but a form of data separation would impose specific barriers to sharing of certain classes of data.
• Operational separation: which would require Apple and Google to run their app development processes independently, and to treat all apps consistently as part of that process. Operational separation requires a form of independence of the management of the separated business, which would address the ability and incentive of Apple and Google to favour their own app development business.
• Structural separation; which would be comparable to operational separation in terms of the businesses being separated, but which would require formal legal separation or divestment of the app development businesses.

Data separation would require Apple and Google to have in place internal restrictions, such as ‘firewalls’ which would limit sharing of information between those running the operation of the app store (including the app review process and mechanism for ranking apps on app stores), together with an obligation to treat all app developers in a comparable way. This would potentially address the specific concerns that there is a conflict of interest for Apple and Google from both setting the rules of their app store processes, and being directly affected by the outcome of those processes through their own app development businesses.

Operational separation would require Apple’s and Google’s own app development businesses to operate independently of the rest of their mobile ecosystem – in particular, those parts of Apple’s or Google’s business which conduct the app review process, or determine what APIs and access to functionality are available to own and third-party apps. An app store review process that is operationally separate from the app development would be required to review and treat Apple and Google’s own apps on an ‘arm’s length’ basis, using the same process as for third-party apps.

The greatest benefits from operational separation come where the introduction of separation allows for development of alternative business models and innovation through alternatives to the separated business. We are therefore particularly interested in any evidence as to whether separation of Apple’s and Google’s app development would be able to achieve such benefits. Given that app development has to date been managed as part of the mobile ecosystem, we would also welcome views on whether operational separation would need to be combined with obligations on other measures, such as requiring comparable functionality (ie APIs) to be accessible between first-party and third-party apps. We welcome views from stakeholders as to how this could be applied in practice.

We recognise that data and operational separation would also come with costs, both in terms of additional obligations on the mobile ecosystems to build in the management processes required to support the relevant forms of separation, and potentially some lost efficiencies. We welcome stakeholders’ views on both the scale of the potential benefits (in terms of more equal treatment of Apple’s and Google’s app development compared to that of third parties), and also the potential costs and practical issues.

A more intrusive alternative would be a structural separation requirement, which could require the app store or app review process either to be divested, or to be operated under independent governance. This would be a more intrusive remedy with higher costs, and to the extent that it resulted in mobile ecosystem providers being unable to design and offer integrated apps, could significantly change the user experience of mobile devices. At this stage we think there are merits in exploring the effectiveness of data or operational separation as alternatives that could deliver many of the benefits of structural separation with comparably lower costs.

Box 7.4: views sought for Remedy Area 4

In respect of the interventions in this section which seek to address the effects of Apple’s and Google’s market power on competition in app distribution, we are interested in views on:

• the likely effectiveness of these interventions in addressing the competition concerns raised in The role of Apple and Google in competition between app developers;

• the extent of privacy, security and other concerns, and what would be required to mitigate any costs associated with the intervention; and

• whether there are specific examples of restrictions on third-party apps which have the greatest effect on third-party app developers, and therefore would be a priority for any intervention.

We also welcome views on the benefits of separation of app development, and what form of separation could be most effective.

Given our findings that the design of choice architecture may in some cases act as a barrier to users making effective choices in line with their preferences on data privacy, we also seek views on:

• whether changing default settings for data privacy can be made easier and if so, what approaches may be most effective;

• what forms of data privacy choice screens and prompts are likely to be most effective in empowering consumers; and

• whether the design of data privacy choice screens within mobile eco-systems should be subject to standardised choice architecture principles.

Interactions of remedies across the themes

Mobile ecosystems are comprised of a wide range of products and services that work together to create an ecosystem’s overall functionality and value. Although the level of integration and business models adopted by Apple and Google differ, they can both influence competition in related activities through their control of the operating systems and their proprietary app stores, browsers and browser engines in their respective mobile ecosystems.

The links between the different segments of mobile ecosystems have a number of implications for potential interventions.

First, it means that some interventions will be most effective when designed in combination with others – for example, enabling greater choice for some areas within mobile ecosystems may also require some form of interoperability requirement. Taken together the objective of such a package of remedies could be to lead to sufficient potential entry to address the market power that currently exists in the mobile ecosystem. At the same time, some of the interventions outlined above could potentially be regarded as alternatives. We highlight some examples of these interactions below:

• Interventions targeted at Apple’s and Google’s positions in operating systems and the distribution of native apps, could also address, at least in part, the ability and incentive of Apple and Google to exercise market power over app developers in downstream markets. Greater competition in app distribution (Remedy Area 2) may, over time, lead to developers being offered improved terms and conditions, which could lead to greater competition between app developers (Remedy Area 4). Over time, this dynamic may lessen, or even remove, the need for interventions targeted at improving competition between app developers.
• There are also multiple examples of potential interventions in downstream markets that could also improve competition upstream. For instance, requiring Apple to allow alternative browser engines on iOS (Remedy Area 3), might support the further development of web apps as an alternative way of accessing content on mobile devices, reducing app developers’ reliance on native apps that are accessed through proprietary app stores (Remedy Area 2) and with possible benefits in relation to reducing the barriers to entry for new operating systems (Remedy Area 1).
• There are also examples of specific agreements that have the potential to harm competition across the themes. For instance, Google’s agreements with device manufacturers in relation to Google Search and Chrome could be harming competition between web browsers, mobile operating systems and the distribution of native apps. It will therefore be necessary to understand the various implications of existing agreements, as well as the impact of any remedial action, across the entire ecosystem as part of the assessment of any interventions in respect of these agreements.

These examples serve to illustrate that any future proposals for interventions to promote greater competition in this sector should not be limited to considerations within a single narrowly defined product or service market – a holistic approach is needed, including ongoing engagement with the owners of the ecosystems, their competitors and users. It may also be possible to prioritise and stagger the implementation of certain remedies, depending on which are regarded as being potentially most effective at driving greater competition and choice both within mobile ecosystems and between them. By contrast, certain interventions may rely on the implementation of others, within an overall package of measures, to be effective.

A further advantage of adopting a more iterative approach to remedy implementation is that the effectiveness of remedies may be uncertain, particularly in digital markets where users’ decision making can be easily influenced by design choices. It may be preferable to monitor the effectiveness of particular remedies prior to implementing further, related interventions. This approach would also help ensure that any further interventions remain necessary and proportionate and their implications across the whole ecosystem are taken into consideration.

International developments

This study is being taken forward at the same time as a number of potential legislative measures internationally which also have the objective of giving powers to competition and regulatory authorities to tackle the competition problems that exist globally in digital markets.

Alongside the UK government’s proposals for a pro-competition regime for digital markets, there is comparable digital markets legislation in other jurisdictions either under development, including the proposed Digital Markets Act in the EU and Open App Markets Act bill in the US; or already enacted, such as the recent amendment to the South Korean Telecommunications Business Act earlier this year.

The EU’s Digital Markets Act proposal ^{[footnote 622]} currently includes measures to regulate large online platforms that meet the criteria for designation as ‘gatekeepers’, which is expected to include both Apple and Google. Gatekeepers will be required to comply with certain obligations in the running of their daily operations. Proposed obligations include measures to: improve equal access to, and interoperability with, hardware and software features; improve access to, and portability of, data; improve users’ ability to remove default apps and software; allow sideloading of apps and app stores; provide access to app stores on fair and non-discriminatory conditions; restrict the tying of services to platforms (for example in-app payment systems); restrict anti-steering measures; and restrict self-preferencing (in terms of access, data and rankings).

The bipartisan Open App Markets Act bill ^{[footnote 623]} recently introduced in the US Congress is targeted specifically at app stores and aims to ‘promote competition and reduce gatekeeper power in the app economy, increase choice, improve quality, and reduce costs for consumers’. The current draft of the bill applies to ‘Covered Companies’, who own or control an app store with more than 50 million users in the United States (which again, would cover Apple and Google, based on their current US user base). Draft provisions include the requirement to allow sideloading of apps and app stores; a prohibition on mandating the use of a platform’s own in-app payment system; a prohibition on anti-steering provisions; interoperability requirements; and restrictions on self-preferencing through search or use of data.

As an example of legislation in this area that has already come into force, South Korea’s National Assembly passed an amendment to its Telecommunications Business Act in August 2021,^{[footnote 624]} which came into effect on 14 September 2021.^{[footnote 625]} The amendment prohibits Apple and Google from mandating the use of their in-app payment systems for in-app purchases of digital content and applying a commission fee of 30%. It also contains provisions requiring Apple and Google not to delay app review or delete apps.

There are also a number of competition investigations and litigation (brought both by governments and private parties) ongoing which target some of the markets within this study. These include, among others, cases in the US,^{[footnote 626]} the EU, ^{[footnote 627]} Japan,^{[footnote 628]} South Korea,^{[footnote 629]} and the UK.^{[footnote 630]}

The CMA itself also has an ongoing investigation under the Competition Act 1998 into aspects of the terms under which Apple grants developers access to the App Store. This investigation is distinct from this market study, notwithstanding that it relates to activities within the scope of this study. The investigation is ongoing and the CMA has not yet come to a conclusion as to whether Apple has breached competition law.^{[footnote 631]}

We also note that, in response to such international regulatory initiatives, Apple and Google could unilaterally decide to adapt their conduct in certain ways. Indeed, certain announcements have been made recently by Apple and Google regarding changes to their policies for app developers.^{[footnote 632]}

Further announcements by Apple or Google, or indeed any further statements by other authorities, could potentially result in changes that would affect market conditions in the UK. We continue to monitor the work carried out in other jurisdictions and, in turn, aim to contribute to the global debate on how to tackle the problems associated with digital platforms with substantial market power. This reflects our belief that the most effective way to promote competition in these markets will be through action that is internationally coherent, by achieving a common understanding of the problems and broad agreement over the way to tackle them.

In the next chapter, we set out how our initial assessment of potential interventions could be applied within the proposed UK legislative framework for establishing a pro-competition regime for digital markets, on which the government recently consulted. Ultimately, as and when the legislation is implemented, it will be for the DMU to decide what interventions it considers necessary (for those activities where it finds a firm has SMS), based on the statutory tests ultimately set out in the legislation and any supplementary DMU guidance. One of the aims of this study is to provide evidence to inform the DMU’s assessment in this regard, which can be considered alongside any subsequent evidence it gathers for itself (in particular to assess any changes in market conditions following the end of this study).
 

8. Applying our findings to the proposed new pro-competition regime for digital markets

Introduction

In July 2021, the government consulted on its proposals to introduce a new pro-competition regime for digital markets in the UK.^{[footnote 633]} It stated that this regime would proactively shape the behaviour of digital firms with significant and far-reaching market power, by making clear how they are expected to behave. The government expects the regime to boost competition and innovation by tackling the sources of existing and future strategic market power, described as Strategic Market Status (SMS), while protecting smaller businesses, consumers and competition by governing the relationship between users and key digital firms. The regime will be implemented and enforced by a dedicated Digital Markets Unit (DMU), which was established on a non-statutory basis within the CMA in April 2021.

As we set out in our statement of scope, we intend the conclusions that we reach through the course of this market study to contribute to the process of establishing and operationalising this new pro-competition regime. In particular, we expect the findings of this market study to be a useful input into any DMU’s assessment of whether Apple and Google should be designated with SMS in particular activities, and also regarding the appropriate range and design of potential interventions that the DMU could put in place following the introduction of the regime, were it to find either Apple or Google to have SMS. Carrying out this work now should help ensure that, if and when legislation is passed to empower the DMU to perform its functions under the proposed new regime, it has a strong evidential foundation on which to base its own analysis and assessment of these issues, and to reach a view and – if and where it considers it necessary – introduce any interventions it proposes promptly.

With this aim, in this chapter we have set out how our provisional findings and the potential interventions we have identified might map across to the key components of the new regime, as they are currently envisaged, which are:

• Strategic Market Status: we draw from our findings in Chapters 3 to 6 to assess whether, based on the evidence we have gathered to date, Apple and Google would presently meet the proposed test for being brought within the new regime (based on the currently proposed test for SMS designation as set out in the government’s consultation).
• Codes of conduct: as currently proposed, the regime envisages that all firms designated with SMS will be subject to a code of conduct designed to address the ability to exploit market power, with common objectives across SMS activities of fair trading, open choices and trust and transparency. In this chapter we highlight how such a code might be applied to mobile ecosystems, including through examples of the practices that we anticipate could potentially be addressed through each of the expected code principles.
• Pro-competitive interventions (PCIs): the government’s proposals envisage PCIs to be a more powerful tool designed to address the sources of market power by tackling barriers to competition, and therefore to undermine that market power over time. We highlight some examples of the potential interventions discussed in the previous chapter that we expect could in principle be implemented as such PCIs.

The following sections set out our initial thinking on the application of these 3 components in turn. Overall, we consider that the framework for codes of conduct and PCIs envisaged in the government consultation could be effective in addressing the competition concerns identified in this interim report. Codes of conduct may introduce specific measures to prevent the exploitation of market power in the activities within the scope of this study, such as through imposing restrictions on how third parties interact with the mobile ecosystem. Given the challenges that may exist in tackling potentially numerous ways that market power could be exploited across the mobile ecosystem, there are also a number of areas where we consider PCIs could be aimed at reducing market power for particular activities over time.

There is likely to be a need to implement these potential interventions iteratively over time to achieve the greatest benefits. A code of conduct could likely take effect soon after the formal commencement of the DMU’s powers; whereas PCIs may take longer to establish and implement; but that if successful in making the markets more contestable, they could result in a code of conduct, or parts of it, being removed over time.

Strategic market status

Building on the recommendations of the Furman Review ^{[footnote 634]} and subsequently the CMA’s advice through the Digital Markets Taskforce, the government has proposed that firms would be brought within the scope of the regime where they are designated by the DMU as having SMS. Its consultation sets out that for a firm to be designated with SMS, the DMU would need to conclude that the firm has substantial and entrenched market power in at least one activity, providing it with a strategic position.^{[footnote 635]}

In the government’s consultation the proposed test for SMS contained the following 3 components:

1. Digital activities: the government has proposed that the DMU should be able to group certain products, services and processes into a single activity if they all can be described as having a similar function or, if in combination, can be described as fulfilling a specific function. It has proposed that such activities are considered ‘digital’ where digital technologies are a ‘core component’ of the products and services provided as part of that activity.
2. Substantial and entrenched market power: substantial market power arises when users of a firm’s product or service lack good alternatives to that product or service, and there is a limited threat of entry or expansion by other suppliers. Such power is entrenched where it is expected to persist over time and is unlikely to be competed away in the short or medium-term.
3. Strategic position: a strategic position would exist where the effects of a firm’s market power are likely to be particularly widespread or significant. The government’s proposed criteria for the DMU to consider when assessing the extent of a strategic position are:

• whether the firm has achieved very significant size or scale in an activity, for example, where a product is regularly used by a very high proportion of the population or where the value of transactions facilitated by a product is large;

• whether the firm is an important access point to consumers (or, in other words, a gateway) for a diverse range of other businesses or the activity is an important input for a diverse range of other businesses;

• whether the firm can use the activity to further entrench or protect its market power in that activity, or to extend its market power into a range of other activities; and

• whether the firm can use the activity to determine the ‘rules of the game’ for those users of the firm’s own ecosystem and also set practice for those businesses in the wider market.

The government proposals also suggest that an assessment of whether a firm has substantial and entrenched market power should closely follow the approach that the CMA takes in market studies and investigations such as this study.

The following sections set out our preliminary assessment of whether each of Apple and Google would meet the criteria set out in the government’s consultation for activities assessed within the scope of this market study. We recognise that this assessment is based on a proposed test that is being consulted on, and which may change as a result of the consultation process and any subsequent legislative process, and so will be subject to ongoing review. We will use the second half of this study, and the views received from stakeholders to this report, to progress this assessment ahead of our final report. However, as noted above, it will ultimately be for the DMU to make any assessments of SMS and the contents of any code for itself, based on the legislation as implemented, and in response to the market conditions and any further evidence it gathers at that time.

Apple

In Chapters 3, 4 and Competition in the supply of mobile browsers we considered 3 different elements of Apple’s mobile ecosystem separately, namely: (i) mobile devices and operating systems; (ii) native app distribution; and (iii) browsers and browser engines. We recognise that there are strong interdependencies between these products and services and that there is a question about whether any SMS designation relating to these elements would be separate or combined in some way.

For the purposes of this interim report we have not considered this question, which is ultimately for the DMU to address, and which will furthermore depend on the content of any final legislation which formally establishes the DMU and its powers.

Rather, for the purpose of our assessment here we have taken the same approach as in previous chapters by considering whether Apple may have SMS in an identified digital activity in relation to each element of its mobile ecosystem separately. In doing this, we follow the approach presently envisaged in the government’s consultation, applying it to our findings from Chapters 3, 4 and Competition in the supply of mobile browsers.

Mobile devices and mobile operating systems

Relevant ‘digital activity’

The concerns we have identified in previous chapters arise due to Apple’s control over its mobile operating system, iOS, and the subsequent control this provides over how its devices function (including the functionality that native apps and web browsers can access) and how they interact with other connected devices. As such we consider that there is a specific activity carried out by Apple which relates to the supply of mobile operating systems.

As outlined in previous chapters, Apple’s iOS is only available on Apple’s own mobile devices – iPhone and iPad. iOS is not supplied or licensed to any third party and Apple explained that the ‘interrelationship’ between mobile devices and mobile operating systems is at the ‘core of Apple’s business model’.

Therefore, our preliminary view is that that any specific activity carried out by Apple which relates to the supply of mobile operating systems also includes the devices on which they are installed. Further, this activity would focus on the relevant products and services supplied to users rather than other aspects of the supply of mobile operating systems and the devices on which they are installed, such as the supply of hardware components.

We welcome stakeholders’ comments on our preliminary view that, for the reasons set out below, Apple would meet the criteria for possible future SMS designation in this activity, as those criteria are envisaged in the government’s consultation. In particular, we are interested in stakeholders’ views on whether, were the DMU to designate Apple as having SMS based on its position in mobile operating systems, they believe it would be appropriate for the DMU also to include Apple’s mobile devices in such a designation.

We consider that this activity is ‘digital’ because:

• Mobile operating systems are a layer of computer software that allow other software (for example native apps, web apps) to operate on a mobile device including allowing other software to make use of the mobile device hardware. Without the mobile operating system users would not be able to access any digital content. This form of computer software is widely recognised and understood to be digital technology.
• Mobile devices are essentially small computers that can be used to access the internet, whether via wireless networks or mobile phone networks and which process information in discrete form. In this regard, mobile devices rely on digital rather than analogue communication systems. The core hardware and software components contained within a mobile device are widely recognised and understood to be digital technology.

Our preliminary view is that this activity would include not only smartphones, but also tablets (ie Apple’s iPad and iPadOS) as:

• in tablets, as in smartphones, Apple has consistently had a share of active devices of [50% to 60%] as set out in Competition in the supply of mobile devices and operating systems;
• the concerns we have heard in relation to the key gateways in Apple’s mobile ecosystem, the App Store and the WebKit browser engine, relate to both smartphones and tablets; and
• apart from some differences highlighted in shares of supply (the presence of a material third operating system – Amazon’s Fire OS had a [20% to 30%] share of active tablets in 2020), ownership rates (which are lower for tablets as set out in Competition in the supply of mobile devices and operating systems) and use cases, no parties have suggested that tablets should be treated differently to smartphones.

We welcome views on our preliminary analysis which suggests that, were mobile devices to be included within this designated activity under the proposed SMS regime, that should include tablets as well as smartphones.

Substantial and entrenched market power

As set out in Competition in the supply of mobile devices and operating systems, Apple and Google have an effective duopoly in the provision of mobile operating systems. Because Apple’s iOS is only used in Apple devices, Apple’s share of mobile devices and mobile operating systems mirror each other. In 2020, Apple was the largest mobile operating system provider and has [50% to 60%] share of all active smartphones and [50% to 60%] of active tablets in the UK.^{[footnote 636]}

In both cases Apple has had persistently high shares of supply. Apple’s share of active smartphones has been [50% to 60%] since at least 2015,^{[footnote 637]} and data from Statcounter set out in Appendix C shows that it has had a high share of active smartphones since 2009. Apple’s share of active tablets is also [50% to 60%] and has been since at least 2017;^{[footnote 638]} data from Statcounter set out in Appendix C shows that it has had a high share of active tablets since 2012, although it has declined over time.

Further, we consider that there is limited user-driven competition, based on our current findings, detailed in Competition in the supply of mobile devices and operating systems, that:

• Most users purchasing a device are buying a replacement device and rarely switch between operating systems when doing so. Users appear to be particularly loyal to Apple.
• There is limited price competition between iOS and Android devices with Apple’s iOS devices dominating sales of high-priced devices and devices using Android dominating sales of low-priced devices. This is particularly the case for smartphones, where the price gap between the 2 has grown over time yet this does not appear to have impacted on switching.
• There appear to be material actual and perceived barriers to switching which include: (i) learning costs; (ii) barriers relating to the transfer of data, apps and managing subscriptions across devices (including some that arise due to requirements to use proprietary in-app payment systems); and (iii) barriers related to losing access to shared functionality between first-party apps, services and connected devices and having a worse experience of interacting with friends’ and family’s devices. These switching costs are asymmetric, with iOS users generally facing higher barriers to switching than Android users. This is due to: restrictions on the information that third-party switching apps can access from iOS devices; constraints on developers’ ability to require users to link developer accounts to their Apple ID so that users can recover paid-for apps and in-app content after switching; and the characteristics of Apple’s first-party apps, services and connected devices, which offer more limited functionality when interacting with Android device than vice versa and may pose challenges to using a pre-existing number for messaging on an Android device.

In addition, we consider that Apple benefits from material barriers to entry and expansion faced by potential rival providers of operating systems. This includes:

• Strong indirect network effects and economies of scale in the development and maintenance of mobile operating systems. In particular, the benefit to users of an operating system increases with the volume and quality of content and apps they can access through that operating system and similarly the benefit to content providers/app developers increases with the number of users they can access through an operating system. This means it is difficult for a new operating system to gain traction as they cannot attract one set of customers without the other and this also makes it even more difficult to achieve scale and overcome barriers due to economies of scale.
• For any new entrant in the operating system market, entry in competition with iOS would either require them to manufacture devices that use their operating system, or to license their operating system to third-party device manufacturers. Apart from Amazon and Huawei who use their own operating systems, all of these manufacturers would have to be attracted away from Google’s version of Android (as Apple does not license iOS to third-party manufacturers). As detailed in Competition in the supply of mobile devices and operating systems this would entail significant challenges due to Google’s complex set of agreements and payments to device manufacturers which mean any new entrant would need to be able to match the financial incentives offered by Google to manufacturers and also offer alternatives to Google’s core apps and APIs.
• Barriers to users switching away from their current mobile ecosystems would substantially limit the chances of a new entrant. These barriers are greatest for Apple users, accounting, as detailed above, for [50% to 60%] of active smartphone users and [50% to 60%] of active tablets, in part due commercial decisions made by Apple, for example, in relation to the interoperability of its first-party apps, services and connected devices.

Based on these findings, we took the view in Competition in the supply of mobile devices and operating systems that Apple has substantial and entrenched market power in the supply of mobile operating systems. Given Apple’s business model, which requires iOS on all its devices and excludes alternative operating systems, this finding relates to its devices and operating system in combination.

Strategic position

We consider there to be strong evidence that, based on the proposed test for Strategic Market Status, Apple has a strategic position in the digital activity of mobile operating systems and the devices on which they are installed, for the following reasons.

First, in the UK, Apple has, since launching its first iPhone in 2007, achieved a very significant size and scale in its supply of mobile devices and operating systems, with its products being used by a very high proportion of the population. In 2020, there were nearly [40 to 50] million accounts making transactions on iPhones and [10 to 20] million accounts making transactions on iPads in the UK compared to a UK population of 67 million.^{[footnote 639]} In addition, Apple directly generates revenues of $[6.5 to 7] billion from iPhone sales and $[1 to 1.5] billion from iPad sales in the UK which as set out in Appendix D are highly profitable.

Second, Apple’s mobile devices and operating system are the entry point for users into Apple’s ecosystem. Apple can use this position to control both the apps and services that are pre-installed on Apple devices and control the main gateways through which online content can be accessed by and delivered to users (which in themselves are significant in scale and size, connecting a large number of users and businesses, as set out below). In particular, through its control of iOS, Apple is able to control:

• How native apps are distributed and installed as well as what those native apps are able to do. For example, Apple has mandated that native apps can only be installed through its own App Store as outlined in Competition in the distribution of native apps. Through the iOS APIs that it makes available, Apple can also determine how native apps can integrate with Apple mobile devices in terms of the aspects of software and hardware they can access, as outlined in The role of Apple and Google in competition between app developers.

• How web content can be distributed as well as what web-based alternatives to native apps are able to do. For example, Apple has mandated that all web browsers on iOS devices must use Apple’s WebKit browser engine, such that, as outlined in Competition in the supply of mobile browsers, Apple effectively controls which features browsers are able to support, thereby determining the extent to which they can support web apps. Additionally, and more generally, Apple determines how web-based alternatives can integrate with Apple devices in terms of the aspects of software and hardware they can access.

Apple’s control over iOS also allows it to determine the ‘rules of the game’ by determining which APIs are made available to third parties and on what terms. This is important as the functionality of native apps and browser engines on a mobile device is determined by which APIs they can access.

Third, Apple can use its control over its own mobile devices and iOS to extend its market power in mobile devices and iOS into other markets:

• Apple is able to confer an advantage on its own apps through restricting access to certain elements of its devices’ hardware and software, pre-installation and the setting of defaults in a way that helps to protect its own apps from competition. To the extent that this promotes the use of Apple’s first-party apps, services and connected devices, this also supports Apple’s position in mobile devices and operating systems as Apple’s first-party apps, services and connected devices act as a barrier to switching as outlined in Competition in the supply of mobile devices and operating systems.
• Apple can use its control over iOS to set policies around where native apps can be installed from (for example it bans sideloading), which allows it to reinforce the position of the App Store as the sole means of accessing native apps. Apple can also use its position at the operating system level to enforce policies such as the restrictions on browser engines and ATT which, as set out in Competition in the supply of mobile browsers and The role of Apple and Google in competition between app developers respectively, can serve to undermine alternatives to the App Store and thus entrench the market power of the App Store. In addition, this also enables Apple to use its market power in operating systems to competitively advantage its advertising services, as ATT increases the value of those services compared to the advertising services of rivals who offer ways to advertise apps to iOS users.

Summary of our preliminary views in relation to mobile devices and mobile operating systems

In combination, our findings to date and the related evidence support the view that Apple has substantial and entrenched market power in the supply of its mobile operating systems and the devices on which they are installed, which we consider to be a digital activity.

In addition, it is our assessment that Apple’s position in respect of its mobile operating systems and the devices on which they are installed is strategic.

Given this, Apple would, in our view, meet the government’s proposed future test for SMS in relation to the supply of mobile operating systems and the devices on which they are installed.

Native app distribution

Relevant ‘digital activity’

As outlined in Competition in the distribution of native apps, Apple provides software and tools to app developers that allow them to write software (ie native apps) that interacts with iOS. Such native apps can then be distributed to iOS users through Apple’s App Store provided they adhere to the terms contained in a number of agreements and guidelines. The rules contained within these agreements and guidelines are unilaterally interpreted and enforced through Apple’s app review process, to which all native apps (both when new and when being updated) are subject.

We consider that there is a specific activity carried out by Apple which relates to the distribution of native apps and this includes the following products and services provided to users and app developers:

• Apple’s App Store and associated advertising services.
• Apple’s services offered via Apple’s Developer Program, Software Development Kits (SDKs) and App Store Review Process.

We consider that this activity is ‘digital’ because all the products and services provided are based on digital technologies and facilitate the distribution of computer software by app developers to users. This form of computer software is widely recognised and understood to be digital technology.

Substantial and entrenched market power

As outlined in Competition in the distribution of native apps, Apple’s rules mean that native apps can only be installed through Apple’s App Store. In particular, native apps cannot be distributed in any other way on iOS devices unless the user engages in a process called ‘jailbreaking’ which is technically difficult and a violation of the iOS end-user software license agreement such that Apple may deny service for an iPhone or iPad that has installed any unauthorised software via jailbreaking.

This has been the case since Apple introduced the App Store to its mobile devices in 2008 and means that since then Apple has essentially had a 100% share of supply in terms of the distribution of native apps on Apple devices. Apple’s rules mean that this market power is also entrenched as no rivals can feasibly provide native app distribution services on iOS devices.

The distribution of native apps through the App Store is also growing over time, for example in the UK:

• the number of users who downloaded at least one app in a given month has increased from over 18 million users in January 2016 to over 25 million users in December 2020;
• the overall number of first-time downloads per year has increased from [1 to 1.5] billion in 2016 to just under [1.5 to 2] billion apps in 2020; and
• the value of customer billings processed by Apple IAP has increased significantly from [REDACTED] in 2016 to [REDACTED] in 2020.

Further, and as considered in detail in Competition in the distribution of native apps, we do not consider that Apple’s App Store is constrained by other methods through which app developers can distribute their content to users:

• Web apps are not currently a suitable alternative to native apps for most app developers – despite the potential savings in development costs, they do not currently allow the same features and functionalities as native apps. Much of this is down to restrictions on the features and functionalities of web apps that are imposed by Apple through its WebKit browser engine. These restrictions diminish developers’ incentives to develop web apps for all mobile devices and operating systems (ie including Android devices) as the idea of a web app is to develop one app to be used on browsers on any operating system.

• The App Store does not face a material competitive constraint from Google’s Play Store. Each app store provides access to a large volume of unique users such that the largest app developers accounting for the most downloads tend to multi-home on both app stores, and Apple and Google face limited constraints from users switching between mobile ecosystems when buying a new device.

• The App Store also does not face a material competitive constraint from alternative non-mobile devices such as desktops or games consoles. These devices are primarily used for different purposes and are mainly viewed by users as complements rather than substitutes, such that not being available on iOS devices is not generally an option for app developers.

Based on these findings and as explained in Competition in the distribution of native apps, Apple has, in our view, substantial and entrenched market power in the distribution of native apps.

Strategic position

Applying the test for Strategic Market Status currently proposed in the government’s consultation, we also consider that Apple’s position in the digital activity of native app distribution is ‘strategic’ (as currently defined in the consultation), for the following reasons.

First, in the UK Apple has achieved a very significant size and scale in mobile app stores with the App Store being used by a very high proportion of the population. The App Store is the only app store on all iPhones and iPads and, as set out above, in the UK in 2020 there were nearly [40 to 50] million transacting accounts using iPhones in 2020 and [10 to 20] million transacting accounts using iPads. In addition, Apple’s net revenue from transactions through Apple IAP was $[400 to 600] million in the UK in 2020 ^{[footnote 640]} and on average [20 to 30] million users downloaded at least one app from the App Store in any given month in the UK in 2020.

Second, Apple’s App Store is an important access point or gateway to users for a diverse and large range of businesses. In particular, in the UK in 2020:

• On average [20 to 30] million users downloaded at least one app from the App Store in any given month;

• roughly [500,000 to 600,000] app developers had roughly [1 to 1.5] million apps on the App Store; and
• the value of customer billings processed by Apple IAP was [REDACTED].

Third, Apple’s control over access to the App Store means that it is able to determine the ‘rules of the game’ for app developers seeking to distribute apps on iOS, in particular through its development of SDKs and through Apple’s app review process (and the ability to reject apps or app updates which do not comply with its rules).

Fourth, Apple can use its control over app distribution on iOS to:

• Extend the market power of the App Store to gain a competitive advantage in other markets: in particular, Apple is able to confer an advantage on its own apps which do not have to comply with rules such as the payment of a commission to Apple. In addition, Apple is able to use its position to gain access to confidential information which may assist it in developing apps, services and devices in a way which departs from competition on the merits. To the extent that this promotes the use of Apple’s first-party apps, services and connected devices, this can also allow Apple to further entrench its market power in mobile devices and operating systems given Apple’s first-party apps, services and connected devices act as a barrier to switching (as outlined in Competition in the supply of mobile devices and operating systems). In addition, restrictions on cloud gaming on iOS may also entrench Apple’s position in mobile devices and operating systems because gamers playing cloud-based games are not constrained by the processing capabilities or storage capacity on a device and so would be able to have essentially the same gaming experience as they get on iOS with a lower end, less expensive mobile device.
• Entrench the market power of the App Store: in particular, Apple can enforce new policies such as those relating to cloud gaming and ATT, which, as set out in The role of Apple and Google in competition between app developers, undermine alternatives to the App Store and thus serve to entrench further the market power of the App Store.

Summary of our preliminary views in relation to native app distribution

In combination, our findings and the related evidence support the conclusion that Apple has substantial and entrenched market power in the distribution of native apps, which we consider to be a digital activity.

In addition, it is our assessment that Apple’s position in respect of native app distribution is strategic.

Given this, Apple would, in our view, meet the government’s proposed test for SMS in relation to native app distribution.

Mobile browsers and browser engines

Relevant ‘digital activity’

As outlined in Competition in the supply of mobile browsers, Apple requires all browsers on iOS devices to use its WebKit browser engine, meaning that in addition to Apple’s own browser, Safari, being based on WebKit, all other browsers on iOS are too.

We consider that there is a specific activity carried out by Apple which relates to the supply of mobile browsers and browser engines which covers both Safari and WebKit.

We consider that this activity is ‘digital’ because the products and services provided are based on digital technologies and facilitate the distribution of digital content, as well as in certain cases software, by content providers to users. The primary use of a browser is to access the web and browse the internet – these activities are widely recognised and understood to be digital in nature.

Substantial and entrenched market power

As outlined in Competition in the supply of mobile browsers, as all browsers on iOS are required to use WebKit, Apple does not face any competition in the supply of browser engines on iOS devices. Across operating systems, this position implies that Webkit has a share of supply of over 50% on mobile devices in the UK (ie matching Apple’s share of mobile devices).

As shown by the data presented in Competition in the supply of mobile browsers:

• with respect to browsers, Safari has a share of supply of more than 90% on iOS devices in the UK;
• across operating systems, given iOS devices’ share of supply of mobile devices in the UK, this position implies that Safari has a share of supply of around 50% across all such devices;
• this share has been relatively stable over the last decade, moving within a range of just under 50% and just under 60%.

Further, we consider that the constraint from other browsers is limited for several reasons:

• First, there are limitations to the ability of rival browsers to differentiate themselves on factors such as speed and functionality due to the WebKit restriction. This is driven by the browser engine being the core component of every browser and primarily determining the functionality a browser can offer.
• Second, Apple, through its control of the iOS operating system, restricts the ability of rival browsers to access APIs that are used by Safari.
• Third, Apple has a closed system as far as pre-installation and pre-set default settings for browsers on iOS are concerned: Safari is the only pre-installed browser on iOS and is set as the default browser. Pre-installation and default settings are important in determining consumer choice, implying that this constitutes a key barrier for other browsers to acquire users. This is reinforced by Apple making it difficult for users to change the default browser.

Based on these findings, we took the view in Competition in the supply of mobile browsers that Apple has substantial and entrenched market power in the supply of its mobile browser and browser engine.

Strategic position

We consider that, based on the government’s test for Strategic Market Status as currently proposed, Apple’s position in the digital activity of browsers and browser engines can be considered ‘strategic’ for the following reasons.

First, Safari accounted for 48% of all web page views on mobile devices in the UK in 2020. When considering all mobile browsers based on Apple’s WebKit browser engine, this figure increases to over 50%, mirroring Apple’s share of supply in mobile devices. In addition, Apple generates substantial revenue from Safari – as noted in our previous market study into online platforms and digital advertising, in 2019 the substantial majority of the £1.2 billion paid by Google in return for default positions in the UK was paid to Apple for being the default on the Safari browser.

Second, other than through app stores, web browsers are the most important way for users of mobile devices to access content and services over the internet. In addition to the important role that browsers play in enabling users to search for and consume content, browsers are one of the key sources of traffic for search engine providers as well as other businesses that want to reach users with their content and products online. Browsers are hence an important gateway through which online content can be accessed by and delivered to users.

• The Safari browser, given its position, is an important access point or gateway to users for a diverse and large range of businesses. This includes both online content providers and more specifically search providers such as Google Search and Microsoft Bing.
• The WebKit browser engine, as the browser engine for all browsers on iOS devices, allows Apple to determine what user data is collected on other browsers on iOS devices. It further gives Apple the ability to control what functionality is offered by any browser on iOS and, in particular, restrict the support for web apps.^{[footnote 641]}

Third, Apple’s control of WebKit allows it, in effect, to determine the ‘rules of the game’ for those using web browsers on iOS, given that all browsers on iOS are required to use WebKit. In particular (and as noted above in the context of browsers’ role as important gateways to online content), by requiring the use of WebKit can largely determine:

• the functionality that can be offered by any web browser on iOS. In turn, the functionality of these browsers determines the features, functionality and performance of web-based alternatives such as web apps and, therefore, the extent to which these alternatives can compete with native apps; and
• what user data can be collected by website on any web browser on iOS. This then influences the effectiveness of digital advertising on iOS.

Fourth, Apple control of WebKit and its position in browsers give it scope to:

• limit the success of web apps and increase the take up of native apps (which can only be accessed through its App Store). This could reinforce Apple’s very strong position in relation to the distribution of native apps on iOS as well as in the supply of mobile devices and operating systems, as it reduces the availability of web content which could help rival device manufacturers compete with Apple.
• make open display advertising less attractive on iOS, by limiting user tracking through its implementation of ITP in WebKit. Any such deprecation of display advertising may in turn decrease the competitive constraint from display advertising on search advertising. It could also reduce the viability of the web as a content distribution channel (given the important role of display advertising in funding web content), which would reinforce Apple’s very strong positions in relation to the distribution of native apps on iOS as well as in the supply of mobile devices and operating systems.

Summary of our preliminary views in relation to mobile browsers and browser engines

In combination, our findings and the related evidence support the view that Apple has substantial and entrenched market power in the supply of mobile browsers and browser engines, which we consider to be a digital activity.

In addition, it is our assessment that Apple’s position in respect of mobile browsers and browser engines is ‘strategic’, as that term is defined in the government’s consultation on a new pro-competition regime.

Given this, Apple would, in our view, meet the government’s currently- proposed test for SMS in relation to mobile browsers and browser engines.

Initial assessment on Strategic Market Status for Apple

Based on the evidence and findings set out in this report and supporting appendices, Apple would, in our view, meet the criteria for SMS currently suggested in the government’s consultation for each of the following activities within its mobile ecosystem: (i) mobile operating systems and the devices on which they are installed; (ii) native app distribution; and (iii) mobile browsers and browser engines.

Google

Mobile devices and mobile operating systems

Relevant ‘digital activity’

Unlike with Apple and iOS, Google’s Android operating system is not available only to mobile devices that Google manufactures. Indeed, while Google’s Android has a large share of supply, Google’s Pixel devices have a very small share of both smartphones and tablets (in the UK in 2020 [0% to 5%] of newly activated Android smartphones were Pixel and less than [0% to 5%] of new Android tablets sold were Pixel). As such Google’s Pixel devices and its Android operating system are separable and, based on the current circumstances (and the way the SMS framework is currently envisaged in the government’s consultation), we would not envisage that Pixel devices would be part of any designated activity.

Instead any designated activity would, in our view, more appropriately focus on Google’s version of Android which has a share of roughly [40% to 50%] of active smartphones and [20% to 30%] of active tablets in the UK in 2020, as set out in Competition in the supply of mobile devices and operating systems.

Google’s version of Android includes the open-source Android code and Google Mobile Services which includes both a set of core Google apps (Play Store, Google Maps, etc.) and Google APIs (Google Play Services). Our preliminary view is that any designated activity related to Google’s version of Android would likely include at least the Google Play Services of Google Mobile Services, given that many native Android apps integrate with these APIs to provide features and functionalities (for example push notifications). This means that many native Android apps may not function properly on devices that do not include Google Play Services.

Consideration might also be given to including other elements of Google Mobile Services. For example, some native Android apps also integrate with elements of Google’s core apps to provide certain features and functionality (for example to provide mapping functionality based on Google Maps). Further, it appears that Google Play Services itself is updated through the Play Store.^{[footnote 642]}

We welcome responses from stakeholders on our preliminary view that, for the reasons set out below, Google would meet the criteria for possible future SMS designation in this activity, as those criteria are envisaged in the government’s consultation. In particular, we are interested in stakeholders’ views on whether, were the DMU to designate Google as having SMS based on its position in mobile operating systems, they believe it would be appropriate for the DMU to include all the elements of Google Mobile Services in such a designation.

We consider that this activity is ‘digital’ because mobile operating systems are a layer of computer software that allows other software (for example native apps, web apps) to operate on a mobile device including allowing other software to make use of the mobile device hardware. Without the mobile operating system most users would not be able to access any digital content. This form of computer software is widely recognised and understood to be digital technology.

Our preliminary view is that this would include Google’s version of Android not only on smartphones, but also on tablets as:

• the concerns we have heard in relation to the key gateways in Google’s mobile ecosystem, the Play Store and its position in browsers and browser engines, relate to both smartphones and tablets; and
• apart from some differences highlighted in shares of supply (resulting from the presence of a material third operating system, Amazon’s Fire OS, which had a [20% to 30%] share of active tablets in 2020), ownership rates (which are lower for tablets as set out in Competition in the supply of mobile devices and operating systems) and use cases, no market participants have suggested that tablets should be treated differently to smartphones.

We welcome views on our preliminary analysis which suggests that, were the DMU to designate Google as having SMS based on its position in mobile operating systems, that should include Google’s version of Android on tablets.

Substantial and entrenched market power

As set out in Competition in the supply of mobile devices and operating systems, Apple and Google have an effective duopoly in the provision of mobile operating systems. In 2020, Android devices made up roughly [40% to 50%] of all active smartphones and [20% to 30%] of active tablets in the UK.

In relation to smartphone operating systems, Google has had a persistently high share. In the UK Android devices have had a share of [40% to 50%] of active smartphones since at least 2015 and data from Statcounter set out in Appendix C shows that Android has had a high share of active smartphones and been the second largest smartphone operating system since 2013. In contrast, Android devices have had a share of active tablets of between [20% to 30%] in recent years.

Further, based on the following key findings we consider that there is limited user-driven competition:

• Most users purchasing a device are buying a replacement device and rarely switch between operating systems.
• There is limited price competition between iOS and Android devices with Apple’s iOS devices dominating sales of high-priced devices and devices using Android dominating sales of low-priced devices. This is particularly the case for smartphones where the price gap between the 2 has grown over time yet this does not appear to have impacted on switching.
• While Android users face lower switching costs than Apple users, we consider there are still material actual or perceived barriers to switching, including: (i) learning costs; and (ii) barriers relating to the transfer of data, apps, app content and managing subscriptions (including some that arise due to requirements to use proprietary in-app payment systems).

In addition, Google benefits from material barriers to entry and expansion faced by potential rival providers of operating systems. These include:

• Strong indirect network effects and economies of scale in the development and maintenance of mobile operating systems. In particular, the benefit to users of an operating system increases with the volume and quality of content and apps they can access through that operating system and similarly the benefit to content providers/app developers increases with the number of users they can access through an operating system. This means it is difficult for a new operating system to gain traction as they cannot attract one set of customers without the other and this also makes it even more difficult to achieve scale and overcome barriers due to economies of scale.
• Any new entrant seeking to compete with Google by licensing its mobile operating system to existing manufacturers would have to attract those manufacturers away from Google’s version of Android. As detailed in Competition in the supply of mobile devices and operating systems, this would entail significant challenges due to Google’s complex set of agreements and payments to device manufacturers which mean any new entrant would need to be able to match the financial incentives offered by Google to manufacturers and also offer alternatives to Google’s core apps and APIs.
• Barriers to users switching away from their current mobile ecosystems would substantially limit the chances of a new entrant.

Given these barriers to entry and the fact that Android is the only licensable mobile operating system in the UK (and is the only large licensable operating system we are aware of internationally), ^{[footnote 643]} manufacturers appear to have no credible alternative option but to use the Android operating system.

Based on these findings, we took the view in Competition in the supply of mobile devices and operating systems that Google has substantial and entrenched market power in the supply of mobile operating systems.

Strategic position

We consider there to be strong evidence that, based on the proposed test for Strategic Market Status, Google has a strategic position in the digital activity of mobile operating systems for the following reasons.

First, in the UK, Google has achieved a very significant size and scale in its supply of mobile operating systems, with its products being used by a very high proportion of the population. There were over [30 to 40] million active Android smartphones in the UK in 2020 and over [5 to 10] million active Android tablets compared to a UK population of 67 million.^{[footnote 644]}

Second, Android is the entry point into Google’s ecosystem and through its agreements with and payments to manufacturers Google can use this position to influence the apps and services that are pre-installed on Android devices and the main gateways through which content can be accessed by and delivered to users (with these gateways themselves being significant in scale and size connecting a large number of users and businesses, as set out below).

In particular, through its control of essential APIs contained with Google Play Services, its suite of core apps (for example Google Search, Google Maps, Gmail, YouTube) with which many native Android apps integrate, and its revenue sharing agreements with manufacturers, Google is able to influence which elements of software and hardware can be accessed by third parties and seek to ensure that other key Google apps are pre-installed prominently. This includes the Play Store and Google Chrome, which are gateways to users accessing native apps and web content on mobile devices and other core Google apps.

Third, Google’s control over the Android operating system gives it scope to:

• further entrench its market power in search advertising;^{[footnote 645]} and
• extend the market power of Android into competitive advantage in other markets.

In particular, through its control of essential APIs and its agreements with manufacturers (including revenue sharing agreements largely based on revenue generated from search advertising) Google is able to confer an advantage on its own apps through pre-installation – including Google Chrome and Google Search which are key gateways for search providers, the Play Store and other core apps – in a way that helps to protect those apps from competition. It also uses its revenue sharing agreements to ensure that Google Search is the default search engine at certain points at which users access search services and more generally collects valuable data through the Android operating system that supports its position in search advertising.^{[footnote 646]}

Summary of our preliminary views in relation to mobile operating systems

In combination, our findings and the related evidence support the view that Google has substantial and entrenched market power in the supply of its mobile operating system, which we consider to be a digital activity.

In addition, it is our assessment that Google’s position in respect of its mobile operating system is ‘strategic’, as that term is currently defined in the government’s consultation.

Given this, Google would, in our view, meets the government’s currently-proposed test for SMS in relation to the supply of mobile operating systems.

Native app distribution

Relevant ‘digital activity’

As outlined in Competition in the distribution of native apps, Google provides software and tools to app developers that allow them to write software (ie native apps) that interacts with Android. Such apps can then be distributed to Android users through Google’s Play Store, provided they adhere to the terms contained in a number of agreements and guidelines. The rules contained within these agreements and guidelines are unilaterally interpreted and enforced through Google’s app review process to which all native apps (both when new and when being updated) are subject.

We consider that there is a specific activity carried out by Google which relates to the distribution of native apps and this includes the following products and services provided to users and app developers:

• Google’s Play Store and associated advertising services.
• Google’s services offered via its Developer Program, Software Development Kits (SDKs) and Play Store review process.

We consider that this activity is ‘digital’ because all the products and services provided are based on digital technologies and facilitate the distribution of computer software by app developers to users. This form of computer software is widely recognised and understood to be digital technology.

Substantial, entrenched market power

As outlined in Competition in the distribution of native apps, Google’s Play Store is the main distribution channel for native apps on Android devices. When looking across Android devices as well as devices using other versions of Android (Huawei’s HMS devices^{[footnote 647]} and Amazon’s Fire OS devices), the Play Store has accounted for [90% to 100%] of downloads in every year since at least 2017 (the first full year of our data). ^{[footnote 648]} Although other methods for distributing native apps are allowed on Android devices – through pre-installation, alternative app stores, and sideloading – the evidence we have received from app developers indicates that they do not consider these other distribution channels to be viable alternatives to the Play Store.

The distribution of native apps through the Play Store is growing over time – for example, in the UK:

• the number of downloads per year has increased from [1.5 to 2] billion in 2017 to [2 to 2.5] billion in 2020; and
• There has been rapid growth in the value of customers billings on apps (including Play Pass) processed by Google Play’s billing system, which have increased from [REDACTED] in 2017 to [REDACTED] in 2020.

Further, we do not consider that Google’s Play Store is constrained by other methods through which app developers can distribute their content to users:

• Web apps are not currently a suitable alternative to native apps for most app developers – despite the potential savings in development costs, they do not currently allow the same features and functionalities as native apps. Much of this is down to restrictions on the features and functionalities of web apps that are imposed by Apple through its WebKit browser engine, as detailed above. These restrictions diminish developers’ incentives to develop web apps for all mobile devices and operating systems (ie including Android devices) as the idea of a web app is to develop one app to be used on browsers on any operating system.
• The Play Store does not face a material competitive constraint from Apple’s App Store. Each app store provides access to a large volume of unique users such that the largest app developers accounting for the most downloads tend to multi-home on both app stores, and Apple and Google face limited constraints from users switching between mobile ecosystems when buying a new device.
• The Play Store also does not face a material competitive constraint from alternative non-mobile devices such as desktops or games consoles. These devices are primarily used for different purposes and are mainly viewed by users as complements rather than substitutes, such that not being available on Android devices is not generally an option for app developers.

Based on these findings, and as explained in Competition in the distribution of native apps, Google has, in our view, substantial and entrenched market power in the distribution of native apps.

Strategic position

Applying the test for Strategic Market Status currently proposed in the government’s consultation, we also consider that Google position in the digital activity of native app distribution is ‘strategic’ (as currently defined in the consultation), for the following reasons.

First, in the UK Google has achieved a very significant size and scale in mobile app stores with the Play Store being used by a very high proportion of the population. The Play Store is pre-installed on almost all Android devices and, as set out above, there were over [30 to 40] million active Android smartphones in the UK in 2020 and over [5 to 10] million active Android tablets. On average [2 to 2.5] million users downloaded an app from the Play Store on each day in the UK.^{[footnote 649]} In addition, Google directly generated revenue on apps from the Play Store of $[200 to 400] million via Google Play’s billing system in the UK in 2020.

Second, Google’s Play Store is the main way to distribute native apps on Android devices and many app developers rely on such native apps. This means that Google’s Play Store is an important access point or gateway to users for a diverse and large range of businesses. In particular:

• on average [2 to 2.5] million users download an app from the Play Store on each day in the UK;^{[footnote 650]}
• roughly [800,000 to 900,000] app developers had roughly [2.5 to 3] million apps on the Play Store in the UK in 2020; and
• [REDACTED] of customer billings on apps (including Play Pass) were processed through Google Play’s billing system in the UK in 2020.

Third, Google’s control over access to the Play Store means that it is able to determine the ‘rules of the game’ for app developers seeking to distribute apps on Android, in particular through its development of SDKs and through the Google’s app review process (and the ability to reject apps or app updates which do not comply with its rules).

Fourth, Google can use its control over app distribution on Android to extend the market power of the Play Store to gain a competitive advantage in other markets. In particular, Google is able to confer an advantage on its own apps which do not have to comply with rules such as the payment of a commission to Google. In addition, Google is able to use its position to gain access to confidential information which may assist it in developing apps, services and devices in a way which departs from competition on the merits.

Summary of our preliminary views in relation to native app distribution

In combination, our findings and the related evidence support the conclusion that Google has substantial and entrenched market power in the distribution of native apps, which we consider to be a digital activity.

In addition, it is our assessment that Google’s position in respect of native app distribution is strategic.

Given this, Google would, in our view, meet the government’s proposed test for SMS in relation to native app distribution.

Mobile browsers and browser engines

Relevant ‘digital activity’

As outlined in Competition in the supply of mobile browsers, Google has a browser called Chrome and a browser engine called Blink.

We consider that there is a specific activity carried out by Google which relates to the supply of mobile browsers and browser engines which covers both Chrome and Blink.

We consider this activity is ‘digital’ because the products and services provided are based on digital technologies and facilitate the distribution of digital content, as well as in certain cases software, by content providers to users. The primary use of a browser is to access the web and browse the internet – these activities are widely recognised and understood to be digital in nature.

Substantial and entrenched market power

As shown by the data presented in Competition in the supply of mobile browsers, Google’s Chrome browser has a more than 75% share of supply on Android devices. The next largest browsers are Samsung at 15% and Firefox at 4%. Across operating systems, Chrome’s share of supply for mobile browsers amounts to around 40%. This share has been steadily increasing over the last decade, starting at only 2% in 2012.

When considering both mobile and desktop devices, Chrome’s position is still strong, with Chrome holding a share of almost 50%.

With respect to browser engines, Google’s Blink browser engine has a share of supply in browser engines on Android devices of at least 95%, as most other browsers on Android devices (including Samsung Internet) use Blink. Across mobile operating systems, Blink has a share of just under 50%.

Further, we consider that the constraint from other browsers is limited for several reasons.

• First, Google influences user behaviour through pre-installation, default settings and choice architecture. A key part of this is Chrome being pre-installed on most Android devices and often set as the default browser. Pre-installation and default settings are important in determining consumer choice, implying that this constitutes a key barrier for other browsers to acquire users. This is reinforced by Google making it difficult for users to change the default browser.
• Second, the importance of web compatibility limits the extent to which Blink-based browser providers are willing to make adjustments to Blink and hence the extent to which they are able to differentiate themselves from Chrome. It further limits the constraint browsers based on other browser engines pose on Chrome.

Based on these findings, we took the view in Competition in the supply of mobile browsers that Google has substantial and entrenched market power in the supply of its mobile browser and browser engine.

Strategic position

We consider that, based on the government’s test for Strategic Market Status as proposed in its consultation, Google’s position in the digital activity of browsers and browser engines can be considered ‘strategic’ for the following reasons.

First, Chrome accounted for almost 40% of all web page views on mobile devices in the UK in 2020. When considering all mobile browsers based on Google’s Blink browser engine, this figure increases to just under 50%. While Google no longer sets Google Search as the default search engine in Chrome and provides users with a search engine choice screen instead, in almost all cases in which the choice screen was used, Google Search was chosen – resulting in substantial revenues from search advertising for Google through Chrome.^{[footnote 651]}

Second, other than through app stores, web browsers are the most important way for users of mobile devices to access content and services over the internet. In addition to the important role that browsers play in enabling users to search for and consume content, browsers are one of the key sources of traffic for search engine providers as well as other businesses that want to reach users with their content and products online. Browsers are hence an important gateway through which online content can be accessed by and delivered to users.

• The Chrome browser, given its position, is an important access point or gateway to users for a diverse and large range of businesses. This includes both online content providers and, more specifically, search providers.
• Blink, as the browser engine for most browsers on Android devices, further allows Google to impact what functionality is offered and determine what user data is collected on all Blink-based browsers.

Third, Google can use its control of Chrome and Blink to determine the ‘rules of the game’ for digital advertising. In particular, Google can determine what user data can be collected by websites on Chrome. This then influences the effectiveness of digital advertising as well as key aspects of competition in digital advertising – an area in which Google is active as a digital advertising provider. Google can further limit the user data that is collected on other browsers that are based on Blink, limiting the availability of, and thus scope for publishers and advertisers to switch to, browsers that allow for more user data collection.

Fourth, Google’s control of Blink and its position in browsers gives it scope to entrench Google’s market power in the supply of ad inventory and in the supply of ad tech services. Google can use its control to influence competition in the supply of ad inventory and in the supply of ad tech services, through the deprecation of third-party cookies on its browser and other Blink-based browsers (which Google has proposed to do as part of its Privacy Sandbox proposal) or by restricting the functionality associated with user tracking for third parties, but retaining this functionality for Google.

Summary of our preliminary views in relation to mobile browsers and browser engines

In combination, our findings and the related evidence support the conclusion that Google has substantial and entrenched market power in the supply of mobile browsers and browser engines, which we consider to be a digital activity.

In addition, it is our assessment that Google’s position in respect of mobile browsers and browser engines is ‘strategic’, as that term is defined in the government’s consultation on a new pro-competition regime.

Given this, Google would, in our view, meet the government’s proposed test for SMS in relation to mobile browsers and browser engines.

Initial assessment on Strategic Market Status for Google

Based on the evidence and findings set out in this report and supporting appendices, Google would, in our view, meet the criteria for SMS currently suggested in the government’s consultation for each of the following activities within its mobile ecosystem: (i) mobile operating systems; (ii) native app distribution; and (iii) mobile browsers and browser engines.

Codes of conduct

The government has indicated its intention that, under its proposed new regime, firms with SMS would be subject to legally enforceable codes of conduct, which would manage the effects of market power by setting out how that firm is expected to behave. These codes are intended to offer clarity to both users and firms designated with SMS, aiming to influence the latter’s behaviour in advance and thus to prevent negative outcomes before they occur. The code is intended to address the adverse effects of market power, and would apply at the point of designation, to allow the DMU to intervene promptly and address urgent concerns.

However, given the scale of the market power of the digital platforms, the government has also indicated its intention for the DMU to be able to put in place interventions targeted at the sources of market power, described as pro-competitive interventions (PCIs). The codes are intended to mitigate the effects of market power and should work alongside these PCIs that address the sources of market power, and which are discussed further below.

The government has proposed that a code will apply to the activity (or activities) that led to a firm being designated with SMS, and that it will consist of high-level objectives and principles that specify the behaviour expected of the firm in order to comply with the code, supported by guidance. Under the government’s proposals, each component would take the following form:

• Code objectives: would set out the overarching aims and scope of the code. The 3 objectives proposed in the government consultation are:

  • Fair Trading: users are treated fairly and are able to trade on reasonable commercial terms with firms with SMS. This aims to prevent exploitative conduct.
  • Open Choices: users face no barriers to choosing freely and easily between services provided by firms designated with SMS and other firms. This aims to prevent exclusionary conduct, for example, the entrenchment, protection or extension of market power.
  • Trust and Transparency: users have clear and relevant information to understand what services firms designated with SMS are providing, and to make informed decisions about how they interact with the firm. This aims to promote informed and effective choices.
• Code principles: legally binding principles would be derived from the objectives and define the behaviour expected of firms designated with SMS to comply with the code. The government has indicated that it is considering options regarding the extent to which these principles are determined through legislation or by the DMU. For the purpose of our analysis below, we have assumed that the DMU will have flexibility to identify a list of principles within the scope outlined by the government’s consultation.^{[footnote 652]}
• Code guidance: the DMU would have the ability to develop guidance specific to each of the firms with SMS, to outline its view on how the code’s legal requirements apply to that firm. Where an SMS firm has different codes as a result of involvement in distinct digital activities, guidance could be established for each code.^{[footnote 653]} The guidance could include specific instances of behaviour that may breach the code, in order to clarify what is expected of the firm designated with SMS. The guidance would be aimed at helping firms to comply with the code’s legal requirements, but would not in itself be legally binding.

Potential design of codes of conduct for activities within mobile ecosystems

In this section, we have set out some potential principles that we believe could fit beneath each of the 3 code objectives in any codes produced for Apple or Google in relation to the activities in which we consider them to meet the criteria for possible designation with SMS, as detailed above. For each principle, we also provide illustrative examples of issues and harmful practices which have been raised to us as potential concerns, and that we think could be well suited to being addressed through provisions in a code. As we consider below, the code of conduct would apply across the range of different relationships between Apple and Google, as owners of the relevant digital activities, and the consumers and business users which use them, including app developers and other online content providers.

At this stage, we have not sought to undertake this exercise for each of the potential SMS activities for Apple and Google separately. Instead we have sought to demonstrate, based on the various assumptions and principles set out above and through the illustrative examples provided in the tables below, how code objectives and principles could be relevant to the types of harms from the exploitation of market power in mobile ecosystems that we have identified to date. We will seek to refine our assessment and application of these proposed principles in the second half of our study, and we also recognise that there may be efficiency, privacy, security or other arguments for the practices in question.

Our purpose here is to demonstrate that there is a wide range of concerns across the markets we have reviewed, and that the principles identified in the government consultation to date would be well suited for addressing those concerns: we are not drawing any conclusions into whether, based on their current activities, Apple and Google would ultimately be found to be in breach of any hypothetical code of conduct in the form we have envisaged.^{[footnote 654]}

Fair trading

The ‘fair trading’ objective would require a firm designated with SMS to trade on fair and reasonable terms for services where they are an unavoidable trading partner as a result of their gateway market position. The fair trading objective is intended to address concerns around the potential for exploitative behaviour on the part of the designated firm.

In the context of mobile ecosystems, the principles associated with this objective are intended to address concerns around the potential for Apple and Google to impose unreasonable terms on other actors in the mobile ecosystem, including on app developers, competitors and end customers. Our preliminary view is that the following potential principles reflect the concerns we have found:

• to trade on fair and reasonable contractual terms;
• not to apply unduly discriminatory terms, conditions or policies to certain customers;
• not to unreasonably restrict how customers can use platform services;
• to act in customers’ best interests when making choices on their behalf; and
• to require use of data from customers only in ways which are reasonably linked to the provision of services to those customers.

Table 8.1 provides examples of some of the concerns that we have heard in the first half of this study that we believe could be addressed under each of these principles.

Table 8.1 Fair trading: concerns that could be addressed under the code

Fair trading principles	Examples of concerns within each activity that we believe could be addressed under the ‘fair trading’ principles
To trade on fair and reasonable contractual terms	App stores: Concerns that Apple’s MFi agreements undermine developers’ IP rights (The role of Apple and Google in competition between app developers). App stores: Concerns that Apple’s contractual terms and conditions unreasonably restrict Cloud gaming (The role of Apple and Google in competition between app developers).
Not to apply unduly discriminatory terms, conditions or policies to certain customers	Operating system: Concerns that Apple and Google are unreasonably providing some developers with preferential access to interoperability relative to others, for example through providing competing browsers or native apps with unequal access to APIs (Chapters 5 and The role of Apple and Google in competition between app developers). App stores: Concerns about the ability of Apple and Google to impose terms and conditions that unreasonably discriminate against certain customers or business models (The role of Apple and Google in competition between app developers).
Not to unreasonably restrict how customers can use platform services	Browsers: Concerns that certain mobile browser functionality within the mobile ecosystem defaults to Apple/Google even when user has selected alternative browser as default (for example Google widget; Voice services) (Competition in the supply of mobile browsers). App stores: Concerns about restrictions on app developers’ choice of payment solutions provider (The role of Apple and Google in competition between app developers).
To require use of data from customers and business users only in ways which are reasonably linked to the provision of the service for which the data was obtained.	App stores: Concerns about Apple and Google potentially requiring access to commercially sensitive data relating to competition in app development, through operation of the app store and app review process (The role of Apple and Google in competition between app developers).
To act in customers’ best interests when making choices on their behalf	Browsers: Concerns regarding the limited functionality of the WebKit browser engine on iOS, which may potentially restrict competition in the market for app distribution by (for example push-notification browser engine functionality on iOS (Competition in the supply of mobile browsers). App stores: Concerns that app developers have insufficient control over refunds and cancellations for purchases made using IAP, because Apple and Google make choices on their behalf through their control of customer relationships (The role of Apple and Google in competition between app developers).

Open choices

The ‘open choices’ objective would require an SMS platform to allow users to choose freely between elements of the platform’s services and those offered by competitors. This objective is intended to address the potential for exclusionary behaviour on the part of the SMS platform, ie, where the SMS platform has the ability and incentive to reserve certain activities to itself, as a result of its market power in a core activity. In mobile ecosystems, this may either be through bundling activities together such as app distribution and payment systems.

This principle could also address concerns around the potential for Apple and Google to use the sources of market power in SMS activities to unreasonably favour their own businesses in associated markets, such as their browsers, app stores and their own apps and services to users.

Finally, this principle could address situations where greater interoperability across ecosystems may benefit users (for example, to enable them to transfer content between devices more easily).

Our preliminary view is that the following principles reflect the concerns we have found:

• not to impose undue restrictions on competitors or on the ability of customers to use competing services, including through bundling or tying the provision of products or services in markets where the SMS platform has market power with other services in a way which has an adverse effect on users;
• not to influence competitive processes or outcomes in a way that unduly self-preferences a platform’s own services, or services for which the platform derives a commercial benefit, over rival services, including through use of preferential access to data;
• not to unreasonably restrict interoperability with third-party technologies where this would have an adverse effect on users;
• to hold own apps/services accountable to the same privacy standards as are being imposed on third parties; and
• not to unreasonably withhold, withdraw, or deprecate APIs or hardware in a way which has an adverse effect on users.

Table 8.2 summarises some of the concerns that we have heard in the first half of study that we believe could be addressed under each of these principles.

Table 8.2 Open Choices: concerns that could be addressed under the code

Open Choices principles	Examples of concerns within each activity that we believe could be addressed under the ‘open choices’ principles
Not to impose undue restrictions on competitors or on the ability of customers to use competing services, including through bundling or tying the provision of products or services in markets where the SMS platform has market power with other services in a way which has an adverse effect on users	Operating systems: Restrictions on users’ ability to transfer data and subscriptions when using the same apps on different operating systems, increasing costs for users and making it harder to switch between operating systems (Competition in the supply of mobile devices and operating systems). Operating systems: Concerns about restrictions in Google agreements which could potentially hold back versions of Android not using Google Mobile Services (Competition in the supply of mobile devices and operating systems). Browsers: Restrictions preventing use of third-party browser engines on iOS, which limits the ability of downstream suppliers (browsers; web-based apps) to attract users (Competition in the distribution of native apps and Competition in the supply of mobile browsers). App stores: Concerns that apps accessed outside of first-party app stores do not automatically update, with the user having to update the app manually (Chapters 4). App stores: Concerns that Apple’s and Google’s payment systems are bundled with their app store services (The role of Apple and Google in competition between app developers). App Stores and Browsers: Concerns regarding the pre-installation of own browsers; pre-installation of own native apps (Competition in the supply of mobile browsers and The role of Apple and Google in competition between app developers).
Not to influence competitive processes or outcomes in a way that unduly self-preferences a platform’s own services over those of rivals	Operating systems and app stores: Concerns that the licensing of key apps and APIs as well as certain payments are conditional on the pre-installation and prominent display of an app store (Competition in the distribution of native apps). App stores: Concerns that ranking in the app store is determined in a manner that favours the app store provider’s own apps (The role of Apple and Google in competition between app developers). App stores: Concerns that Apple/Google own apps do not face the same delays from app review process as third-party apps (The role of Apple and Google in competition between app developers). Operating systems and Browsers: Concerns regarding Google’s use of ancillary services such as Gmail to prompt users of third-party browsers on Android devices to switch default browser to Chrome (Competition in the supply of mobile browsers). App stores: Concerns regarding the impact of in-app commissions and anti-steering restrictions on downstream rivals, such as creating additional costs for rivals and preferencing first-party apps (The role of Apple and Google in competition between app developers).
Not to unreasonably restrict interoperability with third-party technologies where this would have an adverse effect on users;	Browsers and app distribution: Concerns that Apple restricts access to alternatives to Apple’s Webkit browser engine on iOS, and this adversely impacting consumers for web apps (Competition in the supply of mobile browsers). Browsers and app distribution: Concerns that Apple restricts access to certain important functionality on the Webkit browser engine on iOS which would allow third parties to develop more effective web apps, and this adversely impacting consumers (Competition in the supply of mobile browsers). Operating systems: Concerns regarding the lack of interoperability of first-party apps with services on other devices, including examples of concerns relating to iMessage (Competition in the supply of mobile devices and operating systems). Operating systems: Concerns that a lack of interoperability prevents users from managing subscriptions across devices (Competition in the supply of mobile devices and operating systems).
To hold own apps/services accountable to the same privacy standards as are being imposed on third parties	Operating systems and app stores: Concerns that Apple may not be applying the same privacy standards to itself as to third parties, insofar as its ATT policy rests on a definition of ‘tracking’ that excludes Apple’s own use of its users’ personal data from different Apple services and from third-party apps (The role of Apple and Google in competition between app developers). Browsers and app stores: Concerns regarding choice architecture within Apple and Google’s respective ecosystems potentially being used to influence consumer behaviour in a way that preferences Apple/Google. This includes through privacy choice architecture employed in relation to both native apps (ATT) and browsers (ITP and Privacy Sandbox) (Chapters 5 and The role of Apple and Google in competition between app developers).
Not to unreasonably withhold, withdraw, or deprecate APIs or hardware in a way which has an adverse effect on users	Operating system and browsers: Concerns that Apple and Google may be unreasonably withholding APIs from third-party developers which are available to own native apps and own browsers (Chapters 5 and The role of Apple and Google in competition between app developers). Operating system: Concerns about inferior access to attribution and monitoring APIs for native app developers using third-party advertising services as compared to those using Apple’s advertising services (The role of Apple and Google in competition between app developers).

Trust and transparency

The ‘trust and transparency’ objective is designed to ensure an SMS platforms provide sufficient information to users, including both consumers and businesses which transact with the platform, so that they understand how the platform operates and are able to make informed decisions. A number of digital markets are characterised by an asymmetry of information, with limited evidence provided to users on how algorithms work, and the processes followed by digital platforms in implementing terms and conditions far from transparent. There are also a number of digital markets where platforms with SMS data do not provide regular or sufficient data to users about normal trading arrangements. This is particularly important in respect of those digital markets where customers rely on the digital platform to provide accurate and transparent information about the services provided.

A related concern associated with digital markets is that choice architecture should be designed in such a way as to empower consumers to make informed and effective decisions. Users should also have confidence that decisions are being made fairly and according to publicly stated criteria. Users may otherwise be influenced by choice architecture and default settings into making choices that may not be in their best interests, and may also lack sufficient information to make effective choices, undermining the effectiveness of competition. All of these factors can reduce trust in the market.

Our preliminary view is that the following principles reflect the concerns we have identified:

• to provide clear, relevant, accurate and accessible information to users;
• to ensure that choices and defaults are presented in a way that facilitates informed and effective customer choice and ensures that users can take decisions in their own best interests;
• to give fair warning of and explain changes that are likely to have a material impact on business users; and
• to ensure the process for reviewing and implementing policies that apply to business users of mobile ecosystems is clear and transparent, where appropriate with an accessible and well-defined appeals process.

Table 8.3 summarises some of the concerns we have identified in the first half of study that we believe could be addressed under each of these principles.

Table 8.3: Trust and transparency: concerns that could be addressed under the code

Trust and transparency principles	Examples of concerns within each activity that could we believe be addressed under the ‘trust and transparency’ principles
To provide clear, relevant, accurate and accessible information to users;	App stores: Concerns that app store guidelines and feedback provided during app review processes are not sufficiently clear and transparent, potentially leading to unnecessary delay in approval of new apps or app updates (The role of Apple and Google in competition between app developers).
To ensure that choices and defaults are presented in a way that facilitates informed and effective customer choice and ensures that users can take decisions in their own best interests;	Browsers: Concerns about the complexity of the user journey to change the default browser deters users from switching defaults (Competition in the supply of mobile browsers). Operating systems and app distribution: Concerns that the process associated with sideloading of apps, which often involves multiple steps and warning signs, may deter users through its complexity and design (Competition in the distribution of native apps). Browsers and app stores: Concerns regarding choice architecture within Apple and Google’s respective ecosystems potentially being used to influence consumer behaviour in a way that preferences Apple/Google. This includes through privacy choice architecture, defaults and pre-installation of apps including browsers, and through browser choice design (Chapters 5 and The role of Apple and Google in competition between app developers). Browsers: Concerns that users may not be aware of the overriding of customer browser defaults by native apps/widgets (in-app browsers) (Competition in the supply of mobile browsers).
To give fair warning of and explain changes that are likely to have a material impact on business users	App stores: Concerns that third-party native app developers receive insufficient information about search ranking algorithms and editorial features on Apple and Google’s app stores (The role of Apple and Google in competition between app developers).
To ensure the process for reviewing and implementing policies that apply to business users of mobile ecosystems is clear and transparent, where appropriate with an accessible and well-defined appeals process.	App stores and app review process: Concerns that current app review appeal processes are inadequate (The role of Apple and Google in competition between app developers).

Summary of our initial views relating to codes of conduct

Based on the above, we would expect that, if the government proceeds with proposals comparable to those in its consultation, then the codes of conduct that it presently envisages for the new regime would be well-placed to address the concerns we have identified to date about the ability of Apple and Google to exploit market power. This is particularly the case in relation to issues such as self-preferencing and a lack of transparency regarding the app review process. However, codes would not necessarily be designed to directly target the sources of market power. As such, in the next section we give an outline of how we believe PCIs, as currently envisaged in the government’s consultation, could work alongside codes in promoting competition in mobile ecosystems.

Pro-competitive interventions

The codes of conduct described in the previous section would be intended to provide the DMU with the ability to protect business users, competitors and consumers from the ability of SMS firms to exercise market power. Such codes may not address all of the concerns identified in this study to date. In particular, it appears to us that interventions which go further than addressing possible harmful terms or practices and are more targeted at opening up aspects of mobile ecosystems to greater competition, may be implemented through the type of PCIs that the government’s consultation currently envisages.

The government’s consultation proposes that the DMU should have a broad level of discretion in designing and implementing PCIs in instances where it can meet the legal test of proving that there exists an adverse effect on competition.

PCIs are more intrusive measures which aim to open up markets to greater competition. They are intended to be used to address the root causes of substantial and entrenched market power in digital markets, by addressing the characteristics in these markets that lead to weak competition. We consider that PCIs could be used to, over time, introduce more effective competition, and if successful, might ultimately mean that SMS designation and the need for a code of conduct may be removed for a particular firm.

In respect of mobile ecosystems, we consider that PCIs may be appropriate where addressing the concerns we have identified would require Apple and Google to introduce new forms of interoperability or technical changes. For example, we have highlighted that there might be benefits to competition and users from requiring Apple to support third-party browser engines or third-party app stores, both of which are supported by Android. At this stage, we have not fully established the extent to which opening up ecosystems would require new functionality, as opposed to the removal of current restrictions, which if found unreasonable could be removed under a code of conduct. We anticipate that such consideration of whether any specific measures would be beyond the scope of a code of conduct (and more appropriately addressed through PCIs) will be a central part of any assessment of possible interventions by the DMU.

In our view, it appears possible that certain of the potential demand-side interventions targeted at empowering consumers to make meaningful and informed choices could be implemented through either tool. However, in our current view, it may be more appropriate to introduce more intrusive remedies, such as the replacement of a default browser with a choice screen, through a PCI that involved a detailed assessment regarding its potential effectiveness and proportionality as well as any risks and possible unintended consequences.

PCIs could be used to tackle Apple’s and Google’s market power across their mobile ecosystem, for example, including:

• requiring new forms of interoperability between first-party apps on iOS and Android (Theme 1);
• requiring Apple and Google to amend the app review process to support third-party app stores or other forms of app distribution, such as sideloading, subject to appropriate conditions to ensure privacy and security (Theme 2);
• requiring choice screens to make it easier to switch browsers (Theme 3);
• requiring changes to management of the business or to internal systems for managing data, in order to implement separation of the process of app development from other aspects of the mobile ecosystem (Theme 4).

We believe that these kind of PCIs, potentially used alongside codes of conduct, have the potential to bring significant benefits, including in addressing the key areas of consumer harm identified in this study resulting from weak competition within and between mobile ecosystems, as outlined further in Overview of mobile ecosystems. In our view, our findings in this study to date indicate there are significant potential benefits from the DMU having the power to impose PCIs where necessary to address the sources of market power in the markets within the scope of this study.

9. Our decision on a market investigation reference

Our statutory duties

Where the CMA considers that there is a case for a more detailed examination of a market (or markets) it may refer the market(s) for an in-depth market investigation.^{[footnote 655]} A market investigation seeks to determine whether features of the market(s) have an adverse effect on competition, and if so, the CMA decides what remedial action, if any, is appropriate to take using its order making powers, or recommends remedial actions for others to take.

Under section 131 of the Enterprise Act 2002, the CMA can make a market investigation reference where it has reasonable grounds for suspecting that any feature, or combination of features, of a market (or markets) in the UK prevents, restricts or distorts competition. Prior to making that reference, it must consult publicly on its intention to do so.^{[footnote 656]}

Where the CMA has such reasonable grounds, it retains a discretion whether to make a market investigation reference. In line with its published guidance, the CMA applies the following 4 criteria in order to determine whether, in the circumstances, a market investigation reference appears to be an appropriate and proportionate response:

• the scale of the suspected problem is such that a reference would be an appropriate response (ie that the adverse effect on competition is likely to be significant based on the size of the market, the proportion of the market that is affected and the persistence of the market features);
• there is a reasonable chance that appropriate remedies would be available;
• it would not be more appropriate to address the concerns through undertakings in lieu of a reference; and
• it would not be more appropriate to address the competition issues through alternative powers available to the CMA or through the powers of sectoral regulators.

Where the CMA has opened a formal market study, the Enterprise Act creates a specific milestone of 6 months from publishing the notice launching the study by which the CMA must make an assessment of whether it intends to make a market investigation reference in relation to any matters covered by that notice.^{[footnote 657]} For this market study, the deadline for the CMA to publish its intentions in this regard is 14 December 2021.

As noted, the CMA must consult before making a market investigation reference. However even if – based on the statutory tests and published criteria above – the CMA decides at that 6 month point not to make a reference, it must still consult on that decision if it has received stakeholder representations since the start of the market study that it should make a reference. The CMA has not received any such representations during the course of this market study.

Potential candidates for a market investigation

Based on our initial findings, we believe there are reasonable grounds for suspecting that features of the following markets could be restricting or distorting competition in the UK:

• mobile operating systems, with a focus on the closed nature of Apple’s ecosystem, and on the nature of Google’s licensing agreements with device manufacturers;
• app stores and app distribution, with a focus on addressing the sources of Apple’s and Google’s market power in native app distribution within their respective ecosystems; and
• browsers and browser engines, with a focus on Apple’s WebKit restriction and other barriers to competition such as pre-installation, default settings and choice architecture.

Given the significance of these markets and the impact of the issues identified, a market investigation would appear to be a proportionate response. Many of the interventions discussed in the previous chapter could be implemented through the order making powers available to the CMA within a market investigation.

We therefore consider the decision as to whether to propose a market investigation in any or all of these areas at this time rests primarily on whether it is the most appropriate mechanism for assessing the issues and delivering the required outcomes.

The CMA’s decision not to make a market investigation reference

As set out in our statement of scope,^{[footnote 658]} we intend to use this market study in order, among other things, to inform the establishment and development of the proposed new pro-competition regime for digital markets in the UK. In particular, we signalled that we expect that this market study will be an important input into any formal SMS designation decisions taken by the DMU in relation to the activities within the scope of this market study. Our intention was also to help further the thinking on key elements of the regulatory regime such as codes of conduct, should the DMU decide that Apple or Google have SMS in any of these activities.

On the basis of the progress that has been made towards establishing the new regime, with the government recently consulting on its developed proposals,^{[footnote 659]} this continues to be the CMA’s intention. We have set out in Applying our findings to the proposed new pro-competition regime for digital markets of this interim report our initial views on whether we believe Apple and Google would meet the expected test for SMS designation (as that test is currently articulated within the government’s proposals), as well as highlighting various practices that could be addressed through any associated codes of conduct, were the DMU decided to designate either firm as having SMS.

Our current assessment is that the DMU – through a combination of legally enforceable codes of conduct and pro-competitive interventions – will in principle be best placed to tackle the competition concerns identified by this market study to date. There are 3 main reasons for this:

• The types of interventions that we have identified to address our competition concerns would be highly complex, and in some cases technical, potentially needing iterative design, testing, and trialling. In most cases there will be a need for ongoing monitoring and updating of measures as the relevant technology and market evolves, or to address any unintended consequences that arise. This type of implementation will require ongoing oversight and dialogue with the firms in question, whereas a market investigation (resulting in remedies) is arguably more suited to one-off interventions. Implementing these remedies through the DMU will also allow for the adaptation of interventions over time, for example in response to changes in market conditions that could result from the numerous legislative proposals and other policy developments ongoing internationally.
• Given the interconnected nature of different activities contained within and connected to mobile ecosystems (and certain activities outside the immediate focus of this market study), it will be important to assess and design a package of interventions aimed at addressing potential harms to competition in a range of related markets or activities. This approach to interventions would require a particularly broadly-scoped market investigation.
• A market investigation at this time could risk cutting across the work to establish the new regime. In particular, implementing potentially transformative remedies in markets or activities that are in parallel being formally assessed by the DMU with regard to SMS designation and code design may be an inefficient use of public resources and create confusion for market participants.

On this basis, the CMA has decided not to make a market investigation reference at this time. Notwithstanding this, the CMA will continue to keep under review the potential use of all its available tools during and following the second half of the study, taking into account any relevant market or legislative developments that may arise. This includes the possibility of making a market investigation reference at a later point in time or taking further enforcement action under our competition or consumer powers. We may, for example, revisit our present decision not to make a reference if the legislation required to bring the proposed new regime into force is not laid before Parliament for some time, or its anticipated scope materially altered, such that it no longer appears to us that action by the DMU represents the most effective and timely means of addressing the issues we have identified.^{[footnote 660]}

As required by Enterprise Act 2002, the CMA is publishing alongside this interim report a formal notice of its present decision not to make a reference.^{[footnote 661]}

10. Next steps

This interim report has provided an update on the progress we have made to date in this market study. It has set out our initial findings on a wide range of potential concerns within each of our 4 themes, including on:

• demand and supply-side barriers to entry and expansion in the supply of mobile devices and operating systems;
• the existence of market power for Apple and Google in the distribution of mobile apps;
• limitations to genuine competition and choice in the market for mobile browsers; and
• the conduct of Apple and Google in determining outcomes in downstream app markets.

Going forward, we want to gather more evidence to test and refine our thinking in these areas, and to identify where intervention might be most necessary and appropriate. Publication of this interim report for consultation is an important first step in that process.

As noted in the previous chapter, we will also keep under review the possible use of any of the CMA’s powers in relation to the issues we have identified, if based on our further work or wider changes in circumstances it appears to us that action by the DMU is no longer the most effective or timely means of addressing any of those issues.

This consultation

We are consulting on the evidence and preliminary findings that we have set out in this interim report and supporting appendices. We would welcome feedback from any interested parties and hope to gather views from stakeholders with a diverse range of perspectives.

The topics we are seeking views on are set out in Box 10.1

Box 10.1: Our consultation topics

We are seeking views and information on the following 5 topics:

1 Our understanding of the markets within the scope of the study.

2 Our initial findings on the competition concerns under each theme:

• Theme 1: Competition in the supply of mobile devices and operating systems.

• Theme 2: Competition in the distribution of native apps.

• Theme 3: Competition in the supply of mobile browsers.

• Theme 4: The role of Apple and Google in competition between app developers.

3 The merits and challenges of the range of potential interventions that we have identified in this interim report. We indicated in boxes some specific areas that we would welcome views and evidence on in Overview of potential interventions, in relation to:

• Remedy Area 1:

• Remedy Area 2:

• Remedy Area 3:

• Remedy Area 4:

4 The potential application of our preliminary findings to the framework of the proposed new pro-competition regulatory regime for digital markets (Applying our findings to the proposed new pro-competition regime for digital markets).

5 The further work we propose to do over the second half of the study, as indicated throughout this report, and summarised later in this chapter.

How to respond

To respond to this consultation, please email or post your submission to:

Email: mobileecosystems@cma.gov.uk

Post: Mobile Ecosystems Market Study
Competition and Markets Authority
25 Cabot Square
London
E14 4QZ

Please respond by no later than 5pm GMT on 7 February 2022.

For transparency and to inform public debate, we intend to publish all responses we receive. In providing responses:

• please supply a brief summary of the interests or organisations you represent, where appropriate;
• please consider whether you are providing any material that you consider to be confidential, and explain why this is the case; and
• if the response contains confidential information, please also provide a non-confidential version of your response alongside it.

If you are an individual (ie you are not representing an organisation), please indicate whether you wish for your response to be attributed to you by name or published anonymously.^{[footnote 662]}

The next 6 months

Further work

During the second half of the study, we will focus on obtaining further evidence on specific issues to develop our assessment, as well as continuing to review the evidence we have obtained, and progressing our assessment of potential interventions, particularly in light of the stakeholder feedback we receive.

Some of the specific areas for further and more detailed analysis that we have identified include:

• Further work to understand the barriers to switching. We also plan to learn more on the availability and use of switching apps.
• Quantitative analysis of the impact of pre-installation of apps on market outcomes.
• Further evidence gathering on the security performance and outcomes within Apple’s and Google’s respective ecosystems, and the risks associated with enabling a range of particular functionalities and applications.
• Further assessing the impact of Apple’s ATT changes on Apple’s advertising business and on developers’ businesses, and engagement with the ICO on the data protection implications of any possible interventions.
• Considering the extent of differentiation in practice between in-app commission levels charged by each app store operator, and the impact of recent changes and exemptions to commission levels that they have introduced.
• Further quantitative analysis of app discovery, including the importance of searches for specific apps as opposed to more general searches, and the impact of search ranking on downloads.
• Deepening our understanding of the customer journey when consumers pay for subscriptions or make in-app purchases in native apps, and when they request cancellations or refunds.

In addition to reviewing the responses we receive to this interim report, we will gather more evidence through continued engagement with stakeholders and further requests for information from parties, and remain open to conducting or commissioning targeted research.

Our final report

We will publish our final report by 14 June 2022. It will set out our findings on the extent of competition faced by Apple and Google in respect of their mobile ecosystems. It will also revisit, in light of responses to this interim report and our further analysis, our preliminary views on whether, based on existing market conditions, we consider each company would meet the government’s test for SMS designation (if implemented as currently proposed).

Our final report will also provide our more comprehensive assessment of the most appropriate interventions to address the range of issues that we have identified.

1. In this document, we use the term ‘mobile apps’ or ‘apps’ to describe native apps as opposed to web apps. ↩

2. The term ‘progressive web apps’ relates to newer web apps with added functionalities. ↩

3. Except where stated, ‘iOS’ should be read as including both the iOS operating system for smartphones and the iPadOS operating system used on iPads. ↩

4. In this document, mobile devices using versions of Android that fall within Google’s compatibility requirements are referred to as ‘Android devices’. The one exception to this is Huawei’s devices which fall within Google’s compatibility requirements, but use Huawei Mobile Services instead of Google Mobile Services and are referred to as ‘HMS devices’. Mobile devices using version of Android that do not fall within Google’s compatibility requirements are referred to as ‘Android forks’. ↩

5. This includes not only Android devices, but other versions of Android that do not use Google Mobile Services. ↩

6. Each browser is built on a browser engine, which is responsible for key browser functionality such as speed, reliability and web compatibility. ↩

7. Apple saw strong growth in device sales in 2021, which we understand to be a result of 2 new iPhone releases in the same financial year. ↩

8. Visit the Online Nation 2021 report. ↩

9. One exception to this is Huawei’s devices which use a version of Android that meets Google’s compatibility requirements, but relies on Huawei Mobile Services rather than Google Mobile Service. We refer to these as HMS devices. ↩

10. Google has made recent announcements in respect to the use of its payment system, Google Billing, including that more payments for subscriptions for non-game apps will be subject to a lower commission rate of 15%. ↩

11. Visit Apple’s 2021 10K. This profit figure is disclosed as ‘Income before provision for income taxes’. ↩

12. Visit Alphabet Inc’s 2020 10K. This profit figure is disclosed as ‘Income before income taxes’. ↩

13. Visit the CMA’s Online platforms and digital advertising market study page. ↩

14. Visit the Digital Markets Taskforce casepage. ↩

15. Visit A new pro-competition regime for digital markets. ↩

16. Visit the CMA’s Investigation into Apple AppStore casepage. ↩

17. Visit the CMA’s Investigation into Google’s ‘Privacy Sandbox’ browser changes casepage. ↩

18. Visit the CMA’s Investigation into Google’s ‘Privacy Sandbox’ browser changes casepage. ↩

19. Visit the European Commission investigation into Apple App Store page. ↩

20. Visit the European Commission’s Google Android case page. ↩

21. Visit, for example, in the USA: Cameron et al v. Apple Inc., Epic v. Google, Epic v Apple, and Utah v. Google; and in the UK, Kent v Apple and Coll v Google. ↩

22. As Apple’s iOS is only used in Apple devices, Apple’s share of operating systems mirrors its share of mobile devices. ↩

23. In particular, some manufacturers may receive a proportion of Google’s net revenue from Play Store transactions for setting the Play Store as the default app store on their devices and not pre-loading any similar services such as alternative app stores. ↩

24. For example, Android has a share of just over 70% of worldwide smartphone operating systems based on StatCounter data. Visit the Mobile Operating System Market Share Worldwide Statcounter Global Stats. ↩

25. This also includes native apps downloaded through app stores on Huawei Mobile Services (HMS) devices and Amazon’s Fire OS. ↩

26. Such as the pre-installation of apps by manufacturers, users ‘sideloading’ apps from websites, and the fact that it is possible to sideload a different app store than that which is pre-installed on the device. ↩

27. Other than the Play Store, this includes Samsung’s Galaxy Store, Amazon AppStore and Huawei’s App Gallery. ↩

28. As explained further in this report, Google achieves the prominence of its Play Store through the importance of its other activities in the context of the overall mobile ecosystem. First, as part of agreements with device manufacturers Google shares a proportion of its advertising and, in some cases, Play transaction revenue conditional on the pre-installation and prominent placement of the Play Store. Second, the Play Store is only licensed alongside key Google apps and ‘Application Programming Interfaces’ (APIs) which are needed to ensure that many native Android apps work on Android devices. ↩

29. The commission deducted by Apple and Google from every payment for digital content collected by their payment systems is 30% except in some circumstances where Apple/Google has determined that a lower commission rate of 15% will apply, as explained in Appendix H. ↩

30. Being the default browser means that the browser automatically opens and renders a webpage upon a user clicking a link to a website (for example, in an email), without the user needing to select the browser manually. ↩

31. Google’s rules have become more closely aligned with Apple over time. For example, Google has updated its Payments policy and from September 2021 (or March 2022 for some parties granted an extension) all developers selling digital goods in their apps will be required to use Google Play’s billing system (and pay a service fee from a percentage of the purchase). Before this update, we have heard that some app developers who also provided an option to purchase content via the web have been using alternative payment solutions in addition to Google Play’s billing system for in-app purchases. ↩

32. The CMA is investigating concerns regarding Apple’s terms and conditions for in-app purchases under its Competition Act powers. This investigation is ongoing and no decision has been made as to whether Apple has acted unlawfully. Competition Act investigations are based on different legal tests and standards of proof than the CMA’s market studies. As such, any findings in this market study are without prejudice to, and should not be taken as indicative of, the CMA‘s likely future assessment under the Competition Act. ↩

33. Equitable Interoperability: the “Super Tool” of Digital Platform Governance, Yale Tobin Centre for Economic Policy, 2021. ↩

34. The term ‘choice architecture’ describes the contexts in which users make decisions and how choices are presented to them ↩

35. Further guidance on CMA market investigations is set out in CMA3 Market studies and investigations - guidance on the CMA’s approach and CC3 Market Investigations Guidelines. ↩

36. We may, for example, revisit our present decision not to make a reference if the legislation required to bring the new DMU regime into force is substantially delayed, or its anticipated scope materially altered, such that it no longer appears to us that action by the DMU represents the most effective and timely means of addressing the issues we have identified. Prior to making such a reference, the CMA would consult publicly on its intention to do so, in line with its statutory obligations. ↩

37. Visit the Mobile ecosystems market study case page. ↩

38. Visit the CMA’s Digital Markets Strategy February 2021 refresh. ↩

39. Visit the Government’s consultation on A new pro-competition regime for digital markets, July 2021. ↩

40. Visit the Unlocking digital competition Report of the Digital Competition Expert Panel page, March 2019. ↩

41. Visit the Online platforms and digital advertising market study casepage. ↩

42. Visit the Digital Markets Taskforce casepage. ↩

43. Visit Appendix E for details on the agreements Google has with device manufacturers and app developers. ↩

44. Visit the Ipsos MORI, Attitudes Towards IoT Security Summary Report 2020. ↩

45. According to Ofcom’s Online Nation 2021 report, 91% of households had a smartphone with internet access in 2020, compared with 65% for tablets and 47% for desktop computers. ↩

46. References to desktop devices throughout this report are also referring to laptops. ↩

47. Visit Ofcom’s Online Nation 2021 report. ↩

48. Visit Global Data’s United Kingdom (UK) Online Retailing via Mobile and Tablet, 2019 to 2024 webpage. ↩

49. Visit UK Finance’s Contactless now accounts for more than a quarter of all UK payments press release. ↩

50. Web apps are an alternative type of app that are written to operate through the web browser, rather than being specific to the operating system. These are explained fully in Chapters 4 and Competition in the supply of mobile browsers. ↩

51. For example, with the European Commission’s decision against Android. ↩

52. Visit Ofcom’s Online Nation 2021 report. ↩

53. Visit Ofcom’s Online Nation 2021 report. ↩

54. CMA analysis of data from market participants, as a share of operating system activations. This analysis is set out in more detail in Competition in the supply of mobile devices and operating systems. ↩

55. Apple CarPlay is a complementary feature that can be added to vehicle infotainment systems to enable connectivity to Apple devices, rather than acting a stand-alone operating system. ↩

56. Competition in the supply of mobile devices and operating systems and Appendix E provide further detail on these agreements. ↩

57. For instance, Google offers financial incentives to manufacturers for pre-installing Google Search and Google Chrome apps on their devices. ↩

58. Google’s agreements with manufacturers mean that the Play Store is pre-installed and prominently displayed on virtually all Android devices. Competition in the supply of mobile devices and operating systems and Appendix E provide further detail on these agreements. ↩

59. CMA analysis of data from market participants. See Competition in the distribution of native apps for more detailed analysis of market outcomes in app distribution. ↩

60. Based on data submitted to the CMA by Apple and Google. ↩

61. Competition in the supply of mobile browsers and Appendix F provide more detail on the history and importance of browser engines to browser competition. ↩

62. ‘SMS’ is the test proposed by the government in order for the DMU to determine which firms should be brought within the scope of the proposed new pro-competition regulatory regime for digital markets. ↩

63. We set out our detailed analysis of Apple’s and Google’s financial performance in Appendix D. ↩

64. As reported in CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report, Appendix H, Google paid around £1.2 billion for default positions in the UK alone in 2019. ↩

65. Visit Ofcom’s Online Nation 2021 report. ↩

66. From Apple’s 2020 10K Report. ↩

67. These are revenue figures provided by Apple which are based on Calendar Year 2020. Note, however, that net revenue for Advertising (third-party licensing) is not tracked at the country level by Apple. However, the CMA has obtained estimates of the UK share of the value of the licensing payment from Google to Apple that allows us to estimate total UK revenues within the range provided above. ↩

68. For financial years 2011 to 2014 Apple provided a breakdown of Net Sales by Product in its 10K as: iPhone; iPad; Mac; iPod; Accessories; and iTunes, Software and Services. Therefore, this period we considered the category iTunes, Software and Services to be equivalent to Services, as provided in Apple’s 10K from 2015 onwards. ↩

69. From Alphabet Inc 2020 10K Report. ↩

70. Visit Apple’s 2021 10K report. This profit figure is disclosed as ‘Income before provision for income taxes’. ↩

71. Visit Alphabet Inc’s 2020 10K report. This profit figure is disclosed as ‘Income before income taxes’. ↩

72. The CMA recently opened a consultation on modified commitments in respect of Google’s ‘Privacy Sandbox’ browser changes in this case. ↩

73. Released in April 2021, the ATT framework introduced new rules for how app developers can collect and process users’ personal data for mobile advertising on iOS. We discuss ATT in more detail in The role of Apple and Google in competition between app developers and Appendix I. ↩

74. We make clear where evidence or analysis only relates to mobile devices or operating systems). ↩

75. This research has been undertaken in a commercial context providing data suited to commercial purposes. However, this type of research has limitations in that it often uses online panels. Using online panels can lead to sample bias when respondents are drawn from a panel which does not rely on randomisation methods for its recruitment. Whilst a panel can be made to look like a representative cross-section of consumers in terms of its demographic profile, the characteristics of people who join an online panel may be different from other consumers. This can result in online panels biasing samples towards more affluent, digitally confident and urban consumers. Evidence in the academic research literature suggests that those who join an online panel spend more time on the internet and engage more actively than other consumers in searching for better deals online. This bias can influence research findings on issues such as switching and barriers to switching. More generally, response rates to online surveys can be low (with the resulting risk of non-response bias), while the quality of responses is often not as high as when a respondent interacts with an interviewer. Despite these limitations, the research provided by parties provides some relevant evidence of consumer behaviour in this market, especially in relative terms when comparing data across brands/devices and over-time. ↩

76. This means that Google also has to ensure Android is attractive to manufacturers so that they continue to use Android in their mobile devices. We consider this and the constraint it puts on Google in our assessment below. ↩

77. Visit Appendix E which sets out in detail Google’s compatibility requirements. ↩

78. For example, when users cite the operating system they may be thinking of specific aspects of the operating system including tied products/services. ↩

79. As set out below, there are some key ways in which Android and iOS users appear to differ such as the importance of the price of the mobile device in their decision making. ↩

80. For example, the phrasing of questions differs and the range of potential responses (including the phrasing of those responses) provided to respondents differs. ↩

81. For example, one online UK survey of January 2021 with 1,925 purchasers and 1,896 intenders (respondents shopping for a smartphone for personal use and planning to purchase in the next 6 months) showed that 51% of respondents who had purchased a smartphone considered the ‘Operating system’ to be ‘very important’, 49% the ‘Smartphone brand’, 48% the ‘Price of the phone’ and 46% the ‘Hardware specs’. Similarly, in another survey 75% of respondents said the ‘Smartphone brand/Model’ was one of the main criteria in their choice of mobile phone, 50% said the “OS brand” and 45% the “ease of use”. ↩

82. For example, in one survey the battery life of the phone was the most cited reason for choosing a particular brand and model with 55% of respondents, quality of camera was second with 54% of respondents and the size of screen was third with 51%. ↩

83. CMA analysis of IDC data from “IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2”. ↩

84. We note that users can access native apps, at least on Android devices, through other means than app stores. For example, they can be directly installed from app developers’ websites – a process called ‘sideloading’. We consider the alternatives and the constraint they place on Apple’s App Store and Google’s Play Store in the next chapter. ↩

85. Based on the shares of supply set out below, a relatively small proportion of existing mobile device users will be within Amazon’s ecosystem (ie own one of Amazon’s Fire OS tablets) and Huawei’s ecosystem (ie own a HMS device). ↩

86. This is also consistent with the survey evidence on the top reasons why users purchased a new device. For example, a 2021 survey submitted to us [by a party] showed that across all respondents who had purchased a smartphone, the top 3 reasons for purchasing a new device were that they ‘wanted newer device than one I had’(35%), ‘my contract had come to an end’ (31%) and ‘Previous phone had poor battery life’ (22%). ↩

87. For example, research from OFCOM shows that 91% of UK households own a smartphone and smartphones are the device most used among UK internet users to go on online. Visit Ofcom’s Online nation 2021 report. ↩

88. One manufacturer said that it considered this was the case for several reasons including: (i) different usage patterns to smartphones which mean tablets are used less frequently reducing the need to replace them; (ii) differences in usage patterns also mean the performance needs of tablets are lower meaning they should stay competent for longer; (iii) their bigger size means better usage of internal components to enable better efficiency and performance such that they stay competent for longer; and (iv) manufacturers tending to upgrade their tablets less frequently than smartphones. ↩

89. This is in part likely to be due to lower tablet ownership rates. For example, Ofcom’s Technology Tracker survey shows that in 2020 65% of respondents reported (aged 16 and over) owning a tablet. Visit Ofcom’s Interactive report. ↩

90. Consistent with this [REDACTED]. ↩

91. A survey of iPhone buyers in the UK found only [0% to 10%] were buying an additional phone with [30% to 40%] of those having an Android device. [REDACTED]. ↩

92. Google provided some internal data for the UK that suggested that in 2019 and 2020 at least [REDACTED] of Android smartphone users who were purchasing a new smartphone switched to an Apple smartphone. This was equivalent to a lower figure of [REDACTED] of active Android smartphones in those years. Google explained that its analysis was based on [REDACTED], that the number of Android smartphones users purchase a new smartphone is [REDACTED], its analysis excludes users that [REDACTED], the rate of switching to iOS is determined on the basis of [REDACTED] and this analysis is based on [REDACTED]. ↩

93. This based on a 12-month rolling trend as at December 2020. ↩

94. Apple said that it does not have readily available data measuring the average length of life of an Apple ID. Google explained that due to the length of data retention it is not possible to determine the length of time a user maintains an Android account linked to an Android device for more than [REDACTED]. ↩

95. In 2020, Apple users tended to have owned their smartphone for [2 to 3] years. ↩

96. [REDACTED] ↩

97. Apple stated that Samsung’s and Huawei’s top-end devices were more expensive than Apple’s XS and XS Max iPhones (USD 1,450), with pricing for their folding phones at around USD 1,980 and USD 2,600, respectively. For example, visit Business Standard News’ High-stakes battle: How Samsung, Huawei are taking on Apple in pricing game article. ↩

98. For the purposes of this analysis we have not split out Huawei’s HMS devices. ↩

99. We understand that IDC’s data is widely used within the industry we are examining. ↩

100. CMA analysis of IDC data from “IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2”. ↩

101. CMA analysis of IDC data from “IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2”. ↩

102. For example, visit Price runner’s Apple iPhone SE 64GB (2nd Generation) last accessed on 11 December 2021. ↩

103. The majority of these devices identified as those with a Windows operating system are those produced by Microsoft, see CMA analysis of IDC data from ‘IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2’. Microsoft explained that it offers Surface devices that run Windows, but does not offer any tablets running a mobile operating system. However, Microsoft also explained that certain devices such as its Surface laptop face competition from Apple’s high-end iPad Pro. ↩

104. CMA analysis of IDC data from “IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2”. ↩

105. CMA analysis of IDC data from “IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2”. ↩

106. CMA analysis of IDC data from “IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2”. ↩

107. Microsoft explained that if offers Surface devices that run Windows, but does not offer any tablets running a mobile operating system. However, Microsoft also explained that certain devices such as its Surface laptop face competition from Apple’s high-end iPad Pro. ↩

108. See CMA analysis of IDC data from “IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2”. ↩

109. Visit Google’s Statement of Scope Response, page 4 at Response: Google. ↩

110. We understand that battery life is a function of both the hardware (for example, the actual battery used) and the operating system. ↩

111. For example, in one survey the battery life of the phone was the most cited reason for choosing a particular brand and model with 55% of respondents, quality of camera was second with 54% of respondents and the size of screen was third with 51%. ↩

112. Google stated that it had released 18 major versions of Android with many more intermediate and minor version updates. ↩

113. [REDACTED]. ↩

114. [REDACTED]. ↩

115. For example, as iOS updates have generally been provided to iPhones for 5 to 6 years this provides Apple with a greater incentive to innovate in its hardware as that is where the greatest difference between its new and existing smartphones will be. Visit Statista’s How Long Does Apple Support Older iPhone Models ↩

116. For example, as Android manufacturers have to meet certain compatibility criteria set out by Google there are limits on the extent to which they can differentiate the operating system on their devices from other Android manufacturers (although they could differentiate based on the first-party apps or services they offer on the device). This might mean that Android manufacturers have a greater incentive to engage in hardware innovate to ensure they stand out from other manufacturers using the same operating system. ↩

117. For example, due to high ownership rates in countries such as the UK and increases seen in the length of time users are holding onto their devices. ↩

118. For example, visit Time’s Amazon Fire Phone: Why It Failed to Take Off, Fire Phone one year later: Why Amazon’s smartphone flamed out . ↩

119. As set out in Competition in the distribution of native apps, Apple told us that popular and successful app developers almost universally choose to make their apps available on both Android and Apple devices. ↩

120. As set out in Competition in the distribution of native apps, Google told us that app developers typically multi-home across different operating systems and devices with many of the same native apps, including popular apps and Google’s apps, being available on both Android and Apple devices. Google said that this means users have access to similar native app catalogues, regardless of the mobile operating system on which their device operates. ↩

121. As set out below we have used data from market participants. This may lead to an overestimate of the shares of supply as our dataset does not include evidence from all market participants. However, we consider that any overestimate is likely to be minimal as we have used data at the operating system level to understand the overall number of devices and we are not aware of any material operating systems other than those we have received evidence from. ↩

122. We note that Apple provided data on ‘Transacting accounts’. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one smartphone, and one smartphone could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active smartphones. ↩

123. Visit Statcounter’s FAQ Global Stats. ↩

124. Visit BlackBerry 10 and BlackBerry OS Services FAQ End of Life. Nokia announced it would stop using Symbian as its main mobile operating system in 2011 and the last mobile device using the Symbian operating system was released by Nokia in 2012. Visit TechRada’s From birth to death why Nokia’s Symbian was the future of mobile tech ; ZDNet’s Nokia and Microsoft seal Windows Phone alliance and ZDNet’s Android before Android The long strange history of Symbian and why it matters for Nokia’s future. Microsoft announced that there would be no further updates to its last mobile operating system (Windows 10 Mobile) in 2017 and that it would no longer support that operating system in 2019. Visit GSMArena’s Saying goodbye to Windows 10 Mobile Microsoft ends support for its mobile OS and The Verge’s Windows Phone was a glorious failure. ↩

125. Visit Trusted Review’s Amazon Fire Phone UK Release Handset launches today and BBC’s Amazon stops selling Fire smartphone article. ↩

126. Visit Mobile Operating System Market Share Worldwide Statcounter Global Stats. ↩

127. Apple provided data on ‘Transacting accounts’. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one tablet, and one tablet could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active tablets. ↩

128. Visit Statcounter’s FAQ Global Stats. ↩

129. Visit Tablet Operating System Market Share Worldwide Statcounter Global Stats. ↩

130. This is in common with the standard approach in CMA market studies, which do not seek to establish whether a firm has dominance in a defined market, but are focussed on assessing the range of competitive constraints applying to firms, and how these could be strengthened. In a market study, the CMA considers ‘the extent to which a matter in relation to the acquisition or supply of goods or services of one or more than one description in the United Kingdom has or may have effects adverse to the interests of consumers’ (Enterprise Act 2002, section 130A(2)). ↩

131. The former will be considered in Chapters 4, Competition in the supply of mobile browsers and The role of Apple and Google in competition between app developers where we explore competition in relation to app distribution, browsers and competition between first-party apps and third-party apps. The latter will be considered in Chapters 4 and Competition in the supply of mobile browsers where we explore competition in relation to app distribution and browsers as those are points at which content providers enter a mobile ecosystem. ↩

132. For example, Android has a share of just over 70% of worldwide smartphone operating systems based on Statcounter data. Visit Mobile Operating System Market Share Worldwide Statcounter Global Stats. ↩

133. Apple’s iOS, Amazon’s Fire OS and Huawei’s version of Android using Huawei Mobile Services are all only used in first-party devices. ↩

134. CMA analysis of IDC data from “IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2”. ↩

135. CMA analysis of IDC data from “IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2”. ↩

136. CMA analysis of IDC data from “IDC PCD Tracker (Tablet)_FinalHistoricalPivot_2021Q2”. ↩

137. CMA analysis of data from market participants. ↩

138. CMA analysis of data from market participants. ↩

139. For example, one online UK survey of January 2021 with 1,925 purchasers and 1,896 intenders (respondents shopping for a smartphone for personal use and planning to purchase in the next 6 months) showed that 48% of respondents who had purchased a smartphone considered the ‘Price of the phone’ as ‘very important’ while 55% of respondents who intended to purchase a smartphone considered it to be ‘very important’. These were the third and first highest responses respectively. ↩

140. Consistent with this, a survey submitted to us [by a party] showed that [20% to 30%] of those purchasing an Apple device identified the “Cost of phone” as the main criteria for choosing their smartphone, in contrast the figure was [20% to 30%] for those who purchased a Samsung smartphone and [30% to 40%] for all Android devices. ↩

141. For example, one online UK survey submitted by [a party] of January 2021 with 1,925 purchasers and 1,896 intenders (respondents shopping for a smartphone for personal use and planning to purchase in the next 6 months) found that among respondents who had purchased a device, but not switched from a different operating system, [40 to 50%] of Android respondents identified ‘Great value’ and ‘Budget’ as ‘very important’ factors when shopping for a new smartphone compared to [30 to 40%] of Apple respondents. In contrast [40 to 50%] of Apple respondents identified ‘Familiarity’ compared to just [20 to 30%] of Android respondents. ↩

142. For example, one survey of smartphone buyers submitted by [a party] found that 77% of respondents considered Apple to be ’a premium brand’ with the next brand being Samsung at 54% of respondents. In contrast 45% of respondents said Samsung ’Offers good value for money’ whereas only 25% of respondents said this of Apple. ↩

143. As set out in Competition in the distribution of native apps, Apple told us that popular and successful app developers almost universally choose to make their apps available on both Android and Apple devices. ↩

144. As set out in Competition in the distribution of native apps, Google told us that app developers typically multi-home across different operating systems and devices with many of the same native apps, including popular apps and Google’s apps, being available on both Android and Apple devices. Google said that this means users have access to similar native app catalogues, regardless of the mobile operating system on which their device operates. ↩

145. We note that we have not seen evidence of barriers to switching between mobile devices with the same operating system (ie between different manufacturers of Android devices). ↩

146. Learning costs were also identified as a barrier to switching in the following enforcement decisions and market studies: European Commission, Commission Decision of 18 July 2018 Google Android, recitals 523, 524, 527; the Netherlands Authority for Consumers & Markets, Market study into mobile app stores, page 55; Australian Competition & Consumer Commission, Digital platform services inquiry, Interim report No. 2 – App marketplaces, page 38. ↩

147. Apple also stated that, where data that Apple collects is linked to a user’s Apple ID, Apple has endeavoured to make it available to the user in a machine-readable and portable format from Apple’s website. ↩

148. Apple stated that only Apple Music, Apple TV+, DarkSky Weather and Shazam are available as apps across a range of non-iOS devices (however we note that DarkSky Weather is not available on Android). Apple stated that it makes Apple TV+ and Apple Music available across a range of non-iOS devices because users expect them to be available in this way. iOS apps and services not available on Android (alongside DarkSky Weather) include the App Store, Apple Arcade, Apple Books, Apple Pay, Apple News+, iTunes Store and iMessage. ↩

149. We heard that Apple’s practices affect iOS and Android users’ ability to communicate vis SMS / MMS in several ways: messages are delivered slowly and less reliably; users cannot include high-quality images and videos; certain features are hidden or not available (such as location and read receipts); group chat functionality is limited; and users often pay cellular network charges. ↩

150. Visit Dr Greig Paul’s and Dr James Irvine’s, Response to the Statement of Scope, 25 July 2021, pages 5 to 6. ↩

151. In 2021 their shares vary between 1% and 2% of active smartphones in the UK based on Statcounter data. Visit Mobile Vendor Market Share United Kingdom Statcounter Global Stats. ↩

152. As discussed further in Competition in the distribution of native apps. ↩

153. As discussed in Competition in the distribution of native apps, several technical experts have put to us that one of the main benefits of web apps is the ability to make a single app available through browsers on all operating systems (rather than producing a separate native app for each operating system). Therefore, the limited support for web apps on iOS devices is likely to impact on the use of web apps on Android devices. ↩

154. As discussed in Competition in the distribution of native apps, Google has a cross-platform tool called Flutter. Visit Flutter’s Beautiful native apps in record time. ↩

155. Visit Android Brand guidelines and Android Compatibility Program Overview Android Open Source Project. ↩

156. These conditions are set out in the Compatibility Definition Document (CDD) and set out in more detail in Appendix E. ↩

157. Google told us that third-party browsers (as opposed to manufacturer browsers) can have non-Google search services set as default instead, provided that they are not placed on the default home screen (unless in a folder) or the minus one screen. Google also told us that after the EC’s decision in Google Android the default search service in Chrome is set according to the Android choice screen mechanism that applies in the UK and EEA. ↩

158. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising, Final Report, pages 73 and 211. ↩

159. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising, Final Report, page 211. ↩

160. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising, Final Report, paragraph 3.149. ↩

161. These GMS apps include apps such as Gmail, Maps and YouTube. ↩

162. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising, Final Report, paragraph 3.149. ↩

163. For example, Google can access extensive data on user location, including through Android smartphones, on which half to 2 thirds of users have location services activated; this allows search advertising to be more effectively targeted based on location. See CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report, paragraph 5.60. ↩

164. For example, Huawei told us that ‘[a]s the number of users of an operating system increases, this increases the value of that system to other users, [manufacturers] and app developers.’ In addition, Huawei said that the number of app developers determines the scale of the operating system’s ecosystem, with more developers leading to a richer ecosystem improving the user experience and thus number of users and also increasing the attractiveness of the operating system to manufacturers. ↩

165. Visit BBC’s Amazon Fire Phone UK Release Handset launches today Trusted Reviews and Amazon stops selling Fire smartphone article. ↩

166. Visit Time’s Amazon Fire Phone: Why It Failed to Take Off Time, Fire Phone one year later: Why Amazon’s smartphone flamed out CNET, Why did the Amazon Fire Phone Fail? HubPages article. ↩

167. For example, visit Complaint filed by the Department of Justice against Google, paragraphs 73 to 75. ↩

168. CASE AT.40099, Google Android, dated 18 July 2018, paragraphs 1036 (3) and 1076 (currently on appeal). ↩

169. CASE AT.40099, Google Android, dated 18 July 2018, paragraph 1106 (currently on appeal). ↩

170. Visit Apple Search Ads. ↩

171. Visit Appendix D for more detail. ↩

172. Visit Google’s Statement of Scope Response, page 4 at Response Google. ↩

173. Visit Agreements and Guidelines Support Apple Developer, which includes a link to the ‘Apple Developer Program License Agreement’ and ‘Xcode and Apple SDKs Agreement’ (it sets out the terms and conditions that govern the use of Xcode developer tools and software development kits (SDKs)), and Enrollment Support Apple Developer for more information on enrolment in the Apple Developer Program and applicable fees. ↩

174. Visit the section on Google’s business model in Competition in the supply of mobile devices and operating systems. ↩

175. A copy of the Google Play Developer Distribution Agreement is available online at Google Play (effective as of 17 November 2020). Visit also How to use Play Console - Play Console Help regarding the requirements to set up a Google Play Developer Account. Google’s Developer Program Policies can be accessed online at Developer Program Policy - Play Console Help. ↩

176. Both Apple and Google apply a lower commission of 15% in certain circumstances, described further below. ↩

177. Visit in particular App Review App Store Apple Developer and Publish your app Play Console Help. ↩

178. Clause 3.3.2 of the Apple Developer Program License Agreement (last accessed on 10 November 2021). ↩

179. Visit the section below on the overview of other app stores available on Android. ↩

180. For Apple, see for example Apple Developer Program Apple Developer and Apple introduces new developer tools and technologies to create even better apps Apple (UK). For Google, see for example Overview of Google Play services Google Developers and How to use Play Console - Play Console Help as well as Developer Guides Android Developers. ↩

181. Visit Google Play Console Google Play Console and App Store Connect Apple Developer. ↩

182. Visit, for example Helping Developers Succeed Play Console Help (google.com) and Featured Apple Developer Documentation. ↩

183. Visit Google Policy Centre App discovery and ranking Play Console Help; Categories and Discoverability App Store Apple Developer. ↩

184. Visit The role of Apple and Google in competition between app developers on the app review process. ↩

185. Visit Family Sharing Apple (UK). ↩

186. Visit Google Play Points Google Play Console. ↩

187. It was also preinstalled on Amazon’s Fire Phone before the Fire Phone was discontinued. ↩

188. Visit Competition in the supply of mobile devices and operating systems where we set out what HMS devices are. ↩

189. If the AppGallery is not the only app store installed on the device, AppGallery will not be set as default and users can choose which store to use for downloading apps. ↩

190. Visit Amazon Developer Services Agreement. ↩

191. Visit Samsung Galaxy Store Seller Portal, ↩

192. Visit Huawei’s AppGallery Policy Center AppGallery Connect Agreement AppGallery Connect Service and Agreement. ↩

193. Visit Huawei’s AppGallery Policy Center App Review-AppGallery Review Guidelines. ↩

194. Visit the AppGallery Policy Center App Review-App Review FAQs ↩

195. App and Game Development Amazon Appstore Developer Portal. This is in addition to the public resources available on the Amazon Developer Portal at developer.amazon.com. ↩

196. For Apple this data is specific to the UK App Store, includes both first-party Apple apps and third-party apps and corresponds to transactions done through an iPhone or iPad. ↩

197. As set out in Competition in the supply of mobile devices and operating systems, Huawei currently uses a version of Android that falls within Google’s compatibility requirements, but relies on Huawei’s Huawei Mobile Services instead of Google Mobile Services due to US legislation in May 2019 which meant that Huawei could no longer access Google’s apps and services, including Google Mobile Services. ↩

198. We have not aggregated this data to calculate a monthly number as at least some users are likely to have downloaded native apps on multiple days during the period. ↩

199. That is, the revenue that Apple / Google retain from transactions made through their payments systems in the UK. ↩

200. That is, spending based the users who actually made a transaction through Apple IAP in the UK. ↩

201. We understand that Apple previously pre-installed Google Maps, but this has not occurred since the release of the iPhone 6 (in September 2014) and Apple now pre-installs its own first-party alternative to Google Maps. Visit the ACCC’s Digital platform services inquiry, Interim report No. 2 App marketplaces. ↩

202. Visit Google’s response to the Statement of Scope at Response. ↩

203. Visit ACM’s, Market study into mobile app stores, 11 April 2019, page 50 and ACCC’s, Digital platform services, page 29. ↩

204. This includes app stores not being allowed in the App Store. Visit Apple Developer Program License Agreement, Article 3.3.2. ↩

205. Visit Google’s Developer Distribution Agreement, Article 4.5 which states ‘You may not use Google Play to distribute or make available any Product that has a purpose that facilitates the distribution of software applications and games for use on Android devices outside of Google Play.’ ↩

206. For example, Samsung’s website for the Galaxy Store states ‘Find and install your favorite [sic] games in a flash. Score Galaxy exclusive benefits whenever you discover a game that interests you. And check out our game-changing exclusives you can only get at Galaxy Store. You can also enjoy top games with 10% off all in-app purchases.’ ↩

207. Visit Google’s Understanding Google Play’s Payments policy Play Console Help. ↩

208. As set out below, Google provided data showing that in May 2021 [3.5 to 4] million off-Play Store installs were sideloaded. This includes downloads from alternative app stores that were not preloaded which suggests that downloads through non-preloaded app stores are very low. The number of sideloaded apps was based on installations that occurred while the device had an internet connection and on active GMS devices (ie Android devices with Google’s apps and services preloaded) with Google Play Protect enabled which account for around [90% to 100%] of GMS devices in the UK. ↩

209. For example, this could be because the service being offered by the app developer relies upon network effects with the value of the service to users increasing when the number of other users using the service increases. ↩

210. Google explained that it has an app review process which screens for security risk and compliance with Google’s policies. Google explained that while this can be done for individual apps it cannot be done for alternative app stores as it would have to screen every app that the alternative app store distributes if it listed app stores in the Play Store. In addition, Google explained that in relation to some app stores it is aware of material concerns such as hosting pirated apps. Google explained that it does allow apps that offer access to multiple cloud-based services as they do not install additional app packages onto the device. ↩

211. Visit Google’s Statement of Scope response. ↩

212. These are (1) a complaint filed by a coalition of 39 attorneys general in the United States District Court, Northern District of California (“the Utah Complaint”), see State of Utah et al v. Google LLC et al, Case Number 3:2021cv05227. First amended complaint filed 1 November 2021 available at State of Utah et al v. Google LLC et al, 3:21-cv-05227; and (2) a complaint filed by Epic Games against Google in the same court (“the Epic Complaint”), see Epic Games, Inc. v. Google LLC et al, Case Number 3:2020cv05671. Updated complaint filed 19 August 2021, available at Epic v. Google unredacted complaint - DocumentCloud. ↩

213. We further understand that another of these initiatives by Google is Project Banyan (later renamed Project Agave), which targeted Samsung and its Galaxy Store specifically, although it was never implemented by Google and Samsung. Visit the Utah Complaint, paragraphs 139 to 146 and the Epic Complaint, paragraphs 119 to 121. ↩

214. The Utah complaint refers to Project Hug as Google ‘buying off’ key app developers to deter them from making their apps available outside the Google Play Store and ‘sharing it monopoly profits’ with them by providing ‘in-kind services’ in exchange for ‘distribution restrictions’ visit Utah complaint, paragraph 147. ↩

215. According to the Utah complaint, in 2018, Samsung partnered directly with top game developer Epic to launch the mobile version of Epic’s game Fortnite exclusively on the Samsung Galaxy Store. According to the same complaint, Samsung also pursued exclusive deals with other popular app developers such as Riot Games, Activision, and Blizzard and indicated its intent to place the Galaxy Store on the home screen of its next generation devices. See Utah complaint, paragraphs 137 to 138. ↩

216. Epic Games’ Fortnite operated outside of the Play Store for 18 months, app was not available on the Play Store until April 2020 when it became available via the Play Store again. Visit The Guardian’s Fortnite owner gives up battle against Google Play store article. ↩

217. As detailed in Appendix G, based on documentary evidence submitted by Google, Google identified that Project Hug might create such a cycle and hence reduce the risk of spending being diverted away from the Play Store and to alternative stores. ↩

218. As detailed in Competition in the supply of mobile devices and operating systems, Google’s RSAs are only available to EMADA partners. ↩

219. Consistent with this interpretation, one app developer told us that it was impeded in coming to an agreement with manufacturers to have its installer pre-loaded on devices due to agreements between manufacturers and Google. ↩

220. Jailbreaking permits root access to iOS such that the restrictions put in place by Apple can be bypassed. For example, visit Norton’s Is jailbreaking safe? article. ↩

221. For example, visit Vice’s The Life, Death, and Legacy of iPhone Jailbreaking. ↩

222. Visit TestFlight - Apple Developer. ↩

223. Visit Apple Developer Enterprise Program Apple Developer. ↩

224. For example, visit Techcrunch’s Apple bans Facebook’s Research app that paid users for data article. ↩

225. This was based on installations that occurred while the device had an internet connection and on active Google Mobile Services (GMS) devices (ie Android devices with Google’s apps and services preloaded) with Google Play Protect enabled, which account for [90% to 100%] of GMS devices in the UK. ↩

226. One app developer provided evidence from October 2019 when roughly one third of its installations and updates on Android devices were outside the Play Store. ↩

227. Although we understand that any app can launch the relevant Settings screen proactively to prompt users to allow installs from ‘unknown sources’, thereby avoiding the need to show users a dialog box beginning “For your own security, your phone is not allowed to install unknown apps from this source. You can change this in Settings”. Visit Making it safer to get apps on Android O. ↩

228. Google confirmed that once a user had been through the process with a particular source it did not need to go through the process again with that source. ↩

229. Epic Games also explained that depending on the version of Android operating on the device, the user may have to go through many or all of the same steps. ↩

230. Visit Google’s Statement of Scope response. ↩

231. For example, Apple referred to Europol advice that users should only install apps from official app stores. ↩

232. Visit Apple’s response to the Statement of Scope. ↩

233. Visit Apple’s response to the Statement of Scope. ↩

234. Visit Epic Litigation Trial Transcript 3389. ↩

235. Apple submitted that its focus on ensuring the iPhone was as secure as possible was reflected in its announcement of SDKs in October 2007 where Apple said ’[i]t will take until February to release an SDK because we’re trying to do 2 diametrically opposed things at once — provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc.’ Visit Apple Hot News. ↩

236. Apple also submitted that its decision to prevent sideloading was also driven by its desire to make the iPhone ’reliable and easy to use’. While it is not entirely clear exactly what this means, a central part of Apple’s strategy is to have a distinctive ‘look and feel’ and through its app review process it can ensure the user experience on an Apple device is ‘second-to-none’. Apple asserted that this would be undermined by allowing sideloading and that this is reflected in survey evidence showing the importance to users of devices being easy to use. ↩

237. Visit Google’s Statement of Scope Response page 4. ↩

238. Visit Google’s Statement of Scope Response page 6. ↩

239. As discussed below, some cross-platform development tools are available, however, the uptake of these tools seems limited at present with all the app developers we requested information from developing native apps separately for iOS and Android. ↩

240. Apple also said that some of the most advanced streaming game services had opted to offer their games via web apps rather than release their services through the App Store as native apps. We consider the example of cloud gaming including these web apps in The role of Apple and Google in competition between app developers. ↩

241. For example, visit Simplab’s The state of PWA support on mobile and desktop in 2020 blog. ↩

242. For example, Google said that web apps can include a more interactive experience than standard websites, web apps are more likely to integrate with other software, web apps typically require user authentication and in contrast to a standard website, if a web app is altered then a redeployment of the latest version is required. See ↩

243. Google pointed to public sources stating that when Twitter started using a web app, it saw a 65% increase in pages per session, a 75% increase in Tweets sent, and a 20% decrease in bounce rate, while the size of their app decreased by over 97%. Visit Twitter Lite PWA Significantly Increases Engagement and Reduces Data Usage. ↩

244. Although for progressive web apps pinned to the home screen (which is only possible on Safari but not on other browsers on iOS) users can turn off the browser’s UI. ↩

245. For example, in response to questions from the CMA, we were told that ‘Apple’s requirement that browsers use WebKit browser engine also impedes the development of the web platform as a whole, slowing adoption of web apps, and – for developers who want to offer a consistent cross-platform experience – reducing the functionality of web apps to the lowest common denominator.’ ↩

246. Visit Google’s Statement of Scope response. ↩

247. Based on 2020. The evidence we have received suggests the single homing apps are smaller or less well-known apps with low levels of downloads. ↩

248. For example, Amazon, Facebook, WhatsApp, Instagram, Netflix, Spotify among others. ↩

249. For example, visit ACCC’s Digital platform services, page 36. ↩

250. Hyrynsalmi, S, Suominen, A. and Mantymaki, M. (2016), The influence of developer multi-homing on competition between software ecosystems, Journal of Systems and Software, January 2016, page 111, 119 to 127. ↩

251. We used Bank of England data to convert from US Dollars into Great British Pounds, this was done using the yearly data from XUAAUSS Bank of England Database. ↩

252. Spending on apps including Play Pass. We used Bank of England data to convert from US Dollars into Great British Pounds, this was done using the yearly data from XUAAUSS Bank of England Database. ↩

253. This is also supported by evidence from the US where survey evidence shows that Apple users tend to earn and spend more than Android users. Visit PR Newswire’s iPhone Users Spend $101 Every Month on Tech Purchases, Nearly Double of Android Users, According to a Survey Conducted by Slickdeals. ↩

254. Some app developers may use cross-platform tools which allow them to develop one app that can be used across different mobile ecosystems. The use of such tools may mitigate some of these costs, however, the use of such tools implies that they are on both Android and iOS devices so are not considered further here. ↩

255. For example, app developers explained that the user interface, APIs, development and deployment tools, app store rules and requirements, features and functionalities of each operating system may differ. ↩

256. Although the extent of that cost is likely to differ by app developer depending on the nature of their apps. For example, one app developer told us that each of its native apps had common underlying technologies that they interoperate with which means that a proportion of the code for each app was common. The app developer said that 40% to 60% of the code was common for its apps depending on the app in question. The higher the proportion of code that would be common across native apps the lower the cost of redeveloping the app. ↩

257. Visit Flutter’s Beautiful native apps in record time. ↩

258. Visit ZDNet’s Google I/O 2021: Flutter 2.2 adds monetization hooks as it gains traction. ↩

259. Two respondents to our online app developer questionnaire mentioned such cross-platform tools with one explaining they were not suitable for the apps it developed and the other explaining that they work well in categories such as games, but that in other categories native apps are usually used. ↩

260. Google acknowledged that some app developers prefer to develop apps specifically for different platforms, so that they can (in their view) take the fullest advantage of the features provided by each platform. Google also said that the Flutter team tries to identify and remove impediments that might inhibit a developer from taking full advantage of each operating system. ↩

261. In particular, a user’s decision to purchase any device is likely to be driven more by the immediate costs ie price of the device rather than any future costs such as app prices or in-app purchases. This is due to present biased preferences, that is, the tendency to assign greater relative weight to costs and benefits that are closer to the present, when considering tradeoffs between 2 future moments (O’Donoghue and Rabin, 1999). More broadly, Ericson and Laibson (2018), introduce the idea of present-focused preferences (present bias being a special case of present focused preferences) which results in users making more impatient choices in the present by focusing on immediate payoffs. Bar-Gill, 2012 identifies deferred costs as challenging because myopia leads consumers to care more about present costs over future costs and discount any future costs by the probability of them not being incurred. This can reduce the perceived total price of the device. See Seduction by Contract: Law, Economics, and Psychology in Consumer Markets, Oren Bar-Gill (2012), Doing It Now or Later, American Economic Review Vol. 89, NO. 1, March 1999, Ted O’Donoghue and Matthew Rabin (1999) and Intertemporal Choice, Keith Marzilli Ericson and David Laibson (2018), NBER Working Paper Series, Working Paper 25358. ↩

262. Including device brand, camera quality, screen size, etc. ↩

263. Google cited evidence from Statista that 96.7% of apps available on the Play Store and 92.9% of apps on the App Store in March 2021. Visit Statista’s Distribution of free and paid apps in the Apple App Store and Google Play, March 2021. ↩

264. CMA analysis of IDC data “IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2”. For details on this analysis see Appendix C. ↩

265. We used Bank of England data to convert from US Dollars into Great British Pounds, this was done using the yearly data from XUAAUSS Bank of England Database. ↩

266. While users would be switching to an Android device and the average price of an Android device is lower than the average price an Apple device, we consider it unlikely that a user would switching from a high-end expensive Apple device to a low-end cheaper Android device. However, expenditure on apps, in-app purchases and subscriptions is increasing over time. ↩

267. CMA analysis of IDC data ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’. ↩

268. CMA analysis of IDC data ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’. ↩

269. Based on 2020 UK data and for apps including Play Pass. We used Bank of England data to convert from US Dollars into Great British Pounds, this was done using the yearly data from XUAAUSS Bank of England Database. ↩

270. For example, visit PC Mag’s Microsoft Says Xbox Consoles Have Always Been Sold at a Loss, Make Use Of’s All Games Consoles Are Sold at a Loss. Here’s Why…, Polygon’s Sony is selling the PS5 at a loss, investors told and slide 16 on page 9 of Sony’s Q3 FY2020 Consolidated Financial Results. ↩

271. From 2017 to 2018 the average price of iOS devices increased by 16% and for Android devices the increase was 18%, between 2018 and 2019 it was 4% for iOS devices and 1% for Android devices and between 2019 and 2020 it was 4% for iOS devices and -11% for Android devices. CMA analysis of IDC data from ‘IDC Mobile Phone Tracker_FinalHistoricalPivot_2021Q2’. ↩

272. Apple also said that it has a single “P&L” and does not monitor performance at the level of distinct ‘business units’. It does not therefore document how, for example, pricing decisions at the device level are affected by service revenues.’ ↩

273. We note that these findings are consistent with the findings of the Australian Competition and Consumer Commission (ACCC), who found that fixed devices (such as personal computers, gaming consoles and smart TVs amongst others) provide a weak constraint on mobile apps, and this is weakening due to consumer time being increasingly spent on mobile devices, and many activities that use mobile apps inherently relying on mobility. Visit ACCC’s Digital platform services inquiry Interim report page 32. ↩

274. For example, from 2019 to 2020, users increased their hours spent playing mobile games by 25% to 296 billion hours. Visit SLA Digital’s https://sla-digital.com/blog/the-growth-of-mobile-gaming/. Visit also: Over 70% Of People Choose Smartphones For Gaming, More Than PCs And Consoles Combined. ↩

275. It found that the game selection varies considerably across mobile platforms and console, with less than 15 to 20% of native mobile games available on consoles, and less than 6 to 8% of console games available as native games. It also found that gamers playing on mobile devices appreciate the possibility to play “on-to-go” (for example, while travelling to work, on a train, etc.). According to a survey carried out by Altman Vilandrie & Company in January 2019 in 4 major countries, 60% of gamers playing on mobile devices do so “on-the-go” while commuting or travelling. ↩

276. Visit the following section which sets out evidence on time spent on smartphones compared to computers. ↩

277. We used Bank of England data to convert from US Dollars into Great British Pounds, this was done using the yearly data from XUAAUSS Bank of England Database. ↩

278. According to desk research of Argos, Curry’s PC World and Amazon pricing. Accurate as of October 2021. ↩

279. Users can purchase game subscription services which allow them to access a library of games for about £95 to 132 per year (for example Xbox Game pass at £7.99 per month with Xbox Game Pass Ultimate at £10.99 per month, Visit Xbox Game Pass: Discover Your Next Favourite Game. ↩

280. Developing a simple game app for one platform costs between $3,000 and $150,000. Console game budget generally exceeds $1 million. See this blog on game development costs. ↩

281. We note that even if there is some substitutability between PCs and mobile devices for specific use cases, this does not imply that there is any substitutability for other use cases. We also note that there are other app developers who do not make their apps available on PCs. ↩

282. Visit Ofcom’s, Online Nation 2021 report. Data based on Comscore MMX Multi-Platform, Total Internet, Age: 18+, Sep 2019 and 2020, UK. Note: TV set and smart device online use not included. ↩

283. We note that even if there is some substitutability between smart TVs and mobile devices for specific use cases such as video and music streaming, this does not imply that there is any substitutability for other use cases such as productivity, gaming, dating, food delivery and social media usage amongst others. We also note that there are app developers who do not make their apps available on smart TVs. ↩

284. We also note that smart TVs may have a high up-front cost, as with gaming consoles. For example, the cheapest 32” smart TV on Argos is £189.99 as of October 2021. ↩

285. As noted above, the CMA is investigating concerns regarding Apple’s terms and conditions for in-app purchases under its Competition Act powers. This investigation is ongoing and no decision has been made as to whether Apple has acted unlawfully. Competition Act investigations are based on different legal tests and standards of proof than the CMA’s market studies. As such, any findings in this market study are without prejudice to, and should not be taken as indicative of, the CMA‘s likely future assessment under the Competition Act. ↩

286. Visit Auto-renewable Subscriptions App Store Apple Developer. ↩

287. Visit App Store Small Business Program Apple Developer. ↩

288. This was announced on 21 October 2021, visit Android Developers Blog: Evolving our business model to address developer needs. ↩

289. Visit Google’s Changes to Google Play’s service fee in 2021 Play Console Help and Android Developers Blog: Boosting developer success on Google Play. ↩

290. Visit Samsung Galaxy Store Seller Portal section 6.1. ↩

291. Visit Amazon Developer Services Agreement. ↩

292. Visit Publish Apps, Games and Software on the Epic Games Store. ↩

293. CMA analysis based on Apple data. ↩

294. Web browsers provide the same function on desktop and other devices. ↩

295. Visit Kargo and Verto Analytics Web vs App report 2019. The report says that approximately 17% of users’ time is spent on mobile web (Safari and Chrome), with the next closest apps being Facebook with 14% and YouTube with 8%. ↩

296. In-app browsers typically have a reduced feature set compared to a dedicated browser app, with features (such as push notifications) typically arriving later on in-app browsers than on dedicated browsers. Steiner, Thomas. “What is in a web view: An analysis of progressive web app features when the means of web access is not a web browser.” Companion Proceedings of the The Web Conference 2018. ↩

297. Visit CMA Market Study into Online Platforms and Digital Advertising, Appendix H. ↩

298. Visit Android Choice Screen, retrieved 21 October 2021. Previously Google used auctions to determine which search options would be presented to users. ↩

299. Visit CMA Market Study into Online Platforms and Digital Advertising, Appendix H, paragraph 12. ↩

300. Visit CMA Market Study into Online Platforms and Digital Advertising, Appendix H, paragraphs 17 to 30. ↩

301. Visit Tor Project History. ↩

302. What does it mean to be a social business? – Ecosia’s FAQ. ↩

303. Blink is the browser engine, also called rendering engine. Blink is part of Chromium, an open source project which also includes much of the other technology behind the Chrome browser. ↩

304. For example, Cliqz, a browser developed by Cliqz GmbH, used Gecko. However, Cliqz has been discontinued in 2020. ↩

305. Open Source Initiative provides full list of criteria for ‘open source’, visit https://opensource.org/osd. ↩

306. Apple submitted that Safari was one of the differentiating features of the original iPhone, and that Safari was the first mobile browser that was as capable and powerful as a desktop browser. According to Apple, where browsers for other mobile operating systems at the time reflowed, reformatted, or simply broke the look and feel of web pages, mobile Safari presented the web fully and offered simple zoom and scrolling features that was unmatched at the time. A Google document discussing Google’s rationale for launching Blink in 2013 stated that for their platform to be attractive to users, Apple would need to improve browser performance, likely through increased investment in WebKit. ↩

307. Visit Chromium Blog Blink: A rendering engine for the Chromium project. ↩

308. Visit Statcounter, Mobile browser share of supply UK 2012 to 2021. ↩

309. Visit Table 5.2 and Statcounter, Mobile browser share of supply UK 2012 to 2021. ↩

310. We have assessed shares of supply using 2 different metrics: (i) page views, ie the total number of pages loaded or reloaded in a browser; and (ii) usage, measured in minutes. A page view is a request to load or reload a single web page of an internet site. This request usually results from a user who clicks on a link that points to the web page Statcounter Frequently asked questions. ↩

311. Visit Statcounter, Mobile browser share of supply UK 2012 to 2021. Share of supply calculated based on usage minutes data submitted by Google confirm that Chrome and Safari have been holding a joint share of supply of over 80% on mobile devices in the UK in the last few years, and that Samsung Internet is the largest competitor in the mobile browser market. App Annie browser usage data. ↩

312. WebKit’s share is calculated based on the share of iOS in 2020. Blink’s share is calculated based on the share of Android in 2020 but excluding Gecko and the other/unknown category on Android. Visit Statcounter, Mobile operating system share of supply UK 2020, Table 5.2. ↩

313. Visit for example ACCC Consumer Survey Roy Morgan Report section 3.3.2.1, in the Australian context. ↩

314. Visit Appendix E for further details on the agreements Google enters into with device manufacturers. ↩

315. On Android, device manufacturers such as Samsung and Xiaomi routinely license and pre-install Chrome. However, some Android device manufacturers choose to (also) pre-install their own browser and place it in the ‘hotseat’, which is one reason why the use of Chrome on Android is lower than Safari on iOS. For completeness, we note that Chrome is not pre-installed on new Huawei mobile devices since May 2019 due to the US trade ban. ↩

316. Visit the European Commission’s Google Android decision (currently on appeal). ↩

317. Visit Appendix E for further details on the Google Search and Chrome Apps Licence Agreements. ↩

318. Visit Android Choice Screen. ↩

319. Google told us that third-party browsers (as opposed to manufacturer browsers) can have non-Google search services set as default instead, provided that they are not placed on the default home screen (unless in a folder) or the minus one screen. Google also told is that after the European Commission’s Google Android decision, the default search service in Chrome is set according to the Android choice screen mechanism that applies in the UK and EEA. ↩

320. According to Google, the remaining third-party Android manufacturers account for under 6% of mobile devices sold in the UK. ↩

321. Visit Appendix G on ‘the impact of pre-installation and default settings on user behaviour’. ↩

322. In 2019 consumer research commissioned by Microsoft (based on US and Indian users of desktop or mobile devices), security was the most frequent characteristic of their primary browser which users considered to be most important. ↩

323. 15 out of the 16 browser vendors which responded to the CMA’s questionnaire mentioned speed or performance as a dimension of competition. In 2019 consumer research commissioned by Microsoft (based on US and Indian users of desktop or mobile devices), speed was the second most frequent characteristic of their primary browser which users considered to be most important. ↩

324. In 2019 consumer research (based on US and Indian users of desktop or mobile devices), commissioned by Microsoft, website compatibility was the third most frequent characteristic of their primary browser which users considered to be most important. A Microsoft strategy document associated the rapid decline of Internet Explorer with a lack of website compatibility with its Trident browser engine. ↩

325. All 16 browser vendors which responded to the CMA’s questionnaire mentioned privacy as a dimension of competition. ↩

326. 13 out of the 16 browser vendors which responded to the CMA’s questionnaire mentioned feature richness, or similar, as a dimension of competition. ↩

327. Visit Table 5.2. Since Safari is pre-installed as the default browser on all iOS devices, all non-Safari use represents switching by users. ↩

328. Several browser vendors submitted that users value the ability to use the same browser across their devices. ↩

329. Microsoft consumer research (based on US and Indian users of desktop or mobile devices) found that Edge was a leader on features in 2019. ↩

330. For example, ACCC study found that DuckDuckGo users were more likely than other browser users to use it for ‘privacy features’ or prefer it for its ‘data collection practices’. ↩

331. Visit Tom’s Guide Best Android browsers in 2021 Tom’s Guide and Best web browsers 2021 articles. ↩

332. Exceptions include Firefox (Gecko browser engine), and Flow (Flow browser engine). ↩

333. Safari is not available on Android. ↩

334. This differs from forking, as in customising their own version, browser vendors refrain from changing the browser engine so much that their version becomes incompatible with new features and bug-fixes implemented in the original browser engine. ↩

335. For example, Moonchild Productions told us that ‘Blink (Chrome) moves too fast to do anything but minimal trivial changes to if you want to base on that.’ ↩

336. We discuss web compatibility and the role of open standards in more detail in Appendix F. ↩

337. By ensuring compatibility with the largest browsers, they, to a large extent, also ensure compatibility with all other browsers using the same browser engines. ↩

338. This may be due to the very strong position Apple has in other parts of its mobile ecosystem. Apple’s position in mobile devices and operating systems allows Apple to require that WebKit is the only browser engine on iOS, and online content providers cannot generally afford to produce content which is inaccessible to (or functions poorly for) such a large proportion of mobile users. ↩

339. European Commission’s Google Android decision paragraphs 370 to 371. With respect to the demand side, it noted that desktop browsers and mobile browsers rely on different technology and provided examples of different browsing experiences between the 2 (for example, greater processing power on desktops). With respect to the supply side, it found that switching between developing desktop and mobile browsers takes significant time and substantial investments. ↩

340. Exceptions include Samsung (mobile only), BlackBerry (mobile only), HTC (mobile only) and Moonchild Productions (desktop only). ↩

341. European Commission’s Google Android decision paragraphs 378 to 379. With respect to the demand side, the European Commission found that users do not want to download a native app for each web page they visit. With respect to the supply side, it commented on the high development cost of a mobile browser (which is more relevant for the constraint from browsers on native apps than the constraint from native apps on browsers which we are focusing on). ↩

342. For example, native apps can utilise the capabilities built into mobile devices (for example, the camera or push notifications), and many retailers provide native apps with additional in-store capabilities such as product scanning, mobile payments and embedded loyalty cards. ↩

343. However, there is potential for greater substitutability between native apps and progressive web apps (which have a similar feel and functionality to native apps), if some of the constraints on the latter’s performance (particularly those discussed below in relation to Apple requiring the use of WebKit on iOS) can be overcome. ↩

344. We discuss the submissions Apple made with respect to its rationale for the WebKit restriction in detail in Appendix F. ↩

345. For example, Apple noted that WebKit benefits from Pointer Authentication Codes engineered into Apple Silicon chips that defeat a major hacking technique and a hardened sandbox profile designed specifically to protect against web-based attacks. ↩

346. A group of technical experts further told us that a Webkit update on iOS requires a user to update their operating system whereas Blink and Gecko updates do not. ↩

347. This point was raised by a group of technical experts and Epic Games. ↩

348. The AV1 video format is a modern video format which is supported by many browser engines, but not WebKit visit Can I Use’s AV1 webpage. ↩

349. While we understand that browser vendors would be able to base their browser on WebKit also on other operating systems, given the concerns raised about the performance of WebKit (as discussed below), this is unlikely to be an attractive alternative. ↩

350. Visit Browser Specific Failures graph. ↩

351. The Web Platform Test Project is also discussed in blog posts by Alex Russell Progress Delayed Is Progress Denied Infrequently Noted and Tim Perry Safari isn’t protecting the web it’s killing it. Mozilla submitted that the Web Platform Test Project is useful to gauge interoperability issues, but that it looks at just one facet of how browser engines operate and implement certain web standards. ↩

352. These include an assessment based on data from the Web API Confluence Dashboard, MDN Web Developer Needs Assessment 2020, a website called ‘caniuse’ and Test262. These are discussed in further detail in Appendix F. ↩

353. The assessment is provided by wpt.fyi and focuses on the 2021 Compat Focus Areas, which are 5 key areas that represent the most painful compatibility bugs. Further detail on this assessment is include in Appendix F. ↩

354. One group of technical experts further recommended a site called https://whatwebcando.today, which, for the browser with which the websites is opened, indicates which features are available on that browser. ↩

355. For example, Apple told us that [REDACTED]. ↩

356. Key features of PWAs for example include users being able to add the icon of a web app to the home screen, the PWA being able to send push notifications and faster loading. ↩

357. This included submissions from several browser vendors, app developers and technical experts. ↩

358. As explained in further detail below, there have also been submissions that while Apple enables users to add the icon of a web app to the home screen on Safari, Apple does not enable this functionality for other browsers on iOS. ↩

359. List is based on submissions from several browser vendors, app developers and a group of technical experts. ↩

360. This feature is particularly relevant for mobile gaming and presentation sharing. ↩

361. Although for PWAs pinned to the home screen (which is only possible on Safari but not on other browsers on iOS) users can turn off the browser’s UI. ↩

362. This feature is particularly relevant for mobile gaming. ↩

363. We understand that while there are few web apps that required this API, those that do often have it as a core experience. For example, we understand that this is required to connect to certain printers. ↩

364. Visit Progressive Web App Feature Detector. ↩

365. [One browser vendor] told us that this reduces the functionality of web apps to the lowest common denominator. ↩

366. This point was also raised by a group of technical experts. They further mentioned that developers would face higher costs due to the commission that Apple charges for revenues made through native apps on Apple’s App Store. ↩

367. While the strength of this argument in relation to in-app browsing is unclear to us at this stage, it appears to be less relevant for dedicated browser apps. ↩

368. We discuss this in further detail in Appendix F. ↩

369. This argument was also made by Microsoft. ↩

370. For example, Cliqz told us that Gecko had some issues with web compatibility. ↩

371. While we understand that Trident and EdgeHTML are not officially discontinued, Microsoft has stopped active development and only continues to support them for backwards compatibility purposes. ↩

372. Choice architecture describes the contexts in which users make decisions and how choices are presented to them. In online or digital settings, choice architecture refers to the environment in which users make choices, including the presentation and placement of choices, and the design of user interfaces. Examples of choice architecture are the ordering of options available to users, the user interface design for changing default settings, presentation of search results etc. See Thaler, R. H., Sunstein, C. R., & Balz, J. P. (2013). Choice Architecture. In E. Shafir (Ed.), The Behavioral Foundations of Public Policy (pp. 428 to 439). Princeton University Press for details on choice architecture. ↩

373. This is explained in further detail in Appendix E. ↩

374. In particular, [the browser vendor] mentioned [REDACTED]. ↩

375. Google told us that [REDACTED]. ↩

376. In addition to evidence specific to browsers, there is considerable evidence in the behavioural economics literature supporting the strong impact of defaults on consumer behaviour across a wide range of settings. Visit When and why defaults influence decisions: A meta-analysis of default effects Jachimowicz, J., Duncan, S., Weber, E., & Johnson, E. (2019). Behavioural Public Policy, 3(2),159 to 186 for a meta-analysis of studies evaluating default effects, which shows the strong impact of default choices on decision-making. ↩

377. We understand that Chrome is the default browser on most of the non-Samsung Android mobile devices. ↩

378. Samsung Internet’s relatively lower share of supply (compared to its share of being pre-installed and the default) is likely to be a function of Chrome being installed alongside Samsung Internet. ↩

379. For a more detailed discussion, see Appendix G. ↩

380. For a more detailed discussion, see Appendix G. ↩

381. Visit the ACCC’s Roy Morgan Research (2021), Consumer Views and Use of Web Browsers and Search Engines. ↩

382. In particular, these user surveys are an online user survey conducted in November 2020 of iPhone users (including in the UK) and a brand tracking online survey conducted in November 2020 in the US. ↩

383. Status quo bias refers to an individual’s tendency to do nothing or to maintain their current or previous decision. Visit Status quo bias in decision making. Samuelson, W., & Zeckhauser, R. (1988) Journal of Risk and Uncertainty, 1, 7 to 59. ↩

384. As noted in Appendix G, this was mentioned by several browser vendors, is supported by user research and is in line with the findings set out in the final report of the CMA’s market study into online platforms and digital advertising. ↩

385. There is substantial empirical evidence supporting the strong impact of choice architecture elements such as pre-set defaults and ordering of options on consumer decision-making. See Szaszi, B., Palinkas, A., Palfi, B., Szollosi, A., and Aczel, B. (2018) A Systematic Scoping Review of the Choice Architecture Movement Toward Understanding When and Why Nudges Work. Journal of Behavioral Decision Making, 31: 355 to 366 for a review of empirical evidence on choice architecture interventions. Also, see Appendix I which discusses choice architecture of data privacy choices and the implications for user behaviour. ↩

386. For further details on EMADA, see Appendix E. ↩

387. When introduced in April 2019, the Play choice screen displayed choice screens for both browsers and search apps. However, as agreed with the European Commission, Google introduced a separate choice screen for search services in March 2020, to be displayed during the set-up process of newly activated EMADA devices that preload Google Search app. Hence, users of newly activated EMADA devices since March 2020 only see the Play choice screen for browsers. ↩

388. Details on this data can be found in Appendix G. ↩

389. A more detailed description of the behavioural considerations related to the Play choice screen for browsers is offered in Appendix G. ↩

390. Users have the option to make a selection on a one-off basis or to choose which browser they will ‘always’ use to open links in the future unless and until they download a new browser. ↩

391. For completeness, and as discussed in Appendix G, we note that there are certain concerns about the effectiveness of the browser disambiguation boxes displayed on Android 11 or earlier versions, particularly related to the choice architecture. ↩

392. A more detailed discussion of the limitations of browser prompts and concerns over their choice architecture is provided in Appendix G. ↩

393. For example, in one of his blogs, Alex Russell notes that ‘on Android, the #2 and #3 sources of web traffic do not respect browser choice’, visit Infrequently Noted Hobsons Browser. Mozilla told us that while it does not hold data on in-app browser traffic, the traffic going through the Google Search app is likely to be quite significant, and it further submitted that an increasing amount of browsing occurs within in-app browsers. [Another browser vendor] submitted that a lot of web page traffic is moved out of the web browser into native apps (ie in-app browsers). ↩

394. One of the main reasons why app developers choose to rely on in-app browsers relates to being able to collect user information. For example, Mozilla told us that a benefit of in-app browsers for app developers is that the app will know which sites the user visited. ↩

395. Three stakeholders have specifically raised concerns about this. ↩

396. Google submitted that web views are a general concept that is distinct to the Android class ‘WebView’, which is a system component powered by Chrome that allows Android apps to display web content. ↩

397. Specific features mentioned by Mozilla include ‘Process Separation’ (which is a critical operating system feature that is needed for browser vendors for stability, quality and security reasons), restrictive implementation of Safebrowsing (which relates to the browser checking the website URL against lists of known websites and displays a warning if the URL the user is visiting is suspected of fraudulent conduct like phishing) and Apple removing existing functionality for features around data saving, cookie settings and multi-profiles. ↩

398. Specific features mentioned by Microsoft include Safari being the only browser that has direct access to certificates deployed through mobile device management systems (which are commonly used by enterprises for certificate-based authentication) and Apple’s new Private Relay feature (which is a privacy enhancing tool introduced by Apple) being expected to only be available to Safari. ↩

399. The specific APIs that were mentioned are ‘WebRTC’ (which are real-time network protocols for enabling videoconferencing, desktop sharing and game streaming applications) and ‘getUserMedia()‘ (which provides access to webcams). ↩

400. We already engaged with Apple on 2 of these API, namely Service Workers and ‘getUserMedia‘. Apple submitted that both are available to third-party browsers on iOS through WebKit, although we understand that support on other browsers on iOS may be more limited. We have not yet engaged with Apple on the other APIs listed above. ↩

401. However, these browser vendors commented on issues relating to defaults and in-app browsers. We cover issues relating to defaults and in-app browsers in detail in previous sections. ↩

402. Google’s Privacy Sandbox proposals are described in more detail in Appendix 2 of the relevant Notice of intention to accept binding commitments offered by Google. ↩

403. Visit the Notice of intention to accept binding commitments offered by Google, 11 June 2021, paragraphs 5.30 to 5.67. ↩

404. For details of the CMA’s provisional market definition visit the Notice of intention to accept binding commitments offered by Google, 11 June 2021, paragraphs 4.3 to 4.15. For the avoidance of doubt, while the CMA has not undertaken a full market definition exercise for the purposes of the Privacy Sandbox Proposals, any references to economic markets in this document are consistent with the market definition in the final report of the CMA’s market study into online platforms and digital advertising. As set out in Appendix M to the final report, the CMA considers that the ad tech stack in practice consists of several vertically-related markets; it was not necessary to separate these out for the purposes of stating our competition concerns, but this should not be taken as implying that the CMA considers that there is a single market for the supply of ad tech services. ↩

405. Visit the Notice of intention to accept binding commitments offered by Google, 11 June 2021, paragraphs 5.68 to 5.79. ↩

406. Visit the Notice of intention to accept binding commitments offered by Google, 11 June 2021, paragraphs 5.80 to .82. ↩

407. Google’s proposed commitments are described in more detail in Appendix 1 of the relevant Notice of intention to accept binding commitments offered by Google. ↩

408. Visit the Notice of intention to accept binding commitments offered by Google, 11 June 2021, paragraphs 6.1 to 6.77. ↩

409. To provide authenticated third-party content (such as federated logins) despite full TPC blocking, the Storage Access API allows embeds to request access to their first-party cookies when the user interacts with them. A user can be prompted at most twice for storage access, and a user’s consent (‘Allow’ in the prompt) is persisted. ↩

410. Purged data includes (i) all data for domains with cross-site tracking capabilities which have not received user interaction as first party or been granted storage access as third party through the Storage Access API in the last 30 days of browser use, and (ii) a website’s script-writable storage (including IndexedDB, LocalStorage, Media keys, SessionStorage, Service Worker registrations and cache) after 7 days of Safari use without user interaction on the site. ↩

411. Visit WebKit’s Tracking Prevention Policy. ↩

412. The support of Chrome and Safari for different advertising use cases is set out by the W3C Improving Web Advertising Business Group. For example, Apple’s Private Click Measurement allows advertisers to understand which of their advertisements drive conversions, but not to target advertising based on user information as the feature only uses the click destination’s registrable domain visit WebKit’s Introducing Private Click Measurement, PCM. ↩

413. Tracking of users’ online activity is often invisible to users, and their consent is not always sought, or sought in a way that does not comply with the requirements of data protection and privacy law. ↩

414. Visit Announcing the WebKit Tracking Prevention Policy ↩

415. Apple submitted that it has not analysed the impact of ITP on the value of digital advertising on Safari or online content providers’ choice of advertising channel. ↩

416. One online content provider also commented on being unable to consistently and accurately identify its own customers within Safari since the shortening of the lifespan of third-party remarketing cookies. ↩

417. 12 out of the remaining 26 online content providers reported an unclear impact, mostly due to the lack of data. ↩

418. A differential impact may be driven by differences in advertising across online content providers. ITP, for example, has impacted Facebook’s ad business as it comes mainly from direct response advertising but Twitter’s ad business is likely spared as the social networking site is mainly used for less targeted brand advertising. Visit Reuter’s Facebook ad revenue seen feeling brunt of Apple privacy changes article. ↩

419. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising Final Report Appendix G paragraph 324. ↩

420. We have heard complaints that Apple uses ITP as an excuse to restrict competition and favour its own advertising services. ↩

421. Visit Reuters’ Amazon seen triumphing over Apple privacy changes in digital ad business and Alphabet earns record profit on Google ad surge articles. ↩

422. Visit Alphabet Earnings’ Quarterly Period Ended September 30, 2021. ↩

423. As described in paragraphs 6 to 15 of the CMA’s market study into online platforms and digital advertising final report, a lack of competition in advertising can (i) inhibit innovation and the development of new, valuable services for consumers, (ii) increase costs to consumers (since free services are paid for indirectly through advertising), (iii) lead to inadequate compensation for consumers’ attention and personal data, (iv) reduce the ways in which people can control how their personal data is used or (v) cause wider social, political and cultural harm through the decline of authoritative and reliable news media. ↩

424. As described in Competition in the supply of mobile devices and operating systems, the availability of compatible content is a barrier to competition in the supply of mobile devices and operating systems. When web advertising is made less lucrative, some online content providers switch to native apps, reducing the availability of content on the web (which is compatible across operating systems). ↩

425. One online content provider specifically raised the concern that (together with IDFA) ITP encourages developers to change their business model entirely, moving away from an ad-funded model to a subscription or in-app purchase model that is subject to Apple’s 15 to 30% surcharge. The academics Sokol and Zhu make similar points in their paper Harming Competition and Consumers under the Guise of Protecting Privacy An Analysis of Apple’s iOS 14 Policy Updates. ↩

426. DMG Media raised similar concerns in its response to the statement of scope: ‘While impairing effective digital advertising on iOS, Apple is at the same time expanding its own profitable advertising business […] Apple subjects iOS users to personalized advertising by default, that is without obtaining opt-in user consent.’ Apple App Store Search Advertising revenues in the UK increased from [£0 to 100m] in 2017 to [£100 to 200m] in 2020. ↩

427. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising Final Report Appendix G. ↩

428. The Privacy and Electronic Communications Regulations 2003 (PECR) require subscriber or user consent, of the standard laid out in the GDPR, to set any cookies (or similar technology) except when they are strictly necessary to provide a service the subscriber or user has requested. ↩

429. Visit the CMA’s and ICO’s joint statement on competition and data protection law. ↩

430. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising Final Report Appendix H, paragraphs 83 to 85. ↩

431. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising Final Report Appendix H,. ↩

432. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising Final Report Appendix H, paragraphs 123 and 125. ↩

433. We still need to understand to what extent this is driven by merit or other factors. ↩

434. Visit the CMA’s, Market Study into Online Platforms and Digital Advertising Final Report Appendix H, paragraph 3.151. ↩

435. We refer in Competition in the supply of mobile devices and operating systems to concerns about Google not making certain APIs available in the open-source version of Android, which may limit competition from versions of Android not using Google’s Google Mobile Services. That is a different issue to the one considered in this section, which is about restrictions on app developers’ access to APIs within Apple’s and Google’s operating systems. ↩

436. Visit Apple’s Requesting the Carplay Entitlements. ↩

437. Visit UK Finance’s 2021 Payments Report. ↩

438. Visit Apple Support UK’s Use multitasking on your iPad. ↩

439. Visit Jeremy Provost’s, iPad Camera Multitasking blog. ↩

440. Visit App Store Review Guidelines, introduction. ↩

441. Based on appeals since 1 January 2016. Apple upheld its original decision in [60% to 70%] of cases, and closed the remaining [20% to 30%] of appeals for other reasons such as the issue being resolved before a decision was made. ↩

442. This change was connected to the creation of a new feature where developers can submit metadata to showcase in-app events without having to update their apps to a new version – therefore the ‘last 10 submissions’ could include submissions that only updated the metadata as well as new versions of apps. ↩

443. Visit Regulation EU 2019, 1150 of the European Parliament and of the Council on promoting fairness and transparency for business users of online intermediation services, which took effect in July 2020 (and, notwithstanding Brexit, is also incorporated into UK law as ‘retained EU law’). ↩

444. This has not always been the case. For instance, originally the Maps app used Google Maps data until the introduction of Apple Maps in 2012, visit The Verge’s Apple replaces Google Maps with its own maps, turn-by-turn navigation and traffic info article. Originally, iOS also came with a YouTube app, visit CNET’s Google’s official iPhone YouTube app vs iOS 5 YouTube app article. ↩

445. Visit Android’s Google Mobile Services.. ↩

446. In addition, manufacturers are also required to place on the default home screen the Play Store app and a folder labelled ‘Google’ which contains all remaining Google apps. ↩

447. In the EEA and UK, the Chrome and Google Search apps were removed from the GMS suite following the EC’s Android decision in 2018. ↩

448. Under the terms of the EMADA, manufacturers are also free to pre-install apps which compete with Google own apps, except those that have decided to meet certain additional requirements under Google’s RSAs, as detailed in Competition in the distribution of native apps and Appendix E. These apps can be placed anywhere on the device, and may be placed more prominently than Google’s apps. A Google internal document shows device manufacturers pre-installing a wide range of third-party apps, which can vary significantly across providers. ↩

449. [REDACTED]. ↩

450. [This is subject to certain exceptions, which are essential for device out-of-the-box functionality, but does not extend to the Google Search app or Chrome]. Unlike iOS users, Android users are not limited to changing default settings for browser and mail client only and can change defaults for other apps too, such as music player, navigation, and camera apps. ↩

451. Separately, manufacturers who also enter into Placement Agreements with Google receive payments from Google if they meet [certain placement obligations]. ↩

452. For instance, a Google survey of 503 Android device users in India found that the majority of respondents liked having their favourite Google apps preinstalled on Android phones and believed that a smartphone should come with apps for commonly used services. ↩

453. For instance, a [survey we received of iPhone users in November 2020, including 1001 UK adult (18+) iPhone users], found that following the release of iOS 14 users were more likely to switch away from Safari following a negative experience, for example if they were dissatisfied with the app or if they experienced compatibility issues. ↩

454. For instance, a case study from South Korea shows that despite pre-installation of the Google Search app, rival search apps Naver and Daum reached larger download volumes and higher usage than the Google Search app. A 2016 Google survey of 500 Android phone users in France, Germany and the UK found that some of Google pre-installed apps failed to attract users – for example the majority of surveyed users used WhatsApp and Facebook Messenger for sending messages and Skype, Facebook and WhatsApp for video chats, with only a small proportion of users choosing to use Google Hangouts. On the other hand, Google’s cloud-storage app (Google Drive) and music apps (Play Music and YouTube) were among the most popular apps in their respective categories. ↩

455. For example, clicking on an address will automatically open the default navigation app: if users were unable to change the default navigation app, they would need to manually input the address into their preferred navigation app instead of simply clicking on it. ↩

456. Similar findings were also made by the European Commission, which previously concluded in its Google Android decision that pre-installation is an important channel for the distribution of general search services on smart mobile devices. ↩

457. In this report, we use the terms ‘app store search’ and ‘organic app store search’ interchangeably. This refers to a situation when results in response to a search query are strictly determined by the search algorithm and are not affected by any advertiser payments. ↩

458. Based on Apple’s UK App Store downloads between June 2020 and May 2021. ↩

459. Based on Google’s UK Play Store downloads between [REDACTED] and [REDACTED]. Excludes downloads with no source information which accounted for [30% to 40%] of UK Play Store downloads during this period. Comparison with Google’s global downloads data between June 2020 and May 2021 shows that Google Play Store organic search and search ads accounted for [50% to 60%] of global downloads. Downloads browsing other Play Store sections accounted for [20% to 30%] of all downloads and third-party referrals for [10% to 20%]. ↩

460. Although we note that nearly [10% to 20%] of queries could not be allocated a known source. ↩

461. Based on Apple’s UK App Store Downloads between June 2020 and May 2021. Currently the App Referrals also include downloads from Safari app, meaning that the real downloads through other apps will be lower. ↩

462. Unlike Apple’s data, Google’s data does not allow to clearly distinguish between app and web referrals. This is based on Google’s UK Play Store downloads between 20 July 2021 and 10 September 2021 and excludes downloads with no source information which accounted for [30% to 40%] of UK Play Store downloads during this period. ↩

463. For instance, Apple’s webpage on App Store search optimisation explains that its App Store rankings are based on text relevance and user behaviour, visit Apple Developer’s Search Optimization App Store and Discovery on the App Store and Mac App Store. The main parameters used for app ranking and discoverability are also listed in Apple Developer Program Licence Agreement, visit Exhibit D to Apple Developer Program License Agreement. Similarly, Google’s webpages explain that it takes into account user relevance and the quality of the app experience. Visit App Discovery and Ranking Play Console Help. ↩

464. Visit for example Android Developers Blog Improved app quality and discovery on Google Play and Improving discovery of quality apps and games on the Play Store. ↩

465. As the vast majority of respondents were unable to accurately differentiate between categorical and functional search queries, we are unable to confirm the importance of categorical and navigational queries for different apps. ↩

466. Visit the CMA’s Online search Consumer and firm behaviour A review of the existing literature 2017. ↩

467. Visit The EU Google decisions Extreme enforcement or the tip of the behavioural iceberg? Fletcher, A (2019). ↩

468. VisitFeenberg, D., Ganguli, I., Gaulé, P., & Gruber, J. (2017). It’s Good to Be First Order Bias in Reading and Citing NBER Working Papers. The Review of Economics and Statistics, 99(1), 32 to 39 for details on primacy effects. ↩

469. Visit the New York Times’, How Apple’s Apps Topped Rivals in the App Store It Controls article and WSJ’s Apple Dominates App Store Search Results, Thwarting Competitors article. ↩

470. For example many of Apple’s apps’ names (for example,Apple Music, Apple News, Apple Podcasts) match the generic search terms used by the New York Times, for example, ‘music’, ‘news’, ‘podcasts’, essentially benefiting from categorical queries that have become navigational. Apple noted that the New York Times knowingly used these terms rather than terms such as ‘streaming music’ or ‘video games’, thus ignoring how most consumers use App Store Search. Although, notably Apple has in the past demoted third-party apps for giving their apps generic names, visit for example, Investigation of Competition in Digital Markets Majority Staff Report and Recommendations, page 361. ↩

471. [REDACTED] ↩

472. ‘Same Developer Boost’ has since been disabled. ↩

473. Apple explained that when pre-installed iPhone apps were first made deletable with the introduction of iOS 10, they were also added to the App Store for the first time as a means for users to redownload the app and at that time had no search ranking data as a result. The ‘cold start boost’ does expire and the app will fall in the rankings if customers do not download the app. ↩

474. Visit The Verge’s You can finally rate Apple’s apps on the App Store article. ↩

475. Apple explained that the reviews and ratings were unavailable for its pre-installed apps, as these apps were made available for re-download only. ↩

476. Visit the ACCC’s digital platform services inquiry, March 2021 interim report, pages 89 to 91. ↩

477. Some developers mentioned that while they were updated about the most significant changes, they still felt they lacked information about more minor changes to the search algorithms. ↩

478. Providing, through the platform’s terms and conditions, advance notice to businesses of the main parameters used to determine search rankings, their relative importance as well as any action businesses can take to influence the ranking is a requirement of the P2B Regulation, discussed above. As changing those main parameters necessarily involves amending the platform’s terms and conditions, such changes must, under the P2B Regulation, also be notified to businesses at least 15 days before they take effect. ↩

479. Visit example, Discovery on the App Store and Mac App Store App Store Apple Developer and Find great apps and games on Google Play with the Editors’ Choice update. ↩

480. For example, being featured on Apple’s App Store ‘Today’ tab can, in certain cases, boost app downloads by up to 800% during the week following the feature, although this could vary significantly depending on the section in which the app was featured, visit iOS 11’s App Store Increases Downloads of Featured Apps up to 800%. Visit Phiture’s Just How Impactful is Being Featured on the App Store. ↩

481. For example, Google Play Pass and Apple Arcade. ↩

482. [REDACTED] ↩

483. Visit Emails reveal Apple’s attempts to stop Netflix from dropping App Store In-App Purchase support - 9to5Mac and The best emails from the Apple vs Epic trial. ↩

484. Visit the ACCC’s digital platform services inquiry, March 2021 interim report pages 97 to 98. ↩

485. For example, the ACCC found that 88% of apps that had at least one feature occurrence on the Australian App Store in 2020 had in-app payments. By contrast, only 16% of apps on the App Store had business models that required the use of Apple IAP, visit the ACCC’s digital platform services inquiry, March 2021 interim report, page 97. ↩

486. Visit Apple DPLA, 9.3. ↩ ↩²

487. As discussed above in the section on access to device hardware and software, there may be concerns in some instances that restrictions on integration by third parties are unjustified and may be harmful to competition, but in other cases these are likely to be warranted. In those cases, Apple or Google providing higher-quality integrated products is beneficial to consumers. ↩ ↩²

488. Apple’s MFi Program covers third-party hardware accessories that use Apple’s MFi licensed technology to connect electronically to Apple devices. These technologies include the Lightning connectors that are required for any accessory that needs to by ‘plugged in’ to an iPhone, but exclude Bluetooth connections. ↩

489. Visit the Washington Posts’ Apple has copied some of the most popular apps in the App Store for its iPhone, iPad and other software updates article. ↩

490. Visit Hausfeld & Co LLP response to Statement of Scope ↩

491. Visit The Information, Internal Google Program Taps Data on Rival Android Apps, July 23, 2020. ↩

492. Visit the CMA’s Investigation into Apple AppStore. This investigation is ongoing and no decision has yet been made as to whether Apple has acted unlawfully. Competition Act investigations are based on different legal tests and standards of proof than the CMA’s market studies. As such, while the market features and practices being considered are similar, any findings in this market study are without prejudice to the CMA’s assessment under the Competition Act. ↩

493. Publicly available on Apple’s website App Store Review Guidelines Apple Developer. Last accessed 9 December 2021. ↩

494. Visit Payments Play Console Help. See also Monetisation and ads - Play Console Help. ↩

495. Google recently announced proposals to further reduce commission fees for specific vertical apps in the Play Media Experience Program from 1 January 2022. The circumstances in which Google applies a commission of less than 30% are described in Appendix H. ↩

496. Apps that do not enable users to purchase access to digital goods or services from within the app. Understanding Google Play’s payments policy Play Console Help. ↩

497. Visit Android Developers Blog Listening to Developer Feedback to Improve Google Play; Visit also Understanding Google Play’s Payments policy Play Console Help last accessed on 9 December 2021. ↩

498. That is, the revenue that Apple/Google retain from transactions made through their payments systems in the UK. ↩

499. Including the Google Play Store, Amazon Appstore, Samsung Galaxy Store, Microsoft Store, Xbox Live Store, Sony PlayStation Store and Nintendo eShop. ↩

500. Among other things, this legislation, which came into effect in September 2021 prohibits app store platforms such as Apple and Google from requiring app developers to use their proprietary payment systems (ie IAP and Google Play billing). To date, Apple has not proposed changes to its relevant policies, and has reportedly told Korean authorities that it considers that its current practices already comply with the new law. MLex article. ↩

501. Google blog on enabling alternative billing in Korea. ↩

502. Google support page. ↩

503. Apple’s Family Sharing feature allows consumers to share their app purchases content, and services with other members of their family. The Ask to Buy capability provided in Family Sharing allows parents to approve all app downloads, app purchases, and IAP purchases made by their children. ↩

504. An IAP purchase cannot be completed until the consumer is shown a pricing sheet, which clearly discloses the price of the item, and the account and payment method that will be charged. For subscription items the pricing sheet displays the renewal schedule and the duration of any free trial or promotional price. ↩

505. After a customer reviews the pricing sheet, Apple confirms that the consumer wants to go ahead with the purchase via the consumer’s fingerprint on Touch ID-enabled devices, or the consumer’s face on Face ID-enabled devices. ↩

506. All IAP purchases are recorded on a comprehensive email receipt. In addition, all IAP purchases are included in a centralised Purchase History menu that consumers can reference at any time. ↩

507. Consumers can report an issue with a purchase and request a refund from Apple by accessing the Report a Problem menu from an email receipt of on the web. This allows users to deal with a single point of contact and with a company of Apple’s reputation. ↩

508. Apple’s commerce system enables the completion or restoration of purchases, whether in situations where either a user hit the “buy” button for an IAP purchase and the developer did not deliver the content for some technical reason, or where the user wants to transfer and app and in-app purchased content onto a new Apple device. ↩

509. All information about IAP subscriptions is contained in a centralised menu so that consumers can keep track of their charges and can easily cancel subscriptions if they so wish. ↩

510. IAP data is analysed by Apple’s extensive fraud analysis engine, providing Apple with data which it can use to root out scams and unscrupulous developers. ↩

511. Merchant of Record - Play Console Help. See also section 3.3 of DDA ↩

512. See: Apple press release. ↩

513. Information about a user’s consumption of a consumable in-app purchase. ↩

514. App Store preview of Amazon Music listing. ↩

515. Amazon Music FAQs. ↩

516. Apple Music. ↩

517. European Commission press release, Antitrust: Commission sends Statement of Objections to Apple on App Store rules for music streaming providers. ↩

518. Email exchange between Phillip Schiller and Steve Jobs, November 2010. ↩

519. In October 2020, the French competition authority (Autorité de la concurrence) received a request for interim measures by players of the online advertising sector contesting the ATT implementation. Although it rejected such request in March 2021, it continues the investigation into the merits of the case, to verify whether the implementation of ATT may amount to discrimination or self-preferencing. ↩

520. This type of advertising is very common on social media (for example Facebook) where an app is advertised and the ad contains a link (generally called ‘Install now’ or ‘Download now’) that usually directs the user to an app store download page or an app website ↩

521. In previous versions of iOS, users could opt out of allowing app developers to access their IDFA by turning on an option to ‘Limit Ad Tracking’ in the centralised iOS settings. ↩

522. Before the introduction of ATT, user consent to access the IDFA would still have been a legal requirement under the Privacy and Electronic Communications Regulations 2003 (PECR). PECR requires subscriber or user consent, of the standard laid out in the GDPR, to set any cookies (or similar technology) except when they are strictly necessary to provide a service the subscriber or user has requested. ↩

523. Attribution is particularly important for so-called ‘direct response advertising’, meaning the type of advertising designed to get an instant response by encouraging users to take a specific action and whose payoff comes as a result of that action taken directly in response to an ad. This is different from ‘brand advertising’ which is aimed at establishing brand recognition and longer-term relationships with consumers. See What Is Brand Advertising & Why Should You Use it? and Snap Earnings, Attribution and Targeting, The Supply Chain – Stratechery by Ben Thompson. ↩

524. Apple also offers display advertising in its News and Stocks apps, which typically takes the form of ads that appear around or within news articles or other content accessed through those apps, but [over 90%] of Apple’s advertising revenue in the UK and worldwide came from search ads. ↩

525. Apple told us that ads on the App Store do not access consumer data from other Apple services like Apple Pay, Maps, Siri, iMessage, and iCloud or data from devices through services and functions such as the Health app, HomeKit, email, contacts, or call history. ↩

526. ICO (2021), Data protection and privacy expectations for online advertising proposals. ↩

527. As mentioned above, PECR requires that app developers have the user’s GDPR standard consent to access the IDFA. ↩

528. App Store Review Guidelines, 5.1.2 (i)-(iii) ↩

529. The W3C defined tracking as ‘the collection of data regarding a particular user’s activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties’. ↩

530. ICO/CMA joint statement. ↩

531. ICO (2021), Data protection and privacy expectations for online advertising proposals, page 36. ↩

532. ICO (2021), Data protection and privacy expectations for online advertising proposals, page 14. ↩

533. ICO (2021), Data protection and privacy expectations for online advertising proposals, page 15. ↩

534. These stakeholders include Amnesty International, Human Rights Watch, Electronic Frontier Foundation, Privacy International, The Center for Democracy and Technology and Mozilla. See Appendix I for further detail. ↩

535. CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report, Appendix Y. ↩

536. CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report, Appendix Y. ↩

537. App Store Review Guidelines, 3.2.2 (vi). ↩

538. Apple cited in particular European Data Protection Board guidance on GDPR and a statement by the Dutch data protection agency on ‘cookie walls’. ↩

539. ICO, What is valid consent? ↩

540. For specific opt-in figures submitted by some app developers, see Appendix I. ↩

541. For instance, estimates from AppsFlyer suggest that, as of 26 October 2021, 44% of UK users who have seen the ATT prompt opted in. See iOS 14 & ATT benchmarks Report, AppsFlyer (based on 80% iOS 14.5 user adoption rate). Differently, estimates from Flurry suggest a worldwide weekly opt-in rate of 23% across apps that have displayed the prompt in September 2021 with the figure being stable and ranging between 31% and 22% since the release of the ATT prompt. See iOS 14 Opt-in Rate - Weekly Updates Since Launch, Flurry. ↩

542. Assuming an efficiency decline for (the developer’s) spend on of campaigns that drive iOS app installations of 10%, customers decline will be less than 0.5%. ↩

543. This was based on a 63% adoption of iOS 14.5 where the ATT prompt was rolled out. ↩

544. This was due to loss of personalisation only in the ranking as opposed to in targeting. ↩

545. Snap’s Stock Plummets as It Blames Apple’s Privacy Changes for Hurting Its Ad Business - WSJ. ↩

546. Snap Inc. (SNAP) CEO Evan Spiegel on Q3 2021 Results - Earning Call Transcript, Seeking Alpha. ↩

547. Facebook Posts Slower Sales Growth With Apple Privacy Policy - WSJ. ↩

548. Facebook said that it estimated to be underreporting iOS web conversions compared to sales and app installs actually happening due to less accurate measurement post-ATT and it expected to improve this for its clients in the relatively short term. It also said that ATT’s effect on targeting was a longer-term challenge as several Facebook’s ad products are built on user level conversions and, as a result of ATT, Facebook cannot see the same level of conversion data. Therefore, Facebook said it has to rebuild its targeting and optimization systems to work with less data and that this is a multiyear effort. See FB Q3 2021 Earnings Call Transcript. ↩

549. See Twitter Earnings Transcript. See also Snap, Facebook, Twitter and YouTube lose nearly $10bn after iPhone privacy changes, Financial Times. ↩

550. As explained in Appendix I, with ‘contextual advertising’ the targeting of the advertisement is driven by the surrounding content, including the nature of the medium and the user’s activity at the time of seeing the ad (for example, advertising for sports equipment served on sports-related applications); , meaning a type of advertising designed to get an instant response by encouraging people to take a specific action and whose payoff comes as a result of an action taken directly in response to an ad. ‘brand advertising’ on the other hand is aimed at establishing brand recognition and longer-term relationships with consumers over time. See What Is Brand Advertising & Why Should You Use it? ↩

551. Google Q3 2021 Earnings Call Transcript, page 9. ↩

552. This is in part due to concerns around the extent to which SKAdNetwork is an adequate substitute to IDFA-based attribution, as explained in more detail in the ‘Self-preferencing of Apple’s advertising’ section below and in Appendix I. We will further explore this in the second half of our market study. ↩

553. Data protection law would still apply, and the ICO recently confirmed that ‘data protection law does not inherently favour the concept of a first party over that of a third-party within the meanings web standards bodies or data categorisations given to those terms’. Data protection and privacy expectations for online advertising proposals, 2021. ↩

554. An example of this would be a centralised platform hosting interaction between several businesses and their consumers which would normally interact bilaterally elsewhere. See The profound, unintended consequence of ATT: content fortresses. ↩

555. Why did Applovin buy MoPub?, Mobile Dev Memo. ↩

556. See Impact on app developers section above. ↩

557. In response to questions to market participants, we have heard that Apple treats ‘all data within the App Store as being their first-party data’ and therefore it does not need to display the ATT prompt. ↩

558. See Snap Inc. Earning Transcript; See also ATT advantages Apple’s ad network. Here’s how to fix that. ↩

559. In particular, compared to SKAdNetwork, Apple Search Ads Attribution API includes the date of the ad click and more detailed information about the specific ad format that led to a conversion. This information is key to optimising ad campaigns and selecting the most effective ad format for a given group of users. For further detail on how SKAdNetwork and Apple Search Ads Attribution API compare, see Appendix I. ↩

560. Since the ATT roll-out and in the space of a few months, multiple versions of SKAdNetwork have been released by Apple with sudden changes implemented between those. This relates in particular to the so-called “privacy thresholds” rule, based on which Apple hides the conversion values when the number of conversions sharing certain characteristics is too low. We understand that Apple does not disclose the rules governing “privacy thresholds” (for example the characteristics it considers or the threshold that must be reached to be able to see conversion values) to other market participants and these appeared to have suddenly changed, creating data losses and uncertainty for advertisers. For further detail on this, see Appendix I. ↩

561. Apple’s privacy changes create windfall for its own advertising business, Financial Times. ↩

562. Ibid. ↩

563. See This could be Apple’s next $20 billion business. We understand that this estimate excludes the payments Apple gets from Google for setting Google Search as default search engine, including on Apple’s browser Safari, which was reported to amount to up to $12bn by the Department of Justice. See Justice Department Sues Monopolist Google For Violating Antitrust Laws, OPA, Department of Justice. ↩

564. While these figures are indicative of the scale of app install advertising, they may also include other (non-advertising) cases where apps included a link to an App Store page. For example, a developer may include links in one app to its other apps’ App Store pages, or a user of a social media app might post a link to an app on the App Store. Conversely, some downloads that directly resulted from navigational searches may be linked to app install advertising, as users may view or click an app install ad without immediately downloading the app but return to the App Store later and search for the app to download it. ↩

565. It has been suggested that Apple’s role as discovery channel for apps has been weakened by app install advertising and that the App Store has become a “frictional, annoying moment between clicking an ad and installing an app.” See An Interview with Eric Seufert about Apple, Facebook, and Mobile Advertising –Stratechery by Ben Thompson. ↩

566. Apple’s IDFA changes are already changing game design and monetization, VentureBeat. ↩

567. CMA-ICO joint statement on competition and data protection law. ↩

568. Venturebeat, 18 July 2021, Apple’s IDFA changes are already changing game design and monetization. ↩

569. For example, Microsoft’s Xbox Game Pass Ultimate, Google Stadia, Facebook Gaming, Amazon Luna. ↩

570. For example, faster processors or more storage. ↩

571. for example, installing updates or removing game apps which are no longer available. ↩

572. In-app purchases are disabled on the version distributed through Google’s Play Store. ↩

573. ‘AAA games’ are typically produced by medium to large sized publishers with larger development and marketing budgets than other types of games such as mobile games. ↩

574. Stadia - Play Games Online Across Your Devices Now. ↩

575. HTML5 games accessed within the app with AAA games cloud streamed in enabled areas (currently North America, parts of Western Europe and Singapore). ↩

576. Amazon Luna is only available as an early access version in the US. ↩

577. Amazon Luna – Cloud Gaming Service. ↩

578. After Apple introduced an exception for streaming games in September 2020. ↩

579. App Store Review Guidelines - Apple Developer 4.9. ↩

580. For example, maintaining App Store metadata and visual assets such as app icons and screenshots. ↩

581. With in-app purchases disabled – available on Samsung Galaxy Store with in-app purchases. ↩

582. See Tile’s Statement of Scope Response, page 5 at Response: Tile. See Dr Greig Paul and Dr James Irvine’s Statement of Scope Response, page 15 at Response: Dr Greig Paul and Dr James Irvine. ↩

583. Exhibit PX-0464 in Apple/Epic. ↩

584. IFPI Global Music Report 2021. In 2010 digital music download revenues were $3.9 billion while music streaming revenues were $0.4 billion. In 2020, digital music download revenues were $1.2 billion while music streaming revenues were $13.4 billion. ↩

585. NPD estimates gave Apple a 70% share of US digital music downloads in 2010. Statista estimated that Apple Music had a 16% share of music streaming subscribers worldwide in the first quarter of 2021. ↩

586. At this interim stage in our study, we have sought simply to identify potential interventions and give preliminary consideration to their likely effectiveness, rather than seeking to design, or recommend, the particular combination of interventions that we think would result in greatest benefit to competition and consumers. ↩

587. As noted in the next chapter, this preliminary consideration has been undertaken based on the scope and nature of the regulatory regime as currently envisaged in the recent government consultation: A new pro-competition regime for digital markets (June 2021). As and when that regime is implemented, it will be for the DMU (which will operate the new regime within the CMA) to determine, based on its assessment of the mobile ecosystems markets at that time, a) whether Apple or Google should be designated with strategic market status (SMS) in relation to any of their activities relating to their ecosystems; b) whether any interventions are required to make those ecosystems markets work well, and c) if so, the scope and form of those. ↩

588. For Apple, we consider its position for operating systems together with its devices, given Apple’s vertically integrated model. ↩

589. Equitable Interoperability: the “Super Tool” of Digital Platform Governance, Yale Tobin Centre for Economic Policy, 2021. ↩

590. Our commitments for the Privacy Sandbox, Google Blog, June 2021. ↩

591. For example, see Complaint filed by the Department of Justice against Google, paragraphs 73 to 75. ↩

592. See Oracle’s Statement of Scope Response, page 9 at Response: Oracle Corporation. ↩

593. More Competitive Search Through Regulation, Yale Tobin Centre for Economic Policy, 2021. ↩

594. European Commission proposal for a Digital Markets Act, COM/2020/842, 15 December 2020, Article 6(1)(b) and 6(1)(c); and the Open App Markets Act bill introduced in the US Senate, S.2710 – 117th Congress (2021 to 2022), 11 August 2021, Section 3(d). ↩

595. See Apple’s Statement of Scope Response, paragraph 21 at Response: Apple. ↩

596. Building a Trusted Ecosystem for Millions of Apps – a threat analysis of sideloading, Apple, October 2021. ↩

597. Google’s Statement of Scope Response, page 6 at Response: Google. ↩

598. See Apple’s Statement of Scope Response, paragraph 12 at Response: Apple. ↩

599. See Appendix I for further detail on user journeys for changing default browser on iOS and Android. ↩

600. Presenting search app and browser options to Android users in Europe, Google Blog, April 2019. ↩

601. CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report, Appendix V. ↩

602. For example, the Play choice screen for browsers currently shown on Android devices, prompts users to download other browsers, in addition to the ones already installed, without changing the default. However, as this choice screen is displayed once per Google account, the first time a user opens Google Play store, it applies only to a limited sub-set of users. ↩

603. Competition in the supply of mobile browsers and Appendix G discuss our view of these screens. ↩

604. For example, in 2009, Microsoft entered into commitments with the European Commission and made a choice screen available on Windows devices between 2010 to 2014 which gave users the opportunity to choose from a variety of web browsers (See the European Commission’s press release dated 16 December 2009 regarding the commitments it entered into with Microsoft). This was reported as having been a success, leading to a significant uptake in the downloading of non-Microsoft browsers (BBC article (2014), Deal forcing Microsoft to offer browser choices ends). ↩

605. The Google agreement concerns are comparable with our discussion on the Play Store above. ↩

606. The Government is consulting on powers to trial remedies. If such powers were implemented, it would be beneficial to trial different choice screens to understand their impact for users, platforms and third parties, and this could be built into the assessment of likely effectiveness. ↩

607. Indeed, we are aware that within the Android system, competing browsers sometimes elect to withhold functionality theoretically available to Android web apps on basis of privacy or security. ↩

608. For example, because most of the functionality under consideration is already applied by both Blink and in native apps, and because Apple provides a choice screen to customers on whether to enable most forms of functionality, it seems unlikely that allowing access to these types of functionality would adversely affect user experience. ↩

609. Examples provided by third-party developers include more equitable access to: content blockers and password extensions on iOS; WebRTC on iOS; ‘Process Separation’ on iOS; device-related APIs relating to certain audio functionality and webcams, and progressive web app features potentially available to own browsers but not to third-party browsers. See Competition in the supply of mobile browsers for more detail. ↩

610. About the choice screen, Android. ↩

611. See Competition in the supply of mobile browsers and Appendix G. In the year to 31 August 2021, in [90% to 100] % of cases in which the choice screen was used, Google Search was chosen. ↩

612. See, CMA, Notice of intention to accept modified commitments offered by Google. ↩

613. See The role of Apple and Google in competition between app developers for further detail. ↩

614. As noted in The role of Apple and Google in competition between app developers, the Platform to Business (P2B) Regulation already imposes certain transparency requirements on online intermediation services such as app stores, including in relation to the main parameters used by their search or ranking algorithms. It is primarily for individual app developers to make use of complaints or mediation mechanisms that the P2B Regulation obliges online intermediation services to offer, or to bring proceedings before court to recover any losses. We are not aware of any such proceeding being brought against Apple or Google under of the P2B Regulation to date. ↩

615. In particular, Apple argues that the protections on the App Store ensure that games have product pages with important information, are subject to privacy-protective processes and can be subject to parental controls, and that it would not be able to apply these protections to individual games within a cloud gaming app. ↩

616. We note that both Apple and Google’s rules are now limited to only restrict communications made by developers within the app (for example, at point of purchase) rather than outside the app (for example, via email). ↩

617. As set out in The role of Apple and Google in competition between app developers, Google’s recent announcement in South Korea suggests that Google has found a technical solution that enables it to track in-app transactions where a third-party payment system is used, in order to collect its commission. ↩

618. Introduced by the European Commission on 15 December 2020, COM(2020) 842. The European Parliament Committee for the Internal Market and Consumer Protection adopted its position on the proposals, with compromise amendments to the Commission’s original text, on 23 November 2021. The European Parliament is due to vote on the amended proposals in plenary session in December 2021. The Council of the European Union has recently adopted its own common position on the Digital Markets Act and negotiations between the Council and the European Parliament are due to commence in 2022. ↩

619. The Open App Markets Act bill was introduced in the US Senate on 11 August 2021 by Senators Blumenthal, Blackburn and Klobuchar, S.2710 – 117th Congress (2021-2022). A companion bill was introduced to the House of Representatives by Representatives Buck and Johnson on 13 August 2021. The bills await votes in the Senate Judiciary Committee and the House Committee on Energy and Commerce respectively. It is not currently clear when those votes, and the subsequent implementation of the legislation (should it be approved), will take place. ↩

620. S.Korea’s parliament passes bill to curb Google, Apple commission dominance ↩

621. Korea Communications Commission - Press Release. ↩

622. For example, as a matter of public enforcement, a civil antitrust lawsuit filed by the US DOJ and eleven state Attorneys General in October 2020 to stop Google from unlawfully maintaining monopolies through anticompetitive and exclusionary practices in the search and search advertising markets and to remedy the competitive harms (Justice Department Sues Monopolist Google For Violating Antitrust Laws, OPA, Department of Justice). In terms of private enforcement, notable cases include: Cameron et al v. Apple Inc., in which Apple agreed to settle a case brought by a group of app developers regarding Apple’s management of the App Store for the iPhone and iPad (and in particular its abuse of its dominant position to impose high commission fees); Epic Games, Inc. v Google LLC et al, and Epic Games, Inc. v Apple Inc., relating to practices on Google’s and Apple’s respective app stores; and State of Utah v Google LLC, in which a coalition of 37 attorneys general allege exclusionary conduct by Google relating to the Google Play Store for Android. ↩

623. For example, European Commission cases AT.39740 - Google Search (Shopping); AT.40099 - Google Android; AT.40411 - Google Search (AdSense); AT.40716 Apple - App Store Practices; AT.40452 Apple - Mobile payments; and AT.40437 Apple - App Store Practices (music streaming). ↩

624. In September 2021, the JFTC announced that it was closing its investigation into Apple for suspected abuse of dominance in relation to its App Store, on the basis that Apple had agreed to revise its App Store Guidelines by allowing certain ‘read-only’ apps to refer to payment options on websites (see Closing the Investigation on the Suspected Violation of the Antimonopoly Act by Apple Inc.: Japan Fair Trade Commission). ↩

625. In September 2021, the Korea Fair Trade Commission issued a corrective order and a fine against Google for forcing mobile device manufacturers to sign anti-fragmentation agreements (“AFA”), which prevented the manufacturers from installing Android Forks (see KFTC Press Release for further detail). ↩

626. Collective actions against Apple and Google have been filed in the UK alleging respectively: (i) that Google unfairly restricts consumers from accessing potential competition from other app distributors, by requiring smartphone manufacturers to pre-install a bundle of Google’s proprietary apps and services including the Play Store as well as imposing other contractual and technical restrictions; and (ii) that Apple uses its dominant position by imposing restrictive terms on app developers, stifling efforts by other would-be distributors to offer app purchasers better value for money, and reaping excessive profits. The cases will be heard in the Competition Appeal Tribunal (see Elizabeth Helen Coll v Alphabet Inc. and Others (1408/7/7/21); and Dr. Rachael Kent v Apple Inc. and Apple Distribution International Ltd (1403/7/7/21)). ↩

627. Investigation into Apple AppStore ↩

628. Apple agreed to settle the class action Cameron et al v. Apple Inc in August 2021. As part of the settlement process, Apple agreed to change its rules preventing US developers from contacting customers outside the App Store to advertise alternative payment methods. Apple also committed, among other things, to continue with its Small Business Program, to improve its app review process, and to increase the number of price points available to developers. Apple updated its guidelines for app developers on 22 October 2021. The settlement received preliminary approval from the court in the Northern District of California on 16 November 2021. On 21 October 2021, Google announced that it was decreasing its commission fee for all subscriptions on Google Play from 30% to 15%, effective from 1 January 2022. ↩

629. A new pro-competition regime for digital markets. ↩

630. Unlocking digital competition, Report of the Digital Competition Expert Panel (March 2019). ↩

631. See A new pro-competition regime for digital markets, Part 3. ↩

632. CMA analysis of data from market participants. Apple provided data on “Transacting accounts”. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one smartphone/tablet, and one smartphone/tablet could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active smartphones/tablets. ↩

633. CMA analysis of data from market participants. Apple provided data on “Transacting accounts”. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one smartphone, and one smartphone could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active smartphones. ↩

634. CMA analysis of data from market participants. Apple provided data on “Transacting accounts”. Transacting accounts correspond to the number of accounts that performed a transaction (download, purchase etc.) on the device. A transacting account could be linked to more than one tablet, and one tablet could be linked to more than one transacting account. This means that the number of transacting accounts may over or underestimate the number of active tablets. ↩

635. Population estimates - Office for National Statistics. ↩

636. That is, the revenue that Apple retain from transactions made through their payments systems in the UK. ↩

637. Apple’s limited support for web apps on iOS diminishes developers’ incentives to develop web apps for all mobile devices and operating systems (ie including Android devices), given that the idea of a web app is to develop one app to be used on browsers on any operating system. ↩

638. How to Update Google Play Services on Your Android Phone. ↩

639. For example, Android has a share of just over 70% of worldwide smartphone operating systems based on Statcounter data. See Mobile Operating System Market Share Worldwide, Statcounter Global Stats. ↩

640. Population estimates - Office for National Statistics. ↩

641. See, CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report. ↩

642. As set out in the CMA’s market study into online platforms and digital advertising, Android provides Google with data advantages that create a barrier to entry and expansion for rivals in search advertising. CMA (2020), Market Study into Online Platforms and Digital Advertising, Final Report, paragraph 5.60. ↩

643. As set out in Competition in the supply of mobile devices and operating systems, Huawei currently uses a version of Android that falls within Google’s compatibility requirements, but relies on Huawei’s Huawei Mobile Services instead of Google Mobile Services due to US legislation in May 2019 which meant that Huawei could no longer access Google’s apps and services, including Google Mobile Services. ↩

644. As noted in Competition in the distribution of native apps, while this is likely to overestimate the share of the Play Store to some extent as it does not include all alternative app stores, it is consistent with evidence received from app developers. ↩

645. For the short time period in 2021 for which Google provided data. ↩

646. For the short time period in 2021 for which Google provided data. ↩

647. In the year to 31 August 2021, in [90% to 100%] of cases in which the choice screen was used, Google Search was chosen. ↩

648. See Figure 3 and Figure 4 of the government consultation, page 29 and 31. The flexibility for the DMU to set principles that we have assumed appears to us consistent with the consultation’s ‘Option 1’ (‘Principles, developed and updated by the DMU in consultation with stakeholders, would be firm-specific and not set in legislation’) or ‘Option 3’ (objectives and ‘high-level’ principles set in legislation, with the DMU given ‘powers to develop additional legally binding requirements in relation to those principles’). ↩

649. We have not at this stage made any assumption as to whether the different activities within the scope of this study would be considered together under the code, or through separate codes. This would be influenced by the specific drafting of any legislation, and would be for the DMU to determine. ↩

650. Noting again that ultimately it will be for the DMU to determine whether, and for which activities, Apple or Google should be designated with SMS, and then the scope of any consequent codes of conduct, within whatever legal framework is ultimately legislated for. ↩

651. Further guidance on CMA market investigations is set out in CMA3: Market studies and investigations - guidance on the CMA’s approach and CC3: Market Investigations Guidelines. ↩

652. Section 169(6) Enterprise Act 2002. ↩

653. Sections 131A – 131B Enterprise Act 2002. This does not preclude the CMA from making a market investigation reference in relation to those matters at another time, provided the requirements summarised in paragraph 9.2 are met. ↩

654. Mobile ecosystems market study case page. ↩

655. Government consultation on A new pro-competition regime for digital markets, July 2021. ↩

656. Prior to making such a reference, the CMA would consult publicly on its intention to do so, in line with its statutory obligations. ↩

657. Under s131A EA02, where the CMA receives representations that it should make an MIR, it is obliged to consult on whether it should do so. Where, as in this instance/study, no representations are made, and the CMA does not propose to make an MIR, no such formal requirement to consult applies. (s.131B(2) EA02). ↩

658. An explanation of how we will use the information provided to us is set out in the annex to our statement of scope. ↩