Google hat Tools vorgestellt, mit denen Entwickler Chrome-Apps auch für mobile Geräte anbieten können. Damit verfolgt Google weiter konsequent seine Strategie, um mehr Entwickler für Chrome-Apps zu gewinnen. Schon seit September 2013 können Chrome-Apps als Offline-Apps wie native Anwendungen auf Desktopsystemen verwendet werden. Nun sollen diese Offline-Apps auch auf den mobilen Systemen Android und iOS verwendbar sein. Interessant ist, dass Windows Phone nicht unterstützt, ja von Google nicht einmal erwähnt wird.

Für mobile Anwendungen sollen die Chrome-Apps mit einem dünnen Wrapper versehen werden, so dass die Anwendungen als native Apps erkannt werden und auf Gerätefunktionen Zugriff haben. Dazu nutzt Google Apaches Cordova Projekt, besser bekannt unter dem alten Namen Phonegap. Mit Hilfe dieses Projekts und spezieller Erweiterungen von Google sollen die Apps auf Google Play oder Apples App Store bereitgestellt werden können. Details dazu können Googles Blog-Ankündigung entnommen werden.

Für die Nutzer sind diese Apps erstmal nicht direkt als Chrome-Apps erkennbar. Sie bekommen sie wie alle anderen Apps auf Google Play bzw. Apples Store angeboten. Genau hier aber fangen bereits die Schwierigkeiten an. Einfach eine Webanwendung zu nehmen, die auf dem Desktop funktioniert, und mit einem Wrapper versehen als mobile App bereit zu stellen, das reicht nicht. Diese Anwendungen entsprechen weder auf iOS noch auf Android den Erwartungen, die Nutzer an native Apps haben.

Erstens werden diese Apps wie ein Fremdkörper aussehen. Dazu reicht ein Blick auf den Beispiel-Screenshot der Android-App aus Googles Ankündigung. Es fallen sofort die fehlende Actionbar, der für Android untypische Header oder die ungewöhnlichen Buttons auf. Man kann das Design sicher mehr oder weniger in den Griff bekommen, allerdings nur mit erheblichem Aufwand. Dann ist das aber auch kein einfacher Wrapper mehr und erfordert separate Anpassungen für alle unterstützten Plattformen.

Zweitens sind die Interaktionsmuster im Web, auf Desktop-Systemen und auf den verschiedenen mobilen Systemen grundverschieden. Allein zwischen iOS und Android gibt es deutliche Unterschiede, unter anderem bei der Navigation, dem Umgang mit Aktionen und dem korrekten Zuschnitt der Screens und Abläufe. Dieses Problem ist weitaus gravierender als das Design-Problem und Cross-Plattform Tools bieten hierfür keine Lösung.

So ganz einfach scheint es mit dem Cross-Plattform-Ansatz aber auch aus technischer Sicht nicht zu sein. Schaut man sich Googles Beispiel-Apps an, dann laufen fünf der 17 mobilen Apps gar nicht auf Android und sechs weitere nur mit Einschränkungen.

Und für iOS sieht es auch nicht besser aus: Sechs Apps laufen gar nicht, weitere fünf nur mit Einschränkungen. Lediglich zwei Anwendungen funktionieren vollständig auf beiden Plattformen. Und dieser Weg soll es Entwicklern einfacher machen? Soll geeignet sein, Cross-Plattform-Apps zu entwickeln? Wohl eher nicht.

Das Einzige, wo ich bei der Portierung von Chrome-Apps keine Befürchtungen habe, ist die Unterstützung eines responsiven Designs für die unterschiedlichen Gerätetypen und -größen. Hier ist das Web schon seit Jahren Vorreiter.

Will man Anwendungen bereitstellen, die auf den verschiedenen Systemen die Nutzer zufrieden stellen, muss man die Besonderheiten der jeweiligen Systeme berücksichtigen. Und das bedeutet Aufwand - egal welchen Weg man beschreitet. Und ich behaupte, der Gesamtaufwand ist geringer mit drei separaten Projekten für Android, iOS und Windows Phone als mit einem Cross-Plattform Ansatz. Zumal ich bisher noch kein Beispiel gesehen habe, wo ein Cross-Plattform-Ansatz wirklich funktioniert.

Google hat in den letzten Jahren viel getan, um einen einheitlichen Design- und Usability-Ansatz für Android zu verankern. Umso enttäuschender ist diese Ankündigung. Denn mit diesem Tool legt Google den Rückwärtsgang ein. Zurück in eine uneinheitliche Welt ohne gemeinsame Designsprache, ohne typische Interaktionsmuster. Die Nutzer werden diesen Weg allerdings nicht mitmachen.

Als mobiler Entwickler sollte man Googles Projekt beobachten. Zum Einsatz taugt es aber derzeit noch nicht. Dessen sollten sich auch Projektleiter und Produktverantwortliche bewusst sein, wollen Sie nicht am Ende vor ausufernden Kosten stehen - für ein Produkt, das von den Nutzern nicht angenommen werden wird.