Some days ago, Dropbox developers through a post on the official blog of the application unveiled the route they intend to follow in terms of mobile development of your cross-platform application, where the team has decided to create a unified code base, for various purposes or platforms.
The approach can be useful for small teams with little skill, but production is needed as quickly as possible. Since 2013, the Dropbox team has relied on this strategy. TOtip to Android and iOS platforms through a unique code base built in C ++. The post explains why the company now prefers native development on Swift and Kotlin.
“By assembling our codebase in a non-standard way, we inherited costs that we would not have had to worry about if we had aligned ourselves with the default weapons that third parties use on a large scale.” In the end, it was more expensive than writing code. twice, "he said.
Abruptly, Dropbox engineer feedback shows that choosing the cross-platform development approach introduces additional development costs related to deploying custom libraries and frameworks.
Not to mention those related to the implementation of customized work tools or the need to train or recruit third parties capable of adapting to a highly customized software stack.
In fact, emphasizes that choosing C ++ for Android and iOS cross-platform development may lead developers to face difficulties that they would not have had natively.
For example, he says, establishing a framework for managing tasks that run in the background can be a must in the cross-platform C ++ development pipeline.
By contrast, Another engineer explains the Dropbox engineer, it is not a problem in native.
It even claims that the Dropbox team, in the process, had to set up a JSON library for C ++ 11, as well as another for handling NULL pointers.
The company engineer went even further by emphasizing that he is turning to the theory of thinking that one can build a single code base for multiple platforms.
In fact, he insists, the specificities of each platform are factors that cannot be avoided.
"The way an application runs work in the background is platform specific, and you have to look at it from the beginning," he says.
In addition to the considerations that affect the code, there are those that concern the work tools. In this sense, the company's engineer develops in two axes: debugging and configuration of personalized tools.
“The native debugging experience is generally superior to C ++ through the default IDE of the target platform,” he writes, adding that “in addition to having to move away from available tools, we had to mobilize development efforts for the development of others capable of supporting the cross-platform approach in C ++. «
Finally, in terms of training and recruiting aspects, Eyal Guthmann indicates that the cross-platform adventure was built around a core of engineers with a solid background in C ++.
With the departure of the latter to other teams or companies, the company has found it increasingly difficult to fill the technical gap to maintain the C ++ code base. Internally and externally, the company has had trouble training and recruiting on this axis, because it seems that very few mobile developers are interested in C ++.
Moving the team from Dropbox to native via Kotlin and Swift for Android and iOS has benefits.
In fact, the C ++ language, along with the C you no longer cite, serves as a common denominator for managing such problems.
It is not difficult to imagine that the initial group of engineers integrated it for the management of certain critical aspects of the backend. Only, questions about the quality of the C ++ interface with target platforms can be put on the table.