Note: the official view of //Build comes, of course, from the keynote session at //Build and the individual speaker sessions so if you find that anything that I write here seems out of sync with what you see at //Build then, of course, you should apply a pinch of salt to what I’ve written – I can be wrong and it’s early days yet.
You should also check out these 2 blog posts:
Cortana (yes!) and Many, Many Other Great Features coming in Windows Phone 8.1
Extending platform commonality through universal Windows apps
This post follows up from the previous post.
I’d recommend reading that post before launching into this one and all the caveats that I applied to that post also apply here.
Having written a little in that previous post around where I think “we are” with respect to Windows 8.1/Windows Phone 8.0 and developing code for both of those platforms, what does Windows Phone 8.1 bring?
Windows/Phone 8.1 Convergence
With Windows/Phone 8.1 there’s much more convergence than before. In my own head I see this a convergence around “WinRT” as the underlying platform APIs/runtime but that’s maybe an over-simplified view;
What I’m trying to say with that picture is that WinRT is a bigger set of APIs for a Windows Phone 8.1 app than it was in Windows Phone 8.0 and, at a high level, I think you could view it as being “the same set of WinRT APIs that a Windows 8.1 developer has available” although that’s not entirely true when it comes to the detail – the Angels are always in the detail 
I’ve drawn dotted boxes around the Win32, Silverlight, .NET APIs in the diagram above because not every 8.1 app/game developer would call those APIs – it depends on what their app is doing but every 8.1 app/game developer is going to make use of WinRT APIs one way or another.
Thinking from an apps (not games) perspective, I think it’s fair to represent both Windows/Phone 8.1 platforms with the diagram below;
This is the exact same diagram that I drew for the Windows 8.1 platform in the previous post (with different colours ).
The variant of XAML on both Windows and Phone is now the same. That means that;
- Making use of CLR namespace mappings will work the same way.
- Making use of intrinsic types like x:String and so on will work the same way.
- Making use of data-binding capabilities and syntax will work the same way.
- etc.
It’s also important to note that the subset of .NET that’s presented to both Windows/Phone 8.1 platforms is the same subset of .NET so common code can sit on a common substrate.
Windows Phone 8.1 is backwardly compatible – apps and games from previous operating system versions will continue to run and that developers who have an existing Silverlight Phone application targeting 8.0 do not have to leap to “Windows XAML” in order to build for Windows Phone 8.1.
It’s possible to take that existing Silverlight application and re-target it to run on the 8.1 runtime which gives the Silverlight 8.1 app a platform something like the picture below;
This means that a Silverlight developer targeting Windows Phone 8.1 continues to work with “Silverlight XAML” and continues to work with “Silverlight .NET” but also gets access to the new WinRT APIs that have been broadened out for Windows Phone 8.1.
Convergence isn’t “One App, Runs Everywhere”
Going back to the discussion in the previous post about “Phones are different”, the platform convergence above is not about building one app package/binary that will then install and run across Windows/Phone.
A developer who’s building for both Windows/Phone 8.1 on the new platform will still build 2 apps and submit them into Store with separate application manifests although there are capabilities within the Store to link those applications together from the user’s perspective if the developer chooses to do so.
However, the possibility for sharing code between those two apps becomes much greater with Windows Phone 8.1 than it has been to date. From a XAML developer’s point of view;
It’s now possible to produce two apps with (usually) different UIs which make use of common underlying .NET code sitting atop a common set of underlying .NET/WinRT and Win32 platform APIs.
This means that the traditional “problem” of not being able to build portable class libraries that make calls to the underlying platform goes away – it’s possible for code built into a PCL to make use of WinRT to access the file system, the camera, the network and so on as those same WinRT APIs are available on both Windows/Phone.
Common XAML – What Does it Mean?
In terms of “XAML” for Windows/Phone 8.1, the XAML language variant is in place for both platforms as is the same runtime used to render that XAML and as are the same libraries which provide “XAML functionality” to your code. For the first time in a long time, “a Button is a Button is a Button”.
As you’d expect, there is some subtlety here. If we think about the sort of controls that make up a XAML UI;
Update: Since watching some of the //Build breakout sessions I know that diagram above isn’t quite right in at least one way. The controls like Hub/ListView at least should perhaps really sit in the “common, different rendering” column because I learned that they do some make some adaptations for Windows/Phone platforms.
I’ve partitioned those controls into 4 categories as in the diagram above;
- Controls like Button which are the same controls on both platforms and render the same way.
- Controls like Hub (Windows 8.1) which are the same controls on both platforms but a developer would more than likely have different content inside of the Hub control on each platform.
- Controls like DatePicker which are the same control on both platforms but render in a different way so as to preserve the user’s expectation on each platform.
- Controls like Pivot which only exist on one platform – in the case of Pivot, that’s a Phone-only control.
There are some differences here but they are in the minority and the main differences are going to be in how the controls are used more than anything else.
Common WinRT – What Does It Mean?
Much like what’s happening with XAML, when it comes to WinRT there’s a much larger shared API set across Windows/Phone 8.1;
Lots of APIs are going to be common and this has impact on how a developer writes their code. A Windows Phone developer is going to notice more changes than a Windows 8 developer. For example, in areas such as these examples;
a developer is going to be using WinRT APIs for this kind of functionality whereas in Phone 8.0 it was the Silverlight.NET APIs that provided this kind of functionality.
There are some more implications there – using the WinRT APIs for push notifications for example means that a Windows Phone 8.1 application is using the Windows Notification Service for push notifications.
As the picture above suggests though there are going to be some APIs that are still platform specific. For example;
- I don’t think that the Windows 8.1 search contract APIs are present on the Windows Phone.
- I don’t think that the Windows Phone APIs around the new Action Center are present on Windows 8.1.
- There are going to be some places where the same APIs behave somewhat differently on Windows/Phone 8.1. As an example;
- Windows/Phone 8.1 applications have different options around their tile sizes and the way in which notifications (tiles/toasts) are displayed. The same APIs can be used but they are going to achieve slightly different effects.
Summary
The Windows/Phone 8.1 platforms are far more greatly unified than in the past. Windows Phone 8.1 supports a number of different ways of building an 8.1 app;
- With HTML/CSS/JS.
- With XAML/C++
- With XAML/.NET
- With a Silverlight 8.1 app
And that’s not including the options around building games with DX.
For a XAML developer, the XAML variants used across Windows/Phone 8.1 are the same and the underlying .NET/WinRT APIs are greatly unified which should make for a much easier life in trying to target both platforms.
What’s Next?
In the next post, I’ll spin up a “Universal” app project in Visual Studio and look at how that makes use of the new “sharing” folder.
Mike Taulty 