Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Architectures and Processors blog Learning from StaffPad: How to deploy apps with the Universal Windows Platform
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tell us what you think
Tags
  • Windows 10
  • laptop
  • Application developers
  • Arm64
  • Windows
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

Learning from StaffPad: How to deploy apps with the Universal Windows Platform

Ben Clark
Ben Clark
January 18, 2021
5 minute read time.

Windows on Arm has really gathered momentum and the ecosystem is continuing to grow. It now has the supporting tools to make it easy to port Windows apps to run natively.

And it is worth it – the increase in speed and battery life over emulation of Win32 apps is significant, if hard to quantify.

With Universal Windows Platform (UWP), there are a few simple steps to get your code running natively. UWP is Microsoft’s modern framework designed to make cross-platform development easy. And, as ever more libraries, open-source software projects and other dependencies move over to Arm64, the last hurdle is now more achievable than ever.

Let us look at a case study of how a developer ported their UWP app to native Arm64.

This is an image of the StaffPad.

StaffPad

StaffPad is an award-winning music notation app built for composers. You can write music with a pen on screen, edit it and hear it played back. There is some complicated mathematics behind it, which will be explained shortly, but first let us look at the application’s setup.

StaffPad is built by an international team of developer-musicians, from various backgrounds. The app is UWP-based. This decision was made due to the team’s want to be cross-platform, along with the ease of creating a friendly portable device user experience.

The StaffPad developers use Visual Studio Enterprise. The app is split in two layers: 1) a pure-C++ core, and 2) a “native experience” layer handling the User Interface and interaction, which is C#/XAML.

Third-party dependencies

When porting, the biggest issue is likely to be third-party dependencies, especially with UWP solving most other cross-platform issues. For StaffPad, this was true as well.

There was one main blocker here – third-party libraries with vector intrinsics designed for intel-specific hardware acceleration. These were used mainly for FFT (Fast Fourier Transform) processes in the audio engine.

StaffPad’s solution was to build their own optimized FFT code. There were alternative third party library options available which would have given the solution quicker. However, by writing just what StaffPad needed, it was able to keep it lean and fast and in-house.

No other dependencies caused StaffPad any trouble.

Local dependencies

Local libraries were easy. StaffPad just needed to set its target to Arm64 and rebuild, and make sure that the main project was pointing at the native Arm library. Despite having a few internal libraries of audio codecs and other things, this was done within a couple of hours.

Build, test & CI

StaffPad uses plenty of UWP features like Win2D – and they ported without any issue. So, like local dependencies, this was just a matter of targeting Arm64 and building. Having sorted the dependencies, both the C++ core and the C#/XAML UI layer compiled just fine.

Testing was crucial, but straightforward. It is vital to see the app on a device to show what it looks like in a new environment. In StaffPad’s case, there were just a few small mistakes that were quickly fixed once the app was looked on a Microsoft Surface Pro X.

Visual Studio 2019 comes with Windows on Arm debugging, which is also available in Visual Studio 2017 if the 15.9 update is applied and the Arm64 toolset is then downloaded. It only supports Remote Debugging, and there are a couple of steps to get set up for it. The device must accept Remote Debugging. This is achieved through going to the Settings window, choosing Windows Update > For Developer and turning on Developer Mode and Device Discovery. When turning on Device Discovery, you will be able to pair your Windows on Arm device with the machine you are developing on.

Visual Studio Code has local debugging, but the libraries and compilers are still being ported, so it may not be possible depending on the language you are developing in.

For their Continuous Integration (CI) pipeline, StaffPad use Azure DevOps. Windows on Arm just slotted in without any difficulties, to be permanently tested like everything else.

Deploy

With a well-tested app ready the next question is how to deploy.

Rather than going for an installer, StaffPad deploys to customers through the Windows Store. The Store works well with UWP, allowing easy options across a range of platforms – you can even get StaffPad for the Microsoft HoloLens. To deploy, the new platform version was just uploaded and then was available straight away.

Comparisons

The difference between emulation and native was striking for StaffPad. The app does push devices with graphics, audio, touch, machine learning (ML) and networking all needing processing. In particular, the audio engine failed to perform under emulation, with the start up slow and memory usage high.

Natively, the UI is snappy, loading is fast, pen usage is lag-free – overall it is a joy to use.

It is hard to compare machines as they all have different specifications, but native Arm64 StaffPad’s start up time on the Microsoft Surface Pro X is much faster. The feel of the app in use is also smoother than on similar x64 devices. For StaffPad, the speed, all-day battery life, instant-on and continuous connectivity were all reasons why it wanted to be using Windows on Arm. You can read more from StaffPad in this case study.

Conclusion

As you have seen through this example, porting your UWP app to Windows on Arm is generally easy. There can be some issues with dependencies and libraries, but more and more of them are producing Windows on Arm versions. Many Open Source projects are already compatible or may not require much effort to get them going, if they are a dependency.

And once the dependencies are sorted, it is easy from there. Target Arm64, build, and deploy.

It is do-able and worth it for the performance improvements.

Learn more

The following resources provide more Windows on Arm and UWP information:

  • Porting Apps to Windows on Arm
  • Arm Windows on Arm Documentation
  • UWP
  • UWP Windows on Arm

Learn more about Windows on Arm

Sign up to the Arm DevSummit technical sessions where you will learn more about developing, deploying and debugging for Windows on Arm .

Sign up to Arm DevSummit

Anonymous
Architectures and Processors blog
  • Scalable Matrix Extension: Expanding the Arm Intrinsics Search Engine

    Chris Walsh
    Chris Walsh
    Arm is pleased to announce that the Arm Intrinsics Search Engine has been updated to include the Scalable Matrix Extension (SME) intrinsics, including both SME and SME2 intrinsics.
    • October 3, 2025
  • Arm A-Profile Architecture developments 2025

    Martin Weidmann
    Martin Weidmann
    Each year, Arm publishes updates to the A-Profile architecture alongside full Instruction Set and System Register documentation. In 2025, the update is Armv9.7-A.
    • October 2, 2025
  • When a barrier does not block: The pitfalls of partial order

    Wathsala Vithanage
    Wathsala Vithanage
    Acquire fences aren’t always enough. See how LDAPR exposed unsafe interleavings and what we did to patch the problem.
    • September 15, 2025