“file uri scheme”

Dear Apple Support, I would like to raise a concern regarding the behavior of the “Desktop & Documents Folders” feature in iCloud Drive. From a business and development standpoint, the fact that folders may be automatically moved or created without clear and explicit user awareness is quite concerning. File system behavior is something users generally expect to remain predictable and fully under their control. In particular, when working in development environments, even small and unintended changes to folder structures can lead to issues such as broken file paths, build errors, or inconsistencies in project setups. The possibility that such changes may occur automatically introduces an element of uncertainty that is difficult to manage in professional workflows. Additionally, there are security considerations. For example, if sensitive files such as configuration data or API keys are temporarily stored on the Desktop, the possibility that they could be unintentionally synced to

I've got a Project with a bunch of frameworks, each of which has a static library version of itself (for compiling command-line tools that also use the code). Compiling the frameworks goes fine. Compiling one of the static libraries (A Mime-parsing framework) is giving me the rather odd message that a bunch of symbols are ambiguous, but the ambiguity resolves to the same symbol in the error-message... ~/src/E3Mail/Frameworks/E3Mime/E3Mime/Message/MIME/E3AppPkcs7Part.m:57:18: error: reference to 'E3_SMIME_ENVELOPED_DATA' is ambiguous 57 | case E3_SMIME_ENVELOPED_DATA: | ^ In file included from ~/src/E3Mail/Frameworks/E3Mime/E3Mime/Message/MIME/E3AppPkcs7Part.m:9: ~/src/E3Mail/Frameworks/E3Mime/E3Mime/Message/MIME/E3AppPkcs7Part.h:17:2: note: candidate found by name lookup is 'E3_SMIME_ENVELOPED_DATA' 17 | E3_SMIME_ENVELOPED_DATA, // Enveloped data | ^ In module 'E3Mime' imported from ~/src/E3Mail/Frameworks/E3Mime/E3Mime/Message/MIME/E3AppPkcs7Part.h:8: ~/src/E3Mail/Frameworks/E3Mime/E3Mime/Message/MI

When I have a TextField or TextEditor, tapping into it produces these two console entries about 18 times each: CHHapticPattern.mm:487 +[CHHapticPattern patternForKey:error:]: Failed to read pattern library data: Error Domain=NSCocoaErrorDomain Code=260 The file “hapticpatternlibrary.plist” couldn’t be opened because there is no such file. UserInfo={NSFilePath=/Library/Audio/Tunings/Generic/Haptics/Library/hapticpatternlibrary.plist, NSURL=file:///Library/Audio/Tunings/Generic/Haptics/Library/hapticpatternlibrary.plist, NSUnderlyingError=0x600000ca1b30 {Error Domain=NSPOSIXErrorDomain Code=2 No such file or directory}} <_UIKBFeedbackGenerator: 0x600003505290>: Error creating CHHapticPattern: Error Domain=NSCocoaErrorDomain Code=260 The file “hapticpatternlibrary.plist” couldn’t be opened because there is no such file. UserInfo={NSFilePath=/Library/Audio/Tunings/Generic/Haptics/Library/hapticpatternlibrary.plist, NSURL=file:///Library/Audio/Tu

I’m reporting a severe reproducible issue in Instruments, specifically when using the SwiftUI instrument and opening Show Cause & Effect Graph. What happens: • Instruments becomes extremely laggy/unresponsive • The graph/detail area can turn solid magenta/pink • Memory usage rapidly increases (I observed around 18 GB, 25 GB, and up to 34 GB) • My Mac has crashed/restarted during this, or in other terms, had a kernel panic, where my Mac froze, and everything unresponsive. The Trackpad wouldn't even click. Important detail: • I could not find a generated kernel panic log after the crash/restart. Repro context: • SwiftUI iOS app profiled from Xcode • Trigger is specifically entering Show Cause & Effect Graph • Recordings can be short and still trigger it • Issue is much less severe or absent if I avoid that view What I already tried: • Rebooting • Short captures / fewer instruments • Clearing Xcode/Instruments caches/preferences • Retesting after cleanup • Reinstalling Xcode Is this a known Instruments r