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.
Integrated support libraries and such for things that you need to do for almost every project, compare reading contents from a URL in C#: WebRequest.Create("http://www.google.com/").GetResponse()
I can't even think of a way to do it safely in Java without "BufferedBuffer" hell
Integrated libraries cause one of .NET's biggest problems, though: the "if it doesn't come from Microsoft, it doesn't matter" effect. The Java ecosystem's openness provides you a lot of choice and has created a lot of innovation; Coda Hale had a good article on the topic[1]. I don't feel like there's a ton of non-Microsoft innovation in the .NET community--there's some iteration and a lot of (often poor--hello, NuGet) porting and adaptation, but there aren't many people doing something like Scalaz Streams on .NET.
Even setting aside advancement and research, it's hard to really create a real competitors to Microsoft's existing solutions even when they're terrible. NHibernate is the "best" one I can think of and it's kind of trainwreckish. Outside of that--like, NancyFx has been around a long time at this point but hasn't really made a dent, whereas the JVM application server is rapidly losing ground--and it literally cannot come soon enough for my liking--to frameworks like Dropwizard or Play. You can fight the Man on the JVM and win; I'm not sure you can do so on .NET.
That isn't to say .NET doesn't have some significant pluses. If you stay in the sandbox and can stomach having to deal with non-Unix command line tools or Cygwin (haaaa ha ha ha), it is really really nice. But the second you go off-roading, bring a helmet.
Besides JVM tuning hell? Tooling. Eclipse is a disaster ( out of the box). Intellij IDEA isn't much better, although it is better than anything Xamarin produces by a mile. As far as Java vs C#; the gap is definitely closing with anonymous functions in J8. But C# has had lamdbas and LINQ for a while, and I don't see anything close to LINQ in java.
Overall I like Java quite a bit, it's the first thing I reached for when I migrated away from .NET development, but Eclipse/Java dev still doesn't feel as snappy on my Macbook Air with 4Gs of ram as dev with VSExpress 2005 was on my old Dell. Le Sigh.
I agree that Eclipse is a dog in terms of resources. On the other hand, it comes with a bazillion features that last time I looked are not standard in Visual Studio. Also, Ctl-Shift-T/Ctl-Shift-R, which are my go-to functions, are so superior to the Visual Studio search it's not even funny.
The IDEs are generally a bit rotten in Java-land--though I feel you're underselling IDEA a bit, I find it pretty rad--but most of the JVM folks I know reach for Scala. I see more and more people going to Scala as the "big gun" when you want largely functional, primarily immutable idioms on the JVM. If you're comfortable with C# you'll find many features you're used to--like LINQ-esque functional modeling, though Java 8 adds some of that--in Scala. (You'll also find a lot of other stuff in it; at this point I have a good handle on it and use a lot of "fancy" bits of Scala but Scala would sure benefit from a Scala: The Good Parts book.)
(edit: JDK8 and the G1 collector have made my life a lot easier when I have to tune the JVM. I think you gotta cut it a little more slack these days.)
I'm not sure that's true anymore. Some subset of .NET is supported for RT, but so is C++. WinForms is deprecated and it seems like everybody hates WPF, so there isn't a great .NET story around desktop UIs right now. It's a bit of a cluster.
Since Microsoft doesn't care about WPF anymore people started pretending they like HTML5 and JS, kinda like "hey, dirt doesn't taste that bad if you give it some time!".
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.
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?
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.
JVM's garbage collector and JIT are better, they have benefited from several more years of development. But CLR offers so many other advantages (in particular interoperation with C, SIMD, and reified generics) that I lament that CLR is Windows only. Yes, I know Mono exists, my lament remains.
Zing is amazing and I legitimately wish I had a reason to spend the money to play with it. In the interim, Shenandoah seems pretty cool (aiming for 10ms pauses for 100G heaps) and it's open so it's easier to lpay with.
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.
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.
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.
Part of the reason to use Xamarin is in order to take advantage of C# and F#. Using JavaScript throws away or inhibits a lot of useful stuff like static type checking, automatic completion and refactoring, and code browsing. Besides, they’re invested now; switching to another language may be too costly at this point.
Over time I've become convinced that the two really viable options are dynamic typing or really good static typing; TypeScript occupies a middling and very rudimentary spot compared to F# (or Scala, which I have more personal experience with; ScalaJS is interesting but I have some pretty huge reservations about that).
TypeScript's types are way less powerful and expressive than F#'s. The comparison really doesn't fly. It's even less powerful than C#'s, and it doesn't even come close to adequately supporting a whole range of JavaScript patterns (such as generating "classes" - constructor functions - at runtime).
My experience has become that TypeScript is really only suitable for classic OO domain programming, with many nice little classes and mutable state. I work on a project where our model layer (MVC) is made like that, and it works like a charm.
Interfacing with other libraries tends to work ok, but you'll have to forget about using --noImplicitAny (and hand in a whole bunch of safety guarantees with that). Doing non-classical-OO stuff quickly becomes a pain. I recently spent many days making a nice Om-style immutable model layer with TypeScript and Immutable.js, and it just doesn't work. The generics simply aren't powerful enough, and I spent days (and many worthless lines of code) fighting it. This saddens me.
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.
I haven't really used it but I guess I would classify it the same as Titanium. If you're building content apps then it might be really good. I guess it all depends on what you're trying to achieve.
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.
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...
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.
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.
A lot of fans of Microsoft/C# (Myself included) would love to see some sort of acquisition happen. They definitely have some sort of relationship already. What I do find really interesting is that Microsoft seems to be pursuing Cordova (aka PhoneGap) as well.
> 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.
My experience with Ruboto has not been good. Gave it a try during a sojourn away from Xamarin (which I use for the game I'm making, but Ruboto was for something else) and its perf was really unfortunate on a Nexus 4, not much better on a Nexus 5. You'll end up writing anything nontrivial in Java anyway, making a lot of it moot.
> 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.
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.
In principle, Xamarin Forms should enable many common UI elements, like list views, to be coded cross-platform. In practice, I wonder if that holds up well w.r.t. hooking the list views up to the model behind them. But, nonetheless, Xamamrin supports both cross-platform and native UI elements, which seems like a practical approach.
All that said, I would normally advise a client not only to have native code, but also large amounts of native design for their main platform targets. Lots of Android apps suffer from port-itis. Transliterating an iOS implementation inevitably makes for a lackluster Android app that underutilizes Android modularity features among other things Android does well.
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.
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.
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.
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.
..and his position that proper tail call elimination is an irrelevant detail did not help the F# cause on Mono. Some people just dont get how important tail call eliminations are in some languages, "just write loops" is not a substitute, not even close.
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.
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).
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.
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.
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.
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/ 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/). 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 stu...
RemObjects 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/) includes a comparison with Xamarin.
75 comments
[ 3.3 ms ] story [ 137 ms ] threadThey make fantastic tools, but they really do only target Windows.
I can't even think of a way to do it safely in Java without "BufferedBuffer" hell
Even setting aside advancement and research, it's hard to really create a real competitors to Microsoft's existing solutions even when they're terrible. NHibernate is the "best" one I can think of and it's kind of trainwreckish. Outside of that--like, NancyFx has been around a long time at this point but hasn't really made a dent, whereas the JVM application server is rapidly losing ground--and it literally cannot come soon enough for my liking--to frameworks like Dropwizard or Play. You can fight the Man on the JVM and win; I'm not sure you can do so on .NET.
That isn't to say .NET doesn't have some significant pluses. If you stay in the sandbox and can stomach having to deal with non-Unix command line tools or Cygwin (haaaa ha ha ha), it is really really nice. But the second you go off-roading, bring a helmet.
[1] - http://codahale.com/when-formality-works/
Overall I like Java quite a bit, it's the first thing I reached for when I migrated away from .NET development, but Eclipse/Java dev still doesn't feel as snappy on my Macbook Air with 4Gs of ram as dev with VSExpress 2005 was on my old Dell. Le Sigh.
(edit: JDK8 and the G1 collector have made my life a lot easier when I have to tune the JVM. I think you gotta cut it a little more slack these days.)
(I like WPF. But I'm weird.)
We even get to have the "J2EE" version of .NET with all those model view patterns.
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...
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.
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.
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.
Bioinformatics
(I know, I should be using D, you say)
EDIT: Should have mentioned Zing instead of Azul.
It is a bit hard to search while on the move.
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.
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.
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.
My experience has become that TypeScript is really only suitable for classic OO domain programming, with many nice little classes and mutable state. I work on a project where our model layer (MVC) is made like that, and it works like a charm.
Interfacing with other libraries tends to work ok, but you'll have to forget about using --noImplicitAny (and hand in a whole bunch of safety guarantees with that). Doing non-classical-OO stuff quickly becomes a pain. I recently spent many days making a nice Om-style immutable model layer with TypeScript and Immutable.js, and it just doesn't work. The generics simply aren't powerful enough, and I spent days (and many worthless lines of code) fighting it. This saddens me.
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.
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... 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.
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.
http://www.visualstudio.com/en-us/explore/cordova-vs.aspx
https://www.ibm.com/developerworks/community/blogs/mobileblo...
Weird.
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.
http://blog.rubymotion.com/post/97668474211/announcing-the-p...
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.
I think RubyMotion could be a good idea, even today, for someone that knows and use Ruby for his own projects.
Except this is not possible, as you have to recode the UI for each device anyway.
So just go C++, or any other language with compilers that can target C, and do as little as possible in the UI part.
Companies like Dropbox are following this approach.
All that said, I would normally advise a client not only to have native code, but also large amounts of native design for their main platform targets. Lots of Android apps suffer from port-itis. Transliterating an iOS implementation inevitably makes for a lackluster Android app that underutilizes Android modularity features among other things Android does well.
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.
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.
I liked Miguel de Icaza's measured, helpful way of saying 'get bent':
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.
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.
Xamarin requires anyway an UI implementation per device.
The time spent fighting integration bugs can be used in productive coding instead.
My little Qt review, which I posted in a sibling thread, reminded me why using the platform tooling is always the best approach.
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).
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.
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.
I just stumbled upon this 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/ 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/). 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 stu...