Is Xamarin.Forms Making Traditional Xamarin Obsolete?

There is no denying that Xamarin.Forms, has gained incredible popularity over the last few years. You only need to look to at the Forums, blog posts or most newly started projects to see Xamarin.Forms is preferred. It’s had a rough start, and unfortunately, that rough start has left a stain on earlier developers’ perception of Xamarin.Forms, and it is taking a long time to rub clean.

Early Years

Xamarin.Forms came out to a “stable”  release in May 2014. (Stable is purposely air quoted there). After developing a small Objective-C app just after that time,  while I was crying, huddled in a corner, I was searching for an alternative, and being a C# developer, having a XAML based UI, and C# back end seemed like a savior. Having access to all the native API’s, was even better, meaning I wasn’t going to be surprised with limitations on its functionality. But the fun was just about to start. This was a time when I had to use DotPeek to see what was happening under the hood, as it was not open source, it was not widely used and it’s allocated resources at Xamarin were small.

Too Buggy Myth

In the first year especially, over 30% of my working time, was tracking and working around bugs. There was no escape. Painfully obvious, easy to reproduce bugs in Xamarin.Forms, causing minor issues to complete crashes. I never did get around to filing all that I found, but I certainly filed a lot. Though I kept at it, because strangely enough I found it to be the most frustrating fun I have had in a long time. Oh, and the memory leaks, they were difficult to track and particularly painful. You really had to be committed to developing in this platform.

The bugs over time have reduced. There are still new ones introduced, and sometimes regressions appear. But this is generally around new features of Xamarin.Forms, and I rarely come across bugs these days, unless playing with nightly builds or pre-releases.

Performance Myth

It started out as truth, but now it’s not. In the first few years, performance was a large issue. ListView’s were obviously jumpy under small loads, and boot times were also an issue. But that has changed considerably over the last year and even more so in the last few months. ListView’s with cell recycling are now smooth and boot times very much acceptable. Looking at a Xamarin.Forms app and Traditional Xamarin app, I don’t notice any performance issues.

What I do tend to see though, is developer’s put large amounts of initialization code on startup, or in the UI thread, which would make any app slow. Then Google to find the cause, see people previously complaining about Xamarin Form’s performance, then just assume it’s Xamarin’s fault. It’s why I dislike seeing performance touted as such an enormous issue. I released acceptable app’s years ago under Xamarin.Forms, and today’s Xamarin.Forms is far better, so why is it being treated that Xamarin.Forms is slow and clunky? Even Xamarin.Forms animation framework can churn out some buttery smooth animations on low end devices.

I understand it’s never going to be as fast as traditional, but the difference is unnoticeably small in all apps I create today? Is there some large performance issue I haven’t come across in 3 years?

Native Look And Feel Myth

Considering Xamarin.Forms uses the native controls for each platform, I do tend to wonder what people are thinking when they refer to this. I assume it means that navigation or other native gestures aren’t as well supported on a cross-platform application. And this is certainly true.  But the majority of the app can look native on each platform, using the same UI code. The only recommendation I would make here, is to remove the native Toolbar and build your own. It’s far too hard to configure for cross-platform, in my opinion. Then add or disable gestures on each platform as appropriate.

I have seen developer’s complain it takes too long to write custom renderers to make tiny modifications to the UI. Yes, it is disproportionately a lot of time for the result, but didn’t you just save days or more of time only having to write the UI once?

Only for Line Of Business Apps Myth

This was actually started by Xamarin, though while I can not confirm this, I am pretty sure they only mentioned this after people started pushing the boundaries of Xamarin.Forms. In the early days, due to such a limited feature set and bad performance, I think it was easier for Xamarin to say, it’s only meant for Line of Business Apps, than to try and address the incredible amount of issues and insults being flung their way. It sometimes got a little nasty back then, and I always did think Xamarin got unfairly treated in a lot of exchanges. But I had issues, and I was only developing Line of Business applications, so the defense didn’t really hold up.

Thankfully, they now publicly state, it’s not just for Line of Business Apps anymore, coming directly from Miguel’s mouth. If you hear this myth around, don’t buy into it. Xamarin.Forms has expanded into almost everything, including HoloLens and games. It is no longer just for Line of Business Apps.

Should I Still Develop Traditional Xamarin Apps?

If you have a large investment in existing Native Xamarin Apps, there is no ROI, in converting them to Xamarin.Forms, unless you are about to do an extremely large UI upgrade. Hence existing Native Xamarin Apps, should still be developed as native. But, if you are starting a new Xamarin app, then Xamarin.Forms is the way to go. I have heard developers continue to go with Native, with reasons such as, I want a native UI look, specific to each platform and better performance. But honestly, I don’t see that as a deterrent to Xamarin.Forms anymore. It’s easy enough to convert any specific aspects to get a solid native UI/UX on each platform, and the performance is rarely an issue anymore.

Some developers are still going back to native, or not moving to Forms. It’s up to them, though to me it seems as though its personal preference. As much as I was just staying in ASP.NET WebForms, instead of moving to MVC, even though I knew it was the future, well now it’s not. AngularJS, or React, or flavor of the month JS framework. But my point is, because it was far quicker for me to develop in ASP.NET WebForms, because I knew it so well, I stuck with it. But I have never met someone who started in Xamarin.Forms, then chose to go to Native.

(Side note: I did eventually move on to MVC, then to AngularJS. Couldn’t live in denial forever.)


Xamarin.Forms is not perfect, never will be, but the benefits of Xamarin.Forms are now extensive. Most of the performance and bug’s are ghosts of the past, providing little relevance to today, but still haunting developer’s minds. Xamarin.Forms, will always have a slight performance lag over native, and when I mean slight, I’m mostly talking millisecond’s and indistinguishable to the human eye. However, milliseconds add up in items such as ListViews, and native gestures in platforms can cause issues. But with foresight, they can be easily accommodated.

With Xamarin.Forms, continuing to add greater platform support, I fail to see how developers will want to write a native UI in every platform and then just share the backend code. Xamarin.Forms is going to support a lot of platforms soon, including WPF, GTK#, macOS, Tizen just to name a few. At this point I honestly think Traditional Xamarin is going the way of WinForms. It will always be around in old projects that never seem to go away, but the future lies with Xamarin.Forms.

Xamarin.Forms has now moved into so many things. Its also gone full circle and is coming back to infiltrate Traditional Xamarin, with Embedding. As my final thought, I just want to thank the whole Xamarin team for getting this far. It’s been a long and sometimes painful journey, but I bizarrely look back over it fondly, and appreciate what all this effort and dedication has brought to the .NET community. I look forward to the next 3 years.


  1. NMackay

    Good article Adam.

    It will take time to unblock some of the legacy reputation, also people like to bash Xamarin now simply because they are part of Microsoft.

    I choose Forms to have a code base that would mean skills reuse of other team members.

    Forms was 100% the right choice for the projects I’m working on, the only downside is that the jobs I see are still native not Forms so I’ve restricted my employment opportunities to some degree as companies haven’t woken up to how good Forms apps can be if written correctly.

    1. Adam Pedley

      Yeh, I’ve noticed the job issues around Forms. Forms is certainly expanding, and I’ve been lucky enough to keep on Xamarin Forms jobs for the moment, however larger old school Xamarin companies don’t seem to be budging at the moment. Not sure if they are starting new projects on Traditional Xamarin though, or just continuing development of existing apps.

      But those early day perceptions, continue to hang a cloud over Xamarin Forms.

    2. Andrew

      “It will take time to unblock some of the legacy reputation”

      How much time you think it will take? Xamarin Forms is more than 3 years old I think.

      “people like to bash Xamarin now simply because they are part of Microsoft.”

      Do you have some proofs to prove your statement?

      I’ve been watching mobile development space and I haven’t seen any unfounded bashing of Xamarin Forms. Mobile developers which don’t use Microsoft technologies do not care about Xamarin nor Microsoft, they have several good options: React Native, NativeScript and these are just a few of the relatively new ones. The speed of the apps developed with these compared to Xamarin Forms is (much?) better.

      I suggest let’s not live in a bubble, Microsoft did that for a long time. Unfortunately most of the time when people complain about Xamarin Forms they’re correct. If you developed with Xamarin Forms for long enough, you surely hit many issues. This has nothing to do with a Microsoft vs X fight.

      Xamarin should try to be focused on making Xamarin Forms truly industrial class. Xamarin should reconsider their roadmap and priorities.

      1. NMackay

        I will just say I’m delivering successful production apps with Xamarin forms, one developer supporting two apps that support three platforms with 88-90% code share, shared UI supporting tablet & handets.

        There are issue in Forms but they are been addressed mostly, Nativescript doesn’t impress from what I’ve seen but if you like Javascript (lovely language) there is that approach I guess, I’m not attacking other mobile technologies, you just inferred that in your techy response.

        Forms suffers a little at startup due to doing a lot for you but as adam suggested, a lot of this is more to do with bad developer practices, I’ve been supporting people of the Xamarin Forms forums for over 2 years (probably 300 answers), unfortunately people are sometimes jumping into C#/XAML/MVVM pattern with no experience and that can lead to poor slow apps been developed, it’s not the fault of the technology.

        If Xamarin native works for you….fine, if writing in ObjectiveC & Java is your thing then fine, if it’s Nativescript & Java then fine, the original post if just pointing out that Forms is now becoming a compelling choice for new projects.

        1. Andrew

          So you’re saying again that developer complaints are unfounded, Xamarin Forms is 100% ready for production apps, and it’s just a Javascript vs .NET battle, and it’s just some people coming on Xamarin forums to bash Xamarin Forms…

          “I will just say I’m delivering successful production apps with Xamarin forms, one developer supporting two apps that support three platforms with 88-90% code share, shared UI supporting tablet & handets.”

          I am not sure what “successful” means nor what your apps are so I can make an idea. Most of us can deliver “successful” but very simple apps.
          But it’s not about the complexity of the apps. There are issues in Xamarin Forms related to basic\common features. The Xamarin Forms forum is full of the threads about that.

          I will be clear. I’m not saying Xamarin Forms is horrible. It’s just that I think it’s not fully ready. I wish Xamarin focuses on fixing the common things before anything else.

          1. Adam Pedley

            Hi Andrew. I have 2 questions.

            First was your statement
            ” React Native, NativeScript and these are just a few of the relatively new ones. The speed of the apps developed with these compared to Xamarin Forms is (much?) better.”

            Just wondering if there are benchmarks or something you can refer to? As mentioned in my post, I keep hearing these performance issues but still fail to find any significant issue. Would be great if you could point me in the direction of where these performance issues are.

            Second, “I wish Xamarin focuses on fixing the common things before anything else”

            What are these common things that need fixing. I know it’s continually being improved on, but I’m failing to see any show stoppers.

            Just any examples of show stopping common issues, or of show stopping performance issues, would be great for my reference.

  2. Andrew

    Hi Adam,

    The performance issues are very easy to hit into. If you have more “complex” screens (if you can call that complex) with at least 15-20 common controls(no custom contols or renderers) like Labels, Entry, Button, Grid, ListView which use data-binding, you start seeing the lag when navigating between pages.
    It’s visible with XAML compilation enabled.
    Related to issues with common controls: if you just look to very recent PRs you still see issues with Button control, or transparency property on controls. I sometimes experienced issues with StackLayout not honoring the alignment property correctly, or ScrollView rendering content outside its bounds. I think I saw some of these issues on Bugzilla reported many months back.

    Again, if you watch the forums, you should see this pretty often. At least that’s what it used to be, people might had stopped reporting, except very few occasions, there’s nobody from Xamarin officially responding, which is understandable given the team is very small.

    In regards with speed of apps compared to other platforms: I need to look again, I think I saw some benchmarks, but I do recall demos where apps loaded significantly faster than with Xamarin Forms.

    1. Adam Pedley

      I remember the Transparency and alignment issues, though these were all discovered in pre-releases if I remember correctly, and had easy workarounds. They were fixed before stable releases. I don’t deny there are still many bugs in XF, but they are getting fixed, and none have been show stopping. The only show stopping ones I see are generally regressions, in new pre-release versions. Nothing that is preventing me from releasing an app now.

      As for performance, I’ve had fairly complex list views, then navigated to another page, and didn’t notice any lag. But common causes of potential lag in these scenario’s is doing data loading work, or something, on the UI thread. e.g. you moved to a page with a large listview. Things like cell recycling aren’t turned on by default, to ensure backwards compatibility.

      Getting good performance out of XF is certainly possible, though I will note, it’s generally not tuned by default in some areas.

      1. Andrew

        ” I don’t deny there are still many bugs in XF, but they are getting fixed, and none have been show stopping. ”

        Depends what you mean by “show stopping”. Sure, I can try go in the source code of Xamarin Forms and try to understand all the code in there, and fix the issue. Or, try spend time searching forum, Stackoverflow, blogs to find a workaround.
        But don’t you think sincer these issues refer to common controls, simple functionality, maybe should not exist after years?

        Yes, some of the issues are thankfully getting fixed, but I noted more progress mostly recently, and some of these issues are many months if not years old. I know at least of one such issue, related to Button rendering on Android.

        “But common causes of potential lag in these scenario’s is doing data loading work, or something, on the UI thread. e.g. you moved to a page with a large listview. ”

        No, the data loading work is asynchronous, it is getting data from backend.

        Just one example of actual issues is, there’s a very recent PR from 3 days ago with a bug related applying data-binding:
        I swear I saw this reported on Bugzilla a lot of time ago at least one time.

  3. Andrew

    In same page there there other comments regarding other common features not working.
    And that’s just one page in the forum, and it’s from these days.

    I don’t think all the people there are trolls bashing Microsoft. These are developers which have been using Xamarin Forms extensively. Xamarin should listen to them more carefully.

    1. Adam Pedley

      The amount of people getting angry over Xamarin Forms is nothing new, and I have seen or talked to a number of them. I have had my frustrations in the early years, but these days, even when people currently complain about confirmed bugs that they haven’t fixed, its normally not a life or death sentence for the app, a simple work around exists. If it was a large bug, that affected many developers and prevented many apps from production, they get it fixed normally within the day.

      No library is perfect, and XF was previously far less than perfect. But I don’t want to diverge into this discussion. This post was just about XF UI taking over native Xamarin UI. The discussion about which framework is best, is a whole can of worms I don’t want to open right now 🙂

      1. Andrew

        One example of a forum page I was referring earlier where other people are complaining about issues with common controls is this one:

        “No library is perfect, and XF was previously far less than perfect.”.

        OK, it’s just some developers with intention to bash Microsoft 🙂

        I spent an hour writing here about practical examples and even giving links to examples. You’re saying it’s just me, there’s always a workaround and it’s fine.

        “This post was just about XF UI taking over native Xamarin UI. The discussion about which framework is best, is a whole can of worms I don’t want to open right now ”

        I didn’t start this discussion.

  4. Andrew

    For the sake of conversation, could you please approve the comments which require it?
    I think it’s needed because they contain links.

    1. Adam Pedley

      Hi Andrew.

      Comments with links are blocked from the site. It’s actually because it cuts out all the SPAM, not because of any other reason. Sooo much SPAM all the time.

      I agree with quite a number of points you made, and I know XF has many issues, no XF dev is going to disagree there. Even though its an interesting discussion and we both have plenty more to say, I just wanted to cut short this side conversation to remain on topic for others who may comment.

      I know you didn’t start the discussion, and I also happily chatted along, nothing was wrong with the discussion, it just got further off track than I was expecting.


  5. MSicc

    Very well written, and I couldn’t agree more. I got first in touch with Xamarin Forms when I was writing an internal cross platform app for my former employer. It was about that time when Xamarin Forms came up, I already had the Android App ready with Xamarin Native. I then decided to work on the iOS app as a separate Xamarin Forms project. The plan was to convert the Android app to a XF app as well. It never came to that point because I left the company for my current job, and I heard that the app no longer is used internally in favor of a mobile web page. Kind of frustrating, but I do not have to care any longer. All my current projects are Xamarin Forms, and I have no intention to go native even if I only use one of the platforms (coming from a deep XAML background as a Windows Phone developer).

    On a side note, your blog is an enjoyable knowledge source 🙂

    1. Adam Pedley

      Thanks Marco. I didn’t come from a strong XAML background, but certainly enjoy using it. It’s a little verbose, but no language is perfect 🙂

  6. Jesse Liberty

    Thanks Adam,

    Since I couldn’t agree more, I enjoyed your article. A couple year’s back, I did a blog post “If I were Miguel” saying that I’d put most of my effort into Xamarin.Forms — so I take personal responsibility for the growth and improvement (you’re welcome) 🙂

    I’m now convinced that any new project should be started in Xamarin.Forms and that tweaking with effects and native controls will fix 99% of the issues that arise.

    Now, if I can just get another contract

    1. Adam Pedley

      Thanks Jesse. We all know they read our blogs and adjust accordingly 🙂

      Good luck on your contract search, trying to find one myself at the moment too.

  7. Steve Foxover

    I like Xamarin forms. I love using Visual Studio 2017! But I do wish Microsoft could put some more $$$ into Xamarin dev. The Xamarin Live player could be a really great way to develop but right now I cannot get it to work with Google maps. I also use React-Native and its version of live player, “Expo” is awesome. I have been testing the same UI controls with a Google map, highlighted circle, address to location to reload the map etc on both platforms. At this time React-Native is a lot easier to use with Expo live player than any of the Xamarin tools. I like C# better than Javascript but I think Xamarin will need to play catch up for a while.

    1. Adam Pedley

      Xamarin do seem to be a little stretched in tool development, but I am hoping that MS acquisition will start showing some good results this year.

      1. Yuri

        Before acquisition we were able at least to get some support. I was sending emails reporting bugs and getting some answers. Now, when support is Microsoft… Well, we all know how well Microsoft supports small customers.

  8. My Helper

    Thanks Adam.

    Not just yet. We need to wait at least a couple more years (at least one year seeing the current release cadence) to be confident and to start a new project with Xamarin.Forms.

    A few weeks ago I have started a new project but with Xamarin.Native.
    I am from a XAML background (WPF & UWP) and loves it, but still I did not choose Xamarin.Forms because I see, the startup time is still noticeably high, it still misses some of the controls (ex: Carousel View, though there is a control – leaving the official one which was in beta forever -, by Alex – which I hope to be part of Xamarin core soon – it still needs a lot of improvement especially on UWP – yep, I create apps for UWP as well).

    Yes, we can fill the gap with custom renderers etc. I was a little scared this time to start the project with XF, given my client repeated the word “performance! performance!” multiple times.

    However, I encourage everyone to start with XF, and help the product grow ( and I will do the same with my other projects)

    I believe for at least another 2-5 years, we still need to stick with Xamarin.Native for highly polished apps or at least Xamarin should remove its official statements on “when to use XF or Native” found under “”.

    I wish to see XF to grow drastically in the coming years and I am happy to see more adoption rates recently!

    1. Adam Pedley

      Reminds me a bit of the early days of WPF, over WinForms. Lacking controls and some performance but soon becoming the preferred way.

      Maybe I’m a bit eager, but unless it’s heavily relying on customization at a platform level, I always start in XF. 🙂

      1. My Helper

        Yeah. Agree. I remember it was hard to leave win forms on those days.
        So here, I actually entered in to the Xamarin world, with Xamarin.Forms and my most of the apps are on XF. I have comparatively less experience in Xamarin.Native. In fact it would be a good idea to know & have experience as to how Xamarin.Native works under the hood, this helps while creating the custom renderers etc even though you are on XF or your long term plan is to go with XF. Agree?

        Thank you for your response!

          1. Jesse Liberty

            I find that works to a degree, but there is native UI magic I’m not quite getting. Time to read more (and more, and more).

  9. Matt

    There are different use cases to use traditional vs Forms. If you’re doing a lot of hardware specific activities, such as bluetooth communication, tradtional is much easier to implement. Sure, the extra abstraction provided by Forms is great, but can be severely limiting.

    For me, considering how backwards and clunky Xaml is, is reason enough for me to shy away from it unless I have to use it. Even Android’s native xml based design markup is far superior and easier to understand out of the box, and it sucks too…

    1. Adam Pedley

      If you were using Forms or Native, you would be doing bluetooth at a platform specific level anyway. Forms, is just for the UI.

      Every language has it’s issues, but I have found XF Xaml to be great. It’s just bugs in the framework that cause me an issue every now and again.

      1. Jesse Liberty

        Those of us who cut our teeth on XAML, especially in Silverlight, love XAML and have no problems writing an entire UI in XAML. But coming to it cold can be difficult. I’d really like to see a drag and drop UI designer; ideally, one that supports design-time data and, to really extend my wish list, animation. Seems to me we had that in Silverlight, but you know how memory gets when you are geriatric 🙂

        1. Rodrigo Díaz Concha

          I’d like to see a dynamic, fully-capable designer like the one we’ve had for Silverlight and Blend. I love to write XAML by hand and I do it all the time, but XAML language could be a little bit scary for those who are new in the platform.

  10. Ram

    Yes, most of the enterprise customers are depending are going with Native route only because in forms there are limitations in terms of UI as well as calling the platform dependent features.

    1. Rodrigo Díaz Concha

      I truly believe is totally the opposite. Businesses and enterprises are creating Xamarin.Forms applications because it allows them to have results faster than with native.

      In the other hand, would you be so kind as to detail what are those limitations you’re referring to? My experience is way different than yours.


  11. Ahmad ElMadi

    Great article , although I do not know how do you guys find memory leaks problems , like how would you know that there is such a problem that need to be solved ? is it that the app gets slower with time ? or some other stuff ?

    I read quickly through the comments so i would like to give my opinion about it based on these comments .

    I think when it comes to Jobs and requiring Xamarin.Native over Xamarin.Forms, I think there are two problems. The first one is selling the idea of Xamarin.Forms I think usually developers are a bit scared to stand for what they think in general just not to lose the customers and would not try harder to change their mind for that. Some developers who knows Xamarin.Forms too well would know it’s limitation and probably would get scared to confront the customers (or their boss) about them and forgetting that with the time of the development , most of these limitations would be addressed plus there are always work around .

    The second reason, and more important one, is that probably at the customer’s side there is a guy who is already Xamarin.Classic person and does not believe in Xamarin.Forms, and usually you do not have an access to that person who some how conviced the recruiter or your contact at the customer’s side.

    One of the big issues in Xamarin.Forms, if not the biggest, is the lack of documentation , they had a super nice start when they were showing different pages and controls types and how would you go deep into implementing them in different difficulty levels.
    But targetting a bit advanced topic I believe they are doing a very bad job, and these advanced topics are stuff that every Xamarin.Forms developer encounter, the most famous one is CustomRenderers. There are much more in the mobile apps world than an extended label or a button with an image. Many questions are hard to find an answer regarding basics when it comes to custom renderers. like What is an element and what is the controller ?
    What does ExportRenderer do actually ? why do we need it ? If I have to add something from the resources how can I do it ?
    This lack of documentations makes people spend a lot of time to understand how things works in CustomRenderers or just to copy and paste some other’s work without understand it which is the worst feeling ever.

    Having blogs like this or Montemagno’s are super great to make us understanding what is going on. but to be honest that is not the bloggers’ job to do so , a big enterprise like microsoft should be ashamed of having bloggers doing their job.

    Lack of tools and especially the designer is a big disadvantage, and having tools which only works on hello world level is not a solution. I do not see a clear roadmap how are they going to use it . Gorilla Player was the best thing happend regarding this problem , but it never leaved the Beta and I do not think it will soon.
    Xamarin.Forms Previewer was supposed to be a good solution but again it rarely works and ever more rarly continue working after some time.
    Now we have Xamarin Live player, which is also a brilliant Idea but I never managed to make it work with me. So I cannot see their roadmap regarding this issue.

    I think this comment is long enough so I will stop at this point now 🙂

    P.S I predict that Xamarin.Forms 5 will be L.e.g.e.n.d.a.r.y

  12. Alex

    I have terrible experience with the Xamarin Forms application. The thin place are complicated list views, which lags too much and cause to terrible user experience.

    1. Adam Pedley

      Ensure you have RecycleElement set on your ListView, ensure any images are the correct size, that is being displayed, and flatten your view hierarchy as much as possible.

      If all of those things are done, the ListView is very smooth, even under many elements.