I want to start by saying that I speak only for myself. I don't speak for other Objective-C programmers, nor do they speak for me. We are not of one mind. The same is true of Swift programmers: some of them seem quite reasonable to me, and others seem rather… fanatical. Regardless, it's almost impossible to have a productive discussion about programming languages on social media, given the constraints of brevity, and also given the freedom of fanatics to barge in on the discussion at any time, effectively ruining it. This is why I'm taking the time to expound here, free of those constraints. My aim is not to persuade anyone to choose a particular programming language, just to explain my point of view in reasonable terms, without the caricatures and insults regurgitated on social media.
Although I didn't jump on the Swift bandwagon in 2014, I didn't refuse to learn Swift either. In 2017 I wrote an open source Swift app, just to show that I could do it. (This is back when I was still looking for a job.) By popular demand, I also wrote Swift sample code for my long-running Working Without a Nib series of blog posts describing how to create a Mac app, and specifically a Mac app's main menu, without nibs/xibs/storyboards. In fact I've written several blog posts about Swift programming. I can't say I'm a Swift expert, but you can't say I'm a Swift ignoramus. Having used Swift a bit, I ultimately didn't find a reason to switch full-time from Objective-C to Swift. I think I share one opinion with many Swift programmers, which is that it's difficult to fluently alternate between Objective-C and Swift. After writing a lot of Swift, you tend to lose your Objective-C habits, and vice versa. For the sake of maximum productivity, writing both languages simultaneously is the worst of both worlds — especially in the same project! — and it's probably best to choose one language or the other for most of your work. I personally chose to stick with Objective-C.
Perhaps I was unlucky, but my Swift experience turned out to be unpleasant. My main complaint is that the Swift team killed my Swift app. In other words, the app will no longer build with Swift version 5, giving the compiler error "cannot override with a stored property", and it would require a significant refactor of the app to avoid the compiler error. I don't have the time or desire to put that much work into a free open source app, especially without a ton of users. Fortunately, Xcode still supports building with Swift version 4.2, but we know that support for Swift 4 will eventually be removed from Xcode, as has support for Swift versions 1, 2, and 3. I did file a bug with the Swift project in 2018 about my issue, which was only a compiler warning in Swift 4, becoming a compiler error in Swift 5. However, the bug was immediately closed as "Won't Do", so the Swift team is apparently not interested in preserving backward compatibility. Whereas with Objective-C, the backward compatibility situation is mostly wonderful. Recently I took an open source Objective-C project last updated in 2006, in the ppc/i386 era, and all it took was a few build setting modifications to recompile for Apple silicon. It Just Works™!
(Aside: In fairness, the Objective-C Garbage Collection situation was a dumpster fire. Apple removed GC entirely from Mac OS X, killing all apps that used it. This was after certain Apple evangelists who shall remain nameless pushed Objective-C GC zealously. I never jumped on the GC bandwagon myself, but some developers did, to the detriment of themselves and their users. The removal of GC was one of the worst violations of backward compatibility in Objective-C history. Fortunately, it was the exception, not the norm.)
Another major issue I had with Swift was that I found bridging of objects between a Swift app and the Objective-C Apple frameworks to be very problematic. For example, Swift String and Objective-C NSString have different criteria for equality: Unicode canonical equivalence for the former, UTF-16 code unit sequence for the latter. Moreover, both Swift Dictionary and Objective-C NSDictionary frequently use strings for dictionary keys. This can produce unexpected results and bugs when you bridge String/NSString and Dictionary/NSDictionary, a common occurrence in AppKit and UIKit Swift apps. Add UserDefaults/NSUserDefaults to the mix, and it's a minefield. I'm not sure how you're even supposed to "code defensively" for this situation, because it's an inherent "feature" of the language bridge.
id and always skip
nil checking; complaining about that is really the job of your coworkers in code review.
What else do I prefer about Objective-C over Swift?
One more thing I'll discuss. Is Swift easier to learn than Objective-C? I don't know. Maybe, maybe not. I'm skeptical. Perhaps it's easier to get started in Swift, but I personally think it's harder to master Swift than to master Objective-C. It feels like there's a lot more complexity to Swift, once you get beyond the basics. Regardless, I learned C by reading the classic "C Programming Language" by Kernighan and Ritchie, and I learned Objective-C by reading Apple's own "Objective-C Programming Language" in their online developer documentation (archive, sigh). At the time, I didn't think in terms of "easy" or "hard". I wanted to learn how to write Mac software, so I had to learn Objective-C. There was no choice. I didn't pity myself for having to learn Objective-C, it was simply a technical requirement. Every programmer who wrote native Mac OS X and iOS apps prior to 2014 had to learn Objective-C, and it was fine! Countless great apps were written in Objective-C. The operating systems themselves were written in Objective-C. It didn't feel like a burden to me at the time, and it still doesn't feel like a burden to me.
Professional programmers will typically learn many programming languages over their careers, and in my experience, they're all approximately the same level of difficulty to learn. Each of them can be learned with several months of full-time use, give or take. I don't see a massive difference between the languages. There's a learning curve at the beginning, then eventually you make it over the hump, and you spend a lot more time in the learned state than you do in the learning state, so the initial cost is easily paid back if you stick with the language.
In 2007, programmers rushed en masse to iPhone because they were attracted by the platform, not by the language. Just as I was attracted by the Mac platform, not by the language. If the "selling point" of Apple development today is not the platforms but rather the programming language, if Swift is how you recruit programmers to the platform, that's actually a sad commentary on the state of the platforms, in my opinion. I feel that the crap store lockdown and race to the bottom have drained much of the enthusiasm out of our industry, and left us in a state where we think the programming language is the most exciting thing in the world.