You can inject @StateObject during initialization by unwrapping the property with _ Example: struct BinderView: View {   @StateObject var binder: Binder   init(name: String) {     _binder = StateObject(wrappedValue: Binder(name: name))   }   var body: some View {     Text(binder.name)   } }

Amazing, thanks! I've updated to macOS 11 beta 3 and the bug was resolved.

This forum post - https://developer.apple.com/forums/thread/653553?answerId=621106022#621106022 brought up the fact that websockets with longer message lengths cause connection close. It seems related to this extension, Sec-WebSocket-Extensions permessage-deflate. The packet capture shows the client does try to negotiate permessage-deflate extension, but the server does not respond with extension accepted. It seems like the RSV bit gets set regardless if the server accepts the extension. The workaround (if you own the server-side logic) is to enable the permessage-deflate option on the server side. Unfortunately while I have a local server to test on, my application relies on an external service where I don't own and cannot configure the server. Quinn, is it possible to configure URLSessionWebSockets to opt out of this particular extension?

Regarding Network.framework, I ran into segmentation faults when setting up a client connection. Am I missing something? Create and configure NWParameters. let parameters = NWParameters(tls: nil) let wsOptions = NWProtocolWebSocket.Options() parameters.defaultProtocolStack.applicationProtocols.insert(wsOptions, at: 0) Specify NWEndpoint host and port. Create the NWConnection using NWEndpoint and NWParameters. Set stateUpdateHandler in NWConnection instance Set receive() callback in NWConnection instance Start the connection

I took a little field trip and I came back with some packet trace files. Updated the bug report with files. I highly recommend learning how to inspect packets if you're an application developer and haven't had much exposure to the networking stack.

Ahh, I didn't include that the environment is running on macOS 11 beta with macOS 10.16. Let me get back to you on these: I'll try setting a websocket client using Network.framework directly and seeing how it goes. I'm unfamiliar with Network.framework so it will take some time. Attaching a packet trace - I originally debugged on my server to figure out how what frames are being sent. I'll find out how to capture a packet trace and follow up. Yeah... understanding and debugging at the networking layer is quite new to me so thanks again for guidance.

Thanks for the suggestion Quinn, I reproduced the problem without TLS using ws and observed the specific frames that the server receives during frame handling. The first byte of the problematic frame is 192, which is 1100 0010. This sets the RSV1 bit, and is invalid unless an extension is negotiated. My websocket frame handler reports that this as a bad frame because the RSV bit is set with no extension. The first byte of the good frame is 130 which is 1000 0010. Here the RSV bits aren't set. I haven't looked further than here, but it looks like the websocket framing is handled differently for these two binaries.

The connection close code is 1002, termination due to protocol error

The auto generated initializer that @KhaosT mentions allows you to inject the StateObject. The auto generated initializer must have functionality under the hood that tells SwiftUI to create the object only once. I haven't found a way to create your own custom init function if you want to inject StateObjects.