There are two parts to this.
1. IB (Interface Builder, part of Xcode) or not IB.
You could create entire user interfaces in code. All the necessary classes are available for you to instantiate and connect together. But it tends to be a lot of boring, repetitive boilerplate code. A better way is to have an editor that allows you to create these objects on a canvas, in a more or less WYSIWYG way. Then, you can simply archive (write to disk) the entire complex of objects, and in your app's code you can unarchive (read from disk and reconstitute) the entire mess of objects, in one line of code. Or zero lines of code, since loading the main UI archive is built into the app startup process.
That's what IB is about. It's a more efficient way to build UIs, leaving only the most app-specific details to be handled by your custom setup.
2. Understanding the compoents.
There's a rich history of classes and patterns, which makes macOS and iOS development bewildering at first. Keep in mind that basically everything involving the UI is based on the MVC (model-view-controller) pattern, where "knowledge" is compartmentalized to keep information as local as possible. (Global information ends up being a set of constraints on large amounts of your code, making it much harder to change things later.)
The "V" part of this refers to views and other components that are user-facing. Views are a combination of a drawing surface and a set of user interaction behaviors. In current design patterns, the drawing surface tends to get separated out (by the system, if not necessarily in your code) into separate layers for performance purposes (since the presentation is done large via a GPU instead of the CPU alone, in modern hardware). Interaction behaviors are events, touches, gesture recognizers, text input, target-action routing and so on.
The "C" part refers to controllers that in current design patterns tend to contain the "business logic" that manages the "V" parts, and coordinate communication with the "M" (model) parts of the app. (That's why blogs and sample code seems focused on view controllers. That's where most of your code ends up. But they aren't the entire UI in themselves.) Usually, the "C" and the "V" are a matched pair — window and window controller, view and view controller — but the design is pretty flexible. For example, a view controller has its view, but it may also manage some or all of the subviews of that view, which don't need view controllers of their own.
So…
When you write your UI entirely in code, you have to understand the details of how a lot of objects are intended to interact, and to construct them and interconnect them in just the right way. IB has all this standard knowledge built in, allowing you to create your UI based on what you want it to look like, and you don't have to worry about all the details of turning this into code.
Some developers hate doing this, and insist on building their UIs programmatically. I guess you gotta do what you gotta do, but the easy and productive way is to do everything possible in IB, and write code only when absolutely necessary.
