[sandofsky]

As a counter-anecdote from someone who also runs their own company, I began dabbling in Swift in 2014. I held off on full Swift adoption until after the big API renaming that happened with Swift 3, so language migrations haven’t been a big deal. The compiler is slower, but I can still do a clean build in 43 seconds.

Maybe I’ve had a good experience because I’m not working on a FAANG project with a million lines of code, but that’s all to say there are shades of grey, and you have to consider what you get in exchange for Swift’s compiler and evolution overhead.

Personally, I’ve found Swift helps avoid entire categories of bugs that crop up in ObjC, like accidental nil messaging. Generics have allowed me to avoid duplicate implementations. Now SwiftUI has allowed me to implement things in hours what would have taken me days in UIKit. I could go on for a while, but those are off the top of my head.

If you find yourself enjoying ObjC, by all means keep using it. Or C. Or Pascal. Or Lisp. There are tons of different ways to accomplish the same thing, but that doesn’t account for extra-hours and bugs it takes to get there.

[lapcat]

> If you find yourself enjoying ObjC, by all means keep using it. Or C.

I didn't say I enjoyed ObjC. That's not really how I choose my tools. It's a job. The choice is utilitarian.

> Or Pascal.

I seem to recall enjoying Pascal somewhat, though that was a very long time ago.

> Or Lisp.

I definitely recall not enjoying Lisp. Not at all. Yuck.

> that doesn’t account for extra-hours and bugs it takes to get there.

If Swift helps you, that's great. I'm just writing about my experience. For me, it doesn't help. I'm certainly not deliberately avoiding a tool that would help me. I do write my share of bugs, but I rarely write the type of bugs that the Swift compiler would catch, and I never ship them. YMMV

I'm not intending to offer advice of any kind to others. I'm not much for giving or taking advice. And like I suggested, if I needed to find a job, then I'd probably have to go all-in on Swift. My goal, though, is to never get another job for the rest of my life. ;-)

[sandofsky]

> I didn't say I enjoyed ObjC. That's not really how I choose my tools. It's a job. The choice is utilitarian.

Given C is faster and more mature than ObjC, why aren’t you writing everything in pure C and objc_msgSend?

[lapcat]

> Given C is faster and more mature than ObjC, why aren’t you writing everything in pure C and objc_msgSend?

TBH your question feels trollish, but I'll respond anyway.

Objective-C code does compile to objc_msgSend calls. Perhaps you meant getting the method implementations directly and calling them instead?

Objective-C is 40 years old. How much more mature does it need to be?

[sandofsky]

You said you make the utilitarian choice. By using C everywhere, you can use an even faster compiler that doesn’t insert those calls for you. So why don’t you?

[lapcat]

> By using C everywhere, you can use an even faster compiler that doesn’t insert those calls for you.

In the previous comment you said I should use objc_msgSend, now you say I shouldn't. Make up your mind. ;-)

Anyway, I'm using AppKit and UIKit to write apps. The API is Objective-C. That's why I write Objective-C.

Whatever the heck you're talking about—you appear to be confused, so I don't know what exactly you mean technically—it certainly sounds like premature optimization, which is a waste of time and not the correct utilitarian choice. My Objective-C code is not "slow". Could it be infinitesimally "faster" in way that's not even perceivable by the user? Perhaps, but who cares?

[solumunus]

Because of all the downsides. The utilitarian choice is about practicality, not pure performance. This line of questioning is silly.

[NoPedantsThanks]

I built an iOS app alone, from the ground up, in Objective-C. This was after I left Apple, where I mostly used C++. I hated Objective-C less than I expected, and the app was functional and reliable.

Then I built an iOS app for a consumer-electronics company alone, from the ground up. I learned Swift and wrote the whole app in it. I liked it a lot. Once I had the language down, I was very productive and able to implement almost any change that management requested in a few days at most.

SwiftUI, however, is a very different story. It's a half-assed, often brain-dead environment that has made building my own application from the ground up PAINFUL. Not only has it taken months to do what should have taken weeks, but SwiftUI and the attempted "reactive" paradigm it's supposedly optimized for are so full of holes that Apple's recommended practices simply don't work. "One source of truth" my ass; SwiftUI and the absurdly incomplete observation framework it relies on make that impossible.

I usually blame myself for just not having read enough, but with SwiftUI my research has far too often concluded with a finding that, "Oh yeah, that doesn't work."