Xamarin Platform Reviews

The strongest use case for this solution is developing cross-platform mobile apps. Most people are building both Android and iOS, and Xamarin lets you reduce your development efforts and build it from a single code base. You can build for Windows and Mac from it also, but most people are using it to build mobile apps.

Xamarin.Forms is a framework that's coupled with the Xamarin platform, and I think one of the biggest productivity gains is that you can build a single UI using Xamarin.Forms and it runs on both platforms. Plus, it gives you the ability to use C-Sharp, which is a very mature, robust language. The combination of forms for cross-platform UI and C-Sharp for the programming language are my two favorite features.

The solution struggles a little bit with binding libraries. If you want to use something like Google Maps or a third-party component that's been built for Android or iOS but isn't part of the actual Android or iOS platform, you have to build these things called binding libraries. It's a tedious process and the tooling doesn't do a lot to help you with it. The really common libraries usually have bindings already built that you can use, but if you get stuck having to build binding libraries, it's a lot of work.

I'm a Mac user and I'm not a huge fan of the Visual Studio for Mac because it's not as strong of a tool as the Visual Studio for Windows, and you don't have the same features on both. That's why I have to resort to a different IDE. I generally work in JetBrains Rider because it's a much better IDE for Mac. The IDE support on Mac lags, but they do have a new version of Visual Studio out, so I can't say I've given it a fair chance yet.

I have been using this solution for about ten years.

I think the stability is slightly stronger when building iOS apps. When you build an iOS app, there's nothing that is really restrictive, so you should be able to achieve the same type of performance, look, feel, and quality of using Swift and all the native iOS stuff.

The Android apps run pretty well, too. I noticed a little bit of a performance hit on the Android side, but that's because there's some pretty complicated architecture stuff. Overall, I would say you can build very high quality apps with the solution.

The scalability is more based on your backend than Xamarin itself, but there are no real restrictions. You can add developers to the team and there's no restrictions with Xamarin that you wouldn't encounter with any other mobile development platform.

I'm a contractor, and my last customer had five developers using the solution. 
I heard about one mobile team in Denver at Charter Communications that had 25 people on it, but that's a lot. I would say most teams and companies that I've worked with have between two and six developers using the solution.

This is a Microsoft product and you go through the same channels for tech support that you do for any other Microsoft products. I would say they're pretty good at getting back to us. Parts of Xamarin are maintained by an open source team, so that's always a challenge as to what responses you sometimes get from them. 

I would say they're as good as any other solution on support. I almost always find solutions on Stack Overflow before I hear back from them, because there's a pretty big community there. I did a lot of work at Cinemark and we had two to three million users a month and I've never run into anything that we weren't able to solve pretty quickly, within a day or so.

On a scale of one to five, with one being bad and five being excellent, I would rate their technical support team as a four.

The setup is moderately complex. In general, I don't think development for a nice mobile is very simple, but I wouldn't say that it's super complex. .Net itself is a pretty productive programming language, so it helps you with a lot of things, but there's definitely a learning curve to get up to speed on it.

It takes a day to get the solution configured on your workstation, if you know what you're doing. The reason I say that is because you have to install the Android SDK, the iOS SDK, and then you have to install Xamarin on top of all that. All of them have to be installed and configured correctly for everything to work, so there's a lot of dependencies. I think it probably takes at least a day to get a workstation set up and configured, and then you're off and running. 

In regards to DevOps and all that, in most places I've worked, you have developers with their individual machines configured. Then when you merge your code into a git repository, the builds are automatically done and either sift to the testing team or are uploaded to the app stores, depending on where you are in the project. That might take a week or so to get going, but just as an individual developer, it takes about a day.

There's no licensing cost for Xamarin. Like the rest of .Net, it's open source, but there is a licensing cost if you want to use the IDE. There's a number of different development environments you can use. 

You can use just traditional Visual Studio. I license Visual Studio Professional. It's about a thousand dollars a year and Xamarin comes with it. 

I also license another IDE, which I could run independently. That one is called JetBrains Rider, and it's only about $200 a year. You could do all of your Xamarin development with that if you didn't care to license the other stuff. 

The actual platform itself technically doesn't require anything. If you wanted to download Visual Studio Code, which is a free IDE, and figure out all the plugins to get everything to build and work the way you wanted, you could actually technically develop for free, but I don't think many people do that.

I would tell people considering this solution that there's a lot of training available. There's a lot of documentation on Microsoft's website and apps for getting started. Places like Pluralsight also have a lot of video training. I would recommend downloading the IDE and going through some of the Microsoft tutorials initially, and then jumping into Pluralsight to find some deeper training.

I would rate this solution pretty high. I would give it a nine out of ten. I've never had the Xamarin platform cause a project to fail. In other words, I've been successful in every project where we've tried to apply it and, except for external problems with the requirements or things like that, I've never run into any technical problem that I couldn't solve with Xamarin. The apps that you can produce can be very professional depending on how much time you put in and you can dramatically reduce the amount of code you have to write to support two platforms.

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.

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.

I use Xamarin Platform to design application UIs, integrate APIs, and create special features.

Xamarin Platform's best features are its single codebase, the support from Microsoft, and the free libraries.

Xamarin Platform's performance base could be improved. In the next release, Xamarin Platform should include gradients and a looping feature in its path

I've been working with Xamarin Platform for over two years.

Xamarin Platform is stable.

Xamarin Platform is scalable.

Microsoft's support is one of Xamarin Platform's best features.

The initial setup was straightforward.

Xamarin Platform is open-source, but there are fees for deployment, the API Store and Play Store, and using third-party libraries.

I would rate Xamarin Platform eight out of ten.

I use Xamarin.Forms to develop mobile applications, which basically have the same functionality and cross-platform.

It usually saves time for application development. We write once and the code works everywhere.

In Xamarin.Forms, it is valuable that one and the same code (including UI) work on all platforms. It is very convenient.

They need to take a step towards independence from the UI platform. It takes a lot of time to adapt the native controls.

Everything is fine. There have been difficulties with memory leaks, but usually they are not difficult to fix.

No issues. Everything is fine.

The support is not very good. Bugs remain very long openable.

Earlier, I tried to write code on native technologies, but still liked C# more. 

We switched because it makes cross-platform applications more expedient, faster, and cheaper.

Everything was simple. Besides, on GitHub there are always good examples. Although, you need to understand the native SDK a bit.

Good knowledge

Xamarin is free, or comes with Visual Studio. Therefore, it is very profitable.

I looked at Ionic and other HTML/JS platforms, but I considered this a bad decision. They were too slow and you had more problems with their frameworks than the benefits of their work.

Be sure to look at the lessons from Xamarin University, as well as test projects on GitHub.

We develop Model X for sports and tourism and for Android and iPhone sport.

We have some projects on the sport-level worldwide, not only in Europe. One of our examining apps is the GDPR tool. We want to expand the GDPR tool to mobile apps for local sports and in other non-profit organizations. That's the reason why we want to develop mobile apps in the Xamarin Platform, so we can connect local organizations to sports, tourism, and non-profit organizations. That's our focus.

The Cross Platform is a great asset. We develop and then at the end, we publish other mobile apps to Android and to iPhone platforms. We develop stand-alone apps for Android and the iPhone and then transfer our development to Xamarin because it's much easier.

We need to think about partnering with IBM because there is a need for a big data partner; someone who has machine learning and can help us connect the app to big data.

The stability of this solution is fine.

I have not used tech support too much. In the beginning, we had some issues, but the support resolved the issues quickly.

The initial setup was easy.

Xamarin helped us to develop a cross platform mobile app with less time and resources. 

Managing code is useful using TFS, so a separate code managing software was not required. Authenticating user to app is easy using Azure authentication, which is supported in Xamarin

Provides a wide variety of technical work and some interesting problems to solve. 

Being able to use the .NET framework and platform have me creating applications better than anyone who develops on Windows. 

Being able to use Visual Studio means development gets to use the best IDE currently available.

Xamarin is well-integrated with Visual Studio so it will feel very familiar to you once you start. 

There is limited support for UX widgets. Also, there are compatibility issues between versions of various Xamarin components.

The new go-to-market with Microsoft is different. It will require some adapting.

They are genuine, smart, and action-oriented people across the board!

It saved a lot of time and resources needed to develop a cross platform mobile app.

If you are already heavily invested in the .NET platform and C# development, Xamarin is the quickest way to make native iOS apps.

Their leadership is exceptional at both listening to the customer base and delivering innovative, best-in-class products. A company that takes great care of its people. 

Xamarin has just been bought by Microsoft. What an endorsement!

Our primary use case is to build high performance mobile applications and bring about maximum code sharing between different platforms.

We have a lot of applications, which cater to different types of end users. These have really helped us in creating a connected system, which has enhanced the productivity and usefulness of different products.

• This is close to the native app experience. 
• It brings about good code sharing strategies, which bring down cost and maintenance efforts.

• The android application compilation time needs to be reduced. 
• The deployment package sizes need to be looked into.

We mainly build mobile solutions for enterprises. In most of the cases, it does require a lot of complex domain knowledge and multiple integrations with various internal systems, pretty often legacy ones. 

We decided to work with Xamarin, since it does give us a lot of advantages compared to fully native solutions, which use Java or Swift/Objective-C. First, it allows us to reuse our knowledge of C# and .NET Framework. Next, since .NET and Java are the most common choices for enterprise platforms, it allows us to reuse some parts of business logic without the need to re-write/port them. Then, there is the possibility to apply well-known MVVM patterns to both Android and iOS targeting apps with reuse of up to 70% codebase between platforms, not to mention automated testing possibilities.

Xamarin brought various benefits to our clients. For example, we were able to optimize the service organization for one of our clients. Customers can use now a branded mobile application to submit issues within the customer products. It allows for QR code scanning with error details. It makes it much easier for customers to report issues and for service employees to collect all necessary data, then quickly respond to the customer’s needs.

The possibility to share business domain model-related code between iOS and Android.

It would be great to have some quirks of Xamarin.Forms solved. However, the number of community developed libraries and components are growing rapidly, so this should be another advantage soon. 

Nowadays, it is common to find a problem that you would need to develop from the start since there are no third-party components to reuse.

It does have its drawbacks. From time to time, it is a bit harder to code some specific scenarios compared to the native approach. Since Xamarin is the another layer of abstraction, it also adds its own bugs to the whole process. However, the overall experience is really positive. The benefits listed above are much higher than the costs associated with the overhead needed to work with Xamarin.

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