Hacker News new | comments | show | ask | jobs | submit login
Announcing Xamarin 2.0 (xamarin.com)
217 points by petercooper on Feb 20, 2013 | hide | past | web | favorite | 122 comments

I have mixed feeling about this. I have a current Mono for Android Profession subscription and use the Visual Studio integration a lot. My subscription is due for renewal next month and if I want to continue to use VS with Xamarin 2.0 then I have to renew at the Business edition level. I paid for my sub out of my own pocket because I liked the technology so much, but $399 for the pro version last year was a stretch and I just can't justify $1k to renew. Xamarin Studio might be superb, but I've been using VS since 1995 and I really don't need to learn another new IDE right now.

Any comments from Miguel or anyone from Xamarin?

That said, the Indie edition is something that a lot or people were asking for and the price is attractive. The components look good too. I think its going to be a big success.

Edit: See Nat Friedman's response below [1]. Existing Pro subscribers are automatically upgraded to Business and can renew at their existing renewal price. This is described in the FAQ [2] which I didn't read far enough down.

[1] http://news.ycombinator.com/item?id=5250922

[2] http://xamarin.com/xamarin-2.0-faq

As an existing Professional customer you are automatically upgraded to Business edition and can renew at you existing renewal price (which is $249 for you).

Hope that helps :-)

Thanks for the clarification Nat. Thats really good to hear and I'm looking forward to trying the new tools over the next few days.

How long will renewals be this cheap, just the first time around?

We don't have an end date.

I am in the same boat but starting to recognize that the free train of tooling is a ploy of platform vendors trying to pull us in to working in their area. Microsoft can afford to do this because they extract major value on the back end when we target windows with apps.

A cross platform, non-allied company like Xamarin doesn't benefit from that back door revenue as they make no money from my app.

It is a tough bill to swallow but the problem seems to be our perspective, free wasn't always free. $399 was a young company trying to gain traction with a small team and if we want bigger, faster, stronger then it costs.

Sucks, but after 10+ years of consulting in the Windows space I realize that cross-plat mobile is my next 10 years and in that light, 1K is not that bad.

In fact we lowered all prices today.

Our lowest tier, previously, cost $399. Now it costs $299.

Our highest tier, previously, cost $2499. Now it costs $1899.

Then apparently the new pricing model is much more expensive to start with, since there is no longer discounts for renewals. Just to compare apples with apples, here is the difference in pricing:-

old: 999 first time and 599 for upgrades for "enterprise", 399 first and 249 for upgrades for "professional" and company with 10 or less people;

new: flat rate 999 for any companies (2+ people) and 299 (only for single person)

Sorry this may sound bitchy , I just don't like price-ups as I live in a location where inflation is killing me (and the salary is like half of what US rates are so software are twice as expensive in that thinking).

I am not against price ups and it's always better to be an early customer, but one a longer run, new customers (or existing customers as well if they don't get the upgrade price after the first renewal) is definitely paying more. That greatly affects small businesses because they can no longer use lower tier one just to get the juices with cross-platform joy on a more affordable rate.

As one of Nat's other comments points out, you can continue to renew at the old cost.

As much as the store page confused me, so you can't use the product after the end of your subscription (that is, the license is NOT perpetual)? I mean, would you be able to compile or release anything after the expiration of your current subscription?

The licence is perpetual. The subscription entitles you to updates for a year.

I had a lot of updates over the last year and was very satisfied with the value for money that I got.

You can continue to compile and release even after your subscription expires, you just don't get updates to Xamarin's products.

If you need to develop Android apps using VS, have you looked at dot42: https://www.dot42.com/

Looks interesting. If you've used it, what are your impressions?

No but I plan to try it soon. Their free community version has no limitations except that you can't charge for the apps you put in the Google Play Store.

The following YouTube video summarizes exactly how I felt after reading the announcement:


VS2012 integration w/OSX build host. Oh yeah.

Pricing changes have positives and some potential major negatives - In my eyes the "pay money to get started" approach served as a nice filter against pathological customers/mechanism to balance signal to noise. The introduction of a free tier generates mixed feelings within. Xamarin please, please don't allow the inevitable eternal september that will follow to become a distraction.

Seen it happen it happen a few times - forums/support become overrun with noise and the companies were inadequately prepared staffing wise for the eternal september, with staff unable to keep up the resulting quality of product/support dropped considerably.

From a different perspective the introduction of a free their now makes the toolchain available to those whom could not possibly pay for it - students and countries with weaker purchasing power. (where $xxxUSD is equates to x months/a years wage)

Periodic reminder to the Linux and free software community of the damage they made with their ideology wars against the Mono environment. Mono is now the most popular game and one of the most popular app development environments. :-)

Kudos to Miguel and the rest of the Xamarin team, the update looks amazing.

> Periodic reminder to the Linux and free software community of the damage they made with their ideology wars against the Mono environment

What damage, exactly? I don't think Linux adoption is in any way harmed by the removal of all Mono packages from the default installs of several distros.

> Mono is now the most popular game and one of the most popular app development environments

I find that a bit hard to believe unless you are talking about cross-platform mobile game development.

I guess he means Unity which uses Mono. But there are others as well like MonoGame which is the de facto XNA successor (and its natural evolution) and Playstation Mobile that uses Mono.

edit: Would be quite awesome if they somehow incorporated the Mono runtime on the new Playstation as well for indie development. Here's for wishful thinking!

I think a lot of NaCl games are also written in MONO.

Ubuntu removed Tomboy from their default install due to Mono dependency. Tomboy is still a well used and liked application on Linux desktops. Just one example of many great apps "killed" that I am most familiar with.

So going to Ubuntu Software Centre and clicking Install on Tomboy is too hard?

As far as I remember, the problem was that the Mono libraries took far too much space on the CD to justify it for one or two applications...

>I don't think Linux adoption is in any way harmed by the removal of all Mono packages from the default installs of several distros

You'd be surprised.

Well, given that Xamarin doesn't seem to support Linux for their newest IDEs it's especially a shame. I'd prefer .NET/Mono over Java (and i'd prefer python and C over .NET), but it doesn't look like there's support for that..

Last time i tried to get MonoDevelop with those Android tools to check out cross-platform app development with Mono and it's a no-go. Now Xamarin Studio appears to be Mac and Windows only. Very disappointing!

All of the Xamarin Studio changes were pushed upstream to MonoDevelop.

It's true that we don't currently have a version of the Mono-for-Android addin available for the Linux versions of MonoDevelop, though.

I have been working with the beta and am extremely pleased. I think people will get very excited over the VS integration for iOS but I think the component store is going to be one of the big winners here.

The MonoDevelop rewrite (Xamarin Studio) also has a clean, fresh and fast feel to it. I cannot say that X is empirically faster or better but the experience does feel better overall.

I think they are heading in the right direction here and the holy grail for breaking strongly into the enterprise may be the ability to build for iOS without the need for a Mac. It is not there yet but you can see the direction they are going and how that will likely come to pass at some point.

You will generally speaking always need a Mac for building.. but I could see a time where they have a Mac build farm and it is just part of the service offered.

Any news on building apps with F#? These two articles look like a great start, but it would be nice if there was a more official/streamlined way to do it.

http://7sharpnine.com/posts/monotouch-and-fsharp-part-i/ http://7sharpnine.com//posts/monotouch-and-fsharp-part-ii/

I'm still waiting for part 3 if Dave is reading :-)

We are actively working on F# support for our products.

We have built on the great work that the F# community has done and will be shipping it in future versions of the product.

We are looking at a beat of our F# support for March.

Great news! I'd better stop reading all those haskell books and start brushing up on F# 3.0 then I guess :-)

Haskell books will certainly not hurt. You won't need monads right away and you won't feel lacking certain Haskell powers if you don't read RWH right away, but in the long run, it will make F# more enjoyable. Of course OCaml books, ML books, and Clojure books will always help too, as will Scala ones.

I'm also curious about this. Promisingly, F# is explicitly mentioned under the "Extensible" heading here: http://xamarin.com/studio.

Seems awesome. I wonder how they made it possible to have an iOS simulator in their Visual Studio plug-in. Apparently it will be possible to develop native iOS / Android apps written in C# from Visual Studio and I'm guessing from Windows.

I have much respect for Miguel and the other guys at Xamarin. They work on some great stuff, I think C# has a great future for mobile development because of all the work these guys have done.

From http://docs.xamarin.com/guides/ios/getting_started/installat...

"No iOS simulator on Windows. The iOS Simulator runs on Mac OS X, so it’s necessary to switch to the Mac’s screen when testing on the simulator."

Our new Business edition, at $999, now includes iOS support for Visual Studio developers.

I guess you will be able to use a device from Windows, or something like that. Otherwise it won't make sense to provide iOS support for VS.

Correction - you will need a Mac for the final build of the product. VS will connect through network to this Mac ... Not sure if it makes more sense to just use VS as a glorified C# editor. I suppose if you are a hard core VS user it will be easier to do your development from VS.

Using VS would be a huge plus. You don't have to buy a bunch of pricey macs, just 1. You don't have to retrain C# coders to use a Mac. You can use ReSharper! You can open two code windows side by side, something monodevelop cannot do (not sure about Xamarin Studio as I am still waiting on the download). VS integration with Team Foundation is much better than git-tf, so if your company is already using Team Foundation you can tack on iOS development/ports with out much trouble. There are a lot of reasons it makes sense.

I don't own a Mac, but have an Ipad. If I jalbreak my Ipad, would I then be able to deploy applications built with xamarin studio or visual studio for testing?

You don't need to jailbreak your iPad, but you'll still need a Mac.

Visual Studio basically just talks to MonoTouch on a Mac to do the final build steps, to run the Simulator, etc.

Great work, this is really cool. A couple of thoughts, idly:

- 'Xamarin Studio' just a new coat of paint on monodevelop, but it has some nice things in this version; new ui, the autocomplete especially is vastly improved.

- Seems a bit laggy on my mac mini for some reason, which is a bit disappointing, but works fine on my imac. Both mountain lion, so who knows?

- Still no PCL's for macs. :( sigh (yes, you still need to have a separate project for each platform, which includes all the same files).

I think some of the animation stuff is probably the cause of the lag on the mini you are seeing. I'm pretty sure we've already got a patch for this, it just wasn't in time for the final Xamarin Studio 4.0 build.

PCL's are coming. An upcoming Xamarin Studio 4.0.1 will improve PCL support even more - as in, it'll work on Mac, but it won't build true-PCL libraries (it'll link with the Xamarin.iOS or Xamarin.Android BCLs instead of with the true PCL assemblies).

This blog post by Stuart Lodge links to a custom build of MonoDevelop 3.1.1 with my PCL patches if you want to try them out: http://slodge.blogspot.com/2013/02/a-patched-monodevelop-for...

Are they contributing changes back to MonoDevelop?

I'm curious how it integrates Mono runtime into a "native ARM executable". The whole runtime must be really big. When building the App, does it only integrates the parts required to support the App, or does it integrate all?

The other question is that, when running on iOS, is it the .NET IL running on top of the runtime, or C# code is compiled into native binary code that can be directly executed on CPU? I'm trying to figure out if there's something like a micro VM running.

We wrote the equivalent of a linker, which only brings the pieces that you actually reference.


Dunno, but the android ones are pretty big. A simple 'hello world' view:

    ls -sl ~/Desktop/HelloWorld.apk
    10144 -rw-r--r--  1 doug  core  5191787 20 Feb 23:46 /Users/doug/Desktop/HelloWorld.apk

Most Apps are not as simple as a "hello world" view. My guess is that, the getting-started pack is large but when you add more things into it, it doesn't increase that much.

Short answer: it gets converted to native, they can actually determine which parts of the .NET runtime you are using and only fold those elements in which makes the IPA pretty small actually.

There is no virtual machine.

Thanks. That sounds pretty cool! Where does the conversion happen? Does it compile C# directly to target code, or it converts from .NET IL?

C# is compiler to IL.

The IL linker operates over the IL code (typically C# produced, but we are working now on adding also F#) and produces the minimal set needed to run.

Then we compile the resulting linked IL to ARM code, and then we run the result using the C linker (so the same removal of unused code takes place, this time for the C bits of Mono).

That's neat. Just downloaded the installer and I'm gonna give it a try later today. Good job!

As an indie developer who recently bought the full priced package so that he could start testing on real devices: argh. As a developer that knows C# and wants to make iOS apps: awesome.

I haven't had a chance to download it and try it out yet, but Xamarin Studio looks amazing. I've long thought that MonoDevelop has a very solid core but little polish- it looks like Studio adds that polish.

From the FAQs, if this helps.

"Customers that purchased within the past 90 days may request a partial refund for the price difference between their purchase price and Indie. If you choose to make this downgrade, you will lose access to many great Xamarin Business features you already enjoy, including Visual Studio and email-based support."

That pricing is much cheaper than a full $999 price tag and is entitled to $249 upgrades for future, so it seems to be a bargain.

I just bought a license a few months ago. I'd rather keep the business license and the old renewal cost as well over a refund. It would be silly not to with the additional features if one wishes to keep using C# for long term cross-platform development.

This looks amazing. I think in many ways Xamarin has out-done Microsoft here. I'm not sure if Xamarin Studio is more featureful than Visual Studio (VS went over the "overly complex" hill for me after 6.x), but it looks a lot cleaner and easier to get into.

Anyone know if debugging C/C++ code on Mac is still unsupported as it is in MonoDevelop 3.0?

I'm surprised you have that opinion on VS.. the addition of easy add-on installs and nuget packages in 2010-2012 are pretty nice. I found the VS6 UI's decent, but since I do most of my work in web based apps, it never cut it there. These days about half my time is in VS/C# and the other half in WebStorm/NodeJS. I also think web apps have a lot of milage and in some cases more to offer depending on what you are wanting to accomplish. <br/><br/> I am glad that Xamarin has a viable business model, and wish them all the success in the world.

This is great and looks very interesting. First question - what happened to the Windows Phone 8 support? Won't we be able to develop Windows Phone applications using Xamarin?

It says on http://xamarin.com/Windows that Xamarin does support all three platforms, but I don't see anything about the Xamarin studio there.

While we make our cross platform libraries like Xamarin.Mobile run on all platforms, including Windows, we do not actually provide an IDE for Windows Phone apps.

Microsoft already provides a complete and capable product for that space.

> Microsoft already provides a complete and capable product for that space.

Not on OS X.

You raise an interesting point...


What does it mean with "you cannot P/Invoke 3rd-party library"? Does this mean that Xamarin Free edition is limited to the scope of iOS basic SDK and not 3rd-party Obj-C library out there?

Or does this include some of the iOS extended library (if any?) from Apple?

Sorry if this is a dumb question, I'm not quite familiar with iOS ecosystems.

It just means that the Starter Edition (aka the free version) does not allow P/Invoking into C libraries.

You can still use all of Apple's APIs and bindings for third-party Objective-C libraries.

You can actually use the Starter Edition to publish a small application. Wow! This will increase the adoption of Xamarin ...

I've mostly worked on the server side of things for the last few years but last year I decided to dip into mobile. I felt disappointed after trying MonoDevelop as I found a lot of the things I had really appreciated in server development missing or inadequate. Things like a proper package manager and easy integration with CI servers. I just got NuGet to work last month, after trying it infrequently over a couple of months. xbuild, I never got to work properly, sure I was able to run unit tests inside MonoDevelop but my expectations were a bit higher.

Meanwhile, over in Javaville, I can do just about anything Android related my heart desires with Maven and even CocoaPods in its infancy was a better experience than NuGet. Just my 2 cents.

This looks very nice, in particular the free version. I would never consider trying a runtime that can expire, even for experimenting.

They still don't have a Linux version though, which is disappointing, since I can't try it.

True, but judging from Miguel's stance on the use of Linux for a desktop OS, I doubt we'll be seeing a Linux port of it.

While C# looks like a great language, and I'm looking forward to playing with this, does Xamarin really allow you to share that much code between platforms?

In my experience, 75% of my mobile app code tends to be either working with platform-specific APIs or just quite trivial. Is the potential for code reuse high enough to justify the extra layer of stuff to understand (and potentially break)?

Edit: I can see how being able to use C# is a plus for some people, I guess I'm just slightly skeptical of the cross-platform selling point.

Here are two developers that have shared some stats on code reuse:

iCircuit http://praeclarum.org/post/42378027611/icircuit-code-reuse-p...

TouchDraw http://lipsky.me/blog/2012/9/11/touchdraw-code-reuse-updated

Ahh, hard stats vs. gut instinct. That's interesting, thanks. I'd still be concerned that dealing with the differences between native APIs may take up an amount of time not reflected by a LOC count, but I'm more tempted to give it a try...

I am a bit ambivalent - on one side, as I think about new product ideas that will naturally be multiplaform, something like this is very appealing in theory, but my experience tells me that the lowest-common-denominator approach has almost always failed.

I wonder how folks are thinking about that problem - i.e., if you are starting a new app from scratch - even if you are doing iOS only initially - do you go objective-c or xamarin/c# ?

it's quite hard to make an educated decision.

any thoughts?

We do not actually provide a lowest-common-denominator.

It is simpler to think of Xamarin as providing you with:

* C# language on iOS, Android, Mac * 1:1 API bindings to whatever is native on a given platform. On iOS, the CocoaTouch APIs, on Android, the Android APIs, on Mac the Cocoa/CoreFoundation-based APIs.

From this basic setup, you can already see that you wont get code that will run on all platforms. You will need to split your code into cross-platform code (database access, web services, xml, json parsing, offline caches, authentication) and things that are UI-specific (Android activities, Android widgets, iOS View Controllers, and so on).

>We do not actually provide a lowest-common-denominator.

This actually is the reason I keep away from Xamarin, and I guess I'm not alone...

I think that there is a room for having a cross-platform lowest-common-denominator, including UI, File system, Networking, etc... with ability to dive into platform specific details when needed.

We've got some abstractions that build on top of the native APIs as well such as Xamarin.Mobile.

Nothing stops you from treating Xamarin as one.

But it also supports the full experience for each platform.

You can't treat Xamarin as one... e.g. you can't write a simple calculator UI in a cross-platform way - You would have to code the UI part separately for iOS and Android.

At least, that's my understanding and OP (Miguel) confirms it. And I guess your mileage won't vary in this aspect ;)

Although, Xamarin.Mobile is a step in the right direction, as commented here.

>You can't treat Xamarin as one... e.g. you can't write a simple calculator UI in a cross-platform way - You would have to code the UI part separately for iOS and Android.

Yes, but they do offer a "base" abstraction layer besides the C# libraries, that includes stuff like GPS access, accelerometers, etc.

As for the UI part, one could use a Webkit View as the view, and link the various heavy actions to C# code. For something like a common denominator UI, for a simple calculator or some form based stuff, it would be perfectly fine.

It isn't a lowest-common-denominator approach. We expose the entire native API on each platform. So anything you can do in Objective-C, you can do in C#.


I see. In your experience, do people end up complementing the platform-specific C# UI code with native (e.g., objectiveC) pieces?

My worry is there are so many nuances in building a rich UI app - that even searching/finding samples online for specific things will make me want to have native/objectiveC elements into it - as opposed to trying to hack the sample in C#. I just want to copy and paste!

How does that native-C# binding happen? Is it user friendly? Is it your expectation that most folks out there will have this duality? (if not most of the UI code being native?)

I am literally sitting on a new idea that will be multi platform by nature and am wondering all these things as we speak here.

In my experience, all the code is written in C#. The only time when folks use Objective-C is when they are bringing some existing library they found on GitHub to their project. And even in those cases, they dont actually write Objective-C, they just use the library.

In my experience, copy-paste development is seldom a recipe for creating high-quality applications. So I do not think you should be worried about not being able to cut and paste code, you will be better off understanding what the code is doing and adapting your code (even if you do so in Objective-C).

As for how the C# binding happens, it is very simple.

Each Objective-C type exists with the same name in C#. You typically use intellisense to navigate the API.

For example, the Objective-C code: [foo addSubview:bar] becomes: foo.AddSubview (bar) in C#

The best thing to do is to follow our tutorials to get a taste for it.

I will let one of the Xamarin guys speak to this in detail but having built a couple apps for customers with Monotouch I can tell you that you can pull in some native objective c libs for things like richer UI. There is a method for creating a binding to a native objc libs and using it from C#. I use ATMHud, TestFlight and Flurry in one of my apps - all of which are built from bindings to the native objc libraries.

The other thing I will say is that while there are 1:1 API mappings they have also went out of their way to make some common and rigorous tasks simpler. TableViewSource is one that comes to mind, simplifies the UITableView scenarios.

I think you'll actually find that translating Objective-C snippets into C# to be trivial for the most part.

For third-party ObjC libraries, a lot of the more popular ones are already bound.

Writing your own C# bindings for ObjC isn't that difficult, but there is a learning curve involved. We're working on making improved tools to automate more of it, though. In the meantime, we've got a guy that is writing the bindings for libraries based on popular demand.

A lot of the bindings can be found here: https://github.com/mono/monotouch-bindings

The LCD argument is false here, there is nothing that can be done in Objective C through public APIs I cannot do with C#/Xamarin. The day after iOS 6 was released, Xamarin had an update to Monotouch. The betas were available before that as well.

I think for me, having a decade plus of C# experience this was a no-brainer. Moving from building web apps to mobile on a new platform was a big shift and removing the confusion of a new language helped smooth the transition.

Just to clear things up, Xamarin.iOS and Xamarin.Android are not really "lowest common denominator". They are full bindings for the underlying platform APIs.

Does this mean that MonoDevelop is now officially dead?

No, it's still very much alive and kicking: https://github.com/mono/monodevelop/commits/master

This is a pretty cool deal; nice to see an open-source powered company that has found a self-supporting niche.

It will be interesting to see how they strike a balance between making money and keeping things (like Mono.Mac, MonoDevelop, etc.) open... and if they are able to build a community of outside contributors around the open-source parts of their solution(s).

I was wondering about this. Are they planning to keep some part open source? I feel like they ditched that entire idea...

MonoDevelop, MonoMac, and Mono itself are still all open source.





Xamarin also has a number of open source modules on github: https://github.com/xamarin

It would be nice to see a blog post or two on the mile-high long-term etc. goals Xamarin has for the open source aspects of their tech... or perhaps a pointer to any existing summary. As you've pointed out, Xamarin is rather quietly contributing a lot; it would be great to have a place to point the non-developers to that explained this as well.

Do you mind emailing me a list of questions, to make sure I address all of them?

My blogging has gone down, due to twitter mostly, but this is a good chance to talk about our open source work.

Cheers! Miguel

That would be really great. Me being skeptical pays off after all. This is why HN is so great.

I look forward to your blog post.

I'll bring this up with Miguel.

It seems that you will now charge for Mac only development via XamerinStudio? Is that correct? At least, when I went to clarify the multi-buy discount for Indy, I saw to my utter horror that Xamarin.Mac is an included option at $299. So, what does that mean to Mac only Developers? Are we now forever restricted to a 32kb app with no third party P/Invokes too? I'm certainly not ever in 1,000,000 years ever giving you a penny for the Mac target. I think this is an extremely worrying move on Xamerin's part and if we really do have to buy a subscription to get continued support, I really do feel betrayed. I mean, come on, Apple have charged $5 for XCode for a short period for as long as it has existed. And I can open it now and create an app for free. I really don't understand this move. I'm hoping I've get the wrong idea and Miguel (et al) will correct me.

I'm been pretty excited about Xamarin for quite some time, but today I'm not as excited.

The new Studio looks great, but there isn't a Linux version. This makes me very, very sad.

The one thing that could make me very happy, however, is if they target the Ubuntu mobile/touch SDK in the future. Wonder if this is on the horizon?

If the Ubuntu mobile/touch devices become popular, I have no doubt that we'll come out with a product for writing Ubuntu mobile apps as well.

We're always looking into supporting other mobile platforms.

We've just pushed all of our MonoDevelop source code to public github and I'm sure that the Ubuntu packagers will be packaging it for Ubuntu very soon.

Bummer, Mac OS 10.7.x required.

(Edit: I've been reluctant to upgrade from Snow Leopard, but maybe I should reevaluate.)

I held out for a really long time on 10.6 but upgraded a few months ago after buying a new machine and it was a lot less painful than I'd imagined - worth a go, though, as always with OS X, a fresh install may ultimately be less painful than upgrading, even if it's time consuming.

Actually, my old Intel iMac at home can't even run Lion!

The main reason I always wait to upgrade is for kinks to be worked out in OS X ports of mainly-GNU/Linux software.

When starting out with mobile apps i always wonder if it pays off to invest heavily in something like this (i love C#) or put my money on web-tech based apps especially if looking at it mid/long term. I know web-tech isnt there yet, but its not far off. What do you think ?

This is great work.

Working with monodevelop was a pain in MacOS.

Downloading it now, but from the sales page alone they got me.

Good work!



We fix the bugs, and the fixes ship on their own release cadence, when they happen to catch the next QA train.

But enterprise customers typically develop/QA against a version, and are not willing to upgrade to v.Next that contains the fix and a dozen other fixes. They want the exact version they have been using, with only the one fix applied.

Makes sense?

Hi Miguel

Congratulations on the release.

But I think you replied to the wrong thread.

No, what happened was the parent deleted his comment.

Don't know why - it was a decent question with a decent answer.

The poster deleted the comment I was replying to.

We do releases fairly frequently with bug fixes for all of our products. What is meant by hot-fixes is custom builds of a specific version of a product w/ a bug fix.

For Xamarin Studio (the product I work on), I often provide bug reporters with the latest internal build with my patch for their bug no matter what subscription they have (at least for the bigger issues). It's not quite the same thing, but I suspect that'd be good enough for most people until the next official point-release.

I have not been able to determine from usage, but one of my gripes with MD - XCode was the sync logic seemed to sometimes block or get kind of slow at time and my Studio experiences have not been as bad, where changes made in this area or am I just getting lucky?

Yea, there have been some bug fixes since the 3.x versions. You may also be getting lucky, but I hope it's the former and not the latter! ;-)

If I have a team (a "team" of me +2, don't think too big) of coders proficient in both C# and C++, what advantages would using Xamarin bring over having the common/cross-platform code in c++ (objective c++, ok...) and using the platform specific languages and tools for the UI and whatever else ends up being platform specific? (besides C# being a much nicer language, of course)

There are tons of sdks and libraries that you can use with C# / .net. To name just a small few that I have used: Stripe's .net sdk, parse.com's sdk, amazon's sdk for .net... the list goes on and on. Pull their dlls in and just use them. It makes a cinch of hooking into other services.

Hah, I knew I should've pulled the trigger on buying MonoTouch last week!

Oh well, at least I can do some testing on a real device without buying anything for the moment.

From looking at the comparison chart on https://store.xamarin.com/ , the LLVM optimising compiler only seems to be available for Business or above. What does this mean in practice?

Looks interesting but the prices are about equivalent to MSDN subscriptions. Does this make financial sense for most C# developers?

The activation stage of the download isn't working for me. Servers appear to be hosed.

So does this version support building native OS-X apps, aka uses the cocoa UI elements instead of gtk# or something similar? I played with this a while back and I couldn't get the UI to look native at all, it was quite disappointing.

Getting 500 error on download page, is there any mirror for dmg file ? :)


Our servers buckled a little bit under the load. We load-tested, but missed a piece of infrastructure in the chaos. We've since beefed up that last piece of infrastructure, and you should be all set now to use the download form at http://xamarin.com/download. If you're still having trouble, contact our support at support@xamarin.com. Cheers!

It's a shame that Linux support at Xamarin is obviously dropped in many places, so no Mono development for me. :(

The downloading seems to be halted on my Mac. I'm using a case-sensitive partition. Does this matter?

Is anyone else encountering errors with the installation? I'm on a Mac 10.8.2

How to add database addin to xamarin studio to get database access ?

You may want to check out something like SQLite-Net: https://github.com/praeclarum/sqlite-net

Really easy to setup and get up and running!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact