“file uri scheme”

@azdzadazsqsx Thank you for providing me with the FB, looks like it was filed today. Let's give the team sometime and I can check on the status of the issue. Albert Pascual
  Worldwide Developer Relations.

I briefly thought about this though I wasn't sure how path control grabs the icons (through the URL or something else like NSWorkspace) and I wanted to have that in the bg too. Strictly speaking, it uses NSWorkspace.icon(forFile:) but that doesn't really matter at least as far as display works. The rules for EXACTLY which icon will be shown for every possible edge case are sufficiently complex that the only way to ensure consistent behavior is to have a bottleneck through a single API. So NSWorkspace.icon(forFile:) and NSURLEffectiveIconKey are both calling into the same place (currently a private SPI in LaunchServices). I hadn't actually noticed that we'd deprecated kCFURLEffectiveIconKey; however, that doesn't actually change anything about using CFURL. The point of toll-free bridged objects is that the two types should act as full replacements for each other, so you can pass NSURLEffectiveIconKey[1] directly into CFURL. Under normal conditions this isn't a big deal but dealing with a URL on a slow network

Hi, I am developing an instant snapshot backup solution for macOS using Endpoint Security. We have stumbled upon a Kernel Panic when using the fclonefileat API. Yes, this is a known bug (r.161340058). More specifically, the ..namedfork/rsrc construct is a longstanding part of the system, but it's not widely used and it allows the expression of operations that aren't entirely coherent (like cloning an object that isn't a file). Have you tested this on macOS 26.4? I believe the issue should now be fixed. Having said that: I expect that no userspace syscall should be able to cause a kernel panic. It looks like a bug in the APFS implementation and requires a fix on the XNU/kext side. ...this is a good example of one of my long-standing warnings, namely that us fixing kernel bugs doesn't mean your code will work. The panic above is actually fixed in the VFS layer by having fclonefileat fail, just like clonefile does when presented with the same scenario. As a more general comment, I'd suggest adding a che

Same issue. We haven’t been able to submit an app update for almost a week. We’ve filed a bug ticket and reached out to support—no response so far.

I do hope someone at Apple is still paying attention to this. I haven't seen any updates on the bug reports I filed, and no one has reached out to me directly. I will just add that none of the issues I've reported have been fixed in the build of 26.4 (25E246) that released to the public this week.

Well I figured it out - for anyone still encountering this issue: My company has one domain to service multiple locations/storefronts. Each location has it's own separate Payment Processing account, requiring a unique Apple Pay Payment Processing Certificate/MerchantID. The docs and responses here made me think subdomains would be required, which is a headache in itself - especially since the Apple Pay Session must be started from that subdomain (not the parent domain). SOLUTION: If you register multiple MerchantIds within a single Apple Developer Identifier - all Domain Association Files tied to a certain domain are the same. So if you verify for one MerchantID, then add that same domain to another - it will count it as already verified. No need for subdomains. No need for swapping out Domain Association files. Really wish that Apple had made that clear.

@eddyvinck Yes definitely a horrible experience working with simulators. Lets get the ball rolling fast and file a bug so that issue can be resolved quickly. Thanks Albert Pascual
  Worldwide Developer Relations.

[quote='875340022, DTS Engineer, /thread/814559?answerId=875340022#875340022'] I encourage you to file a Feedback report of your own using Feedback Assistant, then post the Feedback ID here. [/quote] Here is my feedback report: FB18061981

Thank you for your posts. While the script was definitely a long shot, considering that I have not used that script for some time, I believe this thread warrants a bug filing as looks like is happening to all of you. I would appreciate it if one of you could file a bug report and provide the FB number here. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Lets get it resolved as fast as possible. Albert Pascual
  Worldwide Developer Relations.

During the beta cycle, developers can get the required MobileDevice by installing the latest Xcode seed. That's problematic on macOS 15.x because Xcode 26.4 now requires macOS 26.2. However, would it be possible to open the Xcode.app/Contents/Resources/Packages/MobileDevice.pkg manually on a macOS 15.x machine to get the required mobile device files? Once the OS is released, either: That doesn't seem to match my experience. macOS 26.4 is now out, and I've updated to macOS 15.7.5 (24G624), but when I try using the restore image of the release version of macOS 26.4 to make a VM, I'm still prompted to install the mobile device files and it still says that they aren't available from the software update server.

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. We implemented your own HTTP protocol on top of NetworkConnection. OK, cool, that’s kinda what I expected but I’m glad you confirmed it. We are very eager to send HTTP requests over Wi‑Fi Aware using URLSession — is this achievable? No. I recommend that you file an enhancement request for that. Please post your bug number, just for the record. Coming back to your throughput issue, I don’t have an immediate answer to that. I’m gonna do some digging and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com