In Etude (etudeapp.com), I made a custom nav bar class and a custom back button control, and I just hijack -pushNavigationItem:animated: in the custom nav bar.
The way I do it is call [self.navigationItem setHidesBackButton:YES animated:NO]; then create a new UIBarButtonItem using -initWithCustomView: (passing in a UIButton subclass I wrote to render a back button) and set the left-side button of the navigation bar to this new button. To implement the "go back" behavior I just use the regular target-action functionality of my UIButton and manually call -popViewControllerAnimated.
For what it's worth, I really think it damages the ecosystem when apps fake standard SDK classes and make them do strange things, like what Instagr.am is doing. Those standard classes are there and have limitations for a reason.
I really don't like what instagr.am has done to the UINavigationBar and there's a lot of applications out there that tries to hijack known standards to make them crazy stuff.
I like to think that its a decision that self-moderates. If its an improvement, it contributes to the success of the app and it may persist. If not, it may contribute to the failure of the app and will eventually disappear. We're so early in the evolution of mobile/touch-based applications, and personally I welcome developers trying new things and stretching the boundaries to see where there's room for improvement.
I agree. It's just that for most cases, it's not a matter of improving. It's a matter of being stubborn about your own idea. Look at twitter's app for example, they keep their design very close to the standard UIKit's HIG while improving some aspects(pull to refresh is a great example)
The title is a tiny bit misleading. The one on the article is better.
I was confused at first because he's reinventing UINavigationBar, not custom back buttons - back buttons are occasionally part of that reinvention, however.
