My Wish For Swift At WWDC: C++ Support

At work, we support a lot of platforms. We support iOS and Android, Windows, Linux, supermarket checkout scanners, Raspberry Pis, old Windows CE devices, and more. And all the devices run our same (large) core code, and all that code is written in C++. I’m not the biggest fan of C++. But there’s no doubt when we need to write something that works across a range of platforms, it’s a rich, commonly understood tool. It’s also been a massive blocker for Swift adoption for us.

For our mobile customers, we do provide both Java and Obj-C APIs. They’re both just wrappings around our C++ core, and they do the conversion from all the Obj-C or iOS native formats into the raw buffers we need to handle in our C++ core. Whenever I look at doing a Swift native SDK in the future, I’m still stuck on not having native C++ support from Swift code. In order to provide a pure native Swift API in the future, I’d have to wrap our ever growing C++ source base once in Obj-C, and then wrap it again in Swift. It just doesn’t make sense to wrap the same code twice over.

Even when I step back from our core algorithms and look at our application level code, I still see issues. We have a lot of OpenGL code written in C++ (again, for portability.) If I ever need to share common code with our Android application, it’ll be written in C++. And I’m not the only one stuck in this situation. Apple themselves use C++ in projects like WebKit, and have been major proponents of C++ in their compilers.  There is a decent population of iOS and Android apps that share common C++ code, especially gaming applications.

I’m not saying that Swift is a bad language, or that people shouldn’t use it. But I’m bringing this up for two reasons.

Swift can never be the inevitable complete replacement to Obj-C without C++ support. Obj-C can not, and will not ever go away as long as Swift doesn’t support C++. And that’s totally ok. But the community needs to understand that this is a big shortcoming of Swift that will prevent Apple from sunsetting Obj-C. So unless Swift adds C++ support, the community needs to drop the idea that Obj-C will just disappear in the next 5-10 years. It can’t. I don’t think Apple internally can even get rid of it because of their support of C++ and cross platform projects. If Swift never gained C++ support, Swift only system frameworks in iOS or OS X do not seem like a possibility either. Neither does a major new platform that only supports Swift and not Obj-C.

Secondly, the community at large needs to understand that when you write a Swift API that does not bridge to Obj-C, a segment of users are being inconvenienced because they still have to write C++ code. You might think your tuple returning fancy modern non bridging Swift API is going to make everyone else’s lives easier, but to me it’s just a door to Obj-C bridging hell. In that case a pretty Swift interface isn’t saving me time, it may have just blown out my schedule.

Obj-C and Swift have been compared sometimes to Carbon and Cocoa. Two APIs that existed almost in competition, with only one surviving. As of right now, it’s hard to see that comparison as an accurate one. When Apple ended support for Carbon, they may have deprecated a few old technologies, but for the most part it was still possible to move any Carbon project into Cocoa. The same isn’t really true of Swift at this point. I have projects I can’t move in to Swift, even if I wanted to.

 

So my biggest wish for Swift this year at WWDC is C++ support. I don’t know if it will happen, I hope it will. If it does I could start laying out a transition to Swift possibly. But until it does, I’ll be continuing to write a lot of Obj-C code. And if it never happens, Obj-C definitely isn’t going anywhere.