“file uri scheme”

I have hit this exact crash pattern in my own ScreenCaptureKit audio capture pipeline. The EXC_BAD_ACCESS in swift_getErrorValue happens because the error object passed to didStopWithError is being deallocated before the delegate method can access it — it is a race condition in the XPC boundary between replayd and your process. The root cause in my case was that the SCStream object was being deallocated (or stopCapture was called) while a pending error was being delivered across the XPC connection. The error object lives in replayd's address space and gets bridged to your process, but if the stream tears down mid-delivery, you get a dangling pointer. Keep a strong reference to the SCStream instance beyond the point where you call stopCapture. Do not nil it out immediately. In your stream delegate, wrap the didStopWithError handler in a DispatchQueue.main.async to ensure the error is fully materialized before you access it: func stream(_ stream: SCStream, didStopWithError error: Error) { let errorDesc = String

OK by this: I tried deleting iOS 18 runtime via Xcode Settings > Components, and even removed iOS 26 runtime then re-downloaded it. But the iOS 18 runtime keeps auto-reappearing right after! I also ran sudo rm -rf against the iOS 18 asset folder, and it just throws a permission error—totally useless. I checked the Info.plist under /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/cc1f035290d244fca4f74d9d243fcd02d2876c27.asset/ and confirmed this folder is exactly the orphaned iOS 18.0 simulator runtime. I’m trying to delete this specific cc1f035290d244fca4f74d9d243fcd02d2876c27.asset folder but hit a wall with system permissions. I found this exact issue is already being discussed in the Apple Developer Forum thread here: Orphaned 9GB Simulator Runtime in /System/Library/AssetsV2 - Cannot Delete (SIP protected). It’s clearly a bug on Apple’s side with MobileAsset lifecycle management—these large orphaned simulator runtime assets get stuck in SIP-protected system directories, and Xcode/simc

What you'll find is that there are two clients— yours and a (presumably unrelated) 3rd party client. The other ES client is basically a 3rd party logger that's not active. Ours does some auth work, but we're fairly certain in this case it's just monitoring to do reporting and follow-up scans. Do you know exactly what kicked off your helper process? Both in terms of the triggering event and the target file? No. At the time, the system had been idle for 2 hours. In this case, we do observe a system update being staged in the background, but not in all other instances. I suspect it was a FILE_NOTIFY_CLOSE. It would be insightful to know if APFS triggers that or related ES events when decompressing a file. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. I will submit unified logs that cover the period in question, but your point remains. That ES c

So it appears to be the same failure we are talking about here: https://developer.apple.com/forums/thread/814076 I just updated that thread, but the bug described there (FB21805212) was fixed in macOS 26.4. Also, to be clear, the bug was specifically in smb, NOT copyfile itself. However... It has data. I can read the filenames when I view it as 'plain text’. The Resource fork is less than 300 bytes, but that is enough for it to cause copyfile to fail. The total file size is ~12kb. That doesn't sound like the bug above. The bug above was caused by the SMBClient incorrectly accounting for large xattr size, which then caused the copy to fail. I don't think it would have happened with small xattrs (certainly not 300 bytes). FYI, the Finder (and other copy engines) work because they're using the ..namedfork accessor, when it ends up going through a totally different code path in smb. Interestingly, .DS_Store causing problems with copying is infamous enough to have a mention on Wikipedia: Yes, but I think

FYI, FB21805212 should be fixed as of macOS 26.4. If you're experience this or similar failure on macOS 26.4 or later, please files a new bug and start a new forum thread with any questions. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thank you for sharing your post. I understand that it can be frustrating, especially when the job is impacting your daily routine. I am eager to assist you in any way I can. I have a potential idea, but I would like to request a bug filing for further investigation. Typically, authentication tokens expire after a few hours. In a stable build, Xcode silently uses a “refresh token” to obtain a new session in the background. Consequently, the system may be terminating your session when the initial token expires. This is an issue that requires immediate attention. However, I am only speculating about the cause. Given that this issue is occurring across two separate computers and began specifically in beta 3, it is highly probable that the problem lies within the beta itself rather than a misconfiguration on your end. Instead of simply signing out and signing back in, I recommend completely deleting the integration from Xcode. Navigate to Xcode > Settings > Accounts (or the specific Claude Agent set

Thank you, I will file a bug report. For anyone else that finds this, the scrollbar: always shows on my Mac Mini (mouse and keyboard only) does not show on my Macbook Air (trackpad) automatically shows when I connect a bluetooth mouse to the Macbook Air, but still does not allow mouse interaction. When I turn off the bluetooth mouse, the scrollbar disappeared. The trackpad allows for scrolling the chart with 2-finger swipe gestures, with or without the bluetooth mouse connected.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. I'll check the status next time I do a sweep of forums posts where I've suggested bug reports and post any information about changes I am able to share to this thread. Bug Reporting: How and Why? has tips on creating your bug report.

Let me start by saying two slightly contradictory things: It's very likely that there is an APFS bug here, so if you haven't already, please file a bug on this and post the bug number back here. It's ALSO very likely that your ES client (possibly both ES clients) are required to actually experience this bug, and you should address it as well. Next, I think I want to be clear that some of what I'm saying is a bit of an educated guess. A big part of the problem here is that the data we're looking at is being collected LONG (2+ days) after the problem itself actually occurred, which means we don't REALLY know EXACTLY what happened. That doesn't invalidate what I'm describing above, but I do think it's important to have some awareness of the limitation of the data at hand and that, most importantly, new data could totally change our understanding of the overall state of things. Getting into the details: But here, I don't see such things. When EndpointSecurityEventManager is on the spindump, it's only bec

Data Storage Security How should I handle data storage in UserDefaults and plist files? UserDefaults should be used to store preferences, not user data. The issues here aren't really security, it's that UserDefaults is an indirect API where you don't really control how the data is stored or managed. That's fine for preference data like where was the user the last time I ran but isn't really the right way to store actual user data. plist files — More specifically, data written and read using NSPropertyListSerialization — is a very reasonable way to store user data of the same type/format you'd store in UserDefaults (Strings/Data/Array/Dictionary/etc.). It shouldn't be used to store large amounts of data (megabytes), but that's primarily because that use case doesn't really fit the API's role, not because of any fundamental flaw. In terms of pure data security, both approaches are fairly similar. The data is being stored in the file system and is protected the same way any other file

Swift and Memory Safety What enhanced security features are useful for fully Swift apps? Enabling enhanced security features like PAC, EMTE, and typed allocations is still useful in Swift apps. In certain language modes, Swift apps which do not use unsafe can still have memory corruption issues due to data races (concurrently modifying a reference can cause reference counting errors). Similarly, although your application may be fully safe Swift, it may interact with libraries (provided by Apple or third parties) which are not fully memory safe, and so turning on enhanced security features will help protect you against issues not caused by your code. How can I use unsafe Swift methods safely? Methods with unsafe in the name can be used safely, but it requires more care and attention to do so. You won't always be able to avoid using such methods, but you can carefully isolate such code and of course make sure to devote more effort to reviewing and verifying any code that uses unsafe methods or types. How can I

Thank you for your post. The App Store team does not monitor the forums, and I believe you set your app as “Made for Kids” for the first time when you deployed the app. Since your app is already live, the “Made for Kids” flag and the “Kids” category are often locked to prevent developers from changing an app’s target audience without parental consent. This will be a significant privacy issue as you can see. To resolve a locked metadata field like that, you need to contact App Store Connect Support, not App Review. Visit the Apple Developer Contact Us page. The representative can file an internal ticket directly to the App Store Connect engineering team to manually unstick the metadata field on your account if appropriate. Now, depending on your app and the people affected by that change, the engineering team will decide whether to make that change. I’m not in that team now I know their process. Once App Store Connect Support unlocks the field and you successfully uncheck “Made for Kids,” you can subm