Windows Phone 8.1 Preview: Universal Apps

One of the more intriguing aspects of the recent Windows Phone 8.1 leak is that this platform might support the creation of so-called Universal apps, similar to those in iOS, that run across both tablets (Windows RT 8.1 in this case) and smart phone (Windows Phone 8.1). With due deference to the game "Portal," however, I can report that Universal apps are a lie. At least from what I can tell.

To understand what I mean, you need to understand a bit about Visual Studio, Microsoft's awesome software development environment. In Visual Studio parlance, each project you create represents a single application (or similar unit), like a Windows Phone app, a Windows desktop application, or whatever. But Visual Studio is also a team-capable and professional developer suite. So each project you create is also contained in something called a solution. And you can have multiple projects within a solution. For example, you might create a complex application that includes a project for the application itself plus separate projects for a service library, class library, or whatever. And each could be written in different languages, and by different developers.

So what's this Universal app stuff?

You may recall that the possibility of Universal apps was first raised when a developer leaked information about Windows Phone 8.1 recently. I wrote about this in Windows Phone 8.1 Feature Set Possibly Leaked, noting that he described "the leaker claims that developers will be able to create so-called Universal apps with HTML and JavaScript that can run on both Windows 8.x and Windows Phone 8.1." The HTML/JavaScript bit is indeed new to Windows Phone 8.1. But Universal apps? No.

With previous versions of Windows 8.x/RT and Windows Phone, Microsoft advised developers who wanted to duplicate an app across each platform that they could create Visual Studio solutions with separate projects for Windows 8.x/RT and Windows Phone apps. There could then be a third project that contained shared code, since there is some crossover between the APIs used by the different platforms (WinRT for PCs and tablets and WinPRT for Phone).

With the SDK that will accompany Windows Phone 8.1, Visual Studio picks up what appears to be a set of new project types for something called Universal apps. There are separate projects for a blank app, a hub app, a portable (i.e. cross-platform) class library, and a portable Windows Runtime component. But all this really is is a formalization of Microsoft's previous advice. What you get, as before, is a single solution with separate projects for the Windows 8.x/RT app, Windows Phone app, and shared code.

In other words, nothing has really changed. Here's how such a solution—with two separate apps and a shared code module—looks in Visual Studio.

The ability to code Windows Phone 8.1 apps in JavaScript (really HTML/JavaScript/CSS) is new to Windows Phone 8.1 and mirrors how this works in Windows 8.x. To me, that is the real story here, that developers can create native Windows Phone apps now with a very familiar set of technologies. That said, in the leaked SDK, the Windows Phone bits run in the Windows 8.x emulator for some reason. So there's apparently still work to be done.

Will the Windows 8.x and Phone APIs, SDKs and platforms merge even more going forward? Of course. But I wish Microsoft had held on to the name Universal apps for the time when such a thing was truly possible. That name suggests something far more than what is possible today, or in this coming release.

Discuss this Article 27

Even in a truly universal situation, you may wish to keep your phone UI (small screen portrait presentation) in a separate project from your tablet/Windows UI (larger screen, landscape presentation). Ultimately, it could compile to one binary that can be loaded on either device, and the "correct" presentation layer chosen at runtime. Theoretically anyway.

Well, i myself don't call this is a lie, in fact, it's a good code design for us to develop on both platforms. You can share your controllers, but the ui and handle for the ui must be separated, each of the ui served different kind of screen. You cannot force the mobile like wp to run compactible with the desktop app, right?

i know ios can, but then the developer still need to write an ipad version. No one wants to use the scale stuff with the app

I'm not sure that you need separate UI and base code just because of different screen sizes. My WinRT app strips away UI elements as the size shrinks, whether that's the screen size or being snapped. It would be possible to do that all the way down to a 4.5" screen.

Probably the best approach is for MSFT is to have the concept of an "app" separate from the actual executable (lets call it "MyApp"). MyApp runs on phones, tablets, laptops, xbox, and desktops. The actual exe that's installed could be different based on the device type or it could be the same. That's up to the ISV to decide. Users only buy MyApp one time.

It seems logical. The ideal is to get to the truly 'Universal App" and this is a step in that directly. The setup should certainly make the development of both Windows and Windows Phone apps easier, and I would imagine there will be more shared code in 8.1 than there was previously. So this is progress, for sure.

But Paul, why do you say It's a lie if you don't understand much about programming? Such a harsh statement.

Some guys that leaked slides of the SDK commented that MS dropped Silverlight and now they are using winrt for the UI. So you can reuse not only "business logic", also UI code (Converged controls). The slide says "80% the same XAML". XAML is the language used to construct the UI.

For simple apps you could reuse 100% of the code on the two projects, the same app for both stores. But for most apps It make sense to adapt the UI to the form factor with a different layout and specialized widgets. For example the panorama control is beautiful in the phone but in a 10-inch tablet doesn't make sense.

It is not a lie but it is also not entire true given how they setup that SLN file.
1) The new universal project lets you separate the UIs, which unless you’re mediocre you’d do anyway. Yes some people “THINK” that it would be great to have a windows phone app on a tablet…until they do. Then you realize a phone app is so badly suited to a tablet that you’ll toss the tablet out the window. This is particularly bad with windows phone because Microsoft doesn’t scale windows phone apps to DPI in a smart way and you end up with a similar effect as the jarring experience of a full screen metro app on a 24 inch LDC.
2) The real lie is that the runtimes are different and the way they configure that solution is fundamentally incorrect. They assume your shared code will not run into problems where it has to call a platform API that isn’t available. So technically there should be two more projects, one for backend non UI code which is available only to the WinPRT and other that is for WinRT. Why not include this code in the first two device dependent project? Because you’d end up with a circular reference which is poor design for apps.
3) What developers really want is a unified runtime, class libraries, and device abstraction which can be used to run the same code on any device. But this would mean WinPRT needs to become a complete set of WinRT. There will never be a way out of the UI issues, but at least doing two UI projects is a lot simpler, and some devs may want to do it anyway as it lets you focus on the experience better than with one size fits all. What MSFT is showing isn’t this. They are nowhere near this.
4) In order to properly create a true multi-MS-platform solution one has to layout the SLN in the following way.
a. One project for each UI. WPF, WinRT, WinPRT. This will contain the XAML and globalization resources, plus any multimedia resources.
b. One Core project which contains all the common app logic which also exposes an interface (contract) which allows the core code to call out to runtime specific methods which will be passed in by clients of that core (WPF, WinRT, WinPRT) by means of using that interface so that it can avoid depending on a specific framework.
c. Implementations for the core interface above for each runtime type (.NET Desktop Framework, WinRT, WinPRT) which are injected into the core (using a technique called dependency injection) so that the core will be truly disconnected from the framework.
5) MSFT could setup the project as above but there are a lot of pitfalls. The biggest is that unless you’re using .NET, you’re going to have a tough time realizing the design above. .NET objects marshall easily if you also used .NET objects in your other projects. But if you used any of the COM crap, or winJS, may budah help you. Say nothing if you chose to use the horrible WinRT components. The other problem is the stupid use of ASYNC everywhere in WinRT and that .NET prefers the TASK approach yet WPF predated both. WinRT over uses async programming and even when they provided helper classes for going from Task to Async Ops, the code looks like crap. IMO the entire thing needs to be scrapped and unified into a single Async pattern which interops nicer with older frameworks.

And BTW, what does this tell us? Those of you who want a new version of Win32 based UIs, need to get over it: MSFT doesn’t care. Learn WinRT for when that stuff runs in floating windows, there will not be a need for Win32 based UIs…ever. And if you know the mess that crap is with an architecture that belongs in the 80s, you should be happy. Win32 is the worse API probably in the history of mankind.

No, Win32 is very useful as is -- a general purpose OS. Third parties tailor it to specific language or application needs with frameworks. By putting a specific framework on it (WinRT) and calling it the "new Windows", they've decided which languages and program styles are favored. And their favored app target doesn't include programs like mine or most other Win32 programs.That's a *huge* mistake. It will kill the company eventually.

"You realize that all your wonderful APIs (.NET, WPF, WinRT, etc.) all sit on top of Win32, right?"

WinRT sits on top of Win32 UI components on Windows 8.x, but not on Windows Phone. The Win32 UI stack is far too interconnected, internally in all its components, and with other services in Windows. When designing WinRT, the Windows team have taken care not to allow Win32's limitations and assumptions to leak into the design: there is no interop between Win32 and WinRT, unlike all the APIs that have gone before.

Windows Phone 8.1 has taken so long because they've had to deal with the issue that the Windows 8.x development team glossed over: having to either unpick the mess of Win32 to get just the bits that they need, or to reimplement the features without using the legacy code at all.

The problem with Win32 - the reason that Microsoft is implementing a new API at all - is that it is very hard to use. Its design is basically 25 years old, and was designed for efficient implementation, not programmer productivity. Attempts - like .NET Windows Forms, WPF or Silverlight - to cover up the beast and make it more friendly ultimately have failed, because they inherit aspects of Win32's antique design. In each case the designers left 'escape hatches' to get down to Win32, for developers to implement things not catered for in the new API, but that meant that the new API still had to behave like an old Win32 application in most ways.

WinRT is an attempt to break that cycle: to define a new API that can, ultimately, *replace* Win32. That's a big job, and Microsoft don't have the luxury that Apple had of spending 6 years developing Cocoa in private (in turn, on top of NeXTStep's core). Microsoft are also *very* aware of how much time and effort was wasted on Longhorn, their last attempt to change Windows' fundamental APIs, with too large a scope and too much change at once making it impossible to stabilise the APIs or debug applications properly. So, to limit the scope of work, WinRT is initially focussed on the app store, full-screen model. Some limitations are also, I believe, deliberate: the sharing model is designed not to require plug-in code, which is a major source of malware and unreliability.

WinRT has projections into C/C++ via COM-like rules of vtable layout, interface selection and reference counting (optionally using language extensions to cover the reference counting). It also has projections into .NET, and into the HTML+JavaScript+CSS environment. That covers three major development platforms, and it should be possible to produce others that sit on top of one of those.

I would expect that all three projections will be available for Windows Phone 8.1.

"there is no interop between Win32 and WinRT, unlike all the APIs that have gone before"

You're kidding, right? WinRT uses Win32 to do all its work. For example, all of the WinRT internet functionality uses Win32's WinInet APIs ... and it sets the gzip flag which screws up my programs when doing a GET with a "range-bytes" header (there's no way to tell WinRT not to set the gzip flag). You also can't turn off WinInet's caching, which screws up repeatedly accessing the same internet URL to retrieve new data.

As for WinPRT, have you done a perf test of your app on an actual phone? I have a XAML+Direct3D WP8 app. When I do a perf test on my HTC 8X and capture the perf trace during graphical activity, guess where most of the time is spent? The D3D driver *and* GDI32.DLL. This is on a physical Windows Phone. If I recall correctly, GDI32.DLL is part of that nasty Win32 API.

Also, I love the part where you say, "[Win32] was designed for efficient implementation, not programmer productivity". Efficient implementation is *exactly* what you want in an OS API. The very "productive" WinRT API results in 250X perf hit over Win32 in file handling due to WinRT's horrible FileBroker. The "productive" XAML layout engine is very slow for anything more than a few buttons on a WinPRT page.

MSFT has sold people a bill of goods on the entire RT family (WinRT and WinPRT). All of the failed efforts in the 2000-2010 timeframe (WPF/XAML, managed code, etc) have been bundled up in WinRT/WinPRT. It's no wonder it has failed miserably.

You can see the technical differences in the comments above, regardless of their complaints, I think Paul's criticism stands. A true 'universal app', such as Android has I suppose, would be coded once and run on both platforms.

Yes, the UI should usually be different, but not necessarily, so why not allow a true single app? Such as in a business, we could have 8" Windows 8 tablets and 6" phones and they're hardly different in UI. In which case, it would be nice that it was 'write once, run anywhere'. And of course getting an app into both store easily (universal app hypothetically) would have value and the second UI could be tailored after the fact if sales/complaints occurred.

Right now, for technical reasons I think neonspark covered well, that isn't possible.

But it's also the case that Microsoft is in the worst position to do 'universal apps' despite their dreams of 'Windows Everywhere' or '3 screens and a cloud' BECAUSE their platform has 4" phones and 30" monster desktop. Even 20" touchable screens or bigger (where's my Surface table? ha).

This is what's confusing me ... you claim that these middle steps to the end goal are epic failures. What should MS do instead? Wait until step B is achieved so that everyone can complain MS isn't doing anything to ease the pain points? They shouldn't make it easier to use their products?

What really ought to happen is to have a Universal app type that comes with three pages by default: MainPage.xaml, MainPhonePage.xaml, and MainXboxPage.xaml. Identical back end, but with different page types for different screen sizes.

But this does save a bit of time on something you would probably do anyway. Do you know if this works on Visual Studio 2013 express? Because you don't get portable class libraries in express, so if this worked in express, it would actually open up possibilities where there was once none.

Can I run a Windows Phone 8.1 app on Windows RT? No, so its not universal.

We van do that in iOS. The benefit of that is mostly to the consumer. You see, if a consumed pays for an iOS app for the iPhone we can install it up to 5 devices weather iPhone, iPad or iPod.

Some apps aren't available in iPad format yet, but still the consumer can use it of he wishes. It smooth the transition.

On another note some apps are available taking advantages both the iPad and iPhone real state. I think in these situations there are actually two builds. But the point is that even in these cases still the consumer does not need to pay twice in most cases. Is up to the developer to decide, but a lot of them don't.

The bottom line is that if MS wants to compete head to head, not only need to provide developers a way to sort the challenges of cross device development from a technical perspective but also from a consumer perspective.

So talking about universal apps when all we have is shared code is actually ridiculous, but better then nothing.

Actually, I don't see why this consumer-paid type of situation could NOT be used in RT and WP apps. This does NOT mean universal code, but a universal "app family" that through the MS profile used to purchase the app would allow multiple installs.

For example, Rovi - available on Win RT/Windows 8 and on Windows Phone X. To keep my Xbox Music, my Outlook, my Xbox video and Games and Gametags synced, I use the same ID on all devices, from my Windows 8.1Pro laptop to my Xbox 360 to my phone. So I purchase Rovi for my phone. Why couldn't he ID when I go to purchase for my desktop note that I have x number of installs available, regardless of device? This is what a unified Store could bring to the mix. The Windows Store already allows me to install on numerous devices, why couldn't it check when I go to purchase the phone app to do the same? Chalk it up to one of my several installs on that account.

For the seller, It would also possibly offer the chance for tiered pricing. Single device (phone $.99, tablet $2.99) or a multi-device license (phone $2.99, PC/Tablet $4.99) before you jump on me for crazy pricing, this is just for demonstration purposes.

Back to my Rovi example, everything is synced to my twitter ID anyhow, so it is only making it attractive to the buyer to use apps from the same developer for familiarity and features.

On Windows I can have a universal binary that runs on both x86 Desktop PCs and ARM tablets. You can't do that on iOS/MacOS at all, even just as "shared code", so your argument that what windows offers is "ridiculous" is itself ridiculous. A tablet is closer to a desktop PC than it is to a phone, so the Windows division actually makes more sense.

I can't run Windows Phone apps on Windows RT. However, I CAN run Windows RT tablet apps on my Windows 8 desktop PC. That's like being able to run iPad apps on a Mac. And it's very handy indeed.

The reason for this difference is that Apple considers a tablet to be a big phone, whereas Microsoft considers a tablet to be a small computer

Windows apps actually have a very good cross-device framework -

1. The developer decides on how many devices a user can install a paid app. iOS allows 5 devices, whereas Windows 8.1 devices (tablets, hybrids, desktops, laptops etc) can be whatever the developer decides. So it might be 3 devices, or 10 devices, etc. I think the limit is 81 devices.

2. The Windows app store framework allows each app to be published in both trial and paid/free without having to make two separate apps. The app framework automatically handles the trial licensing. So you don't need to publish a separate trial app and a separate paid app - you publish one app and you decide whether to allow trial usage or not, and what kind of trial restrictions are imposed (if any).

So, contrary to what you say, Microsoft has a very good cross-device platform. It's just that it hasn't been extended to Windows Phone yet. But that's coming soon.

I only downloaded the WP81 SDK docs so I haven't actually tried to write a "Universal App". With that in mind, it looks like there are two new app infrastructures: Silverlight 8.1 and "WP Store app using XAML (8.1)". SL 8.1 is an extension of the current WP8 app platform (runs in a new host with new rules apparently).

The "WP Store with XAML" platform is the universal one. It looks like it isn't limited to just HTML/JS as earlier reports stated. It uses the same namespaces and controls as WinRT. That's the big deal. For example, instead of LongListSelector you use WinRT's Listview or GridView. For Direct3D you use WinRT's SwapChainPanel instead of DrawingSurface. Devs will be able to share far more code between WinRT81 and WinPRT81 than between WinRT8 and WinPRT8.

Also, I found what appear to be a couple of references in the docs to accessing XAML elements from C++. If that's correct then it may be possible to write a XAML WP81 app entirely in C++. The docs are in such a primitive state that it's difficult to figure out.

This is also true in Android. While some apps may not be perfect (phone apps on a tablet) I have found them to plenty usable and better than no app at all (very often they are things like banking, travel, etc. where it's not necessarily critical to have a tablet specific app). The app is almost always better than struggling with most companies mobile site. Also, unlike windows, Android actually does an excellent job of scaling to different resolutions and screen sizes (everything from 240x320 all the way up to 2500x1600 (or somewhere around there for the Nexus 10 and the new Galaxy S5 is rumored to be that high density). I have had no problems moving apps from my 1280x800 Nexus 7 2012 to my 1280x720 Galaxy S3 to my 800x480 Droid Inc 2 to my 1920x1080 Nexus 7 2013 and LG G2. I never really notice that much if its a phone app or a tablet app.

Maybe you're looking at this too much from a developers perspective (and I say this as a developer). Maybe Microsoft is planning for a way for a user to purchase an app on either Windows Phone 8.1 or Win 8/RT, and have the same app available on the other, without having to re-purchase the app. So from a user's perspective, the app is "universal". Possibly using the Universal App template in Visual Studio is the required or recommend way to structure your solution in order for the app to be approved as a Universal App. That's my guess anyway.

I was under the impression that we were talking about Windows Phone vs Windows RT and not Windows RT / ARM vs Windows 8 / Intel.

The problem of Windows RT, in particular Surface 2 is that its not a good tablet for today's standards. You see, it has been told and retold, people already have tools to be productive!!! The PC (weather Windows, OSX or whatever) are excellent. What people did not have and MS seams not to get it at all is something to get to content quickly and anywhere, to read, play it and manipulate much like a book or a piece of paper. That is what a Tablet is for. If you look at Surface 2, clearly it was done to imitate a PC, so much that it does not work at all nicely vertically. Anyone that have used a Tablet like an iPad knows how nice it is to browse the Internet, Read stuff and all the rest that a PC is not so nice in a vertical format. People just turn it to play videos, play games.

On another note, as I said, the universal app concept needs to cross boundaries back to the consumer. Even though MS allows developers to do what they please, it's not clearly why developers need. The idea of 5 devices as established by Apple is brilliant and in the end of the day it turned out to be good for devs too. Why because it helped growing the user install base with something that it still starting.

The problem of MS is lack of VISION, VISION, VISION. As such at the minimum wind blown the whatever they called VISION goes out of the WINDOW. That happened with X1 and its happening with W8.

When MS get's the Tablet concept it is obvious that the horizontal aspect ratio only its not a good option at all. Hopefully in the future that will be a Surface / PRO and Metro will be changed to work well Vertically too.

By then things may also have improved in the completion. Honestly MS is IMHO wasting time due to terrible decisions. There is simply very little consumer VISION leading to lack of FOCUS.

People want tools to do stuff that they can't do well already. Not the same tool reengineered over and over and over and over and over again simply to present in the end of the day, the same thing to do the same things with minor changes.

Windows 7 its great, its more robust, consumer less resources and has a prettier UI. But in the end of the day people don't do much more with it then they did with Windows XP neither they do things much differently for the better.

Windows 8 was supposed to be an hybrid. But it seams they stuffed a tactile experience on a PC. Now that is not what people expect from a Tablet. They just don't get it IMHO.

I have Surface Pro 2. To b able to use the pen is great. But common, horizontally? I need something wider working vertically, like a sheet. There is a reason why people write that way for a very, very long time. It's pure arrogance to throw out the experience of centuries and come up with this form for everything.