This article is more than 1 year old
Dropbox would rather write code twice than try to make C++ work on both iOS and Android
Write once, run anywhere? You must be joking
Dropbox has abandoned a longstanding technical strategy of sharing C++ code between its applications for iOS and Android, saying the overhead of writing code twice is less than the cost of making code-sharing work.
The online storage outfit formed the previous strategy in 2013 to enable a small team to ship code quickly. It has now "completely backed off from this" in favour of using native languages for each platform, "primarily Swift and Kotlin".
Software engineer Eyal Guthmann gave several reasons for the decision. He said the open-source culture in the C++ dev community is weak, especially when it comes to mobile, so they had to build frameworks to address cross-language type declarations and interface bindings (to connect with Objective-C and Java), JSON parsing and serialisation. This would not have been necessary using the native libraries. The team also had to create a custom build system.
Second, Guthmann said the tooling for cross-platform development is weaker than for the native languages, which means bugs were harder to find. One issue involving multi-threaded code between C++ and Java took "weeks to nail down".
Third, because of differences between iOS and Android, not all code can be cross-platform. You have to write platform-specific code for certain things – interaction with the camera roll, for example.
Fourth, it was hard to find senior developers to work in C++ mobile.
Dropbox may have made cross-platform coding particularly challenging by choosing C++ rather than C# or JavaScript. On the other hand, Guthmann said: "C/C++ are the only languages with a compiler supported by both Google and Apple, so using a different language would have created a whole host of other problems to deal with."
The particular problems faced by Dropbox will not apply to every project. Dropbox needs to integrate deeply with the operating system and performance is critical. It is possible that a custom business application, for example, will be a better use case for a cross-platform solution since it does not have to integrate to the same extent. Cross-platform C++ might also make sense for applications that make heavy use of non-visual algorithms.
That said, Guthmann's post does show that the dream of write once, run anywhere is, in practical terms, still far off for many types of application. ®