“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

[quote='814148021, mmeera, /thread/814148, /profile/mmeera'] Is there any way to enable these key exchange groups on iOS 26? [/quote] For you to enable them? No. If you’d like to see Apple support these cyphersuites, I encourage you to file an enhancement request for that, making sure to explain why these specific ones are important to your setup. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m trying to notarize an Electron app for distribution outside the Mac App Store, but every submission is rejected with error 7000. Team Details: Team ID: P3HATASMP9 Organization: Rose Ai Labs, Inc. Role: Account Holder Apple Developer Program: Active membership Certificate: Type: Developer ID Application Identity: “Developer ID Application: Rose Ai Labs, Inc. (P3HATASMP9)” Status: Valid in Keychain Access with full certificate chain App Details: Platform: macOS (Electron) Hardened runtime: Enabled Code signing: Successful (codesign -v passes) Submission History (all rejected with same error): Date Submission ID Status Jan 20, 2026 d2f5e812-d443-4858-895e-ca9828f65d6b Rejected Jan 20, 2026 4864e851-99d4-49df-87b8-22a6b280f4fc Rejected Jan 21, 2026 69b177bd-5f08-4363-a2bb-1d286dd9f047 Rejected Jan 21, 2026 a181071b-e874-4794-90f3-c172b112900e Rejected Jan 21, 2026 ae3ec87f-60da-4826-91df-a247cd4fd46f Rejected Jan 21, 2026 b7165e2f-19a8-4d4a-9e00-21e85550ec8b Rejected Jan 24, 2026 2b83d46d-66