Ione Souza Junior

Minha jornada no desenvolvimento mobile: Do C# ao Swift

20/08/2023 | 12 minutos de leitura | Tradu√ß√Ķes: en | #xamarin #swift

Em meados de 2014, quando iniciei minha jornada no desenvolvimento mobile, havia poucas op√ß√Ķes de abordagens multiplataforma. Minha trajet√≥ria teve in√≠cio com o Xamarin, uma poderosa tecnologia que me permitiu criar aplicativos nativos para m√ļltiplas plataformas usando C#. Ao longo dos anos, foquei no desenvolvimento de aplicativos, deixando de lado o desenvolvimento backend para me dedicar apenas ao desenvolvimentos de apps para Android e iOS. Neste post, compartilho um pouco da minha experi√™ncia, e tamb√©m conto o motivo de eu me sentir cada vez mais atra√≠do pelo desenvolvimento iOS com Swift.

Durante minha trajetória, dediquei bastante tempo ao trabalho com Xamarin, especialmente com Xamarin Forms. A flexibilidade e a eficiência do Xamarin permitiram que eu criasse aplicativos nativos para Android e iOS com facilidade, compartilhando uma base de código significativa. Eu já havia trabalhado com Java e achei a linguagem C# muito familiar e fácil de aprender. Desde o princípio senti que existia uma ampla comunidade de pessoas desenvolvedoras, bibliotecas robustas e um ecossistema bem evoluído. E é claro, né: Para algumas empresas, esse tipo de tecnologia multiplataforma é muito vantajosa, pois permite escrever menos código, desenvolver mais funcionalidades e entregar mais rápido, e isso era justamente o que a empresa que eu trabalhava na época estava procurando.

Com o decorrer do tempo, adquiri um conhecimento abrangente sobre desenvolvimento mobile. Aprendi a import√Ęncia de uma boa arquitetura, do desenvolvimento de uma interface simples e com boa usabilidade, integra√ß√£o com APIs, particularidades do Android e iOS que precisei lidar quando surgiam novas vers√Ķes das SDKs e diversas situa√ß√Ķes que uma pessoa desenvolvedora mobile enfrenta nestes ecossistemas. Foi uma jornada de crescimento constante, onde cada desafio me levou a aprender novas habilidades e expandir meu conhecimento.

Contudo, √† medida que minha carreira avan√ßava, reconheci a import√Ęncia de aprofundar ainda mais meus conhecimentos em desenvolvimento mobile. Em 2019 quando entrei na Mercos, tive a oportunidade de trabalhar com Xamarin Tradicional, o que me levou a uma reflex√£o profunda sobre minha trajet√≥ria e aspira√ß√Ķes futuras.

Este artigo n√£o se destina a discutir detalhes da minha empresa atual nem o processo de sele√ß√£o pelo qual passei ao ingressar, mas vou dar alguns detalhes para contextualizar o que relato aqui. No teste t√©cnico que fiz para entrar na empresa, precisei consumir uma API fornecida pela mesma e criar um cat√°logo de produtos com algumas regras de neg√≥cios estabelecidas. A √ļnica restri√ß√£o √© que eu n√£o poderia usar Xamarin Forms, somente o Xamarin Tradicional. Com isso, comecei a solu√ß√£o pelo projeto compartilhado, fiz in√ļmeros testes de unidade para validar as regras de neg√≥cio e somente depois comecei o app Android. Como eu j√° gostava de praticar TDD, isso n√£o foi um problema para mim. Com v√°rias dificuldades e noites em claro - pois fiz o projeto durante algumas madrugadas, consegui finalizar o app Android. No entanto, ainda faltava o app iOS e meu prazo estava acabando. Eu n√£o consegui finaliz√°-lo por conta do prazo, mas mesmo assim consegui causar uma boa impress√£o para o gerente da √°rea de engenharia por conta da organiza√ß√£o do projeto, testes de unidade, regras de neg√≥cios que implementei, layout constru√≠do, alguns outros atributos t√©cnicos e principalmente os meus atributos comportamentais.

Fui aprovado no processo seletivo. No entanto, ao mesmo tempo eu estava preocupado, pois percebi que eu precisava urgente aprimorar os meus conhecimentos sobre desenvolvimento mobile nativo. Comecei a estudar Android e iOS, com Kotlin e Swift, respectivamente. E assim o tempo foi passando. Quanto mais eu vivenciava os desafios no app da Mercos, mais eu entendia que sabia pouco sobre mobile. Acredito que isso aconteceu pois eu estive muito focado trabalhando apenas com Xamarin Forms nos primeiros anos trabalhando com mobile. Aprendi a utilizar diversas abstra√ß√Ķes, plugins, c√≥digos que facilitavam as tarefas do dia a dia. Por√©m, usando Xamarin Tradicional voc√™ n√£o tem tantos utilit√°rios para te ajudar e √© comum voc√™ precisar se preocupar mais com estado e ciclo de vida da aplica√ß√£o. Para aprender tudo isso, continuei estudando Android e iOS e comecei a me sentir atra√≠do pelo desenvolvimento iOS com Swift, e isso tem feito eu pensar no meu pr√≥ximo movimento na carreira.

Mas se Xamarin é tão bom, por que mudar de tecnologia? Por que fazer mais uma mudança na carreira? Por que recomeçar? Bom, acredito que isso tem relação com as experiências que vivi até o momento e o que eu quero experimentar no futuro. Isso não tem uma relação com certo ou errado e você não deve tomar uma decisão com base apenas no meu relato, pois cada um de nós temos realidades e necessidades distintas, e o projeto, time ou empresa que atuamos também tem necessidades específicas, que podem ser diferente das nossas.

Mas vamos l√°: Quais as impress√Ķes que tenho sobre estas tecnologias? Que experi√™ncias vivi nos √ļltimos anos? Bom, durante minha jornada com Xamarin, comecei a perceber algumas limita√ß√Ķes que a plataforma tem em compara√ß√£o com o desenvolvimento nativo, seja com Android ou iOS. Embora o Xamarin ofere√ßa uma abordagem de desenvolvimento multiplataforma, algumas ferramentas e recursos s√£o mais otimizados para o desenvolvimento nativo com Kotlin e Swift. Isso despertou meu interesse em explorar mais o desenvolvimento nativo, preferencialmente com Swift que foi a linguagem que me identifiquei mais.

Uma das coisas mais complexas que vejo no ambiente com Xamarin √© a grande interoperabilidade entre as ferramentas, como o Visual Studio e Xcode. Embora essa interoperabilidade facilite a cria√ß√£o de projetos multiplataforma em uma √ļnica linguagem, tamb√©m pode introduzir dificuldades para identificar detalhes espec√≠ficos no stacktrace quando avaliamos os erros de um app em produ√ß√£o em uma ferramenta de crashlytics, tais como App Center, Firebase, Sentry, dentre outras. Essa limita√ß√£o pode ser um desafio, especialmente quando se busca uma an√°lise mais detalhada de problemas ocorridos. Muitas vezes ao analisar um stacktrace de um erro de uma aplica√ß√£o Xamarin, temos apenas uma pista de onde o problema est√° ocorrendo. Dificilmente conseguimos detalhes que far√£o encontrarmos a origem do problema de forma f√°cil, principalmente quando os problemas est√£o relacionados ao ciclo de vida da aplica√ß√£o. Isso √© simples de entender nos apps com Xamarin, pois o .NET √© uma runtime que est√° embedada dentro do APK e IPA. Por conta disso, as ferramentas de crashlytics n√£o conseguem detalhar de forma clara exatamente a linha de c√≥digo onde um problema ocorreu por conta dessa caracter√≠stica das aplica√ß√Ķes .NET. De acordo com colegas de profiss√£o, essa caracter√≠stica √© diferente em aplica√ß√Ķes nativas com Kotlin e Swift, onde conseguimos ter uma maior rastreabilidade sobre os problemas.

Ferramentas que realizam profiling para analisar performance e locais onde o software pode melhorar tamb√©m tem limita√ß√Ķes para aplica√ß√Ķes Xamarin. Para tentar resolver isso, o Xamarin criou o Xamarin Profiler, que √© uma ferramenta que consegue realizar esse tipo de an√°lise em uma aplica√ß√£o mobile .NET. No entanto, o Xamarin Profiler est√° dispon√≠vel apenas para quem tem a licen√ßa Enterprise do Visual Studio, o que na minha opini√£o √© uma l√°stima, pois uma ferramenta que serve para voc√™ desenvolver um app de qualidade deveria ser incentivada gratuitamente pelo ecossistema ao inv√©s de ser vendida como um diferencial. O mesmo tamb√©m acontece com a compila√ß√£o AOT do Android que somente √© disponibilizada na licen√ßa Enterprise. Mas sinceramente, sempre tive dificuldade de utilizar o Xamarin Profiler em Mac‚Äôs Intel pois exige muito da m√°quina. Ainda n√£o testei em Mac‚Äôs ARM, mas acredito que tenha uma melhor performance nestas m√°quinas.

De toda forma, mesmo tendo um profiling para executar em nosso computador, ainda assim sofremos com as limita√ß√Ķes oriundas da runtime do .NET para analisar dados de apps mobile usando uma ferramenta de crashlytics. Atualmente usamos o Sentry como crashlytics e n√£o conseguimos utilizar a funcionalidade do profiling que o mesmo tem pois nossa aplica√ß√£o n√£o √© nativa com Kotlin ou Swift. Essa seria uma excelente ferramenta para descobrirmos gargalos na aplica√ß√£o a partir de casos de uso reais dos clientes usando o app, pois nem sempre conseguimos descobrir todos os problemas somente criando cen√°rios de testes em nossas m√°quinas ou em grandes farms, como App Center e Firebase. Muitas vezes a combina√ß√£o de fatores, como volume de dados, processamento de telas din√Ęmicas ou at√© o tipo de dispositivo que √© utilizado pode influenciar na performance de um aplicativo, e essas ferramentas tendem a ajudar a descobrir onde est√£o estes gargalos bem espec√≠ficos.

Caso você tenha curiosidade em conhecer o Sentry Profiling, aqui está o link.

Outro ponto a ser levado em considera√ß√£o √© em rela√ß√£o as tecnologias mais recentes que existem nestes ecossistemas. Estou falando da constru√ß√£o de telas usando interface fluente com Compose e SwiftUI. O Xamarin sempre anunciou que a plataforma garante 100% de acesso √†s APIs nativas usando os bindings nativos. No entanto, hoje vejo que n√£o temos 100% de acesso pois n√£o conseguimos utilizar estas novas abordagens em aplica√ß√Ķes Xamarin Tradicional. Como a plataforma √© open source, √© poss√≠vel visualizar no reposit√≥rio todas as discuss√Ķes que existem sobre esses assuntos, e achei uma que fala sobre o suporte √† bindings nativos para o SwiftUI. Vale a pena dar uma conferida, pois a discuss√£o aborda diversos problemas enfrentados. O link est√° aqui.

Olhando para todas as discuss√Ķes que j√° aconteceram sobre o assunto, √© compreens√≠vel a dificuldade de fazer isso acontecer. Para mim, at√© fica um pouco mais claro o motivo da Microsoft estar concentrando esfor√ßos no .NET MAUI, visto que com ele j√° temos a possibilidade de criar interfaces fluentes com C# ao inv√©s de XAML. Na verdade, com Xamarin Forms isso j√° era poss√≠vel, mas o suporte a esse tipo de desenvolvimento ser√° melhorado no .NET MAUI. No entanto, como eu ainda utilizo o Xamarin Tradicional e n√£o existe uma necessidade de migrar para .NET MAUI na aplica√ß√£o que trabalho hoje, me sinto um pouco √≥rf√£o neste ecossistema, pois vejo que tudo est√° muito voltado ao .NET MAUI. Como estou totalmente focado no desenvolvimento nativo, me sinto um pouco desconfort√°vel com o futuro do Xamarin Tradicional tendo em vista que ele n√£o est√° compat√≠vel com as novas tecnologias lan√ßadas nos √ļltimos anos pelo Google e Apple. E para quem n√£o sabe ou ainda n√£o entendeu, com a vinda das novas vers√Ķes do .NET, o Xamarin Tradicional continua existindo, s√≥ que agora ele est√° dentro do .NET e se chama .NET Android e .NET iOS. O .NET MAUI usa essas SDKs, igual j√° acontecia antes com o Xamarin Forms. Por baixo dos panos, a l√≥gica b√°sica das coisas n√£o mudou, mas vejo que a √™nfase est√° apenas no .NET MAUI neste momento. N√£o sinto que isso mudar√° no futuro e devemos ver cada vez mais o .NET MAUI como o centro das aten√ß√Ķes para aplica√ß√Ķes mobile .NET. Acredito que isso seja um movimento estrat√©gico da Microsoft para ficar mais competitiva junto √† outras plataformas, como Flutter, KMM e React Native. Acredito que o ‚Äú.NET Tradicional‚ÄĚ (esse nome eu inventei) n√£o ser√° algo altamente divulgado e encorajado como o Xamarin Tradicional foi, e isso me preocupa um pouco. Apenas para deixar bem claro: Essa √© uma opini√£o, certo?

Isso at√© j√° foi pauta de discuss√Ķes que tive com algumas pessoas da comunidade. Da forma como a Microsoft comunica atualmente a evolu√ß√£o da plataforma, sinto que isso faz muitas pessoas entenderem que o futuro do desenvolvimento mobile com .NET ser√° apenas MAUI. Algumas pessoas j√° me perguntaram: ‚ÄúE a√≠, quando voc√™s v√£o migrar o app de voc√™s para MAUI?‚ÄĚ. A resposta curta √© que n√£o vamos migrar. A resposta longa √© que a abordagem de desenvolvimento com Xamarin Tradicional continuar√° existindo atrav√©s do .NET Android e .NET iOS. Isso n√£o mudar√°. O MAUI √© um framework constru√≠do utilizando essas SDKs, e voc√™ poder√° continuar utilizando elas de forma independente se quiser.

O ponto crucial dessa conversa é que aparenta haver uma ausência de estímulo para os desenvolvedores .NET continuarem empregando a abordagem tradicional, visto que já não é mais possível ter acesso à 100% das APIs usando bindings nativos apenas usando C#. Isso significa que devemos parar de usar Xamarin e escolher outra tecnologia? Claro que não! Aqui na empresa, por exemplo, se a tecnologia não ameaçar o rumo dos negócios, é provável que continuemos a utilizar .NET na abordagem tradicional, pois hoje temos uma excelente solução em mãos. Porém, isso tudo tem feito eu questionar o meu futuro no desenvolvimento mobile e, por conta disso, venho pensando mais sobre o meu próximo movimento de carreira para estar mais próximo do desenvolvimento nativo com iOS.

Isso significa que n√£o vou mais postar conte√ļdos relacionados √† .NET? N√£o! Afinal de contas, eu continuo trabalhando com a plataforma no dia a dia e temos muito trabalho para fazer aqui no time, al√©m de eu gostar muito do C#. Por√©m, a tend√™ncia √© que eu comece a postar conte√ļdos relacionados ao desenvolvimento iOS com Swift para compartilhar meus estudos e experi√™ncias com voc√™s. Enquanto eu n√£o trabalho com Swift em per√≠odo integral, vou continuar utilizando o conhecimento que estou aprendendo sobre iOS para aplicar no projeto Xamarin que trabalho hoje. No fim das contas, todos ganham!

Minha jornada no desenvolvimento mobile tem sido cheia de aprendizados. Com o Xamarin, consigo explorar a criação de aplicativos nativos para Android e iOS. No entanto, meu interesse pelo desenvolvimento iOS com Swift me levou a buscar novas oportunidades de aprendizado e aprofundamento. Ao explorar as diferenças entre Xamarin e o desenvolvimento nativo com Swift, estou me preparando para abraçar essa nova fase da minha carreira, expandindo minhas habilidades e buscando novos desafios.

√Č isso! Em breve pretendo compartilhar alguns conte√ļdos sobre iOS aqui no blog.

E voc√™? Como se sente atualmente no desenvolvimento mobile com Xamarin / MAUI? Compartilhe suas impress√Ķes nos coment√°rios. Eu gostaria muito de entender a sua opini√£o sobre o assunto. E se voc√™ entender que existe algum argumento equivocado neste artigo, fique √† vontade para discutir comigo nos coment√°rios.

Abraço!