"Hidden costs" developed in iOS/Andrioid in Dropbox and Slack

Link to the original (Posted: 2019/11/25)

The development of a new native mobile app requires a lot of effort.This is because Kotlin/Java for Android must be done again using Objective-C/Swift for iOS.Dropbox and Slack have been implementing the code between platforms by describing the shared library in C ++, but recently decided to stop this method.

Dropbox's Eyal Guthmann and Slack Tracy Stampfli explained why they decided to stop using C ++ and migrate them to native languages on each platform.Let's introduce the contents.

In 2013, Dropbox adopted an extremely simple method to share Android and iOS code.I decided to write in C ++ first instead of Java or Objective-C.The Dropbox development team was relatively small, but it was necessary to provide a large number of code for both iOS and Android.

According to GuthMan, Dropbox abandoned this method because of hidden (not) hidden (not) codes.

As a countermeasure for overhead, the Dropbox team has developed a number of frameworks and libraries.DJINNI, a tool that generates type definitions that can be shared between languages and interface bindings in the background to the main thread — for Kotlin or Swift, a framework for a framework for easy tasks.JSON11, which performs serializes and decoration, and NN, which realizes non -NULL pointer with C ++.

The unable to use the default development environment such as Android Studio and Xcode has also been a major overhead for the Dropbox team.Gutgman talked about the experience of debugging the random crash of the app by a bug in the bag ground thread framework.He said he spent a few weeks because it was related to multi -threaded cord debugging between C ++ and Java.

Processing for differences between platforms has also become a major overhead.Running tasks in the background and how to access camera rolls could be a problem.The team spent a lot of time to integrate code into different platforms and describe the platform -specific code.Eventually, the unique code itself could be a C ++ layer.

Training, hiring, and stopping developers was also a big challenge.Guthman said that when he adopted this method, there was an experienced C ++ developer group in the company, and they first launched the C ++ project and trained other mobile developers.Later, these developers transferred to other teams and other companies, but the remaining technicians had no sufficient experience to fill the technical leadership gap.I tried to hire a developer with a very special skill set (mobile/C ++ development), but there was no result, and as a result, the mobile developers would not be involved in the C ++ project, and one of the ability.The mobile developer in the club will remain in the project.

Slack does not change the situation -the company is developing Libslack, which enhances shared business logic and processes data synchronization and cache.In the original plan, Libslack was planned to be desktop, iOS, Android, and Windows Phone clients, but it was actually used only on iOS and Android because of inconsistencies related to cash processing.

According to STAMPFIL, Slack has overhead after the introduction of Libslack, like Dropbox.Slack was planning to add Libslack to already stable mobile apps and replace existing features, so it was necessary to fit two established architectures.Before the introduction of Libslack, each mobile client was provided on different schedules, but after the introduction, the release cycle began to share.As a result, problems have been caused by the decisions for hot fixes.Most of the Slack mobile engineers were not familiar with the builds and debug processes needed to fix the C ++ language or Libslack problem.

As Dropbox has experienced, it is difficult to hire a mobile engineer with C ++ experience, which makes it difficult to expand and maintain Libslack.

In the end, Slack determined that the overhead of Library development exceeded the merits, so the previous native approach is to be canceled and the Libslack function is implemented for each client application using platform -specific languages.I decided to return to it.

You may be wondering why you did not use any other frameworks such as Reactive Native, Flutter, Cordova, and Ionic.

In fact, in the Dropbox case, neither Swift nor Kotkin existed at the start.React Native and Flutter are relatively young frameworks, but some companies, such as Airbnb, which used React Native, decided to stop using React Native for similar reasons such as debugging.There is.