PRODUTIVIDADE E ORGANIZAÇÃO ARQUITETURAL NO DESENVOLVIMENTO CROSS-PLATFORM COM FLUTTER: UM ESTUDO DE CASO

Engenharias, Volume 29 - Edição 152/NOV 2025 / 19/11/2025

PRODUCTIVITY AND SOFTWARE ARCHITECTURE ORGANIZATION IN CROSS-PLATFORM DEVELOPMENT USING FLUTTER: A CASE STUDY

REGISTRO DOI: 10.69849/revistaft/pa10202511152349

Abraão Brito Brandão1
Luis Cuevas Rodríguez2

Resumo

O desenvolvimento de aplicativos móveis multiplataforma tem se consolidado como alternativa para reduzir custos e retrabalho na criação de versões distintas para Android e iOS. Nesse contexto, o Flutter apresenta-se como uma solução que combina desempenho, expressividade visual e produtividade, a partir de um modelo declarativo baseado em widgets e de um motor de renderização próprio. Este trabalho descreve um estudo de caso fundamentado na implementação de um aplicativo de calculadora, desenvolvido com o objetivo de analisar a organização da arquitetura, a separação entre lógica e interface e o impacto do framework na experiência de desenvolvimento. Após a conclusão do protótipo, o aplicativo e seu código foram avaliados por onze desenvolvedores com experiência prévia, por meio de um instrumento misto composto por questões fechadas e descritivas. Os resultados indicaram melhora considerável na produtividade e na clareza estrutural, especialmente devido ao recurso de hot reload e à modularidade dos widgets. No entanto, observou-se que a escalabilidade da aplicação depende de escolhas adequadas de gerenciamento de estado em projetos de maior complexidade. Conclui-se que o Flutter se mostra adequado para prototipação e aplicações de pequena a média escala, ao mesmo tempo em que demanda planejamento arquitetural para evoluções futuras.

Palavras-chave: Flutter. Desenvolvimento móvel. Cross-platform. Arquitetura de software. Widgets.

1 INTRODUÇÃO

O desenvolvimento de aplicativos móveis consolidou-se como uma área estratégica para empresas e serviços, uma vez que o uso cotidiano de smartphones moldou novas expectativas em relação à experiência digital. Porém, criar e manter versões distintas de um mesmo aplicativo para Android e iOS ainda representa um desafio significativo para equipes de desenvolvimento, sobretudo quando se busca consistência visual, atualização contínua e controle de custos. A literatura aponta que essa duplicação de esforço pode ampliar o tempo de entrega e tornar a manutenção mais sujeita a falhas ou divergências entre plataformas (Mohammed, 2022)

Nesse cenário, soluções cross-platform surgiram como alternativa para reduzir retrabalho, permitindo que uma única base de código seja compilada para diferentes sistemas operacionais. Entre essas soluções, o Flutter, desenvolvido pelo Google, destaca-se por utilizar a linguagem Dart e um motor de renderização próprio, o que dispensa camadas intermediárias e favorece desempenho próximo ao nativo (Dagne, 2025). Além disso, o framework organiza a construção de interfaces por meio de widgets, um modelo declarativo que simplifica a estruturação visual e facilita ajustes incrementais durante o desenvolvimento (Uplenchwar et al., 2022)

Observa-se, também, que o Flutter foi projetado para oferecer uma experiência de desenvolvimento ágil. O recurso de hot reload, por exemplo, permite visualizar alterações imediatamente, sem a recompilação completa da aplicação. Essa característica costuma impactar diretamente a percepção de produtividade do desenvolvedor e pode gerar ciclos de prototipação mais curtos, especialmente em projetos exploratórios ou educacionais. Estudos comparativos indicam que essa agilidade, aliada à padronização visual, tem sido um dos principais motivos para a adoção do Flutter por empresas e equipes independentes (Väänänen, 2025; Riaz, 2025)

Apesar dessas vantagens, não se trata de uma solução isenta de desafios. A gestão de estado em aplicações mais complexas exige escolhas arquiteturais criteriosas; o tamanho inicial dos binários pode ser maior em comparação com alternativas nativas; e nem todas as integrações dependentes de recursos específicos do dispositivo são triviais (Jain, 2025). Por isso, compreender a experiência prática e os impactos reais do uso do Flutter é relevante não apenas sob perspectiva técnica, mas também para orientar sua adoção em contextos educacionais, profissionais e experimentais.

Este trabalho apresenta um relato de experiência fundamentado no desenvolvimento de um aplicativo de calculadora construído integralmente com Flutter. Descrevemos a organização da aplicação, as decisões de projeto, o fluxo de interação entre interface e estado, além de percepções relacionadas à produtividade e clareza estrutural durante o processo. O objetivo é avaliar criticamente o uso do Flutter no desenvolvimento cross-platform, destacando contribuições, limitações e possíveis implicações para a prática.

2 FUNDAMENTAÇÃO TEÓRICA OU REVISÃO DA LITERATURA

2.1 Desenvolvimento Cross-Platform

A necessidade de criar aplicações capazes de funcionar de maneira consistente em múltiplas plataformas levou ao surgimento de abordagens de desenvolvimento cross-platform, nas quais um único código-fonte pode ser reutilizado para Android, iOS e, em alguns casos, para web e desktop. Essa estratégia surge como alternativa ao desenvolvimento nativo, que implica a manutenção de duas bases de código distintas e, muitas vezes, duas equipes especializadas, o que aumenta custos e tempo de manutenção (Mohammed, 2022)

A literatura aponta que a adoção de ferramentas multiplataforma pode reduzir o retrabalho e simplificar fluxos de atualização, desde que o framework escolhido seja capaz de reduzir perdas de desempenho e garantir consistência visual (Uplenchwar et al., 2022). Porém, esse equilíbrio nem sempre é trivial. Se, por um lado, frameworks cross-platform ampliam alcance e diminuem custos, por outro, podem enfrentar limitações ligadas à integração com APIs específicas do dispositivo e à manutenção de experiência de usuário similar ao nativo.

Esse panorama cria um espaço no qual soluções como o Flutter se destacam justamente por propor um modelo diferente de renderização e construção de interface — tema que será explorado a seguir.

2.2  Arquitetura e Fundamentos do Flutter

O Flutter foi desenvolvido pelo Google com o objetivo de oferecer uma experiência multiplataforma que não dependesse de componentes nativos para a interface. Para isso, ele utiliza um motor de renderização próprio, baseado no Skia, que permite desenhar os elementos diretamente na tela, sem intermediários. Essa abordagem reduz latência visual e ajuda a manter desempenho consistente entre diferentes dispositivos (Dagne, 2025). O framework emprega a linguagem Dart, que combina dois modos de compilação: JIT (Just-in- Time) durante o desenvolvimento acelerando testes e experimentação e AOT (Ahead- of-Time) para empacotamento final, resultando em aplicações executáveis com desempenho mais próximo ao nativo (Väänänen, 2025). Essa característica técnica está diretamente relacionada à fluidez da interface, algo frequentemente percebido pelo usuário final mesmo em dispositivos intermediários.

A construção das interfaces ocorre por meio de widgets, elementos reutilizáveis que representam tanto componentes visuais (botões, texto, containers) quanto estruturas maiores (páginas inteiras). Esse modelo declarativo favorece a legibilidade e permite que alterações no estado da aplicação resultem automaticamente na atualização da interface, sem a necessidade de manipulação direta da árvore visual.

De forma geral, essa arquitetura busca equilibrar desempenho, expressividade visual e produtividade do desenvolvedor, características frequentemente citadas como motivadoras da adoção do Flutter em projetos reais (Riaz, 2025)

2.3 Produtividade e Experiência de Desenvolvimento com Flutter

Uma das principais características que tem atraído desenvolvedores ao Flutter é a sensação de agilidade no ciclo de desenvolvimento. Durante a construção de interfaces, pequenas alterações visuais ou comportamentais podem ser observadas quase imediatamente graças ao recurso de hot reload, que atualiza a interface sem recompilar todo o projeto. Esse mecanismo reduz a espera entre tentativa e verificação, permitindo ajustar detalhes finos de design ou lógica sem interrupções longas. Em práticas de prototipação, essa característica tende a favorecer a exploração criativa e a revisão colaborativa do layout.

Além disso, o modelo baseado em widgets proporciona uma forma natural de organização da interface. Cada componente visual é tratado como uma entidade independente, o que permite que um desenvolvedor dívida a aplicação em pequenas partes reutilizáveis e substituíveis. Essa abordagem não apenas facilita a manutenção, como também torna mais claro o relacionamento entre os elementos da interface e o estado que os sustenta. Nos relatos analisados, essa clareza tem sido apontada como um fator que reduz o retrabalho e facilita revisões de código, principalmente em equipes iniciantes ou em ambientes educacionais (Väänänen, 2025; Riaz, 2025)

Há também um aspecto de integração à rotina de trabalho que merece destaque. Como o Flutter apresenta um conjunto rico de widgets nativos e estilizados, a construção de interfaces visualmente consistentes não necessita de extensas bibliotecas externas. Isso reduz dependências e diminui o tempo gasto em configurações adicionais um fator que pode impactar diretamente a produtividade em projetos curtos ou em equipes reduzidas. Em resumo, o framework oferece um ambiente de desenvolvimento que tende a favorecer um ritmo contínuo, fluido e iterativo.

2.4  Desafios e Limitações na Adoção do Flutter

Embora apresente vantagens expressivas, a adoção do Flutter não ocorre sem desafios. Um dos aspectos frequentemente mencionados na literatura refere-se ao tamanho inicial dos arquivos gerados. Aplicativos simples desenvolvidos com o framework tendem a possuir pacotes mais pesados quando comparados às versões equivalentes produzidas de forma nativa. Esse comportamento é resultado direto da inclusão do motor de renderização dentro do próprio aplicativo, o que garante independência da plataforma, mas amplia o espaço ocupado (Dagne, 2025)

Outro ponto importante diz respeito ao gerenciamento de estado. Ao mesmo tempo em que o modelo declarativo facilita a atualização da interface, ele exige que o desenvolvedor defina claramente como o estado será armazenado, compartilhado e atualizado ao longo da aplicação. Existem diversas abordagens possíveis como Provider, Bloc, Riverpod e Redux e a escolha inadequada pode gerar complexidade desnecessária ou dificultar a escalabilidade. Esse aspecto, portanto, demanda atenção na definição de arquitetura antes mesmo da implementação de funcionalidades mais avançadas (Jain, 2025)

Por fim, algumas funcionalidades que dependem de recursos específicos do dispositivo, como sensores, serviços em segundo plano ou APIs proprietárias, ainda podem exigir o uso de código nativo em Java/Kotlin ou Swift/Objective-C. Embora o Flutter ofereça canais de comunicação para esses casos, esse processo nem sempre é imediato para iniciantes, especialmente quando envolve documentação fragmentada ou diferenças entre versões do sistema operacional.

Em conjunto, esses fatores mostram que o Flutter oferece ganhos expressivos, mas requer planejamento arquitetural e familiaridade progressiva, especialmente em projetos que envolvem integração com hardware ou recursos avançados.

3 METODOLOGIA

A metodologia adotada neste trabalho combina relato de experiência e estudo de caso aplicado, permitindo observar, de forma estruturada, tanto o processo de desenvolvimento quanto a percepção prática do uso do Flutter. Esse formato foi escolhido para descrever não apenas o resultado final, mas também as decisões, ajustes e aprendizados que emergiram ao longo do desenvolvimento da aplicação.

3.1  Ambiente de Desenvolvimento.

A aplicação foi desenvolvida utilizando o Flutter SDK, com suporte da linguagem Dart, em ambiente configurado sobre sistemas operacionais Windows e Linux. O código foi editado no Visual Studio Code, utilizando extensões oficiais do Flutter para suporte à análise estática, sugestões de autocompletar e ferramentas de debug. A execução e os testes foram realizados tanto em emulador Android quanto em dispositivo físico, permitindo observar diferenças de comportamento entre simulação e uso real.

Esse ambiente foi escolhido por refletir uma configuração amplamente acessível, frequentemente encontrada em contextos acadêmicos e de desenvolvimento independente. Além disso, a possibilidade de alternar entre emulador e dispositivo físico contribuiu para observar efeitos visuais, performance e responsividade em tempo real.

3.2  Descrição Geral do Aplicativo (Estudo de Caso)

O estudo de caso consiste no desenvolvimento de um aplicativo de calculadora, que realiza operações aritméticas básicas com uma interface composta por um visor numérico e um conjunto de botões organizados em linhas. Embora simples em termos funcionais, esse tipo de aplicação permite observar aspectos centrais da arquitetura do Flutter e mostra como é feita a organização de widgets, gerenciamento de estado, responsividade da interface e transição entre entradas do usuário.

A interface é composta por um visor numérico e um conjunto de botões organizados em grupos, seguindo um estilo visual inspirado na calculadora do iOS, priorizando simplicidade, contraste e legibilidade. Esse arranjo permitiu identificar de forma clara a relação entre camada de apresentação e módulo lógico.

A estrutura do projeto foi organizada de modo que a lógica de cálculo permanecesse separada da interface. Essa separação facilita a leitura e favorece futuras extensões da aplicação, como histórico de operações ou operações científicas, sem alterar os componentes da interface já estabelecidos. A relação entre usuário, aplicação e plataforma pode ser visualizada no diagrama de contexto apresentado na Figura 1, que situa o aplicativo como intermediário entre o usuário e o sistema operacional do dispositivo.

Figura 1: Diagrama de contexto do aplicativo calculadora. Fonte: autoria própria.

Ainda o aplicativo de estudo seja simples do ponto de vista funcional, o aplicativo foi planejado para oferecer uma base extensível, permitindo inclusive futuros acréscimos, como histórico de operações ou funções científicas. Assim, o foco não esteve na variedade de operações, mas na qualidade estrutural da implementação.

Etapas do Processo de Desenvolvimento

O desenvolvimento seguiu um processo incremental, iniciando-se pela definição da interface básica e progredindo para a separação da lógica de cálculo em um módulo independente. Um ponto central consistiu na distinção entre widgets de interface (responsáveis pela apresentação visual) e a classe de estado (responsável pela memória da operação e pelo resultado exibido). O processo utilizado foi o seguinte:

  1. Definição da interface inicial: composição da tela principal, contendo visor e teclado numérico.
  2. Determinação das responsabilidades de cada widget: identificação de quais elementos seriam estáticos e quais sofreriam atualização conforme o estado.
  3. Implementação da lógica de cálculo em módulo separado: criação de uma classe responsável por interpretar entradas e armazenar resultados.
  4. Integração entre interface e estado: estabelecimento das chamadas e retornos que atualizam o visor conforme as ações do usuário.
  5. Ajustes de layout e responsividade: adaptações para garantir consistência visual em diferentes tamanhos de tela.
  6. Refinamento e documentação do processo: análise da experiência e registro das percepções observadas.

    Esse fluxo não seguiu um modelo rígido de engenharia, mas um ciclo contínuo de teste e ajuste — aspecto que faz parte do próprio modo de desenvolvimento favorecido pelo Flutter.

    A organização interna dos widgets pode ser observada na Figura 2, que evidencia a composição hierárquica entre Display, Keyboard, ButtonRow e Button, bem como a conexão desses elementos com o modelo de memória.

    Figura 2: Organização dos principais widgets da interface. Fonte: autoria própria.

    Essa estrutura permitiu isolar responsabilidades: enquanto a interface exibe e recebe ações, a classe Memory processa entradas e fornece o estado atualizado ao visor, reforçando a separação entre camada de apresentação e lógica de operações.

    O fluxo de execução desde a inicialização do aplicativo até a atualização da interface pode ser observado no diagrama apresentado na Figura 3. Nele, vê-se a sequência: main.dart inicia a aplicação, carrega a tela da calculadora e estabelece vínculos entre interface, configurações estáticas e o módulo de cálculo.

    Figura 3: Fluxo geral de inicialização e atualização do aplicativo. Fonte: autoria própria

    Antes da apresentação dos resultados, é importante detalahr o ambiente de desenvolvimento utilizado, uma vez que o comportamento das aplicações desenvolvidas com Flutter pode variar de acordo com a versão do SDK, do sistema operacional ou do dispositivo de teste. A definição dessas condições é fundamental tanto para fins de reprodutibilidade quanto para uma análise comparativa com outros trabalhos ou implementações futuras. A Tabela 1 apresenta as versões das ferramentas, o hardware utilizado e o canal de distribuição adotado durante o processo de desenvolvimento do aplicativo.

    Tabela 1: Ambiente de desenvolvimento e execução da aplicação.

    Para garantir reprodutibilidade, todos os artefatos do estudo permanecem acessíveis publicamente:

    • Código-fonte (acesso público): https://github.com/abraaobb/calculator_app
    • Arquivo APK executável: disponível na seção Releases do repositório Procedimentos adotados para reprodutibilidade:
    • Registro das versões das ferramentas utilizadas (flutter doctor -v),
    • Documentação do comando de construção (flutter build apk –release),
    • Associação da versão analisada a um hash específico de commit,
    • Listagem das dependências utilizadas no arquivo pubspec.yaml.
    • Essas ações asseguram que terceiros possam executar, testar e validar o estudo.

    3.4 Procedimento de Avaliação do Aplicativo.

    Após a conclusão da implementação, o aplicativo e seu código-fonte foram disponibilizados para um grupo de desenvolvedores com experiência prévia em Flutter. Foi conduzida uma avaliação estruturada com o objetivo de identificar percepções relacionadas à organização do código, produtividade, modularidade e manutenção quando o Flutter é utilizado no desenvolvimento de interfaces. A avaliação foi realizada com 11 desenvolvedores, todos com mais de cinco anos de experiência em programação e, no mínimo, dois anos de formação profissional, assegurando que os participantes possuíam maturidade técnica para emitir julgamento fundamentado. Os participantes puderam executar o aplicativo e examinar a organização do código, incluindo a estrutura dos widgets, a separação entre interface e lógica e o gerenciamento de estado. Esse procedimento assegurou que as respostas ao instrumento de avaliação refletissem percepções fundamentadas tanto no uso do aplicativo quanto na interpretação da sua arquitetura interna, permitindo uma análise qualitativa consistente sobre clareza estrutural, modularidade e potencial de manutenção.

    A coleta foi realizada on-line, por meio de um formulário disponibilizado no Google Forms, composto por perguntas fechadas e abertas. O instrumento foi dividido em três partes:

    (i) perfil de experiência dos participantes;
    (ii) percepção sobre produtividade, organização e manutenção ao utilizar Flutter;
    (iii) comentários descritivos sobre experiências prévias com outras tecnologias de desenvolvimento móvel.

    As respostas das questões fechadas foram avaliadas por meio de uma escala ordinal de cinco pontos, variando de 0 a 4, onde 0 indica nenhuma mudança percebida, 1 corresponde a pequena melhora, 2 representa melhora moderada, 3 indica melhora considerável e 4 reflete melhora excepcional, com impacto percebido de forma clara na experiência de desenvolvimento. Essa escala foi utilizada para avaliar aspectos como:

    • necessidade de refatoração posterior,
    • facilidade de reorganização do código,
    • clareza arquitetural,
    • produtividade no desenvolvimento,
    • facilidade de aprendizado com apoio da documentação,
    • simplicidade no uso de widgets,
    • desempenho percebido do aplicativo,
    • esforço de manutenção quando comparado a outros frameworks.

      As respostas descritivas foram analisadas por meio de análise qualitativa temática, identificando padrões recorrentes de percepção e justificativas técnicas apresentadas pelos desenvolvedores. Esse procedimento possibilitou relacionar a experiência prática ao estudo de caso e também contrastar diferentes perspectivas entre participantes.

      A integração entre dados quantitativos (escala ordinal) e observações qualitativas permitiu estruturar os resultados discutidos na Seção 4, relacionando o comportamento observado no desenvolvimento do aplicativo às percepções experienciadas pelos participantes.

      4 RESULTADOS E DISCUSSÕES OU ANÁLISE DOS DADOS

      A implementação do aplicativo de calculadora permitiu observar, na prática, como o Flutter organiza a construção da interface, o gerenciamento de estado e a separação entre lógica e apresentação. A análise a seguir integra:

      (i) a organização arquitetural adotada no projeto,
      (ii) a avaliação de desenvolvedores com experiência prévia na tecnologia, e
      (iii) a reflexão crítica do pesquisador a partir do processo de implementação.

      4.1  Organização da Arquitetura e Estrutura do Projeto

      A arquitetura adotada no projeto seguiu uma organização orientada a componentes, na qual a interface e a lógica foram separadas de modo a favorecer clareza estrutural, manutenção e extensibilidade. A estrutura geral do projeto, disponível publicamente no repositório3, foi organizada em pastas conforme responsabilidades específicas, como apresentado a seguir:

      Essa estrutura reflete um princípio central adotado no desenvolvimento, cada unidade do código deve ter uma responsabilidade clara.

      • A pasta components/ concentra apenas elementos visuais reutilizáveis, alinhada ao estilo declarativo do Flutter.
      • A pasta models/ abriga a lógica de domínio, que no projeto corresponde ao módulo Memory, responsável por interpretar comandos, armazenar valores intermediários e aplicar operações aritméticas.
      • A pasta screens/ contém a composição da interface completa, onde widgets menores são combinados para formar a tela da calculadora.
      • A pasta config/ contém a lógica por trás da configuração das linhas e tamanho dos botões da calculadora.
      • O arquivo main.dart realiza a configuração da aplicação e a injeção do estado na interface inicial.

      Essa estrutura é coerente com recomendações adotadas na literatura sobre Flutter, que enfatizam separação entre UI reativa e estado encapsulado (Dagne, 2025; Väänänen, 2025). Em termos práticos, essa decisão evitou que a lógica de cálculo fosse acidentalmente distribuída entre widgets problema comum em projetos iniciantes.

      A classe Memory, localizada em models/memory.dart, concentra todo o processamento relacionado às operações aritméticas da calculadora. Sua implementação, disponível no repositório, foi estruturada de forma a manter o valor atualmente exibido, registrar um segundo valor quando operações sucessivas são realizadas e identificar qual operação está ativa no momento da interação do usuário. O cálculo é executado apenas quando necessário, evitando processamento redundante, e o resultado retornado já é formatado de modo adequado para exibição direta no Display. Essa estratégia possibilitou separar de maneira clara a lógica da aplicação da interface gráfica, garantindo que o arquivo calculator.dart atuasse apenas como mediador entre entrada do usuário e atualização do estado.

      Essa separação garantiu que a tela (calculator.dart) atuasse apenas como intermediária entre entrada do usuário e atualização da interface, acionando o método de atualização de estado via setState() apenas no ponto mais alto da árvore de widgets. Esse padrão minimizou reconstruções desnecessárias, contribuindo para estabilidade visual e desempenho fluido.

      Por sua vez, os componentes button.dart e button_row.dart seguiram uma abordagem de composição progressiva: um botão é definido isoladamente, uma linha é composta apenas de botões, e o teclado é composto de várias linhas. Esse encadeamento hierárquico resultou em uma interface mais declarativa, modular e fácil de manter.

      Essa arquitetura foi reconhecida pelos desenvolvedores que avaliaram o projeto, que atribuíram média ≈ 3.00 (melhora considerável) à afirmação “A arquitetura do Flutter contribui para um código mais organizado.” Essa convergência entre decisão de design e percepção prática fortalece a validade do estudo de caso como evidência aplicada, e não apenas teórica.

      4.2  Decisões de Design e Justificativas

      Durante o desenvolvimento do aplicativo, algumas decisões arquiteturais foram tomadas de forma consciente, buscando equilibrar clareza estrutural, simplicidade de manutenção e coerência no fluxo de atualização da interface. Essas decisões emergiram tanto

      da natureza declarativa do Flutter quanto da estratégia adotada para separar responsabilidades entre interface e lógica. Em particular, optou-se por manter toda a lógica de cálculo encapsulada na classe Memory, preservando a tela principal (calculator.dart) como responsável apenas por coordenar a interação entre os widgets e o estado.

      Essa separação implicou em um desenho no qual os componentes visuais não têm conhecimento direto das regras de operação, reduzindo a chance de acoplamento e facilitando modificações futuras. A própria composição hierárquica da interface, organizada de Button → ButtonRow → Keyboard → Calculator, reforça esse princípio de construção progressiva, no qual elementos pequenos, coesos e compreensíveis são combinados para formar estruturas visuais mais complexas.

      Além disso, decidiu-se não utilizar frameworks externos de gerenciamento de estado, como Riverpod ou Bloc, optando por operar o estado diretamente com setState() no nível superior da árvore. A escolha teve como objetivo manter o foco do estudo na compreensão da dinâmica de reconstrução da interface, característica central do modelo reativo do Flutter. Esse ponto foi destacado por alguns dos desenvolvedores que analisaram o projeto, os quais mencionaram que a clareza da reconstrução da tela tornou o comportamento do aplicativo previsível e fácil de seguir durante a leitura do código.

      Ao mesmo tempo, reconheceu-se que essa decisão é adequada para aplicações pequenas, mas pode exigir revisão em projetos de maior escala. A avaliação dos desenvolvedores refletiu esse entendimento, já que a afirmativa “A arquitetura do Flutter contribui para um código mais organizado” recebeu média aproximada de 3.00, indicando melhora considerável, embora não definitiva. Esse resultado sugere que a abordagem adotada foi eficiente para o contexto estudado, mas que a modularização e o gerenciamento de estado devem ser revistos conforme a complexidade da aplicação cresce. A Erro! Fonte de referência não encontrada. sintetiza as decisões principais e seus impactos percebidos.

      Tabela 2: Decisões de Design Principais e Efeitos Observados no Projeto

      4.3  Impacto na pratica

      A implementação do aplicativo permitiu observar, de maneira concreta, como os princípios declarativos do Flutter influenciam o fluxo de desenvolvimento. Um dos efeitos mais imediatos percebidos foi a redução no tempo de iteração entre escrita de código e visualização de mudanças, graças ao mecanismo de hot reload. Essa característica se mostrou especialmente relevante durante o refinamento da interface, permitindo experimentar disposições de botões, tamanhos e espaçamentos sem a necessidade de recompilações completas. Do ponto de vista arquitetural, a separação entre lógica e interface contribuiu para uma maior previsibilidade no comportamento do aplicativo. Alterações no módulo Memory repercutiam diretamente no resultado exibido, enquanto ajustes visuais podiam ser realizados exclusivamente em button.dart ou button_row.dart. Essa independência parcial de camadas conferiu clareza no fluxo de responsabilidades, facilitando tanto o raciocínio sobre o código quanto futuras modificações.

      A avaliação realizada com os onze desenvolvedores experientes corrobora essas observações. A afirmação “O Flutter melhora a produtividade no desenvolvimento” alcançou média aproximada de 3.45, refletindo uma percepção consistente de ganho de eficiência no ciclo de implementação–testes. Os participantes também destacaram que esse ganho está associado não apenas ao hot reload, mas também à estrutura de widgets reutilizáveis, que reduz retrabalho durante ajustes incrementais de layout.

      Por outro lado, a percepção de manutenção e refatoração apresentou resultados equilibrados, com médias próximas de 2.91. Esse dado indica que, embora a organização inicial da aplicação tenha favorecido clareza estrutural, a escalabilidade do padrão adotado depende de um planejamento explícito de gerenciamento de estado e modularização questões que se tornam mais presentes em projetos de maior porte. Esse aspecto foi observado por alguns participantes durante a análise do repositório, que apontaram que o uso de setState() é adequado para aplicações pequenas, mas que frameworks como Bloc ou Riverpod podem ser necessários em sistemas complexos.

      Por fim, a transferência de conhecimento entre tecnologias também teve impacto prático. Desenvolvedores com experiência prévia em frameworks baseados em componentes como React, Angular ou Jetpack Compose apresentaram maior fluidez na leitura da estrutura hierárquica do aplicativo, atribuindo média de 2.82 à afirmação “O contato com outras tecnologias diminui a curva de aprendizagem”. Esse resultado sugere que o Flutter se beneficia de competências prévias de arquitetura e composição visual, o que reforça seu potencial para formar pontes entre ecossistemas distintos de desenvolvimento.

      Em síntese, o impacto prático observado articula-se em dois eixos complementares:

      (i) ganho de produtividade e clareza estrutural durante a implementação, e
      (ii) dependência de decisões arquiteturais conscientes para garantir manutenção e evolução em projetos de maior escala.

      4. 4 Observações qualitativas

      A análise qualitativa das respostas permitiu identificar padrões consistentes na percepção dos desenvolvedores que testaram e examinaram o código do aplicativo. Os relatos convergiram para três aspectos principais: produtividade, organização interna e modularidade da interface. Em relação à produtividade, a experiência com o hot reload foi frequentemente mencionada como facilitadora de ajustes e refinamentos rápidos na interface. Os participantes relataram uma sensação de fluidez no processo de experimentação visual, destacando que pequenas alterações tornaram-se praticamente instantâneas no ciclo de construção da interface. Como sintetizado em uma das avaliações: “A possibilidade de ver as mudanças imediatamente acelerou muito o processo”. Essa percepção dialoga com o resultado quantitativo, no qual a afirmação “O Flutter melhora a produtividade no desenvolvimento” apresentou média aproximada de 3.45.

      A organização estrutural do projeto também foi reconhecida como positiva. O encapsulamento da lógica no módulo Memory e a separação dos widgets em componentes reutilizáveis favoreceram um entendimento claro do fluxo de execução. Um dos participantes mencionou que “a estrutura por arquivos facilita encontrar onde cada coisa acontece”, enquanto outro observou que “a lógica concentrada em uma classe torna o comportamento previsível”. Esses relatos sustentam a média de ≈ 3.00 atribuída à afirmação “A arquitetura do Flutter contribui para um código mais organizado”.

      A modularidade proporcionada pelos widgets foi o ponto de maior consenso entre os desenvolvedores. Houve recorrência na identificação de que a composição hierárquica da interface permitiu reuso e ajustes focados sem retrabalho extenso. Como sintetizado por um dos avaliadores: “O sistema de widgets ajuda a pensar a interface como blocos encaixáveis, e isso deixa tudo mais administrável.” Essa percepção alinhou-se diretamente ao resultado mais expressivo do questionário: a afirmação “O uso de widgets simplifica o desenvolvimento de interfaces” obteve média ≈ 3.55, o maior valor entre os itens avaliados.

      Por outro lado, surgiram observações que apontam limites da abordagem utilizada, especialmente no que diz respeito ao gerenciamento de estado. Embora setState() tenha sido considerado adequado ao tamanho reduzido do aplicativo, alguns desenvolvedores destacaram que projetos maiores exigiriam uso de estruturas mais robustas, como Bloc ou Riverpod. Um avaliador sintetizou essa preocupação afirmando que “para um app simples funciona bem, mas em algo maior eu sentiria falta de um gerenciamento de estado mais controlado”.

      No conjunto, as percepções qualitativas confirmam que a arquitetura e a estrutura adotadas facilitaram o desenvolvimento e a manutenção no contexto estudado, ao mesmo tempo em que apontam caminhos relevantes para expansão e complexidade futura.

      4.6 Recomendações Práticas e Limitações do Estudo

      A experiência de implementação e a avaliação conduzida indicam que o Flutter se mostra particularmente vantajoso em cenários que exigem rápida iteração visual e clareza na organização da interface, favorecendo prototipação e desenvolvimento incremental. Recomenda-se, para projetos iniciantes ou de pequena escala, a adoção de uma arquitetura que separe explicitamente a lógica da camada de apresentação, como exemplificado pelo módulo Memory, permitindo que a evolução da interface ocorra sem interferências indesejadas no comportamento interno do aplicativo. Além disso, a construção hierárquica de widgets demonstrou ser uma estratégia eficaz para promover reutilização e reduzir retrabalho em ajustes de layout.

      Contudo, os resultados também sugerem cuidados importantes, principalmente no que se refere ao gerenciamento de estado. Embora o uso de setState() tenha sido adequado ao contexto deste estudo, desenvolvedores consultados destacaram que aplicações com maior complexidade funcional demandam soluções mais robustas, como Bloc, Provider, Riverpod ou outros padrões baseados em fluxo de dados reativo. Da mesma forma, aspectos ligados a persistência de dados, comunicação com serviços externos e otimização de desempenho em interfaces complexas não foram explorados neste projeto, o que limita a generalização dos resultados para aplicações de larga escala.

      Por fim, destaca-se que o estudo foi conduzido a partir de um caso de uso simples, analisado por um conjunto de desenvolvedores experientes, o que favorece consistência técnica, mas pode restringir a aplicabilidade dos resultados a públicos com menor familiaridade com padrões de projeto ou arquiteturas baseadas em composição. Assim, embora o estudo permita identificar tendências sólidas sobre usabilidade, modularidade e produtividade no uso do Flutter, recomenda-se cautela ao extrapolar essas conclusões para contextos com requisitos mais extensos ou equipes heterogêneas em termos de experiência.

      5 CONCLUSÕES E TRABALHOS FUTUROS

      O estudo apresentado demonstrou que o Flutter se configura como uma alternativa eficaz para o desenvolvimento de interfaces móveis, especialmente em cenários que requerem rápida iteração visual, modularidade e organização clara entre lógica e apresentação. A estrutura adotada no estudo de caso com lógica encapsulada no módulo Memory e interface construída a partir da composição hierárquica de widgets permitiu um fluxo de desenvolvimento contínuo e previsível, reforçado pelo hot reload, que contribuiu para a percepção de produtividade entre os desenvolvedores avaliadores.

      Os resultados qualitativos e quantitativos indicaram melhora considerável na clareza estrutural e na eficiência do processo de implementação, embora tenham também evidenciado que a escalabilidade da arquitetura depende de decisões explícitas de gerenciamento de estado. Esses achados sugerem que o Flutter é particularmente adequado para prototipagem funcional, aplicativos de pequena a média complexidade e ambientes de desenvolvimento que valorizam experimentação visual.

      Como direção para trabalhos futuros, considera-se relevante expandir a investigação para projetos que envolvam:

      (i) integração com APIs externas,
      (ii) persistência local de dados,
      (iii) animações complexas, e
      (iv) múltiplas telas com navegação avançada.

      Além disso, recomenda-se comparar empiricamente diferentes abordagens de gerenciamento de estado (como Bloc, Provider e Riverpod), com foco em custo cognitivo, desempenho e manutenibilidade em médio prazo. Estudos com participantes de diferentes níveis de experiência também poderão contribuir para avaliar a curva de aprendizagem do framework em contextos mais heterogêneos.

      Em síntese, os resultados reforçam o potencial do Flutter como ferramenta para desenvolvimento móvel moderno, ao mesmo tempo em que indicam oportunidades de avanço na compreensão de sua escalabilidade e aplicação em sistemas de maior complexidade.

      REFERÊNCIAS

      BRITO, Abraão. Calculator App (Flutter Example). GitHub Repository. Disponível em: https://github.com/abraaobb/calculator_app. Acesso em: (09/11/2025).

      CARIUS, Lars et al. Cloud-Based Cross-Platform Collaborative Augmented Reality in Flutter. Frontiers in Virtual Reality, v. 3, p. 1–14, 2022. DOI: 10.3389/frvir.2022.1021932.

      CHERVINSKA, A.; AFANASIEVA, I. Mobile Cross-Platform Technologies: Flutter. Xamarin. React Native. Systems of Information Processing, v. 1, n. 180, p. 109–116, 2025. DAGNE, Lukas. Flutter for Cross-Platform App and SDK Development. Bachelor’s Thesis (Bachelor of Engineering) — Metropolia University of Applied Sciences, Helsinki, 2019.

      JAIN, Abhishek. Scalable Frameworks for Cross-Platform Mobile App Development. Journal of Emerging Technologies and Innovative Research, v. 12, n. 6, p. 676–681, 2025.

      RIAZ, Muhammad Usama. Comparative Analysis of React Native, Kotlin, and Flutter for Cross-Platform Mobile Development. Master’s Thesis — Åbo Akademi University, Turku, 2025.

      UPLENCHWAR,  Sakshi  R.;  DENGE,  Urmila  S.;  BAJORIYA,  Anurag  S.; BACHWANI, Sudesh A. Review on Detail Information About Flutter Cross Platform. International Journal for Research in Applied Science and Engineering Technology, v. 10, n. 1, p. 1016–1021, 2022.

      VÄÄNÄNEN, Teemu. Flutter in Cross-Platform Development: Tools, Performance and Optimization. Bachelor’s Thesis — University of Oulu, Oulu, 2025.

      1 Discente do Curso de Engenharia de Software da Fundação Centro de Análise Pesquisa e Inovação Tecnológica (Fucapi) e-mail: abraaobritof10@gmail.com
      2 Docente do Curso de Engenharia de Software da Fundação Centro de Análise Pesquisa e Inovação Tecnológica (Fucapi) e-mail: lcuevasrodriguez@gmail.com