dealloc in Swift

Question

I would like to perform some cleanup at the end of a view controller's life, namely to remove an NSNotificationCenter notification. Implementing dealloc results in a Swift compiler error:

Cannot override 'dealloc' which has been marked unavailable

What is the preferred way to perform some cleanup at the end of an object's life in Swift?

score 338 · Accepted Answer · answered Aug 26 '14 at 04:12

deinit {
    // perform the deinitialization
}

From the Swift Documentation:

A deinitializer is called immediately before a class instance is deallocated. You write deinitializers with the deinit keyword, similar to how intializers are written with the init keyword. Deinitializers are only available on class types.

Typically you don’t need to perform manual clean-up when your instances are deallocated. However, when you are working with your own resources, you might need to perform some additional clean-up yourself. For example, if you create a custom class to open a file and write some data to it, you might need to close the file before the class instance is deallocated.

score 46 · Answer 2 · edited Jun 20 '20 at 09:12

deinit {
    // perform the deinitialization
}

is the correct answer for Swift "dealloc".

However, it is good to point out new in iOS 9 that NSNotificationCenter no longer needs to be cleaned up!

https://developer.apple.com/library/content/releasenotes/Foundation/RN-FoundationOlderNotes/index.html#X10_11Notes

NSNotificationCenter

In OS X 10.11 and iOS 9.0 NSNotificationCenter and NSDistributedNotificationCenter will no longer send notifications to registered observers that may be deallocated. If the observer is able to be stored as a zeroing-weak reference the underlying storage will store the observer as a zeroing weak reference, alternatively if the object cannot be stored weakly (i.e. it has a custom retain/release mechanism that would prevent the runtime from being able to store the object weakly) it will store the object as a non-weak zeroing reference. This means that observers are not required to un-register in their deallocation method. The next notification that would be routed to that observer will detect the zeroed reference and automatically un-register the observer. If an object can be weakly referenced notifications will no longer be sent to the observer during deallocation; the previous behavior of receiving notifications during dealloc is still present in the case of non-weakly zeroing reference observers. Block based observers via the -[NSNotificationCenter addObserverForName:object:queue:usingBlock] method still need to be un-registered when no longer in use since the system still holds a strong reference to these observers. Removing observers (either weakly referenced or zeroing referenced) prematurely is still supported. CFNotificationCenterAddObserver does not conform to this behavior since the observer may not be an object.

but note the points below about strong references, so you may have to worry about cleanup anyway...?

Unless the notification block has a strong reference, then you must remove the observer. — TigerCoding, Apr 22 '16 at 16:59
+1 for not having to clean up observers. Important to know! I make all capturing references weak so never have to deal with this. — n13, Oct 26 '16 at 06:03
Notification blocks always seem to be strongly referenced according to the documentation. So: If you are using blocks to handle your notifications you _have_ to unregister for them inside deinit. — marsbear, Nov 30 '16 at 14:34

score 24 · Answer 3 · edited Aug 28 '19 at 06:29

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Deinitialization.html

Swift automatically deallocates your instances when they are no longer needed, to free up resources. Swift handles the memory management of instances through automatic reference counting (ARC), as described in Automatic Reference Counting. Typically you don’t need to perform manual clean-up when your instances are deallocated. However, when you are working with your own resources, you might need to perform some additional clean-up yourself. For example, if you create a custom class to open a file and write some data to it, you might need to close the file before the class instance is deallocated.

Class definitions can have at most one deinitializer per class. The deinitializer does not take any parameters and is written without parentheses:
deinit {
    // perform the deinitialization
}

score 2 · Answer 4 · answered Sep 30 '18 at 07:09

removing observer is required before deallocation otherwise crash would happen. It can be done using

deinit {
    // perform the deinitialization
    print("deinit")

    removeObserver(self, forKeyPath: kSelectedViewControllerKey, context: nil)
    removeObserver(self, forKeyPath: kSelectedIndexKey, context: nil)

}

score 0 · Answer 5 · answered Oct 12 '20 at 11:16

If you really want to remove something when view goes out of scope and start when in scope, I would suggest let's do it in the controller's didAppear and didDisappear method. Even NSNotificationCenter also can remove and added back when the view appears/disappear.

score -2 · Answer 6 · answered Jan 29 '18 at 11:53

-2

Be careful when calling a method in other class from deinit it will probably end up in crash

answered Jan 29 '18 at 11:53

Jeba Moses

641
5
21

1

Downvoted as that should not be necessarily the case. From [ref. docs](https://docs.swift.org/swift-book/LanguageGuide/Deinitialization.html): *Because an instance is not deallocated until after its deinitializer is called, a deinitializer can access all properties of the instance it is called on and can modify its behavior based on those properties (such as looking up the name of a file that needs to be closed).* – superjos Dec 14 '18 at 17:10

dealloc in Swift

6 Answers6

Linked