file uri scheme

This works. There is a question at the end. I added a Utilities.hpp file in my XCTest folder, TestsOrangeSpider (separate from my project code.) #ifndef Utilities_hpp #define Utilities_hpp #import void testGLMVEC3(const glm::vec3& actual, const glm::vec3& expected); #endif In the same folder I have a Utilities.cpp file. #include Utilities.cpp void testGLMVEC3(const glm::vec3& actual, const glm::vec3& expected) { XCTAssertEqualWithAccuracy(actual.x, expected.x, 0.00001f);... } In one of my test files I import the .cpp file. In all other test files I import the .hpp file. Importing the .cpp file in all test files doesn't work. Importing the .hpp file in all test files doesn't work. It has to be one file imports the .cpp and all other files import the .hpp. Why is there this odd combination requirement? Thanks : )

I did not recieve a bug number. Could you please assist and share the correct page I should access to fill in the bug ? Sorry, I should have included my usual link to Quinn's post on bug filing. That points you to the right page but also includes a good overview of the bug process. But, yes: Hi David you can use the Feedback Assistant app on macOS, or https://feedbackassistant.apple.com ...either of those work. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I'm self-hosting a web project called mempool (https://github.com/Retropex/mempool). This project is entirely self-hosted on my own infrastructure, so I have advanced control to be sure it's just not an anti-DDoS feature that makes the bug happen. If you haven't already, please do the following: You can do the testing below on any machine you can reproduce the issue on. I'd probably use a Mac, but you can use iOS if that's simpler. However, with whatever machine you’re testing with, try and use the most minimal system possible. Ideally, that's a device that's just been reset, but using a newly created account works reasonably well on macOS as long as there isn't too much 3rd party software running system-wide. The key here is that having less on the machine minimizes the risk of private data leaking and extraneous log noise. I'd recommend installing the mDNSResponder and Network Diagnostics on the device. Those might not be necessary, but both of those increase the level of network diagnostic data, and instal

are you developing for macOS or iPadOS, or both? com.apple.developer.driverkit.communicates-with-drivers is for iPadOS. It won't do any harm to set this to true in a macOS app, but you don't need it. When you say your driver fails at runtime, there are various ways this can occur: it fails to load (perhaps due to an entitlement issue), your code fails to find the driver your code finds the driver, but fails to open a user client for it It sounds like you're failing at stage 2. Look in the system log for messages related to your driver's bundle ID. I like to plug in the device, then run log collect --last 1m and peruse the resulting log file in the Console app. Use IORegistryExplorer (part of the additional tools for Xcode) to look for your driver in the IORegistry. If it isn't there, IOServiceGetMatchingService won't find it. IOServiceGetMatchingService takes a matching dictionary as a parameter, but you said you are calling IOServiceGetMatchingService(DriverKitAcxxx) Did you mean IOServiceNameMatchi

hi @matthewyang , This sounds like a bug report to me, if you wouldn't mind filing that at https://feedbackassistant.apple.com and pasting the FB number here so I can follow up with the right folks, that'd be great! In the meantime, this does work for me, what it will do is allow you to drag both the child and the parent (together) if you drag the parent. If you drag the child, only the child will move. Where child is green box and parent is red box. RealityView { content in var manipulationComponent = ManipulationComponent() manipulationComponent.releaseBehavior = .stay manipulationComponent.dynamics.inertia = .low let cube = Entity(components: ModelComponent(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .red, isMetallic: true)])) cube.generateCollisionShapes(recursive: true) cube.components.set([HoverEffectComponent(), InputTargetComponent(), manipulationComponent ]) let cube2 = Entity(components: ModelComponent(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .gr

While updating our test devices to iOS 26, we noticed that the connection between devices is flaky. Often when connecting to a peer from a device running iOS 26, we can observe the invite coming through and when accepting said invite, both ends go to .connecting state and a while later go back to .notConnected within the peer(_ peerID: MCPeerID, didChange state: MCSessionState) function. This happens regularly, and retrying the invitation process several times usually resolves it. Have you filed a bug on this, and if so, what is the bug number? Does anyone have any information or guidance on how to resolve this issue? Well, unfortunately, my (and Quinn's) longstanding advice has been to move to a new API and stop using MultipeerConnectivity. Quinn actually has an extended forum post describing how to move to the Network framework. I'd also suggest taking a look at the Building a custom peer-to-peer protocol sample, which uses the Network framework to implement something very similar to what Multipeer

If you run codesign on your executable, it tells you exactly what the problem is: /tmp $ codesign -vv -R=anchor apple generic renderrob.app renderrob.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /private/tmp/renderrob.app/Contents/Frameworks/Python.framework If you explore that framework using Terminal, you'll see what it's complaining about: /tmp $ find /private/tmp/renderrob.app/Contents/Frameworks/Python.framework ... /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python Remove those files and try again: /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python /tmp $ codes

Hi @RickMaddy, just tried the update method yesterday and now I can confirm it works as described. Installed macOS 14.6.1 to a fresh VM, then upgraded to Tahoe via System Settings. As one would expect, the UDID remained unchanged after the upgrade, which seems essential for the developer signature to work correctly. My developer-signed app built on the host machine starts without issues in the guest running macOS 16 (after adding the UDID in the Developer portal). Please see if it works for you—still a bit cumbersome, but looks much more convenient compared to the dual-boot scheme.

Thank you for your answer. I tried signing the files in ascending order, meaning so sign all files first, and the directory above it. Unfortunately no change in the result though. Is there a way to get more information about why the Developer ID Certificate is invalid?

Hi Kevin, Yes, I’ve already filed a bug report for this issue. The Feedback ID is FB20572131. Thank you for following up.