A sua empresa precisa de duas apps desenvolvidas separadamente ou pode partilhar código entre iPhone e Android?
A nossa recomendação é começar pelo que a app tem de fazer e pelas condições em que vai ser usada. Só depois deve escolher a tecnologia. Se o percurso do utilizador for semelhante nos dois sistemas, vale a pena avaliar uma solução multiplataforma. Se uma função decisiva depender de uma integração específica, peça uma demonstração dessa função antes de adjudicar.
Não escolha desenvolvimento nativo apenas porque parece mais seguro. E não aceite multiplataforma apenas com a promessa de fazer tudo uma vez. A própria documentação de Flutter e React Native prevê código específico para cada sistema. A partilha existe, mas tem fronteiras. (docs.flutter.dev)
Primeiro, esclareça o que está realmente a comparar
Para esta decisão, vamos chamar desenvolvimento nativo separado à construção de uma versão para iOS e outra para Android, com interfaces e implementação próprias de cada plataforma. Por multiplataforma, entendemos uma solução que partilha parte do código entre ambas. Há também soluções intermédias: o Kotlin Multiplatform permite partilhar regras e tratamento de dados, mantendo interfaces específicas. (kmp.jetbrains.com)
Isto significa que a escolha não se resume a duas caixas fechadas.
Partilhar também os ecrãs
Uma ferramenta como o Flutter permite reutilizar código da interface e da lógica da aplicação. Usa os seus próprios componentes visuais e pode comunicar com serviços do sistema operativo. Não se limita a colocar um website dentro de uma app. (docs.flutter.dev)
É uma opção a considerar quando você quer que o produto tenha uma identidade visual e percursos semelhantes no iPhone e no Android.
Partilhar as regras, separar a interface
Também pode existir um núcleo comum que trata dados e aplica regras, enquanto cada plataforma tem a sua interface. A documentação do Kotlin Multiplatform contempla expressamente esta combinação. (kmp.jetbrains.com)
Imagine uma app para equipas que inspecionam imóveis. Os critérios de avaliação podem ser iguais nos dois sistemas, mas a empresa pode querer desenhar separadamente a navegação e a interação com cada dispositivo. Neste exemplo hipotético, faz sentido pedir que essa alternativa seja estudada.
Na reunião com um fornecedor, pergunte: «Que partes propõem partilhar e que partes ficam separadas?» É uma pergunta mais útil do que pedir uma defesa abstrata de uma tecnologia.
A função mais difícil deve orientar a escolha
Considere uma app para técnicos que fazem manutenção de equipamentos. O percurso previsto é consultar uma intervenção, preencher uma ficha, juntar fotografias e entregar o relatório.
Agora acrescente um requisito: a app tem de comunicar com um instrumento de medição fornecido por um fabricante. Antes de discutir os restantes ecrãs, peça à equipa que investigue essa ligação.
Que software disponibiliza o fabricante? Existe suporte para os sistemas pretendidos? A solução escolhida consegue utilizá-lo? Quem fica responsável se for preciso desenvolver uma ligação própria?
O Flutter permite chamar código específico de Android e iOS através de mecanismos de comunicação com a plataforma. Portanto, uma integração sem suporte direto numa biblioteca não é necessariamente impossível. Pode, porém, exigir implementação própria em cada sistema. (docs.flutter.dev)
A nossa recomendação é classificar cada requisito indispensável numa destas categorias:
- Demonstrado: a equipa já o executou na combinação de tecnologia e dispositivos proposta.
- Documentado, mas por validar: existe suporte descrito, falta testar o percurso concreto.
- Dependente de desenvolvimento próprio: a proposta deve explicar o trabalho específico necessário.
- Sem solução confirmada: não deve ser tratado como uma funcionalidade garantida.
Não use o número de requisitos em cada categoria como votação. Uma única função sem solução pode justificar suspender a escolha, se a app não tiver utilidade sem ela.
Matriz para escolher a abordagem a estudar
Use esta matriz como orientação para a conversa técnica, não como um resultado automático. As recomendações são critérios editoriais assentes na possibilidade de partilhar lógica, interface ou apenas partes da aplicação. (docs.flutter.dev)
| Situação do projeto | Abordagem a estudar primeiro | Evidência a pedir |
|---|---|---|
| Os utilizadores fazem as mesmas tarefas nos dois sistemas e pretende-se uma interface semelhante | Multiplataforma com interface partilhada | Um percurso completo a funcionar em iPhone e Android |
| As regras são comuns, mas a experiência deve ser desenhada separadamente para cada sistema | Lógica partilhada com interfaces específicas | Separação clara entre núcleo comum e trabalho de interface |
| Uma integração específica determina o valor da app | Nativa ou multiplataforma com módulo específico, após validação | A integração real a funcionar, não apenas ecrãs de demonstração |
| As versões terão funções e prioridades bastante diferentes | Desenvolvimento separado ou partilha limitada | Plano de evolução independente para cada versão |
| Já existe uma app funcional numa das plataformas | Avaliar preservação e integração antes de propor reescrita | Identificação do que pode ser mantido e do que exige substituição |
Depois de preencher a matriz, escreva uma frase: «Vamos estudar esta abordagem porque…». Se a justificação se resumir a «é a que o fornecedor usa», ainda falta fundamentação.
Peça também a alternativa rejeitada e a razão da rejeição. Não precisa de um relatório académico: precisa de perceber que compromisso está a aceitar.
Troque a promessa de desempenho por um ensaio
«A app tem de ser rápida» não chega como critério de aceitação. Prefira descrever tarefas e condições observáveis.
No exemplo da inspeção, você pode exigir que o técnico consiga abrir uma ficha extensa, consultar fotografias e continuar a preencher campos sem interrupções que prejudiquem o trabalho. A equipa deve propor como medir esse comportamento e em que dispositivos.
A documentação de testes do Flutter distingue testes de funções isoladas, de componentes e de percursos integrados. Também explica que certas interações com elementos nativos exigem ferramentas ou abordagens adicionais. Uma demonstração de ecrãs não substitui, por isso, um ensaio do percurso real. (docs.flutter.dev)
Antes do desenvolvimento completo, proponha uma prova técnica com este guião:
1. Escolha a tarefa de maior risco. Pode ser a ligação ao instrumento de medição, em vez do início de sessão.
2. Fixe as condições. Indique dispositivos, dimensão dos dados e disponibilidade de rede relevantes para o uso previsto.
3. Defina o resultado aceitável. Escreva o que deve acontecer e o que seria uma falha impeditiva.
4. Execute nos dois sistemas. Peça registos dos resultados e das limitações encontradas.
5. Decida o passo seguinte. Avançar, alterar a abordagem ou retirar o requisito são resultados possíveis.
Trate esta prova como uma entrega contratada, com âmbito e conclusão próprios. Não peça o produto inteiro disfarçado de teste gratuito. O objetivo é comprar informação suficiente para evitar uma decisão às cegas.
Interface igual não significa utilização igual
Partilhar ecrãs não dispensa verificar a experiência em cada plataforma. Por exemplo, o React Native disponibiliza mecanismos para distinguir comportamentos e ficheiros por sistema operativo, precisamente para acomodar diferenças. (reactnative.dev)
Na avaliação do protótipo, não olhe apenas para as cores e para a posição dos botões. Peça para executar a tarefa com o teclado aberto, regressar ao ecrã anterior e recuperar de uma mensagem de erro.
Inclua acessibilidade nessa validação. A documentação do Flutter recomenda testes com os leitores de ecrã TalkBack e VoiceOver e atenção a aspetos como contraste, identificação dos controlos e utilização com texto ampliado. Estas verificações continuam a ser trabalho do projeto, mesmo quando a ferramenta disponibiliza suporte. (docs.flutter.dev)
Para uma ficha de inspeção, um teste útil seria aumentar o tamanho do texto e confirmar que o técnico consegue identificar o equipamento, preencher os campos e guardar. Depois, verificar se os controlos fazem sentido com leitura por voz.
Não aceite «a tecnologia suporta acessibilidade» como equivalente a «este percurso foi testado».
Quem resolve os problemas que ficam fora do código comum?
Antes de escolher, peça à equipa que explique como trata as exceções à partilha. Flutter e React Native admitem código específico de plataforma; logo, a proposta deve identificar quem assume esse trabalho quando ele é necessário. (docs.flutter.dev)
Recomendamos esclarecer por escrito:
- Quem investiga um problema que só aparece no iPhone ou só no Android?
- Quem mantém os módulos específicos desenvolvidos para o projeto?
- Como se decide entre atualizar uma biblioteca externa, substituí-la ou criar uma alternativa?
- Que testes devem voltar a ser executados quando se altera uma parte comum?
- Que documentação permitirá a outra equipa compreender estas decisões?
Se escolher desenvolvimento separado, faça a pergunta inversa: como será confirmado que a mesma regra de negócio produz o resultado pretendido nas duas versões?
O objetivo não é eliminar todas as dependências. É saber onde estão e quem responde por elas.
A decisão deve caber numa página
Antes de adjudicar, peça um registo curto da decisão técnica. Deve conter a abordagem escolhida, os motivos, as partes partilhadas, as exceções e o resultado da prova técnica. Acrescente as limitações aceites e as circunstâncias que obrigariam a rever a escolha.
Por exemplo: «Vamos partilhar interface e regras, mantendo um módulo específico para comunicar com o instrumento. A ligação foi validada nos dispositivos definidos. Novos modelos de instrumento exigirão nova avaliação.» É uma decisão concreta, embora este exemplo seja apenas ilustrativo.
Se ninguém consegue explicar a opção sem recorrer a promessas de rapidez, poupança ou superioridade, não feche ainda a tecnologia. Contrate primeiro a validação do requisito que pode inviabilizar o produto.
A melhor próxima ação é simples: leve à reunião a tarefa mais exigente da sua futura app e peça que a equipa mostre como a vai resolver em iPhone e Android. Escolha depois de ver a evidência.