Universal Windows Platform leaves impression of amateurism

I am an author of Share to Speech app, it was included in the official Best of 2014 in the Windows Store, featured many times in the Store and yes I feel Microsoft as a friend.

I've planed to submit the Windows 10 version of the app today, but I am instead forced to write this. I'll try to focus on the facts, and not to let my anger talk about the issue.

I've joined the Windows Insider program, and started to update the app for Windows 10 preview. At first APIs that I have used were useless in some build 1003x, so I could work only on some UI elements and sorting out exceptions, but soon in some build 1006x at least some stuff started to work, and I could work a bit more serious. What I have discovered through the work is that many things were subtly changed from Windows 8 to Windows 10, and to make the app work properly (not just that it can start), it takes a good amount a work, I would say for a reasonably good app it must be in weeks, especially if you try to consolidate different Windows Phone and Windows 8 versions. This was unpleasant surprise considering how expectations are made that you can port even from iOS to Windows in short time (which is probably true for games), but not something that was unacceptable for a new platform, just I think that Microsoft made wrong expectations which usually isn't a good thing.

Last week I had made something that I've considered to be the final version. It worked properly on Windows 10 RTM with the Windows SDK preview. You can see a screenshot here: https://twitter.com/labsii/status/624623847782789122.

Many people wondered why final SDK is to be released AFTER Windows 10. And while they complained about this I really tried to find good reasons for this, like that Microsoft wanted to release Windows for back to school season and couldn't make SDK on time, and also that Microsoft will role out updates gradually and submitting the app a day or two after the release will be on time for most users. And I still think that.

What wasn't right is that documents for submitting to the Store should have been prepared and launched before. I understand that the Store submission backend and frontend can't be launched until it works properly, but you can say to developers what screenshots they need to prepare, what kind of descriptions etc. So that one doesn't have to rush for that after the final SDK is released.

Whatever, the final SDK was released hours after the start of the Win 10 update. After installing it and the final Visual Studio, I was caught in the first unpleasant surprise. Visual Studio could not load my projects! It is really, really incredible that Microsoft had to change the structure of project definition files several months after that it has introduced a new format for Windows 10 Preview. Still at least the issue is documented and you get a good step by step description of what to do. In an hour or so you can complete those dozen of steps, and then... well I had thousands of exceptions. It all worked after the Visual Studio restart, but I don't think that this step was ever mentioned or I might have missed something. But still OK, if you work in preview software, you are never granted that things like this won't happen. So it isn't unacceptable. But still it is a very poor practice.

And here we come to the point of this post, and that is that Microsoft did one incredible thing that anyone who has any experience in software development would never do - they've significantly changed the APIs behavior in the final stage of development!!!!!!!

I can see some smaller and nice touches, which is the things that should have been done - like that they have unified selection highlight for different controls, and that is what is done at this stage of development - small changes that have little risk of breaking something else.

But the first time I succeeded to start the app... the UI was broken!!! SplitView (the hamburger menu) worked like crazy disappearing whenever it wants, and many titles were missing. This would confuse everyone, and that includes me. But after some time, I have discovered that the problem is in the compiled binding - a new technology introduced in Windows 10 to improve the performance. After some experiments, I've got that it actually was broken on just one particular property of SplitView, but somehow it further propagated the problems. So it wasn't incredibly hard, but just not the thing that you should expect at this stage.

And now here we come to the biggest problem - BackgroundMediaPlayer. It is the API that originated from the Windows Phone and it has some advantages there (like working without any UI), so it was reasonable to focus to make app work using that. Unfortunately, it has never worked the same on the Windows like on the Windows Phone and was buggy, but I had made it work. But after final SDK, it seems impossible. The app works nice when it is launched, but when the app is launched again it is muted, the background process updates the UI, but there is no sound. I've spent two days trying hundreds of combinations, trying to work in a strictly documented and every other way, and no it doesn't work.

So it is likely that I will have to turn onto using other APIs that work for the desktop. But it will take time. And double code to maintain. But nothing feels as bad as a feeling that UWP is currently not developed with developers in mind.

Satya, Terry, Joe, Gabe and all other guys, I am sorry but this is not how the things should be done. Hope that this post will get high enough and that some of you will read it, and do something to improve this. Because as UWP is planned to change fast, if this is a sample of the future, not that new developers won't come, but even every old developer will leave this madness.