Use of 'external object' in interface builder and modularity

This is a question about best-practices.

I have an application that uses a standard iOS tab controller.

One of the things that I'd like to do is split the XIB up into separate files. I can achieve this by specifying the 'child' XIB in the 'NIB Name' section for each tab controller. So far, so good.

In this application, I have an object that is used by virtually all of the UIViewControllers (e.g: provides web service calls). Let's call it MyServices.

In the single XIB solution, I can drag an object onto the Objects list, set the type to be 'MyServices'. I can declare in each ViewController an IBOutlet of type MyServices*, and wire the two together. This works nicely.

However, if I move my view out to a separate XIB, any controllers further down the stack that need acces开发者_如何学Pythons to the MyServices object are out of luck, because the object no longer exists within that XIB to perform wiring with.

What I'd expected to be able to do is to declare an 'external object', and wire to that instead. But I can't see how I 'pass' the MyServices Object in the 'parent' XIB as the 'external' object in the child XIB.

Is this just not supported in IB? What is the best alternative?

I could not specify the XIB name in the controller, and perhaps programatically create it at runtime (presumably with some kind of loadFromNib code declaring a dictionary to provide the external object). This does mean that the controller that does this has to be aware of MyServices, even if it doesn't use it directly.

Alternatively, I could have a 'dataProvider' in each UIViewController, so instead of setting the MyServices directly as an IBOutlet, it could do do [dataProvider getServices]. Again, will have to be wired to something that can do that - which limits where XIBs can be broken up. And it feels a bit needlessly verbose..

What's the best practice here?

It looks like with using External Object, you take the object instantiation back into your own hands and you also have to instantiate the NIBs manually. At least that's what I gathered from the answer to How to use a common target object to handle actions/outlets of multiple views?

Can I use Interface Builder to inject dependencies across multiple nibs? asks very similar question to yours, also without a real solution.

In How do I set up a proxy object in the main application NIB? the author also gives up on the idea of using Interface Builder as a dependency injection tool.

So I would guess that we, the Java immigrants, are banging our heads against invisible walls here. The metaphors we use to shape the code in our heads (and the code qualities we've come to value and associate with quality), do not apply to Objective-C, as is. That might be because we are not familiar with Obj-C idioms. Or it might be, that we are dealing with different evolutionary stages of language and community development (for example see the staggering immaturity of TDD practice in Obj-C). I, personally, have not seen much best practices described in Obj-C world in the 9 months that I am seriously dealing with it.