Why Developers Still May Not Steer
For Apple’s App Store, a newly available steering route passes through several states before it becomes a real business channel. A developer must first have the capability to operate outside IAP, then decide whether the route is worth building, test how users respond, and determine whether adoption should expand or stop. This chapter follows that lifecycle so readers can distinguish a legal opening from an operating capability, an operating capability from adoption, and adoption from a competitive effect.
That distinction matters because developers do not make the decision from the fee alone. They weigh payment and support work, customer experience, conversion, the size of their business, and the uncertainty created by different rules in different markets. The CMA’s evidence from the United States and the European Union offers useful observations, but it does not support a universal forecast of behavior. It is evidence about decisions under particular rules and at particular moments.
From permission to capability
The starting state is simple: under the restrictive arrangement described by the CMA, a developer of digital goods or services cannot generally use an external route inside the App Store app. The developer may have a website or already sell through the web, but the app cannot freely connect the user to that offer or use another payment system for the in-app transaction. In this state, the decision to steer is not available, so there is no adoption choice to measure.
A rule change creates a new state, but not yet a new capability. Once steering is permitted, a developer has to assess what it can actually operate. The CMA identifies several possible requirements: a website or offer environment, payment processing, merchant-of-record services, customer support, refunds, and the technical work needed to connect the app to the external route. These responsibilities may be provided by the developer, by a payment provider, or by another specialist, but someone must own them.
The first distinction is between fixed and variable cost. Fixed cost is the work needed to make the route available: updating the app, creating a checkout journey, and connecting the payment route. Variable cost grows with use: payment charges, support, refund handling, fraud controls, and the operational work of serving more external transactions. A developer that already runs a web business may have most of this capability. A developer whose activity has been concentrated inside IAP may need to create it.
This difference changes the threshold for adoption. A large developer may spread a fixed investment across a substantial customer base or already have a payment and support operation. The CMA records evidence that the fixed cost of adoption could be low or zero for some large developers because they already provide many of the required services. That does not make steering automatically attractive. The developer may still face conversion risk, technical complexity, and the cost of maintaining two routes.
A smaller developer can face the same nominal opportunity under worse conditions. If the business sells fewer digital products, a fixed setup cost is spread across fewer transactions. If margins are tight, a lower fee may not compensate for the work of managing payments, refunds, or customer support. The developer may also be less able to cross-subsidize a digital service with another business line. The relevant issue is not whether a small business is legally allowed to steer. It is whether the business can sustain the capability long enough for users to adopt it.
The user’s experience enters before the first external transaction.