It’s already here: preliminary, early support to mix Swift and C++ in a way that does not involve Objective-C++ bridging. You can find forum posts about it here and learn more about their thoughts in this (older) announcement.
Maybe you’re new to Swift programming with Xcode and wondering why you should bother with mixing code. There are a few use cases where I believe C++ integration would be a great match:
- Old desktop apps designed for legacy Windows versions
- Reusing code from Linux application projects
Old desktop apps. I think most readers are thinking ”wait, what did you just say. Come again, please?”. This point needs an explanation: imagine you have been developing desktop apps for Windows since the Windows 98 days. You chose C++ as the programming language all those years ago and for each project, the GUI code was all made with Visual Studio and Win32 API calls.
Recently you started looking for ways to introduce Mac versions of your software, but on closer inspection you were disappointed to find that you would either have to:
- Rewrite your code from scratch
- Invest time in bridging code through Objective-C++. This could be a complex process, which means the potential of introducing unwanted memory leaks.
- Convert the GUI code to use the cross-platform qt framework or similar.
Let’s start with the first option: rewriting it from scratch, in Objective-C or Swift. This is going to be time-consuming and the users are likely going to see an ”alpha preview” label in the Mac app for quite a while.
Next up: bridging to Objective-C++. This means you will be dependent on Objective-C technology in a time when Swift is the norm for all new codebases, which isn’t a great start. It also means you are going to spend time learning how to write Objective-C functions, classes, implementations, interfaces, etc. Afterwards, you spend time learning as much Swift as possible. You never really cared about Objective-C in the first place, but now you need to learn two languages while developing the Mac app(s).
Lastly: convert to qt or another cross-platform GUI framework/library. This could end up being very practical, but on the other hand you miss out on tight integration with the OS. You won’t get easy access to Siri intents, Charts or Widgets exclusive to SwiftUI, etc.
Swift with C++ enters the scene
Now, what if your app could utilise the backend C++ algorithms your team spent years perfecting, while a GUI (frontend) is built around that codebase in Xcode using Swift XIBs, storyboards and/or SwiftUI? There is potential for this technology to help companies create Mac apps that feel completely native, using code borrowed from Windows or Linux projects.
Reusing C++ in iOS projects
There is nothing stopping you from using it in iOS. With SwiftUI being as flexible as it is, old Windows or Linux code could show up even in an iPhone or iPad.
The challenge is to optimise the code to run on multiple operating systems without hiccups or memory leaks. I never said this would be easy, but I do find it really interesting. Once the C++ integration hits a significant milestone in the future, where you can mix Swift and C++ really seamlessly, we’ll know what kind of app transformations are possible. No matter the outcome of the work done to enable the code mix, I’m excited about it as a programmer. I think it will increase the status and attraction of Swift in production-grade apps.
