In that case, -[NSApplication setActivationPolicy:] should be the ObjC/Cocoa equivalent to the C/Carbon procedure. LSUIElement is still a great feature for menu bar apps, though slightly more complicated ones which want things like state restoration need a little more help.

In your Info.plist are you using NSPrincipalClass NSApplication, and does your NSMainNibFile refer to an XIB with a Main Menu in it?

Did you compare your main.m? Are you calling NSApplicationMain() somewhere, or manually performing the equivalent using Carbon?

WoL certainly still works because Apple Remote Desktop uses it in the "Wake" function. There's also DNSServiceSleepKeepalive in dns_sd.h which operates on the principle that you've woken a machine (likely a dark wake) to access a network service (possibly using the sleep proxy) and you need to keep the machine awake long enough for a long-running task to complete. Have you run pmset -g to make sure you don't have any odd settings? I can't speak to the efficacy of third-party tools, but you should try macOS ones first and confirm the issue. Also make sure you have the right MAC address.

Given the crash is in dup(2) called during -launchWithDictionary:error:, the crash is mostly likely EXC_GUARD GUARD_TYPE_FD, which means you're doing things with system-protected descriptors that you shouldn't. This would include reopening things already open, closing descriptors which don't belong to you, etc. Since you're using NSTask, it would be through NSFileHandle, and if you're launching lots of processes (simultaneously, or over time) you probably have a race condition based on incorrect usage of -closeFile (read the documentation of @standardInput) or you're creating them from raw descriptors but not keeping track of them.

Depending on the functionality, there are many options. One is to put additional APPs inside your main one in /Applications, another is to put resources in /Library/Application Support/<YOURNAMEHERE>. LaunchAgents (both per-user and system-wide) are one way, SMLoginItem is another, but the best is not to require that kind of functionality at all. If you have a periodic background task, consider using the background activity scheduler and an XPC service, which are started by the system and contained within your app.

It doesn't look like you provided the full error. The thread doesn't need to be "new", you can launch a task on any thread, but some of the functionality will require a running runloop.

The lower-level commands will probably provide more information: Open Terminal Type cd /tmp and press Return Type sudo rm -r (note trailing space) Drag the installer app to the Terminal window Press Return Type in your administrator password Press Return Depending on the result, it may remove some of the contents, or none at all, but you should get a specific error message. A command like rm -r is very dangerous which is why I recommend changing the directory first.

Are you sure this is a crash? What you've provided looking like a hang, where it's stuck on the os_unfair_lock. If it's actually a crash you need to provide the essential elements of the crash report. If it's a hang, you left out the more important parts of your summary: on the app's main thread, the run loop is calling out to draw, which requires updating the constraints, and in the process of recalculating the size of some text in an NSTextField, an os_unfair_lock in NSCache is deadlocking. Are you modifying the view off the main thread somewhere?

Have you considered using sample(1) or spindump(8)? macOS comes with tools to generate backtraces externally without jumping through special hoops. And I don't think you can attach to macOS (Apple) processes with SIP enabled.

This sort of thing can happen (authentication failures) if the system clocks are desynchronized.

If you're concerned purely about reference counting, you could simply take an extra reference during your loading mechanism, but there also seems to be some confusion about whether this is Cocoa (ObjC) or CoreFoundation (C/C++). Perhaps you could talk a little about why this particular bundle needs to stay resident?

The libraries may not be missing...from the Release Notes - https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes: New in macOS Big Sur 11 beta, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286)

Depending how you're doing the update, you probably want to touch -[NSAnimationContext duration] or +[CATransaction animationDuration]

Unredacting the logs reveals the issue, insufficient permissions to load the kernel extension. Just run this (once): sudo kextload /System/Library/Extensions/smbfs.kext Edit: filed as FB8628919