The Cost of Sharing iOS and Android Code at Dropbox
Until very recently, Dropbox had a technical strategy on mobile of sharing code between iOS and Android via C++. The idea behind this strategy was simple—write the code once in C++ instead of twice in Java and Objective C.
[…]
We have now completely backed off from this strategy in favor of using each platforms’ native languages (primarily Swift and Kotlin, which didn’t exist when we started out). This decision was due to the (not so) hidden cost associated with code sharing. Here are some of the things we learned as a company on what it costs to effectively share code.
[…]
Last, but definitely not least, is the cost of training and/or hiring developers to work on our very custom stack. When Dropbox started with this mobile strategy, we had a core group of experienced C++ developers. This group started the C++ project and trained 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.
C is basically the only truly portable and interoperable language.
Also, PALs are tough, often created with the inverse goals, and I’ve seldom seen them work well for anything that desires truly native integration.
I have come to this same conclusion after many years. It’s not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don’t get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or something. Other than that, it’s almost like the collective consciousnesses of Google and Apple conspire to make cost-effective code-sharing of typical CRUD apps almost impossible.
I often struggle trying to explain to more junior developers that there are times when it’s OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite.
Sometimes, it’s OK to write the same thing twice if the alternative is a major refactor - such as inventing your own stack.
It seems like the real issue was that Dropbox lost all of their senior C++ engineers. That’s a real mistake on their part, losing the only people who truly understand your product can be a death sentence for a company. I know my employer is very conscious of who knows what part of our products, and does their best to ensure that we never have any knowledge gaps.
Previously:
Update (2019-08-16): Sam Deane:
I’m well aware of the complications involved in maintaining cross-platform C++, but dubious about their conclusions. It smells to me (at least partially) of a spin on a technical management failure.
Fascinating stuff from a company that is about to launch an Electron-based desktop client.
5 Comments RSS · Twitter
Sounds more like people just aren't learning C/C++ much anymore. Hard to believe no one could maintain C++. I've been pretty critical of C++, but unless you're using really esoteric stuff primarily of interest to library authors, it's pretty easy to write clear easy to maintain C++. I'd have thought that any college graduate, even if their classes focused on Java or the like, ought be able to code in C. I guess not.
What is a PAL???
There were 3 colour TV standards: PAL, NTSC and SECAM. But this is not it. As to portability C and Forth stand out. Forth because you can adapt it to any chip, even one without a compiler.
Sounds more like people just aren’t learning C/C++ much anymore. Hard to believe no one could maintain C++. I’ve been pretty critical of C++, but unless you’re using really esoteric stuff primarily of interest to library authors, it’s pretty easy to write clear easy to maintain C++. I’d have thought that any college graduate, even if their classes focused on Java or the like, ought be able to code in C. I guess not.
That’s a simplistic and somewhat outdated picture.
For one, the dream of platform-specific UIs with a cross-platform business logic layer underneath is rarely a reality. Microsoft just accomplished it very recently, after almost three decades of trying (and a big misstep in the Word 6.0 era).
But even ignoring that, C++ in particular also isn’t that great a language for such a library. It’s riddled with pitfalls that lead to bugs, including security issues. We cared too little about this in the 1990s, and it’s starting to bite us in the rear big time. We’re finally reaching a point where languages like Rust and Swift might become a viable alternative (which hopefully means we’ll eventually move away from the terrible C-based APIs in Core Foundation).
Lastly, it’s not the job of a college to teach C++ or any other language in particular. Sure, a foundation into how the stack/heap memory model works is useful (though actually, to an increasing amount of developers, it really isn’t very relevant). But C++ is but a tool, and over the course of your career, it will be one amongst many.
