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.