Window functions not found over DLL boundary on MacOS

[stofffe]

Description

When passing a winit::Window over a DLL all window functions are not found on the WinitApplicationDelegate. The following error is produced when trying to call window.inner_size()
invalid message send to -[WinitApplicationDelegate canBecomeMainWindow]: method not found

I did some logging of the window before and after being passed into the DLL

2025-09-01T15:41:32.005805Z  CORE MAIN ID: WindowId(5302672160)
2025-09-01T15:41:32.005809Z  CORE MAIN: WinitWindow {
    __superclass: ManuallyDrop {
        value: NSWindow {
            __superclass: NSResponder {
                __superclass: <WinitWindow: 0x13c105b20>,
            },
        },
    },
    __ivars: PhantomData<()>,
}
2025-09-01T15:41:32.005840Z  DLL MAIN ID: WindowId(105553161520560)
2025-09-01T15:41:32.005844Z  DLL MAIN: WinitWindow {
    __superclass: ManuallyDrop {
        value: NSWindow {
            __superclass: NSResponder {
                __superclass: <WinitApplicationDelegate: 0x600002b285b0>,
            },
        },
    },
    __ivars: PhantomData<()>,
}

Is calling window functions over a DLL supposed to work. I mainly want to know if this is the intended behaviour, so I don't debug for no reason.

My use case

I am writing an engine with support for hot reloading. The event loop is ran on the main thread and calls into a struct that implements a set of callbacks. When the hot reload feature is enabled these callbacks are loaded from a DLL and are reloaded when the dll changes.

Other possible solutions and why they dont work

One solution would be to not call any window functions from the DLL and instead use a queue which is polled in event loop on the non-DLL side. For my use case this has two main problems.

• It changes the architecture of the engine just to support the hot reload functionality, thus hurting the release build.
• External crates such as egui-winit use window functions. Therefore, every crate which uses window functions would need a special version to support my engine in hot reload mode.

macOS version

MacOS 15.3.1

Winit version

0.30.12

See also #4337.

[madsmtm]

So you're clearly hitting some sort of UB here, because the WinitWindow should definitely not have its class suddenly changed to WinitApplicationDelegate!

I tried looking at #4337, but it isn't clear to me how you are passing the window ? Could you maybe post a repo with a reproducer that I could play around with?

[stofffe]

Here's a repo with the minimal code to replicate the bug on MacOS :))
https://github.com/stofffe/winit-dll-bug-macos

[Random-Scientist]

First, the cause of this issue has nothing to do with winit and it should be closed.

Your code contains UB, because Rust, unlike C or C++ does not guarantee a stable ABI for exported functions by default.
https://github.com/stofffe/winit-dll-bug-macos/blob/2dffdb5f430d12d082fe0667a8bc05afa8cff457/src/main.rs#L31-L33
The ABI of a repr(Rust) is not required to be stable between compilations (e.g. compiling the main binary and the library DLL), nor is the extern "Rust" calling convention. winit::window::Window is a repr(Rust) struct, and your access_window_functions is implicitly given the extern "Rust" callconv, which makes calling it immediate UB.
If you want this to work you need to write a wrapper around the Window functionality you want on the main side that exposes only extern "C" (or extern "C-unwind" if you need guarantees aobut unwinding) functions which consume and return only ABI stable types.

[madsmtm]

I was under the impression that Rust generally does have a "stable" ABI as long as it's invoked with the same compiler version etc.?

The UB here is actually in objc2 (and could possibly be triggered with just crate-type = ["dylib"]), I have opened madsmtm/objc2#825 for that - so I agree that we should close this issue (because it's not a Winit bug).