✨ - Add Swift Package Manager support for zstandardios

[zntus]

Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

None

What actions does this improvement affect?

No response

Description of the idea or improvement

Could you please add Swift Package Manager support to zstandard_ios?

The plugin should provide the required Swift Package Manager configuration so it can be integrated by Flutter without warnings.

Current limitations or challenges

Flutter reports that zstandard_ios does not support Swift Package Manager for iOS:

The following plugins do not support Swift Package Manager for ios:
- zstandard_ios

This will become an error in a future version of Flutter. Please contact the plugin maintainers to request Swift
Package Manager adoption.

This is currently a warning, but Flutter indicates that it will become an error in a future release.

Expected impact

Flutter applications using zstandard will be able to build for iOS with Swift Package Manager integration enabled, without this compatibility warning or a future build error.

Alternatives considered

No response

Version of git-board-flow

zstandard 1.5.0 / zstandard_ios 1.5.0

Additional context or comments

Environment

• Flutter: 3.44.6
• zstandard: 1.5.0
• zstandard_ios: 1.5.0
• Platform: iOS

Steps to reproduce

1. Add zstandard: ^1.5.0 to a Flutter project.
2. Resolve the dependencies.
3. Build the iOS application with Swift Package Manager integration enabled.
4. Observe the warning above.

Thank you for maintaining this package.

[vypbot]

🪄 Automatic Actions

1. The issue was assigned to @vypbot.
2. The issue's title was updated from Add Swift Package Manager support for zstandard_ios to ✨ - Add Swift Package Manager support for zstandardios.
3. The issue was linked to vypdev and moved to the column Todo.
4. Priority set to P2 in vypdev.
5. Recommended steps (OpenCode Plan agent):
6. Now I have a complete picture. Here are the recommended implementation steps:

---

Implementation Plan: Add SPM Support to zstandard_ios

1. Commit zstd C sources to the plugin

Why: SPM, unlike CocoaPods, has no prepare_command equivalent to dynamically sync sources at resolution time. The zstd C sources must be present as committed files.

Actions:

• Run bash scripts/sync_zstd.sh from zstandard_ios/ to populate ios/Classes/zstd/
• Verify the sync removed module.modulemap (it clashes with module build)
• Verify the sync does not copy decompress/huf_decompress_amd64.S (assembly not supported on iOS; currently excluded by the .c glob in the podspec but rsync -a will copy it — add --exclude='*.S' to sync_zstd.sh for the iOS copy)
• Ensure ios/Classes/zstd/ is not in any .gitignore (currently not listed)
• Commit the ios/Classes/zstd/ directory

Relevant files:

File	Change
zstandard_ios/scripts/sync_zstd.sh	Add --exclude='*.S' to the rsync line (iOS-only; macOS needs .S files)
zstandard_ios/ios/Classes/zstd/	New committed directory (the synced zstd C sources)
zstandard_ios/.gitignore	Verify no exclusion for ios/Classes/zstd

2. Remove sync/cleanup script phases from zstandard_ios.podspec

Why: Sources are now committed, so the dynamic sync and post-build cleanup are unnecessary. Removing them avoids the risk of the sync script deleting the committed sources if zstandard_native is unavailable.

Actions:

• Remove the s.prepare_command line
• Remove the entire s.script_phases array
• Keep all other podspec settings (source_files, public_header_files, xcconfig, etc.) unchanged — they work fine with committed sources

Podspec diff:

-  s.prepare_command = "bash '../scripts/sync_zstd.sh'"
   ...
-  s.script_phases = [
-    { :name => 'Sync zstd', ... },
-    { :name => 'Remove synced zstd', ... }
-  ]

3. Create ios/Package.swift

Why: This is the core of SPM support. Flutter's iOS build system detects Package.swift in a plugin's ios/ directory and adds it as a local SwiftPM dependency.

Key requirements:

• Package name must match the framework name (zstandard_ios) for DynamicLibrary.open('zstandard_ios.framework/zstandard_ios') to work
• Target path must point to Classes/ (relative to ios/) where both the Swift plugin and zstd C sources live
• Must compile all zstd .c sources (auto-discovered from Classes/zstd/)
• Must define ZSTD_STATIC_LINKING_ONLY and ZSTD_DISABLE_ASM (matching podspec)
• Must exclude decompress/huf_decompress_amd64.S (assembly not supported on iOS)
• Must set publicHeadersPath to "zstd" so zstd.h is findable
• Minimum iOS version: 13.0 (matching podspec)

// swift-tools-version: 5.3
import PackageDescription

let package = Package(
    name: "zstandard_ios",
    platforms: [
        .iOS(.v13),
    ],
    products: [
        .library(
            name: "zstandard_ios",
            targets: ["zstandard_ios"]
        ),
    ],
    targets: [
        .target(
            name: "zstandard_ios",
            path: "Classes",
            exclude: [
                "zstd/decompress/huf_decompress_amd64.S",
                "zstd/module.modulemap",
            ],
            publicHeadersPath: "zstd",
            cSettings: [
                .headerSearchPath("zstd"),
                .define("ZSTD_STATIC_LINKING_ONLY"),
                .define("ZSTD_DISABLE_ASM"),
            ]
        )
    ]
)

Notes:

• module.modulemap is excluded because the sync script already removes it (it conflicts with the module build under the podspec; for SPM it would also cause issues)
• publicHeadersPath: "zstd" makes zstd.h a public header of the module (needed by the Swift plugin and for any bridging)
• SPM 5.3 is the minimum for cSettings and publicHeadersPath

Relevant files:

File	Change
zstandard_ios/ios/Package.swift	New file (content above)

4. Update CI workflow to validate SPM integration

Why: Ensure the Package.swift is valid and the example app can build with SPM enabled.

Actions in .github/workflows/pr_check_ios.yml:

• Add a new job check_ios_spm that:
  1. Runs flutter pub get in the example app
  2. Runs flutter build ios --no-codesign --ios-swift-package-manager (or equivalent SPM-enabled build command)
  3. Validates no "does not support Swift Package Manager" warning appears
• Alternatively, add a step to validate the Package.swift itself: swift package resolve from zstandard_ios/ios/

Relevant files:

File	Change
.github/workflows/pr_check_ios.yml	Add SPM validation job

5. Update documentation

Actions:

• Update zstandard_ios/README.md to mention SPM support and the Package.swift location
• Add a changelog entry in zstandard_ios/CHANGELOG.md (e.g., "Add Swift Package Manager support for iOS")
• Update docs/guides/installation.md if it describes iOS setup

6. Test end-to-end

Manual verification:

1. Create a new Flutter project
2. Add zstandard as a dependency (pointing to local path or pub.dev)
3. Enable SPM in the Flutter project: flutter build ios --ios-swift-package-manager
4. Verify no warning about zstandard_ios not supporting SPM
5. Verify compression/decompression works at runtime

7. (Optional) Apply the same pattern to zstandard_macos

Why: The macOS plugin has an identical architecture (sync script + podspec). If SPM is needed for macOS Catalyst or future Flutter requirements, the same approach applies.

Actions:

• Commit zstd sources to zstandard_macos/macos/Classes/zstd/ (including .S files since macOS supports assembly)
• Create zstandard_macos/macos/Package.swift
• Update zstandard_macos podspec similarly

---

Summary of all files to create/modify

File	Action
zstandard_ios/scripts/sync_zstd.sh	Add --exclude='*.S' to rsync (line 54)
zstandard_ios/ios/Classes/zstd/	New committed directory (synced zstd sources)
zstandard_ios/ios/Package.swift	Create — SPM manifest
zstandard_ios/ios/zstandard_ios.podspec	Remove prepare_command and script_phases
zstandard_ios/CHANGELOG.md	Add SPM support entry
zstandard_ios/README.md	Document SPM support
zstandard_ios/.gitignore	Verify (no change needed likely)
.github/workflows/pr_check_ios.yml	Add SPM validation job

Debug log

[DEBUG] Setup done. Issue number: 141, isSingleAction: false, isIssue: true, isPullRequest: false, isPush: false
[DEBUG] ✅ No previous runs active. Continuing...
[INFO] Running IssueUseCase for issue #141.
[INFO] 📋 Executing IssueUseCase.
[INFO] 🔐 Executing CheckPermissionsUseCase.
[DEBUG] Ignoring permission checking. Issue doesn't require mandatory branch.
[INFO] 👤 Executing AssignMemberToIssueUseCase.
[DEBUG] #141 needs 1 assignees.
[DEBUG] Checking team: tatooine
[DEBUG] Members: 2
[INFO] ✏️ Executing UpdateTitleUseCase.
[DEBUG] Issue title updated to: ✨ - Add Swift Package Manager support for zstandardios
[INFO] 🏷️ Executing UpdateIssueTypeUseCase.
[DEBUG] Setting issue type for issue 141 to Feature
[DEBUG] Creating new issue type "Feature" for organization vypdev...
[DEBUG] Issue Type: Feature
[DEBUG] Issue Type Description: A new functionality, enhancement, or improvement requested for the project.
[DEBUG] Issue Type Color: green
[DEBUG] Fetched issue ID: I_kwDONFe3188AAAABJViuTQ
[DEBUG] Organization ID: MDEyOk9yZ2FuaXphdGlvbjYzNzA1NDAz
[DEBUG] Organization issue types: [{"id":"IT_kwDOA8wRO84AuWac","name":"Task"},{"id":"IT_kwDOA8wRO84AuWag","name":"Bug"},{"id":"IT_kwDOA8wRO84AuWak","name":"Feature"},{"id":"IT_kwDOA8wRO84Bw9l2","name":"Documentation"},{"id":"IT_kwDOA8wRO84Bw9mw","name":"Question"},{"id":"IT_kwDOA8wRO84Bw9oA","name":"Maintenance"},{"id":"IT_kwDOA8wRO84Bw90_","name":"Release"},{"id":"IT_kwDOA8wRO84Bxfgg","name":"Hotfix"},{"id":"IT_kwDOA8wRO84Bxfgh","name":"Help"}]
[DEBUG] Found existing issue type "Feature" with ID: IT_kwDOA8wRO84AuWak
[DEBUG] Successfully updated issue type to Feature
[INFO] 🔗 Executing LinkIssueProjectUseCase.
[DEBUG] Fetched issue ID: I_kwDONFe3188AAAABJViuTQ
[DEBUG] Linked I_kwDONFe3188AAAABJViuTQ with id PVTI_lADOA8wRO84Ajh7BzgzUc7A to project PVT_kwDOA8wRO84Ajh7B
[DEBUG] Content ID: PVTI_lADOA8wRO84Ajh7BzgzUc7A
[DEBUG] Target field: {
  "id": "PVTSSF_lADOA8wRO84Ajh7Bzgb4L2E",
  "name": "Status",
  "options": [
    {
      "id": "f75ad846",
      "name": "Todo"
    },
    {
      "id": "47fc9ee4",
      "name": "In Progress"
    },
    {
      "id": "98236657",
      "name": "Done"
    }
  ]
}
[DEBUG] Target option: {
  "id": "f75ad846",
  "name": "Todo"
}
[DEBUG] Target field ID: PVTSSF_lADOA8wRO84Ajh7Bzgb4L2E
[DEBUG] Target option ID: f75ad846
[INFO] 📏 Executing CheckPriorityIssueSizeUseCase.
[DEBUG] Priority: priority: low
[DEBUG] Github Priority Label: P2
[DEBUG] Content ID: PVTI_lADOA8wRO84Ajh7BzgzUc7A
[DEBUG] Target field: {
  "id": "PVTSSF_lADOA8wRO84Ajh7Bzgb4MPQ",
  "name": "Priority",
  "options": [
    {
      "id": "4af6496f",
      "name": "P0"
    },
    {
      "id": "f87877a5",
      "name": "P1"
    },
    {
      "id": "27f99ddc",
      "name": "P2"
    }
  ]
}
[DEBUG] Target option: {
  "id": "27f99ddc",
  "name": "P2"
}
[DEBUG] Target field ID: PVTSSF_lADOA8wRO84Ajh7Bzgb4MPQ
[DEBUG] Target option ID: 27f99ddc
[INFO] 🧹 Executing RemoveIssueBranchesUseCase.
[DEBUG] Checking branch type feature
[DEBUG] Checking prefix feature/141-
[DEBUG] Checking branch type bugfix
[DEBUG] Checking prefix bugfix/141-
[INFO] 🧹 Executing RemoveNotNeededBranchesUseCase.
[INFO] 🏷️ Executing DeployAddedUseCase.
[INFO] 🏷️ Executing DeployedAddedUseCase.
[INFO] 💡 Executing RecommendStepsUseCase.
[DEBUG] RecommendSteps: prompt length=2483, issue description length=1645.
[INFO] 🤖 Recommending steps using OpenCode Plan agent...
[INFO] OpenCode request [agent build] model=opencode/deepseek-v4-flash-free promptLength=2483
[INFO] OpenCode sending prompt (full):
Based on the following issue description, recommend concrete steps to implement or address this issue. Order the steps logically (e.g. setup, implementation, tests, docs). Keep each step clear and actionable.

**Important – use full project context:** In addition to reading the relevant code (respecting any file ignore patterns specified), read the repository documentation (e.g. README, docs/) and any defined rules or conventions (e.g. .cursor/rules, CONTRIBUTING, project guidelines). This gives you a complete picture of the project and leads to better decisions in both quality of reasoning and efficiency.

**Issue #141 description:**
### Is there an existing issue or feature request for this?

- [x] I have searched the existing issues and feature requests.

### What area does this improvement affect?

None

### What actions does this improvement affect?

_No response_

### Description of the idea or improvement

Could you please add Swift Package Manager support to `zstandard_ios`?

The plugin should provide the required Swift Package Manager configuration so it can be integrated by Flutter without warnings.

### Current limitations or challenges

Flutter reports that `zstandard_ios` does not support Swift Package Manager for iOS:

text
The following plugins do not support Swift Package Manager for ios:
- zstandard_ios

This will become an error in a future version of Flutter. Please contact the plugin maintainers to request Swift
Package Manager adoption.


This is currently a warning, but Flutter indicates that it will become an error in a future release.

### Expected impact

Flutter applications using `zstandard` will be able to build for iOS with Swift Package Manager integration enabled, without this compatibility warning or a future build error.

### Alternatives considered

_No response_

### Version of git-board-flow

zstandard 1.5.0 / zstandard_ios 1.5.0

### Additional context or comments

### Environment

- Flutter: 3.44.6
- `zstandard`: 1.5.0
- `zstandard_ios`: 1.5.0
- Platform: iOS

### Steps to reproduce

1. Add `zstandard: ^1.5.0` to a Flutter project.
2. Resolve the dependencies.
3. Build the iOS application with Swift Package Manager integration enabled.
4. Observe the warning above.

Thank you for maintaining this package.

Provide a numbered list of recommended steps in **markdown** (use headings, lists, code blocks for commands or snippets) so it is easy to read. You can add brief sub-bullets per step if needed.
[DEBUG] OpenCode prompt (full, no truncation):
Based on the following issue description, recommend concrete steps to implement or address this issue. Order the steps logically (e.g. setup, implementation, tests, docs). Keep each step clear and actionable.

**Important – use full project context:** In addition to reading the relevant code (respecting any file ignore patterns specified), read the repository documentation (e.g. README, docs/) and any defined rules or conventions (e.g. .cursor/rules, CONTRIBUTING, project guidelines). This gives you a complete picture of the project and leads to better decisions in both quality of reasoning and efficiency.

**Issue #141 description:**
### Is there an existing issue or feature request for this?

- [x] I have searched the existing issues and feature requests.

### What area does this improvement affect?

None

### What actions does this improvement affect?

_No response_

### Description of the idea or improvement

Could you please add Swift Package Manager support to `zstandard_ios`?

The plugin should provide the required Swift Package Manager configuration so it can be integrated by Flutter without warnings.

### Current limitations or challenges

Flutter reports that `zstandard_ios` does not support Swift Package Manager for iOS:

text
The following plugins do not support Swift Package Manager for ios:
- zstandard_ios

This will become an error in a future version of Flutter. Please contact the plugin maintainers to request Swift
Package Manager adoption.


This is currently a warning, but Flutter indicates that it will become an error in a future release.

### Expected impact

Flutter applications using `zstandard` will be able to build for iOS with Swift Package Manager integration enabled, without this compatibility warning or a future build error.

### Alternatives considered

_No response_

### Version of git-board-flow

zstandard 1.5.0 / zstandard_ios 1.5.0

### Additional context or comments

### Environment

- Flutter: 3.44.6
- `zstandard`: 1.5.0
- `zstandard_ios`: 1.5.0
- Platform: iOS

### Steps to reproduce

1. Add `zstandard: ^1.5.0` to a Flutter project.
2. Resolve the dependencies.
3. Build the iOS application with Swift Package Manager integration enabled.
4. Observe the warning above.

Thank you for maintaining this package.

Provide a numbered list of recommended steps in **markdown** (use headings, lists, code blocks for commands or snippets) so it is easy to read. You can add brief sub-bullets per step if needed.
[DEBUG] OpenCode message body: agent=build, model=opencode/deepseek-v4-flash-free, parts[0].text length=2483
[DEBUG] OpenCode session create body: {"title":"copilot"}
[DEBUG] OpenCode response [OpenCode session.create] status=200 bodyLength=356. Full body:
{"id":"ses_0870a8120ffe1nFRAiBYXrKHEY","slug":"happy-planet","projectID":"4ac61bfddbc238ba0b5af83ff818f3c45e41faf8","directory":"/home/runner/work/zstandard/zstandard","path":"","cost":0,"tokens":{"input":0,"output":0,"reasoning":0,"cache":{"read":0,"write":0}},"title":"copilot","version":"1.18.3","time":{"created":1784440782559,"updated":1784440782559}}
[DEBUG] OpenCode POST /session/ses_0870a8120ffe1nFRAiBYXrKHEY/message body (keys): agent, model, parts (1 part(s))
[INFO] OpenCode: waiting for agent "build" message response (client timeout: 15 min)...
[DEBUG] OpenCode response [OpenCode agent "build" message] status=200 bodyLength=12722. Full body:
{"info":{"parentID":"msg_f78f57f13001mzOKtjsUJ2GLYp","role":"assistant","mode":"build","agent":"build","path":{"cwd":"/home/runner/work/zstandard/zstandard","root":"/home/runner/work/zstandard/zstandard"},"cost":0,"tokens":{"total":39781,"input":1184,"output":1802,"reasoning":1083,"cache":{"write":0,"read":35712}},"modelID":"deepseek-v4-flash-free","providerID":"opencode","time":{"created":1784440955902,"completed":1784440984800},"finish":"stop","id":"msg_f78f823fe001fbIbIxUFdvy49z","sessionID":"ses_0870a8120ffe1nFRAiBYXrKHEY"},"parts":[{"snapshot":"d88dd86112768d34fab7e335fe13024c3ff3f561","type":"step-start","id":"prt_f78f8292e001IDepMcCKuJCTeF","sessionID":"ses_0870a8120ffe1nFRAiBYXrKHEY","messageID":"msg_f78f823fe001fbIbIxUFdvy49z"},{"type":"reasoning","text":"Now I have all the information I need. Let me check whether there's a `module.modulemap` in the zstd source that causes issues.\n\nLooking at the glob results:\n- There's a `module.modulemap` at `zstandard_native/src/zstd/module.modulemap`\n- There's one `.S` file: `zstandard_native/src/zstd/decompress/huf_decompress_amd64.S`\n- There are many `.c` and `.h` files under `common/`, `compress/`, `decompress/`, `dictBuilder/`, `legacy/`, `deprecated/`\n\nThe sync script already removes `module.modulemap` during sync.\n\nNow let me formulate the complete implementation plan. I'll organize it into clear, actionable steps.\n\nHere's my plan:\n\n### Step 1: Commit the zstd C sources\n\nThe current approach dynamically syncs zstd sources. For SPM, committed sources are needed.\n\n**Actions:**\n- Run `bash scripts/sync_zstd.sh` from `zstandard_ios/` to populate `ios/Classes/zstd/`\n- Verify the directory structure matches what's expected\n- Ensure `.gitignore` doesn't exclude `ios/Classes/zstd` (currently doesn't)\n- Add and commit the sources\n\n### Step 2: Update `.gitignore` if needed\n\nCheck that `ios/Classes/zstd` isn't gitignored.\n\n### Step 3: Create `ios/Package.swift`\n\nCreate the SPM manifest.\n\n### Step 4: Update `zstandard_ios.podspec`\n\nSince sources are now committed, the `prepare_command` and `script_phases` for syncing are no longer strictly needed for the podspec, but they can remain as a safety net to ensure freshness. Let me think about this...\n\nActually, there's a subtle issue: if we keep the sync script, it will overwrite the committed sources at pod install time, which means the committed sources are just a fallback. But if the sync runs and fails (e.g., in an environment without `zstandard_native` available), the committed sources would be deleted first (`rm -rf \"$DEST\"` in the script). That would break both CocoaPods and SPM.\n\nSo the safest approach is:\n1. Remove the sync/cleanup phases from the podspec\n2. Rely on committed sources for both CocoaPods and SPM\n3. Keep `sync_zstd.sh` as a manual maintenance script\n\n### Step 5: Update CI\n\nThe iOS PR check workflows should be updated to test SPM integration.\n\n### Step 6: Update documentation\n\nUpdate README and CHANGELOG.\n\n### Step 7: Test\n\nVerify the example app builds with SPM enabled.\n\nNow, let me also think about one more thing: Flutter's SPM support is opt-in. Users need to enable it in their Flutter project with `flutter build ios --ios-swift-package-manager` or by adding configuration in their project. The plugin just needs to provide the `Package.swift`.\n\nLet me also check what changes are needed in the example app to test SPM.\n\nFor the example app to build with SPM, the user would need to:\n1. Have `ios/Package.swift` in the plugin\n2. In the example app, enable SPM (perhaps via `flutter build ios --ios-swift-package-manager`)\n\nBut for testing purposes, we can verify that the `Package.swift` is valid by running `swift package resolve` or `xcodebuild` with SPM enabled.\n\nActually, there's another important consideration. When Flutter resolves SPM packages for plugins, it reads the `Package.swift` in the plugin's `ios/` directory and adds it as a local package dependency to the app's Xcode project. The package name in `Package.swift` should match what Flutter expects.\n\nLooking at Flutter's SPM integration code, Flutter looks for `Package.swift` in each plugin's `ios/` directory and adds them as local SwiftPM dependencies to the Xcode workspace. The package name becomes the framework name.\n\nSo the framework produced by SPM would be named `zstandard_ios` (from the `name` parameter in `Package.swift`). The Dart FFI code loads `zstandard_ios.framework/zstandard_ios`, which matches.\n\nOK I'm confident in the plan now. Let me write it up.\n\nOne more thing: should I also add `zstandard_macos` support? The issue only mentions iOS, so I'll focus on iOS but mention macOS as a future consideration.\n\nLet me also think about whether we need to update the example app's Podfile or project configuration. For the example app to build with SPM, changes might be needed in the example app's iOS configuration. But since this is a plugin-level change, the plugin just needs to provide the `Package.swift`. The consuming app (example or user project) configures whether to use SPM or CocoaPods.\n\nFor testing SPM in CI, we'd need to add a new job or step that builds with SPM enabled.\n\nLet me now write the final, detailed plan.","time":{"start":1784440957547,"end":1784440968876},"id":"prt_f78f82a6b001jVCrsPzLnV02VB","sessionID":"ses_0870a8120ffe1nFRAiBYXrKHEY","messageID":"msg_f78f823fe001fbIbIxUFdvy49z"},{"type":"text","text":"Now I have a complete picture. Here are the recommended implementation steps:\n\n---\n\n# Implementation Plan: Add SPM Support to `zstandard_ios`\n\n## 1. Commit zstd C sources to the plugin\n\n**Why:** SPM, unlike CocoaPods, has no `prepare_command` equivalent to dynamically sync sources at resolution time. The zstd C sources must be present as committed files.\n\n**Actions:**\n- Run `bash scripts/sync_zstd.sh` from `zstandard_ios/` to populate `ios/Classes/zstd/`\n- Verify the sync removed `module.modulemap` (it clashes with module build)\n- Verify the sync does **not** copy `decompress/huf_decompress_amd64.S` (assembly not supported on iOS; currently excluded by the `.c` glob in the podspec but `rsync -a` will copy it — add `--exclude='*.S'` to `sync_zstd.sh` for the iOS copy)\n- Ensure `ios/Classes/zstd/` is **not** in any `.gitignore` (currently not listed)\n- Commit the `ios/Classes/zstd/` directory\n\n**Relevant files:**\n| File | Change |\n|------|--------|\n| `zstandard_ios/scripts/sync_zstd.sh` | Add `--exclude='*.S'` to the `rsync` line (iOS-only; macOS needs `.S` files) |\n| `zstandard_ios/ios/Classes/zstd/` | New committed directory (the synced zstd C sources) |\n| `zstandard_ios/.gitignore` | Verify no exclusion for `ios/Classes/zstd` |\n\n## 2. Remove sync/cleanup script phases from `zstandard_ios.podspec`\n\n**Why:** Sources are now committed, so the dynamic sync and post-build cleanup are unnecessary. Removing them avoids the risk of the sync script deleting the committed sources if `zstandard_native` is unavailable.\n\n**Actions:**\n- Remove the `s.prepare_command` line\n- Remove the entire `s.script_phases` array\n- Keep all other podspec settings (`source_files`, `public_header_files`, `xcconfig`, etc.) unchanged — they work fine with committed sources\n\n**Podspec diff:**\ndiff\n-  s.prepare_command = \"bash '../scripts/sync_zstd.sh'\"\n   ...\n-  s.script_phases = [\n-    { :name => 'Sync zstd', ... },\n-    { :name => 'Remove synced zstd', ... }\n-  ]\n\n\n## 3. Create `ios/Package.swift`\n\n**Why:** This is the core of SPM support. Flutter's iOS build system detects `Package.swift` in a plugin's `ios/` directory and adds it as a local SwiftPM dependency.\n\n**Key requirements:**\n- Package name must match the framework name (`zstandard_ios`) for `DynamicLibrary.open('zstandard_ios.framework/zstandard_ios')` to work\n- Target path must point to `Classes/` (relative to `ios/`) where both the Swift plugin and zstd C sources live\n- Must compile all zstd `.c` sources (auto-discovered from `Classes/zstd/`)\n- Must define `ZSTD_STATIC_LINKING_ONLY` and `ZSTD_DISABLE_ASM` (matching podspec)\n- Must exclude `decompress/huf_decompress_amd64.S` (assembly not supported on iOS)\n- Must set `publicHeadersPath` to `\"zstd\"` so `zstd.h` is findable\n- Minimum iOS version: 13.0 (matching podspec)\n\nswift\n// swift-tools-version: 5.3\nimport PackageDescription\n\nlet package = Package(\n    name: \"zstandard_ios\",\n    platforms: [\n        .iOS(.v13),\n    ],\n    products: [\n        .library(\n            name: \"zstandard_ios\",\n            targets: [\"zstandard_ios\"]\n        ),\n    ],\n    targets: [\n        .target(\n            name: \"zstandard_ios\",\n            path: \"Classes\",\n            exclude: [\n                \"zstd/decompress/huf_decompress_amd64.S\",\n                \"zstd/module.modulemap\",\n            ],\n            publicHeadersPath: \"zstd\",\n            cSettings: [\n                .headerSearchPath(\"zstd\"),\n                .define(\"ZSTD_STATIC_LINKING_ONLY\"),\n                .define(\"ZSTD_DISABLE_ASM\"),\n            ]\n        )\n    ]\n)\n\n\n**Notes:**\n- `module.modulemap` is excluded because the sync script already removes it (it conflicts with the module build under the podspec; for SPM it would also cause issues)\n- `publicHeadersPath: \"zstd\"` makes `zstd.h` a public header of the module (needed by the Swift plugin and for any bridging)\n- SPM 5.3 is the minimum for `cSettings` and `publicHeadersPath`\n\n**Relevant files:**\n| File | Change |\n|------|--------|\n| `zstandard_ios/ios/Package.swift` | New file (content above) |\n\n## 4. Update CI workflow to validate SPM integration\n\n**Why:** Ensure the `Package.swift` is valid and the example app can build with SPM enabled.\n\n**Actions in `.github/workflows/pr_check_ios.yml`:**\n- Add a new job `check_ios_spm` that:\n  1. Runs `flutter pub get` in the example app\n  2. Runs `flutter build ios --no-codesign --ios-swift-package-manager` (or equivalent SPM-enabled build command)\n  3. Validates no \"does not support Swift Package Manager\" warning appears\n- Alternatively, add a step to validate the `Package.swift` itself: `swift package resolve` from `zstandard_ios/ios/`\n\n**Relevant files:**\n| File | Change |\n|------|--------|\n| `.github/workflows/pr_check_ios.yml` | Add SPM validation job |\n\n## 5. Update documentation\n\n**Actions:**\n- Update `zstandard_ios/README.md` to mention SPM support and the `Package.swift` location\n- Add a changelog entry in `zstandard_ios/CHANGELOG.md` (e.g., \"Add Swift Package Manager support for iOS\")\n- Update `docs/guides/installation.md` if it describes iOS setup\n\n## 6. Test end-to-end\n\n**Manual verification:**\n1. Create a new Flutter project\n2. Add `zstandard` as a dependency (pointing to local path or pub.dev)\n3. Enable SPM in the Flutter project: `flutter build ios --ios-swift-package-manager`\n4. Verify no warning about `zstandard_ios` not supporting SPM\n5. Verify compression/decompression works at runtime\n\n## 7. (Optional) Apply the same pattern to `zstandard_macos`\n\n**Why:** The macOS plugin has an identical architecture (sync script + podspec). If SPM is needed for macOS Catalyst or future Flutter requirements, the same approach applies.\n\n**Actions:**\n- Commit zstd sources to `zstandard_macos/macos/Classes/zstd/` (including `.S` files since macOS supports assembly)\n- Create `zstandard_macos/macos/Package.swift`\n- Update `zstandard_macos` podspec similarly\n\n---\n\n## Summary of all files to create/modify\n\n| File | Action |\n|------|--------|\n| `zstandard_ios/scripts/sync_zstd.sh` | Add `--exclude='*.S'` to `rsync` (line 54) |\n| `zstandard_ios/ios/Classes/zstd/` | New committed directory (synced zstd sources) |\n| `zstandard_ios/ios/Package.swift` | **Create** — SPM manifest |\n| `zstandard_ios/ios/zstandard_ios.podspec` | Remove `prepare_command` and `script_phases` |\n| `zstandard_ios/CHANGELOG.md` | Add SPM support entry |\n| `zstandard_ios/README.md` | Document SPM support |\n| `zstandard_ios/.gitignore` | Verify (no change needed likely) |\n| `.github/workflows/pr_check_ios.yml` | Add SPM validation job |","time":{"start":1784440968878,"end":1784440984740},"id":"prt_f78f856ae001r2V8eeX0lbHwh1","sessionID":"ses_0870a8120ffe1nFRAiBYXrKHEY","messageID":"msg_f78f823fe001fbIbIxUFdvy49z"},{"reason":"stop","snapshot":"d88dd86112768d34fab7e335fe13024c3ff3f561","type":"step-finish","tokens":{"total":39781,"input":1184,"output":1802,"reasoning":1083,"cache":{"write":0,"read":35712}},"cost":0,"id":"prt_f78f894c2001lhriK7sf3dB3qq","sessionID":"ses_0870a8120ffe1nFRAiBYXrKHEY","messageID":"msg_f78f823fe001fbIbIxUFdvy49z"}]}
[DEBUG] OpenCode agent "build" message parts: 4 part(s) — [0] type=step-start length=0 | [1] type=reasoning length=4413 | [2] type=text length=6548 | [3] type=step-finish length=0
[DEBUG] OpenCode part [1] type=reasoning full text:
Now I have all the information I need. Let me check whether there's a `module.modulemap` in the zstd source that causes issues.

Looking at the glob results:
- There's a `module.modulemap` at `zstandard_native/src/zstd/module.modulemap`
- There's one `.S` file: `zstandard_native/src/zstd/decompress/huf_decompress_amd64.S`
- There are many `.c` and `.h` files under `common/`, `compress/`, `decompress/`, `dictBuilder/`, `legacy/`, `deprecated/`

The sync script already removes `module.modulemap` during sync.

Now let me formulate the complete implementation plan. I'll organize it into clear, actionable steps.

Here's my plan:

### Step 1: Commit the zstd C sources

The current approach dynamically syncs zstd sources. For SPM, committed sources are needed.

**Actions:**
- Run `bash scripts/sync_zstd.sh` from `zstandard_ios/` to populate `ios/Classes/zstd/`
- Verify the directory structure matches what's expected
- Ensure `.gitignore` doesn't exclude `ios/Classes/zstd` (currently doesn't)
- Add and commit the sources

### Step 2: Update `.gitignore` if needed

Check that `ios/Classes/zstd` isn't gitignored.

### Step 3: Create `ios/Package.swift`

Create the SPM manifest.

### Step 4: Update `zstandard_ios.podspec`

Since sources are now committed, the `prepare_command` and `script_phases` for syncing are no longer strictly needed for the podspec, but they can remain as a safety net to ensure freshness. Let me think about this...

Actually, there's a subtle issue: if we keep the sync script, it will overwrite the committed sources at pod install time, which means the committed sources are just a fallback. But if the sync runs and fails (e.g., in an environment without `zstandard_native` available), the committed sources would be deleted first (`rm -rf "$DEST"` in the script). That would break both CocoaPods and SPM.

So the safest approach is:
1. Remove the sync/cleanup phases from the podspec
2. Rely on committed sources for both CocoaPods and SPM
3. Keep `sync_zstd.sh` as a manual maintenance script

### Step 5: Update CI

The iOS PR check workflows should be updated to test SPM integration.

### Step 6: Update documentation

Update README and CHANGELOG.

### Step 7: Test

Verify the example app builds with SPM enabled.

Now, let me also think about one more thing: Flutter's SPM support is opt-in. Users need to enable it in their Flutter project with `flutter build ios --ios-swift-package-manager` or by adding configuration in their project. The plugin just needs to provide the `Package.swift`.

Let me also check what changes are needed in the example app to test SPM.

For the example app to build with SPM, the user would need to:
1. Have `ios/Package.swift` in the plugin
2. In the example app, enable SPM (perhaps via `flutter build ios --ios-swift-package-manager`)

But for testing purposes, we can verify that the `Package.swift` is valid by running `swift package resolve` or `xcodebuild` with SPM enabled.

Actually, there's another important consideration. When Flutter resolves SPM packages for plugins, it reads the `Package.swift` in the plugin's `ios/` directory and adds it as a local package dependency to the app's Xcode project. The package name in `Package.swift` should match what Flutter expects.

Looking at Flutter's SPM integration code, Flutter looks for `Package.swift` in each plugin's `ios/` directory and adds them as local SwiftPM dependencies to the Xcode workspace. The package name becomes the framework name.

So the framework produced by SPM would be named `zstandard_ios` (from the `name` parameter in `Package.swift`). The Dart FFI code loads `zstandard_ios.framework/zstandard_ios`, which matches.

OK I'm confident in the plan now. Let me write it up.

One more thing: should I also add `zstandard_macos` support? The issue only mentions iOS, so I'll focus on iOS but mention macOS as a future consideration.

Let me also think about whether we need to update the example app's Podfile or project configuration. For the example app to build with SPM, changes might be needed in the example app's iOS configuration. But since this is a plugin-level change, the plugin just needs to provide the `Package.swift`. The consuming app (example or user project) configures whether to use SPM or CocoaPods.

For testing SPM in CI, we'd need to add a new job or step that builds with SPM enabled.

Let me now write the final, detailed plan.
[DEBUG] OpenCode part [2] type=text full text:
Now I have a complete picture. Here are the recommended implementation steps:

---

# Implementation Plan: Add SPM Support to `zstandard_ios`

## 1. Commit zstd C sources to the plugin

**Why:** SPM, unlike CocoaPods, has no `prepare_command` equivalent to dynamically sync sources at resolution time. The zstd C sources must be present as committed files.

**Actions:**
- Run `bash scripts/sync_zstd.sh` from `zstandard_ios/` to populate `ios/Classes/zstd/`
- Verify the sync removed `module.modulemap` (it clashes with module build)
- Verify the sync does **not** copy `decompress/huf_decompress_amd64.S` (assembly not supported on iOS; currently excluded by the `.c` glob in the podspec but `rsync -a` will copy it — add `--exclude='*.S'` to `sync_zstd.sh` for the iOS copy)
- Ensure `ios/Classes/zstd/` is **not** in any `.gitignore` (currently not listed)
- Commit the `ios/Classes/zstd/` directory

**Relevant files:**
| File | Change |
|------|--------|
| `zstandard_ios/scripts/sync_zstd.sh` | Add `--exclude='*.S'` to the `rsync` line (iOS-only; macOS needs `.S` files) |
| `zstandard_ios/ios/Classes/zstd/` | New committed directory (the synced zstd C sources) |
| `zstandard_ios/.gitignore` | Verify no exclusion for `ios/Classes/zstd` |

## 2. Remove sync/cleanup script phases from `zstandard_ios.podspec`

**Why:** Sources are now committed, so the dynamic sync and post-build cleanup are unnecessary. Removing them avoids the risk of the sync script deleting the committed sources if `zstandard_native` is unavailable.

**Actions:**
- Remove the `s.prepare_command` line
- Remove the entire `s.script_phases` array
- Keep all other podspec settings (`source_files`, `public_header_files`, `xcconfig`, etc.) unchanged — they work fine with committed sources

**Podspec diff:**
diff
-  s.prepare_command = "bash '../scripts/sync_zstd.sh'"
   ...
-  s.script_phases = [
-    { :name => 'Sync zstd', ... },
-    { :name => 'Remove synced zstd', ... }
-  ]


## 3. Create `ios/Package.swift`

**Why:** This is the core of SPM support. Flutter's iOS build system detects `Package.swift` in a plugin's `ios/` directory and adds it as a local SwiftPM dependency.

**Key requirements:**
- Package name must match the framework name (`zstandard_ios`) for `DynamicLibrary.open('zstandard_ios.framework/zstandard_ios')` to work
- Target path must point to `Classes/` (relative to `ios/`) where both the Swift plugin and zstd C sources live
- Must compile all zstd `.c` sources (auto-discovered from `Classes/zstd/`)
- Must define `ZSTD_STATIC_LINKING_ONLY` and `ZSTD_DISABLE_ASM` (matching podspec)
- Must exclude `decompress/huf_decompress_amd64.S` (assembly not supported on iOS)
- Must set `publicHeadersPath` to `"zstd"` so `zstd.h` is findable
- Minimum iOS version: 13.0 (matching podspec)

swift
// swift-tools-version: 5.3
import PackageDescription

let package = Package(
    name: "zstandard_ios",
    platforms: [
        .iOS(.v13),
    ],
    products: [
        .library(
            name: "zstandard_ios",
            targets: ["zstandard_ios"]
        ),
    ],
    targets: [
        .target(
            name: "zstandard_ios",
            path: "Classes",
            exclude: [
                "zstd/decompress/huf_decompress_amd64.S",
                "zstd/module.modulemap",
            ],
            publicHeadersPath: "zstd",
            cSettings: [
                .headerSearchPath("zstd"),
                .define("ZSTD_STATIC_LINKING_ONLY"),
                .define("ZSTD_DISABLE_ASM"),
            ]
        )
    ]
)


**Notes:**
- `module.modulemap` is excluded because the sync script already removes it (it conflicts with the module build under the podspec; for SPM it would also cause issues)
- `publicHeadersPath: "zstd"` makes `zstd.h` a public header of the module (needed by the Swift plugin and for any bridging)
- SPM 5.3 is the minimum for `cSettings` and `publicHeadersPath`

**Relevant files:**
| File | Change |
|------|--------|
| `zstandard_ios/ios/Package.swift` | New file (content above) |

## 4. Update CI workflow to validate SPM integration

**Why:** Ensure the `Package.swift` is valid and the example app can build with SPM enabled.

**Actions in `.github/workflows/pr_check_ios.yml`:**
- Add a new job `check_ios_spm` that:
  1. Runs `flutter pub get` in the example app
  2. Runs `flutter build ios --no-codesign --ios-swift-package-manager` (or equivalent SPM-enabled build command)
  3. Validates no "does not support Swift Package Manager" warning appears
- Alternatively, add a step to validate the `Package.swift` itself: `swift package resolve` from `zstandard_ios/ios/`

**Relevant files:**
| File | Change |
|------|--------|
| `.github/workflows/pr_check_ios.yml` | Add SPM validation job |

## 5. Update documentation

**Actions:**
- Update `zstandard_ios/README.md` to mention SPM support and the `Package.swift` location
- Add a changelog entry in `zstandard_ios/CHANGELOG.md` (e.g., "Add Swift Package Manager support for iOS")
- Update `docs/guides/installation.md` if it describes iOS setup

## 6. Test end-to-end

**Manual verification:**
1. Create a new Flutter project
2. Add `zstandard` as a dependency (pointing to local path or pub.dev)
3. Enable SPM in the Flutter project: `flutter build ios --ios-swift-package-manager`
4. Verify no warning about `zstandard_ios` not supporting SPM
5. Verify compression/decompression works at runtime

## 7. (Optional) Apply the same pattern to `zstandard_macos`

**Why:** The macOS plugin has an identical architecture (sync script + podspec). If SPM is needed for macOS Catalyst or future Flutter requirements, the same approach applies.

**Actions:**
- Commit zstd sources to `zstandard_macos/macos/Classes/zstd/` (including `.S` files since macOS supports assembly)
- Create `zstandard_macos/macos/Package.swift`
- Update `zstandard_macos` podspec similarly

---

## Summary of all files to create/modify

| File | Action |
|------|--------|
| `zstandard_ios/scripts/sync_zstd.sh` | Add `--exclude='*.S'` to `rsync` (line 54) |
| `zstandard_ios/ios/Classes/zstd/` | New committed directory (synced zstd sources) |
| `zstandard_ios/ios/Package.swift` | **Create** — SPM manifest |
| `zstandard_ios/ios/zstandard_ios.podspec` | Remove `prepare_command` and `script_phases` |
| `zstandard_ios/CHANGELOG.md` | Add SPM support entry |
| `zstandard_ios/README.md` | Document SPM support |
| `zstandard_ios/.gitignore` | Verify (no change needed likely) |
| `.github/workflows/pr_check_ios.yml` | Add SPM validation job |
[INFO] OpenCode response [agent build] responseLength=6548 sessionId=ses_0870a8120ffe1nFRAiBYXrKHEY
[DEBUG] RecommendSteps: OpenCode response received. Steps length=6548. Full steps:
Now I have a complete picture. Here are the recommended implementation steps:

---

# Implementation Plan: Add SPM Support to `zstandard_ios`

## 1. Commit zstd C sources to the plugin

**Why:** SPM, unlike CocoaPods, has no `prepare_command` equivalent to dynamically sync sources at resolution time. The zstd C sources must be present as committed files.

**Actions:**
- Run `bash scripts/sync_zstd.sh` from `zstandard_ios/` to populate `ios/Classes/zstd/`
- Verify the sync removed `module.modulemap` (it clashes with module build)
- Verify the sync does **not** copy `decompress/huf_decompress_amd64.S` (assembly not supported on iOS; currently excluded by the `.c` glob in the podspec but `rsync -a` will copy it — add `--exclude='*.S'` to `sync_zstd.sh` for the iOS copy)
- Ensure `ios/Classes/zstd/` is **not** in any `.gitignore` (currently not listed)
- Commit the `ios/Classes/zstd/` directory

**Relevant files:**
| File | Change |
|------|--------|
| `zstandard_ios/scripts/sync_zstd.sh` | Add `--exclude='*.S'` to the `rsync` line (iOS-only; macOS needs `.S` files) |
| `zstandard_ios/ios/Classes/zstd/` | New committed directory (the synced zstd C sources) |
| `zstandard_ios/.gitignore` | Verify no exclusion for `ios/Classes/zstd` |

## 2. Remove sync/cleanup script phases from `zstandard_ios.podspec`

**Why:** Sources are now committed, so the dynamic sync and post-build cleanup are unnecessary. Removing them avoids the risk of the sync script deleting the committed sources if `zstandard_native` is unavailable.

**Actions:**
- Remove the `s.prepare_command` line
- Remove the entire `s.script_phases` array
- Keep all other podspec settings (`source_files`, `public_header_files`, `xcconfig`, etc.) unchanged — they work fine with committed sources

**Podspec diff:**
diff
-  s.prepare_command = "bash '../scripts/sync_zstd.sh'"
   ...
-  s.script_phases = [
-    { :name => 'Sync zstd', ... },
-    { :name => 'Remove synced zstd', ... }
-  ]


## 3. Create `ios/Package.swift`

**Why:** This is the core of SPM support. Flutter's iOS build system detects `Package.swift` in a plugin's `ios/` directory and adds it as a local SwiftPM dependency.

**Key requirements:**
- Package name must match the framework name (`zstandard_ios`) for `DynamicLibrary.open('zstandard_ios.framework/zstandard_ios')` to work
- Target path must point to `Classes/` (relative to `ios/`) where both the Swift plugin and zstd C sources live
- Must compile all zstd `.c` sources (auto-discovered from `Classes/zstd/`)
- Must define `ZSTD_STATIC_LINKING_ONLY` and `ZSTD_DISABLE_ASM` (matching podspec)
- Must exclude `decompress/huf_decompress_amd64.S` (assembly not supported on iOS)
- Must set `publicHeadersPath` to `"zstd"` so `zstd.h` is findable
- Minimum iOS version: 13.0 (matching podspec)

swift
// swift-tools-version: 5.3
import PackageDescription

let package = Package(
    name: "zstandard_ios",
    platforms: [
        .iOS(.v13),
    ],
    products: [
        .library(
            name: "zstandard_ios",
            targets: ["zstandard_ios"]
        ),
    ],
    targets: [
        .target(
            name: "zstandard_ios",
            path: "Classes",
            exclude: [
                "zstd/decompress/huf_decompress_amd64.S",
                "zstd/module.modulemap",
            ],
            publicHeadersPath: "zstd",
            cSettings: [
                .headerSearchPath("zstd"),
                .define("ZSTD_STATIC_LINKING_ONLY"),
                .define("ZSTD_DISABLE_ASM"),
            ]
        )
    ]
)


**Notes:**
- `module.modulemap` is excluded because the sync script already removes it (it conflicts with the module build under the podspec; for SPM it would also cause issues)
- `publicHeadersPath: "zstd"` makes `zstd.h` a public header of the module (needed by the Swift plugin and for any bridging)
- SPM 5.3 is the minimum for `cSettings` and `publicHeadersPath`

**Relevant files:**
| File | Change |
|------|--------|
| `zstandard_ios/ios/Package.swift` | New file (content above) |

## 4. Update CI workflow to validate SPM integration

**Why:** Ensure the `Package.swift` is valid and the example app can build with SPM enabled.

**Actions in `.github/workflows/pr_check_ios.yml`:**
- Add a new job `check_ios_spm` that:
  1. Runs `flutter pub get` in the example app
  2. Runs `flutter build ios --no-codesign --ios-swift-package-manager` (or equivalent SPM-enabled build command)
  3. Validates no "does not support Swift Package Manager" warning appears
- Alternatively, add a step to validate the `Package.swift` itself: `swift package resolve` from `zstandard_ios/ios/`

**Relevant files:**
| File | Change |
|------|--------|
| `.github/workflows/pr_check_ios.yml` | Add SPM validation job |

## 5. Update documentation

**Actions:**
- Update `zstandard_ios/README.md` to mention SPM support and the `Package.swift` location
- Add a changelog entry in `zstandard_ios/CHANGELOG.md` (e.g., "Add Swift Package Manager support for iOS")
- Update `docs/guides/installation.md` if it describes iOS setup

## 6. Test end-to-end

**Manual verification:**
1. Create a new Flutter project
2. Add `zstandard` as a dependency (pointing to local path or pub.dev)
3. Enable SPM in the Flutter project: `flutter build ios --ios-swift-package-manager`
4. Verify no warning about `zstandard_ios` not supporting SPM
5. Verify compression/decompression works at runtime

## 7. (Optional) Apply the same pattern to `zstandard_macos`

**Why:** The macOS plugin has an identical architecture (sync script + podspec). If SPM is needed for macOS Catalyst or future Flutter requirements, the same approach applies.

**Actions:**
- Commit zstd sources to `zstandard_macos/macos/Classes/zstd/` (including `.S` files since macOS supports assembly)
- Create `zstandard_macos/macos/Package.swift`
- Update `zstandard_macos` podspec similarly

---

## Summary of all files to create/modify

| File | Action |
|------|--------|
| `zstandard_ios/scripts/sync_zstd.sh` | Add `--exclude='*.S'` to `rsync` (line 54) |
| `zstandard_ios/ios/Classes/zstd/` | New committed directory (synced zstd sources) |
| `zstandard_ios/ios/Package.swift` | **Create** — SPM manifest |
| `zstandard_ios/ios/zstandard_ios.podspec` | Remove `prepare_command` and `script_phases` |
| `zstandard_ios/CHANGELOG.md` | Add SPM support entry |
| `zstandard_ios/README.md` | Document SPM support |
| `zstandard_ios/.gitignore` | Verify (no change needed likely) |
| `.github/workflows/pr_check_ios.yml` | Add SPM validation job |
[INFO] Main run finished. Results: 7, total steps: 6.
[INFO] Publishing result: 7 result(s), 6 step(s), 0 error(s).
[INFO] 📄 Executing PublishResultUseCase.

🚀 Happy coding!

^{Made with ❤️ by vypdev/copilot}

[efraespada]

This will be fixed on a couple of days. Thanks for reporting @zntus

[efraespada]

Swift Package Manager support is intentionally deferred for now.

The master branch contains the current supported CocoaPods implementation and the latest Apple build fixes. It does not provide Swift Package Manager support, so consuming master is not a workaround for the SPM warning when SPM is enabled.

For applications that need the current CocoaPods implementation before the next pub.dev release, the iOS package can temporarily be overridden with:

dependency_overrides:
  zstandard_ios:
    git:
      url: https://github.com/vypdev/zstandard.git
      ref: master
      path: zstandard_ios

Continue using CocoaPods and the default Flutter integration. SPM will be reconsidered once CI has an Apple toolchain capable of validating it reliably.