The joy of Universal Windows Platform ... And things that blow it all

From my developer perspective, the Universal Windows Platform (UWP) appears to be the best platform to develop modern software. Here are my reasons.

Universal is more than "write once, run everywhere"

If you have done Android or iOS, you are probably familiar with the sluggish emulator (or simulator, I cannot distinguish the difference between these two words). The situation has improved with the arrival of Genymotion, a VirtualBox-based simulator. Despite that, you still have to download GB of virtual machine data. Moreover, those virtual machine does not have access to Google Play Services (at the complaint of Google, of course) so you basically cannot test some features of your app without resorting to real device.

In UWP situation, you test the app right on your development machine. The app is intended to be universal so its UI should adapts and you can have a realistic assessment of how it looks on other devices such as phones. There is no need to download GB of virtual machines, set them up, transfering apps and interacting with them via console. (The SDK does come with emulator if you still want to install.) Debugging therefore is way faster than the "virtual debug server" approach.

So universal not only means "write once, run everywhere". It also means "test once, debug once, design once, etc".

C++, one language to rule them all

Android apps are primarily developed using Java and Objective C/Swift for iOS apps. Objective C has the ugliest syntax I have ever seen and Swift reminds me of Python for children (namely, without lambda). Java is a fine language albeit verbose and slow due to its virtual machine nature.

The predecessor of UWP i.e. Windows Runtime in the era of Windows 8 is C# only, which I am also no fan of. Microsoft later adds C++ for Windows 8.1. C++ has great support in UWP.

One advantage is that you can use the same language to develop the whole app while for instance, in Android, you have to switch to C (e.g. to write OpenGL code for native graphic or computationally intensive tasks) and then write some JNI to use it in Java. In UWP, you write your app in C++ and uses Direct X directly without ever having to switch to a different IDE, write a different language and complicated interfaces.

Another advantage is the ability to easily reuse or utilize many available C/C++ libraries. I myself easily port libgit2 to the UWP. If you do Objective C or Java, it will be such a pain. Swift probably imitates Microsoft approach to language agnosticism so it should support C/C++ easier.

No IDE required - Meet Visual Studio Team Service

I am no fan of the IDE to develop UWP, Visual Studio, the extremely bloated and extremely sticky software that cannot be completely uninstalled and liters all over the places on your machine even though I agree that it is the best IDE. Even when I did C++ for Android (not for Windows), I used Visual Studio, not Eclipse or any other Google's solution. Worst than the bloatedness, you have to agree to automatic dianogstic tracking and telemetry collection, activate once in a while, must have administrator right to install, etc. And that is not to count the fact that it fails every once in a while where you have no choice but format your machine, install Windows from scratch and then install Visual Studio (which takes forever like a full day of work and 40GB of hard drive consumption).

There comes Visual Studio Team Service, previously known as Visual Studio Online. The services allow easily build apps without having to install Visual Studio at all. I can just code, push my changes, hit Queue build on the website, wait for it to complete, download the executable and test. All you need for your development is Git. I have to admit that you will need to know how to write and modify Project and Solution files so that you can manually configure the build settings. But the format is really obvious and the documentation is available.

Android has no such thing and definitely, you not only need to use the proprietary XCode but also can only install it on an Apple device. Worst, Google moved away from Eclipse and forces developers to use its proprietary Android Studio which goes into the footstep of Visual studio i.e. requires administrator right to install and collects telemetry by default.

Mature API

When you read the title, you might have wondered if I am nuts. Android and iOS are way more mature, shouldn't they?

Well, I do not think so. The UWP supports virtualized storage (see IStorageFile). It abstracts the notion of a content so an IStorageFile can be a file that comes from OneDrive or Dropbox or any other location. It has file picker dialog which you can easily fire up to ask a user to pick up a file which is also service agnostic: the app just has the file which it can read and write and not to worry about where this file comes from and deal with networking and caching. For instance, if I fire up the dialog to select a file, UWP will show user a list of possible storage app such as Dropbox, local, etc. It would be a pain to support such a thing (which I actually accomplished long ago).

Android and iOS perhaps does NOT have a notion of roaming settings where application data can be synchronized across the phone and the PC. For instance, some applicable settings of Outlook app on my phone (those that is not UI-related for instance) should be synchronized with that of my PC and vice versa. My text editor theme, for instance, should be very well synchronized.

XAML is more mature than Android XML layout. For instance, there is a native notion of data binding, automatic trigger, etc. The ListView for instance supports lazy data loading (loading more data as you scroll down instead of all at once, you have to write lots of code to have that feature on Android).

The Android API and the underlying system is also much less stable. Google changed the constraints all over the time. For instance, Android 4.4 removes app access to SD card. (They did add it back in 5.0 with a catch.) Android has always been meant to be open and customizable. Google's effort to curb the system is doing more harm than good.

The things that blow it all

Despite many good points that it has, the UWP has several major drawbacks that are hard to justify.

The first is its lack of documentation. As I have encountered over and over again such as this question and this question on stackoverflow, Microsoft API documentation is extremely sketchy; obviously building on its 40 years of tradition of mysterious error codes (HRESULT). On this point, Android is much better.

The second thing is its API design (probably followed Microsoft long tradition design by committee) which lacks consistency, logic and easy of use i.e. developer friendly as I have kindly pointed out on stackoverflow. One thing I extremely hated is the fact that all the non-asynchronous API calls are now removed: Every potentially long running piece of code needs to be wrapped around a create_task().get(). The developer should know how best to optimize his/her code. This mentality that everyone is a child and that nobody knows anything of Microsoft is not going to make UWP fly; it only show that Microsoft (just like many other corporations) is basically a hypocrite; their mission is not to "empower every person on Earth" but more to "take away the freedom of every PC user on Earth".

As a side note, another thing I hated about Windows 10 Mobile is that it neither allows users to change default browser nor to completely uninstall the pre-bundled crap apps such as OneNote.

The bottom line

I could go on but let us stop here. UWP is a superior platform compared to Android and iOS even with its severe limitations. However, I would advise against UWP development due to its shortcomings outlined above, at least for now. Stick with Win32 or Linux, they will be around for a long time to come.

Despite the fact that the world is going more mobile, I do not think it needs more mobile applications. I myself spend most of my time on phone with a browser and Pandora. Serious work applications that I need for software development, design, graphics processing, writing tools and doing computations is only appropriate on the PC environment. This is the lesson I have learnt from creating TeXPortal which I have not used for even a day and truly regretted spending time making. (And no, Continuum is not going to save the day. We are not in the era where HDMI screens just lie around for free use like trash bins. Even ubiquitious WiFi is not there yet. And towing along a screen is more a burden than bringing my laptop.)