#react native#xamarin
Hady ElHady
Jun 15, 2022 ⋅ 7 min read

Xamarin vs. React Native

Hady ElHady Marketing @golayer_io | Techie | No-code builder

Recent posts:

7 TUI Libraries For Creating Interactive Terminal Apps

7 TUI libraries for creating interactive terminal apps

When writing applications, a good user interface is just as important as the actual app’s functionality. A good user interface […]

Yashodhan Joshi
Jun 14, 2024 ⋅ 18 min read
Expo Router Adoption Guide Overview Examples And Alternatives

Expo Router adoption guide: Overview, examples, and alternatives

Expo Router provides an excellent file-based routing solution with crucial features such as deep linking and native support.

Marie Starck
Jun 13, 2024 ⋅ 8 min read
Superglue Vs. Hotwire For Modern Frontend Development

Superglue vs. Hotwire for modern frontend development

Explore how Superglue and Hotwire revolutionize frontend development with HTML over the wire, enhancing performance, flexibility, and ease of use.

Frank Joseph
Jun 12, 2024 ⋅ 7 min read
Using Pocketbase To Build A Full Stack Application

Using PocketBase to build a full-stack application

PocketBase is a performant Go-based tool that comes with essential features like user auth, file uploads, access control rules, and more.

Rahul Padalkar
Jun 11, 2024 ⋅ 18 min read
View all posts

17 Replies to "Xamarin vs. React Native"

  1. “The language offers widgets for both iOS and Android, but you have to switch between both manually as it doesn’t have components that automatically adjust their styles depending on the platform you’re running.”

    Actually some of the widgets have a method that is called “adaptive()”. This will provide a platform specific UI for that widget. For instance:

  2. “Continuous integration support: Lacks compatibility with CI tools such as Travis and Jenkins.”

    That’s not true because there’s definitely flutter support in all of the well known CI.

    Flutter provide a rich CLI, where you can do pretty much everything.

    There’s just not enough tutorials on it.

  3. 1 – Search term frequency is a poor metric for popularity; when I am struggling with an environment, my searches go up – when development is comfortable, searches go down.
    2 – “Updates delay” and ” Platform-specific code (maybe)” is going to be an issue with ALL of these platforms.
    3 – Xamarin forms (XAML) applications are 100% code reuse and suitable for most business needs
    4 – Flutter’s “Complete development ecosystem” will not be as complete as the more mature environments.
    5 – Flutter’s “Reliability” because it is a Google product is a questionable statement, as Google has killed off many products shortly after introduction. Flutter could be gone tomorrow.
    6 – Xamarin also has hot-reload, but this is not listed as an advantage.
    7 – Why is React’s may need “Platform-specific code” an advantage, but a disadvantage for Xamarin. Most needs for “Platform-specific code” in Xamarin are handled by Nuget extensions due to the maturity of the product. Meaning they are invisible to the developer.
    8 – Flutter’s use of Dart over Java script and C# is a major disadvantage. Many working programmers are using Java script and C#. Apple’s implementation of Swift was a major blunder — they had to define and redefine it, breaking compatibility, devs had to learn a new (less sucky) language; but at the end of the day C# spec is ECMA open-source -Apple could have saved everybody a ton of headaches by using an established available language.
    9 – Xamarin’s support is extensive through the forum and stack-overflow; MSDN members can actually get dedicated incident support. I wish they would route everything to Stack-overflow as it is a better platform than a forum.

  4. It’s true that recently Flutter has added adaptive constructors to Switch and SwitchListTile. Which is definitely a step towards helping further progress platform-aware widgets within a single codebase. It’s still only just the beginning though but more is expected in the future!

  5. 1st off, thanks for writing this article. Very timely for me. I’m an old timer here (35 years of coding, so far) and want to express my utter dismay with the state of Android programming. I wrote my 1st app in 2012 using Eclipse and Java. It was a bit of learning curve, but not too bad. I didn’t get back into Android until earlier this year. The tools are better (Android Studio)… but Wow, what a mess in terms of languages: Java, Kotlin, Dart (Flutter), Javascript (React), C# (Xamarin), C/C++ (Java NDK), Corona/LUA (?). I agree with jlo 62c’s analysis, especially items 4 & 8. Google is now pushing Kotlin (getting sued by Oracle for Java use?)… but they built Flutter for use with Dart – a whole NEW language!!

    So now, we have to decide: Do I really ‘need’ cross platform (i.e. make the investment to learn DART or strengthen my C#), or do we go with Kotlin, which we believe Google is more likely to support in the future? Maddening. The fact that Google has splintered this Kotlin & Dart (“more options!” if you listen to their marketing dept), gives a bit more strength to the idea of using Xamarin instead.

  6. Hello. A few of the points you made about Xamarin are not true.

    1) “Platform-specific code: You might need to re-write some parts of the UI in your app in native code. That means that you will need some knowledge in native programming languages such as Kotlin or Java for Android, and Swift or Objective-C for iOS.”

    Not true at all. Xamarin has 100% access to Native APIs for iOS and Android and if there’s a library that’s needed in another language, you just create a C# Wrapper/Binding Library to use that feature you want. Absolutely no need for writing native code.

    2) “While all three tools are free, open-source platforms, Xamarin is only free for individuals and small companies.”

    Xamarin is free and open source. You’re confusing Visual Studio licenses and Xamarin which are separate things. I’ve developed Xamarin apps for enterprise clients without paying Xamarin anything.

  7. Dart has been around just as long as Kotlin. They were both introduced in 2011. Frankly, if you develop in C#, you would be effective with Dart in a day. You wouldn’t be learning many new concepts so much as just looking up the syntax for the concepts you already understand. Dart is easier than C# because it doesn’t have as many features. When I develop in either, I increase my skill with the other.

    Dart was selected for Flutter because it has compilation modes and targets that enable its functionality. This was not a mistake, and the benefits are significant. The reason I’m excited about Flutter is precisely the technology mess you mention. I do most of my work in the web space, and the list of technologies there is pretty ridiculous. Dart has made that better for my personal projects, providing a single solution for the gauntlet of technologies and tools surrounding JavaScript development. Now with Flutter, we’re looking at a single framework with a single, easy to learn OO language that can target desktop, mobile and web. I completely sympathize with your exasperation over this mess, but instead of seeing Dart and Flutter as just another piece of that, I see it as a potential solution.

  8. Xamarin hot-reload sucks compared to React native’s and flutter’s reload.
    Only xaml have hot reload any change in the VM or any c# code and you must compile and deploy again.
    Also the unwired deployment is way better in react native with expo:
    As a Xamarin dev for years it hurts but it’s true…

  9. Xamarin (.Forms) dead a long time ago (Even if it’s maintained so hard until now).
    It’s inappropriate that it’s even mentioned here. It shows how not professional this article is.

    Unless it has a serious downside, the important factor is how many third party companies provide SDK for that framework. If you’re not building a toy project, you will have to add many third-party libraries.

    React Native is a clear winner in this factor. It’s very far from others, especially Xamarin.

  10. What world are you living in? Xamarin.Forms is the most widely used product for commercial apps. You ever hear of Guess?

    React Native isn’t anywhere close to Xamarin. Period.

  11. Try TDD and HotReload isn’t a problem. If you’re wiring Xaml and you keep changing code in the ViewModel, you’re doing it wrong

  12. After reading this informative post, I am now sure that I should pick React Native for my next mobile application idea. Thanks for this useful post. However, will it affect the performance of my app or should I opt for native app development? Any suggestions would be of great help.

  13. Hi There:

    I abandoned Xamarin years ago (when it was a paid application) because it was buggy.

    Now, it is buggy but lots less.

    But my main reason to switch back is the use of third party components. The hard part to create a mobile application, its to create the UI. In the case of Xamarin, it’s as easy as to buy a suite, put in the code, duct take with a back code and call it the day. Easy, pretty and functional.

    Instead, if you are programmed native, then you find that there is only a few components around here, and we should do the style by ourselves. And if we do something bad, then it will affect the performance.

    And for React and Flutter, there is nothing. Google gives Material theme but it just tossed it away and the support is quite limited.

    I can spends month building my own components or I can simple buy one.

  14. Can you compare Flutter, React Native and Xamarin? — three of the most popular mobile app cross platform frameworks. We want to consider their structure, tooling, and the kind of applications we can develop with them.

Leave a Reply