Designunterschiede zwischen iOS und Android

Kurz gesagt

Wenn Sie eine App für zwei Plattformen bauen, arbeiten Sie mit zwei Regelwerken. Für iOS gibt es Apples Human Interface Guidelines (HIG), für Android Googles Material Design 3 (M3).

Bei Grundlagen wie lesbarer Schrift und bequemen Touch-Zielen kommen beide zum selben Ergebnis. Die eigentlichen Unterschiede liegen dort, wo die Hand der Nutzer an etwas gewöhnt ist. Wo steht Zurück, wohin kommt die Hauptaktion?

Ich habe die aktuellen Seiten beider Quellen geöffnet und verglichen. Die Daten gebe ich so an, wie sie in der Quelle stehen, denn beide Leitfäden ändern sich oft.

Derselbe Screen, zwei Plattformen

Unten sehen Sie denselben Screen einer erfundenen Haushaltsbuch-App. Links steht die iOS-Version, rechts die Android-Version. Auf dem Smartphone stehen beide untereinander.

Drücken Sie "Unterschiede zeigen". Dasselbe Element bekommt auf beiden Screens dieselbe Nummer, und darunter öffnet sich die Erklärung zu jedem Unterschied.

Navigation: Tab-Leiste und Navigationsleiste

Auf beiden Plattformen stehen die Hauptbereiche unten auf dem Bildschirm. Namen und Regeln unterscheiden sich.

Apple möchte, dass Sie die Tab-Leiste für Navigation nutzen, nicht für Aktionen. Wollen Sie etwas mit dem Inhalt auf dem Screen tun, empfehlen die HIG die Symbolleiste. Laut HIG schwebt die Tab-Leiste unter iOS unten auf dem Bildschirm über dem Inhalt.

Apple nennt für das iPhone keine feste Zahl an Tabs. Die HIG schreiben nur, dass die Navigation mit wenigen Tabs meist leichter ist. Sie raten auch von einem "Mehr"-Tab (More) ab, der überzählige Tabs sammelt.

In Material 3 heißt das Gegenstück Navigationsleiste (Navigation Bar). M3 schreibt, dass diese Leiste Zugang zu drei bis fünf Zielen gibt.

Gibt es weniger als drei Ziele, empfiehlt M3 Tabs. Gibt es mehr als fünf, sollen Sie die Navigationsleiste gar nicht nutzen.

Beide Leitfäden wollen kurze Beschriftungen. Die HIG sagen nach Möglichkeit ein Wort, M3 sagt ein bis zwei Wörter. Laut M3 wird die Beschriftung weder entfernt noch abgeschnitten noch verkleinert, damit sie passt.

Deutsche Beschriftungen werden schnell lang, denken Sie an "Einstellungen" oder "Benachrichtigungen". Diese Regel zwingt Sie, ein kürzeres Wort zu suchen. Im Demo stehen deshalb Start, Budget, Ziele und Profil.

Hamburger-Menü und Navigation Drawer

In Android-Apps sehen Sie oft die Navigationsschublade (Navigation Drawer), die sich von links öffnet. Die aktuelle Drawer-Seite von M3 schreibt, dass die Schublade mit dem Update M3 Expressive nicht mehr empfohlen wird. Stattdessen wird die erweiterte Navigationsschiene (Expanded Navigation Rail) empfohlen.

Die Seite zur Navigationsleiste datiert dieses Update auf Mai 2025. Laut derselben Seite hat die bisherige Navigationsleiste einer kürzeren, flexiblen Leiste Platz gemacht.

In Material 2 hieß diese Leiste "Bottom Navigation". In M3 heißt sie Navigation Bar. Denken Sie daran, wenn Sie sich ein älteres Android-Design ansehen.

Die allgemeinen Navigationsmuster beschreibe ich im Ratgeber zum App-Design. Hier sammle ich nur die Stellen, an denen sich die zwei Plattformen trennen.

Zurück-Verhalten: System-Zurück und Wischen vom Rand

Für mich liegt hier der wichtigste Unterschied zwischen den Plattformen. Um zurückzugehen, denken Nutzer nicht nach, die Hand macht die gewohnte Bewegung.

Unter iOS ist Zurück ein Button. Die Seite zur Symbolleiste in den HIG sagt, Sie sollen den Standard-Zurück-Button nutzen und nicht "Zurück" darauf schreiben. Dieser Button bringt Nutzer in der Informationshierarchie einen Schritt zurück.

Das Wischen vom Rand ist eine Abkürzung dafür. Laut der Gesten-Seite der HIG bieten viele Apps eine Abkürzungsgeste wie das Wischen vom Rand des Bildschirms an und behalten den Zurück-Button bei. Die Geste ersetzt den Button also nicht.

Unter Android ist Zurück eine Systemgeste. Laut der Gesten-Seite von M3 wischen Nutzer bei bestimmten Komponenten nach links oder rechts, um zum vorherigen Ziel zurückzukehren. M3 nennt diese Geste vorausschauendes Zurück (Predictive Back).

Nutzer können sich entscheiden, bevor sie das Wischen beenden. Entweder wechseln sie zur vorherigen Ansicht oder sie bleiben auf dem aktuellen Screen. Der linke Button in der oberen App-Leiste ist in M3 entweder ein Zurück-Pfeil oder ein Menüsymbol.

Meine praktische Folgerung: Unter Android lege ich keine eigene horizontale Wischgeste an die Bildschirmränder. Auch für iOS raten die HIG von eigenen Gesten ab, die mit Gesten für die Systemoberfläche kollidieren.

Hauptaktion: FAB und Symbolleiste

Das bekannteste Element von Android ist der schwebende Aktionsbutton (Floating Action Button, FAB). Laut M3 ist der FAB für die wichtigste Aktion auf einem Screen gedacht und steht vor allen anderen Inhalten.

M3 gibt für den FAB einige klare Regeln vor:

• Auf einem Screen gibt es nicht mehrere FABs.
• Für kleine oder zerstörerische Aktionen wie Archivieren, Löschen, Warnungen oder Fehler wird er nicht genutzt.
• Auf Bildschirmen in Smartphone-Größe steht er meist unten rechts, über der Navigationsleiste.
• Für die meisten Fälle wird der mittlere FAB empfohlen. Der kleine FAB wird nicht mehr empfohlen.

In den HIG-Seiten, die ich geöffnet habe, gibt es keine Komponente, die dem FAB entspricht. Laut der Seite zur Symbolleiste kommt eine einzelne Hauptaktion wie "Fertig" oder "Senden" an die hintere (rechte) Seite der Symbolleiste.

Wenn ein Android-Design nach iOS wandert, bleibt der runde Button unten rechts oft einfach stehen. Das ist ein Fehler, den ich häufig sehe. Für mich wirkt er auf einem iOS-Screen, als hätte ihn jemand aus Android vergessen. Natürlicher ist es, die Hauptaktion nach oben rechts oder in den Inhalt zu verlegen.

Warum die untere rechte Ecke nah am Daumen liegt, erkläre ich auf der Seite zur Daumenzone.

Hinweis und Dialog

Beide Leitfäden wollen, dass Sie Dialoge sparsam einsetzen. Sie unterscheiden sich bei Zahl und Reihenfolge der Buttons.

Laut HIG hat ein Hinweis (Alert) einen Titel, einen optionalen Text und höchstens drei Buttons. Der Titel soll nicht über zwei Zeilen gehen, die Button-Bezeichnung soll ein oder zwei Wörter lang sein.

Stehen die Buttons nebeneinander, steht Abbrechen meist vorne (links). Stehen sie untereinander, rutscht Abbrechen meist nach unten.

Apple sagt außerdem, dass Sie für häufige Aktionen, die sich rückgängig machen lassen, keinen Hinweis zeigen sollen. Auch ein Hinweis beim Start der App wird nicht empfohlen.

In M3 hat ein Dialog höchstens zwei Aktionen. Die Buttons sammeln sich am rechten Rand des Dialogs, der bestätigende Button steht dem Rand am nächsten. Eine schließende Aktion wie Abbrechen kommt links davon.

M3 rät im Titel auch von vagen Fragen wie "Sind Sie sicher?" ab. Der Titel "Ausgabe löschen?" im Demo sagt deshalb klar, was passieren wird.

Für Informationen mit niedriger oder mittlerer Priorität empfiehlt M3 statt eines Dialogs eine Snackbar. Wann ein Dialog nötig ist, beschreibe ich auf der Seite zum Modal- und Pop-up-Muster.

Typografie: SF Pro und Roboto

Laut HIG ist SF Pro die Systemschrift von iOS und iPadOS. Apple gibt auf diesen Plattformen 17 pt als Standardschriftgröße und 11 pt als kleinste Größe an.

Unter iOS liegt die Schriftgröße in der Hand der Nutzer. Mit der Systemfunktion Dynamic Type kann man die Schrift auf dem Gerät vergrößern oder verkleinern. Die HIG schreiben, dass Sie diese Unterstützung bekommen, wenn Sie die Systemschrift mit Textstilen nutzen.

Laut M3 ist Roboto die Standardschrift von Android und der M3-Typskala. Roboto enthält mehr als 3.300 Glyphen. Für Sprachen, die Roboto nicht abdeckt, gibt es mit Noto Sans eine Schriftfamilie für alle modernen und historischen Sprachen.

Sie können auf beiden Plattformen auch eine einzige Markenschrift nutzen. Bei so einer Wahl teste ich zuerst die deutschen Sonderzeichen: ä, ö, ü, ß und das große ẞ. Danach prüfe ich in der größten Schriftgröße, ob lange Komposita wie "Benachrichtigungseinstellungen" den Screen sprengen.

Touch-Ziel: 44 pt und 48 dp

Hier ist der Unterschied klein. Die HIG geben unter iOS 44 × 44 pt als Standardgröße für Bedienelemente an, 28 × 28 pt als kleinste Größe. M3 empfiehlt Touch-Ziele von mindestens 48 × 48 dp und schreibt, dass das etwa 9 mm entspricht.

Dieselbe M3-Seite merkt an, dass iOS 44 empfiehlt. Die Einheiten sind verschieden, aber beide Leitfäden sprechen über denselben Finger.

Die Maße im Detail und die WCAG-Seite erkläre ich auf der Seite zur Touch-Fläche, hier wiederhole ich sie nicht.

Berechtigungsabfragen

Unter iOS fragt ein Systemfenster nach einer Berechtigung wie Standort oder Mikrofon. In Ihrer Hand liegt, wann und mit welchem Satz die Berechtigung erfragt wird.

Die Datenschutz-Seite der HIG ist klar. Fragen Sie nach der Berechtigung, wenn Nutzer die Funktion, die sie braucht, tatsächlich nutzen. Fragen Sie nicht beim Start, außer die App funktioniert ohne diese Berechtigung gar nicht.

Apple gibt auch ein Beispiel für den Erklärungssatz im Berechtigungsfenster. Gewünscht ist ein kurzer, vollständiger Satz im Aktiv. Eine vage Begründung wie "Für ein besseres Erlebnis wird Zugriff auf das Mikrofon benötigt" zeigt Apple als schlechtes Beispiel.

Wenn Sie vor dem Systemfenster einen eigenen Screen zeigen, wollen die HIG dort einen einzigen Button. Er soll etwa "Weiter" heißen und das Systemfenster öffnen.

Schreiben Sie auf diesen Screen nicht "Erlauben". Apple wertet das als eine Form der Manipulation, weil Nutzer dann im Systemfenster womöglich unbeabsichtigt auf den Erlauben-Button tippen.

In den Material-3-Seiten, die ich geöffnet habe, habe ich keinen Abschnitt zu Berechtigungsabfragen gefunden. Unter Android wende ich dieselbe Regel zum Zeitpunkt an: Die Berechtigung wird in dem Moment erfragt, in dem sie gebraucht wird, mit einem Satz, der sagt, warum. Mehr dazu auf der Seite zu Berechtigungs- und Benachrichtigungsscreens.

Ein Design oder zwei?

Selbst wenn Sie beide Apps aus einer Codebasis bauen, rate ich davon ab, ein einziges Design auf beiden Plattformen unverändert zu nutzen.

Ich teile die Elemente auf dem Screen in zwei Gruppen. Wo die Marke sichtbar ist, darf es gemeinsam bleiben: Farben, Karten, Illustrationen, Inhalte. Wo die Hand aus Gewohnheit handelt, wird nach Plattform getrennt: Zurück, Hauptnavigation, Dialog-Buttons und Hauptaktion.

Der Grund ist einfach: Nutzer erwarten in Ihrer App, was sie in anderen Apps gelernt haben. Diese Idee heißt Jakobs Gesetz. iPhone-Nutzer haben die Zurück-Geste in anderen iOS-Apps gelernt und probieren sie auch bei Ihnen.

Barrierefreiheitseinstellungen wie Screenreader und Textvergrößerung teste ich ebenfalls auf beiden Geräten getrennt. Das behandle ich im Ratgeber zur Barrierefreiheit mobiler Apps.

Meine Notiz

Was ich oft sehe: Das Team zeichnet das Design mit den Gewohnheiten des eigenen Smartphones, die andere Plattform wird später "angepasst". Angepasst werden meist nur Farben und Icons, Zurück und Dialog-Buttons bleiben, wo sie waren.

Deshalb sehe ich mir bei einer App für zwei Plattformen zuerst eine Aufnahme desselben Ablaufs auf beiden Geräten nebeneinander an. Die fünf Punkte im Demo oben sind die ersten Zeilen meiner Checkliste.

Wenn Sie beide Plattformen gemeinsam gestalten und in Code bringen wollen, ist der Design & Ship Sprint genau dafür da. Er dauert 2 Wochen, Design und Code kommen zusammen in Ihr Repository.