A lot of my frustration comes from not knowing how Interface Builder does its voodoo.

Yeah, Interface Builder is definitely a confusing piece of the puzzle. You'll probably find that once you've written a few small apps you tend to use the same functionality from it over and over, and it gets a little easier.

For what it's worth, even as a macOS developer with decades of professional experience, I find auto layout highly confusing, and have never touched bindings. SwiftUI is pretty cool, but I've found it somewhat limited.

I also don't have a firm grasp on what design patterns to use.

The biggest pattern for creating the UI for your app is the Model View Controller (or MVC) pattern. Apple has a pretty good description of it here. While they talk about it in terms of UIKit, it's pretty much the same in AppKit.

Your "model" is the data your app creates and reads. If you're writing a spreadsheet app, it's the values of all the cells. If you're writing a word processing app, it's the words the user typed and their styles, etc.

Your views are any classes derived from NSView or UIView. They display the data from the model. They may or may not display all of it, depending on what's appropriate for your particular use case. These are things like text fields, sliders, checkboxes, etc.

Your controllers hold the logic for updating views when the model changes, or updating the models when the views change. There are a number of ways they can work such as directly modifying both views and model, or by sending notifications which are observed by the views and models. They also can be directly manipulated by your model and views, or can observe notifications from your model and views.

What classes are okay to use a delegate? Why doesn't IB let me drag over a delegate linker thingy all the time? What /is/ a delegate?

A delegate is a way of having 2 classes be able to communicate without knowing about each other fully at compile time. A delegate implements a particular protocol (explained below). Say, for example, you want to display a table of students and their scores on the assignments you've given them over the past semester. Apple doesn't know what type of data you'll display in a table, so it created a protocol for the data source for a table view. A protocol is literally just a list of methods that you promise your data source class implements. (In some other languages, this is called an Interface or an Abstract Base Class.) NSTableView doesn't know what class you will use to supply data for the various rows and columns of the table, but in knows that your class will implement methods that tell it things like the number of rows and columns in the table, and that will return an object for each cell of the table. Classes that implement the NSTableViewDataSource protocol are delegates of an NSTableView. (There's also a second type of delegate for an NSTableView — the NSTableViewDelegate — that handles things like how to display the cells. It's the same concept.)

When should I be using a class like NSView and when should I be using an NSViewController?

As mentioned above, an NSView displays some piece of data and allows the user to interact with it. An NSViewController mediates between an NSView and your model object. The view controller also has hooks for determining that the app loaded your view from its NIB file or that it was displayed to the user.

How can I do <x> IB thing purely in code?

Depends on what <x> is, but generally, if there's an object of some class you're dragging around in IB, you can instantiate one directly in code via something like:

NSView* myView = [[NSView alloc] initWithFrame:viewFrame];

You then need to manually add it to your view hierarchy by calling:

[parentView addSubview:myView];

Anyway, if you have other questions, feel free to post them here. I'd be happy to help if I'm able to.