The following applies to the iOS world:
To avoid potential problems with calling methods or even property setters from the dealloc method you could try the following approach, which is based on preprocessor macros entirely – slightly inconvenient, but safer:

1. Define a macro that, given a flag and the name of a property, either calls the property setter to set the property to nil, or, based on a naming convention, releases – and sets to nil – the underlying ivar:

#define RELEASE_PROPERTY(useSetter, propName) ((useSetter) ? (self.propName = nil) : ([_##propName release], _##propName = nil))

Note that this macro relies on the naming convention of naming the ivar that backs a property the same as the property, prefixed with “_”.

2. In lieu of defining a releaseOutlets *method*, define a *macro* in each class that ‘bundles’ all property-release statements, e.g.:

#define releaseOutlets(useSetters) \
RELEASE_PROPERTY(useSetters, textField); \
RELEASE_PROPERTY(useSetters, someOtherProperty); \
RELEASE_PROPERTY(useSetters, yetAnotherProperty)

This is slightly inconvenient, in that each inner line must end in \ and in that you get no syntax coloring.

3. Call the macro
- from viewDidUnload:
releaseOutlets(YES);
- from dealloc:
releaseOutlets(NO);
That way, no methods are called from the dealloc method.

Finally, because it tripped me up is not obvious from the method names:
- viewDidUnload is ONLY called in LOW-MEMORY conditions.
- dealloc is typically NOT called when the APPLICATION AS A WHOLE terminates.