Build apps for Windows 10

by Tim Anderson

Windows 10 is coming and with it a new app platform that will run on everything from desktops to phones, Xbox consoles and IoT devices.

HardCopy Issue: 66 | Published: June 1, 2015

What is next for Windows, following a lacklustre response to Microsoft’s bold remaking of the operating system in version 8? The answer is Windows 10, with availability promised later in 2015; and this time the pitch is that the company is unifying its platform with ‘One Windows’ across all form factors, including games consoles, augmented reality devices that use HoloLens technology, and Internet of Things (IoT) devices such as the latest Raspberry Pi.

Microsoft talked up the concept of Universal Apps before Windows 10 was announced, introducing a new project type in Visual Studio 2013 that can target both phone and PC. Although it is a single project, this type of Universal App is really just a means of sharing code, generating separate executables for each platform, and with device-specific projects within the shared Visual Studio solution. The key technical enabler for old-style Universal Apps is Portable Class Libraries, which lets you use standard .NET assemblies and other class libraries that work across multiple platforms, with Visual Studio enforcing compatibility. Another characteristic of this existing technology is that developers are expected to create a separate user interface for each platform.

In Windows 10, Microsoft is taking a different approach, though it has been using a similar term, namely Universal App Platform (UAP), to describe it. A Windows 10 UAP app is a single project, and the user interface tools have been reworked so you can target multiple devices with one design, an approach Microsoft calls the Adaptive UX. It is a similar concept to Responsive UI in web design, though implemented in XAML, Microsoft’s XML-based presentation language, rather than in HTML.

The UAP is accompanied by a unified Windows Store, so that users can buy once and install both on phone and PC.

The Windows 10 UAP, like Store apps in Windows 8, uses the Windows Runtime (WinRT), a platform within Windows that isolates applications from one another and from the OS, as well as providing a touch-friendly API for apps that run on tablets and phones. However, WinRT apps behave differently in Windows 10, running in a window on the desktop, rather than full-screen. Microsoft has worked to integrate the desktop and WinRT environments, figuring perhaps that in Windows 8 most users live in the desktop and rarely see or explore the modern app platform.

The ‘Universal App’ name may not be the final choice, either. At the Windows Hardware Engineering Conference in Shenzhen, Microsoft Distinguished Engineer Don Box stated:

“In Windows 10 we have this notion of a Universal App platform. The apps that target it are called Windows Apps. Sometimes we say ‘Universal Apps’ but we call them Windows Apps.”

Windows 10 app in Visual Studio screenshot

Working with a Windows 10 app in Visual Studio 2015.

The name is a clue to the importance that Microsoft attaches to the platform. The advantages of the UAP include easy discoverability via the Windows Store (or enterprise app stores in businesses), smooth install and uninstall, better security through app isolation, and ease of use on tablets as well as with keyboard and mouse.

Microsoft is also supporting the UAP with its own apps. The previews of Windows 10 and Windows Phone 10 show the platform being used for standard accessories including Calculator, Alarms, Sound Recorder and Photo viewer. The company has also released a UAP version of Office, including Word, Excel and PowerPoint, with similar functionality to the versions available on iOS and Android.


Building for the UAP

There are several ways to build for the UAP, with the main ones being:

1. XAML with C# or Visual Basic
2. XAML with C++
3. DirectX with C++
4. HTML and JavaScript, through the use of Microsoft’s WinJS library
5. Hosted Web Apps (essentially web sites packaged for the Windows Store with access to WinRT APIs through JavaScript)

In addition, Microsoft has several projects for building apps using simple visual tools, including the online App Studio and TouchDevelop, and the app-based Project Siena. While these currently build Windows 8 Store apps, they are expected to transition to the UAP once Windows 10 is available.
All these options are viable, and the choice is a matter of developer preference and the purpose of the app, with DirectX intended mainly for games, XAML for general-purpose and line of business apps, and WinJS for those coming from web development or with existing JavaScript code to port.

Microsoft builds the Universal App version of Office using XAML and C++, which has a small performance advantage over XAML and
.NET. It is worth noting though that UAP apps written in .NET benefit from Microsoft’s .NET Native project, which means they are compiled to true native code when deployed. This improves start-up time as well as solving potential dependency issues.

The main tool for building UAP apps is Visual Studio 2015, currently in preview. This comes with Microsoft’s Blend visual designer. Blend is integrated with Visual Studio, so that you can right-click a XAML file, choose Design in Blend, work on the page, save, and continue in Visual Studio.

The experience of building UAP apps will be familiar if you have previously worked on Windows 8 Store apps, but less so for those coming from Windows desktop development or other platforms. Note that the platform is more like a mobile platform than a desktop platform, not only in its approach to data, but also in the application lifecycle and sandboxing. Whereas a Windows desktop app is either running or not – even when minimised the process is still active – a WinRT app can be suspended by the OS if the user switches away. Suspension fires an event that you can handle to save data, but it must return within 5 seconds or the app will be terminated. The OS may also terminate a suspended app if there are insufficient resources to keep it in memory.


The application lifecycle means that your app can be suspended and must know how to resume cleanly.

The application lifecycle also means that when an app starts it should check whether it is resuming after suspension, or a new launch, or called by the system because the app is registered for a certain file type or to handle images or contacts.

This approach is required for apps to behave nicely in environments such as Windows Phone or small tablets, which may have low memory.

XAML in the UAP is essentially the next version of XAML for Windows 8 Store apps. It is similar in approach but not compatible with XAML for Windows Presentation Foundation (WPF) or for Silverlight, used by Microsoft’s browser plug-in and by Windows Phone. The GUI controls in the UAP are designed for touch, which means they tend to be chunkier than Win32 or WPF controls, though the flexibility of XAML means that you can achieve a very different look and feel through custom styling if needed. Part of the rationale for the UAP is that it works well with touch though, so it would be unwise to create an app that was hard to use on a tablet.

Despite the concept of ‘One Windows’, different devices have different capabilities. This is handled in the UAP via extension SDKs that are device-specific. When you reference an Extension SDK, the device-specific API is available on all platforms as stub, but only functional on the device to which it applies. Functions like IsTypePresent and IsEventPresent let you detect at runtime whether the features are active on the current device. You can also use conditional compilation using #if, but Microsoft discourages this since if you do, you are back to needing a separate executable for each platform.

Microsoft has currently identified five ‘device families’ which determine what APIs are available and Store availability – in other words, users can only install an app from the Store if they have a supported device. Currently, the device families are Desktop, Mobile, Xbox, IoT and IoT headless (without user interface).

Universal App Platform caveats

Despite Microsoft’s strong push for ‘One Windows’ and the Universal App Platform, there are a couple of drawbacks. One is that the UAP is Windows 10 only. Users of Window 7 and 8 will not be able to run the apps unless they upgrade. The upgrade is free initially, for most users, but this is still a major blocker, particularly in the business market where Windows 7 remains the standard.

Another issue is that although UAP apps run in a desktop window, they are still in the WinRT sandbox and limited to a subset of the Windows API. There are no database drivers for SQL Server or Access, since you are expected to use a web services model to access data, or a local database engine such as the open source SQLite which will be restricted to app-isolated storage. UAP apps are also single instance, though they can open multiple windows.

That said, enterprises do have a way of bypassing the WinRT sandbox by using a technique called Brokered Windows Runtime Components. This is for side-loaded apps (in other words, privately installed rather than downloaded from the Windows Store), and lets you call a desktop component from a WinRT app using inter-process communications.

The consequence of these limitations is that you have to be sure that WinRT provides the functionality you need, and that your users have access to Windows 10, before making the decision to build a UAP app.

Visual Studio 2015 ships with an emulator for Windows Phone 10, based on Hyper-V virtualisation, and you can debug phone apps either with the emulator, or remotely on the device itself.


Microsoft’s Adaptive UX

The idea of designing a UI that works on everything from huge desktop screens to small phones sounds ambitious, and it is. However Microsoft has done a few things to make the task easier.

First, some built-in controls such as the Date Picker and Toggle Switch automatically adapt according to the size of the display.

Second, an updated VisualStateManager includes an element called an AdaptiveTrigger. The way this works is that in your XAML you define an AdaptiveTrigger based, for example, on a minimum window width. If the windows width is below this size, it activates a VisualState in which you can apply changes to the layout, such as changing the orientation of a panel or having it become a flyout rather than always visible. Blend has a States panel that lets you design these different states, or you can define them in code.

Third, a new layout control called RelativePanel lets you create layouts by defining the relationship of one control to one another, so simplifying the markup. Instead of using a grid when you want to ensure that one control is always to the right of another, for example, you can now specify this with a RelativePanel.

Fourth, a new SplitView control makes it easier to present content in a common layout pattern, with navigation links in a left column and a panel on the right with the related detail. You can define this so that the navigation pane is a flyout in small window sizes.

Despite these helpers, creating a high quality user interface that will work from phone to desktop is a lot of work. The benefit is that users will get a seamless experience running the app whatever device they are using – provided of course it is within the Windows 10 family.


New features in the UAP

The biggest change in the UAP when compared with Windows 8 Store apps is desktop integration, with the apps running within a window. There are other enhancements though, in addition to the new features mentioned above, including the following:

  • The WebView control now uses Project Spartan, Microsoft’s new web engine, promising better compatibility with HTML 5.0 content.
  • A new InkCanvas control and InkPresenter classes lets you support pen input, such as on Microsoft’s Surface tablets.
  • A new shared storage class which lets you share a file with another app by passing a token in code.
  • Apps can request location information, subject to user consent, and you can now trigger a request for consent from within the app itself.
  • The AllJoyn open source framework for IoT is implemented in a new AllJoyn namespace.
  • DirectX is upgraded to version 12, with better performance for games and 3D graphics.
  • Video apps can use HTTP Live Streaming (HLS), and there are new overlay and effects APIs available.
  • XAML ListView and GridView controls use list virtualisation for faster scrolling of large lists.
  • Drag and Drop is supported to let users move data between apps, and from apps to the desktop.
  • Cortana integration means that your app can be found in Cortana searches. Microsoft has also stated that you will be able to extend Cortana for app-specific functionality such as voice control.

Note that Microsoft has promised further announcements so this list is not exhaustive.


Making sense of the UAP

The success of the UAP is by no means assured. As with Windows 8, Microsoft’s problem is that mobile is dominated by Android and iOS, while Windows as a client operating system is used almost exclusively for desktop applications.

Windows 10 will still support desktop applications, of course, and by coding for the desktop you can get compatibility with Windows 7 and earlier.

That said, the new app model has real advantages, both for consumers using the Windows Store, and for businesses looking for better security and reliability. The optimistic view is that extending the Windows app platform to cover all device types will boost the ecosystem, bringing more developers to the platform and making it a viable third contender in the overall app market.

Excel screenshot

The appearance of advanced first-party apps like Excel will boost the appeal of Microsoft’s Universal App Platform.

If Windows 10 is successful in attracting users not only from Windows 8, but also from the many Windows 7 diehards, then demand for Windows Store apps will rise, particularly now that desktop integration makes these apps more attractive to keyboard and mouse users.

Microsoft has spoken about its plans to deliver Windows as a regularly updated service, with customers choosing between frequent updates aimed at consumers, “Current branch for business” releases with regular feature updates, and “Long Term Servicing” branches for scenarios where the stability of a particular build is more important than keeping pace with updates. On this basis Windows 10 is not just a new release, but an invitation to move from a version-oriented approach to one where incremental updates are the norm. The UAP is the app platform for this new style of Windows.

Developers will be understandably wary, considering Microsoft’s history of frequent changes to its development platform strategy, but it does look as if the company intends to make this one stick.

That said, it is obvious that the UAP is not the best solution for every kind of application, a fact Microsoft has recognised with further investment in the desktop-only WPF, which now has its own roadmap of new features.

The value of the UAP is for apps that fit the model, in that they run on mobile or desktop, are touch-friendly, and use Internet-hosted services for their data.