I think it’s just generally good practice to call the base class’ method when you override an ‘event handler’ in a sub-class, especially these build-up and tear-down type events.
Even if the super class does nothing in that method right now they may add some logic to it in a later release. If you call it when you have finished your tear-down you will be in good shape if they ever add something that needs to happen on unload.
The other question is whether you should call the super class’ code before or after your code. I thought conventional wisdom is that if you are building something up (loading or creating) you call the super class first so it can do any underlying setup before you do your thing. Conversely if the event is a tear-down type event you would do your thing first then call the super class last. However, the example given calls the base first in the unload method. My concern with this would be that the base may un-allocate some reference that I’m going to need during my tear-down.
Often it isn’t immediately obvious what the right thing to do is. A lot of framework vendors will include notes in the documentation about when you should call the super class in an overridden method. It looks like the Apple documentation is a little inconsistent on this - there’s nothing mentioned for viewDidLoad or viewDidUnload, but in viewDidDisappear the documentation says “If you override this method, you must call super at some point in your implementation.”
As a newbie to iOS and Apple platform development in general, I’d love to know if there are any best practices around this that can be applied consistently.