iOS-Apps auf Android portieren

Trotz einiger Gemeinsamkeiten unterscheidet sich die Bedienung von iOS- und Android-Apps in zentralen Punkten. Wer das bei einer Portierung seiner App auf die jeweils andere Plattform nicht berücksichtigt, riskiert negative Bewertungen in den App-Stores – und damit spürbare Einbußen beim Umsatz.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen
Lesezeit: 10 Min.
Von
  • Markus Junginger
Inhaltsverzeichnis

Trotz einiger Gemeinsamkeiten unterscheidet sich die Bedienung von iOS- und Android-Apps in zentralen Punkten. Wer das bei einer Portierung seiner App auf die jeweils andere Plattform nicht berücksichtigt, riskiert negative Bewertungen in den App-Stores – und damit spürbare Einbußen beim Umsatz.

Auch wenn iOS ein durchdachtes Bedienkonzept bietet, sollte man bei der Portierung von iOS-Anwendungen auf die Android-Plattform bestimmte Anpassungen durchführen, denn auch hier herrschen eigene Gepflogenheiten und Standards. Dennoch sieht man immer wieder Android-Apps, die 1:1 von einer iOS-App geklont wurden – in aller Regel werden sie von Nutzern und Rezensenten entsprechend negativ bewertet. Dieser Artikel möchte grundlegende Unterschiede erklären, um den Leser ein solches Schicksal zu ersparen.

Technisch gibt es zwischen nativen iOS- und Android-Apps kaum Gemeinsamkeiten. Die Programmiersprachen und APIs unterscheiden sich so stark, dass man nicht von einer einfachen Portierung sprechen kann. Vielmehr sind es zwei getrennte Projekte mit jeweils vergleichbarem Aufwand. Beim Bedienkonzept gibt es jedoch einen hohen Anteil an Überschneidungen, so dass man zumindest bei der Konzeptionierung und dem Screendesign einen Teil des Aufwandes einsparen kann. Zudem haben sich in der Praxis einige Muster bewährt, wie das User-Interface von iOS zu Android übertragen werden kann.

Viele iPhone-Apps nutzen die sogenannte Tab Bar am unteren Bildschirmrand, um die Anwendung in unterschiedliche Bereiche zu gliedern. Dieses UI Pattern gibt es bei Android in dieser Form nicht. Stattdessen wird hier regelmäßig das Dashboard Pattern angewandt (Abbildung 1).

Unter iOS greift man in aller Regel auf die Tab Bar als Navigationselement zurück. Bei Android ist hingegen das Dashboard populär (Abb. 1).

Beide Vorgehensweisen haben Vor- und Nachteile und ziehen weitere Konsequenzen nach sich. So kann der Nutzer beim Dashboard Pattern unter Android nicht direkt in einen anderen Programmteil springen, sondern muss den Umweg eben über das Dashboard gehen. Dafür gewinnt der Entwickler aber kostbare Bildschirmfläche für die Anwendung. Das Dashboard Pattern lässt sich gut mit Teaser-Elementen kombinieren, um beispielsweise auf aktuelle Inhalte hinzuweisen. Und man muss auch nicht unbedingt Icons auf dem Dashboard platzieren. Gerade mit Android 4.0 rückt das klassische Dashboard ohnehin etwas in den Hintergrund. Die offizielle Google+-App ist zwar noch ein Beispiel für das herkömmliche Dashboard Pattern, aber andere Google-Apps wie Google Play, Gmail und YouTube gehen schon jetzt neue Wege. Oft starten die Apps mit einem zentralen Bildschirm, der bereits alle wichtigen Informationen und Funktionen abbildet. Existieren weitere Bildschirmseiten, die in der Navigationshierarchie ebenfalls ganz oben stehen (Top-Level-Seiten), sind diese oft mit Tabs oder Swipe-Gesten umgesetzt.

Tabs werden in Android oben platziert und weichen auch sonst in einigen Punkten von der iOS-Variante ab. Während die iOS Tab Bar immer sichtbar ist, verschwinden die Tabs bei Android, wenn man eine Ebene tiefer in die App navigiert. Insgesamt sind Tabs also durchaus ein komplexeres Thema, mit dem man sich gesondert befassen sollte. Beispielsweise wurde die Tab-Funktionalität mit Android Version 3.0 komplett überarbeitet und in die sogenannte Action Bar verlagert.

Beim iPhone gibt es im oberen Bereich der App die Navigation Bar. Neben dem Titel der aktuellen Ansicht gibt es links einen Button, um in der App einen Schritt zurückzugehen. Unter Android gibt es stattdessen eine Titelleiste, oder in neueren Versionen die Action Bar. Die in die Tage gekommene Titelleiste ist wesentlich kleiner, da sie keine weiteren Funktionen beherbergt. Die Funktion des Zurückgehens ist bei Android bereits im System integriert und mit einer Hardwaretaste oder in einer Systemleiste umgesetzt. Etwas moderner ist das Action Bar Pattern, das mit Android 3.0 Einzug in das System gehalten hat. Die hier deutlich größere Action Bar ersetzt die Titelleiste und bietet neben dem Titel weitere Funktionen der App an. Damit bietet die Action Bar nicht nur einen Ersatz für die iOS Navigation Bar. Auch Funktionen der iOS Toolbar lassen sich hier unterbringen (Abbildung 2). Auf dem iPhone findet sie sich am unteren Rand, während auf dem iPad Navigation Bar und Toolbar inzwischen durchaus im oberen Bereich miteinander verschmelzen. Insofern haben sich iOS und Android hier angenähert.

Die Action Bar unter Android ab Version 3.0 vereint den aus iOS bekannten Funktionsumfang der Navigation Bar und der Toolbar. Grundlegende Funktionen sind auf Hardware-Tasten oder eine Systemleiste ausgelagert (Abb. 2).

Mit Android 4.0 und der Split-Action Bar geht die Annäherung sogar noch weiter. Auf Android-Telefonen lässt sich die Action Bar hier zweiteilen und die Aktionen können analog zur iOS Toolbar auf den unteren Bereich verlagert werden. Die Aufteilung nimmt das System jedoch nur im Portraitmodus vor, da die obere Action Bar im Landscape-Modus genug Platz bietet.

Die Action Bar ist eine wichtige und leistungsfähige Komponente von Android, die sich generell für typische Android Apps anbietet. Auch die Verwendung der Action Bar unter den noch weit verbreiteten Android-2.x-Systemen ist möglich: Mit der Open-Source-Bibliothek ActionBarSherlock existiert ein Backport der Action Bar von Android 4.0.