HintergrundSmartphone
9144
Google geht auf Apple zu: Wie ein Knopf auf deinem Phone die Welt verändert
Dominik Bärlocher
Zürich, am 13.10.2021
Google stellt um. Apps auf iPhones und iPads werden neu mit Apple-Komponenten gebaut. Für User ändert sich wenig, aber Google ist ein grosser Erfolg gelungen, selbst wenn sie der Konkurrenz unter die Arme greift.
Google Apps auf iPhones und iPads sollen mehr wie Apple Apps wirken.
Das alleine klingt nicht nach der grossen Sensation, bedeutet aber viel. Denn hinter dem Entscheid, die Google Apps Apple-iger zu machen, steckt viel Arbeit, Politik, Missgunst und Konkurrenzdenken.
Die Umstellung von Googles Eigenentwicklung auf Apple-Komponenten mag zwar der Konkurrenz in die Hände spielen, war aber bitter notwendig und lohnt sich für Google.
App-Architektur: Was hinter den Kulissen läuft
Jede App hat ein Framework. Beim Hausbau wäre das Framework das Baugerüst, auf das die Benutzeroberfläche, die du siehst und benutzt, aufgebaut ist. Frameworks existieren für Backends und Frontends. In diesem Artikel sind nur Frontends wichtig – also Benutzeroberflächen und alles das, was der Kunde sieht. Der Einfachheit halber nenne ich diese im Folgenden einfach «Framework».
Das Framework, dessen Wahl und dessen Eigenheiten, ist ein Entscheid, der von Managern gefällt wird, nicht nur von Programmierern.
Apps auf deinem Smartphone werden in einem sogenannten App Framework erstellt.
Google benutzt das UI-Framework Flutter.
Apple benutzt das UI-Framework UIKit.
Diese beiden Frameworks sind in Software Development Kits (SDK) integriert. Bei Google heisst es Android Studio, bei Apple Xcode. Beide SDKs wurden von den jeweiligen Herstellern erfunden und werden stets weiterentwickelt. Beim Hausbau wären das der Werkzeugkasten, in dem alle Werkzeuge für den Hausbau sind.
Du kannst mit Apples SDK Android Apps machen. Denn UIKit und Xcode arbeiten mit der Programmiersprache Swift, die auch für Android Apps verwendet werden kann. Android arbeitet zwar mit Java, unterstützt aber so ziemlich jede geläufige Programmiersprache auf dem Markt.
Kurz: Es ist also möglich, mit Android-Programmierkünsten iOS Apps zu machen. Und andersrum auch. Nur, dass das in den wenigsten Fällen sinnvoll ist. Der Grund hierfür ist weniger technologisch, sondern mehr politisch.
Die Politik hinter dem Programmieren
Die SDKs sind gratis und frei zugänglich. Die Programmiersprachen sind open source und auch frei zugänglich. Das verspricht das grosse Zeitalter der Apps. Ein Programm, kompatibel mit allem. Technologisch wären die Wege geebnet, dass alle mit allen immer native Apps entwickeln und nutzen könnten.
Nur, dass weder Google noch Apple besonders viel Interesse daran haben, dass das so passiert.
Klar, beide Konzerne sprechen von Offenheit und schmeissen mit Begriffen wie «intuitiv» um sich. Aber das betrifft nur den Fall, dass ein Android-Programmierer mit dem Android Studio für Android programmiert. Alles andere gleicht einem Workaround. Ein Blick in Flutter for iOS Developer zeigt, wie das geht. Begriffe unterscheiden sich, Dinge funktionieren anders und generell müssen Programmierer die Programmiersprache komplett neu erlernen.
Das ist dann halt nicht mehr «intuitiv» oder «einfach zugänglich». Es ist extrem kompliziert, diesen Brückenschlag in der Praxis auch nur ansatzweise vernünftig hinzukriegen. Da scheint es einfacher, wenn ein Programmierer einfach zwei SDKs installiert und die App praktisch zweimal schreibt. Das aber braucht Zeit und Ressourcen, die nur grössere Programmierstudios haben. In der Realität stehen alle App-Programmierstudios, kleine oder grosse, vor einer Wahl:
Sie entscheiden sich für eine Plattform (iOS oder Android) und geloben, die andere Plattform dereinst auch zu bewirtschaften.
Das Studio nimmt ein Hybrid-Framework zur Hilfe. Es ist nicht zwingend notwendig, ein natives Framework zu verwenden. Ionic ist so ein hybrides Framework. Flutter kann auch hybrid, aber um Xcode kommst du da nicht herum.
Das Studio baut die App doppelt. Das kann sogar billiger sein als mit einem Hybrid-Approach.
Hier treffen Management und operative Effizienz aufeinander. Die Entwickler bauen etwas, das zwar open source ist, aber dessen tatsächliche Implementation im echten Leben ausserhalb eines festgesetzten Rahmens absurd kompliziert ist. Könnte das einfach gemacht werden? Ja. Wird es einfacher gemacht? Nein. Grund: die Komponenten für die eigenen Plattformen müssen weiterentwickelt werden. Das braucht Ressourcen, Zeit und Arbeit. Ressourcen, die nicht für die Konkurrenz aufgewendet werden sollen.
Ein etwas weniger abstraktes Beispiel: Wenn Apple den Export Swifts für Android optimieren würde, dann würde der Konzern aus Cupertino Arbeit für seine grosse Gegnerin Google machen. Apple würde Apple-Ressourcen für die Entwicklung Googles verschwenden. Denn Apple selbst hätte davon nichts. Die Programmierwelt vielleicht, aber Apple will eigentlich nicht für die Konkurrenz arbeiten und ist wirklich gut darin, abgeschottete Bereiche für sich zu erstellen und zu halten.
Google Maps auf iOS: Ein Gebastel, historisch gesehen
Mit dem Aufstieg der iPhones und dem gleichzeitigen Siegeszug Androids ist nicht nur eine Konkurrenzsituation entstanden, sondern auch ein Bedürfnis. Das Bedürfnis von Youtube auf dem iPhone, Google Maps und vielleicht Google Photos.
Google hatte da recht wenig Lust drauf, denn sie würden Apple-Usern einen Grund nehmen, auf Android umzusteigen. Doch der öffentliche Druck war zu gross. Also haben Google Apps nach und nach Einzug auf Apples Plattformen gefunden. Andersrum auch. Apple bietet auf dem Google Play Store eine Handvoll Apps an, macht aber keinerlei Anstalten, die iCloud auf Android zu portieren.
Warum auch? Wer die iCloud will, soll ein iPhone verwenden.
Wer Google Drive verwenden will, kann so ziemlich jedes Smartphone verwenden.
Beides sind politische Entscheide der jeweiligen Hersteller. Und zu beiden Entscheiden gibt es nur eines zu sagen: Fair enough. Unternehmen sind nicht der Offenheit verpflichtet. Es ist vielleicht etwas sportlicher, offen zu sein, aber keiner kann Apple zur Sportlichkeit zwingen. Genau wie Google nicht verpflichtet ist, auf Apple-Plattformen vertreten zu sein. Rechtlich gesehen muss bei der Software-Entwicklung bloss dem offensichtlichen Monopol aus dem Weg gegangen werden. Solange keiner ein Monopol nachweisen kann, ist alles okay.
Google hat sich anno 2012 dazu entschlossen, als erste App auf iOS Google Maps zu portieren. Beim Development der Google-App für Apples Ökosystem ist dem Team um Development Leader Jeff Verkoeyen aufgefallen, dass Apple einige zwingend notwendige Elemente für die Google Apps fehlen. Daher hat das Team diese Elemente nachgebaut – als Fremdkörper, in der Fachsprache Material Components genannt. Sie sind natürlich quelloffen. Damit umgehen Google und Apple dem Vorwurf des Monopols.
Sprich: Die erste Version von Google Maps auf Apples iOS war ein Gebastel. Die App hat Apple-eigene Libraries, Designelemente und Funktionen mit von Google nachgelieferten vermischt.
So war es. Neun Jahre lang.
Material Components: Im Maintenance Mode seit Juli
Im Juli 2021 aber ändert sich das. Die Material Components für iOS – die Fremdkörper – werden von Google in den Maintenance Mode versetzt. Das heisst, sie werden bis auf weiteres nicht weiterentwickelt sondern lediglich noch gepflegt. Sollte etwas kaputt sein, wird es repariert. Sicherheitslecks werden gestopft. Aber sonst dürfen die Material Components in Würde sterben.
Damit macht Google einen grossen Schritt, politisch gesehen. Denn anstatt eigene Komponenten zu laden, setzen Jeff Verkoeyen und sein Team in der Zukunft vollends auf die Apple-eigenen Komponenten. Dies bestätigt Verkoeyen in einem Twitter Thread.
Verkoeyen beschreibt die Situation, die in der nicht-gemeinsamen Entwicklung einer Software unausweichlich ist. Die Material Components werden weiterentwickelt und gehen in eine Richtung. Die Kernkomponenten Apples entwickeln sich weiter und gehen in eine andere Richtung. Die Brücke, die die Material Components schlagen muss, wird immer grösser.
Anfang 2021 fragt sich das Team um Jeff Verkoeyen: Muss der Brückenschlag überhaupt noch sein?
Der Blick auf das, was Apples SDK und dessen Komponenten können, zeigt: Apple kann das mittlerweile auch. Es war Zeit, ein paar unangenehme Fragen zu stellen: Muss ein einfacher Schalter in einer App wirklich eine eigene Komponente einer externen Library anfordern?
Die Antwort war klar: Nein. Viele der Material Components werden nicht mehr gebraucht, da Apples Kernkomponenten diese mittlerweile liefern. Die paar Komponenten, die noch zusätzlich reingeladen werden müssen, werden dank dem Maintenance Mode aller anderen Komponenten mehr Aufmerksamkeit erhalten. Das verspricht schnelleres und effizienteres Development der Google Apps unter iOS.
Es ist gut möglich, dass du als Nutzer diese Änderung gar nicht mitbekommst. Dies obwohl einfache Elemente in den Google Apps neu statt mit dem Material Component «App bar» mit dem Apple-eigenen «UINavigationController» gemacht werden.
Natürlich werden diese Apple Components in Googles Apps nicht so aussehen, als ob sie Apple erstellt hätte. Googles eigene Markenidentität wird einfliessen.
Fazit: Geld (und ein bisschen Development) steht über Politik
Der Entscheid Googles, mit Apples Komponenten zu arbeiten, ist ein zweischneidiges Schwert. Er zeigt aber, dass die Vernunft siegen kann. Denn die Umstellung von Googles eigenen Komponenten auf Apples Äquivalente spart Google zwar Geld, bringt der Konkurrenz aber gleichzeitig Informationen, Wissen und vielleicht sogar Code, um etwas zu verbessern, das Apple bis dato nicht verbessern wollte. Oder von dem Apple nicht gewusst hat, dass es verbessert werden müsste.
Aber auf Funktionsseite ist der Entscheid vernünftig. Nur, weil etwas vor zehn Jahren gut oder gar notwendig war, heisst das nicht, dass es heute noch gut oder notwendig ist. Wenn Apple Komponenten liefern kann, die dieselbe Funktion wie die Google-eigenen übernehmen, dann ergibt es Sinn, die Eigenentwicklungen in Würde sterben zu lassen.
Google gelingt zudem ein grosser Wurf mit der Umstellung. Die Services, die die Apps der Suchmaschinengigantin liefern, sind allen Usern lieb. Aber die Kritik, dass die Apps auf iPhones sich nicht so gut anfühlen, wie sie es unter Android tun oder wie Apple Apps sich unter iOS anfühlen, ist berechtigt. Und mit der Umstellung sehr wahrscheinlich dann hinfällig.
Die Suchmaschinengigantin spart Geld, Zeit und macht sich bei den Usern beliebt. Ein Volltreffer.
Verkoeyens Team musste aber Mut beweisen. Denn zuzugeben, dass die Arbeit von zehn Jahren nicht mehr gebraucht wird, ist keine kleine Sache. Zum einen könnten so Stellen im Team verloren gehen, zum anderen beweisen Verkoeyen und Co., dass die «Sunk Cost Fallacy» überwunden werden kann. Oder sogar überwunden werden muss. Nur, weil bisher Geld und Zeit investiert wurde, heisst das nicht, dass sich eine weitere Investition lohnt.
Für User ändert sich vielleicht ein Schalter in der App. In der Hausbau-Metapher wäre das ein Isolationsmaterial in der Wand. Für Google und Apple aber hat sich soeben die Welt ein bisschen verändert.
