Is there any point including PDBs when using NativeAOT publishing?

[catmanjan]

One of the options I get when creating an appx package is to including debugging symbols - do these symbols even work if I am publishing a NativeAOT project?

[MichalStrehovsky]

The big PDB file from the native compilation is useful if you want to debug the app or diagnose crash dumps. It's a native PDB - the debugger will not know it's debugging a C# app. You'll get similar experience to debugging C++ (line numbers, breakpoints, and locals will show up, but managed concepts like properties or visualizers will not work). So yes, it's useful, but make sure you select the Native debug engine (not the managed or mixed-mode debug engine).

[Mr-Documents]

Yes, but their usefulness is a bit different compared to normal .NET apps.

When you publish with NativeAOT, your app is compiled into native machine code, so debugging behaves more like C++ than C#.

What PDBs are useful for:
Debugging crashes (e.g., analyzing crash dumps)
Getting line numbers and stack traces
Setting breakpoints in native debugging mode

What you won’t get:
No typical C# debugging experience
No property inspection, visualizers, or managed features
Why this happens:

NativeAOT removes the usual .NET runtime layer, so the debugger only sees native code, not high-level C# constructs.

The takeaway is that,
it includes PDBs if you want better debugging and diagnostics
it Expect a C++-style debugging experience, not full C# debugging

PDBs are still useful with NativeAOT. Just think of them as tools for low-level debugging, not full .NET debugging
Just make sure to use a native debugger, not the managed one.