Using Universal Windows Platform (UWP) – Pearls and Pitfalls

We work on a lot of cool projects with our clients. In this use case, I’m going to share my experience regarding how my team worked on extending our clients offering to the Microsoft Store using UWP.

The Product ecosystem already had frontend applications (we call them “clients”) selected, namely legacy, web, and mobile (for iOS), which communicate with backend services and synchronize between each other.

These clients are a bit different in their functionality. For example, legacy client is integrated with Skype for Business, so it supports audio- and video- calls during live sessions, and the mobile application has limited functionality – it just allows to download files from the system.

And our goal was to extend this ecosystem with a new client that would be able to support
a wide range of devices running on Windows 10.

Why UWP?

The main objective was to have a new desktop client that would replace the legacy application. However, for the first release, it should naturally fit into the existing ecosystem.

Let’s take a closer look at the business and technical requirements:

  • Time to market is one of the most important factors
  • The new desktop application should be integrated into the existing ecosystem
  • The application should run on any Windows devices with different screen resolutions such as PC, Tablets, Surface Hub, and customer-specific meeting room environment
  • Integration with new Windows 10 capabilities. The new client needs to support Windows Share functionality, push notifications, live tiles
  • Support specific functionality like “Send To” option from Windows Explorer system menu, desktop sharing, and video streaming
  • Easy software distribution
  • User experience consistency through all Windows 10 devices
  • The new client should have an adaptive layout and support features of a Fluent design

Based on these requirements, UWP was a good fit that would meet most of our requirements.

Universal application by design satisfies requirements to support different devices running Windows 10, including fluent adaptive design. However, it is incompatible with older Windows versions. Also, Universal Platform provides APIs for Windows Share, push notifications and live tiles. Installation and updating the system is smooth and transparent for both developers and end users. The developers team needs to create only one package, and there is no need to maintain different versions of every supported device. And the user experience is the same across a supported device park.

The main setback we faced with UWP is working with WinAPI and I will explain how we solved this setback below.

The Journey

We had high expectations for our new client. The team was inspired and motivated to work with UWP because modern technology excites our developers – everybody wants to try a set of new features. From our experience, a good WPF engineer shouldn’t have a long learning curve to start writing UWP. It’s great to re-train existing talent without a big learning curve

UWP definitely had some advantages. For example we didn’t spend time thinking about screen resolutions or window size, and SVG icons helped us keep a nice view on any device. The improvements in XAML on Windows 10 introduced a number of ways to implement responsive UI techniques, so implementing adaptive design was fast and captivating.

While we were developing the app on a desktop PC, our QA didn’t find any specific issue on Surface Pro, and our customer didn’t find any problem on Surface Hub – that was a big benefit for us, as we didn’t have this device in our lab. The same with the Windows Store – preparing installers was a breeze, just a few clicks in Visual studio and bundles for Store review and publishing are ready.

The minimum target version of our application is Anniversary Update, which was an early adoption version of the platform, so we faced some unexpected behavior for ListView and memory leaks in standard UWP controls. However, UWP becomes better and stable with every new Windows Update and our application worked in Fall Creators Update much better than in Anniversary Update.

Regarding our design, we implemented adaptive layouts consistently with the old clients. However, when talking about Fluent design how it’s presented by Microsoft, UI/UX designers should be ready to think about app usability in these new concepts. The limitation for us was balancing between timelines and appropriate quality. So Fluent design was postponed until the future releases.

And of course, no technology comes without a caveat. As mentioned above, the most complex task was integrating with the native WinAPI. Also, we’ve stumbled upon how UWP core functionality maps to WinAPI and how to make this functionality available in runtime to the application via restricted capability settings.

Capabilities, used by the application, must be declared in application’s package manifest to access certain APIs or resources. Without it, an application will not be published in Store. The set of capabilities are restricted and should be approved by Microsoft during bundles review. These restricted capabilities limit access to some functionality, e.g. we required “Extended Execution” capability to run background tasks and be sure that it will not be terminated or canceled by Windows due to execution time limits, as a life cycle of UWP application is different from a usual Win32 application.

Another example: according to the requirements, we need to show some confirmation dialog when a user tries to close the application, and for this case, we need to declare “App Close Confirmation” capability … but it can be requested starting from Windows Creators update and beyond, for the previous versions the capability is private and will cause application install to fail with error message “The requested capability cannot be authorized for this application”. So we had to reject the functionality, as we’re supporting Windows Anniversary.

The most problematic area was around functional requirements on the possibility to show a user desktop or a single running application in video stream during a live session.
It wasn’t a piece of cake, but finally, this problem was solved as well. We implemented an extension for our UWP client as a typical WPF application, wrapped it inside of a UWP application using Desktop Bridge, which is able to communicate with main UWP client through the communication channel. This extension has been distributed in the Store as a full trust application. Making the main client to be a full trust application was not possible from business perspective, however, we agreed to have the extension that will be published in Store as a full trust app. This is not the simplest solution in general, however, it satisfied all the requirements.

Conclusion

This was an interesting experience and a productive project! Would we choose UWP for such type of product again?

This platform allows you to work with new Windows 10 features, to implement adaptive, empathetic and beautiful user interfaces. You need to create only one package to support park of devices, and you don’t need to think about installer or updates anymore.
But if you need to dive deeper into a system level, it could be really time-consuming, and you always need to keep restricted capabilities in mind.

I recall a developer comment that resonates with our experience: “You should choose UWP if you want to implement Instagram, but for Photoshop you should use WPF”.