“file uri scheme”

Unfortunately it’s hard to offer advice without being able to reproduce the problem. FWIW, I’ve seen issues like this a bunch of times )-: In some cases they are transitory. I go back and repeat my actions and things just work. But in the cases where the problem is reproducible, I’m able to file an actionable bug report. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Consider this: % swift demangle _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF MetricKit.mxSignpost(_: __C.os_signpost_type_t, dso: Swift.UnsafeRawPointer, log: __C.OS_os_log, name: Swift.StaticString, signpostID: os.OSSignpostID, _: Swift.StaticString, _: [Swift.CVarArg]) -> () So, the problematic symbol is mxSignpost(…). According to the documentation, that’s available on iOS 13 and later. However, that’s clearly not the case O-: I see two possibilities here: The availability annotation is just wrong. The symbol is available on older system, but it moved, and the corresponding .tbd file doesn’t record that move. I suspect that it’s the latter [1] but, either way, it’s a bug in the MetricKit framework interface and you should file it as such. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @

[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