As of iOS 6, Apple thought Unwind Segues would be added to their layout/views. What this means is, when you're on the 7th view of a stack, you can pop back to any other one. For those of you pure OO fans (like myself), I cringed a little. I cringed even more when I learned these also work with pop-ups.

Why would a modal on top of a stack know about the Nth view before?

I'm a big fan of OO because when you stick to its principles, you don't get spaghetti. And once you have a complex set of modals that are shared among multiple navigation controllers, these Segues begin to cluster into a bunch of lines on your storyboard that effectively don't enhance the navigation (as compared to an Obj-Oriented solution), but take up space on your Storyboard.

If you change a parent view, you immediately break the unwind segue and have to edit all the code that pointed to it, which is one of the exact same reasons we avoid doing this in code.

This has made me cringe for awhile, and I don't see any questions that bring this up in relation to views.

  • 4
    when you stick to its principles, you don't get spaghetti. -- That is by no means assured. Trust me, you can still f**k it up. Mar 5, 2020 at 2:16
  • Some people get 10 layers of lasagne instead of spaghetti.
    – gnasher729
    Mar 5, 2020 at 14:40
  • I have seen many arguments against OO and all of them gave examples that told me the poster didn't understand OO. One person wound up where he would've been if he thought about his architecture from the beginning, then his conclusion said "Thus OO is bad." I use Andre LaMothe as an example of good OO. The games industry has been simulating reality for years, using database, graphics, sound, video, scenegraphs, and network sockets, all at once. I trust the patterns they've tested over the last 4 decades, b/c reduced bugs, increased feature change ability
    – Stephen J
    Mar 5, 2020 at 18:38

3 Answers 3


Immutability is a principle in more than OOP.

Isolation is a principle in more than OOP.

Reaching out and touching whatever you feel like is a bad idea for the same reason pouring glue over the gears of a clock is a bad idea. Sure it holds the clock together but that only works well now. Eventually you want things to be able to move.

Functional programmers will complain about this by talking about side effects. They’ll insist on avoiding them until the last minute.

OOP programmers will complain about this by talking about the service locator pattern and tell you to instead use pure dependency injection to make your dependencies explicit.

Lazy programmers will keep doing it anyway because they know by the time anyone catches them at it they’ll already be at a different Job.

Rather than rail against the inevitable learn to refactor. Rather than preach ideals show how they can be followed. Rather than ask people to have faith show them the real benefits.

Either that or update the ol’ resume.

  • There's nothing wrong with refactoring and being willing to refactor. Something is wrong when you couple your code so tightly for nothing more than a temporary convenience that bloats the view and the code while winding it tightly. UNLESS that navigation will never change, and you know this. Not one team wouldn't point this out and say "Rewrite this to use the delegate pattern" in code, regardless of the patterns used in that team, that I've been on. I see the point you're making, but I don't believe it's relevant to this question
    – Stephen J
    Mar 5, 2020 at 18:04

The primary goal is not that your software follows some principles, but that the software provides the user experience that it should provide.

If your user interface designer declares - after thoughtful analysis - that the user should go from a three times nested inner screen directly to the outmost screen, then that’s what your code needs to do. If you do this with code that goes against your principles, tough.

Apple has created this method because some people, in some situations, want to go straight to a specific screen sometimes. Much better than doing it by hand because you only get one animation, and your code stays unchanged if intermediate levels change.


Child objects should be able to get access to their parents.

Sure, from a philosophical point of view, they shouldn't, every piece of data should be nicely partitioned, etc. Unfortunately the real world has a tendency to bulldoze over every 'elegant' model without a second thought. So, if you make something with airtight, but abstract OO principles, you will likely make something useful for only a very small subset of problems, and make impossible everything else.

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

That's not to say you should abandon all reason, and make a tangled ball of mud and spaghetti. But, sometimes real-world problems need bits of zip-ties and duct tape in certain places, because no model will ever match the complexity of the real world.

if you make the language impossible to do stupid things in, you'll also make it impossible to do clever things

  • As much as I disagree with your premise, I love how your 2nd quote describes Swift. I write iOS apps using custom views, such that I don't write code for new screens if the feature has been used before. It's very extensible, and very fast... without dependencies for most things even. I am sorry you had experiences that made you believe such about OO... whoever taught you must not've known their field.
    – Stephen J
    Mar 5, 2020 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.