iOS/macOS DEVS:

A friend wants to get started building native Apple apps. Should she go AppKit/UIKit or SwiftUI? Or something else?

She has a ton of server dev experience, zero Swift background.

Any and all thoughts appreciated…🙏🏻

#Swift #Apple #UIkit #Appkit #SwiftUI

@davemark For getting a job or for a hobby?

@davemark I would start with UIKit (and Catalyst on macOS).

SwiftUI is great, but I think knowing what it’s (mainly) built in top of will make understanding easier in the future.

@MuseumShuffle Job. Eventually.

@davemark if there's a ton of data to be displayed, then use UIKit Collection Views and Core Data Fetched Results Controllers. If there is NOT a ton of data, SwiftU (and Core Data @FetchedResults)I is the future. One day, SwiftUI will expose all the performance benefits of collection views, but lazy V isn't there yet. imho fwiw.

@davemark Ah, ok. I won't be any help then. I have heard people point out the argument that there's a bigger job potential with UIKit because of how many existing apps are out there. I never did any research into that so take it with a grain of salt. I focus on SwiftUI as a hobby.

https://youtu.be/iRQbqz3nmxo

@MuseumShuffle I’ll watch the video, Chris. Appreciate the share, valuable for me to hear a range of views, helps me stay current. Cheers!

@davemark no problem! If she does decide to go with SwiftUI, I would highly recommend the hundred days of SwiftUI by Paul Hudson. It’s completely free and you learn so much from it. I loved it.

@MuseumShuffle Funny. I was just thinking 100 days of Swift UIKit for her. Either way Paul is a great teacher. Good call.

@davemark good point! I forget about that one because I didn’t take it.

@davemark https://www.thomashanning.com/should-you-still-learn-uikit/

@thomashanning great read, Thomas. Thanks. Interesting to be in the crossing points like this.

@davemark @MuseumShuffle in the intro to that course, he links to this article, which I think would be helpful. He explains pretty clearly why he recommends starting with SwiftUI and then doing UIKit later. https://www.hackingwithswift.com/articles/230/how-to-become-an-ios-developer

Also, @twostraws is Paul’s Mastodon account.

@jmuscara @MuseumShuffle @twostraws Followed him. Paul, been talking about whether a new dev should start with SwiftUI or UIKit. And singing the praises of 100 Days of Swift. Cheers!

@jmuscara @davemark @twostraws Thanks Joe! I took the course in 2020 so that didn't exist then. Interesting reading!

@davemark All my iOS code is in the context of hobby projects, so take with however much salt you deem appropriate.

There's a lot of UIKit code out there, so for a job, I assume there's a good legacy reason to learn it.

That said, there's also lots of Obj-C code out there and I'm not sure I'd recommend going down that path.

SwiftUI isn't a complete replacement for UIKit, but it's definitely where the puck is going.

I think starting with SwiftUI and back-filling where needed is the way to go.

@bennomatic Appreciate that take, will def pass it along. Cheers!

@davemark Personaly, for any new projects where cross-platform is a requirement, I try to go with SwiftUI since it makes life easier overall. Catalyst works great most of the time, but on the macOS side you get a few idiosyncrasies which just makes things a bit annoying … (This is based on having worked with both SwiftUI and Catalyst Mastodon client in the past few weeks 😛)

For work, it really depends on the environment I guess. At work, I have a boss who loves SwiftUI and wants me to convert existing code to SwiftUI. I personally find UIKit faster to get going with since you can build a UI fast and for smaller projects, UIKit (but not AppKit so much, but that again might be my personal biases) faster to get started.

But if the project is cross-platform, I generally reach for SwiftUI. For smaller, less-complex stuff, SwiftUI works well,. But if you try to do some complicated stuff cross-platform, SwiftUI becomes a bit of a learning curve. Generally, it still gets the job done these days and there’s usually somebody who’s faced the same issues as you already, but it does become a bit more work … For example, supporting a specific type of view (say a UITextView analogue with particular functionality) on both iOS and macOS ….

@f Thanks, Fahim. If you were going to build, say, a macOS Mastodon client from scratch, would you use AppKit? Or SwiftUI with some sync stuff for the URL session work in AppKit? Easy to mix the two?

@davemark Personally, I want everything I build to work on both macOS and iOS since if I use it, then my wife will want to use it and she’ll generally be using it from her iPad. So SwiftUI is the preferred option for me most of the time these days.

Went through several Mastodon clients because of this actually 🙂 I liked Mastonaut because the source was available and it was native macOS, but then my wife wanted the features I was building. Looked at at least one which was pure SwiftUI and modified it a bunch but kept hitting issues getting certain things to work — like the UITextView thing I mentioned previously.

Now I’m using a Swift app (with some SwiftUI code) which was mainly written as an iOS app with Catalyst support and I’m modifying the Catalyst part to work for my needs on a Mac. Working out OK so far but it’s a bit of a struggle with Catalyst.

So based on this particular experience, developing for iOS with Catalyst support for macOS would seem to be the the way to go … But my heart is set on trying to get pure native apps on both sides of the fence if I can and so I’d really want it to be SwiftUI cross platform. But that takes a lot more work … and I’m lazy 😛

@davemark I would recommend SwiftUI. In my company, all new projects have been SwiftUI for 2+ years, and all our clients are using more and more SwiftUI all the time. There are still times you need to embed UIKit views, but once you learn the pattern for doing so, it’s straightforward. And Apple is providing built-in SwiftUI support for more and more “legacy” UIKit views every year.

@davemark As you know, I spent over 25 years building apps primarily with AppKit and UIKit. IMHO the layer of abstraction that SwiftUI lays on top of those is simply a “better” abstraction, and is clearly improving every year. Personally, as much as I love and admire the work that has gone into the old frameworks, I hope to never go back to using them directly.

BTW, Apple’s SwiftUI tutorials are a great starting point!

https://developer.apple.com/tutorials/swiftui

@JackNutting cheers, pal. Well said.

@davemark Is your friend building apps for personal satisfaction, hobby, indie dev? Or is your friend hoping to get a job at a company doing mobile development? For the former, SwiftUI in a heartbeat, but for the latter, I have to recommend UIKit, as most companies are still predominantly using it and/or have tons and tons of legacy code in it that needs to be maintained.

@davemark I have a new book coming out from #kodeco in a couple of months aimed at beginners wanting to build Mac apps. It covers introductory Swift, then builds apps with SwiftUI and AppKit.

@davemark I think it depends on the end goal. Get a job building iOS apps? Indie dev?

For an experienced dev trying to work on iOS full time it still makes sense to start with UIKit. It’s not going anywhere and most jobs will value that experience even if they are primarily SwiftUI.

If it’s for fun - I’d go SwiftUI. When you can make iOS 16 your target it’s a pretty good time. Of course, if she’s got a preference for declarative or imperative programming that comes into play too.