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!