As far as I can see that's not the case, you can only use managed code. The closest you can get as far as I can see is using managed C++ allowing you to reuse code from native C++, but of course with the lack of Win32 and many other APIs often used in native code.
We actually do not really support (or at least emphasize) managed C++ (aka C++/CLI) for WinRT development.
The primary targets are via the API "projections." They are:
Native C++ with "Component Extensions" - also called "high level" C++
C# and VB.Net (managed)
C++ apps can use DirectX (D3D/D2D) to render directly (or via a custom UI framework built on top of it), or use the new (fully native) XAML system.
.NET apps can use the same XAML system (the implementation of which is all native).
JS apps use HTML / canvas / SVG
You can also forego the C++/CX extensions and the niceties of the high-level projection, and instead write purely standard C++. Here you'd interact with the WinRT in its raw form, what we call the ABI (Application Binary Interface). That level would be most familiar to experienced COM developers (HRESULTs instead of exceptions, etc). For those developers we also include the new WRL (Windows Runtime Library) helpers, which is analogous to a modernized subset of ATL. But it's all new and designed for the WinRT ABI (and new base platform constructs like HSTRING and such). That said, I don't know why you would :-) The ABI layer is... verbose, compared to the elegant and concise CX goodness (and the result the compiler spits out is the same).