[shoaib-akhtar]

Fixes #231

Problem

SwiftFreeraspPlugin handles the start method call on the platform (main) thread and calls Talsec.start(config:) inline. Talsec.start generates a key through SecKeyGeneratePair → SecItemAdd, which is a synchronous XPC round trip to securityd. On iOS 26 that round trip has been measured blocking the main thread for 30+ seconds, which causes app-hang reports and WatchdogTermination kills on first launch (details in #231). Because the work runs inline, the Dart-side await Talsec.instance.start(config) gives no relief.

Change

• Talsec.start now runs on a serial background queue (talsec.app/freerasp/start, .userInitiated).
• The Flutter result is delivered on the main thread after Talsec.start returns, so await Talsec.instance.start(...) still means "the SDK has started".
• Config decoding errors are still returned straight away, as before.
• The other method channel calls are unchanged. blockScreenCapture/isScreenCaptureBlocked already hop to main.

This matches how the React Native bridge already calls Talsec.start: RN module methods run on a background method queue, so running the SDK start off-main has precedent in production.

I went with an explicit queue rather than a channel taskQueue: (option 1 in the issue) so that only start moves off the main thread and the change can be unit-tested directly.

Tests (written first)

The repo had no native iOS tests, so this adds a RunnerTests XCTest target to the example app (example/ios) and a small seam (talsecStarter) so tests can observe the call without running TalsecRuntime.

The commits are ordered red → green:

1. test(ios): …: the tests, run against the unchanged bridge:
   • testStartRunsTalsecOffTheMainThread: fails (Optional(true) is not equal to Optional(false))
   • testStartReturnsBeforeTalsecFinishes: fails (.timedOut, because handle blocked until start finished)
   • testStartRepliesOnTheMainThreadAfterTalsecStarts: passes (guard)
   • testStartWithInvalidConfigReturnsErrorWithoutStartingTalsec: passes (guard)
2. fix(ios): …: all 4 pass.

Run with:

cd example && flutter pub get && cd ios && pod install
xcodebuild test -workspace Runner.xcworkspace -scheme Runner \
  -destination 'platform=iOS Simulator,name=iPhone 17 Pro' -only-testing:RunnerTests

Verified on Xcode 26.1.1, iOS 26.1 simulator, Flutter 3.38.2. As an extra check, I also called the real TalsecRuntime start through the patched plugin from a test. It started off-main, replied, and did not crash.

Not covered

The issue also shows the same keychain path being reached from inside TalsecRuntime through a UIScreen KVO/notification callback. That code lives in the closed-source xcframework, so this PR can't change it.

[shoaib-akhtar]

Hi @tompsota, any chance you could take a look at this? It's the fix for the 30s main thread hang on iOS 26 from #231. It moves only start off the platform thread and still replies after the SDK has started. Let me know if you want anything changed.

[tompsota]

Thanks @shoaib-akhtar, this is a clean fix and the test-first commits made it easy to review. We're merging it.

Before merging, I pushed a few small updates to your branch:

• Rebased onto 8.3.0 and resolved the CHANGELOG conflict. Your [Unreleased] entry now sits above [8.3.0].
• Removed the Foundation.framework link from the RunnerTests target. It pointed to the iOS 18.0 SDK path, which doesn't exist in newer Xcode versions, and Swift links Foundation automatically.

On expectations: this change moves start off the platform thread, which removes the block you measured on that call. Not all of the SDK's startup work goes through this call, though, so it may not remove every hang reported in #231. We'll look at the rest on the native SDK side and update #231 when there's more.