Swift for Android – vollständige native App-Entwicklung für Android mit Swift

• Ein Framework, mit dem sich native Android-Apps ausschließlich mit Swift entwickeln lassen; von der UI über das Manifest bis zum Lifecycle ist alles in einer einzigen Sprache aufgebaut
• Bietet eine Struktur, um Android-UIs deklarativ zu erstellen, ganz ohne XML, Java oder Kotlin
• Funktioniert als reines natives Android-Framework, nicht als Web-Wrapper oder Transpiler
• Die UI kann mit einer an SwiftUI angelehnten deklarativen Syntax definiert werden, während die komplexe JNI-Schicht vollständig verborgen bleibt
• Bietet ein integriertes Entwicklungserlebnis, bei dem selbst Android-Manifest und Gradle-Konfigurationen direkt in Swift-Code definiert werden
• Eine neue native Alternative für Swift-Entwickler, die auf Android erweitern wollen, und ein Wendepunkt mit neuen Möglichkeiten für plattformübergreifende Entwicklung auf Swift-Basis

---

Überblick über Droid

• Droid ist ein Framework, das dafür entwickelt wurde, native Android-Anwendungen allein mit der Sprache Swift zu entwickeln
• UI, App-Konfiguration, Lifecycle und Manifest werden in einer Sprache und einer Codebasis verwaltet
• Die bei der Android-Entwicklung bislang als unverzichtbar geltenden Abhängigkeiten von XML, Java und Kotlin entfallen
• Enthält native Android-Komponenten wie AndroidX, Flexbox und Material Design
• Bietet eine deklarative Syntax ähnlich wie SwiftUI und vereinfacht damit die Definition von UIs
• Verbirgt die JNI-Schicht vollständig und ermöglicht den Zugriff über eine High-Level-API

Designziele und Merkmale

• Auf Basis von Pure Swift werden UI, Manifest und die gesamte App-Konfiguration in Swift geschrieben
• Verwendet eine deklarative UI, bei der Lesbarkeit und Kombinierbarkeit im Vordergrund stehen
• Verfolgt einen No XML-Entwicklungsansatz ganz ohne XML
• Setzt auf ein natives Android-Ausführungsmodell statt auf webbasierte Ansätze oder Code-Transformation
• Bietet eine integrierte Struktur, in der UI, Manifest und Gradle-Abhängigkeiten an einer Stelle definiert werden

Aufbau einer deklarativen UI

• Android-UIs werden deklarativ mit einer Swift-freundlichen API aufgebaut
• Android-Widgets wie ConstraintLayout, VStack, TextView und MaterialButton werden in Swift-Code ausgedrückt
• Layout-Constraints, Klick-Events und Style-Einstellungen werden direkt im Code definiert

Android Manifest in Swift schreiben

• Das Android Manifest selbst wird als Swift-Code deklariert
• App-Symbol, Theme, Activity- und Fragment-Konfigurationen werden auf Code-Ebene verwaltet
• Lifecycle-Event-Verarbeitung und Konfigurationslogik werden in einer einzigen Swift-Datei integriert

Dokumentation und Entwicklungsumgebung

• Offizielle Dokumentation ist vorhanden und wird kontinuierlich erweitert
• Zwar ist noch nicht die gesamte Android-Funktionalität dokumentiert, vorhandene Leitfäden werden jedoch in aufbereiteter Form bereitgestellt
• Mit der Swift Stream IDE kann sofort mit der Entwicklung begonnen werden

Unterstützungsumfang

• Unterstützung für klassische Android-Widgets
• Unterstützung für AndroidX-Bibliotheken
• Unterstützung für Material-Design-Komponenten
• Unterstützung für Flexbox-Layouts

Projektstatus

• Das Projekt wird aktiv weiterentwickelt und entwickelt sich schnell weiter
• Die API wird mit Blick auf Erweiterbarkeit verbessert, während die Kernvision bestehen bleibt
• Feedback und Mitwirkung sind ausdrücklich erwünscht

[GN⁺]

Hacker-News-Kommentare

• Swift Stream IDE v1.17.0 wurde veröffentlicht. Damit ist jetzt die vollständige Entwicklung nativer Android-Apps nur mit Swift möglich
  XML, Java und Kotlin müssen überhaupt nicht angefasst werden. Intern übernimmt mein SwifDroid-Framework den Android-Lebenszyklus, Activity, Fragment, UI-Widgets (Material, Flexbox usw.) und verwaltet auch Gradle-Abhängigkeiten automatisch
  Es kompiliert Swift-Code und erzeugt ein Projekt, das sich direkt in Android Studio ausführen lässt. Sowohl Tool als auch Framework stehen unter der MIT Open Source-Lizenz

  • Interessant. Mich würde interessieren, wo der Schnittpunkt zwischen der für Swift-Entwickler nötigen Android-Erfahrung und der für Android-/Kotlin-Entwickler nötigen Swift-Erfahrung liegt
    Es heißt, man müsse XML, Java und Kotlin nicht anfassen, aber ich frage mich, ob auch Swift-Entwickler ohne jede Android-Erfahrung erfolgreich Apps bauen können
    Außerdem würde ich gern wissen, wie viel Prozent der Kotlin- oder Flutter-Apps man heute und im nächsten Jahr ungefähr in Swift schreiben könnte
  • Eine der Stärken von Swift ist die Interoperabilität mit C/C++-Bibliotheken. Diese werden meist als SwiftPM- oder Bazel-Abhängigkeiten bereitgestellt; mich würde interessieren, wie SwiftPM-Abhängigkeiten behandelt werden
  • Mich würde interessieren, wie Java-/Kotlin-Code nach Swift gebunden wird
    Wir versuchen etwas Ähnliches gerade mit Rust statt Swift
  • Glückwunsch. Ich hatte auch darüber nachgedacht, meine Entwicklungsumgebung mit Swift zu vereinheitlichen, und das ist wirklich großartige Arbeit

• Solche Versuche müssen am Ende über JNI gehen, daher sind sie dadurch eingeschränkt, dass 80 % der API nur in Java offengelegt sind
  Solche Projekte sind immer interessant, stoßen aber letztlich auf das Problem der durchlässigen Abstraktion (leaky abstraction)
  Genauso wie man unter iOS Objective-C kennen muss und unter Windows .NET/COM

  • Heutzutage muss man selbst im Apple-Ökosystem sowohl Swift als auch Objective-C beherrschen, um erfolgreich zu sein
    Aus meiner Erfahrung mit Unity heraus läuft das Marshalling von C# nach C reibungslos, bei Swift ist der Aufwand aber deutlich größer
    In der Praxis muss man für jedes neue Framework separat nachziehen

• Eine plattformübergreifende gemeinsame Sprache wie Swift oder Kotlin zu verwenden, sieht auf den ersten Blick gut aus, ist in der Praxis aber meiner Meinung nach nicht so effizient wie erwartet
  Am Ende pflegt man doch zwei Codebasen, und durch all die Unterschiede und Workarounds ist es oft besser, einfach jede Sprache so zu verwenden, wie sie gedacht ist
  Die meisten Entwickler bauen ihre Karriere ohnehin mit mehreren Sprachen auf, und der Wechsel ist nicht besonders schwierig. Das ist nur meine persönliche Meinung, aber das Projekt selbst finde ich großartig

  • Trotzdem ermöglichen solche Versuche es Ingenieuren, die mit einer Plattform vertraut sind, auch auf einer anderen Plattform zu arbeiten
    Ich habe früher einmal ein paar Monate lang versucht, native Android-Apps mit Java zu entwickeln, aber es hat mir keinen Spaß gemacht, also habe ich aufgegeben
    Ich bevorzuge vollständig native Entwicklung und habe über Jahrzehnte hinweg plattformübergreifende Frameworks genutzt, ohne dabei große Erfolge zu sehen
    Ein Sprachwechsel bringt immer Kosten für den Kontextwechsel mit sich. Wenn ich zwischen Swift und PHP hin und her entwickle, mache ich ständig Syntaxfehler
    Eine Sprache lernt man schnell, aber um SDKs, Standardbibliotheken und Frameworks zu beherrschen, braucht man sehr lange
  • Solche Frameworks beschleunigen einfache Feature-Entwicklung, sind aber eher ein Hindernis, sobald man plattformspezifische Funktionen nutzen will
    Gerade heute ist die Geschwindigkeit bei einfachen Aufgaben dank AI-Tools ohnehin schon hoch, daher ist die Einsparung bei der Gesamtentwicklungszeit nicht so groß
    Wenn die App faktisch nur eine Web-App ist, mag das anders sein, ansonsten würde ich es nicht empfehlen
  • Kotlin und Swift sind sehr ähnlich, und ich denke, bei den Unterschieden ist es sogar besser, gar nicht zu abstrahieren
    Sprachlich halte ich Swift für besser, aber KMP ist älter und stabiler, daher würde ich in der Praxis wohl eher dazu greifen
  • Mehrere Sprachen zu beherrschen gibt einem eher Freiheit
    Ich möchte mich aber ungern noch stärker an das Ökosystem eines bestimmten Großkonzerns binden
    Außerdem finde ich Swift persönlich eine unangenehme Sprache, deshalb möchte ich sie nicht auch noch auf anderen Plattformen verwenden

• Mich würde interessieren, wie es sich im Vergleich zu Skip verhält
  Dieses Projekt scheint nicht darauf abzuzielen, iOS-SwiftUI-Code auf Android zu übertragen, sondern auf Swift-Entwicklung speziell für Android
  Ich würde gern wissen, ob das zu besserer App-Qualität führen kann und ob es dafür reale Beispiele gibt

• Schon allein die Tatsache, dass man Android Studio oder IntelliJ nicht benutzen muss, halte ich für eine große Verbesserung. Tolle Arbeit

  • Xcode zu benutzen, um Android zu vermeiden, wirkt auf mich wie die Entscheidung, mit Salzsäure zu hantieren
  • Ich frage mich, ob man auch Gradle vermeiden kann. Mich würde interessieren, ob man diesen Albtraum der Abhängigkeitsverwaltung überspringt

• Das Cookie-Einwilligungsfenster wirkt auf mich nicht konform mit europäischem Recht

• Ich verstehe nicht, warum mobile Entwicklung im Vergleich zum PC so umständlich ist
  Ich frage mich, warum es auf Mobilgeräten schon so schwierig ist, nur ein Hello World in Assembler zu bauen

  • Möglich ist es. Aber es ist genauso schmerzhaft, wie auf dem PC ein Hello World in Assembler zu bauen, deshalb macht es niemand

• Ich habe eine Weile Pause von Android-Entwicklung gemacht; wenn ich den heutigen Stand zusammenfasse:
  Früher war iOS Swift und Android Java
  Heute ist es statt Java Kotlin, dazu gibt es plattformübergreifende Frameworks wie Flutter oder React Native
  Mich würde interessieren, ob Swift on Android eine weitere Abstraktionsschicht wie diese ist oder eher nah an nativ bleibt
  Ist am Ende nicht nativer Code immer am schnellsten?

  • React Native basiert nicht auf WebViews. Es ist eine native Übersetzungsschicht, die JSX in SwiftUI-/Kotlin-UI-Code umwandelt
    Ich persönlich bevorzuge Flutter. Viele native Android-Entwickler sagen auch, dass Flutter die Zukunft der Android-Entwicklung sein könnte
    Siehe dazu diesen Reddit-Thread

• Dieses Projekt verfolgt einen anderen Ansatz als SwiftCrossUI oder Skip
  SwiftCrossUI und Skip führen SwiftUI auf mehreren Plattformen unverändert aus,
  während SwifDroid darauf zielt, Android-spezifische UI in Swift zu schreiben
  Es verwendet direkt das Android-View-System und die APIs und will vollständige Android-Apps in Swift ohne Java/Kotlin/XML ermöglichen
  Es geht also nicht um „einmal schreiben, überall ausführen“, sondern darum, eine native Android-Erfahrung in Swift umzusetzen

• Mich würde interessieren, wie man in Swift idiomatisch mit HTTP-Anfragen und JSON-Parsing umgeht