How were you planning to describe the program's entry point to the linker? If this is taken from a code sample for another operating system, is it relying on some implicit GCC behavior? Mach-O uses a load command (LC_UNIXTHREAD before 10.8 Mountain Lion, LC_MAIN afterwards) which indicates the entry point of the executable. When using ld, the symbol can be specified with -e (the man page - x-man-page://ld contains more details about default behavior).

I use NetFSMountURLAsync quite a bit in code, but moved off AFP a while ago. Is there a particular reason you're not using SMB at this stage? You might mention the error code returned, any options you're providing in the two arguments. It's possible mount_afp processes the URL (ParseAFPURL and uamName) and sends the AUTH parameter as an option to mount(2). Technically such options should be supported by the keys in NetFS.h, but only the general ones are documented (and some like allow loopback are broken).

Sounds like what you really want is a "shared" search field that can delegate to the current view controller. In that case you'd use a protocol which your view controller(s) conform to, then an API (possibly in your window controller) which inserts a search field (if it doesn't already exist, or discovers one using an identifier) and connects to the current view controller to send it the relevant messages and provide a reference. The view controller should "attach" then "detach" using the protocol, and the true ownership should be by e.g. the window controller.

You don't need a custom NSWindow subclass to declare storage and an outlet for NSToolbar, it already has a reference. It's not entirely clear to me what you're trying to achieve. Is the goal to have a reusable view controller which discovers an NSSearchField located in the window containing the view? If so, you should strongly consider using an identifier for the search field, which the view controller declares as a public constant. The contract then is the window (e.g. representing a document) contains its own arrangement and customization of the toolbar and field (which uses the identifier). At some point it has the view of this view controller inserted into its hierarchy. When that happens, viewWillAppear() or similar mechanism searches the toolbar of the view's containing window and locates the NSToolbarItem with its defined identifier. What it does with that reference is then up to you. Normally IBOutlets and IBActions are used when there's a strong contract between the interface file and a class, usually the File's Owner. If you're looking to discover a view from a reusable class (like a view controller provided by a framework), something like an identifier or tag is a better "fit".

Regardless of the issue, you should use defaults delete to remove preferences from the current user, since the cfprefsd process will keep an in-memory copy of the data.

Looks like you're doing two different things. Your command adds a certificate as "trusted", which usually isn't necessary unless it's self-signed. In particular you're using the root user to modify the current user's keychain, which might have the effect of making it unreadable by that user The file extension is cer which is not an identity. An identity is a certificate and its private key together in one file, which is almost always encrypted with the extension p12.

The provided method wouldn't be an image (whatever VMware does). A Google search for "macOS Mojave" (or other version) usually turns up a support page from Apple which has a Mac App Store link to the installer app. The app contains the createinstallmedia tool which can create the kind of image you're looking for. For Mojave that page is How to upgrade to macOS Mojave - https://support.apple.com/en-us/HT210190, and the link is Get macOS Mojave - https://itunes.apple.com/us/app/macos-mojave/id1398502828?ls=1&mt=12

If you've reinstalled over the existing installation and still have the same issue, you might consider deleting any saved state for System Preferences in ~/Library, like: com.apple.systempreferences defaults Caches/com.apple.systempreferences

macOS releases have followed iOS/etc by ~one month for many years now. The Xcode 12 GM Seed release notes said: Xcode 12 includes SDKs for iOS 14, iPadOS 14, tvOS 14, watchOS 7, and macOS Catalina 10.15.6 Consider downloading the correct version of Xcode for macOS Big Sur development, which is Xcode 12 beta 6Released August 25, 2020Build 12A8189n

If the dragged outlet doesn't descend into NSToolbar (and the NSToolbarItem containing your view), you can always do the reverse by disclosing the toolbar, then clicking into the custom Item and selecting your NSSearchField. From there and the Connections inspector, drag the New Referencing Outlet to your view controller.

Are you using the current sudo kextload /System/Library/Extensions/smbfs.kext workaround for Beta 6?

The first responder isn't just a named item in Interface Builder, it usually refers to the receiver of nil-targeted actions, as described in Event Architecture - https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html If you want to receive the protocol's message, your intended NSResponder must implement the method (likely in a subclass), then be in the responder chain when you change the color in the panel. An example is an NSTextView subclass which changes its @backgroundColor according to the panel's current selection.

NSColorPanel uses the NSColorChanging protocol on the first responder. That's the general mechanism for most floating panels.

Depending what you're referring to, LaunchServices has had some weird cache invalidation issues around apps in macOS since Yosemite. A classic case is adding a new document type to an app and the UTI not being recognized when debugged for the first time. However, this should mostly occur on developer machines, since users will be installing/copying apps in ways that always trigger LaunchServicesD (make an acronym from the capitalized letters since it will be censored by the forum otherwise). The two most common options are simply touch(1) on the app bundle itself, or the more complicated lsregister found in /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support. You'd want a command like lsregister -f <APP>. I've found lsregister -dump really useful if you want to know what the operating system currently "knows" about your app.

Historically, NSControls are identified by tag which is an NSInteger. In code you might use a constant to refer to a particular number then use that in your controller. There's also the NSUserInterfaceItemIdentification protocol from OS X Lion, which takes a string assigned in Interface Builder (or the automatic one, usually of the form _NS:???). Finally there's the NSAccessibility protocol, which takes a description, title, etc, but is intended to be user-facing.