Jonathan | 23.03.2021

Technologien mobiler Anwendungen - Native Apps

Mobile > Technologien mobiler Anwendungen - Native Apps

Native Apps sind die erste Technologie meiner Blogreihe, die ich Ihnen genauer vorstellen möchte. Bevor Sie diesen Artikel lesen, sollten Sie unbedingt die Projektvorstellung durchgehen. In diesem Artikel soll es um Vor- und Nachteile, Risiken und Abhängigkeiten bei der Entwicklung nativer Anwendungen gehen. 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.

Blogreihe

Hier finden Sie die Auflistung der einzelnen Blogartikel die zur Blogreihe gehören. Diese Agenda wird mit jedem neu veröffentlichtem Artikel erweitert.

  1. Projektvorstellung

  2. Native Apps

  3. Native Apps mit nicht-nativen Framework

  4. Cross Compile Frameworks

  5. Progressive Web App

  6. Hybrid Apps

  7. Technischer Vergleich der Technologien

  8. Wirtschaftlicher Vergleich der Technologien

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

Native Apps zeichnen sich besonders durch Performance aus. Sie sind im Vergleich zu anderen Technologien schneller, da sie auf dem Gerät in 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 native Apps alle den gleichen Look & Feel haben. 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, auf dem Endgerät des Nutzers gespeichert. Dadurch sind die Apps auch offline funktionsfähig, da zur Darstellung der Oberfläche 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 entstehen 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.

Neben der Verpflichtung zur Nutzung der integrierten Zahlungssysteme, behalten die App Stores auch Teile der Einnahmen für sich. Bei Einmal-Käufen sind das sowohl bei Apple als auch bei Google 30%. 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 Updates geht.

Der größte Nachteil bei der nativen Entwicklung ist, dass eine Anwendung immer nur auf einer Plattform funktioniert. Für mehrere Plattformen schreibt man getrennte Anwendungen. 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. Im schlimmsten Fall entwickelt man dann statt einem Produkt für mehrere Plattformen sogar verschiedene Produkte. Auf der anderen Seite bietet die getrennte Entwicklung aber auch die Möglichkeit, die Nutzeroberfläche plattformspezifischer zu gestalten.

Risiken und Abhängigkeiten

Die Risiken der nativen Entwicklung liegen vor allem bei dem Festlegen auf eine Plattform, bzw. das Entwickeln von 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 auch eine 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 der 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 große Teile der Anwendung kaputt gehen können.

Technologien und Markt Know-how

Die Technologien zur Entwicklung einer nativen App hängen komplett von der Zielplattform ab. Für die iOS Entwicklung benutzt die Programmiersprachen Swift oder Objective-C, wobei Swift die neuere Programmiersprache ist. Bei der Entwicklung für Android stehen die Sprachen Java und Kotlin zur Auswahl. Swift ist eine von Apple selbst entwickelte Programmiersprache, welche die bevorzugte Sprache für iOS ist. 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.

Aus dem Stack Overflow Developer Survey 2020 geht 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 benutzen nur ein Fünftel der Mobile Developer. Bei der Frage nach dem Interesse mit der Sprache weiterzuentwickeln, liegen Kotlin und Swift mit ca. 60% unter den Top 10. Auch Java liegt mit etwa 44% auch im Mittelfeld. Objective-C liegt in dieser Statistik mit nur ca. 20% weit hinter den anderen Sprachen, was zeigt, dass nur vergleichsweise wenige Entwickler weiterhin mit Objective-C entwickeln wollen. Bei der Umfrage von JetBrains gab ungefähr ein Drittel an, für mobile Systeme zu entwickeln. Davon gaben 17% an mit Kotlin zu programmieren und nur circa 9% nutzten Swift, lediglich 4% nutzen Objective-C. Bei einem Ranking nach dem Interesse, die Sprache weiter zu nutzen liegen Kotlin und Swift mit ca. 60% unter den Top 10. Auch Java liegt mit etwa 44% auch im Mittelfeld. Objective-C liegt in dieser Statistik mit nur ca. 20% weit hinter den anderen Sprachen.

Betrachtet man die 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. Java ließ sich bei diesem Portal nicht nach „mobile“ Filtern. In den Job-Listings auf Stack Overflow lässt 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.

Aus den Umfragen und den Suchergebnissen geht hervor, dass Swift und Kotlin sehr beliebt und nachgefragt sind. Java genießt nicht so eine große Beliebtheit wie Swift und Kotlin, ist allerdings noch bei weitem beliebter als Objective-C. Anhand des großen Interesses und der vielen Job-Listings lässt ein gutes Entwickler-Know-how am Markt erkennen.

Entwicklungsaufwand und -kosten

Sowohl der Entwicklungsaufwand als auch die Kosten sind immer abhängig von den Features, die die App benötigt. Aus diesem Grund lassen sich beide Faktoren nur allgemein und relativ betrachten. Im Folgenden wird deshalb davon ausgegangen, dass eine mittelgroße App mit Standard Features wie z.B. der Standorterkennung oder der Kamera entwickelt wird. Die Kosten einer App sind weniger abhängig von den eigentlichen Features, sondern viel mehr von der Entwicklungszeit an sich.

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 Entwicklergehälter liegen für Swift und Kotlin bei ca. $90k im Jahr.

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 seitens des Studenten nicht.

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


AnforderungErfülltAnmerkung
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.

Headshot of Jonathan Zbick
Jonathan (Dualer Student)

... ist dualer Student für IT- und Softwaresysteme am Standort Dortmund. Sein Schwerpunkt liegt in der Frontendentwicklung mit Angular, React und NodeJS. Stimmige Nutzungsabläufe und gute Usability si... mehr anzeigen

Standort Hannover

newcubator GmbH
Bödekerstraße 22
30161 Hannover

Standort Dortmund

newcubator GmbH
Westenhellweg 85-89
44137 Dortmund