Is it a bad idea to set a UIViewController as a property of another UIViewController?

For example, say I have a RootViewController class and AnotherViewController class, and I need to change a property in my RootViewController from AnotherViewController... is it safe to have a "RootViewController" property in AnotherViewController.h (so that I can access its instance variables)?

@interface AnotherViewController : UIViewController {
    RootViewController *rootViewController;
}

@property (nonatomic, retain) RootViewController *rootViewController;
@end

@implementation AnotherViewController

@synthesize rootViewController;

- (void)someMethod {
    // set the data was added flag, so the rootViewController knows to scroll to the bottom of the tableView to show the new data
    self.rootViewController.dataWasAdded = YES;

    // if the user came in via a search result, make the search controller's tableView go away
    self.rootViewController.searchDisplayController.active = NO;
}

If that's not a good idea, can anybody explain why?

In the code above, I know I could have used a protocol/delegate to handle the same thing - and I'm guessing I probably should. However, none of the books or other materials I've read has really discussed this.

The reason I'm asking is that I'm in the process of making my app universal, and using a UISplitViewController I've noticed that I need to often update my "master view" as the user makes changes in the "detail view". So, I took what seemed the easy route and started setting UIViewControllers as properties... but I'm experiencing some hard to track memory leaks and occasional crashes. I read something about "circular references", and wonder if that could be part of the issue (I do have a couple of places where UIViewControllers are set as properties of one another).

Thanks for any insight, or pointers to reference materials that cover this.

I'd avoid making a habit of this as there are better safer alternatives. Using a protocol/delegate is the preferred Apple way of managing data across classes. You can also set up NSNotifications to send/trigger data/events from one class to another. Key Value Observing (KVO) is also a decent way to listen in for changes.

In MVC structuring, the child views and downstream controllers really should have no idea (aka, keeping references) of their parents. It should always work the other way around where the parents manage and keep track of the children.