All about (Windows) apps – Ordnung im Chaos

App-Gap, Microsoft muss mehr tun, Astoria, die Bridge – etliche Begriffe gehen hier ein wenig durcheinander, werden manchmal sogar verwechselt. Hier nun eine kleine Übersicht, um etwas Ordnung in das Chaos zu bringen.

Begriffserklärungen

Ohja, die müssen sein. App ist die Abkürzung von „application“, was einfach Anwendung, Programm bedeutet. Im Englischen wird hier durch das Hinzufügen von „desktop“ noch unterschieden, im Deutschen haben sich eher unterschiedliche Begriffe eingebürgert:

desktop app = Programm, „*.exe“, Win32-Programm. Anwendung, die nur auf dem PC oder Tablet-Computer (mit Windows 10 Home/Pro/Enterprise) lauffähig ist. Nicht in einer Sandbox lauffähig. (Entsprechende native Varianten gibt es auch für Linux und MacOS.)

app = App. Anwendung, die nur über einen App-Store herunterladbar und installierbar ist (Sideloading im Entwicklermodus einmal ausgenommen). (Nur) in einer Sandbox lauffähig.

Im weiteren Sinne werden auch Webseiten als Anwendungen bezeichnet, weil sie auf Benutzereingaben (und wenn es nur das Anklicken eines Menüs ist) in einer bestimmten Art und Weise reagieren. Benutzerkonten, Suchen über den Inhalt, aufbereitete Darstellung der Suchergebnisse, usw. sind alles Teile einer solchen Internet-Anwendung. Diese laufen immer in einem Browser (z.B. Amazon, Youtube, Wikipedia), auch wenn dieser nicht mehr sichtbar ist (z.B. Google Earth).

Der Unterschied zwischen App und Programm

Ein Programm hat das gesamte Betriebssystem und die gesamte Hardware zur Verfügung: Es kann auf alle Festplatten zugreifen, auf das Netzwerk, das Internet, auf sämtliche Schnittstellen (Maus, Tastatur, Drucker, PS2-Ports, Video-Ports etc.). Es kann sogar Hardware-Interrupts abfangen und umleiten (wichtig für sehr hardwarenahe Programmierung und auch Trojaner bzw. Viren). Außerdem kann diese Anwendung sämtliche verfügbaren Programmbibliotheken (*.dll) und Schnittstellen (API, ABI) verwenden. Sie hat außerdem (theoretisch) Zugriff auf die komplette Registrierungsdatenbank (Registry) und die Windows-Programmdateien. (Mit Windows 7 wurden hier Hindernisse eingebaut. So muss z.B. nun immer mit Admin-Rechten eines PCs bestätigt werden, wenn ein Programm irgendwelche Änderungen am Betriebssystem, z.B. Registry oder Dlls, vornehmen möchte.)

Im Gegensatz dazu kann eine App nur sehr wenig: Sie hat nur begrenzten Zugriff auf die Ressourcen, kann auf andere Dateien schreibend nicht direkt zugreifen, lesend auch nur auf bestimmte Verzeichnisse, kann nur ihre eigene Registry bearbeiten. Auf die Hardware hat sie nur begrenzt und nur indirekt Zugriffsmöglichkeiten, sie muss sich an die Schnittstellen halten. Im Hintergrund kann sie nur ihren eigenen Code ausführen und hat keinerlei Zugriff mehr auf die Hardware-Schnittstellen. Sie kann nur das verwenden, was ihr das Betriebssystem in ihrer eigenen Sandbox zur Verfügung stellt.

Beispiel: Programm A (hardwarenah), eine Banksoftware, ruft Umsätze ab und gibt z.B. Zahlungsaufträge ein. Dazu muss ein Passwort eingegeben werden, bzw. die Tastatur oder andere Eingabemedien (Chipkartenleser) werden – eventuell sogar direkt über Interrupts – angesprochen und Benutzereingaben ausgelesen. Programm B (ebenfalls hardwarenah) liest diese Eingaben mit (ebenfalls über Interrupts) und führt eigene Überweisungen aus. Das ist das prinzipielle Vorgehen z.B. eines Trojaners.

Der Sandkasten

Im Falle von Apps sieht das anders aus: App A läuft in einer eigenen Sandbox. Die Sandbox hat keinen direkten Zugriff auf die Tastatur. Die App A bittet daraufhin das Betriebssystem, ihr die Daten aus der Tastatur zu geben. Das Betriebssystem blockt daraufhin alle anderen Apps, auch App B, von der Tastatur ab, sodass nur App A die Eingaben zu Gesicht bekommt. App B, der Trojaner, hat so keine Chance mehr, die Daten unberechtigterweise abzugreifen.

Android und Apple benutzen auch ein Sandbox-System, das aber im Gegensatz zu dem von Windows bei Android schon mehrfach und bei Apple auch schon geknackt wurde.

Der angebliche Hack der Windows-Sandbox unter „Windows 10 S“ ist allerdings per Definition eigentlich keiner, weil die App selbst keine Möglichkeit hatte, auf das Betriebssystem direkt zuzugreifen. Dies wurde über den Umweg über ein Makro, welches dann die Win32-API nutzte, welche natürlich Hardwarezugriff haben darf (!), bewerkstelligt. Im Gegensatz dazu wurde aus Apple und Android direkt in das Betriebssystem hinein eingebrochen, was unter Windows wie gesagt bislang noch keinem gelungen ist.

Sandbox und Berechtigungen

Wenn eine App für den Store verpackt wird, muss die App angeben, welche Berechtigungen sie zum Betrieb benötigt. Das wird von Microsoft gerade beim ersten Mal händisch (!) überprüft und kann daher auch mal ein paar Tage (oder Wochen) dauern, bis die App endlich im Store auftaucht. Benötigt sie z.B. Berechtigungen, die offensichtlich überflüssig sind, oder die sie nicht als benötigt angegeben hat, wird sie im Store nicht freigeschaltet, der Entwickler bekommt Rückmeldung. Damit erreicht Microsoft eine recht gute Qualitätssicherung. Oder anders ausgedrückt: Microsoft verhindert damit 95.000 „Taschenlampen“-Apps, die nur die Kontakte auslesen wollen oder gar im Hintergrund als E-Mail-Bots funktionieren.

Viren und Trojaner

Wenn man diese Grundlagen kennt, dann ist es nicht verwunderlich, dass man heute auf einem Android-Smartphone genauso wie auf dem PC eine Antiviren-Software benutzen sollte.

Selbst bei Apple ist dies anzuraten (https://www.netzsieger.de/ratgeber/apples-strategie-gegen-iphone-virus). Eine Infektion mit einem Virus sollte zwar wegen der Sandbox relativ harmlos sein, weil der Virus nur seine eigene Sandbox infizieren kann, allerdings hat es in der Vergangenheit schon mehrere Trojaner auf Android und iPhone gegeben, die aus dem Internet Schadcode nachluden und die ein normales Android/iPhone (ohne Jailbreak/rooting) verseuchen konnten. Dass Android/iPhones mit Jailbreak/rooting natürlich komplett ungeschützt sind, sollte klar sein.

Sideloading und Jailbreak

Unter Windows ist, wie gesagt, ein Ausbruch aus der Sandbox noch nicht gelungen. Selbst wenn man sich per Sideloading eine App installiert, hat diese App immer noch keinen Zugriff auf das System. Bei Apple muss per Jailbreak das System „aufgebrochen“ werden, um Apps von anderen Quellen als dem Apple Store installieren zu können – die damit außerdem kompletten Zugriff auf das System bekommen. Eine recht gefährliche Sache also.

Bei Windows kann dagegen eingestellt werden, dass man auch Apps aus anderen Quellen installieren können will (Sideloading, Entwicklermodus). Wenn man dann aus einer fremden Quelle Apps installiert, sind die natürlich nicht von Microsoft überprüft worden. Das bedeutet, dass sie sich nicht nur die Rechte nehmen, die sie angeben, sondern vielleicht auch weitere oder alle möglichen Rechte. Damit wären z.B. auch Datenverluste (Kontakte) möglich. Auch ein E-Mail-Bot wäre so möglich.

Aber diese Apps hätten trotzdem keine Möglichkeit (auch nicht durch das Nachladen von weiterem Code wie bei Apple), direkt auf bzw. in das System oder die Programmdaten von anderen Apps zuzugreifen. Sie könnten also das Betriebssystem selbst oder andere Apps trotzdem nicht „knacken“ oder kompromittieren. Denn es gibt bei Windows keine „Superrechte“, wie es sie z.B. unter Apple gibt.

Welche Apps kommen in den Store?

Prinzipiell können alle Anwendungen, egal mit welcher Programmiersprache sie geschrieben wurden (vorausgesetzt, Visual Studio versteht sie), in eine App „verpackt“ und in den Store geladen werden. Zum Programmieren einer Anwendung wird eine „Entwicklungsumgebung“ (z.B. Visual Studio) benötigt. Das ist ein Programm, das nicht nur bei der Programmierung, sondern auch bei der Erstellung des Installationspakets bzw. der App hilft. Ähnlich, wie man Word benutzt, um ein Buch zu schreiben, das nachher als PDF oder Paperback gelesen wird.

Diese Entwicklungsumgebung stellt alle Programmbibliotheken und API-Beschreibungen zur Verfügung, die auf der Zielplattform (in unserem Fall immer Windows 10) benutzt werden können. Werden andere Programmbibliotheken benötigt, so müssen diese entweder mitgeliefert werden (klassische Win32-Programmierung) oder in den Programmcode integriert werden.

Programmiersprachen und Entwicklungsumgebungen, Frameworks

Unter Framework wird eine Kombination aus Programmbibliotheken, Tools oder auch Entwicklungsumgebungen und weiteren Programmdateien verstanden, die es einem Entwickler erlauben, auf einfache Art und Weise auf diesem „Gerüst“ basierende Anwendungen zu schreiben. Der Programmierer muss sich also die Einzelteile nicht erst mühsam zusammensuchen, sondern bekommt sie sozusagen hübsch aufbereitet mit vielen Standard-Einstellungen und Arbeitserleichterungen versehen en bloc geliefert. Dieses „Gerüst“ ist dann auf den Ziel-PCs schon vorinstalliert und kann von der fertigen Anwendung als Laufzeitumgebung genutzt werden.

Silverlight – Ein Framework, das Windows Runtime benutzt, für Windows Mobile. Wurde mit Windows 7 eingeführt, unter Windows 8 wurde es eher unbedeutend. Solche Apps können oft am Windows-8-Design erkannt werden. Seit Windows 10 ist es abgekündigt („deprecated“). Es wird empfohlen, Apps von Silverlight nach UWP zu portieren.

C++, C# („cee sharp“), Visual C – Das sind die Programmiersprachen, die sich bei den meisten Entwicklern durchgesetzt haben, da sie die beste, einfachste objektorientierte und relativ plattform-unabhängige Programmierung ermöglichen.

Comal, Cobol, Pascal, Basic, Visual Basic, Visual Basic for Applications, Assembler, C, etc. – Programmdinosaurier, die praktisch nicht mehr zur Programmerstellung genutzt werden. Assembler stellt da eine Sonderform dar, da praktische alle Programme nach Fertigstellung in Maschinencode = Assembler konvertiert, „assembliert“, „kompiliert“ werden, und damit erst direkt ohne Entwicklungsumgebung lauffähig sind. Auf manchen Plattformen (z.B. Windows 10) wird jedoch nicht mehr Assembler genutzt, sondern eine weiterentwickelte Zwischenform, z.B. .NET-Code („dot-net-code“).
Manche Programmiersprachen setzen das Vorhandensein einer entsprechenden Mutter-Anwendung voraus. So z.B. Visual Basic for Applications (VBA), das ohne z.B. Word, Excel oder Access recht sinnfrei ist, denn das VBA-Programm muss aus der Mutter-Anwendung heraus gestartet werden (auch wenn sie nicht sichtbar ist). Im Prinzip ist VBA eine aufgebohrte Makrosprache oder auch Scriptsprache; die damit geschriebenen Programme benötigen einen Interpreter.

Java – Interpreter für „universelle“ Anwendungen für Windows, Unix, Android, iOS, MacOS

JavaScript – Scriptsprache für Anwendungen im Browser

Objective-C, Swift – Sprachen für Apple (iOS, MacOS)

HTML, XML, CSS – Sprachen für Webseiten. Sie führen selbst keinen Code aus, sondern regeln die Darstellung bzw. Anzeige eines Textes. Was ist ein Absatz, wie hat er auszusehen, usw.

Mit Windows 10 hat Microsoft quer über alle Betriebssystem-Varianten von Windows ein neues Framework – die Universal Windows Platform (UWP) – geschaffen, die es auf einfachste Art und Weise ermöglicht, Apps zu programmieren, die auf allen Windows-Geräten laufen.

„Mit der universellen Windows-Plattform und unserem zentralen Windows-Kern können Sie die gleiche App auf jedem Windows 10-Gerät ausführen, von Smartphones bis zu Desktop-PCs. Erstellen Sie diese universellen Windows-Apps mit Visual Studio 2015 und den universellen Windows-App-Entwicklungstools.“

Damit ist der „normale“ Weg also ganz grob der folgende:

• Sich für ein Framework und eine Sprache entscheiden,
• passende Entwicklungsumgebung installieren,
• Anwendung schreiben,
• Anwendung kompilieren,
• Anwendung mit Testprogramm testen,
• Anwendung als App verpacken,
• Anwendung auf Testgerät(en) installieren und testen,
• Fine-Tuning (mit evtl. erneutem Testzyklus),
• sich beim Store als Entwickler registrieren/anmelden,
• App in den Store laden.

Fertig. Auf das Fine-Tuning kommen wir weiter unten nochmal zurück.

Manchmal wurden aber bereits Programme für ein anderes Betriebssystem/Framework geschrieben, z.B. für Android, iOS, MacOS, Linux, Silverlight. Genau hier setzen die verschiedenen Projekte bzw. „Brücken“ an – Microsoft versucht(e) damit, Apps von anderen Plattformen in den Store zu ziehen bzw. Richtung UWP zu pushen. Mit teilweise mäßigem Erfolg.

Brücken bauen

Microsoft war mit seinem Windows Store leider etwas spät dran, Apple und Google waren da schon viel weiter, und der App-Gap avancierte damit zum absoluten Schreckensszenario für jeden App-User unter Windows (gleich ob Smartphone oder PC). Inzwischen hat sich die Lage hier etwas entspannt, es kommen immer mehr Apps in den Store. Besonders im Business-Bereich ist heute der Windows-Store sehr gut ausgestattet.

Im Consumer-Bereich dagegen hinkt der Store noch gewaltig hinterher und es ist auch fraglich, ob sich das jemals wirklich ändern wird. Da 95% der Smartphone-Benutzer Apple oder Android nutzen, ist die Marktabdeckung hier aus Sicht der Firmen ausreichend. Ich möchte hier mal wieder an die 80-20-Regel, das Pareto-Prinzip erinnern.

Pareto-Prinzip in: Windows Updates – Wie getestet wird, warum Daten gesendet werden

Es gibt zwar noch Nutzer, die keine Apple- oder Android- oder überhaupt Smartphones nutzen, also z.B. nur ein Windows-Tablet oder nur einen PC gebrauchen, allerdings ist hier der Bedarf z.B. für eine Hue-Fernsteuerung vergleichsweise dürftig – die Firmen konzentrieren sich eben logischerweise auf die am leichtesten und am schnellsten zu erreichenden und am ehesten interessierten (!!!) Benutzergruppen. Sie wollen eben Geld verdienen und Inklusion auch der Randgruppen kostet mehr Geld, als es bringt.

Nachdem aber die Tablets, die mit Windows 10 laufen, in der letzten Zeit enorm an Umsätzen zugelegt haben, wird das Interesse größer, für diese Tablets Apps anzubieten. Windows 10 S und auch dieses neue „kategoriedefinierende Gerät“ (Surface Mobile?) verstärken diese Entwicklung (hoffentlich) noch ein wenig. Gerade im Business-Bereich, wo verriegelte und verrammelte Windows-10-PCs (entsprechen dann etwa der Funktionsfähigkeit von Windows 10 S, eventuell auch mit Win32-Programmen) üblich sind, wächst naturgemäß das Interesse an Apps, die durch das Sandbox-System auch viel sicherer und weniger störanfällig als normale Win32-Programme sind.

Siehe dazu: https://docs.microsoft.com/de-de/windows/uwp/porting/

Über sieben Brücken musst Du gehen…

Projekt Astoria – Android Bridge

Astoria sollte Android-Apps in den Windows Store bringen, was prinzipiell auch recht gut funktioniert hat. Leider hat man sich damit auch einiges an Ballast und Problemen aufgehalst:

1. Sehr viele Android-Apps sind nach der Portierung insgesamt gesehen „buggy“ programmiert, sie stürzen oft ab, oder funktionieren nicht so, wie eigentlich gewünscht.
2. Viele Android-Apps haben überflüssige oder gar gefährliche Berechtigungen (siehe oben unter „Apps und Berechtigungen“), was enorm viel händische Arbeit von Microsoft kostet, um diese zu überprüfen und außerdem die Wartezeit für gute Apps, bis diese im Store erscheinen, nur unnötig verlängert.
3. Da sie grundsätzlich bereits für ARM kompiliert sind, laufen sie auf einer Intel-Plattform ohne Emulator nicht. Diese Apps würden dann zwar auf Windows 10 Mobile (oder Windows 10 ARM) laufen, aber nicht ohne einen ARM-Emulator auf Windows 10 Home/Pro/Enterprise. Das ist wohl mit ein Hauptgrund gewesen!
4. Ihre Performance ist hinterher durch den Emulator oft sehr schlecht.

Das waren damit vier gute Gründe, die zu einer Einstellung des Projekts führten.

Projekt Islandwood – iOS Bridge

Islandwood hat das Ziel, iOS-Apps in den Store zu portieren. Im Gegensatz zu Android sind iOS-Apps von Zuhause aus meist besser und Windows-ähnlicher programmiert (objektorientierte, strukturierte Programmierung) und durch eine bessere Kontrolle bzw. eine der Windows-Sandbox ähnlichere Umgebung auch weniger als Virus oder Trojaner geeignet.

Außerdem basieren die meisten iOS-Apps auf Objective-C, was das „Übersetzen“ in .Net wesentlich erleichtert. Trotzdem ist hier auch mit einer schlechteren Performance als auf einem iPhone zu rechnen.

Siehe dazu https://developer.microsoft.com/en-us/windows/bridges/ios

Project Westminster – WebApp Bridge

https://youtu.be/g1az7mFXVMg

Hostet WebApps sind, wie oben bereits erwähnt, komplexe Webseiten, aus denen sich mit Westminister recht einfach eine UWP-App, ein WebWrapper bauen lässt. Mehr dazu weiter unten.

Siehe dazu https://blogs.windows.com/buildingapps/2015/07/06/project-westminster-in-a-nutshell/

ManifoldJS – PWA Bridge

Progressive Web Apps sind ebenfalls komplexe Webseiten, die sich wie eine App anfühlen, aber im Hintergrund immer noch einen Browser benötigen, auch wenn er nicht mehr sichtbar ist. Google Earth ist ein solches Beispiel. Progressive Web Apps sind unter Edge nicht lauffähig, der Support soll mit dem Fall Creators Update kommen.

Siehe dazu ManifoldJS und https://docs.microsoft.com/de-de/windows/uwp/porting/hwa-chrome-conversion

Silverlight-Brücke mit Mobilize.Net

Silverlight bzw. Windows Runtime wurde durch die Universelle Windows-Plattform abgelöst (siehe oben). Mobilize.Net ist ein Tool, das die Portierung nach UWP erheblich vereinfacht.

Siehe dazu https://docs.microsoft.com/de-de/windows/uwp/porting/wpsl-to-uwp-root

Project Centennial – Desktop Bridge

Mit der Einführung der Universal Windows Platform (UWP) möchte man auch die vielen nativen Windows-Programme in den neuen Windows Store ziehen. Diese Desktop Bridge erlaubt es, bereits vorhandenen Code (Win32 und .net) in den Store zu bringen.

Siehe dazu https://developer.microsoft.com/en-us/windows/bridges.

Eine genauere, differenziertere Gegenüberstellung zwischen Android, iOS und UWP bietet die folgende Seite: https://docs.microsoft.com/de-de/windows/uwp/porting/android-ios-uwp-map.

Wer mitgezählt hat, wird festgestellt haben, dass es nur sechs Brücken waren. Aber was braucht der Mensch? Sechs (Brücken) und ein Bier…

Plattformübergreifende Entwicklung – Xamarin

Wer sich schon einmal bei einem Anbieter darüber beschwert hat, dass es keine App für Windows gibt und sich mit ihm etwas unterhalten hat, der bekommt in aller Regel etwa folgende Aussagen zu hören:

• „Unsere Zielgruppe sind Apple-(Android-)User.“
• „Die Entwicklung ist sehr teuer.“
• „Es ist als nächstes eine App für Android (iOS) geplant.“
• „Es werden viel zu wenige Windows-Smartphones benutzt, als dass sich die Entwicklungskosten für eine dritte App rechtfertigen ließen.“
• „Microsoft hat die Entwicklung von Windows Mobile aufgegeben.“

Diese Argumentation geht meist von einer grundlegenden Fehl-Annahme aus: „Für jede Plattform brauche ich eine eigene Entwicklergruppe bzw. eine eigene App. Es werden also zwei- bzw. dreimal die gleichen Kosten fällig.“ Darüber hinaus werden Windows-UWP-Apps mit Windows Mobile gleichgesetzt. Und weil die Nutzerzahlen von Windows Mobile am Boden sind, wird davon ausgegangen, dass Microsoft Windows Mobile aufgegeben habe (trotz anders lautender Verlautbarungen, trotz Updates, trotz angekündigtem Windows 10 ARM, trotz Adromeda, etc. pp.).

Größere Firmen, die idealer Weise auch schon für das eigene Haus programmiert haben, sind sich immer häufiger dieser Kosten bewusst. Wenn sie eigene Entwickler im Haus haben, oder bereits Apps für iOS/Android entwickelt haben, wird sich daher an der Entscheidung, für welche Plattformen entwickelt wird oder eben nicht, nicht viel ändern.

Kostenreduzierung

Es sei denn, die Firma plant etwas völlig Neues. Oder die Firma versucht mit der relativen Neuentwicklung auf lange Sicht Kosten zu sparen, indem sie auf plattformübergreifende Entwicklung (hier sind dann meist nur Android und iOS gemeint) umstellt. Auch die, die die neue Entwicklung ihrer Apps in fremde Hände geben, sind durchaus für Kosteneinsparungen zu begeistern, haben aber bislang oft zu wenig Informationen darüber.

Viele angefragte Entwickler werden vermutlich natürlich lieber eine iOS-App empfehlen, weil sie das gut können, und an einer zweiten Android-App ein zweites Mal noch gut verdienen. Das Interesse dieser Entwickler, selbst UWPs zu entwickeln bzw. zu empfehlen, ist daher naturgemäß eher gering. Mit der ursprünglichen Variante lässt sich mehr Geld verdienen.

Es ist also anscheinend einfach zu wenig bei den Entscheidern bekannt, bzw. oft nicht klar, dass z.B. mit Xamarin (jetzt in Visual Studio integriert) nur einmal der Code für die Applikation geschrieben werden muss. Dieser Code wird dann mit vergleichsweise wenigen Anpassungen zu iOS, Android oder Windows 10 (hier sind dann nach Wunsch mit abgedeckt: Smartphone, PC, Hololens, Hub, Xbox) portiert. Unter dem Strich ergibt sich dann etwa eine Kostenersparnis von geschätzt bis zu ca. 50% (gegenüber ZWEI Apps), man deckt damit aber drei bzw. bis zu sieben Plattformen ab.

Siehe dazu: https://docs.microsoft.com/de-de/visualstudio/cross-platform/visual-studio-and-xamarin
und https://docs.microsoft.com/de-de/visualstudio/cross-platform/develop-apps-for-the-universal-windows-platform-uwp

Die große Frage ist, an welchen Entwickler die Firmen geraten: Einen, der ihnen iOS und Android separat empfiehlt, weil er zweimal den Preis absetzen kann? Oder einen, der mit Xamarin Arbeit einspart, dadurch mehr liefern kann und dadurch aber eventuell einen höheren Preis einfordert? Wie groß ist der Einfluss, den ein Entwickler hat, überhaupt? Allein an diesen Fragen kann man schon sehen, dass es nicht so einfach ist, UWP-Apps in den Mainstream-Gedanken zu importieren.

Noch dazu, weil Apps für Windows 10 (nicht nur Windows 10 Mobile) praktisch noch nicht in der öffentlichen Wahrnehmung angekommen sind. Smartphones haben Apps, aber PCs?

Für die Community gibt es das Visual Studio übrigens kostenlos: https://developer.microsoft.com/en-us/windows/downloads

Fine-Tuning

Die Entwicklung von Apps mit Xamarin sieht jetzt also folgendermaßen aus: Der Entwickler nimmt seinen bereits vorhandenen Code und portiert ihn via Bridge nach Visual Studio (Xamarin) bzw. Developer Studio. Dort kann er, falls gewünscht, weiter dran basteln. Außerdem kann er hier die Oberfläche für die verschiedenen Plattformen (Apple, Android und die verschiedenen Windows-Oberflächen, z.B. Hololens, Hub, PC, Mobile, Xbox, IoT) bei Bedarf noch anpassen (das oben erwähnte Fine-Tuning). Wenn er fertig ist, kann er die UWP-App nach Vorstellung bzw. Einsatzzweck für die verschiedenen Windows-Plattformen kompilieren und als ein Paket in den Store schieben.

„Xamarin ist eine Entwicklungsplattform für mobile Apps zum Erstellen systemeigener iOS-, Android- und Windows-Apps auf einer gemeinsamen C#/.NET-Codebasis, die zwischen 75 % und nahezu 100 % Wiederverwendung des Codes über die Plattformgrenzen hinweg erzielt. Mit Xamarin und C# erstellte Apps haben uneingeschränkten Zugriff auf die zugrunde liegenden Plattform-APIs und bieten die Möglichkeit, native Benutzeroberflächen zu erstellen und zu plattformspezifischen Paketen zu kompilieren, sodass der Einfluss auf die Leistung zur Laufzeit minimal ist. (Hinweis: Xamarin unterstützt auch F#. Visual Basic wird derzeit nicht unterstützt.)“

Was sich jetzt im Windows Store so tummelt

Wenn wir also jetzt in den Store schauen, finden wir ein Sammelsurium der unterschiedlichsten Apps vor. Allerdings sind nicht alle dieser Apps überhaupt auf Windows 10 Mobile lauffähig. Verpackte Win32-Anwendungen sind zum Beispiel nur auf Geräten mit Intel-Prozessoren lauffähig und werden von vorneherein auf einem Windows-10-Smartphone nicht angezeigt. Und wenn der Entwickler nicht will, dann kommt die App auch nur für den PC und nicht für das Smartphone, wie z.B. die Tagesschau-App, auch wenn es (mit geringem Aufwand) möglich wäre. Bei Web-Wrappern genügt es z.B. völlig dafür, ein Häkchen zu setzen. Da manche Apps durchaus Mobile-fähig wären, aber trotzdem keine Mobile-Version im Store zu finden ist, muss man davon ausgehen, dass die Entwickler den relativ geringen Mehraufwand scheuen und/oder sich extra teuer bezahlen lassen. Wie anders wären sonst solche „fehlenden“ Apps zu erklären?

Am Design lässt sich leider nicht zweifelsfrei erkennen, welcher Herkunft eine App letztlich ist. Denn auch das Design kann auf verschiedene Weisen erreicht werden: Man kann es komplett alleine programmieren, oder man kann es per Markup definieren oder aber auf Standard-UI-Elemente der benutzten Plattform zurückgreifen. Echte UWP-Apps allerdings können nur die Standard-UI-Elemente verwenden – wird das Design der Plattform geändert, so ändert sich deren Aussehen in Maßen automatisch mit, zeitraubende Anpassungen an das neue Design entfallen.

Manche Design-Elemente können z.B. auch nicht oder nur schwer auf sehr kleinen Bildschirmen angezeigt werden. So wäre eine „normale“ Dialog-Box praktisch nicht darstellbar, da der Bestätigen/Abbrechen-Button meist außerhalb des Bildschirms liegen dürfte, weswegen er unter Windows 10 wo immer möglich entfällt. Von der Touch-Bedienbarkeit einmal abgesehen. Das ist mit ein Grund, warum UWP-Apps üblicherweise keine normalen Dialog-Boxen besitzen. Drop-down-Menüs dagegen sind wie ein Hamburger-Menü gut darstellbar. Die Menü-Bänder, wie wir sie von Office kennen, dagegen wieder nicht. (Damit ist übrigens auch verständlich, warum 4:3/2:3-Bildschirme im Business-Bereich beliebter sind, als 16:10/9-Bildschirme, die für die Video-Wiedergabe bei Consumern praktischer sind.)

Office im Store

Office an sich ist bereits in den Store portiert worden, ist aber eben genau wegen dieser Restriktionen nicht unter Windows 10 Mobile lauffähig. Ich gehe stark davon aus, dass sie bereits daran arbeiten, aus Office echte UWP-Apps zu machen, aber das dauert sicherlich noch. Vermutlich lässt sich damit auch erklären, warum auch Windows 10 ARM etwas auf sich warten lässt: Die vielen auf Win32 basierenden Apps müssen absolut verlässlich laufen können, was eben einen absolut verlässlich funktionierenden Emulator voraussetzt.

Auch die Portierung von Win32-Elementen nach UWP ist nicht ganz simpel. Mit Win32 hat der Entwickler viel mehr Möglichkeiten, mit UWP dagegen eine gefühlte Menge Einschränkungen. Hätte Microsoft auf die Centennial Bridge verzichtet, würden uns heute eine ganze Reihe Apps im Store fehlen. Auf der anderen Seite steht Windows 10 ARM schon in den Startlöchern und diese Windows-Version wird Win32 ausführen können. Es besteht also kein Grund für die Softwarehersteller, die Entwicklung neuer UWP-Apps aus den bekannten Win32-Anwendungen zu überstürzen. Man kann sich Zeit lassen.

Web-Wrapper

Eine relativ bequeme Form, eine App für eine Webseite zur Verfügung zu stellen, ist die Programmierung eines Web-Wrappers. Das ist leider nicht bei allen Webseiten möglich. Wichtig ist, dass für die App ein ordentliches „Manifest“ definiert wird. Ein Manifest kann man dabei als einen Katalog der wichtigsten Eigenschaften der Seite betrachten: Schriftgrößen, verschiedene Icons, Menüstruktur etc. Entlang dieses Manifests wird dann per Datenverbindung der Inhalt der Seite vom Internetserver ausgelesen, runtergeladen und dargestellt. Damit wäre ein Web-Wrapper im Allgemeinen auch aktueller und würde immer alle Funktionen der zugrundeliegenden Webseite anbieten können, was bei herkömmlichen Apps nicht der Fall sein muss und meist auch nicht ist.

Es ist relativ einfach, einen Web-Wrapper zu basteln. Ich habe selbst nur rudimentäre Programmierkenntnisse und habe es trotzdem innerhalb weniger Stunden geschafft. Zuerst habe ich mir das kostenfreie Visual Studio installiert. Und dann bin ich nach der Anleitung unter https://docs.microsoft.com/de-de/windows/uwp/porting/hwa-create-windows Schritt für Schritt vorgegangen. Fertig war die App. Jetzt müsste ich sie nur noch in den Store laden – was ich aber nicht tun werde, denn die zugrunde liegende Webseite gehört mir nicht.

Um eine App in den Store zu laden, benötigt man ein Developer-Konto, das mit dem eigenen Microsoft-Konto verknüpft ist. Soweit mir bekannt ist, ist das Konto dann mit einer einmaligen Gebühr (15 €) für 50 Jahre bezahlt. Man loggt sich dann im Developer Studio im Web ein und lädt die neue App bzw. das komplette App-Paket hoch. Anschließend durchläuft man noch einmal einen Fragenkatalog (bei neuen Versionen entfällt dieser Schritt) und gibt die Plattformen an, auf denen die App laufen soll, die Windows-Version, das Freigabe-Alter usw. Fertig. Nun muss man nur noch auf die Freigabe der App warten. Microsoft prüft u.a., ob die Altersangabe vorhanden ist bzw. zu passen scheint, ob alle benötigten Rechte deklariert wurden, usw.

Tut Microsoft zu wenig?

Angesichts der verschiedenen Brücken, dem Kauf von Xamarin und dem kostenlosen Visual Studio für die Community kann man Microsoft nicht vorwerfen, nicht genug für die Apps getan zu haben, allenfalls eine nicht suboptimale Kommunikation und die schleppende Vermarktung der Möglichkeiten wären zu kritisieren. Der nächste, allerdings utopische Schritt wäre gewesen, fremde Apps in den Windows Store zu portieren oder für andere Unternehmen Apps zu entwickeln.

Dass das selbst die Community nicht schafft, dazu sei beispielsweise an den Werdegang der App „Gelb-Rote Sendungen“ erinnert. Ursprünglich hieß sie wohl etwa „DHL-Sendungen“. Nach einer Abmahnung musste der Entwickler den Namen und die Farben bzw. das Logo ändern. Derlei unangenehme Erfahrungen gibt es noch mehr. Dass der Entwickler der inoffiziellen Burger-King-App noch nicht abgemahnt wurde, ist entweder ein Wunder oder die Manager von Burger King sind vernünftiger, sprich: freuen sich über die kostenlose App und die damit verbundene Werbung. Wahrscheinlich ist letzteres der Fall.

Ab und an stolpere ich auch über eine nicht vorhandene App und rufe dann dort an oder schreibe eine E-Mail. Meist beschwere ich mich darüber, dass ich „keine App dafür auf meinem Windows-10-Gerät habe“. Und dann wiederhole ich nochmal, dass ich Windows 10 und nicht Windows 10 Mobile meine, was aber keinen großen Unterschied mache. In Zukunft werde ich auch diesen Artikel dazu verlinken. Alles frei nach dem Motto: Steter Tropfen höhlt den Stein. Wer die App Projekt App-Gap kennt: Das ist das gleiche, allerdings zu Fuß.

Die öffentliche Wahrnehmung und der Mainstream

Dass es UWP schwer hat, hat auch etwas mit „Mode“ zu tun. Es existiert noch bei vielen Firmen eine gewisse „Apple-Hörigkeit“ bzw. ein gewisses Technik-Mode-Bewusstsein: Wer in sein will, hat ein iPhone, mithin eine App für Apple. Wer viele Leute erreichen will, programmiert dann noch eine für Android. Den Rest braucht man nicht unterstützen, das ist sowieso nur der Riese Microsoft, und es ist immer noch in, auf Microsoft zu schimpfen… Dagegen anstinken ist sehr, sehr schwer.

Der Weg, über die Consumer mit Windows 10 Mobile einen großen App-Store aufzubauen und das Betriebssystem auf dem Smartphone als dritte Kraft neben Apple und Android zu etablieren – der ist gründlich gescheitert. Microsoft hat überhaupt mit Consumer-Produkten – die Xbox einmal ausgenommen – kein glückliches Händchen bewiesen, obwohl sie viele tolle Ideen bzw. Produkte hatten. Für den relativ schnelllebigen Consumer-Markt ist Microsoft einfach ein wenig zu schwerfällig. Von daher finde ich die Idee, Consumer-Produkte in eine Tochter-Firma auszugliedern, richtig charmant, Leo!

Kern-Kompetenz von Microsoft dagegen war und ist immer schon der Business-Bereich gewesen. Von daher ist die Konzentration auf One Core – One Windows, Cshell und Andromeda durchaus richtig und wichtig. Es ist aus Microsofts Sicht viel einfacher, etwas Bestehendes auf eine weitere, kleine Plattform hin weiter zu entwickeln, statt parallel dazu ein separates Betriebssystem zu entwickeln. Das ist vor allen Dingen eher ein semantisches Problem, wie man es adressiert, denn ein technisches.

Ein Problem der Sichtweise

Ob Microsoft nun Windows 10 Pro auf ein kleines ARM-Device runterbricht oder Windows 10 Mobile auf ein potenteres ARM-Device hievt, ist nur ein Unterschied in der Sichtweise, in der Semantik. Technisch ist es prinzipiell das gleiche. Dann ist auch das Problem mit den vielen Win32-Apps, die unter Windows 10 Mobile nicht laufen, kein Problem mehr. Denn unter, sagen wir mal, Windows-ARM-Andromeda-Mobile werden sie alle laufen. Und dann haben Android und Apple, solange iOS und MacOS noch nicht verschmolzen sind, einen riesigen App-Gap – den haben sie zwar jetzt schon, aber dann wird es allen bewusst: Die riesige Menge an Win32-Programmen, der unter Android komplett fehlt und unter Apple nur teilweise verfügbar ist. (Ob sie auch ohne Portierung in eine Store-App unter Windows 10 ARM laufen werden, ist noch nicht raus. Cool wäre es allemal. Aber selbst mit Portierung ist der Aufwand vergleichsweise minimal.)

Bereits jetzt haben wir mit dem Windows 10 Mobile Feature 2 ein echtes Windows auf dem Smartphone, das allerdings aus Performance-Gründen einige Bausteine nicht enthält – womit der Begriff Feature 2 völlig ausreichend erklärt wäre. (Feature im Sinne von „kann weniger als“, genauso wie bei Feature Phones.)

Auch Windows 10 ARM, d.h. der Win32-Emulator, wird aus Performance-Gründen nicht auf die aktuellen Smartphones, die aktuelle Hardware kommen können. Zusätzlich wird als Mindest-Bildschirmgröße 6“ angegeben, damit die Win32-Programme noch einigermaßen sinnvoll bedient werden können.

Cshell und ein paar Gerüchte

Ob allerdings die Cshell noch auf die leistungsstärksten aktuellen Handys kommt, steht sehr im Argen. Lauffähig ist sie, wie bereits mehrfach gezeigt wurde, und für Microsoft bestimmt auch kein Hexenwerk. Aber ist es sinnvoll, ein neues Gerät mit der Cshell und auch gleich Windows 10 ARM (Andromeda) anzubieten und die alten Geräte fallen zu lassen? Ist es sinnvoll, sozusagen einen großen Entwicklungssprung zu machen (wie bei Windows Mobile mehrfach in der Vergangenheit praktiziert), in der Hoffnung, dass die Leute sowieso eher das neue Gerät werden haben wollen?

Oder ist es nicht sinnvoller, die Cshell noch auf die alten leistungsstärkeren Handys zu bringen, als Continuum 2.0, um die User mit den Altgeräten (sozusagen als Appetizer) für das neue Gerät zu sensibilisieren? Das wäre auch ein schönes Signal an Android mit deren DeX. Und an den depressiven Teil der Community. Und es würde zu den Gerüchten passen, dass es im Herbst 2017 noch ein „Übergangssmartphone“ geben soll, eventuell eines von HP.

Allerdings hat Zac Bowden (WindowsCentral) mitgeteilt, dass es keine Cshell für Windows 10 Mobile geben wird, wie ihm gesagt wurde, weil es nach wie vor Redstone 2 wäre. Redstone 3 und 4 werden nicht für Windows 10 Mobile kommen, allerdings werden Apps mit den neuen APIs von Redstone 3 bzw. 4 auf Redstone 2 zurück portiert, sodass sie auch laufen werden und Windows 10 Mobile weiterhin attraktiv bleiben wird, bis Andromeda fertig ist.

Das „kategoriedefinierende Gerät“

Ein nächster Schritt auf eine potentere bzw. kleine bzw. höchst mobile Hardware ist nun fällig, sowohl aus der Sicht von Windows 10 Pro als PC-Betriebssystem, als auch aus Sicht von Windows 10 Mobile, den bisherigen „ausgelutschten“, toten Smartphones. Ohne es hätte Microsoft hier eine Lücke…

Mit dieser neuen Hardware kann und wird nun ein starker Drang in den Windows Store einsetzen müssen. Weniger, weil Microsoft das so möchte, sondern vermutlich eher, weil der Business-Bereich das so haben wollen wird.

Übrigens gibt es mit dem Azure App Service auch das ganz große Entwicklerpaket mit einer Platform as a Service (PaaS) für die Entwicklung von leistungsstarken Apps mit richtig großen Backendlösungen. Big Business und Big Data werden also hiermit auch noch abgedeckt, ohne dass der Entwickler jedes einzelne Detail selbst programmieren muss.

Siehe dazu: https://docs.microsoft.com/de-de/azure/app-service-mobile/app-service-mobile-value-prop

Wie schätzt Ihr nun die App-Situation ein? Könnte Microsoft noch mehr tun, und wenn ja, was?
Wie denkt Ihr, dass die weitere Entwicklung aussehen könnte?

Diskutiert mit uns in den Kommentaren!