Em Flutter, “white-label” não é um recurso do framework. O termo descreve, na prática, duas formas de entregar o mesmo código a várias marcas: gerar um app separado para cada marca, ou manter um único app instalado que muda sua aparência e configuração conforme o cliente ou o tenant. A escolha depende de uma pergunta central: cada marca precisa de uma identidade instalada própria, com nome, ícone e identificador próprios na loja, ou basta que o app se adapte depois de aberto?
Antes de escolher: o que muda entre as marcas
A distinção entre as duas filosofias começa pelo que o usuário vê depois de instalar. Se cada cliente aparece na loja como um app distinto, com seu próprio nome e identificador, o caminho é gerar builds separados. Se todos os clientes usam o mesmo app e só entram em suas contas, o caminho é a configuração em tempo de execução. As duas abordagens podem coexistir, e a maioria dos projetos reais combina pelo menos uma técnica de cada lado.
As an Amazon Associate I earn from qualifying purchases.
Também é preciso deixar claro o que a documentação oficial do Flutter cobre. As páginas de flavors, temas e arquitetura descrevem peças desse desenho, mas não prescrevem uma receita de white-label. A organização em “duas filosofias e três técnicas” usada aqui é um critério editorial para facilitar a leitura, não uma taxonomia oficial do Flutter.
Recommended Free Tools
As duas filosofias
Filosofia 1: um build separado por marca
Nesse modelo, um mesmo código-base gera variantes configuradas de forma independente. Cada variante pode ter seus próprios valores para nome do app, ícone, endpoint de API e assets. Segundo a documentação oficial de flavors para Android, esses valores são associados a cada variante de build. Para iOS e macOS, o guia oficial trabalha com esquemas do Xcode e permite nomes de exibição, ícones, identificadores de bundle e assets distintos.
#1 Best Overall
O ganho é uma fronteira clara entre marcas empacotadas: cada uma tem sua própria identidade instalada. O custo está na gestão de builds e de releases. Cada marca adicional pode exigir configuração e tratamento de publicação próprios, multiplicando o trabalho conforme cresce o número de marcas, ambientes e plataformas. Trata-se de uma consideração de engenharia, não de uma medição de custo.
Filosofia 2: um app compartilhado para várias marcas
Nesse modelo, existe um único app instalado, e a marca é escolhida para a conta ou o tenant ativo. O Flutter oferece temas em nível de aplicação, com possibilidade de sobrescritas locais, como mostra o guia de temas da documentação oficial. Esse recurso cuida da parte visual, mas não resolve sozinho o restante.
Seleção de tenant em runtime, isolamento de dados entre clientes e controle de autorização são decisões de arquitetura da aplicação. A documentação do Flutter não prescreve como implementá-las. Um tema bem configurado deixa a interface com cara de outra marca; ele não torna o app seguro para múltiplos clientes. Esse modelo faz mais sentido quando a identidade de cada cliente pode ser exibida dentro do app e o produto não exige um app instalado e publicado por cliente. Essa é uma decisão de produto, não uma limitação do framework.
| Critério | Builds separados por marca | Um app com seleção em runtime |
|---|---|---|
| Identidade na loja | Cada marca pode ter nome, ícone e identificador próprios | Um único app publicado; a marca aparece dentro dele |
| Momento da escolha da marca | Tempo de build ou de release | Tempo de execução, conforme a conta ou o tenant |
| Ferramentas oficiais principais | Flavors (Android), esquemas do Xcode (iOS/macOS), flavors em Windows e Linux | Temas e configuração de aplicação; a arquitetura é responsabilidade do projeto |
| Principal custo de manutenção | Configuração e publicação de cada variante | Isolamento de dados, autorização e condicionais por marca no código |
| Quando costuma servir | Marcas que precisam de identidade própria instalada | Marcas que podem viver dentro de um mesmo app |
As três técnicas
As três técnicas abaixo são uma forma de organizar as opções. Elas não se excluem: um projeto pode usar flavors para ambientes e configuração em runtime para as marcas dentro de cada ambiente.
1. Flavors e variantes de plataforma
Flavors usam a configuração de build de cada plataforma para definir nome, ícone, endpoint, assets e, no caso das plataformas móveis, o identificador do app. A documentação oficial é específica para cada plataforma:
- Android: product flavors, descritas em Set up Flutter flavors for Android.
- iOS e macOS: esquemas do Xcode, com nomes de exibição, ícones, identificadores de bundle e assets, descritos em Set up Flutter flavors for iOS and macOS.
- Windows e Linux: as páginas oficiais Set up Flutter flavors for Windows e Set up Flutter flavors for Linux indicam suporte nativo a flavors a partir do Flutter 3.47.
Como ponto de partida, o índice de implantação da documentação está em Deployment. A ordem de trabalho recomendada é:
- Confirme a versão do SDK com
flutter --version. Para Windows e Linux, a versão precisa ser 3.47 ou superior, segundo as páginas oficiais citadas. - Siga o guia da plataforma em que você vai publicar. Não copie passos de bundle ou de esquema de uma plataforma para outra.
- Defina uma variante por marca e, se necessário, uma por ambiente, e confira se cada uma gera um artefato com a identidade esperada.
- Teste a instalação de cada variante lado a lado, para garantir que os identificadores não colidem.
2. Configuração em runtime e temas
Nesta técnica, os valores de marca ficam em um modelo de configuração escolhido pela conta ou pelo tenant. Os valores visuais alimentam o tema do Flutter, e os recursos de cada marca são carregados a partir desse modelo. O guia oficial de temas mostra como compartilhar cores e estilos de texto com ThemeData e como fazer sobrescritas locais. Ele não define uma arquitetura de configuração por tenant; o exemplo abaixo é um padrão ilustrativo, não uma recomendação oficial do framework.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →class BrandConfig {
final String name;
final String logoAsset;
final Color primary;
const BrandConfig({
required this.name,
required this.logoAsset,
required this.primary,
});
}
ThemeData themeFor(BrandConfig brand) {
return ThemeData(
colorScheme: ColorScheme.fromSeed(seedColor: brand.primary),
);
}Com esse padrão, a troca de marca vira uma troca de objeto de configuração, sem bifurcar telas. O limite é que nada disso protege dados. Endpoints por cliente, permissões e dados isolados precisam de regras próprias na aplicação e no servidor.
3. Núcleo compartilhado com cascas por marca
Aqui o código reutilizável, com domínio e features, fica separado dos pontos de entrada e dos ativos de cada marca. Pode ser um único repositório com pastas bem delimitadas ou um conjunto de pacotes. Cada marca ganha uma casca fina: um ponto de entrada próprio que injeta a configuração e os assets correspondentes no núcleo.
Rank #4
A documentação de arquitetura do Flutter, em Architecting Flutter apps, defende estrutura intencional pela manutenibilidade. Como se lê no próprio guia: “Good app architecture provides a number of benefits to engineering teams and their end users.” A página não prescreve o padrão de cascas por marca; ele é uma forma de aplicar essa orientação ao caso de white-label.
O risco típico dessa técnica é o acúmulo de condicionais do tipo “se a marca for X” espalhadas pelas telas. Ele cresce com o tempo. Manter o núcleo livre de nomes de marca, e concentrar as diferenças na configuração e nas cascas, reduz esse problema.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Como decidir
Avalie as opções com estas perguntas:
- Cada cliente precisa de um app instalado e publicado com identificador próprio?
- As diferenças são apenas visuais, ou também variam fluxos, funcionalidades, endpoints e integrações?
- A marca precisa ser fixada no build, ou pode mudar por conta em tempo de execução?
- Quantas combinações de marca, ambiente e plataforma o time precisa lançar e manter?
- Quais assets e configurações ficam empacotados no artefato, e como os ambientes são separados?
- O comportamento do produto pode continuar compartilhado sem que condicionais por marca se espalhem pelas telas?
Essas perguntas são uma síntese editorial. A documentação do Flutter não oferece uma matriz formal de pontuação para esse tipo de decisão.
Best Value
Sobre o pacote multi_app_flavor
O pacote multi_app_flavor, publicado no pub.dev, descreve suporte a configuração, temas e assets específicos por tenant. Ele pode servir como ponto de comparação ao avaliar a abordagem. A página do pacote, porém, não comprova manutenção, segurança ou compatibilidade com a sua versão do Flutter. Antes de adotá-lo, verifique a data da última publicação, as versões suportadas, as issues abertas e a cobertura de testes no próprio pub.dev.
The Bottom Line
Se cada marca precisa aparecer na loja como um app próprio, comece por flavors nas plataformas em que você publica. Se as marcas podem conviver em um único app instalado, use configuração em runtime com temas e trate o isolamento de dados e a autorização como problemas de arquitetura desde o início. Na maioria dos casos reais, a combinação das duas filosofias é o desenho mais provável.
Quick Recap
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.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →
