Cartola FC: 2020 e SwiftUI + Combine

Olá pessoal, vou contar aqui um pouco sobre as motivações, obstáculos, perdas e ganhos com a inclusão destes novos frameworks em uma nova feature que entrou na temporada 2021 do Cartola FC.

Tudo começou lá no 4 quarter de 2020 do Cartola quando teríamos que incluir o famoso e tão pedido pelos cartoleiros, o Banco de Reservas, para a próxima temporada que estava por vir. Com isso o time de engenharia(éramos quatro devs iOS) que se reuniu para discutir sobre a utilização do SwiftUI.
Naquele momento já estávamos usando a lib wrapper do Combine que dava suporte para os sistemas operacionais mais antigos da Apple(iOS12), o OpenCombine. Pensamos em usá-lo minimamente para não termos problemas com algo que ainda era beta. A estratégia do time era de quando pudéssemos incorporar de vez o Combine e ao remover a lib, simplesmente retirando o prefixo Open dos imports nos arquivos deixando apenas o Combine. Bela estratégia que deu certo. Tudo funcionou 😊 🙃 🚀

Quando de fato pudemos subir o target de suporte para o iOS13, assim removendo o suporte para o iOS12, a migração foi bem tranquila. O que não podemos dizer sobre o SwiftUI.

Primeiro problema foi com os frameworks que já existiam. No Cartola já utilizávamos módulos de frameworks dinâmicos dentro do projeto tanto para separar as responsabilidades do código, como melhorar o processo de build que afetava muito o CI. Tivemos um grande trabalho de pegar alguns módulos do projeto e transformá-los em SPM(Swift package manager).

Módulos que foram possíveis a serem mudado;

• UI
• Networking
• Models
• Logic
• Resources
• Protocol
• Analytics
• Navigation

Digo possíveis por conta do prazo que tínhamos e a complexidade de outros módulos.

Como colocaríamos apenas(como se fosse pouco hahaha, mas não) a tela de Escalação toda em SwiftUI, isso já seria muita mudança. Contando que essa tela era legada, com código em Objective-C, com muitas funcionalidades e que ainda estava entrando uma nova que era, o Banco de Reservas. Muita responsabilidade.

Módulo de escalação.

Como foi a decisão?

Algo que muitas pessoas de negócios me perguntam é: “qual foi o impacto para o Produto ou Clientes?”.

No ponto de vista de Produto, a inclusão de uma tecnologia mais nova, abre oportunidades para features que hoje os devices mais atuais podem usufruir. Também melhorar a experiência para o usuário, trazendo maior fluidez nas interações com a App. Tem a questão da velocidade da entrega que aumenta ao desenvolver novas features com SwiftUI em comparação ao View Code ou StoryBoard(nem fala dos merge hell’s). Essa parte é absurda.

Para você criar uma tela é muuuito rápido. Prototipar com SwiftUI é questão de poucos minutos, vide a maioria de videos que temos por aí nas redes sociais mostrando criação de layout. É absurdo de veloz.

Outro ponto importante era que nossa base de usuários com iOS12 era bem pequena(bem mesmo) e não valeria deixar a grande parte dos usuários que aliás já estavam no iOS14 sem essa atualização. Porém o time de engenharia decidiu dar suporte ao iOS13 e não implementamos nada do SwiftUI 2 o que seria ruim para nossos usuários, visto que havia uma parte considerável utilizando o iOS13. Porém com isso tivemos alguns problemas pois o SwiftUI 1 carece de muitas funcionalidades que o SwiftUI 2 complementa, trazendo a necessidade de misturar ou criar alguns componentes de UI(UIKit) com ViewCode(não ao StoryBoard, please! 🛑 rsrs).

O lado bom de poder misturar UIKit com SwiftUI é que nem tudo precisa ser migrado para SwiftUI para de fato ser utilizado, ou seja, se você está em um processo de refatoração, você ainda consegue reaproveitar muito componente de UIKit que você já tenha em sua app, ou criar um novo por conta do SwiftUI 1 não ter o suporte.

Esse ponto das versões do SwiftUI é algo importante ao pensar em migrar. É importante levar em conta que a primeira versão não é completa. Mas mesmo assim, a documentação está boa. Então na hora que o desenvolvedor bate com uma escrita de código, o próprio Xcode diz que aquela funcionalidade é para a versão 14+, ou uma lida na própria documentação já diz qual versão de SwiftUI é aquela funcionalidade. Isso não é um impeditivo para a implementação.

O conhecimento de SwiftUI é mais um ponto em questão. Por ser algo novo, muitos desenvolvedores podem ainda não terem estudado e nem trabalhado. Passamos por isso em algumas entrevistas para o nosso time. Vimos que alguns desenvolvedores não tinham experiência com SwiftUI e não haviam nem estudado. Porém isso não foi impeditivo para nós do time. Bastava apenas ter a vontade de aprender, assim cabendo ao time capacitar os mesmos. A Globo patrocina os funcionários com treinamentos e estimula essa troca de conhecimentos com talks internas e comitês técnicos, que ajudam a disseminar conhecimento. Então quando alguém entra no time, logo há a passagem de conhecimento para nivelar o novo funcionário. Isso é um diferencial para usarmos tecnologia de ponta. Tanto que a implementação começou no último quarter de 2020, visto que SwiftUI teve seu lançamento em setembro de 2019. Hoje há vários artigos e a própria Apple tem uns cursos sobre SwiftUI e Combine.

Its magical

Para o time de engenharia escrever com SwiftUI é melhor por ele ser declarativo, em vez de imperativo, como escrevemos com UIKit. Basicamente, significa que você simplesmente se concentra em descrever como deseja que sua interface de usuário tenha a aparência e o comportamento, deixando que o SwiftUI se encarregue de descobrir a melhor maneira de fazer isso.

Por ser cross-platform isso é um outro ganho. Sua UI pode ser facilmente compartilhada para WatchOS, MacOS e TvOS.

cross-platform

Falando de Combine… No início quando ainda decidimos usar o OpenCombine, aliamos no time de usarmos apenas para binds de View e não em tudo. No decorrer do desenvolvimento e quando adotamos de fato o Combine nativo, vimos que poderíamos usar em outros lugares como nos requests. Combine também é declarativo facilitando a escrita e entendimento em processar eventos e dados de forma assíncrona. Outro ganho ao subirmos o target do iOS 🚀.

Outro ponto ruim é o Preview, pois ele pode quebrar em alguns casos e você fica sem aquela referência de UI quando estiver criando uma tela. Isso pode não acontecer. Mas é algo comum quando se tem várias dependências e imports de módulos. Vide a quantidade de posts no Stackoverflow sobre crashes de previews. Com isso pode ficar um pouco mais lento o processo de desenvolvimento. Porém nada que um build no simulador não resolva, e para quem estava acostumado de só ver layout dessa forma(esquece o storyboard, please! hahaha), talvez não seja um problemão hahaha.

Dito tudo isso, levamos esses pontos para nossa área de negócios. Nosso PO estava de acordo com a subida para a versão 13 e como todos os pontos levantados acima eram fatos, foi tranquilo o aceite de ambas as parte(negócio e desenvolvimento).

Lançamento

Lançamos a App com o Banco de Reservas em Abril e já corremos para os analytics para acompanhar a saúde da app no lançamento. Por sabermos que SwiftUI é algo novo de 2 anos aproximadamente, sabíamos que poderia acorrer algum bug, porém havíamos feito todo quanto é teste antes do lançamento. E qual foi o resultado? Um crash free users com 99% 📈, ou seja, a versão estava estável 🥳 🎉. Até depois com o começo do campeonato brasileiro em Maio, quando realmente tem um acesso maior de usuários, a app se mostrou estável.

Conclusão

Motivação:

• Velocidade em criar Layout
• Migração ao poucos. Não precisa migrar tudo de UIKit, pode ser feito de forma gradual.
• Poder utilizar novas funcionalidades disponíveis apenas para as versões mais atuais do iOS.
• Aumentar a velocidade da entrega, visto que construir layout é mais fácil e rápido.
• Utilizar tecnologia de ponta da Apple, assim estando à frente no mercado.
• O código ser declarativo.
• Escrever menos código para obter o resultado desejado.
• Cross-platform
• Você pode usar o preview para ver as views como se fossem um live reload. Isso ajuda para desenvolver rápido sua IU.
• WidgetKit requer SwiftUI e você talvez queira ter um em sua app.

Obstáculos:

• Migrar alguns módulos que antes estavam em frameworks estatísticos para SPM
• SwiftUI 1 não é completo precisando ainda de UIKit para caso você queria da suporte a partir do iOS13
• Conhecimento da equipe.
• Os problemas serão mais difíceis de resolver, pois ninguém os enfrentou ainda(Embora esteja diminuindo com o passar do tempo).
• As melhores práticas ainda não foram definidas.

Perdas:

• Sua base de usuários em devices com iOS12 ou anteriores.

Considerações finais

SwiftUI é o futuro e chegou para ficar.

Não vejo o UIKit ir a algum lugar por um longo tempo.

O futuro é declarativo, vide a quantidade de linguagens se adaptando para serem declarativas. Exemplo do Android com o Jetpack Compose.

Mas meu conselho é: entender quais são as vantagens e desvantagens e considerá-las ao pensar em escrever um novo aplicativo ou criando novas funcionalidades em um aplicativo em produção. Se você estiver construindo um pequeno protótipo ou um aplicativo de demonstração, o SwiftUI pode ser a escolha certa e pode ajudar a reduzir os custos e o tempo de desenvolvimento. Se você está construindo algo para usuários com iOS12 ou anterior, talvez o UIKit seja mais preferível. Mas você também pode escolher quais features deseja publicar para cada OS, ou seja, algo só para usuários iOS13 ou para iOS12. É uma opção.

Se tiver com dificuldade para decidir entre UIKit e SwiftUI, tente usar uma combinação: SwiftUI primeiro ou um projeto UIKit conservador com algumas views/features em SwiftUI, como nos do Cartola fizemos.

Os ganhos de produtividade compensaram os pequenos contratempos que listei acima.

Obrigado pela leitura e divirta-se com o SwiftUI!