Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Stellt Apple Swift für Android vor?

Es ist fünfzehn Jahre her, dass Chris Lattner mit der Arbeit an Swift begann. Offiziell vorgestellt wurde der designierte Nachfolger von Objective-C auf der WWDC 2014, im Dezember 2015 erschien die Programmiersprache mit einer Open-Source-Lizenz (Apache 2.0). Hauptsächlich dient sie dazu, eine einheitliche Programmiersprache für sämtliche Apple-Plattformen zu bieten. Doch auch für Linux und Windows steht Swift zur Verfügung, und Embedded Swift kann Microcontroller steuern. Zeitnah soll sich Swift-Code zudem leichter in Android-Apps integrieren lassen. Darum kümmert sich eine Arbeitsgruppe, die jüngst ins Leben gerufen wurde.

Die Swift Android Workgroup hat sich eine umfangreiche Liste an Aufgaben gesetzt. Generell will man Android-Unterstützung in der offiziellen Swift-Distribution verbessern und aufrechterhalten. Zudem sollen Empfehlungen entstehen, um das Programmieren in Swift für Android reibungsloser zu gestalten. Dazu gehören Verbesserungen an essenziellen Paketen wie Foundation und Dispatch. Offenbar befindet sich das Projekt in einer frühen Phase, denn viele Zielsetzungen sind sehr abstrakt. So will die Android Workgroup in Zusammenarbeit mit der „Platform Steering Group“ zunächst Support-Ebenen definieren, um diese dann strukturiert umzusetzen. Auch Konzepte wie Packaging, Continuous Integration sowie Debugging von in Swift umgesetzten Android-Apps stehen auf der To-Do-Liste der frisch gegründeten Arbeitsgruppe.

Neues Forum, Meeting alle zwei Wochen
Die Workgroup hat einen eigenen Bereich im Swift-Forum. Zusätzlich halten die Teilnehmer in ungeraden Kalenderwochen zur Ostküsten-Mittagszeit (das entspricht 18:00 mitteleuropäischer Zeit). Das derzeitige Team besteht aus zehn Mitgliedern des Swift-Forums; man freut sich aber über Zuwachs. Die Inhalte des Unterforums stehen offen im Netz; wer bereits Mitglied des Swift-Forums ist, kann Fragen stellen und sich beteiligen – und auf Antrag auch an den (virtuellen) Treffen teilnehmen.

Erleichterung (nicht nur) für App-Entwickler
Wer mobile Apps anbietet, will sowohl unter iOS als auch unter Android vertreten sein. Während Google das für Java optimierte Kotlin empfiehlt, setzt Apple seit 2014 auf Swift. Es gibt einige Anbieter, die versprechen, funktionierende Apps für beide Plattformen aus einer Code-Basis zu erstellen – mehr oder weniger erfolgreich. Ein reibungslos in Android-Projekte integrierbarer Swift-Code könnte App-Entwicklern einige Arbeit ersparen. Nebenbei haben Apples hauseigene Entwickler ein Interesse daran, Android-Apps mittels Swift umzusetzen: Mit Apple Music, Apple TV sowie dem Migrationsassistenten veröffentlicht der Konzern selbst Titel im Play Store von Google.

Jony Ives geheimes KI-Projekt: Gerichtsunterlag...

iOS 26 beschert Apple Music viele Neuerungen: A...

Steve Jobs: Stanford-Rede

Bloomberg: Erste Gerüchte zu M6-, M7- und impos...

Neuer Sonos-Chef: „Wir haben die wirkliche Welt...

Bericht: iPhone 17 mit drei unterschiedlichen C...

Bloomberg: Interne Siri-Entwicklung vor dem Sch...

Mac-Tipp: Was landet nicht in einem Time-Machin...

Kommentare

aMacUser01.07.25 08:48

Ich bin ja mal gespannt, ob Apple dann auch SwiftUI für Android bereitstellt, und ob sich das dann auch nach Material Design styled. Denn das wäre mal genial. Dann bräuchte man wirklich nur noch eine einzelne Code-Basis.

MLOS01.07.25 09:03

aMacUser

SwiftUI ist leider, von dem, was ich bisher gehört habe, viel zu beschränkt und qualitativ teils eher unterirdisch. Der Ansatz ist natürlich cool. Hoffen wir, dass SwiftUI brauchbarer wird.

LoCal01.07.25 09:59

MLOS

Der Ansatz ist natürlich cool.

Ernst gemeinte Frage, was findest du am “SwiftUI-Ansatz” cool?
Seit der Vorstellung von SwiftUI Frage ich mich, warum man dieses Paradigma für Geräte gewählt hat, deren Inhalte ehr dynamisch als statisch sind.
Bestes Beispiel dürften ScrollViews sein, dort auf Änderungen zu reagieren ist mehr als pain in the Ass, mit iOS17 wird es zwar leicht besser, aber das Paradigma von SwiftUI macht es immer noch unfassbar hässlich dynamische UIs zu generieren.

Der deklarative Ansatz passt gut ins Web, aber nicht so gut zu macOs, iOS und Co.

Ich hab zwar keine Lösung, doch ich bewundere dein Problem

milk01.07.25 10:25

Es gibt inzwischen Kotlin Multiplatform, was recht problemlos auf iOS läuft. Damit haben wir plattformübergreifenden Code geschrieben. Das funktioniert erstaunlich gut, solange man keine GUIs braucht.

aMacUser01.07.25 10:27

LoCal

MLOS

Der Ansatz ist natürlich cool.

Ich fange gerade an mit SwiftUI-Entwicklung (ohne nennenswerte Vorbelastung durch UIKit) und finde den Ansatz super. Bisher komme ich mit SwiftUI auch noch sehr gut klar (wobei ich auch noch keine sehr komplexen Dinge habe).
Ich würde behaupten, dass sich die Leute eher deswegen beschweren, weil sie jetzt einfach seit Jahrzehnten den bisherigen Ansatz gewohnt waren. Das neue ist einfach ungewohnt, aber es hat einige Vorteile. Zum Beispiel kannst du einmal eine Oberfläche bauen und mit ein paar Anpassungen auf allen Betriebssystemen ausführen. Ich komme aber auch aus der Web-Welt und bin diesen Ansatz gewohnt. Ich habe zwar auch mal ein paar Jahre Desktop-Entwicklung gemacht, aber bin mit GUI-Buildern nie so richtig warm geworden.

aMacUser01.07.25 10:28

milk

Aber wann braucht man Mobil denn keine GUI?

milk01.07.25 10:38

aMacUser

Aber wann braucht man Mobil denn keine GUI?

Bei den Sachen, die Daten verwalten oder berechnen zum Beispiel. Lediglich das Ergebnis wird an die GUI gegeben, und die ist „vernünftig“ nativ entwickelt.

Wenn man eine ordentliche Trennung der Schichten hat, selbst wenn es nur MVC ist, dann sollte ein guter Teil des Codes nicht direkt mit dem GUI zu tun haben.

LoCal01.07.25 11:12

aMacUser

Aber genau das ist ja das Problem an SwiftUI. “Einfache” Dinge gehen schnell und sind auch kein Problem. Aber wenn es komplexer wird, dann ist SwiftUI wirklich ein riesiger Schmerz.
Und auf einen kompletten Entwicklungszeitraum einer App gesehen, würde ich SwiftUI auch keine Vorteile zuschreiben.

aMacUser

Ich würde behaupten, dass sich die Leute eher deswegen beschweren, weil sie jetzt einfach seit Jahrzehnten den bisherigen Ansatz gewohnt waren. Das neue ist einfach ungewohnt, aber es hat einige Vorteile. Zum Beispiel kannst du einmal eine Oberfläche bauen und mit ein paar Anpassungen auf allen Betriebssystemen ausführen.

Naja, AppKit und UIKit sind mittlerweile so angeglichen, dass ich mal die steile These aufstelle, dass man das auch mit AppKit/UIKit gut hinbekommen kann.
Und dann hätte Apple das ja auch so machen können, dass sie UIKit so erweitern, dass damit alle Plattformen bedient werden. Das ist jedenfalls nichts was SwiftUI auszeichnet!

aMacUser

Ich komme aber auch aus der Web-Welt und bin diesen Ansatz gewohnt. Ich habe zwar auch mal ein paar Jahre Desktop-Entwicklung gemacht, aber bin mit GUI-Buildern nie so richtig warm geworden.

Weder UIKit noch AppKit brauchen GUI-Builder, wenn du damit InterfaceBuilder bzw. Storyboards meinst, das kann und sollte man alles im Code machen.

Ich hab zwar keine Lösung, doch ich bewundere dein Problem

LoCal01.07.25 11:13

aMacUser

milk

Aber wann braucht man Mobil denn keine GUI?

So gut wie die ganze Logik sollte grundsätzlich nicht abhängig von der GUI sein und das sind auch Dinge, die man gut in eine Library packen und in mehreren Projekten nutzen kann…

Ich hab zwar keine Lösung, doch ich bewundere dein Problem

netspy01.07.25 13:03

MLOS

SwiftUI ist leider, von dem, was ich bisher gehört habe, viel zu beschränkt und qualitativ teils eher unterirdisch.

Teste es einfach selber und lass dich nicht zu sehr von Entwicklern beeinflussen, die jahrelang mit UIKit und AppKit entwickelt haben. Aus eigener Erfahrung kann ich dir sagen, dass SwiftUI mittlerweile sehr ausgereift ist und mir kein Szenario einfällt, in dem man es nicht verwenden könnte.

netspy01.07.25 13:09

LoCal

Aber wenn es komplexer wird, dann ist SwiftUI wirklich ein riesiger Schmerz.

Kann ich beim besten Willen nicht bestätigen. Wenn es komplexer wird, dann wird das Projekt natürlich komplexer, das war und ist bei UIKit aber auch nicht anders.

Ein Schmerz waren für mich dagegen immer Constraint und Auto Layout, die ich nicht misse.

sumpfmonsterjun01.07.25 13:42

Was @netspy sagt!

milk01.07.25 14:33

Was @LoCal sagt.

-2

frank126601.07.25 16:40

Jetzt „dachte“ ich doch zuerst, was hat denn nun wieder die Taylor mit Android vor und was zum
Henker hat Apple damit zu tun 😳…scheiß Hitze 😂

LoCal01.07.25 19:05

netspy

Kommt halt darauf an, was Du bisher mit SwiftUI gemacht hast.
Wenn Du nur H/V/Z-Stacks mit den Standard-SwiftUI-Controls befüllt hast, dann wirst Du keine großen Probleme erlebt haben, aber wenn Du auf die Content-Position in ScrollView reagieren muss und dazu noch Änderungen der UI hast, die sich direkt auf den ScrollView auswirken, dann wirst Du sehr schnell merken, wie unfassbar schlecht der deklarative UI-Ansatz ist. Das ist in UIKit eine Kleinigkeit.

Ich hab zwar keine Lösung, doch ich bewundere dein Problem

-1

Stellt Apple Swift für Android vor?

Kommentare

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.