Designing a Usable Alternative
The CMA’s proposed Steering conduct requirement is not a proposal for an unbounded exit from Apple’s App Store. It is a proposed way to let developers of digital goods and services complete transactions elsewhere while preserving targeted protections for users. This chapter examines how that boundary works in practice: where a user may be sent, what a developer still needs from a payment provider, how the choice should appear, and why the CMA treats WebViews and child protections differently. The goal is to judge whether the proposed route is both usable and appropriately safeguarded.
The distinction matters because the alternative is a journey, not a destination. A developer-controlled website may host the offer, but another company may process the payment. A link may be allowed, but an interstitial or an extra step may change whether users follow it. A safety notice may inform a user, or it may discourage them. The CMA’s design choices are attempts to preserve the competitive value of steering without treating every external transaction as identical or every risk as a reason to close the route.
A bounded destination can still open competition
The proposed requirement focuses on steering for a particular purpose: directing an end-user outside Apple’s in-app purchase environment to complete a transaction for a digital good or service. That focus is narrower than a general right to send a user anywhere on the web. The CMA says it has seen limited benefits in allowing links for purposes other than completing transactions and has identified possible security and privacy concerns in doing so. Its provisional approach is therefore to protect the link when it addresses the competition problem—an alternative way to complete a purchase—while leaving Apple room to restrict other kinds of redirection.
This is a question of fit between the remedy and the harm. If the concern is that Apple prevents a developer from presenting and completing a cheaper or more flexible purchase option, the rule need not also require Apple to facilitate every unrelated external activity. A targeted scope can reduce unnecessary exposure to risks that are not needed for the competitive objective. But targeting must not be defined so narrowly that the route becomes unusable. The transaction usually requires an offer page, account continuity, payment processing, and some way to confirm what the user bought.
The CMA provisionally considers that Apple could require the link to direct the user to a website owned, operated, or controlled by the relevant developer. This boundary addresses Apple’s concern that a developer should remain accountable for the commercial environment to which its app sends a user. It also makes the route easier for a user to understand: the app and the external offer are still connected to the developer whose service they chose.
That boundary does not mean the developer must process every payment itself. The CMA says the proposed approach should not impose additional restrictions that prevent legitimate third-party payment providers from being used through the developer’s website. A payment provider may supply the checkout technology, handle payment information, or provide other regulated services while the developer controls the offer and customer relationship. A merchant-of-record service may also take on financial and legal responsibility for the sale. Separating these roles is important because control of the offer environment and control of the payment infrastructure are not the same thing.
A simple example shows why.