Betrachtung verschiedener Methoden zur Entwicklung mobiler Apps mit Fokus auf Funktionsumfang und technischer Umsetzung
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
FH Aachen Fachbereich 9 Medizintechnik und Technomathematik Seminararbeit im Studiengang Scientific Programming Betrachtung verschiedener Methoden zur Entwicklung mobiler Apps mit Fokus auf Funktionsumfang und technischer Umsetzung Autor: Joel Otte, 3158603 Betreuer: Prof. Dr. rer. nat. Alexander Voß Paul Mangartz, M.Sc. Aachen, 05.01.2020
Abstract
Die Nutzung von Mobilgeräten hat mit der Zeit immer weiter zugenommen und
damit einhergehend ist auch die Relevanz mobiler Anwendungen gestiegen. Das
stellt viele Entwickler vor die Herausforderung zu entscheiden, welche der ver-
schiedenen Möglichkeiten, eine mobile App zu entwickeln, für ihren spezifischen
Anwendungsfall in Frage kommt.
In folgender Ausarbeitung werden die verschiedene Methoden für die Entwick-
lung mobiler Apps vorgestellt, wobei zwischen drei Entwicklungsansätzen unter-
schieden wird: Nativ, Hybrid und Cross-Platform. Bei der Betrachtung liegt der
Fokus jeweils auf Funktionsumfang und technischer Umsetzung der App. Zudem
werden die Plattformen iOS und Android tiefergehend behandelt, indem tech-
nische Konzepte erläutert werden und Einblick in den Entwicklungsprozess mit
xCode und Android Studio gegeben wird.
Neben der Darstellung und Bewertung verschiedener Entwicklungsansätze wird
im Rahmen dieser Seminararbeit das Ziel angestrebt, Bewertungskriterien zu
schaffen, mithilfe derer der Prozess vereinfacht wird, für ein bestimmtes App-
Projekt ein passendes technologisches Setup zu ermitteln.
III
Inhaltsverzeichnis
1 Einleitung ............................................................................................ 1
2 Native Apps ........................................................................................ 3
2.1 iOS .......................................................................................................... 5
2.1.1 Architektur .................................................................................. 6
2.1.2 Voraussetzungen ....................................................................... 7
2.1.3 Entwicklung mit xCode .............................................................. 8
2.1.4 Bewertung ................................................................................. 11
2.2 Android ............................................................................................... 13
2.2.1 Architektur ................................................................................ 14
2.2.2 Voraussetzungen ..................................................................... 16
2.2.3 Entwicklung mit Android Studio IDE ..................................... 16
2.2.4 Bewertung ................................................................................. 20
3 Hybride Apps ................................................................................... 21
4 Cross-Platform Apps ..................................................................... 23
5 Zusammenfassung und Fazit ..................................................... 25
6 Literaturverzeichnis ...................................................................... 27
7 Abbildungsverzeichnis ................................................................. 31
IV
1 Einleitung
Das erste Smartphone, welches als solches bezeichnet werden könnte, wurde
1994 von IBM1 herausgebracht und kam lediglich mit fest installierten Apps wie
unter anderem einem Kalender und einem Taschenrechner daher.[1] Mit Ein-
führung des BlackBerry 5810 von RIM2 im Jahr 2002 erlebte das Smartphone
eine kleine Revolution. Die Kombination aus innovativer Benutzeroberfläche, über
die diverse Anwendungen angesteuert werden konnten, und integriertem Mobil-
telefon erfreute sich insbesondere bei Geschäftskunden großer Beliebtheit.[2]
Der große Durchbruch des Smartphones kam jedoch erst im Jahr 2007, als Apple
das erste iPhone vorstellte. Ein Jahr später sollte eine neue Ära der mobilen App-
Entwicklung eingeläutet werden. Apple brachte den hauseigenen App Store her-
aus und Konkurrent Google schaffte das Pendant Android Market 3. Nach Ver-
öffentlichung der Software Development Kits (SDKs) hatten externe Entwickler
erstmals die Möglichkeit, native Apps für die Plattformen Android (Google) und
iOS (Apple) zu entwickeln. Das führte in den darauffolgenden Jahren zu einem
starken Wachstum der App-Branche. Während in Apples App Store anfänglich
noch rund fünfhundert Apps verfügbar waren, umfasst dieser mittlerweile mehr
als 1,8 Millionen Apps. Der Google Play Store kommt sogar auf fast 2,5 Milli-
onen Apps4.[3][4][5]
Mit der Zeit wurde mobilen Apps immer mehr Relevanz zugesprochen und es
entwickelte sich eine neue Produkt-Philosophie unter dem Paradigma „Mobile
First“. Hier steht die Kompatibilität einer Anwendung mit Mobilgeräten (Smart-
phones, Tablets, etc.) im Vordergrund. Der damalige Google CEO Eric Schmidt
beschrieb im Jahr 2010 die Denkweise des Unternehmens bezüglich Produkt-
entwicklung mit den Worten: „We understand that the new rule is mobile first“
und weiter „Mobile first in everything. Mobile first in terms of applications.“[6] Vier
Jahre später bestätigt Schmidt diesen Standpunkt, als er sagt „The trend has
been that mobile was winning. It’s now won.”[7]
____________________________
1
US-amerikanisches IT-Unternehmen („International Business Machines“)
2
Kanadischer Softwarehersteller (seit 2013 „BlackBerry”)
3
Seit 2012 „Google Play Store“
4
Stand: Oktober 2019
1
Ein Anstieg der Smartphone-Nutzer und Downloads mobiler Apps lässt sich zu-
dem zahlenmäßig belegen und untermauert die Bedeutsamkeit dieses Ansatzes.
Während in Deutschland im Jahr 2010 noch rund 14 Millionen Menschen ein
Smartphone besaßen, überstieg diese Zahl im Jahr 2016 bereits die 50-Millionen-
Marke. Weltweit betrachtet liegt die Anzahl der Smartphone-Besitzer bei 3,3 Mill-
iarden5. Das entspricht, gemessen an der Weltbevölkerung, einem Prozentsatz
von fast 43%. Was die Downloads mobiler Apps angeht, lässt sich ebenfalls ein
Zuwachs verzeichnen: Im Jahr 2016 wurden weltweit in den App Stores etwa 144
Milliarden Apps heruntergeladen. Die Zahl der Downloads betrug im Jahr 2018
bereits 194 Milliarden.[3]
Die obigen Ergebnisse lassen durchaus die Feststellung zu, dass die Relevanz
mobiler Endgeräte und Anwendungen in den letzten Jahren immer größer ge-
worden ist und sich dieser Trend vermutlich auch fortsetzen wird. Laut einer
Vorhersage des Marktforschungsunternehmens Gartner werden im Jahr 2022
bereits 70% aller Interaktionen mit Software auf Mobilgeräten stattfinden.[8]
Aufgrund dieser Beobachtungen wird der Entwicklung mobiler Apps eine große
Bedeutung zuteil. Aus diesem Grund sind jedoch auch die Möglichkeiten zur Um-
setzung vielfältiger geworden. Während mobile Anwendungen damals nur unter
Verwendung eines entsprechenden SDKs im App Store einer Plattform verfügbar
gemacht werden konnten, stehen heutzutage weitaus mehr Methoden zur Ver-
fügung, die unter anderem auf eine plattformunabhängige Entwicklung ausgelegt
sind. Der Markt bietet zudem eine Vielzahl an Tools und Frameworks, welche
diesen Ansatz fördern und die Entwicklung mobiler Apps erleichtern. Dadurch
stehen Entwickler heutzutage vor der großen Herausforderung, einen Ansatz zu
wählen, der für ihren spezifischen Anwendungsfall geeignet ist, wobei Kriterien
wie Aufwand, Kosten und Funktionsumfang der App berücksichtigt werden müs-
sen. Im Folgenden werden verschiedene Entwicklungsansätze für die Umsetzung
mobiler Apps vorgestellt. Es werden die grundlegenden Konzepte aller Ansätze
erläutert und die jeweiligen Vor- und Nachteile herausgearbeitet. Dabei liegt der
Fokus auf jenen Apps, die über einen App Store bereitgestellt werden können.
Auf reine Webanwendungen, die lediglich für Mobilgeräte optimiert wurden, wird
somit nicht näher eingegangen.
____________________________
5
Stand: November 2019
2
2 Native Apps
Native Apps bezeichnen jene Anwendungen, die für eine spezifische Plattform
unter Verwendung des jeweiligen Software Development Kits und in den dafür
vorgesehenen Programmiersprachen entwickelt werden. Das SDK eines Be-
triebssystems umfasst hierbei die notwendigen Werkzeuge für die Entwicklung.
In der Regel werden eine Entwicklungsumgebung und native Schnittstellen be-
reitgestellt. Letztere ermöglichen die Verwendung nativer Bedienelemente für
die grafische Oberfläche und den Zugriff auf verschiedene Systemfunktionen.
Eine native App für Apples Betriebssystem iOS wird beispielsweise in den Spra-
chen Objective-C oder Swift geschrieben, während xCode als Entwicklungs-
umgebung dient. Native Android-Apps werden hauptsächlich in Android Studio
IDE mit den Sprachen Java oder Kotlin umgesetzt.[9]
Aufgrund der Tatsache, dass hier für eine bestimmte Plattform entwickelt wird,
liegt es nahe, dass native Apps die beste Performance bieten. Die Programmier-
sprache und die verwendeten Bibliotheken sind optimal auf das System abge-
stimmt und bieten höchste Kompatibilität. Der Einsatz nativer Bedienelemente
sorgt zudem für ein gewohntes optisches Erscheinungsbild, da sie gewissen
„Style Guidelines“ folgen, die für das Betriebssystem festgelegt wurden. Das
könnte dem Anwender, der mit der Plattform vertraut ist, die Navigation durch
die App erleichtern und sich somit positiv auf die Usability1 auswirken. Des Wei-
teren ist der Entwickler durch die Anbindung an native Schnittstellen nahezu
uneingeschränkt, was die Nutzung von Systemfunktionen (z.B. Kamera, GPS oder
Bluetooth) angeht. Ein weiterer Vorteil liegt in der Unabhängigkeit von Drittan-
bietern. Durch die Nutzung eines nativen SDKs ist vollständiger Support aller
Updates und Features, die die Plattform bereitstellt, gewährleistet.[8][9]
Auch wenn eine native Entwicklung viele Vorteile bietet, müssen Einbußen be-
züglich Aufwand und Kosten hingenommen werden, vor allem dann, wenn man
sich dazu entscheidet, mit einer App mehrere Plattformen zu bedienen.
____________________________
1
„Benutzerfreundlichkeit“
3
Für jedes Betriebssystem muss die App von Grund auf neu aufgesetzt werden,
was nicht nur einen zeitlichen Aufwand mit sich bringt, sondern auch deswegen
problematisch sein kann, weil verschiedene Entwickler für spezielle Program-
miersprachen benötigt werden. Darüber hinaus verlängert die Arbeit mit mehr-
eren Codebasen jeglichen Entwicklungsprozess. Das betrifft unter anderem das
Hinzufügen neuer Features und das Testing, aber auch die Wartung einer bereits
veröffentlichten App. Es kann zudem die Inkonsistenz der grafischen Benutzer-
oberfläche über verschiedene Plattformen hinweg kritisiert werden. Jede Platt-
form hat eigene Richtlinien für das Design und interpretiert unter Umständen be-
stimmte Bedienelemente anders. Dadurch kann ein einheitliches Verhalten der
App für Anwender unterschiedlicher Plattformen nicht immer gewährleistet wer-
den, was den oben genannten Vorteil des homogenen Designs innerhalb eines
Betriebssystems relativiert.[8]
Die native Entwicklung stellt ein bewährtes Vorgehen dar, eine mobile App um-
zusetzen und wird trotz nennenswerter Alternativen von vielen Entwicklern be-
vorzugt. Insbesondere für grafisch anspruchsvolle Apps wie 3D-Games oder all-
gemein rechenintensive Anwendungen empfiehlt sich der native Ansatz.[8] Für
den Fall, dass eine App ohnehin nur für eine Plattform vorgesehen ist, bietet es
sich ebenfalls an, nativ zu entwickeln, da hier der Aufwand eher gering ist und
der Fokus auf dem Endprodukt liegen sollte. Generell, wenn man den Entwick-
lungsprozess (inkl. Zeitaufwand, Kosten und Wartung) bei der Validierung aus-
schließt und nur das Endprodukt samt Funktionsumfang bewertet, schneidet die
native App womöglich am besten ab, weil sie die beste Performance und Zugriff
auf alle Gerätefunktionen bietet. Da erstere Faktoren aber nicht zu vernachläs-
sigen sind und darüber hinaus viele Apps keine „High-End Performance“ oder
Zugriff auf sämtliche Gerätefunktionen voraussetzen, ist es für jedes App-Projekt
eine Einzelfallentscheidung, die eine Abwägung von Ressourcen (finanziell und
personell) vorsieht.
In den nächsten Abschnitten liegt der Fokus auf den Betriebssystemen iOS und
Android. Es werden die verschiedenen Entwicklungsprozesse nativer Apps für
beide Plattformen genauer betrachtet, wobei die unterschiedlichen Konzepte
erläutert und Vor- bzw. Nachteile aus Entwicklersicht herausgestellt werden.
42.1 iOS
Das Betriebssystem iOS2 ist seit Veröffentlichung des ersten Apple iPhones im
Jahr 2007 verfügbar. Ein Jahr später war es auch externen Entwicklern gestattet,
native Apps für iOS zu entwickeln. Damit brach Apple und in persona Steve Jobs3
mit der Konvention, dass Anwendungen von Drittanbietern ausschließlich in Form
von Web Apps über den Browser Einzug in die „Apple-Welt“ finden sollten.[4][10]
Heutzutage ist der App Store nicht nur für den Endanwender unabdingbar, son-
dern eine ebenso wichtige Einnahmequelle für das Unternehmen.[3] Häufig wird
jedoch die Tatsache kritisiert, dass Apps für iOS nur über diesen zentralen App
Store heruntergeladen werden können und es nicht möglich ist, Programme aus
anderen Quellen zu beziehen. Sicherlich kann hier auch das Gegenargument an-
gebracht werden, dass durch die Kontrolle der Software seitens Apple, Sicher-
heitslücken regulierbarer sind.
iOS-Apps wurden zunächst ausschließlich in Objective-C entwickelt. Objective-C
basiert auf der Programmiersprache C und erweitert diese um Eigenschaften der
Objektorientierung. Im September 2014 stellte Apple mit der Programmierspra-
che Swift erstmals eine alternative Möglichkeit vor, native iOS-Apps umzusetzen.
Nach anfänglicher Skepsis, was die Reife der Sprache anging, ist Swift mitt-
lerweile fast so weit verbreitet wie Objective-C und zählt zu den zehn belieb-
testen Programmiersprachen im Jahr 2019.[3] Beide Sprachen koexistieren
problemlos, da sie miteinander kompatibel sind. So können Swift-Module in
Objective-C Projekte eingebunden werden und andersherum.[11]
Swift steht unter der Apache 2.0 Lizenz und ist daher frei zugänglich. Es handelt
sich um eine objektorientierte Sprache, die über eine minimalistische Syntax ver-
fügt und „Safe by Design“ ist, also gewisse Fehlerquellen schon durch ihr Sprach-
konstrukt präventiv abdeckt. Laut eigenen Angaben ist Swift optimal auf Apples
Ökosystem abgestimmt und 2,6-mal schneller als Objective-C. Swift gilt damit als
sehr performante Programmiersprache.[11] Im Folgenden wird auf Objective-C
nicht weiter eingegangen, da Swift die modernere und zudem von Apple bevor-
zugte Sprache ist.
____________________________
2
Bis 2010 „iPhone OS“
3
Bis 2011 CEO von Apple
52.1.1 Architektur
Der grundlegende Aufbau von iOS kann durch vier Abstraktionsschichten veran-
schaulicht werden. Dabei bildet das Framework Cocoa Touch die oberste
Schicht. Es ist die Ebene, auf der die direkte Interaktion mit dem Anwender
stattfindet und die somit für Erscheinungsbild und Verhalten der App zuständig
ist. Darunter befindet sich die Schicht Media, die Grafiken, Animationen und an-
dere Medieninhalte bereitstellt. Die nächste Ebene Core Services ermöglicht
den Zugriff auf das Dateisystem und umfasst Dienste zur Netzwerkkommuni-
kation und Speicherverwaltung. Core OS regelt als unterste Schicht die Kern-
Funktionalitäten des Betriebssystems, welche die Basis für alle Schichten darü-
ber bilden.[12]
Abb. 2.1 – iOS Architektur
In der Praxis arbeitet der Entwickler weitestgehend auf der obersten Ebene.
Cocoa Touch beinhaltet unter anderem das Framework UIKit, welches die UI-
Elemente4 bereitstellt, die Hierarchie dieser verwaltet und das Event-Handling
übernimmt. Da Cocoa Touch nach dem MVC-Pattern (Model-View-Controller)
implementiert wurde, verfolgen iOS-Apps ebenfalls diesen Ansatz. Hierbei ist
der View Layer lediglich für die grafische Darstellung der App zuständig, wäh-
rend die Programmlogik dahinter im Controller programmiert wird. Das Model
stellt alle notwendigen Daten für die App bereit. Diese können dann über Kom-
munikation mit dem Controller im View Layer dargestellt werden.[11]
____________________________
4
Bedienelemente der grafischen Benutzeroberfläche
6Abb. 2.2 – Funktionsweise Model-View-Controller
2.1.2 Voraussetzungen
Die Entwicklung nativer iOS-Apps ist nur über macOS5 möglich, sodass Apple-
Hardware Voraussetzung für die Umsetzung ist. Als Entwicklungsumgebung
dient Xcode von Apple. Hier sind das iOS SDK, ein Geräte-Simulator und wei-
tere Werkzeuge zum Testen bereits integriert. Um eine fertiggestellte App auch
im App Store veröffentlichen zu können, ist die Teilnahme am Apple Developer
Program notwendig, für welches 99 US-Dollar jährlich investiert werden müssen.
Die Einrichtung empfiehlt sich bereits während der Entwicklung, da das Pro-
gramm einerseits den Zugriff auf diverse App-Technologien wie Siri oder Apple
Pay und die Nutzung der neuesten iOS Beta-Versionen ermöglicht und zum
anderen das Testing-Tool TestFlight bereitstellt, mit welchem schon vor Re-
lease bis zu zehntausend Nutzer eingeladen werden können, die App zu tes-
ten.[11]
Apple bietet Entwicklern neben einer ausführlichen Dokumentation sogenannte
Swift Playgrounds an, die den Einstieg in die Programmiersprache erleichtern.
Hierbei handelt es sich um kleine Test-Umgebungen, in denen Swift-Code ge-
schrieben werden kann, um die Sprache zu lernen, ohne direkt eine komplette
App aufsetzen zu müssen.[11]
____________________________
5
Betriebssystem für Apples Mac-Computer
7Ist Apple-Hardware vorhanden und xCode installiert, steht der Entwicklung einer
iOS-App nichts mehr im Wege. xCode liefert bereits vorinstallierte Templates für
verschiedene App-Projekte, wobei unter anderem zwischen Single View App,
Game oder Tab-Based App ausgewählt werden kann. Der Entwickler legt sich
durch die Auswahl eines Templates jedoch nicht endgültig fest. Der Aufbau einer
App kann manuell geändert und ein gewünschtes Feature auch nachträglich
noch hinzugefügt werden. Die Templates sollen lediglich den Einstieg erleichtern,
indem eine gewisse Struktur für bestimmte Anwendungsfälle schon vorgegeben
ist.
Zudem muss eine Auswahl für die Erstellung der Benutzeroberfläche getroffen
werden. Ab xCode 11 gibt es dafür zwei verschiedene Möglichkeiten: Die Um-
setzung kann entweder mittels Storyboards erfolgen oder unter Verwendung
des Frameworks SwiftUI. Da Letzteres erst im Juni 2019 von Apple vorgestellt
wurde und somit noch wenige iOS-Apps auf SwiftUI basieren, wird sich im
Folgenden auf Storyboards beschränkt. Dennoch kann SwiftUI als eine vielver-
sprechende Alternative angesehen werden, die in ferner Zukunft Storyboards
ablösen könnte.[11]
2.1.3 Entwicklung mit xCode
Abb. 2.3 – xCode 11 - Aufbau
8Als offizielle Entwicklungsumgebung für iOS kommt xCode mit vielen Funktio-
nen daher, die dem Entwickler die Arbeit erleichtern. Das Interface von xCode
kann in vier grundlegende Bereiche eingeteilt werden (siehe Abb. 2.3). Ganz links
befindet sich die Navigator Area, welche hauptsächlich der Projektansicht dient.
Darüber hinaus werden hier beim Kompilieren der App alle Errors und Warnun-
gen aufgelistet. Die Editor Area in der Mitte ist der Hauptbestandteil von xCode.
Im vorliegenden Screenshot ist der Interface-Builder aktiv, welcher sich in die
Komponenten-Ansicht (2a) und in die Device-Ansicht (2b) unterteilt und für die
Erstellung der Benutzeroberfläche zuständig ist. Dort wird dem Entwickler die
Hierarchie der verwendeten UI-Komponenten und die Vorschau in einem Apple-
Device, welches beliebig geändert werden kann, angezeigt. Die Editor Area ist
allgemein der Bereich für die Bearbeitung der aktuellen Datei. An dieser Stelle
befindet sich somit auch der Code-Editor für die Swift-Dateien. Es ist möglich,
mehrere Editoren parallel zu öffnen, sodass beispielsweise der Interface-Builder
neben der zu bearbeitenden Swift-Datei angezeigt wird. Die Inspector Area auf
der rechten Seite gibt Auskunft über die aktuell in der Navigator Area aus-
gewählte Datei. Bei aktivem Interface-Builder werden hier die Attribute der UI-
Elemente (z.B. Größe oder Farbe) festgelegt. Die Debug-Area unten dient zum
Testen der App. Nach Start der Applikation werden hier alle Konsolen-Ausga-
ben sowie der Status verschiedener Variablen angezeigt. Über die Toolbar ganz
oben, welche in der Abbildung nicht als eigener Bereich gekennzeichnet ist, kann
das Programm gestartet, das Device für den Geräte-Simulator geändert und das
Interface von xCode durch Ein- oder Ausblenden beliebiger Bereiche angepasst
werden. Seit xCode 11 befindet sich hier außerdem der Button zum Hinzufügen
von UI-Elementen für die Benutzeroberfläche.[11]
Um zu verstehen, wie iOS-Apps entwickelt werden, muss zunächst das Konzept
der Storyboards erläutert werden. Ein Storyboard besteht aus mehreren Views,
also Bildschirmansichten, die abhängig von der Interaktion des Users angezeigt
werden. Navigiert ein User beispielsweise durch ein Menü, können ihm verschie-
dene Views ausgespielt werden. Eine View wird immer von einem zugehörigen
ViewController, welcher für die Programmlogik zuständig ist, verwaltet. Bei dem
ViewController handelt es sich um eine Swift-Datei, die vom Entwickler imple-
mentiert werden muss. Somit ist die Separation von View Layer und Controller
gemäß MVC-Pattern bereits durch die App-Struktur vorgegeben.[11]
92.4 – xCode 11 - Storyboards
In Abb. 2.4 wird ein Storyboard, bestehend aus drei Views abgebildet. Startpunkt
des Storyboards ist hier eine Tab Bar Controller Scene, was durch den um-
randeten Pfeil neben der Screen-Ansicht verdeutlicht wird. Sie regelt die Über-
gänge (Segues) zu den anderen beiden Views, sodass in der fertigen App ein
User zwischen zwei Tabs wechseln kann und dementsprechend View 1 oder
View 2 angezeigt bekommt. Innerhalb eines Projektes können beliebig viele
Storyboards angelegt werden. So ist es nicht selten, dass für einen Login-Pro-
zess oder andere komplexere Abläufe eigene Storyboards designt werden. Es
kann aber genauso vorkommen, dass ein Storyboard, welches nur eine Scene
umfasst, ausreichend ist. Das ergibt sich aus der Komplexität der Anwendung.
Da die Programmlogik einer View innerhalb des zugehörigen ViewControllers
implementiert wird, ist noch zu klären, wie die Verbindung zwischen UI-Elemen-
ten und Programmcode erfolgt. Es gibt in Swift zwei verschiedene Arten von
Verbindungen: Outlets und Actions. Ein Outlet ist die Instanziierung eines UI-
Elements, während eine Action auf die Interaktion mit einem UI-Element reagiert.
102.5 – xCode 11 – Outlets und Actions
Anhand von Abb. 2.5 kann die Funktionsweise von Outlets und Actions beispiel-
haft gezeigt werden. In der Abbildung ist links der Interface-Builder und rechts
der Code-Editor für den zugehörigen ViewController geöffnet. Diese Ansicht hat
den Vorteil, dass so in xCode Verbindungen via „Drag and Drop“ angelegt wer-
den können. Für den oberen blauen und den unteren roten Button wurde jeweils
eine Action erstellt, die den Text eines Labels bei Klick auf den Button entspre-
chend ändert. Um dieses Label verändern zu können, wurde zuvor ein Outlet für
das UI-Element erstellt, dessen Variablenname dann verwendet werden kann, um
es anzusprechen.
2.1.4 Bewertung
Apple stellt mit xCode, das nach jedem iOS-Update aktualisiert wird, und mit der
modernen Programmiersprache Swift ein innovatives Entwicklungsumfeld bereit.
Dadurch, dass nur Apple-Geräte berücksichtigt werden müssen, hält sich außer-
dem der Testing-Aufwand, verglichen mit der Entwicklung von Android-Apps, in
Grenzen. Ein weiterer positiver Aspekt ist die Tatsache, dass der Anteil der iOS-
Nutzer, die die neueste Version des Betriebssystems verwenden, deutlich höher
ist, als es bei Android-Nutzern der Fall ist.
11So verkündete Apple im Juni 2019, dass die damals neueste Version iOS 12
auf 85% aller Apple-Geräte installiert sei, während zum gleichen Zeitpunkt An-
droid 9 gerade mal 10% der Android-Geräte bediene.[13] Das hat für iOS-Ent-
wickler den Vorteil, dass Fehlerbehebungen und Updates schneller an die Nutzer
verteilt werden können. Zudem können modernere Features verwendet werden,
ohne dass befürchtet werden muss, dass nur ein geringer Anteil der Anwender
diese nutzen kann.
Der offensichtliche Nachteil nativer iOS-Apps ist der geringere Marktanteil von
aktuell 22%. Zum Vergleich: Mit einer nativen Android-App wäre der Markt be-
reits zu 76% abgedeckt.6 [3] Hinzu kommt, dass Apple-Hardware vorausgesetzt
wird und die Entwicklergebühren für die Veröffentlichung einer App vergleichs-
weise hoch sind. Der Entwickler ist außerdem, was den Verbreitungsweg angeht,
auf Apples hauseigenen App-Store beschränkt.
Eine native Entwicklung für iOS kann sich insbesondere dann empfehlen, wenn
die App auf Umsatzgenerierung abzielt. Trotz des deutlich geringeren Markt-
anteils von iOS, war der Umsatz von Apples App Store im ersten Halbjahr des
Jahres 2019 um ca. 80% höher als der des Google Play Stores, was womöglich
durch eine kaufkräftige Apple-Kundschaft zu begründen ist.[14]
____________________________
6
Stand: Juli 2019
122.2 Android
Der Name „Android“ meint sowohl das Betriebssystem als auch die Programm-
bibliothek zur Entwicklung mobiler Apps. Android ist seit dem Jahr 2008 verfüg-
bar und wurde von der Open Handset Alliance (OHA) entwickelt. Bei der OHA
handelt es sich um einen von Google gegründeten Zusammenschluss aus Un-
ternehmen für Soft- und Hardware. Die Gerätehersteller HTC, LG Electronics,
Samsung Electronics und Motorola waren Gründungsmitglieder und stellten die
ersten Mobilgeräte mit Android als Betriebssystem her. In den Jahren darauf
schlossen sich dem Konsortium weitere Hersteller an (u.a. Sony Ericsson, Huawei
Technologies und ZTE). Mit dem Ziel, einen Standard für Mobilgeräte zu schaffen,
der von vielen Geräteherstellern geteilt wird, verfolgt Android einen Ansatz, wel-
cher sich konträr zu Apples Philosophie mit iOS verhält, das ausschließlich Apple-
Hardware bedient.[15][16]
Nach Veröffentlichung des SDKs konnten Anwendungen für Android zunächst
nur in der Programmiersprache Java entwickelt werden. Ein Jahr später war es
mit dem Android NDK (Native Development Kit) auch möglich, die Sprachen C
bzw. C++ für die Einbindung spezieller Bibliotheken zu nutzen. Die Programmier-
sprache Kotlin, welche von JetBrains6 entwickelt wurde und unter der Apache 2.0
Lizenz frei verfügbar ist, wird seit 2017 für Android-Apps unterstützt. Kotlin
läuft in der JVM (Java Virtual Machine) und ist daher auch mit Java kompatibel.
Ähnlich zu Apples Programmiersprache Swift setzt Kotlin auf eine intuitive Syn-
tax und auf ein per Design sicheres Sprachkonstrukt.[17][18]
Aufgrund des höheren Bekanntheitsgrads wird sich in den folgenden Beispielen
auf Java beschränkt. Dennoch sei hier anzumerken, dass Kotlin, zumindest was
die Entwicklung für Android angeht, Java früher oder später ablösen könnte. Da-
für spricht einerseits die Tatsache, dass Kotlin seit 2019 die bevorzugte Sprache
für Android-Projekte ist und zudem, dass laut Googles Angaben fast 60% der
Top 1000 Android-Apps Kotlin Code verwenden.[5]
____________________________
6
multinationales Software-Unternehmen mit Hauptsitz in Prag
132.2.1 Architektur
Die Android-Plattform kann in vier Abstraktionsschichten eingeteilt werden. Die
oberste Komponente Applications umfasst jene Anwendungen, die Android
standardmäßig zur Verfügung stellt. Darunter fallen unter anderem Funktiona-
litäten wie Kamera, Browser oder SMS-Messenger. Die Schicht darunter bildet
das Application Framework, welches für die Entwicklung mobiler Android-Apps
von großer Bedeutung ist. Es stellt Entwicklern dieselben Schnittstellen zur
Verfügung, die von Androids System-Apps genutzt werden. Sie ermöglichen
beispielsweise die Nutzung des Notification Managers für Push-Benachrich-
tigungen oder den Zugriff auf Daten externer Apps mittels sogenannter Content
Provider. Zudem liefert das Application Framework viele wiederverwendbare
UI-Komponenten für die Benutzeroberfläche und verwaltet den Lebenszyklus
einer Anwendung.[17]
Abb. 2.6 – Android Plattform – Architektur
Die nächste Schicht setzt sich aus den Komponenten Libraries und Runtime zu-
sammen. Libraries umfasst native Bibliotheken, die auf C und C++ basieren und
dem Application Framework viele Funktionen (u.a. Graphic Rendering, Daten-
speicherung und Web Browsing) bereitstellen. Diese Bibliotheken können mittels
Android NDK, wie weiter oben erwähnt, auch direkt innerhalb eines Android-
Projektes angesprochen werden.
14Die Komponente Runtime, häufig auch Android Runtime (ART) genannt, verwal-
tet den laufenden Prozess einer App, wobei dieser innerhalb einer Dalvik Virtual
Machine (DVM) ausgeführt wird. Auf derselben Ebene befinden sich zudem die
Core Libraries, welche die Nutzung der Sprachen Java und Kotlin für die
Entwicklung von Android-Apps erst ermöglichen. Die gesamte Android Archi-
tektur stützt sich auf den Linux Kernel, der alle Hardware-Treiber verwaltet und
für die Netzwerkkommunikation und Speicherverwaltung zuständig ist. Außer-
dem wird der Hardware Abstraction Layer (HAL) bereitgestellt, der dem
Entwickler Zugriff auf Hardware-Komponenten gewährt.[17]
Abb. 2.7 – Android - App-Architektur
Die von Android empfohlene App-Architektur ähnelt dem Konzept des MVC-
Patterns, wobei in diesem Zusammenhang häufig vom MVVM-Pattern (Model-
View-ViewModel) die Rede ist. Der View Layer, bestehend aus einer Activity
oder einem Fragment, ist hier ebenfalls nur für die grafische Darstellung der
Oberfläche und das Event-Handling zuständig. Das ViewModel stellt UI-rele-
vante Daten, welche es über das Repository erhält, bereit.
15Das Repository hat die Aufgabe, Daten aus einer Datenquelle (Datenbank oder
Webservice) abzurufen und gilt als „Single Point of Truth“, also als der korrekte
Datenbestand, welcher die App mit Daten anreichert. Android bietet darüber
hinaus viele weitere Architektur-Komponenten an, die eine robuste App-Archi-
tektur fördern, jedoch hier thematisch nicht im Vordergrund stehen.[17]
2.2.2 Voraussetzungen
Als Entwicklungsumgebung für Android-Apps diente lange Zeit Eclipse in Ver-
bindung mit dem Plugin ADT (Android Development Tools). Offizielle Entwick-
lungsumgebung ist seit 2015 Googles Android Studio IDE, das auf IntelliJ IDEA
von Jetbrains basiert. Android Studio IDE ist für alle gängigen Betriebssysteme
verfügbar, sodass, anders als bei iOS-Apps, keine bestimmte Hardware voraus-
gesetzt wird. Für die Veröffentlichung einer App im Google Play Store muss ein
Google Publisher Account eingerichtet werden, der eine einmalige Registrie-
rungsgebühr von 25 US-Dollar verlangt. Die Bereitstellung einer App über den
Google Play Store ist zwar die empfohlene Variante, dennoch können Android-
Apps auch auf anderem Wege verbreitet werden. Nach Fertigstellung einer
Android-App kann die zugehörige AKP-Datei (Android Package) beispielsweise
auch über eine Webseite als Download angeboten werden.[17][19]
Android bietet Entwicklern eine umfangreiche Dokumentation mit ausführlichen
Anleitungen inklusive Codebeispiele für Kotlin und Java, die sowohl für den Start
als auch über den gesamten Entwicklungsprozess hinweg hilfreich sein können.
Wie xCode kommt Android Studio IDE mit vorinstallierten Templates für spezi-
fische App-Projekte daher. Ansonsten muss vor Entwicklungsbeginn nur die ge-
wünschte Programmiersprache (Java oder Kotlin) und das minimale API-Level für
die zu unterstützenden Android Versionen ausgewählt werden.
2.2.3 Entwicklung mit Android Studio IDE
Da Android Studio IDE auf dem Code von IntelliJ IDEA basiert, stellt es dieselben
Features bereit und bietet darüber hinaus spezielle Tools für die Entwicklung von
Android-Apps an.
162.8 – Android Studio 3 – Aufbau
Das Interface von Android Studio ist ähnlich wie das von xCode aufgebaut. Es
lässt sich in drei Bereiche einteilen: Ganz links befindet sich die Projektansicht.
Von hier aus wird durch die Dateien des Projektes navigiert. Im Editor Window
in der Mitte kann zwischen Layout-Ansicht für das Design und Code-Editor für
hauptsächlich Java- oder XML-Dateien gewechselt werden. Dazu wird in der
oberen Menüleiste des Bereiches die entsprechende Datei ausgewählt, die
bearbeitet werden soll. Die Layout-Ansicht ist, was den Aufbau angeht, nahezu
identisch zu xCode. Es gibt eine Übersicht über alle verwendeten UI-Kompo-
nenten, eine Device-Ansicht, die konfiguriert werden kann und ein Fenster (2b)
für die Anpassung der Eigenschaften von UI-Elementen. Letzteres wird nur in der
Layout-Ansicht angezeigt, sodass sich der Code-Editor über die gesamte Breite
(2a und 2b) erstreckt. Die Debug-Area zum Testen befindet sich in Android Stu-
dio ebenfalls unten. Neben Konsolen-Ausgaben und einem Terminal bietet die-
ser Bereich auch die Möglichkeit zur Auflistung von anstehenden Aufgaben, die
das Projekt betreffen. Über die Toolbar oben kann der Run- bzw. Debug-Prozess
gestartet und das Android-Gerät für den Emulator (Geräte-Simulator) ausgewählt
werden.[17]
Während für die Erstellung einer Benutzeroberfläche von iOS-Apps Storyboards
genutzt werden, wird in Android Studio mit Activities gearbeitet. Eine Activity ist
eine Bildschirmansicht und besteht aus Layouts und Widgets.
17Layouts gehen auf die Basisklasse ViewGroup zurück und sind eine Art
unsichtbarer Container, der die Widgets enthält. Android bietet verschiedene
Typen von Layouts an, wobei LinearLayout, RelativeLayout und ConstraintLay-
out am weitesten verbreitet sind. Es wird hier nicht weiter auf die Eigenschaf-
ten dieser Typen eingegangen. Es sei nur festzuhalten, dass verschiedene Lay-
outs existieren, wobei sie die Bedingungen für Abstände und Position der Be-
dienelemente jeweils unterschiedlich festlegen. Widgets hingegen sind UI-
Elemente (Buttons, TextViews etc.), die Android zur Verfügung stellt und die alle
auf der Klasse View basieren. So setzt sich eine Benutzeroberfläche in Android
aus ViewGroups und Views zusammen (siehe Abb. 2.7). [17]
2.9 – Android – UI-Hierarchie
Das Design einer Activity wird innerhalb einer XML-Datei festgelegt. Wenn für
Anpassungen der grafischen Oberfläche der Layout-Editor genutzt wird, wie es
häufig der Fall ist, wird die XML-Datei automatisch erweitert. Theoretisch kann
das gesamte Design erstellt werden, ohne die XML-Datei direkt zu bearbeiten,
sondern nur unter Verwendung des Interfaces. Die Programmlogik einer Activity
wird in einer zugehörigen Java-Klasse implementiert. Innerhalb einer Manifest-
Datei kann festgelegt werden, welche Activity als Launchscreen, also als Start-
punkt der App dienen soll. Um zwischen verschiedenen Activities zu wechseln,
können sogenannte Intents verwendet werden, die in der Java-Klasse imple-
mentiert werden müssen.
18Mittels Intents kann nicht nur zwischen Activities innerhalb der Anwendung
gewechselt, sondern zudem mit externen Apps kommuniziert werden, um bei-
spielsweise ein Mail-Programm oder die Kamera zu öffnen.[17]
2.10 – Android Studio 3 – Zusammenspiel UI & Logik
Die obige Abbildung 2.8 veranschaulicht, wie für die grafische Oberfläche einer
Android-App Programmlogik implementiert werden kann. Die dargestellte Java-
Klasse verbindet sich zunächst mit der Activity, die es verwalten soll (rote Linie).
In diesem Fall hat sie den Namen „activity_main“. Über eine ID, die im Layout-
Editor für jedes UI-Element festgelegt werden kann, wird in der Zeile darunter die
TextView instanziiert, sodass auf dieses Element im Code zugegriffen werden
kann. In den grün umrandeten Funktionen wird der Text des TextView-Elements
je nach Aktion geändert. Um die Funktionen mit den entsprechenden Buttons zu
verbinden, werden die Funktionsnamen im Layout-Editor als onClick-Attribut der
jeweiligen Buttons angegeben.
192.2.4 Bewertung
Wie xCode bietet Android Studio viele Werkzeuge, welche die Entwicklung
nativer Android-Apps erheblich erleichtern. Mit Java und Kotlin besteht zudem
die Möglichkeit, zwischen einer einerseits weit verbreiteten und einer anderer-
seits sehr modernen Programmiersprache zu wählen. Android Studio ist sowohl
für macOS als auch für Windows verfügbar, sodass es bezüglich der Hardware
keine Voraussetzungen gibt. Die Entwicklergebühren für die Veröffentlichung
einer App sind verglichen mit iOS niedrig und vor allem einmalig. Darüber
hinaus gibt es für Android-Apps neben dem Google Play Store viele weitere
Verbrei-tungswege. Die große Marktabdeckung von 76% [3] ist sicherlich
ebenfalls als großer Vorteil von Android anzusehen.
Jedoch bringt die Tatsache, dass viele verschiedene Gerätehersteller beteiligt
sind, aus Entwicklersicht auch Nachteile mit sich. Zum einen vergrößert sich der
Testing-Aufwand, wenn sichergestellt werden soll, dass die App auf verschie-
denen Android-Geräten unterschiedlicher Hersteller reibungslos funktioniert und
zum anderen wird die Bereitstellung von Updates und die Nutzung moderner
Features dadurch eingeschränkt, dass Androids Softwareupdates nicht zentral
ausgerollt werden, sondern abhängig vom jeweiligen Gerätehersteller sind.
Die Entwicklung einer nativen Android-App empfiehlt sich insbesondere dann,
wenn die App möglichst viele Anwender voraussetzt oder eine schnelle Ver-
öffentlichung über einen beliebigen Verbreitungsweg gewünscht ist.
203 Hybride Apps
Hybride Apps stellen eine Mischung aus Webanwendung und nativer App dar.
Sie werden auf Basis der Webtechnologien HTML, CSS und Javascript ent-
wickelt und darüber hinaus in einen nativen Container eingebettet, wodurch es
möglich ist, sie wie eine native App im App Store verfügbar zu machen. Hybride
Apps könnten somit als Anwendungen mit nativer Infrastruktur und webbasiertem
Inhalt bezeichnet werden.
Die Einbettung in einen nativen Container geschieht über eine sogenannte „Web
View“, welche nichts anderes als eine Browser Engine1 innerhalb einer nativen
App ist. Im Gegensatz zu einem herkömmlichen Browser existieren in einer Web
View keine Bedienelemente zur Navigation und keine Adressleiste. Sie ist ledig-
lich für die Darstellung von Webinhalten zuständig, ohne weitere Browserele-
mente anzuzeigen. Ein weiterer Unterschied, verglichen mit einer Webanwen-
dung, besteht darin, dass hybride Apps auch offline lauffähig sind, sofern nicht
auf Ressourcen zugegriffen werden muss, die eine Internetverbindung voraus-
setzen. Das liegt in der Tatsache begründet, dass der Webinhalt hybrider Apps
nicht von einem Webserver geladen, sondern innerhalb der App auf dem Gerät
gespeichert wird.[8][9]
Der Einsatz von App-Frameworks wie Ionic oder Adobe Phonegap kann die
Entwicklung einer hybriden App wesentlich erleichtern. Sie übernehmen die
Einbindung des webbasierten Codes für verschiedene Plattformen und stellen
Plugins bereit, die einer hybriden App Zugriff auf viele native Gerätefunktionen
ermöglichen.[20][21]
Der größte Vorteil von hybriden Apps ist die kurze Entwicklungsdauer, die da-
durch zustande kommt, dass eine Codebasis verschiedene Plattformen bedienen
kann. Des Weiteren werden keine Entwickler benötigt, die auf native Program-
miersprachen spezialisiert sind, sondern es können Web-Entwickler für die Um-
setzung hybrider Apps eingesetzt werden.
___________________________
1
„HTML-Renderer“
21Eine Umfrage, welche im Jahr 2019 von Stack Overflow 2 durchgeführt wurde,
ergab, dass fast 70% aller Teilnehmer mit Webtechnologien vertraut waren,
während die nativen Sprachen Swift, Objective-C oder Kotlin jeweils unter der
7%-Marke blieben.[22] Die große Verbreitung von webbasierten Sprachen kann
somit durchaus als Vorteil hybrider Entwicklung angesehen werden.
Trotz alledem sieht man sich bei der Entwicklung hybrider Apps mit ein paar
Herausforderungen konfrontiert. Verglichen mit nativen Apps können sie im Be-
reich Performance nicht mithalten, was sich besonders bei rechenintensiven An-
wendungen bemerkbar macht. Dies äußert sich beispielsweise durch eine ver-
längerte Reaktionszeit bei Interaktion mit der App oder generell durch längere
Ladezeiten. Beides kann sich im schlimmsten Fall negativ auf die Usability aus-
wirken. Dazu kommt, dass bei einer hybriden Entwicklung der Zugriff auf alle
Gerätefunktionen nicht sichergestellt ist, auch wenn die angesprochenen App-
Frameworks viele Features mittels Plugins bereitstellen. Der Entwickler ist nichts-
destotrotz abhängig von entsprechendem Support des Drittanbieters, was bei
einer nativen Entwicklung nicht der Fall ist.[8]
Hybride Apps glänzen durch eine schnelle und plattformübergreifende Entwick-
lung unter Verwendung verbreiteter Sprachen. Wenn der Schwerpunkt auf einer
möglichst schnellen Veröffentlichung für mehrere Plattformen liegt, ist der hy-
bride Ansatz durchaus empfehlenswert. Eine hybride App eignet sich somit auch
besonders gut für die Umsetzung eines MVP (Minimum Viable Product), um
Markt- bzw. Funktionsbedarf zu testen. Für Anwendungen, die komplexer und
rechenintensiver sind und bei denen es zudem von großer Wichtigkeit ist, dass
sie stabil und flüssig laufen, ist womöglich von einer hybriden Entwicklung ab-
zuraten. Jedoch muss dazu gesagt werden, dass Webanwendungen allgemein
schneller und leistungsstärker geworden sind und die Einbußen bezüglich Per-
formance heutzutage nicht mehr so gravierend sind. Für den Fall, dass bereits
eine für Mobilversionen optimierte Webanwendung existiert, kann sich die Erwei-
terung auf eine hybride App ebenfalls anbieten, um sie in den App Stores ver-
fügbar zu machen.
___________________________
2
verbreitete Internetplattform für Softwareentwickler
224 Cross-Platform Apps
Der Begriff „Cross-Platform App“ („plattformübergreifende App“) wird häufig als
Oberbegriff für jene Apps verwendet, die die Eigenschaft der Plattformunab-
hängigkeit aufweisen, was hybride Apps mit einschließen würde. In dieser Arbeit
wird jedoch klar zwischen hybriden Apps und Cross-Platform Apps unterschie-
den, da letztere einen anderen technischen Ansatz verfolgen. Eine Codebasis
bedient hier ebenfalls mehrere Plattformen, jedoch mit dem Unterschied, dass
bei der Erstellung der Benutzeroberfläche native UI-Elemente verwendet wer-
den. Es handelt sich daher nicht, wie bei den hybriden Apps, um Web App-
likationen mit nativer Hülle, sondern um Apps bestehend aus „echten“ nativen
Komponenten.[9]
Cross-Platform Tools wie React Native oder Xamarin stellen dabei die Verbin-
dung zu den nativen Schnittstellen her und ermöglichen die Übersetzung in na-
tive UI-Elemente. Für eine Umsetzung mit React Native würde das beispielsweise
bedeuten, dass der Entwickler UI-Komponenten in React1 schreibt und React
Native diese in entsprechende native Komponenten für die jeweilige Plattform
umwandelt.
Cross-Platform Apps genießen damit dieselben Vorteile wie hybride Apps, wenn
es um eine schnelle, plattformunabhängige und kosteneffiziente Entwicklung
geht. Mit React Native und Xamarin können zudem die modernen Sprachen
React und C-Sharp2, die beide über eine große Community verfügen, für die
Umsetzung genutzt werden. Der größte Vorteil von Cross-Platform Apps gegen-
über hybriden Apps ist sicherlich die Tatsache, dass derselbe Code von ver-
schiedenen Plattformen genutzt werden kann, aber zugleich native UI-Elemente
verwendet werden. Diese Transferleistung übernimmt dabei das jeweilige Cross-
Platform Tool. Das ideale Endprodukt wäre somit eine leistungsstarke, nahezu
native App, die auf eine schnelle, plattformunabhängige Entwicklung zurück-
geht.[23][24]
___________________________
1
JavaScript-Framework (entwickelt von Facebook)
2
Objektorientierte Programmiersprache (entwickelt von Microsoft)
23Cross-Platform Apps verfolgen einen Ansatz, der darauf abzielt, die Vorteile einer
hybriden App mit denen einer nativen App zu vereinen. In der Theorie ist es
genau das, was Cross-Platform Apps so reizvoll macht, in der Praxis ist es jedoch
nicht immer so leicht umzusetzen. Der Entwickler ist hier stark auf die Unter-
stützung des Cross-Platform Tools angewiesen. Wenn ein gewisses natives UI-
Element nicht bereitgestellt wird oder eine gewünschte Modifizierung des
Elements nicht vorgesehen ist, kann der Entwicklungsaufwand in die Höhe
schnellen. Es ist zwar möglich, eine beliebige native Anbindung selbst zu imple-
mentieren, jedoch kann dieser Codeabschnitt dann nicht mehr von anderen
Plattformen verwendet werden. So kann es bei komplexeren Anwendungen
schnell passieren, dass aufgrund nativer Anpassungen letztendlich doch mit
verschiedenen Codebasen gearbeitet werden muss. Zudem kann trotz nativer
Benutzeroberfläche nicht dieselbe Performance wie bei einer nativen App ge-
währleistet werden, da durch die Umwandlung des Codes ein Zusatzaufwand
entsteht.[9]
Die Entwicklung einer Cross-Platform App eignet sich für verschiedene Anwen-
dungsfälle. Generell, wenn eine native Benutzeroberfläche für mehrere Plattfor-
men gewünscht ist, kann dieser Ansatz in Betracht gezogen werden, wobei vor-
her analysiert werden sollte, ob die Vorteile, die ein Cross-Platform Tool bietet,
nicht durch spezielle Anforderungen an die App und dadurch entstehenden
Mehraufwand wieder relativiert werden. Es liegt auf der Hand, dass für Entwick-
lerteams, die ohnehin auf die Sprachen React oder C-Sharp spezialisiert sind,
die Umsetzung einer solchen App ebenfalls in Frage kommt. Für den Fall, dass
bereits eine Webanwendung in React existiert, kann ein großer Teil dieses Codes
in React Native wiederverwendet werden, wodurch sich dieser Ansatz dann auch
empfehlen kann.
Alternativ zu React Native von Facebook und Xamarin von Microsoft kann seit
2017 Flutter von Google für die Umsetzung einer Cross-Platform App genutzt
werden. Apps werden hier in der ECMA-standardisierten Programmiersprache
Dart geschrieben, die ebenfalls von Google stammt.
245 Zusammenfassung und Fazit
Wie in der Einleitung bereits gezeigt wurde, ist die Entwicklung mobiler Apps mit
der Zeit immer relevanter geworden, wodurch auch die Möglichkeiten zur Um-
setzung vielfältiger geworden sind. In dieser Arbeit wurde daher ein Überblick
über die verschiedenen Methoden, heutzutage mobile Apps umzusetzen, ge-
geben. Dabei wurden die technischen Unterschiede der verschiedenen Entwick-
lungsansätze erläutert und darüber hinaus eine Bewertung hinsichtlich Funk-
tionsumfang, Aufwand und Machbarkeit abgegeben.
Etwas detaillierter wurde sich den Betriebssystemen iOS und Android und der
technischen Umsetzung nativer Apps für diese Plattformen gewidmet. Dies dien-
te dazu, den grundlegenden Aufbau der beiden verbreitetsten mobilen Plattfor-
men und die Kernkonzepte dieser zu erläutern, um sich auf Basis dessen mit
anderen Entwicklungsansätzen beschäftigen zu können. Die angesprochenen
Frameworks für hybride App-Entwicklung oder die Cross-Platform Tools konn-
ten nicht in derselben Tiefe behandelt werden, da es den Rahmen der Arbeit ge-
sprengt hätte. Nichtsdestotrotz sollte eine ausreichende Übersicht über die ver-
schiedenen Entwicklungsansätze, deren Eigenschaften sowie Vor- und Nachteile
geliefert worden sein.
Trotz nennenswerter Alternativen stellt die native Entwicklung noch immer ein
bewährtes Vorgehen dar, mobile Apps zu entwickeln. Ein umfangreiches natives
SDK bietet viele nützliche Werkzeuge explizit für eine Platform und gewährleistet
zudem Support aus erster Hand. Des Weiteren ist die Performance einer nativen
App aufgrund der nahtlosen Kompatibilität von Programmiersprache, Bibliothe-
ken und Betriebssystem am besten.
Durch die schnelle und plattformübergreifende Entwicklung sind hybride Apps
ebenfalls eine beliebte Möglichkeit, Anwendungen für Mobilgeräte umzusetzen.
Dadurch, dass webbasierte Sprachen, welche weit verbreitet sind, verwendet
werden, erhalten viele Entwickler, die mit nativen Sprachen nicht vertraut sind,
Zugang zur App-Entwicklung. Zudem erleichtern Frameworks die Entwicklung
hybrider Apps, indem sie die Webinhalte in die native App einbinden und Plugins
für den Zugriff auf native Funktionen bereitstellen.
25Cross-Platform Apps erweitern den hybriden Ansatz, indem Cross-Platform
Tools, ausgehend von einer Codebasis, UI-Elemente in native UI-Komponenten
für die jeweiligen Plattformen übersetzen. Mit dem Ansatz, die Konzepte von na-
tiven und hybriden Apps zu vereinen, ist die Entwicklung von Cross-Platform
Apps eine reizvolle Methode, wobei in der Praxis bei komplexeren Anforde-
rungen die Vorteile schnell relativiert werden.
266 Literaturverzeichnis
[1] „Simon Says 'Here's How!' User’s Manual” – IBM Corporation, 1993
Zugriff: 14.11.2019
URL: https://www.microsoft.com/buxtoncollection/a/pdf/Simon%20User%20Manuals.pdf
[2] „Blackberry: Vom Überflieger zum Übernahmekandidat“ - CIO Magazin, 2015
Zugriff: 14.11.2019
URL: https://www.cio.de/a/blackberry-vom-ueberflieger-zum-uebernahmekandidat,3102876
[3] Statista - Statistics & Facts - Statista
„Mobile app usage” – 2019, Zugriff: 15.11.2019
URL: https://www.statista.com/topics/1002/mobile-app-usage/
„Smartphones industry” – 2018, Zugriff: 15.11.2019
URL: https://www.statista.com/topics/840/smartphones/
„The Most Popular Programming Languages” – 2018, Zugriff: 03.12.2019
URL: https://www.statista.com/chart/16567/popular-programming-languages/
„Mobile operating systems’ market share” – 2019, Zugriff: 02.01.2019
URL: https://www.statista.com/statistics/272698/global-market-share-held-by-mobile-operating-
systems-since-2009/
[4] Apple Newsroom – Apple
„The App Store turns 10” – 2018, Zugriff: 15.11.2019
URL: https://www.apple.com/newsroom/2018/07/app-store-turns-10/
„Apple Announces iPhone 2.0 Software Beta“ – 2008, Zugriff: 15.11.2019
URL: https://www.apple.com/newsroom/2008/03/06Apple-Announces-iPhone-2-0-Software-
Beta/
[5] Android Developers Blog - Google
„Android Market: Now available for users” – 2008, Zugriff 15.11.2019
URL: https://android-developers.googleblog.com/2008/10/android-market-now-available-for-
users.html
„Announcing a beta release of the Android SDK” – 2008, Zugriff 15.11.2019
URL: https://android-developers.googleblog.com/2008/08/announcing-beta-release-of-android-
sdk.html
„Android’s commitment to Kotlin” – 2019, Zugriff 29.11.2019
URL: https://android-developers.googleblog.com/2019/12/androids-commitment-to-kotlin.html
27[6] Eric Schmidt (Google CEO) - Mobile World Congress – Barcelona, 2010
Zugriff: 11.11.2019
URL: https://www.youtube.com/watch?v=ClkQA2Lb_iE
[7] Eric Schmidt (Google Chairman) - Bloomberg Interview, 2014
Zugriff: 11.11.2019
URL: https://www.youtube.com/watch?v=vzKM8oyCsUg&feature=emb_title
[8] eBook: Hybrid vs. Native – Ionic
Zugriff: 22.12.2019
URL: https://ionicframework.com/books/hybrid-vs-native
[9] Ionic Framework Articles - Ionic
„What is hybrid App Development” – 2019, Zugriff: 18.12.2019
URL: https://ionicframework.com/resources/articles/what-is-hybrid-app-development
„Ionic vs. React Native: A Comparison Guide” – 2019, Zugriff: 19.12.2019
URL: https://ionicframework.com/resources/articles/ionic-vs-react-native-a-comparison-guide
[10] „Steve Jobs resisted third-party apps on iPhone” – The Guardian, 2011
Zugriff: 16.11.2019
URL: https://www.theguardian.com/technology/appsblog/2011/oct/24/steve-jobs-apps-iphone
[11] Apple Developer Documentation – Apple
Apple Developer Program, Zugriff 02.12.2019
URL: https://developer.apple.com/programs/
Swift Introduction, Zugriff: 04.12.2019
URL: https://developer.apple.com/swift/
„Model-View-Controller”, Zugriff 08.12.2019
URL: https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-
CocoaCore/MVC.html
SwiftUI, Zugriff 08.12.2019
URL: https://developer.apple.com/xcode/swiftui/
xCode Help, Zugriff 15.12.2019
URL: https://help.apple.com/xcode/mac/current/
Interface Builder, Zugriff 16.12.2019
URL: https://developer.apple.com/xcode/interface-builder/
28[12] „iOS Architecture“ – Medium, 2018
Zugriff: 01.12.2019
URL: https://medium.com/@anuradhs/ios-architecture-a2169dad8067
[13] „WWDC: 12 big announcements for enterprise users” – Computerworld, 2019
Zugriff: 02.01.2019
URL: https://www.computerworld.com/article/3400099/wwdc-12-big-announcements-for-
enterprise-users.html
[14] Global App Revenue – First Half of 2019 – SensorTower, 2019
Zugriff: 02.01.2019
URL: https://sensortower.com/blog/app-revenue-and-downloads-1h-2019
[15] „Google unveils cell phone software and alliance” – CNET, 2007
Zugriff: 29.11.2019
URL: https://www.cnet.com/news/google-unveils-cell-phone-software-and-alliance/
[16] Open Handset Alliance - FAQ – OHA, 2007
Zugriff: 29.11.2019
URL: https://www.cnet.com/news/google-unveils-cell-phone-software-and-alliance/
[17] Android Developer Documentation – Google
„Fundamentals”, Zugriff: 27.11.2019
URL: https://developer.android.com/guide/components/fundamentals
„Android NDK“, Zugriff: 29.11.2019
URL: https://developer.android.com/ndk
„Platform Architecture“, Zugriff: 12.12.2019
URL: https://developer.android.com/guide/platform
„Guide to app architecture“, Zugriff: 18.12.2019
URL: https://developer.android.com/jetpack/docs/guide
„Publish your app“, Zugriff: 18.12.2019
URL: https://developer.android.com/studio/publish
„Layouts“, Zugriff: 22.12.2019
URL: https://developer.android.com/guide/topics/ui/declaring-layout
„Meet Android Studio“, Zugriff: 27.12.2019
URL: https://developer.android.com/studio/intro
29Sie können auch lesen
