Was ist Xamarin – Woher hat es seine Ursprünge?

In diesem Artikel möchten wir euch das Framework Xamarin näher vorstellen. Xamarin stammt vom Entwicklerteam Mono, dass 2011 gegründet wurde und gehört seit 2016 nun zu Microsoft. Damit kann es als Teilkomponente in Visual Studio verwendet werden und unterliegt dessen Lizenzbedingungen. Für die kostenlose Version von Visual Studio (VS Community Edition) gilt dabei, dass diese von einzelnen Entwicklern auch zu kommerziellen Zwecken, von beliebig vielen Personen im Rahmen von Open-Source oder akademischen Projekten verwendet werden darf. Im Unternehmensumfeld muss Visual Studio Professional oder Visual Studio Enterprise verwendet und lizenziert werden.

Wie funktioniert Xamarin und was bietet es?

Xamarin beschreibt eine Reihe von Tools des gleichnamigen Unternehmens, mit denen Cross-Plattform-Apps für Android, iOS und UWP unter Verwendung von C# entwickelt werden können. Xamarin unterteilt sich dabei in die folgenden Produkte/Tools:

Xamarin Platform (Xamarin.Android, Xamarin.iOS) stellt APIs zur Verfügung, die es Entwicklern ermöglichen, C#-Code für Businesslogik zwischen Android, iOS und Windows zu teilen. Die Benutzeroberfläche wird pro Plattform individuell geschrieben. Hier kann durchschnittlich etwa 75% des gesamten Quellcodes geteilt werden:

Xamarin-Architektur

Forms ermöglicht es Entwicklern, zusätzlich plattformunabhängige Oberflächen zu erstellen, die dann in native Oberflächen „gemappt“ werden. Damit kann bis zu 100% des Quellcodes für alle Plattformen verwendet werden.
Xamarin Test Cloud stellt eine Testumgebung auf etwa 2.000 echten Endgeräten kostenpflichtig zur Verfügung (mehr Informationen unter Test-Unterstützung)
Xamarin for Visual Studio ist die Entwicklungsumgebung für Xamarin unter Windows
Xamarin Studio ist die Entwicklungsumgebung für Xamarin unter macOS
Xamarin Mac

Intern verwendet Xamarin verschiedene Ansätze für die Unterstützung der verschiedenen Plattformen:

iOS: Für die iOS-Plattform wird der geschriebene C#-Code per AOT (ahead-of-time)-Kompilierung in ARM-Assembly-Sprache übersetzt und zusammen mit der Mono-Implementierung des .NET Frameworks gepackt. Dabei werden Klassen, die nicht verwendet werden ausgelassen.
Android: Unter Android wird der C#-Code in Intermediate Language (IL) übersetzt und zusammen mit Mono und einer Just-In-Time-Kompilierung-Funktionalität (JIT) gepackt. Auf dem jeweiligen Android-Gerät läuft die Applikation neben der Android Laufzeitumgebung (ART) und greift per Java Native Interface (JNI) auf die nativen Typen zu.
Windows: Für Windows (UWP) wird der C#-Code in IL übersetzt und direkt von der in UWP vorhandenen Laufzeitumgebung ausgeführt.
Mac: Unter macOS wird der C#-Code zunächst in IL übersetzt, zusammen mit Mono gepackt und entweder später während der Laufzeit per JIT-Kompilierung oder per AOT-Kompilierung während des Build-Prozesses in nativen Code übersetzt.

Unterstützte Plattformen

Xamarin wirbt mit der vollen Unterstützung der Plattformen Android, iOS und UWP (also Windows Phone und Windows 10). Diese werden auch – wie in Zugriff auf plattformspezifische Funktionen genauer beschrieben wird – vollumfänglich unterstützt. Plattformen wie Linux, o.ä. werden nicht unterstützt, was jedoch weniger an der technischen Machbarkeit (Mono als verwendetes Framework ist grundsätzlich auch unter Linux verfügbar), als an den damit einhergehenden Problemen liegt. Die Unterstützung von macOS erfolgte mit der Einführung des Produkts Xamarin.Mac, das aktuell jedoch noch in einer sehr frühen Phase ist.

Unterstützte Entwicklungsplattormen

Für die Entwicklung wird Visual Studio für Windows und Xamarin Studio für macOS angeboten. Andere Entwicklungsplattformen (bspw. Linux) werden nicht unterstützt.

Zugriff auf plattformspezifische Funktionen

Xamarin wirbt damit, dass die komplette zugrundeliegende native API angesprochen werden kann und somit alle Funktionen, die bei der Entwicklung mit Java, Objective-C, o.ä. verfügbar sind, genutzt werden können. Das hat sich bei der Evaluierung der Test-App auch bestätigt, da es in deren Umfang keine Funktion gibt, die nicht angesprochen werden konnte. Es gibt bei der Verwendung von Xamarin.Forms mehrere Möglichkeiten geräte- bzw. plattformspezifische Funktionen anzusprechen: So kann man pro Plattform ein zuvor definiertes Interface implementieren und dieses dann im Shared Code über den Dependency Service ansprechen. Eine andere Möglichkeit ist, entsprechende NuGet-Pakete zu installieren und diese zu verwenden (intern wird hier auch meist der Dependency Service mit verschiedenen Interfaces verwendet).

Es besteht sogar die Möglichkeit, Bibliotheken, die bspw. in reinem Java für Android geschrieben wurden über Binding-Libraries zu verwenden, wobei diese Funktionalität hier nicht getestet wurde. Damit steht jedoch eine riesige Auswahl nativer Bibliotheken zur Verfügung.

Dadurch, dass Xamarin jedoch bei Release neuer Funktionen der einzelnen Plattformen (bspw. Android Oreo) diese erst in ihrer eigenen Bibliothek anbieten muss, können die neuesten Funktionen erst nach einer bestimmten Zeitverzögerung (stabil) genutzt werden. Bisher war Xamarin jedoch sehr schnell in der Umsetzung neuer Funktionen, sodass nahezu keine Zeitdifferenz zwischen Release der nativen neuen API und Unterstützung durch Xamarin bestand.

Look & Feel

Da mit Xamarin vollständig native Oberflächen erstellt werden, wirkt die Oberfläche für den Nutzer sehr vertraut. Xamarin unterstützt auch Styling mit Themes. Die Xamarin Oberfläche fügt sich dementsprechend sehr gut in die Plattform ein und ist von der Oberfläche nicht von nativen oder System-Apps unterscheidbar. Unter Android wird auch Material Design unterstützt.

Xamarin-Screens

Performance und Ressourcennutzung

Besonders negativ fällt hier die Startzeit der App auf. Nach mehreren Messungen der Zeit zwischen „Tippen“ des App-Icons und fertig geladener bzw. einsetzbarer Oberfläche ergab sich ein Durchschnitt von etwa 3-3,5 Sekunden, was gerade für eine solch simple Anwendung sehr langsam und für den Nutzer definitiv spürbar ist. Dieses Verhalten kann eventuell noch in späteren Xamarin-Updates behoben werden, ist aktuell jedoch definitiv ein negativ auffallender Aspekt.

Die Performance nach dem Start ist hingegen sehr gut, Eingaben werden sehr schnell registriert und die Aktionen sehr schnell ausgeführt, sodass die App sich bezüglich dieses Aspektes nicht von nativ entwickelten Apps unterscheidet.

Der belegte Speicherplatz ist jedoch ungewöhnlich groß. Die Referenz-App belegt in der Release-Konfiguration ca. 28 MB Speicherplatz. Das liegt zum Teil daran, dass für jede App der eigentliche Code, die verwendeten Bibliotheken, andere Daten (Bilder), die Mono Laufzeitumgebung, und die benötigten BCL Assemblies mitgeliefert werden müssen. Eine simple Hallo-Welt-App besitzt somit bereits eine Größe von ca. 16 MB. Zwar nimmt die Größe der App nicht linear mit der Codebase zu, jedoch ist die „Grundgröße“ bei jeder App recht groß. Es ist jedoch auch anzumerken, dass es viele verschiedene Einstellungsmöglichkeiten und Tweaks gibt, um den belegten Speicherplatz zu reduzieren, an dem eigentlichen Grund für den hohen Speicherbedarf ändert das jedoch nichts.

Der durchschnittliche Arbeitsspeicherverbrauch liegt bei 17 MB, was im normalen Rahmen liegt.

Verteilung und Deployment

Während des Entwicklungsprozesses können die Apps entweder auf Emulatoren oder direkt auf angeschlossenen Geräten installiert, ausgeführt und debuggt werden. Das ist auch recht einfach und unproblematisch, da Visual Studio diese Funktion bereits mitbringt und vollautomatisiert ausführt.

Fertige Xamarin-Apps können wie native Apps in den plattformspezifischen App-Märkten (Google Play Store, Apple App Store, Amazon App Store, Windows Store, etc.) angeboten, installiert und aktualisiert werden. Der Veröffentlichungsprozess wird sehr detailliert in der offiziellen Xamarin-Dokumentation beschrieben. Dort gibt es sogar spezielle Abschnitte für Enterprise-spezifische Anwendungsfälle wie das In-House-Programm von Apple. Weitere Möglichkeiten sind die Installationen über E-Mail oder per Webseite.

Oberflächengestaltung

Die Oberfläche wird in XAML unter Verwendung Xamarin-spezifischer Tags entwickelt. Es gibt eine Oberflächen-Preview, die jedoch keine Erstellung), sondern lediglich eine Vorschau (d.h. die Erstellung muss stets über XAML erfolgen) unterstützt. Bei der Preview werden keine Navigationsleisten, Navigation, o.ä. unterstützt, was somit keine wirkliche Alternative zum Deployen der App ist. Bei der Verwendung von Xamarin.Forms muss beachtet werden, dass lediglich „der kleinste gemeinsame Nenner“ verwendet werden kann, d.h. plattformspezifische Funktionen bzw. Eigenschaften können nicht direkt in XAML verwendet werden (bspw. Toolbar-Subtitles in Android). Solch spezielle Funktionen müssten über Custom Renderer angesprochen werden, die wiederum die Entwicklung etwas komplexer machen.

Komplexität der Entwicklung

Zwar ist die Entwicklung durch die große Anzahl an Möglichkeiten relativ komplex, jedoch kann man auf eine sehr große Anzahl an Anleitungen, Tutorials und Beispielprojekten zurückgreifen. Auch die Community ist groß, jedoch kein Vergleich zu den Communities der nativen Technologien oder HTML/JSS/CSS. Für viele Anwendungsfälle (bspw. Fingerabdruckscanner) gibt es auch bereits fertige Demo-Apps.

Wartbarkeit

Bei der Entwicklung von Xamarin-Apps wird der Einsatz des MVVM Entwurfsmusters gefördert, was durch die Entkopplung von Belangen auf der Präsentationsschicht verbesserte Wartbarkeit mit sich bringt. Auch die strikte Trennung in XAML für die Oberflächengestaltung und C# für die Logik schafft einen strukturierten Aufbau.

Test-Unterstützung

Xamarin unterstützt das Schreiben und die Durchführung von Unit-Tests und UI-Tests. Der größte Vorteil von Xamarin ist jedoch die Xamarin Test Cloud, die es ermöglicht Apps auf bis zu 2.000 echten Endgeräten auszuführen und zu testen. Es lassen sich dabei auch Daten zu Ressourcennutzung und Performance erheben, die wiederum in die weitere Entwicklung einfließen können. Da es sich hierbei jedoch um ein separates Produkt von Xamarin handelt, fallen auch relativ hohe Kosten an.

Übertragbarkeit

Da Xamarin auf Basis von Mono mit C# geschrieben wird, lässt sich der geschriebene Quellcode nur sehr schwer auf andere Sprachen und Frameworks übertragen. Die in XAML geschriebene Oberfläche hingegen könnte prinzipiell in HTML oder ähnliche Sprachen transformiert werden, was jedoch mit großem Aufwand verbunden wäre und sicherlich nicht problemlos verliefe. Eine Austauschbarkeit wie bei der Verwendung von HTML/JSS/CSS ist somit nicht gegeben.

Geschwindigkeit und Kosten der Entwicklung

Prinzipiell ist die Entwicklung durch die Verfügbarkeit vieler Anleitungen, Beispielprojekte und guter Dokumentation recht schnell. Durch die Verwendung von C# lassen sich viele Dinge sehr elegant und einfach lösen, was die Entwicklung (bspw. verglichen mit Java) sehr erleichtert.

Probleme können jedoch mit Visual Studio oder NuGet auftreten, gerade da diese sehr umfangreich sind.

Probleme, die bei der Entwicklung der Referenz-App auftraten waren:

Bei der Installation einer Bibliothek über NuGet musste das gesamte Projekt in einen anderen Ordner verschoben werden, da der Pfad die von Windows erlaubten 256 Zeichen überstieg.
Bei der Verwendung des NuGet-Paketmanagers kann es zu Versionskonflikten kommen, die manuell behoben werden müssen. Dies ist eine sehr langwierige Aufgabe, da man zunächst durch Recherche oder Ausprobieren herausfinden muss, welche Pakete miteinander im Konflikt stehen.

Der Entwicklungsprozess wird etwas durch das Fehlen einer (ausgereiften und umfangreichen) Live-Preview-Funktion verlangsamt, da man bei jeder Änderung die App kompilieren muss und auf einen Emulator bzw. auf ein angeschlossenes Geräte deployen muss.

Quellen:

Xamarin, „Mobile Application Development to Build Apps in C# – Xamarin,“ 2017. [Online]. Available: https://www.xamarin.com/platform. [Zugriff am 6 Dezember 2017].

Xamarin, „Part 1 – Understanding the Xamarin Mobile Platform,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_-_understanding_the_xamarin_mobile_platform/. [Zugriff am 6 Dezember 2017].

Xamarin, „Xamarin.Mac Architecture,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/mac/under-the-hood/architecture/. [Zugriff am 6 Dezember 2017].

Microsoft, „Microsoft-Software-Lizenzbestimmungen,“ 2017. [Online]. Available: https://www.visualstudio.com/de/license-terms/mlt553321/. [Zugriff am 6 Dezember 2017].

Microsoft, „Visual Studio 2017-IDEs im Vergleich,“ 2017. [Online]. Available: https://www.visualstudio.com/de/vs/compare/. [Zugriff am 6 Dezember 2017]

Bugzilla, „Mono for Android Support on Linux,“ 2017. [Online]. Available: https://bugzilla.xamarin.com/show_bug.cgi?id=142. [Zugriff am 6 Dezember 2017].

Xamarin, „DependencyService,“ 2917. [Online]. Available: https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/dependency-service/. [Zugriff am 6 Dezember 2017].

Xamarin, „Binding a Java Library,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/android/advanced_topics/binding-a-java-library/. [Zugriff am 6 Dezember 2017].

Xamarin, „The Xamarin story,“ 2017. [Online]. Available: https://www.xamarin.com/about. [Zugriff am 6 Dezember 2017].

Xamarin, „Application Package Sizes,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/android/advanced_topics/application_package_sizes/. [Zugriff am 6 12 2017].

Xamarin, „In-House Distribution,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/ios/deployment,_testing,_and_metrics/app_distribution/in-house-distribution/. [Zugriff am 6 Dezember 2017].

Xamarin, „Publishing an Application,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/android/deployment,_testing,_and_metrics/publishing_an_application/. [Zugriff am 6 Dezember 2017].

Xamarin, „Custom Renderer,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/custom-renderer/. [Zugriff am 6 Dezember 2017].

Xamarin, „Uni Testing,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/unit-testing/ . [Zugriff am 6 Dezember 2017].

Xamarin, „Introduction to Xamarin.UITest,“ 2017. [Online]. Available: https://developer.xamarin.com/guides/testcloud/uitest/intro-to-uitest/. [Zugriff am 6 Dezember 2017].

Xamarin, „Mobile app testing made easy,“ 2017. [Online]. Available: https://www.xamarin.com/test-cloud. [Zugriff am 6 Dezember 2017].

Was bedeutet „Cross-Plattform“?

Der Begriff Plattformunabhängigkeit oder Cross-Plattform beschreibt die Eigenschaft einer Anwendung, auf verschiedenen Plattformen (z.B. iOS oder Android) ausgeführt werden zu können. Aus Sicht des Entwicklers wird dabei im Idealfall eine einzige Code-Basis verwendet.

Ansätze zur Entwicklung von Cross-Plattform-Applikationen

Aktuell sind verschiedene Ansätze im Bereich der Entwicklung cross-plattformfähiger Anwendungen üblich. Am gängigsten sind:

Web Apps (auch Progressive Web Apps): Entwicklung einer – für mobile Endgeräte optimierten – Webanwendung unter Verwendung von HTML, CSS und JavaScript. Da auf nahezu jedem Endgerät ein Webbrowser vorinstalliert ist, sind Web Apps auch unter nahezu jeder Plattform ohne Einschränkungen nutzbar. Vorteile sind die einfache Portabilität der App sowie die relativ simple Entwicklung durch Verwendung bekannter und standardisierter Web-Technologien. Gleichzeitig bietet die breite Verfügbarkeit zahlreicher Frameworks zur Erstellung (Angular, Bootstrap, React, Vue, etc.) der Anwendungen eine geringe Einstiegshürde. Nachteile sind der tendenziell, für Apps, nicht-native Look & Feel sowie die Tatsache, dass gerätespezifische Funktionen (bspw. GPS) nicht ohne weiteres verwendet werden können. Auch die Performance leidet im Vergleich zu nativen Anwendungen, da Web Apps auf jeder Plattform interpretiert werden müssen und nicht kompiliert vorliegen.
Hybride Apps: Hierbei handelt es sich ebenfalls um Apps, die auf Webtechnologien (HTML, CSS und JavaScript) aufbauen. Die Apps greifen auf den unterschiedlichen Endgeräten auf speziell modifizierte, nativen Browser (ohne Adresszeile und ähnliche Steuerelemente) zurück, um die App-Oberfläche darzustellen. Anders als bei reinen Web Apps, bieten Frameworks wie Apache Cordova oder Adobe PhoneGap die Möglichkeit auch gerätespezifische Funktionen des Geräts (bspw. GPS) und native Steuerelemente leicht einzubinden. Vorteile sind die relativ einfache Entwicklung und die gute Portabilität auf unterschiedliche Plattformen. Nachteile können – je nach Anwendungsfall und verwendetem Framework – der fehlende native Look & Feel und auch die etwas schlechtere Performance gegenüber nativen Apps sein. Besonders der Performanceunterschied ist mittlerweile meist nur noch marginal und für den Endnutzer praktisch nicht spürbar.
Nativartige Apps: Entwicklung von Apps mit vollständig nativer Benutzeroberfläche, jedoch gemeinsamer Code-Base unter Verwendung von Frameworks wie Xamarin oder Titanium. Vorteile sind der native Look &Feel sowie die hohe Performance. Nachteile sind der potenziell erhöhte Entwicklungsaufwand und die gestiegene Komplexität des Entwicklungsprozesses, da gegebenenfalls auch plattformspezifischer Code geschrieben werden muss.

Die nachfolgende Grafik veranschaulicht die Funktionsweise dieser Technologien nochmals:

Cross-Platform-App-Development-Tools (CPAD)

Als Cross-Platform-App-Development-Tools (CPAD) bezeichnet man eine Sammlung von Technologien und Werkzeugen, die es einem Entwickler ermöglichen, den gesamten oder einen Teil des Quellcodes einer Anwendung für verschiedene Plattformen (Windows, MacOS, Android, iOS, etc.) wiederverwendbar zu entwickeln oder eine geteilte Code-Basis dafür zu verwalten. Durch ihre Verwendung kann der Entwickler den Entwicklungsaufwand signifikant reduzieren und damit die Entwicklungskosten senken, um gleichzeitig eine große Zielgruppe von Benutzern anzusprechen. Durch die große Popularität mobiler Endgeräte und die gestiegenen Ansprüche der Nutzer erfreuen sich CPAD-Tools immer größerer Beliebtheit gegenüber der Entwicklung mit den jeweiligen plattformspezifischen SDKs.

Im weiteren Verlauf der Beitragsreihe werden folgende 4 CPAD Umgebungen anhand einer einheitlichen Test App kurz vorgestellt. Wir wollen Euch dabei die Umgebungen Ionic, Xamarin, React Native und Oracle Jet vorstellen.

Frameworkvergleich mithilfe einer Test-App

Im Zusammenhang mit den verschiedenen CPAD Umgebungen und unserer Test-Anwendung werden wir die Vorteile und Nachteile der jeweiligen Umgebungen beleuchten. Dabei ist es geplant auch native Funktionen wie Kamera, GPS aber auch Push-Benachrichtigungen und weiteres zu demonstrieren. Wir möchten euch so einen umfassenden Vergleich der verschiedenen Umgebungen bieten. Die nachfolgenden Vergleichskriterien werden Euch daher wiederholt begegnen.

Bewertungskriterien der Infrastruktur

Lizenzen und Kosten: Unter welcher Lizenz wird das Framework verteilt und welche Kosten sind zu erwarten?
Unterstützte Plattformen: Welche Plattformen (mobil und stationär) werden unterstützt und in welchem Umfang?
Unterstützte Entwicklungsplattformen: Welche Plattformen (Windows, macOS, Linux) werden bei der Entwicklung unterstützt?
Zugriff auf plattformspezifische Funtionen: Auf welche plattformspezifischen Funktionen (bspw. GPS) kann zugegriffen werden und wie?
Langzeitunterstützung: Wie aktiv wird das Framework unterstützt? Wie zukunftssicher ist es?
Look & Feel: Wie wirkt die Benutzeroberfläche auf den Endnutzer? Fügt sich die App in die jeweilige Plattform ein?
Performance und Ressounrcennutzung: Wie schnell startet und reagiert die App? Wie viel Arbeitsspeicher und Gerätespeicher belegt die App?
Verteilung & Deployment: Wie kann die App verteilt, deployet und geupdatet werden und wie einfach ist dies?

Bewertungskriterien der Entwicklung:

Entwicklungsumgebung: Welche Funktionen bietet die Entwicklungsumgebung, wie ausgereift und wie einfach zu installieren ist sie?
Oberflächengestaltung: Wie einfach ist die Gestaltung der Oberfläche? Gibt es einen dedizierten Editor für das UI-Design?
Komplexität der Entwicklung: Wie einfach ist die Entwicklung allgemein? Wie gut ist die Dokumentation, Community-Diskussion, Beispielcode, etc.?
Wartbarkeit: Wie einfach kann die App gewartet werden?
Test-Unterstützung: Wie einfach kann die Businesslogik und Oberfläche der App getestet werden?
Übertragbarkeit: Kann Quellcode bei anderen Ansätzen (d.h. Frameworks) wiederverwendet werden?
Geschwindigkeit und Kosten der Entwicklung: Wie schnell ist der Entwicklungsprozess? Gibt es Faktoren, die den Prozess maßgeblich behindern?

Wie geht es weiter?

Im nächsten Beitrag möchten wir euch die Grundsätze der App-Entwicklung näher bringen. Auch hier legen wir den Fokus bereits auf die Cross-Platform-Entwicklung. Zusätzlich veröffentlichen wir nach und nach jeweils einen spezifischen Beitrag zu den vier Frameworks. Hierbei gehen wir dann im Zusammenhang mit unserer Test-App gezielt auf die Stärken und Schwächen des jeweiligen Ansatzes ein. Wir planen auch, den Quellcode unserer Test-App auf GitHub bereitzustellen. Ih könnt unsere Test-Apps daher auch einfach selbst nachbauen oder clonen.

Wo finde ich in der Zwischenzeit noch weitere Informationen zum Thema?

Heitkötter, Henning; Hanschke, Sebastian; Majchrzak, Tim A, „Evaluating Cross-Platform Development Approaches for Mobile Applications,“ in International Conference on Web Information Systems and Technologies, 2012, pp. 120-138
V. Ahti, S. Hyrynsalmi und O. Nevalainen, „An Evaluation Framework for Cross-Platform Mobile App Development Tools,“ in Computer Systems and Technologies, 2016, pp. 41-48
A. Charland und B. Leroux, „Mobile application development,“ 2011
T. Y. Adinugroho, Reina und J. B. Gautama, „Review of Multi-platform Mobile Application Development Using WebView,“ Procedia Computer Science 59, pp. 291-297
Hybride oder Native Anwendungen?
M. Palmieri, I. Singh und A. Cicchetti, „Comparison of cross-platform mobile development tools,“ 16th International Conference on Intelligence in Next Generation Networks, 2012
Oracle Jet im Blog

Xamarin

Beitragsreihe zu Cross-Plattform: 3. Xamarin