Swift SDK für Android angekündigt
(swift.org)- Die Swift-Sprache ist gereift und hat sich auf Cloud, Windows, Browser und Mikrocontroller ausgeweitet; nun wurde auch das Swift SDK für Android vorgestellt
- Dieses SDK ist das Ergebnis monatelanger Arbeit der Swift Android Workgroup und ermöglicht es Entwicklerinnen und Entwicklern, native Android-Apps mit Swift zu entwickeln
- Das SDK ist im Windows-Installer enthalten oder kann separat für Linux und macOS heruntergeladen werden; Beispielcode und Anleitungen werden ebenfalls bereitgestellt
- Über das swift-java-Projekt wird bidirektionale Interoperabilität zwischen Swift und Java unterstützt; automatisch erzeugte Bindings sorgen für Leistung und Sicherheit
- Die Veröffentlichung beschleunigt den Ausbau des plattformübergreifenden Swift-Ökosystems und gilt als Wendepunkt, der neue Möglichkeiten in der mobilen Entwicklung eröffnet
Überblick über das Swift SDK for Android
- Vor dem Hintergrund, dass sich die Swift-Sprache in den vergangenen zehn Jahren von Cloud-Services über Windows und Browser bis hin zu Mikrocontrollern ausgedehnt hat, wird der Schritt auf die Android-Plattform nun offiziell
- Dank der Interoperabilität von Swift lässt sich Code leicht zwischen verschiedenen Plattformen teilen
- Die Android Workgroup ist eine offene Gruppe, an der sich alle beteiligen können, und verfolgt das Ziel, Swift auf Android auszuweiten
- Mit dieser Ankündigung wird ein Nightly-/Preview-Build des Swift SDK for Android veröffentlicht; sie ist das Ergebnis langjähriger Zusammenarbeit der Community
Zentrale Funktionen und Bereitstellung des SDK
- Entwicklerinnen und Entwickler können nun mit Swift direkt native Android-Anwendungen entwickeln
- Dadurch eröffnen sich neue Möglichkeiten für die plattformübergreifende Entwicklung
- Das SDK wird gebündelt mit dem Windows-Installer ausgeliefert und ist separat für Linux und macOS verfügbar
- Swift.org erklärt im „Getting Started“-Guide, wie sich Swift-Code für Android-Geräte einrichten lässt
- Im GitHub-Repository Swift for Android Examples wird ein End-to-End-App-Workflow demonstriert
Paketkompatibilität und Ausbau der Community
- Mit dem Swift SDK lassen sich bestehende Swift-Pakete auf Android portieren
- Bereits mehr als 25 % der Pakete im Swift Package Index unterstützen Android-Builds
- Auf der Seite Community Showcase wird die Android-Kompatibilität angezeigt
- Diese Erweiterung stärkt die Multiplattform-Unterstützung im Swift-Ökosystem
Das swift-java-Projekt und Interoperabilität
- Das swift-java-Projekt ist eine Bibliothek und ein Codegenerator, die Interoperabilität zwischen Swift und Java bereitstellen
- Es verarbeitet die bidirektionale Integration zwischen Swift und Java automatisch und erzeugt sichere, leistungsfähige Bindings
- Entwicklerinnen und Entwickler können damit Business-Logik auf Android portieren; weitere Informationen finden sich im Vortragsvideo des Swift Server Side Meetup
Beteiligung der Community und künftige Roadmap
- Diese Preview-Veröffentlichung eröffnet neue Chancen für Tooling-Verbesserungen und den Ausbau des Ökosystems
- Im Android-Bereich des Swift-Forums wird dazu ermutigt, Erfahrungen, Ideen, Tools und Apps zu teilen
- Die Ankündigung wird auch im offiziellen Thread des Forums diskutiert
- Die Android Workgroup arbeitet derzeit an einem Vision-Dokument, das Prioritäten und die künftige Ausrichtung von Swift on Android festlegen soll
- Über das Projektboard lässt sich der Fortschritt zentral nachverfolgen, und mit dem offiziellen CI-System wird die Qualität des SDK gesichert
- Das Swift-Team ruft die Community zur Beteiligung auf und verfolgt das Ziel, Swifts Stellung im Android-Ökosystem zu stärken
1 Kommentare
Hacker-News-Kommentare
Die Kernfrage bei jedem Cross-Platform-Framework ist, wie die UI gehandhabt wird.
Wenn man wie bei Adobe Flex Builder ein Designsystem nutzt, das sich auf jeder Plattform fremd anfühlt, muss man am Ende das native Look-and-Feel doch selbst nachbauen.
Flutter versucht, das iOS-Cupertino-Theme perfekt nachzubilden, und React Native nutzt die Standard-Widgets der Plattform, damit sich Dinge wie Scrollen natürlich anfühlen.
Schade, dass dieser wichtige Punkt im Blogpost nicht erwähnt wird.
Selbst wenn Apple Swift für Android herausbringt, könnte es sich auf Android wegen Apples eigener Designphilosophie immer noch ungewohnt anfühlen.
Ob dieses Projekt direkt von Apple geführt wird oder eher ein Community-getriebener Open-Source-Versuch ist, dürfte die weitere Richtung bestimmen.
Deshalb gefällt mir KMP. Auf iOS kann man die UI mit SwiftUI schreiben, auf Android mit Kotlin, und nur die Business-Logik wird geteilt.
Wenn man versucht, die UI zu teilen, endet das oft im Albtraum „einmal schreiben, überall debuggen“.
Swift for Android scheint so etwas wie sprachbasiertes Teilen von Logik zu ermöglichen.
Selbst in den Beispielen wird Jetpack Compose unverändert verwendet und dabei Swift-Logik aufgerufen.
Es behält dieselbe Struktur wie Swifts referenzzählendes Speichermodell bei, was für mehr Konsistenz sorgt.
Aus Sicht von Apple, wo man für Entwickler-Tools verantwortlich ist, hoffe ich, dass diese Technik zur Grundlage neuer Innovationen wird.
SwiftUI ist ursprünglich keine „native UI“, sondern eine deklarative Sprache, die vom System interpretiert wird, um UIView oder NSView zu erzeugen.
Wenn man sie nicht wie Flutter direkt nachbaut, ist es unmöglich, Apple-UI auf Android unverändert zu verwenden.
Stattdessen übernehmen Projekte wie Skip.tools das Bridging von SwiftUI zu Jetpack Compose.
Ein Beispiel dafür sieht man in der Skip Showcase App.
Ich arbeite an Skip-Produkten, bin Mitglied der Swift Android Workgroup und war bei diesem SDK der Release Manager.
Ich freue mich sehr, dass es als offizielles Projekt angekündigt wurde.
Ich habe RN und Flutter ausprobiert, aber das Problem war immer das fehlende native Look-and-Feel.
Es gibt zwar KMP, aber die meisten Entwickler starten mit iOS und erweitern dann auf Android.
Wenn man Code über Swift Package teilt, wird dieser Ablauf viel natürlicher.
Dagegen gibt es viel weniger Swift-/Objective-C-Entwickler.
Außerhalb der USA ist der iPhone-Marktanteil geringer, daher denken Unternehmen oft eher Windows- oder browserzentriert.
KMP wird bereits in großen Apps wie Google Workspace eingesetzt, und dank Kotlin sowie der Investitionen von JetBrains ist der Reifegrad hoch.
Bei Flutter war der Release-Zyklus so schnell, dass es schwer war, mitzuhalten.
Mit JavaScriptCore oder QuickJS läuft sie auf iOS, Android und im Web, und Hot Reload ist möglich.
Wegen der App-Store-Richtlinien sind größere Funktionsänderungen zwar schwierig, aber für Bugfixes ist das gut geeignet.
Angesichts der langsamen Release-Zyklen bei Mobile Apps halte ich diesen Ansatz für eine große Chance.
Eine Struktur aus gemeinsamer Core-Library plus nativen UI-Projekten pro Plattform funktioniert gut.
Ich habe mich gefragt, ob das mit dem SKIP-Transpiler zusammenhängt, von dem ich im Skip.tools-Blog gelesen habe.
Ich wollte eine SwiftUI-App nach Android bringen, RN aber vermeiden.
Skip hat zwei Modi: den Lite-Modus, der Swift-Code nach Kotlin konvertiert, und den Fuse-Modus, der Swift direkt für Android kompiliert.
Beide Modi lassen sich zusammen nutzen, um das Kotlin-Ökosystem etwa mit Lottie oder Firebase zu integrieren.
Einen detaillierten Vergleich gibt es in den Skip Docs.
Ich freue mich, dass nun das offizielle SDK verfügbar ist und wir statt eigener Builds die offizielle Version verwenden können.
Hoffentlich endet das nicht wie Swift Embedded nur auf dem Niveau eines einfachen Proof of Concept.
Swift ist als Sprache elegant, aber es gibt eine gewisse Unruhe beim Vertrauen in die Community-Führung.
Ich möchte RN und Flutter langsam nicht mehr sehen.
Diese kantige UI und die träge Touch-Reaktion gehen mir auf die Nerven.
Wenn sich etwas träge anfühlt, liegt das wahrscheinlich an der Implementierung der App.
Apple könnte auch schnell wieder das Interesse verlieren.
„You got Kotlin in my iOS.“
„You got Swift in my Android.“ — eine witzige Formulierung.
Siehe Kotlin Native Overview.
Diese Ankündigung wirkt wie ein Erfolgsbeweis für das neue Swift-SDK-System.
Früher war die Unterstützung anderer Plattformen wegen der Verstrickungen mit CMake kompliziert, aber jetzt sollte eine Portierung auf jede Plattform möglich sein, solange man den SDK-Regeln folgt.
Geplant ist eine Ausweitung nicht nur auf Android, sondern auch auf Linux, wasm, embedded und bald Windows.
Die Interoperabilität mit der JVM ist noch nicht vollständig, aber die Plattformunabhängigkeit ist klar gewachsen.
Ich mag Kotlin Multiplatform, aber Swift for Android finde ich ebenfalls spannend.
Für speicherkritische Aufgaben dürfte es nützlich sein, native Swift-Bibliotheken zu teilen.
Für die komplette Business-Logik in Swift ist KMP aber wohl noch reifer.
Das Teilen der Business-Logik war eigentlich schon gelöst.
Der eigentliche Schmerzpunkt war, die UI zweimal schreiben zu müssen.
Nötig wäre ein gemeinsames UI-Framework, das nicht so umständlich ist wie React Native.
Zusammen mit Expo hat sich die Developer Experience stark verbessert.
Ich teile schon lange Code zwischen Android und iOS, aber gemeinsame UI war immer ein Albtraum.
Komplexe Logik habe ich nur in C/C++/Rust geteilt, wodurch es am Ende gleich drei Sprachen wurden.
KMP und Swift for Android machen es viel sauberer, weil man nur noch Kotlin bzw. Swift teilen muss.
Dieser Ansatz ist viel realistischer und effizienter als Frameworks, die UI mit Gewalt gemeinsam nutzbar machen.