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.

Existing Code

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.

New Code

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.

C++ Code

If you are bridging to C++ code, wrapping it in C and then calling it through C functions from Swift is a bit cumbersome as you need to wrap all C++ types in C structs and manually memory-manage them, making it hard to use modern C++ features like std::shared_ptr for public types. Sometimes wrapping C++ in Objective-C using the Objective-C/C++ hybrid language Objective-C++ makes this easier, as you can easily call into 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.

Update: Removed mention of `OpaquePointer` with C++, that is only an issue if you do `typedef struct MyOpaqueStruct MyOpaqueStruct;` instead of using a pointer like `typedef struct MyOpaqueStruct *MyOpaqueStructRef;`.