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

Aufgrund der Corona-Krise: Die Veröffentlichung von Stellenangeboten und -gesuchen ist bis 31.12.2021 kostenfrei. Das beinhaltet auch Angebote und Gesuche von und für Freischaffende und Selbstständige.

  • 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.“