Multiple but Different Views in same Window

You can have as many different views (or kinds of views) in the same window as you want. A window has a single content view, but you can add any number of subviews to the content view, and you can arrange them any way you want. Sprite Kit or Scene Kit views are no different in this regard, the only restriction being that it's not desirable to have any other view overlap a Sprite or Scene Kit view, since those views use OpenGL or Metal and compositing them with regular views can be a performance killer. Adjacent views should be fine, though.

If your app is document-based, your NSDocument subclass instance has an associated window, but there's no particular relationship between the document's data and which subviews of the window display a representation of that data.

Note that if you represent document data in a specific subview, you probably want a view controller for that subview (for document-UI-specific logic, since it no longer really belongs to the top level content view). Because of the way storyboards work, you would have to use a view controller hierarchy as well as (in parallel to, sort of) the view hierarchy, and that will introduce an extra level into the view hierarchy. Let me know if you want me to spell out how to achieve that in your storyboard. (The alternative is to have the top level view controller manage all of the views in the hierarchy.)

You will have to come up with a strategy for laying out the subviews of the content view to fit the window. Autolayout constraints are probably what you want here. However, if the subviews are to be user resizable (by dragging the borders between the views) then you would likely use a NSSplitViewController to structure your window instead of simply using subviews.

That's the overview, as briefly as I can tell it. If you want me to expand on any part of this, just say so.

Thanks Q

I have been experimenting with storyboard in a documents based applicattion. I added a Split View Controller. I disconntected the View Controller with the label "Your documents contents here". Then connected the Window Controller to the Split View Controller, I disconnected one of the View Controllers from the Split View and then reattached the the other. All this through the Connections Inspector. Then I placed a Text View in the Document View Controller.. Compiled it to see if it would run. Next, program it for functionality.

BugMage

Allow me some time to experiment further with what you had written above... again thanks.

Yes, that all sounds correct. However, if you want to divide a view via subviews, and you want to give one of the subviews its own view controller, it's not obvious how to get there in the storyboard.

What you do is use a "container view" (one of the objects in the IB palette chooser that contains the various controllers, views and controls) as one of the subviews. Then you drag a view controller (of some kind) onto the storyboard, and connect the container view to this view controller using an "embed" segue (the only segue offered in this case). Then you put the subview contents inside the sub-view controller's content view. As I said earlier, this introduces an extra empty view into the hierarchy, but it's harmless.

It also makes the sub-view controller a child view controller of the top level (parent) view controller, giving a view controller hierarchy that's similar, but not identical, to the view hierarchy. It's a bit hard to describe in words, but it's very logical once you can see the whole picture.

(in response to Q)

----------------------------

1Parent View Controller

1Container View 2Container View

1Child View Controller 2Child View Controller

--------------------------

Do I use two Child View Controllers to view my contents?

BugMage

There are a total of 3 view controllers in that configuration, each of which may be a standard class (like NSViewController) or a custom subclass. That means you can divide your custom functionality amongst the custom subclasses however you want.

There's no right or wrong here, and hierarchical view controllers are relatively new to the Mac, as a standard design pattern. (They have been usual on iOS since the beginning.) In the past, complex multi-pane windows have tended to be implemented in a giant, monolithic NSWindowController subclass. We're still feeling our way, a little bit, with the distributed view controller hierarchy approach.