Construir uma app mobile nativa requer muito trabalho; é necessário no mínimo codificar em duas plataformas, Kotlin/Java no Android, e Objective-C/Swift no iOS, o mesmo se aplica para a interface do usuário. No passado, o Dropbox e Slack implementaram uma estratégia para compartilhar código entre plataformas. Para isso, foi escolhido o C++, uma vez que o mesmo é suportado pela maioria das plataformas.
Recentemente, Eyal Guthmann from Dropbox e Tracy Stampfli from Slack, compartilharam o motivo de terem desistido do C++, concentrando-se no desenvolvimento usando as linguagens e recursos específicos das plataformas. Vamos explorar os motivos.
Em 2013, o Dropbox adotou uma estratégia técnica para compartilhar código entre o Android e iOS: codificando uma única vez em C++, ao invés do Java/Objective C. A equipe do Dropbox era relativamente pequena com uma alta demanda de funcionalidades para ambos iOS e Android.
De acordo com Guthman, o Dropbox abandonou a estratégia devido aos custos (não tão) escondidos associados com o compartilhamento de código.
Ao escrever o código de uma maneira não tradicional, assumimos uma sobrecarga que não teríamos que nos preocupar se tivéssemos ficado com os padrões de plataforma amplamente usados. Essa sobrecarga acabou sendo mais cara do que apenas escrever o código duas vezes.
A sobrecarga levou a equipe do Dropbox a construir frameworks e bibliotecas, tais como o Djinni, que é uma ferramenta para gerar declarações de tipos em várias linguagens; um framework para executar tarefas em background e na thread principal, algo que é trivial no Kotlin/Swift; o json11 para a (de)serialização de JSON; e o nn, que são ponteiros não nulos para o C++.
Afastar-se do padrão da plataforma, como o Android Studio/Xcode, também foi uma grande sobrecarga para a equipe do Dropbox. Guthman mencionou uma experiência de depuração na qual um bug estava causando um deadlock em uma thread sendo executada em background, fazendo com que a app finalizasse aleatoriamente. Foram necessárias semanas para resolver o bug uma vez que o mesmo envolvia depurar código multi-thread executando no C++ e Java.
Gerenciar as diferenças entre as plataformas também foi uma grande sobrecarga; mesmo a execução de uma thread em background ou como interagir com a câmera pode se tornar um problema. A equipe demorou muito tempo para integrar o código entre as plataformas específicas e escrever código específico da plataforma.
Treinar, contratar e reter os desenvolvedores também é um grande desafio. Guthman disse que no início da estratégia eles tinham um grupo experiente de desenvolvedores C++, e esse grupo começou o projeto em C++ e treinou outros desenvolvedores mobile. Com o passar do tempo, esses desenvolvedores migraram para outras equipes e outras empresas, e os engenheiros que permaneceram não tinham experiência suficiente para preencher o gap técnico. Eles tentaram contratar candidatos com esse skill set muito específico (mobile/C++ developer) por um ano sem sucesso, e por fim, os desenvolvedores mobile não querem trabalhar em um projeto C++ e alguns engenheiros mobile talentosos deixaram o projeto.
No Slack, a história não é muito diferente; eles construíram o Libslack, uma biblioteca C++ para encapsular regras de negócio compartilhadas, e gerenciar o cache e sincronização. O plano inicial era usar o Libslack no desktop, iOS, Android, e Windows Phone, mas devido a algumas estratégias de cache conflitantes, somente o iOS e Android acabaram usando o Libslack.
De acordo com Stampfli, no Slack assim como no Dropbox, houve uma sobrecarga após o Libslack. O Slack adicionou Libslack quando sua app mobile já estava madura, substituindo funcionalidades já existentes, e isso teve que acontecer em duas arquiteturas já estabelecidas. Antes do Libslack, cada cliente mobile tinha um calendário de lançamento de versão independente, e após o Libslack, foi necessário ajustar o ciclo de releases para que as versões fossem lançadas simultaneamente. Isso trouxe problemas como determinar o que corrigir, uma vez que a maioria dos engenheiros mobile no Slack não estavam familiarizados com o C++ e os processos para construir e depurar o Libslack para ajudar na correção de problemas na biblioteca.
Muitas das desvantagens que o Dropbox experimentou com sua biblioteca compartilhada também foram verdadeiras para o Slack. Como descrito em nossos posts anteriores sobre o Libslack, houveram certos benefícios em compartilhar código entre as apps clientes - uma biblioteca compartilhada aumenta a consistência de comportamento e evita a duplicação de regras de negócio similares em cada cliente Slack, por exemplo. Entretanto, também existem desvantagens nessa abordagem.
Stampfli mencionou que, assim como no Dropbox, é difícil contratar engenheiros mobile com experiência em C ++, o que tornaria difícil o crescimento e a manutenção do Libslack.
No final, o Slack decidiu que a sobrecarga do desenvolvimento da biblioteca superava os benefícios e, portanto, parou o projeto, voltando para uma abordagem nativa, usando a linguagem de plataforma específica para implementar a funcionalidade do Libslack separadamente em cada aplicativo cliente.
Você pode estar pensando, por que eles não usaram frameworks como React Native, Flutter, Cordova, Ionic ou qualquer outra framework?
Bem, no caso do Dropbox, quando eles iniciaram, o Swift ou Kotlin ainda nem existiam. O React Native e Flutter são frameworks relativamente jovens, e mesmo algumas empresas como o Airbnb, que estava usando o React Native, decidiu por deixar de usar o React Native por vários dos mesmo motivos, tais como problemas de depuração.