“DTiPhoneSimulatorErrorDomain Code 2”

[quote='826273021, jaikiran, /thread/826273, /profile/jaikiran'] we even printed the details of an already signed binary … and that prints [a] similar warning message [/quote] OK. Lemme explain how that message comes about, and I think you’ll be able to extrapolate from there. The codesign tool calls SecCodeCopySigningInformation and looks at two properties: kSecCodeInfoTime and kSecCodeInfoTimestamp. If the values differ significantly (3 minutes IIRC) you get this message. While these properties are covered reasonably well by the documentation, the best source of info about them is the doc comments in . In summary: kSecCodeInfoTimestamp is secure, having been issued by Apple’s timestamp service. For more on that, see the Certificate expiration section of TN3161 Inside Code Signing: Certificates. kSecCodeInfoTime is based on your Mac’s time setting. So I suspect that the Mac doing the signing has a clock that’s way of sync with reality, so these two values end up significantly diffe

[quote='826232021, oddeyed, /thread/826232, /profile/oddeyed'] we were posed with the option of choosing a Developer ID Certificate Intermediary [/quote] Oh, that’s a new one. [quote='826232021, oddeyed, /thread/826232, /profile/oddeyed'] Can you please let us know which Developer ID Certificate Intermediary we should choose … ? [/quote] I don’t think there’s a one-size-fits-all answer to that, which is why we give you the choice. My general advice is that you pick the new one, but the old one might make sense if: You have infrastructure that relies on ancient versions of Xcode (or the Command Line Tools package). Or infrastructure that’s tied to a specific intermediate. Picking the new one may require you to install the new intermediate on your build infrastructure, but that’s not a particularly onerous task. From a deployment perspective, this choice shouldn’t matter. When codesign signs code, it builds a chain of trust and embeds that full chain into the code signature. So when a Mac goes

There are a couple of ways XPC services can help with security. The first is the one you’re talking about, that is, where you give the XPC service elevated privileges. Your ‘delete a user’ example isn’t great though, because deleting arbitrary users is problematic and it also requires BSD privileged escalation. So let’s consider a different example. Consider a sandboxed app that wants to install an item in ~/Library/PDF Services. There are no BSD level blocks to doing that, but it is blocked by the App Sandbox. To get around that block you sign the app with the com.apple.security.temporary-exception.files.home-relative-path.read-write temporary exception entitlement. Cool, problem solved! Note For links to more about temporary exception entitlements, and the App Sandbox in general, see App Sandbox Resources. However, if your app gets compromised then it might install arbitrary stuff into ~/Library/PDF Services, which isn’t great. So instead you move that code into an XPC service and the app tells the

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!? 😂