dsym file

I'm developing a DriverKit USB driver for iPadOS. So, my first and strongest recommendation is that you shift your development environment from iPadOS to macOS, even if you never intend to ship on macOS. I have a more extended post on this here, but the basic summary is that, in my experience, the higher friction, lower visibility, and lack of critical investigator tools [1] on iPadOS mean that you'll end up wasting far more time trying to figure out “what’s happening on iPadOS than you saved by not getting a minimal macOS implementation working. [1] In particular, I consider IORegistryExplorer to be an absolutely critical tool for driver developers. See this forum post for download instructions and general guidance on using it. That leads to here: Does iPadOS allow third-party DriverKit extensions to access vendor-class (0xFF) USB devices? That is, in iPadOS, is there a way for a third-party DriverKit extension to access IOUSBHostInterface objects for vendor-class (0xFF) USB devices? Yes, that should also wo

Hi @keckausome, please file a feedback report for Xcode Cloud (including your team ID and logs for this failure) and then post the feedback number here. You can file Xcode Cloud specific feedback using these steps.

Sorry for the confusion, and you assumed correctly that copying in the Finder works, but I actually meant something else. What I meant was this: a user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error Result too large. When the app copies the same files from the Desktop folder, it works. Copying the files with the Finder, regardless their source location, works as well. From what the user told me, the issue only happens with some files. I actually asked them to narrow the issue down as much as possible and they found a folder with a single file, and copying that folder always causes that error. Interestingly, the destination file is actually created but has a much smaller size than the source: 250 KB instead of 34 MB. The user also shared that file as a zip archive on Dropbox with me. I ran the ls -l@ command on it to see its extended attributes and their size, the output was: com.apple.

Hi @milesg000, You wrote: This doesn't answer the question unfortunately. The docs still say the merchant needs to host an apple-developer-merchantid-domain-association. For merchants, the merchant ID domain verification file is a 1:1 association with your merchant ID and merchant certificate used to secure your Apple Pay requests. See the following documentation for more details: Configuring Your Environment https://developer.apple.com/documentation/ApplePayontheWeb/configuring-your-environment For payment platform integrators using the Apple Pay Web Merchant Registration API, the payment platform domain verification file is a 1:1 association with your payment platform integrator ID and payment platform ID certificate used to secure your Apple Pay requests. Platform integrators also can download and distribute merchant domain verification files to each merchant they've registered. For more information, please see below: Preparing merchant domains for verification https://developer.

A user of my app reported that when my app copies files from a QNAP NAS to a folder on their Mac, they get the error Result too large. When copying the same files from the Desktop, it works. Clarifying what you mean here, are you saying that the Finder can handle the copy and while your app cannot? Or that your app is doing both copies it works to one destination (the Finder) and fails to another? Or something else? I'm going to assume the Finder works and your app fails (that's what typically happens) but please correct that if I'm wrong. I asked them to reproduce the issue with the sample code below and they confirmed that it reproduces. They contacted QNAP for support who in turn contacted me saying that they are not sure they can do anything about it, and asking if Apple can help. Can someone at Apple say anything about this? I spent some time looking into this and there does appear to be a newly reported issue (r.165759954) that sounds similar to this. In terms of next steps, I have a f

Using the simulator so screenshots are weird where I see the height of the table restricted at this time. But you running into a physical device. I wonder if there is anything weird in that project, can you submit the project with the sysdiagnose of that device? Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Thanks Albert Pascual
  Worldwide Developer Relations.

Hello @albertOrtegas. I cannot make any comments about future Apple business plans. However, if you file a feedback report and post the feedback number here I will be able to talk to engineering about your bug report and post any comments they are able to share to this thread. So, please consider filing a feedback report and posting the feedback number to this thread.

Thank you for the detailed description and the technical context. Based on what you’ve shared, this should be considered as an improvement instead of a regression or in this case a limitation on redirects based on the documentation on the tech note. TN3155: Debugging universal links | Apple Developer Documentation The HTTP 301 and 302 is not supported for requests to AASA files, I don’t know how was working previously. TN3155: Debugging universal links | Apple Developer Documentation#Host-and-verify-your-AASA Can you provide me a link to your AASA file? The AASA for the IDN domain should be served at https://xn--[punycode].com/apple-app-site-association (no .json extension, correct mime type, no redirects). The AASA JSON must be valid and contain the corresponding paths (e.g., paths: [*] or whatever you’re using) for applinks, and the webcredentials section must mirror your domain. There must be no HTTP->HTTPS redirects or unusual chain that would cause the OS to fetch a different domain

Yes, confirmed. My device was set to Dark Mode. Light Mode: Glass renders correctly (light/frosted) Dark Mode: Glass renders dark/muddy gray Is this a known bug with .glassEffect() in Dark Mode? Is there a workaround, or should I file a Feedback Assistant report? Thanks for identifying this. I've been stuck with this for quite a while.

It sounds like you're aware of what a routing app is, but just to confirm details: A routing app provides navigational directions between two locations. It is enabled inside of an Xcode project by going to the Capabilities tab, and adding the Maps capability, which will then show you a list of checkboxes for the transportation modes by which you're able to provide navigational directions between points. Those checkboxes correspond to values added to your Info.plist file under a key named MKDirectionsApplicationSupportedModes. It sounds like you're not providing directions, but you should check to make sure the above capability isn't enabled accidentally. And if you're not providing directions, also don't enable this capability just to try and solve this error, as I've seen people get tangled up further by trying that. If all of that looks good and that capability wasn't accidentally enabled, then the next thing you should do is to open a bug report with the details of your App ID and the build number

Well, that was fun. Lemme start with some disclaimers. It’s impossible to talk about logging at this level without discussing implementation details, that is, information about how the system works today but which isn’t considered API. This stuff has changed in the past and could easily change again in the future. Don’t build knowledge of this into a product that you ship to a wide range of users. Also, the limits imposed by the system log are not arbitrary. They represent a trade-off between convenience — when debugging problems that come in from the field, more logging is always better — and cost. There are three specific costs of concern: Logging consumes CPU cycles, which leaves less available for real computation and also takes energy. Persistent logging consumes I/O bandwidth and even more energy. Persistent logging can contribute to SSD wear. The system log is a shared resource and it’s important to Apple that it remain useful for debugging a wide range of problems. I touch on this in Your Friend the S