So I'm dealing with a really obtuse crash that appears to be a stack overflow in an internal SwiftUI code path creating a Color.Resolved. I haven't found anyone one else with this issue online, and I cannot get it to reproduce on my own device. Interestingly enough, it is only happening on 1 device in the field (according to XCode crash logs). Here are some lines from the crashed thread. You can see that my code is never called, and it appears to be starting in some Array equality check checking the equality of colors (which I can't think of anywhere in my app I am doing anyway). You can see from this trace here that it appears to be a recursive call through Color.Resolved and NSColor.withColorAppearance. I don't have any idea how to solve this, but it keeps happening with at least one in-the-field device across multiple app updates. So my whole app is open source on github at https://github.com/msdrigg/roam, but I don't even use NSColor explicitly anywhere except for here which doesn't match the stack trace. I also tried changing the accent color of the app with defaults write com.msdrigg.roam AppleAccentColor -integer 1 to see if that somehow caused the crash, but my app opened up totally fine (and respected the change). Besides this, the only places I think I could be using dynamic colors is I when define an AccentColor and a WidgetBackground color for my app using xcassets, and then I use these colors from SwiftUI. In most of my app I stick to the system colors (Color.gray and such). Thread 0 Crashed: 0 libsystem_pthread.dylib 0x000000018601213c ___chkstk_darwin + 60 1 CoreFoundation 0x0000000186108434 -[NSArray isEqualToArray:] + 52 (NSArray.m:454) 2 AppKit 0x000000018a21fcd4 -[NSCoreUICatalogColor resolvedCUINamedColorForAppearance:] + 164 (NSColor.m:5057) 3 AppKit 0x0000000189c32cd4 -[NSCoreUICatalogColor resolvedColor] + 48 (NSColor.m:5148) 4 AppKit 0x0000000189c31e74 -[NSDynamicNamedColor colorUsingColorSpace:] + 32 (NSColor.m:4410) 5 SwiftUICore 0x0000000221ca9fd8 CoreColorPlatformColorGetComponents + 116 (CoreColorFunctions.m:149) 6 SwiftUICore 0x0000000221faaf28 specialized Color.Resolved.init(platformColor:) + 92 (CoreColor.swift:14) 7 SwiftUICore 0x0000000221faa5b0 Color.Resolved.init(platformColor:) + 16 (<compiler-generated>:0) 8 SwiftUI 0x00000001b53b1dc4 closure #1 in NSColor.resolve(in:) + 20 (AppKitColorConversions.swift:156) 9 SwiftUI 0x00000001b53b222c partial apply for closure #1 in static NSColor.withColorAppearance(in:_:) + 32 (<compiler-generated>:0) 10 SwiftUI 0x00000001b46b1e54 closure #1 in SubmitTriggerSource.dispatchUpdate(_:) + 28 (PlatformViewCoordinator.swift:12) 11 SwiftUI 0x00000001b5484488 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0) 12 AppKit 0x0000000189c174a4 +[NSAppearance _performWithCurrentAppearance:usingBlock:] + 72 (NSAppearance.m:2408) 13 SwiftUI 0x00000001b53b2088 specialized static NSColor.withColorAppearance(in:_:) + 324 (AppKitColorConversions.swift:142) 14 SwiftUI 0x00000001b53b1e7c protocol witness for ColorProvider.resolve(in:) in conformance NSColor + 68 (<compiler-generated>:151) 15 SwiftUICore 0x0000000222436e6c ColorBox.resolve(in:) + 124 (Color.swift:288) 16 SwiftUICore 0x0000000222435e30 Color.resolve(in:) + 72 (Color.swift:87) 17 SwiftUI 0x00000001b53b1c88 closure #1 in NSColor.init(_:) + 196 (AppKitColorConversions.swift:124) 18 SwiftUI 0x00000001b4542714 thunk for @escaping @callee_guaranteed (@guaranteed NSAppearance) -> (@owned NSColor) + 56 (<compiler-generated>:0) 19 AppKit 0x0000000189c31e74 -[NSDynamicNamedColor colorUsingColorSpace:] + 32 (NSColor.m:4410) //// ... Repeating for 500 lines 500 SwiftUICore 0x0000000221ca9fd8 CoreColorPlatformColorGetComponents + 116 (CoreColorFunctions.m:149) 501 SwiftUICore 0x0000000221faaf28 specialized Color.Resolved.init(platformColor:) + 92 (CoreColor.swift:14) 502 SwiftUICore 0x0000000221faa5b0 Color.Resolved.init(platformColor:) + 16 (<compiler-generated>:0) 503 SwiftUI 0x00000001b53b1dc4 closure #1 in NSColor.resolve(in:) + 20 (AppKitColorConversions.swift:156) 504 SwiftUI 0x00000001b53b222c partial apply for closure #1 in static NSColor.withColorAppearance(in:_:) + 32 (<compiler-generated>:0) 505 SwiftUI 0x00000001b46b1e54 closure #1 in SubmitTriggerSource.dispatchUpdate(_:) + 28 (PlatformViewCoordinator.swift:12) 506 SwiftUI 0x00000001b5484488 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0) 507 AppKit 0x0000000189c174a4 +[NSAppearance _performWithCurrentAppearance:usingBlock:] + 72 (NSAppearance.m:2408) 508 SwiftUI 0x00000001b53b2088 specialized static NSColor.withColorAppearance(in:_:) + 324 (AppKitColorConversions.swift:142) 509 SwiftUI 0x00000001b53b1e7c protocol witness for ColorProvider.resolve(in:) in conformance NSColor + 68 (<compiler-generated>:151) 510 SwiftUICore 0x0000000222436e6c ColorBox.resolve(in:) + 124 (Color.swift:288) full-log.crash

So I am looking to use a custom NSWindow application (so I can implement some enhanced resizing/dragging behavior which is only possible overriding NSWindow). The problem is my whole application is currently SwiftUI-based (see the project here: https://github.com/msdrigg/Roam/blob/50a2a641aa5f2fccb4382e14dbb410c1679d8b0c/Roam/RoamApp.swift). I know there is a way to make this work by dropping my @main SwiftUI app and replacing it with a SwiftUI root view hosted in a standard AppKit root app, but that feels like I'm going backwards. Is there another way to get access (and override) the root NSWindow for a SwiftUI app?

I am trying to diagnose a very strange application crash that occurs intermittently under the following conditions App built in release and installed on iPhone App is in the background (e.g. close the app and open a different app without fully force quitting it) When these conditions are present, and I re-open the application by clicking on it's icon on the home screen, the app shows briefly on the screen and then immediately quits. This happens maybe 50% of the time when these conditions are present, but it does not create a crash report and there are no jetsam reports from the time of the crash either. I was able to capture a sysdiagnose immediately after the crash (within 3 seconds), and I have reviewed the logs to help me determine a possible cause, but none of the logs seem to be causing it. I am putting some potentially relevant log lines below, and I am attaching the logarchive. Additionally, the entire application is open source here on github, and the crashing :( version of the app is available here on the app store. Note this crash does not happen in the macOS version. Finally, I saw a previous thread that recommended adding atexit {abort()} to an app that doesn't produce a crash report, so I added that here before collecting these logs and I still don't get a crash report. Here are some log lines may be relevant, but none of them provide a reason for app termination. >>> MY APP IS OPENED default 2025-01-25 13:16:11.060118 -0500 runningboardd com.apple.runningboard monitor Calculated state for app<com.msdrigg.roam(95D1E2E9-9609-44D9-A30A-0C4AEA990A0D)>: running-active (role: UserInteractiveFocal) (endowments: <private>) default 2025-01-25 13:16:11.060132 -0500 runningboardd com.apple.runningboard process [app<com.msdrigg.roam(95D1E2E9-9609-44D9-A30A-0C4AEA990A0D)>:1758] Set jetsam priority to 100 [0] flag[1] default 2025-01-25 13:16:11.060132 -0500 runningboardd com.apple.runningboard ttl [app<com.msdrigg.roam(95D1E2E9-9609-44D9-A30A-0C4AEA990A0D)>:1758] Resuming task. default 2025-01-25 13:16:11.060185 -0500 runningboardd com.apple.runningboard ttl [app<com.msdrigg.roam(95D1E2E9-9609-44D9-A30A-0C4AEA990A0D)>:1758] Set darwin role to: UserInteractiveFocal info 2025-01-25 13:16:11.062002 -0500 CommCenter com.apple.CommCenter ul BundleID: com.msdrigg.roam is a foreground app >>> XPC says something about XPC_ERROR_CONNECTION_INTERRUPTED com.apple.mDNSResponder Default [R9386->Q40264] Question assigned DNS service 125 default 2025-01-25 13:16:11.067097 -0500 Roam com.apple.xpc connection [0x300b94900] Re-initialization successful; calling out to event handler with XPC_ERROR_CONNECTION_INTERRUPTED default 2025-01-25 13:16:11.067152 -0500 Roam com.apple.runningboard monitor Received state update for 1758 (app<com.msdrigg.roam(95D1E2E9-9609-44D9-A30A-0C4AEA990A0D)>, unknown-NotVisible info 2025-01-25 13:16:11.068357 -0500 Roam com.apple.coreaudio >>>MY APP RUNS AND STARTS LOGGING ON ITS OWN default 2025-01-25 13:16:11.109376 -0500 Roam com.msdrigg.roam ECPWebsocketClient Clearing handlers default 2025-01-25 13:16:11.109378 -0500 Roam com.msdrigg.roam ECPWebsocketClient No longer in error b/c restarting default 2025-01-25 13:16:11.109419 -0500 Roam com.msdrigg.roam ECPWebsocketClient Ignoring state change because it is the same connecting at 2025-01-25 18:16:11 +0000 >>> XPC Connection invalidated default 2025-01-25 13:16:11.146441 -0500 runningboardd com.apple.runningboard process XPC connection invalidated: [app<com.msdrigg.roam(95D1E2E9-9609-44D9-A30A-0C4AEA990A0D)>:1758] >>> Launchd reports app exit default 2025-01-25 13:16:11.150861 -0500 launchd user/501/UIKitApplication:com.msdrigg.roam[6159][rb-legacy] [1758] exited due to SIGPIPE | sent by Roam[1758], ran for 4930203ms default 2025-01-25 13:16:11.150876 -0500 launchd user/501/UIKitApplication:com.msdrigg.roam[6159][rb-legacy] [1758] service state: exited Logs split due to size being too big :( roam-crash.1.log roam-crash.2.log roam-crash.3.log roam-crash.4.log roam-crash.5.log roam-crash.6.log

Hi All, I am trying to write an NWProtocolFramerImplementation that will run after Websockets. I would like to achieve two goals with this Handle the application-layer authentication handshake in-protocol so my external application code can ignore it Automatically send pings periodically so my application can ignore keepalive I am running into trouble because the NWProtocolWebsocket protocol parses websocket metadata into NWMessage's and I don't see how to handle this at the NWProtocolFramerImplementation level Here's what I have (see comments for questions) class CoolProtocol: NWProtocolFramerImplementation { static let label = "Cool" private var tempStatusCode: Int? required init(framer: NWProtocolFramer.Instance) {} static let definition = NWProtocolFramer.Definition(implementation: CoolProtocol.self) func start(framer: NWProtocolFramer.Instance) -> NWProtocolFramer.StartResult { return .willMarkReady } func wakeup(framer: NWProtocolFramer.Instance) { } func stop(framer: NWProtocolFramer.Instance) -> Bool { return true } func cleanup(framer: NWProtocolFramer.Instance) { } func handleOutput(framer: NWProtocolFramer.Instance, message: NWProtocolFramer.Message, messageLength: Int, isComplete: Bool) { // How to write a "Message" onto the next protocol handler. I don't want to just write plain data. // How to tell the websocket protocol framer that it's a ping/pong/text/binary... } func handleInput(framer: NWProtocolFramer.Instance) -> Int { // How to handle getting the input from websockets in a message format? I don't want to just get "Data" I would like to know if that data is // a ping, pong, text, binary, ... } } If I implementing this protocol at the application layer, here's how I would send websocket messages class Client { ... func send(string: String) async throws { guard let data = string.data(using: .utf8) else { return } let metadata = NWProtocolWebSocket.Metadata(opcode: .text) let context = NWConnection.ContentContext( identifier: "textContext", metadata: [metadata] ) self.connection.send( content: data, contentContext: context, isComplete: true, completion: .contentProcessed({ [weak self] error in ... }) ) } } You see at the application layer I have access to this context object and can access NWProtocolMetadata on the input and output side, but in NWProtocolFramer.Instance I only see final func writeOutput(data: Data) which doesn't seem to include context anywhere. Is this possible? If not how would you recommend I handle this? I know I could re-write the entire Websocket protocol framer, but it feels like I shouldn't have to if framers are supposed to be able to stack.

I have a an application that incorporates a RTCP client to communicate with a local networked device. The device's RTCP implementation requires that the local RTCP port be 6970 even for the initial outbound connection. I have an implementation that is working just fine on macOS and iOS, but I when I port this to visionOS, I see that the local connection is ignoring my .requiredLocalEndpoint specification and choosing a random port (I can see this is happening in Wireshark via the VisionOS simulator.) let remoteRtcpEndpoint = NWEndpoint.hostPort(host: NWEndpoint.Host(remoteRTCPAddress), port: NWEndpoint.Port(rawValue: remoteRTCPPort)!) let rtcpParameters = NWParameters.udp let localEndpoint = NWEndpoint.hostPort(host: NWEndpoint.Host("0.0.0.0"), port: NWEndpoint.Port(rawValue: localRTPPort)!) Self.logger.info("Starting rtcp with local port \(localRTPPort), remote address \(remoteRTCPAddress), endpoint \(String(describing: localEndpoint))") rtcpParameters.requiredLocalEndpoint = localEndpoint rtcpParameters.allowLocalEndpointReuse = true remoteRtcpConnection = NWConnection(to: remoteRtcpEndpoint, using: rtcpParameters) remoteRtcpConnection.start(queue: .global()) And here's the code that sends the command. remoteRtcpConnection.send(content: RtcpPacket.vdly(delayMs: HUGE_FIXED_VDLY_MS).packet(), completion: .contentProcessed({ error in if let error = error { Self.logger.warning("Error sending VDLY packet \(error)") continuation.resume(throwing: error) } else { Self.logger.debug("VDLY Sent \(self.HUGE_FIXED_VDLY_MS)") continuation.resume(returning: ()) } })) If this is a known limitation of the Network framework, should I revert to BSD sockets or something? How can I work around this? Additionally, I don't have a VisionOS device, so I am using the simulator, could this be a problem with the simulator's network bridge?

I have a scroll view that scrolls horizontally and one of my users is asking that it respond to their scroll wheel without them having to use the shift key. Is there some way to do this natively? If not, how can I listen for the scroll wheel events in swiftUI and make my scroll wheel scroll to respond to them?

I am able to create a UIImage from webP data using UIImage(data: data) on iOS and iPadOS. When I try to do this same thing on watchOS 10, it fails. Is there a workaround to displaying webp images on watch os if this isn't expected to work?