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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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 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.
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
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.
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.
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.
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.)
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!
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.
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.
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.
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.
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...
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).
EDIT: you can get a free copy of my book by setting the price to $0.00: https://leanpub.com/SwiftAI