“file uri scheme”

[quote='820860021, pabugeater2, /thread/820860, /profile/pabugeater2'] I've filed FB FB22353950 [/quote] Thanks. That’s the best path forward here. Oh, except that you should file an ER for a better screen saver API, one based on app extension technology. Normally I’d include my standard spiel on that topic, but I believe that you’ve seen already. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

These two statements are at odds: [quote='882101022, Arebus, /thread/820871?answerId=882101022#882101022, /profile/Arebus'] there is nothing special here [/quote] [quote='882101022, Arebus, /thread/820871?answerId=882101022#882101022, /profile/Arebus'] just a command line tool with a Localization.xcstrings file [/quote] Doing this is special because, in general, we don’t localise command-line tools on the Mac. Specifically, the traditional Unix-y way of localising command-line tools [1] is not standard practice on Apple platforms. Rather, Apple platforms use their own mechanism, based on the bundle structure. This mechanism is intended for GUI apps, and you have to jump through hoops to get it to work from the command line [2]. If you’re doing this just for testing, I recommend that you use Xcode’s testing infrastructure. It has options for overriding the language and region. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Roote

Is any of your code involved here? Reading your description it doesn’t look like that’s the case, in which case the best place for this report is Feedback Assistant. See Bug Reporting: How and Why? for lots of hints and tips on how to file a bug. 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

[quote='820864021, matthewruzzi, /thread/820864, /profile/matthewruzzi'] FB22353186 [/quote] Thanks! I filed my own bug about this a while back (r. 92946014), but it’s always good to get external reports of issues like this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

-URLByAppendingPathComponent: is, as the name makes clear, intended to add a single path component. However, it doesn’t do anything to block you from adding a string with a path component separator, which effectively adds multiple path components. This is something I try to avoid relying because it assumes that the path component separator is always /. Way back in the day Foundation used to run on non-Unix-y platforms, where that wasn’t the case. And the Swift equivalent of this method runs on non-Unix-y platforms today. Notably, the modern Swift equivalent of this method, namely appending(component:directoryHint:), will percent encode path separators. ps File system paths are a source on ongoing grief. For a clear example of that, read this Swift Forums thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So, DevForums is primarily focused on APIs, and thus we’re not really set up to help folks with Wi-Fi debugging issues. You might have more luck over in the Apple Support Community, run by Apple Support, and specifically in the Business and Education topic area. However, I have a couple of tips to share: Filing a Wi-Fi Bug Report is my advice on how to file an actionable Wi-Fi bug. Specifically, it talks about how to enable additional Wi-Fi logging. Your Friend the System Log offer general advice on how to use the system log effectively. [quote='820970021, Whitebengal, /thread/820970, /profile/Whitebengal'] I've submitted a couple of pieces of feedback [/quote] What were those bug numbers? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I recommend that you file a bug about this. Once you’re done, please post your bug number, just for the record. In general, frameworks that use XPC to talk to a daemon should recover if the daemon terminates for some reason. Now, you manually killing the daemon is an extra-ordinary thing, but I understand that you’re doing that just to illustrate your point. ctkd could be terminated by the system for other reasons [1], or it could crash, and the framework should handle that. Are you actually seeing this in practice? I mean, without you manually killing the daemon? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Notably, both the daemon and agent variants specifically opt in to memory pressure termination: % plutil -p /System/Library/LaunchDaemons/com.apple.ctkd.plist { EnablePressuredExit => true … } % plutil -p /System/Library/LaunchAgents/com.apple.ctkd.plist { EnablePressuredExit => true … }

[quote='820929021, g_i_i_k, /thread/820929, /profile/g_i_i_k'] Filed an issue with Apple [/quote] What was that bug number? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I am seeing zero CloudKit pushes delivered on iOS 26.4. Filed FB22367981

Thank you for filing the feedback, @newwbee. We responded to your feedback privately a while ago, but I want to include the response here, too, for anyone else that might have the same question and stumbles upon this. SwiftUI’s Settings scene is designed to help you build a first-class Mac settings experience that follows Apple’s Human Interface Guidelines at https://developer.apple.com/design/human-interface-guidelines/settings#macOS Toolbars within Settings scenes use a style appropriate for a typical macOS settings window, which displays centered tabs to group related settings. (Please refer to Settings windows in apps like Safari and Mail as an example.) People also typically expect macOS application settings to be applied as soon as the setting is changed, without the need for a “Save” button. To create a bespoke settings experience for your app, you can use a regular Window scene, which uses a default toolbar style that you’d be familiar with in an application’s main and document windows. You w

I've been hitting the same refusal regression after 26.4 on guided generation. In my case I'm using LanguageModelSession with custom Generables for structured output from transcribed text, and the refusal rate jumped from near-zero to roughly 30% of requests after the update. Two workarounds that helped reduce it: that frames the task as data transformation rather than content generation. Something like: You are a structured data extractor. Convert the following input into the requested format. This seems to bypass whatever safety classifier is being overly aggressive. When you get a refusal, retry the same prompt with a slightly different temperature (0.1 increments). In my testing, about 80% of refusals succeed on retry, suggesting the classifier is borderline on these inputs rather than fundamentally objecting to them. The Bool.self casting issue you mention is particularly telling — a boolean response should never trigger content safety. This looks like a regression in the on-device safety classifier that

Hi, There are indeed some caveats around CATiledLayer's threading behavior, but this error does not seem expected given the setup you've described. If possible, could you file a bug report through Feedback Assistant (with either a sample project that reproduces this issue, or steps to reproduce this in your actual app) and provide the feedback ID here so we can investigate further?

Update: After extensive investigation I have identified what appears to be the root cause of the 401 Invalid Bearer Token error on my Intel Mac, and I want to share the findings in case they help others reporting similar issues on M1 and M4 machines. WHAT I FOUND (Intel Mac - x86_64): The Claude Agent binary that Xcode downloads is the darwin-arm64 build regardless of host architecture. On my Intel Mac this binary physically cannot execute, which fails silently and surfaces as a 401 error. Confirmed via terminal: file ~/Library/Developer/Xcode/CodingAssistant/Agents/claude/2.1.14/claude Returns: Mach-O 64-bit executable arm64 — wrong for Intel Mac The IDEChatClaudeCodeVersion preference is hardcoded to the ARM64 download URL: defaults read com.apple.dt.Xcode IDEChatClaudeCodeVersion Returns: darwin-arm64 URL regardless of CPU architecture We also confirmed the darwin-x64 binary exists in Anthropic's distribution bucket and runs correctly on Intel — both in the terminal and as a standalone binary: cur