Earthquake behind the UWP

, 8 minutes to read

Dur­ing Mi­crosoft Build 2019 con­fer­ence many peo­ple asked about the fu­ture of UWP be­cause there were very few ses­sions ded­i­cated to it. It may look like noth­ing new is hap­pen­ing, but the op­po­site is the truth. Mi­crosoft is chang­ing ar­chi­tec­ture of the whole stack. The vi­sual layer is be­ing de­cou­pled from the op­er­at­ing sys­tem and ahead-of-time com­piler with .NET im­ple­men­ta­tion are be­ing merged with .NET Core. Things are mov­ing for­ward.

.NET 5

The biggest an­nounce­ment of the con­fer­ence was an in­tro­duc­tion of .NET 5. It is Mi­crosoft’s sil­ver bul­let for soft­ware de­vel­op­ment and there­fore also the fu­ture of UWP. These are words of Scott Hunter, Di­rec­tor Pro­gram Man­age­ment of .NET, from .NET To­day and To­mor­row in­ter­view:

We an­nounced that UWP is on the roadmap for .NET Core 3. I mean that we would have the ability to run UWP app on the top of .NET Core 3 stack. To­day, the UWP run­time is called .NET Na­tive AOT com­piled run­time that we have for Win­dows Store ap­pli­ca­tions. In the .NET Core 3 wave you would not have AOT com­piler. You would run on the same frame­work we have. What we do is to take a .NET Core 3, make a pack­age, put it in Store and the Store ap­pli­ca­tion is de­pen­dent on that pack­age and run. As you get the .NET 5 wave we will then have an AOT com­piler which would be the mimic of .NET Na­tive for those ap­pli­ca­tions. What it means is in the 3 wave you would have the abil­ity of UWP ap­pli­ca­tion to take ad­van­tages of all fea­tures in .NET Stan­dard 2.1 and run on .NET Core 3.

As you build UWP ap­pli­ca­tion to­day you de­velop lo­cally against Core CLR and then you pub­lish it pub­lish .NET Na­tive. Those are two dif­fer­ent run­times which means some­times your lo­cal de­vel­op­ment ex­pe­ri­ence is “it works great and when you pub­lish to the Store it does not work. So, I think an­other ben­e­fit of UWP on .NET Core is you will have the same de­vel­op­ment story as your pro­duc­tion story. Which means it will make de­vel­op­ment eas­ier.

UWP de­vel­op­ers will no longer be an iso­lated is­land with its own .NET Frame­work pro­file. Hu­man resources needed to keep UWP up-to-date with the lat­est .NET Stan­dard could be moved to UWP XAML. AOT com­pi­la­tion will be re­spon­si­bil­ity of .NET 5. An­ders He­jls­berg, au­thor of Turbo Pas­cal, Del­phi, C# and Type­Script, said in the 'Look Back' on C# in­ter­view:

Prob­a­bly the biggest in­flu­ence was when we added gener­ics which was from .NET 1.0 to .NET 2.0. That was a big change and had a lot of new op­codes in the run­time and new meta­data for­mat and so forth. But then we made (what I think in ret­ro­spec­tive was prob­a­bly a mis­take) in sense that .NET run­time is a Win­dows com­po­nent and it ships with the Win­dows op­er­at­ing sys­tem and it can­not run side by side with other ver­sions of .NET. And that in a sense put hand­cuffs on evolv­ing any­thing in the run­time. And there was a num­ber of years we re­ally band over back­wards to do ev­ery­thing in the com­piler in­stead in the run­time. But now with .NET Core we fi­nally got where I think we should be in the first place, which is run­time can in­stall in di­rec­tory, run side by side, you can delete it and its gone, it is like it never was on your ma­chine. At that point you can have dif­fer­ent ca­pa­bil­i­ties in the run­time and we start to look at things we could not have done be­fore.

All the good things of .NET Core will be also avai­l­able for UWP apps. And there is a lot of things like gRPC or Java in­ter­op­er­abil­ity.


Lind­say Kubasik, Senior Pro­gram Man­ager work­ing on the Win­dows UI plat­form, noted about the fu­ture of UWP dur­ing the Win­dows UI plat­form roadmap in­ter­view:

We are do­ing a lot of work to de­cou­ple the pre­sen­ta­tion plat­form from the core op­er­at­ing sys­tem which gives you the op­por­tu­nity to have ac­cess to all of the new UI fea­tures we are build­ing on down­level ver­sions of Win­dows.

Joe Steg­man, Group Pro­gram Man­ager for UWP XAML, con­firmed this strat­egy with some ad­di­tional tech­ni­cal de­tails:

On the top of Di­rectX, we have a visual com­po­si­tion layer and XAML on top of that. Di­rectX stays on the plat­form, but ef­fec­tively we are de­cou­pling the com­po­si­tion layer (the vi­sual layer if you will and an­i­ma­tion layer and some of our in­put layer and ev­ery­thing above that in­cluding the all XAML stack and the XAML frame­work) and mak­ing all of that avai­l­able on pre­vi­ous ver­sions of Win­dows 10. So ef­fec­tively you just need a base­line ap­pli­ca­tion run­n­ing on RS 2 and then you can use the stack on any Win­dows 10 ma­chine greater than that.

This ba­si­cally means that UWP apps will be as eas­ily portable as games. They will rely only on a spe­cific ver­sion of Di­rectX and Win­dows Run­time. As we al­ready know, Di­rectX and Win­dows Run­time are main­tained as back­ward com­pat­i­ble. To­day, the biggest headache of UWP apps is the back­ward com­pat­i­bil­ity over­head in the user in­ter­face be­cause user con­trols are em­bed­ded in the op­er­at­ing sys­tem. Embed­ded con­trols in the app is the ap­proach which games al­ready estab­lished decades ago and how it in my opin­ion should be done in the first place.

Win­dows UI Li­brary con­tains con­trols which are de­cou­pled from the plat­form. They are shipped out­side Win­dows as NuGet pack­ages. The up­com­ing ver­sion will con­tain Tabs con­trol (which is used in the new Win­dows Ter­mi­nal), input val­i­da­tion or Teach­ing tips.

Long-term project

The truth is that UWP apps lost a lot from its sense when Mi­crosoft de­cided to stop man­u­fac­tur­ing phones and no one else ships Win­dows 10 as a mo­bile op­er­at­ing sys­tem, but when we con­sider why that hap­pened we must ad­mit that the soft­ware in­fras­truc­ture was not ready for mo­biles with touch dis­plays. Sil­verlight on the top of Win­dows CE, then Win­dows Run­time XAML Frame­work and fi­nally UWP, don’t for­get to Portable Class Li­braries and Shared Projects, de­ploy­ing apps via Zune app and later di­rectly from Vi­sual Stu­dio with com­bi­na­tion of all de­pen­den­cies to dif­fer­ent op­er­at­ing sys­tem ver­sions, the ex­is­tence of Win­dows Phone Mar­ket­place side by side with Win­dows Store and a fact that the first wave of de­vices was stuck on Win­dows Phone 7.8 and the sec­ond on Win­dows Phone 8.1 – all of that to­gether caused one huge pain and even big­ger fail­ure.

The fast progress made Mi­crosoft man­agers happy from ag­ile de­vel­op­ment rather than mak­ing de­vel­op­ers happy from a rock-solid base­ment for their apps even at the cost of a de­lay. Mi­crosoft has learned and is prepar­ing it­self for the fu­ture. Win­dows 10 op­er­at­ing sys­tem and Mi­crosoft Store are now ready for up­com­ing de­vices (what­ever it will be) bet­ter than ever be­fore.