The (not so) hidden cost of sharing code between iOS and Android

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 adopted this C++ strategy back in 2013, when our mobile engineering team was relatively small and needed to support a fast growing mobile roadmap. We needed to find a way to leverage this small team to quickly ship lots of code on both Android and iOS.

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. And they all stem from the same basic 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.

Say it with me: "write once, run everywhere" is a terrible long-term approach for building mobile apps.

One of the biggest reasons we lose leads is because people are swayed by the promise of having a single codebase that runs on iOS, Android, and the web. Solutions like Xamarin, Flutter, and React Native are touted as these golden solutions that will save you time and money.

These solutions, however, introduce a layer of overhead that end up making it more expensive than it would have been if you did it the right way from the start.

If you are looking to build custom mobile software for your business, learn from Dropbox's example and build your apps using native frameworks from day one.