Por que lançamos o Swift e não o SwiftUI

Em todas as edições da WWDC desde 2019, o SwiftUI tem vindo a ganhar cada vez mais destaque e, sempre que começamos a desenvolver uma nova aplicação, reunimo-nos em equipa para fazer a mesma pergunta: Será que já merece um lugar nas nossas aplicações? Até agora, a resposta tem sido «não» no que diz respeito aos aspetos importantes — e, provavelmente, «sim» no que diz respeito aos aspetos que não importam.

Isto não é um julgamento sobre o SwiftUI em geral. Muitas equipas lançam aplicações excelentes com esta tecnologia. É apenas uma descrição do contexto em que faz sentido para nós: um pequeno estúdio que mantém várias aplicações iPhone e iPad em simultâneo, sem margem para surpresas em nenhuma delas.

O que funciona

O SwiftUI é realmente excelente para ecrãs de configurações estáticas, layouts de formulários e tudo aquilo em que a árvore de visualização é pequena e o fluxo de dados é unidirecional. Nós utilizamo-lo. Também o utilizamos para pré-visualizações enquanto estamos a projetar — o ciclo de iteração é mais rápido do que o do UIKit.

Na prática, isso significa que o ecrã onde se selecionam unidades ou se exportam dados é, muitas vezes, em SwiftUI, integrado numa aplicação cujos ecrãs principais são em UIKit. Os dois coexistem sem grande atrito, e a sua combinação permite-nos utilizar cada um deles onde se destaca, em vez de dedicarmos toda a aplicação a uma única abordagem.

O que não funciona (para nós)

Assim que um ecrã necessita de gestos personalizados, listas sensíveis ao desempenho, um estado de navegação complexo ou uma sincronização precisa das animações, voltamos a recorrer ao UIKit. A razão não é mera moda — é o tipo de erros que encontramos quando não o fazemos. O SwiftUI melhorou significativamente nas suas versões mais recentes, mas ainda nos surpreende em tempo de execução de formas que o UIKit raramente o faz.

Os exemplos concretos ajudam. Um programa de treino de digitação precisa que cada tecla premida resulte no caractere certo, sem qualquer atraso visível, e que o ecrã acompanhe o ritmo dos dedos do utilizador. Um histórico extenso de registos num aplicativo de acompanhamento precisa de rolar suavemente num telemóvel mais antigo. Um planeador com a funcionalidade «arrastar e largar» precisa de gestos que não entrem em conflito com os do próprio sistema. É neste tipo de ecrãs que consideramos o UIKit mais previsível.

As vantagens e desvantagens

Manter-se fiel ao UIKit tem o seu preço. Significa mais código para o mesmo ecrã e implica que quem se junte à equipa tenha de se sentir à vontade com um framework mais antigo, que os tutoriais tendem cada vez mais a ignorar. Algumas novas funcionalidades do sistema chegam primeiro ao SwiftUI, e a sua adoção a partir do UIKit exige um trabalho adicional de adaptação. Temos também de ser honestos e admitir que parte da nossa cautela se deve à familiaridade: conhecer um framework em profundidade tem o seu valor, mas também pode tornar-se uma desculpa.

Há também uma questão em aberto. As nossas aplicações iPhone e iPad já funcionam nos Mac com Apple Silicon, e temos em planos criar aplicações nativas para o Mac. Se o SwiftUI facilitar significativamente a partilha de código de interface entre essas plataformas, a situação poderá mudar.

O que fizemos de errado

Uma vez utilizámos o SwiftUI para um ecrã que parecia simples no papel, mas que acabou por não o ser: uma lista com ações de deslizar personalizadas e um estado que mudava à medida que se percorria o ecrã. Funcionava bem nas pré-visualizações, mas de forma estranha nos dispositivos reais. Recriá-lo no UIKit demorou mais tempo do que teria demorado começar por aí. Agora decidimos caso a caso, logo à partida, com base no que a tela tem realmente de fazer.

Esse é o único teste verdadeiro: Será que isto nos vai surpreender na produção? No que diz respeito à maior parte do que desenvolvemos, a resposta exclui o SwiftUI como plataforma principal. Voltaremos a analisar essa possibilidade no próximo ano.