"Native" confusingly has two different commonly used meanings. The one you seem to think is the only meaning distinguishes VM from non-VM runtime code (where C# is non-native). This meaning is the N in Android NDK.

The other common usage is "the preferred local platform specific language and dev stack", eg "A native Android app" which usually means "written in Java compiled to dalvik/art" distinguishing from a webapp or an app that is just a packaged webview.

Often it's also a byword for the platform-preferred first-party stack, making the argument somewhat tautological: of course there's a limited selection of first-party preferred stacks on every platform.

I'm guessing this usage is a contraction of the term "platform-native".

I wonder what the authours would think of C++, Qt and webviews?

Correct. C# does not ahead-of-time compile to hardware machine code (e.g. x86).

> WPF is not a native UI

How do you classify "native" vs "non-native" UI?

WPF is it's own toolkit built in directx, it's as native as swing. WPF sits at the same abstraction level as most games, would you consider the main menu in GTA to be a native one?

Does a WPF menu (and WPF-based apps in general) integrate with the systemwide conventions and settings for things like keyboard shortcuts, default font, etc? Is it a first-class UI toolkit for the system? My impression was it is supposed to be, in a way GTA's UI (or Swing) is not.

About as well as swing ever did, no where near as good as Qt does, I think we'd all agree qt is not the native UI of windows.

Then again, it is hard to judge. Not a lot of win32 apps seem to follow system wide settings either, even the MS ones.

Really? It's just not the impression I get, granted it's been a while since I've used Windows for anything other than to, well, play a bit of GTA. I remember paint.net being a thing (seems it's still around) and it looked and behaved like a Windows app. Qt apps look instantly recognizable and fugly to me on any platform. It's hard to believe that WPF apps had or still have, say, the font-rendering problems Swing apps had or were missing access to affordances like control over the tray icon, etc.

The reason I'm skeptical is that WPF was very much intended to be a first-class Windows-specific ui toolkit. You're telling me it's worse than cross-platform toolkits with all of their necessary design and implementation compromises.

Edit: Oh! I figured out where I was confused. WPF and Winforms. Not the same thing.

DirectX is at the same level of abstraction as Win32's Graphic Device Interface (GDI) and Hardware Abstraction Layer (HAL) that the rest of Win32's "native toolkit" was built on top of; Windows.UI is just as "native" as Win32 ever was. It should not be a surprise that the hardware abstraction toolkit beat into performance submission by performance demanding games is the new native layer for Windows. The surprise should be how long it has taken to make the transition across. (Avalon promised it back in Vista and WPF was the closest to delivering it. Windows 8 finally delivered on the Avalon promise.)

Examples: My Summer Car, Sol 0, Software Inc.

Not OP, but presumably WPF can be considered non-native because it relies upon the .Net stack.

Ever heard of NGEN, Mono-aot, .NET MDIL, .NET Native?

All straight sugar free Assembly instructions.

Now if you mixing the notions of VM and runtime, even C has a runtime called crt0 on most UNIX systems.

I was mixing them up. The line seems be kind of blurry though once you start embedding garbage collectors though, then again the GC could just as easily be in an external library.