What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Para criar um app white-label em Flutter, primeiro decida se cada marca terá um aplicativo instalado separadamente ou se um único app atenderá várias marcas em tempo de execução. Depois escolha como organizar a implementação: flavors de plataforma, configuração e temas selecionados pelo app, ou um núcleo compartilhado com shells e configurações específicos por marca. Esses modelos podem ser combinados, mas flavors escolhem valores na compilação; seleção de tenant acontece dentro do app em execução.

As duas filosofias: apps separados ou um app multi-tenant

Builds separados para cada marca

Neste modelo, uma base de código gera variantes configuradas para cada marca. Cada variante pode ter nome, ícone, recursos e identidade de instalação próprios, além de configurações como endpoint de API. É a opção natural quando o cliente precisa de um app separado, por exemplo com uma identidade distinta na loja ou um identificador de pacote próprio.

No Android, a documentação do Flutter descreve product flavors e valores específicos por variante, incluindo nome, ícone, endpoint e assets: configurar flavors para Android. Para iOS e macOS, o processo usa schemes do Xcode e pode variar nome de exibição, ícones, bundle identifiers e assets: configurar flavors para iOS e macOS.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

A fronteira entre marcas fica explícita no que é empacotado, mas cada combinação adicional de marca, ambiente e plataforma traz configurações e etapas de release a manter. Isso é um custo de engenharia a considerar, não um número fixo: depende do processo e das diferenças entre os apps.

Um app compartilhado para várias marcas

Nesta filosofia, existe uma instalação e a marca ou configuração ativa é escolhida dentro do app, por exemplo após a seleção de uma conta ou tenant. Ela pode controlar tema, textos e assets e, conforme a arquitetura do produto, outros comportamentos. Faz sentido quando a marca é uma escolha em tempo de execução e não é necessário publicar uma identidade de app separada para cada cliente. Essa é uma decisão de produto, não uma limitação do Flutter.

O tema do Flutter permite compartilhar estilos em toda a aplicação e aplicar overrides locais: Use temas para compartilhar cores e estilos de fonte. Mas tema é um mecanismo de interface, não uma arquitetura multi-tenant completa. Isolamento de dados, autenticação, autorização e seleção segura da configuração precisam ser resolvidos pela arquitetura da aplicação; as orientações de tema não prescrevem essas partes.

Três técnicas para implementar a estratégia

1. Flavors e variantes de plataforma

Use configurações de build para selecionar valores empacotados, como identidade, assets e endpoints. A configuração é escolhida antes da distribuição, não alternada livremente por conta durante a execução. As etapas são específicas de cada plataforma: consulte o índice de deployment do Flutter e siga o guia correspondente, em vez de transportar configurações de bundle ou scheme de uma plataforma para outra.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Para Windows e Linux, os guias oficiais indicam suporte integrado a flavors a partir do Flutter 3.47. Confira a versão instalada do SDK antes de aplicar essas instruções: flavors para Windows e flavors para Linux.

2. Configuração em tempo de execução e temas

Modele os valores de marca em uma configuração selecionada pelo app — por exemplo, com base no tenant ativo — e use esses valores para fornecer tema, assets e outras opções de interface. Isso é um padrão de implementação recomendado, não uma arquitetura definida pela documentação do Flutter. Mantenha a seleção de tenant e as regras de acesso separadas da camada visual, para que trocar cores ou logotipo não seja confundido com conceder acesso a dados.

3. Núcleo compartilhado com shells ou configurações por marca

Separe funcionalidades e regras de domínio reutilizáveis dos pontos de entrada, assets e configurações pertencentes a cada marca. Essa divisão pode existir em um único repositório ou em pacotes distintos. A orientação de arquitetura do Flutter destaca a importância de uma estrutura que favoreça manutenção conforme o app e a equipe crescem, mas não determina um padrão white-label específico: Architecting Flutter apps.

Como escolher o modelo certo

Use estas perguntas como critérios de decisão; não há uma pontuação oficial do Flutter para white-label.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  • Identidade de distribuição: cada cliente precisa de app próprio na loja ou de bundle/application identifier distinto? Se sim, builds separados tendem a se encaixar melhor.
  • Momento da escolha: a marca deve ser definida ao compilar e publicar, ou usuários de uma mesma instalação podem alterná-la em execução?
  • Escopo das diferenças: as variações são sobretudo visuais ou também envolvem fluxos, funcionalidades, endpoints e integrações?
  • Combinações a manter: quantas marcas, ambientes e plataformas precisam ser compilados, testados e lançados?
  • Limites de configuração: quais valores e assets serão empacotados, e como os ambientes serão separados? Não trate valores incluídos no app como segredo apenas por estarem em uma variante.
  • Manutenção do código: as regras podem permanecer compartilhadas sem espalhar condicionais específicas de marca por telas e funcionalidades?
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Combinar técnicas sem confundir seus papéis

Flavors e seleção em tempo de execução resolvem momentos diferentes. Um flavor pode separar desenvolvimento, staging e produção, enquanto o app escolhe a identidade do tenant durante a execução em cada ambiente. Também é possível usar flavors para gerar apps de marcas distintas e manter funcionalidades compartilhadas em um núcleo comum.

A decisão essencial é identificar o que precisa ser diferente no artefato distribuído e o que precisa variar durante uma sessão. Para opções de build, siga o guia da plataforma; para estilos, use temas; para limites entre funcionalidades e marcas, organize a arquitetura conforme as necessidades de manutenção.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.