shouldPerformSegue and tab bar controller

When you use a tab bar view controller, you shouldn't segue that controller. Rather, you should segue the individual tab controllers (if you're transitioning to replacement controllers within a tab), or switch tabs (if you're transitioning between tabs).

So your validation code was probably in the right place, but your segues were probably in the wrong place in the storyboard (i.e. on the tab bar controller instead of the individual tabs' controllers), if that makes sense.

(Or are you trying to validate when switching between tabs? Or are you actually trying to segue away from the tab bar controller as a whole, which is kinda against the human interface guidelines?)

>> The code compiles etc., but the override never executes.

If you're going to override this (although I don't think that's what you actually want to do in this case), make sure you give the storyboard scene's view controller object the proper subclass, using the Identity inspector. The class popup at the top should show your subclass as a choice.

>I have redesigned a view so that its functionality is now split between 3 sub-views of a tab bar controller.

Does that mean you have have a single UITabBarController and three UINavigationControllers (one per tab)?

> is something spepcific to tabBarControllers that I might be missing?

About tBC, see the docs: https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/ViewControllerCatalog/Chapters/CombiningViewControllers.html

Combined View Controller Interfaces

You can use the view controllers that the UIKit framework provides by themselves or in conjunction with other view controllers to create even more sophisticated interfaces. When combining view controllers, however, the order of containment is important; only certain arrangements are valid. The order of containment, from child to parent, is as follows:

• Content view controllers, and container view controllers that have flexible bounds (such as the page view controller)
• Navigation view controller
• Tab bar controller
• Split view controller

Brilliant! Thanks very much, all sorted now.

Sorry, I marked your answer correct without noticing that the tab buttons are now no longer visible. I was a bit excited to get the fix!

In context: There is a home page view, this calls a table view and then this the tab bar controller at the detail record. Is this for some reason abusing the tab bar controller? Or is there in fact a way to show the tab buttons?

Thanks again for you’re help.

>> There is a home page view, this calls a table view and then this the tab bar controller at the detail record. Is this for some reason abusing the tab bar controller?

To the best of my knowledge, it is. The idea is, if your app uses a tab bar controller at all, that same tab bar should be visible all the time, so the user doesn't have to figure out how to get the tabs back when they're not there. Reasonable exceptions, IMO, include things like:

— You have a login page that's always displayed without tab bar first (when the user is not logged in), then the app transitions to a fully-tabbed UI.

— You have a split view controller at the top level, and you want a tab bar controller as the "detail" side of the split. In this case, the tab view is always visible, so the user is not troubled by any apparent disappearance.

However, this is UI "abuse". I don't think it has anything to do with why the buttons are disappearing here.

It's a bit hard to diagnose what might have gone wrong, since it's hard to describe a storyboard configuration in a post. You might have a configuration that tab bar controllers don't support, or perhaps it's just an autolayout issue where the buttons are present but off the bottom of the screen. You could try using Xcode's view debugger to deconstruct your view hierarchy, and see what's actually there.

Regard the UI issues, I don't know what to advise, because the best setup depends on intimate details of what your app is for. It might make sense to put the table view in the "master" pane of a top-level view controller. It depends on factors like how much time the user spends in each part of your UI.

Thanks again, I’ll have another bash at it today. I think the issue relates to how the tab bar was constructed. In the article linked by KMT it states that a navigation controller should be included with the views that are to be managed by the tab (when they are embedded in the tab bar). . I think I need to read up more on the UI guidelines. I’ve been building desktop apps for years and always used tab controls to split up wider data sets into logical groups. It never occurred to me that a tab bar controller would be inappropriate for this scenario... old age I guess. Thanks again for your time, much appreciated :)

I don't see anything that says you should use a navigation controller in the tabs. It says that if you want to present information via a navigation controller, it should be in one tab of the tab bar controller (rather than the other way around — it isn't recommend to use a navigation controller to navigate down to a tab bar controller).

I also see that I misspoke earlier. The normal configuration involving a split view controller and a tab view controller together — the document says — is to put the tab bar controller inside the split view controller. That makes sense if the "master" side of the split is available whatever tab is currently displayed. However, there are some apps where it makes sense for only one tab to be split. Even some of Apple's apps (appear to) do this. For example, in the iOS 11.2 version of Pages on iPad, there are two tabs, but there is a split view in only one of them. This appears to be using a split view controller (because of the way the master side becomes slide-out in portrait mode), but it's embedded in a tab in "violation" of the human interface guidelines.

>> old age I guess

Not that. iOS is just different from the desktop. On the desktop, it's relatively easy to show containment of a tabbed view inside a more complex hierarchy. On iOS, tab bars are designed to be permanently at the bottom of the screen, otherwise there are no clues where to find it if it disappears (without a UI redesign that ***** up screen real estate).

Of course, you can still present modally over a tab bar controller. If your main view, or your table view "master" view, needs to be shown only briefly, that might be a way to leave the tab bar controller at the top level, but cover it with a dismissable view when needed.

> but it's embedded in a tab in "violation" of the human interface guidelines.

You mean the old admonition that SVC should always be root?