Cross-Platform-Entwicklung
Cross-Platform-Entwicklung bedeutet, eine App einmal zu programmieren und sie danach auf mehreren Systemen laufen zu lassen, etwa auf iPhones und Android-Handys. Das spart Zeit und Geld, kostet aber oft etwas Geschwindigkeit und Nähe zum jeweiligen Gerät.
Ein Handy von Apple und ein Handy mit Googles System Android sind innen sehr verschieden. Sie verstehen unterschiedliche Programmiersprachen und bieten Entwicklern unterschiedliche Werkzeuge an. Früher musste eine Firma ihre App deshalb zweimal komplett neu schreiben, einmal für jedes System. Cross-Platform-Entwicklung ist der Gegenentwurf dazu: Man schreibt den Programmtext nur einmal und lässt ihn anschließend auf beiden Systemen laufen. Ein Zwischenwerkzeug übersetzt oder vermittelt dabei zwischen dem gemeinsamen Programmtext und dem jeweiligen Gerät. Dasselbe Prinzip gilt auch für Programme, die gleichzeitig unter Windows, macOS und Linux funktionieren sollen.
Warum Firmen nicht dreimal dieselbe App bauen wollen
Der Hauptgrund ist schlicht Geld. Zwei getrennte Apps bedeuten zwei Teams, zwei Fehlerlisten und zwei Zeitpläne. Bei einem gemeinsamen Programmtext teilen sich beide Versionen oft 70 bis 90 Prozent des Codes. Eine neue Funktion muss dann nur einmal gebaut und einmal getestet werden.
Dazu kommt ein Vorteil, den man als Nutzer direkt merkt. Bei getrennten Apps hinkt eine Version fast immer hinterher. Die Android-Variante bekommt ein Feature Monate später als die iPhone-Variante, oder umgekehrt. Ein gemeinsamer Code hält beide Fassungen automatisch auf demselben Stand.
Der Preis dafür ist Kontrolle. Wer für ein System allein programmiert, kann jede Besonderheit des Geräts ausreizen, etwa eine neue Kamerafunktion am Erscheinungstag. Cross-Platform-Werkzeuge unterstützen solche Neuerungen oft erst mit Verzögerung. Für Spiele mit hohen Grafikanforderungen oder Apps, die dauerhaft Sensoren auslesen, ist der Umweg manchmal spürbar langsamer.
Der gemeinsame Code und die Übersetzungsschicht
Technisch gibt es zwei große Familien von Lösungen. Die eine Familie erzeugt aus dem gemeinsamen Code echte Apps für das jeweilige System. Bekannte Vertreter sind Flutter von Google und React Native von Meta. Sie liefern eigene Bausteine für Knöpfe, Listen und Menüs mit, die auf beiden Systemen gleich aussehen oder sich anpassen lassen.
Die zweite Familie verpackt im Grunde eine Webseite in eine App-Hülle. Der Inhalt wird mit den Sprachen des Internets gebaut und in einem unsichtbaren Browserfenster angezeigt. Das ist besonders günstig, weil viele Entwickler diese Sprachen ohnehin beherrschen. Dafür fühlen sich solche Apps manchmal etwas träge an, weil zwischen Bedienung und Gerät eine zusätzliche Schicht liegt.
Ein hilfreiches Bild ist ein Dolmetscher. Der gemeinsame Code spricht eine Sprache, das Gerät eine andere, das Werkzeug übersetzt dazwischen. Übersetzen kostet immer ein wenig Zeit und geht selten ganz ohne Verluste. Deshalb schreiben viele Teams kleine Teile ihrer App trotzdem separat für jedes System, etwa den Zugriff auf besondere Hardware.
Welche bekannten Apps so gebaut sind
Viele Programme, die man täglich benutzt, sind plattformübergreifend gebaut. Die Desktop-Versionen von Spotify, Discord und Visual Studio Code laufen alle auf einer Web-Technik in einer App-Hülle. Auf dem Handy nutzen unter anderem Teile von Instagram und die App der Deutschen Bahn solche Ansätze. Nutzer merken davon im Idealfall nichts.
In Wirtschaftsnachrichten taucht der Begriff auf, wenn Unternehmen über Entwicklungskosten sprechen. Ein Start-up mit fünf Programmierern kann sich zwei getrennte Apps meist nicht leisten. Große Konzerne mit hunderten Entwicklern entscheiden sich dagegen häufiger für getrennte Versionen, weil sie maximale Qualität wollen. Manche Firmen wechseln auch wieder zurück und begründen das öffentlich mit Geschwindigkeitsproblemen.
Ein verbreiteter Irrtum ist, Cross-Platform bedeute überall exakt dieselbe Bedienung. Gute Apps passen sich weiterhin an: Ein Zurück-Knopf sitzt auf Android anders als auf dem iPhone. Geteilt wird vor allem die Logik dahinter, also Berechnungen, Datenverwaltung und Serverzugriffe. Die Oberfläche bleibt oft bewusst unterschiedlich.