Why Dropbox Abandoned C++ for Cross-Platform Development

Write once, run anywhere. This phrase has been used by countless tools and frameworks to attract more companies and developers. However, as a staunch practitioner of this strategy, Dropbox recently announced it would rather write two sets of code for different platforms than use C++ to share code between the two major platforms, iOS and Android.

Back in 2013, Dropbox adopted this strategy for mobile development, with a simple idea: write code once in C++, instead of writing it twice in Java and Objective-C. At that time, the entire mobile engineering team was relatively small but needed to support a rapidly growing mobile roadmap. Therefore, the company sought a way for this small team to quickly deliver a large amount of Android and iOS code.

Now, Dropbox has completely abandoned this strategy, turning to use native languages for each platform (primarily Swift and Kotlin, which didn’t exist when the mobile strategy was first formulated). The main reason for this decision is that the hidden costs associated with code sharing are too high, stemming from the same fundamental issue:

Writing code in a non-standard way incurs overhead for Dropbox, and if the widely used platform defaults were adopted, these overheads could be avoided, which ultimately becomes much more expensive than just writing the code twice.

Subsequently, Dropbox summarized the main reasons for the excessive costs, such as the overhead of custom frameworks and libraries, the overhead of custom development environments, the overhead of handling platform differences, and the costs associated with training, recruiting, and retaining developers, which are closely related to the issues inherent in C++. However, C/C++ is the only language whose compiler is supported by both Google and Apple, and using other languages would lead to a series of more troublesome issues.

The most common overhead associated with using C++ is the construction of frameworks and libraries, which can be broadly categorized into two types:

• Frameworks that allow developers to interact with the host environment and build a fully functional mobile application. For example, Djinni and frameworks for running tasks in the background and main thread.

• Some libraries that could have been used in the platform’s native language or open-source standards. For example: json11 for JSON (de)serialization; C++ non-null pointer nn.

If native platform languages were used, then this code would be unnecessary. Of course, this does not rule out the possibility that individual developers can make good use of open-source C++ libraries, but the open-source culture in the C++ development community is not as strong as in the mobile development community (especially the almost non-existent C++ mobile community). These costs are particularly high in C++ (compared to other possible non-native languages like Python or C#) due to its lack of a comprehensive standard library.

Although the C++ standards committee has done a lot of work for this language, even holding the largest meeting in history (with 180 attendees) to decide which features could be included in the new version, such as Concepts, Ranges, Modules, Coroutines, etc., most developers do not recognize these adjustments and dismiss some new features as “syntactic sugar,” complaining on social platforms.

A foreign game developer has repeatedly expressed views on social platforms, even publishing a lengthy statement expressing skepticism about the new features of C++20, believing that the new version does not address the most critical issues, leading to ridicule even before its release. This indicates that the entire C++ community has certain problems and struggles to achieve the level of activity found in the mobile development community, with many issues remaining unresolved.

The mobile ecosystem has many tools available to improve development efficiency, but the C++ community does not fare as well. Developers must invest time in building tools that support C++ code sharing. In fact, Dropbox even created a custom build system that included C++ code along with Java and Objective-C wrappers, generating target files recognizable by both Xcodebuild and Gradle. This system is a significant cost burden and drag, as it requires constant updates to support changes in both build systems.

Although iOS and Android applications are both “mobile applications” and usually have the same features and functionalities, there are inherent differences between the platforms that affect implementation; it is not truly possible to write code once and run it on different platforms. Considerable time must be spent integrating code into different platforms and writing platform-specific code (sometimes this code is located at the C++ layer).

Today, it is increasingly difficult to recruit senior engineers with relevant C++ experience who are interested in mobile development. Of course, if one is willing to increase recruitment costs and offer more attractive salaries, this issue is not difficult to resolve. However, how to retain these developers is also a significant problem. In fact, the mobile development community has a plethora of new technologies and patterns emerging, and mobile developers may not want to engage in C++ project development at all.

As mentioned above, sharing mobile code using C++ has led to exorbitant development costs, forcing former supporters like Dropbox to abandon this approach.

“Write once, run anywhere” has long been the dream of developers. However, based on Dropbox’s experience, the path to realization has been tortuous and even repetitive.

We found a particularly interesting piece of news: in 2014, Dropbox developers gave a lecture to Facebook developers sharing their experiences with cross-platform development using C++. They specifically mentioned that inconsistencies in the codebases for iOS and Android platforms would lead to a series of problems:

• Development and maintenance costs increase exponentially.

• Development teams need to fix the same defects multiple times.

• Defects reported for one platform may be ignored by another platform.

• App behaviors on different platforms may have unexpected subtle differences.

• Performance optimization costs are high and platform-dependent.

The strategy Dropbox relied on to overcome these issues was to establish a shared cross-platform C++ library for all UI-independent code, such as logic for data and networking. The UI portion was still written in native code to leverage the platform’s support for animations, effects, and device sensors as much as possible, ensuring adequate responsiveness.

Five years later, the experiences of that time seem to have turned into Dropbox’s technical debt, as they ultimately abandoned C++ for cross-platform development in favor of using native languages for each platform.

Is cross-platform development a trend or a thing of the past?

In 2018, Airbnb abandoned using React Native, returning to native technologies due to the difficulties in maintenance as projects grew large; the varying quality of third-party libraries; and the need to expend more energy on compatibility…

Fang Qiufang, a client engineer at Tencent, stated in an interview with InfoQ:

These are common issues with cross-platform frameworks.Cross-platform means spending a lot of time addressing platform differences while facing the reality that third-party libraries are not as rich and robust as native platforms.Cross-platform is essentially a trade-off, sacrificing some functionality and experience for development speed and consistency, not a silver bullet for business development.

The WeChat team’s solution for cross-platform development is:

The WeChat team currently does not use a unified cross-platform development framework.We are also actively exploring various possibilities.

WeChat Mini Programs represent a fusion of the first and second phases of cross-platform development, utilizing Webview as a rendering container, and through a specified subset of web technology stacks (WXML, WXSS), allowing the client to gain more rendering performance optimization space while gradually introducing native controls to replace Webview rendering.

In addition, we are also exploring cross-platform development based on C++.Essentially, this is still a second-phase approach, but using C++ as an intermediate language to write business code and call native controls.Why use C++?Because C++ offers higher security and better performance.It can be applied in scenarios where security is a higher requirement.

Will Flutter be the ultimate choice for cross-platform development? This question is quite meaningful. There are various frameworks that enable cross-platform development, making it overwhelming. The most popular cross-platform frameworks include Xamarin, PhoneGap, Ionic, Titanium, Monaca, Sencha, jQuery Mobile, React Native, Flutter, etc. However, the performance of these tools varies, each with its strengths and weaknesses. The only ones that remain hot are React Native and Flutter, primarily because they are backed by Facebook and Google, making developers more trusting.

The advantages of Flutter include: it is completely free and fully open-source; it allows for faster application creation; it has an excellent user interface (UI); it reduces code volume; it can access platform-native features; it is best suited for MVP development (minimal viable product); older devices can run applications with the same UI; it reduces testing workload; it has richer community support; it has lower maintenance difficulty; and it includes a built-in package manager from Dart.

Many of these features, such as reducing code volume, accessing platform-native features, supporting older devices, and lower maintenance difficulty, hit the pain points of cross-platform development. The industry believes that there is currently no perfect solution for cross-platform development. Relatively speaking, Flutter does a better job in compatibility, attempting to minimize platform differences through a self-developed framework from the ground up. However, reliability still needs further verification, and introducing Flutter requires companies to have a very clear understanding of their business and weigh the pros and cons.

With Google’s continued investment in Flutter, it may soon become the best solution for cross-platform development.