Replies: 2 comments
-
|
👉P.S Rationales behind Q1. Today most of the win32 developers including individual open source developers refuse to update their desktop apps because even if they update , their existing app just keeps working for the same userbase also their userbase remains the same. letting existing huge number of win32 apps run on other platforms will give some serious reasons for developers to update their existing desktop apps because of their potential user userbase growth and userbase is the thing Developers mostly cares about . ◼◼👉 Apple is letting their biggest asset ~the existing huge number of their iOS apps to run on MacOS, it really entices to develop for them from a Developer perspective because of the potential userbase growth for their apps. It's no secret that UWP apps aren't Windows biggest asset, but the existing win32 apps are. why not MS too leverage their huge asset the existing win32 apps to run on other platforms with proper modifications ? this is more about making win32 apps transition to universal the most easiest way possible with the help of Reunion without breaking most of the functionalities and rewriting too much. I know this is telling too much on the abstract to assess on , but once MS approves the idea that win32 apps can go universal, developers will start to provide feedback on which win32 APIs they need to run on appContainer/need OS-managed APIs Brokerings and all these stuffs. 👍
this essentially doesn't harm UWP developers at all since they already enjoy all these stuffs and project reunion in the long term will unify+merge the two app models anyway. 🙂 |
Beta Was this translation helpful? Give feedback.
-
@ecovio1 Here is my current understanding based on following the Project Reunion repository: You shouldn't expect support for your Win32 app (using Project Reunion APIs or not) to run (natively) on all the other Windows device categories any time soon, nor is there a guarantee that such support will come at all in the future. @ptorr-msft gave such a comment here. If you need to deploy your app or run it natively/"best" on Windows devices like the Xbox, HoloLens, Surface Hub, IoT, potentially 10X (let's wait and see how the 10X story will unfold), then a UWP app is the way to go. New Project Reunion APIs will, however, run on all supported Windows versions and be available for all app models (though their behavior might differ depending on whether, for example, an AppContainer is used or not) (mentioned here). And this brings me to an important benefit of using Project Reunion APIs: What this means in pratice for an existing Win32/UWP app is the following: If you want to have the easiest path from one "app model" to another, your app should use as many Project Reunion components as possible. For UWP, you are already at a great starting point there since, for example, WinUI is based on UWP XAML. In case of your existing Win32 app, you have more work to do. In that case, you will likely need to re-write your app UI to use WinUI instead of WPF/WinForms/.... However, using WinUI in your Win32 app will give you considerably more benefits than just a potential easier switch to the UWP app model in the future (Fluent Design, touch-friendly UI, scalability, using the leading Windows UI platform,...). Which means app developers might want to re-write their app UIs anyway for WinUI to ship with a modern UI. We are seeing this API unification not just for the UI stack but also for many other areas like the Windowing model, shell interaction (notifications, badges), file system APIs, startup and background tasks, clipboarding,.... So while it might never be as simple as setting a compile flag
WinUI is part of Project Reunion and as noted earlier, if you currently have a UWP XAML app, then you are in a great place. While there might be a few changes required to your code-base, no significant changes should be required on the developer's part. Many other Project Reunion APIs will likely be modeled after existing WinRT APIs so as a UWP developer, you should be in a great position. It is also worth noting that the componentization design approach for Project Reunion means you as a developer can pull bits and pieces pf Project Reunion into your existing app at your own speed without a "nothing-or-all" approach. If, in theory, some Project Reunion components require a little more work to be integrated into your existing app, you can still first make use of the Project Reunion APIs which will be easier to consume.
Project Reunion consists of many different components. Some of them are already available (like MSIX deployment), others are already partly available (like WebView2 (for UWP devs, WinUI 3 preview is required for now)) and other components are on track to be released in 2021 (like WinUI). You might also want to keep an eye on the roadmap for any changes. Work is underway and just recently, a bunch of new API specs were created. As we keep watching this repo, I expect we will get more details in the coming months about Project Reunion APIs outside of WinUI, WebView2,..... |
Beta Was this translation helpful? Give feedback.
-
Just stumbled on Project Reunion . I will like to thank Windows Platform Division that they are finally reuniting the win32 + winRT APIs mess created since windows 8. Future looks really exciting and simplified. 🙂 👍
I will like some enlightenment on some things that were not clearly mentioned in readme that
👉1. will All Project Reunion APIs be able to run on future and existing other windows powered platforms (eg : Xbox/Hololens) ?
suppose I have an existing desktop app , will I be able to make it available on other windows powered platforms using the Project Reunion APIs( eg: uwp app lifecycles, appContainer) without rewriting it from scratch and breaking my app desktop apps functionalities ?
👉2. will existing UWP (winRT and Desktop Bridge) developers who had already invested/are invested be able to take part in this Project Reunion API without the same rewriting from scratch and breaking their apps functionalities ?
👉 3. when will Project Reunion APIs be made available for production ready use ?
this is the most un-enlightened area. If MS doesn't/can't make some commitments, it doesn't give developers Confidence in windows development .
If MS paying attention to Apple's recent advancements, they have been very clear with developers what to expect in the near future and their commitments shows .
that being said, windows developers will have no choice rather than to completely switch to Web Development or to Apple .
Just give us a clear commitment when existing win32 developers can take part into Project Reunion by the end of 2021 and in the same manner when existing UWP developers can take part by the end of 2022.
and what developers should do until then.
project reunion should have been happened a few more years back , we know this Unification transition won't happen overnight but again the more delay Reunion will cause, the more opportunities for other OS-vendors to shine. 🙂
Beta Was this translation helpful? Give feedback.
All reactions