Microsoft kündigt Project Reunion an und beendet so UWP-Entwicklung für Windows 10
Um Windows 10 als Heimat für Softwareentwickler weiterzuentwickeln, hat Microsoft auf der Entwicklerkonferenz Build 2020 das Project Reunion angekündigt und zudem WinUI 3 gezeigt. Mit Project Reunion soll der Zugriff auf bestehende Win32- und UWP-APIs vereinheitlicht werden und sie über Tools wie NuGet vom Betriebssystem entkoppelt verfügbar machen.
Als Windows 10 im Jahr 2015 veröffentlicht wurde, gab es mit Universal Windows Platform eine Entwicklerumgebung, die es ermöglichte, eine App zu schreiben und diese prinzipiell auf verschiedene Windows-Geräte zu bringen. So sollte es Apps und Spiele geben, die sowohl auf Windows-Smartphones, PCs und der Xbox-Konsole laufen. Allerdings hat sich UWP nicht am Markt durchgesetzt. Nun hat Microsoft zur Build 2020 das Project Reunion angekündigt. So sollen der Zugriff auf bestehende Win32- und UWP-APIs vereinheitlicht werden und sie über Tools wie Nuget vom Betriebssystem entkoppelt verfügbar machen. Es soll künftig egal sein, ob man auf C++, React Native (von Facebook entwickelt) oder .NET (inklusive WPF, Windows Forms und UWP) seine Apps entwickelt, die APIs sollen immer die gleichen sein.
WinUI 3 soll Win32-Apps besser skalierbar machen
Zudem kann jede Windows-App mittels Webview 2 künftig Web-Inhalte integrieren, da Chromium-Technik ebenfalls ein Teil von Project Reunion ist. Ebenfalls können Win32-Apps auch mit einzelnen UWP-Funktionen ausgestattet werden. Die Entwickler-Plattform ist rückwärtskompatibel, sodass auch bestehender Code genutzt werden kann, um die Entwicklung fortführen zu können, aber nicht gänzlich neu beginnen zu müssen. Ein Beispiel ist die in Windows 10 integrierte App "Alarm & Uhr", welche in einer kommenden Version auf WinUI 3 setzen wird. WinUI 3 soll etwa mit einer besseren Skalierung der UI-Elemente aufwarten können und so dem Umstand Rechnung tragen, dass es immer mehr Bildschirme mit hohen Auflösungen gibt. Softwareentwickler sollen also nicht mehr unbedingt UWP-Apps und UWP-Spiele entwickeln, sondern können in gewohnter Win32-Umgebung ihre Desktop-Programme schreiben. Die Win32-Apps können aber ausschließlich auf Windows 10-PCs genutzt werden. Lediglich über Windows Virtual Desktop können entsprechend angepasste Win32-Apps über Server von Microsoft Azure auf Endgeräte mit Android oder iOS gestreamt und so auch auf diesen OS für mobile Geräte verwendet werden.
WinUI 3 wird bereits in ein paar Desktop-Programmen genutzt, etwa von Magix mit dem Programm Vegas Pro. Die Uno Platform soll es ermöglichen, auf einer Codebasis Apps für verschiedene Plattformen zu entwickeln. Dieses Entwicklerplattform ist als Open Source auf Github verfügbar. Aktuell ist WinUI 3 als Preview-Version für Entwickler verfügbar und soll später in diesem Jahr dann generell erhältlich sein. Auch WinUI wird via Github dokumentiert.
UWP als "eine App für alle Versionen von Windows 10" gibt's nicht mehr
Immer wieder gab es die Aussage zu lesen, dass Entwickler bei UWP nur eine App entwickeln müssten, welches dann auf allen Windows-10-Geräten lauffähig ist. Das ist aber etwas zu kurz gegriffen, da die Entwickler immer selbst angeben mussten, auf welchen Endgeräten die jeweilige App im Microsoft Store zur Verfügung stehen darf. Die Realität sieht so aus, dass es wohl nur sehr wenige Softwareentwickler gab und gibt, die tatsächlich eine UWP-App oder ein UWP-Spiel programmiert und veröffentlicht haben. UWP ist also offiziell tot, da Microsoft nun nur noch von einzelnen UWP-APIs spricht und nicht mehr über eigenständige UWP-Apps, wie noch anno 2015.
Bereits seit letztem Jahr gibt es ein neues Containerformat namens MSIX. Bei diesem unter Open Source stehenden Format wird derartig verpackte Software von Microsoft zertifiziert und kann dann auf einer Plattform seiner Wahl an Kunden vertrieben werden. Zumindest PC-Nutzer haben so auch weiterhin Wahlfreiheit bezüglich ihrer Installationsquellen. Alle via Win32-Apps mit WinUI 3 werden standardmäßig im MSIX-Containerformat verpackt und können so auf verschiedenen Distributionsplattformen vertrieben werden. Zudem wird Project Reunion bei Github dokumentiert, sodass Entwickler hier auch Beispiele und Vorlagen finden.
Ebenfalls lesenswert: Microsoft über PC-Gaming: Steam-Unterstützung und neuer Xbox Game Pass for PC
Fakten zu Project Reunion und WinUI 3 für Win32-Apps:
- Project Reunion soll der Zugriff auf bestehende Win32- und UWP-APIs vereinheitlicht werden und sie über Tools wie NuGet vom Betriebssystem entkoppelt verfügbar machen, wie Microsoft auf der Entwicklerkonferenz Build 2020 angekündigt hat.
- Die Entwickler-Plattform ist rückwärtskompatibel, sodass auch bestehender Code - wie bei manchen Microsoft-Apps - genutzt werden kann, um die Entwicklung fortführen zu können, aber nicht gänzlich neu beginnen zu müssen.
- Project Reunion ist auf Github einsehbar und integriert auch nativen Web-Content mittels Chromium in Win32-Apps, wenn dies gewünscht ist.
- Zudem können Win32-Apps mittels WinUI 3 mit einer skalierbaren Benutzeroberfläche versehen werden.
- Alle Win32-Apps mit WinUI 3 werden standardmäßig im MSIX-Containerformat verpackt und können auf verschiedenen Distributionsplattformen für Windows 10 vertrieben werden.
- Die Win32-Apps können aber ausschließlich auf Windows 10-PCs genutzt werden. Lediglich über Windows Virtual Desktop können entsprechend angepasste Win32-Apps über Server von Microsoft Azure auf Endgeräte mit Android oder iOS gestreamt werden.
- Eine erste Win32-App mit WinUI 3 ist etwa Magix Vegas Pro.
Quellen: Microsoft (1), Microsoft (2), Microsoft (3), Microsoft (4), Github, WinUI, Drwindows (1), Drwindows (2), Reactnative, Nuget, Magix
Entwickler haben aber bei "Project Reunion" drei neue Möglichkeiten, die Sie nutzen können, aber nicht müssen:
- Win32-App mit WinUI 3 versehen und so etwa eine App mit 15 Jahre alter Codebasis mit einer neuen Benutzeroberfläche versehen, welche etwa eine bessere Skalierung ermöglicht und auch für die Touch-Bedienung geeignet ist, falls der Nutzer ein entsprechendes Display angeschlossen hat.
- Win32-App mit Inhalten aus Webseiten ausstatten. Schließlich ist in Project Reunion auch Webview 2 dabei, so dass Entwickler so auf Basis von der Chromium-Engine nativ Web-Inhalte in die Win32-App integrieren können.
- Win32-App mit Anbindung an die Microsoft Azure Cloud ausrüsten und so diese App mittels "Windows Virtual Desktop" auch auf Geräte mit Android oder iOS streamen.
-> Sämtliche Win32-Apps mit WinUI 3 werden standardmäßig im quelloffenen Containerformat "MSIX" verpackt und können und dürfen auf verschiedenen Distributionsplattformen vertrieben werden.
Ich bin reichlich retro-verliebt, aber selbst ich kenne kein 15 Jahre altes Tool, das ich heute noch regelmäßig unverändert über eine GUI nutze. Erst recht nicht auf einem Touch-Gerät. Das wenige derart alte, was mir noch wichtig ist, arbeitet im Hintergrund oder dient einmalig zur Einstellung und bietet dabei meist einen Funktionsumfang, der schon damals umständlich zu bedienen war, für den sich aber eben nie etwas bessere ergeben hat. Für die Zukunft wäre es für mich also wichtig, dass diese Tools auch 2025 noch korrekt mit dem Betriebssystem zusammenarbeiten können. Hilft Reunion dabei weiter? Wird eine langfristig unveränderte Unterstützung garantiert? Und Entwickler, die ein und dieselbe Software derart lange Pflegen, ohne sie in großen Teilen nach fünf oder zehn Jahren neu aufzubauen, werden meist in professionellen Umgebungen unterwegs sein, in denen diese Software zum Teil auch noch auf den gleichen Maschinen eingesetzt wird. Wie gut laufen im Rahmen von Reunion erstellte Anwendungen also unter Windows XP?
Wo ich dagegen wenig Nachfrage erwarte: Plattformübergreifende Distributionsformate für Code, der aus Zeiten stammt als nur eine Plattform von belang war und Vertrieb durchgängig auf CD erfolgte. Oder Cloud-Streaming auf iOS für Anwendungen, die in einer Zeit erfolgreich waren, als es noch kein iOS gab und mobile Zugriffe auf Internetinhalte mit wap. begannen. Für soetwas bietet sich doch eher eine virtualisierte Umgebung mit Remote-Web-Interface an, oder?
M.M.n. hätte man sich eher darum kümmern sollen, mit .NET 5 (oder .NET Core 3.X, oder wie sie das Zuegs schon wieder umbenannt haben) wirklich systemübergreifend mit einer einzigen Codebasis und einer einzigen Entwicklungsumgebung auch GUI-Anwendungen entwickeln zu können. Aber sowas scheint mit Microsoft-"Systemmitteln" nahezu unmöglich zu sein. Erst wenn sie mal soweit sind macht es für mich Sinn, bewusst auf Win32-Aufrufe zu verzichten (was derzeit nahezu immer einen Verzicht bei Performance oder Funktionalität bedeutet).
Gemeinsam mit .NET 6 wird auch .NET MAUI kommen, womit es möglich sein wird, eine UI zu programmieren, die Cross Plattform verfügbar ist und somit auf verschiedenen Endgeräten und Betriebssystemen lauffähig sein wird. Hierzu wird .NET MAUI auch in .NET for Android und .NET for iOS (ehemals Xamarin) integriert werden.
"NET MAUI vereinfacht die Auswahlmöglichkeiten für .NET-Entwickler und bietet einen einzigen Stack, der alle modernen Workloads unterstützt: Android, iOS, MacOS und Windows. Die systemeigenen Funktionen der einzelnen Plattformen und UI-Steuerelemente sind in einer einfachen, plattformübergreifenden API für Sie erreichbar. NET MAUI wird in all diesen Versionen - Visual Studio 2019, Visual Studio for Mac und Visual Studio Code - verfügbar sein und sowohl die vorhandenen MVVM- und XAML-Pattern als auch zukünftige Funktionen wie Model-View-Update (MVU) mit C# oder sogar Blazor unterstützen. Wir werden im Laufe dieses Jahres mit dem Versand von .NET MAUI-Previews beginnen und streben die allgemeine Verfügbarkeit von .NET 6 im November 2021 an. "
Link: Introducing .NET Multi-platform App UI | .NET Blog
Mal sehen ob ihnen das unmögliche gelingt die komplette Win32-API zu kapseln. Bisher haben sie das mit .NET ja bekanntlich nicht geschafft, selbst ohne die noch viel stärker kastrierte UWP-APIs.
Wenn man heute diese Anforderung hat und auf Grund der >10 Jahre alten Codebasis das nicht mit akzeptabelem Aufwand gelöst bekommt, dann dürfte die Applikation vermutlich auf MFC oder Windows Forms basieren (um im Microsoft-Universum zu bleiben), inkl. fehlender Trennung von Logik- und Benutzerschnittstelle.
Dass MS es niemals schaffen will und wird, Winodws Forms entsprechend zu erweitern (wäre sowieso nicht zu 100% möglich, die SW-Anpassungen wären aber viel einfacher wie der Umstieg auf WPF), ist ja bekannt.
Warum sollte dann jetzt irgendwer mit einer neuen WinUI3 anfangen, seine alte Applikation umzustellen? Das wird unter Garantie Jahrelang (oder gar Jahrzehntelang) auch wieder nicht vollständig sein, womit sie gerade für solche Projekte nutzlos ist. Dazu kommt die Gefahr, dass MS das Projekt in 3-4 Jahren einfach wieder fallen lässt, wie schon so vieles.
Es gibt bis heute genügend Dinge, die sich mit managed .NET schlicht nicht lösen lassen. Warum sollte Reunion es dann schaffen, das innerhalb absehbarer Zeit stabil, vollständig und langfristig zu ermöglichen?
Mit fällt auch kein Grund ein, warum ich mit Webview2 irgendwelche Web-UIs in eine Applikation integrieren sollte. Entweder, ich nutze Webtechnnologie für das Programm, dann kann (bz.w meist will) ich unabhängig vom Client-OS sein und entwickele gleich eine Weboberfläche mit entsrpechendem Server. Oder ich benötige Funktionalitäten, die seit dem Ende des IE abgeschafft wurden, dann bringt mir Webview2 mit Chromium auch nichts.
Nun ja, ich denke, dass es bei Webview 2 darum geht, die Web-UIs einfacher in Win32-Apps integrieren zu können und trotzdem eine Art "Desktop-Programm" zu haben. IE ist in einer der kommenden Microsoft-Edge-Chromium-Versionen integriert. Es kann ja durchaus auch Nutzer bzw. Firmen geben, die zwar bestimmte Infos aus URLs ziehen müssen, aber eben trotzdem ein lokal installierbares, "altes" Win32-Programm bevorzugen. Schließlich wollen viele Softwareentwickler nicht den Aufwand betreiben und z.B. eine extra UWP-App programmieren. Also lieber die alte Win32-App weiter aufbohren, um Zeit und somit Geld zu sparen. Der Nutzung auf anderen Windows-Geräte-Formfaktoren wie z.B. der Xbox-Konsole, findet so gut wie gar nicht statt und Windows-Smartphones gibt es keine mehr. Es gibt also keinen Grund mehr, eine UWP-App zu entwickeln.
Gleichwohl gibt es durchaus verschiedene Eingabemethoden am PC, die mit einer alten Win32-App nur sehr schwerlich zu nutzen sind. So ist oftmals die Skalierung von UI-Elementen ein Problem, wenn man das Programm mittels Touchscreen bedienen will. In diesem Fall müssen sowohl die UI-Elemente größer - und somit "Finger-freundlich" - gestaltet sein, sowie sollte es eine Unterstützung für "Swipe-Gesten" - also Wischgesten - geben, damit man mit einem Fingerwisch etwas bestätigen oder ablehnen kann. All das geht mit einer alten UI einer Win32-App nicht bzw. bedarf einer teuren Eigenentwicklung der Softwareentwickler. Mit "WinUI 3" hingegen kommen solche Funktionen als Teil der nutzbaren Bibliothek für jeden Softwareentwickler, sodass man hier einen gewissen Standard hat.
Klar, es ist ein ambitioniertes Vorhaben von Microsoft mit "Project Reunion". Aber der Konzern aus Redmond hat nun eingesehen, dass der bisher seit dem Jahr 2015 (Marktstart von Windows 10) propagierte "Zwang", Entwickler zur Neuprogrammierung einer UWP-App zu bringen, absolut nichts gebracht hat. Die Softwareentwickler scheuen den zusätzlichen Aufwand und haben - wie gesagt - argumentiert, dass man ja eine auch auf Windows 10 funktionierende Win32-App (früher "Win32-Programm" genannt) anbiete, die eben auf einer vergleichsweise alten Codebasis steht, aber immer noch lauffähig ist. Der Anreiz für eine komplette Neuprogrammierung hat gefehlt.
-> Folge: Mit "Project Reunion" setzt man eben da an und erlaubt es Entwicklern explizit, ihre alte Codebasis zu behalten, egal, ob diese mit Windows Forms, WPF, C++ geschrieben ist. Es geht darum, diese im Kern jahrealten x86-Programme mit neuen Funktionen anreichern zu können, bei vertretbarem Aufwand, also ohne, dass eine komplette Neuprogrammierung notwendig ist.
-> Microsoft will den Softwareentwicklern mehr Freiheiten geben und steckt bewusst zurück, was etwa die Thematik eigenständige UWP-App angeht. Schließlich kann Microsoft auch auf andere Art und Weise Geld verdienen, in dem man etwa Gebühren von Entwicklern verlangt und diesen dafür Softwarelizenzen von Visual Studio überlässt. Oder falls ein Entwickler eine Win32-App kompatibel mit "Windows Virtual Desktop" macht, dann muss er zwingend Microsoft Azure benutzen, also in die Microsoft-Cloud gehen und hier einen individuellen Rahmenvertrag zur Nutzung der Cloud-Dienste mit Microsoft abschließen und bezahlen.
So muss Microsoft also gar nicht mehr unbedingt irgendwelche Verkaufsprovisionen durch den Verkauf von Apps und Spielen im Microsoft Store einkassieren, wie das noch bei UWP-Apps der Fall ist. Dieses Finanzierungskonzept - in Anlehnung an den Apple Appstore - ist nicht mehr notwendig für Microsoft und Windows 10, weil es sich für das Desktop-Betriebssystem nicht am Markt durchgesetzt hat. Weder die App-Entwickler, noch die Windows-Nutzer haben großartig viel Geld im Microsoft Store gelassen und ihn größtenteils ignoriert oder gar komplett am PC blockiert.
Dass MS es niemals schaffen will und wird, Winodws Forms entsprechend zu erweitern (wäre sowieso nicht zu 100% möglich, die SW-Anpassungen wären aber viel einfacher wie der Umstieg auf WPF), ist ja bekannt.
Warum sollte dann jetzt irgendwer mit einer neuen WinUI3 anfangen, seine alte Applikation umzustellen? Das wird unter Garantie Jahrelang (oder gar Jahrzehntelang) auch wieder nicht vollständig sein, womit sie gerade für solche Projekte nutzlos ist. Dazu kommt die Gefahr, dass MS das Projekt in 3-4 Jahren einfach wieder fallen lässt, wie schon so vieles.
Es gibt bis heute genügend Dinge, die sich mit managed .NET schlicht nicht lösen lassen. Warum sollte Reunion es dann schaffen, das innerhalb absehbarer Zeit stabil, vollständig und langfristig zu ermöglichen?
Mit fällt auch kein Grund ein, warum ich mit Webview2 irgendwelche Web-UIs in eine Applikation integrieren sollte. Entweder, ich nutze Webtechnnologie für das Programm, dann kann (bz.w meist will) ich unabhängig vom Client-OS sein und entwickele gleich eine Weboberfläche mit entsrpechendem Server. Oder ich benötige Funktionalitäten, die seit dem Ende des IE abgeschafft wurden, dann bringt mir Webview2 mit Chromium auch nichts.
M.M.n. hätte man sich eher darum kümmern sollen, mit .NET 5 (oder .NET Core 3.X, oder wie sie das Zuegs schon wieder umbenannt haben) wirklich systemübergreifend mit einer einzigen Codebasis und einer einzigen Entwicklungsumgebung auch GUI-Anwendungen entwickeln zu können. Aber sowas scheint mit Microsoft-"Systemmitteln" nahezu unmöglich zu sein. Erst wenn sie mal soweit sind macht es für mich Sinn, bewusst auf Win32-Aufrufe zu verzichten (was derzeit nahezu immer einen Verzicht bei Performance oder Funktionalität bedeutet).
Man muss nicht alles haben bzw. alles für ein wenig Spass an seiner Privatsphäre opfern. Thats Life
Hier liegt wohl ein Missverständnis vor. Project Reunion ist keine Umgebung für Apps, sondern ist vollständig abwärtskompatibel zu . Net, UWP und C++ und soll keine Umgebung sein. Es spielt bei Project Reunion keine Rolle mehr, in welcher Umgebung die App entwickelt wurde bzw. wird.
Entwickler haben aber bei "Project Reunion" drei neue Möglichkeiten, die Sie nutzen können, aber nicht müssen:
- Win32-App mit WinUI 3 versehen und so etwa eine App mit 15 Jahre alter Codebasis mit einer neuen Benutzeroberfläche versehen, welche etwa eine bessere Skalierung ermöglicht und auch für die Touch-Bedienung geeignet ist, falls der Nutzer ein entsprechendes Display angeschlossen hat.
- Win32-App mit Inhalten aus Webseiten ausstatten. Schließlich ist in Project Reunion auch Webview 2 dabei, so dass Entwickler so auf Basis von der Chromium-Engine nativ Web-Inhalte in die Win32-App integrieren können.
- Win32-App mit Anbindung an die Microsoft Azure Cloud ausrüsten und so diese App mittels "Windows Virtual Desktop" auch auf Geräte mit Android oder iOS streamen.
-> Sämtliche Win32-Apps mit WinUI 3 werden standardmäßig im quelloffenen Containerformat "MSIX" verpackt und können und dürfen auf verschiedenen Distributionsplattformen vertrieben werden.