[HN Gopher] SwiftUI for Mac 2022
___________________________________________________________________
SwiftUI for Mac 2022
Author : allenleein
Score : 100 points
Date : 2022-07-03 14:32 UTC (8 hours ago)
(HTM) web link (troz.net)
(TXT) w3m dump (troz.net)
| adamnemecek wrote:
| This big thing for me about SwiftUI is that it makes not using
| xibs a thing of the past. Like there's value to it even if your
| app is just NSViewRepresentables (or UIViewRepresentables).
| sircastor wrote:
| After some 17 years of web development, I finally managed to sit
| down with XCode and figure out some app development with Swift
| UI. Having gone through some much earlier InterfaceBuilder
| tutorials and trying to figure out ObjectiveC, I'm far more
| confident I could actually make something viable in SwiftUI.
| Purely anecdotal, of course.
| ardit33 wrote:
| SwiftUI looks promising, but it is not ready at all. It is fine
| for 'toy apps' but if you want to do anything serious UIKit is
| unbeatable.
|
| I think it will take few more years until SwiftUI can get to
| feature parity with UIKit.
| spike021 wrote:
| I think it depends on what you're trying to build.
|
| I was working on a 'toy app' earlier this year. I needed to
| use MapKit, but the SwiftUI MapKit is pretty simple,
| features-wise.
|
| So I had to do the more complicated (relatively-speaking as
| someone with no prior UIKit/Swift experience) solution of
| using a UIViewRepresentable to host a UIKit MapView.
|
| It wasn't the hardest thing to implement but it definitely
| shows that SwiftUI can't handle everything.
|
| I definitely think having that 1:1 parity will help and
| hopefully it doesn't took too long.
| lostgame wrote:
| I'm baffled as to how this has been so downvoted. It's just a
| fact. Been using SwiftUI for two-some years and while I use
| it for prototyping, when I actually want to get 'real' things
| done, I go back to UIKit quick as a bolt of lightning.
| programmarchy wrote:
| I've found SwiftUI to be a dramatic improvement over
| storyboards or view controllers for managing state and
| flow. Sure, for some view components you need to drop down
| into UIKit to do some detail work, but then it can be
| abstracted back into SwiftUI.
| ardit33 wrote:
| No serious company is using Storyboards. Only toy apps or
| small companies do, or junior devs. SwiftUI might be ok
| for them as well.
| spideymans wrote:
| I find that SwiftUI is fantastic for small, self-contained views,
| that don't have any complex custom behaviour, and don't deal with
| navigation logic. For anything more complex that that, I'd
| strongly urge falling back to UIKit
| ardit33 wrote:
| Agreed... it is not ready to be prime time yet. UIKit is still
| unbeatable for more serious apps. At this pace it might take
| few more years of dev for SwiftUI to reach feature parity.
| secretsatan wrote:
| I concur, recruiting now and everyone wants to use swift ui,
| but uikit, horrible as it is, is the only option for our
| complex ui
| LeoNatan25 wrote:
| What is "horrible" about UIKit or AppKit, other than them not
| being the latest sexy fad?
| [deleted]
| spideymans wrote:
| >I concur, recruiting now and everyone wants to use swift ui,
| but uikit, horrible as it is, is the only option for our
| complex ui
|
| That's interesting. UIKit is by far my favoured UI
| development framework (whether on web or mobile). It's
| incredibly powerful, and also pretty damn easy to work with
| once you know what you're doing.
|
| I feel SwiftUI might be favoured nowadays, only because the
| vast majority of devs come from a web development background.
| UIKit unfortunately has a pretty steep learning curve if
| you've come from a web dev background.
| viktorcode wrote:
| I concluded from experience that it always pays off to keep
| views separate from any logic except the bare minimum required
| for presenting the data on screen. This works regardless of UI
| framework.
| spideymans wrote:
| Are you describing MVVM? If so, I completely agree.
| mark_l_watson wrote:
| I wrote a short mostly-AI book on Swift and Core ML last year and
| the last example was an app using SwiftUI (the example is in
| Apple's App Store). I was pleasantly surprised how
| straightforward it was to use SwiftUI. I read the Apple docs and
| spent about $10 for a short online class. It was probably only a
| 15 hour investment to learn enough for my purposes.
|
| EDIT: you can get a free copy of my book by setting the price to
| $0.00: https://leanpub.com/SwiftAI
| srvmshr wrote:
| Just a gentle headsup: Looks like this suggestion doesn't work,
| since Leanpub annual membership is added automatically to this
| purchase, as being part of some bundle. Typically I wouldn't
| mind paying it if I knew what I would be getting out of the
| book
| mark_l_watson wrote:
| Thank you, I then need to keep PDFs available on my web site.
| I will do that in the next day or two.
|
| That said, I will first ask Leanpub if I can allow no
| membership downloads.
| codybontecou wrote:
| I was able to find the manuscript on his
| [Github](https://github.com/mark-watson/SwiftAI-book)
| simonw wrote:
| Which online class did you use?
| aaaaaaaaaaab wrote:
| God, please tell me future macOS apps won't look like this:
| https://troz.net/images/form.jpg
| lapcat wrote:
| Unfortunately it will. Look at the redesigned System Settings
| in the Ventura beta.
| hombre_fatal wrote:
| So, you scrolled the article just to attack a random screenshot
| out of context?
|
| Open up Xcode and drag various AppKit/UIKit's components onto
| the screen. Now ask yourself if this is the future of iOS/macOS
| apps just because you were able to cobble it together out of
| curiosity.
| speedgoose wrote:
| Thankfully, most of them will be Electron based (or similar)
| and look better.
| draw_down wrote:
| christoph wrote:
| Not sure why you are getting downvoted. There are so many basic
| fundamental things wrong there...
|
| A UI framework should at least get some of the very basic
| things correct with out of the box defaults. Bootstrap, for
| example, largely gets this right. You can slap something
| together and it at least looks vaguely cohesive. The screenshot
| you posted, should have taken somebody a lot of effort to
| demonstrate how a UI should NOT look. It's a visual version of
| a new HTML form framework where the labels aren't clickable...
| eyelidlessness wrote:
| All the things that don't look nearly or exactly identical to
| Catalina-era Cocoa (i.e. the "switch" toggles, "grouped" sub-
| form, oversized "capsule" button) are explicitly declared in
| the source code[1]. I'd wager those toggles will become more
| common as they get more first-party usage, grouped sub-forms
| probably less so. Huge oversized buttons? Pretty unlikely.
|
| 1: https://github.com/trozware/swiftui-
| mac-2022/blob/a301437c16...
| resist_futility wrote:
| It literally says "UI Samples" right above it, it's not
| supposed to be pretty
| dmitriid wrote:
| Despite what people are replying to you, yes, that is the
| future of MacOS apps.
|
| For proof, look no further than the new Settings.app. As Craig
| Federighi said in Gruber's talk show, it was carefully crafted.
| dagmx wrote:
| Why would that be your conclusion? If you were to slap any UI
| framework elements together without a design in mind,
| especially for a form, they'd look like that.
|
| This is just the author putting together the elements and
| discussing them. They're not trying to design something.
|
| There's tons of SwiftUI apps out there that are gorgeous
| looking. As with any UI framework, it's up to the developers
| who use them to make pretty or not.
| ChrisMarshallNY wrote:
| It's an academic exercise app. Those always look fairly
| primitive.
|
| I'm pretty sure that some of the new versions of the Apple
| standard apps are in SwiftUI. They may be a better example.
|
| Polish takes a great deal of effort, and often detracts from
| the lesson.
|
| Having done a number of things like this, I can attest to how
| much work it is, and appreciate the effort.
|
| All that said, I am still not entirely comfortable with
| committing to SwiftUI for a major app development project. I'm
| in no hurry. AAA apps are still using ObjC codebases, so
| there's no real urgency.
| Shadonototra wrote:
| In comparison, looks at the mess that is WinUI
| https://docs.microsoft.com/en-us/windows/apps/winui/winui3/c...
| smoldesu wrote:
| WinUI, and even SwiftUI, to an extent, are pretty contrived
| systems for building apps. Maybe I'm crazy, but writing apps
| for x11/GTK3 was probably the easiest time I had writing a GUI
| application of any kind. I simply drafted up an XML file
| containing all of my UI elements, then called some functions
| that would wrap actual app logic around interactive components
| at compile-time. The result? Designing an app can be done
| entirely with drag-and-drop, then programmed with your language
| of choice. I used Rust, and my resulting binaries were pretty
| competitive all things considered.
|
| Unfortunately, desktop Linux development has been on a constant
| downhill trend for the past few years. Red Hat and GNOME have
| been doing their best to pull the rug out underneath most of
| the good development infrastructure, which is annoying to say
| the least. It's a crying shame, but I have no doubt that Apple
| will trounce whatever libadwaita nonsense is getting built by
| GNOME maintainers right now.
| thechao wrote:
| I also found Win16/32 with "the giant switch statement" easy
| to program & reason about. Once you weapped your head around
| how to minimize the rdraw area, there wasn't much that could
| wrong. OTOH, it was a really tedious way to GUI.
| mixedCase wrote:
| Have you taken a look yet at Gtk4 and libadwaita docs to form
| such a strong opinion? Cambalache (Glade's author's new UI
| builder) has only recently gained libadwaita support, but you
| can do exactly what you describe.
___________________________________________________________________
(page generated 2022-07-03 23:00 UTC)