[andrea689]

Description

Since #3797 (7.3.0), the iOS plugin drops every connectivity update that arrives while UIApplication.applicationState is .background, so that it never sends on a FlutterEngine whose shell is already gone. That PR expected the state to resync on the next onListen or check call. A listener that stays subscribed gets neither, so onConnectivityChanged keeps reporting the old connectivity until the next path change, which may never come.

Steps to reproduce on a physical iPhone, with an app that keeps a Connectivity().onConnectivityChanged subscription open:

1. Open the app while on Wi-Fi.
2. Go to Settings, turn Wi-Fi off, and come back to the app.

NWPathMonitor reports the change while the app is in the background, and the plugin drops it. The stream never emits [mobile], even after a minute in the foreground. With 6.1.5 it emitted [mobile] right away.

This PR remembers that an update was dropped, and on UIApplication.didBecomeActiveNotification emits the current connectivity once:

• It emits the current path rather than the dropped one, because a newer update may still be queued on the main queue.
• Updates that arrive while the app is active or inactive are emitted right away, as before, and clear the flag. So do onCancel and detachFromEngine.
• The background guard from fix(connectivity_plus): guard eventSink after engine teardown (iOS) #3797 is unchanged: nothing is sent while the app is in the background.

Why this does not bring back the crash #3797 fixed: the extra emission happens only on didBecomeActive, when the app is .active. That is the same state in which every live update is already emitted today. The shell is destroyed on scene disconnect or terminate, and since #3957 the engine's dealloc calls detachFromEngine, which clears the sink and the flag. An engine kept alive after its shell is gone would already crash on the first path change in the foreground. This PR does not add a state in which the sink is called.

To make this testable, the plugin's internal initializer now takes the application state and the notification center. They default to UIApplication.shared.applicationState and NotificationCenter.default. The example's RunnerTests, until now the empty template, cover the event stream with a fake ConnectivityProvider, in 11 tests. With the initializer change alone, the 5 that cover the emission on becoming active fail. With the fix, all 11 pass.

The CI workflow does not run the native tests. To run them:

cd packages/connectivity_plus/connectivity_plus/example
flutter build ios --config-only --simulator
cd ios
xcodebuild test -workspace Runner.xcworkspace -scheme Runner -only-testing:RunnerTests \
  -destination 'platform=iOS Simulator,name=iPhone 17'

Tested:

• The RunnerTests above, on an iPhone 17 simulator with iOS 27.0.
• flutter test integration_test/connectivity_plus_test.dart on the same simulator.
• A build with SWIFT_STRICT_CONCURRENCY=complete. It shows the same warnings in ConnectivityPlusPlugin.swift as main, and none new.
• On a physical iPhone 16 Pro with iOS 27.0.1, using an app built with this branch's iOS sources: the steps above, turning Wi-Fi off and then on again. Each time the stream emitted the new state within a few milliseconds of the app becoming active.

Related Issues

• Related fix(connectivity_plus): guard eventSink after engine teardown (iOS) #3797

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
• No, this is not a breaking change.