How Swift and Kotlin Destroyed Dropbox’s Terrible C++ Pipe Dream

For years, Dropbox used C++ to share features between its various platforms. It now says that dream is dead; instead, it will focus on Swift and Kotlin for mobile platforms.

It began using C++ when its team was small, and chasing the ‘write once, deploy everywhere’ pipe dream was still viable. “We needed to find a way to leverage this small team to quickly ship lots of code on both Android and iOS,” Dropbox explained in its blog posting, adding: “We have now completely backed off from this strategy in favor of using each platforms’ native languages.” That is, Swift (iOS) and Kotlin (Android).

The blog post is an interesting look at technical debt and the cross-platform dream that frameworks such as React Native and Flutter haven’t delivered on. Dropbox claims those two frameworks have “limited adoption” and don’t eliminate technical debt. In Dropbox’s case, using C++ meant it had to create or use custom frameworks and libraries.

As the posting noted:

“None of this code would have been necessary had we stayed with the platform native languages, and our contributions to open source projects would have probably benefited more developers if they were in platform native languages.”

In addition:

“The mobile ecosystem has a lot of tooling available to make development more efficient. Mobile IDEs are very rich and Google and Apple have invested a lot of resources in making them the best development experience for developers on their corresponding platforms. By moving away from the platforms’ defaults we gave away some of these benefits. Most notably, the debugging experience in a platform’s native language is generally superior to debugging in C++ code via the platform’s default IDE.”

Perhaps the most underrated pitfall of these types of stacks is hiring and on-boarding. Dropbox said it began with a core group of C++ developers, so using such a customized stack was appropriate; a small team of developers using the same language, rowing in the same direction – it worked. But not forever.

“Over time, these developers moved on to other teams and other companies,” Dropbox wrote. “The engineers who remained did not have sufficient experience to fill the technical leadership gap that opened up, and it became increasingly difficult to hire replacement senior engineers with relevant C++ experience who would be interested in mobile development.”

In closing, “although writing code once sounds like a great bargain, the associated overhead made the cost of this approach outweigh the benefits.” We won’t dissuade anyone from their favorite framework, language, or technology… but we do suggest making yourself aware of the pitfalls.

This is also a good reason to go native for mobile platforms, however minuscule your actual footprint on mobile. Even if your team carves out one or two roles for each mobile platform, it’s far better to allow them to maneuver within native frameworks than to create a custom stack that morphs into something totally unsustainable and cumbersome.

Aside from fully native being easier to support long-term (and hire into), incoming technology makes it almost mandatory for a great number of services and applications. For instance, as augmented reality rounds into shape and become useful in just about every scenario, native is the only way to go. In a general sense, Dropbox’s new direction (“We want our engineers to have a delightful experience and to be able to contribute back to the community”) is one every company should follow, and go native.

5 Responses to “How Swift and Kotlin Destroyed Dropbox’s Terrible C++ Pipe Dream”

  1. I wonder how Tango feels about this. They were using a very similar C++ library with native UI wrappers approach when I interviewed there years ago, but I have no idea whether they stuck with it.

  2. Their original mentality shows that they really didn’t understand the whole software development lifecycle. It pains me to see developers talk about “development time savings” while failing to understand that the majority of time will be spent in MAINTAINING the product AFTER the initial development is done. You can expect anywhere from 5 to 20 times the effort during the maintenance cycle. So saving a few hours up front at the expense of an additional 20 hours later just doesn’t make much sense.

    This also applies to everyone’s favorite new languages that promise “increases in productivity” by allowing you to “type less”. In the end, these types of languages do not really save you anything because they invariably result in much higher maintenance costs due to hard to find bugs and just generally being harder to understand for beginning programmers.

    The goal of any product architecture should be that you can someday hire any Joe Blow programmer off of the street and they will not be able to screw it up too badly because it is easy to understand how it works. The developers at Dropbox clearly didn’t understand this concept and now they have to re-develop the whole thing all over again.

    These are lessons that most programmers never get experience with because they are never involved in development of large scale systems. Writing a few minor “tools” in your favorite “scripting language” is not “real” programming. It is “scripting”. And there is a big difference…

  3. Good modern languages reduce development costs AND maintenance costs. My experience migrating apps from objective-C to Swift as well as Java to Kotlin is that the process is 95% automatic and 5% “oh that’s a bug, how has it been missed until now?” (Percentages are in terms of lines of code, measuring by effort would be the reverse). The answer is, of course, that language designers are advancing their field, and programmers benefit from getting more features and more safety for less effort. I agree that throw-away tools are very different than full-lifecycle commercial apps. But vast enterprise systems are built on JavaScript and Python, and I wouldn’t say those developers aren’t programming.

  4. I would be interested to get opinions on using tools such as React, Electron, and Progressive Web Apps as ways to create cross-platform functioning programs that allow for execution on the desktop and on mobile devices of various kinds. Any thoughts, y’all?