Universal Apps: What are they and how are they good for developers?

[This article was written by Andy Wigley, a Technical Evangelist that works in the Microsoft Developer Experience (DX) group in the UK. If you have any questions feel free to follow him on Twitter @andy_wigley, or view similar content on our developer site.]

In the world of mobile computing devices, no one operating system or development language enjoys complete dominance. iOS, Android (and its offshoots), and Windows 8/Windows Phone are the big three, but app developers also build for Blackberry, Tizen, and others - all of these have their place and their supporters. For a company looking to build a smartphone or tablet app, this fragmented landscape adds up to a headache: how do they build a mobile app running across more than one of these without incurring significant development costs associated with building the app individually for each target platform?

Universal apps, that holy grail of ‘build once, run anywhere’! Business has been looking for such a solution for a long, long time and they’re still looking. The problem is that each mobile device platform – quite rightly – offers a differentiated user experience to users. Nobody wants a world where every device sold is identical in every respect. Users want a device that allows them to express their individuality and is a tool for them to pursue their own interests, and the industry satisfies that demand by offering different devices that interact with the users in unique ways. Users get choice and can select the device and operating system that appeals to them.

For developers of course, this device diversity is a problem. Since each device operating system is different, each has its own development tools that allow the creation of apps that shine on their platform. There are a number of tools that offer cross-platform solutions, such as Apache Cordova which is a set of device APIs that allow a mobile app developer to access native device function such as the camera or accelerometer from JavaScript. Coupled with a UI framework such as jQuery Mobile or Dojo Mobile or Sencha Touch, this allows a smartphone app to be developed with just HTML, CSS, and JavaScript. Visual Studio tooling for this, which was announced recently at TechEd 2014, called the Multi-Device Hybrid Apps for Visual Studio CTP which you can download from the Microsoft Download Center, or you can watch the session on this on Channel9 from the recent TechEd 2014 conference.

Even though solutions such as Cordova are good, by using them you are inevitably accepting some trade-offs that come with developing for multiple platforms. You are targeting a breadth of devices, rather than creating tailored, optimized experiences for each device. Facebook famously tried to develop a family of new apps using HTML5 but dropped the development and went back to developing fully native apps for each platform, as that offered them the best way of creating optimized experiences for each platform.

Another popular cross-platform development solution is Xamarin, which allows you to use your .NET C# development skills to build apps for iOS, Mac, Android and Windows. This toolset takes the approach of allowing you to write all your business logic just once using your favorite development language and libraries, C# and .NET, and then to write the UI layer individually for each platform. Here, at least in the UI, you are creating an optimized experience using the native UI technologies of each platform, albeit at the additional cost of having to build each UI.

Xamarin recently announced V3 of their product which includes a new cross-platform GUI development technology called Xamarin Forms. It remains to be seen how effective this is in providing a great user experience on each platform, and at what point the inevitable compromises of a cross-platform solution would lead you back to choosing to create a pure native UI.

Windows 8.1/Windows Phone 8.1 Universal Apps

In March at the //build/ 2014 conference in San Francisco, Microsoft unveiled Windows Phone 8.1 to the world. The big deliverable of this major update is convergence of the developer platforms for Windows 8.1 and Windows Phone 8.1. Common APIs in the Windows Runtime went from around 5% in Windows Phone 8.0 to over 90% in Windows Phone 8.1. The SDK is released as a part of Visual Studio 2013 Update 2 and adds in new tooling for the creation of Universal apps targeting Windows 8.1 and Windows Phone 8.1. If you want to watch an overview of the main features of this release and a demo of creating a universal app, see the first video of my Building Apps for Windows Phone 8.1 video series on Channel9.

A few commentators mistakenly reported these new Universal apps as being cross-platform, allowing apps to run on Windows, iOS and Android. They’re not – these are Windows 8.1 and Windows Phone 8.1 only, but they do allow you to create rich, tailored, optimized experiences for both Windows Phone and Windows Tablet/PC. When you create a Universal app solution in Visual Studio, you have a Windows 8.1 project which outputs an app package for Windows, a Windows Phone 8.1 project that outputs an app package for Windows Phone, and a Shared project which is where you put all items that are common to both platforms, which should amount to a very high percentage of your code and assets. You can create Universal apps using HTML with JavaScript, XAML with C++, or XAML with C# or Visual Basic.

The question of whether to develop a single UI layer that runs or both, or whether to build platform-specific UI is an interesting one. It is certainly possible to build a single UI from a technical standpoint because the XAML and the UI controls are (on the whole) the same, but we would advise that this is rarely a great idea. A tablet is not a phone; each provides a different user experience. You usually use a phone in portrait orientation, but a tablet in landscape (at least those that are 9” or above) and a tablet screen offers much more display space that you can use to communicate more information than a phone screen. Phones are often used for quick information snacking, while tablets may be used for more leisurely information consumption.

So form factor and usage does matter, and you should think carefully before offering the exact same display on phone and tablet. You should build a great UI optimised to each platform, though that doesn’t mean that you have to build your UI from scratch. You can still share lots of UI code, by creating user controls, and sharing data templates (layouts) and assets.

Benefits of Universal Apps for the developer

Well, this is a no-brainer really. Build your app out once, run it on both phone and tablet – what’s not to like? You do have to craft your UI for each platform, but most of your code and logic is common. And by doing this, you are extending your potential user base from not just phone or tablet/PC owners, but to phone *and* tablet/PC owners – a potentially massive user base of many millions.

There are a number of other advantages as well that are not quite so obvious:

  • Shared State
    If you write your app to store settings into RoamingSettings or files into the RoamingFolder and you keep the volume of that data below 100KB, these items are automatically synced across all the users devices. This means that details of their last items, last searches, most recently used ‘things’ – whatever makes sense in your app – is flowed across the users’ devices. So your user can start a task on their phone using the phone app, then shortly after, pick up their tablet and using the tablet version of your app, pick up right where they left off. This is a great feature that users will just expect, so make sure you plan on roaming appropriate data in your universal apps.
  • Shared entitlement
    When a user purchases your app on one platform, they can download the corresponding app on the other platform for free. The Store apps will detect that the user is purchasing an app that they have already purchased for the other platform, and no charge will be levied.
    A developer can choose to opt out of this when submitting apps to the store, but I would suggest that you should not do this unless the phone app offers substantially different capabilities to the tablet/PC app or vice-versa. To insist on a charge on both platforms for what the end-user will perceive to be essentially the ‘same app’ will probably just engender bad reviews and user resentment. If you *do* offer substantially different capabilities between the two versions, it is probably a better idea to charge for those features through in app purchase.
  • In app purchase shared
    Speaking of which – in-app purchase durables (i.e. items the user purchases and owns forever, such as levels in a game) are shared across phone and tablet/PC so the user only has to purchase once to get usage across all devices. Consumable in-app purchase items (such as usage tokens) remain associated with the device where they were purchased.

To learn more

If you want to find out more about how to build a universal app using XAML and C#, and learn strategies for sharing code and XAML, please take a look at my session from TechEd 2014: Build for Both: Building Shared Apps for Windows Phone and Windows 8.1

Report a problem with article
Previous Story

Lumia 635 disappears from Microsoft Store, a day after preorders open

Next Story

Google accidentally posts images of next version of Android

14 Comments

Commenting is disabled on this article.

@greenwizard88: 'Major fluff'! I hope not. That wounds me, I've never been accused of that before :-).
If you want some deeper stuff, please see my blog http://andywigley.com . But my intention with this piece was to position Windows/Windows Phone 8.1 Universal apps against other options that may target more platforms, but which involve more compromises, and to dispel some of the myths about what they are. Sorry if it missed the mark for you.
Check out my TechEd session referenced at the end of this piece - I go much deeper into real tips and tricks on building universal apps for Windows/Windows Phone.

MS already adopted Bootstrap so they know that is possible to create an interface once for different kind of devices.

Also, i don't mind working with 8.1 and WP, i feel at home developing with C#. However, XAML is a PITA.

I just started updating my app last night - literally, I was up until 2am - and I'm finding that the state of documentation is *much much much* better than it was last year. I already have the "home screen" of my app done, and I was able to just fly through the paces. I'm looking forward to this, enough so that I may have to go buy another Surface to test my app on 8-)

Having said that, this article reads like major fluff. Really MS?

Microsoft's biggest problem is that until very recently (and even still), they had to developer TWO applications... one for phone, and one for tablets.

The goal here is that the developer only needs to develop ONE application to run across all of Microsoft's platforms... Phone, Tablet, Laptop, Desktop, and even Xbox potentially.

Providing one set of unified APIs, a set of unified libraries, and a unified development environment will be a big win.

Even bigger? The ability to use 3rd party tools to easily generate iOS and Android versions as well, all based off the same code-base (Xamarin).

Microsoft's story here is not yet compelling. But it's getting there. And soon will be OVERWHELMINGLY compelling.

Microsoft already has OneDrive which works across platforms, unlike the competition ... with more and more applications and services that run across platforms, Microsoft is really positioning itself well. Developers can come to Microsoft, get the best tools available, and distribute their apps the most widely.... and thus make the most money.

Win-Win-Win

We just have to struggle for another year to get there, and hope it's not too late.

pmbAustin said,
... and even Xbox potentially....

eventually
pmbAustin said,
Microsoft's story here is not yet compelling. But it's getting there. And soon will be OVERWHELMINGLY compelling.

agreed.

Edited by deadonthefloor, Jun 24 2014, 8:04pm :

Its interesting that a lot of the early focus seemed (to me at least), focussed on how easy it was to just re-use your UI across devices - that was something shown on centre stage at //build for example.

To me the challenge has really been at the backend; do the file download handlers match across WinPhone and WinRT for example. Building a new UI is something I'd probably want to do anyway because as the article states in the nice info graphic, form factor matters.

Besides, not everything migrates nicely even if you do try a 'life & shift' approach, so you're always going to spend some time at that layer.

Universal project templates in VS2013 are great, but again its the bits in the backend that catch you out. I use SQLite for data storage in my app, there are WinRT and WinPhone versions, but not a Universal version; my Universal Model project can only reference one of them so it's not really universal.
Now if I could somehow make references dependent on build platform, that would really help this situation, but I've not found any means of doing that unfortunately.

The obvious good stuff is really at the user layer as the article states, I love the idea of data roaming and purchase sharing.

The 90%+ API convergence for WinRT on Windows 8.1 and Windows Phone 8.1 means that you can really share *a lot* of code now. As long as you adopt good architecture such as MVVM and keep your View layer slim, you'll find that most of the rest of your code is common.
There are exceptions of course - the '...andContinue' methods for things such as the FileOpenPicker or WebAuthenticationBroker which have had to be adopted on Windows Phone in order to support low-memory 512MB devices, and the need to handle the back key properly on Phone (though the NavigationHelper class you get if you add a Basic Page to your project helps with this).
As far as SQLite goes: SQLite-Net already works across Windows 8.1 and Windows Phone 8.1, and SQLitePCL just yesterday announced support for universal apps: http://aka.ms/SQLitePCLUniversalApps . SQLite-WinRT will follow - when I get around to it :(.

I hope the Apache Cordova is not going be the standard. I hate JavaScript.

For now I stick to universal Windows apps, will get a Xamarin license when my student life is ready for that. (Yes, even the $198 student offer is a no go.)

Niekess said,
I hope the Apache Cordova is not going be the standard. I hate JavaScript.

For now I stick to universal Windows apps, will get a Xamarin license when my student life is ready for that. (Yes, even the $198 student offer is a no go.)

Apache Cordova is crap in my opinion too. Not because I hate JavaScript either but due the fact that your apps run inside a web browser control and are severely crippled. Also as soon as you need to use any sort of third party libraries and SDK's (for advertising for instance) things get very difficult very quickly.

With Xamarin on the other hand, if you are a C# developer you can truly share a huge amount of your code base and with the recent introduction of Xamarin Forms, even the majority of your mobile UI. Combine that with universal Windows apps and the C# ecosystem is looking better and better each day. I wish Microsoft would simply buy Xamarin. They already have certain licensing deals for MSDN subscribers but unfortunately only for the guys who shell out $5,000 or more (ie. not available for BizSpark or DreamSpark customers).

Obry said,
I wish Microsoft would simply buy Xamarin.

That's the last thing the dev community needs.

Xamarin managed to support Google Gear SDK within hours of its release.
If MS owned the toolchain, how long do you think it would take them to do the same?

deadonthefloor said,

That's the last thing the dev community needs.

Xamarin managed to support Google Gear SDK within hours of its release.
If MS owned the toolchain, how long do you think it would take them to do the same?

I agree, Microsoft should not buy Xamarin. They need to stick with their own vision to support all others SDK quick.

Microsoft should create an extremely close partnership with Xamarin. I hope to see a license of Xamarin included with MSDN subscriptions. I bet this will work out great for both parties. Developers will choose quicker for a subscription since it supports all kind of platforms, also will Microsoft and Xamarin see an increase with users.

deadonthefloor said,
Xamarin managed to support Google Gear SDK within hours of its release.
If MS owned the toolchain, how long do you think it would take them to do the same?

All due respect but how many people do you think give a rat's ass about Google Gear SDK vs being able to write native cross-platform apps in C# using Visual Studio...

Obry said,
...

That was just one example from build conference about how agile Xamarin is compared to (historic) MS. Yes MS release cadence is speeding up, but the fact remains Xamarin would be slower to release inside MS than outside.

This is why Windows first + Xamarin is the best way to cover the technology landscape.

The reason you can't do it all in VS is because Apple still requires you to buy their dev tools, and Xamarin runs on OSX where VS does not.