News

Dropbox Abandons Cross-Platform C++ for Mobile, Goes Native

• By David Ramel
• August 16, 2019

Is the Holy Grail of cross-platform code-sharing for iOS and Android mobile apps attainable? Dropbox doesn't think so -- at least not with C++.

The enterprise storage specialist has abandoned its cross-platform approach to creating mobile apps using C++, instead going to a pure native approach for each platform.

The cross-platform vs. native coding debate for mobile development will go on forever, but the experience of Dropbox indicates C++ might not be the best option for the former approach.

"Although writing code once sounds like a great bargain, the associated overhead made the cost of this approach outweigh the benefits (which turned out to be smaller than expected anyway)," the company said in a blog post this week. "In the end we no longer share mobile code via C++ (or any other non-standard way) and instead write code in the platform native languages."

Dropbox is now primarily using Swift for iOS and Kotlin for Android development, the more modern approach that's usurping the Objective-C-for-iOS and Java-for-Android tradition.

Ironically, Swift and Kotlin didn't exist when Dropbox adopted the C++ cross-platform strategy in 2013 when it was younger, with a small dev team tasked with shipping a lot of mobile code.

The Dropbox team discovered its C++ approach ended up causing more problems that it solved, and never even reached the point where most of the codebase was created with C++. The team likened its code-sharing failure to that of Airbnb, which stopped using React Native (as did Udacity) last year.

The main problem, the team said in the blog post this week, was the extra overhead incurred with a customized C++ development solution.

"By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults," said Eyal Guthmann in an Aug. 14 blog post titled The (not so) hidden cost of sharing code between iOS and Android. "This overhead ended up being more expensive than just writing the code twice."

Guthmann detailed for main types of overhead:

• The overhead of custom frameworks and libraries
• The overhead of a custom development environment
• The overhead of addressing differences between the platforms
• The overhead of training, hiring, and retaining developers

Several other factors also affected the company's change in direction, all together causing doubts about the elusive goal of mobile development code sharing.

"It's also worth noting that much larger companies like Google and Facebook have been developing scalable code-sharing solutions for several years," Guthmann said. "These solutions have, so far, gained only limited adoption. While you can avoid some of the overhead described below by leveraging a 3rd party code sharing solution like React Native or Flutter, some will still apply (at least until one of these technologies gains traction and mature). For example, Airbnb sunset their use of React Native for many of the same reasons outlined in this post."

Reader reaction to the post was mixed, with some developers questioning the whole notion of using C++ for mobile development to begin with. For example, among popular approaches, React Native (though not really cross-platform) uses JavaScript, Flutter uses Dart and Xamarin uses C#. Other readers maintained that cross-platform code-sharing can be done successfully with alternative tooling such as Xamarin.

"I wouldn't say I agree with lumping that approach with React Native / Flutter since these platforms, especially React Native, have been seeing quite a widespread adoption. In addition to that, it depends on what you are moving on a shared code layer as well -- if it is the business logic for a tech-heavy app such as Dropbox, and not the presentation layer, especially with an app that is integrated deeply with the system APIs, it is a much much different challenge than aligning buttons and views."