Cartola FC 2020 e SwiftUI + Combine

Contexto

Ola pessoal, vou contar aqui um pouco sobre as motivacoes, obstaculos, perdas e ganhos com a inclusao destes novos frameworks em uma nova feature que entrou na temporada 2021 do Cartola FC.

Tudo comecou la no 4 quarter de 2020 do Cartola quando teriamos que incluir o famoso e tao pedido pelos cartoleiros, o Banco de Reservas, para a proxima temporada que estava por vir. Com isso o time de engenharia (eramos quatro devs iOS) se reuniu para discutir sobre a utilizacao do SwiftUI. Naquele momento ja estavamos usando a lib wrapper do Combine que dava suporte para os sistemas operacionais mais antigos da Apple (iOS12), o OpenCombine. Pensamos em usa-lo minimamente para nao termos problemas com algo que ainda era beta. A estrategia do time era de quando pudessemos incorporar de vez o Combine e ao remover a lib, simplesmente retirando o prefixo Open dos imports nos arquivos deixando apenas o Combine. Bela estrategia 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 migracao foi bem tranquila. O que nao podemos dizer sobre o SwiftUI.

Os obstaculos da migracao

Primeiro problema foi com os frameworks que ja existiam. No Cartola ja utilizavamos modulos de frameworks dinamicos dentro do projeto tanto para separar as responsabilidades do codigo, como melhorar o processo de build que afetava muito o CI. Tivemos um grande trabalho de pegar alguns modulos do projeto e transforma-los em SPM (Swift Package Manager).

Digo possiveis por conta do prazo que tinhamos e a complexidade de outros modulos.

Como colocariamos apenas (como se fosse pouco, mas nao) a tela de Escalacao toda em SwiftUI, isso ja seria muita mudanca. Contando que essa tela era legada, com codigo em Objective-C, com muitas funcionalidades e que ainda estava entrando uma nova que era, o Banco de Reservas. Muita responsabilidade.

Como foi a decisao?

Algo que muitas pessoas de negocios me perguntam e: "qual foi o impacto para o Produto ou Clientes?".

No ponto de vista de Produto, a inclusao de uma tecnologia mais nova abre oportunidades para features que hoje os devices mais atuais podem usufruir. Tambem melhora a experiencia para o usuario, trazendo maior fluidez nas interacoes com a App. Tem a questao da velocidade da entrega que aumenta ao desenvolver novas features com SwiftUI em comparacao ao View Code ou Storyboard (nem fala dos merge hells). Essa parte e absurda.

Para voce criar uma tela e muito rapido. Prototipar com SwiftUI e questao de poucos minutos, vide a maioria de videos que temos por ai nas redes sociais mostrando criacao de layout. E absurdo de veloz.

Outro ponto importante era que nossa base de usuarios com iOS12 era bem pequena (bem mesmo) e nao valeria deixar a grande parte dos usuarios que alias ja estavam no iOS14 sem essa atualizacao. Porem o time de engenharia decidiu dar suporte ao iOS13 e nao implementamos nada do SwiftUI 2 o que seria ruim para nossos usuarios, visto que havia uma parte consideravel utilizando o iOS13. Porem 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 (nao ao Storyboard, please!).

O lado bom de poder misturar UIKit com SwiftUI e que nem tudo precisa ser migrado para SwiftUI para de fato ser utilizado, ou seja, se voce esta em um processo de refatoracao, voce ainda consegue reaproveitar muito componente de UIKit que voce ja tenha em sua app, ou criar um novo por conta do SwiftUI 1 nao ter o suporte.

Esse ponto das versoes do SwiftUI e algo importante ao pensar em migrar. E importante levar em conta que a primeira versao nao e completa. Mas mesmo assim, a documentacao esta boa. Entao na hora que o desenvolvedor bate com uma escrita de codigo, o proprio Xcode diz que aquela funcionalidade e para a versao 14+, ou uma lida na propria documentacao ja diz qual versao de SwiftUI e aquela funcionalidade. Isso nao e um impeditivo para a implementacao.

O conhecimento de SwiftUI e mais um ponto em questao. Por ser algo novo, muitos desenvolvedores podem ainda nao terem estudado e nem trabalhado. Passamos por isso em algumas entrevistas para o nosso time. Vimos que alguns desenvolvedores nao tinham experiencia com SwiftUI e nao haviam nem estudado. Porem isso nao foi impeditivo para nos do time. Bastava apenas ter a vontade de aprender, assim cabendo ao time capacitar os mesmos. A Globo patrocina os funcionarios com treinamentos e estimula essa troca de conhecimentos com talks internas e comites tecnicos, que ajudam a disseminar conhecimento. Entao quando alguem entra no time, logo ha a passagem de conhecimento para nivelar o novo funcionario. Isso e um diferencial para usarmos tecnologia de ponta. Tanto que a implementacao comecou no ultimo quarter de 2020, visto que SwiftUI teve seu lancamento em setembro de 2019. Hoje ha varios artigos e a propria Apple tem uns cursos sobre SwiftUI e Combine.

Declarativo, cross-platform e Combine

Para o time de engenharia escrever com SwiftUI e melhor por ele ser declarativo, em vez de imperativo, como escrevemos com UIKit. Basicamente, significa que voce simplesmente se concentra em descrever como deseja que sua interface de usuario tenha a aparencia e o comportamento, deixando que o SwiftUI se encarregue de descobrir a melhor maneira de fazer isso.

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

Falando de Combine... No inicio quando ainda decidimos usar o OpenCombine, aliamos no time de usarmos apenas para binds de View e nao em tudo. No decorrer do desenvolvimento e quando adotamos de fato o Combine nativo, vimos que poderiamos usar em outros lugares como nos requests. Combine tambem e declarativo facilitando a escrita e entendimento em processar eventos e dados de forma assincrona. Outro ganho ao subirmos o target do iOS.

Outro ponto ruim e o Preview, pois ele pode quebrar em alguns casos e voce fica sem aquela referencia de UI quando estiver criando uma tela. Isso pode nao acontecer. Mas e algo comum quando se tem varias dependencias e imports de modulos. Vide a quantidade de posts no Stackoverflow sobre crashes de previews. Com isso pode ficar um pouco mais lento o processo de desenvolvimento. Porem nada que um build no simulador nao resolva, e para quem estava acostumado de so ver layout dessa forma (esquece o storyboard, please!), talvez nao seja um problemao.

Dito tudo isso, levamos esses pontos para nossa area de negocios. Nosso PO estava de acordo com a subida para a versao 13 e como todos os pontos levantados acima eram fatos, foi tranquilo o aceite de ambas as partes (negocio e desenvolvimento).

Lancamento

Lancamos a App com o Banco de Reservas em Abril e ja corremos para os analytics para acompanhar a saude da app no lancamento. Por sabermos que SwiftUI e algo novo de 2 anos aproximadamente, sabiamos que poderia ocorrer algum bug, porem haviamos feito todo quanto e teste antes do lancamento. E qual foi o resultado? Um crash-free users com 99%, ou seja, a versao estava estavel. Ate depois com o comeco do campeonato brasileiro em Maio, quando realmente tem um acesso maior de usuarios, a app se mostrou estavel.

Conclusao

Consideracoes finais

SwiftUI e o futuro e chegou para ficar.

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

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

Mas meu conselho e: entender quais sao as vantagens e desvantagens e considera-las ao pensar em escrever um novo aplicativo ou criando novas funcionalidades em um aplicativo em producao. Se voce estiver construindo um pequeno prototipo ou um aplicativo de demonstracao, o SwiftUI pode ser a escolha certa e pode ajudar a reduzir os custos e o tempo de desenvolvimento. Se voce esta construindo algo para usuarios com iOS12 ou anterior, talvez o UIKit seja mais preferivel. Mas voce tambem pode escolher quais features deseja publicar para cada OS, ou seja, algo so para usuarios iOS13 ou para iOS12. E uma opcao.

Se tiver com dificuldade para decidir entre UIKit e SwiftUI, tente usar uma combinacao: 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!