
Xamarin makes me sad, here is my message to them - nreece
https://gist.github.com/sadxamarinuser/2717d68996daea0e2f17
======
jpobst
I worked for Novell/Xamarin for almost 7 years and this was a large part of
why I eventually parted ways with them. I spent a couple of years on Windows
Forms, a couple years on Mono Tools for Visual Studio, and a couple of years
on Mono for Android. In all that time I never really felt proud of something
we released. I always felt more like I was apologizing for our releases than
proudly showing them off.

Having said that, I gave Mono for Android a try as a hobby again this year and
it was light years better than when I left. (Congrats guys!) However there
were definitely still bugs that were mildly annoying as a hobbyist that I can
see would be infuriating if I had to rely on it for my job.

~~~
andycted
Ditto. I really can't think of anything better to say: Working with Xamarin
tools is infuriating. You come to expect them to apologize for the level of
unreliabity, instead, not long ago, I got an angry reply that I should be
careful when reporting bugs and that I'm insulting them. Never did, but I
might start.

------
cellis
C# is a great language and .NET is probably the most advanced VM on earth.
Visual Studio is the most polished IDE. It's just a shame that Microsoft had
to enforce windows-only so dogmatically, which is the only reason mono and
Xamarin exist in the first place. So the real thing that needs to happen is
MSFT needs to make tools for .NET and work to make .NET run on *nix.

~~~
x0x0
what does .net platform offer over the jvm? (And to be clear, I understand
differences between java and c#).

~~~
pjmlp
> what does .net platform offer over the jvm?

Some builtin features that Sun/Oracle leave for third parties.

\- It always JITs. Either at runtime (JIT on load) or at installation time
(NGEN).

\- Windows Phone 8 .NET applications are compiled to native code, to an
executable format called MDIL. Native code with symbols left for linking.

\- A new JIT in the works that offers SIMD instructions

\- A native compiler for static binaries based on the Visual C++ backend (.NET
Native)

\- Value types (In discussion for Java 9)

\- Flat arrays

\- Native interop (JNI sucks, Oracle also recognized this)

\- Real generics.

Regarding the first issues, Java also offers them, but you have to buy a
commercial JVM as the standard Oracle tooling doesn't offer such features.
There is the Graal/Substracte VM at Oracle Research, but who knows when
integration will happen.

Regarding the last issues, they were discussed at JVM Language Summit 2014.
Some of them might be fixed in Java 9 timeframe.

[http://www.oracle.com/technetwork/java/javase/community/jlss...](http://www.oracle.com/technetwork/java/javase/community/jlssessions-2255337.html)

~~~
x0x0
Hmm.

what is a flat array?

By value type, you mean assignment causes deep copy instead of reference copy?

What is the advantage of a static binary over just shipping the jvm (which you
are certainly allowed to do)? I guess I could see it if you are writing end-
user software, but the jvm is pretty much server-software and devtools at this
point.

What do you mean it always jits? So does the jvm unless I misunderstand what
you mean by jit.

simd is beginning to make its way into java, but numerics are not the jvm's
strong spot. I didn't think they where for c# either. Is this incorrect?

And yeah, jni is fucking awful.

Real generics would be nice.

Thanks for your answer.

~~~
pjmlp
> what is a flat array?

In multidimensional arrays you do one single allocation instead of n times m
time k times ... allocations.

You can fake this in Java by allocating one major block and doing the math for
the respective cell yourself but it is cumbersome.

> What is the advantage of a static binary over just shipping the jvm

The same as doing coding in C and similar languages. Guess one of the reasons
why Java lost the desktop.

> What do you mean it always jits?

There isn't any interpretation going on. On most JVMs you need to set
execution threshold to zero to achieve similar behavior.

On most JVMs, it is a two step process as they start interpreting and only hot
methods (this is customizable on most) get JITted.

> simd is beginning to make its way into java

It is still not clear if it will make it into Java 9 timeframe.

> Is this incorrect?

Yes, as C# as managed to place itself as "good enough C++" on the Windows
world, for many use cases.

~~~
x0x0
Thank you.

I've shipped single jar programs -- it's pretty simple to repack everything --
and I believe (but am not 100%) that we included the jvm in there, so it can
be done. At the expense of a 100+m download, but for our use case, that was
not an issue.

Have you seen performance improvements from forcing always jit? I've played
with similar settings and only really found them useful for benchmarking.

I'm surprised you're seeing c# for numerics on windows; I thought there wasn't
much besides games that needs to be local and isn't written in c++ these days,
either for performance or because the codebase is old. I work on ml programs,
mostly c++ and java.

~~~
pjmlp
> I'm surprised you're seeing c# for numerics on windows;

Bioinformatics

------
Zigurd
The author's complaints about Xamarin might be true, but it is also likely
that Xamarin is less broken than any other cross-platform solution. If a
client _insisted_ on one code-base for iOS and Android I would choose Xamarin.

Doing what Xamarin does is VERY hard and Xamarin hasn't had big-time funding
until recently. And they can't stop and just fix bugs, like the article author
would like. Xamarin is on the treadmill and has to keep up with two platforms
that are in competition with each other. The only good news in that is that
they will probably converge in terms of capabilities. But, damn, I wouldn't
want that job.

3rd party dev tools are a thankless and usually VC-less pursuit. The investors
are probably hoping for an exit in the form of Satya Nadella taking C# and VS
cross-platform and using it for Microsoft's own apps.

~~~
vinceguidry
> If a client insisted on one code-base for iOS and Android I would choose
> Xamarin.

Have you considered Ruby? With Ruboto for Android and RubyMotion for iOS, I'd
think you could get a pretty good single-codebase solution. I ask because as a
Ruby dev who may one day branch out, I'd like to know what I'd be getting
myself into, and it sounds like you might have gone down that road.

~~~
srgpqt
RubyMotion now has builtin (beta) support for Android.

[http://blog.rubymotion.com/post/97668474211/announcing-
the-p...](http://blog.rubymotion.com/post/97668474211/announcing-the-public-
beta-of-rubymotion-for-android)

~~~
AlexeyBrin
This seems like a viable approach in the future. I hope you are not suggesting
that it is OK to send code compiled with a beta version to a client.

~~~
vinceguidry
> I hope you are not suggesting that it is OK to send code compiled with a
> beta version to a client.

If the client's demanding a single-codebase solution for both Android and iOS
and you are better at Ruby than you are with either Java or Objective C, then
it might make sense to sell the client on using the beta.

~~~
AlexeyBrin
I guess it depends on the client, if he is willing to take the risk that, for
e.g., his app won't be compilable with the final version of RubyMotion. You
can probably convince him it is a good idea if you specify in your contract
that you will offer support in the future when RubyMotion for Android is
stable.

I think RubyMotion could be a good idea, even today, for someone that knows
and use Ruby for his own projects.

------
Moto7451
To provide a (small) counterpoint I've shipped code targeting standard mono
for OS X, Windows, Linux, and MS's .Net compiler/runtime as source and
distributable DLLs and NancyFX based websites and haven't run into any major
road blocks aside from minor Xamarin Studio/Visual Studio project file
hiccups. Xamarin's .Net runtime/BCL compatibility list has been spot on for my
usage.

I can definitely see how chasing Apple, Microsoft, and Google's yearly mobile
API revisions can be a task. I don't think that necessarily justifies throwing
the entire project out (maybe just some careful evaluation of their mobile
oriented offerings). It's akin to throwing all of Java out due to your
displeasure with Android development (of which I have a long list of
grievances).

------
fotcorn
Google Cache version:
[http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://gist.github.com/sadxamarinuser/2717d68996daea0e2f17)

------
vlucas
You guys should just switch to JavaScript and use Titanium. Same end result
and shared codebase. You can use the Titanium Studio IDE, but it's completely
optional. I personally use it with vim and the command line, and it works
beautifully. There are some minor issues like certain native APIs not being
supported in Titanium (more of a problem on Android), but nothing like the
problems listed here.

~~~
pan69
I tried Titanium. Its horribly slow. You can't really build native UI's unless
you mimic them. Using Javascript is super simple but you trade off in power,
big time.

General rule of thumb; if you're building "content" apps you can get away with
Titanium. If you're trying to build awesome experiences you'd have to go
native and Xamarin is currently the best cross-platform suite out there.

~~~
vlucas
I have built multiple apps in Titanium, and I have never experienced anything
even remotely "horribly slow". The performance penalty is very, very small -
undetectable to the average user. I am not sure the apps you were building,
but, you do have to use common sense: you can't expect to build a highly
interactive game with lots of complex calculations and animations in a dynamic
language without a noticeable performance penalty. For 90%+ of the apps out
there though, there is no reason not to use something like Titanium if cross-
platform is your priority.

~~~
davidfischer
Titanium isn't horribly slow, but it isn't some cross-platform panacea either.
Building an app that supports iOS and Android well is still a big task. You
don't just build one app and get the second platform for free. Lots of the
APIs, methods and properties are platform specific or function quite
differently platform to platform. Most of this is documented but some of it
isn't. I don't want to be overly critical of Titanium as I think it has its
place but I think your post was a bit optimistic.

BTW, the OP's original rant reminds me of a similar rant for Titanium:
[http://usingimho.wordpress.com/2011/06/14/why-you-should-
sta...](http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-
from-appcelerators-titanium/) That rant is a few years old and Titanium has
made a lot of progress since then. However, some of the points still hold
true.

------
pjmlp
Well, to also provide another counterpoint.

I just lost a few days of development researching Qt for mobile. With the
outcome that it still has a lot of catching up to do.

First issue that was found. The common file dialogs present a desktop file
selector on mobile devices! Apparently this is being fixed for 5.4, but it
requires the UIs to be written in QML. No such luck for those using pure C++
Widgets.

Then the documentation about Qt Quick versions, how to integrate with C++
Widgets and the various ways the deployment to mobile devices can be
customised requires a bit o hunting and asking questions on the forum.

On my case we had deployment working without issues in the emulator, only to
be greeted with a blank screen on some mobile devices.

Since a good UX requires using the expected platform behaviours, the best
approach is to use C or C++ for logic with a thin shim for the UI and device
sensors.

Way more productive than hunting third party integration issues, without any
guarantee of having them fixed.

~~~
mwcampbell
On top of that, Qt has zero accessibility support (that is, support for
assistive technologies required by users with disabilities, such as screen
readers for blind users) on mobile platforms. So as you said, you're better
off using the native UI.

------
skrebbel
What a mindless rant.

As an equally (un)valuable counter-anecdote: I spent about 9 months developing
a set of apps for Android and iOS with Xamarin and didn't encounter many of
these problems.

We did find one bug in the toolchain. We reported it, Xamarin responded with a
workaround in 1 day and a fix in 7.

------
mwcampbell
RemObjects Elements
([http://www.remobjects.com/elements](http://www.remobjects.com/elements))
looks interesting, especially the C# flavor. With that, you can write in C#,
then compile to .NET IL, JVM bytecode (and from there to Dex bytecode for
Android), and x86/ARM native code targeting the ObjC runtime for Mac and iOS.
The RemObjects C# FAQ
([http://www.remobjects.com/elements/hydrogene/faq/](http://www.remobjects.com/elements/hydrogene/faq/))
includes a comparison with Xamarin.

------
lucisferre
As someone who spent a lot of time in the .NET world, can someone with more
experience using Mono/Xamarin tell me what the main goal is with using this
rather than switching to a more *nix centric ecosystem? Is it mainly popular
with those who want to develop cross-platform desktop apps?

From what I can tell it isn't that great for the end user either. I recall
once trying to install a mono based tool on OSX. It was... unpleasant and I
ended up simply choosing not to use it.

~~~
ZanyProgrammer
Well, its more of a write once, publish everywhere solution from what I
understand-it allows .Net devs to develop in C# for Android/iOS.

I recently tried downloading MonoDevelop on OSX, and poked at an ASP.NET MVC 3
web app. Straight out of the box I couldn't run it without an error popping up
I couldn't get rid of, so I ditched it.

~~~
pjmlp
> Well, its more of a write once, publish everywhere solution from what I
> understand-it allows .Net devs to develop in C# for Android/iOS.

Except they don't offer a multi-platform UI toolkit. Xamarin.Forms is quite
recent and the amount of bugs shows it still has lot to improve.

------
simplehuman
Xamarin is hardly a monopoly in any market. What am I missing?

~~~
aaronbrethorst
Nothing. I think the author may be tossing that word around _just a wee bit_
unfairly.

I liked Miguel de Icaza's measured, helpful way of saying 'get bent':

    
    
        Exception stack traces are the easiest problems
        for us to fix. But we need to get a copy of the
        exception.
    
        Would you be so kind of filing a bug every when
        you get those exceptions? Whatever settings you
        have or environment you are using is different
        than mine, and I have not experienced those
        problems personally.

~~~
eropple
I might get some flak for this, because while I respect the hell out of Miguel
we've never seen eye to eye when we've talked (he's called me a troll twice,
I'm very proud of that), I think that's a huge cop-out. I chafe real hard when
Miguel says "file a bug and we'll look at it", because...Xamarin's taking
money. When you're taking money, it's no longer "we the community," it's "you
the profit-seeking organization." It's their problem, not my problem. Xamarin
(and Novell before them) have not done a good job of managing a Mono
community, even aside from hiring a big chunk of the community and wondering
where the community up and went. They've burned the community at times (and
don't get me wrong, I understand why that happens, but it does still happen)
and they're clearly spending most of their effort on their commercial stuff.
Which is _cool_ , but you lose a lot of the "please file a bug" pull.

Expecting people to go sign up for your bug tracker and blah blah blah about a
bug in your basically-commercial software is such a fundamental failure to
understand _people_ that to me it's pretty much a statement that no, you don't
care. If you're seriously interested in fixing bugs people kvetch about on
Twitter, get your developer relations people (you have developer relations
people, right? (if not, why not?)) to send an email and do the legwork around
a bug.

And frankly, I feel like "file a bug with an exception trace" is a method of
symptomatic treatment rather than the fairly core auditing and testing that
most of the Xamarin software I run into on a semi-regular basis really needs.
From the outside, a lot of it feels _rotten_. Picking off an exception here or
there doesn't seem likely to cure the disease, it just lances a boil or two.

~~~
migueldeicaza
This is the bug report you provided:

    
    
        Nice updates to Xamarin Studio. Too bad they can't fix that pesky "indenting pukes on itself" or "lines disappearing in the editor".
    

And all I did was ask you for information about this, purely because I had not
experienced it myself:

    
    
         @edropple bug report please
    

But for the record, you do not need to sign up for our bug tracking system.
You can email your concerns, complains to support@xamarin.com who will be
happy to shepherd your problem through our developers.

As for filing the bug with the exception: I am merely trying to prioritize
someone with a bug right then. We do get crash reports with the exceptions,
and we go through those and fix those.

The only reason to ask for the exception is to provide you with better support
and address your fix faster.

------
an0nymousse
Everything the original poster said is true. If you want a really terrifying
fact: they're on their series C.

Series A: $12MM Series B: $16MM Series C: $54MM

$82MM and they still haven't fixed the fundamental issues that have existed
from day 1. Stability and support should always come first.

------
nstart
Since the original file seems to be missing now, here's the full text for
reference

I just stumbled upon this
[https://gist.github.com/anonymous/38850edf6b9105ee1f8a](https://gist.github.com/anonymous/38850edf6b9105ee1f8a)
and decided to write one too. I don't have affiliation with the OP, but I like
his idea and really understand his points.

I used Xamarin for the past year or something, not givin real date to keep
this anonymous so they dont block my account ;) All the information here is
subjective, I'm just expressing my rage in a very emotional way, take it with
a grain of salt. Xamarin, if you're reading this, PLEASE TAKE SOMETHING
POSITIVE FROM THIS AND GO FIX SOME BUGS.

TL;DR: I love C# more than any other language, but Xamarin is HORRIBLE. I wish
it and mono were never invented. It's a disgrace, completely broken and buggy
and just the most broken thing in the entire universe, but I still use it.

Why? Because I can write for 2 platforms as if it was one. haha, not really
... but because I work on small apps, I don't have to write all the business
crap twice. That is good about Xamarin, that is the only thing. They can
actually compile plain C# ... hooray. If only the rest of the crap expensive
broken Xamarin crap library actually worked as advertised.

I'm sorry for being so dramatic, but really if something costs a thousand
dollars a year per platform, you kind of expect the damn company to put some
love into the thing. You would expect bugs to get fixed, and for things to
work. But no, that is not the case.

Look at Xamarin Forms. Oh a shiney new thing that builds real cross platform
UI, so nice. EXCEPT THAT THERE ARE MILLION BUGS IN IT. Fundamental bugs,
crashes, memory leaks and other memory issues, broken resource handling ...
just serious things that normal company would never release to public, but
Xamarin debugs on paying customers, on customers who pay thousands of dollars.

If you don't believe me, go to
[https://bugzilla.xamarin.com/](https://bugzilla.xamarin.com/) and look at the
bugs, or look at mono release notes. Just look at the list of shiny features
of Mono ([http://www.mono-project.com/docs/](http://www.mono-
project.com/docs/)). Well half of that crap is either broken, or was never
implemented, or just doesn't work as documented. Everything is just a lie that
should make it look good. Xamarin does thousand things, they release new iOS
SDK the same day Apple releases it ... wow ... if only they waited a year and
then released a working version instead. They make thousand cool features, but
they're all broken.

All developers make mistakes, we all create bugs ... but software that costs a
thousand dollars should work. It shouldn't leak memory like a total noob, it
shouldn't crash the compiler when you compile, and it should work the same way
when you compile once and when you compile twice, really the compiler is
sometimes just so broken.

PLEASE STOP ADDING NEW THINGS, STOP MAKING INTERFACE BUILDERS AND SHIT THAT
WILL NEVER WORK, AND JUST FIX SOME BUGS. I want to say something positive, but
really I just want to scream and cry and I don't know what to say.

I wish I could use something else, I wish I could go back to doing things
native, but the things I work on are too invested in Xamarin that there is no
way back ... I guess I'll just have to run away.

Oh btw, in case you're writing something important, like something working
with money, or human lives, or just moving around pictures of cats, pick some
other technology, maybe go with native C++ if you want to share your biz
logic. Maybe write it as a native things, just please, be careful. There are
dragons here.

A closing thought. Xamarin is trying to do something amazing. Xamarin.Forms is
an amazing technology and makes me really happy at times ... but then I try to
do something special and find 50000 completely stupid bugs on each platform,
and I start raging again.

Please Xamarin, I'm begging you, allocate more humans to fix the bugs,
stability is important. And if you manage to accidentaly fix something, please
don't break it. I'm always shitting my pants whenever there's a new update,
because almost always things get broken.

P.S. I'm writing this anonymous because I'm trying to say what is really in my
heart. I wouldn't be able to do this in any ot her way, because if certain
people found out, I could lose my job, and I value it too much. But still I
think this is the right thing to do. I'm not trying to put a bad light on
Xamarin, I just want to express my feelings.

------
jagawhowho
Seems he already knows the solution. Go native with c/c++. Re-write the front
end per platform.

~~~
cageface
This works pretty well on iOS where you can transparently mix C++ and ObjC but
on Android you're looking at JNI hell.

~~~
pjmlp
Still way better than having to deal with JNI hell plus whatever code, that
you don't control, sits between your application and the JNI calls.

My little Qt review, which I posted in a sibling thread, reminded me why using
the platform tooling is always the best approach.

