<p>When I've registered an object <strong>foo</strong> to receive KVO notifications from another object <strong>bar</strong> (using addObserver:...), if I then deallocate <strong>foo</strong> do I need to send a <code>removeObserver:forKeyPath:</code> message to <strong>bar</strong> in -dealloc?</p>

[{'answer_id': 14054, 'author': 'Chris Hanson', 'author_id': 714, 'author_profile': 'https://Stackoverflow.com/users/714', 'pm_score': 6, 'selected': True, 'text': "<p>You need to use <code>-removeObserver:forKeyPath:</code> to remove the observer before <code>-[NSObject dealloc]</code> runs, so yes, doing it in the <code>-dealloc</code> method of your class would work.</p>\n\n<p>Better than that though would be to have a deterministic point where whatever owns the object that's doing the observing could tell it it's done and will (eventually) be deallocated.  That way, you can stop observing immediately when the thing doing the observing is no longer needed, regardless of when it's actually deallocated.</p>\n\n<p>This is important to keep in mind because the lifetime of objects in Cocoa isn't as deterministic as some people seem to think it is.  The various Mac OS X frameworks themselves <strong>will</strong> send your objects <code>-retain</code> and <code>-autorelease</code>, extending their lifetime beyond what you might otherwise think it would be.</p>\n\n<p>Furthermore, when you make the transition to Objective-C garbage collection, you'll find that <code>-finalize</code> will run at very different times — and in very different contexts — than <code>-dealloc</code> did.  For one thing, finalization takes place on a different thread, so you really <strong>can't</strong> safely send <code>-removeObserver:forKeyPath:</code> to another object in a <code>-finalize</code> method.</p>\n\n<p>Stick to memory (and other scarce resource) management in <code>-dealloc</code> and <code>-finalize</code>, and use a separate <code>-invalidate</code> method to have an owner tell an object you're done with it at a deterministic point; do things like removing KVO observations there.  The intent of your code will be clearer and you will have fewer subtle bugs to take care of.</p>\n"}, {'answer_id': 34513, 'author': 'Barry Wark', 'author_id': 2140, 'author_profile': 'https://Stackoverflow.com/users/2140', 'pm_score': 3, 'selected': False, 'text': "<p>A bit of extra info that I've gained by painful experience: although NSNotificationCenter uses zeroing weak references when running under garbage collection, KVO does not. Thus, you can get away with not removing an NSNotificationCenter observer when using GC (when using retain/release, you still need to remove your observer), but you must still remove your KVO observers, as Chris describes.</p>\n"}, {'answer_id': 65336, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 2, 'selected': False, 'text': '<p>Definitely agree with Chris on the "Stick to memory (and other scarce resource) management in -dealloc and -finalize..." comment.  A lot of times I\'ll see people try to invalidate NSTimer objects in their dealloc functions.  The problem is, NSTimer retains it\'s targets.  So, if the target of that NSTimer is self, dealloc will never get called resulting in some potentially nasty memory leaks.  </p>\n\n<p>Invalidate in <code>-invalidate</code> and do other memory cleanup in your <code>dealloc</code> and <code>finalize.</code></p>\n'}]
['https://Stackoverflow.com/questions/13927', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/1512/']