Quais APIs/libraries de iOS e Android as empresas como Smule usam para criar aplicativos de música?

Versão curta: Porque o desenvolvimento para Android é uma porcaria. Eu implementei recentemente um recurso em um aplicativo tanto para iOS quanto para Android. No iOS, levei 23 linhas de código e alguns minutos. No Android, demorei 567 linhas de código e 3 dias.

Versão longa: Primeiro, deixe-me dizer que as outras respostas que falam sobre o pouco dinheiro que há no Android são, pelo menos parcialmente verdadeiras, mas (para mim pessoalmente) não é tão terrível como elas fazem com que seja. Eu faço uma quantidade não trivial de dinheiro dos meus aplicativos Android, mas eu faço mais do dobro dessa quantidade nos meus aplicativos iOS.

But to the main point... Android é uma droga. Eu sei que isso parece um argumento religioso, mas tenha paciência comigo.

Para ser claro, como um usuário Android, você provavelmente nunca experimentará nada que faça você pensar que o Android é uma droga. No entanto, ser um desenvolvedor Android é miserável porque o AndroidOS subjacente está gerações atrás do iOS.

Apple trabalha diligentemente para fazer o iOS WORK muito bem E parecer bem ao mesmo tempo. Muitos dos pedaços de doces visuais que a Apple inclui no iOS realmente ajudam na usabilidade, eles não são apenas para mostrar. Eles sutilmente comunicam informações ao usuário para que o usuário entenda o que está acontecendo e porque as coisas estão acontecendo.

No entanto, o Google se concentrou principalmente em apenas colocar o básico do Android funcionando porque eles valorizaram a idéia de expressão individual pelos desenvolvedores, ao contrário da Apple, que queria que os aplicativos tivessem uma aparência e uma sensação consistente. O problema é que a grande maioria dos desenvolvedores não é treinada em usabilidade ou design gráfico e por isso seus aplicativos pareciam grosseiros e funcionavam de forma rudimentar. Por volta da época do Android 4.x o Google percebeu que eles tinham um problema real porque não havia dois aplicativos Android que funcionavam da mesma maneira porque cada desenvolvedor tinha uma abordagem diferente. Eles começaram a tentar padronizar a interface e conseguiram que alguns de seus profissionais gráficos tentassem fazer os elementos visuais parecerem mais bonitos. Ainda não foi ótimo.

Aqui está um exemplo específico da diferença de esforço do ponto de vista do desenvolvedor. Eu tenho uma funcionalidade em um dos meus aplicativos iOS e queria ter certeza que essa funcionalidade também estava na versão do Android.

A funcionalidade envolve tocar + segurar em um item de uma lista/tabela e depois arrastá-lo para cima ou para baixo para reordenar os itens na tabela (arrastar e soltar). No iOS, isto só me levou 23 linhas de código porque essencialmente tudo já está incorporado no sistema iOS subjacente. O objeto UITableView (a rolagem lista que você vê em todo lugar no iOS) já sabe como responder ao tap+hold e já sabe como animar movendo a linha enquanto você arrasta o dedo... e já aplica uma bela sombra de gota enquanto você arrasta a linha... e já sabe como animar as outras linhas da tabela para sair do caminho enquanto você arrasta esta única linha, etc. Também já tem ganchos embutidos para que o sistema possa perguntar o meu código: O usuário deve ter permissão para arrastar esta linha? O usuário pode soltar esta linha entre x e y? e ele me dirá O usuário arrastou e soltou esta linha neste novo local, o que permite que meu código responda a esse evento.

É por isso que meu código iOS tem apenas 23 linhas. Tudo o que tenho de fazer é escrever o código que diz quais as linhas que podem ser arrastadas e depois responder a elas deixando cair a linha para que eu possa atualizar os dados subjacentes. Eu implementei esse recurso em alguns minutos no iOS.

Mas o Android não faz NENHUMA dessas linhas, por isso meu código Android tem 567 linhas e levei 3 dias para fazer tudo funcionar. Felizmente, neste UM caso em particular, eu não tive que escrever todo esse código sozinho porque muitos outros desenvolvedores Android reclamaram da falta desse recurso incrivelmente básico. Em resposta, o Google tinha postado algum "código de amostra" que mostrava como criar manualmente uma forma rudimentar de arrastar/pararar. Claro, esse código estava desatualizado porque foi escrito para o Android 4 e não funcionava para o Android 5, 6, ou 7 (7.x é a versão atual a partir desta escrita).

E seu código de amostra não envolvia nenhuma funcionalidade para verificar se certas linhas da lista/tabela deveriam poder ser arrastadas. Não incluiu nenhuma verificação para verificar se uma linha deveria ser permitida para cair em um determinado local. Não incluiu a capacidade de definir uma chamada de retorno para que o seu código pudesse responder ao reordenamento. Eu tive que pegar todo o seu código rudimentar e buggy e tentar melhorá-lo para que ele fizesse mais do que a versão do jardim de infância da funcionalidade.

Isso significava que eu passei vários dias para produzir uma funcionalidade que nem sequer funciona tão bem ou parece tão boa quanto a funcionalidade que já existe no iOS e me levou apenas alguns minutos. Tirei uma captura de tela do código de ambos e os coloquei lado a lado para que eu pudesse usá-lo para explicar a diferença. (veja abaixo. A captura de tela inclui os comentários no código, mas eu não contei os comentários na minha contagem de linhas.)

Quando tenho um cliente que quer seu aplicativo tanto no iOS quanto no Android, eu digo que a versão do Android vai demorar 4 vezes mais para produzir e só vai ser cerca de 80% tão bom. Quando lhes dou a cotação, determino quanto o aplicativo iOS levará para produzir e depois multiplico esse número por 2,5 para cobrir a versão do Android... que não paga -trultilmente - todo o meu tempo na versão do Android, mas cobrar 4 vezes a quantidade parece ridículo para eles porque não sabem como é.