I’m prototyping a personal-use system that lets an iPhone with a physically attached controller act as an input device for a Mac. End goal: Use the iPhone as the transport and sensor host Use the attached physical controller for buttons/sticks Map the iPhone gyroscope to the controller’s right stick to get gyro aim in Mac games / cloud-streamed games such as GeForce NOW that don't support the gyro. What I’m trying to understand is whether Apple supports any path for this on macOS that does NOT require restricted entitlements or paid-program-only capabilities. What I’ve already found: CoreHID virtual HID device creation appears to require com.apple.developer.hid.virtual.device HIDDriverKit / system extensions appear to require Apple-granted entitlements as well GCVirtualController does not seem to solve the problem because I need a controller-visible device that other apps can see, not just controls inside my own app So my concrete question is: Is there any supported, entitlement-free way for a personal macOS app to expose a game-controller-like input device that other apps can consume system-wide? If not, is the official answer that this class of solution necessarily requires one of: CoreHID with restricted entitlement HIDDriverKit/system extension entitlement some other Apple-approved framework or program I’m missing I’m not asking about App Store distribution. This is primarily for local/personal use during development. I’m trying to understand the supported platform boundary before investing further. Any guidance on the recommended architecture for this use case would be appreciated.

I have two Macbook Pros: 14" M4 Pro (company) 16" M4 Max (personal) I work remote full-time and recently purchased 2 of the new Studio Display XDRs. Everything works perfectly however I chose to connect them to the M4 Max. I have a caldigit Element TB5 hub and can daisy chain both monitors through that perfectly. With that said, no matter how I plug them into the M4 Pro I can only ever get one to light up at a time. What I have tried to resolve it: Plug them in individually to the m4 pro Plug them in one at a time, force them to 60hz and then plug them both in. Daisy Chaining the displays Daisy Chaining the displays through the TB5 Hub Nothing works. Only one display comes on and its whichever is plugged in first. I have even tried lowering the refresh to as low as it goes on both manually then plugging them back in. Still nothing. From what I am reading it appears to be that the M4 Pro has 3 display lanes and when I plug the first studio display XDR it is using 2 lanes. If I go down to 60hz which is what the original studio display was, then it should theoretically go down to 1 display lane allowing a second to be plugged in. A bunch of people had the older studio display running 2x 5k ASD monitors on the M4 Pro. Now with the latest Studio Display XDR I am stuck. I was researching possibly editing the EDID of each to mimic the older studio display, but I don't know how to do that easily without BetterDisplay and right now I have no ability to install that. There is a chance I can get approval to run commands / BetterDisplay to get this working if a solution can be found. What I think the ultimate fix is for the firmware / macOS to realize the limitation, force the studio display XDR to 60hz when a second monitor is plugged in and they both would work. A single Studio Display XDR could run 120hz, but immediately upon plugging a second one it swaps to 60hz. I am completely fine with that scenario. I have found a few discussions about this topic with the main one being on apple discussions: https://discussions.apple.com/thread/256262701?sortBy=rank&answerId=261888577022 Someone sort of gave me this idea on Mac because they were trying to use the studio display XDR on windows and it appears to have worked with cloning an older ASD EDID on the new model: https://www.reddit.com/r/mac/comments/1s3ani5/got_studio_display_xdr_working_on_windows_pc_5k/ I don't really know what else to do. I opened a ticket with support. Case # 102853480566, but it went no where. I got disconnected during the first call after describing everything and when they reached back out they didn't even give me 2 seconds to pick up and they hung up and closed the ticket. I really don't want to return the displays because they are beautiful and work beautifully on the m4 max. They should work with 60hz on the m4 pro. Who / How / When can we get this resolved? I would be happy to work with an Apple dev / engineer to help resolve this.

iPhone16PM Clean DFU, no restore, no tweaks. Started on iOS 26.4.3 and still happening on iOS 26.4. Triggers: ∙ Editing Home Screen widgets ∙ Heavy media in Safari ∙ ProMotion UI transitions Panic log — 0x8badf00d watchdog timeout: userspace watchdog timeout: no successful checkins from SpringBoard in 180 seconds. service: backboardd Drivers: com.apple.driver.AppleAVD + com.apple.iokit.IOSurface Is there a solution for this? Thank you.

Hi, I’m looking for clarification from folks familiar with CoreHID rather than App Review, as the guys there have not responded to my post (https://developer.apple.com/forums/thread/820676) We have a sandboxed macOS app that creates a virtual HID device (HIDVirtualDevice) as described in Creating virtual devices https://developer.apple.com/documentation/corehid/creatingvirtualdevices To work at all, the app requires the entitlement: com.apple.developer.hid.virtual.device With this entitlement present, macOS shows the system prompt requesting Accessibility permission App would like to control this computer using accessibility features. Grant access to this application in Security and Privacy preferences located in System Preferences. when HIDVirtualDevice(properties:) is called. There is no mention of Accessibility in the HIDVirtualDevice documentation, but the behavior is reproducible and seems unavoidable. My question is therefore: Is creating a virtual HID device from userspace via HIDVirtualDevice considered inherently incompatible with Mac App Store distribution? In other words: Is the Accessibility prompt an expected side‑effect of this API? And if so, does that mean using HIDVirtualDevice is only practical for direct (non–App Store) distribution unless the app is explicitly an accessibility tool? I’m not asking about review policy details—just whether, from a technical/system point of view, HIDVirtualDevice is actually intended to be usable by App Store apps. For context, there seem to be public, non‑accessibility uses of Apple’s virtual HID infrastructure, like this recent post: https://developer.apple.com/forums/thread/820708 and corresponding Github repo this project. I don't know if these intend to use the App Store, but they might end up in the same situation. Any insights from people who’ve worked with CoreHID would be greatly appreciated. Thanks, Magnus