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 theAppIntentsBridgelibrary
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