Apple on October 13, 2026 published a revised Apple Developer Program License Agreement that writes two new ways of selling subscriptions into its contracts with developers: Group Purchases, in which one subscriber buys seats and invites others, and Volume Purchases, in which a business or school buys seats through Apple Business or Apple School Manager. The update also adds terms for a Live Assistance API that lets accessibility services join FaceTime calls, an App Replacement Entitlement for moving users from one app to another, and Apple HomeView, while setting out what developers may and may not do with customer tax information that Apple passes to them.

In Short

Apple changed the rulebook that every app maker signs, so that apps can now sell one subscription that a whole family, team or school shares. It also added rules for a few new features, like letting a sign language or captioning service join a FaceTime call, and for showing iPhone widgets on Apple's new home screen device. If you build apps, you have to click "agree" to the new version to keep using Apple's tools, and the tax information Apple shares with you can only be used for tax purposes.

What Apple posted on October 13

The notice on Apple's developer news page is short. Titled "Updated Apple Developer Program License Agreement now available" and dated October 13, 2026, it states that the agreement "has been revised to support new features and updated policies, and to provide clarification." Developers are told to review the changes and "sign in to your account to accept the updated terms."

Eight bullet points follow, each naming sections of the agreement. Apple lists updated security requirements in Section 3.2; terms for the Live Assistance API in Section 3.3.8(j); terms for the App Replacement Entitlement in Section 3.3.8(k); terms for iOS app widgets and CarPlay apps on Apple HomeView in Sections 6.4, 6.4.1 and 6.4.2; Group Purchases in Schedule 2; Volume Purchasing in Schedule 3; and two tax provisions that apply across both schedules. Translations, according to Apple, "will be available on the Apple Developer website within one month."

The agreement itself, as published on Apple's support site, carries matching dates. Its closing notes state that the Developer Program License Agreement, including Schedule 1, was "last updated October 13, 2026," that Schedules 2 and 3 were last updated on the same date, and that the exhibits to Schedules 2 and 3 were last updated on August 27, 2026. Schedule 2 also carries a version code, LYL260, printed above the October 13 date.

Two caveats frame everything below. First, the public copy is not the binding one. A note at the bottom of the page states that "the version of the Apple Developer Program License Agreement you accept in your developer account is binding and the most up to date. This version is provided for your convenience." Second, Apple published no redline. The news post names sections but does not quote old wording, so for several of the changes it is impossible to tell from the two documents alone which sentences are new and which were already there.

Why acceptance is not optional

Section 4 of the agreement explains why a terms update of this kind lands on every developer's dashboard at once. "Apple may change the Program Requirements or the terms of this Agreement at any time," it reads. To continue using Apple Software, certificates or services, developers "must accept and agree to the new Program Requirements and/or new terms of this Agreement." If they do not, their "use of the Apple Software, Apple Certificates and any Services will be suspended or terminated by Apple." Acceptance can be signified "by Your checking a box or clicking on an 'agree' or similar button."

The same section limits the reach of changes to apps already on sale. New or modified program requirements "will not retroactively apply to Applications already in distribution," although Apple "reserves the right to remove Applications" that do not comply "at any time." The clause is not new, but it governs every item in the October 13 changelog.

Group Purchases: one buyer, many seats

The most commercially significant change sits in Schedule 2, the contract that governs paid apps and in-app purchases on the App Store. It creates a new kind of customer.

Section 1.1(b) of Schedule 2 now extends the definition of "End-User" for auto-renewable subscriptions to "each individual who receives access to a Group Purchase (a 'Group Member')." A Group Purchase, according to the same clause, "is an auto-renewable subscription purchased by an End-User (the 'Group Organizer') to be shared with a group of individuals." Section 1.2(d) adds Group Members of Group Purchases to the list of people to whom developers authorize distribution, alongside existing categories such as Family Sharing accounts, Legacy Contacts and Apple Configurator deployments.

Section 3.1 adds the commercial authority. "For Group Purchases, You authorize Apple to market, solicit, and facilitate purchases of Your Group Purchases under a single transaction for use by multiple End-Users." In practice, one charge covers several people.

Refunds are where the new mechanism gets most detailed. Section 3.8(c) has long required developers to fulfil a subscription "during the entire subscription period, as marketed," and authorizes Apple to refund the customer if they do not. The revised text adds that, for Group Purchases, developers authorize Apple "to refund to the Group Organizer (i) the full amount of the price paid for the entire Group Purchase, or (ii) a partial amount equivalent to the price of any unused subscription." Apple "will not grant partial refunds for any subscription that is currently accessed by an active Group Member."

One sentence in that section shifts a factual question onto developers. "For refunds for Group Purchases where You hosted and managed the invitations, You acknowledge and agree that Apple will determine if a subscription is currently being accessed by an active Group Member based on the information You provide to Apple." The agreement therefore anticipates two models: invitations run by Apple, and invitations run by the developer. In the second case, the accuracy of the developer's own seat data determines whether a partial refund is available. The agreement does not say what format that information takes or how often it must be supplied.

The existing reimbursement clause still applies. Where Apple refunds a subscription, developers "shall reimburse, or grant Apple a credit for, an amount equal to the price for that subscription," and repeated violations allow Apple to exercise its rights under Section 7.3 of Schedule 2.

Apple first described the product at its developer conference. At WWDC26 on June 8, Apple said group purchases would let a single subscriber buy seats and invite others to join, with volume purchasing due "this fall" and group purchases "this winter." The October 13 agreement is the contractual layer for both. Neither the news post nor the agreement gives a launch date for either feature.

What the agreement does not say about Group Purchases

Several practical points are absent from both documents. There is no maximum group size, no statement of how Group Purchases relate to the six-person limit of Family Sharing, and no separate commission rate. The commission terms in Section 3.4 of Schedule 2 appear unchanged: 30% of the price paid by each End-User, falling to 15% for renewals once a customer has accrued more than one year of paid service within a Subscription Group. Because a Group Purchase is a single transaction by a Group Organizer, how the one-year clock is measured for individual Group Members is not addressed.

There is also a drafting slip. In the published text of Section 1.2(d), Group Members appear as a second item numbered "(iv)", directly after an existing item (iv) covering Custom App Distribution. The same paragraph refers to distribution "under this Schedule 1" inside Schedule 2. The news post cites Section 1.2(d)(iv), which matches the location but not the duplicated numbering.

Volume Purchases through Apple Business and Apple School Manager

Schedule 3 covers Custom App Distribution, the channel Apple uses to sell apps to organizations rather than to the public. Here the parallel concept is the Volume Purchase.

Section 1.1 of Schedule 3 now defines a "Volume Purchase" as "an auto-renewable subscription purchased by an institutional purchaser through Apple Business or Apple School Manager to be shared with a group of individuals." The people who receive access are also called "Group Members," the same label Schedule 2 uses for consumer groups. Section 1.2(d)(iii) authorizes distribution to "Group Members of Volume Purchases purchased through Apple Business or Apple School Manager," and Section 3.1 adds the same single-transaction authority found in Schedule 2.

Apple Business is itself recent. Apple announced it in March and launched it on April 14 in more than 200 countries and regions, replacing Apple Business Connect, Essentials and Apple Business Manager. The October 13 agreement is the first revision of developer terms to tie subscription seat sales to that platform by name.

Section 3.8(a) of Schedule 3 includes a warning that has no consumer equivalent. "For Volume Purchases, You acknowledge that opting out of multi-seat purchasing for a subscription or otherwise changing Your availability settings via App Store Connect may affect the ability to renew or add to that auto-renewable subscription, including removal of the subscription from Apple Business and/or Apple School Manager, as described in the Documentation." A developer who switches off multi-seat sales could therefore cut existing institutional customers off from renewing. The agreement points to separate documentation for the details.

Refunds mirror the consumer model, with the institutional purchaser in place of the Group Organizer. Under Section 3.8(c) of Schedule 3, developers authorize Apple to refund "the full amount of the price paid for the entire Volume Purchase, or (ii) a partial amount equivalent to the price of any unused subscription," with no partial refunds for subscriptions "currently accessed by an active Group Member." Unlike Schedule 2, the Schedule 3 text contains no clause about developer-hosted invitations.

The news post lists Schedule 3 Sections 1.1(b), 1.2(d)(iii), 3.1, 3.8(a) and 3.8(c) as changed. Schedule 3's definitions in the published agreement are unlettered paragraphs under Section 1.1, so there is no visible "1.1(b)" label in that schedule, although the Volume Purchase definition sits in the "End-User" paragraph the news post appears to mean.

Tax data: the news post and the contract use different words

Two bullets in the news post deal with tax. On these, the wording in the changelog and the wording in the agreement differ in ways that matter.

According to the news post, Section 3.3(a) of both schedules "specifies that Apple will report legally required information such as tax, sales, and contact details to tax authorities." The agreement text is narrower in vocabulary and looser in obligation. Section 3.3(a) of Schedule 2 reads: "You acknowledge and agree that any information You provide to Apple under this Schedule 2 may be disclosed by Apple to the applicable tax authorities to the extent required under applicable law." It adds that such disclosure "shall not constitute a breach of any confidentiality obligation otherwise owed by Apple to You under the Agreement." Schedule 3 uses identical language.

Three differences stand out. The news post says "will report"; the contract says "may be disclosed." The news post names "tax, sales, and contact details"; the contract refers to "any information You provide to Apple" and does not list categories. And the contract adds a confidentiality waiver that the news post does not mention. The phrase "to the extent required under applicable law" is the limit in both, but the agreement does not name the laws or jurisdictions concerned. Neither document identifies which tax regimes prompted the change.

The second bullet runs in the opposite direction. According to the news post, Section 3.3(b) "restricts the use of any customer tax information shared by Apple with developers to only those purposes mandated by law." The contract states: "In the event that Apple discloses to You any information that Apple is required to disclose under applicable law, including without limitation any tax information relating to any End-User, You shall use such information solely for the purpose of complying with applicable tax obligations, including tax reporting, remittance, and audits as required by applicable law, and for no other purpose."

Here the agreement is broader than the summary. The news post refers to "customer tax information"; the contract covers "any information that Apple is required to disclose under applicable law," of which tax information is one example. For marketers and app businesses that combine customer records across systems, the closing words, "for no other purpose," are the operative ones. Information received this way cannot, under the contract, be used for analytics, customer relationship management or marketing.

These clauses sit beside tax terms that were already in place. Section 3.2 of each schedule still makes developers "solely responsible for selecting and maintaining accurate inputs for tax categorization," allows Apple to hold amounts in trust if it considers a categorization inaccurate, and requires developers to indemnify Apple against tax authority claims. The exhibits that set tax rates by country were last updated on August 27, 2026, the date Apple adjusted developer proceeds for a 20% VAT in Morocco, an 18% VAT in the Republic of the Congo and a higher digital sales tax in Tanzania.

Live Assistance API: accessibility providers on FaceTime

The first of two new technology clauses appears in Section 3.3.8, the agreement's catch-all for specialist frameworks. The definitions section now describes the "Live Assistance API" as "the Documented API that enables an Application or Corresponding Product to connect to an end user's FaceTime call." A Corresponding Product, in Apple's terms, is a developer's website, web application or other version of its software.

The use is tightly bounded. Section 3.3.8(J) states: "At an end user's invitation, Your Application or Corresponding Product may use the Live Assistance API solely for the purpose of enabling an accessibility service provider to join the end user's FaceTime call to provide accessibility services (e.g. captioning, translation, etc)."

Two conditions are explicit: the end user must invite the service, and the purpose must be accessibility. The clause does not mention recording, storage of call content, or advertising use, and it does not cross-reference the agreement's general data rules. Nor does it define "accessibility service provider." Whether, for example, a general-purpose translation app qualifies is left to Apple's documentation and review.

App Replacement Entitlement: moving users without losing them

The second clause addresses a long-standing problem for app publishers: getting existing users onto a new app without losing their data or leaving two copies installed. The agreement defines the "App Replacement Entitlement" as the entitlement that shows, "upon first launch of Your replacement Application, a system sheet that gives the end user a choice to move data and settings from Your original Application that they installed previously, and to delete that original Application."

Section 3.3.8(K) sets two limits. A replacement app may use the entitlement "only if both it and Your original Application are under Your Developer Program membership, and have substantively the same primary purpose and functionality."

The first condition rules out using the system sheet across different developer accounts, which matters for companies that acquire apps or restructure their corporate entities. The second rules out using a popular app's install base to push users into an unrelated product. The agreement does not define "substantively the same," and does not say whether ratings, reviews or purchase history carry over. The sheet, according to the definition, gives the user "a choice," so the move cannot be forced.

Apple HomeView, CarPlay and widgets

Section 6.4 has been retitled "CarPlay and Apple HomeView." Under Section 6.4.1, developers "agree that Your iOS Application widget may be made available on CarPlay and Apple HomeView." The consent is built in: there is no opt-in step described.

The rest of 6.4.1 concerns CarPlay only. Developers are responsible for deciding whether a widget "is functional and suitable to use for CarPlay," and for using the "disfavoredLocations function to disfavor Your iOS Application widget if it is not." Unsuitable examples given include widgets "that require extensive user interaction while driving, or that require the iPhone to be unlocked to be used." Apple reserves the right to disfavor a widget itself. No equivalent suitability test or opt-out is described for HomeView, so on the text as published, an iOS widget may appear on HomeView with no developer step to prevent it.

Section 6.4.2 goes further. "If Your Application includes a CarPlay entitlement profile in a category identified by Apple in the Documentation, You agree Apple may provide access to such Application on Apple HomeView while it is running on a paired iOS device." An app built for a car dashboard can, under this clause, also be surfaced on a home device, provided it runs on a paired iPhone. The categories are not listed in the agreement.

The news post attributes this change partly to "Definitions" and in fact lists "Definitions" twice in the same bullet. The published agreement contains no defined term for Apple HomeView or CarPlay, so either the definitional change concerns another term or the reference is in error; the documents do not resolve it. HomeView is the home hub Apple presented on the same day as the agreement update; according to Apple's home announcement that day, it is not offered for sale in the European Union.

Section 3.2: security rules without a changelog

The news post's first bullet is also its vaguest: "Section 3.2: Updated security and related requirements for using Apple's software and services." Nothing in the post says which sentences changed.

The current Section 3.2(e) bars developers from creating any product or code that would, among other things, "deceive regarding the identity, purpose, or behavior of the product, code, or program, including through post-review modifications that would cause harm to others"; "impersonate Apple or any third party to solicit credentials or other sensitive information"; "implement security or privacy protections in a manner that is intentionally weakened, or inconsistent with what is described"; "whether through Your own code or someone else's, access, collect, or transmit user data beyond what was disclosed when consent was requested"; or "use the end user's device or network resources to provide services to third parties without the user's explicit prior consent."

Several of those clauses touch the advertising and measurement stack directly. The phrase "through Your own code or someone else's" places responsibility for data collected by third-party software development kits on the developer. The last item addresses apps that turn phones into nodes for proxy or bandwidth-sharing networks. The "post-review modifications" language covers apps that change behavior after passing App Review.

Section 3.2(h), in the same section, bars developers from using "output generated from an Apple model to train, fine-tune, or improve another artificial intelligence model" and from programmatically accessing Apple models "except as expressly permitted." Whether any of these provisions were added on October 13, or merely revised, cannot be established from the two documents.

The security context is not abstract. Apple has also imposed recent restrictions through software rather than contract language. In September, iOS 27 began blocking certain tracking domains in Safari, which prompted ID5's chief executive to call for regulators to look. On October 2, Apple also said it would tighten Full Disk Access on the Mac, without giving a date.

Where this fits in Apple's contract changes this year

The October 13 revision is the latest in a run of contract updates. On August 18, Apple published single EU business terms that replaced the per-install Core Technology Fee with a 5% Core Technology Commission, taking effect October 1. That change lives in Attachment 14 of the same agreement, which states that it applies "as of October 1, 2026, or the date on which You sign this Agreement including this Attachment 14, whichever is later." The October 13 changelog does not mention Attachment 14, and its text was not part of this update.

In September, a clause in Apple's UK developer terms extending its commission to purchases made within seven days of an out-of-app link drew attention from developers, following the October 2025 Competition Appeal Tribunal ruling that Apple abused its dominant position. Those changes were driven by courts and regulators, in Europe often under the Digital Markets Act. The October 13 changes are different in kind. None of the eight bullets cites a regulator or a court. They read as product enablement for subscription seats and new hardware, plus tax housekeeping.

For subscription businesses, that distinction may be the more significant. Group and volume seats change the unit economics of apps sold to families, teams and schools, and Apple's own figures show how much is at stake: the company said App Store ecosystem billings and sales reached $1.4 trillion in 2025. In November 2025 Apple also created a separate Mini Apps Partner Program with an 85% developer share for qualifying purchases. Seat-based subscriptions add another commercial structure that runs entirely through Apple's billing, refund and reporting systems.

Questions remain that only Apple's documentation, or the features themselves, can answer. How seats appear in App Store Connect reporting, how attribution tools and subscription analytics count a Group Member against a Group Organizer, and whether ad platforms measuring subscription conversions will see one purchase or several are not addressed in either document.

Timeline

Summary

Who: Apple, and every developer enrolled in the Apple Developer Program, who must accept the revised terms to keep using Apple's software and services. Subscription businesses selling to families, teams, businesses and schools are most directly affected.

What: A revised Apple Developer Program License Agreement adding Group Purchases (one subscriber buys seats for a group) and Volume Purchases (institutions buy seats through Apple Business or Apple School Manager), with new refund rules for both; terms for a Live Assistance API that lets accessibility providers join FaceTime calls; an App Replacement Entitlement limited to apps under the same membership with the same purpose; widget and CarPlay app availability on Apple HomeView; updated security requirements in Section 3.2; and tax clauses allowing disclosure of developer information to tax authorities and limiting developers' use of information Apple discloses to tax compliance only.

When: The news post and agreement are dated October 13, 2026. Translations are due within one month. No launch date is given for Group or Volume Purchases.

Where: The changes apply to the worldwide agreement and to Schedules 2 and 3, which govern the App Store and Custom App Distribution. Apple HomeView is not offered for sale in the European Union.

Why: Apple describes the revision as supporting "new features and updated policies" and providing "clarification." The news post and the contract differ on the tax provisions, the post cites definitions for HomeView that do not appear in the published text, and no redline shows what changed in Section 3.2, so the precise scope of several changes depends on the binding version in each developer account.