Recap on Xamarin.Forms
I’ve now finished four apps (and created at least a dozen prototypes) with Xamarin.Forms so I feel its time for a recap.
The overall experience was.. subpar to say the least. In my opinion Xamarin Forms is still very much in alpha and not really ready for production.
Here’s a few points why:
Startup time is abysmal
That Xamarin isn’t fast at startup (esp. on android) has been known for a long time, however Forms is a lot slower to startup than Xamarin Native and it makes for a very bad user experience when a small to medium sized app takes 4-5 seconds to start on a latest gen high-end phone and 6-8 seconds on a 2 year old phone (considered high-end back then).
That different platforms require different error handlings isn’t anything new, however with Xamarin (esp. with the latest series of updates that where provided) a lot of error handling seems to be delayed to runtime.
I.e. on a clean Windows install I setup Visual Studio with all tooling, but forgot to download “Android SDK Build-tools v27.0.2” from the SDK Manager.
Xamarin worked just fine (using an older build tool chain) in debug mode and even happily compiled in release mode without any errors. However once deploying the release version to an actual phone the app would insta-crash on startup. I still don’t really know why the new toolchain is required or why it worked fine in debug but failed in release mode with the older toolchain.
Bugs, bugs everywhere
The various bugs are well known and I have yet to see a company (that is developing with Xamarin) that doesn’t have a “giant list of Xamarin bugs & workarounds” list.
Often times it’s small things that sort of work on all platforms, except sometimes they don’t on some platforms:
- Android debug builds continuously reset their storage access permission to “off” even though the manifest has them included causing crashes when interacting with external storage
- Building the android version after a clean checkout? How dare you! It will just fail until you build any other platform (iOS/UWP), doesn’t matter if that platform even compiles, however afterwards compiling android will just magically work
- Deleting some classes? Let me hit you with some random build errors that you might get sometimes and not other times (“resource is missing” anyone?). Restarting Visual Studio and deleting “\obj directory” will fix it (most of the time at least) but is very time consuming
Overall this makes for a frustrating, hair pulling developer experience.
Can we talk about lists for a moment?
Sure, Forms has a listview and even a few basic templates to demonstrate it’s flexibility (ImageCell, TextCell and the like), but.. beyond that?
If I want a list that shows two images next to each other (and the images aren’t always the same height) I’m shit-out-of-luck and have to resort to hacky manual bindings setting each itemcell’s height manually to the taller image height.
Except I can’t even get the image height from an image loaded from the web so I save the image to disk and then load it again… err okay.
Overall the experience with controls has been a very flaky one. Controls sort of work, except for when they don’t or show different behaviour across platforms.
Once you actually get them to behave sort of as expected you realize: the entire control set is very limited and it is near impossible to build native looking beautiful designs because only the very basic controls have been provided.
Forms seems to be targeted more towards internal business applications (“hey lets build an app for our upcoming conference”).
Productivity gain (hint its actually a loss)
One big argument for Xamarin.Forms is the productivity gain of sharing Xaml across platforms and “build once, run anywhere”).
In theory you only have to write business logic once (no more different bugs in different platforms!) and write the ui layout once.
In the real world it’s actually a productivity loss. The entire toolchain is just not ready for primetime and I’m definitely spending more time chasing weird bugs and unexpected behaviour.
Even when I get the layout to behave as necessary I always find subtle differences between platforms.
To make matter worse most of the time small differences between platforms are necessary (iOS has a different navigation model compared to android) so now I have shared views but I actually need to make them look different again!
At least Xamarin provides “On Platform” which allows you to specify code/xaml that only executes on a specific platform.
This is enough to add e.g. different colors for different platforms:
<OnPlatform x:Key="SwitchOnColor" x:TypeArguments="Color"> <On Platform="iOS|Android" >#0000FF</On> <On Platform="UWP">#FF0000</On> </OnPlatform>
Is Xamarin Forms really the holy grail? I don’t think so
Stepping back and looking at the bigger picture, I don’t think that Xamarin Forms will be the primary way of app development for any company.
Internal business applications that need to be rolled out to all employees of a company and have to work and not look pretty? Sure. Maybe.
But everyone else is much better off with Xamarin.Native where you can share the code but let designers create truly native UIs.
Sure, the idea of sharing 100% (more like 90-95% in real world scenarios) of code sounds sexy and “could lead to faster app development cycles”, except that it really doesn’t work in the real world:
- Different platforms have different design philosophies
- Every platform should have it’s own, separate design
- Also: stop shoehorning your hamburger menu on all of them, please
- Xamarin Forms (still) takes away a lot of flexibility by being the lowest common denominator between platforms
- Having only a subset of options available when trying to design aesthetically pleasing apps hinders design and slows down development
- Each platforms should abide to the design rules of its vendor (insert Google/Microsoft/Apple/other-platform-vendor here)
- Actually increased development effort needed
- Having to create custom controls for each platform because they don’t (yet) exist
- Having to work around bugs/inconsistent behaviours in existing controls
- It’s early alpha like state makes it hard to plan
- Seemingly easy features to implement take a lot longer due to unexpected bugs that have to be worked around