“file uri scheme”

Have you filed a bug on this and, if so, what is the bug number? Not yet, but I do have another thread where I describe the same problem in regards to .DS_Store: https://developer.apple.com/forums/thread/819041 I will post the bug number (most likely there) when I carve out a little time for it. Currently if copyfile fails and errno is not set my code falls back to a kind of 'Unknown Error' which I hate but if the user is counting on my app to perform the copy it's kind of a gamble if the operation doesn't succeed to just hope not critical data was lost. A big part of this is that xattrs aren't actually safe“— the system doesn't have a documented system for defining how they should be handled, and app/copy engine/file format support for them is inconsistent, so storing critical data in them can end up being a good way to lose critical data. Importantly, that kind of data loss isn't really a bug in the same way other kinds of data loss would be. The general point of xattrs is to allow the att

I'm experiencing this issue. Copy file works locally for these files but fails when coming from a NAS. So, the first question here is what these files are and how they got onto that NAS. More specifically, there are basically only three reasons a file would have a resource fork today: It's really, really old. Apps were discouraged from using the resource fork from the very first release of macOS X and the Resource Manager (the only API that allowed access to it) was deprecated in macOS 10.8. Files that are intentionally using it should not be common. It's actually a compressed file. I described that case above, but the key point is that compressed files should never be leaking off of our volumes. Something else (weird) is going on which I'd love to understand. The most likely explanation here is #2, however, making that happen means something didn't work properly, which is what you should identify and correct. Works from Finder in both cases, as p

Since you're seeing this often, please open a bug report with some URLs to example builds so we can investigate. Make sure to include the details about the URL and the DNS errors. once you have that FB number on file, please post it here for the record. — Ed Ford,  DTS Engineer

Please file a Feedback report using Feedback Assistant, then post the ID here.

I have multiple Apple Pay Merchant IDs for different locations, each requiring its own domain association file. This forces me to verify each Merchant ID on a separate subdomain. The problem: the Apple Pay session must be initiated from the verified subdomain. It works on 10171.example.com but fails on www.example.com. I want to keep a single top-level checkout domain without redirecting users to subdomains. Is there any supported way to do this, or is top-level navigation to the verified domain always required for multi-Merchant ID setups?

I would like to note that both the documentation you have linked and our developer portal for enabling this entitlement both mention this API is macOS only. The documentation and portal are both wrong. I'm working on getting the portal fixed (r.162380702) and I'll try and let you know once that's done. On the documentation side, I'd appreciate you filing your own bug on that issue and then posting the bug number back here once it's filed. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I filed FB22260532 Perfect, thank you! __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I’m going to consult with a colleague about this, but I suspect that this is ultimately going to end up being a bug report. Yes. If you haven't already, please file a bug on this and the post the number back here. Once I've got the bug number, I'll follow up with the engineering team to see if there are any other options here. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Please file a feedback report via Feedback Assistant and share the feedback number here once submitted. Include the OS, Xcode versions and sample code you're able to reproduce the issue on.

Thank you for providing the code. I modify a bit to be able to build in our DUT FYI, my original code has some logic flaws that I eventually sorted out with a bit more testing and experimentation. The underlying math here is that the BCT binning test is equivalent to the combined probability of rolling 10 3-sided dice and having either or both of these occur: The same number appear on 4 or more dice -> ~31% At least one number not appearing at all ->21% ...and the combined probability of those two events works out to about ~40%. I suspect/assume that you're having test runs that OCCASIONALLY succeed, but the inherent failure rate might also be being skewed by other details of your implementation. I've filed a bug on this already (r.172771068), but I'd appreciate your filing your own bug and posting the bug number back here. I would like to confirm if the result of SHARED REPLY TIMING with Warning is not an issue and can still result to BCT certification to Pass. This warning is not an

Hello @iiil8 I would like to take a look at this. Can you file a report with Feedback Assistant https://developer.apple.com/feedback-assistant/ and attach a minimal sample project that reproduces this issue? Please reply with the FB number once complete.

Could you please file a feedback report and include the sample code that reproduces the issue. Once you do please share the Feedback ID number here for the record. Thanks

Thank you for filing FB22254960 . When your app declares support for public.text in CFBundleDocumentTypes, you're telling the system that your app can open text documents. The document picker respects your declaration and shows both the content types you explicitly request folder and the types your app supports.

Thanks for this interesting post! I'm not an expert on that field nor that API. Hope one of the engineers on that team can jump into this thread for better info. These specific FigXPCUtilities and FigCaptureSourceRemote logs are almost certainly benign internal framework noise rather than a regression or a flaw in your capture pipeline. Looking up the err=-17281 is a CoreMedia error code that, without knowing here, typically points to a minor XPC synchronization hiccup, a port invalidation, or an asynchronous state mismatch during the setup or teardown of the capture session? I believe this logs are for information only and should be removed. Code paths that silently recovered in older iOS versions often have their log levels elevated in newer releases (or beta releases), resulting in console spam. If your AVCaptureVideoDataOutputSampleBufferDelegate is successfully receiving CMSampleBuffer frames and your preview layer is rendering smoothly. You can safely ignore these logs. If you want to temporarily hide t