I invite you to see my opinion on this topic and to see the reasons that led me to the development of mobile applications with XAMARIN. As this post is a bit long, I have divided it into two parts.
Here I’ll put you in context with some basic definitions in mobile development. I’ll show you a little of what has happened in recent years with the development of mobile applications, the criticisms and how were my beginnings with this tool. In the next part I’ll expose the pros, cons and paradigms, among other things, related to this tool called Xamarin so that you can have a general knowledge about it. So if there is a need to choose between the tools, you’ll be able to know if Xamarin has what you are looking for.
So, let’s star…
Nowadays we are living a much accelerated technological growth. It’s increasingly necessary to be connected to the information cloud provided by the Internet; technology makes our lives much easier in that sense.
With this growth, paradigms have emerged that the smaller, faster and more functional the technology, better the user experience is; and it’s in this sense where smartphones make sense. Today we are already being able to have our own personal assistant within smartphones. This is just the beginning of what is yet to come.
The truth is that these devices are just hardware. The real magic that has made more than 5 million smartphones in the world are mobile applications. These applications are those that allow users to choose the fastest route to reach their destination through a global map. These are the same as you use to organize your chores, order a pizza, and many other things.
Nowadays it’s deduced that there are more than 26 million mobile applications downloaded through the application stores. This’s normal since 80% of users on the internet connect through mobile devices. But what about those people who make these mobile applications? Well, they’re called mobile application developers and they’re the ones that make all the magic happen.
Previously, when a company was looking for a mobile developer; they were looking a developer to work on a specific platform (Android, iOS or Windows Phone). Today they have more options. Developers have tools that allow them to work for different platforms in the same project.
I’ve seen that there is always a preference for one or another tool for development in general. It’s very common that when you have no knowledge of mobile development, you’re going to search on the internet to try to find references. Maybe you want to choose a certain tool and start in this world of mobile application development. Maybe you don’t feel very happy with the tool you choose and you’re looking for other options. Or maybe you are just looking for information to have a reference about the tools that are currently on the market.
The truth is that most companies that want a mobile application for their business are not interested in the technology, platform or programming language that is used for the development of it. They only focus on fulfilling the desired functions at a competitive cost. However, developers or companies that want to devote to the development of applications have to consider the factors mentioned above.
Now, within the development of mobile applications, we can find different types among which are hybrid, native and generated Apps. Within the development of hybrid or generated applications, there’s multiplatform development. Although I will not delve into these details very much, I will leave you a brief description of each one.
It’s born from the need to offer solutions for each mobile platform. One of the main advantages of this approach is based on the reduction of development time when you want to have a presence in more than one platform and, therefore, the cost reduction as well. Another advantage of this type of development is the ease of maintenance. Maintenance is easier by having a centralized development compared to maintaining several native applications at the same time.
These offer a better user experience (UX) in each platform. To generate a native application for each platform, it’s necessary to use the platform specific programming language. Objective-C or Swift for iOS; Java or Kotlin for Android; and some language based on C with .net technology for Windows Phone.
These are developed with tools that have their own specific programming language. These tools allow you to compile your application to any native platform that supports it. In this section we can see multiplatform development tools such as Telerik’s NativeScript, Microsoft’s XAMARIN, Facebook’s React Native and others.
Years ago when mobile application development had only two sides, hybrid and native apps, there was a controversy against hybrid applications. Currently even these sides are still seen with contempt as the developers of hybrid applications don’t see the sense to program in Java, Swift and C #; or at least it is what it seems.
Of course, this resentment is understandable since at that time hybrid applications or native applications but with other programming languages had certain performance problems.
Here is where everything makes sense
This perception was had because of the first iterations of PhoneGap (tool to make hybrid applications) delivered very bad products in the application stores, which is normal because it was a new product. Unfortunately, past experiences still influence developers. With the great advances we have made over the last few years, things have changed a lot.
Now that we have generated applications, the same conflicts arise as in the previous battle of native and hybrid applications. Pseudo-native applications is the term adopted for the applications generated in its beginnings. These applications generated although they were native didn’t meet certain parameters of efficiency compared to native. The truth is that all the progress these tools have made doesn’t validate these past conflicts and comparisons.
Xamarin and the Critics
According to the research I have done many of the bad reviews, not only for Xamarin but also for other tools, are developers with the following characteristics:
- They base their evidence on bad applications.
- They don’t want to leave their comfort zone.
- Ignorance in not knowing how these development tools work.
- They don’t take into account all the technical and maintenance details of other tools.
Something I’ve seen a lot in the communities is that developers who decide to start the line of learning within the development of mobile applications (without having any knowledge of this, few experienced mostly) always decide to go for the native way, that’s logical because if you want to make a demo for Android to show your family how cool you are and do a search on Google I imagine that JAVA will be your first suggestion displayed on your browser.
In the same way I have seen many developers excited about this topic of native development, and I have also seen how they migrate to different options. In the end, it’s a matter of perception. Of course, companies have another approach based on productivity and that is why cross-platform development it has gained so much popularity in such a short time.
Although it’s true that the number of developers who use a certain tool can influence the popularity of these. It’s obvious that if your environment of developers around you uses a certain type of technology and you want to introduce yourself in that world, I think it’s normal that they try to evangelize you so that you use that technology.
The bad thing is that many developers who use a certain technology, see that technology as if it were the bible and everything that is out of that is wrong. It’s for this reason that there are many fights between developers who use different technologies for software development, they only think about what they use but don’t think about the person in front of them, what is best for them and what can shorten them the process of success in its unfolding. I still see developers that are based on a single opinion without knowing other options, mainly due to the characteristics mentioned above.
XAMARIN has been many criticisms of the supposed competition (as some see, I think they are just different tools for different types of developers). Xamarin has received a great boom within the developer’s communities. You can see this clearly because more and more, little by little, there are more requests from companies that require developers of mobile applications with XAMARIN.
My beginnings with Xamarin
It’s not a secret to anyone that I use XAMARIN for the cross-platform development of mobile applications. In my beginnings when I started working as a mobile developer it was because it was born of a need in the company where I worked. I was the first as a mobile developer, so, they allowed me to choose the tool that I thought it’s going to be the best for me and the company. Obviously after a great analysis and spent hours on the internet looking for references I arrive at XAMARIN.
After having worked for a while with Xamarin and Visual Studio, in 2016 mostly in the communities, there was a certain resentment with the platform as such. Many developers who used other approaches for development of mobile applications ensured that XAMARIN didn’t meet expectations, not to mention the exact words that they said.
So far all this makes sense. Few months after Microsoft announced the integration of Xamarin with Visual Studio; the bugs that the developers had to face were not normal. Many times without even putting your hand to the project, after having debugged several times and everything was fine; when you were going to debug again you had 1,798 errors from nothing. At that time I only lowered my head since there was not much information about these.
Maybe you translate this as “Xamarin the worst tool“. The truth is that it’s not like that. I came from having zero knowledge in mobile application development and without having a mentor or close person with experience; this made it more difficult for me. Tutorials were very basic and so on.
For my luck, I’m very focused on what I do. I had a company that trusted me to release the project that I was working at the time. I never gave up and kept going. After a while and seeing how the developers reacted in the communities; I understood that clean/rebuild was the solution for many of those errors. The magic of XAMARIN in its beginnings.
As developers, we know that things will not always turn out the way we want. When everything went well it was a special feeling that gave me the strength to keep going and overcome obstacles. If you are a developer, I think you understand me. It’s something I can’t explained that simple.
It is almost obvious that new tools can cause all these problems. Luckily, Microsoft always keeps making updates, solving these bugs and adding new features to make life easier for developers. From what was XAMARIN to what it is now there is much difference, things have changed enough; now we have incredible improvements and I know that it will continue to improve. All the tools do it.
That’s all for now, see you in the next part!
[bucket id=”11123″ title=”Thanks for reading”]