A software engineer from Dropbox explains the reasoning behind the company’s decision to no longer share code between iOS and Android.
Until recently, Dropbox shared code between its Android and iOS apps using C++ to only write once rather than in both Java and Objective-C. This strategy has been in place since 2013 when Dropbox’s team was still relatively small but needed to support a fast-moving roadmap.
Dropbox, now it’s a much larger company, has switched to developing its Android and iOS apps using each platform’s respective native language. In a blog post, Dropbox software engineer Eyal Guthmann provides some insight into what downsides the company found with sharing code.
Guthmann says all of Dropbox’s problems stem from one core issue: “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. This overhead ended up being more expensive than just writing the code twice.”
By writing cross-platform code in C++, Dropbox found it had to build many of its own frameworks and libraries.
Guthmann acknowledges it’s possible the firm could have done a better job at leveraging open-source C++ libraries, but in his experience, the community isn’t as strong as in mobile development. Furthermore, Guthmann believes that Dropbox’s open-source contributions would have reached more developers in the platform-native languages.
“These costs are particularly high in C++ (as opposed to other possible non-native languages like Python or C#) because it lacks a single, full-featured standard library. That being 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,” Guthmann wrote.
The next overhead Guthmann highlights with cross-platform development is the lack of access to platform-specific IDEs from Google and Apple. Android Studio and Xcode are feature-rich and each company invests a ton of resources into ensuring they’re great experiences with enhanced debugging for their respective languages.
“In addition to losing tools, we also had to invest time in building tools that would support C++ code sharing. Most importantly, we needed a custom build system that created libraries containing C++ code as well as Java and Objective-C wrappers and could generate targets that were understood by both Xcodebuild and Gradle. This system was a big drag on our resources as it needed to be constantly updated to support changes in two build systems.”
Guthmann notes how platform-specific differences must be accounted for, meaning it’s rarely a case of “write the code once” anyway. One particular example of this is how each platform handles apps wanting to execute background tasks.
Whereas most platforms achieve something of feature-parity with rivals over the course of their development, Guthmann notes how some things – such as interaction with the camera roll – have only diverged over time.
The final overhead Guthmann highlights is that of hiring and training developers to work on a custom stack. When Dropbox started its mobile strategy, the company started the C++ project with experienced developers while training other mobile developers at Dropbox on how to contribute to the codebase.
“Over time, these developers moved on to other teams and other companies. 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.”
You can find Guthmann’s full blog post here, it presents some interesting considerations to make before deciding to use one language for cross-platform development.
Interested in hearing industry leaders discuss subjects like this? Attend the co-located IoT Tech Expo, Blockchain Expo, AI & Big Data Expo, and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London, and Amsterdam.
