“A Summary of the WWDC25 Group Lab”

The hover effects feature introduced in visionOS 26 represents a significant enhancement for creating immersive experiences, allowing users to interact with virtual objects using spatial gestures. However, the behavior of these gestures, particularly with the PSVR 2 controllers, can indeed vary based on how they are integrated into different types of views and applications. Clarification on Hover Effects and PSVR 2 Controllers Hover Effects in VisionOS: Hover effects are designed to provide feedback when a user's gaze is directed towards a virtual object. This is akin to a mouse hover on a desktop and can trigger spatial events or visual highlights. Controller Gestures: On the PSVR 2, traditional button presses (like pulling the trigger) are well-supported across various interfaces, including SwiftUI. However, gaze-based interactions like hover effects require additional handling to map spatial gestures to these events. Discrepancies in Behavior Sample Application Behavior: The sample you referenced likely re

The error you're encountering is due to Swift's concurrency model introduced in Swift 5.5, which aims to prevent data races by enforcing actor isolation. In Swift 6, these checks have become more stringent, especially when dealing with concurrent and actor-isolated contexts. The Translation framework's methods, like translate, are likely designed to work concurrently, which means they expect to be called from an actor context. When you pass the session object, which is likely actor-isolated to the main actor (due to how URLSession typically works), to a concurrent method, Swift flags this as a potential data race. How to Fix the Issue Make the Session Actor If possible, wrap the URLSession instance in an actor. This way, all interactions with it are serialized and safe from data races. actor TranslationSession { private let session: URLSession init() { self.session = URLSession(configuration: .default) } func translate(_ text: String) async throws -> TranslatedText { let configuration = TranslationConfigur

Kevin, First, I wanted to apologize for not replying for a full month, as well as thank you very much for your reply. I was pulled away from this project for a couple weeks, and when I got back I was still spinning my wheels getting the driver installed. I only today found my issue, which wasn't something you could have helped with since I hadn't thought to include the correct context in my original comment. I only found the issue after careful log monitoring in the Console app during the install process as my main installer app was running. It turns out that my bundle ID was too long. It was 67 characters and, apparently the maximum is 63. Seems like an arbitrarily short max in this day and age, and you'd think both XCode and the Developer Portal would catch that, but that's what it was. When I redid my bundle IDs more succinctly (and all my permissions on the Apple Developer Portal), I was able to successfully install/register/enable the driver. I have granted it permission in System Settings, it shows up u

Thanks for responding, Quinn! Further analysis by Claude based on your inputs. I ran sudo sysdiagnose immediately after the failure and analyzed the system_logs.logarchive. The findings suggest our situation may be different from the threads you linked. No crash reports and no nesessionmanager involvement: Zero crash reports for sysextd, nesessionmanager, or CodeSigningHelper (checked both /Library/Logs/DiagnosticReports/ and the sysdiagnose archive) Zero connection to com.apple.nesessionmanager.system-extensions interrupted messages nesessionmanager has zero log entries during the activation attempt window (12:49:14–12:49:15) The activation never reaches staging or validating by category: In thread 776759, the successful flow progresses: activation request → realize extension → advancing state from realizing to staging → import to staging → category validation by nesessionmanager Our flow stops before staging: 12:49:14.598 client activation request for dev.indrasvat.chakshu.filter 12:49:14.598 attempting to

Thanks again for your guidance. I’m following up with concrete implementation details and current repro logs because we still cannot read SSID via CoreWLAN from our agent process. Environment: macOS 26.3 (build 25D125) Xcode 26.2 (17C52) Wi-Fi interface: en0 Agent bundle ID: com.acme.SSIDInspector.Agent App bundle ID: com.acme.SSIDInspector How we launch the agent: We use SMAppService.agent(plistName:) from the main app. Embedded LaunchAgent plist path in app bundle: com.acme.SSIDInspector.Agent.plist Plist details: Label = com.acme.SSIDInspector.Agent BundleProgram = Contents/Resources/SSIDInspectorAgent.app/Contents/MacOS/SSIDInspectorAgent MachServices includes com.acme.SSIDInspector.Agent RunAtLoad = true, KeepAlive = true We call register()/unregister() on SMAppService, and use XPC (NSXPCConnection to mach service) to verify the agent is running/reachable. Privacy/authorization setup: Agent Info.plist usage strings are present: NSLocationAlwaysUsageDescription NSLocationUsageDescription NSLocationWhenInU