The Challenge For Universal Windows Apps

The Challenge For Universal Windows Apps

At its Build 2014 developer conference today, Microsoft announced the concept of “Universal Windows Apps”: code that can run both as a desktop Windows app and on Windows phone devices. It sounds appealing for both developers and consumers, but the reality is a little messier than the vision.

Picture: Getty Images

The idea that Windows and Windows Phone should be able to run the same apps is hardly a new one: the fact that both use the same tiled ‘Modern’ interface made an attempt as such a move almost inevitable. The forthcoming release of Windows Phone 8.1 is supposed to bring that vision much closer to reality.

[related title=”BUILD 2014″ tag=”build-2014″ items=”9″]”With the Windows Phone 8.1 release, we’ve bought the new Windows runtime to phones,” David Treadwell, corporate VP of the operating systems group, said during the opening Build keynote. “Now you can use common code to produce apps across PCs, phones and tablets.”

The phrase “common code” reminds us that we’re not talking about a truly universal app, a point which Microsoft also emphasised in its blog announcement:

Universal projects allow developers to use approximately 90 percent of the same code, a single packaging system, and a common user interface to target apps for phones, tablets and PCs.

90 per cent of the same code is a welcome improvement on lower percentages, but the final 10 per cent could still prove to be painful for more complex apps. During the keynote, Kevin Gallo gave a demonstration of exporting existing Windows app code using Visual Studio 2013 Update 2 to produce a near-identical Windows Phone app. The basic export is simple enough; it’s the tweaking of elements to account for different screen sizes and input options that takes the time.

One big selling point for the universal approach is that it also applies at consumer level: if you purchase an app to run on your PC, it can also be available on your phone for no extra cost. A special symbol on the Windows Store will indicate apps which take that approach. In-app purchases can also be shared across apps on different form factors.

Developers aren’t forced to take this approach: if you want to, you can continue to sell different versions for phone/tablet and for PC. I suspect this won’t be popular though: it’s hard to justify charging separately for identical-looking apps, for starters.

Universal apps are a good idea, but there’s one big issue. A universal app will run on either the distant #3 mobile platform (Windows Phone), or on the dominant Windows computing platform. The latter is the bigger target, and yet the usage of Modern Windows apps (as distinct from the familiar Windows desktop workhorses) is still relatively low.

One way Microsoft is addressing this is by trying to make Modern apps more appealing to users who don’t have touch screens (the vast majority of them). The soon-to-arrive Windows 8.1 Update will allow Modern apps to be pinned to the Taskbar, and will add a title bar when they’re used with a mouse. A subsequent Windows update will also offer the option to run Modern apps in floating windows. Also promised in the future: the ability to shift universal apps to the Xbox as well.

When that happens, it will make building Modern apps more appealing for developers. But since we don’t have a timeframe for that change (it seems unlikely until 2015, when it might form part of the rumoured Threshold update), it’s not exactly clear that coders will be clamouring to make the switch just yet.

Disclosure: Angus Kidman travelled to San Francisco as a guest of Microsoft.


  • Modern apps are a far cry from proper Windows applications. So many of them in the MS Store are very badly written and don’t work well. It makes the whole W8 experience very poor indeed. Microsoft really needs to help developers create high quality robust apps.

  • What this didn’t mention (and what @willd was getting at) is the consumption of desktop code for WinRT apps.

    For line of business apps *only* (so sideloading, not in the store), desktop code will be able to be consumed by WinRT components, so in this case, yes, 90% of *all code* will truly be cross platform.

    As someone who loves the .Net platform, I’m in favour of this. There was a time when I was getting at hobby projects and lamenting the fact that some functionality (speech to text and vice versa) which had different implementations that were allowed/blocked in inconcistent ways between WinPhone8, Windows Desktop, and Windows Store (ie RT) applications.

    This bridges that completely, but for the UI, for LoB apps.

  • Remember when people were complaining about how most Android tablet apps are blown-up phone versions? Yeah. This just seems even worse. Even if they executed flawlessly and it worked just like their (ideal) demonstration, blowing up an app designed for 5″ screens to a corner of a 27″ monitor just sounds… very unpleasant to use.

Show more comments

Comments are closed.

Log in to comment on this story!