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.

6 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?

  5. Ted Bendixson

    Mobile has a funny problem. I’ll try to break it down as best as I can.

    If I am a video game developer, and I want to put my game on every possible platform where there are paying customers, it makes sense to create a separation between code that is unique to my game and a small “platform layer” that acts as a conduit between Mac OS, Sony Playstation, Windows, etc. and my game.

    Since most video games feature 100% original art, user interfaces, interactions, and stylings, the bulk of the game code can be fully cross-platform while only a small portion of it is platform-dependent.

    That’s not so with mobile. When building mobile apps, we’re usually trying to take advantage of various existing SDKs, and it greatly changes the dynamic. There’s way more platform-dependent code because you’re trying to take advantage of Apple and Google’s scrolling tables and other various widgets that come with their kits.

    I haven’t really experimented with a cross-platform C architecture that flips the equation and goes with thick platform layers and thin cross-platform libraries. In principle, there’s no reason why it can’t be done, but there may be a good argument in favor of not introducing this sort of complexity to a team that (for the most part) isn’t likely to be familiar with lower level programming concepts and languages.

    That said, I can imagine an app where all of the layout is done in code (on both platforms) and the values for that layout come from some cross-platform C library, or one where the cross-platform library is responsible for simple common things like input validation, url manipulation and other common behaviors shared between both apps.

    That said, the thing in short supply is talented developers, and unfortunately most developers aren’t familiar with lower level programming languages like C. Very few programmers, in my professional experience, could build an app like the one I am describing. Most know just one or two languages. Only a handful could make a custom C library interface with Swift on iOS and Java on Android.

    None of this impossible or perhaps even impractical. It’s just hard to find the sorts of people who can do it.