The Customer Relationship Apple Sits Between
The Apple App Store does more than deliver an app to a phone. It sits between a developer and the people who use, pay for, and need help with that app. This chapter traces the control points along that relationship—distribution, communication, payment, and post-purchase service—so readers can see how a restriction at one point propagates into pricing, product design, customer information, and competition. The practical judgment is whether Apple’s rules leave a developer with a meaningful relationship of their own, or only with access on terms set by the gateway.
The distinction matters because digital products do not end when someone downloads them. A subscription may need renewal and cancellation. A game may sell continuing digital content. A service may need to answer questions, correct a billing problem, or tailor an offer. The business that built the product normally has reasons to understand those interactions directly. If another company controls the route through which the offer is presented and paid for, the developer can lose more than a percentage of revenue.
The CMA’s consultation describes the relationship as a chain rather than a single payment event. Its account is focused on digital goods and services sold through the App Store. That boundary is important: apps selling physical goods and services are subject to different terms, and the consultation says they can generally choose their own payment processor, link outside the app, and pay no commission. The analysis here concerns the more restrictive digital-goods arrangement.
Where control enters the journey
The first control point is access. A developer can write and operate an app, but an iPhone or iPad user generally encounters the native version through Apple’s App Store. The CMA describes the store as a vital gateway used by businesses in many sectors, including retail, finance, fitness, gaming, and financial technology. It reports the earlier finding that developers distributing digital content and services need Apple’s Mobile Platform to reach a large and distinct user base.
That fact changes the meaning of a distribution rule. A developer is not choosing between two equally convenient shops when one route reaches a user base that is difficult to replace. The App Store’s value to a developer comes partly from reach; the range of apps, in turn, helps make Apple’s device ecosystem valuable to users. Each side contributes to the other side’s reason to remain. A developer may disagree with a term and still conclude that refusing it would cost too much access.
The CMA gives UK scale ranges for 2024: approximately 1–2 million apps on the App Store, 0–1 million developers distributing through it, and 20–30 million users downloading a native app each month. It also reports annual UK spending on digital products and services in a redacted range of £0–5 billion. These figures are not precise counts, and the consultation’s references to the earlier Strategic Market Status decision are not a substitute for reading that decision in full. They nevertheless show why a rule applying to Apple’s App Store can shape the choices of a large population of businesses and users.
The second control point is communication. According to the CMA, developers of digital goods and services are generally not allowed to put a button, link, or information in the App Store app that directs an end-user to an offer available elsewhere. This is easy to underestimate because the restriction may look like a small interface rule. In practice, it governs what a developer can tell a customer at the moment when the customer is deciding whether and where to buy.
Suppose a subscription service has a website where it can offer a different price or manage an account across devices. If the app cannot tell an iPhone user that the offer exists, the website is not a genuine alternative for that user. The developer may have a second commercial channel in the abstract, but cannot connect the person already using the app to it. The communication rule protects the existing route from comparison before the payment question is even reached.
The third control point is transaction processing. The CMA says those developers are generally not allowed to sell and process payments for digital goods and services through another system inside the app. Instead, Apple’s In-App Purchase system is the required route. Apple’s role can extend beyond moving money: the consultation explains that when IAP is used, Apple acts as the merchant of record, taking financial and legal responsibility for the sale from the developer.
This arrangement can provide a service. A developer may not need to build every payment, billing, or transaction-support function from scratch. But the same arrangement also determines which payment providers can compete, how the sale is recorded, and who stands between the developer and the customer. The CMA records evidence that Apple’s rules exclude alternative payment processors and merchant-of-record services from offering services that could compete with Apple’s billing system. The question is therefore not whether Apple performs a useful function. It is whether the developer can choose another function when the benefits, costs, or customer relationship make that choice important.
These control points are connected. A ban on outside communication makes it harder to move a customer to another route. A ban on another payment system makes it harder to act on a cheaper or more flexible offer even when the customer knows it exists. The combination gives Apple influence over both the message and the transaction.
What crosses the boundary after purchase
A purchase creates an ongoing relationship. The developer may need to explain a charge, respond to a cancellation request, restore access, or decide how to change the product. Under the arrangement described by the CMA, Apple can manage important parts of that interaction while the developer remains the party whose product the customer believes they are buying.
The consultation records evidence from developers that restrictions on steering prevent them from developing direct relationships with their customers. One UK-based social-media developer described in the document said it could not help users with cancellations or refunds because Apple’s restrictions left it without a direct relationship. The developer said this harmed customers and caused reputational damage. This is a reported business case, not proof that every app experiences the same result, but it makes the mechanism concrete: responsibility for the user’s experience can remain with the developer even when control over the transaction does not.
Customer information is part of the same boundary. The CMA says developers may have limited access to information such as customer demographics or tax information, while Apple can manage the relationship and gather data from customers. Less information can weaken several ordinary business functions. A developer may find it harder to understand who is buying, to identify where an offer is failing, to coordinate support across platforms, or to personalize a service. It may also have less say in whether a refund is granted or how a problem is resolved.
This does not mean that direct control automatically produces good decisions. More customer data can create privacy responsibilities, and a developer may not use information well. The relevant point is control over feedback. A business that can hear from customers, observe how offers perform, and handle support can adapt. A business that receives only an indirect or incomplete signal may be less able to improve the product or respond to a problem. The dependence is relational because it affects the flow of knowledge as well as the flow of money.
The effects can reach product design. The CMA records evidence that developers’ choices about what to sell, how to price it, and how to distribute it can be limited. Developers cited possible impacts on innovation, including combining digital and physical services, integrating customer support across platforms, and increasing personalization. These are not guaranteed effects of every restriction; they are examples of opportunities that may become harder or less attractive when the developer cannot choose the commercial structure around its app.
Consider a service that wants one account to work across a mobile app and a website. The technical account may be possible, but the commercial relationship still matters. If a customer joins through one route, pays through another, and needs support from a third party, responsibility becomes fragmented. A developer may prefer to provide one consistent system for billing and support, while Apple’s rules determine which part of that system can operate inside the app. The result is not necessarily a visible failure on any one screen. It is a loss of freedom to design the service as a whole.
The fourth consequence is competitive. The CMA records concerns that developers competing with Apple’s own first-party apps may be weakened by having to pay a commission and by being unable to direct users to a lower-cost distribution channel. A rival’s headline price, feature investment, or customer support budget may be affected by the combined loss of margin and control. The rival is not merely paying for a neutral service; it may be paying the operator of an ecosystem in which the operator also offers competing products.
The CMA says Apple’s headline commission for digital goods and services is 30% and that the average rate remains close to that headline figure. A 30% charge is plainly relevant to a developer’s economics, but its competitive importance grows when it is joined to the communication restriction. If the developer could tell users about a cheaper route, the customer might compare the price. If the developer could use another payment processor, the business could choose a different cost or service model. When both options are restricted, the commission is insulated from the pressure that comparison would create.
The same logic applies to payment providers. A competing processor cannot win a transaction merely by offering a better technical service if the app’s rules prevent the developer from using or promoting it. A merchant-of-record provider cannot compete for a role that Apple reserves to itself. The effect is not only that one developer pays more. Potential rivals are denied a way to test whether they could provide better terms.
There can also be effects below the named developer. Some developers operate platforms for creators or smaller businesses. The CMA says developers told it that lower costs could be passed on to end-users or used to increase investment or payouts to other businesses. This is a provisional benefit theory, not a measured universal outcome. It shows, however, why a change in the App Store relationship could travel through a wider commercial network: the immediate payer may not be the only person affected by the retained revenue or lost flexibility.
Why the system matters more than any single restriction
It is tempting to ask which rule is the “real” problem: the commission, the payment mandate, or the ban on outside links. The system view gives a more useful answer. Each rule controls a different interface between Apple and the developer, but the interfaces reinforce one another.
Distribution determines whether the developer can reach the user at scale. Communication determines whether the developer can present an alternative at the point of decision. Payment rules determine whether the alternative can be completed and which provider can serve it. Billing, refunds, and support determine who manages the relationship afterward. Customer information determines how much feedback the developer receives. Pricing and margin determine what the developer can invest in and how strongly it can compete with Apple or other businesses.
A restriction at one interface can therefore increase the value of control at the next. If a developer cannot communicate an outside offer, Apple’s payment route faces less comparison. If the developer cannot choose another processor, Apple’s transaction role remains tied to the customer relationship. If the developer has less information or refund control, it may be less able to compensate users for a poor experience through its own support. The result is a form of dependence that does not appear in the commission alone.
The physical-goods boundary helps test this explanation. The CMA says an app selling groceries or rides can generally use its own payment processor and link to information outside the app without paying a commission. That does not prove that digital-goods rules are unjustified, and digital transactions may raise different questions about delivery, access, or platform protections. It does show that Apple’s ecosystem can operate with alternative payment arrangements and external links in some contexts. The claim that a mobile app must always keep payment and communication inside Apple’s system is too broad.
The CMA’s proposed Steering conduct requirement is aimed at this connected structure. Its stated objective is to give developers meaningful choices about communicating with end-users and directing them to channels outside Apple’s app-store ecosystem, while allowing users to make informed decisions between purchasing options. In the CMA’s account, effective steering could help developers manage billing, refunds, support, pricing, offers, and payment processing more directly. It could also create pressure between Apple and third-party providers and, over time, on wider App Store commissions.
That proposal remains provisional, and it does not assume that every developer should abandon IAP. Some businesses may value Apple’s integrated services. Some users may prefer the protections or familiarity of Apple’s system. A developer might also decide that operating its own payment and support functions costs more than it saves. Meaningful choice means having a credible option, not being forced to use it.
The next issue follows directly from this map. If Apple is allowed to say that steering exists while making the link difficult to find, expensive to use, or risky to implement, the relationship may remain substantially unchanged. A real alternative must cross all the relevant boundaries—not just the payment boundary—and the conditions of that crossing will determine whether the customer relationship can become contestable.