Skip to content

Developer Tools10 min read

Apple Developer Program License Agreement, October 2026: what changed

Apple revised its developer agreement on October 13 and 29, 2026: five new prohibitions in 3.2, terms for Live Assistance, App Replacement and HomeView, multi-seat subscriptions, tax data and 26% in Taiwan.

On October 13, 2026 Apple published a revised Apple Developer Program License Agreement with eight changes, three days before the App Review Guidelines update. On October 29 the agreement was revised again, this time for the Taiwan storefront. The footer of the agreement page now says that the agreement and Schedule 1 were last updated on October 29, 2026, and Schedules 2 and 3 on October 13, 2026. Apple promises translations within a month.

Apple's changelog names the sections but not the new wording. So we compared the agreement text from an October 11 snapshot in the Internet Archive with the current page, line by line. Below is what was actually added, who it affects and what we would check. We ship our own apps through the App Store, and where we interpret the text, we say so.

Note

The binding version is the one you accept in your developer account: Apple notes at the bottom of the page that the website copy is provided for convenience. This article is a developer's reading of the text, not legal advice.

The changes at a glance

SectionWhat changedWho should check
3.2Five new prohibitions: deception including post-review changes, phishing, weakened protections, data beyond consent, device resources for third partiesEveryone, especially apps with third-party SDKs, VPN and security apps
3.3.8(J)Terms for the Live Assistance API: accessibility services in FaceTime calls, at the user's invitationAccessibility service providers
3.3.8(K)Terms for the App Replacement EntitlementDevelopers who replace an app with a new one
6.4–6.4.2Widgets and CarPlay apps on Apple HomeViewApps with widgets or CarPlay support
Schedule 2Group Purchases: one subscriber buys seats for a groupApps with auto-renewable subscriptions
Schedule 3Volume Purchasing through Apple Business and Apple School ManagerApps with subscriptions for organizations
Schedules 2 and 3, 3.3Reporting to tax authorities; customer tax data only for legal purposesEveryone who sells on the App Store
Attachment 15, October 2926% commission in Taiwan from October 31Apps that sell on the Taiwan storefront

Section 3.2: five new prohibitions

Section 3.2 lists the conditions for using Apple software and services. One of its items already prohibited code that disables Apple's security mechanisms or violates the security of systems. On October 13 Apple added five more cases to the same item. You may not create a product, code or program that would:

  • deceive about the identity, purpose or behavior of the product, including through post-review modifications that would cause harm to others, end users or Apple;
  • impersonate Apple or a third party to solicit credentials or other sensitive information;
  • implement security or privacy protections that are intentionally weakened or inconsistent with what is described;
  • access, collect or transmit user data beyond what was disclosed when consent was requested, whether through your own code or someone else's;
  • use the end user's device or network resources to provide services to third parties without the user's explicit prior consent.

The first item is the contract version of guideline 2.5.19 against bait-and-switch apps, which Apple published three days later. Changing an app after approval is now a breach of the agreement itself, not only of the App Review rules.

The other four read to us like a list of known abuse patterns. Our interpretation of what they mean in practice:

  • "Someone else's code" covers third-party SDKs. If an analytics or ads SDK collects more than you disclosed in the consent prompt and in your privacy labels, the responsibility is yours.
  • "Inconsistent with what is described" ties the implementation to your own claims. If the listing promises end-to-end encryption or no logs, the code has to match. For VPN, password and messaging apps this is the item to reread.
  • Device and network resources cover SDKs that sell a user's bandwidth as a proxy exit or run computations for someone else. Such a mode now needs explicit consent before it starts. A VPN feature where a user's device relays other people's traffic falls here too.

Section 4 of the agreement also reminds that new requirements do not apply retroactively to apps already in distribution, but Apple reserves the right to remove apps that do not comply with them at any time.

Live Assistance API

The new section 3.3.8(J) and a matching definition describe the Live Assistance API, which lets an app connect to an end user's FaceTime call. The terms are narrow. The app may use the API only at the end user's invitation and solely so that an accessibility service provider can join the call and provide accessibility services; the agreement gives captioning and translation as examples. In our reading, recording calls, analyzing conversations or adding a general-purpose assistant falls outside these terms.

App Replacement Entitlement

Section 3.3.8(K) covers a new entitlement for apps that replace other apps. On the first launch of your replacement app, the system shows a sheet that offers the user to move data and settings from your original app and to delete the original. There are two conditions: both apps must be under your Developer Program membership, and they must have substantively the same primary purpose and functionality.

This helps when an update to the existing app is not an option, for example when a rewrite ships under a new bundle ID. It does not let you move users to an app with a different purpose or to another developer account. The agreement does not say how to request the entitlement, and at the time of writing we did not find a separate documentation page for it, so check Apple's entitlement documentation before you plan a migration around it.

CarPlay and Apple HomeView

Section 6.4 used to cover only iOS app widgets on CarPlay. It is now called CarPlay and Apple HomeView and has two subsections. Under 6.4.1 your iOS app widget may be made available on CarPlay and Apple HomeView; you are still responsible for checking whether the widget is functional and suitable for CarPlay and for using disfavoredLocations if it is not. Under 6.4.2, if your app includes a CarPlay entitlement profile in a category that Apple identifies in its documentation, Apple may provide access to the app on Apple HomeView while it runs on a paired iOS device.

Apple's CarPlay page says that CarPlay audio and video apps also work on Apple HomeView without any modifications to the app. If you have such an app, you agree to this by accepting the terms, so look at how it behaves on the new screen.

Group Purchases and Volume Purchasing

The largest part of the update is in Schedules 2 and 3, which govern paid apps and custom apps. They introduce subscriptions with several seats:

  • A Group Purchase is an auto-renewable subscription that a user, the Group Organizer, buys to share with a group of people. Everyone who gets access becomes a Group Member and counts as an End-User.
  • A Volume Purchase is an auto-renewable subscription that an organization buys through Apple Business or Apple School Manager to share among its people.

Section 3.8(c), which covers refunds when a subscription is not delivered as marketed, got rules for seats. Apple may refund the organizer or the organization the full price of the purchase or the price of unused seats, but does not give partial refunds for a seat that an active Group Member uses. If you host and manage invitations yourself, Apple decides whether a seat is in use based on the information you provide.

According to Apple's announcements from September and October, Volume Purchasing launched on October 22, 2026. Group Purchases can be tested in a Sandbox Apple Account starting in November and will reach the App Store this winter. Apple suggests preparing by making sure your apps use StoreKit 2.

Warning

Multi-seat purchasing is enabled by default for auto-renewable subscriptions in App Store Connect, unless you changed this setting earlier. Your subscription may already be available through Apple Business and Apple School Manager.

The setting is in the purchase options of each subscription and in the App Store Connect API: the multiSeatStatus attribute turns multi-seat purchases on or off, and marketSettings chooses between the App Store, Apple Business and Apple School Manager. Turning on Family Sharing disables multi-seat purchasing automatically. If you disable it, existing multi-seat subscribers keep renewing at their current seat count but cannot add seats, and Schedule 3 warns that such changes may remove the subscription from Apple Business or Apple School Manager. A request that keeps a subscription single-seat looks like this:

bash
curl -X PATCH "https://api.appstoreconnect.apple.com/v1/subscriptions/$SUBSCRIPTION_ID" \
  -H "Authorization: Bearer $ASC_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"data":{"type":"subscriptions","id":"'"$SUBSCRIPTION_ID"'","attributes":{"multiSeatStatus":"DISABLED"}}}'

If you leave it on, check how your backend links a subscription to an account. A server that assumes the person who paid is the person who uses the app will break when seats go to colleagues or group members.

Taxes: reporting and limits on customer data

Section 3.3 of Schedules 2 and 3 got two new paragraphs. Under (a), information you give Apple under these schedules may be disclosed to tax authorities to the extent required by law, and that disclosure is not a breach of Apple's confidentiality obligations to you; Apple's announcement describes it as reporting tax, sales and contact details. Under (b), if Apple discloses information to you because the law requires it, including tax information about End-Users, you may use it only to comply with tax obligations such as reporting, remittance and audits, and for no other purpose. In practice, such data should not end up in a CRM, mailing lists or analytics.

October 29: 26% in Taiwan

The second revision added Attachment 15. Starting October 31, 2026, the commission for standard Apple In-App Purchase and paid app transactions on the Taiwan storefront of the App Store on iOS and iPadOS is 26% instead of 30%. Apple says the change follows discussions with the Taiwan Fair Trade Commission, and you do not need to sign the updated terms by October 31 to get the new rate.

Edits outside the changelog

The comparison also shows edits that Apple did not list: the iWork API is now called the Creator Studio API, and several typos and quotation marks were fixed. We found no other substantive changes in the text.

What to do now

  • The Account Holder should sign in to the developer account and accept the updated terms; other roles cannot do it. Under section 4, if you do not agree to new terms, Apple suspends or terminates your use of its software, certificates and services.
  • Review the third-party SDKs in your apps against the new items of 3.2: what data they collect beyond your consent prompt and whether they use the device or network for other parties.
  • Compare the security and privacy claims in your listing and on your site with what the code actually does.
  • Make sure nothing changes the app's behavior after review in a way you did not describe, and read this together with guideline 2.5.19.
  • For each auto-renewable subscription, decide whether multi-seat purchasing should stay on and in which markets, and test Group Purchases in Sandbox once it opens in November.
  • If you have a CarPlay audio or video app, check how it works on Apple HomeView; if a widget is not suitable for CarPlay, use disfavoredLocations.
  • Use the tax information about customers that you receive from Apple only for tax purposes.
  • If you plan to replace an app with a new one, look at the App Replacement Entitlement before you release the new app.

Sources

ShareXLinkedIn

ONLYAPPS Team

Novi Sad, Serbia · onlyapps.org

Contact

We use analytics cookies only with your consent. Essential cookies keep the site working. Privacy policy