app_intents_annotations

The last of the Xcode 27 work that a Simulator can settle: entities can travel between apps in both directions, long-running intents report progress and hear about cancellation, and a handler can ask the user for a missing value mid-run. Two fixes change behavior you may notice — see Heads-up below.

Heads-up

FlutterBridge-mode intents never reached their handler — regenerate your Swift

The generated perform() invoked the Dart handler with the Swift struct name, while the generated Dart registers under @IntentSpec.identifier. So no background (FlutterBridge) intent could ever find its handler. The golden test asserted the same wrong string, which is why it went unnoticed. Regenerate with generate_swift; URL scheme and foreground (cache) intents were already correct.

The codegen CLIs now fail on an invalid annotation (#138)

generate_swift, generate_widget_swift and generate_kotlin exit 1 when an analyzer rejects an annotation, printing the file and the problem. Previously the error became a Warning: Could not analyze … line, the spec was left out of the output, and the command still exited 0 — a project whose only specs were invalid got empty output and a green build. If a build that used to pass stops here, that spec was never being generated. A file that fails to resolve is still skipped with a warning.

Relevant-entity donation wiring gains an operation argument

If you wired #55, AppIntentsPlugin.relevantEntitiesDonationForwarder and the closure passed to FlutterBridge.registerRelevantEntitiesDonator now take an operation (update / remove / removeAll). Update AppDelegate — see docs/usage.md.

Progress, cancellation and requestValue (ADR 0010)

A long-running intent's perform() now opens an execution scope and hands its id to Dart. Inside the handler, AppIntentExecution.current gives you:

• reportProgress(fraction) / reportProgressUnits(completed, total) (#130)
• isCancelled / cancelled — onCancel: is forwarded to Dart instead of being a comment stub (#130). AppIntents().onIntentCancellation observes the same from outside a handler.
• requestValue<T>(parameter) for a parameter declared @IntentParam(requestValue: true) — the system prompts the user and the call resumes with the answer (#131). Optional primitive parameters only: the system already asks for a missing non-optional one on its own.

Generated handler signatures did not change — the scope reaches the handler through a Zone, not a new argument. Wire AppIntentsPlugin.intentProgressForwarder, intentValueRequestForwarder and FlutterBridge.setCancellationNotifier in AppDelegate.

Cross-app entities (ADR 0002)

• Place export (#128). @EntitySpec(exportAs: EntityExportType.place) exports a GeoToolbox.PlaceDescriptor, built from fields marked @EntityExportField(EntityExportRole.latitude / .longitude / .address).
• Import (#129). @EntitySpec(importable: true) generates ValueRepresentation(exporting:importing:); resolve the incoming value with AppIntents().registerValueImportHandler. It rides the value-query bridge, so there is no new native wiring.
• Why there is no currency export. ValueRepresentation(exporting:) is only declared for IntentPerson and _SystemIntentValue conformers. IntentCurrencyAmount exists in the SDK but is neither, so generated Swift using it does not compile — measured against the iOS 27.0 SDK, not assumed.

Donations and discovery (ADR 0003)

• Dual identifiers (#132). @EntityStableId + @EntitySpec(syncable: true) gives the entity a SyncableEntityIdentifier<String, String> for entities whose @EntityId is local to the device. Using such an entity as an @IntentParam(entityType:) value is a generation error.
• Removal (#133). AppIntents().removeRelevantEntities / removeAllRelevantEntities. Unlike donating an empty list, these can clear across every context.
• Re-indexing (#133). IndexedEntityQuery behind --experimental=reindexing.
• Union value queries (#133). @UnionValueSpec(valueQuery: true) generates an IntentValueQuery that can answer with several entity types.

AppIntentsPackage on a statically linked target (ADR 0008)

No code change, but a documented hazard: in a sibling project, declaring AppIntentsPackage on a statically linked target stopped App Intents from being ingested in TestFlight / App Store builds only — the same build ran fine from Xcode. Removing the declaration fixed it. Static linking already merges the metadata without it, so don't reach for --app-intents-package unless you cross a dynamic link boundary. The CLI help now says so.

Not verified on device yet

Siri's progress UI for a long-running intent, the actual IntentCancellationReason strings, and the prompt requestValue raises have been compiled and unit-tested, not seen on hardware.

Full Changelog: v0.16.0...v0.17.0

Siri's result card and Smart Stack are both reachable from Dart now, without writing a SwiftUI view or a line of Swift. Four features that had been parked waiting on Xcode 27 turned out not to need it, so they ship ungated. If you use @EntitySpec(valueQuery: true), see Heads-up below.

Heads-up: IntentValueQuery graduated out of the experimental opt-in

IntentValueQuery (#51) is declared at iOS 26.0 and ships in the released iOS 26.5 SDK (Xcode 26.6), so #if APP_INTENTS_WWDC26 was never the right guard. The <Entity>ValueQuery struct is now emitted whenever @EntitySpec(valueQuery: true) is set, under @available(iOS 26.0, *).

• Already passing --experimental=value-query? No action required. The flag is still accepted and now reports itself as a no-op instead of being rejected.
• Set valueQuery: true without the flag? The query appears in your generated Swift for the first time — make sure a Dart <entity>ValueQuery handler exists.
• Everyone else is unaffected.

An entity that also opts into App Schema (#49) keeps its #if/#else pair, because the entity type itself is iOS 27 only in that branch.

Declarative snippet cards and richer result dialogs

@IntentSpec(snippet:) — a card in Siri's result without a SwiftUI view (ADR 0007)

SnippetTemplate / SnippetRow describe a fixed layout — optional SF Symbol, title, optional subtitle, LabeledContent rows — and codegen emits a self-contained SwiftUI <Intent>SnippetView returned with .result(view:). A Flutter app gets a Siri result card without supplying a SwiftUI view of its own.

Templates interpolate two things:

Placeholder	Available in
{paramName}	any execution mode
{result.key} — the Dart handler's returned map	FlutterBridge mode only

Using {result.…} on a URL scheme or foreground intent is a generation error, not a card that renders empty at runtime. {result.key} works in resultDialogTemplate too, and for any intent whose snippet or dialog reads it, the generated registration now returns the handler's value through the new intentResultPayload instead of discarding it. Every other intent's generated Dart is unchanged. Row labels are collected into the String Catalog.

Not experimental — ShowsSnippetView is iOS 16. The generated file gains import SwiftUI because .result(view:) lives in the _AppIntents_SwiftUI overlay.

IntentDialog(full:supporting:) (ADR 0006)

@IntentSpec gains resultDialogSupportingTemplate — the on-screen half, so the spoken line can skip context a reader already has — and resultDialogSystemImageName for an SF Symbol. Both require resultDialogTemplate and are a code generation error on their own rather than a silently dropped field. The symbol initializers are iOS 17.2+ while generated intents target iOS 17.0, so the symbol form is built behind if #available(iOS 17.2, *) with the symbol-less dialog as the fallback.

Not experimental — IntentDialog(full:supporting:) is iOS 16.

RelevantIntent donation for Smart Stack (#55, ADR 0009)

@WidgetConfigurationSpec(relevantIntents: true) makes generate_widget_swift emit a registerRelevantIntentDonator() plus a RelevantContext decoder, and Dart drives it with AppIntents().donateRelevantIntents(...) using RelevantIntentDonation / RelevantContextSpec.

Things worth knowing:

• Each call replaces the app's entire set. An empty list clears it. That is why there is one donator per generated file rather than per configuration — RelevantIntentManager.updateRelevantIntents is whole-set.
• Entity parameters are resolved through the cache-backed widget query, so the donated intent carries a full entity. Scalar parameters absent from a donation are left unset rather than defaulted.
• RelevantContext.location(_ exact: CLRegion) is deliberately not exposed — a CLRegion cannot be rebuilt from a map.
• iOS-only. AppIntentsBridge still imports only Foundation: the closure names RelevantIntent, the actor does not.

Not experimental — RelevantIntentManager is iOS 17; only the kind: date refinements are iOS 26 and they sit behind if #available.

Two ways a donation lost its dates, fixed

The generated decoder used a default ISO8601DateFormatter, which rejects the fractional seconds DateTime.toIso8601String() always emits. Every date / dateRange donation was silently dropped — and since the API replaces the whole set, a batch of only date donations cleared it instead of updating it. The decoder now tries fractional and second precision.

Separately, RelevantIntentDonation.toMap() now encodes DateTime parameter values as ISO-8601 strings, and a DateTime widget parameter is carried the same way: Flutter's standard method-channel codec cannot encode a DateTime at all, so a donation with one would have thrown before reaching iOS.

AppIntentsPackage generation (ADR 0008)

generate_swift and generate_widget_swift gain --app-intents-package <Name> and repeatable --include-package <Module.Type>, for sharing generated intents through a Swift package that several targets link.

Note what the declaration is actually for: metadata from a statically linked module already merges without it (Xcode SPM links statically by default). The declaration is what a dynamic link boundary needs — it is not a fix for a type missing from Metadata.appIntents.

generate_widget_swift --public is the companion flag: it emits the generated declarations as public, which that shared-module setup requires. Without it Swift's default internal hides the configuration intent, its parameters, the entities and the donator registration from an importing target — and a single-file swiftc -typecheck cannot reveal that, since the file compiles fine on its own.

Also in this release

• Placeholder parsing for dialog and snippet templates is now shared between the analyzer, the Dart generator and the Swift generator, and tolerates padding ({ result.x }). Each previously had its own regex, so a dialog reading {result.…} without a snippet had its handler result discarded on the Dart side while the generated Swift still read keys from it.
• scripts/verify_widget_module_swift.sh (new) builds the widget output as a module and compiles a consumer that imports it — the check that would have caught the --public gap.
• scripts/verify_experimental_swift.sh now type-checks the example's generated Widget Extension Swift too (nothing compiled that output before except an Xcode build), fixes a stale AppIntentsBridge source path broken since the module moved into the plugin's Swift package (#102), and can run against a stable Xcode — where it checks only the non-#if branch, which is what proves an ungated feature compiles without the iOS 27 SDK.
• make verify-swift runs the Swift type-checks against both Xcodes.
• Dependency bumps: androidx.appfunctions 1.0.0-alpha11, AGP, Gradle wrapper 9.7.1, actions/setup-java 6, source_gen, build_test.

app_intents_annotations is released in lockstep with the annotations the above require: @WidgetConfigurationSpec(relevantIntents:), SnippetTemplate / SnippetRow / @IntentSpec(snippet:), and @IntentSpec(resultDialogSupportingTemplate:, resultDialogSystemImageName:). All are additive and optional; existing specs are unaffected.

Full Changelog: v0.15.0...v0.16.0

Two follow-ups to the AppIntentsBridge distribution work in v0.14.0. If you added the Swift package by path in 0.14.0, see Migration below.

app_intents

Fix: import AppIntentsBridge did not resolve on the CocoaPods route (#105)

app_intents_bridge.podspec had no s.module_name, so CocoaPods derived the module name from s.name and emitted framework module app_intents_bridge. Every generate_widget_swift output opens with import AppIntentsBridge, so the generated code could not be built as generated by a CocoaPods consumer.

The failure was easy to misread: the import line itself often reported nothing, and only the types surfaced, as Cannot find 'AppIntentsEntityCache' in scope.

Fixed by declaring s.module_name = 'AppIntentsBridge'. All three routes now take the same import line. Verified against the generated modulemap, which now reads framework module AppIntentsBridge.

AppIntentsBridge is now a product of the plugin's own Swift package

v0.14.0 recommended adding the bridge from ios/.symlinks/plugins/…, but .symlinks is created only by flutter_install_all_ios_pods while CocoaPods evaluates a Podfile. An app that had migrated to Swift Package Manager and run pod deintegrate — which the Flutter tool itself suggests once every plugin is a Swift Package — had no version-following local path at all, and was left with .package(url:), the one route that is not pinned to the pub version.

AppIntentsBridge is now a second product of the plugin's own Swift package, so the recommended route is:

File → Add Package Dependencies… → Add Local… → ios/Flutter/ephemeral/Packages/.packages/app_intents → add the AppIntentsBridge library

Flutter's Swift Package Manager integration generates that symlink, so the path needs no Podfile and survives app_intents upgrades. Add only AppIntentsBridge to an extension target — the sibling app-intents library links Flutter.

It has to be that package rather than a sibling directory: Xcode normalizes local-package paths lexically, so …/.packages/app_intents/../AppIntentsBridge collapses to .packages/AppIntentsBridge and fails to resolve.

Route	Needs a Podfile?	Follows the pub version?
Local Swift package (recommended)	no	yes
CocoaPods app_intents_bridge pod	yes	yes
Remote .package(url:)	no	no — pin the vX.Y.Z tag

The CocoaPods pod and the root-manifest .package(url:) route are otherwise unchanged. app_intents.podspec still globs app_intents/Sources/app_intents/** only, so the two pods carry no duplicate symbols.

Migration

If you added the Swift package by path in 0.14.0 (ios/.symlinks/plugins/app_intents/ios/AppIntentsBridge), re-point it at ios/Flutter/ephemeral/Packages/.packages/app_intents and select the AppIntentsBridge library.

CocoaPods and .package(url:) users need no change beyond the version bump — though CocoaPods users can now drop any import app_intents_bridge workaround.

app_intents_codegen / app_intents_annotations

No code changes; released in lockstep.

Also in this release

The example app gained a real TaskWidget app-extension target. app/ios/TaskWidget was previously a bare directory of generated Swift verified only by swiftc -typecheck; it now compiles in a genuine extension target, links the AppIntentsBridge product over the path above, and carries its own App Groups entitlement — so the downstream integration story is exercised on every example-app build.

Note for contributors: swift test in the bridge directory is gone. The plugin's package is iOS-only because it links Flutter, so the Swift tests run via xcodebuild test -scheme AppIntentsBridge on a simulator, which is what CI already did.

Full Changelog: v0.14.0...v0.15.0

app_intents

• Fix: AppIntentsBridge could not be reached from a downstream app (#102). The Swift package now ships inside the pub package at ios/AppIntentsBridge/, so import AppIntentsBridge — which the generate_widget_swift output requires — resolves without a separately versioned dependency. Three consumption routes, all building the same sources:

  Route	How
  Local Swift package (recommended, projects with a Podfile)	File → Add Package Dependencies… → Add Local… → ios/.symlinks/plugins/app_intents/ios/AppIntentsBridge
  CocoaPods	pod 'app_intents_bridge', :path => '.symlinks/plugins/app_intents/ios'
  Remote Swift package (required for Podfile-less SPM projects)	https://github.com/touyou/flutter_intents → AppIntentsBridge

  A new standalone app_intents_bridge podspec carries no Flutter dependency, so an App Extension target — which must not link Flutter and therefore sits outside flutter_install_all_ios_pods — can take it. app_intents.podspec deliberately does not include these sources, so a target may take both pods without duplicate symbols. The repository root Package.swift keeps the same AppIntentsBridge product, so existing .package(url:) consumers are unaffected.

  Previously the package lived only in the repository's ios-spm/ subdirectory, which neither pub nor CocoaPods shipped and which SPM cannot resolve over a Git URL — a Widget Extension target failed with No such module 'AppIntentsBridge'.

• Docs: AppIntentsEntityCacheKey.forEntity now states that its result is the cache key, not the raw UserDefaults key. The plugin namespaces it as app_intents.<storageIdentifier>.cache.<cacheKey>; reading with the un-namespaced key returns nil silently, which only surfaces as an empty widget configuration picker. Same note added to docs/usage.md / docs/usage.ja.md.

app_intents_codegen

• Widens the analyzer constraint to >=7.0.0 <15.0.0, so the package can be used alongside analyzer 14.x. Verified against analyzer 14.1.0 / _fe_analyzer_shared 105.0.0: analysis clean, full test suite passing, and build_runner, generate_swift, generate_widget_swift and generate_kotlin all producing byte-identical output to the 13.x resolution.
• Bumps app_intents_annotations to ^0.14.0.

app_intents_annotations

• No user-facing changes; released in lockstep.

Also in this release

• Example app: removed three stale, never-compiled copies of AppIntentsBridge sources (#104).
• Toolchain: AGP 9.2.1 → 9.3.1, Gradle wrapper 9.6.1 → 9.7.0, build 4.0.8, build_test 3.5.17, dart_style 3.1.12.
• RELEASING.md now lists the two podspecs, the three per-package READMEs, and the ^X.Y.Z pins in docs/ — all of which the checklist had been omitting.

Full Changelog: v0.13.0...v0.14.0

• feat: App Extension entity access + WidgetConfigurationIntent codegen (#97/#98, #99)
• fix(codegen): normalize entity id property to id for AppEntity conformance (#100)

Also fixes version references that were missed in the 0.12.0 release:
the iOS podspec (left at 0.11.0) and the ^0.11.0 dependency snippets in
docs/ and the per-package READMEs.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Follow-up release after v0.11.0 reflecting the matsudate WWDC 2026 review #4 survey: three additive, opt-in items (#55 intent donation, #52 IntentParameter.ValueState, and the system.searchInApp schema rename) plus the deferred-items punch list in CLAUDE.md. All three packages are released together at the same version.

app_intents 0.12.0

• New API AppIntents().donateIntent(identifier, params) (#55): wraps AppIntent.donate() (stable iOS 16+) so the Dart side can record an executed intent for Siri / Apple Intelligence to learn from. The call is forwarded through AppIntentsPlugin.intentDonationForwarder (set in AppDelegate, mirroring relevantEntitiesDonationForwarder) to FlutterBridge.shared.donateIntent, which invokes the per-intent reverse-executor emitted by @IntentSpec(donatable: true) codegen. iOS-only; a no-op on other platforms.
• iOS native:
  • AppIntentsPlugin.intentDonationForwarder static hook for AppDelegate wiring. The donateIntent MethodChannel case returns DONATION_NOT_CONFIGURED when the forwarder is not set.
  • FlutterBridge.shared.registerIntentDonator(intentIdentifier:_:) / donateIntent(intentIdentifier:params:) / hasIntentDonator(for:); the donators dictionary is cleared by clearExecutors() alongside the other executor slots.
• Docs (docs/usage.md): adds the intentDonationForwarder wiring example next to the existing relevantEntitiesDonationForwarder block, plus the matching register<Intent>Donator() call site.

app_intents_annotations 0.12.0

• @IntentSpec(donatable: true) — opt-in for AppIntent.donate() so Siri / Apple Intelligence learns the user performed the action in-app (#55). Inert unless the donation experimental feature is enabled in app_intents_codegen. MVP restricts to primitive parameter types (String / int / double / bool / DateTime, optionals allowed); entity / file / enum / union / collection params are rejected at codegen time.
• @IntentParam(useValueState: true) — opt-in for IntentParameter.ValueState (@available(iOS 18.2, *) stable — no #if gating required). Distinguishes unset / set / cleared for an optional update parameter so the Dart handler can tell "don't touch" from "explicitly cleared." Only valid on a nullable Dart type; analyzer rejects use on non-optional params.
• AppSchemas.system.searchInApp — typed accessor for the iOS 27 system search-in-app schema (iOS 17 used .system.search; iOS 27 renamed it). The iOS-17 identifier remains reachable via AppSchemas.of(AppSchemaDomain.system, 'search'). Also adds AppSchemas.system.open.

app_intents_codegen 0.12.0

• @IntentSpec(donatable: true) (#55, requires --experimental=donation): emits a #if APP_INTENTS_WWDC26-gated register<Intent>Donator() reverse-executor that reconstructs the concrete intent from a [String: Any] params dict and calls intent.donate() (stable iOS 16+). Analyzer enforces the MVP primitive-only contract; rejects entityType / enumType / fileType / entityCollectionType / @UnionValue / non-primitive Dart types at codegen time.
• @IntentParam(useValueState: true) (#52): emits if #available(iOS 18.2, *) { switch $field.valueState { … @unknown default … } } in perform() and adds a sibling "<field>State": "unset" | "cleared" | "set" entry to the wire dict. The state key is added via if let in both FlutterBridge and cache-mode emit paths, so it is absent on iOS < 18.2 and the Dart handler can distinguish "no state info" from a present state. Analyzer rejects opt-in on non-optional Dart params. The Swift output uses @unknown default to future-proof against Swift 6's non-frozen enum errors. No experimental flag — this is a normal feature (the SDK symbol is stable iOS 18.2).
• AppSchemas.system.searchInApp — codegen consumes the schema string verbatim through the existing @AppIntent(schema:) / @AppEntity(schema:) macro emission (the app-schema experimental gate is unchanged); no codegen change beyond the typed accessor that lives in app_intents_annotations.
• Bumps app_intents_annotations dependency to ^0.12.0.

Repo meta

CLAUDE.md adds a new Deferred WWDC26 punch list section reserving ADR numbers 0005–0010 for the seven defer-with-ADR items uncovered by the matsudate review #4 audit (snippetView, dialogFullSupporting, requestValue, PlaceDescriptor export, LongRunningIntent progress/cancel forwarding, SyncableEntityIdentifier dual-id, @AppIntentsPackage). One document-only item (notificationEntity) is also tracked.

Verification

• All three Dart unit-test suites green (annotations, codegen, plugin), Swift AppIntentsBridge suite green (26 tests, .serialized trait fixed the shared-singleton race when adding the new intent-donator tests).
• swiftc -typecheck of the useValueState emit pattern against the Xcode 27 beta iOS 27 SDK (target iOS 17.0): exit 0, no warnings.
• The example app's regenerated Swift is byte-identical to the previous commit — the opt-in design means existing intents that don't opt in are completely unaffected.

First release since v0.10.1 to ship the accumulated WWDC26 App Intents work (opt-in, default OFF), plus a documentation audit pass. All three packages are released together at the same version.

app_intents 0.11.0

• WWDC26 experimental bridges (opt-in; exercised only when experimental Swift generation is enabled):
  • IntentValueQuery (#51): registerValueQueryHandler + platform queryValuesAsync (generic inbound value query; the visual SemanticContentDescriptor variant is out of scope)
  • Donations & discovery (#55): donateRelevantEntities(id, entities, context:) via a reverse executor, wired through AppIntentsPlugin.relevantEntitiesDonationForwarder
  • Onscreen-awareness scaffold (#56): setOnscreenEntity(typeId, instanceId, title:) / clearOnscreenEntity() backed by NSUserActivity, plus AppIntentsPlugin.onscreenEntityBinder
  • Extended the platform interface, method channel, and iOS AppIntentsPlugin.swift accordingly
• Docs: fix the Android setup README (compileSdk/targetSdk 37, minSdk 36 — the previous "36" would fail the appfunctions:1.0.0-alpha09 AAR-metadata check) and replace the placeholder example app READMEs with real content

app_intents_annotations 0.11.0

• WWDC26 App Intents annotation surfaces (opt-in; inert unless experimental code generation is enabled in app_intents_codegen):
  • Intent execution control (#52): @IntentSpec(longRunning:, cancellable:, executionTargets:) + the IntentExecutionTarget enum
  • App Schema (#49): schema: on @EntitySpec / @IntentSpec / @EnumSpec, plus the AppSchemas catalog (messages / mail / photos)
  • Semantic indexing (#50): @EntityProperty(title:, indexingKey:)
  • Entity ownership (#55): @EntitySpec(ownership:) + EntityOwnershipState
  • Rich parameter types (#53): Duration parameters, the new PersonName value type, @IntentParam(entityCollectionType:), and @UnionValueSpec / @UnionCase (which codegen lowers to a native @UnionValue enum)
  • Cross-app export (#54): @EntitySpec(exportAs:) + EntityExportType
  • IntentValueQuery (#51) and donations/discovery (#55): @EntitySpec(valueQuery:, syncable:, relevantEntities:)

app_intents_codegen 0.11.0

• WWDC26 experimental code generation (opt-in, default OFF). Master switch --experimental-wwdc26 + per-feature --experimental=<flag> (app-schema, ownership, long-running, rich-types, value-query, value-representation, donation). Experimental Swift is emitted inside #if APP_INTENTS_WWDC26 with a mandatory stable #else fallback, so released-SDK builds (without the flag) still compile.
  • Intent execution control (#52): LongRunningIntent / CancellableIntent / execution targets
  • App Schema (#49) + semantic indexing (#50): @AppEntity/@AppIntent/@AppEnum(schema:) and @Property(indexingKey:) (indexing ships as a normal iOS 18.4 feature)
  • Entity ownership (#55): additive OwnershipProvidingEntity conformance
  • Rich parameter types (#53): native Duration / PersonNameComponents / EntityCollection / @UnionValue parameters with compile-everywhere fallbacks, plus a generated union fromMap factory
  • IntentValueQuery (#51), cross-app export (#54, IntentPerson), and SyncableEntity / RelevantEntities donation (#55)
  • Dual-branch output verified via swiftc -typecheck (with and without APP_INTENTS_WWDC26) against the Xcode 27 beta SDK; see scripts/verify_experimental_swift.sh
• AppIntentsTesting scaffold for the example app (#57, compile-checked, inert on stable Xcode)
• Docs: correct the @EnumSpec / @EnumCaseDisplay examples, the Dart SDK constraint (^3.10.0) and dependency ranges, the Android toolchain versions, and add the ownership experimental flag to the feature tables

---

Published to pub.dev:

• https://pub.dev/packages/app_intents/versions/0.11.0
• https://pub.dev/packages/app_intents_annotations/versions/0.11.0
• https://pub.dev/packages/app_intents_codegen/versions/0.11.0

Full Changelog: v0.10.1...v0.11.0

app_intents 0.10.1

• Fix Android build on Kotlin 2.3+ / AGP 9.1.0+: migrate the plugin's android/build.gradle.kts from the deprecated kotlinOptions DSL to the modern compilerOptions DSL (#20, thanks @cpbritton)
  • The kotlinOptions block now causes "Script compilation errors" with recent Kotlin Gradle Plugin / AGP toolchains; compilerOptions { jvmTarget.set(JvmTarget.JVM_17) } is the supported replacement
• Maintenance: dependency bumps and OSS infrastructure hardening (CI, issue/PR templates, Dependabot)

app_intents_annotations 0.10.1 / app_intents_codegen 0.10.1

• No API changes; version-aligned with app_intents 0.10.1
• codegen: dependency maintenance (analyzer, source_gen, build, build_test, dart_style, test)

---

Published to pub.dev:

• https://pub.dev/packages/app_intents/versions/0.10.1
• https://pub.dev/packages/app_intents_annotations/versions/0.10.1
• https://pub.dev/packages/app_intents_codegen/versions/0.10.1

Full Changelog: v0.10.0...v0.10.1

app_intents 0.10.0

• Add Swift Package Manager (SPM) support for the iOS plugin (#29, #30)
  • New manifest at ios/app_intents/Package.swift; native sources moved to ios/app_intents/Sources/app_intents/ (SPM-standard layout)
  • app_intents.podspec now points source_files/resource_bundles at the shared Sources/ location, so CocoaPods and SPM build the same files (both remain supported during the transition)
  • Fixes Flutter reporting app_intents as "does not support Swift Package Manager" when host apps enable SPM
  • Host apps that enable SPM need Flutter 3.24+; CocoaPods users are unaffected (flutter: '>=3.3.0' unchanged)
  • The privacy manifest is now actually bundled (previously commented out in the podspec)
• Declare the NSPrivacyAccessedAPICategoryUserDefaults required-reason API in PrivacyInfo.xcprivacy
  • Reasons CA92.1 (UserDefaults accessible only to the app itself) and 1C8F.1 (UserDefaults shared within the App Group, for cross-process cache/EntityQuery data)
  • Required for App Store review of downstream apps that bundle the plugin

app_intents_annotations 0.10.0 / app_intents_codegen 0.10.0

• No API changes; version-aligned with app_intents 0.10.0

---

Published to pub.dev:

• https://pub.dev/packages/app_intents/versions/0.10.0
• https://pub.dev/packages/app_intents_annotations/versions/0.10.0
• https://pub.dev/packages/app_intents_codegen/versions/0.10.0

• @AppShortcutsBuilder annotation in generated AppShortcuts (#25)
• App Group UserDefaults fallback for EntityQuery cold-start (#26)
  • New @EntitySpec.persistedCacheKey field
  • Defaults to app_intents.entities. when enumerable/indexed

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

Bump all packages to v0.8.0 to publish the AppFunctions alpha09
upgrade (#23). Downstream Android hosts need AGP 9.1.0+, Gradle
9.3.1+, compileSdk 37, and the android.newDsl=false /
android.builtInKotlin=false shims in gradle.properties. Regenerate
Kotlin output with dart run app_intents_codegen:generate_kotlin
after upgrading.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

Fix: Android AppIntentsPlugin now handles iOS-only cache methods
(getCachedValue/setCachedValue/clearCachedValue/configureStorage/
processPendingActions) as no-ops returning null, instead of throwing
MissingPluginException. Prevents silent failures in release builds
where PlatformDispatcher.onError swallows the exception (#22).

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

• No API changes; version bump to align with plugin fix release

• No API changes; version bump to align with plugin bug fix release (App Group storage fix)

• No API changes; version bump to align with codegen bug fix release

• No API changes; version bump to align with codegen bug fix release

• No API changes; version bump to align with codegen bug fix release

• No API changes; version bump to align with codegen bug fix release

• No API changes; version bump to align with codegen bug fix release

• No API changes; version bump to align with codegen package (xcstrings generation feature)

• No API changes; version bump to align with codegen/plugin packages

• Documentation fixes: correct outdated code examples and API references

• BREAKING: Remove generic type parameters from IntentSpecBase
  • Before: class MyIntent extends IntentSpecBase<Input, Output>
  • After: class MyIntent extends IntentSpecBase
  • Input/Output types were unused by the framework and can be removed safely

• No API changes; version bump to align with other packages

• No API changes; version bump to align with codegen package

• Add imageName field to @EnumCaseDisplay for AppEnum case icon support
• Add displayImageName field to @EntitySpec for entity type-level display image
• Add indexed field to @EntitySpec for IndexedEntity Spotlight integration (iOS 26+)
• Add enumerable field to @EntitySpec for EnumerableEntityQuery support

• Add IntentMode enum for intent execution mode control (foreground/background)
• Add supportedModes field to @IntentSpec for iOS 26+ IntentModes support
• Add IntentFile model class for file/image parameter handling
• Add fileType field to @IntentParam for UTType-based file parameters

• Add Android AppFunctions support (annotations shared across iOS and Android)
• Update documentation for cross-platform (iOS App Intents + Android AppFunctions)

• Documentation updates to reflect v0.2.0 features
• No API changes

• BREAKING: Raise iOS minimum to 17.0
• Add resultDialogTemplate to @IntentSpec for Siri/Shortcuts dialog feedback
• Add parameterSummary to @IntentSpec for Shortcuts UI parameter display
• Add enumType to @IntentParam for AppEnum parameter support
• Add @EnumSpec and @EnumCaseDisplay annotations for AppEnum definitions
• Update @AppShortcut phrase docs: all phrases require {applicationName}

• Initial release
• @IntentSpec and @IntentParam annotations for intent definitions
• @EntitySpec, @EntityId, @EntityTitle, @EntitySubtitle, @EntityImage annotations for entity definitions
• @AppShortcut and @AppShortcutsProvider annotations for Spotlight shortcuts
• IntentSpecBase and EntitySpecBase base classes