Rc/8.1.0

[martinzigrai]

resolves #203
dSYMs.zip

[tompsota]

@martinzigrai , the ios hierarchy looks like this: ios/freerasp/Sources/freerasp/..., i.e there is extra freerasp subfolder. Can you remove it?

[tompsota]

When you run example app, there are some modified files. Can you commit them?

[tompsota]

Add a CI job that builds the example app with SPM

Right now nothing in CI exercises the Swift Package Manager path that this PR adds. build-ios in .github/workflows/flutter-ci.yml runs flutter build ios --release --no-codesign with SPM disabled (it's still opt-in behind flutter config --enable-swift-package-manager), so the example app is built through CocoaPods and ios/freerasp/Package.swift is never even read. A typo in the manifest, a wrong binaryTarget checksum, or a broken artifact URL would all merge green.

Two things need to happen:

1. Commit the example app's SPM migration. The six modified files under example/ios/ (the FlutterGeneratedPluginSwiftPackage reference in project.pbxproj, freerasp removed from Podfile.lock, the scheme pre-action, the UIApplicationSceneManifest entry in Info.plist, and the AppDelegate rewritten onto FlutterImplicitEngineDelegate) are currently uncommitted, so they're not on this branch.

2. Add a second iOS job that builds with SPM enabled, keeping the existing CocoaPods job so both integration paths stay covered:

  build-ios-spm:
    runs-on: macos-latest
    needs: test
    steps:
      - name: 📚 Git Checkout
        uses: actions/checkout@v6

      - name: 🐦 Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          channel: stable
          flutter-version: 3.41.0   # FlutterFramework SwiftPM package requires 3.41.0+
          cache: true

      - name: 📦 Enable Swift Package Manager
        run: flutter config --enable-swift-package-manager

      - name: 🍎 Build iOS app (SPM)
        working-directory: example
        run: flutter build ios --release --no-codesign

Note that the workflow currently pins FLUTTER_VERSION: 3.24.0, which predates everything the migrated example app relies on — FlutterImplicitEngineDelegate, FlutterSceneDelegate, and the generated FlutterFramework package are all 3.35+/3.41+. If the example changes are committed without also raising the Flutter version, the existing build-ios job will fail to compile AppDelegate.swift. Either raise FLUTTER_VERSION for both jobs, or keep the CocoaPods job on an older pinned version and give the SPM job its own.

A cheap extra safety net worth considering in the same job: download the URL from the binaryTarget, verify its SHA-256 against the declared checksum, and diff it against the committed ios/freerasp/TalsecRuntime.xcframework. Right now the two copies of the SDK are in sync (I verified this locally), but nothing prevents a future SDK bump from updating one and not the other, which would silently ship different SDK versions to CocoaPods and SPM consumers.

[tompsota]

Document the Flutter 3.41.0 minimum for the SPM path

The changelog entry says "Swift Package Manager (SPM) support for iOS" without qualification, and neither the README nor the docs mention a version requirement. In practice SPM support here requires Flutter 3.41.0 or newer, and consumers on older SDKs who enable the feature flag will hit a build failure with no indication of why.

Why 3.41.0 specifically. ios/freerasp/Package.swift declares a dependency on a package that the Flutter tool generates:

dependencies: [
    .package(name: "FlutterFramework", path: "../FlutterFramework")
]

This is a filesystem path, not a registry lookup, so if nothing exists at that location SPM fails during resolution with "the package at ... cannot be accessed" before anything compiles. What's on disk depends on the Flutter version:

Change	Landed in
SPM as opt-in feature (--enable-swift-package-manager)	3.24.0
Plugins symlinked into a shared .packages/ directory	3.35.0
FlutterFramework package generated	3.41.0

• 3.24–3.34: plugins weren't symlinked yet, so ../FlutterFramework resolves to a sibling of the plugin inside the pub cache (~/.pub-cache/hosted/pub.dev/freerasp-8.1.0/ios/FlutterFramework). Nothing ever puts a package there. In these versions plugins didn't declare a Flutter dependency at all — the tool injected framework search paths instead.
• 3.35–3.40: the symlink directory exists so the path now points at the right conceptual location (ios/Flutter/ephemeral/Packages/.packages/FlutterFramework), but the tool still doesn't create it. Same failure.
• 3.41.0+: generated by generatePluginsSwiftPackage, so it resolves correctly.

(Introduced by flutter/flutter#181578, "Generate Flutter framework swift package", first released in 3.41.0.)

Suggested handling. I'd leave the flutter: ">=3.24.0" constraint in pubspec.yaml as is rather than raising it. pub has no way to express "3.41+ only when using SPM", so bumping it would lock out every CocoaPods consumer on an older SDK — who are entirely unaffected — for the sake of the opt-in SPM minority. Documenting it is the cheaper trade:

• CHANGELOG: change the bullet to something like "Added Swift Package Manager (SPM) support for iOS. Requires Flutter 3.41.0 or newer; CocoaPods remains supported on older versions."
• Docs / README: state the same in the iOS integration section, alongside the raised iOS 13.0 deployment target, which is also currently undocumented outside the changelog.

Worth noting the blast radius is limited — SPM is still opt-in behind the feature flag even in 3.41, so only users who explicitly enabled it are exposed. But those are exactly the users this feature was built for, and the failure they'd get is an opaque SPM resolution error that gives no hint that their Flutter version is the problem.

[martinzigrai]

the ios hierarchy looks like this: ios/freerasp/Sources/freerasp/..., i.e there is extra freerasp subfolder. Can you remove it?

Done. Verified both CocoaPods and SPM builds.

[martinzigrai]

When you run example app, there are some modified files. Can you commit them?

Left these out on purpose. The example only builds with SPM when the checkout directory is named freerasp, and ours is Free-RASP-Flutter. Flutter derives the SPM package identity from the plugin directory's basename, while the example-only local override is keyed by the plugin name, so resolution fails:

unable to override package 'freerasp' because its identity 'free-rasp-flutter' doesn't match override's identity (directory name) 'freerasp'

Tested with the same migrated files: builds in a freerasp/ dir, fails in Free-RASP-Flutter/. Since actions/checkout uses the repo name, committing them wouldn't make CI pass, and Flutter regenerates the migration on the fly anyway. Covered the SPM path with a consumer app in CI instead (see the CI comment).

[martinzigrai]

Add a CI job that builds the example app with SPM

Added a build-ios-spm job, but it builds a throwaway consumer app instead of the example (flutter create + flutter pub add freerasp --path . + SPM + flutter build ios). A consumer doesn't get the example-only override, so it builds regardless of the checkout directory name and still exercises Package.swift and the binary linking. It's green in CI.

Also dropped the remote binaryTarget(url:): CI hit a SwiftPM already exists in file system download bug on the runner's Xcode (would hit consumers on those versions too), and since the xcframework is committed anyway for CocoaPods, the URL gave no size benefit. SPM now points a local binaryTarget(path:) at the same file, so SPM and CocoaPods use one source of truth and can't drift (so no checksum/drift check is needed).

[martinzigrai]

Document the Flutter 3.41.0 minimum for the SPM path

Documented in the CHANGELOG.