In mid-2014, when I began my journey into mobile development, there were few options for cross-platform approaches. My journey started with Xamarin, a powerful technology that allowed me to create native applications for multiple platforms using C#. Over the years, I focused on mobile development, leaving backend development behind to dedicate myself solely to Android and iOS development. In this post, I share some of my experiences and explain why I am increasingly drawn to iOS development with Swift.

During my journey, I devoted much time to working with Xamarin, especially with Xamarin Forms. The flexibility and efficiency of Xamarin enabled me to easily create native apps for Android and iOS, sharing a significant codebase. Having worked with Java before, I thought the C# language to be very familiar and easy to learn. Right from the beginning, I sensed the presence of a vibrant community of developers supported by robust libraries and a highly evolved ecosystem. Moreover, for some companies, this type of cross-platform technology is advantageous, as it allows for writing less code, developing more features, and delivering faster – precisely what the company I was working for at the time was seeking.

As time went on, I gained comprehensive knowledge of mobile development. I learned the importance of good architecture, developing a simple and usable interface, API integration, handling Android and iOS intricacies when new SDK versions emerged, and a lot of situations that a mobile developer faces in these ecosystems. It was a journey of constant growth, where each challenge led me to learn new skills and expand my knowledge.

However, as my career advanced, I recognized the importance of delving deeper into mobile development. In 2019, when I joined Mercos, I had the opportunity to work with the Xamarin Traditional approach, which led to deep reflection on my journey and future aspirations.

This article is not intended to discuss details about my current company or the recruitment process I went through to join. But for more clarity of my point of view, I’ll provide some information to contextualize what I’m sharing here. In the technical test I took to enter the company, I needed to consume an API and create a product catalog with some business rules. The only restriction was that I couldn’t use Xamarin Forms, only Xamarin Traditional. With this, I began the solution with the shared project, performed numerous unit tests to validate the business rules, and only then started the Android app. Since I already enjoyed practicing TDD, this wasn’t a problem. Some days after, I managed to finish the Android app. However, the iOS app was still pending, and my deadline was approaching. I couldn’t complete it due to the timeline. Nevertheless, I still succeeded in leaving a positive impression due to the project’s organization, unit tests, implemented business rules, constructed layout, some other technical attributes, and especially my behavioral attributes.

I was approved in the recruitment process. However, at the same time, I was concerned because I realized I urgently needed to enhance my knowledge of native mobile development. I started studying Android and iOS with Kotlin and Swift, respectively. And so time passed. The more I faced challenges with the Mercos app, the more I understood that I knew little about mobile development. I believe this happened because I had been so focused on working exclusively with Xamarin Forms in the first years of my mobile development career. I learned to use various abstractions, plugins, and codes that facilitated daily tasks. However, with Xamarin Traditional, you don’t have as many utilities to help, and it’s common to need to pay more attention to the app state and lifecycle. To learn all these things, I continued studying Android and iOS, and I began to be drawn to iOS development with Swift. This is making me think about my next career move.

But if Xamarin is so good, why change technologies? Why make another career shift? Why start over? Well, I believe it’s related to the experiences I’ve had so far and what I want to explore in the future. This isn’t about right or wrong, and you shouldn’t make a decision solely based on this post because each of us has different realities and needs, and the project, team, or company we work in also has specific requirements that may differ from our own.

But let’s get to it: What impressions do I have about these technologies? What experiences have I had in recent years? During my journey with Xamarin, I notice some limitations the platform has compared to native development, whether with Android or iOS. Although Xamarin offers a cross-platform development approach, some tools and resources are more optimized for native development with Kotlin and Swift. This sparked my interest in exploring native development more, preferably with Swift.

One of the most complex things I see in the Xamarin environment is the high interoperability between tools like Visual Studio and Xcode. While this interoperability makes it easier to create cross-platform projects in a single language, it can also introduce difficulties in identifying specific details in the stack trace when evaluating errors in a production app using crash analytics tools like App Center, Firebase, Sentry, and others. This limitation can be challenging, especially when seeking a detailed analysis of issues. Often, when analyzing a stack trace for a Xamarin app error, we only have a hint of where the problem is occurring. We rarely obtain details that would help us identify the source of the problem, mainly when issues are related to the application’s lifecycle. This is straightforward to understand in Xamarin apps, as .NET is a runtime embedded within the APK and IPA. Because of this, crash analytics tools can’t detail exactly which line of code a problem occurred due to this characteristic of .NET applications. According to fellow professionals, this not occurs in native applications with Kotlin and Swift, where we can have greater traceability regarding problems.

Tools that perform profiling to analyze performance and areas where software can improve also have limitations for Xamarin applications. To address this, Xamarin created the Xamarin Profiler, a tool that can perform this analysis on a .NET mobile application. However, the Xamarin Profiler is only available to those with an Enterprise license of Visual Studio, which, in my opinion, is a shame because a tool designed to help develop a quality app should be incentivized and available for free within the ecosystem instead of being sold as a premium feature. The same applies to Android’s AOT compilation, which is only available with the Enterprise license. But honestly, I always had difficulty using the Xamarin Profiler on Intel-based Macs as it demands a lot from the machine. I haven’t tested it on ARM-based Macs yet, but I believe it might perform better on these machines.

Even with profiling tools available for our computers, we still struggle with limitations stemming from the .NET runtime when analyzing data from mobile apps using a crash analytics tool. Currently, we use Sentry as our crash analytics tool and can’t try the profiling functionality it offers because our application isn’t a native app developed with Kotlin or Swift. This would be an excellent tool to discover bottlenecks in the application based on behavior usages of our customers of the app since we can’t always identify all issues by creating test scenarios on our machines or in large farms like App Center and Firebase. Often, the combination of factors such as data volume, dynamic screen processing, or even the type of device used can influence an app’s performance, and these tools tend to help identify these specific bottlenecks.

If you’re curious about Sentry Profiling, you can find the link here.

Another aspect to consider is the latest technologies in these ecosystems. I’m referring to building screens using the fluent interface with Compose and SwiftUI. Xamarin has always announced that the platform provides 100% access to native APIs using native bindings. However, at this moment, I see we don’t have 100% access because we can’t use these new approaches in Xamarin Traditional applications. Since the platform is open source, you can view all discussions about these topics in the repository, and I found one discussing support for native bindings for SwiftUI. It’s worth checking out as the conversation addresses various issues faced. The link is here.

Looking at all the discussions that have taken place on the subject, it’s understandable how difficult it is to make this happen. I believe that this is one of the reasons why Microsoft is focusing on .NET MAUI, given that it already allows for creating fluent interfaces with C# instead of XAML. This was already possible with Xamarin Forms, but the support will be improved in .NET MAUI. However, as I still use Xamarin Traditional and there’s no need to migrate to .NET MAUI in the application I work on today, I feel somewhat orphaned in this ecosystem because I see everything very focused around .NET MAUI. Since I’m entirely focused on native development, I feel a bit uncomfortable about the future of Xamarin Traditional approach, considering it’s not compatible with the new technologies released by Google and Apple in recent years. And for those who don’t know or haven’t understood yet, with the newer .NET versions, Xamarin Traditional still exists. It’s now within the .NET platform and is called .NET Android / .NET iOS. .NET MAUI uses these SDKs, just as Xamarin Forms did before. The fundamental logic behind things hasn’t changed, but I see a lot of energy and focus only on .NET MAUI. I believe this will not change as the platform evolves, and we should increasingly see .NET MAUI as the center of attention for .NET mobile applications. Also, I think this is a strategic move by Microsoft to be more competitive with other platforms like Flutter, KMM, and React Native. I guess the “.NET Traditional” (this term I made up) will not be highly promoted and encouraged as Xamarin Traditional was. It concerns me a bit. Just to be very clear: This is an opinion, okay?

I already talk with some people in the community about this topic. The way Microsoft communicates the platform’s evolution makes many people understand that the future of .NET mobile development will be only MAUI. Some people have asked me, “When are you plan to migrate your app to MAUI?” The short answer is that we’re not going to migrate. The long answer is that the Xamarin Traditional development approach will continue to exist through .NET Android and .NET iOS. This won’t change. MAUI is a framework built using these SDKs, and we can continue to use them independently.

The critical point of this conversation is that there seems to be a lack of incentive for .NET developers to continue employing the traditional approach, as it’s no longer possible to access 100% of the APIs using only native bindings with C#. Does this mean we should stop using Xamarin and choose another technology? Of course not! Here at the company, for example, if the technology doesn’t threaten the business evolution, we’ll likely continue to use .NET in the traditional approach because we currently have an excellent solution built. However, this has made me question my future in mobile development, and as a result, I’ve been thinking more about my next career move to get closer to native iOS development.

Does this mean I won’t post content related to .NET anymore? No! After all, I continue to work with the platform day-to-day, and we have a lot of work to do here on the team, and I still really like C#. However, the tendency is that I’ll start posting content related to iOS development with Swift to share my studies and experiences with you. While I don’t work with Swift full-time yet, I’ll continue to apply the knowledge I’m gaining about iOS to the Xamarin project I currently work on. In the end, everyone benefits!

My journey in mobile development has been full of learning. With Xamarin, I can explore creating native apps for Android and iOS. However, my interest in iOS development with Swift has led me to seek new learning opportunities and deepen my knowledge. By exploring the differences between Xamarin and native development with Swift, I’m preparing to embrace this new challenge.

That’s it! I plan to share some content about iOS here on the blog soon.

And you? How do you currently feel about Xamarin / MAUI mobile development? Share your impressions in the comments. I’d like to understand your opinion on the matter. And if you find any flawed arguments in this article, feel free to discuss them with me in the comments.

Bye!