Abolish Retain Cycles in Swift with a Single Unit Test

Can’t believe we’re still dealing with this in 2017? Well, that makes two of us. While retain cycles are easy to fix, they’re also hard to spot while eyeballing a codebase. Recently, I’ve found that a single unit test can provide solace. With just a few lines of code, it runs continuously as you make changes, all the while verifying you haven’t introduced any new memory leaks.

It’s a simple snippet, but I’ll walk you through it.

The test function makes use of XCTest’s asynchronous expectation system to pick up whether your class’s deinit function gets called. The subclassing trick you see there is needed because Swift doesn’t support reflection yet. The subclass tracks the deinit call by adding that deinitCalled closure.

The test works by allocating the instance on the main queue, while immediately deallocating it on the background queue. This triggers the deinit call, and the test succeeds.

If the test fails due to the 5-second timeout, this is your cue. You have just found a retain cycle! I’ve found it helps to run this test throughout the development process. The delta between code changes remains small enough to pick up where you forgot a [weak self] or [unowned self].

P.S. I was unable to figure out a way to make the test function generic, so I’ve been copy-pasting it around. I realize this is not ideal. However, I find it’s not a big deal because we’re dealing with test code, not actual app code.

3 thoughts on “Abolish Retain Cycles in Swift with a Single Unit Test”

  1. I really like this way of testing for reference cycles, automating the process is always good!
    Can you give me an example of where this test will fail i.e catches a retain cycle, thanks

    1. Hi Izzy,

      Sure! Consider the following (contrived) example. The most common retain cycles can be triggered by accessing some property on self from within a closure, which itself is stored on self. The test below does exactly this and will fail due to a timeout when run on causesRetainCycle() because it implicitly captures self strongly (by omitting the capture list).

      doesntCauseRetainCycle() succeeds because it explicitly captures self as weak (see [weak self] in statement).

      class ClassWithRetainCycle {
      var someProperty = false
      var someAction: (()->Void)?

      init() {}
      func causesRetainCycle() {
          someAction = {
              self.someProperty = true
      func doesntCausesRetainCycle() {
          someAction = { [weak self] in
              self?.someProperty = true


      class RetainCycleTestTests: XCTestCase {
      func testCleanup() {
      // Extend your class inline in order to add closure property deinitCalled,
      // which indicates when/if your class’s deinit() gets called
      class ClassUnderTest: ClassWithRetainCycle {
      var deinitCalled: (() -> Void)?
      deinit { deinitCalled?() }

          // Set up async expectation, which causes the test to wait for `deinitCalled`
          // to be called
          let exp = expectation(description: "exp")
          // Initialize the class
          var instance: ClassUnderTest? = ClassUnderTest()
          // Set up up the `deinitCalled` closure, making the test succeed
          instance?.deinitCalled = {
          // On a different queue, remove the instance from memory,
          // which should call `deinit`, in order to clean up resources.
          // If this doesn't cause `deinit` to be called, you probably have a
          // retain cycle
          DispatchQueue.global(qos: .background).async {
              instance = nil
          // Wait for max. five seconds for the test to succeed, if not,
          // you may have a memory leak due to a retain cycle
          waitForExpectations(timeout: 5)


Leave a Reply

Your email address will not be published. Required fields are marked *