Retain cycles in SwiftUI

The one rule, and why the screen is exempt

An object is freed when nothing holds it any more. It gets stuck in one of two ways: something it holds leads back to it (a retain cycle), or something that never ends holds it (a running Task, a repeating Timer). Everything in this guide is one of those two.

A SwiftUI view is not an object and cannot be the owner in a cycle. It is a struct, and its body is a computed property — a getter that runs, returns a value, and keeps nothing:

// From the SDK's View protocol, shortened — not code to type
public protocol View {
    @ViewBuilder @MainActor @preconcurrency var body: Self.Body { get }
}

So reading your model in body holds it only for the length of that one call. The closures a view hands to Button, .onAppear or .task are kept — but SwiftUI keeps them, and releases them when the screen leaves. None of them belongs to your model. Here is a screen that names its model in every one of those places, with a weak probe on the model; the run puts it in a real window, shows it, and pops it the way a NavigationStack pops a screen:

import SwiftUI

@MainActor
@Observable
final class Model {
    var count = 0
    init() {
        probe.object = self
    }
}

/// body, a Button, .onAppear and a .task all name the model, and nothing writes [weak …]
struct CounterScreen: View {
    @State private var model = Model()
    @State private var note = ""

    var body: some View {
        VStack {
            Text("\(model.count) \(note)")
            Button("Add") {
                model.count += 1
            }
        }
        .onAppear {
            note = "shown"
        }
        .task {
            model.count += 1
        }
    }
}

Shown, popped, and asked

after the screen is popped, the model is freed

Now the same screen hands the model a closure. The closure never mentions the model — it sets the screen's own rareBird:

import SwiftUI

@MainActor
@Observable
final class Model {
    @ObservationIgnored var onRareBird: ((String) -> Void)?
    init() {
        probe.object = self
    }
}

struct SightingScreen: View {
    @State private var model = Model()
    @State private var rareBird = "none yet"

    var body: some View {
        Text("Rare bird: \(rareBird)")
            .onAppear {
                model.onRareBird = { name in
                    // really self.rareBird: the closure keeps a copy of the whole screen
                    rareBird = name
                }
            }
    }
}

Shown, popped, and asked

after the screen is popped, the model is still alive

Inside a view, rareBird means self.rareBird, so the closure captures self: a copy of the whole screen struct, and in that copy the @State box that holds the model. The model stores the closure, and that is the whole difference. model → closure → a copy of the screen → the model. Nothing SwiftUI keeps can be freed, because the model is not SwiftUI's to free.

How these runs are made

Every screen on this page is proven the same way, as a macOS program with the course's strict settings: the screen goes into an NSHostingView in a real window, a flag shows it and then takes it off the screen, and a weak reference to its model says whether anything still holds it. This is the rig behind each shownThenPopped, folded here in full — not code to type, but the whole of what the cards run:

import SwiftUI
import AppKit
import Observation

@MainActor
final class Probe {
    weak var object: AnyObject?
}

@MainActor let probe = Probe()

@MainActor
func freed() -> String {
    probe.object == nil ? "freed" : "still alive"
}

/// Whether the window shows the screen under test — the way a NavigationStack shows a screen, then pops it.
@MainActor
@Observable
final class Stage {
    var showing = false
}

struct Host<Screen: View>: View {
    let stage: Stage
    let screen: () -> Screen

    var body: some View {
        if stage.showing {
            screen()
        } else {
            Text("nothing on screen")
        }
    }
}

/// Puts the screen in a real window, lets it run, takes it off the screen, and says whether its model was freed.
@MainActor
func shownThenPopped<Screen: View>(_ screen: @escaping () -> Screen) -> String {
    let app = NSApplication.shared
    app.setActivationPolicy(.accessory)
    let stage = Stage()
    let window = NSWindow(contentRect: NSRect(x: 200, y: 400, width: 240, height: 120), styleMask: [.titled], backing: .buffered, defer: false)
    window.isReleasedWhenClosed = false
    window.contentView = NSHostingView(rootView: Host(stage: stage, screen: screen))
    window.orderFront(nil)
    let spin = { RunLoop.main.run(until: Date(timeIntervalSinceNow: 0.3)) }
    autoreleasepool {
        spin()
        // the screen appears: body runs, .onAppear and .task fire
        stage.showing = true
        spin()
        // the screen is popped: SwiftUI lets go of everything it kept
        stage.showing = false
        spin()
    }
    window.close()
    return freed()
}

So the rule, and the question to ask about any leak: start at the model and follow its stored properties. A view cannot even try to hold itself weakly — the compiler refuses [weak self] in a struct, and a card below shows the message. The rest of this guide is the ways a model ends up holding something that leads back to itself.

The model holds a closure that names itself

The commonest cycle: a model keeps a closure, and the closure names something that leads back to the model. It need not name the model directly — the callback above never did. With @Observable the fix is usually to delete the callback. Make the answer a property of the model and read it in body; there is no closure to hold, and Observation keeps the screen current on its own:

import SwiftUI

@MainActor
@Observable
final class Model {
    var rareBird = "none yet"                    // a property, not a callback: nothing to store
    init() {
        probe.object = self
    }
    func spotRareBird() {
        rareBird = "Waxwing"
    }
}

struct SightingScreen: View {
    @State private var model = Model()

    var body: some View {
        VStack {
            // body reads it; Observation updates the screen
            Text("Rare bird: \(model.rareBird)")
            Button("Spot a rare bird") {
                model.spotRareBird()
            }
        }
        .onAppear {
            model.spotRareBird()
        }
    }
}

Shown, popped, and asked

after the screen is popped, the model is freed

When the model really must keep a closure, the cycle is the classic one and has nothing SwiftUI about it. A helper the model owns — a camera, a location manager, a network client — calls back through a closure that names self:

import Observation

@MainActor
final class BirdCamera {
    var onSighting: (() -> Void)?
}

@MainActor
@Observable
final class Model {
    let camera = BirdCamera()
    var robins = 0
    init() {
        probe.object = self
    }
    func start() {
        camera.onSighting = {
            // the camera keeps this closure, the closure names self, self owns the camera
            self.robins += 1
        }
    }
}

The model owns the camera, the camera keeps the closure, the closure names self. The helper never has to know about the model; the closure carries the reference for it. The fix is [weak self] on that closure — the owner must not be owned back — and the cards run both versions. The loop can also run through more than one object: a list that builds rows, each row keeping an onTap closure that names the list, is list → rows → row → closure → list, and a card runs that too. Follow the stored properties all the way along, not just the first hop.

Three things that confuse the picture, each with a card: @ObservationIgnored keeps a property out of Observation and changes nothing about who holds whom; the compiler makes you write self. in an escaping closure on a class precisely so that you notice the capture; and a closure that does not escape — map, filter, forEach — needs neither self. nor [weak self], because it is gone when the call returns.

A task or timer that never ends

The second kind of leak holds the model without a cycle at all: work that never finishes. A running Task stays alive on its own and holds everything it names until it ends — and cancelling is a request the loop has to notice, which Task.sleep and Observations do. Written as Task { } in .onAppear and never cancelled, or stored on the model and "cancelled in deinit", a loop that never ends keeps the model for the life of the app.

The loop in the model, and the [weak self] trap

This matters most for the Observations loop — the iOS 26 way (lesson 18) to react to every change of what a closure reads. A model that starts one, names self in it, stores the handle and cancels it in deinit has written the leak in its most careful-looking form: deinit runs only once nothing holds the model, and the task does. The next step everyone takes is [weak self] — unwrapped once at the top, because an optional self is annoying inside a loop:

import Observation

@MainActor
@Observable
final class Model {
    var count = 0
    @ObservationIgnored var task: Task<Void, Never>?
    init() {
        probe.object = self
    }
    func listen() {
        task = Task { [weak self] in
            guard let self else {
                return
            }
            // this strong self lives until the closure ends — never
            for await _ in Observations({ self.count }) {
                self.heard()
            }
        }
    }
    func heard() {}
    deinit {
        task?.cancel()
    }
}

The loop starts, the owner lets go

the model is still alive

[weak self] only makes the capture weak. guard let self makes a new, strong self that lasts until the closure ends, and the closure ends when the loop ends, which is never. The strong reference moved down two lines. The fix is to keep self weak the whole way through — in the Observations closure too, or it holds the model between changes — and to unwrap inside the loop, for one pass:

import Observation

@MainActor
@Observable
final class Model {
    var count = 0
    @ObservationIgnored var task: Task<Void, Never>?
    init() {
        probe.object = self
    }
    func listen() {
        task = Task { [weak self] in
            for await _ in Observations({ [weak self] in self?.count }) {
                guard let self else {
                    return
                }
                // this strong self lives for one pass of the loop
                self.heard()
            }
        }
    }
    func heard() {}
    // and now it runs, and ends the loop
    deinit {
        task?.cancel()
    }
}

The loop starts, the owner lets go

the model is freed

Now nothing holds the model while the loop waits, deinit runs, cancels the task, and the loop ends. The question to ask about any [weak self] is not whether you wrote it but how long the unwrapped self lives.

A timer

A repeating Timer has the same shape: the run loop keeps the timer until it is invalidated, the timer keeps its closure, and the closure names the model. Invalidating is the only way out — a deinit that would invalidate it is waiting for exactly the thing it is meant to stop:

import Foundation

@MainActor
@Observable
final class Model {
    var ticks = 0
    @ObservationIgnored var timer: Timer?
    init() {
        probe.object = self
    }
    func start() {
        timer = Timer.scheduledTimer(withTimeInterval: 0.03, repeats: true) { _ in
            MainActor.assumeIsolated {
                // names self: the run loop keeps the timer, the timer keeps this closure
                self.ticks += 1
            }
        }
    }
}

Let the timer tick, then invalidate it

with the timer running, the model is still alive after 3 ticks
after the timer is invalidated, the model is freed

On a view: .task, and the Task nobody keeps

On a screen, .task is simpler than any of this. SwiftUI cancels it when the view leaves, Task.sleep throws on cancellation, and a loop that checks Task.isCancelled ends — so even a loop that would run forever lets go of the model with the screen. Write the same loop as Task { } inside .onAppear and nobody owns it: it is not a cycle, and it leaks just the same. Two cards run both, in a window. The one cost of .task is that it runs once per window — on a Mac or iPad with two windows open, the work runs twice.

Two more shapes, each with a card: a task that names the model and finishes is not a leak but a lifetime stretched — the model goes when the task ends; and a NotificationCenter block observer is an owner that never dies, so the token cannot be removed in a deinit that the block itself prevents — [weak self] in the block first, then an isolated deinit to remove the token in, or an Observations-style loop over notifications(named:) in a .task.

Cycles with no closure of yours

A closure is one way for a model to hold something that leads back, but not the only one. Two strong stored references are enough. The classic is a child that points at its parent:

import Observation

@MainActor
@Observable
final class Feeder {
    var birds: [Bird] = []
    init() {
        probe.object = self
    }
    func add() {
        birds = [Bird(feeder: self)]
    }
}

@MainActor
@Observable
final class Bird {
    var feeder: Feeder                  // strong, back to the parent that owns it
    init(feeder: Feeder) {
        self.feeder = feeder
    }
}

The parent owns the children, so the back-reference is the one to make weak: weak var feeder: Feeder?, nil on its own once the feeder is gone. Make both strong and neither is ever freed — a card proves it, and the next card fixes it. The same trap hides in a router that stores the next screen as a view: an AnyView holds the view struct, and a view struct is a value that can hold a reference — the router. Store which screen, as a value, and build the view in body when it is needed:

import SwiftUI

@MainActor
@Observable
final class Router {
    var next: AnyView?                  // a view, and the view holds the router
    init() {
        probe.object = self
    }
}

struct DetailsScreen: View {
    let router: Router
    var body: some View {
        Text("Details")
    }
}

enum Destination {
    case details
}

@MainActor
@Observable
final class ValueRouter {
    var next: Destination?              // which screen: a value that holds nothing
    init() {
        probe.object = self
    }
}

Both routers, with the probe

a router that stores the screen is still alive
a router that stores which screen is freed

Some of these are set by frameworks, not by you. URLSession keeps its delegate strongly until the session is invalidated — unlike almost every UIKit delegate, which is weak:

// URLSession keeps its delegate — from the SDK, shortened
open class URLSession {
    // strong, until the session is invalidated
    open var delegate: (any URLSessionDelegate)? { get }

    open func finishTasksAndInvalidate()
    open func invalidateAndCancel()
}

// UIKit's delegates are weak — from the SDK
@property(nullable, nonatomic, weak) id<UITextViewDelegate> delegate;

And one is set by Observation itself. Every @Observable object has a registrar of its own, and observableObject's registrar keeps the onChange closures that are waiting for a change. Call withObservationTracking on a model from the model, with an onChange that names self, and you have stored a closure on the model without writing a property for it — model → observableObject's registrar → closure → model. The closure is one-shot, so the first change fires it, removes it, and breaks the loop; until then the model is stuck:

import Observation

@MainActor
@Observable
final class Model {
    var count = 0
    init() {
        probe.object = self
    }
    func watchMyself() {
        withObservationTracking {
            // the read files a closure in this object's own registrar…
            _ = self.count
        } onChange: {
            print("  onChange fired, and the model's registrar let the closure go")
            _ = self                        // …and the closure names self
        }
    }
}

Before and after one change

before any change, the model is still alive
  onChange fired, and the model's registrar let the closure go
after one change, the model is freed

SwiftUI's own tracking of a body goes through this same registrar and does not leak, because the closure it files holds a node number, not the view. You would not write this one on purpose; it is here because it is the only cycle whose middle link is Observation's own bookkeeping, and because it shows exactly where observableObject's registrar keeps its closures.

weak, unowned, and what deinit can reach

Two ways to break a cycle, and they are not the same. weak is an optional that becomes nil when the referent goes. unowned is not optional and does not become nil: it promises the referent outlives the reference. Read an unowned reference after its object is gone and the program stops — a card shows the exact message:

final class Bird {
    // never nil in a correct program; a crash if the feeder is gone
    unowned let feeder: Feeder
}

final class Bird {
    // nil once the feeder is gone; an optional you check
    weak var feeder: Feeder?
}

Use unowned only where the lifetimes truly nest and the reference is read while both are alive — a child that cannot exist without its parent. Everywhere else, weak. The cost of weak is an optional you unwrap; the cost of a wrong unowned is a crash.

And deinit is not the cleanup hook it looks like. It runs only once nothing holds the object — so if a task, a timer or a notification block is holding it, the deinit that would cancel, invalidate or remove them can never run. On top of that, under Swift 6 a deinit is not on any actor, so it cannot call a main-actor method, and it may not touch a non-Sendable stored property either:

import Foundation

@MainActor
@Observable
final class Model {
    @ObservationIgnored var timer: Timer?

    // runs on the main actor, so it may touch main-actor state
    isolated deinit {
        timer?.invalidate()
    }
}

Mark it isolated deinit and it runs on the main actor, free to touch main-actor state — the lab's models use it for exactly this. But it changes where a deinit runs, not whether it runs: a card gives the endless-task model an isolated deinit and it is still never freed. Do not rely on deinit to break a cycle. Break it where the work starts — cancel the task, invalidate the timer, remove the observer — in .onDisappear, or by letting the view's .task own the work.

How to find one

The cheapest instrument is a print in deinit, which is how every screen of the lab reports: go back, and either a line prints or it does not. For a real app, Xcode's Memory Graph Debugger (the button in the debug bar while the app runs) draws every object that is alive and what holds it; turn on Malloc Stack Logging in the scheme's Diagnostics and it also marks the objects that nothing reaches, with the line that allocated each. Instruments' Leaks template watches the same thing over time.

From the command line, leaks does the same for any process, and the shape of its report is worth knowing. This program makes the callback cycle from the first section with two plain classes, in a function that returns, and is run under leaks --atExit:

final class Model {
    var onDone: (() -> Void)?
}

final class Owner {
    let model = Model()
    var text = ""
    func start() {
        model.onDone = {
            // the model keeps a closure that keeps the owner that keeps the model
            self.text = "done"
        }
    }
}

func makeTheCycle() {
    let owner = Owner()
    owner.start()
}

What leaks --atExit -- ./program reported as it ended

Process 84530: 2 leaks for 96 total leaked bytes.
    2 (96 bytes) ROOT CYCLE: <Model 0x79cc828000> [48]
       1 (48 bytes) __strong onDone.context --> ROOT CYCLE: <Owner 0x79cd004000> [48]
          __strong model --> CYCLE BACK TO <Model 0x79cc828000> [48]

A ROOT CYCLE is a group of objects that only hold each other, and each __strong line is one stored reference: the owner's model, then the closure context the model stores in onDone, back to the owner. That is the loop drawn link by link, with the types named. (leaks scans the stack too, so a cycle made in the very function it is called from can hide behind a stale pointer — make it in a function that has returned.)

The lab: twelve leaks to open

Reading about a leak is one thing; watching a model not go away is another. RetainCycleLab.zip is a small iOS app: a control screen that leaks nothing, then twelve leaks from this guide, each with a leaking screen and a fixed screen next to it in the list. Open a screen, go back, and watch the console: a line beginning with a check mark means the model was freed; nothing means it is stuck.

Each file in Leaks/ holds one mistake — the callback, the timer, the stored task, the task nobody keeps, children that point back, a router that stores a view, Observation's own registrar, the list's rows, a helper's callback, the model's own stream, the [weak self] trap, and URLSession's delegate — with a comment that says why you would write it, draws the loop one link per line, and gives you something to try. A breakpoint is set on the check-mark line in every model's deinit, so Xcode stops there when a fixed screen frees its model and never when a leaking one does. StartHere.swift is the map.

The screens are the cards of this guide as an app: the same models, the same loops, the same fixes. Download it, open it in Xcode, and run it on any iPhone simulator.