O custo de compartilhar código entre iOS e Android

A Dropbox, quando começou em 2013, usava C++ para compartilhar código entre as duas plataformas.

Na época, a equipe era pequena, e isso era para dar suporte a um roadmap mobile em rápido crescimento.

Hoje, mudou para o uso de Swift e Kotlin, e isso se deve aos seguintes custos ocultos de compartilhar código (na verdade, nem são tão ocultos assim)

• Overhead de frameworks e bibliotecas customizados

• Overhead de um ambiente de desenvolvimento customizado

• Overhead para lidar com as diferenças entre plataformas

• Overhead para treinar, contratar e reter desenvolvedores

Em resumo, usar uma única base de código parece bom, mas o overhead é grande.

O importante é que o último parágrafo deste texto é basicamente: "Estamos contratando desenvolvedores Android / iOS!"

[godrm]

Não seria uma questão de ser ou não um overhead que a organização consegue suportar?

Independentemente do que escolher, se dá para suportar, acho que faz sentido focar naquilo que você faz melhor.

No fim das contas, parece que as diferenças entre as plataformas são inevitáveis. Mesmo criando algo híbrido, essas diferenças não desaparecem.

[iolothebard]

Cross-platform é apenas mais uma plataforma.

E ainda por cima mais complexa e mal-acabada..

[ohjongin]

Hoje em dia, o React Native parece estar bem maduro..

Claro, se for para um app dependente do dispositivo como o Dropbox, o sofrimento dos apps híbridos tradicionais provavelmente continua o mesmo..

[xguru]

O texto é longo, mas, na verdade, a Dropbox é um caso peculiar por usar C++,

então, para organizações pequenas, é verdade que no começo a ideia de dar suporte a múltiplas plataformas com um único código realmente parece atraente.

Há 10 anos, era assim com o desenvolvimento híbrido usando HTML5 e Phonegap,

hoje em dia, coisas como React Native e Flutter surgiram e seduzem todo mundo com a promessa de dar suporte a várias plataformas de uma só vez.

Na minha opinião, para organizações pequenas, compartilhar código dessa forma claramente tem vantagens.

Mas, à medida que o produto cresce, isso acaba se tornando dívida técnica novamente.

Quando os usuários aumentam, a organização cresce e o número de desenvolvedores também, acho que o resultado final é que Web/iOS/Android acabam evoluindo com tecnologias adequadas a cada um.

Como no bom texto sobre dívida técnica em https://pt.news.hada.io/topic?id=309,

o importante é criar dívida técnica de forma intencional. Vamos pagar a dívida antes que os juros aumentem.