Why Dropbox walked away from C++ code sharing

From 2013 until recently, Dropbox maintained a mobile engineering strategy of sharing iOS and Android code through C++. The initial reasoning was straightforward: with a small mobile team facing a rapidly growing roadmap, writing logic once in C++ instead of twice in Java and Objective-C promised significant leverage.

The company has now fully abandoned that approach in favor of native development, primarily with Swift and Kotlin — languages that did not exist when the C++ strategy was adopted. The reversal was driven by what Dropbox calls "the (not so) hidden cost" of sharing code across platforms. That cost stemmed from one central problem: by writing code in a non-standard fashion, the team took on overhead that would have been avoided entirely by staying with platform defaults. That overhead turned out to exceed the cost of writing the code twice.

Notably, Dropbox never reached the point where most of its codebase was C++. The overhead of C++ adoption prevented full migration in that direction. The company also notes that larger players like Google and Facebook have spent years building scalable code-sharing solutions with only limited adoption, and that third-party frameworks such as React Native or Flutter avoid some of these costs but not all — pointing to Airbnb's decision to sunset React Native as an example.

Frameworks and libraries nobody wanted to build

The most predictable overhead was the need to create custom frameworks and libraries. This fell into two buckets:

  • Frameworks for interacting with the host environment to build a full mobile app. Dropbox built Djinni, a tool for generating cross-language type declarations and interface bindings, plus a custom framework for managing background versus main thread tasks — something trivial in native languages.
  • Libraries that replaced language defaults or open source standards. Dropbox wrote json11 for JSON (de)serialization and nn for non-nullable C++ pointers.

None of this infrastructure would have been necessary with native languages. The company also notes that the C++ open source culture — particularly for mobile — was weaker than that of the mobile development community, and its own open source contributions might have served more developers had they been written in platform-native languages. These costs were especially high in C++ because, unlike languages such as Python or C#, it lacks a single, full-featured standard library. However, C/C++ are the only languages with compilers supported by both Google and Apple, so choosing another non-native language would have introduced its own problems.

A degraded development environment

By moving away from platform defaults, Dropbox lost access to the rich tooling that Apple and Google have built for their respective IDEs. Debugging in C++ through a platform's default IDE was generally inferior to debugging in the native language.

The team recalls one particularly painful example: a bug causing random app crashes due to a deadlock in the custom background threading framework. Because the issue required debugging multi-threaded code that ran back and forth between C++ and Java, it took weeks to resolve — a task that would have been far more tractable in a standard stack.

The team also had to build its own tooling to support the C++ sharing model. Most significantly, they needed a custom build system that created libraries containing C++ code plus Java and Objective-C wrappers, while generating targets usable by both Xcodebuild and Gradle. This system demanded constant updates to keep pace with changes in two build systems.

Platform divergence ate at the "write once" premise

Despite the assumption that shared code means writing logic once, iOS and Android differ in ways that affect implementation. Background task execution works differently on each platform, and even behaviors that were initially similar — like camera roll interaction — diverged significantly over time.

This meant code could not simply run on both platforms out of the box. Considerable effort went into integrating code into each platform and writing platform-specific code, sometimes even inside the C++ layer itself. As a result, the promised benefit of writing code once never fully materialized, which significantly reduced the theoretical advantages of the approach.

The human cost: hiring and retention

The final and most significant expense was talent-related. Dropbox started with a core group of experienced C++ developers who launched the project and trained other mobile engineers to contribute. Over time, those developers moved on to other teams or companies. The engineers who remained lacked the expertise to fill the technical leadership gap, and hiring replacement senior engineers with relevant C++ experience who were interested in mobile development proved extremely difficult. Dropbox tried to hire for that role for over a year without success.

Training in-house was practically impossible once the expert group had left — there was no one left to perform the training. Even before that, mobile engineers were generally uninterested in learning C++, making it hard to find willing trainees.

The custom stack also created a retention problem. Mobile developers who wanted to keep their skills current did not want to work on a C++ project. The mobile community, Dropbox notes, is highly dynamic, with new technologies and patterns adopted quickly. While keeping up with the latest trends is a challenge even with a standard stack, locking into a custom stack that sits outside the wider mobile ecosystem magnified that problem considerably.

Aligning with industry standards

Dropbox no longer shares mobile code via C++ or any other non-standard method. The company now writes code in platform-native languages, prioritizing what it describes as a delightful engineering experience and the ability to contribute back to the developer community.