“DTiPhoneSimulatorErrorDomain Code 2”

I am developing a library called MemoryCryptor for macOS. Its purpose is to protect sensitive data of the calling process (including launchd daemons), e.g. user passwords and other secrets, from being written to disk or read directly by debuggers or malware. So, the first thing I need to clarify here is what you're threat model is and to what degree you're willing to trust the operating system itself. The problem here is that there's a spectrum of trust that runs from: If you trust the operating system, then the solution is fairly simple. As described here, if a process has Get task allow set to false, then the system will not allow any process to retrieve that processes task port. Without that port, there's no way for an app to gain access to another apps process, solving the issue. Are many other mechanism at work that reenforce and/or prevent other attack vectors, but the general answer here is that that standard system configuration makes ensures that one process cannot read the memory of another process

The stack you've posted is entirely within the ShareSheet framework — no app frames are visible. -[__NSArrayM insertObject:atIndex:] + 1276 is the code path that throws NSInvalidArgumentException when you pass a nil object, so something inside SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion: is receiving a nil item provider for one of the activity items and adding it to an array without a nil check. That suggests a framework issue, but I'll need more to be confident. It's also possible that the specific item you're passing to UIDocumentInteractionController is what triggers the nil-provider path. A few things would help narrow this down: A full .ips crash report. Beyond the top frames, the thread that crashed, the other threads' states, and the binary images list all matter for diagnosis. The exception reason string matters most — the *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '...' line that usually precedes this kind of stack. Tha

Thank you very much for the very quick replies. Almost an honor to hear from two literal dev forum legends so quickly. This is much, much funnier than you'd realized. Up until COVID took WWDC virtual, Quinn and I would regularly end up hanging out together in the WWDC labs... talking someone out of using MultipeerConnectivity. Apparently, we've continued that habit into the forums. To the feedback FB22691771 I now added: Fabulous, all of that was perfect. In terms of what the logs show, if you narrow down to the MultipeerConnectivity library, you'll clearly see that it's repeatedly discovering the device and attempting to connect, only to have the connection fail over and over again. What's causing the full failure pattern isn't clear, but it's likely tied to these messages on the receiver side: 2026-05-11 08:30:50.990771+0200 wifip2pd: [com.apple.awdl:subscribe] AWDLBrowse _rps-service._tcp.local will attempt to stop 2026-05-11 08:30:50.991521+0200 wifip2pd: [com.apple.awdl:subscribe] AWDLBrowse _rp

I re-wrote the code after much experimentation, some time ago, and solved the issue. Please ignore.

Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown. I'm not sure why we wrote it that way, but I believe that description is somewhat misleading. What sudden termination actually does is change how an app is expected to handle quit. The standard quit flow is that an app receives kAEQuitApplication, which then lets in opt in/out of exiting through applicationShouldTerminate(). Sudden termination reverses that approach. When sudden termination is enabled, the system quits your app by directly terminating it without any notice or warning. Your app is then responsible for telling the system NOT to do that by using disableSuddenTermination()/enableSuddenTermination(). You can read more about it here, but my guess is that it's probably not a factor. That's primarily because it's hard to send kAEQuitApplication to an FBA (Faceless Background App) unless you really dig into the system, but also because I believe we start with sudden termination disabled, so your

Is it only with objC code or Swift as well ? Xcode 26.5: In new iOS storyboard project I can connect IBOutlets from the Assistant editor in Swift...looks fixed there. Connection bubbles show. But in Objective-C the connection bubbles are completely gone from source files so in ObjC the problem is not fixed, actually worse. You can connect from the Connections Inspector though, but Xcode won't display connection status in ObjC source. So for me, because I still use ObjC the problem is worse. Hope that's not intentional. That would be very very negative evolution. You mean typing xibs by hand doesn't make you more productive!? 😂

Your collectionBehavior is close — canJoinAllApplications is the right option for spanning other apps' Spaces — but two other pieces are missing for floating above full-screen apps: 1. Accessory activation policy. macOS doesn't layer regular foreground apps above other apps' full-screen Spaces. Overlay utilities like DropOver use NSApplicationActivationPolicyAccessory, which removes the Dock icon and app menu bar (most overlay utilities add a menu bar status item in their place) and lets the app's windows appear above full-screen content from other apps. In your app delegate's applicationDidFinishLaunching: NSApp.setActivationPolicy(.accessory) 2. NSPanel with .nonactivatingPanel. An NSWindow activates its app when ordered front, which can cause a full-screen app to exit its Space. An NSPanel with the .nonactivatingPanel style mask doesn't. Full panel setup: let panel = NSPanel( contentRect: NSRect(x: 200, y: 200, width: 260, height: 140), styleMask: [.nonactivatingPanel, .titled, .closable]