All Apple talks about these days is Swift. It feels as if Objective-C was going away. Should I start with Swift? Should I rewrite my existing Objective-C app in Swift? It depends on what you are doing.
If you have an existing code-base, there’s no point in rewriting it in Swift. That’s working, debugged code. Apple will not pull the plug immediately. Focus on doing stuff that your users see.
Apple has stated Swift is the future. So all their effort for improvements is going into Swift, Objective-C is a second-class citizen now. If you want to leverage all the work Apple is doing and save yourself work, it does not make sense to write new code in the old language if you don’t have to.
While you can mix Swift and Objective-C, there’s always friction, so I generally find that a good cut-off is to write new classes in Swift, and leave old ones untouched until you have to make larger changes to them or they are significantly improved by taking advantage of Swift features.
That said, you can write Swift extensions on Objective-C classes as long as they aren’t generic classes, and use the code from Objective-C as long as you stay away from Swift features that don’t map to Objective-C. So you can get a head start by writing new code in Swift, even if you’re not getting all the benefits right away.
If you are bridging to C++ code, wrapping it in C and then calling it through OpaquePointer etc. from Swift is very cumbersome compared to the ease and type-safety with which Objective-C++ lets you just mix the two languages, so often it makes sense to write thin Objective-C wrappers around C++ code and then use those from Swift.
However, Swift-to-C-to-C++ is still your best choice if you are dealing with high-performance code. There is a good deal of overhead in NSString-to-String conversion and Swift calling into Objective-C also performs a lot worse than calling C.
Performance and Stability
While theoretically Swift is engineered towards faster runtime execution, it is also a very new language, as such not all of Swift’s potential is actually realized yet. So if you have performance-critical code, compare the Objective-C and Swift versions of the code, and make sure it’s not a slowdown. Also, sometimes it may actually make sense to write an Objective-C or C version of critical code to see if it’s faster, at least until Swift has caught up with Clang’s head-start of years of Apple investing in performance optimization.
Undefined Behavior and Other Misfeatures
The C family of languages are notorious for having lots of subtle pitfalls that let you cause subtle memory issues under the hood (beyond the obvious issues like buffer overflows). Later languages like Swift or even more so Rust are engineered to not let you make these mistakes.
So there are various pragmatic, technical, and situational reasons why you might use Swift, or Objective-C.