Swift中Vidyo iOS SDK在TestFlight发布版本的VCConnector初始化问题
I’ve run into this exact discrepancy between Debug/TestFlight builds with Vidyo’s iOS SDK before—let’s break down what’s happening and how to fix it.
The core problem here is clear: you’re initializing VCConnector with nil as the first parameter, instead of passing a valid UnsafeMutableRawPointer pointing to your custom Vidyo view. Debug builds in Xcode use minimal optimization, so the SDK might have some loose fallback logic that masks this issue locally. But TestFlight builds use Release-level optimizations, which tighten up memory layout and eliminate those safety nets—leading to the abnormal behavior you’re seeing.
Here’s the fix:
- First, make sure you have a valid, initialized Vidyo view instance (either programmatically created or loaded from a Storyboard/XIB). For example, declare it as a retained property in your view controller to avoid early deallocation:
var vidyoView: UIView! override func viewDidLoad() { super.viewDidLoad() vidyoView = UIView(frame: view.bounds) view.addSubview(vidyoView) } - Update your
VCConnectorinitialization to pass the pointer to this view instead ofnil:connector = VCConnector(UnsafeMutableRawPointer(&vidyoView), viewStyle: .default, remoteParticipants: 10, logFileFilter: UnsafePointer("warning"), logFileName: UnsafePointer(""), userData: 0)
Key notes to avoid future issues:
- Never use a local variable for the Vidyo view: If you declare
vidyoViewinside a function without retaining it as a property, optimized Release builds might deallocate it before theVCConnectorfinishes using it. - Wait for the view to fully load: If your Vidyo view comes from a Storyboard/XIB, initialize the
VCConnectorinviewDidAppearinstead ofviewDidLoadto ensure the view is fully initialized and part of the view hierarchy.
This change will align the behavior between your local builds and TestFlight releases, since the SDK will now have a valid view pointer to bind to for rendering.
内容的提问来源于stack exchange,提问作者Marco

