
Ask HN: Is Xamarin worth learning? - ceeK
For context I&#x27;m a day to day iOS developer. However I&#x27;d like to quickly be able to make cross platform applications, and React Native is apparently lacking for Android.
======
grezql
Xamarin Native developer here, I started off by trying to create a Pokemon Go
Map app. Although I got off to a quick start, slowly it downed upon me that I
started spending too much time finding fixes for Xamarin issues rather that
programming. I used macbook as agent and visual studio as IDE. Sometimes the
deployment would take 5 minutes! I then had to restart the agent to fix it. As
a programmer I am rather a person who runs a code, change a little bit in
code, then run it again. If I dont understand things I google it or find the
documentation. Thats my way of learning things instead of reading through
programming books.

For me Xamarin Native was slow and rigid. I highly doubt I could make
'innovative' apps with Xamarin. Maybe it is okay for people who want simple
things like a "to-do app" or somethign that fetches list of images and
displays it.

I wanted more and found no solution for things I needed, so I gave up and
started xcode (swift + some objective c).

And let me be clear here, if I had spent same amonut of time on xcode as
xamarin I would have been iOS dev master :)

Things just works much better. You can do anything you imagine with Xcode and
swift. With Xamarin its more like find whatever library is out there and try
to create something by combining these. Too many bugs.

This is no sly dig on Xamarin or Microsoft as I use alot of MS products
myself. I have also tried phonegap, react native etc. and Xamarin is the best
when it comes to cross platform without a question, but none of these can
match true native coding (xcode swift/objc)

~~~
rogihee
I use VS2015 a lot for .Net ASP dev, but when I do Xamarin iOS dev I tend to
do it in Xamarin Studio on the mac.

Much better experience, fast deploys/builds. I miss Resharper but can live
without it.

~~~
V-2
Very recently Microsoft introduced VS for Mac (although I understand it's sort
of a preview version).

I don't know about OS X, but I used Xamarin Studio on Windows and it was
horrible.

~~~
rogihee
That is a rebranded Xamarin Studio, with a slightly updated layout to match
VS.

It feels much better on mac I must say, also tried it on Windows but just
weird and slow.

I'm quite happy with it, but maybe I'm biased a bit because it sucked big time
and they made big improvements to it last year. It's all relative ;-).

~~~
milkytron
Are you saying Visual Studio feels much better on mac? If you've tried it, is
there a link to download so that I can try it out myself?

~~~
rogihee
No Xamarin Studio on the mac vs on Windows. Logical I think because Windows
has the real Visual Studio and Xamarin Studio Windows is based on GTK# (AFAIK,
I think the mac UI is native Xam since last year) it is limited on the Windows
side / feels quirky.

------
lanestp
I've been extremely disappointed in Xamarin. The main issue is that you don't
really get code sharing. I would estimate that only 25% of the Xamarin project
I manage is cross platform code. The rest is this bizarre merger of native
APIs with C#. It's difficult to write because of the lack of examples and
documentation. It's also buggy, even with simple things like page views.

The real problem is that I can write a native iOS app in a fraction of the
time it took to write a Xamarin app. Swift has improved iOS development speed
so much I'm not convinced we need cross platform app engines (excluding
games).

As for Android, yeah, native Android sucks. Activities and fragments are the
worst idea anyone has ever had and no one agrees on best practices. But even
with cross platform high levels of abstraction like Unity3D you still need to
understand them. So, my current advice is to suck it up and write it native
twice. Pick your favorite OS, start with that, and then port the logic.

~~~
king_magic
I've had completely the opposite experience. Have worked on several medium-to-
very large Xamarin projects (4 developers up to 60 developers) and rarely have
I seen code sharing drop below 50%, with the sweet spot being around 60%.

2 years ago, Xamarin was buggy as hell. Today, (IMHO) it's quite stable.

Edit: downvoted for sharing my experience? Stay classy, HN.

~~~
lanestp
Can you elaborate on what kind of apps are you developing and where you are
getting good reuse? My apps are generally heavy on the UI and moderate data
and I'm wondering where the sweet spot is.

~~~
xeromal
I've been doing Xamarin for about 6 months and I get most of me reuse in
services. Sure, manipulating the UI is mostly native code but the rest can be
reused such as the DB layer, API layer, and anywhere else you have business
logic.

------
mathijs
I've used Xamarin for several projects and I greatly regret that decision.
Granted, most of my hatred is targeted towards Xamarin Studio and
Xamarin.Forms so if you use Visual Studio and build only native UIs then maybe
your experience will be better.

However, in my experience, both Xamarin Studio and the build system are buggy
as hell. Random or inexplicable build errors, things that break during
updates, incompatibilities with official Android support libraries... I find
myself doing 'clean project and rebuild' to fix random errors, or switching
between alpha, beta and 'stable' channels all the time depending on which one
does not have the bugs that I'm running in to.

Xamarin.Forms is simply a disaster. Because it aims to unify the apis for the
UIs for various platforms it boils down to only the most common denominator of
those platforms. And then makes it worse. Not only is it buggy, it is also
very slow and incredibly limited. In our office we're keeping a list of all of
Xamarin's silliness we encounter, here is just one of those:

    
    
        "Clicking a Button changes its text alignment from center to left-aligned; it requires writing a custom Renderer to solve this."
    

I admit that Microsoft is usually quick to fix those bugs, but it doesn't
instill much trust in the system if you're constantly running into issues.
Many days I am literally working 50% of the time on my app and 50%
working/fighting my way around Xamarins issues.

I'd love to hear from someone using Visual Studio if their experience is more
positive, but my advise is: please stay away from Xamarin.Forms and Xamarin
Studio as much as possible.

~~~
dep_b
I can't find anybody that has done significant work with Forms and isn't
complaining about it. It's giving the platform a really bad rep.

~~~
ghuntley
Forms is not Xamarin. It's a DSL in the form of a NuGet (aka npm/cpan) package
developers can use to attempt to ignore the differences between the platforms.

It's kinda like swing. Great for throwing together a line of business
application and getting xplat ui for free. It's possible to build a performant
application with the framework but it abstracts subtle things that come back
to hurt you. For example. Forms apps on Android is a single activity, always,
period. Fragments are cycled in and out of this activity as navigation occurs.
This introduces subtle annoyances related to memory usage as the entire app
must be running vs thin slice. It transforms the lifecycle of Android into the
UWP or iOS lifecycle.

Again this is Xamarin Forms. It is not Xamarin. It has its place but please
don't confuse the product due to poor branding.

~~~
dep_b
I understand this, but how many people read these kind of angry rants on the
internet and realise there are more ways to use Xamarin than using Forms?

------
eonil
What you have to deal with;

* Xcode = iOS bugs + UIKit bugs

* Xamarin = iOS bugs + UIKit bugs + different runtime, language, memory model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs & overheads + C# bugs + slow followup of platform updates

* Xamarin Forms = iOS bugs + UIKit bugs + different runtime, language, memory model abstractions + .NET bugs + P/Invoke bugs & overheads + GC inter-op bugs & overheads + C# bugs + slow followup of platform updates + extra UI abstraction layers + lack of fine level controls & features

------
FlyingSnake
iOS developer with multiple years of experience of burning fingers in cross-
platform development here.

I've tried Cordova/Ionic, Xamarin, Dropbox Djinni, and native iOS development.
C++ is the closest I've got the a performant cross-platform solution, even
though it go it's own quirks.

The problem with Xamarin is it'll always play second fiddle to quick moving
targets of Android and iOS toolchains. In my case the Reactive Extensions
support was utterly broken, and Visual Studio kept crashing on MvvmCross,
Android SDK updates would make things hell, and I would waste at least 8 hours
a week to fight the toolchain. The promise of cross-platform doesn't deliver
much as you're trying to tweak your MVVM solution to Android/iOSs whims and
fancies, which leave you with a fragile common logic.

If you want to write a TODO list of simple CRUD app, it might work, but for
professional iOS/Android development, Xamarin is not enough. Xamarin doesn't
free you from learning ViewController lifecycle etc and platform specific
implementation details. So you're stuck on a foreign platform, with extra
overload of learning C#/F# along with Android/iOS platform overhead.

My Advice: Learn Swift and Kotlin, and do native development. Cross-Platform
is a illusion, and the road is paved with dead and failed projects.

~~~
ceeK
Thanks for the input. I do feel more and more that cross-Platform is a
illusion like you say.

I already know Swift. Do you think Kotlin would a better transition into
Android than straight up Java?

~~~
FlyingSnake
Kotlin is a breeze compared to Java, and it's conceptually similar to Swift
(syntax, null safety, type inference etc). I love Kotlin but it's not with
it's own quirks.

I would love to see a true cross-platform solution, but honestly it's a dead
end in my experience. I would say C++ comes close, but I wouldn't be surprised
if people feel unwelcome due to it's syntax and quirks.

------
ghuntley
Xamarin has unfortunately muddled their branding.

Xamarin Forms is not Xamarin, it is a DSL. You do not need to use it. At its
core Xamarin is c# with pinvoke to the underlying native platform
implementation. You'll still need that platform knowledge but now you can
share the core business logic between platforms.

To get maximum code share you'll need a MVVM framework such as ReactiveUI
which is based on the Reactive Extensions and modeled on functional reactive
principals check out
[https://github.com/reactiveui/ReactiveUI/releases/tag/7.0.0](https://github.com/reactiveui/ReactiveUI/releases/tag/7.0.0)
or [http://reactiveui.net](http://reactiveui.net)

~~~
theflagbug
Agreed, people seem to think Xamarin == Xamarin Forms, while the real power
lies in shared business logic with native UIs, in my opinion.

Xamarin Forms may be useful for internal super-CRUD LOB apps that really are
just a collection of input fields, but as soon as you do anything customer
facing, you should be using the standard native UI approach.

Also +1 for ReactiveUI, it completely changed the way I build apps for the
better.

------
zihotki
_MS stack developer_ I think yes, MS invests a lot into the Xamarin platform,
so I expect it to become more stable and more developer friendly than it was
before. I have a plenty of experience doing cross platform mobile development
and I tried several other alternatives, Xamarin was actually the best - easy
to start, easy to implement stuff, fast enough on mobiles, has a lot of
components, etc.

Also I would like to recommend to focus more on Xamarin.Forms, it's using more
modern approach. XAML (it's a xml-derived language) is actually quite good for
writing UI part. Add there some MVVM framework and you'd love it.

Edit: fixed spelling

~~~
miguelrochefort
XAML and MVVM are _much_ nicer to work with then their iOS and Android
equivalent. WPF/UWP/Xamarin.Forms are very underrated.

~~~
ghuntley
You can do the MVVM pattern on iOS and Android; it's an architecture choice.

~~~
V-2
Not quite.

For MVVM (unlike MVP and the like), you need the "glue" that ties viewmodels
to views. Rolling it out by hand is far from trivial, not to mention things
such as IDE support etc.

The official Data Binding library by Google - in my opinion, the only sane way
of attempting MVVM on Android - is fairly new. If I'm not mistaken, they've
only recently moved it out of preview stage, and they didn't tout about it
much anyway.

------
m_fayer
My experience with Xamarin is mostly on the Android side, so that's what I'll
mention. Spoiler: mostly positive, with some big caveats.

In no particular order:

Stay the hell away from Xam.Forms, unless it's improved drastically in the
last 6 months. Though I also think the whole idea is misguided.

For Android, go with Xamarin or Kotlin. I would take C# over Kotlin because of
the maturity of the language, the tooling around the language, and the
ecosystem. Either way, having a powerful modern language will be a godsend.

Concurrency on Android is much easier to deal with in Xamarin than with
native. This extends to things like complex orchestration of animations.

You will do backflips trying to get startup-time down. But once your app is in
memory performance is basically native-level.

Xamarin gives you some nice framework-level things that native Android
doesn't. A good API for sqlite and http. Proper data-binding. MvvmCross and
ReactiveUI are light-years ahead of anything that is available in native-land.

Xamarin builds are faster and more reliable than Gradle.

Xamarin introduces its own layer of bugs and glitches. You've added another
slice of Swiss cheese to the stack.

Xamarin plugin for Visual Studio is crash/glitch city. Xamarin Studio is
tolerable at best. Either way, your tooling will be faster but less feature-
rich than Android Studio.

Every time you want to use an existing third party library, you will go
through this process: Has anyone done an official binding for it? If yes, use
awkward Java syntax in C#. If no, try to find an unofficial binding. If not
found, try to bind on your own - 50% chance it just works, 50% chance you
fiddle for half the day and then fail. If it's the latter, try to decide if
you want to do a code-level port, or abandon your idea. Code-level ports are
possible nearly line-by-line, it's slow brainless work.

~~~
tonypp
I will re-iterate the "Stay the hell away from Xam.Forms" as we've used it at
work for almost 1.5 years.

I just convinced our management to move away from it when I migrated a page
from Xamarin.Forms to regular Xamarin.Android. The page render time went from
2,000ms to 400ms.

A quick glance on the now-open source code of Xamarin Forms now shows you why
the perf is so sluggish (the whole thing seems like it was hacked together by
a college intern as a week-end project).

Xamarin seems to have a marketing team that is far ahead of their development
team.

------
bobbygoodlatte
You might want to look into Exponent. They're a YC startup that build a
framework on top of React Native.
[https://getexponent.com/](https://getexponent.com/)

The team is made up of a few React core devs and some ex-FB folks. They
actually helped organize the last official React conf. The scope of what can
be built using Exponent is expanding rapidly. And you can build apps that are
virtually indistinguishable from Swift/Java apps.

If you want an example, I'd encourage you to download the Android version of
this app: [https://li.st/](https://li.st/)

~~~
FlyingSnake
> you can build apps that are virtually indistinguishable from Swift/Java apps

That is a very tall claim to make without any citations. All the cross-
platform toolkits lag behind native swift/java apps by at least some margin,
and the claim that JS indistinguishable from swift/Java is highly
questionable.

~~~
hobofan
How would you distinguish between the two if both are running above 60fps,
which RN effortlessly can?

~~~
FlyingSnake
> which RN effortlessly can*

I respect RN and the engineering behind it, however how can it beat the raw,
on-metal performance of Swift/Java? I'm not talking about CRUD/TODO list apps
like [https://li.st](https://li.st), but performance critical apps like
Spotify etc. Facebooks own apps are written in native code, IIRC.

I would love to be proven wrong here, and it would be great if you can provide
some sources.

~~~
jamesisaac
React Native is primarily aimed at writing cross-platform UI code. When it
comes to performance critical code, or integrating heavily with native UIs (eg
the media streaming abilities of Spotify) it's perfectly fine to drop down to
native code. RN provides an easy way to bridge between the JS and these native
components.

------
jmkni
I am using Xamarin.Android currently for a project, and I really like it.

One thing I love is that because it maps so closely to native Android
development, you don't need to look specifically for Xamarin.Android
tutorials/SO Answers/blog posts etc to learn how to do something.

Most of the time, information targeted towards native Android development will
apply to Xamarin.Android also, and you can basically map example Java code to
C# because they use the same classes/namespaces.

I'm going to be getting into Xamarin.IOS soon, hopefully the experience is as
nice.

~~~
jordache
It maps closely to android development? Then how is that a good soln for cross
platform Dev?

~~~
jmkni
You have access to all of the same namespaces that a native app does, and also
access to all of the namespaces included in .net Framework Standard.

You can stay within .net Framework Standard and share that code between your
Android/iOS/Windows Phone(lol) app, and reach into the native libraries when
you need platform specific functionality.

~~~
jordache
if the xamarin cross platform sdk maps closely to one mobile platform, how
does make it intuitive for iOS developers? Or are the classes aliased for each
target platform?

------
calferreira
I'm currently developing an app integrates Google APIs like SignIn and a
google product that i plan to make available on all major platforms
(Android,iOS,Windows).

In the beginning, i thought about making a hybrid app, because it could save
me time on the long run, but starting to developing with Cordova and EmberJS
or even Xamarin was frustrating.

My major reason for frustration is the tooling, cordova emulator just sucks
(Ripple?) and working with javascript mvc frameworks isn't just for me (too
complex IMHO).

Xamarin on VS has some bugs that would only go away if i restarted the IDE in
order for things to work. Also, i'm concerning about being dependant to a
third party framework.Can they keep up to speed with Google,Apple and MS?

Another valid concern is app size distribution that seems to be considerably
higher with cordova and Xamarin.

Since i started on Android, using Android Studio made my life a lot easier and
i'm progressing daily and enjoying it, something that was a PITA with other
tools.

In my experience i would say that it will be more time consuming (expensive)
to develop a single solution for each platform as well as giving support, but
the tooling is a lot better, also you can give users a better experience
because you end up developing native apps for each platform that can take
better advantage of it's ecosystem.

I'll find out in the future if i'm right or wrong.

~~~
miguelrochefort
> Can they keep up to speed with Google,Apple and MS?

Xamarin _is_ Microsoft now.

~~~
egeozcan
You are right, on the other hand, Microsoft isn't famous for being able to
keep up with itself (especially if you look at the number of deprecated ways
of creating GUIs).

~~~
positivecomment
UWP is going to change that.

~~~
stonemetal
They said the same thing about the last 4 APIs as well.

~~~
WorldMaker
Depends on which "last 4" you are talking about. UWP's GUI API is essentially
the completion of the "Avalon promise" from the Longhorn/pre-Vista era: WPF
and Silverlight (aka WPF/E) were both "spin offs" from Avalon in their own
ways and WinRT was final push to complete "Avalon" before being rebranded
UWP... So from that sense Avalon, WPF, Silverlight, WinRT, UWP are all
iterations of the same API plan, all share more similarities among each other
than dissimilarities, and all share a base set of transferable skills that
learning one of them makes it easier to transfer to a different one. So from
that perspective too, the "last 4" APIs they told people to use have all
really be just one API that's taken a while to grow, evolve, then re-converge.

------
martinpinto
Ionic 2 is a very promising hybrid approach. It's still in beta but should be
out of it soon (better wait until it's released). The current beta version is
quite fast. It has lots of components which are beautiful and has great
support for ios, android and windows phone. It's JS (angular2) and html based.

~~~
macns
Can you please point to an app built on this? I'm currently looking into
hybrid apps and Ionic is probably the best option. It may be fast but not
smooth though, e.g when scrolling or pulling a left side menu.

~~~
beermann
Our app Pacifica, [http://thinkpacifica.com](http://thinkpacifica.com), is
built on Ionic 1. It is currently showcased on both the Ionic and Cordova
websites and we've see a fair amount of success with over a million registered
users since launching last year.

------
miguelrochefort
If you're familiar with C# and .NET, it's a no brainer.

Xamarin is nothing more than a C# wrapper around the native iOS and Android
APIs. Everything you're familiar with (UIViewController, UIView, UITextField,
UIButton, etc) remains the same. The main benefit (other than using C#) is
that all non-UI code can be shared across platforms (iOS, Android, Windows,
server, etc).

Xamarin.Forms is built on top of Xamarin and lets you reuse the same code for
UI as well (using their own abstraction that's similar to WPF/UWP). I would
only recommend this for relatively simple apps as you lose some control over
platform specific details.

------
jasallen
Hey Guys, Xamarin University Instructor here,

Obviously I think it's worth it, I learned it well enough to teach others. We
have a bunch of _free_ Self Paced Learning modules and videos at Xam
University, as well as obviously the paid stuff that pays my salary ;-)

There is a ton of investment and effort from a small team, remember, we've
only been with a "big company" a few months, so the improvements come at a
blistering start-up pace. If you haven't seen it in a couple years, you should
really check back.

If you are going to develop "all platforms" or even just iOS and Android, it
is _certainly_ worth a long look. Access to every API you get access to in
their native languages and the ability to avoid that language "context
switching" pain. Plus, some amount of shared code (varies wildly, 25% - 75%
depending on how heavily your app is just about custom UI and animations ).

Because we use the same APIs (except when we have better ones), you can
leverage the same documentation and StackOverflow posts when you need to (yes
with a little language translation), but you often don't need to because
Xamarin has a _lot_ of great documentation as well.

And, as has been mentioned, "Xamarin Forms" does not equal "Xamarin". Although
it is a valid choice for developing in Xamarin, it is only one option. Here is
a super shallow comparison:

Xamarin Forms: Super fast for super simple UI's and interactions with common
elements. It is highly opinionated on what it should do and look like on all
platforms. Customization is do-able but starts to increase the complexity of
the app quickly to the point where the below would have been a better choice.

"Xamarin" aka "Xamarin.iOS and Xamarin.Android": Use essentially the same
development patterns as Native Android and iOS developers and use the same
API's (plus .NET library, and many .NET 3rd party libraries). You get code
sharing (as noted, amount varies considerably), ability to "think in one
language (often including your server, which might also be c#), and access to
some additional libraries (because we support both the Native libraries _and_
the .NET ecosystem).

Hope this helps :)

Oh, and a quick plug. Xamarin University is live classes taught by real, very
experienced developers who can actually help you learn and understand, so we
are, you know, worth asking questions of. Also, we'll be doing a free
presentation all day on November 18th as part of Visual Studio Connect, so
check us out there and see what you think of Xamarin _and_ Xamarin University!

------
cryptarch
I've very recently worked with Xamarin Forms for about 5 full-time months and
it was terrible.

My main complaints are:

* It's full of bugs

* The build system is unreliable and mysteriously breaks, which generally takes a full day to fix

* Basic functionality such as merging resource dictionaries (which are stylesheets, kinda) is missing

* No graphical UI designer or preview, so every layout change requires a recompile and deploy before you can see it

* Apps feel sluggish and crash at runtime without specific error messages

* It makes VS crash all the time. I'm not a regular VS user so I'm not sure if VS:CE2015 is a POS or if Xamarin is.

~~~
zihotki
Actually they've released Xamarin Forms Previewer -
[https://developer.xamarin.com/guides/xamarin-
forms/xaml/xaml...](https://developer.xamarin.com/guides/xamarin-
forms/xaml/xaml-previewer/) It's still a bit buggy but does the job in most
cases. Also the latest version of Xamarin is way more stable.

------
pritambarhate
Yes it is worth learning. It's a skill which is quite in demand especially
from established companies for their business applications.

However, as others have pointed out, Xamarin Forms is a bit of let down.

In my experience, if you try to create custom designed UI (which is quite
common in the native apps), then you find that Xamarin Forms is very limited.
To overcome this limitation you need to write something called as a custom
renderer for each OS you want to support. So it doesn't really save you much
time.

Xamarin has something called as Xamarin Labs project on Github:
[https://github.com/XLabs/Xamarin-Forms-
Labs](https://github.com/XLabs/Xamarin-Forms-Labs) But it's progress has been
very slow.

If you have a business data collection / reporting app, where how things look
is not very important, Xamarin can save a lot of time while creating cross-
platform apps.

However, I wouldn't recommend Xamarin Forms for B2C apps.

~~~
mnx
AFAIK, Xamarin Forms was always meant to be simplistic, and not very
customisable. They even say it was meant to be called Xamarin Duplo, but
trademarks.

~~~
zgramana
That was just an internal working name. Xamarin.Forms has first and foremost
been a code patterns library, not a WORA framework (despite how it may be used
in practice). It's a unique leaf on the MV* tree. The central insight from
it's chief architect was to apply the scenegraph + renderer model from 3D
graphics to solve the native cross-platform UI problem. It should be
classified something like Model-ViewModel(Scenegraph)-Renderer.

As a practical matter it had to ship with a library of default renderers for
common UI elements, but other than the layout system, those all can be
replaced by alternative renderers either in part or in whole. But the
scenegraph essentially is the data structure that stores your app's business
value (think HTML templates + JS). The renderers can too, but those should be
reusable across many apps (think CSS/the value prop of Bootstrap). The
scenegraph maximizes intra-app UI code sharing and the renderers maximize
inter-app UI code sharing.

It's a hard problem space, and there is no magic bullet. Even the
Xamarin.Forms team would tell you that. For many use cases, it's great. The
bugs are tricky, since UIKit and Android have major thread safety issues and
wildly divergent object life cycles (and Android itself is such a moving
target, which any experienced Android dev knows, cough _Support Libraries_
cough). Bugs tend to come from the layout engine because that is the heaviest
lift. XF eats complexity that you otherwise have to eat on your own. For many
small/under resourced teams, that's the difference between "iOS only" and
"Android also" support. If you are resourced for two teams, awesome! If not,
but have to support both, you face some hard choices. Xamarin.Forms tops a
very short list of available options.

All that's to say that some people use Forms to build really native apps
because they understand the patterns Forms is built on, and it's limitations.
Every framework has a grain. When you cut with it, the results are quick and
smooth. When you cut against it, and the results are tough, course, and
possibly cracked.

------
gtsteve
I have read some fairly negative comments in this thread. I have experienced
many of the negative aspects myself, and while I don't disagree with them, I
would still say that it is worth learning this technology.

Microsoft's strategy with bringing a phone to market appears to have failed so
they're going to have to take the next best thing which is owning the
development tools. I expect the outlook for the software to be extremely
bright and if you plan to be a professional mobile developer I strongly
suggest learning it.

Of course, this does not excuse you from learning how to develop for iOS and
Android natively, but it is a great addition to your toolkit as a developer.
It's also another box to tick for the recruiter or hiring manager.

~~~
taormina
My primary question, as an Android developer who can write decent enough Swift
when needed and who does not develop on any Windows platforms, is why should I
learn Xamarin?

~~~
WorldMaker
The possible savings of the value of your time? If you can share even a small
bit of code between Android and iOS, that is time you save in rewriting Java
code to Swift or vice versa.

I can't tell you where that bar is, but especially if you are a solo developer
it can be easy to undervalue your time spent porting your app between
platforms.

Beyond that too, even though you don't develop on Windows now, using a cross-
platform toolkit at least provides you the _option_. You might be surprised
how many users [1] you can pick up by making a Windows version, and if it is
as easy as add a couple more platform specific files to a mostly shared
codebase you might get extra users for quite cheap.

[1] Windows phones have dropped to a low percentage, but that low percentage
is still countable in millions of devices. Plus, the UWP continues to expand
in number of tablet devices and desktops that support it, not to mention Xbox
Ones and AR/VR devices.

------
santiagobasulto
We've been working lately with React Native and Exponent (getexponent.com) and
we've had an amazing experience. The apps resulting have a great experience
and performance. Vue.js and Angular are also making progress towards the
Native world. I honestly don't think hybrid apps are going to be a think 2
years from now (of course I could be wrong, this is just an opinion).

------
dep_b
I tried Xamarin once for a macOS application. I migrated a Forms application
by extracting all logic that I could from Forms-specific (code behind files)
into more generic classes.

Then I had a .dll that I could use in my Xamarin project. The Xamarin project
was razor thin and I only used C# to connect my XIBs or Storyboard (I forgot
what I used, but it was in Interface Builder) to the existing .dll calls and a
specific type of hardware scanner.

The hardest part was getting that scanner to work, which would be not so easy
for me even in Objective-C. But I basically had to create an Objective-C
wrapper wrapped in some kind of C# wrapper. It wasn't easy but it was doable.

The hardest part was getting everything signed correctly, since I was using
all kinds of layers you usually wouldn't use in "just software" project.

The overall experience was really good despite that the native editor for
macOS wasn't that spectacular. I did the meat of my programming in Visual
Studio and Visual Studio is a really great tool. Another part was done in
Interface Builder which is a great tool in my opinion.

A friend uses it a lot for a cross-platform app written in Xamarin Forms. The
thing with Forms is that unless you keep it simple you will run into Xamarin
bugs, iOS specific bugs or Android specific bugs in your layouts and that can
be challenging sometimes.

I would say that if you would make the UI in native code or storyboards and it
still seems like an attractive idea to use Xamarin, use Xamarin. Don't use
Forms.

------
misskallisto
[Full Disclosure: I work on the Xamarin team at Microsoft. I’m familiar with
the Xamarin tools and want to offer my thoughts and guidance on the original
post. Opinions here are my own.]

The answer to whether or not you should learn Xamarin depends largely on what
you are trying to accomplish. Let me explain.

If you were to approach me as someone interested in Xamarin, I would start by
asking what kinds of apps you are looking to build, how complex they are, and
how much you care about UI quality and customization. This is to help decide
between Xamarin and other xplat solutions, but also between Xamarin native and
Xamarin.Forms, our cross-platform UI toolkit. I’d ask what you hope to gain
from a cross-platform approach, so we can optimize for that. I’d ask what
parts of your app you are looking to share, and how you plan on architecting
your app to allow that.

I’d ask how much experience you have with .NET, and if being able to use C#
and/or Visual Studio makes you more productive. I’d ask if you have an
existing codebase you want to connect to. Your familiarity with native iOS
development is a plus - the particulars of iOS and Android add to the learning
curve, but you can’t make good native apps without knowing the basics of the
platforms you’re building for.

From these considerations, we would decide if Xamarin is a good fit for you.
It would be naive to say that Xamarin is the ideal solution for everyone, but
it is a very good solution for many people.

At the end of the day, Xamarin is free, and it takes less time to get a handle
on developing with Xamarin than it does to read this thread. I encourage you
to try it out and decide for yourself.

------
Meph504
I think where Xamarin shines is in places where the development stack is
already .net. If you are starting green pasture, and don't have .net
developers already, then it seems to make very little sense.

With that said, I've made a number of apps in it, and it works well enough,
but the more abstractions, the more problems, and you want to do anything
outside of simple UI apps, you are likely going to have to learn how the
native methods work anyway.

------
wsloth
When using Xamarin I always get the feeling I'm writing Java code--but in C#.
The cross-platform project is a blessing, it's truly amazing to be able to
write code once and use it on all platforms (especially if you use Dependency
Injection for even more sharing).

The downside to this is that making a UI seems to even out your gained time--
it's extremely messy and even complicated. Code that's valid in C# produces
vague underwater bugs in Java code, which makes you keep hacking around until
you find a working solution.

Not to mention the docs: some parts of the documentation are completely
outdated to the point of not even compiling on an older version of Xamarin.
For example, the tutorials on using Google Maps in your Xamarin.Droid
application are way out of date, ignoring the fact that the "Google Play
Services" component has split off into thirty-or-so components. Some of the
most used API's are not documented at all, simply having a "To be added"
description.

All in all I find much potential in Xamarin, and I _really_ want to love it,
but it's a messy nightmare to use, and it only makes me want to use Java and
Swift separately for apps.

~~~
theflagbug
> The downside to this is that making a UI seems to even out your gained time
> --it's extremely messy and even complicated. Code that's valid in C#
> produces vague underwater bugs in Java code, which makes you keep hacking
> around until you find a working solution.

Interesting, I had the exact opposite experience, since the Java->C# mappings
often reduce much of the boilerplate code that you have to write if you were
using Java (e.g C# events, properties, etc..)

I also never came across any bugs in the mappings, but I can't say for sure
that there aren't any.

~~~
wsloth
Most of my problems often come from constructors. For example, using a custom
_parametered_ constructor in an Activity or Fragment seems impossible, so
constructor injection is already out of the question. _This is valid C#_ , but
will not compile. Hence, I stated that using Xamarin feels like programming
Java in C#, which makes me feel like I would actually be happier writing Java
code.

Instead, for this example you could subclass Activity/Fragment and use
reflection to find properties on the activity to inject services into.

This is only one of countless annoying Xamarin problems I have encountered in
my few months of use, and this one was relatively easy to solve. Vague
problems also ensue when forgetting to inherit a class from Java.Lang.Object
which leads to vague exception messages like "Specified cast invalid".

Sure, sometimes parts can be made faster in C#, but more often than not I
spend day(s) debugging extremely vague bugs related to non-documented
mappings.

------
vblord
I've been a life long Microsoft developer. So when I started down the mobile
app path, I naturally gravitated to Xamarin. Xamarin allows you to build
mobile apps in the best development IDE out there. This is true... but it has
it's issues. I've created 3 andoid apps with Xamarin (and tried more), but
each time i've run in to bugs or oddities that make life suck. I wish it was
better, but if I could go back in time, I would have probably chosen a
different language/tool. Maybe Unity if I still wanted to stay with the C#/VS
IDE.

One nice thing about it is that all the methods/classes are named almost the
same thing as native android. If you want to know how to do something, you can
find the android solution and just change a few small things.

So my vote would be to not do Xamarin and to choose a different cross platform
development environment. Cross platform is the key. If you do choose Xamarin,
I would spend some time and do a little bit of training before jumping in.
It's not like the ease of building windows applications in VS.

------
Zigurd
I have had clients that use Xamarin. This is what I've observed:

1\. If you don't use Xamarin and you don't have a team in-house that uses C#,
don't bother. You'll be better off doing native development on iOS and Android
platforms.

2\. Your app won't be as pretty, and it won't adhere to platform native UI
conventions as well if you use Xamarin.

3\. Xamarin does a better job of it than most but it will still be lagging in
access to the latest features.

4\. BUT, if you are doing a vertical market app that wants to be cross-
platform AND you have C# coders you can apply to that task, Xamarin is the
best choice.

There are a lot of places where choosing Xamarin makes a lot of sense. And the
people who created Xamarin are excellent. And now that Xamarin is owned by MS,
it won't die because it is hard to make money as a cross-platform startup. But
as with every other cross-platform tool for non-game apps I've seen, it isn't
the best choice in green-field situations.

------
andyjohnson0
I've been using Xamarin since mid-2012 and have developed a couple of niche
imaging products on Android and iOS for my employer, plus some internal tools
on Android.

Overall I've been very happy. Code re-use hasn't been stellar, but good enough
to repay the investment. We have re-use not only between apps, but also
between mobile apps, Windows desktop apps, and our application backends. I
also feel I'm more productive than if I had so swap between
Java/Swift/ObjC/Andorid Studio/Xcode.

Stability has improved a lot in the last year. Paid-for support was pretty
good (esp. guys like @jonpryor), but the self-serve forums can be a bit hat-
and-miss. I never had any killer bugs (but then I never used Xamarin.Forms...)

Overall: 85% happy with Xamarin.

------
alex4Zero
I've spent last 3 years working with Xamarin and native iOS and Android apps.

Xamarin wins if you need something for Enterprise. A lot of entry fields,
validation, integrations with SSO, Sharepoint, other rest API. If you use MVVM
well, it will lead to ~75% of code reuse between iOS and Android. Even more
with XamarinForms. No complex effects, no complex animations, just enterprise.

Native wins if you want to make it more beautiful for end-users and you need
to have a lot of customization. For example, customize map, pins and callout
views. You will hate everything if you do it in Xamarin. No code reuse here

In general, Xamarin has very great chance to be #1 choise when you choose
platform for Enterprise development.

------
sergiolp
At flexVDI, we use Xamarin for building our macOS client (Xamarin.Mac),
sharing most of the code with the client for Windows, built with Visual
Studio. Both of them, link against a shared library which implements core
functionality, written in C.

I must say that, having its own quirks and nuisances (specially in Xamarin
Studio, which was pretty buggy until version 6.x), it does the job pretty
well.

In fact, when we wrote our iOS and Android clients, Xamarin was still pretty
immature. But if we had to rewrite them today, it would be one our of first
options, right after using the native frameworks (which ensures the best
results, but drastically increases the costs).

------
jsingleton
I couldn't get React Native working for Android (on either Mac or Windows) but
I've been pretty happy with Xamarin. I've written a simple game in
Xamarin.Forms that I will be posting about.

Purely by coincidence, I have four blog posts on this out this week. The first
one (on React Native and Xamarin) is here: [https://unop.uk/cross-platform-
native-mobile-app-development...](https://unop.uk/cross-platform-native-
mobile-app-development-options)

------
DevInPainNeo
The Xamarin needs to develop easy and customization should be easy.

Had huge pain in full screen mode dynamically for all the devices.

Calendar with colors forced me to create a new custom control from 0.

To be stable with the controls if you make a tab control in one version should
be the same in other versions also, not reinvent and change the wheel.

Easy and clear documentation. Forums all with lots of no one cares why it
works int works on my machine stuff.

To new technology and has to get mature and stable. If you are not in the same
versions of Xamarin in mac and windows it just not works properly.

Proper error message. I am getting an error like There were deployment errors.
Continue. (Not run in administrative mode the vs 2015, closing the emulator or
it was opened by other vs before, or you closed the emulator before finished
the deploy) There are lots of errors like "aapt exited with code 1" that means
there is some bad character in image or in files like -.... or files starts
with number.

Also sometimes out of memory exception when loading images larger then 1mb or
in android 4.2 larger than 300kb, even going lover to 100kb having problems in
4.2 android.

Proper editor for Xamarin.Forms is a must have if you want to develop. You
can't see the design what you are doing with vs 2015.

Also designer is crashing all the time if i open multiple times and make some
adjustments.

------
grabcocque
If you want to develop cross platform mobile apps your only other option seems
to be React Native. I'd like to see a good rundown of the pros and cons of
each approach.

~~~
omnibrain
There also is Delphi with the mobile Addon.
[https://www.embarcadero.com/products/delphi](https://www.embarcadero.com/products/delphi)

~~~
Swinx43
I learned Pascal in school many years ago. I honestly did not know that Delphi
was still kicking around. Very interesting to see this :)

------
hitgeek
i'm mostly a web developer with C# and JS. I've tried to learn Swift, Xamarin
and React Native multiple times over the last 2 years.

With both Xamarin and React Native there was a honeymoon period where
everything seemed so easy and great. But at some point I always hit a problem
where there was limited documentation, or unsupported features, and that
really hurt my productivity and motivation.

The learning curve for Swift/ObjC always seemed much higher, with a lot more
upfront investment required before I could make anything resembling a
functional app. The iOS layout system in particular was an obstacle, as well
as managing the tooling and dev environments.

If I had a free 6 months, I would just learn full native, but keep an eye on
React Native. The dev experience in React Native is unparalleled, and it seems
easy to drop down to native code (assuming you know it). Also the ability to
easily contribute back to the community with NPM and react-native "link",
makes me hopeful limitations will quickly be erased.

------
LyalinDotCom
Just one comment to bring up as many folks still don't know, Xamarin is free
for many developers along with Visual Studio Community edition, the full info
is here in this announcement from March 2016:
[https://blog.xamarin.com/xamarin-for-all/](https://blog.xamarin.com/xamarin-
for-all/)

------
mbruins
Native iOS and Android developer here. I switched to Xamarin a few years ago.
As a native developer i was afraid of Xamarin and that i couldn't harness the
power that Swift and Java gave me. However it give's you full control over
your apps just as Java or Swift does. Everything you do in Java or Swift can
be done with Xamarin in C#! Your knowledge isn't lost, the syntax has only
changed. Nowadays i absolutely love it! I work with enterprise companies as a
consultant using Xamarin, code sharing is approximately around 80% when using
a Xamarin and a framework like MvvmCross! In my opinion Xamarin is the feature
of building apps. Please ask any questions you have and i be happy to answer.

------
ParanoidShroom
I loved C#, hated Xamarin forms. It was about a year ago no, but I doubt
things have changed that much. There were just so sooo many bugs. I have
nothing against them and still think .net is amazing, but that was such a
worse experience. I think reactive will win though.

------
eonil
Such cross platform apps are meaningful only if your product doesn't need
great UX. But the question is, if your app doesn't need it, why do you need a
native app? It's better sticking to a web-app. Make a web-app and cover all
platforms at once.

~~~
UK-AL
You can make any sort of UX in Xamarin. Xamarin.Android, Xamarin.IOS are just
straight up wrappers to the real api.

------
bedane
Xamarin is only worth it if you already have lots of C# code you need to reuse
in mobile apps(our formerly windows-only company had to)

As a day to day user, I quite dislike it. But rewriting our business code was
not an option.

------
ghuntley
If you are currently doing Xamarin development or are interested in learning
more check out the [http://weeklyxamarin.com](http://weeklyxamarin.com)
newsletter.

------
Taylor_OD
This is different than your circumstance but back when I was recruiting I
helped a Xamarin developer with no professional experience find a gig with a
95K base salary. It's currently niche enough that people are willing to pay
top dollar for anyone who can actually work in it. Another Xamarin developer I
know consults for 150 an hour. (Although he's probably one of if not the best
xamarin guy in Chicago)

~~~
ghuntley
95k base is indeed low. Severe undersupply of developers with deep mobile
knowledge.

Whilst it's been years since the advent of mobile, most enterprise
organisations are doing their first mobile project in 2016/2017\. You can
thank Gartner for that.

As for $150/hr on contract, I know someone who invoices more than that but you
must be on your A game and be ready to teach, teach, teach.

There's nothing too special about Xamarin knowledge. Drop your Apple vs google
fanboyisms, learn both platforms, learn MVVM, implement pure MVVM (don't fall
back to singleton city).

If you know android/iOS well and are wondering where next to apply your six+
years of mobile development knowledge vs having to compete with comoditization
and off shoring - this is it. With your deep knowledge and experience you will
smash the existing talent in the market out of the park.

------
dvcrn
Ruby Motion vs React Native vs Xamarin vs Native (Java/Swift) is a question I
have all the time. All look interesting and worth learning

~~~
jaoued
We are in favour of Native. We are still in product market fit with our
current product (native iOS to native Android online instant porting tool,
www.myappconverter.com) but we are making good progress based on customers and
user feedback. We are currently working to support auto-layout.

~~~
dvcrn
The thing with RN is that, well, either you like javascript or you don't. I
don't.

I agree that RN is the most sophisticated of the options but at the same time
I would rater write in Ruby than in javascript. There are some other languages
that you can pretty well compile to JS (cljs for example), but in the end
you're still dealing with javascript.

------
dontJudge
This probably isn't cool, popular, or what you want to hear. But for client-
side software, use the native GUI library for each platform. Write the core in
C or C++. Abracadabra. It's cross platform, no issues, no bloat, no extra
fees. With experience it can be fast to develop too.

------
davidgrenier
F# is worth learning that's for sure.

~~~
zgramana
_Especially_ when/if using Xamarin.Forms (and not XAML). It's a very good fit
for a functional language. Code equals data.

------
paulftw
Isn't Facebook for Android built in React Native? Doesn't seem to be lacking
for them. Airbnb and Instagram [1] are also doing alright.

[https://facebook.github.io/react-
native/showcase.html](https://facebook.github.io/react-native/showcase.html)

~~~
ceeK
I think mainly for minor parts.

From my initial research it appears the React Native on Android suffers
performance problems. I.e. the Discord app on that showcase is still native
Android, whereas their iOS app is React Native.

------
tejasv
We use Xamarin Forms a LOT for our internal and public facing apps. I started
exploring it almost 2 years back, because native Android development just
sucked, and C# has the async/await keywords, which is simply perfect for
asynchronous operations in UI.

It has not been an easy road. After 2 years, I'm finally beginning to reap the
benefits. The simple problem is this: this is another layer over the existing
layers and it's very hard to get it right, especially if the underlying layers
suck.

Just because you've learnt Xamarin Forms doesn't mean you can choose not to
learn the underlying native platforms. You can skip over most of the details,
but something will always come back to bite you, and then you have to go
figure it out. Xamarin Forms works on top of Xamarin Android, that works on
top of Android SDK and Android Tooling, which works on top of the JDK, which
works on top of the OS you're developing on. So many places for something to
go wrong, and usually presents itself in the form of a cryptic error at the
top. Developing for iOS is considerably easier.

So there's still a fair amount of expertise to develop if you're completely
new to mobile development. Take it for what it is -- an abstraction, and as
with any abstraction, any concrete manifestation will have its issues, and you
must be ready to roll up your sleeves to figure it out. And it does get keep
getting better with every subsequent release.

But it does eventually help -- we have to get the complex bit right once, and
then it simply works. Don't approach this like you would approach an Android
app -- make sure you understand UI design best practices -- especially
reactive design and data binding.

We also have .NET stack, so I'm finally in this beautiful world where all my
logic is represented as C# Expression Trees on the server side, that gets
serialized and pushed down to our Xamarin Forms Apps. Looking forward to WASM
adoption, so I can finally get rid of that JavaScript mess.

So if you're writing a one-time app, and you just want to target Android/iOS,
and you don't care how you've done it, no it doesn't make too much sense.

But if you're trying to make a long-term bet, in this awful fragmented device-
oriented world, (and having to write the same app twice goes against the very
nature of your existence), well that's my bet, I will be cautiously
optimistic. If you're on .NET, it's a no-brainer -- there are simply too many
other benefits to ignore, and philosophically very true.

The architecture itself (Forms, Xamarin.Android, Xamarin.iOS, Custom
Renderers, Platform Effects, Bindings to access native libraries) is
theoretically flawless (or very close to it), a work of art -- and I'm a
sucker for theory, no matter the real world pain.

------
vibrato
One downside of Xamarin apps is memory usage. Just launching our app uses
>200mb of memory. After doing all we can to avoid memory leaks and excessive
usage, we still crash regularly due to running out of memory. (part of this is
due to a UIWebView)

------
amelius
How is React lacking for Android?

~~~
ceeK
I've heard performance problems.

~~~
hobofan
The only performance problems I've seen were created by people who don't
understand when React triggers a redraw, thus rerendering a 1MB image on every
keyboard keystroke.

As long of you are a bit mindeful of the big pitfalls (any bigger framework
has some of those), the performance of React-Native is excellent.

~~~
ceeK
According to discord ([https://discord.engineering/using-react-native-one-
year-late...](https://discord.engineering/using-react-native-one-year-
later-91fd5e949933#.p29xq5bx6)):

    
    
      Unfortunately Android devices have much 
      greater variance in performance and tend to trail significantly behind iOS. 
      We were able to get our app running fairly quickly, 
      but the performance — specifically on touch events was not at an acceptable level even on higher end devices. 
      In addition at that early stage there was still a lot missing in the React Native Android feature-set that would
      have made getting our prototype to production level more time consuming than our iOS effort.
    

This was posted on the 7th June admittedly. Does this still hold true?

~~~
hobofan
I personally haven't experienced any performance problems, even on lower end
devices (only the ones where the whole OS is sluggish).

I don't know what Discord has seen there, so I don't know if that's been
resolved. They also state that transitioning to React-Native on Android would
have been more time than on iOS , which doesn't mean that any alternative like
Xamarin would have been better. It also reads like the team for the respective
platforms is around 1 person big and they already have a running version for
Android, so the cost of a rewrite and the time to retrain would not have been
worth it, which is reasonable. On a greenfield project, different conditions
apply.

------
shams93
Yes if you're looking to be a primarily .Net developer, it's not so widely
used outside of the .Net community but in many .Net shops it's become the
standard tool for mobile development.

------
staticelf
If you already is an iOS dev I think it's easier to just also pick up android
instead of Xamarin. Altough, Xamarin seems very nice and so on.

------
UK-AL
Yes, but only Xamarin, not xamarin forms.

------
wjd2030
Xamarin for business layer logic, native for the actual app.

------
umurgdk
I've used in production and experience was good. Xamarin Studio is more than
enough for development / debugging. Xamarin is very powerful, but usually
people taking the wrong direction with Xamarin and using Xamarin.Forms. As
like many other cross platform solutions Xamarin.Forms sucks. If you think
making a native iOS application is easy with Swift, it is same with Xamarin
too. When i develop applications with xamarin (desktop/mobile) i usually look
for java/swift documentations or forums for my problems. This way i don't need
separate xamarin community. Because you can write the same code in c# easily.
Please check my workflow, for any further questions, twitter: @umurgdk

Recommended workflow: 0\. Never ever use Xamarin.Forms other than quick
prototyping. If you develop applications with other cross-platform frameworks,
you already know all of them sucks and Xamarin.Forms is not an exception.

1\. Create PCL / Shared project for your business logic (also your view models
if you're using MVVM architecture). Believe me most of your application is
platform independent (except the view layer). Your api communication, storage
operations all handled here. See 3rd article to how to make storage/network
platform independent.

2\. Create native projects for each platform (iOS, Android, Windows) implement
native views here (use xcode, android studio if you need visual designer).
This part should be exactly the same as your swift/java code. For iOS you're
just implementing an ApplicationDelegate class and UIViewControllers as same
as your swift code. Same for Android part, nothing special to xamarin just
implement your activity classes. At this level you have the full power of your
native platform with one exception 3rd party native libraries. It's possible
to use (yes i used some swift/java libraries for youtube player) them but
really hard to integrate to your project, that part has to be improved and
better documented.

3\. Your shared code base need native features, for example storage
implementations are totally different for each platform, or changing views
(navigation) will be implemented differently for each platform. Since shared
code base shouldn't know anything about native platform. You should abstract
these functionalities with interfaces. For example create a storage interface
with methods like saving/reading/creating files. Another example might be
network communication. Abstract it as an interface on your PCL and implement
this interface in your native project with full control of your platform. Your
shared code base only knows how to use that interface. And then each of your
native projects should implement these interfaces. At this point dependency
injection may help to register implementations easily. Actually that part is
what makes you share your business logic. Writing idiomatic cocoa navigation
code is much better than using any cross platform implementations, you have
full control but in the same time your shared code base using them without
knowing anything about the platform.

------
T3RMINATED
I've used Xamarin for several projects and I greatly regret that decision.
Granted, most of my hatred is targeted towards Xamarin Studio and
Xamarin.Forms so if you use Visual Studio and build only native UIs then maybe
your experience will be better.

------
WhiteHat1
Microsoft just announced the launch of Visual Studio for Mac (based on
Xamarin). It's great if you want to C# development. Have you tried Eclipse or
Android Studio?

------
icemelt8
No one is mentioning how expensive Xamarin is and there is no proper free
version.

In the free version you app expires after 24 hours AND it has to be below a
certain size, I dont remember maybe 2 MB or something.

To make something you have to cough up a lot of money, and the sad part is
this information is incredibly hard to find, you only stumble upon it when you
download GBs of files.

~~~
ghuntley
This is 1 year+ old information. Go look at the pricing page for a pleasant
surprise.

~~~
misskallisto
Hi, from Xamarin here - what page are you referring to? Community is free,
there are a few extra features that come with VS Enterprise. Those are just
nice-to-haves, like other VS enterprise features. You can develop with Xamarin
for free.

~~~
ghuntley
My point exactly. :)

~~~
misskallisto
Aaaah I had misread :)

