Skip to main content Skip to footer

Why Build Responsive Apps with Windows 10

We recently released our UWP Edition in beta, a collection of controls designed to work across all Windows 10 devices. In this topic I cover why your UWP (Windows 10) apps need to be adaptive, or responsive. In the next topic I'll dive into several tips and techniques for accomplishing an adaptive UI.

Responsive Apps == Adaptive UI

Last year I gave a session on tips for creating adaptive UIs for Windows 8.1. Earlier this year I updated the talk for Windows 10 UWP apps. I decided to use the word 'responsive' in the title because it seems to be catching on in the industry more than 'adaptive.' So I figured more people would understand what my talk was about. I want to clarify this before going any further because technically responsive app design is a Web thing, and adaptive UI is the same thing for native Windows apps. Maybe even by the time you are reading this the world has changed and it doesn't matter, but anyway onto the content...

What is Adaptive UI?

An adaptive UI is a user interface that adapts its layout to the needs of the user. The needs of the user can be thought of us several things like the user’s role, or experience, but in most cases when we refer to adaptive UI we refer to UI’s that adapt to different sized devices. For instance when an app is run on a smaller device, the UI reduces its complexity allowing the app to be used, while maintaining as much of the same experience as possible. In Web development this is well known as responsive design. Responsive_Adaptive_apps

Enter the Universal Windows Platform

With Universal Windows Platform Apps, we can now develop once for all Windows devices using a unified toolset. With Windows 10, a Universal app is now created with a single project template in Visual Studio 2015. It outputs a single package that runs on all devices. For these new UWP Apps we have 5 or so device families: Devices & Internet of Things, which is like the app on your refrigerator, Mobile, PC, Xbox and Surface Hub. Even though this topic is really only focused on Mobile development, the concepts are the exact same on these platforms. UWP_Apps With Windows 8.1 you targeted each OS (Windows or Windows Phone) separately with code sharing capabilities. With Windows 10 you no longer target an OS but a device family. With Windows 8.1 we could share a lot but it was still targeting to different runtimes. With Windows 10 there’s a universal API which is a common API for all device families. And then you typically target an app toward a single sub-API family. But you’re not completely limited here, you can target more than one and even share code. Windows_10_Universal_Device_Family

Universal Windows Apps Must Be Adaptive

So with Windows 10, Universal Windows Apps now provide the ability to use a single UI that can adapt from small to large screens without sacrificing user experience.

This means our UI needs to be adaptive in order to get the most out of writing once and sharing code.

It's that simple.

What do you get for free?

Some aspects of your app's UI will automatically adapt across devices. For free you get common input handling whether you are using touch, a pen, mouse, or keyboard, or a controller such as a Microsoft Xbox controller. You also get adaptive scaling that accounts for resolution and DPI differences across devices. Controls such as buttons and sliders automatically adapt across device families and input modes.

Why Write Once/Share Code?

So you might be asking why share code and what does it have to do with creating adaptive UIs? For code such as business logic, it’s a no brainer to share. And really, we’ve been sharing business logic tiers for long before Universal Apps came along. For resources that are the same across all outputs it also makes clear sense to share. But the XAML, which represents the user interface, was always something that you didn't share between your Windows Phone and your WPF or Windows App. Now with UWP Windows 10 apps, the XAML can be shared between phone and PC/tablet. It means, for example, you can create a single page for your app defined in XAML. Rather than create multiple versions of this page for each device size, you can use techniques on your single page so it becomes adaptive. This is what I mean by writing once or sharing code even though it's not the same as sharing code from a PCL. For the user, sharing promotes a universal experience across all device platforms. For the developer, sharing is cleaner and results in less code to maintain. Sharing code can be beautiful and enjoyable (like an art form), but it can also make code more complex, so it’s not an end-all solution. The downside to having beautiful code that can do a million things at once is that it gets more complex. You pass it to the next developer to maintain it and they have to twist around and figure out how it can do so much with a single block of XAML or code. Now, this is more of a generic statement. I actually think with XAML in particular it’s not hard to decipher so long as you know XAML. Some things like DataTemplates and the VisualStateManager can be intimidating for novice XAML developers.

Why adaptive UI?

In summary, if we are sharing XAML for our user interface across multiple devices it MUST be adaptive. If it’s not adaptive, then we shouldn’t be sharing it. In my next topic I will cover several tips and techniques for creating adaptive UIs with UWP.


Download our free UWP Edition Beta >>


ComponentOne Product Manager Greg Lutz

Greg Lutz

comments powered by Disqus