“A Summary of the WWDC25 Group Lab”

Thank you for the explanation! Xcode did add the localized string key %@ timer started. to my string catalog as you correctly assumed, and I have provided a proper translation: %@ Timer gestartet. However, I still don't understand why Siri does not translate the %@ part properly. When it's 10 seconds in English, it also reads 10 seconds when Siri is set to German with the number 10 being correctly translated (zehn instead of ten) but not the unit (seconds where it should read Sekunden). Summary & Overview: Localized String Key: %@ timer started. English output: Displayed text: 10 seconds timer started. Spoken by Siri: Ten seconds timer started. 🇺🇸🇺🇸🇺🇸🇺🇸 German output: Displayed text: 10 seconds Timer gestartet. Spoken by Siri: Zehn seconds Timer gestartet. 🇩🇪🇺🇸🇩🇪🇩🇪 where zehn is German, but seconds is English. This seems to be a bug? I will wrap this as a minimal example in an Xcode project to file a Feedback report and share the ID here once I've done that, as you suggested. Than

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 of their source location, works as well. Yes, that all makes sense. There are basically two different issues that work here: There appears to be a bug in SMB involving the handling of larger xattr. The issue is specific to smb, which is why this doesn't affect local file copies. The Finder uses its own copy engine, which bypasses the problem. More specifically, the Finder is almost certainly using the ..namedfork/rsrc accessor that StackOverflow post mentions. Covering a few details: Interestingly, the destination file is actually created but has a much smaller size than the source: 250 KB instead of 34 MB. The initial f

Our engineers have thoroughly followed the practices outlined in TN3179. The apps have been tested on a variety of test systems (including clean installs) in our test lab. As the issue has also been reported by many end-user customers, we are confident that the behaviour is reproducible across all systems and test environments/setups. We can affirm that it is not specific to one system and its corrupted local network privacy state.

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 shoul

hello @DTS Engineer I am bumping this thread to not lose visibility. If anyone in the DTS Engineering group can help me understand my issue it would be greatly appreciated. Regards, Captadoh

I was discussing this thread with a colleague and they pointed out an issue with your OSLogPreferences setup. While it’s not a bug per se, it is something you should know about so you can make a conscious decision about whether you want to change your setup or not. Right now your setup changes the TTL for all categories in your subsystem (com.example.MyApp). That’s not something we’d recommend, because it unnecessarily increases pressure on the logging system. By doing that you cause the logging system to hit its limits earlier, which makes it less likely that the really interesting log entries will survive. A better option is to: Classify your log points into those that need to persist for longer and those that don’t. Put them in separate categories. Adjust the TTL only on the categories for the priority group. The TTL is a type of priority and, as an old friend of mine once said, the nature of priority is that for you to ‘win’ someone else has to ‘lose’. If you give all your log entries high priori