You have three doors, not one

Apple’s own “After You Submit” section names them separately, and they are separate games with separate counterparties.

Door 1 — Resolution Center in App Store Connect. This is a message to the review team about your submission. Same desk, roughly the sa…

Read more

I ran App Review at Apple for the better part of a decade. In that time I read a lot of appeal letters, and almost all of them made the same mistake. They argued that the developer was right.

Being right is not the winning move. It is barely a move at all.

What most developers never see is that App Review is not a compliance check, where a reviewer looks up your app in a rulebook and returns a verdict. It’s a game, in the formal sense. Two parties, incomplete information, asymmetric payoffs, played over and over. Once you can see the structure, a lot of behavior that looks arbitrary from the outside turns out to be the predictable output of the incentives in the room.

So let’s put the board on the table.

The reviewer’s payoff matrix is not symmetric

Start here, because everything else follows from it.

Picture the reviewer’s two ways to be wrong. They can approve an app that turns out to be a problem: a scam that hits the news, a kids’ app doing something it shouldn’t, a gambling product live in a state where it isn’t licensed. Or they can reject an app that should have shipped.

The first error is loud. It has a name attached to it, an incident review, sometimes a press cycle. The second error is nearly silent. It surfaces as an unhappy developer, and unhappy developers are routed to appeals, which is a different desk. From where the reviewer sits, the cost of a false rejection is externalized almost entirely onto you.

Now add the clock. Reviewers work a queue with throughput expectations. Every minute spent puzzling out what your app actually does is a minute not spent clearing that queue. Rejection is the cheap exit from ambiguity. It costs the reviewer thirty seconds and moves the burden of proof back across the table.

Put those together and you get the single most useful sentence I can give you: under uncertainty, the reviewer’s rational move is to reject. Not because anyone dislikes you or your app. Because the payoffs are lopsided and ambiguity is expensive.

This reframes the whole problem. You are not trying to win an argument. You are trying to remove uncertainty, because uncertainty is what’s generating the rejection in the first place.

Your notes are cheap talk

Game theorists have a precise term for a message that costs nothing to send: cheap talk. A cheap-talk message carries information only when the sender’s interests are aligned with the receiver’s. When they aren’t, and here they aren’t, because a bad actor wants approval exactly as much as you do, a rational receiver ignores it entirely.

“This app complies with 5.1.1.” Cheap talk. A non-compliant developer can type that sentence just as easily as you can. It transmits zero bits. The reviewer isn’t being stubborn when they skip past it; they’re being correct.

Michael Spence won a Nobel for the alternative. A costly signal works precisely because it is expensive for the wrong type of sender and cheap for the right one. That asymmetry is what makes it credible. And it’s what separates the appeals that work from the ones that die.

What that looks like in practice:

- A demo account that actually works, pre-seeded with real state. Not an empty shell. If your app is a marketplace, the account should have listings, history, a transaction to look at. Trivial for you. Genuinely hard for someone hiding something.

- A screen recording of the exact flow in question. Sixty seconds, no narration needed. You have collapsed the reviewer’s most expensive task, understanding your app, into the cheapest possible form.

- The actual document. Not “we’re licensed in these states.” The license, with the number, for the jurisdictions you claim.

- A written explanation of the thing that looks bad. If you have a feature that reads as a Guideline problem and isn’t, say so first, before they find it. Pre-empting scrutiny is expensive for a bad actor and free for you.

Every one of these is a costly signal. Together they create what economists call a separating equilibrium: a state where honest developers can distinguish themselves from dishonest ones at reasonable cost. Without them you’re stuck in the pooling equilibrium, indistinguishable from the worst app in the queue, and priced accordingly.

Which, if you want the uncomfortable version, is Akerlof’s market for lemons. Apple can’t cheaply tell your app from a bad one, so it discounts everything. The fraudsters set your review experience. That’s not Apple being hostile. That’s what an information problem does to a market.

The vagueness is the point

Every developer eventually runs into Guideline 4.3 on spam, or 4.2 on minimum functionality, and concludes that Apple’s rules are vague because Apple is sloppy.

They’re vague on purpose, and once you see why, you’ll stop trying to lawyer them.

A precisely specified rule is a rule you can engineer around. Every sharp line you draw gives an adversary a place to stand exactly one inch outside it, in full compliance, doing the thing the rule existed to stop. Apple is writing rules against a population that includes people optimizing full-time for the gap between the letter and the intent. Under those conditions, deliberate ambiguity is a commitment device. It preserves the discretion that makes enforcement credible.

So 4.3 is, by design, close to unfalsifiable. You cannot prove you aren’t spam. Arguing the text is playing a game you can’t win.

The move that does work is to clear the line by a visible margin. Don’t ask whether you’re technically inside 4.3. Ask whether a tired reviewer, twenty seconds in, could mistake you for the thing 4.3 exists to catch. Then move until they can’t.

It’s a repeated game, and Apple has a very long memory

The most expensive mistakes I saw came from developers treating submission as a one-shot game. Get it past review, then flip the server flag. Ship the compliant build, enable the real feature after approval.

In a one-shot game that’s rational. This is not a one-shot game.

Apple plays it millions of times and keeps records against your team ID. You’ll play it dozens of times. In repeated play, the folk theorem says cooperation becomes sustainable, but only because defection can be punished later. And Apple’s punishments are unusually credible: slower reviews, elevated scrutiny on everything you ship afterward, and at the far end, account termination. That last one costs Apple revenue, which is exactly what makes the threat believable.

One detected defection doesn’t just cost you that build. It updates the prior on every submission you make afterward. I’ve watched developers spend years paying interest on a single clever trick.

Precedent is a focal point

Reviewers, being human and being fast, pattern-match against what’s already live. Thomas Schelling would call the approved incumbents in your category a focal point: the solution everyone converges on absent explicit coordination.

This is enormously useful and almost nobody exploits it. Before you submit into a contested category, go study what the approved apps there actually did: how they describe themselves, what they put in the listing, which features they left out of the store build entirely. Sometimes the equilibrium is surprising, in categories I’ve looked at recently, competitors making flatly opposite representations about identical business models are both live, which tells you the reviewed surface is the listing and the build, not the company.

Matching the incumbent pattern isn’t cynicism. It’s using information the store is giving you for free.

Stop modeling this as zero-sum

Last thing, and it’s the one that changes the most behavior.

Most developers walk in framing App Review as conflict. It isn’t. Apple makes money when your app ships. Nobody in that building profits from keeping you out. What you’re actually in is a coordination problem under bad information, both sides want the same outcome and can’t cheaply verify their way to it.

The adversarial frame is a modeling error, and it produces bad tactics: concealment, escalation, threatening press. All of which raise the reviewer’s uncertainty, which, see the top of this piece, raises your rejection probability.

The cooperative frame produces the right ones. Make yourself cheap to approve. Send costly signals instead of cheap talk. Never defect in a repeated game. Don’t lawyer vague rules, clear them by a margin. And when you appeal, don’t argue that you’re right. Argue that the reviewer’s risk is lower than they think.

That’s the whole game. It’s winnable. It’s just not the one most people think they’re playing.

Every installment in this series has been about the same architectural habit. A thin clause in the body of the agreement, an attachment carrying the actual obligations, and a gap between them where the enforcement lives. MFi routes to the MFi Program. APNs routes to Attachment 1. iCloud routes to Attachment 4.

Then you reach 3.3.7(E), and the pattern breaks.

E. Extensions

Applications that include extensions in the Application bundle must provide some functionality beyond just the extensions (e.g., help screens, additional settings), unless an Application includes a WatchKit Extension.

Followed by seven bullets, every one of them substantive. Prohibitions on advertising. Restrictions on screen behavior. A design mandate for keyboards. Two data-use rules that override the general privacy clause. A disclosure requirement for keystroke logging.

No attachment. No cross-reference to a separate document. No “in accordance with the terms of Attachment N.” The clause carries its own weight, and it is one of the very few in Section 3.3 that does.

That is worth pausing on, because the reason is not sloppiness. It is a tell about what the attachments are actually for.

Read more

Here is the entire clause.

D. iCloud

All use of the iCloud Storage APIs and CloudKit APIs, as well as Your use of the iCloud service under this Agreement, must be in accordance with the terms of this Agreement (including the Program Requirements) and Attachment 4 (Additional Terms for the use of iCloud).

Forty-four words. It prohibits nothing, permits nothing, and defines nothing. Like 3.3.7(C) before it, it is a routing instruction. Attachment 4 is where the contract actually lives.

But 3.3.7(D) does something 3.3.7(C) did not. It reaches twice. It covers use of the APIs, and separately it covers “Your use of the iCloud service under this Agreement.” That second reach is doing real work, and it is worth noticing before we open the attachment, because the attachment immediately tries to give it back.

Read more

Here is the entire clause.

C. Apple Push Notification Service and Local Notifications

All use of Push Notifications via the Apple Push Notification Service or Local Notifications must be in accordance with the terms of this Agreement (including the Program Requirements) and Attachment 1 (Additional Terms for Apple Push Notification Service and Local Notifications).

Forty-two words. No operative obligation. No prohibited conduct. No standard of review. It is a signpost with an arrow on it.

Regular readers of this series know the move by now. The clause body is a receipt; the transaction happened somewhere else. We saw it with MDM in 3.3.5, where a single sentence routed to a protocol specification containing a remote wipe capability. We saw it with MFi in 3.3.7(A), where the operative approval criteria live in a program agreement the developer is not party to and cannot read.

So let me give Apple credit where it is due, briefly, because it will not last. Attachment 1 is printed in the same PDF as the clause that points to it. You can read it. It is three pages long, it is in English, and it does not require you to sign a separate NDA to find out what you agreed to.

That is the good news.

The bad news is what is in it.

Read more

Most of Section 3.3.7 is easy to categorize. It is called “Infrastructure Technologies,” and clause by clause it does what the heading promises: MFi Accessories in (A), Push Notifications in (C), iCloud in (D), Wi-Fi Aware in (G), TelephonyMessagingKit in (H), Default Dialer in (I). Each of those governs a thing Apple built, owns, runs, and can switch off.

Section 3.3.7(B) is different. It governs the cellular network.

Apple does not own the cellular network. Apple does not operate it. Apple does not pay for its spectrum, its towers, its backhaul, or its capacity. And yet 3.3.7(B) is the clause in which Apple assumes the authority to judge whether your application is using that network too much, and to require you to warn users about a contract they signed with a company that is not a party to this agreement.

Here is the whole thing.

B. Cellular Network

(i) If an Application requires or will have access to the cellular network, then additionally such Application:

• Must comply with Apple’s best practices and other guidelines on how Applications should access and use the cellular network; and

• Must not in Apple’s reasonable judgment excessively use or unduly burden network capacity or bandwidth.

(ii) Because some mobile network operators may prohibit or restrict the use of Voice over Internet Protocol (VoIP) functionality over their network, such as the use of VoIP telephony over a cellular network, and may also impose additional fees, or other charges in connection with VoIP, You agree to inform end users, prior to purchase, to check the terms of agreement with their operator, for example, by providing such notice in the marketing text that You provide accompanying Your Application on the App Store. In addition, if Your Application allows end users to send SMS messages or make cellular voice calls, then You must inform the end user, prior to use of such functionality, that standard text messaging rates or other carrier charges may apply to such use.

Two bullets and a paragraph. No attachment. No entitlement. No definition. It looks like the least consequential subsection in 3.3.7.

It is not.

Read more

Apple gives developers three ways to touch Apple Music. MusicKit for playback. ShazamKit for recognition. The Apple Music Feed API for promotion. They sit next to each other in the DPLA, D, E, and F, and most people read them as three separate grants of access.

They are not three grants. They are one architecture with three intakes.

Read together, every path these APIs open leads back to the same place: the Apple Music subscription, the Apple Music brand, and the Apple Music commercial relationship. You are allowed to build the pipe. Apple keeps the water. That is the whole design, and once you see it, the individual clauses stop looking like a toolkit and start looking like a turnstile.

Here is how the three sections do that job, and what they refuse to say while doing it.

Read more

Every clause in this series has been about a chokepoint. Section 3.3.6(C) is about the one that sits in front of the couch.

The TV app is the shelf that Apple built above every video service on the device. It holds the Up Next row, the “continue watching” state, the recommendation surface that decides which show a person resumes on a Tuesday night. If you run a streaming service, that shelf is a distribution channel you did not build, cannot see inside, and do not control.

Here is the price of admission, in full:

You may not use the TV App API unless (a) Your Application is primarily designed to provide video programming, (b) You have received an entitlement from Apple, and (c) Your use is in accordance with the TV App Specification.

Three conditions. Two of them are Apple’s opinion.

Read more

More developers than ever are writing to me with the same story. The account is gone. Every app under it, gone. The email cites fraud. It does not say what the fraud was, when it happened, or who committed it. Appeals go into a void. The developer is left to reverse-engineer their own execution.

When I press for details, a pattern surfaces that the developer usually has not noticed themselves. Somewhere on the team is a person who, two jobs ago, worked at a company that got caught. Maybe that old employer hired a growth agency that turned out to be running bots to download, rate, and review apps. Maybe it was payment fraud. The developer writing to me had nothing to do with it. They may not even know it happened. But the account is still gone.

We have a saying for inherited blame: the sins of the father. It does not fit here. Nobody is being punished for a parent. They are being punished for a coworker. So here is a new one, and I think it is going to earn its keep:

The sins of your coworkers.

Read more

Section 3.3.6(B) is one of the strangest clauses in the DPLA.

It is not strange because of what it says. It says, quite clearly, what it says. It is strange because of what it does not do.

It does not point to an attachment. It does not route the operative terms to a separate document. It does not follow the recurring architecture we have been tracking across this series, where a thin body sends the reader to Attachment 3 or Attachment 10 or Attachment 8 for the terms that actually govern.

The entire clause is body. Every operative provision Apple wants to enforce about the Single Sign-On API is on the page.

That is worth pausing on. What does an Apple developer clause look like when Apple is not routing the operative terms to an attachment?

It looks like this. And it does not read like a developer license. It reads like a commercial arrangement written into a developer agreement.

Read more

The first time most developers read Section 3.3.6(A), their eye does not stop.

The clause says:

> All use of the Game Center must be in accordance with the terms of this Agreement (including the Program Requirements) and Attachment 3 (Additional Terms for the Game Center).

One sentence. A reference to the Program Requirements. A pointer to an attachment. Standard contract housekeeping, apparently.

It is not standard. It is the same architecture as 3.3.5(D), the MDM clause we covered in *The Chokepoint Has a Certificate*. A short body. An operative attachment. A service that, in the body of the agreement, looks like an afterthought, and in the attachment, contains a privacy framework, a price control, an account-level termination trigger, and a unilateral discontinuation right.

Game Center is fifteen years old. The architecture in Attachment 3 is fifteen years old. That is not a reason to glance past it. It is a reason to look more carefully. Apple wrote the template for almost everything that came after, here.

Read more

“(iv) To use App Intents for launching via the side button of iPhone when configured by an end user, your voice-based conversational application must (1) launch into a voice experience as the primary modality when the button is pressed; and (2) after launch, appropriately respond to questions or requests and perform actions.”

That is from 3.3.11(C)(iv). It is the first time the DPLA has contemplated, in writing, that a non-Apple application might be the default thing invoked by a piece of iPhone hardware. The gating is behavioral, not commercial. The app has to actually launch into voice. The app has to actually respond to questions. There is no entitlement, no commission, no fee, no Apple-blessed allowlist. There is just a specification.

Apple has decided the rules for who gets to be the voice on the other side of that button, and the rules turn out to be the kind of rules an engineering team writes, not the kind a commercial team writes.

Read more

(note that the PLA has also changed as of yesterday, and will be discussed tomorrow)

That seventeen-page expansion is the largest single revision to the DPLA’s body since the post-DMA reorganization, and almost all of it lives in two places: two brand-new attachments, and a wave of new framework provisions stitched into Section 3.3.

I read both versions side by side. The headline is not any single clause. It is structural.

For the first time in the history of the agreement, the DPLA contains standard commission rates that differ by country, set inside the contract text itself.

The page count is the story.

Seventeen pages of net additions, almost none of it deletions. The Definitions section alone added eleven new defined terms. Section 3.3 grew new subsections under Data and Privacy, Infrastructure Technologies, and Other Technologies. Two completely new Attachments were appended, numbered 12 and 13.

The structural fingerprint matches what I have been arguing across this series. When Apple has something operationally consequential to add, it does not bulk up the clause bodies. It adds attachments.

That pattern held cleanly here. Both regulatory accommodations went into attachments. Neither went into the body.

Japan got its own attachment, and it reads exactly like the EU’s did.

Attachment 12 is titled “Additional Terms for iOS Apps in Japan.” It is roughly fifteen pages, the largest single block of new text in this revision. It exists because Japan’s Mobile Software Competition Act is now in force, and Apple’s compliance posture had to be in writing.

The new attachment defines four operational concepts that did not previously exist in the DPLA: Alternative App Marketplace (Japan), Marketplace Website (Japan), Alternative Payment Processing, and Out-of-App Offers.

The eligibility test for operating an Alternative App Marketplace will look familiar to anyone who read the EU DMA accommodations:

> Be a member of good standing in the Apple Developer Program for two (2) continuous years or more, and have an Application that had more than one (1) million First Annual Installs on iOS and/or iPadOS worldwide in the prior calendar year.

Or, in the alternative:

> Provide Apple with a standby letter of credit from a BBB- or better rated (or equivalent by S&P, Fitch, or Moody’s) financial institution in the amount of at least USD 1 million.

The financial structure is also a familiar shape. There are three layered fees.

For Alternative Payment Processing, Apple takes a 21 percent commission on resulting sales, reduced to 10 percent for Small Business Program participants, Apple Video Partner Program members, Mini Apps Partner Program members, and post-year-one subscription renewals.

For Out-of-App Offers, where a user taps an actionable link and completes a transaction on a website within seven calendar days, Apple takes a 15 percent store services commission, reduced to 10 percent under the same categories.

For developers who continue using Apple’s in-app purchase system on the Japan storefront under this attachment, Apple’s standard rate becomes 21 percent (10 percent reduced), plus an additional 5 percent App Store payment processing fee.

And then, on top of all of that, Section 4 of the attachment imposes a separate 5 percent Core Technology Commission on essentially any sale completed in, attributable to, or initiated from an Alternative App Marketplace (Japan) or an app distributed through one.

The EU established the principle that a separate technology fee can run underneath app store commissions. Japan applies it differently: a 5 percent commission on sales rather than the EU’s per-install Core Technology Fee. Same architectural insight, different commercial implementation. Same eligibility gates. Same entitlement-profile gating. Same iOS minimum requirement (here, iOS 26.2).

There is also a full reporting, invoicing, tax withholding, and audit regime in Section 5 of the attachment. Three-year record retention. Thirty-day audit response window. Late-payment interest at 1 percent monthly. None of that was in the EU equivalent, because EU billing flows through Apple’s existing accounting systems. The Japan attachment treats developers operating marketplaces as something closer to direct commercial counterparties, and the contract documentation reflects that.

China got an attachment too, and that is the new precedent.

Attachment 13 is short. It is one operative page. The title is “Additional Terms for iOS and iPadOS Apps in China mainland.” It opens with this language:

> As of March 15, 2026, the terms in this Attachment 13 apply to commissions and payments for Applications distributed on the China mainland storefront of the App Store on iOS and iPadOS.

And then:

> The Paid Applications Agreement is amended and restated so that Apple’s standard commission rate for the sale of Licensed Applications is twenty-five percent (25%).

That is the first time, to my knowledge, that the DPLA itself has set a country-specific standard commission rate inside the four corners of the agreement. Historically, commission rates lived in Schedule 2 (the Paid Applications Agreement) or in program addenda like the App Store Small Business Program. The standard 30 percent rate was a global default, and reductions came through enrollment in programs.

China mainland now has its own number, written into the master contract, applicable by jurisdiction of the storefront.

The reduced rate is 12 percent under the same triggers as the EU and Japan equivalents: Small Business Program participation, Mini Apps Partner Program qualification, or post-year-one subscription auto-renewal.

The reasons Apple did this are visible in the public record. China’s antitrust regulators have been scrutinizing app store commission practices. The 30 percent rate has been a contested number in Chinese policy commentary for years. Apple made a unilateral move.

The form of the move is what matters here. It is not a settlement. It is not a public commitment. It is not a press-released concession. It is a contract attachment. It went live in the legal instrument, with a March 15, 2026 effective date that preceded the agreement’s revision date of March 30, 2026 by fifteen days. That sequencing is telling. Apple drafted the attachment around an internal effective date and adjusted the master agreement around it.

Attachment 13 is short. But it is the most precedential page in the new DPLA.

EU Data Act provisions arrived as footnotes.

Two existing sections gained pointers to external EU Data Act terms. Section 3.3.8(A) on Xcode Cloud now contains:

> If You are enrolled in the Apple Developer Program as an organization based in the European Union, additional terms for Xcode Cloud related to Regulation (EU) 2023/2854 are set forth at https://developer.apple.com/download/files/EU-Data-Act-Terms-XcodeCloud.pdf.

Attachment 4 on iCloud got a parallel insertion at new Section 1.6 for CloudKit. Same structure.

This is the EU Data Act (Regulation 2023/2854) showing up in Apple’s developer-facing contracts for the first time. Apple’s handling here is consistent with how it has handled the Digital Services Act and the Digital Markets Act regulatory text. Keep the obligations off the main agreement, pin them to a URL, and let them update independently. The DPLA references the document. The document is the document.

The Apple Intelligence and Vision Pro feature wave shows up as new frameworks.

Section 3.3 gained six new framework provisions that did not exist in LYL 217. Reading them together, they map cleanly to Apple’s recent hardware and OS push.

Section 3.3.7(J), “Accessory Notifications Framework and Accessory Live Activities Framework,” governs notification forwarding from an iPhone to what the agreement now calls an “Authorized Target Accessory.” This is the structural plumbing for third-party smart glasses, watches, and similar accessories that mirror iPhone notifications.

The restrictions are unusually strict for an accessory framework. Forwarded notifications cannot be used for “advertising, profiling, training models, or monitoring location.” The notification data cannot be decrypted anywhere except on the target accessory itself. It cannot be redisseminated to any other device, including back to the originating iPhone. And the developer is contractually responsible to Apple for the target accessory’s compliance, not just the app’s compliance.

That last point is the operationally interesting one. A non-app entity (the accessory) is being made subject to DPLA obligations through the developer’s contract.

Section 3.3.7(K), “Foveated Streaming Framework,” is Vision Pro-specific. It enables sessions where streaming content can be optimized using eye-tracking data. The framework definition acknowledges that it transmits “the approximate region where an end user is looking.” Treating gaze direction as a regulated data type, with its own framework section, is a notable expansion of what Apple considers sensitive sensor output worth contractually fencing.

Section 3.3.8(J), “Wi-Fi Infrastructure Framework,” lets an iOS app share Wi-Fi credentials from an Apple device to an Authorized Target Accessory, but only through the developer’s “Accessory Data Transport Extension,” only end-to-end encrypted, only for connecting that accessory to a network the iPhone can already join. Same structural pattern as 3.3.7(J): the framework, the extension, the target accessory, the developer responsibility for accessory compliance.

The Family Controls Framework got Section 3.3.3(Q), which is unusually narrow. Primary purpose must be either family controls through Family Sharing, or individual focus and productivity tools. The express prohibitions are interesting: not for ad blocking, not for use in organizational settings, and (this is the new part) not for “managing the device of another adult.” That last carve-out is a privacy framing I have not seen before in a DPLA framework restriction.

The Location Push Service Extension, in new Section 3.3.3(F)(vi), is restricted to (a) user-approved location sharing, or (b) “alert[ing] the nearest first-responders to a time-sensitive medical emergency.” That second use is the one that matters. Apple has built a framework whose only non-consumer permitted use is emergency dispatch. That suggests partnerships with public-safety entities are coming, or are already running in production with specific developers.

The data and privacy expansions are smaller but read as a tightening pattern.

Section 3.3.3(A) on Recordings added one sentence:

> Your Application may not be designed to facilitate Recordings of others without their awareness.

That is a behavioral prohibition, not a technical one. It is the kind of clause we used to write when we wanted reviewer discretion over a category of apps without naming the category. In practice, this clause will be used to reject covert-recording apps that route around the conspicuous-indicator requirement by, for example, disguising the indicator or recording when the app is backgrounded.

Section 3.3.3(B) extended third-party SDK obligations to “any service with whom You have contracted.” Previously the obligation was scoped to third-party SDKs. Now it reaches third-party services. That is a meaningful expansion if Apple is using it during review to require disclosure of backend dependencies and not just bundled SDKs.

Section 3.3.3(P), the Declared Age Range API section, was renamed to include the new Significant App Update Topic API, and the operative language expanded:

> data from the Declared Age Range API is based on information provided to Apple that is declared by an end user, or their parent or guardian, and may be confirmed using a payment method (like a credit card), government ID, or another method.

The acknowledgment that government ID and payment cards can flow through this API is new. It maps onto the wave of U.S. state-level age-verification laws and the UK Online Safety Act’s age-assurance regime. Apple is signaling that the Declared Age Range API will become the channel through which verified age data, not just declared age data, reaches third-party apps.

Section 3.3.1(B) was quietly restructured to make room for marketplaces.

This one is small in word count but large in meaning. The LYL 217 text on executable code contained this prohibition:

> Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS.

The LYL240 text reorders and rewords:

> Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application (b) does not bypass signing, sandbox, or other security features of the OS; and (c) for Applications distributed on the App Store, does not create a store or storefront for other Applications.

The “no store within an app” prohibition still exists. But it is now cabined to App Store distribution. It does not apply to apps distributed through an Alternative App Marketplace (Japan) or, by structural extension, through any future jurisdictional attachment that creates an alternative distribution path.

This is the kind of edit you make when the body of the agreement needs to accommodate attachment-level carve-outs without explicitly announcing them. The clause does the work; the carve-out is invisible unless you compare the versions.

What did not change is the tell.

Section 7.6, the chokepoint clause I wrote about earlier in this series, is unchanged. Section 3.2(f) is unchanged. Attachment 10 on MDM, which I covered in my most recent piece, is unchanged. Section 3.3.5(D) on MDM compliance is unchanged. The Schedule 1 agency appointment is unchanged in structure (only minor formatting updates).

In other words, every enforcement chokepoint that I have been mapping in this series remained exactly where it was. Apple did not loosen any of them.

The new attachments do not relocate enforcement authority. They add new commercial regimes on top of the existing enforcement architecture. The chokepoints continue to function, and now they function across more jurisdictions, with more commission tiers, more entitlement profiles, more reporting obligations, and more contractually-bound non-developer entities (the Authorized Target Accessory framework).

The DPLA grew. The grip did not loosen.

This is the agreement Apple wanted to write three years ago.

If you read LYL240 as a finished document rather than as a diff, it reads like a contract that has finally caught up to the regulatory environment around it.

The EU has its DMA accommodations sitting in the Notarization regime and a separate developer pathway. Japan now has Attachment 12. China mainland has Attachment 13. The EU Data Act has CloudKit and Xcode Cloud footnotes. The Foundation Models Framework has its acceptable-use document. The Apple Intelligence and Vision Pro frameworks have their dedicated subsections.

Every regulatory and product expansion has its own contract surface, and almost all of them live in attachments. The body of the agreement remained nearly stable. The work happened at the edges.

For a series that has been arguing the DPLA is built as thin clauses with operative terms in attachments, this revision is the cleanest demonstration of the thesis I could have asked for. Apple did not amend the body to accommodate Japan and China. It added attachments.

The contract has a border now. It has two of them.

How many will it have by the end of 2026?

What happens when a developer’s Application is simultaneously subject to Attachment 12, Attachment 13, the EU DMA accommodations, and Section 3.3.5(D) MDM obligations? Which attachment governs in conflict?

And if jurisdictional commission rates can now live inside the master agreement, what is to stop the Schedule 2 standard 30 percent rate from becoming the exception rather than the rule, jurisdiction by jurisdiction, attachment by attachment?

Section 3.3.5(D) of Apple’s Developer Program License Agreement governs Mobile Device Management. The clause reads in full:

D. Mobile Device Management All use of MDM must be in accordance with the terms of this Agreement (including the Program Requirements) and Attachment 10 (Additional Terms for the use of MDM).

That is the entire clause. One sentence. Twenty-eight words.

MDM is the mechanism that makes enterprise iOS possible. It is how organizations remotely configure their devices, enroll them at scale, push certificates, install or remove apps, lock screens, wipe data, and collect compliance telemetry. It is the contractual backbone of every Apple-managed device fleet in every Fortune 500 company, every school district, every government agency, and every healthcare network. It is also the legal foundation of an entire mobility software industry: Jamf, Microsoft Intune, VMware Workspace ONE, Ivanti, Kandji, Mosyle, and dozens of smaller vendors.

The clause that grants Apple authority over all of it is one sentence.

The real terms are in Attachment 10. And Attachment 10 is the room behind the doorway.

Read more

Section 3.3.5(C) is one of the shortest API clauses in the DPLA. It is also one of the most jurisdictionally aggressive. The clause governs Sign in with Apple and Sign in with Apple at Work & School. It also reaches your website.

You may use Sign in with Apple or Sign in with Apple at Work & School in Your Corresponding Products only so long as Your use is comparable to including Sign in with Apple or Sign in with Apple at Work & School, respectively, in Your Application.

The phrase that does the work is “Corresponding Products.” Defined elsewhere in the agreement as your website, web application, or other version of your software application. The DPLA is your iOS contract. This clause uses that iOS contract to dictate your behavior on the open web.

Read more

Most developers who scan the Developer Program License Agreement skip past 3.3.5 entirely. It sits in a corner labeled Enterprise and Education Technologies, and unless you ship an app that pushes assignments to Schoolwork or pulls a class list from Apple School Manager, you assume it does not apply to you.

That assumption is wrong in an interesting way. Section 3.3.5(B) is the most restrictive data-handling contract Apple writes for any third party in the entire DPLA. It is stricter than the App Tracking Transparency disclosures. It is stricter than the HealthKit privacy terms. It is stricter than the Address Book API rules. And it is built on a structural choice that almost no other clause in the agreement makes: it treats a third party, the school’s IT administrator, as the sole consent authority over user data the developer is processing.

Here is the clause in full.

Your Application must not include the ClassKit APIs unless it is primarily designed to provide educational services, and this usage is clearly evident in Your marketing text and user interface. You agree not to submit false or inaccurate data through the ClassKit APIs or to attempt to redefine the assigned data categories for data submitted through the ClassKit APIs (e.g., student location data is not a supported data type and should not be submitted).

You may not share, sell, transfer or disclose Roster Data to any third parties (e.g., affiliates, advertising platforms, data brokers, information resellers). You must process Roster Data for educational purposes solely in accordance with the instructions of the school’s IT administrator. You must comply with the school IT administrator’s choice to not renew or to revoke the school’s consent to use the Roster Data. If the school IT administrator does not renew or revokes Your access to a school’s Roster Data, You must destroy all of the school’s Roster Data in Your possession within thirty (30) days. You are responsible for complying with all applicable legal requirements associated with Your use of the Roster API.

Six sentences. Six different obligations. Let’s take them apart.

Read more

Configuration Profiles look like housekeeping for IT admins. They are actually the first thing Apple ever wrote to stop developers from shipping outside the App Store.

Most developers skim past Section 3.3.5 of the DPLA. It lives under the heading “Enterprise and Education Technologies,” and the assumption is that whatever is inside applies to MDM vendors, school IT departments, and the kind of companies that buy thousands of iPads at a time.

That reading is wrong.

Read more

It looks, at first glance, like a feature-enablement paragraph. A small carve-out covering how Apple’s Spotlight image search service interacts with the web domains you associate with your iOS app. The kind of clause your eyes skip over on the way to something more obviously consequential.

It isn’t.

Read more

Most developers read the charitable contributions clause in Apple’s Developer Program License Agreement and treat it as a minor permission. A nice-to-have. A small carve-out that lets your app point users at a “Donate” button. Read it again.

3.3.4(vii): Your Application may include a direct link to a page on Your web site where You include the ability for an end user to make a charitable contribution, provided that You comply with any applicable laws (which may include providing a receipt), and fulfill any applicable regulation or registration requirements, in the country, territory, or region where You enable the charitable contribution to be made. You also agree to clearly state that Apple is not the fundraiser.

Fifty-four words. One sentence of permission, one sentence of compliance, one sentence of disclaimer. Apple gives you very little, demands quite a lot, and walks away from the entire regulatory perimeter.

This is one of the cleanest examples in the DPLA of a clause that looks permissive and is, structurally, an enormous risk transfer.

Read more

In a piece for the Middle East Monitor on May 3, Karam Nama borrowed an analogy from the Financial Times’ John Thornhill: Apple is the digital Strait of Hormuz. Not a waterway, but a chokepoint. Not the source of the oil, but the passage through which it must flow.

The metaphor lands. It lands harder if you’ve spent any time inside the contract that runs the strait.

I have been writing a clause-by-clause series on the Apple Developer Program License Agreement. Most of those pieces look at one obligation, one liability shift, one definitional move. This piece is different. It is about the shape of the whole document, and what that shape means.

The shape is a strait.

Apple does not need to be first. Apple needs to be the gate.

Thornhill’s argument, distilled by Nama, is that power in the AI era is not invention. It is access. Models proliferate. Capabilities multiply. Foundation labs raise eye-watering rounds. None of it reaches a user without crossing a screen, and the screen, for billions of people, is governed by Apple.

“Apple does not need to dominate AI research to dominate its distribution.”

That sentence, from Nama’s piece, is not a description of Apple’s market position. It is a description of the Apple Developer Program License Agreement.

The DPLA exists to enforce one bright line: software runs on Apple devices on Apple’s terms or it does not run at all. Section 7.6, titled “No Other Distribution Authorized Under this Agreement,” reads in part:

“In the absence of a separate agreement with Apple, You agree not to distribute Your Application for iOS, iPadOS, tvOS, visionOS, or watchOS to third parties via other distribution methods or to enable or permit others to do so.”

That is the strait, written down. 2.5 billion active devices on one side, every developer in the world on the other, and a single sentence of legal English between them.

Every clause is a tollbooth.

If section 7.6 is the strait, the rest of the agreement is the geography of it.

3.3.1(B) is the clause Apple invoked against Replit and Vibecode. It governs what kind of software can run inside other software, and Apple used it to slow down vibe coding platforms before they could become parallel app stores.

3.3.4(iv) is the malware clause. It pushes liability for harmful or unstable code down onto the developer, regardless of how the code was generated. The AI generation question is unsettled.

3.3.4(v) is the FOSS clause. It refuses GPL-style copyleft obligations from contaminating Apple’s distribution. If your dependency tree includes a license Apple does not like, the strait is closed to you.

3.3.4A is the content layer. Music rights, objectionable content, age verification, sensitive content scanning. Each one a separate kiosk in the same building.

3.3.3(N) shifts identity verification liability onto developers who use Apple’s ID Verifier APIs.

App Store guideline 3.2f governs fraud detection and permanent termination. One enforcement event closes the strait to your developer account, forever.

I could keep going. The series will keep going. The point of listing them like this is to make a structural argument that no single clause can make on its own: every clause in the DPLA is a tollbooth, and every tollbooth is positioned at a different point along the same strait.

Some are about money. Most are not. Most are about permission.

The Hormuz tax is not a metaphor. It has a number.

Thornhill calls it the Hormuz tax in the metaphorical register. In the actual contract, it has a name and a number.

The In-App Purchase API, governed by Schedule 2 of the DPLA, takes a percentage of every digital transaction inside an app distributed through the App Store. Thirty percent for most developers, fifteen percent for small businesses and second-year subscriptions. There are corners and exceptions, but the structural fact is simple: if your AI service charges a user through an iOS app, Apple gets a cut.

This is the most visible part of the strait, and the part that has drawn the most regulatory attention. The European Digital Markets Act. The Epic Games litigation. The South Korean alternative payment law. All of them aimed at this one tollbooth.

None of them, so far, has redrawn the coastline.

Developers stop thinking about what is possible.

This is the move in Nama’s piece I keep coming back to. He argues that when one company becomes the passage, developers stop asking what is possible and start asking what is permitted. Creativity becomes negotiation, not invention.

That is the actual cost of the strait, and it does not show up on a balance sheet.

It shows up in the Replit team rewriting their architecture to satisfy a clause. It shows up in vibe coding founders reading the App Review Guidelines before they read their own product roadmap. It shows up every time a developer with a working idea looks at the DPLA and decides not to build the thing.

The series I am writing is, at its core, an attempt to map that constraint clause by clause. Not because the clauses are interesting in themselves, although they often are. Because the clauses, taken together, define the imaginative perimeter of an entire industry.

Ternus inherits the tollbooth.

I wrote last week about John Ternus taking over as CEO on September 1. The succession is a product-CEO signal, a pivot back toward hardware-led decision making, and probably the closest Apple has come to a Steve Jobs leadership posture since 2011.

It does not change the strait.

Tim Cook becoming Executive Chair and global ambassador, traveling between Brussels and Beijing and Washington, is consistent with this. The strait keeper does not negotiate the strait away. The strait keeper negotiates with the parties trying to redraw it. That is Cook’s next job. Ternus’s job is to keep the device and the developer platform attractive enough that nobody seriously wants to redraw it in the first place.

The contract stays. The signatures change.

Can the strait be broken?

Nama offers two paths, and they are the right two: a technological revolution that changes the device, or regulatory intervention that redistributes power.

Both are circling. Neither has landed.

A new device class, glasses or an ambient AI wearable that does not depend on the iPhone for distribution, would route around the strait the way pipelines once routed around Hormuz. Apple knows this. Apple has its own glasses program. So does everyone else.

Regulatory intervention, especially the DMA in Europe, is changing the texture of the strait at the margins. Sideloading. Alternative payment processors. Third-party browser engines. None of it has reduced Apple’s structural position. Compliance has been technical and grudging, and the toll continues to be collected.

There is a third path Nama does not name. Read the DPLA more carefully. Push back on the clauses that overreach. Make Apple defend each tollbooth on its own terms instead of accepting the whole geography as given.

That is the path this series is on.

Who is allowed to pass?

In the past, knowledge was power. Today, access is power. Apple does not need to be first. Apple needs to be the gate.

Every clause in the Apple Developer Program License Agreement is a stretch of that gate. Some narrow. Some wide. All of them written by Apple, all of them enforceable by Apple, all of them subject to change at Apple’s discretion.

The next piece in this series will go back to a single clause. The clause-level work matters, and it is going to keep mattering, especially as the AI wave runs through every section of the agreement at once.

But the strait is the frame. The strait was always the frame. Thornhill named it. Nama sharpened it. The contract has been writing it down for sixteen years.

The question developers should be asking, every time they sign the DPLA, is the question Nama ends on:

Who is allowed to pass?