Die erste Technologie, die ich Ihnen in meiner Blogreihe vorstelle, sind die nativen Apps. Bevor Sie diesen Artikel lesen, sollten Sie unbedingt die Projektvorstellung durchgehen.
In diesem Blogbeitrag geht es um Vor- und Nachteile, Risiken und Abhängigkeiten bei der Entwicklung nativer Anwendungen. Zudem schauen wir uns an, welche verschiedenen Technologien es gibt, um native Anwendung zu entwickeln und wie gut das Know-How der einzelnen Technologien am Markt ist. Anschießend betrachten wir noch die Entwicklungskosten und den Entwicklungsaufwand, bevor wir uns zum Schluss noch die Ergebnisse der Beispiel-App anschauen.
Die Blogreihe „Technologien mobiler Anwendungen"
Hier finden Sie die Auflistung der einzelnen Blogartikel dieser Blogreihe:
Native Apps
Wirtschaftlicher Vergleich der Technologien
Überblick: Native Apps
Eine native App zeichnet sich dadurch aus, dass sie für genau ein Betriebssystem entwickelt wurde. Sie wird in einer systemspezifischen Sprache geschrieben und direkt in den vom Betriebssystem verwendeten Maschinencode kompiliert. Eine native App bietet die Möglichkeit auf die Systemfunktionen zuzugreifen.
Das bedeutet, dass man mit einer nativen App ohne Umwege direkt Features wie die Kamera, das Mikrofon oder sonstige Sensoren nutzen kann. Typischerweise werden native Apps im herstellerspezifischen App Store für den Endnutzer bereitgestellt. Das ist für iOS Geräte der Apple App Store und für Android Geräte häufig der Google Play Store.
Vor- und Nachteile von nativen Apps
Native Apps zeichnen sich besonders durch ihre Performance aus. Sie sind im Vergleich zu anderen Technologien schneller, da sie auf dem jeweiligen Gerät im richtigen Maschinencode vorliegen. Die UI-Komponenten von nativen Apps sind vorgefertigte Komponenten des Betriebssystems, wodurch diese nicht extra durch eine Zwischenschicht gezeichnet werden müssen.
Diese Eigenschaft führt auch zu dem Vorteil, dass bei der Entwicklung einfacher ist den Look & Feel der Zielplattform umzusetzen. Look & Feel beschreibt das Aussehen einer Anwendung und das Nutzungsgefühl, also wie sich die einzelnen UI Komponenten bei der Nutzung anfühlen.
Native Apps werden, wie auch alle anderen Technologien, direkt auf dem jeweiligem Endgerät gespeichert. Dadurch sind die Apps auch offline funktionsfähig, da zur Darstellung der Oberfläche in der Regel nichts aus dem Internet heruntergeladen werden muss. Die Speicherung einer App auf dem Endgerät nutzt allerdings auch Speicherplatz, wodurch je nach Anwendung schnell sehr viel Speicherplatz verbraucht werden kann.
Durch die Bereitstellung der App über den App Store bei iOS-Apps oder auf Google Play bei Android-Apps entstehen leider auch einige Vor– und Nachteile.
Mit einer App in einem App Store hat man die Möglichkeit das integrierte Zahlungssystem zu nutzen, um beispielsweise In-App Käufe zu ermöglichen, ohne einen weiteren Anbieter nutzen zu müssen. Allerdings ist es bei dem Apple App Store und dem Google Play Store sogar der Fall, dass die Verwendung anderer Zahlungssysteme nicht erlaubt ist, sodass man die Zahlungssysteme von Google bzw. Apple nutzen muss.
Anmerkung: Seit 2024 sind die App Stores, im Zuge des Digital Markets Act, dazu verpflichtet, die Benutzung von Drittanbieter Zahlungsmethoden zu erlauben.
Zudem suchen die Meisten Smartphone Nutzer nach neuen Apps in dem jeweiligen App Store, dadurch ist eine App im App Store näher an den Nutzern und wird besser entdeckt. Nachteile, die durch einen App Store entstehen, sind eng mit dem Download verbunden.
Eine App, die über einen App Store verfügbar gemacht wird, muss vollständig gedownloadet werden. Das bedeutet auch, dass Nutzer bei jedem Update der Anwendung, diese wieder über den App Store herunterladen müssen. Das kann gegebenenfalls auch zu einem Sicherheitsrisiko führen, wenn es um sicherheitsrelevante und damit zeitkritische Updates geht.
Der größte Nachteil bei der nativen Entwicklung ist, dass eine Anwendung immer nur auf einer Plattform funktioniert.
Für mehrere Plattformen müssen einzelne Anwendungen entwickelt werden. Dadurch kann es dazu kommen, dass man die Anwendungen auseinanderentwickelt, da eventuell Features für die eine Plattform umsetzbar sind, aber für die andere nicht. Auch steigen die Kosten durch die Mehrfachentwicklung massiv an.
Im schlimmsten Fall entwickelt man dann statt einem Produkt für mehrere Plattformen sogar verschiedene Produkte für jeweils eine einzige Plattform. Auf der anderen Seite bietet die getrennte Entwicklung aber auch die Möglichkeit, die Nutzeroberfläche plattformspezifischer zu gestalten.
Risiken und Abhängigkeiten von nativen Apps
Die Risiken der nativen Entwicklung liegen vor allem bei dem Festlegen auf eine Plattform, bzw. dem Entwickeln von zwei verschiedenen Anwendungen für die beiden Betriebssysteme. Durch das Entwickeln für eine Plattform macht man sich komplett abhängig von dieser. Bei der nativen Entwicklung besteht daher eine recht starke Abhängigkeit zu den Herstellern der Geräte und der Betriebssysteme.
Die Technologien zur nativen Entwicklung werden durch die Betriebssystemhersteller vorgegeben. Da es vorkommen kann, dass sich die Hauptprogrammiersprache für ein Betriebssystem ändert, macht man sich auch in dieser Hinsicht von den Betriebssystemen abhängig. Allerdings kommt dies eher selten bis nie vor.
Darüber hinaus kann es sein, dass die Programmiersprachen nicht hundertprozentig backwards-kompatibel sind. Das bedeutet, dass Features von alten Versionen in neueren Versionen nicht mehr funktionieren, wodurch der Wartungsaufwand steigt.
Wenn man Third-Party-Frameworks nutzt, kann es auch passieren, dass diese Frameworks mit neueren Versionen nicht mehr kompatibel sind, wodurch Teile der Anwendung nicht mehr funktionieren würden.
Technologien und Markt Know-how
Die Technologien zur Entwicklung einer nativen App hängen komplett von der Zielplattform ab.
Für die iOS Entwicklung werden die Programmiersprachen Swift oder Objective-C benutzt, wobei Swift die neuere und auch empfohlene Programmiersprache ist. Swift ist eine von Apple selbst entwickelte Programmiersprache, welche die bevorzugte Sprache für iOS ist.
Für die Android Entwicklung stehen die Sprachen Java und Kotlin zur Auswahl. Kotlin ist eine Java-ähnliche Programmiersprache, welche von JetBrains entwickelt wurde und direkt in Bytecode für die Java Virtual Machine oder auch Maschinencode übersetzt werden kann. Kotlin wird seit 2017 offiziell von Google unterstützt und gilt seit 2019 als die bevorzugte Sprache, um für Android zu entwickeln.
Bei den im Folgenden behandelten Statistiken handelt es sich um das Stack Overflow Developer Survey 2020, welches von der Internetplattform Stack Overflow durchgeführt wurde und eine Umfrage des IDE-Herstellers JetBrains. Bei diesen Umfragen wird bei Java nicht unterschieden, ob für Android oder eine andere Plattform entwickelt wurde, weshalb der Fokus im Folgenden auf den Sprachen Swift, Objective-C und Kotlin liegt.
Verbreitung der Programmiersprachen der nativen App Entwicklung
Bei der Wahl der Programmiersprachen für App-Projekte hat sich in den letzen vier Jahren sehr viel getan. Aus dem Stack Overflow Developer Survey 2020 ging hervor:
dass sich ein Fünftel der Befragten selbst als Mobile Developer bezeichnen,
davon gaben circa 60% an Swift zu nutzen
und circa 63% Kotlin.
Objective-C hingegen benutzten nur ein Fünftel der Mobile Developer. Betrachtet man die damaligen Suchergebnisse auf Jobseiten für die Programmiersprachen, fällt auf, dass Kotlin und Swift bei Indeed jeweils zwischen 800 und 900 Ergebnissen lieferten und Objective-C nur circa 600 Ergebnisse. In den Job-Listings auf Stack Overflow ließ sich im Gegensatz dazu erkennen, dass Kotlin und Java jeweils fast doppelt so viele Suchergebnisse lieferten wie Swift und dass Objective-C mit nur knapp 50 Ergebnissen mit Abstand am wenigsten lieferte.
Swift und Kotlin waren also sehr beliebt und nachgefragt. Anhand des großen Interesses und der vielen Job-Listings ließ ein gutes Entwickler-Know-how am Markt erkennen.
Im Jahr 2024 hat sich der Markt für App-Entwickler verändert. Auf Indeed gibt es zum Zeitpunkt des Edits für Kotlin und Swift nur noch 400 - 600 Job-Listings und für Objective-C sogar nur 100. Stack Overflow bietet ihren Job-Listing Service inzwischen nicht mehr an.
Ebenfalls liegen Kotlin und Swift bei Stack Overflow inzwischen auf Platz 15 und Platz 20 der beliebtesten Programmiersprachen (Quelle: Stack Overflow Developer Survey 2024). Auch in der Statistik von JetBrains sind Kotlin und Swift nur noch auf den Plätzen 13 und 17 (Quelle: The State of Developer Ecosystem 2023). Diese Statistiken lassen einen Rücklauf in der Nachfrage an Entwicklern und dem Interesse an Kotlin und Swift ableiten. Vielleicht liegt diese Entwicklung auch an der immer weiter fortschreitenden Verbreitung von hybriden Apps und PWAs mit Webtechnologien. Auf diese gehe ich in weiteren Artikeln dieser Reihe ein.
Entwicklungsaufwand und Entwicklungskosten einer App
Sowohl der Entwicklungsaufwand als auch die Kosten einer App sind immer abhängig von der Komplexität der App-Features, der Plattform, dem UX-Design, Sicherheitsaspekten, der Nutzerverwaltung, der Größe Ihres Entwicklungsteams und vielen mehr. Aus diesem Grund lassen sich beide Faktoren nur allgemein und relativ betrachten.
Native Apps haben - wie zuvor bereits genannt - den großen Nachteil, dass für jede Plattform eine eigene App entwickelt werden muss. Das führt natürlich auch dazu, dass sich die Entwicklungszeit und -kosten im Vergleich zu anderen Technologien verdoppeln bzw. verdreifachen, sollte man für drei Plattformen entwickeln wollen.
Die Beispiel-App
Als Programmiersprache wurde für die Beispiel-App Kotlin gewählt, da die vorhandene Zielplattform ein Android Smartphone ist. Damit lässt sich sofort auch ein Nachteil der nativen Beispiel App erkennen, nämlich, dass sie nur auf Android funktioniert. Vorkenntnisse in der Entwicklung mit Kotlin gab es meinerseits nur wenige.
Innerhalb der Entwicklungszeit wurden alle Anforderungen erfüllt, wobei es keine großen Komplikationen gab. Für die Entwicklung wurden keine Third-Party-Libraries oder Frameworks verwendet. Die komplette Anwendung konnte mit Hilfe der nativen Android UI-Komponenten erstellt werden. Die Integration von dem Wecker-Ton war sehr einfach. Es wird der vom Nutzer ausgewählte Standard Wecker-Ton verwendet.
Hier nochmal der Erfüllungsgrad der einzelnen Features in einer Tabelle.
++: Feature ist vollständig umgesetzt
+-: Feature ist nur teilweise umgesetzt
--: Feature ist gar nicht umgesetzt
| Anforderung | Erfüllt | Anmerkung |
|---|---|---|
| Runde Progressbar | ++ | |
| Picker für die Zeit | ++ | Dialog mit 3 nativen NumberPickern, weil der native TimepIcker nicht mit Sekunden vorhanden ist |
| Play-Button | ++ | |
| Reset-Button | ++ | |
| Vibration | ++ | mit nativem RingtoneManager |
Wenn Sie die nächsten Artikel der Blogreihe „Technologien mobiler Anwendungen“ nicht verpassen wollen, dann folgen Sie newcubator auf den Social Media Kanälen und schauen Sie regelmäßig auf unserer Blogseite vorbei. Im nächsten Artikel schauen wir uns an, wie man native Apps mit einem nicht nativen Framework schreiben kann.
