I think you already got the correct answer on Stack Overflow. The window is not the same thing as the NSWindow object.
Although the NSWindow object keeps track of the state of the window within your app, the Window Server (a separate process that services the windows of all apps) also manages the window. That's how your windows can be interleaved (front to back order) with windows from other apps without sacrificing privacy.
A long time ago, I read (though I can't remember where) that when your app frees its last reference to the NSWindow object, the object actually stays alive until the Window Server has been notified, which takes an additional iteration of the main thread run loop. In other words, the object won't be deallocated immediately after your app's last reference is released, but sometime later. I don't know if this is still true, but it may be.
If you don't want the window to exist any more, then "close()" is the correct function to call. You should also discard any strong references in your code. After that, it's not your responsibility any more.
I see. Thanks for answer.
It seems there's another owner that I don't know. It would be nice if I can find some document that mentions about another owner.
Note that I'm not claiming that the Window Server "owns" the NSWindow object in the retain/release (memory management) sense. I'm making two slightly different claims:
1. The actual NSWindow object in your app may have its (retain/release) lifetime artifically extended until the Window Server says it's OK to deallocate. This would have to be implemented as an extra owning reference inside your app, but just not inside code you wrote.
2. The actual window may be a "thing" in the WIndow Server separately from the NSWindow object in your app, and the thing's lifetime may be slightly different from the NSWindow object lifetime.
If both of those claims are true, then reasoning about the apparent lifetime of a window from the user's point of view is a little tricky in the edge cases of its lifetime — even though the behavior is deterministic if we could peer into the internals of the Window Server.
The other components that hold a strong reference to your window are the various pieces of the AppKit and operating system components. If you think about how the window is actually created and maintained, all the way down to the screen drawing and compositing operations, it is likely that several components of the architecture maintain a reference in some fashion. When you call close(), you're telling the system you are not interested in the window anymore, and it can release it's references, re-draw the screen, and the like.
The whole subject is somewhat touched in the Windows Programming Guide (archived document in the Developer documentation), but no real specifics since this all considered an implementation detail, and is part of the AppKit black box.