Apple Developer Program License Agreement changes after WWDC26 give developers a clearer view of where Apple is taking its platforms: more artificial intelligence, more privacy-sensitive frameworks, more identity verification, more child and teen safety language, and tighter rules around how apps use system technologies.
Apple published the updated Apple Developer Program License Agreement and App Review Guidelines on June 8, 2026, the same day WWDC26 opened. The timing is not unusual. Apple often updates developer agreements around WWDC to support new platform features, operating system releases, frameworks, and policies. This year’s update is more meaningful because it arrives as Apple expands Apple Intelligence, Siri AI, Foundation Models, App Intents, and new system-level APIs that give apps deeper access to user context and device behavior.
For developers, the update is not only paperwork. The agreement defines what developers can do with Apple software, SDKs, services, models, APIs, App Store Connect, and app distribution. When Apple adds new AI frameworks or changes privacy rules, those changes eventually become legal and operational requirements. A developer can watch the keynote, adopt the SDK, and build new features, but the updated license agreement decides the conditions for using them.
The main message is that Apple wants developers to build more capable apps while accepting more responsibility. AI features must follow Apple’s model rules. Sensitive content tools must be used within their intended limits. Suggested Actions and Trust Insights come with specific requirements. Apps serving minors face more attention. Developer identity and export compliance are becoming more formal. Analytics may reach developers through more channels, including Xcode and the App Store Connect API.
That is the post-WWDC26 developer reality: more opportunity, more integration, and less room for treating platform access as a loose technical privilege.
Apple Developer Program License Agreement Moves AI Into Its Own Category
The most visible shift is the way Apple reorganized AI and machine learning terms. The updated agreement groups AI and machine learning technologies under a new subsection and updates requirements for the Foundation Models framework. Apple also updated terms for the use of and access to Apple models.
That matters because Apple is no longer treating AI as a scattered collection of developer tools. Foundation Models, Apple Intelligence, Siri AI, and app-level AI features are becoming a platform layer. Developers will increasingly build apps that call models, generate structured output, use tool calling, interact with personal context, or expose app actions to the system.
The Foundation Models framework is especially significant. It gives developers a way to build with Apple’s models, including on-device and Private Cloud Compute models designed for Apple Intelligence. WWDC26 expands that story with multimodal and agentic app experiences, where apps can use language model sessions, guided generation, and tool calling to create more useful workflows.
The license update signals that Apple wants to control this carefully. Developers are not simply receiving a free-form AI sandbox. They are receiving access to Apple-controlled model capabilities under platform rules. That likely affects how apps present AI features, handle user data, generate content, connect model output to app actions, and describe Apple-powered features in marketing.
For developers, the practical step is to review any app using Foundation Models, Apple Intelligence, Siri integration, App Intents, or machine learning features before shipping updates built with the WWDC26 SDKs. The technical question is not only whether a feature works. It is whether the feature complies with the updated AI terms.
AI also changes liability. If an app uses Apple models to generate output, summarize content, suggest actions, or automate workflows, the developer still has responsibilities around user experience, safety, accuracy, privacy, and misuse. Apple may provide the model access, but the app owner is still responsible for how the feature appears inside the product.
Identity and Export Compliance Become More Formal
Apple also updated Sections 3.1 and 14.8 to specify requirements for providing information and responding to questions about developer identity, including in the context of export compliance. This is a less flashy change than the AI rules, but it could be one of the more operationally important updates for development teams.
Developer identity has become more sensitive across app distribution. Governments, marketplaces, payment systems, and platform operators all face pressure to know who is distributing software, where they operate, and whether they comply with trade, sanctions, tax, consumer protection, and export-control rules. Apple already verifies developer accounts, legal entities, banking information, and agreements through the Apple Developer Program and App Store Connect. The updated wording suggests Apple wants stronger authority to ask questions and expect answers.
Export compliance is especially relevant for apps that include encryption, security tools, certain enterprise functions, data-transfer capabilities, or technologies that may be subject to trade restrictions. Many developers already encounter export compliance questions in App Store Connect. The updated license language puts identity and export-related cooperation more explicitly into the agreement.
For small developers, this may only mean keeping account information accurate and responding if Apple asks for clarification. For larger teams, it reinforces the need for internal ownership of compliance. Developer account details, legal entity information, D-U-N-S records, tax forms, banking information, app encryption declarations, and App Store Connect metadata should not be treated as one-time setup tasks.
This also affects contractors, agencies, and companies with multiple developer accounts. If Apple asks who controls an app, where the company operates, or how a technology is being used, the account holder needs to be able to answer. A messy account structure can become a launch risk.
Minor Safety Is No Longer Background Language
The updated App Review Guidelines introduction now includes revised kid and teen safety guidance, and the Developer Program License Agreement update also specifies requirements in Section 7.9 around providing app information in App Store Connect and protecting end users who are minors.
This is part of a larger platform trend. Apple has already introduced age-related developer tools and policies, including the Declared Age Range API in certain regions. Regulators are putting more pressure on platforms and developers to protect minors, verify age where required, and ensure age-appropriate experiences. Apple’s updated language makes clear that developers have their own responsibilities, not only Apple.
The App Review Guidelines now emphasize that many kids and teens use apps to communicate, create, learn, and become more independent, while developers must do their part to provide age-appropriate experiences. This is not only a content moderation issue. It touches onboarding, account creation, social features, messaging, user-generated content, advertising, recommendations, purchases, parental controls, and data collection.
Developers should treat this as a metadata and product-design issue. App Store Connect age ratings, privacy nutrition labels, content descriptions, user-generated content controls, reporting tools, blocking features, and moderation workflows all need to match the actual app experience. If an app allows social interaction, public profiles, uploads, location sharing, chat, dating-like behavior, creator monetization, or algorithmic discovery, it should be reviewed through a minor-safety lens.
The risk for developers is inconsistency. An app may claim one age rating, describe itself as safe for general users, but include features that expose younger users to unsuitable content or contact risks. Apple’s revised guidance gives App Review more room to question that gap.
For developers building family, education, social, gaming, fitness, entertainment, or creator apps, this update should trigger a review of age ratings and safety flows before the next major submission.
New Frameworks Bring New Responsibilities
The updated license agreement specifies requirements for several frameworks and APIs, including Sensitive Content Analysis, Suggested Actions, Trust Insights, Media Device Extension, Spatial Audio Extension APIs, Customer Engagement APIs, and Passes privacy requirements.
This is Apple’s usual pattern when it opens more system capability to developers. A new framework can make apps more powerful, but Apple typically ties sensitive access to strict usage rules. The more a framework interacts with user content, device behavior, media, identity, customer engagement, or privacy-sensitive signals, the more carefully Apple defines its permitted use.
Sensitive Content Analysis is a good example. It can help apps detect sensitive visual content and protect users, but it also touches private material. Developers using it need to make sure the feature is used for appropriate safety purposes, presented clearly, and not turned into unnecessary surveillance or profiling.
Suggested Actions also deserves attention. If an app can participate in suggested user actions, the developer needs to think about relevance, user intent, and privacy. Suggestions that feel helpful can improve the experience. Suggestions that feel manipulative, spammy, or contextually wrong can create App Review problems.
Trust Insights is another sign that Apple is giving developers access to system-level signals while controlling their use. Any framework connected to trust, safety, fraud prevention, or user confidence requires careful handling because misuse can affect users, developers, and Apple’s platform integrity.
Customer Engagement APIs point to another area Apple is formalizing. Developers want better ways to interact with customers, but Apple remains sensitive to spam, unsolicited messages, misleading prompts, and abuse of system surfaces. This also connects with the updated App Review Guideline language around Live Activities, which clarifies that Live Activities may not be used to spam, phish, or send unsolicited messages.
The message is consistent: Apple is expanding developer tools, but not allowing every system surface to become a marketing channel.
App Review Guidelines Tighten Quality and Spam Signals
The App Review Guidelines changes after WWDC26 include updates to sections around safety, spam, and app duplication. Apple says guideline 1.2 now includes a new paragraph clarifying developer responsibilities for content that violates the guideline. Sections 4.3(a) and 4.3(b) clarify the basis for the guideline and add examples. Section 4.5.3 clarifies that Live Activities may not be used to spam, phish, or send unsolicited messages.
Guideline 4.3 has long been associated with spam and app duplication. Apple has pushed back against developers submitting many similar apps, low-value clones, template-based products, or apps that do not offer enough distinct value. Clarifying this area after WWDC26 suggests Apple wants to keep the store cleaner as AI tools make it easier to generate apps, content, descriptions, images, and code quickly.
That matters in 2026 because generative AI can flood app marketplaces with shallow software. Developers can generate wrappers, image tools, chat apps, content utilities, and template apps faster than before. Apple’s App Review team will likely pay closer attention to whether an app offers a genuine product experience or only repackages common functionality with minimal differentiation.
Live Activities are another area where Apple is drawing a line. A Live Activity is designed for timely, glanceable updates, such as a delivery, ride, timer, sports score, or active event. It is not meant to become a persistent ad, phishing surface, or notification loophole. Developers using Live Activities should make sure the feature is tied to a real-time user-initiated activity and ends when that activity ends.
This is especially important for commerce, delivery, sports, media, travel, finance, and event apps. A useful Live Activity can improve retention. A spammy one can create rejection risk.
App Store Connect Information Carries More Weight
The updated agreement’s reference to providing information regarding apps in App Store Connect is a reminder that metadata is not administrative filler. Apple relies on App Store Connect information to evaluate apps, apply policies, determine ratings, support users, manage compliance, and review business models.
Developers should make sure app descriptions, screenshots, privacy labels, age ratings, in-app purchase information, account deletion details, export compliance declarations, support URLs, and review notes are accurate. If an app uses AI, sensitive content analysis, user-generated content, subscriptions, health information, kids’ features, pass-related functionality, or regulated services, the review notes should clearly explain what the app does and how sensitive features are controlled.
Poor metadata can create rejection risk even when the app itself is functional. A review team cannot approve what it cannot understand. The more Apple expands AI and privacy-sensitive frameworks, the more developers need to explain their use cases precisely.
This is also where Rank Math-like clarity matters for app submissions, even though App Store Connect is not a website SEO tool. The title, subtitle, description, privacy information, review notes, and screenshots should align. If a product claims to be an AI assistant, the app should explain what the assistant does, what data it uses, whether output is generated on device or through cloud services, and how the user remains in control.
Developers should also check whether the updated agreement blocks any workflow until acceptance. Apple’s App Store Connect help states that when a new Paid Apps Agreement is available, developers may be unable to create a new app or in-app purchase until the latest agreement is accepted. The Account Holder role is required to sign agreements, so teams should not wait until release day to discover that the person with authority is unavailable.
Analytics Expands Through Xcode and App Store Connect API
Apple updated Section 6.7 to specify that analytics may additionally be provided through Xcode and the App Store Connect API. This is a practical change for development teams because app performance, distribution, crashes, adoption, and business metrics increasingly need to flow into developer workflows.
Analytics inside App Store Connect is useful, but many teams also want data in dashboards, CI pipelines, internal reports, and release-monitoring systems. API access can make that easier. Xcode integration can bring performance or distribution signals closer to where developers already work.
The change also reflects Apple’s broader attempt to make development more continuous. Developers do not only submit an app and wait. They monitor adoption, crash rates, engagement, conversion, subscriptions, reviews, in-app purchases, TestFlight feedback, and performance. Better analytics access can help teams catch issues earlier.
There is a compliance side too. Analytics should be used responsibly, especially when apps involve minors, sensitive categories, or user privacy concerns. Developers should not assume that more analytics access means fewer privacy obligations. Apple’s wider platform direction remains clear: collect what is needed, explain it accurately, and respect user consent and policy limits.
In-App Purchase and Passes Get Clarified
The updated agreement clarifies requirements for use of the In-App Purchase API and updates privacy requirements for Passes. These changes may not affect every app, but they matter for developers in commerce, subscriptions, loyalty, ticketing, transit, events, membership, finance, and wallet-related experiences.
In-App Purchase remains one of the most scrutinized parts of Apple’s developer rules. Developers offering digital goods, subscriptions, premium features, credits, content, or services inside apps need to understand when IAP is required and how the API may be used. Apple regularly updates language in this area because business models keep changing and regulators continue to challenge App Store payment rules in different regions.
Passes are also privacy-sensitive because they can relate to identity, membership, travel, purchases, entry, loyalty, events, or financial interactions. Updated privacy requirements indicate Apple wants developers to treat passes as more than visual cards. They are user-facing credentials or service objects that can carry personal information and location or transaction context.
Developers working with Wallet passes should review what data is included, how it is stored, how it is updated, and how users are informed. A pass should not collect or expose more information than needed for its function.
What Developers Should Do Now
The first step is simple: the Account Holder should sign in to the Apple Developer account and accept the updated terms. Teams should confirm whether the Paid Apps Agreement or related schedules also need attention in App Store Connect, especially if they sell paid apps, subscriptions, or in-app purchases.
The second step is an AI audit. Any app using Apple Intelligence, Foundation Models, machine learning frameworks, generated content, model-powered summaries, tool calling, personal context, or Siri-related features should be reviewed against the updated agreement. Developers should document what data the feature uses, whether processing is on device or cloud-based, what output is generated, and what user controls exist.
The third step is a safety and metadata review. Apps with minors, social features, user-generated content, messaging, creator tools, public profiles, or sensitive content should recheck age ratings, moderation, reporting, blocking, parental controls, and App Store Connect descriptions.
The fourth step is a framework review. Teams using Sensitive Content Analysis, Suggested Actions, Trust Insights, Media Device Extension, Spatial Audio Extension APIs, Customer Engagement APIs, Passes, EnergyKit, or In-App Purchase should review the new requirements before submitting major updates built with the WWDC26 SDKs.
The fifth step is a release-process check. Legal, product, engineering, and App Store Connect owners should know who can accept agreements, who maintains compliance documents, and who responds to Apple if questions come in. A blocked release because the right person has not accepted terms is avoidable.
The Agreement Shows Where Apple Is Going
The updated Apple Developer Program License Agreement is not only a legal document. It is a map of Apple’s platform priorities after WWDC26. Apple is pushing developers toward AI-powered apps, deeper system integration, smarter actions, richer media, stronger safety controls, and more precise App Store compliance.
The trade-off is that developers must accept more responsibility. If an app uses Apple models, the developer must understand the model rules. If an app serves minors, the developer must protect them beyond a basic age rating. If an app uses system suggestions, trust signals, Live Activities, customer engagement tools, or Passes, the developer must avoid turning those surfaces into spam, surveillance, or unclear data collection.
For developers who treat compliance as part of product design, the update is manageable. It gives them a framework for building with Apple’s newest technologies without waiting for App Review problems later. For developers who treat the agreement as an obstacle clicked through at the end, WWDC26 makes that approach riskier.
Apple’s developer ecosystem is moving into an agentic AI phase, where apps are expected to expose actions, understand context, work with Siri AI, and use models responsibly. The updated agreement is Apple’s way of saying that the next generation of apps will need both technical ambition and stricter discipline.
https://developer.apple.com/documentation/foundationmodels