Hey xamarin guys, i know you visit this site. Can you call my boss and convince him to use your product for me :D
we got a growing staff with an expertise in C#, and he's decided to have one of his guys write each new mobile app in java or objective c, despite the fact that no one else has experience in these languages.
but most of all, i know i'm one day going to have to look at the code base for one of these apps, and I dread it.
I simply love mono, and find that C# is an amazing language, but I also find that mono's project on github is a bit of a mess, and I really hope this motivates them to clean it up, and provide better documentation on the internals.
Agreed. We actually gave mono a thumbs down as choice for a recent project because of similar concerns. Xamarin support for the project seems to have slowed as they have moved into mobile dev tools. As examples there has been no official release of version 3. The last stable version is 2.10. Second there is no indication they will add Web API support, arguably the most important recent ASP.NET addition for those looking to do a REST interface in .Net.
Congrats to the Xamarin crew, this is well-deserved. They've been cranking out some really useful products and doing a good job of building products that layer nicely on top of the free Mono stack instead of gutting useful features out of it to try and sell them to you.
These guys slogged through an incredibly grueling task - porting the entire .NET Framework and C# language - through some really hard times. I'm glad to see that it's paying off for them!
I wonder how accurate this chart is. The last time we really wanted to port something from .net to mono (3 - 4 years ago) windows forms was supported, but it was a mess. It worked 90% - but the 10% never got fixed. Problems popped up in the strangest places (rounding of numbers). Impressive as a proof of concept, but we've stopped trying to support mono and never looked back.
Just wrapped up my first project at work with xamarin.ios and also used monomac for some tools. It was awesome. The app used a bunch of opengl-es on ios and everything went very smoothly. I'm always glad to see them pop up on HN.
While it is fine to pay for dev tools, IDE, I find unacceptable that the language (a raw compiler) and libraries have a shareware ($400-$2000?) or any other commercial model.
At least they have a free version to play with. They didn't even have that a while ago.
I'm not in the mobile apps business, but if I were, I would consider the price worth it.
As a freelancer, I see a lot of people requesting Android and iOS apps. I don't see myself developing in both Objective-C and Java. With Xamarin I could cover three platforms with one language, which also happens to be my language of choice for productivity.
I kinda thought the same thing and its especially attractive since I've written a lot of C# code. But I discovered that the Mono mobile framework wraps the respective devices UI APIs fairly faithfully - and learning those is the more laborious part. In other words, it doesn't abstract all of the devices and you still need to understand how to code for each one. You just get to do it in C#.
I still think it has great value and you most likely could share some of your code between devices. It just wasn't as seamless as I had thought supporting multiple devices. I think HTML based apps do have that one advantage.
The MvvmCross pattern they've been promoting seems promising for maximizing shared code. We've got the most benefit from sharing stuff like libs, network code, GLES, etc. I've come to the conclusion that the thin platform API is an advantage because I'm so, so tired of punching holes through crappy abstractions.
I think that the language (and its "batteries", i.e. std libs) should be separated from the product, because products die.
Xamarin model - while it can be fine for a short stint, I don't think it is good for a long-term relationship.
For me, Xamarin developer is kind of associated with Clarion developer, PowerBuilder developer.
You make a fair point and I normally share your view about compilers and tools. I think the Xamarin situation is complex, though, because most of the product is already open source. The C# compiler and x86 runtime, the standard libs (System.*), and the IDE (monodevelop aka Xamarin Studio) are all open source; and the platform bindings are a thin, almost 1:1 layer covering the iOS and android APIs. What you're really paying for is the AOT mechanism, packaging, and ARM runtime -- it's about all that's left they can sell. It's also worth noting that a ton of their code goes back into mono and associated projects.
I still think you have a good point, and I agree, but as for myself, I decided to make an exception in this case. I don't think it's quite as bad as PowerBuilder or Clarion at least.
to be fair monodevelop and xamarin studio are not equal. The first is low supported and full of bug but free ( i think that is voluntary), the second is not free (at least not if you want to do something decent) and is the main focus of xamarin.
I would say they try to "trap" you in mono with monodevelop to then oblige you to buy something more decent as xamarin studio.
Xamarin Studio and MonoDevelop are the exact same code base.
The only difference is that Xamarin Studio contains the iOS and Android plugins, plus adds a Xamarin Branding (branding is completely pluggable in MonoDevelop)
Mostly because they would have to provide their own Mono runtime as there's too many variations in the vast number of Linux Distros out there. That combined with demand is much lower than that of Windows and OSX for Mono.
I wonder how many more like us are out there. I got off the Microsoft train a while ago but always loved C# the most. I use it on linux, mac, mobile; my hope is that this becomes more mainstream and less awkward from a "what kind of dev are you?" standpoint.
Huge congrats to the Xamarin folks. I'm a huge fan of their products. Personally, I've found their tools for Android development to be less cumbersome than Google's tools for the same. I was extremely impressed by their Evolve conference as well. Great engineering and great, friendly, responsive people. Kudos!
I've recently become a Xamarin customer, and I haven't looked back yet. I'm very impressed at how mature the platform, the docs and the tooling are given that it's not from $BIGCORP.
Admittedly, there are a few bugs here and there,mostly in the build chain, but they get fixed fast and support is excellent.
The only feature request I have is to allow us to give feedback on the docs. Whille 95% are awesome, there's little mistakes here and there. I suspect customers will gladly help trace those down.
We used to use monotouch a lot, but as soon as we tried to use any third party sdk it was a huge mess. All of the ones supplied by xamarin never quite worked/were out of date and threw a bunch of weird errors.
Of course there is a way to write your own bindings, but the those threw a bunch of undecipherable error messages as well and never really worked either. The main problem was that there were way too many possible sources of the errors to try and just diagnose the problem and the error messages themselves were useless.
So basically xamarin was great as long as you didn't need to use a third party sdk and there is 0 chance that down the road you might need to use a third party sdk.
That was really the deal breaker for us, that we were severely limiting our future capabilities on any app we made with monotouch.
Also it is often difficult to pull in third party c# libraries because monotouch uses weird versions of all the main .net references. But this was not the main problem.
In the end it is just much easier to bite the bullet and use obj C.
I had high hopes for Xamarin. The appeal of it was strong: I could program in a functional language (F#) with libraries (.NET) and share my work with friends on Mac, Windows, Linux, and Mobile.
Unfortunately nothing worked. I was blocked at every turn.
The FSharp.core assembly is in someway there and not there (create a project and it's in error-red text, but the compiled app runs). I asked and asked on the IRC channel how to fix it. Programs compiled in Xamarin would work on the host OS, but on Windows would complain about missing assembly. The same project on Xamarin would not compile in Visual studio for the same reason. I never figured out how to properly build executables for both windows and both, or how to arrange my project files to work on Xamarin Studio and Visual Studio. I never figured out how to fix this.
I also tried to play with GTK with F#. Their GTK builder is C# only. OK, fine. F# isn't 1/10 as popular as C#. I know.
So how about iphone? I could drop ObjC, rewrite my app in a language I admire, and finally bring my app to android. However, the sample F# ios app, without modifications, compiles to an executable that is too big for the trial limitation of Xamarin Studio. Wait, the sample "hello world" app (which is supposed to convince that the IDE is worth paying for) can't be run in the trial version of Xamarin Studio? I asked and lurked for days in the IRC channel. In a patronizing exchange with one of the developers, I was told that the Fsharp assembly needs to be embedded into the ios binary. Because of this, the trial limit is reached. An update will fix this later.
Oh well. Nevermind. Once again, I'll shelve the idea of cross platform development.
Common, F# is like 1% of their customers. Even Microsoft does not support F# as much as C#. JetBrains ignore it as well. I keep coming back to this language but I see no enthusiasm in Microsoft for it.
I love mono. I think it's a great thing to try and bring .net/C# to more people.
But seriously guys, can we get System.Data.SqlClient to the point that it's production ready? the only thing that's holding us back from rolling mono in production for our entire stack.
I can't speak to Rx, but I use LINQ to objects and LINQ to XML frequently. Async/await is also supported in mono 3 and is in beta for the Xamarin tools.
It's awesome they exist. Otherwise it would've been HTML5 vs native. First won't be ready for a long time, second means different high-level languages for each platform.
we got a growing staff with an expertise in C#, and he's decided to have one of his guys write each new mobile app in java or objective c, despite the fact that no one else has experience in these languages.
but most of all, i know i'm one day going to have to look at the code base for one of these apps, and I dread it.
reply