Also grundsätzlich ist UWP nichts anderes als ein modernes Paradigma Applikationen für Windows zu erzeugen. Für wen ist das interessant? Nicht so für Spotify (und viele andere), weil die ja schon eine Applikation haben oder gar mehrere für verschiedene Plattformen. Wenn Hersteller früher vor 15 Jahren eine Applikation mit Win32 API und C++ geschrieben haben, war deren Not diese Applikation jetzt mit dem damals neuen .Net Forms neu zu entwickeln auch eher überschaubar. Auch wenn es da neue Features gab, und neuere Technologien ist eine Portierung mal grundsätzlich mit Arbeit verbunden, die genau 0 neue Features für User bringt.
Interessant ist es eher dann, wenn ich eine neue Anwendung schreiben möchte. Da kann ich mir überlegen, wen ich aller wo erreichen will und welche Technologie ich dann verwende.
Das hat auch Microsoft inzwischen erkannt und mit dem Ziel, dass der Windows Store zu irgendwas brauchbar ist, die Centennial Bridge entwickelt. Es können bestehende Anwendungen mit vergleichseiwese geringem Aufwand in den Store gestellt werden, ohne das UWP Modell komplett übernehmen zu müssen.
Der Store wiederum ist an ein Deployment-Pattern - dem APPX Container, sowie dem Ausführen von Anwendungen in einer Sandbox gebunden.
Währen APPX nur ein Paketierungsformat darstellt (also im Wesentlichen eine ZIP Datei die alle Daten enthält und damit auch eine "Stinknormale" EXE) ist die Sandbox eine Umgebung, in der eine Applikation mit bestimmten Berechtigungen und Einschränkungen lebt. UWP Apps verwenden hier die Windows Runtime, eine auf COM basierende Technologie. Es wurden hier im Gegensatz zu klassischen Applikationen zusätzliche Modelle eingebaut, die Zugriff aus Ressourcen und das System massiv einschränken. Diese Einschränkungen der Sandbox gelten im Groben (hier fehlt mir etwas Detailwissen) auch für Win32 Anwendungen die mit Centennial installiert werden.
Soviel zum Windows Store und UWP. Bzgl. "Wahl der Technologie" ist Xamarin lediglich eine Möglichkeit zur Wiederverwendung von Code auf mehreren Plattformen. Das hat mit UWP nichts zu tun. Xamarin ist ein (mehr oder weniger) neuer Name für Mono auf mobilen Plattformen (Mono.Droid und Monotouch). Basis ist primär die Verwendung von .Net zur Entwicklung von Android und iOS Anwendungen. Xamarin.Forms abstrahiert das noch eine Stufe mehr und lässt damit Code per Meta-UI-Framework noch besser wiederverwenden, wobei man dazusagen muss, dass man hier meiner Meinung nach zu viele Kompromisse eingehen oder Aufwand reinstecken muss um wirklich gute Apps zu entwickeln. Wie gesagt, das hat nix mit UWP zu tun, da (reines) UWP ja quasi schon .Net ist und daher kein Binding auf .Net mehr erfolgen muss. Xamarin kann insofern UWP nicht ablösen, da UWP ein "Zielsystem" von Xamarin wäre und nicht Ersatz.
Wenn ich also als Entwickler eine neue App schreiben möchte, muss ich mich zunächst fragen, wo meine User sind. Wenn ich sehe, dass diese unter Windows sind, werde ich mich eventuell entschließen für diese Zielgruppe eine Applikation zu schreiben. Wenn meine User auch auf anderen Systemen sind, werde ich möglichst versuchen Code wieder zu verwenden und. z.B. Xamarin einsetzen. Während ich unter iOS und Android immer den Weg über den Store nehme, kan nich unter Windows entscheiden, ob ich den Store wähle oder nicht. Wähle ich nicht den Store kann ich keine UWP Anwendung schreiben und muss z.B. WPF verwenden (wie gesagt, auch das wäre mit Xamarin vereinbar - Technologie ist ja .Net (Framework)) oder irgendetwas anderes. Wenn ich in den Store möchte, kann ich entweder eine "klassische" Anwendung schreiben und mich der Sandbox unterwerfen oder eine UWP Applikation, deren API bereits auf die Sandbox ausgelegt ist.
Ist UWP ein totes Pferd? Weil nicht jede Applikation mit einem Hurra neu geschrieben wird wenn es sie schon gibt? Nein, finde ich definitiv nicht. Spotify wäre wahnsinnig gewesen, hätten sie anderes agiert! UWP ist eine (mögliche) Zukunft ausschließlich für neue Windows Anwendungen. UWP ist für ein Leben in der Sandbox entwickelt worden und bietet zusätzlich Entwicklerfeatures wie z.B. die Eingabemethoden, das moderne Adaptive-UI-Framework, Composition, Built-In ARM Unterstützung, Performance ... die über die offensichtlichen User-Features (Live-Tile) hinausgehen. Es kommt natürlich auf die Applikation an, aber wenn ich eine neue Applikation schreiben würde und diese halbwegs gut aussehen soll, gäbe es für mich nicht viele Gründe diese als "klassische" Applikation zu schreiben und dann über Centennial in den Store zu stellen. Als User sollte man sich da eigentlich keine Gedanken machen müssen - genauso wenig wie wenn eine Applikation in Java, .Net oder MFC geschrieben ist. Der Centennial Weg ist ein sehr pragmatischer, finde ich. Man möchte über den Store und die Sandbox auf längere Sicht das Applikationsmodell und Sicherheitsmodell von Windows verbessern - Centennial lässt Anwendungen da ohne groben Aufwände mitmachen.
Bzgl. Sicherheit der Sandbox ist es natürlich niemals gewollt, dass hier eine Anwendung "ausbricht". Dass es vorkommen kann ist eine Gegebenheit, da Software nicht zu 100% sicher ist, zumindest sollte man nicht davon ausgehen
Über den Store existiert allerdings zumindest eine Kontrollinstanz die mutwillige Angriffe einschränken kann/könnte.
