DELIVERY-125462: Add Swift Package Manager (SPM) support for Core by Kobikg78 · Pull Request #459 · AppsFlyerSDK/appsflyer-flutter-plugin

Kobikg78 · 2026-07-21T12:27:22Z

Summary

Adds ios/appsflyer_sdk/Package.swift for the plugin's Core iOS integration, moving ios/Classes/ into an SPM-compatible shared source tree that both CocoaPods and SPM compile from (verified directly against Flutter's official plugin-author SPM migration guide, not just copied from prior draft PRs feat(ios): add Swift Package Manager support for Core #454/feat(ios): add Swift Package Manager support #455).
Corrects a real bug found in draft PR feat(ios): add Swift Package Manager support for Core #454: the SPM dependency must point at AppsFlyerFramework's actual product name AppsFlyerLib, not AppsFlyerLib-Static as that PR's description claimed — verified by resolving live against the upstream repo (swift package describe).
Purchase Connector stays CocoaPods-only this release — blocked upstream by flutter/flutter#161182 (Flutter's own plugin tooling lacks conditional-compilation support; confirmed SwiftPM Package Traits don't help since Flutter doesn't route plugin builds through them). Three alternative architectures were evaluated and documented (docs/researches/R-001-spm-support.md) — none viable for this release; a federated package split is the one real path if this becomes a hard requirement later.
Updates F-054 (Purchase Connector: Build-Time Opt-in) to document the new SPM path as a third, permanently-excluded gate, and adds F-060 (Swift Package Manager Support) to the feature catalog.
Full delivery trail: PRD → research → tech design → implementation → feature doc, all Alice-reviewed (docs/prds/spm-support.md, docs/researches/R-001-spm-support.md, docs/tech-designs/spm-support.md).
Includes Add AI delivery workflow tooling and feature catalog #458 (feature catalog + workflow tooling) merged in as a base.

Test plan

flutter test test — all 38 existing Dart tests pass, unaffected (iOS-only change).
pod spec lint --quick --allow-warnings — passes; confirms the podspec's repointed paths resolve.
swift package describe — live dependency resolution against the real AppsFlyerFramework repo confirms the corrected AppsFlyerLib product resolves at 6.18.0..<7.0.0.
iOS E2E workflow dispatched against this branch and passed in full (all 6 phases, every check) — real device build via GitHub Actions with the real ENV_FILE secret, confirming Flutter actually activated the SPM manifest during the build and the app initializes, links, and drives real attribution traffic end to end. Run: https://github.com/AppsFlyerSDK/appsflyer-flutter-plugin/actions/runs/29748317820
CocoaPods Core+PurchaseConnector build path — not yet re-verified after the development merge; recommend a rerun before promoting to RC.

🤖 Generated with Claude Code

Adds ios/appsflyer_sdk/Package.swift for the Core iOS integration, moving ios/Classes/ into an SPM-compatible shared source tree that both CocoaPods and SPM compile from. Purchase Connector stays CocoaPods-only, blocked upstream by flutter/flutter#161182. Updates F-054 and adds F-060 in the feature catalog, plus PRD, research, and tech design docs for the delivery workflow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…2-spm-support

…-spm-support

Package.swift pinned AppsFlyerFramework with `from: "6.18.0"` (a semver range, ..<7.0.0), while the podspec pins CocoaPods to exactly 6.18.0. CI's own iOS E2E run exposed the drift: it resolved and ran against 6.18.1 via SPM. Switch to `.exact("6.18.0")` so both distribution paths pin identically, and correct the docs/plan that described the old pin as correct. Also retracts a stale claim in plans/01-ios-spm-core-support.md that `.iOS("12.0")` is invalid SwiftPM syntax — verified valid via `swift package describe`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Dani-Koza-AF

The core mechanics are sound and, verified against Flutter's official plugin-author SPM guide. Great work.
Additional General note, can we rename docs/ to something clearly internal (e.g. internal-docs/)? It's one letter off from the user-facing doc/, so the two are easy to confuse.

Dani-Koza-AF · 2026-07-22T13:19:02Z

Shouldn't be commited

Dani-Koza-AF · 2026-07-22T13:22:03Z

Shouldn't be committed

Dani-Koza-AF · 2026-07-22T13:23:15Z

+        .library(name: "appsflyer-sdk", targets: ["appsflyer_sdk"])
+    ],
+    dependencies: [
+        .package(url: "https://github.com/AppsFlyerSDK/AppsFlyerFramework.git", .exact("6.18.0"))


Pinning .exact here is the right call for parity with the podspec. But the green iOS E2E linked in the description ran before this line changed (it resolved 6.18.1 via from:), so we don't have a passing SPM build for the 6.18.0 we're actually shipping.
Can we re-run the SPM E2E on this commit before RC?

or just resolve if SPM E2E passed

Dani-Koza-AF · 2026-07-22T13:24:41Z

+- `pod spec lint --quick --allow-warnings` — passed, confirming the podspec's repointed `source_files`/`public_header_files` globs resolve correctly against the moved tree.
+- `flutter test test` — all 38 existing Dart tests pass unaffected (this change touches only iOS native file locations and build manifests, not Dart code).
+
+> **Outstanding pre-release gate**: the tech design's mandatory 4-path real-device build verification (SPM Core-only / CocoaPods Core-only / CocoaPods Core+PurchaseConnector / confirming SPM+PurchaseConnector is inert, all on real devices, not `--no-codesign` alone) has **not yet been run** — it requires a full macOS/Xcode/iOS-device environment that was unavailable during implementation. This must be completed before this ships (before promoting through the RC pipeline). See `docs/tech-designs/spm-support.md` for the exact verification steps.


This says the 4-path device verification hasn't run yet, but the PR description says the E2E "passed in full." Those don't agree. Let's reconcile, and make sure the CocoaPods Core+PurchaseConnector path is re-checked before we promote.

Dani-Koza-AF · 2026-07-22T13:25:43Z

 - Updated iOS SDK from 6.17.9 to 6.18.0
 - Updated iOS Purchase Connector from 6.17.9 to 6.18.0
 - Fixed Android warm-app deep link consumption race so `DeepLinkListener` fires reliably when the app is resumed from a `VIEW` intent (forward new intents to `AppsFlyerLib` from the plugin's `onNewIntentListener` before the SDK's `onResume` auto-handler marks them `af_consumed`)
+- Added Swift Package Manager (SPM) support for the Core iOS integration (`ios/appsflyer_sdk/Package.swift`), alongside continued full CocoaPods support — no behavior change for existing CocoaPods consumers. Purchase Connector remains CocoaPods-only for now, pending resolution of an upstream Flutter limitation ([flutter/flutter#161182](https://github.com/flutter/flutter/issues/161182)) that blocks conditionally-compiled plugin features under SPM.


Good release note. The ticket also asks for the user-facing guides though, and doc/Installation.md and doc/PurchaseConnector.md still say nothing about SPM or that Purchase Connector needs CocoaPods.
Can we add that so PC users don't just hit a MissingPluginException with no explanation?

Dani-Koza-AF · 2026-07-22T13:27:07Z

+    targets: [
+        .target(
+            name: "appsflyer_sdk",
+            dependencies: [
+                .product(name: "AppsFlyerLib", package: "AppsFlyerFramework")
+            ],
+            cSettings: [
+                .headerSearchPath("include/appsflyer_sdk")
+            ]
+        )


Minor: the target declares no PrivacyInfo.xcprivacy. That's fine if our own ObjC doesn't call any required-reason APIs (the SDK xcframework ships its own manifest), but worth a quick confirm rather than assuming.

Same rationale as #460: docs/ was one letter off from the user-facing doc/, easy to confuse. Renames this branch's own docs/prds/, docs/researches/, docs/tech-designs/, and docs/features/ additions (F-054, F-060), fixes the tech design's frontmatter self-references (prd:/research: fields), and picks up two files #460 missed (ai-delivery-workflow-templat/README.md, update-existing-repo.md). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Kobikg78 · 2026-07-23T09:59:38Z

Thanks @Dani-Koza-AF! Good catch on docs/ vs doc/ — done, in two parts:

Rename docs/ to internal-docs/ #460: renames docs/features/ → internal-docs/features/ (the base catalog from Add AI delivery workflow tooling and feature catalog #458, already merged) and updates every internal reference in CLAUDE.md and .claude/.
This branch (DELIVERY-125462-spm-support): renamed its own docs/prds/, docs/researches/, docs/tech-designs/, and docs/features/ additions (F-054, F-060) to match, including fixing the tech design's frontmatter self-references.

Recommend merging #460 first so this PR's diff picks up the rename cleanly.

* Rename docs/ to internal-docs/ Addresses review feedback on #459: docs/ was one letter off from the user-facing doc/ (per-feature integration guides consumed by SDK users), making the two easy to confuse. Renames the directory and updates every internal reference in CLAUDE.md and .claude/ to match. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Fix two files missed in the docs/ rename ai-delivery-workflow-templat/README.md and update-existing-repo.md still referenced the old docs/ path. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…2-spm-support

Per Dani's review on #459: plans/01-ios-spm-core-support.md and templates/af-tech-quiz-template.html shouldn't be committed to the repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Per Dani's review on #459: - doc/Installation.md: new section on iOS SPM support for Core, with a pointer to the PurchaseConnector CocoaPods-only caveat. - doc/PurchaseConnector.md: explicit warning that Purchase Connector requires CocoaPods even when the app has adopted SPM for Core, and what happens (MissingPluginException) if it's skipped entirely. - F-060: fixed two docs/researches/... references missed in the earlier docs/ -> internal-docs/ rename sweep. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Per Dani's review: F-060 said device verification hadn't run while the PR description said E2E passed in full. Reconciled with links to all 3 real CI runs now completed, and honestly flagged the one remaining gap (SPM+PurchaseConnector inertness was reasoned through, not actively tested). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Kobikg78 · 2026-07-26T07:19:40Z

@Dani-Koza-AF — sorry, I'd only caught your top-level review comment before, not the inline ones. Went through all of them now:

plans/01-ios-spm-core-support.md and templates/af-tech-quiz-template.html "shouldn't be committed" — removed both from this branch (a6fe723).

SPM E2E was tested against the wrong pin — you're right, the originally-linked run tested from: "6.18.0" (which had resolved 6.18.1), not the .exact("6.18.0") fix. Re-ran it: run 30191649705, all 6 phases pass, and getSDKVersion now confirms 6.18.0 — not a drifted patch release this time.

F-060 vs. PR description contradiction — reconciled (c6ba139). F-060 now links all 3 real E2E runs (SPM Core-only with the corrected pin, hybrid SPM+CocoaPods PurchaseConnector, and pure CocoaPods with SPM explicitly disabled) and honestly flags the one gap that's still just reasoned-through rather than actively tested: calling a Purchase Connector API from an SPM-only build to confirm it raises MissingPluginException rather than something worse. Low risk (same underlying mechanism as the existing CocoaPods not-opted-in path), but not yet exercised by a real test.

User-facing docs missing SPM/PurchaseConnector guidance — added (56be549): doc/Installation.md now has an SPM section, and doc/PurchaseConnector.md explicitly calls out that Purchase Connector needs CocoaPods even if the app has SPM for Core, and what happens if that's skipped.

Privacy manifest — already checked during research, just hadn't reported it back here: I downloaded and inspected the actual AppsFlyerFramework xcframework zip (not just assumed) — PrivacyInfo.xcprivacy is embedded directly inside each per-platform slice of the xcframework itself (confirmed for ios-arm64, ios-arm64_x86_64-simulator, etc.). Same manifest content as the CocoaPods pod, just packaged per SPM's own convention (in-framework vs. CocoaPods resource_bundle). No gap here.

Everything above is on this branch — no new PRs.

Dani-Koza-AF

Looks goof, loved the hybrid approach with PC.

Kobikg78 and others added 5 commits July 20, 2026 10:40

Merge remote-tracking branch 'origin/development' into DELIVERY-12546…

cc9671f

…2-spm-support

Merge branch 'docs-workflow-and-feature-catalog' into DELIVERY-125462…

dcef64f

…-spm-support

Merge branch 'docs-workflow-and-feature-catalog' into DELIVERY-125462…

3b6a4b9

…-spm-support

Dani-Koza-AF reviewed Jul 22, 2026

View reviewed changes

Kobikg78 mentioned this pull request Jul 23, 2026

Rename docs/ to internal-docs/ #460

Merged

2 tasks

Kobikg78 and others added 4 commits July 26, 2026 09:41

Merge remote-tracking branch 'origin/development' into DELIVERY-12546…

88f602f

…2-spm-support

Remove plans/ and templates/ artifacts per review

a6fe723

Per Dani's review on #459: plans/01-ios-spm-core-support.md and templates/af-tech-quiz-template.html shouldn't be committed to the repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Dani-Koza-AF approved these changes Jul 26, 2026

View reviewed changes

Kobikg78 merged commit c9b4da3 into development Jul 26, 2026
9 checks passed

Kobikg78 mentioned this pull request Jul 26, 2026

Correct SPM + Purchase Connector guidance: mutually exclusive #462

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

DELIVERY-125462: Add Swift Package Manager (SPM) support for Core - #459

DELIVERY-125462: Add Swift Package Manager (SPM) support for Core#459
Kobikg78 merged 10 commits into
developmentfrom
DELIVERY-125462-spm-support

Kobikg78 commented Jul 21, 2026

Uh oh!

Dani-Koza-AF left a comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Uh oh!

Dani-Koza-AF Jul 22, 2026 •

edited

Loading

Uh oh!

Dani-Koza-AF Jul 22, 2026

Uh oh!

Dani-Koza-AF Jul 22, 2026

Uh oh!

Dani-Koza-AF Jul 22, 2026

Uh oh!

Dani-Koza-AF Jul 22, 2026

Uh oh!

Dani-Koza-AF Jul 22, 2026

Uh oh!

Kobikg78 commented Jul 23, 2026

Uh oh!

Kobikg78 commented Jul 26, 2026

Uh oh!

Dani-Koza-AF left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Kobikg78 commented Jul 21, 2026

Summary

Test plan

Uh oh!

Dani-Koza-AF left a comment

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Dani-Koza-AF Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

Kobikg78 commented Jul 23, 2026

Uh oh!

Kobikg78 commented Jul 26, 2026

Uh oh!

Dani-Koza-AF left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Dani-Koza-AF Jul 22, 2026 •

edited

Loading