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.
