Obviously, 95% of graphics- or CPU-intensive apps (eg. games, graphics utilities) are going to be native, but this isn't implied in the slide deck -- indeed it almost suggests (somewhat disingenuously) that the "trend" toward non-native includes games, which is silly.
The Unity engine has 98% of its hardware-intensive functionality compiled natively on the device, with only a small percentage of the remainder being interpreted code. Once again, it's hard not to call such an app "native" since there's no interpreter layer between the instructions and the bare metal of the device.
I worry that by suggesting these examples are "non-native" you're placing them on the same bar as HTML5 / JavaScript which is largely interpreted. I think a distinction needs to be made between languages/engines whose code is largely native and / or compiled at runtime, and languages / engines whose code is largely interpreted while running. There's huge performance implications between these two categories.
With Unity and the Epic Unreal Engine, the goal is to be able to build games that will be able to run anywhere in a web/WebGL context: https://blog.mozilla.org/blog/2013/03/27/mozilla-is-unlockin...
I believe it's also about finding ways to make interpreted code much more optimized as well. We also fairly recently had a blog post about asm.js and where it's going: https://hacks.mozilla.org/2014/05/asm-js-performance-improve...