The instance variables for an ARC-compiled class will be destroyed +at some point after control enters the dealloc method for the +root class of the class. The ordering of the destruction of instance +variables is unspecified, both within a single class and between +subclasses and superclasses.
+ +Rationale: the traditional, non-ARC pattern +for destroying instance variables is to destroy them immediately +before calling [super dealloc]. Unfortunately, message +sends from the superclass are quite capable of reaching methods in the +subclass, and those methods may well read or write to those instance +variables. Making such message sends from dealloc is generally +discouraged, since the subclass may well rely on other invariants that +were broken during dealloc, but it's not so inescapably +dangerous that we felt comfortable calling it undefined behavior. +Therefore we chose to delay destroying the instance variables to a +point at which message sends are clearly disallowed: the point at +which the root class's deallocation routines take over.
+ +In most code, the difference is not observable. It can, however, +be observed if an instance variable holds a strong reference to an +object whose deallocation will trigger a side-effect which must be +carefully ordered with respect to the destruction of the super class. +Such code violates the design principle that semantically important +behavior should be explicit. A simple fix is to clear the instance +variable manually during dealloc; a more holistic solution is +to move semantically important side-effects out of +dealloc and into a separate teardown phase which can rely on +working with well-formed objects.