Note: I respect Jason Smith and his group at Xamarin immensely. My complaint is not with his group. His guys are smarter than I am. They have forgotten more about mobile platforms than I will ever know. My complaint is that too many developers are using Xamarin.Forms in a way that leads to failure. They turn around and blame the technology, when they should be blaming the decision maker for using the wrong tech.
I wanted to take some time to expand on my thoughts on Xamarin.Forms. I've copied out the first part of my article to give a baseline for my thoughts.
My personal beliefs on cross-platform development were formed in November 1993. I worked at The Coca-Cola Company at the time, and a few colleagues and I were discussing how to provide Mac users with the same set of applications that we were building on Windows 3.1 with PowerBuilder.
The discussion centered around the UI. The concern was with providing a Windows-centric interface to Mac users. I remember one of the great lines from the meeting: "If you provide Windows help to a user expecting Mac balloon help, you are going to have users that hate you." After this and some personal experiments, I came to agree with this viewpoint. If developers want to make users as happy as possible, they need to call the native APIs of the platform.
Fast-forward to 2009, when I fell in love with the Xamarin iOS product from the first announcement. Xamarin had created a way for C# developers to use the Microsoft .NET Framework and to call into the native platform APIs. Xamarin Android operated the same way. While I would often discuss the need for a cross-platform UI with Xamarin management, I never forgot the lessons of cross-platform from many years ago. At the same time, I knew that there was a need for a cross-platform toolset to create an application. I had talked to enough people to understand the pain and agony. Quite honestly, I was a fence sitter in this area. I liked the idea of XF, but I was never quite ready to make the jump and, honestly, try XF for anything more than some personal experiments and helping a couple of customers.
The problem with cross-platform tools is that they tend to target the lowest common denominator. This commoditizes the UI. This isn't necessarily a bad thing. Time to market can be improved. There are lots of applications that don't need a fully optimized platform. There are a number of applications where getting something out quickly and solving a business problem can be the most important factor.
There's no "one size fits all" solution no matter what some faction wants to preach. Some applications have very device-specific needs -- some applications don't -- it very much depends on the situation. Users, the ones who pay for development, tend to want applications that look, smell and taste like every other application that they already have. The worst possible situation to get yourself into is the one where you start down the road of using a cross-platform framework, and the users demand so many features that are platform-specific that it would've been easier and cheaper to have just built two or more platform-specific applications. That is a special type of hell. I've been there, and it's a bad conversation to have with a paying customer. The bottom line is that you need to have a real-world discussion with your users and the people that sign the checks. No one will quite understand it, but morally, you really need to have this conversation in the consulting world.
To help solve the cross-platform problem, Xamarin has produced Xamarin.Forms and added this product to the list of tools for developers. XF is a cross-platform API that maps to device-specific APIs. This article will delve into an examination of Xamarin.Forms with an application that I had to write for our startup and how well it meets several requirements:
- How well does it display on a platform? How much platform-specific code is necessary? Does the application "look" like a native platform?
- When a developer has to resort to native API calls, how easy is it? Can it be done? Does it work?
- When something else has to happen, how much third-party support is there?
- Internal company applications. Internal apps tend to be heavily data-bound. Solving the business problem is the most important thing.
- Applications that don't need to customize the UI. The more customization of the UI, the less an XF app makes sense.
It's into this world that XF sits, and a ton of developers see Xamarin.Forms as the holy grail, the solution to all of their problems, the cross platform magic, free safe sex, etc. Let me be clear (as our President likes to say), there are a certain set of applications that work really well with Xamarin Forms, and there are a certain set of applications that do not. I've listed out the types of apps that work well, let's look at the type of apps that do not. These are:
- Customer facing applications. Customer/Consumer facing applications tend to need lots of UI customization. Customers want applications that look, smell, and taste like all of the other applications on the devices. Give them a windows app that runs on their mac and they will burn you in effigy forever. XF can do a lot of things, but its not magic. It is not going to solve every problem and there will be some things that it limits you from doing. Nothing is as embarrassing as someone pulling their phone out and saying "This app does this, why doesn't ours?" and then having to explain the problems with cross platform development tools. You can easily spend a lot of time, much more than was budgeted for, to do all the little UI specific cool things that makes a marketing manager happy. Somebody's got to pay for this time, it ain't going to be me.
- Performance driven applications. If an application needs the utmost in performance, a cross platform tool will probably not be the right tool. You want as few layers in your application as is possible and make sense.
What are the mistakes that I see happening? They tend to be numerous. I'll try to summarize them here:
- No, no, no, shoehorning XF into every application that you could ever want to build and magically getting iPhone, Android, Windows, etc. out the other side is not a good idea. I see this one over and over and over. XF is not a hammer and everything is not a nail. It sounds cool. It is the siren's call of developers. It has rarely worked great (dare I say ever) in the past. You have to take each individual application requirement and use the appropriate tool to build it.
- XAML. This is another tool I'm not convinced is the best idea to use. Yes, there are a lot of XAML developers in the MSFT space. That doesn't mean that using XAML is a good idea in a mobile application. Currently, the XAML tools are in their infancy (alpha or beta level). There is going to be a growing pain with them. My guess, and I have no data to back this up, is that there are performance problems under the hood with respect to Android and I bet that these problems happen when using XAML. Why? If you build a native layout in Android with it's xml, there is a lot of work that the android layout subsystem has to do for a deeply nested Android layout. This is time. I bet that there is some work done to turn a XAML layout into an Android layout that is happening behind the scenes, then the Android layout subsystem has to take over and do it's work.
- Android is slow. It is a horrible resource hog. My iOS golf app runs great in the iPhone. The Android version runs great, but it is an up to date nexus 6p. There is lots of complaining about performance in the Xamarin Forums with regards to performance in Android. This so reminds me of 2011 when Xamarin.Android had performance problems. Eventually, the Xamarin.Android problems got solved. Eventually, the XF problems in Android will be solved. Dang, there is a lot of pain right now.
- Lots of Android phones are old. Let's be clear. iPhones turn over every 2-3 years. Most of the people I know update every 2 years. There are lots of android phones out there that are older. How many people are out there running Android 4.x phones or phones that originally came with Android 4.x? The answer is a lot. As of today (10/12/2016), Android 4.x and earlier is over 40% of the Android phone marketplace. There are a lot of old phones out there.
- I've seen 3 XF apps up close and personal beyond my work. 1 worked fine because it was nothing more than a wrapper around html. The other two had a lot of performance issues on Android. It's easy to say that the developer was at fault, but there also has to be something for the developer not being given full information as to the reality of XF on Android. Just expecting them to become aware of a performance problem on their own is tantamount to lying. There needs to be some indication that there are performance issues, the situations where these occur, and how to mitigate them. There is mostly silence on the matter.
- It seems that you have to add lots of third party components to get an XF solution to work. Will these components be kept up to date? Will they be supported under future versions of iOS, Android, etc? Do they really work?
- And then there are all the classic software development mistakes that happen. My favorite being the management adage: We've hit a bump in the road, let's get someone that uses this stuff all the time for the little tweeks that we need. No, no, and no. By the time a problem has been found by users, it is typically too late. The only good solution at this point is to just start over. Management fights back with: we've already spent all of this money, we can't just dump what we have and start over. Me: what you have doesn't work. FYI, I get pulled into this issue all the time. My response now is just to blanket direct the company to start over. No amount of pulling someone else in is going to solve a problem.
To tie this together, XF works great in small applications. It works great in internal company applications. Not so much in consumer facing applications. Not so much in user facing situations.
Ok, great, so what are you supposed to use? Use Xamarin.iOS, use Xamarin.Android. Learn the platform specific features. These will solve your problems. You'll be able to take advantage of platform specific stuff that makes an iPhone app an iPhone app or an Android app an Android app. Your users will like it much better. Yes, this will probably cost more than building one app to rule them all, but you'll probably have more success as well. Still want to use XF? Fine, then embed some XF in your iOS and Android applications. This will limit your exposure to problems and lower your risk. While people say that they are worried about cost, they really need to be worried about something more basic, which is success (at least they should be). I would question the ability to be successful if you are building a major consumer facing application with Xamarin.Forms. Small applications, I'm not worried about. Applications built with Xamarin.iOS and Xamarin.Android, I'm not worried about.
PS. I love the XF bug where it displays the label in the wrong color on the Galaxy s4. That's a nice one to get thrown in your face when you are testing and showing what you have built.
PSS. But Wally, you love Xamarin Forms according to your articles. No, I love solutions. XF fits a part of the cross platform problem. Not all applications fit into the space of "I need something quick that works for iOS & Android and don't care that much about the UI." My example picture taking app for golf fit into that space. Just because I would build my picture taking golf app in XF means that it is suitable for every situation. And btw, my golf app is pretty robust now. It worked really well in some low quality cell connectivity areas last week.
PSSS. I was finally able to find a solution to my problem of already having an image in a byte[]. Here it is: https://forums.xamarin.com/discussion/17882/blob-to-image-binding. I'll probably be talking about this in a future article. :-) How I missed this post previously, I don't know, but I am glad to find it.
