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.
