Building a new native mobile app requires a lot of work since it is necessary to code it in Kotlin/Java for Android, and then again in Objective-C/Swift for iOS. In the past, Dropbox and Slack had been implementing a strategy to share code between platforms, building a shared library in C++, until recently, when they decided to get rid of this.
Recently, Eyal Guthmann from Dropbox and Tracy Stampfli from Slack explained why they decided to get rid of C++, focusing instead on the native languages of both platforms. Let's explore the reasons.
In 2013 Dropbox adopted a pretty simple technical strategy to share code between Android and iOS: write once in C++, instead of Java/Objective C. The Dropbox team was relatively small, and they needed to ship lots of code on both iOS and Android.
According to Guthman, Dropbox abandoned that strategy due to the (not so) hidden costs associated with code sharing.
By writing code in a non-standard fashion, we took on the 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.
That overhead led the Dropbox team to build frameworks and libraries, such as Djinni, which is a tool for generating cross-language type declarations and interface bindings; a framework for running tasks in the background vs the main thread, which is a trivial task when performed in Kotlin/Swift; the json11 for JSON (de)serialization; and nn, non-nullable pointers for C++.
Moving away from the platform's default like Android Studio/Xcode was also a big overhead for the Dropbox team. Guthman mentioned a debugging experience in which a bug was causing a deadlock in a background threading framework, leading the app to randomly crash. It took weeks to get fixed because it involved debugging multi-threaded code running back and forth between C++ and Java.
Handling differences between the platforms was also a big overhead; even the execution of a task in the background or how to interact with the camera roll can become a problem. The team had to spend a lot of time integrating code into different platforms and writing platform-specific code, and sometimes that code ended up in the C++ layer itself.
Training, hiring and retaining developers is also a big challenge. Guthman said that at the beginning of the strategy they had a group of experienced C++ developers, and this group started the C++ project and trained other mobile developers. Over time, these developers moved on to other teams and other companies, and the engineers who remained did not have sufficient experience to fill the technical leadership gap. They tried to hire candidates with this very specific skill set (mobile/C++ developer) for over a year with no success, and in the end, mobile developers did not want to work in a C++ project and some of the talented mobile engineers left the project.
At Slack, the story is not so different; they built Libslack, a C++ library to encapsulate shared business logic, and to handle syncing and caching data. The initial plan was to use Libslack in desktop, iOS, Android, and Windows Phone clients, but due to some conflicting caching strategies, only iOS and Android really used Libslack.
According to Stampfli, at Slack as well as at Dropbox, there was overhead after Libslack. Slack added Libslack when its mobile apps were already mature, so it was replacing existing functionality, and it had to fit into two different established architectures. Before Libslack, every mobile client was shipped on a different schedule, and after Libslack, they shared the same release cycle. This brought problems such as determining what to hotfix, since most of the mobile engineers at Slack were not familiar enough with C++ and the processes for building and debugging Libslack to help fix issues in the library.
Many of the drawbacks Dropbox experienced with their shared library rang true for Slack as well. As described in our previous post about Libslack, there were certainly benefits to sharing code between client applications - a shared library increases consistency of behavior and prevents duplication of similar business logic in every Slack client, for example. However, there are also downsides to this approach.
Stampfli mentioned that just as Dropbox experienced, hiring mobile engineers with C++ experience is hard, which would have made it difficult to grow and sustain Libslack.
In the end, Slack decided that the overhead of developing the library outweighed the benefits and they therefore sunsetted the project, moving back to a native approach using the specific platform language to implement Libslack's functionality separately in each client application.
You may be thinking, why they didn't use frameworks like React Native, Flutter, Cordova, Ionic, or any other framework?
Well, in Dropbox's case, when they started, Swift or Kotlin didn't even exist. React Native and Flutter are relatively young frameworks, and even some companies such as Airbnb, who were using React Native, decided to sunset its use of React Native for a number of similar reasons, such as debugging problems.