“file uri scheme”

[quote='818622021, mobiusmoonglade, /thread/818622, /profile/mobiusmoonglade'] Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? [/quote] No. Our direction in this space is the ManagedApp framework. It’s super cool. For a short intro, watch WWDC 2025 Session 203 Get to know the ManagedApp Framework. However, it won’t work for you because it’s not available on the Mac. Also note that its focus is on apps and app extensions, so it’s not clear how it would work for a launchd daemon. If you’d like to see ManagedApp support your use case, I recommend that you file an enhancement request describing your requirements. And if you do that, please post your bug number, just for the record. Beyond that, the only option that I’m aware for provisioning a daemon is via the super obscure mechanism [1]. However, that’s really meant for configuration settings rather than credentials. You could obviously jam a credential into it, but that has significant drawbac

Right. That’s the Swift compiler crashing, which is something it should never do. I recommend that you file a bug about it. And as this is specific to Apple technologies, you’ll have to use Feedback Assistant rather than the Swift open source bug process. 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

This is likely fallout from Wi-Fi hardware changes, so the best path forward is for you to file a bug about it. 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

It's not really about what the Numbers guy does but probably what FileDocument lets it do it. I have never used FileDocument with an iOS app. I do have a macOS application with FileDocument. If I open and then close a document and then move it under a different volume or a folder, the application is still able to open it. But it won't if I move a file to the dumpster.

Right -- think I've had a breakthrough: the entitlements file for the appex shows its app ID as follows: [Key] com.apple.application-identifier [Value] [String] $(AppIdentifierPrefix)$(PRODUCT_BUNDLE_IDENTIFIER) while the main app shows a proper value: [Key] com.apple.application-identifier [Value] [String] XXXXXXXXXX.com.mydomain.MyApp For some reason, the Xcode variables weren't being substituted in the FileProvider! The surprise here is simply that the app worked for so long without the entitlements being validated... Anyway. I've confirmed that the app now presents the entitlements validated flag correctly on our older machines; once I hear back from the employee running this on Sequoia that it works now, I'll accept the answer here. Thanks!

Interesting. Is there any issue where I could track that status on the swift language? And is there any other known workaround beside copying the related declarations together in one file?

Is there a way to mark the file 'unselectable' with the published progress? I'm not sure if/where this was originally documented, but the Finder actually still does this the way macOS Classic did, which is by using type/creator codes. If you're not familiar with them, macOS Classic originally related files to the apps using two 32-bit values- type (meaning what kind of file is this) and creator (meaning, what app should open this). By convention, these were constructed 4 ASCII characters, leading to definitions like these: kFirstMagicBusyFiletype = 'bzy ' kLastMagicBusyFiletype = 'bzy?' How you set them is a bit obscure, but getattrlist/setattrlist (see their man pages for full details) provides access to them through ATTR_CMN_FNDRINFO. The data returned in the concatenation of the FileInfo and ExtendedFileInfo structures[1], with the type being in FileInfo.fileType. Note that the ATTR_CMN_FNDRINFO structures are used to store other data, so the normal behavior is to retrieve the cu

Quinn, thank you for another quick and informative answer (and for explaining the change in the man page text). If I were in charge, you would never have to pay for a beverage again. ;-) A couple of quick clarifications: I haven't implemented any XPC listeners yet; it's more how I'm thinking about the low-level messages I'm seeing that refer to Mach service names and the like. That said, when I wrote a single XPC listener for both, using the same service name under each key, I meant that I would enter the service name for the single listener under both keys in the Info.plist file. It seems clear to me that multiple listeners need unique service names for each. You've summarized quite well the tradeoffs of single vs. multiple sysexen. In the case where both subsystems feed events to a common module, a single sysex seems like the better choice. Thanks again for your assistance.

@TE2026, thanks for filing that report. Would you mind also opening a code-level support request so that I can discuss the situation with your particular Mac directly with you? We found some useful insights in the logs you attached, but they're potentially really specific to you instead of being broadly useful to the community. — Ed Ford,  DTS Engineer

Hello, I apologize for the issues you're hitting with Voice Control, these definitely sound like real bugs. When you get a chance, could you please paste the Feedback Report IDs for the bugs you've filed? We are already aware of some of the bugs you've mentioned, but if you can forward the report IDs here, I can ensure we track those as well, so that you are notified when the bugs are fixed in a future release! Thank you for taking the time to report these issues!

For UIKit, isDarkerSystemColorsEnabled indicates whether Increase Contrast is active. To receive updates when this setting changes, observe darkerSystemColorsStatusDidChangeNotification. For AppKit, the accessibilityDisplayShouldIncreaseContrast property indicates if a high-contrast user interface should be presented. Apps can register accessibilityDisplayOptionsDidChangeNotification to respond to changes in this setting Lastly, SwiftUI has colorSchemeContrast, an environment value that provides information on whether standard or increased contrast applies to a view. SwiftUI automatically updates this value when the contrast changes, redrawing views that depend on it. I encourage you to share your workarounds here, as well as file separate bug reports against each app that displays incorrectly. Once complete, post those FB numbers in this thread and I will make sure they get the correct eyes on them. Thank you.  Travis

@_lilpit and @Russ_T, Thank you for filing these Feedback reports. We are looking into them.

@e5johnson Please file a code-level support request including your Team ID for assistance.