
Why choose Xamarin? - pauloortins
http://www.pauloortins.com/2014/06/25/why-choose-xamarin/
======
keithwarren
It amazes me that the constant complaint on here is the price. Seriously
folks, if you are a professional developer (by that I mean your primary
ability to earn money for you and your family is the development of software)
then the cost of a Xamarin license should be looked at as a factor of time.

How much time will it save you? Lets imagine your current project to build an
iOS and Android app of identical functionality you are estimating at 6 weeks
for each platform. 12 total weeks. Lets say that Xamarin tech gives you a 10%
boost (it will be much higher but lets be conservative), that means over the
60 business days, you get back 6. Assume you have 8 hours of work per day and
you just bought 48 hours of your time. The basic license which does nearly
everything most people need is the Indie license and $300 per platform. Six
hundred dollars to buy 48 hours of your time back means the purchase is viable
if you value your time at more than 12.50 per hour.

If you value your time less than that, you have bigger problems than which
mobile tooling to use.

The truth is the productivity factor is much higher than 10% and the license
is good for a year, pick up a couple other projects like this through the year
and that number collapses. For me this year I will probably do 4 cross plat
projects with Xamarin and my productivity diff is north of 50%. The purchase
is a no brainer.

~~~
mjt0229
Here's the problem: it's too expensive to learn on my own, and I can't
advocate for C#, F# or Mono without already being an expert. Yes, I am a
professional software engineer, and I support my family that way. But I have
other expenses and interests, too, and blowing money on a
compiler/IDE/platform just so I can play with it in my spare time doesn't
really work for me.

Think of it another way: how do you plan to grow the next generation of
engineers if they can't afford your technology to learn on, but they can
download a JDK and a good Scala IDE for free?

Moreover, I'm not sure how you're arriving at a 10% productivity gain without
knowing what I'm already working on. It may be 10% compared to Objective C for
iOS, but is it 10% for my server-side Scala project?

~~~
mjt0229
Maybe the tacit assumption here is that I'm doing development for Android and
iOS; I'm currently interested in neither, although I do think F# is a
compelling language and I'd love to be able to advocate for it at my
workplace. However, given the fact that we're a Linux shop, Xamarin has made
it really hard to push for Mono/F# as an alternative to Scala.

~~~
keithwarren
Another thing that colors my perspective - I have been on my own for 15 years.
I don't have to consider the company, legacy or other devs in the shop. It is
me, whom I choose to sub-contract to and what jobs I choose to take on. There
is a level of freedom in that I often take for granted.

~~~
jaegerpicker
Right and as an independent dev Xamarin makes a mertic SHIT ton of sense,
though once Ruby Motion has Android I'd argue that is a way better value. But
as a guy working a day job hoping to bootstrap a startup/indie game on my
nights and weekends $600-$2000 is ALOT of dough to drop, Ruby motion is $200
and I can swing that without much of a second thought, honestly I could swing
$600-$2000 is within my range also I mean I'm extremely lucky in my salary
compared to the rest of the world but it's A LOT harder to justify on top of a
$3000 macbook pro retina, an intellij license, and the rest of my day used dev
tools. Not trying to attack you on your stance I just would love Xamarin to
rearrange their pricing to something that makes sense for different markets. I
know that $20 a month plus 15-20% of app profits or something more flexible
may make them much more popular with certain crowds.

------
fidotron
The killer problem with Xamarin is to use it effectively you have to be expert
in both Xamarin and the native platform you're targeting. This is because most
of the work of mobile apps ends up being tied to the UI, which has a platform
specific API.

If your app happens to deviate from this, then at least for Android once more
you're in platform specific land (for example, services), but I've seen people
doing things like rolling their own ghetto mini database in C# to give
themselves a portable data model, when it would be faster to use SQLite on
Android and iOS, just to justify the decision to use Xamarin at all.

So, it can work, but people have a tendency to greatly overestimate how much
of a mobile app can actually be platform independent anyway. Games are a
different proposition, and this is one reason why Unity has cleaned up.

~~~
keithwarren
YMMV but for me, there was not 'learning' of Xamarin. There really is no
Xamarin framework - there is the mobile frameworks themselves for which there
is an almost 1:1 translation. CalculateFoo in ObjC or Java will in nearly
every case be CalculateFoo in C#. In the cases where the recommended method is
to use a higher level abstraction (like for table data in iOS), the option to
use a mirror of the ObjC pattern is there but there is an easier approach
available if you choose that.

The key for me was understanding the idiosyncrasies of both Android and iOS
and their patterns and then using C# to craft as much reusable code as
possible. It drives my approach and I failed to get the re-use level I wanted
on my first true cross platform app build, but since I have learned those
lessons I have gotten much better at it.

(note: I have yet to use Xamarin.Forms, this experience is based on Xamarin in
the past 15 months)

------
romanovic
Someone mentioned Titanium earlier. Titanium shares the major advantages Paulo
points out in his case for Xamarin (i.e. single language, cross-platform,
native apps, access to native APIS). But Titanium also has a couple clear
advantages over Xamarin:

    
    
      - Titanium is FOSS - Xamarin's cost is merely very inconvenient; its closedness is much more repulsive
      - Titanium doesn't sideline those of us who develop on linux (a linux-based OS rules the mobile market, after all)
    

On the other hand, C# is a beautiful, evolved language that I would love to
try out with mobile development, and I can appreciate a shiny IDE. However, as
long as the above conditions apply, I'll always consider open and developer-
friendly solutions like Titanium first before resorting to Xamarin.

------
jasallen
Xamarin's IDE is not as good as VS, but it is often much better than XCode,
and C# and F# are both more pleasant languages to work in for people with the
vast majority of experiences (C++, Java, .Net, Ruby), so even without all the
cross platform goodness I prefer to work with Xamarin. (Swift may change some
of that, I haven't looked into it yet).

I've never had a problem easily translating Obj C StackOverflows or blog posts
to Xamarin/C# so essentially you get the whole community as well, with no
worries about Xamarin specificness.

That said, I think their current pricing structure makes sense for them right
now. They are not 'quite' at the polish level, not quite at the level that
average people can do things averagely. There is still just a little more
cross platform knowledge and effort required. The price serves as both a
barrier to entry to manage the community size, and provides them enough
capital (on top of outside investment) to keep investing toward a fully mass
market approach.

------
ogdenyogly
I have done a lot amount of development in MonoTouch / MonoDroid (full time
for about 2.5 years now). I started using them back when they were beta, and I
would wager we have one of the larger apps written in Xamarin (about 250kloc).

First of all, it's tricky. It took our team a long time to get the rhythm of
simultaneous Android/iOS development. For a long time every single push broke
something.

Some annoyances:

Visual studio project files don't merge. You need a special xml aware merge
tool to do this. Even then, its a pain in the ass.

It can be very tricky to abstract the differences between Droid and iOS if
you're interacting with the OS a lot.

Some things to know:

Just because you're in C# land, doesn't mean your API is. You're going to
spend a lot of time implementing stuff in C# that feels wrong because your API
is ObjC/Java.

Sometimes there isn't a good mapping between NS data types between the APIs.

You're going to spend a LOT of time in the iOS / Droid docs, so you'd better
be comfortable with ObjC / Java.

Overall I'm happy with the experience.

------
jaegerpicker
Personally I much prefer Ruby Motion to Xamarin. I like ruby more, it's a
closer work flow to my standard python/django, Ruby/Rails based workflow
(terminal and text editor based). Intellij provides a great ide (MUCH better
than Xamarin studio, one of my least favorite IDE's all though visual studio
is even better than intellij's offerings IMO). In version 3.0 they will offer
Android support and at that point I think Ruby Motion will be the best native
app option.

Almost forgot to mention that, all of the ruby is compiled down to actual
Native obj-c runtime code. Great performance and look, as good as a regular
Obj-C or Java app.

~~~
declan
Thanks! I wasn't aware of that announcement. Last month's blog post says: "If
you have a RubyMotion app for iOS or OS X and want to port it to Android, you
can even share some of the code."
([http://blog.rubymotion.com/post/87048665656/rubymotion-3-0-s...](http://blog.rubymotion.com/post/87048665656/rubymotion-3-0-sneak-
peek-android-support))

I haven't used Ruby Motion myself -- do you know how much of the code can be
reused excluding platform-specific UI stuff? There's a significant difference
between 5% and 95%. :)

~~~
revelation
From the blog post, that seems like a rather perilous approach.. what are the
chances they get all the builtin Ruby stuff to work the same way despite
basing it on Java equivalents?

~~~
declan
And what are the chances they get all the Android Ruby stuff to work perfectly
in the initial release? As opposed to 6 months later after the bug fixes are
deployed; hope you didn't have a release window for that fall 2014 app!

(Perhaps I'm overly cynical, though I've seen this before on other platforms.)

~~~
jaegerpicker
Actually I'd say pretty good as their software has been really high quality so
far. That and the fact that JRuby already exists and I'm pretty sure thats the
target runtime, a lot of their work is already pretty solid.

------
atwebb
I realize that the difference of $700 could be made up in improved development
performance but I really, really wish they'd allow VS support for the indie
license. It's not a case of saving more it's a risk/reward thing for me. I can
see the possible value but, without being able to pick it up quickly in an
environment I know I can't justify either spending an extra $700 or picking up
another IDE/workspace along with the curve of mobile dev and setups for the
different devices. Though I understand the cost, it provides tremendous value
and you can't just give that away for free.

~~~
AUmrysh
It's clear to me that Xamarin is trying to get everyone to pay right now. The
free license won't even allow you to build the Xamarin.Forms demo, and Forms
is one of the most significant new features they added. Cross platform apps
with a common UI and codebase, no more separate views for each platform, and
data binding! I think they're scaring off small developers by requiring the
several hundred dollar investment to use Xamarin, even if it is a great
product.

Where I work, we chose Xamarin over PhoneGap/Cordova.

~~~
pauloortins
Totally agree. Prices could be lower and they would have a bigger market share
in mobile development.

------
zura
Why not choose C++/Qt/QML?

~~~
general_failure
AFAIK, QML has barely any native UI integration. Are there iOS and Android
components? Why does nothing turn up when doing a simple google search?

~~~
RayDonnelly
This email just in today:

[http://lists.qt-project.org/pipermail/android-
development/20...](http://lists.qt-project.org/pipermail/android-
development/2014-June/000388.html)

It's native look and feel though, and not native integration. However AFAIK it
goes to great lengths to blend in with the actual device you're running it on.

------
yesimahuman
It's a common misconception that phonegap and cordova don't have the same
access to native APIs. They do, but they are limited by what plugins are
available, and your ability or interest to build ones to fill the "gap."

For example, I wrote a plugin recently to send low-level broadcast UDP packets
on Android and iOS through Cordova. The plugin API is just a bridge and sets
up a calling convention for Javascript-to-native code.

~~~
McGnarlySheen
100% true. I'm going to piss many off by this statement I'm sure... but if you
are a web developer Xamarin offers no advantages against PhoneGap/Cordova I
don't know anyone that is "just a C# developer" and hasn't done any web
development, maybe Xamarin makes sense for those.

Take a look at Ionic Framework if you think PhoneGap/Cordova can't provide a
native look and feel.

------
gte910h
I want to use Xamarin like
[http://www.remobjects.com/elements/hydrogene/](http://www.remobjects.com/elements/hydrogene/)
remobjects c# works.

(Well, I guess I'd prefer to use it in F# too).

How well does it work to ignore the .Net parts and just use the nice
IDE/Packaging/Not java story?

------
rational-future
The big question IMHO is will Microsoft buy Xamarin or not. If they do the
price will certainly fall drastically. On one hand it will give MS way more
apps on their app store. On the other if Xamarin becomes very popular Apple
may block Xamarin built apps from it's app store.

~~~
EShy
Apple tried blocking certain platforms in the past, at that time Xamarin
wasn't included since they are following the guidelines set in Apple's
developer terms of use. Apple changed their mind very quickly about that
decision too.

Xamarin still requires a mac. Your code is still compiled using LLVM (or
whatever engine Apple will introduce later). The resulting app that is
uploaded to Apple looks just like an app that was built using XCode.

It will be interesting to compare a simple app and see the difference in the
resulting package between Xamarin and XCode

------
will_work4tears
How does Xamarin compare to a more open (and free) solution like MonoCross?

~~~
mousetraps
You can't really compare them. MonoCross is a crossplat MVC framework that you
use on top of Xamarin's Monotouch/droid/etc. to increase your shared code.
Xamarin allows you to write about the same code for multiple platforms, but it
doesn't make it easier to share the same exact code. E.g
[http://components.xamarin.com/view/xamarin.mobile](http://components.xamarin.com/view/xamarin.mobile)

The code looks similar across platforms, but it's not exactly, the same - you
can't make one change and have it carry across to all platforms. Monocross
brings you closer to a write-once for all platforms experience.

A better comparison is Monocross v.s. MvvmCross

~~~
will_work4tears
Ah, thanks, I didn't catch that MonoCross required Xamarin - it's not obvious
from the homepage at all (or even looking for it on any page).

Was hoping to use it to learn some C# (beyond the simple hello world type of
thing) - Xamarin's pricing is pretty steep for an amateur/hobbyist.

------
sschalk
There are so many factual errors and outdated assumptions in your thread that
i wont take the time to do a writeup. To put it short: \- You're wrong. \-
Given the current speed of Javascript on mobile, Xamarin is just a job
creation tool for unemployed .NET/WPF Developers. - You cannnot reuse run-of-
the-mill web devs for hybrid app development. \- Good web developers are just
as expensive as good native devs. \- Hybrid app development is not easier than
native development.

Have a nice weekend.

~~~
McGnarlySheen
I forgot to add this to anyone who disagrees with this comment. Take a look at
Ionic Framework if you think PhoneGap/Cordova can't provide a native look and
feel.

------
montspencer
Xamarin recently released special pricing for small businesses and startups.
Just FYI!

