Xamarin Platform Reviews

We use the Xamarin Platform since we have a .NET team that is familiar with .NET, and we appreciate the idea of shared code between platforms. We still use MVVM architecture, so we have loads of shared code in view models and services, which are all shared between our apps.

The native features and Xamarin Essentials package are highly valuable to us. However, we struggle with support for third-party libraries in .NET MAUI, particularly with Firebase, including messaging, analytics, and Crashlytics. This has led us to create our own custom bindings. The concept of shared code between platforms remains valuable, enabling us to maintain a good architecture.

The primary area for improvement is the support for third-party libraries, especially for major providers like Microsoft and Google. The lack of robust documentation and support for third-party bindings is a significant hurdle. There was a transition from Xamarin Forms to .NET MAUI, which led to a loss of available libraries. Better documentation would greatly help developers to create their own bindings.

I have been using Xamarin Platform since its beginning for over ten years.

The stability of Xamarin Platform is rated as a five out of ten. The challenges with stability arise mostly when using Visual Studio Code, where debugging can be inconsistent, with issues often depending on the day.

The architecture allows us to scale the app effectively in terms of scalability. 

However, integrating third-party libraries presents challenges since they require us to create our own bindings often. I rate the scalability at a five out of ten.

The general documentation is good, however, when I face issues, there is no direct way to reach out to Microsoft's support for assistance. Queries posted in forums often don't receive responses.

Neutral

The setup process has become more complex with changes, like the move from Visual Studio for Mac to Visual Studio Code with plugins. Most team members find it challenging to build both Xamarin Forms and MAUI concurrently.

Xamarin Platform is free, and we use an Azure subscription at a relatively low cost for our builds. It offers a good value for money, although it requires time to make it work effectively.

We considered React Native, and during a full redesign, we might opt for a different platform. Aviva, a previous employer, chose React Native over transitioning Xamarin Forms to .NET MAUI.

While I recommend Xamarin Platform, I suggest checking the library support needed for first-party libraries to avoid future challenges. 

I rate the overall solution a six out of ten.

Xamarin Platform is being used for building applications. For example, shopping and e-commerce applications.

The most valuable feature of the Xamarin Platform is the deployment.

Xamarin Platform can improve if there was a virtual test environment so we did not have to have a Mac system for the iOS testing. At this time You must have a Mac to deploy or generate IBA profiles. 

I have been using the Xamarin Platform for approximately six years.

Xamarin Platform is a stable solution. I have published six to seven applications on the Apple Store and they are stable.

The scalability of the Xamarin Platform is good and it updates often.

The support of the Xamarin Platform is good. 

If you start from the beginning and face problems Microsoft support will find a solution. You will be placed in the queue for support from Microsoft, and depending on the issue the time for the response can vary. For example, if the question is the first time it has been asked or has occurred, it could take longer, but if someone has already found the solution previously, it could be a faster response.

Xamarin Platform deployment is very good, it is simple. You must have a virtual machine on your system for the Xamarin Platform to work. The full deployment takes a few days at the most.

It's reducing the cost and time to deploy and deliver your applications to different customers. You can deploy it on Android and iOS, which includes mobile devices and desktops.

Xamarin Platform

The price of the Xamarin Platform is not expensive. However, the price of the solution depends on the application that is made. For example, if you have small applications, it's different from large or enterprise applications.

The cost for us on average is $2,000 to $3,000 for all the projects. This involves starting from scratch until we deploy and package them to the Google Store or Play Store for publishing.

I would advise others to use the Xamarin Platform because it's the technology that is most stable in the market. There is always support from Microsoft and it is updated often.

I rate Xamarin Platform an eight out of ten.

We use this solution mainly for mobile app development.

In the App Center we can not only deploy our apps, but we can also carry out user analysis; which page particular users have visited, whether the app has crashed, and what the root cause of that crash might have been, so that we can fix the issue.  This functionality allows us to provide a better user experience.

This solution is a cross-form technology, meaning that we don't have to create separate code to deploy apps across different platforms. 

We also find this solution to be simple to use, with a very user-friendly environment.

We have noticed that there have been stability-based performance issues with this product, which need to be improved.

We would also like the notification feature that was available with previous versions, to be included again.

We have been using this solution for six years.

The stability of this solution has previously been an issue, and requires constant updates to maintain.

This is a scalable solution, but it requires some prior training to carry out upgrades effectively.

The support for this solution is good. There are multiple ways to resolve issues, including a Facebook group that has been set up by the provider.

The initial setup of this solution was very straightforward, and the deployment only took 10 minutes to carry out.

This is an open-source solution, but there is a subscription charge to use the App Center of around $100.

I would rate this solution a seven out of ten.

We use the Xamarin Platform for developing applications for businesses. I've worked and used the solution for property management companies, and the medical and education sector.  We consume APIs and distribute them within app stores.

The most valuable features of the Xamarin Platform are that it has cross-platform development, one code base serves a purpose on both, and the grid layout is a lifesaver.

Xamarin Platform can improve by making the enterprise documentation better. There's a lot of basic documentation of how to do many of the functions of the solution, but there's not much enterprise-level documentation.

I have been using the Xamarin Platform for approximately eight years.

The stability of the Xamarin Platform could improve.

Xamarin Platform is scalable.

I am the only one using this solution in my company.

Xamarin Platform could improve the support. Sometimes they're responsive, sometimes they're not.

I rate the support from Xamarin Platform a three out of five.

Neutral

The initial setup of the Xamarin Platform is straightforward. If you want a simple debug deployment it is simple, you only need to press play.

I manage all the way from design, testing, and deployment in the Xamarin Platform. Additionally, we have a web team.

If you are making applications with the Xamarin Platform and they make money then this solution will have a good ROI. However, if you are making applications that are not making money then it will not have a good ROI.

I evaluated other solutions, such as React, before choosing the Xamarin Platform. I'm a .NET developer and the Xamarin Platform was easy to use for me and this is why I choose it.

My advice to others is to look into tutorials, such as on YouTube. There are a lot of resources on YouTube. Additionally, there is a lot of documentation within Microsoft that's good.

I rate Xamarin Platform an eight out of ten.

Xamarin Platform is used for base unit testing and the creation of new projects. 

The solution lets us apply the application tools for automation IDs, so we can test our unique testing. We can check step by step the automation ID by the codes or controls and all the functionality based. 

Xamarin Platform enables you to use a single code language. This is beneficial for Android, iOS, and Windows platforms, so they can be developed over application or built over application. 

You can create applications like MarketWatch, trading, business development, commerce, gaming, and also e-commerce applications using Xamarin.Forms.

With Xamarin Platform, you can use business levels of the applications such as billing, counter billing, barcode scanner, and payment gateway applications.

Xamarin Platform is missing the code renderer, like a model view controller where you can design your code and then pass it while in preview model. Having this would provide better performance.

I have been using Xamarin Platform for five years. 

Version 5 is the most stable version. The latest version has some bugs in the test version.

The initial setup of Xamarin Platform is easy. Once you have created and initialized your project in Visual Studio, you can create the Xamarin.Forms platform project.

The instructions are step-by-step and easy to follow.

Deployment is completed in minutes. You can find the rest of your devices and run and click on your virtual devices within minutes.

Xamarin Platform is open-source, so it is free to use.

I have evaluated Syncfusion. Most of the community users, including software engineers, use Syncfusion. The Syncfusion controls provide battery efficient controls, like the panel control and some entry controls. For some of these, you can customize your entry using the custom renderer. Syncfusion provides a free account for the community version.

I would recommend that anyone that is considering implementing Xamarin into their organization first learn all about the product. You can learn directly via Microsoft videos. After, you can learn about the languages Xamarin uses. 

Once you have developed your applications by yourself, and you have learned about the fundamental of Xamarin.Forms, then you can start the practicalities of a test project. Then you can start your project, but it takes some time to learn.

Overall, I would rate Xamarin Platform a nine out of ten.

We use Xamarin almost exclusively for development of native mobile applications, even when single platform. The development hardware that we use are MacBook Pros with 16GB RAM and min 500GB SSDs. We run Windows 10 in a Boot Camp partition and virtualized using parallels. We have Xcode installed on the iOS partition and Visual Studio 2017 installed on both Windows and Mac partitions, along with Android SDK and NDK.

We use Xamarin.Android and Xamarin.iOS for apps with a complex UI, and use Xamarin.Forms where applicable.

It has significantly reduced the skill barrier for development and testers. Our company is mostly a Microsoft stack house, so most developers either use, or are familiar with, C# and .NET. Removing the need to become proficient in two other languages, makes adoption easier. Though it should be noted that developers still have to become familiar/proficient with the iOS and Android SDKs and the lifecycles of the native apps.

The ability to reuse significant amounts of code between platforms, have a single code repository, and a single development team for all platforms has massive advantages. It significantly reduces development and test costs, and ensures that there is synergy between the platforms on product features and user experience. However, the most important impact is the reduction in product lifecycle costs.

It allows the development of truly native applications in C# using the power of .NET framework and Visual Studio.

Xamarin allows the same development and build environment to be used for all platforms and code to be controlled in a single code repository. Shared logic, such as business logic and models, can be shared between the platforms, which significantly reduces development, test, and maintenance efforts. Typically, this leads to around 75-80% code reuse between the platforms. If Xamarin.Forms can be used, then this reuse typically rises to around 95%.

Xamarin also leverages the full power of the .NET Framework, including things like lambdas, LINQ, properties, bindings, commands, etc. Lastly, it uses the Visual Studio IDE, by far the most powerful and complete IDE available, making development and maintenance much easier.

The Xamarin SDK provides C# bindings to all native iOS and Android SDK APIs, as well as access to the .NET framework and builds to a native package. The Xamarin Mono run time runs a .NET CSR alongside the native run time with a bridge between them, and handles memory management and garbage collection.

App behavior is completely native and performance is near native (depending on the app architecture, but can be even faster than native if the business logic is computationally intensive). App size and memory footprint is slightly larger than native, due to the need for the inclusion of the .NET and Xamarin libraries. In a debug build, this can be significant. However, in release mode, the build process uses a rigorous linking process which removed most of the unused classes and methods from the managed DLLs. As a result, the average app size increases in a release build by only 5 to 6MB.

The most common issues involved are with the IDE and build process. The worst build issue concerns are the caching process MSBuild uses to reduce the build time. It is unnecessarily complex (internally) and will sometimes leave cached files which should have been removed, even when a full solution clean is performed. The work around involves closing the solution and deleting some project folders. Occasionally, IntelliSense loses sync with the code and provides visual error indicators when no error exists.

Xamarin.Forms does have some short comings, especially surrounding performance. Launch time on Android is a particular issue because Xamarin.Forms loads all the external assemblies during initialization. Support for lazy loading or merging of assembles would significantly reduce this, but Microsoft is still committed to a solution. Support of platform specific behavior could also still be improved. However, I believe strongly that Xamarin.Forms is the future of cross-platform native mobile development.

I have been using Xamarin for about seven years, since before it was Xamarin (it used to be MonoTouch and MonoDroid).

We use the solution for inventory management in our warehouse and also for unbound deliveries.

The solution is easy to understand and has banking integrated. The shorter development time, the bugging and as well as availability of a lot of documentation on the web. Also the native integration is easy.

The monitoring of the remote devices is not good as it should be extended along. It would be useful if the log is more integrated with the central console. I am not sure it can be accessed but it would be better.

I have been using the solution for six to seven months.

It is a stable solution.

It is a scalable solution. There are four to five users using the solution. Some are in the US, some in Europe and some in Spain.

We have not used the technical support as there is a lot of information on the web.

The initial setup was easy. We used the MDM for the deployment as it can be deployed to remote devices. The deployment took two days but the problem was after that for fixing and backing. The maintenance becomes difficult because there is a problem with the log. If there would be a better log that would be transmitted to a central console would be better because we have to get the log from the remote device and analyse what happened

I think the solution is free.

I recommend other users to use it, like the native integration or native development or native features. We use the SAP so they have to consider which kind of integration they should adapt to with SAP. I rate the overall solution a nine out of ten.

I used this solution for three years.

I am not using this solution anymore, but I had Visual Studio and Xamarin installed — we were using components of Xamarin.

We were trying to integrate some PSPDFKit functionality. We wanted to open up a PDF document to the last page that the person opened it. If it was a five-page document and they opened it on page two and then when they closed it, they wanted it to open back up to the page where they left off. They were trying to get the PDF to be sticky.

The product owners that were looking at it liked the functionality. There was a competing product library called PSPDFKit. They wanted to get rid of that because it costs a lot of money; however, they wanted the functionality that the PSPDFKit had, inside Xamarin. There were some issues with it that they were trying to resolve.

When they put their ticket in, Microsoft pointed to Xamarin and Xamarin pointed at Microsoft, to say who's going to fix it. That's where it got left off. Xamarin was never able to utilize that module for the PDF. They had to keep the PSPDFKit software, that's the current state. 

The software itself was pretty good. The problem that I faced was that the communication, the roles, and the responsibilities, weren't defined between Microsoft and Xamarin, that's really where the problem was in my opinion. Nobody was taking ownership of that. 

Let's say you have two platforms on-prem. If you're an iPad user, you want the look and feel of the iPad; if you are a Surface Pro user, you want the look and feel of the Surface Pro. What I feel is of the utmost importance in regards to Xamarin, is to make sure that when you do something, whatever the object is, you get the object that the iPad user expects. Conversely, if you're a Surface Pro user, you get the object that the Surface Pro user expects.

I was in favor of it, it had the capabilities. I was impressed by the way they were thinking of moving it forward, scalability-wise.

The developer activity was complex, but it was understandable. From my perspective, I wanted to minimize the number of software vendors we were working with, and consolidate where features were overlapping. The reason I was trying to do that was to try and save the government some money. I was thinking I was still paying X dollars for one contract for three years, and Y dollars for another contract, and the features were all the same — what's the use of paying for both?

I believe the initial implementation took two years. They developed a working product that was in production. Xamarin was included in that initial design.

They had good documentation regarding implementation, but I understand it was evolving and integrating into Visual Studio.

When someone's building something, they want the capability to do so across the platform; initially, there was a goal to build something for iOS, something for Windows, and something for Android. The first thing they dropped was the Android approach. They ended up keeping the iPad and Windows. You write the code once and it generates in both, or in multiple outputs. 

In our situation, we were supporting it on the iPad — 95% of the people used one. A very select few people used Microsoft Surface. It's a tremendous effort to keep both going, although that's the whole purpose of having Xamarin.

It's a great concept. I think it worked well. The concept of doing it is still not perfect. When we generated some code on the iPad, we would get fewer bugs, and with Surface Pro, we would get more bugs.

The same code was pushing a bug on Surface Pro, but not on the iPad. That's basically a fact of maturity over their capabilities. From a business point of view, it didn't make sense for the use case that we had — it was a huge cost for a few users. In many situations, Xamarin has a purpose. There are good reasons to build it once and have it work on both platforms.

Not from a technical point of view, but from the business side, if I was consulting to a large government organization and looking at the cost-effectiveness, I would suggest they have iPads or Surface Pros and give them to their public users — make them decide upfront instead of going down both paths, doubling the paths.

On the market, compared to everyone else, they're the top solution. They're the best solution out there that I could see. On a scale from one to ten, I would give Xamarin Platform a rating of nine. If they become bug-free, I would give them a rating of ten.