As I mentioned in my HoloLens talk last Friday, there are two paths to build HoloLens apps.

The Easy Path: UWP

First, you can build a Universal Windows Platform (UWP) App. It’s amazingly simple and if you’ve been working in Visual Studio (like me) for a long time, you’ll feel right at home.

This is what UWP apps look like on HoloLens:

What is interesting about the hologram that UWP apps live on is that they aren’t exactly flat planes. They are, in fact, rectangular boxes (i.e. they have depth).

Because HoloLens runs Windows 10 (or a special version of it) it can run any app that is:

1. Built using the Universal Windows Platform
2. Enabled in the Windows Store to support HoloLens

So right off the bat that means you can do a whole bunch of really cool stuff with your HoloLens.

Like play Crossy Road at the United Club.

Or play Xbox One on a Holographic monitor in your living room.

I could go on and on. It’s awesome.

However, the UWP path has one huge limitation. Aside from all the incredible developer productivity enhancements you get (e.g. the BCL, the awesome UWP sample pack from Microsoft, the absurd amount of NuGet packages and GitHub projects to draw from). The one downside to this approach is this. You only get one Hologram and its a rectangular plane that your 2D UWP app lives inside. Yep, that’s it.

The Rocky (but WAY cooler) Path: Unity 3D

This path breaks you free from the shackles of the uni-hologram land that is UWP and you get to still code in C#. BUT-and this is a big but-that C# you are writing is NOT standard .NET.

That means you don’t get the standard BCL (base class library, seriously?). You are using something that Unity 3D developers have been using called Mono. I’ll save you some time. It’s 3rd party (think open source) C# compiler and runtime. Forget System.* (well, kindof). Forget Windows.Foundation.*. Say hello to UnityEngine.* and MonoBehaviour.

It’s true, you will be writing C# but you won’t be doing it in the same way you did before. If you spent some of your life working with XAML based UI then you might be familiar with the concept of “Attached Behaviors”. This will be hugely useful in understanding how to develop within Unity. Almost every piece of code you write will be attached to some component and obtain everything from lifecycle, state change, inter-object messaging from it’s attachment to some component within the scene.

The main room in this party house is not the Solution Explorer. It’s the scene.

Code gets attached to objects using the Inspector panel. This is almost exactly like how you would use an Attached Behavior in the XAML world in Expression Blend.

It’s a very different way of doing things and takes some time to wrap your brain around it. Even in the XAML world where we used Attached Behaviors frequently, there was only a narrow use case where Attached Behaviors were the appropriate way of adding functionality. Now you’re essentially implementing all functionality in that manner!