I got the answer from google group and followed his suggestion, it works:

From Sukima: I believe (although I have no real idea) that what these applications like skype and Beejive are doing is when view A wants view C it will message your UITabBar to move to the chats tab then push in the detail view C. This is actually better because then the user will see that the view has changed via the fact that the tabbar has changed highlights. from: I further read the stackoverflow thread. I understand now what your asking.

Your going to find this hard to implement largely because this is a bad UI design and the API does not support it.

You user will expect a back button to take them "back" to the previous view just as in every other app they use. Going to any other view will confuse them all the more so because it isn t a hierarchy but a loop. Users will sometimes go B-->C-->B but other times, A-->C-->B-->C. (How do they get back to A?)

Instead of a back button in C, you should have a button on the right hand side that always takes you to B regardless of how you got to C. The same button in the same context should always produce the same result. Users shouldn t have to remember what invisible mode they are in to predict what action a button will have.

Edit01:(Response to comments below)

(This is all off the top of my head so take it with a grain of salt.) You will need to abandon using the navigation controller and instead manage the views yourself. You will need to swap the views out via the tabbar by substituting the C view for the A and B views in each tab s view property.

I think you will have to start with master view that is invisible and then add the tabbar to that. In the master view controller, create attributes/outlets for each view. In each view, have an attribute/outlet linked to the master view controller. Then have the "back button" (which I strongly suggest you label "Chats") of C view call method in A and B that then calls a method in the master view controller that (1)removes the C view from either tab A or tab B (2) switches the tab to the B tab and then (3) loads view B into tab B.

I can t emphasis how ungainly I think this design is. It doesn t matter if other apps use it. In my experience major companies are more likely to make interface mistakes because their marketing departments want the UI to look unique.

By comparison, look at how the phone app handles the same situation. No matter which tab you use to make a call, favorites, contacts, keypad etc, you still come back that tab s view when the call is done. If you want to make a call with another method, you just hit the appropriate tab.

Ignore the bad example of others. Why spend so much time and effort trying to reproduce someone else s mistake?

You ll always wind up going back to the view that called pushViewController

Could you have A send B a message that causes B to call pushViewController?
I may not understand your architecture, but I believe that would work.

If you really want to do this you could create a method in B that pushes C then push B from A (without animation) and call the method that pushes C. Of course when you pop C to B, A will still be under it.