The Issue With Xamarin

Some may know that I have a lot of feelings towards Xamarin and very few of them are warm. Most are very heated, but for the wrong reasons. Thought I'd finally write them out and explain what's the problem.

Note! I am talking with experience while developing application that currently has source code size of over 400k lines (quick check with cloc 1.70). This is not a small project. Many people may be happy using Xamarin with their apps. Most of those apps are small. Very small compared to this one. So when saying "it works for me" do tell the size of your projects also. I welcome all comments and experiences, but this is one difference between the typical Xamarin user that I've seen and our project.

TL; DR

Xamarin is slow, buggy system that will make you lose your mind. It won't help you save time or share code or magically make two apps with the price of one. I tried to help them by reporting issues, but was shut down with "you're not paying us enough." So I guess they have an issue somewhere, though I'm sure some people there would prefer people reporting issues so they can be fixed. So I'm writing them here.

No, I won't fight with Bugzilla. It's one of the horriblest things I've ever used. Maybe it's better these days, but it left a bad taste years back and I'm not paid to write perfect reports. If Xamarin wants me to give more information, they can ask nicely and I can see what I can do. I really wanted to help and make my own work go more smoothly.

This is not about bashing Xamarin, this is to show that behind the marketing hype and pretty words there is a beta class product that might work for small apps but isn't really ready for real world use and requires a lot of TLC from Microsoft in the future.

Most of these things I found out after one week of using Xamarin. One week. That's all it took, though of course I've used it for longer now. I can't believe nobody else has seen this. Or am I working on such a big project (25 projects and 2000+ files, over 400kloc) and nobody else bothers? Also, my machines are on the quad i7 with SSD level, so it's not due to me having an old machine. And I can compare to Visual Studio easily on the same machines.

The Good?

First I must say that there are many nice things about Xamarin. I like how they've converted the iOS/Android APIs into .NET style, I love how easy it is to do things with async/await compared to the Java way of anonymous classes after anonymous classes. But this is all just .NET, nothing really special to Xamarin.

I would just love Xamarin if it worked as it should and provided a nice way to do .NET on iOS and Android. But since it just can't, what can I do? The version numbers are 4-6, so it's not like it's alpha/beta stuff. It should already work!

Marketing Hype

I was contacted by Xamarin sales rep and how he tried to get me to buy into the Xamarin hype was totally ridiculous. Here's a verbatim quote from him:

With two native development teams you will have no collaboration meaning you will build two apps with complete different feature sets, leading to two different experiences - this is not good for user adoption. This will also be expensive and you will need to skill up two teams rather than leveraging your current development team. It will also take twice the time to build an app.

I would want to emphasize the main points, but that would mean emphasizing the whole lot. Let's break it down.

"you will have no collaboration" - this is the first whattaheck moment. No collaboration? I've been in the industry for two decades. I've worked on mobile devices for way over 15 years. And I've yet to understand why anyone would hire two teams to do two platforms and isolate them into different rooms. Maybe that wasn't the intention of this? Let's see...

"you will build two apps with complete different feature sets, leading to two different experiences" - no, it was exactly that. The teams would work totally separately, build two separate apps however they would like to. No no no. This is not how I operate. This is not how anyone sane operates. No way.

And two different experiences is a two-way thing. If you build an app that looks and feels exactly the same on iOS and on Android, you're again doing it wrong. Android users are used to having a dedicated back button. iOS doesn't have it. This is just one of the differences that have to be addressed when creating applications. So of course the applications will be different, but only in the parts that need to be different for the application to feel "at home" on both platforms.

This doesn't mean in any way that you can't use same UI elements, same background code or you'd have two completely different experiences. You're just tuning it to suit the platform.

"you will need to skill up two teams rather than leveraging your current development team" - now, Xamarin allows the use of the existing .NET knowledge of the team. But since the UIs are still made natively to both platforms, do tell how do we not need to make our developers knowledgeable about iOS or Android by using Xamarin? And no, Xamarin Forms is not an answer. Xamarin themselves says it's only for prototypes or little things, not for actual development.

Using any platform requires getting new skills into the developers. And what if our team already has iOS and Android knowledge? I, for one, have both. And .NET knowledge. So I don't need to skill up anything from scratch to do native or Xamarin development. I do need to learn more, I don't know everything.

"It will also take twice the time to build an app." - no, I don't think so. If developing at the same time, it will take more time. If developing first one, then another, less so. And even with Xamarin the user interfaces must be done separately so the time usage is still bigger. It's not a silver bullet.

There was also a sales pitch document from a company that said it's so great they only had to write 50% of the code for two platforms and how they didn't have to train their people since the outsourced the whole thing to a company that does Xamarin work etc. A typical pitch with no actual figures or anything. And the app seemed to be quite simple anyway. But I'm sure the consultants took their money.

So to wrap it up: doing two platforms will take more time whether you use Xamarin or native. With Xamarin you'll have tools fighting you, maybe have to learn new things if you're not both .NET and iOS/Android savvy. With native you'll have another set of issues with the languages and environments, maybe have to learn new things if you're not ObjC/Swift/Java and iOS/Android savvy. Which is better? Depends, as usual.

The Price

Xamarin has a couple of different options. If you're an indie and don't need much, you can get things with $25/month, or $299/year. You won't get any support (except forums, which are useless), you won't get Visual Studio integration, nothing.

If you want better things, you'll pay $999/year. And do note this is per developer, per platform, yearly payment. So let's say you have a team of two and both work on both platforms. You'll pay $3996 per year to use Xamarin properly. That means you really have to get some benefit from it. Probably you won't.

The Issues

I tried to report lots of issues with Xamarin and Xamarin Studio by email, as the marketing person informed me to do. The reply I got was that since I'm not paying the $999/dev/platform/year, they won't provide support to me. This was quite a shock. Their product is broken. I explain how. They brush me off without any help. Tell me to go to the forums. The forums that is a wasteland of questions without answers since nobody else can answer than Xamarin themselves and they don't seem to care about the forums.

So here are some of the issues I have come across. Not nearly all since I haven't written everything down.

Xamarin Studio

Xamarin Studio is quite a heap of junk. Most of my issues are with it. And since there really isn't an alternative for using it (VS is mentioned a bit later) people have to suffer with it.

The editor doesn't update the screen always. Press Ctrl-Delete and maybe nothing happens. Click somewhere or press cursor keys and then the screen updates. Maybe sometimes deleting code or pasting new adds the text, but the coloring doesn't move on screen.

Unstable IDE

XS at least once a day goes into a mode where all on-screen parts, like Solution, Properties, Errors etc views just lose their content. It's running and responsive, but nothing is drawn. Restart fixes it.

XS crashes at least a couple of times a day due to random things. Have never found anything that crashes it for sure, it just dies randomly.

Changed Files

Also noticing files changing and reloading them, especially project files, is shady. Some might say why do you alter project files outside, but that's what version control does. I don't want to close the solution and reopen it every time this might happen.

Also if it realizes a file has changed, of course it won't stay on the same line where you were. The file is reloaded and the position jumps to beginning. Thanks.

Key Shortcuts

So, I want to delete the previous word. How was it... Oh, yes. Ctrl-Backspace, like in any other Windows program. Deletes the last character, that's odd. Let's check the settings. Oh, there is no key command defined. I'll just add Ctrl-Backspace... except I can't. Backspace is always deleting the Ctrl definition. So I can't do it. No key command can have Backspace in it from the GUI. So, I'm to be without it forever? Nice.

Going backwards/forwards in code after using, for example, F12 to jump to definition. Oh, Ctrl-Alt-Left/Right is said on the menu. Except no, it doesn't work. It just goes to prev/next character. Another thing that's broken. Nice.

Some people suggest downgrading GTK library versions. Why bundle a broken version when you know it's broken? Why not provide a fix with an older version on next update? Why bother, seems to be the idea.

Nobody Needs Paste

Paste doesn't work. Yep. If I copy text from Notepad, Visual Studio, anything else than Xamarin Studio, I can't paste it. It just doesn't work. No idea why. I can copy/paste within XS without issues. Just nothing from the outside.

Visual Studio Plugin

Of course I could use Visual Studio. If I pay the $999 price. But the plugin is a bit broken, as everything. Maybe breakpoints won't work. Maybe solution loading hangs the whole system. Maybe this or that. In the end it's better to just stick to Xamarin Studio. It works better in general. So you're paying for nothing and just waiting for things to get better.

Build Speed

The speed with which Xamarin builds depends on the platform. Or rather, platforms. If you're doing iOS development on OS X, prepare to wait. The compilation is slow and since the code has to be compiled to native code in the end (Apple doesn't allow code generation on the fly), it'll take even longer.

Android builds on Windows are faster. This mainly due to not having to do native, unless you want to. And things work better there anyway.

For me my current work project is a big application, so it has 25 projects in it. Making one line change and getting it to run on the iDevice takes 3-4 minutes. Calculate that: if I'm working on a feature I can only build about 10 times an hour. The rest of the time I'm waiting for compilation and a little sliver of time I'm actually coding. This also relates to the next issue.

Disabled Projects Still Build

If I have 25 projects and only work on one, it's logical to mark the 24 others to not build. Then I'll just have to build one and link the stuff together. But this doesn't work. On iOS every project is built whatever settings you have. And it's not just a little thing to check if there is need to build. It takes ages to just check. Visual Studio on Windows does it in couple of seconds for this many projects. XS may take a minute just for that.

No Caching of Output

Monotouch, the compiler to turn the .NET into native code, doesn't seem to have any kind of cache, or the previous item messes with it. So every build needs a looooong time to compile into the end product that can be pushed into the device. It's very bad.

Language Bugs

iOS version allowed parameterless constructors for structs. C# doesn't allow this. This was fixed finally.

There still is an issue where I can build code where a method expects to get a parameter with type ISomething and the actual object given does not implement that interface. It does have the methods that are called on that object and it resides in another assembly, so for some reason Mono/Xamarin uses duck typing in this case. I haven't bothered to build a MVCE of this, but it's in my code tree. Building every day without errors.

Android UIs

You can work with UI definitions inside Xamarin Studio. But the experience is quite bad. Change the ID of a control? It's not changed anywhere else. Feel free to find every place where you referenced that control, or just don't bother and use the text editor and do things manually.

Also if you happen to have UI definitions in another project that links to your main project, good luck. If you add a control to the referred assembly and build, Xamarin won't find the ID definitions. You will have to rebuild the referred and the main assembly. No, just building doesn't help. Rebuild needed. For two projects. Slow...

And if you ask why would anyone do that, well, when you have a set of controls or UI elements you want to use in several product variants, that's the way to do it.

Also trying to drag controls to the UI editor may add them somewhere where it shouldn't. You'll get a compilation error saying scrollview can only have one control and you can't see more than one control. Until you go edit the XML. Always stick to the XML.

There is no undo. Not for parameters, not for moving controls around, nothing.

Android UIs Not Updating

Sometimes XS goes into a mode where any changes you do to the UI files is not pushed to the device. All code changes are there, but the UI doesn't change. Of course a full rebuild helps, but not nice when you're testing 20 changes to the UI and want to just quickly run them. Nope, won't happen.

Disk Bloat

Building things with XS on OS X starts hogging disk space. I was wondering why my disk was filling up until I did a total clean on projects. Helped a bit. Then I shut down Xamarin. 10GB of disk space suddenly appeared. Haven't checked what it does, but it just leaks files left and right. Messy.

No Information on What's Wrong

Let's say you have a file open on the editor. You've written something on it. Then you do an operation that changes the file, let's say pulling from source control. Then you go to XS and try to build or run. Nothing happens. You try pushing buttons, selecting menus, using key commands. Nothing. Until you go through all the tabs and suddenly there's a mention that a file has changed on disk. Only after handling that you can build.

Visual Studio would show a dialog immediately it detects a change and this would never happen. But with XS I've had this several times.

Autosave File Found

Sometimes you get a mention about an autosave file being found. You're asked do you want that or the existing file. No way to compare, see what's the difference. You just have to choose. Right now. Otherwise you can't continue.

Version Control Done Wrong

Let's say someone made your solution in a way where some projects are above the solution in directories. Might happen, even though not that nice. Still you expect things like version control to work properly. Not so with Xamarin Studio.

If you edit a project that is outside the folder where the solution is (note: still in the same repository), Xamarin Studio won't show the changes for that project when you ask it to show all changes in solution. You may be committing partially. This also was a nice thing to notice. So better not to use the integrated git.

You also might have different settings on git and Xamarin Studio for email, name etc. On commit XS asks which would you want to use. You're surprised, want to check what they are. So you press cancel expecting it to cancel the commit. Not so, commit is done with some information and you are not told which. That is not canceling.

Realtime Error Detecting? Not on My Watch!

With Visual Studio I'm spoiled with error checking. I can just see errors immediately while writing code. If I fix them I can see them disappearing from the list. With Xamarin Studio it usually takes a build to get them to go away. Which may take minutes to do. So much usability.

This seems to work better on Xamarin.Android/Windows than Xamarin.iOS/OS X for some reason.

Intellisense

Adding resources to a project should be simple. Just add and you've got intellisense (or equivalent) and can just code. Not with Xamarin Studio. You may need to reload the whole solution, or restart it, to get things to show up. I'm really hoping Roslyn will fix all of this.

Change Code While Building

You're doing one of the slow builds and notice an error in the code. You don't realize to cancel the build but rather just fix the issue. Save. Then cancel build and start again. XS doesn't realize you've changed anything. You need to do a rebuild for it to realize something was changed. So always stay away from code while building.

Not All APIs Are Converted Properly

Usually if there is a Android API with setSomething() and getSomething() Xamarin has done it nicely into a property. You just use object.Something = 123; I like it a lot. Makes it .NETty and familiar. Except randomly there's some API that has a read-only property and still a SetSomething(). Or some API has GetSomething() and SetSomething() even though they have the same type and only one argument.

I don't know what logic they use to (automatically) convert these, but it would be nice to be consistent.

Code Formatting

Basically every programming language has a style it should be written in. For me C# has the nice style, like this:

int Function(string name)
{
    Console.WriteLine(name);
}

It doesn't matter much that I prefer that, but it's the style it should be. Everyone should use it writing C#. But how does Xamarin Studio do things?

int Function (string name) {
    Console.WriteLine(name);
}

Notice the space before parentheses and the curly brace on the same line. That's not right. In Java and JavaScript you put the curly braces there, but not even they have the space before parens. What the heck?

So, why do this? On the forums I saw that it's due to Mono's coding style, which someone recalls is copied from Linux kernel style. Why the heck has the Linux kernel have anything to do with how C# should be written? Really?

If I tried to suggest a totally different style for coding Java and explain that "because Scheme has this style" I'm sure people would just kick me. So stop it, Xamarin.

Yes, this can be changed, but it has to be changed for each machine you use. Cumbersome.

Can't Switch Between Fast and Slow Assembly Deployments

If you use Fast assembly deployment even once you can't go back without removing the application. Xamarin installs the assemblies in a different way and for some reason the fast mode overrides the slow one. So any changes you do to things like UIs will be taken from the fast mode and things will crash and you'll burn.

Also code changes won't show up, but you won't know it. You might be debugging old code and wondering why the behaviour doesn't change.

Archiving With Errors

So your app is ready for deployment. You want to archive it. Select Archive for Publishing and Xamarin starts building. But, there is an error in your code so it won't compile. Xamarin Studio will still present you with the archive list and doesn't necessarily highlight the error section, so you might just without checking pick the previous successful build and sign that.

Of course there should just be an error message and no archive window would be presented on such occasion. Basic UI testing should've shown this issue.

Oh, and if you click Cancel on the file selection dialog on the last step of signing, Xamarin will still spend time doing something and say that your application was signed successfully. Where? Nobody knows. They don't even check if Cancel or OK was pressed.

You're Better Off With Beta

I had an issue with websockets. Everything worked fine on native iOS. Import a library to Xamarin and the app just hangs on connect. No explanation. Tried everything: different threads, other ways of calling, everything. No help.

Then I just for fun checked updates. A beta version available. Ok, let's install. And suddenly the code works without issues. So you're sometimes better just using the beta stuff from them since they have issues fixed faster.

Can't Decide Error/Warning Counts

I'll just leave this picture here:

Can't Show Exceptions

Sometimes Xamarin really goes to town with exception details:

Android Profiler

Now, this is the first beta level part I'm talking about. And considering the production versions are that bad, you can imagine how a beta product works. So this is not a horrible bashing, I'm waiting for the non-beta. Which is probably a long way ahead.

The profiler has only memory profiling. And I say profiling very lightly. All you get is a list of different allocations, a very strange call stack that doesn't really show all the places where you allocated, for example, int[]. Just one or some of them. You don't really get a sense of what's alive and what's not. Mainly just "I have allocated strings for 20MB at some point altogether kinda I guess."

There is a snapshot button. Snapshots are great. I take a snapshot, then do some operations, then another snapshot and compare. What allocations happened, what's still alive? Except in this product it just hangs or stops the collection. So totally useless at the moment.

The profiler had a CPU profiler also, but since it had issues with Mono, it was removed. There are many people asking why not just put a mention that it doesn't work for everyone and let the ones that had no issues with it use it still. And especially since the memory profiler also should have a mention "probably does you no good and is completely featureless" why not have both?

Of course could be me at fault here not knowing how to use it, but considering I've used at least half a dozen profiling tools successfully without any issues, I'd say this one is broken. But hopefully it'll get better someday.

Enough?

That's just some things I've run into. I don't even remember them all. There's so much. But what you should take from this is this: Xamarin is expensive. Sure, the yearly license is not much compared to the salary of a developer per month. But when you understand how much slower it might make you in development, testing and getting the product out, you really have to think about it. My suggestion is to stay native. Don't believe the hype. Try it if you want, but since without paying you can't do anything substantial, you won't really get the feel for it.

If you have a small app to develop, the chances of getting savings from Xamarin are tiny. If you are developing a big application, you'll run into issues costing you a lot of time.

Of course I might be a unique snowflake and nobody else is having these issues, but I just can't believe it.

Future With Microsoft?

I really hope Microsoft will take the whole system and rip it open and fix it. Make the Visual Studio plugin work properly. Make me never need to use Xamarin Studio ever again. Make things fast. Make it just work. Listen to bug reports. Answer on the forums. Do the things I know Microsoft does.

So maybe in a year Xamarin will be worth your while. But now, definitely not.

As for me, I can't just convert all this code into native, so I'll be using it for a long time, whether I want to or not. And if Xamarin wants my help in fixing bugs, I'm happy to help, but I don't want to hear any bull about not paying enough when I'm telling what's broken.