Summary of changes

• When using the broadcast capturer on iOS, the broadcast extension now drives whether or not screen sharing is enabled, publishing a screen sharing track when the extension begins broadcasting upon user approval.
• The new BroadcastManager class gives developers control over the broadcast state and track publication for advanced use cases.
• Since the broadcast state is now managed within the library, the boilerplate required in the user's implementation is reduced; the example app has also been updated to reflect this.

Fixes

• Fixes [bug]The user did not click "Start Broadcast"，but the isScreenShareEnabled() method returns true on iOS #674

Minor breaking changes

• Enabling screen sharing with setScreenShareEnabled or setSourceEnabled on LocalParticipant currently returns a LocalTrackPublication representing the newly published screen share track. After this change, when using the broadcast capturer on iOS, this method will return null, as the track will be published asynchronously pending user approval. Developers should treat enabling screen share as a request that might not be fulfilled and should not interpret null return values from these methods as errors.
• Since track publication is now asynchronous, capture options must be set as room defaults rather than being passed to setSourceEnabled when enabling screen sharing.

Additional context

• Solution is very similar to the one implemented in the native Swift SDK: Properly handle broadcast capture state client-sdk-swift#551

Outstanding items

• Not ready to merge as it depends on the patch made in feat: Add option to start capture without broadcast picker flutter-webrtc/flutter-webrtc#1764