Editorial: Die mobile Betriebssystemflut
Vor vier Jahren war die Welt der Smartphone-Betriebssysteme noch einfach: Es gab Symbian, und es gab den Rest wie Windows Mobile, PalmOS oder RIM OS, die zusammen nochmal auf dieselbe Stückzahl kamen wie Symbian alleine. Und viele Kommentatoren und Marktbeobachter sagten eine weitere Konzentration voraus, dass mittelfristig nur zwei bis drei unabhängige Systeme überleben würden.
Es kam aber vollkommen anders: Nicht nur sind alle damals wichtigen Systeme auch heute weiterhin verfügbar (wenn auch in aktualisierten Versionen, etwa wurde PalmOS zu WebOS), nein, es kamen zwei wesentliche neue Anbieter hinzu: Mac OS X von Apple und Android von google. Und es werden immer mehr, etwa bada von Samsung und MeeGo von Intel und Nokia.
Das Konzept zur Entwicklung eines neuen Handy-Betriebssystem erscheint einfach: Man nehme ein etabliertes offenes PC-Betriebssystem (etwa Linux oder im Falle von Apple auch BSD), ergänze es um die nötigen Treiber, optimiere einen bestehenden freien Browser (Webkit oder alternativ auch Gecko/Firefox) auf die mobilen Bedürfnisse und stricke darum eine Oberfläche. Es scheint nur eine Frage der Zeit, bis auf diesem Weg das zweite Dutzend voll wird.
Fluch oder Segen?
Die gute Nachricht für die Verbraucher: Es gibt kein Monopol. Der intensive Wettbewerb zwischen den Systemen zwingt die Entwickler, innovative Konzepte auszuprobieren, und zu übernehmen, was sich bei der Konkurrenz bewährt hat. So konnte sich der Touchscreen binnen kurzem als Smartphone-Bedienkonzept durchsetzen. Ebenso geschwind ziehen derzeit Navigationsdienste in die Smartphone-Welt ein; kaum ein neues Gerät erscheint, dass nicht zumindest A-GPS und nachinstallierbare Navigiationssoftware unterstützt.
Was dieser Tage für viele Betriebssystem-Entwickler eine besonders erwähnenswerte Neuigkeit, nämlich die Integration von Social-Networking-Diensten wie Twitter, Facebook oder Buzz, wird in zwei Jahren so selbstverständlich sein, dass sie von den Handy-Hersteller bei der Neuvorstellung kaum mehr erwähnt wird. Dafür werden neue Features in den Mittelpunkt rücken, die wir heute allenfalls ahnen können.
Die schlechte Nachricht: Es gibt kein Monopol. Jedes System verwendet etwas andere interne Strukturen und Protokolle für Datenaustausch und Synchronisation. Die Aufgabe, die Kontakt- und Terminverwaltung für ein größeres Team von Windows Mobile und Exchange auf Android und SyncML zu migrieren, treibt den Admins die Schweißperlen auf die Stirn. Und während es für eine Desktop-Webpage zumeist reicht, sie in jeweils einem Exemplar der vier großen Browser-Familien (Internet Explorer, Firefox, Webkit = Safari und Chrome, Opera) auf einem einzelnen PC zu testen, muss eine mobile Website auf mindestens einem Dutzend Geräten getestet werden, bevor man sich auch nur halbwegs sicher sein kann, dass sie überall vernünftig dargestellt wird.
Und so ist die Systemvielfalt gut für die Verbraucher, indem sie das Gerät wählen können, dass ihren persönlichen Vorlieben am nächsten kommt. Und sie ist gut für die Entwickler und Admins in dem Sinn, dass sie sie beschäftigt hält.
Anwendungs-Container
Den schwersten Stand haben Entwickler, die Anwendungen (Apps) für Smartphones entwickeln. Sie müssen ihre Programme im Zweifelsfall einzeln auf jede Kombination aus Betriebssystem und Oberfläche anpassen. Einen Ausweg aus diesem Problem bieten portable Entwicklungsumgebungen: Die Java-Umgebung J2ME läuft auf den meisten Smartphones (die große Ausnahme ist Apples iPhone) und sogar vielen Feature-Phones, und ist vor allem für die Entwicklung von Handy-Spielen beliebt. Und Adobe drängt mit mobilen Flash-Playern in denselben Markt.
Der Nachteil dieser Umgebungen: Sie können im Vergleich zu nativer Software nur einen Teil der systemnahen Funktionen nutzen. Und sie verlangen dem Applikationsprozessor mehr Leistung ab, denn auf einer Meta-Ebene geschriebene Software ist weniger effizient als solche, die nativ direkt auf dem Prozessor läuft.
Die genannten Umgebungen bieten aber auch Vorteile, insbesondere bei der Sicherheit: Eine native Applikation kann fast nach Belieben Schadcode ausführen. Eine J2ME- oder Flash-Anwendung muss hingegen zunächst eine Sicherheitslücke in der zugrundeliegenden Umgebung ausnutzen, um dann nativen Schadcode nachladen zz können. Dieser Sicherheitsvorteil wird aber dadurch mehr als konterkariert, dass viele Browser die in Webseiten enthaltenen Flash- oder Java-Applets automatisch herunterladen und ausführen.