Xamarin Platform Reviews

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 have so many applications on Xamarin Platform. We can use Xamarin native Developer, Xamarin.Android or Xamarin.iOS. It is a true native solution, and we can use the cross-platform framework using Xamarin.Forms. There are a lot of times when we have to code or complete beginning steps with the Ionic Framework. We can target the core native platform like Android, iOS, and Mac.

It is great that Microsoft supports many libraries for digital forms and Xamarin. The Xamarin community is big. They respond, and so many developers share their knowledge on the framework, core custom control and details on implementation.

This solution has improved in so many areas, like in .NET MAUI. They have reduced the structure and introduced so many new features. However, Xamarin Platform lacks in app size. When we are developing an app, it is higher compared to other frameworks. The developers are working on the issue, as many people have raised concerns about the app file size. They should introduce a fix on .NET 7.0.

We have been using this solution for about six and a half years. It is deployed on public cloud.

Xamarin Platform was stable initially, but they recently launched MAUI, and there are bugs. This is because it is an initial release of their global release. However, they are working on the bugs and hoping to introduce fixes in .NET 7.0.

It's a scalable product for the enterprise level, and we can use Xamarin Platform because it gives us a native look and feel. We have about three or four projects using Xamarin.Forms, so about ten people use the solution. They are primarily developers.

We've never used technical support because we immediately use GitHub if we find any problems or bugs. They have developers that are responsive to those issues, and if there are any workaround solutions, they work on them. I rate the technical support a nine out of ten.

The setup is very easy, and we can do the setup on Visual Studio. While installing Visual Studio, the modules are similar to the ones on cross-platform. A developer can select a particular model, and it will install everything. After that, we only have to set up the Visual Studio tools.

There is no license, and it is open-sourced. Therefore, there are no hidden fees.

I rate this solution a nine out of ten. I rate it a nine because it is a great framework tool for them to develop mobile apps within .NET., and only minimal XAML knowledge is required. If they don't have the XAML knowledge, the developer can design within C#. In addition, the community in Xamarin Platform is big, and many developers and program managers from Microsoft Azure. They inform of tips and tricks whenever new information is available about Xamarin on YouTube, Twitter, or websites. As a result, all developers contribute to design challenges.

We have so many developer teams for many frameworks and languages. Xamarin Platform is suitable for the developer who knows the C#, .NET framework and is familiar with XAML. They can easily do mobile app development in Xamarin.Forms.

Regarding additional features, they have already introduced MAUI .NET 6.0, and they are upgrading these Xamarin.Forms to MAUI. I think they are supporting Xamarin.Forms next year, and after that, all the applications will move to .NET MAUI. I believe they have already introduced many features in .NET MAUI and are working on other features to introduce in .NET 7.0 and .NET 8.0. Every quarter, the .NET products release new features and fix bugs.

The primary use case at Seamgen for the Xamarin platform is to create forms or data-driven apps that utilize mostly stock UI components and benefit greatly by sharing a common core software layer for data processing and handling.

With the help of Xamarin.Forms, we can effectively realize a cross-platform app with a very small team of 1-2 developers, targeting both iOS and Android platforms.

In a purely native development environment, you would typically find a developer specializing in one of the major platforms. If the objective is to create a mobile experience for more than one platform at the same time, you typically need distinct resources for each platform. Often times they create the same code/logic in different programming languages for each platform. In this scenario, the Xamarin platform can reduce overhead significantly through code-share and reuse. The typical team size for a Xamarin project is significantly reduced compared to purely native projects.

The ability to share a platform-agnostic common core, or business logic, enables a mobile developer to write code for all targeted mobile platforms, independent of the individual developer's specialization in iOS, Android, or Windows. This helps not only during development but also enables easier maintenance of deployed apps, since bug fixes or feature additions can be often made in the platform-agnostic layer.

Xamarin's profiling tools are only available for the highest tier of MSDN subscription and compatibility with platform-native profiling tools is rather lacking. This causes friction when working on performance-related issues.

While working with the Xamarin framework at Seamgen, we do not encounter any major stability issues in the framework itself. However, we do recommend testing any third-party component for fitness, because it is fairly easy to incur stability issues by importing external components or libraries.

Outside of the general issues that come with bigger development teams, the Xamarin framework added no extra overhead.

Before Microsoft acquired Xamarin, the technical support was excellent. The acquisition added some noticeable friction and the transformation period for long-running Xamarin customers to the Microsoft environment wasn't the smoothest.

At Seamgen, we evaluate which framework and platform are the most viable to achieve our client's goals on a per-project basis. We do not default to any one set of tools for everything. We work on many projects where Xamarin is not suitable.

The initial setup is very well documented and there are plenty of resources available to hit the ground running if you are an experienced developer already. For beginners, the entire setup can be overwhelming because it involves setting up development environments for iOS, Android, and Windows at the same time if you want to target all three.

Xamarin is available under several licensing arrangements. Each developer needs one license at least. To access all features, especially the Profiler, you need the highest tier.

We do evaluate other options like PhoneGap, Itanium, React Native, Cordova and the like, not only against the technical requirements of each project but also against the particular requests of our clients.

Compared to alternative cross-platform development frameworks for mobile (i.e. Appcelerator, Cordova, Ionic, React Native, etc.) we consider Xamarin the most viable option in most cases.

We have been using Xamarin for over four years on multiple app projects of varying sizes, complexity, and code-reuse, ranging from fully featured custom UI social networking applications to data-driven forms apps with a maximum degree of codeshare and minimal UI.

Xamarin can sure look like the one hammer that makes every project look like a nail, but it is not. Here at Seamgen, we consider it another tool in our toolbox, suitable to successfully realize our customer's ideas.

Xamarin is a framework for creating mobile applications. It can be deployed on any device for mobile app development. I am a user of this solution. 

This is a Microsoft-supported source platform so the technical support is very good and it's close to native. It's all compiled into related code and at the same time wraps old libraries or native libraries into cross-platform libraries which is great. I do a lot of proof of concepts, and part of the reason I like Xamarin is that I'm familiar with it and know my way around which saves me a lot of time. 

Xamarin is reaching its end of life and they're moving it to .NET MAUI, combining it with other platforms and creating a centralized framework. It's a big change that's affecting a lot of the good features and something they could have done in a more user-friendly way.

I've been using this solution for six years. 

I have had times when I ran into bugs which can take some time to sort out. I found out the hard way that these bugs can often take quite some time to resolve and that's obviously not ideal.

The solution is scalable, we can vertically build on top of it.

Customer support is good. 

The deployment is fairly straightforward. Since it's backed by Microsoft, the documentation is expensive. There are MVPs working around the clock to help get you up to speed, so implementation is a breeze. It's not really a problem. In that respect, it's much better than React Native. I've deployed this on my phone. 

Xamarin is open source, so it's free. If you're planning on development within a company, it might require purchasing the commercial version.

Until relatively recently, I used this solution all day, every day, but at this stage it would not be my go-to choice and I'd now prefer Flutter or React Native. If you're starting something new and you have experience with .NET, and are already in the environment of the ecosystem, then I would say that you could potentially use Xamarin. But if you are coming from a JS perspective, then I would recommend Flutter. If you're production ready, go with Flutter or React Native. 

The solution has served me well and I rate it eight out of 10. 

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.

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 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.