Apple’s IP Pretext

Apple takes 30% of most digital transactions on the iPhone. When asked to justify this, Apple doesn’t say “because we can,” which I think is closest to the real answer. Apple says it’s compensation for intellectual property.

It sounds almost reasonable. Apple built the platform. Apple made the tools. Shouldn’t Apple get a cut?

The problem is that the claim is empty. A real IP license identifies what IP is being licensed and what conduct would infringe that IP absent the license. Apple has never done either. And when you try to figure out what Apple could mean, every candidate theory falls apart.

What exactly would be infringing?

An IP license is permission granted for conduct that would otherwise be unlawful.¹ If you want to put a song in your movie, you need the songwriter’s permission because using the song without permission would be copyright infringement. If you want to manufacture a patented invention, you need the patent holder’s permission because making the thing without a license would be patent infringement.

A real IP license also identifies what’s being licensed. A patent license lists the patent numbers. A copyright license identifies the work. A trademark license specifies the marks.

What does Apple’s license actually grant? The Developer Program License Agreement does identify specific software. Section 1.2 defines “Apple Software” as “Apple SDKs, iOS, watchOS, tvOS, iPadOS, visionOS and/or macOS, the Provisioning Profiles, FPS SDK, FPS Deployment Package and any other software that Apple provides to You under the Program.” The “Apple SDKs” are further defined as the Software Development Kits “including but not limited to header files, APIs, libraries, simulators, and software (source code and object code)” in the Xcode package.

So the DPLA is a real software license for identified software—Xcode, the SDKs, iOS itself. Section 2.1 grants “a limited, non-exclusive, personal, revocable, non-sublicensable and non-transferable license” to use this software for developing and testing apps. And Section 8 specifies the fee for this license: $99 per year.

The 30% commission isn’t in the main agreement at all. It appears in Schedule 2 (for paid apps) and Schedule 3 (for custom apps), which govern App Store distribution. The 30% isn’t compensation for using Xcode or the SDKs: a developer has already paid $99 for that. The 30% is compensation for access to Apple’s distribution channel. Apple has simply framed this distribution toll as something like an IP license fee without identifying any additional IP being licensed beyond what the $99 already covers.

You can read Tim Cook’s 2020 congressional testimony for an example of this framing. Cook speaks of Apple’s “investment” in software and security. But investment isn’t the same as a licensable IP right.

The 30% isn’t compensation for permission to do something that would otherwise be prohibited. It’s a toll Apple can extract because it controls the only distribution channel.

Nevertheless it might be useful to walk through what Apple’s fees are allegedly compensation for, from a perspective (mine) that doesn’t just view IP as a vague buzzword or rallying cry.

The code inside an app?

One possible theory is that developers are distributing Apple’s code when they ship an app. This is wrong, but it requires some technical background to explain why.

When a developer writes an iOS app, the app needs to interact with the iPhone’s operating system. It needs to display things on the screen, respond to touches, connect to the network, and so on. The operating system provides these capabilities through “frameworks”–collections of pre-written code that handle common tasks.

There are two ways an app can use a framework: static linking and dynamic linking. With static linking, the framework’s code is copied into the app itself. The app becomes a single self-contained package that includes everything it needs. With dynamic linking, the app just contains references to the framework. When the app runs, it loads the framework code from the operating system.

Modern iOS apps use dynamic linking for all core Apple frameworks (UIKit, Foundation, SwiftUI, and so on). These frameworks live on the iPhone’s operating system partition, not inside the app bundle. When you download an app from the App Store, you’re not downloading a copy of UIKit. UIKit is already on your phone. The app just tells the phone: “When I need to display a button, use the UIKit code you already have.”

The developer’s app bundle doesn’t contain Apple’s proprietary code. The developer isn’t “distributing” Apple’s software. The developer is writing new software that, when it runs, talks to software the user already owns. (Just a separate note, yes, if users own their iPhones, they “own” a copy of iOS in exactly the same sense that you can own a DVD or an NES cartridge. Software companies don’t like to admit this because pretending that you can “license” physical copies, as opposed to actual IP rights, gives them more legal tools–tools they should not have. That’s a different topic though.)

Even if some small amount of “glue code” is statically linked, that’s a functional byproduct of using a compiler. Any code required to make an app run on an iPhone is code that Apple has already licensed (or sold!) to the end-user as part of the operating system.

Google v. Oracle

Some readers may think of Google v. Oracle., the 2021 Supreme Court case about Java APIs. The Supreme Court held (6-2) that Google’s use of Java’s API structure was fair use as a matter of law, which does imply a copyright interest to begin with. (I wrote about this case when the Supreme Court took it up and when it was decided.)

Good news for developers. But the case doesn’t help Apple’s argument. Google v. Oracle was about re-implementing an API: Google copied Oracle’s API structure to build a competing platform. The court held that this is an IP-triggering event, but that it was allowed under the fair use doctrine. That’s a different question from whether calling an API, using it as intended, requires any license at all.

Apple’s developers aren’t not copying Apple’s API structure at all. They’re calling APIs on a device the user already owns, using those APIs exactly as Apple intended. This doesn’t implicate the reproduction right, the distribution right, or the public performance right. The user already owns a licensed copy of iOS. The developer is writing instructions that tell the user’s copy of iOS to do things. There’s no copying of Apple’s code involved. This isn’t a fair use question because there’s no use that requires fair use analysis in the first place.²

Apple’s developer tools

Apple does create various software tools for developers–these are mentioned in the DPLA and in principle can carry with them various license terms. But Apple should not be able to put extractive terms on tools that Apple itself has made essential for app distribution. Apple chose to make Xcode and the Developer Portal the only path to the App Store. Having created this chokepoint, Apple can’t then claim that using these tools creates an IP licensing obligation. Apple manufactures the dependency, then charges for it.

Swift is Apple’s primary programming language for iOS apps. It’s open-source under the Apache 2.0 license, with a Runtime Library Exception. You can read the license on swift.org. The exception is explicit: “if you use this Software to compile your source code and portions of this Software are embedded into the binary product as a result, you may redistribute such product without providing attribution.” In plain English: you can use Swift to build commercial software and owe Apple nothing.

The Swift compiler–the program that translates code that programmers write to machine code computers understand–is built on LLVM, an open-source compiler infrastructure also licensed under Apache 2.0 with a similar exception. LLVM’s license states: “if, as a result of your compiling your source code, portions of this Software are embedded into an Object form of such source code, you may redistribute such embedded portions in such Object form without complying with the conditions of Sections 4(a), 4(b) and 4(d) of the License.” Both licenses were specifically designed so that compiled applications carry no licensing obligations back to Apple or the LLVM project.

Xcode is Apple’s Integrated Development Environment–a complicated Mac app for creating software for Apple’s platforms. Xcode is proprietary, and I’m not claiming that Apple has no right to put conditions on its use. Xcode bundles the Swift compiler together with a graphical interface, debugging tools, a simulator, and various conveniences. But the core act of compilation doesn’t require Xcode. A developer could, in principle, write an iOS app using any text editor and compile it using the open-source Swift toolchain. (In fact it’s almost trivially easy to do this today, with AI tools like Claude Code and Gemini CLI.)

So what proprietary Apple software must a developer use to create an iOS app? The answer is: none, for creating the app itself. The programming language is open source. The compiler is open source. A developer writing an iOS app isn’t “using Apple’s IP” in any way that triggers a licensing obligation–until they want to distribute through Apple’s App Store, at which point they need code signing and access to Apple’s distribution infrastructure.

If a writer uses Microsoft Word to write a novel, Microsoft doesn’t claim 30% of the royalties. If a musician uses Pro Tools to record an album, Avid doesn’t claim a cut of streaming revenue. Apple’s claim to a percentage of revenue from apps built with Xcode is unprecedented in the history of creative tools. (If there are any precedents, then they suck too.) During the 1990s antitrust era, even Microsoft at its most aggressive never suggested it was entitled to a percentage of the revenue of every program that ran on Windows.

The only “Apple IP” developers are forced to use are the Developer Portal and code-signing services (which can include Xcode, for submitting builds to Apple). Code-signing is a process by which Apple cryptographically verifies that an app was built by a registered developer. This is a security feature that primarily benefits Apple’s users, making its platforms more valuable to them, and thus to Apple. These services are not creative contributions–and they’re a thin reed to hang the 30% revenue cut on.

I’ll grant that Apple has built a secure, high-trust environment that attracts customers willing to spend money. But Apple already monetizes this trust through the hardware price tag (iPhones aren’t cheap) and the $99 annual developer fee.

Who needs whom?

To be fair to Apple, when executives talk about “intellectual property,” they probably don’t mean it in the strict legal sense. They’re likely referring to Apple’s general investment in iOS, its hardware platforms, its developer tools, its retail presence, its brand. Apple has spent billions building an ecosystem. Executives want to convey that developers benefit from this ecosystem and should pay for access.

I find this framing annoying. “Intellectual property” has a specific legal meaning. Patents, copyrights, trademarks, and (maybe) trade secrets. When a company uses “IP” as shorthand for “all the stuff we spent money on,” it obscures the question of what legal rights are actually at stake. It lets Apple imply that developers owe a license fee without specifying what they’re licensing. If Apple means “we invested a lot and want a return,” it should say just that, without triggering copyright nerds like me.

But set that aside. Grant Apple the most charitable interpretation: the 30% is compensation for the general value of the iOS ecosystem. There are still problems with this.

Apple already earns a return on its investment. It is worth over three trillion dollars. It sells iPhones at a substantial margin. It charges $99 per year for developer program membership. It sells iCloud storage, Apple Music subscriptions, AppleCare, and accessories. The notion that Apple needs an additional 30% of every third-party digital transaction to recoup its R&D spending is not credible. Apple’s hardware business alone generates hundreds of billions in revenue. The ecosystem investment has been repaid many times over.

Also: the value of the ecosystem comes largely from the developers themselves. An iPhone without apps is an expensive phone that can browse the web. The App Store has two million apps because two million developers chose to build for iOS. Those developers created the software that makes the iPhone worth buying.

Apple likes to cite the $1.3 trillion in economic activity facilitated by the App Store. More than 90% of that value comes from physical goods and services (Uber, Amazon, Target) and advertising, where Apple takes zero commission. Only about $131 billion in digital goods and services falls into the 30% bucket.

If Apple’s investment is what enables the commerce, why is a digital sword in Fortnite taxed at 30% while a physical sword sold on eBay is taxed at 0%? Both transactions use the same iOS APIs. Both run on the same hardware. The difference is that Apple has figured out a way to insert itself into digital transactions, and hasn’t (yet?) figured out a way to insert itself into physical ones.

The Mac is right there

Apple’s own Mac platform is the clearest refutation of the IP argument. The Mac uses the same general “intellectual property” as iOS: If you accept Apple’s premise that iOS developers owe 30% for the privilege of using Apple’s IP, Mac developers should owe 30% too.

But Mac developers owe nothing, unless they choose to use the Mac app store. A developer can write a Mac app using Swift and Xcode, compile it, notarize it through Apple’s security system, and distribute it directly from their own website. The developer uses all the same Apple “IP” and pays Apple zero percent of their revenue.

The only difference is that Apple can’t force Mac developers to use the Mac App Store. On the Mac, alternative distribution exists. Developers can choose. And when given the choice, most developers choose not to pay Apple 30%.

Apple / Epic

The Epic v. Apple litigation is where Apple’s IP theory first became prominent. The quotations below are from the trial transcript.

Cook testified under oath about the relationship between in-app purchase and Apple’s commission. One important exchange came when Apple’s own lawyer asked whether developers would still owe a commission if there were no IAP. Cook’s answer: “Yes, of course.”

When asked “What is IAP’s role with respect to the commission?”, Cook answered: “IAP helps Apple efficiently collect the commission. The commission is for a number of different things, from developer tools to the APIs and to the customer service that’s provided.” Later in his testimony, Cook was more direct: “I strongly believe that IAP is the most efficient way to collect it because you would then have to figure out how to track what’s going on and invoice it and then chase the developer.”

Judge Gonzalez Rogers pressed Cook on why Apple prohibits developers from telling users they can buy elsewhere. Cook’s answer: “If we allowed people to link out like that, we would in essence give up the–our total return on our IP.”

The judge was skeptical. She observed that gaming “seems to be generating a disproportionate amount of money relative to the IP that you’re giving them and everybody else. In a sense, it’s almost as if they’re subsidizing everybody else.” When Cook said customers could choose Android if they didn’t like Apple’s terms, the judge replied: “You don’t have competition in those in-app purchases, though.”

The linked-out purchase scenario clarifies what the IP argument was always about. When a user taps a link, leaves the app, and completes a purchase on the developer’s own website using the developer’s own payment processor, Apple has no further involvement in the transaction. Apple isn’t processing the payment, or providing fraud protection or customer service. Yet Apple claims a commission anyway (27% in its post-injunction “compliance” scheme). If the justification for the fee were the services Apple provides through in-app purchase, there would be no fee here. But Apple’s position is that the fee is for amorphous “IP,” which justifies a toll regardless of whether Apple does anything at all.

In the original September 2021 district court ruling, Judge Gonzalez Rogers found that Apple’s anti-steering provisions violated California’s Unfair Competition Law by preventing informed consumer choice. While Apple prevailed on nine of ten counts, the court permanently enjoined Apple “from prohibiting developers from . . . including in their apps and their metadata buttons, external links, or other calls to action that direct customers to purchasing mechanisms” outside the App Store. The Ninth Circuit affirmed in April 2023, upholding the injunction.

Apple then implemented what it called compliance: a 27% commission on linked-out purchases and a set of restrictions designed to make external payment options unusable. In the April 2025 contempt order, Judge Gonzalez Rogers found Apple in civil contempt. Her summary:

One, after trial, the Court found that Apple’s 30 percent commission “allowed it to reap supracompetitive operating margins” and was not tied to the value of its intellectual property, and thus, was anticompetitive. Apple’s response: charge a 27 percent commission (again tied to nothing) on off-app purchases, where it had previously charged nothing.

The court found that Apple had “willfully chose to ignore the Injunction, willfully chose to create and impose another supracompetitive rate and new restrictions, and thus willfully violated the Injunction.” Apple’s purported security and privacy justifications were “pretextual.” But notice she implicitly buys into the idea that Apple has a free-floating right to charge for the “value of its intellectual property,” without reference to what specific intellectual property rights are in question.

The Ninth Circuit’s December 2025 opinion affirmed the contempt finding but modified the remedies. While agreeing that “Apple did not charge any commission; it charged a prohibitive commission,” the court held that the district court’s blanket ban on all commissions was overbroad. It accepted Apple’s argument that Apple is “entitled to some compensation for the use of its intellectual property that is directly used in permitting Epic and others to consummate linked-out purchases.”

This is disappointing. The Ninth Circuit accepted Apple’s framing without requiring Apple to identify what intellectual property is being licensed or grappling with the implications of Apple’s view of the world. At least the court rejected Apple’s nonsensical “takings” argument, though not on the grounds that I would have preferred, that nothing has been “taken” from Apple other than its ability to violate the law.

Final thoughts

Apple shouldn’t be permitted to extract rents from developers based on hand-wavy claims about “intellectual property” that have no technical or legal foundation and are unjustifiable on their merits.

But Apple does provide real services that have real value. In-app purchase handles payment processing, currency conversion, fraud detection, and chargebacks. The App Store provides distribution, discovery, and a degree of trust. Xcode and the SDKs reduce the cost of development. These aren’t nothing.

The problem isn’t that Apple offers these services. The problem is that Apple bundles them together, makes them mandatory, and charges a single non-negotiable fee for the package. A developer who wants App Store distribution but not Apple’s payment processing can’t opt out. A iPhone developer who wants to use Xcode but distribute independently can’t do so. If Apple unbundled its services and let developers choose, the market would sort out what each service is worth. In-app purchase would have to compete with Stripe, PayPal, and direct credit card processing. The App Store would have to compete with alternative stores and direct distribution. Developers who valued these services would pay for them. Developers who didn’t would go elsewhere.

This is how markets work. Just not the App Store.

You can charge for a license, and convey a license in a contract, but a license is not a contract. Unlike a contract, for instance, a license can just be one-way, with no reciprocal “consideration.” A songwriter or patent holder may charge a fee for granting that permission, but the license is the permission itself, not the payment. Most lawyers and judges don’t bother making this distinction, and approximately zero non-lawyers do, but it’s useful.↩︎
There’s a distinction between local APIs (which run on the user’s device at zero marginal cost to Apple) and cloud APIs like iCloud or server-side AI (which consume Apple’s resources and might justify some fee). But cloud APIs are optional, or should be: many developers don’t use them and would happily forgo them to escape the 30%.↩︎