SwiftUI for Mac 2022 | Hacker News Reader

SwiftUI for Mac 2022

troz.net

151 pointsallenleee68 comments

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

https://github.com/mark-watson/KGN

If anyone was interested in the app. I couldn’t find it on the App Store.

I used to have one large GitHub repo for all the book examples, but then decided later to have separate GitHub repos for the examples because some are libraries and this works better with the Swift Package Manager.

This link should show all my public Swift repos: https://github.com/mark-watson?tab=repositories&q=swift&type...

Also, I am a Common Lisp developer. Swift is just a side language for me, but I enjoy it and I was blown away at how useful Apple's Core ML libraries are (good stuff!).

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

I was able to find the manuscript on his [Github](https://github.com/mark-watson/SwiftAI-book)

Note: I licensed the book using a Creative Commons reuse with attribution, so figures, text, etc. can be reused. I look at this as open source, but for writing.

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.

EDIT: you should now be able to get the book for free.

Confirming that it works. At 77 pages its a small book which I could hopefully go over in 2-3 days toying around. I already read the frontmatter & it looks friendly. Thank you for updating downloads on the Leanpub side.

You should consider expanding it. (plus: Typeset in latex). Maybe even selfhost it instead of Leanpub since you make it available to read for no charge. I am sure you will find much better viewership & suggestions/PR/contributors.

I will hopefully have time for a second edition.

Professionally I am a Common Lisp programmer and I have updated My Loving Common Lisp... book many times.

I think that Apple has done a very good job with the Swift + SwiftUI + Core ML ecosystem. Probably not to many people's taste, but I really like bottom up programming, starting with experiments in a REPL, and then creating little libraries, etc. Swift support this and on any M1 or M2 laptop of iPad Pro, compilation is really fast. I think that Apple could improve the Swift Playgrounds experience on iPad Pros, but I like what they have done so far.

Thanks for the book.

What kind of AI application could be handled bay Macbook Air M1 easily?

Apple's Core ML library pre-trained models run really well on M1/M2 laptops and iPad Pros.

You can also import Keras/TensorFlow models, etc.

Apple devices are optimized for inference, not training, so anything where models are pre-trained (but then, what's the point?)

your m1 is a beast of a machine, especially for running pre-trained models. you should be able to run any of the image identification models no problem, and in real time.

Which online class did you use?

I think it was the 2021 version of: SwiftUI Masterclass 2022 - iOS App Development & Swift

I just used the parts I needed.

If you're interested in SwiftUI and care about feature composability, decent test coverage, dependency injection, isolated side effects, functional core and being able to use live previews properly, take a look at: https://github.com/pointfreeco/swift-composable-architecture

Been using it at work for a moderately complex app (not a toy app by any means) and it's been fantastic. We're 7 months in and haven't hit any gotchas, but the learning curve can be a bit steep, especially for more junior iOS devs.

Helps that they have a full video series taking you through the library and how they built it: https://www.pointfree.co/collections/composable-architecture

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.

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.

I think this is a bit of hyperbole. SwiftUI itself does a decent enough job. It's kind of like React without much of the ecosystem.

If you start with SwiftUI and need to integrate sone part of UIkit without really knowing the patterns, it's daunting for a while, but it's kind of an interesting daunting. My biggest issue is in the blurry line between iOS SwiftUI and mac swiftUI capabilities. A lot of examples are written by ios devs, who aren't even thinking about mac discrepancies

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.

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.

I wouldn't describe it as a "fact" that SwiftUI is a toy

I have used SwiftUI now in 5 shipping iOS applications and one internal macOS app. Two of them had codebases that extended all the way back to pre-ARC Objective-C! One app was 100% SwiftUI (with two UIKit exceptions where I had to drop down to work around a SwiftUI bug)

I get "real" things done in both UIKit and SwiftUI. It is trivial to host a SwiftUI view in UIKit, and it soon becomes the most pleasant part of the app to work on in my experience

It's simply a tool to use alongside UIKit, and it happens to be fun to use too

  > It's simply a tool to use alongside UIKit, and it happens to be fun to use too

exactly. the way i look at it is like a super powered version of xml (xib) for describing app uis

there are alot of things you cant do in pure xml/xib and the same is true of swiftui, in those cases you need to use an island of imperative code (uikit or custom class) and things work smoother in those cases

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.

No serious company is using Storyboards. Only toy apps or small companies do, or junior devs. SwiftUI might be ok for them as well.

I work for a major bank in Canada; we are one of the largest companies in Canada, and we use storyboards. We are very serious about the work we do.

We are also working on SwiftUI stuff as well.

You made my point. You work on a bank, not a software company. Let’s be real, third league and banks treat software as an expense/cost center.

Let me know when any of the major companies actually use it seriously.

You seem to have a serious chip on your shoulder, and a lot of your comments are really gatekeeper like.

Out of curiosity, what products of note have you developed that give you the right to talk down to everyone else?

Wow, you okay, man?

We are a bank. We make software used by millions of people a day.

We are a major company.

Lost your key, gatekeeper? :P

How exactly are you building watchOS app?

Plenty of serious development uses SwiftUI and storyboards.

Apple’s own iOS apps use storyboards.

I have production apps in the store with SwiftUI so it's not a fact at all. These are non-toy apps. UIKit is more mature but it hasn't matter at all in my experience.

I think that's hyperbole. We have multiple, very complex SwiftUI apps published, and there are quite a few on the app store.

You can do very fully featured apps in SwiftUI today

I’ve heard this a lot, and as someone who is just about to jump back into iOS after a 7 year break, I’m inclined to just defer to this opinion.

But I’m curious what this means, specifically. What would a good example of a serious UI, in your view? Not looking to argue - I’m genuinely curious.

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

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.

Are you describing MVVM? If so, I completely agree.

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.

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

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

What is “horrible” about UIKit or AppKit, other than them not being the latest sexy fad?

UIKit's constraint-based layout system isn't as easy as SwiftUI's layout system. SwiftUI layout system is similar to the CSS layout system, so it's easier to learn.

Easier to learn but severely limited in what can be achieved. But also, the springs and struts (“autoresizing masks”) is simpler than the SwiftUI system, but just as powerful.

In comparison, looks at the mess that is WinUI https://docs.microsoft.com/en-us/windows/apps/winui/winui3/c...

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.

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.

I agree with that, but I felt like the tooling surrounding it offered just enough functionality to make really nice, functional applications. The tedium was never really an issue to me since I mostly stuck to the GTK3 ethos of making small, polished and usable apps, but I could see how it would get complicated when making something more advanced.

Like you said, though, it's a great entrypoint for people like me who work on servers first and write software second. Kinda like how Zenity was a nice swiss-army-knife for script kiddies who got their rocks off watching sliders go from 0-to-100. Unfortunately, it looks like GTK4 isn't quite as accessible, which is going to be really challenging for it's adoption. The regression of features was frustrating enough, but now I genuinely don't know how to write an app with the library anymore. It's insane that they'd expect me to re-write my app to fit their brand new library, especially if it might not be sticking around very long either...

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.

I've been tracking Cambalanche's development, but I'm not really sure that I like it's development model. Glade had a really nice imperative workflow where you could procedurally add functionality to an app in a very natural and productive way. The model that Cambalanche uses closer resembles iOS app development, which I'm not very crazy about. Similarly, libadwaita proved extremely frustrating to deal with. Stripping it out of my builds was the first thing I did, but generally I just don't think GTK4 is ready for developers or users yet. There are far too many broken features at the moment, but they don't really seem to be listening to the community either. I'm going to be sticking with GTK3 for the foreseeable future (it's not like anyones ever dropping support for it lol), but I'm really hoping that GNOME can turn their development efforts around and really work with the community here.

Edit: also, looks like Cambalanche isn't packaged for my distro anyways.

Edit 2: I just built a more recent version and I am actually pretty impressed with how it's come along. Still not at parity, but a lot better than when I last saw it. Now, if only I didn't need Flatpak in order to watch it's development...

For someone who casually makes Swift apps, how can I keep up to date?

It moves so fast, it's changing every time I revisit. Often forcing me to upgrade my OS in order to keep my toy-software compatible.

Meanwhile I can reopen PHP projects from 6 years ago and it's still perfectly correct and workable.

I feel swift is mature now and they should slow the f down. I'm being priced out of the market in terms of maintainability. If it's your full time job, sure. Otherwise, RIP weekends.

This is becoming true for maintaining any Mac app nowadays, if only in terms of Apple's security theater "features" and arbitrary restrictions which randomly break apps that had worked fine for over a decade. Want to enumerate mounted disks or read a file from the user's Documents folder? Guess again. Meanwhile there are still more zero-days in the OS itself than ever.

This is exactly my point. The walled garden of Apple is riddled with developers' head on pikes.

SwiftUI is only a couple years old. That would be like PHP templating ossifying around the turn of the century.

Additionally, web apps only need to maintain install compatibility with their server. iOS apps are “desktop apps” so you need to have the mindset that your installation targets are a constantly evolving mix.

On top of that, your targeted OS is one with strict design, security and performance guidelines that aren’t static. The web doesn’t have this requirement (other than what search ranking factors incentivize.)

Intreasting read this thread.

I haven't done any coding since I was a kid and fancied doing some, since my devices are all Apple, iPhone / iPad / Mac, Swift and SwiftUI seemed like a good choice to start learning.

I'm finding it a little slow going and the language seems quite strange to me, I'm not too sure if it's because i've only dabbled in older languages itself or if it's more the language or the framework, but I do hope I made the right choice to invest time into!

God, please tell me future macOS apps won't look like this: https://troz.net/images/form.jpg

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.

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.

I think the issue is not on it being primitive.

The defaults being inconsistent and ugly is a failure of the component system. Like, why does the date field s month (6) have a space in the middle, and the up/down arrows are different from the select box’s up/down arrows ? And squared corners instead of round ones ?

It might be from the options the author is setting, but I’m not sure why it would end up that way.

It probably is the way the author set stuff up.

For myself, I spend many hours, polishing my courses.

This one is a bit dated, but you can see what I mean: https://github.com/ChrisMarshallNY/ITCB-master

The date picker is the only thing I see as wrong with the components displayed here.

And, from the perspective of a developer, I don't think it's a big deal. This date-picker design is used consistently across the system. So I assume someone at Apple will eventually get a 16 man-hour ticket to fix it system-wide, including third party apps.

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

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.

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.

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

Unfortunately it will. Look at the redesigned System Settings in the Ventura beta.

It literally says “UI Samples” right above it, it’s not supposed to be pretty

Thankfully, most of them will be Electron based (or similar) and look better.

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).

Reply on news.ycombinator.com