Re: NSAlert boxes ...

Graham Cox

On 17 Feb 2020, at 12:22 pm, Sandor Szatmari <> wrote:

The MRR rules are straight forward and deviating from them because the runloop may retain the alert is asking for trouble in my opinion.  There is no harm in taking ownership of the alert and releasing/autoreleasing it.  I would argue that doing so ensures that any changes in SDK/runtime behavior don’t adversely affect your product.  


That’s exactly what I’m saying - you are taking ownership of it with alloc+init.

Then you release it or autorelease it within the scope of setting it up. Normal rules.

But the point is the alert is run asynchronously, so it has to survive long after the scope of where you instantiated and set it up. Long after the next autorelease drain in fact. But that is someone else's problem - the run-loop’s, I’m supposing.

The alternative is to try to take ownership of it until it is finally and completely dismissed, which requires an unbalanced release in the completion block. This not only flags a warning when you compile, but it’s simply unnecessary. Trying to overthink the ownership rules in this case leads to code that is not only complicated, but redundant. The designers of NSAlert have already taken its lifetime into consideraton, so YOUR ownership of it only lasts as long as it takes to instantiate it, set it up, and ask it to run modally.

Peter’s original code, where he autoreleases as part of alloc + init, works absolutely fine.


Join to automatically receive all group messages.