Passgenaue Benutzeroberflächen für mobile Apps Cross-Platform-Entwicklung für Android und iOS
Anbieter zum Thema
Aus Entwicklersicht ist die Entwicklung für verschiedene Mobilgeräte nicht so einfach, schließlich unterscheiden sich Android und iOS unterscheiden in vielen Belangen. Cross-Plattform-Programmierung kann ein Ausweg sein.

Mobile Apps werden in immer mehr Bereichen eingesetzt. Sie erobern zunehmend auch das unternehmerische Umfeld (Mobile Enterprise Computing). Aus der privaten Nutzung sind sie schon lange nicht mehr wegzudenken. Aus Sicht der inhaltlichen Gestaltung, des Designs und der technischen Umsetzung gilt es dabei mehrere Herausforderungen zu meistern:
- Inhaltlich: Umfassende Use Cases brauchen einen durchdachten Ansatz, um die dazu notwendigen Elemente auf einer begrenzten Bildschirmfläche unterzubringen. Gerade bei Unternehmens Apps, können die Konzepte aus vorhandener Software nicht 1:1 auf die mobilen Devices kopiert werden. Es gibt auf dem Smartphone weder eine Tastatur noch eine Maus.
- Design: Die Nutzergemeinde ist „gespalten“. Eine App muss i.d.R. Android und iOS unterstützen und idealerweise auch auf das jeweilige System angepasst sein. Ein Vermischen oder ein neutrales Design sind zwar technisch möglich, aber meist keine gute Lösung: Hinzu kommt noch oft die Anforderung das eine App zusätzlich die möglichen Vorgaben eines Corporate Designs des Unternehmens berücksichtigen muss.
- Technisch: Zwei Apps bedeuten nahezu einen doppelten Aufwand bei der Entwicklung. Der Quellcode kann nicht geteilt werden, denn zu technisch unterschiedlich sind Android und iOS. Beginnend bei der Programmiersprache bis hin zur Umsetzung des User Interfaces oder bei der Arbeit mit den Sensoren, muss vollständig anders vorgegangen werden.
Aus dieser Aufzählung ergibt sich, dass Entwickler die Unterschiede zwischen Android und iOS in den Griff bekommen müssen. Wichtige Merkmale der beiden Systeme aus technischer Perspektive sind in der folgenden Tabelle dargestellt.
Merkmal | Android | iOS |
---|---|---|
Lizenz | Open Source | Closed, mit Open Source Komponenten |
konfigurierbar | umfassend | eingeschränkt |
Dateitransfer | USB-Port, Android File Transfer Desktop App; Fotos auch ohne App | Verwendet iTunes, Fotos auch über USB ohne App |
Verfügbarkeit | Smartphone und Tablets unterschiedlichster Hersteller | iPod Touch, iPhone, iPad, Apple TV |
Calls and Messaging | Google Messaging, 3rd party Apps wie Facebook Messenger, WhatsApp, Google Duo, Discord und Skype | iMessage, FaceTime, 3rd party Apps wie Google Hangouts, Facebook Messenger, WhatsApp und Google Duo. |
Internet Browser | Google Chrome, andere Browser sind verfügbar; jeder kann als Standardbrowser definiert werden | Safari, andere Browser sind verfügbar; aber können nicht als Standardbrowser definiert werden |
App Store | Google Play Store | Apple App Store |
Sprachsteuerung | Google Assistant | Siri |
Maps | Google Maps | Apple Maps; Google Maps ist verfügbar, aber nicht als Standard |
Open Source | Kernel, UI und einige Apps | Kernel ist nicht Open Source |
Programmiersprache | Java, Kotlin | Objective-C, Swift |
Entwicklungsumgebung | Android Studio | XCode |
Testen | Android Emulator | iOS-Simulator |
Betriebssystem für Entwicklung | Windows, macOS, Linux | macOS |
Cloud Service | native Integration von Google Drive Storage | native Integration von iCloud |
Cross Plattform Programmierung als Ausweg
Einen Ausweg aus dem Dilemma, zwei einzelne Apps für Android und iOS zu erstellen, ist die Cross-Plattform-Programmierung. Mit diesem Ansatz verfolgt man das Ziel, simultan eine App für Android und iOS gleichzeitig aus einem Quellcode zu erstellen. Mit anderen Worten: „Write once, run anywhere“.
Die Apps sollen sich möglichst gut in Android und iOS einpassen, d.h. sie dürfen dabei nicht als „Fremdkörper“ wirken. Es gibt inzwischen (erfreulicherweise) eine große Anzahl von Vorgehensweisen der Cross-Plattform-Entwicklung. In der Tabelle unten sind aktuell verfügbare Ansätze mit wichtigen Eigenschaften zusammengetragen.
Ansatz | Programmiersprache | User Interface-Definition | Werkzeuge | Bemerkungen |
---|---|---|---|---|
Xamarin | C# | nativ oder deklaratorisch mit Hilfe von XAML | Visual Studio unter Windows oder macOS | natives UI für Android und iOS oder gemeinsame UI-Definition mit Xamarin Forms |
RAD Studio | Delphi (Object Pascal) | mittels UI-Designer; Plattformunabhängigkeit wird über Grafikframework FireMonkey erreicht | RAD Studio unter Microsoft Windows | komponentenbasierter Ansatz für das UI und nicht visuelle Komponenten für andere Aufgaben; geräteübergreifende Entwicklung für Desktop und Mobile |
NativeScript | TypeScript (JavaScript) | deklarativ mittels JSX (JavaScript Syntax Extension) | Command Line Interface, beliebiger Editor, zum Beispiel Visual Studio Code | weitere Frameworks (Angular, Vue.js) können eingebunden werden |
React Native | TypeScript (JavaScript) | deklarativ mittels JSX | Command Line Interface, beliebiger Editor, zum Beispiel Visual Studio Code | Erweiterung zur Web-Bibliothek React |
Tabris.js | TypeScript (JavaScript), kein HTML und CSS notwendig | deklaratorisch über JSX | Command Line Interface, beliebiger Editor, zum Beispiel Visual Studio Code | Möglichkeit des Online-Build aus GitHub-Repository oder über das Command Line Interface; Hardwareinteraktion über Cordova Plugins |
Flutter | Dart | deklaratorisch im Quellcode | Android Studio, IntelliJ IDEA | UI-Komponenten werden über die Rendering-Engine namens Skia gezeichnet |
Qt | C++ | erfolgt mit QML Qt Meta-Object Language) deklarative | beliebiger Editor, Qt Creator (UI) | geräteübergreifende Entwicklung für Desktop und Mobile |
Ein „ideales“ Vorgehen gibt es bei der plattformübergreifenden Entwicklung nicht. Jeder dieser Ansätze bietet Vor- und Nachteile. Dabei können wir feststellen, dass eine Reihe von Ansätzen auf den Werkzeugen, Programmiersprachen sowie Ressourcen, d.h. Bibliotheken und Frameworks, der Web-Entwicklung basieren.
Dazu zählen zum Beispiel NativeScript und React Native. Andere Ansätze, zum Beispiel RAD Studio oder Xamarin sind eher an die Vorgehensweise der Entwicklung von klassischen Desktop-Applikationen angelehnt. Hier hat der Entwickler die Wahl.
User-Interface-Gestaltung
Sowohl das Design von iOS- als auch von Android-Apps hat seinen Ursprung im Flat-Design. Dieses impliziert die Verwendung von zweidimensionalen Elementen und hellen Farben. Android-Geräte basieren in erster Linie auf Material Design, während Apple den Human-Interface-Richtlinien folgt.
Einen ersten größeren Unterschied gibt es bei der Navigation. In Android gibt es eine Navigationsleiste am unteren Rand, bestehend aus drei Tasten (je nach Gerät entweder physisch oder digital), welche als Rück-, Home- und als Aufruf der offenen Apps dient. iOS geht einen anderen Weg. Wenn ein Benutzer eine App verlassen möchte, drückt er einfach die Home-Taste oder wischt von unten nach oben, um eine App in den Hintergrundmodus zu versetzen. Es gibt keinen universellen Zurück-Knopf. Der größte Teil der Navigation im iOS-System erfolgt mittels Wischgesten.
Wenn es um die Navigation durch Anwendungen geht, ist das Grundelement in Android das Drawer-Menu. Typisch ist auch die Verwendung von Registerkarten. Für iOS befindet sich diese normalerweise am unteren Bildschirmrand, mit der Benutzer zwischen mehreren Bildschirmen wechseln können. Die Rückwärtsnavigation erfolgt mit einem Zurück-Button in der oberen linken Ecke des Bildschirms oder durch einfaches Wischen von links nach rechts.
Die grundsätzliche Funktion von Buttons zum Auslösen von Aktionen ist dagegen identisch, lediglich das Design ist unterschiedlich. Sowohl iOS als auch Android empfehlen die Verwendung ihrer Systemschriftarten. Android verwendet die Roboto-Schriftart und iOS San Francisco. Die Größe des Textes ist ähnlich, aber das Materialdesign verwendet einen größeren Unterschied in der Schriftgröße innerhalb des Layouts und iOS verwendet Fettdruck für die Darstellung von Texthierarchien.
Auch das Design und die Handhabung einiger Standard View-Elemente, wie für die Texteingabe, die Auswahl von Datum oder Uhrzeit oder die Listenauswahl unterscheiden sich zwischen den Systemen. Es ist nicht sinnvoll, das Aussehen dieser Elemente in der eigenen App über Plattformgrenzen hinweg anzupassen. Der Benutzer hat seine Gewohnheit, denn er arbeitet regelmäßig mit Android oder iOS und erwartet eine für ihn vertraute Benutzerführung. Verändert man diese, fühlt sich das für den Nutzer ungewöhnlich und im schlechtesten Fall sogar falsch an.
Die Liste der Unterschiede ist umfangreich und zeigt, dass sich beide Systeme nicht nur technisch, sondern auch in Fragen des Designs erheblich unterscheiden. Einen Fehler sollte man nicht begehen: Eine App 1:1 von einem System auf ein anderes zu kopieren. Hier fühlt sich mindestens eine Nutzergemeinschaft nicht wohl. Maßgebend sind für Android die Material Design Guidelines und für Apple die Human Interface Guidelines. Man sollte diese immer wieder bei Fragen des Designs zu Rate ziehen.
Die Praxis der Cross-Plattform-Programmierung
Mit moderner Cross-Plattform-Entwicklung kann man die Unterschiede zwischen den Systemen weitgehend automatisiert in den Griff bekommen. Mittels eines Ausschnitts der Gestaltung des User Interfaces soll die Vorgehensweise ansatzweise demonstriert werden.
Einen Ansatzpunkt in Form eines Beispiels für die App-Navigation mit Hilfe von Tabs (Registerkarten) ist in einem Blogbeitrag von Embarcadero beschrieben. Mit Hilfe des grafischen Designers und der Entwicklungsumgebung RAD Studio wird das User Interface – in diesem Fall die App Navigation – in Form einer Tab-Navigation zunächst plattformneutral erstellt.
Dabei muss nicht darauf geachtet werden, wie dieses User Interface Control später auf der Zielplattform aussehen wird. Es geht nur um die Festlegung der Funktionalität. Dazu sind folgende Angaben notwendig:
- Eine Beschriftung – für iOS und Android
- vordefinierte Symbole – nur für iOS
- benutzerdefinierte Symbole – für iOS und Android.
Die Registerkarten werden als Elemente hinzugefügt und mit den entsprechenden Funktionen verknüpft. Dabei muss weiterhin keine Rücksicht auf die spezifische Plattform genommen werden. Danach kann festgelegt werden, wie das finale Layout aussehen soll. Folgende Optionen zur Platzierung der Registerkarten (Navigation) stehen in diesem Fall zur Auswahl:
- Top: stets oben
- Button: stets unten
- Dots: keine Registerkarten, es erfolgt lediglich die Anzeige von Punkten
- Plattform: Android oben, iOS unten
Die Varianten Top und Button „verstoßen“ stets gegen eine der Richtlinien von iOS und Android. Die Variante Dots ist von beiden Plattformen losgelöst und die Variante Plattform berücksichtigt die Vorgaben von iOS und Android automatisch. Man hat also die Wahl die App über Systemgrenzen hinweg zu gestalten oder sich an die spezifischen Vorgaben zu halten.
Wichtig: Die Cross Plattform-Programmierung abstrahiert von der jeweiligen technischen Umsetzung, indem sie die Programmierung auf die Ebene der Use Cases hebt. Aus der Entwicklungsumgebung heraus werden in diesem Fall native Apps erstellt. Für die Anwender bieten sie den gleichen Komfort, wie eine nativ programmierte App, d.h. sie passt sich nahtlos in das System ein. Für den Entwickler vereinfacht Sie den Prozess der Programmierung erheblich, da Plattformbesonderheiten nur noch am Rande eine Rolle spielen.
Fazit
Moderne Cross Plattform Ansätze unterstützen den Entwickler dabei, die Unterschiede zwischen Android und iOS in den Griff zu bekommen. Das User Interface kann dabei neutral konzipiert werden. Idealerweise erfolgt die Anpassung an das System dann weitgehend automatisch und man kann sich auf die Use Cases statt um die Einhaltung der Design-Richtlinien kümmern.
* Elena Bochkor beschäftigt sich mit Fragen rund um die Gestaltung von Webseiten und Benutzeroberflächen für Apps der mobilen Plattformen. Dr. Veikko Krypczyk ist begeisterter Entwickler und Fachautor. Weitere Informationen zu diesen und anderen Themen der IT finden Sie unter Larinet.com. Folgen Sie uns auf Instagram unter larinetcommunication.
(ID:47167331)