Benutzt jemand SwiftUI für macOS?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Benutzt jemand SwiftUI für macOS?

    Hallo zusammen,

    die o. g. Frage sagt schon alles, und ist durchaus nicht provokativ gemeint:

    Gerne würde ich mich - neben meinen anderen vielen Baustellen - einmal mit SwiftUI beschäftigen. Eigentlich müsste mal ein iOS 14 Widget entstehen, aber es interessiert mich auch so. Angeregt durch @Wolfs Bemerkung bzgl. DisclosureGroup wollte ich mal sehen, wie das Teil auf macOS aussieht ... auch wenn ich es für das konkrete Problem nicht verwenden kann. Aber Google wirft nur iOS Screenshots aus...

    Wie gesagt, kein akutes Problem, aber mir kommt es eh schon lange so vor, als würden alle nur noch für iOS programmieren. Wo sind die "klassischen" macOS-Programmierer geblieben, und setzt jemand dort schon SwiftUI ein?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich selbst habe SwiftUI nur mal kurz angeschaut und dann entschieden, ich warte erst mal ab, bis das erwachsen geworden ist. Da sind mir noch zu viele offene Baustellen und wenn es mal um mehr als eine Hand voll Daten geht, bricht die Performance in sich zusammen. Daher kann ich den Hype um SwiftUI nicht wirklich nachvollziehen.

    Hier ist aber einer, der schon recht viel mit SwiftUI auf dem Mac macht. Ob das alles schon SwiftUI ist, was da auf seine Seite ist, weiß ich nicht. Aber er arbeitet daran.
  • Ich schreibe nebenbei an einem Programm zur Steuerung einer Fräse. Bei deiner Frage zu klappbaren Views, musste ich auch direkt an die DisclosureGroup denken. :)
    Die Umstellung auf SwiftUI ist schon nicht ohne und für manche UI-Kleinigkeiten kann man wunderbar viele Stunden verbringen. Ich hatte vorher schon eine Umsetzung mit Swift und AppKit implementiert, aber die Umsetzung mit SwiftUI gefällt mir besser. Zum Einen gefällt mir Datenmodell besser, was aber nicht unbedingt an SwiftUI liegt. Andererseits sind die View-(Controller-)Komponenten einfacher und übersichtlicher.
    Wenn du für ältere macOS-Versionen als 11 entwickeln willst, solltest du aber besser auf AppKit setzen. Fenster und bestimmte Komponenten wie z. B. TabView, ScrollView sind teilweise schwer adaptierbar. Styles, Modifier und das Environment sind eine nette Idee, wenn Apple erlaubt, dass man sie auch sinnvoll implementieren darf. Beispielsweise kann man den aktuellen Font einfach aus dem Environment bekommen. In einem HostingView ist das aber nutzlos, weil man an die Fontinfos nicht drankommt. :(
    Das Layout ist aber ein großes Plus, weil es sehr einfach, leicht änderbar und intuitiv ist, und SwiftUI (wie React) verführt gerade dazu, eigene, wiederverwendbare Komponenten zu entwickeln.
    „Meine Komplikation hatte eine Komplikation.“
  • Also ich habe gerade ein Projekt in den Mac App Store gebracht und habe es nicht bereut, auf SwiftUI gesetzt zu haben. Im Gegenteil, ich bin damit letztendlich deutlich produktiver und motivierter, nachträglich tiefergehende Änderungen an der GUI vorzunehmen. Bei der ganzen IB-Property-Verdrahterei und dem Constraints-Geraffel waren mir Überarbeitungen ehrlich gesagt oft zu mühselig. Zusammen mit dem neuen StoreKit Testing in Xcode 12 hat das Programmieren des In-App-Stores der App sogar fast Spass gemacht.

    Die momentanen Nachteile und Unzulänglichkeiten nehme ich in Kauf. Mir ist es z.B. bis heute nicht gelungen, ein TextField programmatisch in den Edit-Mode zu versetzen. Der TextEditor als NSTextView-Äquivalent ist selbst mit gutem Willen nur als rudimentär zu bezeichnen und AppKit-gemäße mehrspaltige TableViews mit Header wären auch nett. Aber für meine Zwecke reicht es im Moment.
  • plasmatron schrieb:

    Mir ist es z.B. bis heute nicht gelungen, ein TextField programmatisch in den Edit-Mode zu versetzen. Der TextEditor als NSTextView-Äquivalent ist selbst mit gutem Willen nur als rudimentär zu bezeichnen und AppKit-gemäße mehrspaltige TableViews mit Header wären auch nett..
    Wo liegt denn das Problem? Ich hatte hier bislang noch kein Problem dabei.

    Zum Thema Headers mit Tableview, das ist doch mit einen 5 Zeiler zu realisieren. Ausser du meinst was anderes…

    Das schöne an SwiftUI ist doch, das man das eine tun kann, ohne das andere zu lassen. Man kann doch Problemlos mixen…

    Wenn man spezielle Ding vorhat, was das andere nicht lesen kann, dann legt man das halt in einen zentralen Objekt ab um auf zentrale einstellungen zuzugreifen oder diese zu setzen. Wo ist da das Problem? Ausserdem, wer mehr als 3 Schriftarten verwendet, der braucht mir nix mehr von Layouts erzählen.
  • Wolf schrieb:

    Wo liegt denn das Problem? Ich hatte hier bislang noch kein Problem dabei.
    Wie hast du es denn gelöst, so ohne Zugriffsmöglichkeit auf die Responder Chain?

    Wolf schrieb:

    Zum Thema Headers mit Tableview, das ist doch mit einen 5 Zeiler zu realisieren. Ausser du meinst was anderes…
    Klassische NSTableViews mit durch den User in der Breite veränderbaren Spalten (die man ggf. neu anordnen kann) sowie Errungenschaften wie vertikale Spalten-Separatoren -- in SwiftUI nativ momentan halt nicht vorhanden. Beim TextEditor fehlt mir beispielsweise die Möglichkeit, einen textContainerInset zu setzen sowie den automatischen Zeilenumbruch zu unterbinden.

    Wolf schrieb:

    Das schöne an SwiftUI ist doch, das man das eine tun kann, ohne das andere zu lassen. Man kann doch Problemlos mixen…
    Wenn aber bei einem Projekt ein gehöriger Anteil an GUI-Elementen nur durch native AppKit/UIKit-Replacements umzusetzen ist, macht der Einsatz von SwiftUI ab einem gewissen Punkt noch keinen großen Sinn. Was nun ein "gehöriger Anteil" ist, muss jeder bei seinem Projekt selbst bewerten.
  • Ein Äquivalent zum NSTableView gibt‘s in SwiftUI noch(?) nicht. Aber die Lazy Grids sind aber auch nicht ohne swiftui-lab.com/impossible-grids/

    Textfelder und -views sind nur für einfachste Aufgaben gedacht. Noch nicht mal den Focusring kann man verschwinden lassen. Der Texteditor ist ein schlechter Witz.

    In meinem Projekt ist der Anteil der selbsteingebetteten, nativen Views eher gering, ca. drei Views. Den View für die grafische Darstellung der Pfade und Bohrungen hätte ich vielleicht auch in purem SwiftUI umsetzen können, hatte das Teil aber nun mal schon da.
    „Meine Komplikation hatte eine Komplikation.“
  • Sorry für das Ausgraben dieser Thread-Leiche, aber ich wollte den aktuellen Stand bzgl. SwiftUI abfragen.
    Hat sich Eure Meinung geändert, bzw. habt Ihr das jetzt nochmals versucht?

    Ich frage, weil ich halt überlege, bei einem uralten 10.9 macOS Programm die UI neu zu implementieren (ich habe bei einigen Views so viele Constraints drin, das muss doch einfacher gehen). Und da frage ich mich jetzt: Was wäre da der beste (zukunftssichere) Weg?
    --
    Wer ist dieser Root und warum gehören ihm alle meine Dateien??

    SIDplay5 for macOS on GitHub
  • Alexco schrieb:

    Sorry für das Ausgraben dieser Thread-Leiche, aber ich wollte den aktuellen Stand bzgl. SwiftUI abfragen.
    Hat sich Eure Meinung geändert, bzw. habt Ihr das jetzt nochmals versucht?

    Ich frage, weil ich halt überlege, bei einem uralten 10.9 macOS Programm die UI neu zu implementieren (ich habe bei einigen Views so viele Constraints drin, das muss doch einfacher gehen). Und da frage ich mich jetzt: Was wäre da der beste (zukunftssichere) Weg?
    Also, der "beste" Weg ist glaube ich immer objektiv.
    Wenn du einen Entwickler mit +xx Jahren Entwicklungserfahrung fragst wird er dir immer sagen, dass sein Weg der beste ist, einfach weil er ihn verstanden hat :)

    Der zukunftssichere Weg ist aber aus meiner Sicht definitiv SwiftUi fürs Tablet / iPhone und wird auf lange Sicht auch auf MacOS kommen.
    Apple setzt zu 100% darauf, es gibt mehr und mehr Features dafür und wenn ich mir hier so die alten Beiträge durchlese, dann sind viele Dinge auch schon ausgebessert.

    Hier noch ein schöner Vergleich, mit einer Grafik wie welches Framework verteilt auf die einzelnen OS angewendet wurde.
    Entwickler analysiert Anteile von AppKit, Catalyst und SwiftUI
  • Ja, natürlich ist das auch immer abhängig von persönlichen Präferenzen oder Erfahrungen. Aber auch das kann ja interessant sein, ebenso wie der Link, danke dafür.
    Leider finde ich auch keine aktuellen Tutorials zu SwiftUI auf macOS (nur immer iOS) und das Kombinieren mit AppKit.

    Wenn ich komplett auf AppKit setze, dann kann ich runter bis macOS 10.9 oder 10.13. Geht das auch mit SwiftUI? Oder muss ich verwendete Features auf die jeweilige Verfügbarkeit bei macOS-Versionen prüfen?
    --
    Wer ist dieser Root und warum gehören ihm alle meine Dateien??

    SIDplay5 for macOS on GitHub
  • Das liegt daran, dass SwiftUI Plattformübergreifend ist. Die Punkte, welche nur mit einer Plattform funktionieren, werden immer weniger, das heisst selbst Apple entwickelt dafür Dummies, damit man das nicht jedesmal manuell coden muss.

    In der Tat, der Punkt, bis zu welcher Version deine Software laufen soll, ist der ausschlaggebende Punkt. denn die Runtime wird mit dem Betriebssystem ausgeliefert. Das heisst, die Features welche Du zu einer aktuellen SwiftUI implementation hast, funktionieren auch immer erst zu der korrespondierenden Betriebssystem Version. Wenn Du im September anfängst mit SwiftUI und SwiftData, dann setzen deine Applikationen auch immer mindestens die Betriebssystem Version deines Entwicklungssystems voraus.

    Letztes Jahr kamen die Fenster, welche MyMattes unbedingt wollte, auch die Tabellen. Auch dieses Jahr gibt es nützliches, auf das man ungern verzichten möchte, wie weitere schöne Grafiken :)

    Also, überleg es Dir...
  • Alexco schrieb:

    Wenn ich komplett auf AppKit setze, dann kann ich runter bis macOS 10.9 oder 10.13. Geht das auch mit SwiftUI? Oder muss ich verwendete Features auf die jeweilige Verfügbarkeit bei macOS-Versionen prüfen?
    Das kann man eigentlich über die Filter in der Apple Developer Documentation leicht in Erfahrung bringen.

    developer.apple.com/documentat…ftui?changes=latest_minor

    (Oben im Kopf bei den API Changes).

    Ich bin kein aktiver Entwickler, aber die Features finde ich auch schön. Denke, hier wird nach und nach ergänzt.

    Vielleicht gibt es in englischer Sprache mehr an Materialien zu den Themen.

    Ja, mobile Plattformen sowie Hybrid wurde ja in letzter Zeit stärker favorisiert. Aber bestes Beispiel sind natürlich die Apps, die Apple auch selbst für die eigenen Produkte entwickelt. Da findet man ja eigentlich viele Anhaltspunkte, wie man etwas umsätzen kann / könnte.

    Das hängt natürlich auch von der App / Genre ab. Ich denke mir, viele wünschen sich auch Pro Apps auf mobilen Geräten, da ja die Leistung mittlerweile vorhanden ist. Aber man wird sich z.B. Logic auf dem Tablet mal anschauen müssen, wie Apple selbst das ein oder andere gelöst hat, wofür man bisher nur die native Mac OS App nutzen konnte. Ich kann mir vorstellen, dass für Touch Bedienung auch erst mal entsprechende Konzepte entwickelt werden müssen.

    Die Blender Community würde sich über eine mobile App freuen mit dem Leistungsumfang der Desktop App. Aber bisher geht es nur via Side Car (Sculpting / Modeling mit dem Apple Pencil). Für den vollen Umfang braucht man dann doch noch den Mac.

    Ich denke auch, dass die Funktionalitäten weiter zusammenwachsen werden.

    Ansonsten zu Mac OS Programming. Alle Bücher von Aaron Hillegass

    amazon.de/Aaron-Hillegass/e/B0…=dbs_a_mng_rwt_scns_share

    Oder bei Stackoverflow suchen. Da muss man natürlich aufpassen, ob die Infos noch zu dem aktuellen Umfeld passen.

    Theoretisch könnte man Game Development jetzt mit allen grundsätzlichen Funktionen angehen, würde man ein eigenes Framework erstellen, was wohl kaum jemand machen dürfte, da es schon andere Produkte gibt, die da deutlich weiter sind.

    Es bleibt halt wie bei allem die Sinnfrage.