The next generation of Windows Apps theory

45

With all of the changes to Microsoft’s developer story it is hard to tell where they will land and how it will affect different developers. But for an educated guess here is my theory on the next generation of apps for Windows.

Windows Core Apps

  • Running on .Net Core 3, eventually .Net 5
  • XAML UI with first party controls built in WinUI
  • Targets Windows 10, Lite OS, HoloLens, Xbox, IoT, and Xamarin
  • Similar APIs to UWP, limitations on background running, runs in sandbox, suspend/resume, etc.
  • More Windows APIs like the running in System tray, create and manage windows and panes etc.
  • New APIs to manage 2 screens, rotating screens, machine learning magic
  • Packaged to MSIX
  • Optional distribution through the Microsoft Store

Migration Paths

  • UWP apps are probably more strict than Windows Core Apps will be so they can be migrated with some package manifest changes.
  • WPF apps would need to target .Net Core instead of .Net Framework, also if they are making use of now restricted APIs they will have to swap over to new APIs if possible. then package to MSIX
  • WinForms apps probably similar to WPF, target .Net Core, ensure no restricted APIs are used, and package to MSIX

That’s my theory. I think most of it is pretty obvious, I’m curious what everyone else will think is the next step for Windows Developers, and what they want in the next generation of Windows apps.

Comments (45)

45 responses to “The next generation of Windows Apps theory”

  1. longhorn

    Very possible.


    But Microsoft can't pull the rug out from under existing applications. Now Edge is a classic Win32 application. This time there will be no swift changes. Microsoft has learned the lesson that an ecosystem has to be moved forward gently. Otherwise applications may disappear. Support for LOB applications is the biggest strength of Windows. These applications will move forward slowly.


    The value of Windows is long term evolution. It has always been like that because Windows is a productivity platform, maybe the only true productivity platform in existence. Therefore WaaS is a joke, not suited to Windows.


    • hrlngrv

      In reply to longhorn:

      . . . Otherwise applications may disappear. . . .

      Or worse, those applications could run under wine under Linux but not under the lastest version of Windows. FWIW, I've never been able to get any version beyond Office 2003 to run under wine, and I don't use anything from Adobe. Pretty much every other piece of Win32 or older Windows or DOS software I still try to use runs OK under wine or dosemu.

      MSFT has no choice but to support 15-year-old Windows software. That's a running 15 years, so no further need to support 16-bit Windows software or even pre-XP 32-bit software. However, Windows does need to be able to run software last updated in 2006 if MSFT means for the Home variant to keep selling.

      I figure MSFT needs to accept many Windows users' adamant intention to stop using certain old software only when it's pried from their cold dead fingers. Come out with a WinBox app like DOSBox, and give it all the capabilities of Windos XP SP3. Sandbox it from the rest of Windows.

      maybe the only true productivity platform in existence

      Maybe, but there are R and TeX workstation setups for Linux which would suggest otherwise.

  2. Intara

    UWP is dead, dead, dead...

  3. christian.hvid

    [ Paul, please don’t read this post – I don’t want you to have an aneurysm. ]


    I’m a little slow, but I think I finally understand this confusion around the death or non-death of UWP (it’s almost like Schrödinger’s cat at this point). For a while, I couldn’t figure out whether ”dead” meant outright discontinued, simply de-emphasized or discreetly put into zombie state. Turns out it’s neither of those. UWP is really being split in half, with the presentation layer moved into WinUI 3.0+, where it can be consumed from any application model going forward. What is left is a sandboxed app model that is compatible with Microsoft’s Win32 as well as non-Win32 platforms. Both of these halves will remain and continue to be developed, but it’s not the monolithic UWP we once knew. And I won't be surprised if it's renamed back to WinRT.


    On the surface, this is certainly sound thinking: let the presentation layer and logic be the same across platforms, and use different application models depending on whether you target full-fat Windows or a subset like Hololens. But here’s the problem: one of the reasons developers spurned UWP is the sheer ugliness of its associated design language. The Bauhaus inspired Metro design that came with Windows 8 was useless for desktop applications, but at least it was light and elegant. It has now devolved into a typography that on one hand strives to be clean and minimalistic (although it’s really just primitive), and on the other hand is being covered in a thick layer of the ghastly visual effects they call Fluent. So how will Microsoft convince developers to use WinUI when every control needs to be restyled before use?


    Microsoft has another modern design language that is actually both coherent and good-looking: Office UI Fabric. But this is only available to web developers, and more specifically to React developers. Porting this to XAML would allow people to create desktop applications with a distinctly Microsoft-y default look, but without the messy design of native Windows. (Speaking of Office: the Office Team appears to have more or less settled for React Native for app development, much to the disappointment of Xamarin fans. And now they are porting React Native to Windows, where it will compile to – wait for it – UWP!)

    • longhorn

      In reply to christian.hvid:

      Interesting, thanks. "UWP is dead" didn't make sense - even if that was what Paul was told. It's not like they would just throw away this work instead of evolving/morphing it into something new. And the UWP apps in the Store are here to stay until the developers adopt these newer technologies. It may take a while.


      • Paul Thurrott

        In reply to longhorn:

        It's amazing to me that some still misunderstand this. Microsoft can't "throw away" UWP. What they can do is stop acting as of (or pretending that) it is the way forward. It is no longer "the" app strategy. It's still there. It doesn't disappear.


        That's all this means.

        • darkgrayknight

          In reply to paul-thurrott:

          The make everyone move to the universal windows platform strategy is dead. Universal Windows Platform applications will live on in cross device (PC, Xbox, HoloLens) needs and the capabilities of UWP are being pushed back into Win32/.Net/WPF/WinForms/etc. What is interesting is that the Ideas within that strategy were also revamped into sandboxing non-UWP apps. This is enormously better than the previous strategy, though the core ideas are nearly the same.

        • christian.hvid

          In reply to paul-thurrott:

          Ok, so that was meant as a light hearted joke about your recent involvement in a somewhat surreal Twitter war around UWP. Nothing more. But I should probably know better than making jokes in a foreign language.

    • illuminated

      In reply to christian.hvid:

      Wasn't restyling the reason why WPF had a very slow start as well?

      When WPF first appeared I could use VisualStudio WinForms designer to make an app in five minutes and have something looking like just another app. Boring but OK. WPF on the other hand had pretty poor designer and apps with default styling looked like junk. WPF did not start slowly because everybody just loved WinForms. WPF development sucked. Learning curve was steep and even Microsoft was not using WPF for some time.

      • christian.hvid

        In reply to illuminated:

        Maybe, but I think the learning curve was the real drag on WPF adoption. Aside from having to learn the intricacies of XAML, you also needed to wrap your head around MVVM, which was a completely new concept at the time.

      • yaddamaster

        In reply to illuminated:

        This comment a thousand times - 'YES!!'


        Most developers I know have to maintain multiple skillsets: might be java or .net on the backend, some windows and linux and now osx. Plus the myriad different other solution design approaches. But the last thing front-end developers wanted to do was do what was necessary to master front-end web dev AND also understand XAML. I tried. Did a few simple WPF LOB apps and a simple Silverlight control back in the day. Quickly said "heck no" and moved on. It was painful. I had zero desire to put myself through that nonsense.

    • maethorechannen

      In reply to christian.hvid:

      Office Team appears to have more or less settled for React Native for app development, much to the disappointment of Xamarin fan


      Even worse, the Blazor team are looking at doing something similar to React Native, The Office team's one thing, I'd be surprised if they had any contact with that part of MS does Xamarin, but Blazor are building client side Blazor on top of mono and I'm guessing that they are a lot, lot closer to the Xamarin people on the org chart.

      • christian.hvid

        In reply to maethorechannen:

        I think Daniel Roth got a little carried away when he started envisioning Blazor as a universal framework spanning from native mobile to server-side web applications. But hey, Flutter is doing it, so why not? But yes, I believe Xamarin is heading for zombie-land pretty soon, and they know it.

    • dontbeevil

      In reply to christian.hvid:

      Fabric is available for web, ios and android ... it's not available on UWP because IS the UWP design language

  4. dontbeevil

    Probably we're not going to see this news here: Rudy Huyn moved to MS to focus on UWP development

    windowscentral.com/well-known-uwp-developer-rudy-huyn-joins-microsoft

  5. jules_wombat

    None of this is relevant. No sensible developer would start any major development on .NET or Windows only platforms. Its a very dead duck. The consumers, including enterprise expect multi platform access. Microsoft themselves admitted as such way back at Build 2011. Need to listen to what Satya is actually saying.

  6. jules_wombat

    Seriously who cares. Microsoft has dumped on all the core .Net developers at Build 2011, and has not had any credible development since then. All their development platforms have failed since then, leaving just a confused mess.

    It's an Web and Android first client platform now, not Microsoft. And for Android, we have Xamarin who at least have more confidence in .Net than Microsoft ever had.

    • Usman

      In reply to Jules_Wombat:

      .Net devs aren't just Windows client application devs. The best thing to happen to .Net is for it to go cross platform and bring .Net Standard.


      Which means logic can be targetted to Net Standard and run on any platform since Unity, Xamarin, UWP, .Net Core and .Net Framework implement .Net Standard.


      I can reuse my data repositories and domain models that are used in web apis, can be used exactly the same way in xamarin and also in unity, I'm not tied to Windows only applications.

  7. Usman

    The future of Windows client apps will be XAML Desktop with native support for WinUI 3. (Link to Build 2019 slide)


    You have two choices, run as a traditional desktop app, which will use .Net Core 3+; or as a UWP/WinRT app, in that case it will use WinRT, and currently supports .Net Standard 2.0.


    The current migration steps for WinForms/WPF applications are :

    • Target the backend C# code to .Net Core 3/.Net Standard
    • Update the UI from classic WinForms/WPF to WinUI 3 controls via XAML Islands


    I believe the only migration path to XAML Desktop, will be for WPF applications that are exclusively using WinUI 3 components through XAML Islands.


    UWP will still be the cross windows platform (IoT Core, Hololens, Hub, Xbox) since XAML Desktop is built on top of Win32 APIs rather than WinRT.


    I think the most rational option for greenfield projects would be to build via web technologies either as a website, pwa or electron app. If you want it cross platform including iOS then it makes sense to go with a cross platform framework like React Native or Xamarin.

    • thejoefin

      In reply to Usman:

      What kind of API mixing and matching do you see happening? Will anything get pulled in from WPF? And what new APIs could the Windows team cook up?


      Do you see Blazor as a serious competitor to React, Vue, etc.?

      • maethorechannen

        In reply to TheJoeFin:

        Do you see Blazor as a serious competitor to React, Vue, etc.?


        I don't.


        For a start, moving from "Javascriptland" to .Net is quite a jump. You can go from Angular, to React to Vue to whatever is the new hotness without any extra cognitive load other than learning the new tool itself (I think Angular kind of shot itself in the foot with the push for Typescript). I think it's the reason why Ruby got dropped in favour of node - you could do the server side stuff without a forced jump in thinking. I think flutter is going to suffer for the same reason, but nowhere near as much as Blazor.


        Also, MS do a really, really crappy job at explaining why people outside the .Net ecosystem should start using it. They seem to be far too focused on keeping people from leaving. What's the compelling reason why someone already using JS based tools would want to switch?


        Another problem (for all of .Net) I see is the over-reliance on Visual Studio. Yeah, there are command line tools but there's just far too much fallback to VS.


        Also, I take it we're only talking about client side Blazor. Because server-side Blazor just seems to be bat**** insane. Technically impressive, but insane. Thinking about it, running .net in webassembly doesn't seem like the sanest idea either.

  8. jimchamplin

    Usman really spells it out. I think Microsoft finally learned their lesson on churning the damn API every few years. First we had WinRT in 8.x, then the just-different-enough-to-be-incompatible-with 8.x UWP standard. It's the same thing they did on Windows Phone. They had 7.x, then threw the whole API out for 8.x then went and again replaced that with UWP.


    I get the feeling that they realize they've been doing nothing but throwing boulders at developers who have to dodge around trying to keep up. Or, what's really been happening... the developers are leaving. Microsoft now performs damage control by changing course one more time to a much, much more conservative future.

    • Tony Barrett

      In reply to jimchamplin:

      It almost certain Windows Core (or whatever it's called) will have yet another API. Core may be targeted at specific hardware, but MS really aren't helping their case with devs - "throwing them under a bus" is more the term I'd use, time and time again!

      • jimchamplin

        In reply to ghostrider:

        I don't think they will. Their utter failure came from repeatedly changing the goddamn API. Illuminated says even that they'd be surprised to see that same behavior again.


        Win32 is stable. .NET is stable. Hell, .NET Core is stable and under active development. UWP is stable.


        We watched so many post-Longhorn APIs get built up and then forgotten about, but they're all still there. WPF is pretty damn nice, and back in the Vista era there were some really great demo apps that made great use of it. Does anyone remember Yahoo Messenger's WPF demo?


        There's some really nice APIs that target Windows that can make some truly modern software.


        The big question is whether developers will come back...

      • illuminated

        In reply to ghostrider:

        I would be surprised to see MS try the same old API rewrite trick once again.

  9. longhorn

    According to Rudy Huyn there is no need to migrate UWP apps.


    "Let’s be clear about that. No, UWP is far from dead, it’s one of the keystone of the future for Windows. Let’s remind that a large majority of first party apps and Windows components (Start Menu, Action Center, Settings…) are UWP. Let’s also remind that Microsoft invests a lot in this technology: Ink, Windows ML, ONNX…


    These journalists/bloggers writing that UWP are dead, are also the same writing articles about how amazing is Surface Hub 2, how they are excited for the future of Hololens, how Xbox Two will be a revolution…


    I would like to ask them a simple question: what technology will we use to create applications on these devices? If you dream of a folding tablet, what types of applications do you see on it in your dream? Probably not win32 applications.


    To be clear: UWP is the only technology which, when targeted by a developer, ensures an app can run natively on any windows 10 (including variants: Xbox OS, Windows Lite, Windows Core..) device and able to fully use the capabilities of this one."


  10. hrlngrv

    Is a Store approach reasonable/useful for major software? There isn't much desktop software to choose from in the MSFT Store, so I have to wonder whether distribution through the store benefits anyone on the money-making end other than MSFT; I'll stipulate that it may be good for all users, but that doesn't seem to count for much.

    There's also the fact that MSFT itself doesn't use the store to distribute its own major software, e.g., R Open. If the Store isn't good enough for MSFT's software, why should it be good enough for any ISV's software?

    Then there's multiple platform software. I'll stick to R: R itself and RStudio (my own perferred GUI, FWIW) are available for Windows, macOS, Linux, BSD and maybe other OSes. With Qt available for all those OSes, why would developers of that software want to use Windows-exclusive UI frameworks?

    Granted that kind of software is used by less than 5% of PC users, so it may not matter to consumers. However, how much NEW or CURRENTLY MAINTAINED 3rd party software is exclusive to Windows any more? IOW, to what extent can MSFT dictate to Windows ISVs the tools and frameworks they must use?

  11. Paul Thurrott

    Interestingly, I blurted out something like this, but less well-formed, on FRD the other day. My guess was that the future of Windows apps was WPF + .NET Core.

  12. christian.hvid

    Paul speculated the other day that the future of Windows development is WPF. Of course, the future of Windows development will be whatever the majority of developers prefer, but I highly doubt that Microsoft sees WPF as the future of anything. It's a Windows Vista/7-era technology, and even if it now supports .NET Core and XAML islands, its glory days are well in the past. Going forward, I'm almost certain the model for native Windows development will be very similar to UWP, but with access to the full set of Windows APIs.

    • hrlngrv

      In reply to christian.hvid:

      To the extent 3rd party browsers like Chrome, Firefox, Opera, Brave, etc and FOSS like GNU R and LibreOffice are used by a substantial share of Windows users, those all run on Windows, macOS and Linux. To the extent their developers intend for them to look and work mostly the same across all those OSes, those developers may not care what MSFT intends for the One True Path Forward.

      • christian.hvid

        In reply to hrlngrv:

        True, a dwindling number of developers care about Microsoft's intentions, and native application development just isn't a thing these days. But even if almost all "Windows applications" going forward will actually be PWA, Electron, React Native or Flutter apps, any platform needs a native development model too - if only to be the compilation target of other, non-native technologies. And that model has to be light-weight, efficient and up to date with the platform. In other words, not WPF.

    • illuminated

      In reply to christian.hvid:

      There is nothing vista/7-ish about WPF. UWP on the other hand looks like an unnecessary rewrite of the same old APIs from scratch.

      • christian.hvid

        In reply to illuminated:

        It is, in the sense that WPF is targeting Windows 7 and older, and does not natively support the APIs and UI components that came with Windows 8 and 10. For a very long time, Microsoft refused to bring these capabilities to WPF, instead expecting developers to port their applications to WinRT/UWP.


        That didn't happen, so Microsoft has now bolted some Win10 technology onto WPF via XAML islands. It's not a very elegant solution in my view, and having two different XAML dialects in the same application is far from ideal. Still, Microsoft is selling XAML islands as a way to "modernize" legacy WPF applications, with the clear implication that WPF isn't "modern" anymore.


        You may disagree and argue that WPF is modern enough, but Microsoft is likely to want an application model that's built from the ground up to leverage everything that the current and future versions of Windows can do. But they are also supporting developers who prefer to stick with WPF, or even WinForms, something I find very commendable.

        • illuminated

          In reply to christian.hvid:

          What new APIs did MS provide in UWP that did not exist in WPF land? What is that modern stuff? Something besides XAML.

          All I can remember from my failed UWP development adventure was a constant search for the same functionality that was provided by old win32 APIs years ago. That was so pointless.

          • christian.hvid

            In reply to illuminated:

            When WPF was released back in 2006, many WinForms developers reacted the same way: why do we need a completely new way to achieve the same old thing? And it didn't help that WPF had a steep learning curve, so steep in fact that a lot of casual developers never managed to climb it. But Microsoft was ultimately proven right: advances in hardware, user expectations and Windows itself required a new application model, and WinForms just didn't cut it anymore.


            WinRT/UWP was essentially introduced for the same reasons. WPF was tied to desktop computing and couldn't be made to support the wide range of mobile devices that were emerging. Of course, now that Microsoft no longer has a mobile platform, many argue that these new technologies are just unnecessary, and we should all go back to the golden days of WPF. But mobile is not just about phones. A 2-in-1 Windows laptop is also a mobile device, and it has the same needs for gesture support, battery conservation, pen/voice input and other things as a phone or a tablet. And an application model that was designed for desktop PCs fifteen years ago is just not the right answer.

          • thejoefin

            In reply to illuminated:


            UWP provides APIs to access user data from the signed in Windows 10 account stuff like calendar, contacts, calls, etc. without requiring the user to sign into the same account again. Also a more modern inking APIs with recognition and document structure. In-app-purchases and subscriptions are also easier and more integrated with UWP rather than expecting developers to bring their own e-commerce solution. APIs around the Share experience are also available in UWP. Being able to send data to and from apps is pretty neat and a good way to make small utility apps which can be invoked from anywhere via Share.

            • illuminated

              In reply to TheJoeFin:

              Calendar, contacts and sharing could be useful, In-app purchases are nice too but these features are mostly important on mobile which Microsoft abandoned. By the way sharing from UWP apps is a pain. Have a file in some random folder on the disk? Good luck sharing that file using UWP app. UWP apps just look broken. Can't open files, can't save files, can't resize properly, weird controls, etc. etc.


              I am somewhat surprised by your enthusiasm. I would like some too.


              • thejoefin

                In reply to illuminated:

                You can open files with UWP; you can save files with UWP.

                Opening files is not a pain; Saving files is not a strain.


                Controls are different than WPF but are more aimed at devices which also have touch, like the majority of Windows laptops these days. Resizing generally isn't an issue but it does work differently than WPF. You can't resize an app to a 138px X 236px rectangle which doesn't display anything but a little more than the windowing controls.


                It is completely true that UWP cannot touch every nook and cranny of a PC. UWP doesn't junk up a PC registry. UWP apps cannot go crazy eating 90% of a laptop battery. UWP apps need to notify you before watching network traffic. Also UWP apps can't have crazy custom Window shapes and sizes (Sorry Winamp) but to me these things are not an issue. Some devs need zero hurdles to develop an app. To each his own.

  13. ghostrider

    UWP being dead primarily means that there are almost zero developers working on the pure UWP API app model - you know, the app format MS have been pushing for the last 5 years that started with Windows 8. MS have tried every trick in the book, and some new ones, to get devs onboard, but it's failed completely. Now, MS are trying another tact, one that keeps part the UWP model, but also includes parts of Win32. WTF is that all about? This is one of Microsoft's huge problems, as they have no consistency. They're changing things every year - or more, and developers like consistency and a clear path forward.

    Look, nothing is going to replace win32. It was massively successful, feature rich and a known quantity. The fact MS focused on UWP for a number of years meant win32 development was stable and consistent, so devs kept with it to a degree.

    The problem is these days, Windows isn't where the action is. Windows is stale, bloated and requires too much effort. Web development (inc PWA) is truly cross-platform and probably the future, which unfortunately is a future where Windows isn't necessarily required anymore.

Leave a Reply