Why a Link Is Not the Same as a Choice
In Apple’s App Store, the difference between a permitted link and a usable alternative is the difference between formal access and real competition. This chapter examines the specific question behind the CMA’s proposed Steering conduct requirement: what could still make an external purchasing route unattractive after Apple no longer bans it outright? The answer helps readers judge a steering rule by its full mechanism—who can communicate, which links work, how the option is presented, what friction is added, and where security controls are justified.
“Steering” is the term used for information or a link inside an app that directs an end-user to another place, such as a developer’s website, to complete a transaction. The phrase can sound like a small interface feature. For a developer selling digital goods or services, however, it is a bridge between the App Store’s audience and a different commercial relationship. If the bridge is technically weak, commercially unattractive, or presented as a warning rather than an option, the customer may never cross it.
The CMA’s proposal is provisional. Its importance here is not that it settles the UK policy question, but that it identifies the layers a remedy must address if steering is meant to change Apple’s position in the customer journey.
Permission can be neutralized
The CMA says that removing restrictions on steering alone would not be enough. Apple could still impose conditions that frustrate the purpose of the opening: complicated design requirements, restrictive technical rules, commercially unattractive terms, or enforcement practices that discourage developers from using the option. A developer would then face a familiar business calculation. Building and supporting an external route costs time and money. If Apple makes the route hard to find or less effective than IAP, the developer may conclude that the investment is not worthwhile. If few developers use the route, users will encounter it less often and gain less confidence in it. Low adoption then becomes evidence that the alternative is weak, even if the formal right remains on the books.
This is a feedback loop, not a single prohibited act. The platform does not need to say “no external payment” in one sentence if its review process rejects the relevant interface, its technical rules prevent the necessary link, or its commercial terms absorb the benefit. A rule that examines only the wording of the ban can miss the ways in which a gatekeeper shapes conduct through implementation.
The proposed UK requirement therefore reaches an action or omission by Apple whether it is direct or indirect. The CMA lists contractual terms, technical design requirements, app review processes, enforcement practices, and other measures. The point is not to turn every App Store decision into a regulatory dispute. It is to recognize that a platform controls several interfaces at once, and that each interface can affect whether a developer can exercise the right that the rule is supposed to create.
Consider a hypothetical subscription app. Under a formal permission, the app might be allowed to mention a website. But if the mention cannot include a usable button, if the link cannot reflect the customer’s selected plan, if the user must pass through several extra screens, or if the developer is charged a fee that leaves no meaningful saving, the permission changes little. The app has technically communicated an alternative, but the customer journey still favors Apple’s route.
The CMA’s proposed framework responds by describing the redirection mechanism itself. It would prevent Apple from restricting a developer’s ability to communicate with an end-user or include a feature that redirects the user to an external website to complete a steered transaction. The proposal includes an important exception: Apple could restrict such conduct where the restriction is strictly necessary for an objectively justifiable purpose such as preventing malware, fraud, unlawful content, or content harmful to children. That is a bounded safety exception, not a general authority to make external routes less attractive.
The distinction matters because “necessary” and “convenient” are not the same. A restriction may make a platform’s review or design process easier without being necessary to prevent a specific harm. Conversely, a targeted restriction on a known malicious destination could protect users without disabling legitimate steering more broadly. The CMA’s proposed language tries to keep those cases apart, although the practical application would still depend on evidence about the risk and the effect of the restriction.
There is also a difference between the developer’s destination and the payment provider’s role. The CMA provisionally considers that Apple could require a steering link to direct the user to a website owned, operated, or controlled by the relevant developer. It does not intend that boundary to prevent a legitimate third-party payment provider from serving the transaction through that website. A developer-controlled offer environment can therefore coexist with payment infrastructure supplied by another business. This preserves some accountability over where the user is sent without reserving every part of the transaction to Apple.
The sequence shows why the link cannot be evaluated in isolation. It must survive platform rules before the user sees it, provide enough context to complete the transaction, and lead to a relationship that someone can support afterward. A failure at any step can preserve dependence while leaving the word “steering” technically present.
What makes an external route functional?
One issue is the information carried by the link. The CMA discusses dynamic links: links generated according to a user’s transaction, context, or selected product. It also discusses link parameters, which can pass user-authorized information to the destination, including information needed for seamless login or continuity between the app and the transaction. These features are not decorative engineering choices. They can determine whether the user reaches the right offer, remains associated with the correct account, and can complete a purchase without starting again from an unfamiliar page.
Imagine two versions of an external route. The first sends every user to a generic home page. The user must find the product again, identify the right subscription, sign in, and work out whether the price applies to them. The second takes the user to the relevant offer with the context they authorized for the transaction. The second route may be materially easier to use and easier for the developer to measure. If platform rules allow only the first version, the alternative can be legal yet commercially weak.
Apple argues that these capabilities create privacy and security risks. A dynamic link may resolve to different destinations depending on the user’s context, making it difficult for Apple to review every possible outcome. Link parameters may pass information from the app to a website, while the user sees only a domain in the browser and may not know what information has been transferred. Apple also argues that changing web content can evade a review performed at an earlier time. These are concrete concerns about information flow and changing destinations, not merely an assertion that competition is undesirable.
The CMA’s provisional response is that broad restrictions may bring limited additional protection. It notes that dynamic links and link parameters are already used in analogous parts of the App Store ecosystem, including apps that sell physical goods or direct users to external websites. It also reasons that some restrictions could be circumvented: information could be collected in the app or on the destination without being placed in the link, and developers could connect app and web accounts through other methods. If a restriction is easy to work around, it may impose friction on legitimate developers without removing the underlying privacy risk.
That reasoning does not establish that dynamic links are harmless. It makes a narrower claim about proportionality: the incremental protection produced by a broad ban may be small compared with the damage to a usable steering route. The CMA says Apple could pursue less disruptive mitigations, such as requiring developers to integrate interfaces that identify where users are being steered in practice. Whether such a measure would work would depend on its design, data access, and burden. The key principle is to target a demonstrated risk rather than use the existence of risk to preserve every existing restriction.
Presentation is another functional condition. The proposal would require an end-user redirection mechanism used for a steered transaction to be presented, accessed, and used in the same or an equivalent way to Apple’s IAP system. This does not necessarily mean the two options must look identical. It means Apple could not give its own route a privileged position through size, prominence, number of steps, or interaction design while technically allowing an external one.
The proposed approach would allow Apple to require side-by-side presentation of IAP and the steered option. That design keeps Apple’s payment system available for users who prefer its protections or familiarity, while allowing a user to compare alternatives at the moment of choice. The CMA says developers should have flexibility to communicate price differences and non-price benefits—such as promotional bonuses—where the user decides which option to use.
Point-of-choice information matters because users do not make decisions with a perfect record of every earlier screen. The CMA cites the risk that information shown on a prior page may not be recalled later, leaving users more likely to choose a familiar option by default. If the outside offer is cheaper or includes a different benefit, hiding that information until after the user has committed to IAP defeats comparison. A choice can be formally available and still be distorted by when the relevant facts are shown.
Friction operates in the same way. The proposed rule would bar additional steps, blocked price information, and warnings or disclosures whose language, formatting, or prominence discourages an external transaction. Apple could be allowed one interstitial screen—a screen shown while the user moves from the app to an external destination—but the CMA says it should contain only information strictly necessary to explain that the user is leaving Apple’s IAP system. It should use neutral language and visual design, have comparable prominence and interaction, and not be designed to scare the user away.
This is a difficult balance. Users may reasonably want to know who is processing a transaction and which protections apply. A developer may reasonably worry that an extra screen will cause users to abandon a purchase. The CMA records developer estimates of drop-off ranging from 5% to more than 60%, but also notes that these estimates were expectations or observations from other settings rather than robust tests of the exact steering scenario. The evidence supports concern about friction; it does not establish one universal abandonment rate.
The same point applies to WebViews, which allow web content to appear inside an app. Some developers told the CMA that a WebView could provide a smoother experience than opening a separate browser, with fewer steps and potentially better conversion. Apple raised concerns that a WebView may look like part of the app and confuse users about whether Apple’s protections still apply. The CMA provisionally decided that it was not necessary at this stage to require Apple to allow WebViews for steering because the available evidence did not show that banning them would materially reduce uptake. It also left room to review that decision as in-app browsing becomes more significant.
This is an example of evidence-calibrated regulation. The CMA did not need to declare WebViews either safe or essential. It asked whether the evidence justified imposing an obligation now. A future finding that external-browser journeys materially reduce adoption, or that neutral disclosure does not resolve confusion, could support a different conclusion.
The boundary between protection and deterrence
Security and privacy do not disappear when a user follows a link. The developer and the selected payment provider take on responsibilities that Apple’s integrated system previously handled or presented as central. A user may no longer receive Apple’s central refund protections or subscription-management services. Apple may have less ability to monitor a changing external website or see signals associated with fraud. Those are real changes in responsibility, and a fair account of steering must name them.
The question is how far those changes justify platform control. The CMA says Apple may retain app review and may introduce targeted protections for children. It provisionally supports stronger measures where the potential harm is particularly acute, including the possibility of preventing steering for children or on devices with parental controls. It is less persuaded by broad restrictions on link functionality that would reduce adoption while producing only limited incremental protection.
The proposal’s security exception is therefore tied to a purpose and a degree of necessity. Preventing a known malicious destination, unlawful content, or content harmful to children is different from making every external option less prominent because some external websites might be risky. The first is targeted risk management. The second can become a choice architecture that protects Apple’s transaction route from comparison.
The evidence remains contested. Apple says the App Store creates an expectation of safety and limits the number of parties receiving sensitive payment information. It says developers may use weaker privacy policies, that fraudsters can exploit changing web content, and that users may lose parental controls or other protections. The CMA reports these claims and acknowledges the residual loss of Apple’s refund and subscription systems. It provisionally considers that the proposed design can mitigate the risks, noting that external payment providers are subject to industry standards and regulatory oversight and that physical-goods apps already conduct external transactions under different App Store terms.
That last comparison is informative but limited. The fact that physical-goods transactions can use alternative payment methods shows that Apple’s ecosystem can accommodate them. It does not prove that every digital-goods transaction has the same risk profile or that every developer can provide the same level of support. Likewise, the CMA’s report that it found no robust evidence of observed privacy or security harm from enabling digital-content steering elsewhere is not evidence that harm is impossible. It is evidence about what the authority found in the material collected for this consultation.
The practical test is consequently not “Apple or the open web: which is safe?” It is whether a particular safeguard reduces a demonstrated risk more than it reduces the usefulness of the alternative, and whether the user can understand the change in responsibility. A neutral notice may inform without deterring. A targeted child restriction may protect a vulnerable group without closing the route for adults. A developer-controlled website may provide accountability while a regulated payment provider handles the transaction. The details matter because protection and deterrence can use the same interface.
This is also why price cannot be separated from design. If an external route shows no price comparison, requires more steps, and carries a warning that IAP does not, many users may stay with the familiar option even when the outside offer is better. The developer then sees low uptake and may stop investing in steering. Apple’s payment system remains the practical default, and the original dependence survives through user experience rather than an explicit ban.
A meaningful steering rule must therefore look beyond the existence of a link. It must ask whether Apple can limit the mechanism, what information the mechanism carries, how the options are presented, which safeguards are targeted and necessary, and whether the user can finish the alternative without unnecessary friction. The CMA’s proposal is built around that broader question. The next challenge is economic: even when a route is visible and usable, will its fee and operating burden leave a developer with enough reason to adopt it?