Apple Developer Agreement October 2026: What Changed and What App Teams Must Do
Apple revised its Developer Program License Agreement on October 13, 2026. This guide separates the contract update from the App Review Guidelines and turns the changes into a practical team action plan.
Executive summary
What matters most
The October 13 release updates the agreement, not the App Review Guidelines.
Every team should review the new security language. Feature-specific work depends on the APIs, surfaces, sales model, and regions you use.
The current agreement is version LYL260. EU Attachment 14 was already effective from October 1, 2026, or the later acceptance date.
Update your privacy policy or EULA only when the app's real data, payment, support, distribution, or license practices changed.
Scope check
Agreement, not guidelines
Apple's October 13 notice announces changes to the Developer Program License Agreement. The last announced App Review Guidelines revision before this date was June 8, 2026.
October 13, 2026
Developer agreement revised
June 8, 2026
Latest announced guideline revision
The source record
What Apple published on October 13
Apple's October 13 announcement names changes across the main agreement and the paid application schedules. The copy reviewed for this guide is marked version LYL260 and dated October 13, 2026. Apple says the English version accepted in the developer account is the binding and most current version, so use the public agreement as a review aid and confirm the account copy before accepting it.
The update does not create the same task for every developer. A practical review starts by identifying which changed sections map to your products, regions, APIs, sales model, and team roles.
Change 01
Security requirements are more explicit
Agreement 3.2
The revised section prohibits products or code that interfere with Apple security, digital signing, verification, or authentication. It also bars conduct that harms the security, integrity, or availability of a user, network, computer, or communications system.
The wording also calls out several implementation risks directly:
Deceiving people about a product's identity, purpose, or behavior, including harmful changes after review
Impersonating Apple or another party to obtain credentials or sensitive information
Intentionally weakening security or privacy protections, or implementing them differently from the way they were described
Collecting or transmitting user data beyond what was disclosed when consent was requested
Using a person's device or network resources to serve third parties without explicit prior consent
This is wider than a penetration-testing checklist. Product, security, privacy, and release teams should compare the submitted behavior, consent copy, SDK behavior, remote configuration, and post-review feature flags. If a backend or SDK can change behavior after review, document the guardrails around that path.
Change 02
Two capabilities now have specific contract terms
Live Assistance API
At the user's invitation, an app or corresponding product may use this API only to let an accessibility service provider join the user's FaceTime call to provide an accessibility service, such as captioning or translation.
Section 3.3.8(j)
App Replacement Entitlement
A replacement app may use the entitlement only when the original and replacement apps are under the same Developer Program membership and have substantially the same primary purpose and functionality.
Section 3.3.8(k)
The App Replacement Entitlement displays a system sheet on first launch that lets a person move data and settings from the original app and delete it. A shared owner is not enough by itself. Teams should document why the two apps have substantially the same primary purpose and functionality, and test the data migration and deletion path.
Change 03
HomeView and CarPlay create a new suitability check
Agreement 6.4, 6.4.1, 6.4.2
Apple may make an iOS app widget available on CarPlay and Apple HomeView. The developer is responsible for deciding whether the widget is functional and suitable for CarPlay, and for using disfavoredLocations when it is not. Apple gives extensive interaction while driving and a locked-iPhone dependency as examples of unsuitable behavior.
If an app has a CarPlay entitlement in a category identified by Apple, Apple may also make that app accessible on HomeView while it runs on a paired iPhone. Inventory every widget and entitled app, test it in the intended context, and explicitly disfavor a surface when the experience is unsafe, nonfunctional, or misleading.
Change 04
Paid subscriptions can serve groups and organizations
Apple's announcement lists new terms in Schedule 2 for selling multiple seats of a subscription through Group Purchases. It also lists Schedule 3 changes for offering subscriptions to Apple Business Manager and Apple School Manager organizations through Volume Purchasing.
This affects more than a price screen. Subscription owners should review seat access, entitlement changes, renewal behavior, support ownership, refunds, account transfer, and the product's organization-level onboarding. The public announcement is a change summary, so teams using these options should review the full Paid Applications Agreement accepted in App Store Connect before configuration or launch.
The same schedules now say Apple will report legally required tax, sales, and contact information to tax authorities. If Apple shares customer tax information with a developer, the developer may use it only for purposes required by law. Restrict access, retention, and downstream use accordingly.
Change 05
EU Attachment 14 is already in effect
Attachment 14 was introduced in August and became effective on October 1, 2026, or when the Account Holder accepted the agreement, whichever was later. It replaces the prior Alternative Terms Addendum for Apps in the EU and StoreKit External Purchase Link Addendum for Apps in the EU. It is not a new October 13 feature, but it is part of the current agreement and belongs in the same account review.
Under the current terms, an app in an EU storefront can use Apple In-App Purchase, alternative payment processing, actionable out-of-app offers, or an allowed combination. The choice carries design, reporting, support, tax, child-safety, and commission obligations.
EU App Store commission snapshot
Rates shown from the current terms checked October 15, 2026
| Payment route | Standard | Qualifying reduced |
|---|---|---|
| Apple In-App Purchase | 26% | 15% |
| Alternative payment processing in the app | 20% | 10% |
| Actionable out-of-app offer | 15% | 10% |
Reduced rates depend on program or subscription status. Out-of-app commissions apply to qualifying promoted digital sales initiated within seven calendar days after the link action. Check the current agreement and Apple's EU support page for definitions, exceptions, alternative-distribution terms, and tax treatment.
Operational requirements teams can easily miss
A payment-option election generally remains in effect for 12 months and applies across EU storefronts.
Apple In-App Purchase must be offered at least as prominently when it appears with another payment option.
Alternative payment options for minors require the protections specified in Attachment 14.
Alternative payment providers must meet the stated payment-security requirements.
The developer must support disputes, subscriptions, and refund requests.
Applicable alternative-payment transactions must be reported to Apple monthly within the required deadline.
Model the full cost and operating burden before selecting a payment route. A lower commission does not by itself account for payment processing, tax handling, refunds, fraud, reporting, customer support, or the 12-month election period.
Action plan
What app teams should do now
Account Holder
Open the developer account, review the exact agreement presented there, accept it when authorized, and check the status of the Paid Apps Agreement in App Store Connect.
Engineering and security
Map section 3.2 to authentication, SDKs, remote configuration, post-review changes, consent boundaries, device resources, and incident controls.
iOS product team
Identify any use of Live Assistance, App Replacement, widgets, CarPlay, or HomeView. Confirm eligibility, purpose limits, user initiation, and surface suitability.
Monetization and finance
Review Group Purchases, Volume Purchasing, tax-data access, EU payment elections, commission assumptions, monthly reporting, refunds, and support ownership.
Privacy and legal operations
Update the privacy policy, EULA, consent copy, or support terms only where the implemented data flow, payment path, distribution model, or user relationship changed.
Release manager
Keep evidence of the review, put entitlement and payment details in App Review notes when relevant, and verify the current agreement and guidelines again before submission.
If your app's data or user terms changed, review our evergreen guide to the Apple developer agreement privacy policy and EULA requirements. You can also use the iOS privacy policy generator and EULA generator as drafting starting points, then compare the drafts with the app's real behavior and the terms accepted in your account.
Next step
Bring your app documents back in sync
Draft an iOS privacy policy or EULA from your actual app practices. Review the result against your SDKs, App Privacy answers, payment flows, user terms, and the latest Apple agreement before publishing.
Common questions
Frequently asked questions
What changed in the Apple Developer Program License Agreement in October 2026?
Apple updated security requirements, added terms for the Live Assistance API and App Replacement Entitlement, addressed widgets and CarPlay apps on Apple HomeView, added subscription purchase options for groups and organizations, and clarified tax information handling in the paid application schedules.
Did Apple also change the App Review Guidelines on October 13, 2026?
No update to the App Review Guidelines was announced on October 13. Apple's latest announced guideline revision before that date was June 8, 2026. The current guidelines still apply, so teams should check both sources before submitting an app.
Who can accept Apple's updated developer agreement?
The Account Holder is the role that accepts updated agreements for the developer membership. The Account Holder must also sign the Paid Apps Agreement when the organization sells paid apps or offers In-App Purchases.
Do the October 2026 changes affect every app?
The agreement applies broadly, but the operational impact depends on the app. Teams using the new APIs, HomeView or CarPlay surfaces, paid subscriptions, EU alternative payments, or alternative EU distribution have the most specific implementation work.
Do we need to update our privacy policy or EULA?
Not automatically. Update those documents when the app's real data handling, payment flow, support process, distribution model, or user terms change. Do not add disclosures for features or data flows the app does not use.
Evidence
Primary sources
This article is general information, not legal advice. It summarizes Apple's public announcement, the Developer Program License Agreement marked LYL260, App Review Guidelines, and App Store Connect help as checked on October 15, 2026. The version accepted in your developer account controls. Review the current terms and get qualified advice for your app, regions, payment model, and organization.