Universal Apps -- How Do They Work?

[tompkin]

I am just realizing gaps in my current knowledge about a number of technologies that Microsoft is introducing and was wondering if someone might explain something to me about Universal Apps. (Hopefully I won't be too long-winded).

 

A couple of scenarios come to my mind

 

********

1) From what I understand, a Windows 10 developer will be able to write an app on, say, a Windows Phone and it will run on any other Windows 10 device (tablet, phone, etc.)

I pretty much understand how that might work conceptually but I don't understand what the underlying layer is. Is the full "API" on Windows Phone as is on the desktop? Does it produce a "native binary" as we have known it in the past?

 

*********

2)The second seceneio I'm even more ignorant about. Supposedly, we will be able to compile an app for Windows Phone and then with very little effort produce a native Android app? How is this possible?

 

My understanding is with Java where there is a virtual machine running your Java program inside it. The virtual machine itself IS platform specific and does all the underlying machine-specific housekeeping chores.

 

My question is, again, how is a native Window app somehow going to turn into a native Android app? Won't their have to be some kind of "virtual machine" underneath it?  

 

Thanks!

[tompkin]

@DevTech, et.al., I will try to make this as short-winded as possible. I am not the most concise writer.

 

I believe that the big reason why it's been difficult for me to wrap my head around Universal Apps, and the newer technologies is that I stayed with Windows 7 and these newer 'bits' required Windows 8 to just play around with in Visual Studio. I decided to wait until Windows 10 because that was the future but I didn't want to sit around and twiddle my thumbs either.

 

I decided to branch out a bit so I began looking for something (as you say) that would be a good fit with my current skills and experience. I decided to learn Neo4j.

 

Note: This is not an advertisement for Neo4j, just an explanation of why I chose it. Neo4j is a graph database. It supports a number of languages including the .NET languages and even has a Visual Studio plugin. (I've used it in VS2013.) Every language calls the same underlying API so that is cool. I have been learning the "SQL" to the database and basically sending commands from a console. Now I am ready to use the database from a language. 

 

The one thing that has made me pause was that the most activity out on GitHub is for Java. My fear was that when inevitable problems crop up that I won't have quite the same pool of help as I would if I were programming in Java. There are a number of examples in Java also to help. I have finally decided to go ahead and use C# because I feel that it shouldn't be too difficult transferring the Java examples to C#. I also like C# more than Java. 

 

The reason for my original post was that I was trying to figure out what type of front end would be best for the future. I am not a big fan of HTML5, CSS, Javascript. That's just me. Different strokes for different folks. I knew that parts of .NET is going open source but I didn't know if, for instance, WPF (or XAML) would be able to be used on tablets, for instance. When I learned it, XAML was sort of the "code behind" for WPF. Wasn't sure how that was being handled today. 

 

So that's where I was coming from. Would be interested in comments, suggestions, or questions.

Thanks. 

[DevTech]

@DevTech, et.al., I will try to make this as short-winded as possible. I am not the most concise writer.

 

I believe that the big reason why it's been difficult for me to wrap my head around Universal Apps, and the newer technologies is that I stayed with Windows 7 and these newer 'bits' required Windows 8 to just play around with in Visual Studio. I decided to wait until Windows 10 because that was the future but I didn't want to sit around and twiddle my thumbs either.

 

I decided to branch out a bit so I began looking for something (as you say) that would be a good fit with my current skills and experience. I decided to learn Neo4j.

 

Note: This is not an advertisement for Neo4j, just an explanation of why I chose it. Neo4j is a graph database. It supports a number of languages including the .NET languages and even has a Visual Studio plugin. (I've used it in VS2013.) Every language calls the same underlying API so that is cool. I have been learning the "SQL" to the database and basically sending commands from a console. Now I am ready to use the database from a language. 

 

The one thing that has made me pause was that the most activity out on GitHub is for Java. My fear was that when inevitable problems crop up that I won't have quite the same pool of help as I would if I were programming in Java. There are a number of examples in Java also to help. I have finally decided to go ahead and use C# because I feel that it shouldn't be too difficult transferring the Java examples to C#. I also like C# more than Java. 

 

The reason for my original post was that I was trying to figure out what type of front end would be best for the future. I am not a big fan of HTML5, CSS, Javascript. That's just me. Different strokes for different folks. I knew that parts of .NET is going open source but I didn't know if, for instance, WPF (or XAML) would be able to be used on tablets, for instance. When I learned it, XAML was sort of the "code behind" for WPF. Wasn't sure how that was being handled today. 

 

So that's where I was coming from. Would be interested in comments, suggestions, or questions.

Thanks. 

 

Neo4j is a server type database. It can be embedded per http://neo4j.com/docs/stable/tutorials-java-embedded-setup.html but the GPL3 license might be problematic in that case. So you might run Neo4j on any desktop O/S or server that supports Java 7 and then if you make a API layer for it, a client could be in any language.

 

Your ultimate objective is unclear in terms of devices you would like the client to run on and how your combination of client and server would be deployed. If you want to fire up a VM for Neo4j on Azure or AWS for example, and access it via mobile devices and various Windows platforms then all the previous discussion would seem to apply directly.

 

In terms of community support all major programming languages will have an active following of people willing to help you. If your background is mainly Java, then you could use Java as a client to cover Windows Desktop and Android. You could then compile Java to Javascript perhaps to deply web apps for Apple and WIndows Store.

 

C# as you already know is very similar to Java and should present few issues and per previous discussions can cover the most devices with the most common code but there will still be a substantial amount of device specific code.

 

Scala and Kotlin are two other options for fans of Java as they use the JVM and interop nicely. But doesn't help with increasing device targets.

 

There is no universal XAML. Silverlight, WPF, UWP and Xamarin Forms all use different variations of the layout language. There is nothing about Windows 10 over Windows 8 that really makes this any better other than being able to run Windows Store Apps in a resizeable window means that for some people the psychological barrier of giving up the legacy Windows Desktop Application can be overcome.

 

The simplest least effort approach to cover a wide range of devices is to use C#/XAML as long as you can drop Windows Desktop mode and also Apple OSX. Adding those two will require much more forked code but of course still much less than the common current approach of  using multiple languages.

 

"Best for the Future" is something nobody can answer unless you measure "The Future" in months. But at least you are thinking about the least effort/most robust kind of approach when current "best practices" of rewriting entire code bases for each target device is utter madness.

[DeadEndAccount]

They are exactly the same thing as WinRT apps. It is just fancier calling them Universal apps instead of Windows Runtime apps.

 

From what I understand in the case of 'Universal Apps' it also includes a lot of harmonisation between the platforms - based on what I've seen with the BUILD and Ignite conference there were platform differences such as the Bluetooth stack between Windows Phone and Windows on the desktop that would result in those differences impacting developers. The common core combined with the universal applications stack will hopefully mean that there is greater harmonisation which avoids two API's that are designed to do the same thing but are on different platforms for historical reasons rather technological. Parts of Winsock which were off-limits have also made their way into the 'Universal Apps' Stack so lots are changing under the hood which is great - it should make maintenance a lot easier long term and reduce the cost of developing Windows going forward.

 

Which only was happening because .NET Framework was limiting to one platform, Windows. Developers want to write code once and re-use everywhere. It's part of why Web Apps became so popular and part of why Windows 8 added HTML and JavaScript as a first class language for Windows apps.

The C++ aspects though is just choice. I think Windows Phone limiting the C++ development without explaining it hurt them more than anything. It was seen as locking down and preventing developers from creating. Developers need choice, the more the better.

 

Part of that was Microsoft waving around their 'we have patents' and Ballmer's 'open source is communist' which ultimately made those excited about .NET but wanting to use Linux as a platform to simply avoid the technology - the net result is that they lost the mindshare battle when compared to 'good enough' open source alternatives that existed out there. Nadella is now having to move heaven and earth to convince developers that .NET is a technology worth investing into and they're not going to get antsy if you want to develop for a non-Microsoft platform like Linux or *BSD of some flavour and then to make it more enticing the partial open sourcing of the stack (although they need to go further and fully open source the whole stack as well as have a 'patent amnesty' so that that threat of using those patents is put in clear black and white that they're only for defensive reasons and not to stop third parties from developing solutions on top of .NET and compete with Microsoft in some areas.

[Kaitly]

Universal Apps are a little bigger that single platform apps.

[tompkin]

Neo4j is a server type database. It can be embedded per http://neo4j.com/docs/stable/tutorials-java-embedded-setup.html but the GPL3 license might be problematic in that case. So you might run Neo4j on any desktop O/S or server that supports Java 7 and then if you make a API layer for it, a client could be in any language.

 

Your ultimate objective is unclear in terms of devices you would like the client to run on and how your combination of client and server would be deployed. If you want to fire up a VM for Neo4j on Azure or AWS for example, and access it via mobile devices and various Windows platforms then all the previous discussion would seem to apply directly.

 

In terms of community support all major programming languages will have an active following of people willing to help you. If your background is mainly Java, then you could use Java as a client to cover Windows Desktop and Android. You could then compile Java to Javascript perhaps to deply web apps for Apple and WIndows Store.

 

C# as you already know is very similar to Java and should present few issues and per previous discussions can cover the most devices with the most common code but there will still be a substantial amount of device specific code.

 

Scala and Kotlin are two other options for fans of Java as they use the JVM and interop nicely. But doesn't help with increasing device targets.

 

There is no universal XAML. Silverlight, WPF, UWP and Xamarin Forms all use different variations of the layout language. There is nothing about Windows 10 over Windows 8 that really makes this any better other than being able to run Windows Store Apps in a resizeable window means that for some people the psychological barrier of giving up the legacy Windows Desktop Application can be overcome.

 

The simplest least effort approach to cover a wide range of devices is to use C#/XAML as long as you can drop Windows Desktop mode and also Apple OSX. Adding those two will require much more forked code but of course still much less than the common current approach of  using multiple languages.

 

"Best for the Future" is something nobody can answer unless you measure "The Future" in months. But at least you are thinking about the least effort/most robust kind of approach when current "best practices" of rewriting entire code bases for each target device is utter madness.

I have not been trying to lock myself into a given form factor so much as wanting to see what would give me the most "bang for my buck" as far as trying to be the most flexible going forward as far as devices are concerned.

 

One Achilles's heal from a developers point of view is that the Universal apps is targeting Android Open Source. Yes, it's Android but I'm still missing the vast majority of Android users out there. 

 

I realize I'm beating a dead horse here and waffling. It's just that I'm going over and over these things and I know I'm going to have to, end the end, pick one. I think there might not be a "bad decision" here just (as you say the path of least resistance). 

[+Asmodai MVC]

From what I understand in the case of 'Universal Apps' it also includes a lot of harmonisation between the platforms - based on what I've seen with the BUILD and Ignite conference there were platform differences such as the Bluetooth stack between Windows Phone and Windows on the desktop that would result in those differences impacting developers. The common core combined with the universal applications stack will hopefully mean that there is greater harmonisation which avoids two API's that are designed to do the same thing but are on different platforms for historical reasons rather technological. Parts of Winsock which were off-limits have also made their way into the 'Universal Apps' Stack so lots are changing under the hood which is great - it should make maintenance a lot easier long term and reduce the cost of developing Windows going forward.

That's an odd way to look at it. It's a simple drop and replace. Windows Phone APIs are dead they're not harmonized with anything. WinRT (the API behind Windows 8 apps) has just been extended with new APIs (which it didn't have in Win8) and new Phones will use it. It's just one common API now ,thus the "Universal apps" moniker, where they're used to be two similar but slightly incomparable ones (one for phone and one for tablet/desktop). It's still the WinRT from Win 8 though, it's just got MORE stuff added to it... phone related stuff, windows resizing stuff, stuff that used to be only on phone, etc.

Part of that was Microsoft waving around their 'we have patents' and Ballmer's 'open source is communist' which ultimately made those excited about .NET but wanting to use Linux as a platform to simply avoid the technology - the net result is that they lost the mindshare battle when compared to 'good enough' open source alternatives that existed out there. Nadella is now having to move heaven and earth to convince developers that .NET is a technology worth investing into and they're not going to get antsy if you want to develop for a non-Microsoft platform like Linux or *BSD of some flavour and then to make it more enticing the partial open sourcing of the stack (although they need to go further and fully open source the whole stack as well as have a 'patent amnesty' so that that threat of using those patents is put in clear black and white that they're only for defensive reasons and not to stop third parties from developing solutions on top of .NET and compete with Microsoft in some areas.

This is largely FUD. MS has never been against open source in general. In fact NTs network stack for some time (I believe they've rewritten it now) was based on the open source BSD stack. Microsoft has a HUGE problem with so called "copyleft" licenses such as the GPL and that's what they've railed against in the past (often not choosing their words as carefully as perhaps they should). GPL backers have spun that into FUD saying MS hates all open source but that's just FUD. None of that has changed. MS STILL hates Copyleft licenses they're just more careful about what they say so GPL backers don't try to spin it as them being against all open source anymore. What is relatively new though is their willingness to open source their own stuff. They weren't hesitant to do that in the past because they hated open source they were hesitant to do that in the past because they are a commercial software developer who makes their money by selling software so it's hard to just give away your products for free and say in business. As they transition to services though it becomes much easier and that's what's going on now. Plus they're getting destroyed on mobile so they need to reduce the barriers to entry on their ecosystem as much as possible now and that includes removing the pay wall to use their platforms and increasing compatibility with the currently dominant platforms to try to entice users/developers to try theirs.

[simplezz]

This is largely FUD. MS has never been against open source in general.

No it's not, it's a fact. Microsoft has a history of being anti-FOSS and anti-competitive. It regularly sues companies who use FOSS as a base for their products (TomTom, B&N, Android OEM's), supports trolls like SCO attacking Linux, calling Linux a cancer, spreading FUD about the cost of OOS, and making unchallenged accusations of patent infringement to create uncertainty (WINE etc). Trying to rewrite history won't get you anywhere. These things are a matter of public record and won't just disappear.

And that's just the tip of the iceberg. Take a look at the Halloween documents if you want to see what Microsoft is really like.

In fact NTs network stack for some time (I believe they've rewritten it now) was based on the open source BSD stack.

That just shows how hypocritical they are. In the same way as supporting Oracle's API copyright court case with an amicus curiae, while at the same time copying Android/Google's API's for its Windows 10 OS.

[Max Norris]

No it's not, it's a fact. Microsoft has a history of being anti-FOSS and anti-competitive. It regularly sues companies who use FOSS as a base for their products (TomTom, B&N, Android OEM's), supports trolls like SCO attacking Linux, calling Linux a cancer, spreading FUD about the cost of OOS, and making unchallenged accusations of patent infringement to create uncertainty (WINE etc). Trying to rewrite history won't get you anywhere. These things are a matter of public record and won't just disappear.

All of that has to do with patent infringement, not open source. And that "Linux is cancer" quote is sooooo often taken out of context, he was going on about the highly restrictive GPL. And when has Microsoft gone after Wine? Or stuff like ReactOS? Kind of writing history yourself there.

 

And that's just the tip of the iceberg. Take a look at the Halloween documents if you want to see what Microsoft is really like.

How about something from this century? Times change, and so has MS. Ford used to work with the Nazis too... ban them forever? Nowadays, you'll want to be looking at companies like Google who have embraced that very 1995 attitude. Funny seeing you constantly defend that very same nonsense that they pull, but I guess that's ok eh?

 

while at the same time copying Android/Google's API's for its Windows 10 OS.

... so? Isn't this stuff open? Or is it for everyone to use except big bad MS?

[+Asmodai MVC]

No it's not, it's a fact. Microsoft has a history of being anti-FOSS and anti-competitive. It regularly sues companies who use FOSS as a base for their products (TomTom, B&N, Android OEM's), supports trolls like SCO attacking Linux, calling Linux a cancer, spreading FUD about the cost of OOS, and making unchallenged accusations of patent infringement to create uncertainty (WINE etc). Trying to rewrite history won't get you anywhere. These things are a matter of public record and won't just disappear.

And that's just the tip of the iceberg. Take a look at the Halloween documents if you want to see what Microsoft is really like.

That just shows how hypocritical they are. In the same way as supporting Oracle's API copyright court case with an amicus curiae, while at the same time copying Android/Google's API's for its Windows 10 OS.

 

Most (if not all) of what you cite uses copyleft licensing (particularly the GPL) which I said MS HATES and still does to this day.  You'll never see MS release software under the GPL or include anything GPL in their products.  It does NOT constitute a hatred of open source in general.  MS doesn't have a problem with MIT and BSD licenses for example.  Microsoft has a history of going after entities that promote copyleft licensing no open source in general.

[DevTech]

I have not been trying to lock myself into a given form factor so much as wanting to see what would give me the most "bang for my buck" as far as trying to be the most flexible going forward as far as devices are concerned.

 

One Achilles's heal from a developers point of view is that the Universal apps is targeting Android Open Source. Yes, it's Android but I'm still missing the vast majority of Android users out there. 

 

I realize I'm beating a dead horse here and waffling. It's just that I'm going over and over these things and I know I'm going to have to, end the end, pick one. I think there might not be a "bad decision" here just (as you say the path of least resistance). 

 

 

As I have previously discussed, Javascript and C# cover the largest percentage of common modern product  targets with C++ being a more distant third option in terms of being able to arrange your source code tree with the maximum amount of common code.

 

What we are seeing in the current developer landscape is that very few developers are approaching this with such a logical perspective that you are giving to the issue and it certainly deserves. And that's why I have been motivatated to work through this discussion both as a respository for other developers to tind and as an opportunity to see if anyone has insight into the development mess of 2015 that seems to be designed by a girl named Lucy who lives somewhere in the Sky with her Diamonds.

 

Maybe we are just asking too much at this point in time. There has always been hundreds of development languages to choose from and if you picked any one of them it would work out for deployment on most of the world's computers running Windows and you could safely ignore anything else. Then the web came along and you could choose any of the languages you knew and there would be a web server that used it to deliver HTML. Then Google came up with the rickety contraption of an application inside a browser and there we have the first restriction of language that can be used - Javascript. Then Apple created another "Walled Garden" of Objective-C. Then Google gave you the option of Java or C++ on Android. Then Microsoft joined the mobile party late with C# and then C++ and Javascript. These changes all had a lot of hype and buzz and the original developer uptake was "where is you SDK and what language do you mandate" and away they went with communities spring up around these walled gardens. All of the choices have played out as marketing and social, not technical.

 

What is probably making you hesitate are the huge currents of social force as you scan tech blogs and poke around in GitHub etc. Nothing seems to make any real coherent sense. A lot of people deal with this cognitive overload by embracing a walled garden and diving in. And I would have to say that is better than forever testing the waters on the sidelines.

 

Well, I'm not sure any thought on the "why of it" gives much insight so back to specifics.

 

UWP is a rename from the previous rename of UAP. It appears by now that Microsoft sees value in keeping Xamarin as an independent partner and will not be buying them. But I suspect we will see ongoing increasing support of that partnership. In VS 2015, Android and IOS are in the Microsoft documentation with instructions to install the VS Xamarin plug-in. Microsoft also purchased the company that made the Unity 3D VS plug-in that also targets Android. Microsoft also supports an Android Emulator. So Android in Visual Studio may not be part of UWP but it is very close. You can arrange all of this development technology to make an App for Android and Windows Phone with about 80% common code. The APK that Xamarin generates performs as native but you should check recent benchmarks and let me know since it's been a while since I have looked at that.

[libertas83]

Then Microsoft joined the mobile party late with C# and then C++ and Javascript. .

I don't think that is an accurate statement. Microsoft was never late to mobile, they were early. Windows Mobile was a major player of smartphones until iPhone and Android's 2nd big push into mobile. They had about 30% of the market if I'm not mistaken when Android started pushing them out. Back then, you could use C# or C++ to create apps.

Their mobile problems started because every new market Apple went into, they dominated. So Microsoft over-reacted and tried to push a more Apple-esque model of locking down the platform. That caused devs to flee to Android and left Microsoft into the dust. Their 2nd issue was slow updates of Windows Mobile making them too slow to respond to respond to the market.

Most mobile apps back then were written in C++ because it was more powerful. In fact, that was the top compliant with Windows Phone 7 because they wouldn't let devs use native code. Microsoft had the .NET Compact Framework for C#, but it was a different API so you couldn't build one app and re-use it.

If you look at the plans for Windows Mobile, you can see the roadmap of what they were trying to do. Windows Mobile 6.5 was really Windows CE kernel at the time. They decided to kill it and move to Windows NT. To do that, all apps would have to be re-written. So they released Windows Phone 7 as a stop-gap so they can build the app platform. A custom version of Silverlight was chosen (WPF lite) so they can have XAML front-ends. Native code (C++) was locked down to prevent issues with those devs having to rewrite their apps again....

Then came the big shift from Steve Sinfosky's Windows Team (Windows Mobile was separate during all of this). Silverlight was killed off in favor of WinRT, brand new API to replace WPF and Silverlight. That forces Windows Mobile team to change their strategy. If you watched, they ended up having to port over all the Silverlight code to a branch of WinRT called WinPRT (Phone Runtime). That cost them big. All of the dev cycle for Windows Phone 8 turned into not just porting the kernel, but having to make sure all Silverlight apps could still run, process to convert apps to WinPRT, and make everything support WinPRT in the first place.

Windows 10 really is the culmination of what they had started and had to change. So now, WinPRT is being ported straight into WinRT 2.0 which has now become "Universal Windows App". The remaining Silverlight stuff is being ported over to it as well. So going forward, Windows Phone will finally stabilize and be able to iterate new features rather than trying to build the back-end platform.

[+Asmodai MVC]

I don't think that is an accurate statement. Microsoft was never late to mobile, they were early. Windows Mobile was a major player of smartphones until iPhone and Android's 2nd big push into mobile. They had about 30% of the market if I'm not mistaken when Android started pushing them out. Back then, you could use C# or C++ to create apps.

Their mobile problems started because every new market Apple went into, they dominated. So Microsoft over-reacted and tried to push a more Apple-esque model of locking down the platform. That caused devs to flee to Android and left Microsoft into the dust. Their 2nd issue was slow updates of Windows Mobile making them too slow to respond to respond to the market.

Most mobile apps back then were written in C++ because it was more powerful. In fact, that was the top compliant with Windows Phone 7 because they wouldn't let devs use native code. Microsoft had the .NET Compact Framework for C#, but it was a different API so you couldn't build one app and re-use it.

If you look at the plans for Windows Mobile, you can see the roadmap of what they were trying to do. Windows Mobile 6.5 was really Windows CE kernel at the time. They decided to kill it and move to Windows NT. To do that, all apps would have to be re-written. So they released Windows Phone 7 as a stop-gap so they can build the app platform. A custom version of Silverlight was chosen (WPF lite) so they can have XAML front-ends. Native code (C++) was locked down to prevent issues with those devs having to rewrite their apps again....

Then came the big shift from Steve Sinfosky's Windows Team (Windows Mobile was separate during all of this). Silverlight was killed off in favor of WinRT, brand new API to replace WPF and Silverlight. That forces Windows Mobile team to change their strategy. If you watched, they ended up having to port over all the Silverlight code to a branch of WinRT called WinPRT (Phone Runtime). That cost them big. All of the dev cycle for Windows Phone 8 turned into not just porting the kernel, but having to make sure all Silverlight apps could still run, process to convert apps to WinPRT, and make everything support WinPRT in the first place.

Windows 10 really is the culmination of what they had started and had to change. So now, WinPRT is being ported straight into WinRT 2.0 which has now become "Universal Windows App". The remaining Silverlight stuff is being ported over to it as well. So going forward, Windows Phone will finally stabilize and be able to iterate new features rather than trying to build the back-end platform.

 

This is spot on.

 

I work for a developer that got on mobile early and had custom written Windows Mobile apps for internal use.  We have all Windows desktops, all Windows web servers, but we have *nix based (oracle) database servers.  When Windows Phone 7 came out and broke compatibility the *nix guys started porting the apps to Android and Windows guys worked on WP7.  It took a long time to port the apps (wasn't a top priority) and when WinPRT came out the project was ditched in favor of the Android version in part because it was pretty clear WinPRT wasn't going to be the final API either as well as Androids vast mobile market share.

 

Being a Windows developer myself I'd love to get mobile back and WinRT 2.0 ("Universal Apps") looks great but honestly I can't see it happening at this point with the Android apps already established.  Right now Android apps are developed and just placed on the internal web server for release (users "side-load" the apk) and just the suggestion of having to get Apple/Google/MS to approve our apps or set up some branded store is scoffed at.  Maybe if they had gone straight from Windows Mobile 6.5 to something like WinRT 2.0 we would have been able to make that sell but now they're not going to rewrite apps that are already working on the dominant mobile platform just to get it to work on a very small platform for mobile.

 

As a developer I'm interested again in MS development with WinRT 2.0 (I had no interest in WinPRT or WinRT 1.0 "Windows 8 apps") so that's good on MS's part but I'm afraid anything I learn will just be used on my own personal side projects for the time being.  The only hope I see at this point for professional adoption (at my company) is developing WinRT 2.0 apps for Win10 when we migrate to that on the desktops and then using the "Universal" nature to show the powers that be that we already have non-Android versions that work on Microsoft's Mobile platform too.

 

We're still on Windows 7 though because the company has no interest in touch on Desktop/Laptop and no plans to buy tablets (We do Android Phones, Windows 7 Desktop/Laptops).  The system guys avoided Windows 8 like the plague.  I suspect we'll go to Win10 though as Win7 support expires.  It should be interesting though to see if us Windows devs can take back mobile from the Android/*nix Oracle Server guys.