Segue between view controllers using NIB files

Your code is fine. I understand that it feels strange to instantiate UINvagationController where you only need custom view controller, but this is how it's done in UIKit.

You actually don't need to keep a reference to this navigation controller in your HomeViewController. You better keep reference to StackTable and Create view controllers.

- (void)didReceiveMemoryWarning {
    [super didReceiveMemoryWarning];
    // Dispose of any resources that can be recreated.
}

This is repeated through all of your view controllers. I don't blame you too terribly much, because I know it's something that Xcode pre-populates whenever you create a new UIViewController subclass, and it's extraordinarily silly. I've never written a single line of code in this method. I know what it is, and what it's for, but for a lot of development, you'll never need this method, so I'm not sure why Apple insists on generating it for you.

Anyway, any time you have a method, and within the method, the only thing that happens is a call to the super implementation of that method, we can simply not include the method. So, let's just delete it. And get in the habit of deleting this one every time.

It doesn't effect performance to delete it or leave it... it just clutters up the source file. And with that said, we can also delete viewDidLoad from the first class (it just calls to [super viewDidLoad];).

@interface HomeViewController : UIViewController

- (IBAction)goToStack:(id)sender;

- (IBAction)goToCreate:(id)sender;

@end

We've exposed these IBAction methods in our .h file. There's really no reason to do this at all. No other class should be calling these methods. These methods should only be called by the action we've hooked up to it (i.e. pressing a button). Likely, you created these via Ctrl+Dragging from your NIB file to the .h file. We can instead change the assistant editor to show us the .m file rather than the .h and Ctrl+Drag from the button to the @implementation section to just create the method straight in the .m without exposing it.

@interface HomeViewController ()

@property (strong, nonatomic) UINavigationController *navigationController;

@end

The UIViewController class already has this exact property actually, so we don't need this at all.

[super initWithNibName:@"HomeViewController" bundle:nil];

We should specify the bundle we're loading the nib from. By passing nil to this method, the implementation assumes your nib is in the main bundle. Most of this time, this will probably be the case, but passing nil is just lazy. However, what should always be the case is that our nib should be in the same bundle as our .h and .m files for that class. So instead of passing nil, we should do this:

NSBundle *bundle = [NSBundle bundleForClass:[self class]];
[super initWithNibName:@"HomeViewController" bundle:bundle];

Now, as to your primary concern of the navigation controller. What we're doing is indeed a little strange.

A UINavigationController object is a subclass of UIViewController. One of the properties of a UINavigationController is the viewControllers property. This is its navigation stack essentially.

We have two actions with a navigation controller--pushing and popping.

We start with a navigation controller and its root view controller. We can add to the navigation controller's navigation stack by "pushing" new view controllers onto the stack. The navigation controller keeps track of every view controller that's on the stack though in its viewControllers property. The key here is that we can then "pop" one of these view controllers off of the stack, and the navigation controller takes care of presenting the next highest view controller remaining in the stack.

Think of it like a deck of cards. We start with the AceOfSpadesViewController card face up on the table. We push a button on that view and that pushes a new card, the KingOfDiamondsViewController onto the stack. Then we push another button on this view controller in order to go back to where we came from, and the KingOfDiamondsViewController is "popped" off the stack.

So for your setup, realistically, it is the HomeViewController which should be the root view controller of a navigation controller, then, in order to push a new view controller onto the navigation stack, we'd rewrite goToCreate: to look something like this:

- (IBAction)goToCreate:(id)sender {
    // self.navigationController will already be a reference to the nav controller we're embedded in
    NSBundle *createBundle = [NSBundle bundleForClass:[CreateViewController class]];
    CreateViewController *createViewController = [[CreateViewController alloc]initWithNibName:@"CreateViewController" bundle: createBundle];
    [self.navigationController pushViewController:createViewController animated:YES];
}  

And in the CreateViewController, when we're done there and ready to "pop" back to whatever previous screen we came from:

- (void)cancel {
    [self.view endEditing:YES];
    [self.navigationController popViewControllerAnimated:YES];
}

There are two other ways of popping backward on a navigation controller as well. The above method just removes the top-most view controller from the navigation stack.

We can also call the method popToRootViewControllerAnimated: which will remove everything except the root view from the navigation stack, which is very useful if we need to quickly get back all the way to the "home" screen.

And you might rarely need to use popToViewController:animated:, which accepts a UIViewController reference, and if that UIViewController object is in the stack, the navigation controller removes everything that is on top of the top-most instance of this object from the navigation stack.

As one final note, you'll notice I changed:

[self.myTextView resignFirstResponder];

to

[self.view endEditing:YES];

If we ever have more than one view that is editable, our method will quickly become clogged up with a lot of resignFirstResponder calls. endEditing: recursively calls resignFirstResponder on all of the subviews (and subviews' subviews).

But I'm pretty sure this isn't actually needed either way. When the view controller is dismissed, then any of its subviews can no longer be first responder any more and the keyboard should go away on its own.