1) You can’t just use segue.destinationController if you are using a VC that is wrapped in a navigation controller.  You must dig into the controller hierarchy and find it.  For example:

       UIViewController* viewController = nil;

        if ([[segue destinationViewController] isKindOfClass:[UINavigationController class]]) {             UINavigationController* navController = [segue destinationViewController];             viewController = (UIViewController)[navController topViewController];         } else {             viewController = (UIViewController)segue.destinationViewController;         }

This is very troublesome to me and just doesn’t smell right.

2)  There is no automatic prepareForSegue for an accessory view action on a table view cell.  You have to implement this yourself.  So much code…

3)  There is a reproducible flaw I discovered with an overrelease on a UISearchViewController if you create one as part of your storyboard and a low memory situation occurs.  So much for ARC.    If you’d like an example project on this, fell free to hit me up.

4)  If you are doing a Universal app, you must keep the segues in sync. If you change a segue name in the iPhone version, you must make a corresponding change in the iPad version, else use branching logic.  Having to duplicate or keep these sorts of things in sync really rubs me the wrong way.  The problem is that I can’t think of a good alternative.

5)  Popovers on iPad are the worst.         a)  You cannot programmatically set the anchorView nor the anchorRect without using a private API.                 i) This is important to be able to do when you may not create everything through IB.         b)  The expected order of operations in a popover differ from other segue transitions:                ii) The view is loaded first, then the prepareForSegue call is made.                ii)  In other segue transitions, prepareForSegue is called first, then the view is loaded.                iii)This is detrimental to the design of your ViewControllers because some UI modifications may have been expected to be made based on models you set in prepareForSegue, thus causing you to write more code to overcome the difference in behavior…

The bloated prepareForSegue is a bad smell, in the Refactoring sense. And I would have expected that the solution would be the same as in Refactoring: multiple UIStoryboardSegue subclasses. Unfortunately the inventors of storyboards didn’t think of that, so prepareForSegue is sent to the source view controller and we end up with spaghetti.And string identifiers – could anything be less maintainable, more error-prone? And they didn’t even think to show the identifier in big letters in the canvas part of the storyboard editor?Plus, the whole prepareForSegue architecture is just wrong; instead of letting the destination view controller specify its own designated initializer, so that it must be given the right data in order to be instantiated and can then do with that data what it likes, the source view controller winds up having to know the inner mechanisms of the destination view controller and set its properties or call its methods. That is not correct OOP design. Storyboards feel like a sop to beginners who don’t understand view controllers, but I don’t think they actually make life better for them or for anyone else. I do understand view controllers and I’m very nimble with them; storyboards just get in my way.Nevertheless, the basic idea is intriguing, especially the insight that the whole repertoire of things that must happen as a view transition takes place can be clumped into an object (a segue).

Storyboards seem suited for those new to cocoa, allowing them to focus on the ViewController actions and not have to bother with the particulars of App delegate up front. Also, I’ve used Storyboards with designers to visually place interface elements, allowing them partial exposure to the development process. But as you mentioned, these are simply too inflexible for any kind of advanced use. 

There’s nothing intrinsically wrong with UIStoryboard. I think if Apple improves upon it , it could be really useful. I just don’t think the current version of it is ready.