Should we use Interface Builder in need of dynamically created UI?

I'm currently thinking of project, which is basically interpreting data from many abstract data sources.

So the communication within application is like this

[UI] <-> [Controller / Delegate] <-> [Subclass of Abstract Data Source]

which is basically the MVC pattern. What is my problem, that each [Subclass of Abstract Data Source] can use only limited amount of [UI], so the flow is basically this:

• Create instance of Data Source (DS)
• Get list of possible UI's from DS
• Create UI chooser and instantiate preset UI
• Let DS modify UI
• Fill UI from DS by predefined handler method

Example UI's are NSTableView, NSOutlineView, NSCollectionView, etc.

So I basically need to change column names, order, style of controls, ... without possibility of having unique NSWindow designed for each Data Source

Now the question:

If I need dynamic UI creation and custom data handling logic (no bindings to Core Data, or so), should I (and is it even possible to) use InterfaceBuilder or should I implement all view logic programatically?

Use whichever you favor. Any variations/dynamic areas can be represented/handled by the controllers. In a way, that means that I recommend moving the dynamic portions to code to controllers -- but you can still use XIBs for common high level design, if you choose.

Therefore, when a view is not suitable for a singular data representation and is used for multiple, the implementation/variations can be moved to the controller domain. When an implementation/definition applies to all, then you can define that in the XIB or in the program -- wherever you prefer to put it. In that case, you can use XIBs (or code) for invariant (skeletal) views.