- All Categories
- Augmented reality
- Business Intelligence
- Front End & UI Platforms
- IT business
- Java development
- Mobile development
- News and events
- Platforms and frameworks
- Project management
- Software engineering
- Software modernization
- Test automation
- Video and live streaming
- Web design
- Web development
Xamarin. One for All (Part II): Drawbacks
In our first article we’ve examined the main perks of Xamarin. As we’ve written earlier, Xamarin helps businesses to build an app on multiple platforms at one time thus easing us of odd fuss & bother. But, as a rule, each & every thing has the reverse side of the coin and Xamarin is no exception.of its own environment
That’s why *instinctools team decided to examine the dark side of the Moon.
So, here we go:
1. Limited Sharing of Code Outside of Xamarin
Xamarin doesn’t allow to create reusable components or modules outside of its own environment. The code written in Xamarin cannot be used in native or HTML5 apps. This means that any code developed by using Xamarin cannot be shared or reused by using any other tool for iOS or Android.
2. Non Portable .NET Libraries
If you use a PCL core library, you will have problems with finding 3rd party libraries that support it. Some companies that offer .NET libraries to interface with their APIs do not yet offer PCL versions or do not have PCL versions that support Xamarin iOS or Xamarin Android.
3. Portability Woes
While most of the code in our core layers is typically portable, sometimes the structure of the View Model (VM) is created to cater to the View in one platform or another. An iOS or Android developer creating the VM would bias the structure of the data toward one’s platform’s views – and most developers out there, even Xamarin-only developers, have a bias towards iOS or Android. For more complicated apps, this becomes a real issue until more developers become accustomed to making concessions for all platforms involved.
4. More Moving Parts
Xamarin introduces it’s own set of bugs that affect product quality and developer productivity. The problem is not that Xamarin has a bad product, but that adding any large or complex system to the app toolchain comes with problems and bugs that do not exist in native apps.
5. Lean Community
This is something that is not really Xamarin’s fault. However, it matters. When developers are 10 times more likely to find results when surfing the web about an issue, it has a direct influence on productivity. The ecosystem of available support, services, and 3rd party components is and will continue to be, significantly smaller than for native or HTML5 based apps.
In these 2 articles, we’ve tried to describe the main perks & drawbacks of Xamarin. We shouldn’t deny the fact that the ability to re-use code for multiple mobile platforms can be helpful & quite comfortable. For serious businesses, with a major focus on c#, Xamarin is probably the prefered method of development. But one should keep in mind that it’s up to you to decide on which side you’re.
In the end, both Xamarin and native approaches will make your projects shine, but they each have their unique peculiarities that need to be weighed carefully based on project requirements & constraints.