Als WhatsApp die allgemein verhasste Entscheidung traf, seine native Windows-App auf einen Web-Wrapper umzustellen, richtete sich die meiste Kritik an Meta. Und das zu Recht. Es fühlte sich faul an, es war eindeutig ein RAM-fressendes Downgrade und es entfernte das kleine „native“ Erlebnis, das die App unter Windows hatte.
Doch die Realität sieht etwas unbequemer aus.
Selbst Meta hatte keinen großen Anreiz, bei einer nativen Windows-App zu bleiben. Das Unternehmen hat es kaum aktualisiert, keine Funktionsparität eingeführt und stattdessen standardmäßig auf die Webversion umgestellt. Der Hauptgrund liegt wahrscheinlich darin, dass Web-Apps kostengünstiger in der Erstellung und Wartung sind. Das eigentliche Problem besteht jedoch darin, dass Microsoft den Entwicklern kein UI-Framework zur Verfügung gestellt hat, an das sie sich langfristig halten können. Web-Apps haben dieses Problem nicht.
Wir haben kürzlich von einem langjährigen Windows Insight-Leser, Alexander Ovchinnikov, gehört, der zufällig auch Entwickler ist. Seine Argumente spiegeln wider, was viele Entwickler bereits denken.
Im Gegensatz zu macOS, das immer native Apps erhält, obwohl es eine viel kleinere Benutzerbasis hat, geht es bei der Einstellung der Entwickler, Web-Apps nur für Windows zu veröffentlichen, nicht um Bequemlichkeit. Es geht um Vertrauen, oder besser gesagt, um den Mangel daran.
Im Laufe der Jahre hat Microsoft mehrere „zukünftige“ Frameworks eingeführt, um sich später von ihnen zu entfernen. Von WPF und Silverlight über UWP bis hin zu WinUI 3 hat das Unternehmen dieses Muster nicht geändert. Wie Alexander es ausdrückt, gehen viele Entwickler mittlerweile davon aus, dass alles, was Microsoft heute vorantreibt, möglicherweise nicht lange genug hält, um eine Weiterentwicklung zu rechtfertigen.
Microsoft hatte seit Jahrzehnten keine klare GUI-Strategie mehr und Windows bietet jetzt zu viele Frameworks ohne eine definitive Antwort darauf, was Entwickler tatsächlich verwenden sollten.
Dieses Wissen verändert meine Einstellung zu Web-Apps für Windows. Sie sind eine Ausweichoption, wenn die Plattform selbst unsicher ist. Allerdings könnte die jüngste Liebe von Microsoft, 100 % native Apps für Windows zu entwickeln, die Dinge ändern.
Windows hat sich von einem klaren Entwicklungspfad zu zu vielen verwirrenden Entscheidungen entwickelt
Es gab eine Zeit, in der die Erstellung einer Windows-App keine mentale Debatte erforderte. Die frühe Windows-Entwicklung drehte sich um einen einzigen, gut verstandenen Ansatz. Win32 war die Antwort. Eine API, ein mentales Modell und eine klare Möglichkeit, Dinge zu erledigen.
Charles Petzolds „Programming Windows“, das allgemein als die „Bibel“ der Windows-Entwicklung galt, machte es zugänglich, und Entwickler konnten ihre Zeit investieren, da sie wussten, dass die Plattform ihnen nicht ins Wanken geraten würde. Diese Stabilität schuf Vertrauen, und Vertrauen ließ das Ökosystem wachsen.
Anstatt Win32 jedoch zu etwas Modernerem weiterzuentwickeln, führte Microsoft immer wieder neue Ebenen und Alternativen ein. Zuerst kam MFC als C++-Wrapper. Dann WinForms für.NET-Entwickler. Es folgte WPF mit XAML und hardwarebeschleunigtem Rendering. Silverlight wurde als plattformübergreifende Wette angezeigt. Dann kamen WinRT und UWP während der Windows 8- und Windows 10-Ära. Und jetzt haben wir neben MAUI auch WinUI 3 mit dem Windows App SDK für die plattformübergreifende Entwicklung.
Jedes davon wurde mit einer starken Aussage über die Zukunft der Windows-Entwicklung angekündigt. Jeder forderte die Entwickler auf, Zeit zu investieren, neue Muster zu lernen und darauf aufzubauen.
Das Problem war nicht, dass diese Technologien schlecht waren. Viele von ihnen waren ihrer Zeit wirklich voraus. Das Problem bestand darin, dass die „Zukunft“ immer wieder ersetzt wurde, bevor sie sich vollständig niederschlagen konnte. Anstelle einer einzigen sich weiterentwickelnden Plattform blieben die Entwickler auf der Suche nach beweglichen Zielen.
Jeffrey Snover weist in seinem ausführlichen Blog darauf hin, dass Windows keine klare Antwort auf eine einfache Frage mehr hat: Wie sollte man eine Windows-App erstellen?
WPF sollte die Zukunft sein, bis Silverlight auf den Markt kam, was vielversprechend aussah, bis Microsoft auf HTML5 umstieg. UWP wurde als einheitliche Plattform für alles propagiert, konnte sich jedoch nie vollständig durchsetzen, nicht einmal intern. WinUI 3 wird mittlerweile als die moderne Lösung positioniert, aber seine Roadmap hat nicht das gleiche Maß an Vertrauen geweckt, das Entwickler in früheren Zeiten hatten.
Wenn Microsoft ein neues Framework mit einer klaren Richtung einführt, werden die Entwickler damit beginnen, es zu übernehmen. Dann würde sich die Strategie ändern und die Aufmerksamkeit würde sich woanders verlagern. Das bisherige Rahmenwerk würde nicht immer offiziell abgeschafft, aber es würde langsam an Relevanz verlieren. Dieser Zyklus wiederholte sich so oft, dass die Entwickler aufhörten, sich vollständig zu verpflichten.
Wie Alexander uns sagte, herrscht heute die Meinung: Wenn Microsoft nicht bei früheren Frameworks bleiben konnte, warum sollte man dann davon ausgehen, dass das aktuelle anders sein wird?
So sieht es heute aus. Fragen Sie einen Entwickler, was er für eine Windows-App verwenden soll, und die Antwort hängt davon ab, wen Sie fragen. Einige werden weiterhin Win32 empfehlen. Andere bevorzugen WPF, weil es stabil ist. WinUI 3 gilt als modern, ist aber noch nicht allgemein vertrauenswürdig. MAUI existiert für die plattformübergreifende Nutzung. Dann gibt es noch die Web-Route mit Electron oder PWAs. Darüber hinaus gewinnen Frameworks von Drittanbietern wie Avalonia und Qt an Bedeutung.
Dies ist nicht die Art von Auswahl, nach der die Entwickler gefragt haben. Es ist völlige Unsicherheit.
Warum Entwickler Web-Apps anstelle von nativen Apps wählen
Einige der beliebtesten Windows-Apps sind nicht wirklich nativ. WhatsApp, Spotify, Discord, Slack, Notion, Zoom und sogar Teile des Microsoft-eigenen Ökosystems … Microsoft Teams (vor seiner Neufassung), Clipchamp und mehrere Erstanbieter-Erlebnisse nutzen WebView2.
Natürlich ist es so einfach geworden, eine Web-App einmal zu erstellen und überallhin zu versenden. Es kann unter Windows, macOS, Linux und sogar in einem Browser ausgeführt werden, ohne dass separate Codebasen verwaltet werden müssen. Frameworks wie Electron, Chromium-basiertes WebView und Progressive Web Apps haben die Verteilung einfacher, Updates schneller und die Entwicklungskosten gesenkt. Den Unternehmen fällt es schwer, das zu ignorieren.
Microsofts Umstellung auf WebView2 bettet die Edge-Engine (Chromium) in Apps ein. Dies sorgt für eine gute Konsistenz, bedeutet aber auch, dass es sich bei vielen „Desktop“-Apps nur um Webseiten handelt, die in einem Container ausgeführt werden.
Und der offensichtliche Nachteil ist, dass diese Apps mehr RAM verbrauchen, weniger reaktionsschnell sind und sich nicht so tief in das Betriebssystem integrieren. Das gleichzeitige Ausführen mehrerer Electron-Apps kann leicht Systemressourcen beanspruchen, was native Apps traditionell viel besser bewältigen.
Unter macOS und iOS priorisieren Entwickler immer noch native Apps. Sogar Unternehmen, die anderswo über Webtechnologien verfügen, erstellen native Versionen für Apple-Geräte. Das liegt daran, dass Apple einen viel klareren Entwicklungspfad verfolgt hat. Frameworks wie Cocoa, AppKit und jetzt SwiftUI wurden konsequent unterstützt und weiterentwickelt. Entwickler wissen, was sie verwenden müssen, und was noch wichtiger ist, sie wissen, dass es auch Jahre später noch relevant sein wird.
Windows bietet nicht die gleiche Klarheit und die Entwickler reagieren entsprechend.
Anstatt also auf ein Framework zu setzen, das möglicherweise erneut die Richtung ändert, entscheiden sich viele für das Internet. Es ist nicht perfekt und in vielen Fällen sogar objektiv schlechter für die Desktop-Leistung. Aber es beseitigt das größere Risiko, von der nächsten Entscheidung von Microsoft abhängig zu sein.
Microsoft versucht, das Problem zu beheben, aber es könnte zu spät sein
Es gibt Anzeichen dafür, dass Microsoft sich des Problems bewusst ist. Jüngste Bemühungen deuten darauf hin, die Leistung zu verbessern, die Abhängigkeit von webbasierten Komponenten zu verringern und mehr native Erlebnisse für Windows zu schaffen. Rudy Huyns X-Beitrag, in dem er Windows-Entwickler dazu auffordert, 100 % native Apps zu entwickeln, wurde positiv aufgenommen.
Aber die Reparatur der Apps selbst ist nur ein Teil der Gleichung.
Auch wenn Microsoft in Zukunft bessere native Apps liefern wird, werden die Entwickler noch zögern. Das Zögern ist nicht darauf zurückzuführen, was WinUI 3 heute kann oder nicht kann. Es kommt von dem, was mit allem passiert ist, was davor war. Jahrelange Prioritätenverschiebungen haben Entwickler vorsichtig gemacht, und diese Art von Zögern verschwindet nicht über Nacht.
Wenn Microsoft das ändern möchte, sollte es sich vollständig auf ein Framework festlegen und es den Entwicklern gut kommunizieren. Das bedeutet auch, lange genug an einem Rahmen festzuhalten, damit er reift, seine Richtung klar vorgibt und ihn unterstützt. Entwickler benötigen eine Roadmap, der sie vertrauen können, sowie klare Migrationspfade, wenn Änderungen vorgenommen werden.
Das eigentliche Problem ist nicht die Technologie, sondern die Konsistenz
An Fähigkeiten mangelt es Microsoft nicht. Das Unternehmen verfügt über einige der besten Ingenieurtalente der Branche und verfügt über eine lange Geschichte in der Entwicklung leistungsstarker Entwicklungstools. Viele der eingeführten Frameworks waren aus technischer Sicht wirklich stark.
Was fehlte, war und ist Konstanz.
In der Analyse von Rebecca Sutter wurde erwähnt, dass das Problem kein technisches Versagen ist, sondern ein Muster interner Entscheidungen, die immer wieder die Richtung ändern.
Diese haben immer wieder zu Unsicherheit für Entwickler geführt. Von außen betrachtet spielt es keine Rolle, warum diese Änderungen stattgefunden haben. Was zählt, ist das Ergebnis. Den Entwicklern blieben mehrere Wege übrig, von denen keiner das Gefühl hatte, dass er von Dauer sein würde.
Deshalb sieht die Situation heute so aus. Das Problem ist nicht, dass Windows zu wenige Optionen hat. Es ist so, dass sich keine davon endgültig anfühlt. Entwickler fordern nicht mehr Frameworks. Sie verlangen jemanden, dem sie vertrauen können.
Web-Apps sind ein Symptom, nicht das Problem
Web-Apps erobern Windows nicht, weil sie besser für Desktop-Computing geeignet sind. In vielen Fällen ist dies nicht der Fall. Sie übernehmen die Rolle, weil sie Entwicklern Zuverlässigkeit bieten, die nicht mehr in die Windows-Plattform investieren möchten.
Den Entwicklern kann nicht vorgeworfen werden, dass sie eine kalkulierte Entscheidung treffen, die auf Erfahrungen aus der Vergangenheit basiert.
Wenn Microsoft die Qualität von Apps unter Windows verbessern möchte, besteht die Lösung nicht nur darin, Windows 11 zu reparieren und native Erstanbieter-Apps zu erstellen, sondern auch darin, das Vertrauen der Entwickler wiederherzustellen und zu beweisen, dass die Plattform (WinUI3, wie ich hoffe) dieses Mal konsistent bleibt.
Zuhause
Teilen
Newsletter
WL-Newsletter
WL-Newsletter!
Bleiben Sie mit den neuesten Windows-, IT- und KI-Updates auf dem Laufenden. Mehr als 50.000 Abonnenten vertrauen darauf.
Name
Kostenlos beitreten
*️⃣ Quelllink:
weist darauf hin , dass die meisten beliebten Windows-Apps nicht wirklich nativ sind und mehr native Erfahrungen unter Windows schaffen. Windows-Entwickler müssen 100 % native Apps erstellen, Analyse von Rebecca Sutter , Home , Newsletter ,