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!

[DevTech]

Thanks for the great write-up.

 

As a .NET dev these were some dark years where I thought Microsoft was just miscommunicating but some part of me feared they actually lost their mind and were deprecating .NET. These were times where entering "Is .NET" in Google had "Is .NET dead" as first suggestion. Today it has become "Is .NET open source" (to which the answer is yes). How attitudes and communications have changed at Microsoft in the last few years is very impressive.

 

I think in Sinofsky's mind the "reality" of the marketplace would make .NET self-deprecate. If Objective-C was needed to make apps responsive and give iStuff long battery life then Windows devs would flock to C++ to get the same benefits. He also wanted to fill the " App Gap" by porting web apps via Javacript and then C++ would also bring in various game engines from IOS and Android. C++ was the obvious choice to him and hey that had a great effect of reviving the Visual C++ team to get up to standards and indirectly led to .NET Native. All it took I think to finish off the mis-communication was the way in which Microsoft uses BUILD to only mention the new stuff. The was a critical time period where it would have been great for Microsoft to have some sessions on how they support many dev technologies for decades.

[+Asmodai MVC]

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?

Yes the full "Universal App" API is on both Windows Phone and Desktop.

Eventually it produces a native binary. What happens is a developer submits their app to the store and the store compiles it for supported devices and sends the proper native binary to the user. So the developer never compiles to native, the store does. The end result is the file a user downloads IS native though there is no JIT involved.

Android with ART works similar but your individual phone does the compile on install instead of the store. On Android the developer uploads the java-like code and the user downloads it but with ART after download the device compiles the app to native code. This is necessary on android due to the diversity of the hardware (Google doesn't know all the hardware combinations in advance to compile the app in the store like MS does.)

 

*********

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?

You have that backwards. MS isn't making it easier to make native android apps. What they're doing is allowing an android developer to import their android project and recompile it to run on Windows Phone (They're doing this with iOS as well.) The developer has to actually do this with the app source though you can't just take an existing Android app and it only works with the AOSP code so if they hook into google services (such as maps) they'll have to go in and tweak the app to use a MS replacement (such as bing maps instead) but it makes it a lot easier. So to users this doesn't mean much but it's big for developers because it makes porting their apps from Android to Windows Phone much easier. Windows Phone Universal Apps are NOT going to run on Android (or iOS)

[gawicks]

C++ compiler's normally produce native Win32 binaries. Are you saying then that C# universal apps compile to Win32 binaries?

 

They produce native x86-64 binaries. Win32 is an API and in this case Universal apps target WinRT. To get your head around it easily; C# universal apps work just like native C++ apps targeting WinRT. They do this by embedding the .net runtime (GC+ Framework code) in the app itself. That's overly simplifying the mechanics that happens inside there . but enough for you to get an overall idea Read more up on.Net Native then you'll understand. 

 

 

[in response to another poster]

It's highly unlikely (impossible?) that C# could ever use a C++ compiler because the language specifications are so different. C# has always been ahead of C++ in terms of language features (think Generics) so there would be features in C# that the C++ compiler could not handle. There might be some type of compiler but it wouldn't be a C++ compiler.   

 

Note that I said c++ 'backend'. This is the optimizer /code gen part of the c++ compiler. I think they wrote a new frontend for vc++ to understand the c# object model. You're right to be skeptical that this would actually work . There's some magic under the covers. Check out this excellent deep dive by Charles http://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native. That explains the story upto the handover to the c++ compiler.

[libertas83]

I think in Sinofsky's mind the "reality" of the marketplace would make .NET self-deprecate.

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.

[DevTech]

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.

 

 

The why and how developers write code will depend on many factors, with some of them being amusing and social rather than logical. Only some percentage of developers "want to write code and re-use it everywhere."

 

Xamarin as successful as they might be would be overwhelmingly on top if developers really wanted a single code base in the modern mix of targets. But the amusing and sad story goes more like this:

 

• Some corp has Windows WPF app to track vacation schedules or whatever
• Then Everyone wants to access this on a phone or tablet so a new App is made in Objective-C for the iPhone.
• Then BYOD policy permits Android so everything gets remade as a Web App in Javascript so just one code base needs to be maintained
• Then performance of web apps on mobile overloads the support department with complaints (yeah and Facebook as well)
• Then Android App gets made in Java
• Then Sinofsky says rewrite your App again for WinRT but maybe everyone is just a bit exhausted at this point and will "wait and see" on Windows 8

 

So the LOL part is this still plays out in 2015 when a developer can get 80% common code base by using C# across all platforms, you still see the same app being made both in Objective-C for IOS and Java for Android. At this point I think a cognitive exhaustion sets in and nobody wants to do a third rewrite to C# for the remaining 5% of the market. The trick is to get the mindspace for C# happening before that first "prototype" is hacked out in Objective-C or Java or even the particular mobile torture that is Javascript. (see: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/)

 

I have loosly touched in just a few of the reasons that developers choose a dev technology logical or not. There are many more...

[The_Decryptor Veteran]

Actually .Net Native works by compiling IL to the representation used by the C++ backend so they can then apply the same compile and link-time optimizations. Pretty amazing stuff.

Do they actually use the C++ compiler backend, or the existing .NET compiler backend? I would assume it'd be more work retrofitting the .NET semantics onto the C++ compiler, as it would introducing optimizations from the C++ one across to the .NET one.

Although Ive never really played around with MS's C++/.NET stuff (Only C#/VB.NET), but I always thought they were just doing transparent p/invoke stuff between them.

And actually thinking about it, the .NET compiler stuff is a hell of a lot like LLVM. Language specific compiler frontends parse the code and produce a AST, then "compile" that to MSIL which is compiled with a single compiler.

[Philippe Majerus]

They are saying that on Android, that Microsoft is going to use the Android Open Source Project (AOSP). This means that this version of Android will not come with Google services (such as Play Store, Maps, etc.) which is very low level stuff. Microsoft will have to provide this. 

 

Paul Thurrott said that he expected that they would go in the opposite direction, i.e. they would port Universal Apps to Android and iPhone. I'm assuming he meant that he thought they would port universal apps to the stock Android that has the Google Services included.  They mentioned that Xamarin will now not work. I'm not sure why but you can hear this at the above spot in the video. They talk rather quickly so you have to pick it up rather quickly. 

 

Targeting AOSP is the right way to go.

If they target Google's version, and took advantage of Google's extras .net apps would use Google Maps, etc..., and would only work on Google's version of Android.

By targeting AOSP, they go for the lowest common denominator and implement their own mapping and extra services on top of .net.

This means a .net app for AOSP would work on any Android version, Google or AOSP or any manufacturer fork of AOSP.

This could have huge impact on the Android platform, as if there are enough .net apps available, AOSP could become a viable alternative for manufacturers, freeing them form the Google version.

 

[DevTech]

Do they actually use the C++ compiler backend, or the existing .NET compiler backend? I would assume it'd be more work retrofitting the .NET semantics onto the C++ compiler, as it would introducing optimizations from the C++ one across to the .NET one.

Although Ive never really played around with MS's C++/.NET stuff (Only C#/VB.NET), but I always thought they were just doing transparent p/invoke stuff between them.

And actually thinking about it, the .NET compiler stuff is a hell of a lot like LLVM. Language specific compiler frontends parse the code and produce a AST, then "compile" that to MSIL which is compiled with a single compiler.

 

 

There appears to be a lot of confusion  concerning .NET Native which is impressive technology for sure but has a limited range of uses.

 

First of all, it applies only to .NET Apps programmed for the Windows 8 and 10 Store environments.

 

For Windows Desktop, there is a new 64 bit runtime called RyuJIT which has better performance.

 

For Windows 10 Store Apps the new .NET Native compiler will be the default option.

 

From https://msdn.microsoft.com/en-us/library/ms171868%28v=vs.140%29.aspx, "Windows apps for Windows 10 that target .NET Core and are written in C# or Visual Basic can take advantage of a new technology that compiles apps to native code rather than IL. They produce apps characterized by faster startup and execution times."

 

On a modern desktop computer the performance of the C# runtime is very close to native C++ code and in some cases can be faster. The many advantages of the .NET runtime in code safety and debugging maximizes human productivity at a tiny cost to machine performance. But the performance has a hidden cost in CPU utilization. If C++ can use a little less CPU you get extended battery life on mobile devices and improved energy savings in large data centers. For any single application, that you might make, the whole energy issue will not be noticeable but if all Store Apps are compiled to native, there should be a scaled out aggregate improvement. So the main thing you will see as an individual is the faster start up time since there is no runtime init as all .NET DLL's are compiled into your executable.

 

On the specific issues of the compiler, yes it is true that the Visual C++ compiler back end is being used to construct the final output and it is more complicated than a simp[le back end processing of IL code and it is quite a technical achievment to do this in a way that minimizes the runtime impact to Reflection and other metadata driven coding techniques but there is still a long list of potential gotchas in a large code base. (see "Handle additional reflection and serialization usage "  https://msdn.microsoft.com/en-us/library/dn600165%28v=vs.110%29.aspx and also "Migrating Your Windows Store App to .NET Native" https://msdn.microsoft.com/en-us/library/dn600634%28v=vs.110%29.aspx)

 

For a broad overview of the .NET Native compiler mechanics, see: https://msdn.microsoft.com/en-us/library/dn807190%28v=vs.110%29.aspx

 

Note that it would be easy to see the process as operating only on the IL back end which many people latch onto as a way to explain what is happening similar to LLVM but in fact much more is going on and it is better to make a mental model (IMO) of a completely alternate .NET compiler chain.

 

I am curious to know if the .NET Native effort inspired the Objective-C to Windows compiler or if the Objectice-C project came first to inspire .NET Native since the time frames seem similar.

[DevTech]

Targeting AOSP is the right way to go.

If they target Google's version, and took advantage of Google's extras .net apps would use Google Maps, etc..., and would only work on Google's version of Android.

By targeting AOSP, they go for the lowest common denominator and implement their own mapping and extra services on top of .net.

This means a .net app for AOSP would work on any Android version, Google or AOSP or any manufacturer fork of AOSP.

This could have huge impact on the Android platform, as if there are enough .net apps available, AOSP could become a viable alternative for manufacturers, freeing them form the Google version.

 

 

In the context of this thread, to extend the concept of a universal app the Android process would look like this:

 

https://msdn.microsoft.com/en-us/library/dn879698%28v=vs.140%29.aspx

 

To attempt to cover the complete set of device targets from phones to 80 inch Surface Hub devices (I made a list of all targets in a previous post on this thread) with a maximum common C# code base should actually be possible to automate to some extent but is not yet a Visual Studio "New Project" template!

 

The issue of AOSP arises in the case of emulating (or deploying) existing Android code for which I can't see the connection to this topic thread.

 

But in any case the Google version of Android is not an option for any Microsoft usage since everyone who uses that version (just about 100% of all Android) has to pay Google about $8 per device. (Google calls this a "testing fee" so they can still maintain the fiction that Android is free) and in any case the chance that Google would allow Microsoft to use Google Android seems even less likely than Google making Apps for Windows Phone.

[The_Decryptor Veteran]

So ".NET Native" is like ngen, but a bit more reliable and with things like DCE built in then.

[DevTech]

Paul Thurrott has posted a summary article on UWP: https://www.thurrott.com/windows/windows-10/3294/need-to-know-universal-windows-platform

 

Unfortunately it contains a close simulation of information zero which is another indication of the difficulty of explaining UWP. We saw this sort of problem when Sinofsky introduced WinRT at BUILD and bypassed the simple explanation that parts of .NET had been rewritten into the Windows API.

 

UWP = the Microsoft app model hosted wherever they think it might make sense.

 

Metro/WinRT was Windows 8.0

 

Modern was an out of nowhere embarrassing name change.

 

Windows Store App was Windows 8.1 and Windows Phone 8.1 and promises of running on whatever Windows 8 was on Xbox One

 

Universal App Platform changed nothing at all but introduced a handy TLA: UAP

 

And now Universal Windows Platform changes the TLA to UWP and appears to support similar targets:

 

Windows 10, Windows Phone 10 and promises of running on whatever Windows 10 Microsoft  pushes out to the Xbox One (someday...)

 

To make this more "Universal" they add in IOT on a Raspberry Pi and Surface Hub

 

It is easier than ever to add a C# target for Android and Apple and share a huge amount of code with UWP so the technical accomplishments are there but are a quiet slow evolution and nothing ground breaking.

 

One could be cynical about the 90% marketing driven nature of UWP but the platform actually does need some good marketing both across Windows and how easy it is to get excellent code reuse across Android and IOS.

 

In 2015, it is still a tough message to get out there into the general development community that developers might want to evaluate C# before starting a project with Objective-C or Swift.

[DevTech]

So ".NET Native" is like ngen, but a bit more reliable and with things like DCE built in then.

 

It depends on your definition of "is like"

 

Ngen just pre-JITS IL code but still uses the complete .NET runtime installed on the computer. It is invisible to your code.

 

The .NET Native compile pulls in all the .NET assemblies as if they were C++ LIB files and creates a stand alone EXE with no connection to the installed .NET runtime on the computer.  The process is not invisible to your code and may require many changes to your code and 3rd party libraries to function as a static executable.

[DevTech]

Thanks for the great write-up.

 

As a .NET dev these were some dark years where I thought Microsoft was just miscommunicating but some part of me feared they actually lost their mind and were deprecating .NET. These were times where entering "Is .NET" in Google had "Is .NET dead" as first suggestion. Today it has become "Is .NET open source" (to which the answer is yes). How attitudes and communications have changed at Microsoft in the last few years is very impressive.

 

For that wtf double-take of nostalgia, this simple google hits the mark nicely:

 

"scott barnes silverlight" - https://www.google.ca/search?q=scott+barnes&ie=utf-8&oe=utf-8&gws_rd=cr&ei=dwNIVb2OBZGwogSNiIHgBQ#q=scott+barnes+silverlight

 

In case any future time traveller drops by and wants a useful link, here is Scott: http://www.riagenic.com/ - he deleted one juicy rantty blog post, but this former Microsoft manager was the most forthcoming with the events of the time

[tompkin]

Perhaps I'm being too simplistic here. I realize there is a huge C#/.NET type of installed base of code and developers out there (i wish we could all stay in the WPF world) but if I"m going to do an app, why not just use HTML5, CSS, and Javascript (maybe generated by Typescript) and be done with it! That's what some in Microsoft have been encouraging people to do anyway. 

[tompkin]

For that wtf double-take of nostalgia, this simple google hits the mark nicely:

 

"scott barnes silverlight" - https://www.google.ca/search?q=scott+barnes&ie=utf-8&oe=utf-8&gws_rd=cr&ei=dwNIVb2OBZGwogSNiIHgBQ#q=scott+barnes+silverlight

 

In case any future time traveller drops by and wants a useful link, here is Scott: http://www.riagenic.com/ - he deleted one juicy rantty blog post, but this former Microsoft manager was the most forthcoming with the events of the time

Great post! I will tell you if I've learned one thing it's that each developer must do what they think is right for himself/herself. 

 

Silverlight is a perfect example where a company decides that what is best for the company is to discontinue a product so it does so. Quite suddenly. There was no one screwed over more than Silverlight developers (I was not one). There was a rumor outside the U.S. that Microsoft was going to discontinue Silverlight. Microsoft responded to the rumor by denying that they were discontinuing it (no more internal development for it). Very shortly thereafter they announced that they were discontinuing it. It's one thing to not comment on something. It's quite another to lie about it.

 

My point being is that, developers need to do what's best for themselves and not worry about a given platform, etc. Microsoft is going to do what's best for Microsoft. That's the way it should be. Microsoft is a good company. We seem to get caught up, however, that this technology or that is some kind of religion when it's really not.  

[tompkin]

Targeting AOSP is the right way to go.

If they target Google's version, and took advantage of Google's extras .net apps would use Google Maps, etc..., and would only work on Google's version of Android.

By targeting AOSP, they go for the lowest common denominator and implement their own mapping and extra services on top of .net.

This means a .net app for AOSP would work on any Android version, Google or AOSP or any manufacturer fork of AOSP.

This could have huge impact on the Android platform, as if there are enough .net apps available, AOSP could become a viable alternative for manufacturers, freeing them form the Google version.

 

I see what your saying but if your trying to get current Android users to switch to WP, they likely are already tied to Google services. They are not going to want to change to Microsoft services. It's too much of a hassle for very little gain.

 

Also, what kind of "look" will MS give to Android. I would say it's ok to give it a new look but not TOO close to Metro. If they try to "Metro-ize" the UI they will lose customers because people have a bad taste in their mouth about Metro. I know people will say that when they add apps that people will still come. I personally don't think they will. There is a stigma associated with Metro (like Vista) and no amount of marketing is going to change that. 

[+Asmodai MVC]

I see what your saying but if your trying to get current Android users to switch to WP, they likely are already tied to Google services. They are not going to want to change to Microsoft services. It's too much of a hassle for very little gain.

Microsoft doesn't have a choice. AOSP is open source and free for anyone to use. It's what Amazon uses to make their Kindle's, it's what Barnes and Noble uses for the Nook, it's what the cheap Chinese knock offs use. It's free and available to anyone who wants to use it.

How google makes money with Android is through google services. While you can get AOSP for free if you want to have the Google Play Store or use Google Maps or gmail, etc. then you have to pay a license to Google. MS isn't going to pay Google so they can't put google services on Win10 devices.

If MS wants to get current Android users to switch to WP they HAVE to convince them to change to MS services. They do that by making at easy as possible for app developers because most users don't really care what service works behind the apps they love. If you're an android user and you use MyMapApp and you see that MyMapApp is available for Windows 10 then you're more likely to be ok with switching. It probably doesn't matter to you that MyMapApp on Android uses Google Maps and MyMapApp on Win10 uses Bing Maps. As long and the app is there and works essentially the same the users will be happy.

Also, what kind of "look" will MS give to Android. I would say it's ok to give it a new look but not TOO close to Metro. If they try to "Metro-ize" the UI they will lose customers because people have a bad taste in their mouth about Metro. I know people will say that when they add apps that people will still come. I personally don't think they will. There is a stigma associated with Metro (like Vista) and no amount of marketing is going to change that.

MS isn't going to fundamentally change the look of the app. Even on Android there are slight differences between what a checkbox looks like for example due to skins and so they might make their "skin" for ported android apps use similar looking base widgets as Metro but the overall design will still be Android. They won't be universal apps that work with Continuum because they'll just be translation of the Android API and it doesn't have anything like Continuum.

[tompkin]

Microsoft doesn't have a choice. AOSP is open source and free for anyone to use. It's what Amazon uses to make their Kindle's, it's what Barnes and Noble uses for the Nook, it's what the cheap Chinese knock offs use. It's free and available to anyone who wants to use it.

How google makes money with Android is through google services. While you can get AOSP for free if you want to have the Google Play Store or use Google Maps or gmail, etc. then you have to pay a license to Google. MS isn't going to pay Google so they can't put google services on Win10 devices.

If MS wants to get current Android users to switch to WP they HAVE to convince them to change to MS services. They do that by making at easy as possible for app developers because most users don't really care what service works behind the apps they love. If you're an android user and you use MyMapApp and you see that MyMapApp is available for Windows 10 then you're more likely to be ok with switching. It probably doesn't matter to you that MyMapApp on Android uses Google Maps and MyMapApp on Win10 uses Bing Maps. As long and the app is there and works essentially the same the users will be happy.

MS isn't going to fundamentally change the look of the app. Even on Android there are slight differences between what a checkbox looks like for example due to skins and so they might make their "skin" for ported android apps use similar looking base widgets as Metro but the overall design will still be Android. They won't be universal apps that work with Continuum because they'll just be translation of the Android API and it doesn't have anything like Continuum.

The common theme is that it's the "services" that ultimately really matter. I totally agree.

 

I have read in several places that Microsoft currently makes 1.5-2.0 bln. dollars from Android sales due to patents. Essentially, that's "money for nothing". (They don't have to manufacture anything or develop anything.) If all the Windows Phone users suddenly went to Android, it wouldn't be as big a loss for Microsoft because they will be getting money for every Android sold. Plus they would be eliminating all the expense involved in keeping Windows phone on life-support.

 

But as you say, it's the Services that matter. We can only cross our fingers that the developers will come.   

 

EDIT: One point I would like to add. When you get into one eco-system (whether Apple, Android, or Microsoft) there is an inertia present. If your a WP user and have a Microsoft account, if you start using Android little things will start to bother you. It will ask you for new passwords, things will look different (thus, not liked). I wouldn't call going from one eco-system to another a seamless process, and the average user (in my view) would feel a degree of pain. 

[+Asmodai MVC]

I have read in several places that Microsoft currently makes 1.5-2.0 bln. dollars from Android sales due to patents. Essentially, that's "money for nothing". (They don't have to manufacture anything or develop anything.) If all the Windows Phone users suddenly went to Android, it wouldn't be as big a loss for Microsoft because they will be getting money for every Android sold. Plus they would be eliminating all the expense involved in keeping Windows phone on life-support.

If all current Windows Phone users went to Android it wouldn't be a big loss for Microsoft because there aren't many of them and the money they make (if it's profitable at all atm) is insignificant in terms of the income of the overall company.

That said they don't want to surrender mobile. Microsoft would make a whole lot more money from Windows Phone when it charges to put the phone on devices. Windows Phone is a "Walled Garden" so it only runs apps from the Windows Store and Microsoft gets a 30% cut of everything bought from the store. 30% of every app every user buys on your platform is a HUGE deal if you've got a lot of users.

EDIT: One point I would like to add. When you get into one eco-system (whether Apple, Android, or Microsoft) there is an inertia present. If your a WP user and have a Microsoft account, if you start using Android little things will start to bother you. It will ask you for new passwords, things will look different (thus, not liked). I wouldn't call going from one eco-system to another a seamless process, and the average user (in my view) would feel a degree of pain.

This is not unique to MS. If you got from one eco-system to another there is always going to be some degree of pain but if you own an ecosystem it's your job to try to make that pain as small as possible. That's what MS is trying to do.

MS has to focus on it more than others because they're so late to the party. Apple and Android already have huge user bases and most of their growth is through new people getting their first smart device and not switchers.

MS doesn't have a huge base on mobile so they have to try to convince people to switch. To do that they're trying to make it as easy as they can for Android and iOS developers to port their app to Windows Phone.

[DevTech]

Perhaps I'm being too simplistic here. I realize there is a huge C#/.NET type of installed base of code and developers out there (i wish we could all stay in the WPF world) but if I"m going to do an app, why not just use HTML5, CSS, and Javascript (maybe generated by Typescript) and be done with it! That's what some in Microsoft have been encouraging people to do anyway. 

 

The choice of a development technology will depend on your experience, willingness to try new things, social factors such as friends/fanism, perceptions of trends, device targets, domain of application and demographics of anticipated users. I've probably missed a few factors. Given the matrix of interactions of all those factors it is no surprise we see a wide variety of development languages and platforms and of course commercial interests of the major platform providers attempt to influence your decision such as forcing the heavily walled garden of Apple or try to get everyone to join the party by providing you with the kitchen sink of technologies a la Microsoft.

 

Javascript is an ideal choice if you want to provide a crappy but universal experience across all devices using a technology invented by some mad scientist on an acid trip. Instead of a user running some code that uses the O/S to write pixels to the screen, somebody thought that was too simple and decided that the user would run a web browser which would load a document which would then load style sheets and Javascript functions all of which would get assembled by a browser to display slow pixels in a browser window that in turn would get the browser to use the O/S to write pixels on the screen. This conglomeration of stuff stuck together by chewing gum sort of works on a powerful desktop computer to turn a document hypertext program into a application runner but even on a desktop computer web apps rarely consider dozens of other things running at the same time and on mobile devices there are some very serious performance considerations.

 

See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ which generated a storm of counter-articles none of which addressed his core data IMO.

 

If your background is in web development then it is very easy to use Javascript to get a prototype of something running on various devices. After the initial success, there are a myriad of performance tweaking issues and device differences. Javascript (HTML5) has become popular in the entrprise world because it permits a single code base to run across a wide range of targets and if it performs poorly everywhere the management can just tell their captive user base to live with it. But if you are making an App in HTML5/Javascript for which you will be competing in the open market against Apps that are native, the data shows that native wins every time.

 

It was a smart move for Microsoft to add Javascript to the mix because there are a lot of web developers in the world and it makes an easy on-ramp for them. It was stupid to also dump Silverlight which overlapped a bit with that developer base but there were some complicated politics at that time. The inclusion of Javascript into Windows 8 as a first class citizen was incorrectly interpreted at the time as an endorsement by Microsoft of a single technology movong forward. Instead Microsoft was just being inclusive and actually at that time attempted to communicate that making C++ a new first class citizen was the "really big deal" while for .NET it was just supposed to be a huge improvement with XAML being pulled into the Windows API. With the new BUILD there is the promise of Objective-C, Android Java and some hints of Apple Swift. The kitchen sink gets larger.

 

It is extremely unclear if there is a future world of technology where the array of possible target devices permit Javascript to perform as well as native with the next ten years. The original assumption of the "web everywhere" crowd was that faster silicon everywhere would lead to world dominance or something like that. This never happenned. It's not the silicon that became the problem it was the complete lack of an advance for human civilization of a significantly improved battery technology. There may be a marketing advantage to provision a cell phone with an octo-core CPU but there will be so much throttling going on that Javascript will not see any significant extra headroom.

 

If you disagree with my pessimism concerning target CPU capacity over the next decade, then within the world of Javascript lies the wide open opportunity of Asm.js which is small subset of Javascript designed to run a near-native speed. Just like machine language, a compiler can target Asm.js. Check out the enscripten project which provides a LLVM for Asm.js which means any language that targets LLVM can run in a browser! (Which is wonderfully amazing and sickening horrific at the same time)

 

C# and C++ are the only languages that can target a wide range of devices at near-native performance with the chance of a huge percentage of common code. C# has the advantage of more UI sharing with C++ typically using OpenGL across platforms which caters more to games.

 

Since all mobile targets have decent universality of sufficient GPU and desktops are generally also good enough in that area we are in an age where it is possible to consider a cross platform gaming dev technology for even 2D business and consumer apps. With a suitable GUI plug-in, the C# based Unity 3D for example could run everywhere at native speeds, have a fast and fluid UI everywhere and share over 90% common code i.e. as good as Javascript.

 

If Microsoft can build it's billion user App store with Windows 10, then Javascript and C# might become the two first choices for cross-platform coverage. Otherwise if inertia keeps things the way they are, the primary App dev languages will be Objective-C (possibly moving to Swift) and Android's Java with the ever looming possibility of the "death of the web"

[tompkin]

C# and C++ are the only languages that can target a wide range of devices at near-native performance with the chance of a huge percentage of common code. C# has the advantage of more UI sharing with C++ typically using OpenGL across platforms which caters more to games.

 

 

I hear what your saying and cannot disagree with anything. I'm not familiar with LLVM. I was curious if you had looked at QT for C++. I realize it's not "Microsoft" and frankly when I looked at it I was mainly interested in Android. It's "all C++" and seems to work on mobile as well as desktop. I got suspicious of licensing issues when I looked at their website and was actually warned to make sure I agreed to them before I got too deep. I'm not sure how it "plays" with the Universal Platform.

 

I was curious, though, as to your thoughts. 

[DevTech]

I hear what your saying and cannot disagree with anything. I'm not familiar with LLVM. I was curious if you had looked at QT for C++. I realize it's not "Microsoft" and frankly when I looked at it I was mainly interested in Android. It's "all C++" and seems to work on mobile as well as desktop. I got suspicious of licensing issues when I looked at their website and was actually warned to make sure I agreed to them before I got too deep. I'm not sure how it "plays" with the Universal Platform.

 

I was curious, though, as to your thoughts. 

 

LLVM - http://en.wikipedia.org/wiki/LLVM "It is written in C++ and is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages. Originally implemented for C and C++, the language-agnostic design (and the success) of LLVM has since spawned a wide variety of front ends: languages with compilers that use LLVM include Common Lisp, ActionScript, Ada, D, Fortran, OpenGL Shading Language, Go, Haskell, Java bytecode, Julia, Objective-C, Swift, Python, Ruby, Rust, Scala,[3] C#[4][5][6] and Lua."

 

Apple uses this for Objective-C and hence the huge uptake.

 

The interesting aspect is that the abstract intermediate code output of LLVM has been designed in a way that enough people view it as good enough to standardize on and hence if you have any language compiler implemented in LLVM it is possible to pump it into Emscripten and run it in your browser.

 

Emscripten - http://en.wikipedia.org/wiki/Emscripten - " As its input it takes LLVM bytecode, typically created by compiling from C or C++. As output it emits a file in the JavaScript programming language which can run in web browsers"

 

I can't help but view this technology with a split brain of wonder and absurdity and many will be sucked into it like a happy moth sticking to a light bulb.

 

-----------------------

 

 

Qt - http://en.wikipedia.org/wiki/Qt_(software) - "Qt 5 was officially released on 19 December 2012. This new version marked a major change in the platform, with hardware-accelerated graphics, QML and JavaScript playing a major role."

 

QML was donated to the project by Nokia and provides a layout engine similar to XAML.

 

I have not used Qt but here are some notes that come to mind. I don't have anything to contribute on the license issue other than it looks ok to me for a non-enterprise scenario. It is my opinion that most likely the setup of a project to handle a wide variety of targets will require some careful thinking around a good modern build tool. I would also have concerns that the QML/Javascript layout engine will introduce all the problems of Javascript in terms of device fragmentation and performance. Most of the modern device targets just about every developer will want to anticipate adding to their target list will have touch. I would be careful to kick the tires on Qt touch demos on a variety of devices before considering it.

 

For me the attraction of a C++/OpenGL path would be the ability of making any 2D GUI as a texture on a 3D surface to get native GPU performance with some very customized visuals to make an app really stand out. This is not the path of least resistance and hence I'm not aware of any examples outside GUI's inside games but it it my personal belief it has the potential to translate into increased buzz and user uptake/sales if done right. This type of method should also be possible with Unity 3D whaich has recently been made completely free.

 

There is also the tooling issue which is very subjective. The newly free Visual Studio Community edition along with the newly free Unity 3D with Visual Studio plugin could provide a much more productive toolset for some people than creating your own Qt C++ tool chain. For others, having dozens of shell windows open is the essence of productivity.

 

If you wanted to comment on what you think your objective might be, it is possible I could comment further.

[+Asmodai MVC]

I was curious if you had looked at QT for C++. I realize it's not "Microsoft" and frankly when I looked at it I was mainly interested in Android. It's "all C++" and seems to work on mobile as well as desktop. I got suspicious of licensing issues when I looked at their website and was actually warned to make sure I agreed to them before I got too deep. I'm not sure how it "plays" with the Universal Platform.

Not sure if you know but Qt is the framework the KDE Desktop is based on for Linux. Back in the day the big rivalry (one of them anyway) was Qt/KDE vs. GTK/Gnome. GTK was the darling of the free software movement though because Qt had a commercial license at the time and then over the years has had various licenses incompatible with the Open Source Initiative. I think that's been all cleared up now and it's licensed in a bunch of different ways that allows it to be both GPL compatible as well as used in closed commercial software.

[tompkin]

Not sure if you know but Qt is the framework the KDE Desktop is based on for Linux. Back in the day the big rivalry (one of them anyway) was Qt/KDE vs. GTK/Gnome. GTK was the darling of the free software movement though because Qt had a commercial license at the time and then over the years has had various licenses incompatible with the Open Source Initiative. I think that's been all cleared up now and it's licensed in a bunch of different ways that allows it to be both GPL compatible as well as used in closed commercial software.

No, I was not aware of that. I was just googling around and discovered it. 

 

One thing I thought I would mention. Back in mid-February I "direct-messaged" someone on Twitter that is knowledgeable in C++ (written books, well known) about the dilemma (as I saw it) of C++ not having a native front-end. I mentioned MFC but knew that it's long past it's useful life. I asked them what was the best current way to do it. I will cut and paste what there response was to me:

 

"a C#/XAML UI (view) with a native C++ backend (model) and a C++/CLI glue layer (view model) between them."

[DevTech]

No, I was not aware of that. I was just googling around and discovered it. 

 

One thing I thought I would mention. Back in mid-February I "direct-messaged" someone on Twitter that is knowledgeable in C++ (written books, well known) about the dilemma (as I saw it) of C++ not having a native front-end. I mentioned MFC but knew that it's long past it's useful life. I asked them what was the best current way to do it. I will cut and paste what there response was to me:

 

"a C#/XAML UI (view) with a native C++ backend (model) and a C++/CLI glue layer (view model) between them."

 

That is one possible approach on a Windows desktop from 8 backwards. On Windows 8, C++ becomes a first class App citizen and can access native Windows API XAML in the Windows API. In fact it is C# that goes through a layer (called a projection) to the native C++ XAML.

 

On Windows 10 with Apps moving to resizable windows on the desktop there should be no reason to avoid the App model. For cross platform C++, the XAML front-end will be less universal than Qt although with Xamarin C# on Android and IOS the same technique could be used.

 

Of course just like the debate about using a nuclear weapon the fact that it is possible to do it this way doesn't mean it should be done. If you have a large existing body of code in C++ and want to have a modern user interface, then C# XAML offers excellent tooling support with Visual Studio. Since the C++ code is essentially implementing the equivalent of an API layer, you could also use Javascript as the front end.

 

If you are starting a new project then using C++ is pointless unless you are building a DirectX game engine or some scientific thing where every CPU cycle counts. (or making a Device Driver or embedded system or lots of very special cases)