Repository navigation
fix(sensors_plus): isolate iOS stream handlers per engine - #3963
Open
FeliksLv01 wants to merge 1 commit into
Open
FeliksLv01 wants to merge 1 commit into
FeliksLv01 wants to merge 1 commit into
Conversation
6 of 7 tasks
FeliksLv01
force-pushed
the
fix/sensors-plus-ios-multi-engine
branch
from
November 12, 2026 06:18
2f5d49f to
88c5402
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fixes the iOS lifecycle crash and cross-engine stream interference described in #3955.
The plugin now publishes an engine-owned instance and implements
detachFromEngine(for:). Event channels and stream handlers are instance-owned, while each handler owns its CoreMotion object and event sink. Detaching one FlutterEngine therefore only stops that engine's streams; queued callbacks re-check the handler state before sending an event.The shared Swift handler base uses module visibility so the concrete handlers can be constructed from the plugin registration file.
Production crash evidence
An App Store crash on a physical iPhone running iOS 26.6.2 confirms the accelerometer callback path. The affected application uses a downstream sensors_plus fork, so its closure names differ from the upstream
sendFlutter(...)helper. Inspection of that fork confirms that it also has the incorrectdetachFromEngineForRegistrar(...)hook.The application frames below were symbolicated against the exact distributed IPA. Both the application executable UUID and Flutter framework UUID match the crash report. Flutter's Objective-C metadata additionally identifies the engine and messenger-relay methods. Application identity, release/build numbers, binary UUIDs, installation paths, incident identifiers, and internal service links have been removed.
This preserves the complete last-exception backtrace, rather than including unrelated background threads. A matching dSYM is not available, so source line numbers and the stripped Flutter frame are deliberately left unresolved. The corresponding production Sentry exception is
NSInternalInconsistencyException: Sending a message before the FlutterEngine has been run.; the Apple report independently shows the assertion in the engine's send method. This is evidence of a callback reaching an unavailable engine, not evidence of an out-of-memory termination.Related Issues
Checklist
Validation
flutter build ios --no-codesign --simulator --debug --target=lib/main.dart --dart-define=CI=true.git diff --check upstream/main...HEAD.Breaking Change