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.

Weiterer Bericht zu den Preisen des iPhone 17: ...

Apples "TechWoven", Nachfolger von FineWoven

HDMI ARC: Muss nicht

Apple verliert den KI-Entwicklungschef an Meta ...

Jailbreak: macOS auf iPad/iPhone

Neue Probleme in der Mail-App: Keine Anzeige me...

Federighi: Warum es so lang dauerte, bis das iP...

Kurz: Netflix auf Apple TV mit großem Update ++...

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!

-1

milk01.07.25 14:33

Was @LoCal sagt.

-3

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

netspy01.07.25 20:26

LoCal

Wenn Du nur H/V/Z-Stacks mit den Standard-SwiftUI-Controls befüllt hast, dann wirst Du keine großen Probleme erlebt haben

Ich ignoriere mal lieber diese ziemlich arrogante Antwort.

LoCal

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 stelle hier nur fest, dass du offensichtich den deklarativen Ansatz noch nicht verinnerlicht hast und du dir vermutlich nicht die Mühe gemacht hast, hier etwas tiefer einzutauchen. Es reicht eben nicht, sich ein paar Beispiele und Tutorials anzuschauen und dann zu denken, dass man SwiftUI verstanden hat, weil man ja so ein toller Entwickler ist.

Um es kurz zu machen: Your’re holding it wrong. Wenn man weiß, wie es geht, dann ist das von dir beschrieben in SwiftUI genauso einfach wie in UIKit zu bewerkstelligen.

-3

ruphi01.07.25 21:31

Halten wir vlt. einfach mal fest, dass keiner von euch weiß, wie viel der jeweils andere weiß & kann, und es deswegen absolut müßig ist, hier einen Längenvergleich auszutragen

LoCal01.07.25 21:43

netspy

Um es kurz zu machen: Your’re holding it wrong. Wenn man weiß, wie es geht, dann ist das von dir beschrieben in SwiftUI genauso einfach wie in UIKit zu bewerkstelligen.

Nur so für dich: Ich arbeite seit dem Release von SwiftUI mit SwiftUI … und natürlich mit AppKit/UIKit (AppKit seit weit über 20 Jahren) in bestehendem Code. Und ich arbeite wahrscheinlich näher an der blutigen Kante von SwiftUI und UIKit als Du. Und natürlich habe ich den deklarativen Ansatz verstanden … ich bleibe aber dabei, dass es für macOS, iOS usw. der Falsche ist.
Trotzdem führt an

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

netspy01.07.25 21:56

ruphi

Halten wir vlt. einfach mal fest, dass keiner von euch weiß, wie viel der jeweils andere weiß & kann, und es deswegen absolut müßig ist, hier einen Längenvergleich auszutragen

Das letzte um was es mir geht, ist ein Längenvergleich. Wenn aber (in einem anderen Artikel) von MTN selbst und jetzt hier von einem Nutzer behauptet wird, wie schlecht irgendetwas angeblich in SwiftUI funktioniert, dann darf ich doch wohl noch aus eigener Erfahrung widersprechen dürfen. Oder nicht?

Wem SwiftUI nicht zusagt, der soll es halt einfach nicht nutzen und weiter UIKit benutzen. Punkt!

LoCal01.07.25 22:58

netspy

Wem SwiftUI nicht zusagt, der soll es halt einfach nicht nutzen und weiter UIKit benutzen. Punkt!

Na wenn das deine Einstellung ist … und wenn Apple dann AppKit/UIKit den Stecker zieht, dann sitzt man schlagartig vor einem Scherbenhaufen.

Vielleicht solltest Du auch ein bisschen einsehen, dass bei SwiftUI nicht alles so zuckerschnutig ist wie Du es Dir vielleicht wünscht. Und wenn es nach 6 Jahren nicht mal einen VideoPlayer in SwiftUI gibt, dann spricht das auch Bände.

Aber, und es tut mir echt ein bisschen weh so was zu schreiben, so ziemlich alles was bei Apple mit Swift zu tun hat wirkt wie kopflos entwickelt.

Das beginnt bei Swift selbst, das über Jahre inkompatibel zu seinen eigenen Vorgängerversionen war und Apple selbst die ersten Jahre nicht wusste, welche Philiosophie sie damit einschlagen wollen (Tipp: Schau mal wie man sich anfangs bei Apple vorgestellt hat, wie man mit Swift entwickeln soll, Stichwort functional programming … und wie es heute aussieht. Oder das große versprechen, dass Swift "sauber und frei von Krücken sei" und wie man sich dabei über die Block-Syntax von ObjC lustig machte … und Swift heute?
Weiter geht es über SwiftUI, das einen mit unsinnigen Fehlermeldungen den Tag versüsst. Und einen manche Dinge extrem verkompliziert.
Geht dann weiter über SwiftCharts, bei dem man vom Apple Support selbst nur als Antwort bekommt: Oh, das ist wohl ein Bug, einmal Radar bitte.
Und endet bei SwiftData, das bis iOS 26 nicht mal Vererbung für seine Models (KLASSEN!!!) konnte, aber eine Konvertierung für bestehendes CoreData bietet … das dann aber mit "Oh, Vererbung kann ich nicht" abbricht.

Glaub mir, es kotzt mich an so zuschreiben, aber Swift ist einfach ein Spiegelbild von Apple seit Cook dort waltet … Chaos, unfertiger Sch@$% und Planlosigkeit.

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

netspy01.07.25 23:13

LoCal

Vielleicht solltest Du auch ein bisschen einsehen, dass bei SwiftUI nicht alles so zuckerschnutig ist wie Du es Dir vielleicht wünscht.

Und vielleicht solltest du mir nichts unterstellen, was ich so nie behauptet habe!

LoCal

Und wenn es nach 6 Jahren nicht mal einen VideoPlayer in SwiftUI gibt, dann spricht das auch Bände.

Ach, es gibt also keinen VideoPlayer? Dann habe ich von dem hier wohl nur geträumt.

LoCal

Glaub mir, es kotzt mich an so zuschreiben, aber Swift ist einfach ein Spiegelbild von Apple seit Cook dort waltet … Chaos, unfertiger Sch@$% und Planlosigkeit.

Glaub mir, auch wenn du mir etwas anderes unterstellst, feiere ich Apple nicht für jeden Entwicklungsschritt von Swift und SwiftUI. Die Änderungen bis Swift 4 fand ich auch nicht wirklich prickelnd. Aber es geht stetig voran und seit ca. 2 Jahren ist die Kombi in meinen Augen durchaus produktiv einsetzbar. So etwas kann man entweder positiv sehen oder man sucht weiterhin jedes Haar in der Suppe.

Raziel102.07.25 08:36

MLOS

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.

"gehört habe" ist da der springende Punkt. Wir nutzen SwiftUi seit dem ersten Release voll produktiv in großen Apps und könnten nicht glücklicher sein. Was anderes würde hier keine mehr freiwillig verwenden. Da ist weder was beschränkt noch qualitativ unterirdisch Im Gegenteil: Damit vollwertige Apps zu bauen geht so schnell, dass wir teilweise unsere Wireframes statt zuerst als Mockup, direkt in der App mittels SwiftUI gebaut haben.

Natürlich gab es in den Anfangszeiten kleinere Themen die man aber alle Lösen/Umgehen konnte. Aber Apple blieb ja nicht Still und erweiterte und verbesserte kontinuierlich. Sollte man wirklich irgendwas ganz spezielles benötigen, was es nur im UiKit gibt, kann das problemlos durchmischt werden. Das hatte wir in den letzten 6 Jahren aber erst einmal. Und wir haben wirklich große weit verbreitete Anwendungen da draussen im Feld

Raziel102.07.25 08:45

netspy

LoCal

Wenn Du nur H/V/Z-Stacks mit den Standard-SwiftUI-Controls befüllt hast, dann wirst Du keine großen Probleme erlebt haben

Ich ignoriere mal lieber diese ziemlich arrogante Antwort.

LoCal

Kann ich nur zustimmen. Es gibt leider viele die von klassischen Systemen zu SwiftUI kommen und direkt loslegen was grundsätzlich funktioniert weil SwiftUI super leicht zum einsteigen ist. Aber wenn es komplexer wird, wird schnell die Schuld auf SwiftUI geschoben. Das ist kein Vorwurf, denn auch wir hatten einige "Aha" Momente, wo wir dann selbst nach 3 Jahren SwiftUI drauf gekommen sind, dass wir ein paar Grundlagen bisher garnicht wussten oder richtig verstanden hatten.

SwiftUI ist richtig genial aber man kann genau darum, weil es so einen einfachen Einstieg bietet, schnell in die Situation kommen dass man auf komplexere Probleme/Verhalten stößt, die eigentlich meistens eine einfache und simple Ursache haben, die einen aber durch Mangel an Wissen von SwiftUI erstmal verwirrt. Das ist natürlich ein "Risiko" weil man bei SwiftUI direkt loslegen kann und sofort tolle Ergebnisse hat. Dann eventuell seine App/Views konzeptionell falsch baut, weil es ja momentan super funktioniert, nur um dann irgendwann auf dementsprechende Konsequenzen zu stoßen. Dann wird erstmal nachgelesen wie man es eigentlich hätte machen sollen und die AHA Momente tauchen auf

Unwindprotect02.07.25 11:14

LoCal

Ich kenne Dich natürlich nicht - insofern möchte ich Dir das nicht unterstellen. Allerdings kenne ich aus eigener Erfahrung: einige Entwickler die seit 20 Jahren einem bestimmten Paradigma folgen tun sich besonders schwer sich an neue Paradigmen anzupassen. Deshalb sind die neuen Paradigmen aber noch lange nicht der "falsche Ansatz".

MrJava02.07.25 15:48

LoCal

netspy

Wem SwiftUI nicht zusagt, der soll es halt einfach nicht nutzen und weiter UIKit benutzen. Punkt!

Wenn das alles so Sch... wäre, dann gäbe es keine gute Software mehr. Hmm, scheint alles zu funktionieren bei mir!

Hör auf Dich selbst, sonst hört Dich keiner!

Stellt Apple Swift für Android vor?

Kommentare

Kommentieren

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