The Swift naming convention makes it more difficult to learn, discover, and use large, complex APIs like AppKit and UIKit, so I'll often revert back to Objective-C when writing AppKit (and to a lesser extent, UIKit) when given the choice. It's common for me to still mix the two languages in a single app.

For example, this the AppKit API for pulling a URL off of the pasteboard:

    +[NSURL URLFromPasteboard:]

It's easy to find, since it has both URL and Pasteboard in the name.

The Swift version gets melted down to this:

    URL(from:)

which is obfuscated nonsense. Unless you already know that API exists, you'll never find it.

The Swift version of AppKit is littered with this kind of obfuscation. Since I don't code in AppKit very regularly, I usually just throw my hands up and switch to Obj-C whenever I start running into these kinds of road blocks.

The Obj-C naming convention has advantages and disadvantages, but has always been considered verbose. The Swift designers considered this a problem in need of a solution. As is almost always the case in software development and language design, the solution was a giant overreaction and overcorrection that just replaced one problem with another.